summaryrefslogtreecommitdiffstats
path: root/bgpd/bgp_evpn.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* bgpd: Convert bgp_addpath_encode_[tr]x() to bool from intDonatas Abraitis2022-02-011-1/+1
| | | | | | Rename addpath_encode[d] to addpath_capable to be consistent. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* bgpd: Add CLI for overlay index recursive resolutionAmeya Dharkar2021-06-081-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Gateway IP overlay index of the remote type-5 route is resolved recursively using remote type-2 route. For the purpose of this recursive resolution, for each L2VNI, we build a hash table of the remote IP addresses received by remote type-2 routes. For the topologies where overlay index resolution is not needed, we do not need to build this remote-ip-hash. Thus, make the recursive resolution of the overlay index conditional on "enable-resolve-overlay-index" configuration. router bgp 65001 bgp router-id 192.168.100.1 neighbor 10.0.1.2 remote-as 65002 ! address-family l2vpn evpn neighbor 10.0.1.2 activate advertise-all-vni enable-resolve-overlay-index----------> New configuration exit-address-family Gateway IP overlay index will be resolved only if this configuration is present. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
* bgpd: EVPN route type-5 to type-2 recursive resolution using gateway IPAmeya Dharkar2021-06-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When EVPN prefix route with a gateway IP overlay index is imported into the IP vrf at the ingress PE, BGP nexthop of this route is set to the gateway IP. For this vrf route to be valid, following conditions must be met. - Gateway IP nexthop of this route should be L3 reachable, i.e., this route should be resolved in RIB. - A remote MAC/IP route should be present for the gateway IP address in the EVI(L2VPN table). To check for the first condition, gateway IP is registered with nht (nexthop tracking) to receive the reachability notifications for this IP from zebra RIB. If the gateway IP is reachable, zebra sends the reachability information (i.e., nexthop interface) for the gateway IP. This nexthop interface should be the SVI interface. Now, to find out type-2 route corresponding to the gateway IP, we need to fetch the VNI for the above SVI. To do this VNI lookup effitiently, define a hashtable of struct bgpevpn with svi_ifindex as key. struct hash *vni_svi_hash; An EVI instance is added to vni_svi_hash if its svi_ifindex is nonzero. Using this hash, we obtain struct bgpevpn corresponding to the gateway IP. For gateway IP overlay index recursive lookup, once we find the correct EVI, we have to lookup its route table for a MAC/IP prefix. As we have to iterate the entire route table for every lookup, this lookup is expensive. We can optimize this lookup by adding all the remote IP addresses in a hash table. Following hash table is defined for this purpose in struct bgpevpn Struct hash *remote_ip_hash; When a MAC/IP route is installed in the EVI table, it is also added to remote_ip_hash. It is possible to have multiple MAC/IP routes with the same IP address because of host move scenarios. Thus, for every address addr in remote_ip_hash, we maintain list of all the MAC/IP routes having addr as their IP address. Following structure defines an address in remote_ip_hash. struct evpn_remote_ip { struct ipaddr addr; struct list *macip_path_list; }; A Boolean field is added to struct bgp_nexthop_cache to indicate that the nexthop is EVPN gateway IP overlay index. bool is_evpn_gwip_nexthop; A flag BGP_NEXTHOP_EVPN_INCOMPLETE is added to struct bgp_nexthop_cache. This flag is set when the gateway IP is L3 reachable but not yet resolved by a MAC/IP route. Following table explains the combination of L3 and L2 reachability w.r.t. BGP_NEXTHOP_VALID and BGP_NEXTHOP_EVPN_INCOMPLETE flags * | MACIP resolved | MACIP unresolved *----------------|----------------|------------------ * L3 reachable | VALID = 1 | VALID = 0 * | INCOMPLETE = 0 | INCOMPLETE = 1 * ---------------|----------------|-------------------- * L3 unreachable | VALID = 0 | VALID = 0 * | INCOMPLETE = 0 | INCOMPLETE = 0 Procedure that we use to check if the gateway IP is resolvable by a MAC/IP route: - Find the EVI/L2VRF that belongs to the nexthop SVI using vni_svi_hash. - Check if the gateway IP is present in remote_ip_hash in this EVI. When the gateway IP is L3 reachable and it is also resolved by a MAC/IP route, unset BGP_NEXTHOP_EVPN_INCOMPLETE flag and set BGP_NEXTHOP_VALID flag. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
* bgpd, zebra: Add svi_interface to zebra VNI and bgp EVPN structuresAmeya Dharkar2021-06-081-1/+2
| | | | | | | | | | | | | | | | | SVI ifindex for L2VNI is required in BGP to perform EVPN type-5 to type-2 recusrsive resolution using gateway IP overlay index. Program this svi_ifindex in struct zebra_vni_t as well as in struct bgpevpn Changes include: 1. Add svi_if field to struct zebra_evpn_t 2. Add svi_ifindex field to struct bgpevpn 3. When SVI (bridge or VLAN) is bound to a VxLAN interface, store it in the zebra_evpn_t structure. 4. Add this SVI ifindex to ZEBRA_VNI_ADD 5. Store svi_ifindex in struct bgpevpn Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
* bgpd: CLI to advertise gateway IP overlay indexAmeya Dharkar2021-06-081-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Adds gateway-ip option to advertise ipv4/ipv6 unicast CLI. dev(config-router-af)# advertise <ipv4|ipv6> unicast <cr> gateway-ip Specify EVPN Overlay Index route-map route-map for filtering specific routes When gateway-ip is specified, gateway IP field of EVPN RT-5 NLRI is filled with the BGP nexthop of the vrf prefix being advertised. No support for ESI overlay index yet. Test cases: 1) advertise ipv4 unicast 2) advertise ipv4 unicast gateway-ip 3) advertise ipv6 unicast 4) advertise ipv6 unicast gateway-ip 5) Modify from no-overlay-index to gateway-ip 6) Modify from gateway-ip to no-overlay-index 7) CLI with route-map and modify route-map Author: Sri Mohana Singamsetty <srimohans@gmail.com> Signed-off-by: Sri Mohana Singamsetty <srimohans@gmail.com>
* bgpd: handle local ES del or transition to LACP bypassAnuradha Karuppiah2021-03-261-1/+0
| | | | | | | | | | | | | 1. When a local ES is deleted or the ES-bond goes into bypass we treat imported MAC-IP routes with that ES destination as remote routes instead of sync routes. This requires a re-evaluation of the routes as "non-local-dest" and an update to zebra. 2. When a ES is attached to an access port or the ES-bond transitions from bypass to LACP-up we treat imported MAC-IP routes with that ES destination as sync routes. This requires a re-evaluation of the routes as "local-dest" and an update to zebra. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* bgpd: use L3NHG while installing EVPN host routes in zebraAnuradha Karuppiah2020-11-241-4/+17
| | | | | | | Host routes imported into the VRF can have a destination ES (per-VRF) which is set up as a L3NHG for efficient failover. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* bgpd: replace bgp_evpn_route2str with prefix2strPat Ruddy2020-10-161-2/+0
| | | | | | Remove bgp_evpn_route2str and replace calls with prefix2str Signed-off-by: Pat Ruddy <pat@voltanet.io>
* bgpd: support for Ethernet Segments and Type-1/EAD routesAnuradha Karuppiah2020-08-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the base patch that brings in support for Type-1 routes. It includes support for - - Ethernet Segment (ES) management - EAD route handling - MAC-IP (Type-2) routes with a non-zero ESI i.e. Aliasing for active-active multihoming - Initial infra for consistency checking. Consistency checking is a fundamental feature for active-active solutions like MLAG. We will try to levarage the info in the EAD-ES/EAD-EVI routes to detect inconsitencies in access config across VTEPs attached to the same Ethernet Segment. Functionality Overview - ======================== 1. Ethernet segments are created in zebra and associated with access VLANs. zebra sends that info as ES and ES-EVI objects to BGP. 2. BGP advertises EAD-ES and EAD-EVI routes for the locally attached ethernet segments. 3. Similarly BGP processes EAD-ES and EAD-EVI routes from peers and translates them into ES-VTEP objects which are then sent to zebra as remote ESs. 4. Each ES in zebra is associated with a list of active VTEPs which is then translated into a L2-NHG (nexthop group). This is the ES "Alias" entry 5. MAC-IP routes with a non-zero ESI use the alias entry created in (4.) to forward traffic i.e. a MAC-ECMP is done to these remote-ES destinations. EAD route management (route table and key) - ============================================ 1. Local EAD-ES routes a. route-table: per-ES route-table key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP) b. route-table: per-VNI route-table Not added c. route-table: global route-table key: {RD=ES-RD, ESI, ET=0xffffffff) 2. Remote EAD-ES routes a. route-table: per-ES route-table Not added b. route-table: per-VNI route-table key: {RD=ES-RD, ESI, ET=0xffffffff, VTEP-IP) c. route-table: global route-table key: {RD=ES-RD, ESI, ET=0xffffffff) 3. Local EAD-EVI routes a. route-table: per-ES route-table Not added b. route-table: per-VNI route-table key: {RD=0, ESI, ET=0, VTEP-IP) c. route-table: global route-table key: {RD=L2-VNI-RD, ESI, ET=0) 4. Remote EAD-EVI routes a. route-table: per-ES route-table Not added b. route-table: per-VNI route-table key: {RD=0, ESI, ET=0, VTEP-IP) c. route-table: global route-table key: {RD=L2-VNI-RD, ESI, ET=0) Please refer to bgp_evpn_mh.h for info on how the data-structures are organized. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* bgpd: pull the multihoming code out to a separate fileAnuradha Karuppiah2020-08-051-4/+0
| | | | | | | | | | Re-org only; no other code changes. This is being done to make maintanence of MH functionality (which will have more code added to it) easy. The code moved here was originally committed via - 'commit 50f74cf13105 ("*: support for evpn type-4 route")' Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* bgp: rename bgp_node to bgp_destDonald Sharp2020-06-231-8/+8
| | | | | | | | | This is the bulk part extracted from "bgpd: Convert from `struct bgp_node` to `struct bgp_dest`". It should not result in any functional change. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* lib, bgpd: Another round of `struct const prefix` cleanupDonald Sharp2020-03-261-5/+6
| | | | | | | Cleanup another set of functions that need to respect the const'ness of a prefix. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: Rework code to use `const struct prefix`Donald Sharp2020-03-241-3/+5
| | | | | | | | Future work needs the ability to specify a const struct prefix value. Iterate into bgp a bit to get this started. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: More `const struct prefix` workDonald Sharp2020-03-221-5/+7
| | | | | | | | | 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>
* bgpd: evpn pip parse vrr macChirag Shah2019-11-221-1/+2
| | | | | | | | | | | | | | | | In L3VNI add callback parse, vrr rmac value. For non-zero vrr mac value, use it as anycast RMAC and svi mac as individual rmac value. If advertise-pip is disable or vrr rmac is not present use svi mac as anycast rmac value for all routes. Ticket:CM-26190 Reviewed By: Testing Done: Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
* bgpd: evpn pip data struct and cliChirag Shah2019-11-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Evpn Primary IP advertisement feature uses individual system IP and system MAC for prefix (type-5) and self type-2 routes. The PIP knob is enabled by default for bgp vrf instance. Configuration CLI for enable/disable PIP feature knob. User can configure PIP system IP and MAC to retain as permanent values. For the PIP IP, the default behavior is to accept bgp default instance's router-id. When the default instance router-id change, reflect PIP IP assignment. Reflect type-5 to use system-IP and system MAC as nexthop and RMAC values. Ticket:CM-26190 Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
* bgpd: Add nexthop of received EVPN RT-5 for nexthop trackingAmeya Dharkar2019-11-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem statement: When IPv4/IPv6 prefixes are received in BGP, bgp_update function registers the nexthop of the route with nexthop tracking module. The BGP route is marked as valid only if the nexthop is resolved. Even for EVPN RT-5, route should be marked as valid only if the the nexthop is resolvable. Code changes: 1. Add nexthop of EVPN RT-5 for nexthop tracking. Route will be marked as valid only if the nexthop is resolved. 2. Only the valid EVPN routes are imported to the vrf. 3. When nht update is received in BGP, make sure that the EVPN routes are imported/unimported based on the route becomes valid/invalid. Testcases: 1. At rtr-1, advertise EVPN RT-5 with a nexthop 10.100.0.2. 10.100.0.2 is resolved at rtr-2 in default vrf. At rtr-2, remote EVPN RT-5 should be marked as valid and should be imported into vrfs. 2. Make the nexthop 10.100.0.2 unreachable at rtr-2 Remote EVPN RT-5 should be marked as invalid and should be unimported from the vrfs. As this code change deals with EVPN type-5 routes only, other EVPN routes should be valid. 3. At rtr-2, add a static route to make nexthop 10.100.0.2 reachable. EVPN RT-5 should again become valid and should be imported into the vrfs. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
* bgpd: Adding new bgp evpn cli's for ip-prefix lookupLakshman Krishnamoorthy2019-09-271-0/+1
| | | | | | | | | | | | | | | | | Implement CLIs for the following, to filter for a prefix within evpn type 5 route 1) show bgp l2vpn evpn A.B.C.D 2) show bgp l2vpn evpn A.B.C.D json 3) show bgp l2vpn evpn A.B.C.D/M 4) show bgp l2vpn evpn A.B.C.D/M json 5) show bgp l2vpn evpn X:X::X:X 6) show bgp l2vpn evpn X:X::X:X json 7) show bgp l2vpn evpn X:X::X:X/M 8) show bgp l2vpn evpn X:X::X:X/M json Sample output provided here: https://github.com/FRRouting/frr/pull/4850 Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
* bgpd: maintain flood mcast group per-l2-vniAnuradha Karuppiah2019-04-201-1/+2
| | | | | | | | | | | | | If PIM-SM if used for BUM flooding the multicast group address can be configured per-vxlan-device. BGP receives this config from zebra via the L2 VNI add/update. Sample output - root@TORS1:~# vtysh -c "show bgp l2vpn evpn vni 1000" |grep Mcast Mcast group: 239.1.1.100 root@TORS1:~# Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* Merge branch 'master' into evpn-session-vrfTuetuopay2019-03-281-2/+39
|\
| * Merge pull request #3892 from vivek-cumulus/evpn_vrf_route_leakSri Mohana Singamsetty2019-03-151-2/+39
| |\ | | | | | | Leaking of EVPN-based IPv4 and IPv6 routes between VRFs
| | * bgpd: Recursively determine if route's source is EVPNvivek2019-03-011-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With leaking of IPv4 or IPv6 unicast routes whose source is a EVPN type-2 or type-5 route between VRFs, the determination of whether the route's source is EVPN has to be made recursively. This is used during route install to pass along appropriate parameters to zebra. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
| | * bgpd: Allow EVPN-sourced routes to be leaked back into EVPNvivek2019-02-281-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | Refine check on whether a route can be injected into EVPN to allow EVPN-sourced routes to be injected back into another instance. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
| | * bgpd: No nexthop tracking for EVPN-imported leaked routesvivek2019-02-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IPv4 or IPv6 unicast routes which are imported from EVPN routes (type-2 or type-5) and installed in a BGP instance and then leaked do not need any nexthop tracking, as any tracking should happen in the source instance. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | bgpd, zebra: Redo checks to advertise_all_vniTuetuopay2019-03-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | This replaces manual checks of the flag with a wrapper macro to convey the meaning "is evpn enabled on this vrf?" Signed-off-by: Tuetuopay <tuetuopay@me.com> Sponsored-by: Scaleway
* | | bgpd: Allow non-default instance to be EVPN oneTuetuopay2019-03-191-1/+1
|/ / | | | | | | | | | | | | | | This makes the instance bearing the advertise-all-vni config option register to zebra as the EVPN one, forwarding it the option. Signed-off-by: Tuetuopay <tuetuopay@me.com> Sponsored-by: Scaleway
* / zebra, bgpd: Exchange L3 interface for VRF's VNIvivek2019-02-271-1/+2
|/ | | | | | | | | | | | | | | | | | | | In the case of EVPN symmetric routing, the tenant VRF is associated with a VNI that is used for routing and commonly referred to as the L3 VNI or VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP) interface (SVI). Overlay next hops (i.e., next hops for routes in the tenant VRF) are reachable over this interface. https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement section 4.4 provides additional description of the above constructs. The implementation currently derives this L3 interface for EVPN tenant routes using special code that looks at route flags. This patch exchanges the L3 interface between zebra and bgpd as part of the L3-VNI exchange in order to eliminate some this special code. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: reinstate current bgp best route on an inactive neigh delAnuradha Karuppiah2019-01-251-1/+2
| | | | | | | | | | | When an inactive-neigh delete is rxed bgp will not have a local path to remove (and re-run path selection). Instead it simply re-installs the current best remote path if any. Ticket: CM-23018 Testing Done: evpn-min Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* bgpd: Add '[no] flood <disable|head-end-replication>'Donald Sharp2018-10-121-0/+1
| | | | | | | | | | | | | Add the '[no] flood <disable|head-end-replication>' command to the l2vpn evpn afi/safi sub commands for bgp. This command when entered as 'flood disable' will turn off type 3 route generation for the transmittal of the type 3 route necessary for BUM replication on the remote VTEP. Additionally it will turn off the BUM handling via the new zebra command, ZEBRA_VXLAN_FLOOD_CONTROL. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: Convert `struct bgp_info` to `struct bgp_path_info`Donald Sharp2018-10-091-5/+5
| | | | | | | | | | | | Do a straight conversion of `struct bgp_info` to `struct bgp_path_info`. This commit will setup the rename of variables as well. This is being done because `struct bgp_info` is not descriptive of what this data actually is. It is path information for routes that we keep to build the actual routes nexthops plus some extra information. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd, zebra: EVPN extended mobility supportvivek2018-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement procedures similar to what is specified in https://tools.ietf.org/html/draft-malhotra-bess-evpn-irb-extended-mobility in order to support extended mobility scenarios in EVPN. These are scenarios where a host/VM move results in a different (MAC,IP) binding from earlier. For example, a host with an address assignment (IP1, MAC1) moves behind a different PE (VTEP) and has an address assignment of (IP1, MAC2) or a host with an address assignment (IP5, MAC5) has a different assignment of (IP6, MAC5) after the move. Note that while these are described as "move" scenarios, they also cover the situation when a VM is shut down and a new VM is spun up at a different location that reuses the IP address or MAC address of the earlier instance, but not both. Yet another scenario is a MAC change for an attached host/VM i.e., when the MAC of an attached host changes from MAC1 to MAC2. This is necessary because there may already be a non-zero sequence number associated with MAC2. Also, even though (IP, MAC1) is withdrawn before (IP, MAC2) is advertised, they may propagate through the network differently. The procedures continue to rely on the MAC mobility extended community specified in RFC 7432 and already supported by the implementation, but augment it with a inheritance mechanism that understands the relationship of the host MACIP (ARP/neighbor table entry) to the underlying MAC (MAC forwarding database entry). In FRR, this relationship is understood by the zebra component which doubles as the "host mobility manager", so the MAC mobility sequence numbers are determined through interaction between bgpd and zebra. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* *: support for evpn type-4 routemitesh2018-05-301-0/+4
| | | | Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* bgpd: add an option for RT auto-derivation to use RFC 8635.Vincent Bernat2018-04-231-0/+1
| | | | | | | | | | | | | RFC 8635 explains how RT auto-derivation should be done in section 5.1.2.1 [1]. In addition to encoding the VNI in the lowest bytes, a 3-bit field is used to encode a namespace. For VXLAN, we have to put 1 in this field. This is needed for proper interoperability with RT auto-derivation in JunOS. Since this would break existing setup, an additional option, "autort rfc8365-compatible" is used. [1]: https://tools.ietf.org/html/rfc8365#section-5.1.2.1 Signed-off-by: Vincent Bernat <vincent@bernat.im>
* bgpd: Fix use of ROUTE_IMPORTED for EVPNvivek2018-03-301-0/+26
| | | | | | | | | | Ensure that only EVPN routes are flagged as such when installing into or withdrawing from zebra, the earlier check broke L3VPN or VRF route-leaked routes. Also, fix an incorrect check related to imported routes in path selection. Updates: bgpd: Use BGP_ROUTE_IMPORTED for EVPN [vivek] Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
* *: use C99 standard fixed-width integer typesQuentin Young2018-03-271-9/+9
| | | | | | | | | | | | | | | | | | | | | | The following types are nonstandard: - u_char - u_short - u_int - u_long - u_int8_t - u_int16_t - u_int32_t Replace them with the C99 standard types: - uint8_t - unsigned short - unsigned int - unsigned long - uint8_t - uint16_t - uint32_t Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Merge branch 'master' into type5-default-originateMitesh Kanjariya2018-03-121-10/+7
|\
| * *: conform with COMMUNITY.md formatting rules, via 'make indent'Lou Berger2018-03-061-10/+7
| | | | | | | | Signed-off-by: Lou Berger <lberger@labn.net>
* | Merge branch 'master' into type5-default-originateMitesh Kanjariya2018-02-271-1/+2
|\|
| * zebra, bgp: Support type-5 routes with asymmetric routingMitesh Kanjariya2018-02-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Asymmetric routing is an ideal choice when all VLANs are cfged on all leafs. It simplifies the routing configuration and eliminates potential need for advertising subnet routes. However, we need to reach the Internet or global destinations or to do subnet-based routing between PODs or DCs. This requires EVPN type-5 routes but those routes require L3 VNI configuration. This task is to support EVPN type-5 routes for prefix-based routing in conjunction with asymmetric routing within the POD/DC. It is done by providing an option to use the L3 VNI only for prefix routes, so that type-2 routes (host routes) will only use the L2 VNI. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* | bgpd: move l2vpn evpn related flags in struct bgp to af_flagsMitesh Kanjariya2018-02-231-2/+4
| | | | | | | | | | | | | | We have af_flags in struct bgp to hold address family related flags, l2vpn evpn flags to indicate advertise ipvX unicast should be moved there. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* | bgpd: allow advertise-subnet cmd without enabling advertise ipv4 unicastMitesh Kanjariya2018-02-231-0/+17
|/ | | | | | | | | Type-5 routes can be useful in multiple scenarios such as advertise-subnet, default-originate etc. Currently, the code has a restriction that to allow advertising type-5 routes, user has to first enable advertise ipvX command. This restriction is not necessary and should be removed. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* bgpd: Use source route's path attributes for type-5 routesvivek2018-01-241-0/+1
| | | | | | | | | | | | | | | | When an IPv4 or IPv6 unicast route is injected into EVPN as a type-5 route (upon user configuration), ensure that the source route (best path)'s path attributes are used to build the EVPN type-5 route. This will result in correct AS_PATH and ORIGIN attributes for the type-5 route so that it doesn't appear that all type-5 routes are locally sourced. This is necessary to ensure that external paths (IPv4 or IPv6 from EBGP peer) are preferred over internal EVPN paths, if both exist. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Ticket: CM-19051 Reviewed By: CCR-7009 Testing Done: Verify failed scenario
* bgpd: advertise VNI subnetMitesh Kanjariya2018-01-241-2/+2
| | | | | | | | | | | | | | In EVPN symmetric routing, not all subnets are presents everywhere. We have multiple scenarios where a host might not get learned locally. 1. GARP miss 2. SVI down/up 3. Silent host We need a mechanism to resolve such hosts. In order to achieve this, we will be advertising a subnet route from a box and that box will help in resolving the ARP to such hosts. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* bgpd: carry two MPLS labels in EVPN NLRIsMitesh Kanjariya2018-01-241-2/+25
| | | | | | | | | | | | | | When doing symmetric routing, EVPN type-2 (MACIP) routes need to be advertised with two labels (VNIs) the first being the L2 VNI (identifying the VLAN) and the second being the L3 VNI (identifying the VRF). The receive processing needs to handle one or two labels too. Ticket: CM-18489 Review: CCR-6949 Testing: manual and bgp/evpn/mpls smoke Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
* bgpd, lib, zebra: fix style problemsmitesh2017-12-271-3/+4
| | | | Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* bgpd: advertise/withdraw new added/deleted type-5 routesMitesh Kanjariya2017-12-141-0/+6
| | | | Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* bgpd: follow AFI/SAFI style for advertising/withdrawing type-5 routesMitesh Kanjariya2017-12-141-2/+4
| | | | Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* bgpd: evpn enabled should only be checked for default instanceMitesh Kanjariya2017-12-141-0/+9
| | | | Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* bgpd: advertise/withdraw type-5 routes upon user configmitesh2017-12-141-0/+2
| | | | | | | | | | | | | CLI config for enabling/disabling type-5 routes router bgp <as> vrf <vrf> address-family l2vpn evpn [no] advertise <ipv4|ipv6|both> loop through all the routes in VRF instance and advertise/withdraw all ip routes as type-5 routes in default instance. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* bgpd: set vrf originator ip to kernels local-ipmitesh2017-12-141-1/+2
| | | | | | | | | For EVPN type-5 route the NH in the NLRI is set to the local tunnel ip. This information has to be obtained from kernel notification. We need to pass this info from zebra to bgp in l3vni call flow. This patch doesn't handle the tunnel-ip change. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-07 09:05:23 +0100