summaryrefslogtreecommitdiffstats
path: root/bgpd/bgp_attr.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* bgpd: rip out bgp_attr_deep_dup(), fix table-mapDavid Lamparter2017-09-071-2/+0
| | | | | | | | | bgp_attr_deep_dup is based on a misunderstanding of how route-maps work. They never change actual data, just pointers & fields in "struct attr". The correct thing to do is copy struct attr and call bgp_attr_flush() afterwards. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd: kill bgp_attr_refcount()David Lamparter2017-09-071-1/+0
| | | | | | | | | | This attempt at optimization has cost us more than a week's worth of time on several people hunting down the subtle bug that it was missing an increment on attr->lcommunity. This is absolutely not worth the maintenance cost. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd: add safety check on ATTR_FLAG_BITDavid Lamparter2017-09-071-1/+6
| | | | Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd: encap: fix extension sizingDavid Lamparter2017-08-261-1/+1
| | | | | | | | Variably-sized struct tails are done as [0], not [1]. The latter triggers compiler warnings and mis-sizes "sizeof(struct) + n" expressions. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* Revert "*: reindent pt. 2"David Lamparter2017-07-221-1/+1
| | | | | | | | | This reverts commit c14777c6bfd0a446c85243d3a9835054a259c276. clang 5 is not widely available enough for people to indent with. This is particularly problematic when rebasing/adjusting branches. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: reindent pt. 2whitespace / reindent2017-07-171-1/+1
| | | | | | | | w/ clang 5 * reflow comments * struct members go 1 per line * binpack algo was adjusted
* *: reindentreindent-master-afterwhitespace / reindent2017-07-171-191/+191
| | | | | | indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd: Refactor 'struct attr_extra' into 'struct attr'Donald Sharp2017-07-121-42/+30
| | | | | | | | | | | | | | | | | Most of the attributes in 'struct attr_extra' allow for the more interesting cases of using bgp. The extra overhead of managing it will induce errors as we add more attributes and the extra memory overhead is negligible on anything but full bgp feeds. Additionally this greatly simplifies the code for the handling of data. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> bgpd: Fix missing label set Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: EVPN route handlingvivek2017-07-121-0/+12
| | | | | | | | | | | | | | | | | Core EVPN route handling functionality. This includes support for the following: - interface with zebra to learn about local VNIs and MACIPs as well as to install remote VTEPs (per VNI) and remote MACIPs - create/update/delete EVPN type-2 and type-3 routes - attribute creation, route selection and install - route handling per VNI and for the global routing table - parsing of received EVPN routes and handling by route type - encoding attributes for EVPN routes and EVPN prefix creation (for Updates) Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
* bgpd: Install SAFI_LABELED_UNICAST routes in SAFI_UNICAST tableDaniel Walton2017-06-161-3/+7
| | | | | | | | | | | | | | | | | | | | | Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> - All ipv4 labeled-unicast routes are now installed in the ipv4 unicast table. This allows us to do things like take routes from an ipv4 unicast peer, allocate a label for them and TX them to a ipv4 labeled-unicast peer. We can do the opposite where we take routes from a labeled-unicast peer, remove the label and advertise them to an ipv4 unicast peer. - Multipath over a labeled route and non-labeled route is not allowed. - You cannot activate a peer for both 'ipv4 unicast' and 'ipv4 labeled-unicast' - The 'tag' variable was overloaded for zebra's route tag feature as well as the mpls label. I added a 'mpls_label_t mpls' variable to avoid this. This is much cleaner but resulted in touching a lot of code.
* Merge branch 'frr/pull/536'David Lamparter2017-05-181-2/+2
|\ | | | | | | Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
| * bgpd: remove bgp_nexthop_afi prototypeDavid Lamparter2017-05-181-2/+0
| | | | | | | | | | | | as pointed out by Renato Westphal in #536 Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
| * bgpd: fix nh_afi in bgp_packet_mpattr_start()Daniel Walton2017-05-161-2/+2
| | | | | | | | Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
| * bgpd: added bgp_nexthop_afi()Daniel Walton2017-05-151-0/+2
| | | | | | | | | | | | | | Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Added bgp_nexthop_afi() to have one place that determines what the Nexthop AFI is for bgp_packet_mpattr_start()
* | *: make consistent & update GPLv2 file headersDavid Lamparter2017-05-151-18/+18
|/ | | | | | | | | | | The FSF's address changed, and we had a mixture of comment styles for the GPL file header. (The style with * at the beginning won out with 580 to 141 in existing files.) Note: I've intentionally left intact other "variations" of the copyright header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd: remove unused bgp_attr_default_intern() functionRenato Westphal2017-05-121-1/+0
| | | | | | This function is not used anymore since commit 137446f9. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Update to draft-ietf-idr-bgp-prefix-sid-05Daniel Walton2017-04-261-0/+8
| | | | | | | | | | | | | | Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> The initial implementation was against draft-keyupate-idr-bgp-prefix-sid-02 This updates our label-index implementation up to draft-ietf-idr-bgp-prefix-sid-05 - changed BGP_ATTR_LABEL_INDEX to BGP_ATTR_PREFIX_SID - since there are multiple TLVs in BGP_ATTR_PREFIX_SID you can no longer rely on that flag to know if there is a label-index for the path. I changed bgp_attr_extra_new() to init the label_index to BGP_INVALID_LABEL_INDEX - put some placeholder code in for the other two TLVs (IPv6 and Originator SRGB)
* bgpd: Switch u_int64_t -> uint64_tDonald Sharp2017-04-071-1/+1
| | | | | | | Apparently u_int64_t is not available( or we don't pull the right headers in for solaris based systems). Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: Modify attr->flag to be 64 bitDonald Sharp2017-04-061-2/+2
| | | | | | | | | | | | With the some current bgp drafts the Attribute number has surpassed 32. Which is a bit unfortunate in that we keep track of the attributes via a bitfield based on the attribute #. For the moment since I am not aware of Attribute #'s being greater than 64, convert the flag to 64 bit and allow the bit shifting to know about it. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: This patch implements the exchange of the BGP-Prefix-SID label index attrVivek Venkatraman2017-04-061-0/+3
| | | | | | | | | Implement BGP Prefix-SID IETF draft to be able to signal a labeled-unicast prefix with a label index (segment ID). This makes it easier to deploy global MPLS labels with BGP, even without other aspects of Segment Routing implemented. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
* bgpd: remove useless white space character in evpn function declarationPhilippe Guibert2017-02-141-1/+1
| | | | | | | Some tabulation replaces the white space used for the declaration of this evpn function. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: evpn NLRI route type 5 forgingPhilippe Guibert2017-02-141-2/+3
| | | | | | | | | This patch introduces the ability to make route type 5 message when EVPN is enabled. Picked up paramters are collected from the bgp extra attribute structure and are the ESI, the ethernet tag information. In addition to this, nexthop attribute is collected too. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: route type 5 internal structures plus processingPhilippe Guibert2017-02-141-0/+11
| | | | | | | | | The commit introduces the changes to be done to carry route type 5 EVPN information in bgp extra attribute information. The commit also handles the update processing for route type 5 information, including ESI, gatewayIP and label information. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: lcommunity: fix whitespace & copyrightDavid Lamparter2017-01-251-1/+1
| | | | | | | | | (to match surrounding code) "git diff -w" should be almost empty. Copyright edited to say FRR, this is not GNU Zebra :) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* Support for BGP Large CommunitiesJob Snijders2017-01-191-0/+3
| | | | | | | | | | | | | | | | | | BGP Large Communities are a novel way to signal information between networks. An example of a Large Community is: "2914:65400:38016". Large BGP Communities are composed of three 4-byte integers, separated by a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. This feature was developed by: Keyur Patel <keyur@arrcus.com> (Arrcus, Inc.), Job Snijders <job@ntt.net> (NTT Communications), David Lamparter <equinox@opensourcerouting.org> and Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: Job Snijders <job@ntt.net> Signed-off-by: David Lamparter <equinox@opensourcerouting.org> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgp: Use intern/unintern for encap to fix valgrind identified memory leakLou Berger2017-01-021-0/+2
| | | | Signed-off-by: Lou Berger <lberger@labn.net>
* *: Consistently support 32-bit route tagsChristian Franke2016-10-081-1/+1
| | | | | | | | | | | | | | | | | | | This patch improves zebra,ripd,ripngd,ospfd and bgpd so that they can make use of 32-bit route tags in the case of zebra,ospf,bgp or 16-bit route-tags in the case of ripd,ripngd. It is based on the following patch: commit d25764028829a3a30cdbabe85f32408a63cccadf Author: Paul Jakma <paul.jakma@hpe.com> Date: Fri Jul 1 14:23:45 2016 +0100 *: Widen width of Zserv routing tag field. But also contains the changes which make this actually useful for all the daemons. Signed-off-by: Christian Franke <chris@opensourcerouting.org>
* bgpd: add L3/L2VPN Virtual Network Control featureLou Berger2016-10-031-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature adds an L3 & L2 VPN application that makes use of the VPN and Encap SAFIs. This code is currently used to support IETF NVO3 style operation. In NVO3 terminology it provides the Network Virtualization Authority (NVA) and the ability to import/export IP prefixes and MAC addresses from Network Virtualization Edges (NVEs). The code supports per-NVE tables. The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2 (L2) forwarding information between NVAs and NVEs is referred to as the Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For general background on NVO3 and RFP concepts see [1]. For information on Openflow see [2]. RFPs are integrated with BGP via the RF API contained in the new "rfapi" BGP sub-directory. Currently, only a simple example RFP is included in Quagga. Developers may use this example as a starting point to integrate Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code also supports the ability import/export of routing information between VNC and customer edge routers (CEs) operating within a virtual network. Import/export may take place between BGP views or to the default zebera VRF. BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN information between NVAs. BGP based IP VPN support is defined in RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use of both the Encapsulation Subsequent Address Family Identifier (SAFI) and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute, are supported. MAC address distribution does not follow any standard BGB encoding, although it was inspired by the early IETF EVPN concepts. The feature is conditionally compiled and disabled by default. Use the --enable-bgp-vnc configure option to enable. The majority of this code was authored by G. Paul Ziemba <paulz@labn.net>. [1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req [2] https://www.opennetworking.org/sdn-resources/technical-library Now includes changes needed to merge with cmaster-next.
* bgpd: Add fix for multiple set commands with prefer-globalroot2016-09-011-0/+2
| | | | | | | | | | | | | | In further testing, found that if there were multiple set commands in the route-map with one being prefer-global, the removal of the prefer-global was not recognized and reacted to correctly. This small addition includes that support Ticket: CM-11480 Signed-off-by: Don Slice Reviewed By: Donald Sharp Testing Done: Manual testing, bgp-min and bgp-smoke completed (cherry picked from commit 3aef92192569c33906c6a2623d0753c16c0e7a64)
* *: use an ifindex_t type, defined in lib/if.h, for ifindex valuesPaul Jakma2016-08-181-1/+1
| | | | (cherry picked from commit 9099f9b2a66e86f8a90d7fe18f61bd2bb1bc6744)
* bgpd: Add command to prefer global ipv6 addressDon Slice2016-08-031-0/+3
| | | | | | | | | | | | | | | | There are cases where customers desire the ability to override the default behavior of installing ipv6 prefixes with a link-local next-hop if both a link-local and global ipv6 next-op is present in the bgp table. This fix provides this ability and will allow the global to be used as the next-hop. This also retains the ability to manually set the ipv6 next-hop global value as before, and if so, this manual entry will be used for the next-hop. Ticket: CM-11480 Signed-off-by: Don Slice Reviewed By: CCR-4983 Testing Done: Manual testing results attached to the ticket. bgp-min and bgp-smoke will be completed before committing.
* bgpd: encap: add attribute handlingLou Berger2016-06-101-0/+17
| | | | | | | | | | | | Signed-off-by: Lou Berger <lberger@labn.net> Reviewed-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit c3741789530ee824693fd606356acac2ad695f83) Conflicts: bgpd/Makefile.am bgpd/bgp_attr.c bgpd/bgp_attr.h lib/memtypes.c
* bgpd: general MP/SAFI improvementsLou Berger2016-06-101-0/+2
| | | | | | | | | | | | | | | | This fixes some minor mixups particularly in MPLS-related SAFIs, as well as doing some stylistic changes & adding comments. Signed-off-by: Lou Berger <lberger@labn.net> Reviewed-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit 050defe816e4bd4cac7b028f69e45cb1974ca96d) Conflicts: bgpd/bgp_attr.c bgpd/bgp_attr.h bgpd/bgp_packet.c bgpd/bgp_route.c bgpd/bgp_route.h
* bgpd: wire up VPNv6 protocol processingLou Berger2016-06-071-1/+3
| | | | | | | | | | | | | | | | | | There wasn't much missing for VPNv6 to begin with; just a few bits of de- & encoding and a few lists to be updated. Signed-off-by: Lou Berger <lberger@labn.net> Signed-off-by: David Lamparter <equinox@opensourcerouting.org> [Editorial note: Signed-off-by may imply an authorship claim, but need not] Edited-by: Paul Jakma <paul.jakma@hpe.com> / <paul@jakma.org> (cherry picked from commit 9da04bca0e994ec92b9242159bf27d89c6743354) Conflicts: bgpd/bgp_attr.c bgpd/bgp_mplsvpn.c bgpd/bgpd.c
* bgpd: resolve merge issues in bgp_attr_check()Daniel Walton2016-05-271-1/+1
| | | | Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
* bgpd: well-known attr check only run for v4/uni, which could cause a crash.Paul Jakma2016-05-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * ANVL testing by Martin Winter threw up a crash in bgpd in aspath_dup called from bgp_packet_attribute, if attr->aspath was NULL, on an IPv6 UPDATE. This root cause is that the checks for well-known, mandatory attributes were being applied only if an UPDATE contained the IPv4 NLRI and the peer was configured for v4/unicast (i.e. not deconfigured). This is something inherited from GNU Zebra, and never noticed before. * bgp_attr.c: (bgp_attr_parse) Move the well-known mandatory attribute check to here, so that it can be run immediately after all attributes are parsed, and before any further processing of attributes that might assume the existence of WK/M attributes (e.g. AS4-Path). (bgp_attr_munge_as4_attrs) Missing AS_PATH shouldn't happen here anymore, but retain a check anyway for robustness - it's definitely a hard error though. * bgp_attr.h: (bgp_attr_check) No longer needs to be exported, make static. * bgp_packet.c: (bgp_update_receive) Responsibility for well-known check now in bgp_attr_parse. (cherry picked from commit 055086f70febc30fdfd94bb4406e9075d6934cd8) Conflicts: bgpd/bgp_attr.c bgpd/bgp_attr.h bgpd/bgp_packet.c
* bgpd: Removed unused variable from 'struct attr_extra'Donald Sharp2016-02-031-3/+0
| | | | | | | The mp_nexthop_local_in variable is never used. Remove it from the code base. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* BGP: support for addpath TXDaniel Walton2015-11-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com Ticket: CM-8014 This implements addpath TX with the first feature to use it being "neighbor x.x.x.x addpath-tx-all-paths". One change to show output is 'show ip bgp x.x.x.x'. If no addpath-tx features are configured for any peers then everything looks the same as it is today in that "Advertised to" is at the top and refers to which peers the bestpath was advertise to. root@superm-redxp-05[quagga-stash5]# vtysh -c 'show ip bgp 1.1.1.1' BGP routing table entry for 1.1.1.1/32 Paths: (6 available, best #6, table Default-IP-Routing-Table) Advertised to non peer-group peers: r1(10.0.0.1) r2(10.0.0.2) r3(10.0.0.3) r4(10.0.0.4) r5(10.0.0.5) r6(10.0.0.6) r8(10.0.0.8) Local, (Received from a RR-client) 12.12.12.12 (metric 20) from r2(10.0.0.2) (10.0.0.2) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 8 Last update: Fri Oct 30 18:26:44 2015 [snip] but once you enable an addpath feature we must display "Advertised to" on a path-by-path basis: superm-redxp-05# show ip bgp 1.1.1.1/32 BGP routing table entry for 1.1.1.1/32 Paths: (6 available, best #6, table Default-IP-Routing-Table) Local, (Received from a RR-client) 12.12.12.12 (metric 20) from r2(10.0.0.2) (10.0.0.2) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 8 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:44 2015 Local, (Received from a RR-client) 34.34.34.34 (metric 20) from r3(10.0.0.3) (10.0.0.3) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 7 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:39 2015 Local, (Received from a RR-client) 56.56.56.56 (metric 20) from r6(10.0.0.6) (10.0.0.6) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 6 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:39 2015 Local, (Received from a RR-client) 56.56.56.56 (metric 20) from r5(10.0.0.5) (10.0.0.5) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 5 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:39 2015 Local, (Received from a RR-client) 34.34.34.34 (metric 20) from r4(10.0.0.4) (10.0.0.4) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 4 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:39 2015 Local, (Received from a RR-client) 12.12.12.12 (metric 20) from r1(10.0.0.1) (10.0.0.1) Origin IGP, metric 0, localpref 100, valid, internal, best AddPath ID: RX 0, TX 3 Advertised to: r1(10.0.0.1) r2(10.0.0.2) r3(10.0.0.3) r4(10.0.0.4) r5(10.0.0.5) r6(10.0.0.6) r8(10.0.0.8) Last update: Fri Oct 30 18:26:34 2015 superm-redxp-05#
* A nexthop value specified by an outbound routemap is not beingDonald Sharp2015-06-121-1/+14
| | | | | | | | 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-111-1/+1
| | | | | present in any received Update. Make sure the validation is done correctly for address families besides IPv4-unicast.
* bgpd, zebra: rfc-5549-generic.patchDonald Sharp2015-06-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Use #define for mp_nexthop_len valuesDonald Sharp2015-05-201-0/+6
|
* bgpd: Add route-map support for set ip next-hop unchangedDonald Sharp2015-05-201-0/+1
| | | | | | | | | In the data center, where load balancers are announced as VIPs, and eBGP is used as the routing protocol, this feature is required to ensure that VIP announcements can be made from anywhere the operator sees fit. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
* BGP: Add dynamic update group supportDonald Sharp2015-05-201-0/+14
| | | | | | | | | | | | | | | | | | | | This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
* atomic-aggregate is lost when we aggregate another aggregate that has ↵Donald Sharp2015-05-201-1/+1
| | | | atomic-aggregate
* Add support for route tagsDonald Sharp2015-05-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Credit ------ A huge amount of credit for this patch goes to Piotr Chytla for their 'route tags support' patch that was submitted to quagga-dev in June 2007. Documentation ------------- All ipv4 and ipv6 static route commands now have a "tag" option which allows the user to set a tag between 1 and 65535. quagga(config)# ip route 1.1.1.1/32 10.1.1.1 tag ? <1-65535> Tag value quagga(config)# ip route 1.1.1.1/32 10.1.1.1 tag 40 quagga(config)# quagga# show ip route 1.1.1.1/32 Routing entry for 1.1.1.1/32 Known via "static", distance 1, metric 0, tag 40, best * 10.1.1.1, via swp1 quagga# The route-map parser supports matching on tags and setting tags ! route-map MATCH_TAG_18 permit 10 match tag 18 ! ! route-map SET_TAG_22 permit 10 set tag 22 ! BGP and OSPF support: - matching on tags when redistribing routes from the RIB into BGP/OSPF. - setting tags when redistribing routes from the RIB into BGP/OSPF. BGP also supports setting a tag via a table-map, when installing BGP routes into the RIB. Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
* bgpd: bgpd-route-map-match-interface.patchDonald Sharp2015-05-201-0/+1
| | | | | | | | BGP: Add match interface support to BGP route-map. Currently, BGP route maps don't support interface match. This is a problem for commands such as redistribite connected that cannot exclude routes from specific interfaces (such as mgmt interfaces).
* bgpd: bgpd-table-map.patchDonald Sharp2015-05-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | COMMAND: table-map <route-map-name> DESCRIPTION: This feature is used to apply a route-map on route updates from BGP to Zebra. All the applicable match operations are allowed, such as match on prefix, next-hop, communities, etc. Set operations for this attach-point are limited to metric and next-hop only. Any operation of this feature does not affect BGPs internal RIB. Supported for ipv4 and ipv6 address families. It works on multi-paths as well, however, metric setting is based on the best-path only. IMPLEMENTATION NOTES: The route-map application at this point is not supposed to modify any of BGP route's attributes (anything in bgp_info for that matter). To achieve that, creating a copy of the bgp_attr was inevitable. Implementation tries to keep the memory footprint low, code comments do point out the rationale behind a few choices made. bgp_zebra_announce() was already a big routine, adding this feature would extend it further. Patch has created a few smaller routines/macros whereever possible to keep the size of the routine in check without compromising on the readability of the code/flow inside this routine. For updating a partially filtered route (with its nexthops), BGP to Zebra replacement semantic of the next-hops serves the purpose well. However, with this patch there could be some redundant withdraws each time BGP announces a route thats (all the nexthops) gets denied by the route-map application. Handling of this case could be optimized by keeping state with the prefix and the nexthops in BGP. The patch doesn't optimizing that case, as even with the redundant withdraws the total number of updates to zebra are still be capped by the total number of routes in the table. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
* cluster-id length equality for multipathDonald Sharp2015-05-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A fat tree topology running IBGP gets into two issues with anycast address routing. Consider the following topology: R9 R10 x x R3 R4 R7 R8 x x R1 R2 R5 R6 | | | | 10/8 10/8 10/8 S Let's remind ourselves of BGP decision process steps: 1. Highest Local Preference 2. Shortest AS Path Length 3. Lowest Origin Type 4. Lowest MED (Multi-Exit Discriminator) 5. Prefer External to Internal 6. Closest Egress (Lowest IGP Distance) 7. Tie Breaking (Lowest-Router-ID) 8. Tie Breaking (Lowest-cluster-list length) 9. Tie Breaking (Lowest-neighbor-address) Without any policies, steps 1-6 will almost always evaluate identically for all paths received on any router in the above topology. Let's assume that the router-ids follow the following inequality: R1 < R2 < R5 < R6. Owing to the 7th step above, all routers will now choose R1's path as the best. This is undesirable. As an example, traffic from S to 10/8 will follow the path S -> R6 -> R7 -> R9 -> R4 -> R2 -> 10/8 instead of S -> R6 -> R7 -> R5 -> 10/8. Furthermore, once R7 (& R8) chooses R1's path as the best, it would withdraw its path learned through (R5, R6) from (R9, R10). This leads to inefficient load balancing - e.g. R9 can't do ECMP across all available egresses - (R1, R2, R5). The patch addresses these issues by noting that that cluster list is always carried along with the routes and its length is a good indicator of IBGP hops. It thus makes sense to compare that as an extension to metric after step 6. That automatically ensures correct multipath computation. Unfortunately a partial deployment of this in a generic topology (note: fat-tree/clos topologies work fine) may lead to potential loops. It needs to be looked into. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
* bgpd: don't send NOTIFY twice for malformed attrsDavid Lamparter2014-06-291-0/+3
| | | | | | | Most of the attribute parsing functions were already sending a notify, let's clean up the code to make it happen only once. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-15 06:57:38 +0100