summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Fixup of warnings in the codeDonald Sharp2015-07-2625-79/+44
| | | | | | | | | Ticket: None Reviewed by: Trivial Testing: A bunch of warnings have crept in to the code base. This fixes the issue
* Fix bugs reported by coverity scanDenil Vira2015-07-233-12/+4
| | | | | | | | | | | | | | | | 1. Fix useless call in bgpd/bgp_mplsvpn.c Coverity scan ID : 1302528. Calling "decode_label(pnt)" is only useful for its return value, which is ignored. Removed the call. 2. Fix logically dead code in lib/stream.c Coverity Scan ID 1302488. Test for size==0 makes no sense, since assert immediately before it would not let this code happen. 3. Fix Free Pointer dereference in lib/filter.c Coverity Scan ID 23056. access is accessed after free in access_list_delete
* Fix bgp_route.c missing codeDonald Sharp2015-07-231-3/+2
|
* Some more missing changesDonald Sharp2015-07-223-5/+24
|
* Cleanup of missing NEXTHOP_FORCE_SELFDonald Sharp2015-07-224-56/+107
|
* Fixup of some last remaining differences between stg and gitDonald Sharp2015-07-224-8/+6
|
* ptm-integration.patchDonald Sharp2015-07-224-127/+212
| | | | | | | | | | Integrates Prescriptive Topology Module(ptm) into quagga. If this module is enabled, link ups are notified only after the link is verified as being connected to the neighbor specified. The neighbor specification and checking is done by the ptm daemon. <This is a recommit of this patch because it was changed in situ>
* Fixup of peer memory leaks in bgpDonald Sharp2015-07-222-19/+22
| | | | | | | | | | When deleting a set of peers, the peer->group pointer was being set to NULL and then passed into peer_delete. peer_delete has functionality to safely remove the peer->group structure if it non-null and to remove the peer->group if it's refcnt reaches zero. This is a day one bug in the quagga source tree.
* multipath is broken if deterministic-med is enabledDaniel Walton2015-07-221-7/+1
|
* bgpd-capability-cleanup.patchDonald Sharp2015-07-223-23/+56
| | | | | | | | | | | BGP: Make Capability handling a little more robust This patch does two things: - Returns the right sub error code when a malformed capability is rcvd - Verifies that the capability length is a multiple of an individual unit Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
* Call of quagga-reload.py does not return error codeDonald Sharp2015-07-221-0/+1
|
* This patch changes ospfd from only listening mode for BFD status updates to ↵Donald Sharp2015-07-2228-431/+1285
| | | | | | | | | | | | | | | | | | interactive mode of dynamically registering/deregistering neighbors discovered on BFD enabled interfaces with PTM/BFD through zebra. Neighbor is registered with BFD when 2-way adjacency is established and deregistered when adjacency goes down if the BFD is enabled on the interface through which the neighbor was discovered. OSPF BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx). interface <if-name> ip ospf bfd <detect mult> <min rx> <min tx> This patch also adds BFD support for IPv6 OSPF. ospf6d will dynamically register/deregister IPv6 neighbors with BFD for monitoring the connectivity of the neighbor. Neighbor is registered with BFD when 2-way adjacency is established and deregistered when adjacency goes down if the BFD is enabled on the interface through which the neighbor was discovered. OSPF6 BFD command added to configure BFD and parameters (detect multiplier, min rx and min tx). interface <if-name> ipv6 ospf6 bfd <detect mult> <min rx> <min tx> Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
* When IPv6 peer BFD down status is received by BGP, all the the peers for ↵Donald Sharp2015-07-223-15/+33
| | | | | | which the BFD is enabled are brought down. This happens due to reverse memcmp check of destination and source IPv6 addresses with the BFD enabled BGP peers. Fixed it by doing the memcmp correctly. Also, there is no reason stored in the last_reset field when BGP peer goes down due BFD. Incorrect/no peer down reason can get logged when BGP peer goes down due to BFD. Fixed it by adding new BFD peer down reason code and storing it in the peer last_reset field when peer is broght down due to BFD.
* The last BGP peer down reason code "PEER_DOWN_V6ONLY_CHANGE" has no ↵Donald Sharp2015-07-221-1/+2
| | | | corresponding logging/display string defined in "peer_down_str". This will cause incorrect or empty down reason to get logged when the peer is brought down because of interface based v6only config change.
* bgpd-interface-ipv4-cmd.patchDonald Sharp2015-07-224-24/+141
| | | | | | | | | | | | BGP: Determine peer's IP address if interface has /30, /31 Allow interface-based session config for IPv4 numbered links if the link address is either /30 or /31. This is not RFC5549, but can be deployed now, and independent of whether the peer supports RFC5549 or not. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-By: Vivek Venkataram <vivek@cumulusnetworks.com>
* quagga-fix-stop-vty.patchDonald Sharp2015-07-221-1/+1
| | | | | | When stopping quagga, we do not wait for quagga to finish shutting down before we start attempting to delete the sockets for the various protocols.
* The MD5 password configured for a BGP peer was incorrectly gettingDonald Sharp2015-07-222-4/+12
| | | | | | deleted from the listen socket in some situations. This would lead to incorrect behavior where a BGP connection from a peer that does not specify the MD5 option would be accepted.
* watchquagga-mode-3-fix.patchDonald Sharp2015-07-222-10/+3
| | | | | | | | | | | | | | | | Watchquagga: In phased restart with zebra, invoke restart all when zebra dies To correctly handle starting and stopping of individual daemons not affecting watchquagga's monitoring, we resorted to fixing up watchquagga's daemon watch list every time a daemon was started or stopped. This was done by restarting watchquagga itself. This meant the handling of phased restart of individual daemons was broken in watchquagga as it attempted to stop daemons individually before starting them all individually. Fix this by restarting all when this happens. This does make mode 4 indistinguishable from mode 1, but I don't understood the point of mode 4 and we don't think users change watchquagga modes. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
* Add optional json capability to the "show ip ospf neighbor", "show ip ospf ↵Donald Sharp2015-07-221-80/+211
| | | | neighbor all", and "show ip ospf neighbor IFNAME" commands and whatever functions that they call.
* Add json capability to the "show ip ospf interface [INTERFACE]" and "show ip ↵Donald Sharp2015-07-221-117/+296
| | | | ospf <1-65535> interface [INTERFACE]" commands and whatever functions that they call. Option shows up as {json}.
* Add json capability to the ospf commands: "show ip ospf" and "show ip ospf ↵Donald Sharp2015-07-221-190/+498
| | | | <1-65535>". Optional argument will be {json} and will output a json object with all applicable information.
* Use camelCase notation for all json keywordsDonald Sharp2015-07-224-64/+64
|
* # This series applies on GIT commit ace4704890f1351ba5568c92bedc88c378acfeebDonald Sharp2015-07-220-0/+0
| | | | | | | | | | | | | | | | | | bgpd-json-use-camelcase-keywords.patch ospfd-show-ip-ospf-json.patch ospfd-json-ospf-interface.patch ospfd-json-ospf-neighbor.patch watchquagga-mode-3-fix.patch bgpd-fix-peer-password-reset.patch quagga-fix-stop-vty.patch bgpd-interface-ipv4-cmd-patch bgpd-fix-v6only-config-change-down-reason.patch bgpd-bfd-fix-peer-flap.patch ospfx-bfd-dynamic-support.patch quagga-reload-error.patch bgpd-capability-cleanup.patch bgpd-multipath-with-deterministic-med.patch bgpd-peer-memory-leaks.patch
* Remove draft-walton-bgp-hostname-capability-00 for nowDonald Sharp2015-06-128-335/+19
|
* ipv6_ll_address_to_mac() fails to correctly convert ↵Donald Sharp2015-06-121-2/+1
| | | | fe80::a8aa:aaff:feaa:aaf8 to AA:AA:AA:AA:AA:F8
* bgpd-5549-display-ll-ifname.patchDonald Sharp2015-06-121-8/+40
| | | | | | | | | | | BGP: Display Link local addr and ifname as part of 5549 support As part of BGP unnumbered and RFC 5549 support, the implementation will honor the link local address as the NH if present and so it'd be useful to display that info along with the interface name, when displaying the BGP route summary. That is what this patch aims to do. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
* bgpd-addpath-rx-cap-fix.patchDonald Sharp2015-06-121-1/+15
| | | | | | BGP: Make Addpath capability failure handling more inline with other cap. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
* BGP: Restart the BGP FSM if update source fails.Donald Sharp2015-06-121-6/+12
| | | | | | | | | | | | | | | For IPv6, update source sometimes fails at the first attempt. If we continue ignoring the error, some sessions will not come up. If instead we check for the error and return connect_error, the FSM will reset its state and try again till the update source bind succeeds and the session will come up. This patch adds checking for the result of bind and update_source to return connect_error or success. The rest of the code handles the situation correctly after that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
* bgpd-set-somark.patchDonald Sharp2015-06-123-0/+27
| | | | | | | | | | | | | BGP: Set SO_MARK on connecting sockets to ensure lookup in right routing table In the presence of a function such as management VRF/MRF, bgpd needs to be able to specify that it intends to run in the dataplane and not the front panel. To ensure this, we add a mark in the connecting socket so that the kernel does the routing lookup in the right table. This assumes that an appropriate ip rule has been configured (outside the scope of this package). While we've forced the mark to be 254 for now, it maybe required to make it configurable at a later time.
* This patch changes BGP from only listening mode for BFD status updates to ↵Donald Sharp2015-06-1233-320/+2870
| | | | | | | | | | | | | | | | interactive mode of dynamically registering/deregistering BFD enabled peers with PTM/BFD through zebra. Peer is registered with BFD when it goes into established state and de-registers when it goes out of establish state. This patch also adds BFD multihop support for BGP. Whether a peer is multi-hop or single hop is determined internally. All IGP peers are considered as multi-hop peers. EBGP peers are considered as single hop unless configured as multi-hop. BGP BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx). router bgp <as-number> neighbor <name/ip-address> bfd <detect mult> <min rx> <min tx> Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com> Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
* Key changes:Donald Sharp2015-06-1214-476/+578
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - The aspath and community structures now have a json_object where we store the json representation. This is updated at the same time the "str" for aspath/community are updated. We do this so that we do not have to compute the json rep - Added a small wrappper to libjson0, the wrapper lives in quagga's lib/json.[ch]. - Added more structure to the json output. Sample output: show ip bgp summary json ------------------------ BGP router identifier 10.0.0.1, local AS number 10 BGP table version 2400 RIB entries 4799, using 562 KiB of memory Peers 17, using 284 KiB of memory Peer groups 4, using 224 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 1.1.1.1 4 10 0 0 0 0 0 never Active 10.0.0.2 4 10 104 7 0 0 0 00:02:29 600 10.0.0.3 4 10 104 7 0 0 0 00:02:29 600 10.0.0.4 4 10 204 7 0 0 0 00:02:29 1200 20.1.1.6 4 20 406 210 0 0 0 00:02:44 600 20.1.1.7 4 20 406 210 0 0 0 00:02:44 600 40.1.1.2 4 40 406 210 0 0 0 00:02:44 600 40.1.1.6 4 40 406 210 0 0 0 00:02:44 600 40.1.1.10 4 40 406 210 0 0 0 00:02:44 600 Total number of neighbors 9 { "as": 10, "dynamic-peers": 0, "peer-count": 17, "peer-group-count": 4, "peer-group-memory": 224, "peer-memory": 291312, "peers": { "1.1.1.1": { "inq": 0, "msgrcvd": 0, "msgsent": 0, "outq": 0, "prefix-advertised-count": 0, "prefix-received-count": 0, "remote-as": 10, "state": "Active", "table-version": 0, "uptime": "never", "version": 4 }, "10.0.0.2": { "hostname": "r2", "inq": 0, "msgrcvd": 104, "msgsent": 7, "outq": 0, "prefix-advertised-count": 1200, "prefix-received-count": 600, "remote-as": 10, "state": "Established", "table-version": 0, "uptime": "00:02:21", "version": 4 }, "10.0.0.3": { "hostname": "r3", "inq": 0, "msgrcvd": 104, "msgsent": 7, "outq": 0, "prefix-advertised-count": 1200, "prefix-received-count": 600, "remote-as": 10, "state": "Established", "table-version": 0, "uptime": "00:02:21", "version": 4 }, "10.0.0.4": { "hostname": "r4", "inq": 0, "msgrcvd": 204, "msgsent": 7, "outq": 0, "prefix-advertised-count": 1200, "prefix-received-count": 1200, "remote-as": 10, "state": "Established", "table-version": 0, "uptime": "00:02:21", "version": 4 }, "20.1.1.6": { "hostname": "r6", "inq": 0, "msgrcvd": 406, "msgsent": 210, "outq": 0, "prefix-advertised-count": 2400, "prefix-received-count": 600, "remote-as": 20, "state": "Established", "table-version": 0, "uptime": "00:02:36", "version": 4 }, "20.1.1.7": { "hostname": "r7", "inq": 0, "msgrcvd": 406, "msgsent": 210, "outq": 0, "prefix-advertised-count": 2400, "prefix-received-count": 600, "remote-as": 20, "state": "Established", "table-version": 0, "uptime": "00:02:36", "version": 4 }, "40.1.1.10": { "hostname": "r10", "inq": 0, "msgrcvd": 406, "msgsent": 210, "outq": 0, "prefix-advertised-count": 2400, "prefix-received-count": 600, "remote-as": 40, "state": "Established", "table-version": 0, "uptime": "00:02:36", "version": 4 }, "40.1.1.2": { "hostname": "r8", "inq": 0, "msgrcvd": 406, "msgsent": 210, "outq": 0, "prefix-advertised-count": 2400, "prefix-received-count": 600, "remote-as": 40, "state": "Established", "table-version": 0, "uptime": "00:02:36", "version": 4 }, "40.1.1.6": { "hostname": "r9", "inq": 0, "msgrcvd": 406, "msgsent": 210, "outq": 0, "prefix-advertised-count": 2400, "prefix-received-count": 600, "remote-as": 40, "state": "Established", "table-version": 0, "uptime": "00:02:36", "version": 4 } }, "rib-count": 4799, "rib-memory": 575880, "router-id": "10.0.0.1", "table-version": 2400, "total-peers": 9 } show ip bgp json ---------------- *> 40.1.1.2 0 0 100 200 300 400 500 40 i * 40.3.88.0/24 40.1.1.6 0 0 100 200 300 400 500 40 i * 40.1.1.10 0 0 100 200 300 400 500 40 i *> 40.1.1.2 0 0 100 200 300 400 500 40 i * 40.3.89.0/24 40.1.1.6 0 0 100 200 300 400 500 40 i * 40.1.1.10 0 0 100 200 300 400 500 40 i *> 40.1.1.2 0 0 100 200 300 400 500 40 i "40.3.88.0/24": [ { "aspath": "100 200 300 400 500 40", "med": 0, "nexthops": [ { "afi": "ipv4", "ip": "40.1.1.6", "used": true } ], "origin": "IGP", "path-from": "external", "valid": true, "weight": 0 }, { "aspath": "100 200 300 400 500 40", "med": 0, "nexthops": [ { "afi": "ipv4", "ip": "40.1.1.10", "used": true } ], "origin": "IGP", "path-from": "external", "valid": true, "weight": 0 }, { "aspath": "100 200 300 400 500 40", "bestpath": true, "med": 0, "nexthops": [ { "afi": "ipv4", "ip": "40.1.1.2", "used": true } ], "origin": "IGP", "path-from": "external", "valid": true, "weight": 0 } ], "40.3.89.0/24": [ { "aspath": "100 200 300 400 500 40", "med": 0, "nexthops": [ { "afi": "ipv4", "ip": "40.1.1.6", "used": true } ], "origin": "IGP", "path-from": "external", "valid": true, "weight": 0 }, { "aspath": "100 200 300 400 500 40", "med": 0, "nexthops": [ { "afi": "ipv4", "ip": "40.1.1.10", "used": true } ], "origin": "IGP", "path-from": "external", "valid": true, "weight": 0 }, { "aspath": "100 200 300 400 500 40", "bestpath": true, "med": 0, "nexthops": [ { "afi": "ipv4", "ip": "40.1.1.2", "used": true } ], "origin": "IGP", "path-from": "external", "valid": true, "weight": 0 } ], show ip bgp x.x.x.x json ------------------------ BGP routing table entry for 40.3.86.0/24 Paths: (3 available, best #3, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.0.0.2 10.0.0.3 10.0.0.4 20.1.1.6 20.1.1.7 40.1.1.2 40.1.1.6 40.1.1.10 100 200 300 400 500 40 40.1.1.6 from 40.1.1.6 (40.0.0.9) Origin IGP, metric 0, localpref 100, valid, external Community: 1:1 2:2 3:3 4:4 10:10 20:20 Extended Community: RT:100:100 RT:200:200 RT:300:300 RT:400:400 SoO:44:44 SoO:55:55 SoO:66:66 Last update: Fri May 8 21:23:41 2015 100 200 300 400 500 40 40.1.1.10 from 40.1.1.10 (40.0.0.10) Origin IGP, metric 0, localpref 100, valid, external Community: 1:1 2:2 3:3 4:4 10:10 20:20 Extended Community: RT:100:100 RT:200:200 RT:300:300 RT:400:400 SoO:44:44 SoO:55:55 SoO:66:66 Last update: Fri May 8 21:23:41 2015 100 200 300 400 500 40 40.1.1.2 from 40.1.1.2 (40.0.0.8) Origin IGP, metric 0, localpref 100, valid, external, best Community: 1:1 2:2 3:3 4:4 10:10 20:20 Extended Community: RT:100:100 RT:200:200 RT:300:300 RT:400:400 SoO:44:44 SoO:55:55 SoO:66:66 Last update: Fri May 8 21:23:41 2015 { "advertised-to": { "10.0.0.2": { "hostname": "r2" }, "10.0.0.3": { "hostname": "r3" }, "10.0.0.4": { "hostname": "r4" }, "20.1.1.6": { "hostname": "r6" }, "20.1.1.7": { "hostname": "r7" }, "40.1.1.10": { "hostname": "r10" }, "40.1.1.2": { "hostname": "r8" }, "40.1.1.6": { "hostname": "r9" } }, "paths": [ { "aspath": { "length": 6, "segments": [ { "list": [ 100, 200, 300, 400, 500, 40 ], "type": "as-sequence" } ], "string": "100 200 300 400 500 40" }, "community": { "list": [ "1:1", "2:2", "3:3", "4:4", "10:10", "20:20" ], "string": "1:1 2:2 3:3 4:4 10:10 20:20" }, "extended-community": { "string": "RT:100:100 RT:200:200 RT:300:300 RT:400:400 SoO:44:44 SoO:55:55 SoO:66:66" }, "last-update": { "epoch": 1431120222, "string": "Fri May 8 21:23:42 2015\n" }, "localpref": 100, "med": 0, "nexthops": [ { "accessible": true, "afi": "ipv4", "ip": "40.1.1.6", "metric": 0, "used": true } ], "origin": "IGP", "peer": { "hostname": "r9", "peer-id": "40.1.1.6", "router-id": "40.0.0.9", "type": "external" }, "valid": true }, { "aspath": { "length": 6, "segments": [ { "list": [ 100, 200, 300, 400, 500, 40 ], "type": "as-sequence" } ], "string": "100 200 300 400 500 40" }, "community": { "list": [ "1:1", "2:2", "3:3", "4:4", "10:10", "20:20" ], "string": "1:1 2:2 3:3 4:4 10:10 20:20" }, "extended-community": { "string": "RT:100:100 RT:200:200 RT:300:300 RT:400:400 SoO:44:44 SoO:55:55 SoO:66:66" }, "last-update": { "epoch": 1431120222, "string": "Fri May 8 21:23:42 2015\n" }, "localpref": 100, "med": 0, "nexthops": [ { "accessible": true, "afi": "ipv4", "ip": "40.1.1.10", "metric": 0, "used": true } ], "origin": "IGP", "peer": { "hostname": "r10", "peer-id": "40.1.1.10", "router-id": "40.0.0.10", "type": "external" }, "valid": true }, { "aspath": { "length": 6, "segments": [ { "list": [ 100, 200, 300, 400, 500, 40 ], "type": "as-sequence" } ], "string": "100 200 300 400 500 40" }, "bestpath": { "overall": true }, "community": { "list": [ "1:1", "2:2", "3:3", "4:4", "10:10", "20:20" ], "string": "1:1 2:2 3:3 4:4 10:10 20:20" }, "extended-community": { "string": "RT:100:100 RT:200:200 RT:300:300 RT:400:400 SoO:44:44 SoO:55:55 SoO:66:66" }, "last-update": { "epoch": 1431120222, "string": "Fri May 8 21:23:42 2015\n" }, "localpref": 100, "med": 0, "nexthops": [ { "accessible": true, "afi": "ipv4", "ip": "40.1.1.2", "metric": 0, "used": true } ], "origin": "IGP", "peer": { "hostname": "r8", "peer-id": "40.1.1.2", "router-id": "40.0.0.8", "type": "external" }, "valid": true } ], "prefix": "40.3.86.0", "prefixlen": 24 }
* BGP: bestpath needs to prefer confed-external over confed-internalDonald Sharp2015-06-121-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Topology: +-----------------------------------------+ | | | AS 100 | | | | +----------------+ | +-----------+ | | | | | | | | SubAS 65001 | | | AS 90 | | | | +-------------+ | | r9----------------r1---------r2----\ | | | | | | | | | | | | | SubAS 65002 | | +-----|-----+ | | \--- r3 --/ | \-------r4 | | \---------------------/ \---------------/ | | | | | | | | | | | +----------------+ | | | | | | | | | | +----------------+ | r5 | | +-----------+ | | | | | | | | | | | SubAS 65003 | +-----|-------+ | | AS 80 | | | | | | | r8----------------r7--------r6--------------/ | | | | | | | +-----------+ | +----------------+ | +-----------------------------------------+ Important info: - r8 originates 8.8.8.8/32 - r1, r2, r3 -> r7 are 10.0.0.1, 10.0.0.2, etc - 'bgp bestpath compare-routerid' is configured everywhere (we could still hit the problem without this though) Bestpath selection for 8.8.8.8/32 on r2 and r3 is inconsistent. Here r4 advertised the 8.8.8.8/32 to r2 first, r2 then advertised it to r3, r3 selected the path from r2 as the bestpath due to lowest router-id. r2 BGP routing table entry for 8.8.8.8/32 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.0.0.1 10.0.0.3 10.0.0.4 (65002 65003) 80 10.0.0.7 (metric 50) from 10.0.0.4 (10.0.0.4) Origin IGP, metric 0, localpref 100, valid, confed-external, best Last update: Fri May 1 14:46:57 2015 r3 BGP routing table entry for 8.8.8.8/32 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.0.0.4 90.1.1.6 (65002 65003) 80 10.0.0.7 (metric 50) from 10.0.0.2 (10.0.0.2) Origin IGP, metric 0, localpref 100, valid, confed-internal, best Last update: Fri May 1 14:46:58 2015 (65002 65003) 80 10.0.0.7 (metric 50) from 10.0.0.4 (10.0.0.4) Origin IGP, metric 0, localpref 100, valid, confed-external Last update: Fri May 1 14:46:57 2015 Here r4 advertised the 8.8.8.8/32 to r3 first, r3 then advertised it to r2, r2 selected the path from r3 as the bestpath due to lowest router-id. r2 BGP routing table entry for 8.8.8.8/32 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.0.0.4 (65002 65003) 80 10.0.0.7 (metric 50) from 10.0.0.4 (10.0.0.4) Origin IGP, metric 0, localpref 100, valid, confed-external Last update: Fri May 1 15:37:27 2015 (65002 65003) 80 10.0.0.7 (metric 50) from 10.0.0.3 (10.0.0.3) Origin IGP, metric 0, localpref 100, valid, confed-internal, best Last update: Fri May 1 15:37:27 2015 r3 BGP routing table entry for 8.8.8.8/32 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.0.0.1 10.0.0.2 10.0.0.4 90.1.1.6 (65002 65003) 80 10.0.0.7 (metric 50) from 10.0.0.4 (10.0.0.4) Origin IGP, metric 0, localpref 100, valid, confed-external, best Last update: Fri May 1 15:37:22 2015 The fix is to have bestpath prefer a confed-external path over a confed-internal path. I added this just after the "nexthop IGP cost" step because some confed customers will have one IGP covering multiple sub-ASs, in that case you want to compare nexthop IGP cost.
* Remove the '(ignored)' output for nexthops, instead display 'used' for the ↵Donald Sharp2015-06-121-1/+5
| | | | used one
* Here we have an unsual confederations config, "router bgp X" andDonald Sharp2015-06-125-46/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "bgp confederation id X" are the same value. router bgp 1 bgp router-id 10.1.1.1 bgp confederation identifier 1 bgp confederation peers 24 35 neighbor 10.1.1.2 remote-as 24 neighbor 10.1.1.2 update-source lo neighbor 10.1.1.3 remote-as 1 neighbor 10.1.1.3 update-source lo The customer does this because they want to peer to 10.1.1.2 as a confed-external peer but peer with 10.1.1.3 as a normal iBGP peer. The bug was that we thought 10.1.1.3 was an EBGP peer so we did not send him LOCALPREF which caused the Juniper to send us a NOTIFICATION. I confirmed that quagga also sends a NOTIFICATION in this scenario. The fix is to add a check to see if router bgp X and bgp confederation identifier X are equal because that is a factor in determining if a peer is EBGP or IBGP Additional issues fixed in the this patch: We were not properly removing all AS_CONFED_SEQUENCEs/SETs from the aspath when advertising a route to an ebgp peer. This was due to two issues: We only called aspath_delete_confed_seq() if confederations were configured. We can RX as aspath with CONFED segments even if confederations are not configured. aspath_delete_confed_seq() was implemented based on the original confed RFC 3065 which basically said "remove all of the leading AS_CONFED_SEQUENCEs/SETs" where the new confed RFC 5065 says "remove ALL of the AS_CONFED_SEQUENCEs/SETs" peer-groups did not work for confed-external peers. peer_calc_sort() always returned BGP_PEER_EBGP for a confederations where the remote-as was not specified. The reason was the peer->as_type was AS_UNSPECIFIED but we checked if (peer->as_type != AS_SPECIFIED) return (peer->as_type == AS_INTERNAL ? BGP_PEER_IBGP : BGP_PEER_EBGP); After fixing that I found that when we got to the else where we checked for peer1 we could only possibly return BGP_PEER_IBGP or BGP_PEER_EBGP, we need to also be able to return BGP_PEER_CONFED. I changed this to return peer1->sort. "show ip bgp x.x.x.x" would always display "Local" for the aspath. This is because we were calling aspath_counts_hop() to determine if the aspath was empty. This is wrong though because CONFED segments do not count towards aspath hopcount. The fix is to null check aspath->segments to determine if the aspath is actually empty. "show ip bgp x.x.x.x" and "show ip bgp neighbor" always displayed "internal" or "external" and never "confed-internal" or "confed-external". This made troubleshooting difficult because I couldn't tell exactly what kind of peer I was dealing with. I added the confed-internal and confed-external output...also added a "peer-type" field in the json output for 'show ip bgp x.x.x.x' "show ip bgp peer-group" did not list the peer-group name if we hadn't determined the "type" (internal, external, etc) for the peer-group
* Use nexthop-global-foo and nexthop-local-foo for all nexthop related JSON keysDonald Sharp2015-06-121-9/+9
|
* BGP cannot do a "no" on "neighbor x.x.x.x update-source lo"Donald Sharp2015-06-121-4/+7
|
* When an interface goes down, any neigbors learnt on that interfaceDonald Sharp2015-06-122-6/+67
| | | | | | | | using IPv6 Router Advertisements (RAs) must be deleted. When an interface comes up and neighbors are learnt on that interface, the BGP FSM for any interface peer must be started only if a valid local address exists; the local address may come up later after IPv6 Duplicate Address Detection.
* The nexthop reveived for a prefix in a BGP update is cached in theDonald Sharp2015-06-121-1/+7
| | | | | | | | | | | | nexthop cache in BGP and registered for resolution with the nexthop tracking (NHT) component. If the prefix were to be received from the same peer with a different nexthop, the prior nexthop needs to be processed for cleanup and unregistered and removed from the cache, if appropriate. That is handled with this patch. Signed-off-by: Vivek Venkataraman <vivek@cumulusnetworks.com> Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
* If the received MP nexthop is a martian address, treat the update asDonald Sharp2015-06-121-30/+63
| | | | | | | | | | | | | an implicit withdraw as is done for the NEXT_HOP attribute in the update itself. Note: Check is implemented only for IPv6 for the global nexthop. The code will quietly ignore an invalid IPv6 link-local nexthop, if present; this is the existing behavior and is not changed. Signed-off-by: Vivek Venkataraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
* When a route-reflector is configured with "next-hop self" towards an IBGPDonald Sharp2015-06-121-0/+1
| | | | | | | | | peer, it will only set the nexthop to "self" for non-reflected routes. To force the nexthop to "self" for reflected routes, a "next-hop self force" configuration is required. With the introduction of the update groups function, these two configurations are not distinguished correctly leading to inconsistent behavior. Resolve by introducing the proper distinction.
* Fix route-map peer-address configuration and operation.Donald Sharp2015-06-121-18/+22
|
* When peering is done on link-local address, always store the local addressDonald Sharp2015-06-121-3/+7
| | | | | | | | in the peer structure so that it can be used in setting the link-local nexthop in updates. This would ensure that in the absence of a global IPv6 address on the peering interface, a route-map can be used to specify a potentially arbitrary global v6 nexthop and that would be sent in conjunction with the correct link-local nexthop.
* With the dynamic update groups feature, BGP updates are formed for an updateDonald Sharp2015-06-122-4/+24
| | | | | | group and then replicated and sent for each member peer. The nexthop field in the update is set only as part of this final step, as it may differ per member peer. Update logs to display the final nexthop that is sent.
* A nexthop value specified by an outbound routemap is not beingDonald Sharp2015-06-125-138/+165
| | | | | | | | honored correctly for EBGP peers after the introduction of the dynamic update groups functionality. Ensure this is handled correctly. Also, the route-map can separately set different nexthops - IPv4, IPv6 global or IPv6 link-local; treat these separately.
* BGP Path attributes classified as well-known and mandatory need to beDonald Sharp2015-06-113-16/+26
| | | | | present in any received Update. Make sure the validation is done correctly for address families besides IPv4-unicast.
* When performing a delete of an IPv6 route, BGP passes along a nexthopDonald Sharp2015-06-111-41/+7
| | | | | | | | | | | | | | | | to zebra. If the nexthop value is non-NULL, Zebra would attempt to find a route that not only matches the prefix but also the nexthop i.e., treat the delete as a specific ECMP path delete. However, the intent in BGP is not a path delete but a delete of the entire prefix. If the deletion were triggered by the nexthop for a prefix changing from NH1 to NH2 and NH2 is not reachable, the delete would be issued to zebra for the prefix with the nexthop as NH2 and zebra wouldn't delete the prefix as it still has NH1 as its nexthop. Fix by not sending any nexthop in IPv6 route delete. This is based on the assumption (currently valid) that BGP does a route add/replace for any path changes and issues a route delete only when it needs to delete the entire route.
* When a route-map configuration is used to set the nexthop to a value, makeDonald Sharp2015-06-113-1/+54
| | | | | | sure that the value is acceptable. For example, if the route-map is setting the IPv6 link-local nexthop, make sure the value is an IPv6 link-local address.
* Update the log message when we receive a non-link-local nexthop for betterDonald Sharp2015-06-111-1/+2
| | | | readability.
* (no commit message)Donald Sharp2015-06-117-3/+159
|
* bgpd, zebra: rfc-5549-generic.patchDonald Sharp2015-06-1120-72/+526
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for BGP RFC 5549 (Extended Next Hop Encoding capability) * send and receive of the capability * processing of IPv4->IPv6 next-hops * for resolving these IPv6 next-hops, itsworks with the current next-hop-tracking support * added a new message type between BGP and Zebra for such route install/uninstall * zserv side of changes to process IPv4 prefix ->IPv6 next-hops * required show command changes for IPv4 prefix having IPv6 next-hops Few points to note about the implementation: * It does an implicit next-hop-self when a [IPv4 prefix -> IPv6 LL next-hop] is to be considered for advertisement to IPv4 peering (or IPv6 peering without Extended next-hop capability negotiated) * Currently feature is off by default, enable it by configuring 'neighbor <> capability extended-nexthop' * Current support is for IPv4 Unicast prefixes only. IMPORTANT NOTE: This patch alone isn't enough to have IPv4->IPv6 routes installed into the kernel. A separate patch is needed for that to work for the netlink interface. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Vivek Venkatraman <vivek@cumulusnetworks.com> Donald Sharp <sharpd@cumulusnetworks.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 05:50:27 +0100