Donald Sharp [Sun, 22 Mar 2020 18:50:46 +0000 (14:50 -0400)]
bgpd: More `const struct prefix` work
Modify more code to use `const struct prefix` throughout
bgp. This is all prep work for adding an accessor function
for bgp_node to get the prefix and reduce all the places that
code needs to be touched when we get that work done.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Sat, 21 Mar 2020 12:22:51 +0000 (08:22 -0400)]
isisd: Expand send/receive buffers to allow for larger mtu
User is reporting:
2020/03/21 03:12:36 ISIS: isis_send_pdu_bcast: sock_buff size 8192 is less than output pdu size 9014 on circuit em0
2020/03/21 03:12:36 ISIS: [EC 67108865] ISIS-Adj (1): Send L2 IIH on em0 failed
MTU's can frequently hit 9k in size, we have buffer limits
that prevent this from being fully used and creating errors.
Modify the code to allow for up to 16k mtu
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Martin Winter [Fri, 20 Mar 2020 22:50:29 +0000 (23:50 +0100)]
tests: Make topotest working on different locale
"sort" as used in all-protocol-startup used sort which causes
different sort order based on locale settings. Specify the
correct one to make output matching our expected result
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Donald Sharp [Fri, 20 Mar 2020 00:19:50 +0000 (20:19 -0400)]
bgpd: Convert #define of bgp fsm events to an enum
In PR #6052 which fixes issue #5963 the bgp fsm events
were confused with the bgp fsm status leading
to a bug. Let's start separating those out
so these types of failures cannot just
easily occur.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
the vtysh command to set the isis metric on an interface
is 'isis metric level-1 X', but when showing the running
config we were displaying it as 'isis metric X level-1'.
This would confuse frr-reload.py when attempting to apply
a config file populated with the correct command; on the
other hand, using the show command format would return an
error when running vtysh -C on the file.
Fix this by making the show command return the same format
as the vtysh setting command.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
vivek [Wed, 18 Mar 2020 22:40:04 +0000 (15:40 -0700)]
bgpd: Allow EVPN advertise route-map to modify attributes
Ensure that the EVPN advertise route-map is applied on a copy of the
original path_info and associated attribute, so that if the route-map
has SET clauses, they can operate properly. This closely follows
the model already in use in other route-map application code.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ruben Kerkhof [Thu, 19 Mar 2020 13:00:20 +0000 (14:00 +0100)]
bgpd: use the right format specifier
Fixes:
/Library/Developer/CommandLineTools/usr/bin/make all-am
CC bgpd/bgp_attr.o
bgpd/bgp_attr.c:2664:5: warning: format specifies type 'unsigned char' but the argument has type 'uint16_t' (aka 'unsigned short') [-Wformat]
length, STREAM_READABLE(peer->curr));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./lib/log.h:94:50: note: expanded from macro 'flog_err'
zlog_err("[EC %" PRIu32 "] " format, ferr_id, ##__VA_ARGS__)
~~~~~~ ^~~~~~~~~~~
1 warning generated.
Donald Sharp [Thu, 19 Mar 2020 12:24:37 +0000 (08:24 -0400)]
tests: Increase some wait time in tests
The bfd-bgp-cbit-topo3 test is testing bfd timers
with some timers that only wait 4 seconds. The CI
system is failing in various places due to bfd
not converging properly. Upon logging into a
CI system and running tests with intensive disk i/o
I was able to make the tests fail repeatedly in
a couple of different places. Add some additional
time to allow the system to converge on our CI
systems that are running in vm's and may not
always have complete control of cpu's.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Wed, 18 Mar 2020 03:36:05 +0000 (20:36 -0700)]
bgpd: Strip Route Targets during VRF-to-VRF route leak
During VRF-to-VRF route leaking, strip any extraneous route targets. This
ensures that source-VRF-specific route targets or route targets that are
internally assigned for the VRF-to-VRF route leaking don't get attached
to the route in the target VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
vivek [Wed, 18 Mar 2020 03:27:23 +0000 (20:27 -0700)]
bgpd: Make strip extcommunity handle multiple extcommunities
Extended communities like the BGP Route Target can be present multiple
times in a route's path attribute. Ensure that the strip function for a
particular extended community (type and subtype) handles this and
strips all occurrences.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
vivek [Wed, 18 Mar 2020 02:59:52 +0000 (19:59 -0700)]
bgpd: Refine multiaccess check for next hop resetting
A BGP update-group is dynamically created to group together a set of peers
such that any BGP updates can be formed just once for the entire group and
only the next hop attribute may need to be modified when the update is sent
out to each peer in the group. The update formation code attempts to
determine as much as possible if the next hop will be set to our own IP
address for every peer in the group. This helps to avoid additional checks
at the point of sending the update (which happens on a per-peer basis) and
also because some other attributes may/could vary depending on whether the
next hop is set to our own IP or not. Resetting the next hop to our own IP
address is the most common behavior for EBGP peerings in the absence of
other user-configured or internal (e.g., for l2vpn/evpn) settings and
peerings on a shared subnet.
The code had a flaw in the multiaccess check to see if there are peers in
the update group which are on a shared subnet as the next hop of the path
being announced - the source peer could itself be in the same update group
and cause the check to give an incorrect result. Modify the check to skip
the source peer so that the check is more accurate.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
vivek [Wed, 18 Mar 2020 02:25:13 +0000 (19:25 -0700)]
zebra: Install nexthop's weight for IPv4 routes with IPv6 next hops
Ensure that any weight associated with the next hop is installed for
IPv4 routes with IPv6 next hops too.
Updates: lib, zebra: Allow for installation of a weighted nexthop
bgpd: support for match ip address next-hop address command
this command is missing, compared with 'match ipv6 next-hop' command
available. Adding it by taking into account the backward compatible
effect when supposing that some people have configured acls with name
being an ipv4 address.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Mon, 16 Mar 2020 21:23:34 +0000 (17:23 -0400)]
bgpd: Fix certain code paths that reset reason code
The bgp reason code was being reset in bgp_best_selection
by rerunning bgp_path_info_cmp multiple times under certain
receiving patterns of data from peers.
This is the debugs that show this issue:
2020/03/16 19:17:22.523780 BGP: 2001:20:1:1::6 rcvd UPDATE w/ attr: nexthop 20.1.1.6, origin i, metric 600, community 1000:1006, path 20
2020/03/16 19:17:22.523819 BGP: 2001:20:1:1::6 rcvd 20.10.0.6/32 IPv4 unicast
2020/03/16 19:17:22.556168 BGP: 20.1.1.6 rcvd UPDATE w/ attr: nexthop 20.1.1.6, origin i, metric 500, community 1000:1006, path 20
2020/03/16 19:17:22.556209 BGP: 20.1.1.6 rcvd 20.10.0.6/32 IPv4 unicast
2020/03/16 19:17:22.572358 BGP: bgp_process_main_one: p=20.10.0.6/32 afi=IPv4, safi=unicast start
2020/03/16 19:17:22.572408 BGP: 20.10.0.6/32: Comparing path 2001:20:1:1::6 flags 0x410 with path 20.1.1.6 flags 0x410
2020/03/16 19:17:22.572415 BGP: 20.10.0.6/32: path 2001:20:1:1::6 loses to path 20.1.1.6 due to MED 600 > 500
2020/03/16 19:17:22.572422 BGP: 20.10.0.6/32: path 20.1.1.6 is the bestpath from AS 20
2020/03/16 19:17:22.572429 BGP: 20.10.0.6/32: path 20.1.1.6 is the initial bestpath
2020/03/16 19:17:22.572435 BGP: bgp_best_selection: pi 0x5627187c66c0 dmed
2020/03/16 19:17:22.572441 BGP: 20.10.0.6/32: After path selection, newbest is path 20.1.1.6 oldbest was NONE
2020/03/16 19:17:22.572447 BGP: 20.10.0.6/32: path 20.1.1.6 is the bestpath, add to the multipath list
2020/03/16 19:17:22.572453 BGP: 20.10.0.6/32: path 2001:20:1:1::6 has the same nexthop as the bestpath, skip it
2020/03/16 19:17:22.572460 BGP: 20.10.0.6/32: starting mpath update, newbest 20.1.1.6 num candidates 1 old-mpath-count 0 old-cum-bw u0
2020/03/16 19:17:22.572466 BGP: 20.10.0.6/32: comparing candidate 20.1.1.6 with existing mpath NONE
2020/03/16 19:17:22.572473 BGP: 20.10.0.6/32: New mpath count (incl newbest) 1 mpath-change NO all_paths_lb 0 cum_bw u0
Effectively if BGP receives 2 paths it could end up running bgp_path_info_cmp multiple times
and in some situations overwrite the reason selected the first time through.
In this example path selection is run and the MED is the reason for the choice.
Then in bgp_best_selection is run again this time clearing new_select
to NULL before calling path selection for the first time. This second
call into path selection resets the reason, since it is only passing in one
path. So save the last reason selected and restore in this case.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
saravanank [Mon, 16 Mar 2020 02:23:38 +0000 (19:23 -0700)]
zebra: Disable rmap update thread before routemap_finish while shutting down zebra
Problem: While zebra going down, rmap update thread is being called as part of
timer event. This make zebra to crash.
RCA: At this time route_map_master_hash is made to 0 by sig int handler.
This is causing Zebrad to crash while executing rmap update thread
Fix: As part of SIGINT handler, before calling routemap_finish,
thread off any routemap update scheduled at that point and make sure that
it wont get scheduled again by making the timeout as 0.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Sarita Patra [Mon, 2 Mar 2020 08:55:22 +0000 (00:55 -0800)]
pimd: fix OIL not removed after IGMP prune
Issue: Client1------LHR-----(int-1)RP(int-2)------client2
Client2 send IGMP join for group G.
Client1 send IGMP join for group G.
verify show ip mroute in RP, will have 2 OIL.
Client2 send IGMP leave.
Verify show ip mroute in RP, will still have 2.
Root cause: When RP receives IGMP join from client2, it creates
a (s,g) channel oil and add the interface int-2 into oil list and
set the flag PIM_OIF_FLAG_PROTO_IGMP to int-2
Client1 send IGMP join, LHR will send a (*,G) join to RP. RP will
add the interface int-1 into the oil list of (s,g) channel_oil and
will set the flag PIM_OIF_FLAG_PROTO_IGMP and PIM_OIF_FLAG_PROTO_PIM
to the int-1 and set PIM_OIF_FLAG_PROTO_PIM to int-2 as well. It is
happening because of the pim_upstream_inherited_olist_decide() and
forward_on() get all the oil and update the flag wrongly.
So now when client 2 sends IGMP prune, RP will not remove the int-2
from oil list since both PIM_OIF_FLAG_PROTO_PIM & PIM_OIF_FLAG_PROTO_IGMP
are set, it just unset the flag PIM_OIF_FLAG_PROTO_IGMP.
Fix: Introduced new flags in if_channel, PIM_IF_FLAG_MASK_PROTO_PIM
& PIM_IF_FLAG_MASK_PROTO_IGMP. If a if_channel is created because of
pim join or pim (s,g,rpt) prune received, then set the flag
PIM_IF_FLAG_MASK_PROTO_PIM. If a if_channel is created becuase of IGMP
join received, then set the flag PIM_IF_FLAG_MASK_PROTO_IGMP.
When an interface needs to be added into the oil list check if
PIM_IF_FLAG_MASK_PROTO_PIM or PIM_IF_FLAG_MASK_PROTO_IGMP is set, then
update oil flag accordingly.
Issue 1: "show ip pim interface traffic" not show prune TX/RX
Rootcause : not added the variable in the json
Fix : add prune TX/RX in show ip pim interface traffic json
Issue 2: "show ip pim rp-info" not shows the key iAmRp when it is false
Rootcause: Only display the key when the value is true.
Fix: add iAmRp as false in show ip pim rp-info json
Issue 3: "show ip pim rp-info" not showing outbound interface if it is empty
Rootcause: Only display when there is any OIL
Fix: When RP is not reachable then, the outbound interface is Unknown
The command "show ip pim rp-info json" not displaying the outbound
interafce if it is unknown
Sarita Patra [Mon, 9 Mar 2020 06:23:16 +0000 (23:23 -0700)]
pimd: add flags in show ip mroute command
S - Sparse Mode
C - indicates there is a member of the group directly connected to the router.
R -set on an (S, G) by the receipt of an (S, G) RP bit prune message.
F -This indicates that this router is a FHR and send register messages to RP to inform RP of this active source
P - OIL list is NULL. That means the router will send a prune.
T - At least one packet received via SPT.
Donatas Abraitis [Sun, 15 Mar 2020 12:19:11 +0000 (14:19 +0200)]
bgpd: Add subcodes for BGP Finite State Machine Error
Implement https://tools.ietf.org/html/rfc6608
I used python scapy library to send a notification message in OpenSent state:
```
send(IP(dst="192.168.0.1")/TCP(sport=sp,
dport=179,
seq=rec.ack,
ack=rec.seq + 1,
flags=0x18)/BGPHeader(type=3)/BGPNotification(error_code=4,
error_subcode=0))
```
Logs from FRR:
```
%NOTIFICATION: sent to neighbor 192.168.0.2 5/1 (Neighbor Events Error/Receive Unexpected Message in OpenSent State) 0 bytes
```
saravanank [Mon, 16 Mar 2020 02:36:33 +0000 (19:36 -0700)]
pimd: moving the route_unlock_node outside debug function
Problem: Route node is not de referenced after search when pim debug events are
not enabled when pim_rp_find_match_group is called. So this memory will not get
released when route node is deleted after hitting this path.
RCA: Dereferencing is done inside debug condition.
Fix: Moving outside debug condition
Signed-off-by: Saravanan K <saravanank@vmware.com>
projects / mirror_frr.git / log