Showing posts with label Peering. Show all posts
Showing posts with label Peering. Show all posts

3/14/2019

Arista BGP Peering Options (5) - v6 link-local peering/NH



Arista TOI Link

Compared with "v4 over v6 NH", the configuration is quite similar, except the interface address and neighbor use link-local address. 

So the benefits here are obvious:

  • Minimizing the configuration efforts, no need ipv4 and global ipv6 address. 
  • IPv4 NLRI over IPv6 link-local NH. 

Because the link-local address is a local address and not accessible by remote devices, the bgp configure is considered to be a special one. The following regular bgp knobs don't work as usually:

  • iBGP
  • eBGP multi-hop
  • confed BGP
  • local AS if changing to iBGP
  • Link-local eBGP learnt routes are not advertised to iBGP peers, because of lacking NH address
Please note that this is ONLY supported in Gated, not in multi agent mode. 

3/13/2019

Arista BGP Peering Options (4) - IPv4 NRLI over IPv6 NH



This blog is about the v4 NRLI over v6 NH. Based on Arista 4.17.0F TOI, this feature comprises 2 parts:
Compared with previous configurations, 2 configures are needed:
  1. IPv4 forwarding on IPv6 interface, which is enabled by "ip routing ipv6 interfaces  vrf v3"
  2. neighbor <ipv6Nei> next-hop address-family ipv6 originate
Another way of 2nd part is to enable "bgp next-hop address-family ipv6". But in the above topology, the NRLI is originated directly, so have to put originate. 

From the output of "show ip route", you can see the v4 route's NH is the ipv6 address

R1.lp231.20:13:59(config-router-bgp-vrf-v3)#sh ip route bgp detail
VRF: v3
 B E   103.2.2.0/24 [200/0]
       via 12:12:103::2, Vlan103

R1.lp231.20:14:07(config-router-bgp-vrf-v3)#sh ip bgp 103.2.2.0
BGP routing table information for VRF v3
Router identifier 103.2.2.2, local AS number 1
BGP routing table entry for 103.2.2.0/24
 Paths: 1 available
  2
    12:12:103::2 from 12:12:103::2 (103.2.2.2)
      Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:18:46 ago, valid, external, best
      Rx SAFI: Unicast


Arista BGP Peering Options (3) - IPv6 NRLI over IPv4 Peering


This peering configuration is the reverse version of the previous one. So the configuration-wise, it is very similar. 

The benefit is clear, we only need 1 BGP peering to carry both address families. But we still need to keep a dual stack on the interfaces to be used as NH. In today data center network, ECMP is very popular and wide. Evening using /31, the finest network mask, a /24 can only afford 128 links. 

And this youtube explains very well on the requirement behind RFC 5549, ipv4 over v6 NH, which is shown in the next blog

Arista BGP Peering Options (2) - IPv4 NRLI over IPv6 Peering



Here is the TOI link

On the top of regular IPv6 BGP configuration, you need to configure 2 things:

1) Enable IPv4 NLRI over v6 peering and 2 ways to do it:
  1. Under ipv4 address-family, activate it on ipv6 peering, which is shown in R1's configuration
  2. Global configuration of "bgp default ipv4-unicast transport ipv6" in R2's show run
2) Specify the IPv4 NH of IPv4 prefixes, and we can do it 3 ways:
  1. Global automatic NH address - "bgp auto-local-addr" in R'2 configuration. But this is a global knob, so if you have IPv6 prefixes over IPv4 NH, it will break peering silently
  2. Neighbor-base automatic NH address - "neighbor 12:12:101::1 auto-local-addr"
  3. Neighbor-base manual NH address in R1's configuration - "neighbor 12:12:101::2 local-v4-addr 12.12.101.1"
Here is the output of "sh ip bgp 101.2.2.0" (I enable "routing-context vrf v1", so no need vrf)

R1.lp231.16:28:58(config)#sh ip bgp 101.2.2.0
BGP routing table information for VRF v1
Router identifier 101.1.1.1, local AS number 1
BGP routing table entry for 101.2.2.0/24
 Paths: 1 available
  2
    12.12.101.2 from 12:12:101::2 (101.2.2.2)
      Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:02:03 ago, valid, external, best
      Rx SAFI: Unicast

And both ipv4/ipv6 ping work as expected. 

R1.lp231.16:29:11(config)#ping 101.2.2.2
PING 101.2.2.2 (101.2.2.2) 72(100) bytes of data.
80 bytes from 101.2.2.2: icmp_seq=1 ttl=64 time=0.242 ms
80 bytes from 101.2.2.2: icmp_seq=2 ttl=64 time=0.100 ms
80 bytes from 101.2.2.2: icmp_seq=3 ttl=64 time=0.093 ms
80 bytes from 101.2.2.2: icmp_seq=4 ttl=64 time=0.091 ms
80 bytes from 101.2.2.2: icmp_seq=5 ttl=64 time=0.093 ms

--- 101.2.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.091/0.123/0.242/0.060 ms, ipg/ewma 0.174/0.180 ms
R1.lp231.16:31:39(config)#ping ipv6 101:2:2::2
PING 101:2:2::2(101:2:2::2) 72 data bytes
80 bytes from 101:2:2::2: icmp_seq=1 ttl=64 time=0.262 ms
80 bytes from 101:2:2::2: icmp_seq=2 ttl=64 time=0.106 ms
80 bytes from 101:2:2::2: icmp_seq=3 ttl=64 time=0.103 ms
80 bytes from 101:2:2::2: icmp_seq=4 ttl=64 time=0.099 ms
80 bytes from 101:2:2::2: icmp_seq=5 ttl=64 time=0.103 ms

--- 101:2:2::2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.099/0.134/0.262/0.064 ms, ipg/ewma 0.184/0.196 ms

Arista BGP Peering Options (1)

In this series of blogs, I will discuss a bit on the Arista EOS BGP peering options. As of March 2019, the EOS has the following peering options:

Arista EOS BGP peering features

Here is the Arista official TOI links:
So, why do we need them, what's the difference and how to configure them?

1) Why
Today's network needs to support dual address spaces - IPv4 and IPv6, which requires providers to run 2 parallel control/forward planes. So the purpose of all the above features is to decrease the complexity by reducing control plane even forward plane.

For example, a data center with public ipv4/ipv6 address and needs support worldwide ipv4 and ipv6 access. Is that possible to use ipv4/ipv6 address space at the server pool and service routers, and only ipv6 infrastructure? The answer is yes.

2)  What's the difference between the above 3 options?
  1. The basic way is to have dual ipv4/ipv6 infrastructures and control planes, which means, 2 BGP sessions and 2 address planes. 
  2. IPv4 NRLI over IPv6 Transport is to send v4 prefixes over v6 peering. So it saves 1 just 1 control plane - ipv6 bgp but still needs ipv4 next hop as ipv4 prefixes, which means 2 data planes or dual v4/v6 stack. 
  3. RFC 5549 - IPv4 NRLI over IPv6 NH, this feature is one step further, ipv4 prefixes can use ipv6 NH. So 1 BGP session and 1 data planes (v6 infrastructure)
  4. BGP IPv6 link-local peering, this utilizes the ipv6 link-local address to establish BGP peering w/o assigning global IPv6 interface addresses. 
3) How to configure them? In the following blogs, I will show the configuration 1 by 1. (Please note that I use vrf under router bgp, in order to configure them together in one place. But it is not required and most of the time, you only need ONE)