• Author : Sandeep Betha


BGP nexthop resolution RIBs

Description This feature adds support for user-configured BGP Nexthop Resolution RIB profiles for various BGP-based services e.g. IP unicast, L3 VPN, EVPN, etc. The feature allows an administrator to customize the next hop resolution semantics of BGP routes with an ordered list, or profile, of resolution RIB domains (i.e., either tunnel or IP domain). This allows EOS to direct specific services over the specified RIB domains, overriding the default behavior. Further, this feature, through the use of user-defined tunnel RIBs, empowers an administrator to further select a subset of tunnelling protocols for specific services. Refer to User-defined tunnel RIBs for...
Continue reading →

Optimizing hardware utilization for unused (S,G) routes

Description Current EOS PIM sparse mode implementation installs an (S, G) route in the hardware whenever it receives an (S, G) join from the PIM neighbor. Prior to using this feature, devices could have higher hardware utilization because EOS installs all the routes corresponding to the (S, G) joins. This is especially evident if the devices peers with other autonomous system receivers which are administered by an external source. These receivers can send a large number of (S, G) joins for invalid sources leading to exhaustion of hardware resources. With the support of this feature, PIM sparse mode doesn’t install...
Continue reading →

Support to Restrict the Number of Bgp Ecmp Next Hops in Multi-Agent Protocol Model

Description In the ribd routing protocol model, the “maximum-paths … ecmp …” command allows restricting the number of BGP paths and the number of vias in the ECMP FEC respectively. In the multi-agent protocol model, a “maximum-paths” value of greater than 1 enabled the formation of ECMP. However, the number of BGP paths or the number of vias in the FEC were not constrained by the configured value. With the 4.24.0F EOS release, the multi-agent protocol model supports restricting the number of BGP paths and ECMP FEC size based on the BGP configuration. Platform Compatibility Supported on all platforms. Configuration...
Continue reading →

MLDv2 Snooping

Description MLDv2 Snooping optimizes the transmission of multicast packets in Layer 2 by using Layer 3 information contained in MLDv2 and PIM packets. MLDv2 is the protocol used to manage the membership of hosts in multicast groups for IPv6. RFC 3810 talks about MLDv2 functionality. MLDv2 is the IPv6 counterpart of IGMPv3. Starting in EOS 4.25.0F, MLDv2 Snooping is supported on MLAG deployments. Platform compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7500R DCS-7500R2 CCS-720XP CCS-750 DCS-7050CX3 DCS-7050SX3 DCS-7050TX3 DCS-7300X3 DCS-7280R3 DCS-7500R3 DCS-7800R3 Feature History Release Update 4.25.0F Initial introduction. Support for 7020R, 7280R, 7280R2,  7500R and 7500R. 4.26.0F Support for 720XP, 750, 7050CX3,...
Continue reading →

Connecting IPv6 islands over IPv4 MPLS using IPv6 provider edge routers

Description This feature allows service providers to interconnect IPv6 sites over a Multiprotocol Label Switching (MPLS)-enabled IPv4 core network as defined in RFC 4798. This approach relies on IPv6 Provider Edge (6PE) routers to be dual stacked, to connect the IPv6 site and the MPLS core. A typical use case is described below where PE1 and PE2 are 6PE routers and LSR is a label switching router. TCP transport session for the 6PE peer should be IPv4. IPv6 destinations are advertised as MP-BGP path attributes with IPv6 AFI and MPLS label SAFI. IPv6 MP-BGP destinations are always advertised with IPv6...
Continue reading →

Supporting GSHUT community in BGP

This feature adds support for standard BGP GSHUT (0xFFFF0000) community. GSHUT community is the community used in BGP for graceful shutdown. With this support, the BGP speaker sets the local preference of the incoming BGP advertisement to 0 if the advertisement is received with attributes containing GSHUT community. It also enables setting the GSHUT community and matching on GSHUT community using route-maps. Configuration No explicit configuration is required to enable processing GSHUT community. The following configuration creates a route-map entry that sets the community to GSHUT: Arista(config)#route-map map1 Arista(config-route-map-map1)#set community GSHUT Arista(config)#exit Arista(config)# The following configuration creates a route-map entry that...
Continue reading →

AS prepend in BGP policy using “auto” keyword

The "set as-path prepend" clause in the config-route-map mode is enhanced to accept the "auto" keyword. The "auto" keyword is designed to take the value of either the BGP local or peer AS number depending on the directionality of the route-map. In the case of neighbor inbound route-map, the "auto" takes the value of peer AS number and for outbound route-maps, it takes the value of local AS number. The "auto" keyword has no significance in all other cases and will be ignored. The as-path sequence of “set as-path prepend” can accept more than one “auto” similar to any other...
Continue reading →


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

Join other followers: