• Tag : multi-agent

 
 

EVPN VxLAN IPV6 Overlay TOI

Description Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from IPV6 host to another IPV6 host on a stretched Vxlan VLAN. This TOI explains the EOS configuration and show commands. Platform Compatibility Platform supporting ND Proxy and ND Suppression DCS-7280R/7280R2 DCS-7050CX3-32S-F DCS-7050SX3-48YC12-F ( Starting in 4.22.1F ) DCS-7050SX3-48YC8 ( Starting in 4.22.1F ) DCS-7050/7050X/7050X2 ( Starting in 4.22.1F ) DCS-7260X/7260X3 ( Starting in 4.22.1F ) DCS-7060X/7060X2 ( Starting in 4.21.1F ) DCS-7250 ( Starting in 4.22.1F ) DCS-7300/DCS-7320 ( Starting in 4.22.1F ) Platform not supporting ND Proxy, No ND Suppression  DCS-7020R...
Continue reading →

MSDP support for multi-agent model

Description The Multicast Source Discovery Protocol (MSDP) provides a mechanism to connect together multiple PIM Sparse-Mode (PIM-SM) domains. Through peering relationships with MSDP-speaking routers in other PIM-SM domains, an MSDP speaker can learn of multicast sources in these domains, and interested receivers in its own can then be delivered multicast data from these over an inter-domain distribution tree. Existing support is in place for MSDP with the ribd routing protocol model. EOS-4.22.1F introduces support for MSDP with the multi-agent routing protocol model. Platform compatibility This feature is platform-independent. SA Messages and RPF-Peer Selection In both the ribd and multi-agent models,...
Continue reading →

Support for UCMP “adjust auto” (multi-agent)

Description Unequal-cost multi-path (UCMP) for BGP is a mechanism for forwarding ECMP route traffic using weights, with which the next hops of those routes are programmed in the FIB. This is done using BGP by disseminating BGP link-bandwidth extended community attribute information with BGP routes, such that the receiver device of all routes programs the next hops in the FIB using the received link-bandwidth values. This feature appends the percentage of interface speed with a route’s received link bandwidth extended community value. The idea is to rebalance the weight ratio of the traffic sent over egress ports, such that we...
Continue reading →

BGP shutdown and reset communication (multi-agent)

Description This feature implements support for RFC8203/BIS so that users can attach the reason of BGP instance or peer session administrative shutdown or hard reset to the BGP Cease Notification sent to the peers. Platform compatibility This feature is platform independent and only available when multi-agent mode is enabled. Configuration Below is a list of all possible configurations under this feature: (config-router-bgp)# shutdown [reason REASON] (config-router-bgp)# neighbor ( addr | peer-group) shutdown [reason REASON] (config-router-bgp)# clear [ip | ipv6] bgp [(neighbor (addr | peer-group)) | * ] [vrf (all | default | VRFNAME)] [reason REASON] Note that attaching ‘reason REASON’...
Continue reading →

BGP Labeled Unicast / Segment Routing support in multi-agent mode

Description This feature implements RFC3107 that allows carrying a label stack with BGP route updates, using multi-protocol BGP. It also implements segment routing extensions that allow accepting and carrying the transitive segment-index (SID) attribute in LU route updates. This implementation is for multi-agent mode. BGP LU for ribd mode is supported since 4.17.0F, see details in the following location: https://eos.arista.com/eos-4-17-0f/bgplu/ The following BGP LU features are supported: Basic IPv4 and IPv6 BGP LU, both receiving LU updates and originating/re-advertising LU routes to other peers iBGP and eBGP peering for LU peers Using ISIS-SR (or other MPLS tunnels) as the underlay...
Continue reading →

BGP VPN and Inter-VRF Local Route Leaking Support for default VRF

