• Tag : multi-agent

 
 

BGP IPv6 Link Local Peers Discovery

Description This feature adds support for a dynamic configuration model to eliminate the need for the network administrator to assign and configure IPv6 addresses for BGP peering. We leverage the following details to automatically establish BGP adjacency: IPv6 link local addresses can be, and typically are, automatically generated by the system based on MAC addresses. IPv6 router advertisements can be used to communicate these addresses among potential BGP peers. Since this feature uses IPv6 router advertisement to discover the peer’s IPv6 link local address, devices are required to have IPv6 routing enabled, and the interface used for peering should have...
Continue reading →

Route Map – Match Interface Support in Multi-Agent

Description This feature adds support for ‘match interface’ clause under route-map config for Bgp policy application in multi-agent model. This feature may be used when a policy to filter routes on the basis of the resolved interface of a route is desired. A route-map can be used at various application points to filter routes based on the policy but ‘match interface’ is supported  only for specific application points. For such applications when a route-map with ‘match interface’ clause is applied, the interface of the resolved nexthop of each route is matched against the interface specified in route-map and the route...
Continue reading →

BGP sFlow export in multi-agent mode

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). Starting in EOS 4.22.1F v6 non-default vrf traffic is supported Starting in EOS 4.23.2F ECMP traffic is supported 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...
Continue reading →

BGP logical OR of multiple community lists in the same match command

Description In the multi-agent routing protocol model, the Bgp agent now supports matching community lists with a logical OR via the route map “match community or-results <community-list-1> <community-list-2>” command (same applies for extended and large communities with “match extcommunity” and “match large-community”). Without this new “or-results”, the default is to compute the logical AND of all provided community lists. Before this new feature one would need to merge existing community lists into one to do a logical OR: Issue: ip community-list COMMLIST1 permit 1:1 ip community-list COMMLIST2 permit 2:2 ! No way to match "COMMLIST1" or "COMMLIST2" in a singe...
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 one 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 DCS-7160 DCS-7500R/7500R2/7500E Configuration Enable IPv6 Routing Enable global IPv6 unicast routing and IPv6...
Continue reading →

Static inter-VRF route support

Description This feature adds support for static inter-VRF routes. This enables configuration of routes to destinations in one ingress VRF with an ability to specify a next-hop in a different egress VRF through a static configuration. Such static inter-VRF routes can be configured in default and non-default VRFs. A different egress VRF is achieved by “tagging” the “next-hop” or “forwarding via” with a reference to an egress VRF (different from the source VRF) in which that next-hop should be evaluated. Static inter-VRF routes with ECMP next-hop sets in the same egress VRF or heterogenous egress VRFs can be specified This...
Continue reading →

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: