Overlay Routing#
With IP underlay configured we prepared the grounds for the EVPN overlay services. In order to create an EVPN service on top of an IP fabric our leaf devices should be able to exchange overlay routing information. And you guessed it, there is no better protocol for this job than BGP with an EVPN address family. At least that's what the industry has agreed upon.
Since all our leaf switches can reach each other via loopbacks, we can establish a BGP peering between them with evpn address family enabled. Operators can choose to use iBGP or eBGP for this purpose. In this tutorial, we will use iBGP for the overlay routing using spine as the Route Reflector (RR).
Utilizing RRs reduces the number of BGP sessions; leaf switches peer only with RRs and receive from other leafs at the same time. This approach minimizes configuration efforts, allows for centralized application of routing policies, but, at the same time, introduces another protocol.
In this section our goal is to setup iBGP session with evpn address family between our leaf switches so that when we configure L3 EVPN instance in the next chapters; the overlay EVPN routes will be exchanged between the leafs using these sessions.
Let's have a look at the configuration steps required to setup overlay routing on our leaf switches:
-
BGP peer-group
Just like with the underlay, creating a BGP peer group simplifies configuring multiple BGP peers with similar requirements by grouping them together. We will call this groupoverlay. -
Autonomous System Number
Since we are configuring a new iBGP instance, all routers should share the same AS number. We will use AS 65535; note, that we will have to set the peer-as and local-as, since otherwise a globally configured underlay AS number would be used. -
Address Family
In the overlay, we only care about the EVPN routes, hence we are enabling the EVPN address family for the overlay BGP group and disabling theipv4-unicastfamily that was enabled globally for the BGP process for the underlay routing. -
Neighbors
Leaf devices uses Spine's System IP for iBGP peering.
-
EVPN Route Reflector
The command below will enable the route reflector functionality and only needs to be enabled on the spine.
Resulting configs#
Here are the config snippets for the leaf and spine devices covering everything we discussed above.
enter candidate
/ network-instance default {
protocols {
bgp {
group overlay {
peer-as 65535 !!! iBGP to the spine acting as route-reflector
afi-safi evpn {
admin-state enable
}
afi-safi ipv4-unicast {
admin-state disable
}
local-as {
as-number 65535
}
}
neighbor 10.10.10.10 {
admin-state enable
peer-group overlay
}
}
}
}
commit now
enter candidate
/ network-instance default {
protocols {
bgp {
dynamic-neighbors {
accept {
match 0.0.0.0/0 {
peer-group overlay
}
}
}
group overlay {
peer-as 65535
afi-safi evpn {
admin-state enable
}
afi-safi ipv4-unicast {
admin-state disable
}
local-as {
as-number 65535
}
route-reflector {
client true
}
}
}
}
}
commit now
Verification#
Similarly to the verifications we did for the underlay, we can check the BGP neighbor status to ensure that the overlay iBGP peering is up and running. Since all leafs establish the iBGP session with the spine, we can list the session on the spine to ensure that all leafs are connected.
--{ + running }--[ ]--
A:spine# / show network-instance default protocols bgp neighbor 10.*
----------------------------------------------------------------------------------------------------
BGP neighbor summary for network-instance "default"
Flags: S static, D dynamic, L discovered by LLDP, B BFD enabled, - disabled, * slow
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
+----------+----------+----------+----------+----------+----------+----------+----------+----------+
| Net-Inst | Peer | Group | Flags | Peer-AS | State | Uptime | AFI/SAFI | [Rx/Acti |
| | | | | | | | | ve/Tx] |
+==========+==========+==========+==========+==========+==========+==========+==========+==========+
| default | 10.0.0.1 | overlay | D | 65535 | establis | 0d:0h:3m | evpn | [0/0/0] |
| | | | | | hed | :35s | | |
| default | 10.0.0.2 | overlay | D | 65535 | establis | 0d:0h:3m | evpn | [0/0/0] |
| | | | | | hed | :27s | | |
+----------+----------+----------+----------+----------+----------+----------+----------+----------+
----------------------------------------------------------------------------------------------------
Summary:
0 configured neighbors, 0 configured sessions are established,0 disabled peers
4 dynamic peers
Both iBGP sessions from the spine towards the leafs are established. It is also perfectly fine to see no prefixes exchanged at this point, as we have not yet configured any EVPN services that would create the evpn routes.
This is what we are going to do next in the L3 EVPN section.