Scribd
Upload
6 views1 page

PG 4

The document discusses a network setup where a leaf switch receives remote routes from two spine switches, demonstrating end-to-end connectivity through successful pings between leaf-1 and leaf-2. It outlines the benefits of this design, such as avoiding BGP AS numbers and update intervals, while also hinting at potential drawbacks. The document suggests using a GitHub repository for testing similar configurations.

Uploaded by

arunprabhuram
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views1 page

PG 4

The document discusses a network setup where a leaf switch receives remote routes from two spine switches, demonstrating end-to-end connectivity through successful pings between leaf-1 and leaf-2. It outlines the benefits of this design, such as avoiding BGP AS numbers and update intervals, while also hinting at potential drawbacks. The document suggests using a GitHub repository for testing similar configurations.

Uploaded by

arunprabhuram
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

* 10.0.0.2/32 10.1.0.

6 0 - 100 0
* > 10.0.0.3/32 10.1.0.2 0 - 100 0
* > 10.0.0.4/32 10.1.0.6 0 - 100 0
* > 172.16.0.0/24 - - - - 0
* > 172.16.1.0/24 10.1.0.2 0 - 100 0
* 172.16.1.0/24 10.1.0.6 0 - 100 0

As you can see:

The leaf switch receives remote routes from two spine switches.
The BGP next hops are set to the IP addresses of the spine switches.

Not surprisingly, leaf-1 can ping the loopback IP address of leaf-2 , proving the end-to-
end connectivity:

leaf-1#ping ip leaf-2 source 10.0.0.1


PING leaf-2 (10.0.0.2) from 10.0.0.1 : 72(100) bytes of data.

SIDEBAR
80 bytes from leaf-2 (10.0.0.2): icmp_seq=1 ttl=63 time=0.649 ms
80 bytes from leaf-2 (10.0.0.2): icmp_seq=2 ttl=63 time=0.349 ms
80 bytes from leaf-2 (10.0.0.2): icmp_seq=3 ttl=63 time=0.459 ms
80 bytes from leaf-2 (10.0.0.2): icmp_seq=4 ttl=63 time=0.489 ms
 
80 bytes from leaf-2 (10.0.0.2): icmp_seq=5 ttl=63 time=0.520 ms

--- leaf-2 ping statistics ---


5 packets transmitted, 5 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 0.349/0.493/0.649/0.096 ms, ipg/ewma 1.000/0.572 ms

Want to repeat my tests? The easiest way would be to use netlab-examples repository with
GitHub Codespaces (import Arista EOS container if needed and change the directory to
BGP/interface-IBGP ).

Benefits and Drawbacks

Should you use this design? Probably not, but let’s go through the benefits and drawbacks:

Benefits:

You don’t need to deal with BGP AS numbers. BGP CLUSTER_LIST attribute replaces the
AS_PATH attribute as the loop prevention mechanism.
You don’t need to worry about the BGP update interval. Most implementations do not
delay/batch IBGP updates.
You don’t have to worry about valley-free routing or path hunting. Leaf switches will not
reflect IBGP routes.
Your job security has increased by a few percentage points.
You can go to conferences and boast about how cool you are.

Drawbacks

You might also like