Description This feature extends the BGP Layer 3 VPN Import/Export and VRF Route Leaking functionality to “default” VRF. Currently, these functionalities are only supported for non-default VRF. Please refer to this TOI for more details on the support for non-default VRF. EOS supports the following two types of VPN configurations and this feature is applicable for both. RFC 4364 BGP/MPLS L3 VPN (TOI Link) BGP L3 EVPN (TOI Link) This feature is available when configuring BGP in the multi-agent routing protocol model. Platform Compatibility DCS-7250 DCS-7050TX/SX/QX DCS-7060X DCS-7280R DCS-7500R Configuration Configuring BGP VPN in default VRF is similar to how it is...
Continue reading →

EVPN VxLAN IPV6 Overlay

Description Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from IPV6 host to another IPV6 host on a stretched Vxlan VLAN. This TOI explains the EOS configuration and show commands. Platform compatibility Platform Supporting ND Proxy and ND Suppression DCS-7280R/7280R2 DCS-7050CX3-32S-F DCS-7050SX3-48YC12-F ( Starting in 4.22.1F ) DCS-7050SX3-48YC8 ( Starting in 4.22.1F ) DCS-7050/7050X/7050X2 ( Starting in 4.22.1F ) DCS-7260X/7260X3 ( Starting in 4.22.1F ) DCS-7060X/7060X2 ( Starting in 4.21.1F ) DCS-7250 ( Starting in 4.22.1F ) DCS-7300/DCS-7320 ( Starting in 4.22.1F ) Platform Compatibility (No ND Proxy, No ND Suppression) DCS-7020R...
Continue reading →

BGP replace remote-as

Description The replace remote AS feature allows a provider edge (PE) router to change the autonomous system (AS) number used by a customer edge (CE) device, on an external BGP (EBGP) session. Enterprises, which are geographically distributed, are connected via providers. As a best practice, these enterprises use same BGP AS across multiple sites. This will cause the local AS number to be carried in AS_PATH via external BGP sessions, as illustrated in the diagram below. BGP, by default, does not accept routes with an AS path attribute that contains the local AS number to prevent routing loops. In the...
Continue reading →

sFlow extension BGP in multi-agent

Description Sflow samples can be augmented with additional Extended gateway data by getting data from BGP in addition to sFlow’s standard IP information. The additional BGP information can be seen in sFlow Version 5 doc under extended_gateway. Extended gateway data was already supported in gated mode. Now it is being supported for multi-agent mode (arBGP). Platform compatibility This feature is supported on all platforms. Configuration A BGP instance must be configured on the switch for BGP sFlow export to operate. rtr1(config)#sflow run rtr1(config)#sflow extension bgp Show Commands bgprtr1(config)#show sflow sFlow Configuration ------------------- Destination(s):   127.0.0.1:54855 (VRF: default) Source(s):   10.10.10.10 (VRF: default)...
Continue reading →

GTSM for BGP

Description This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect BGP peering sessions (both iBgp and eBgp) from an attacker on the network segment causing denial of service using forged IP packets by spoofing the BGP peer’s IP address. The solution is described by the RFC 3682 (Generalized TTL Security Mechanism). The user can configure a minimum TTL for incoming IP packets received from the BGP peer. BGP session will only get established if the TTL value in the received IP packet header is greater than or equal to the...
Continue reading →

ribd vs multi-agent (ArBGP)

My organization is developing lab scenarios to move our network towards implementing EVPN. Part of that process is to add the: service routing protocols model multi-agent command. We have found a few unique situations where the default behavior of routing (outside of BGP) has changed. For example: OSPF summary routes not working Static routes to unreachable next hops (while the interface is up) are not placed in the RIB. I have been unable to find any documentation outside about what actually changes when implementing that command. Is there a white paper about it, or a list of default behaviors that...
Continue reading →

GTSM for BGP

Description This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect BGP peering sessions (both iBgp and eBgp) from an attacker on the network segment causing denial of service using forged IP packets by spoofing the BGP peer’s IP address. The solution is described by the RFC 3682 (Generalized TTL Security Mechanism). The user can configure a minimum TTL for incoming IP packets received from the BGP peer. BGP session will only get established if the TTL value in the received IP packet header is greater than or equal to the...
Continue reading →

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: