NAT for an IP shared over BGP inside a VRF

Hi, I am having a bit of an issue in getting this to work and if anyone could help it would be greatly appreciated. I am trying to do a 1:1 Source and Destination NAT for a route advertised over BGP. The SNAT rule is working but the DNAT is not. Traffic hits the external interface but never exits the internal interface.   Thanks for taking a look!   Here is the relevant sanitized config: ! device: SSP2 (DCS-7150S-52-CL, EOS-4.17.0F) ! ! boot system flash:/EOS-4.17.0F.swi ! vlan 105 name Peer ! vlan 505 name Peer_TR ! vrf definition Peer_vrf rd...
Continue reading →

AS Ranges for Dynamic BGP Peer Groups

BGP neighbors, or peers, are initiated by configuration commands that cause BGP to establish TCP connections with other BGP speakers.  Dynamic neighbors are established by creating a listen range and accepting incoming connections from neighbors within that address range.  Dynamic neighbors must be configured using a dynamic peer group, which defines attributes for all neighbors associated with the listen range.  A BGP listen range has so far allowed exactly 1 remote AS number to be specified for acceptable incoming connections. The AS Ranges for Dynamic Peer Groups feature introduces a flexible means of specifying multiple, allowable remote AS numbers for...
Continue reading →

BGP AS path prepend using “last-as” keyword

The “set as-path prepend” clause in route-map configuration mode has been enhanced with the addition of the “last-as” keyword, which will prepend the AS path with the specified number of instances of the last AS number in the AS path. Currently, the command only accepts an explicit list of AS numbers to prepend to the AS path. This list may also include one or more “auto” keywords in place of AS numbers, which are replaced by the peer AS number for inbound routes, and the local AS number for outbound routes. By extending some AS paths, this feature enables customers...
Continue reading →

as masquerading – need to ibgp peer in a vrf using different as number than main vrf

I know with arista all VRF’s have to have the same AS number. lets say I use as 65000 to ebgp peer with someone. If I set up aanother VRF and want to ibgp peer with someone using as 65005, with the “local as” function where you impersonate an AS number, if I use local-as 65005 and peer with another router using 65005 will it behave as iBGP? Because I have an arista router using 65000 for eBGP with a partner and I need to also iBGP with someone using 65005 in a second VRF. Will this local-as approach work?...
Continue reading →

Load Balancing with ECMP: Hardware Configuration Lookup

Abstract: This publication illustrates a technique which can be used to find exactly how Arista devices program routes to send traffic across multiple available paths. An example will be given on the Arista DCS-7150S-52-CL-R running EOS version 4.14.8M. Initial configuration: As an IGP we are using OSPF with maximum paths feature configured: Arista(config)#router ospf 1 Arista(config-router-ospf)#maximum-paths 32 There are two iBGP peers configured via a peer-group “pg1”: Arista(config)#router bgp 65001 Arista(config-router-bgp)#neighbor pg1 maximum-routes 16000 Arista(config-router-bgp)#neighbor 172.20.18.49 peer-group pg1 Arista(config-router-bgp)#neighbor 172.20.18.121 peer-group pg1 iBGP advertisements: * >   10.82.2.32/27       172.20.16.143    0       100     0       64920 64944...
Continue reading →

vEOS BGP fails to establish with Cumulus VX

I’m running vEOS (4.17.0F) in a KVM hypervisor along with an instance of Cumulus VX 3.0.1. I’m attempting to bring up a simple BGP session between the devices through a virbr virtual network, but AFACT the vEOS instance is failing to ack any SYN packets to TCP/179 coming from the Cumulus instance; every 30 seconds the vEOS instance sends a SYN to TCP/179 to the Cumulus instance, which then sends a SYNACK back…which vEOS doesn’t acknowledge either. I’m not seeing any oddities WRT the BGP configs or basic reachability (the fact that I do see SYNs going in both directions...
Continue reading →

RFC 5549: IPv4 unicast NLRI with IPv6 next-hop support

This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions described as the Extended Next Hop Encoding capability in RFC5549. Extended Next Hop Encoding capability can be supported for IPv4 unicast, IPv4 Labeled Unicast, and IPv4 VPN address and sub-address families (1/1, 1/4, 1/128 respectively). In this release, the feature enables negotiating Extended Next Hop Encoding capability for IPv4 unicast NLRI advertisements over IPv6 BGP sessions, and encoding of the next-hop in the UPDATE message that allows determination of the next-hop’s address family. Platform compatibility This feature is provided on...
Continue reading →

BGP Policy config enhancements

The sub-route-map configuration simplifies routing policies by sharing common policy across route-maps. Common functionality of route-maps configured as inbound/outbound BGP policies can be extracted into a separate route-map and reused using sub-route-map. Platform compatibility This feature is available on all platforms. Configuration CLI A route-map can be made to refer another route-map by configuring the other (referred) route-map as sub-route-map. route-map referring_map_name [permit|deny][sequence_number] [ match condition ] [ no|default ] sub-route-map referred_map_name [ set condition ] “no” or “default” variant of command will un-configure the sub-route-map. While configuring sub-route-map care must be taken to avoid cycles, which will result in...
Continue reading →

Maximum number of accepted-routes in BGP

Currently, the ‘maximum-routes’ knob allows one to set an upper bound on the number of routes that can be received from a neighbor. The ‘maximum-accepted-routes’ feature provides the ability to set an upper bound on the number of routes that can be accepted from a neighbor after filtering. When the limitation is exceeded, the peer session will be put into Idle state indefinitely. The session can be reactivated by issuing one of the ‘clear ip bgp neighbor’ commands or by configuring the bgp idle restart interval (see Reference section below). Platform compatibility This feature is provided on all platforms. Configuration...
Continue reading →

eBGP IP next-hop unchanged

The eBgp “ip next-hop unchanged” feature allows a router to send routes to its eBgp peers without changing their next-hops to its own peering address. By default a Bgp router, as defined in RFC 4271, changes the next-hop attribute of a route to its own address before sending it out to its eBgp peer. The router uses third party address as next-hop when the eBgp peers are within the same subnet as the source of the prefixes. Users may need further flexibility for multihop eBgp peer other than the above cases. If the command proposed by this feature is configured,...
Continue reading →

eBGP IP next-hop unchanged

The eBgp “ip next-hop unchanged” feature allows a router to send routes to its eBgp peers without changing their next-hops to its own peering address. By default a Bgp router, as defined in RFC 4271, changes the next-hop attribute of a route to its own address before sending it out to its eBgp peer. The router uses third party address as next-hop when the eBgp peers are within the same subnet as the source of the prefixes. Users may need further flexibility for multihop eBgp peer other than the above cases. If the command proposed by this feature is configured,...
Continue reading →

CLI command to explain BGP best path selection

This feature provides the ability to track the reason why a BGP path is excluded from the BGP best path selection process. For a given prefix, the show command output indicates how the winning best path was determined by adding a reason next to every losing path. Please refer to the full BGP best path selection process document for more details. BGP best path selection process Platform compatibility This feature is provided on all platforms. Status Show Commands The explanation for the BGP best path selection process decision can be found within the output of show ip bgp <prefix> detail...
Continue reading →

EVPN Control-Plane support for VxLAN

Just wondering if there is EVPN Control-Plan extensions planned for support (and when) with VxLAN Leaf devices like ahem, other vendor’s are doing.  Stretched fabrics (over wan) are becoming popular as an escape from OTV and prior ilk are where this seems most relevant, and something I’m seeing interest in where flood control can/should be most relevant.

Layer 3 Leaf-Spine – Rendezvous Point Placement?

Hello everybody, I have configured a leaf-spine architecture (4 leafs, 2 spines), see attached image. L3 routing is enabled on leafs and spines and eBGP is used between them. To enable VXLAN (from VMware Hosts), multicast needs to be configured. So far, ip multicast-routing and ip pim sparse-mode is set. Where do I configure the rendezvous point (RP) and which method would I use? I would prefer to place it on the spine switches using anycast-rp, but one spine switches does not reach the other spine switch (as the route to spine1 is not announced to spine2 by the leafs...
Continue reading →

BGP METRIC attribute

Hi, I was trying to find out how do I configure Metric BGP attribute? I look all over the Arista commands and could not figure it out. Thank you   Victor