At this point in your networking career you’ve mastered the L2 domain. I can recall several years ago when I was an embedded software engineer (programming NPUs – Network Processing Units for a networking startup) meeting a colleague that was a master of the L2 domain. This individual knew everything you wanted to know about L2, including non-Ethernet protocols. Then came the day when I was drawing a network diagram with L3 interfaces and diagramming the packet formats at the points of ingress and egress through each L3 hop. My L2 Grandmaster looked at me with a blank stare. I then realized that there is a moment in one’s life when you have an epiphany about layered abstractions in networking. My L2 Grandmaster needed help transitioning from being an L2 thinker into an L3 thinker.
Since then I’ve run into several individuals and customers that are more L2-centric thinkers than they are L3-centric thinkers. So I figured that I’d share some simple L3 configurations that can help transition people to start dabbling in the world of L3.
Let’s look at a very simple network diagram along with their partial configurations below. I want to present a set of very simple configs that provide a minimum needed to allow for L3 peering between Leaf-1 and Spine-1. Note that the connection between Leaf-1 and Leaf-2 is a simple L2 trunk port, which the L3 newbie can use for comparison of configurations to the L3 connection between Leaf-1 and Spine-1. Also note that the cluster of hosts that are southbound of Leaf-1 have IP addresses within the subnet of 172.16.112.0/24.
Leaf-1 Configuration (partial)
vlan 12 ! interface Ethernet1 description LEAF2 switchport mode trunk ! interface Ethernet2 description SPINE1 no switchport ip address 172.16.200.0/31 ip ospf network point-to-point ! interface Ethernet5 description HOST1 switchport trunk allowed vlan 12 switchport mode trunk ! interface Loopback0 ip address 172.16.0.3/32 ! interface Management1 ip address 192.168.0.14/24 ! interface Vlan12 ip address 172.16.112.1/24 ! ip routing ! router ospf 1 router-id 172.16.0.3 passive-interface default no passive-interface Ethernet2 network 0.0.0.0/0 area 0.0.0.0
Leaf-2 Configuration (partial)
interface Ethernet1 description LEAF1 switchport mode trunk ! interface Loopback0 ip address 172.16.0.4/32 ! interface Management1 ip address 192.168.0.15/24 ! ip routing
Spine-1 Configuration (partial)
interface Ethernet2 description LEAF1 no switchport ip address 172.16.200.1/31 ip ospf network point-to-point ! interface Loopback0 ip address 172.16.0.1/32 ! interface Management1 ip address 192.168.0.10/24 ! ip routing ! router ospf 1 router-id 172.16.0.1 passive-interface default no passive-interface Ethernet2 network 0.0.0.0/0 area 0.0.0.0
Let’s talk about a few of the commands related to the OSPF dynamic routing protocol for Spine-1. Note that the same explanations also apply to Leaf-1.
router ospf 1
- This specifies your intention to run an OSPF process with a process ID = 1
- This process ID can be any number between 1 – 65535
- Note that there can be multiple OSPFv2 (IPv4) instances on a switch (https://eos.arista.com/eos-4-23-1f/ospfv2-multiple-instances-support/)
- Also note that any one switch can run instances of OSPF and another dynamic routing protocol simultaneously
- Sets an ID to identify this router to the rest of the OSPF infrastructure
- Note that it’s best practice to explicitly set a router-id
- When no router-id is set, there is then a precedence for the router’s identity (from highest to lowest):
- The loopback IP address is used when there is only a single loopback configured
- The loopback with the highest IP address is used when multiple loopbacks are configured
- The highest IP address on a single interface (not including any Management interfaces) is used when no loopback interfaces are configured
- This puts all interfaces into an OSPF passive state, meaning that there are no neighbor adjacencies established nor any routing updates sent out anywhere
no passive-interface Ethernet2
- In combination with the above, this will explicitly put a particular interface into an OSPF active state to establish a neighbor adjacency and begin sending routing updates out
- Note that leaving an interface in passive-interface state (“passive” state) is different than just shutting down (shutdown) that same interface. Shutting down that interface would prevent other interfaces (which may be in an “active” state via no passive-interface) from advertising the subnet attached to the shutdown interface.
network 0.0.0.0/0 area 0.0.0.0
- This is a very simple way to advertise all local networks – every L3 interface’s subnet. Note this assumes all connected subnets are in the same OSPF area 0.0.0.0.
- If you’d prefer to not have every subnet advertised out, you could instead use subnet-specific network statements under router ospf 1’s scope.
- Note that subnet-specific network statements provide a bit more control in case there’s a misconfiguration of a subnet elsewhere on the same switch that could, say, already be configured somewhere else in the infrastructure, hence you would have the same subnet advertised from different areas.
Within the interface scope, the command ip ospf network point-to-point is actually optional in this network since Leaf-1 and Spine-1 are physical and directly connected to each other. This command is recommended for point-to-point links because it eliminates the need for the OSPF DR (Designated Router) & BDR (Backup Designated Router) election process, since OSPF supports neighbor adjacency discovery on broadcast networks, like Ethernet.
Remember to always include ip routing in the global configuration for any switch that will perform L3 routing. Also note that OSPF requires that the interface MTUs match between peers in order to allow for OSPF peering (unless explicitly ignored, which isn’t recommended).
After the configurations above are applied to the 3 switches, we can now verify (from an L3 perspective between Leaf-1 and Spine-1 – Recall that the relationship between Leaf-1 and Leaf-2 is only L2 and won’t have any OSPF information or state) the OSPF peering state for Leaf-1:
Leaf-1#show ip ospf neighbor Neighbor ID VRF Pri State Dead Time Address Interface 172.16.0.1 default 0 FULL 00:00:35 172.16.200.1 Ethernet2
… and for Spine-1:
Spine-1#show ip ospf neighbor Neighbor ID VRF Pri State Dead Time Address Interface 172.16.0.3 default 0 FULL 00:00:32 172.16.200.0 Ethernet2
A “State” = FULL (or FULL/DR or FULL/BDR if you’re not using ip ospf point-to-point) is what you want to see. Note that “Address” is the IP address of the neighbor’s interface, and “Interface” is this switch’s interface from where this peering is established.
If we look at the IP routing table on Leaf-1, we see Leaf-1 has learned the Loopback0 (or router-id) of Spine-1 via OSPF and no other advertised route information that isn’t already directly connected (C) to Leaf-1 (like the shared point-to-point 172.16.200.0/31 network):
Leaf-1#show ip route VRF: default Codes: C - connected, S - static, K - kernel, O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1, E2 - OSPF external type 2, N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary, NG - Nexthop Group Static Route, V - VXLAN Control Service, DH - DHCP client installed default route, M - Martian Gateway of last resort is not set O 172.16.0.1/32 [110/20] via 172.16.200.1, Ethernet2 C 172.16.0.3/32 is directly connected, Loopback0 C 172.16.112.0/24 is directly connected, Vlan12 C 172.16.200.0/31 is directly connected, Ethernet2
… and then if we look at the IP routing table on Spine-1, we see that Spine-1 has learned the Loopback0 (or router-id) of Leaf-1 via OSPF as well as the IP subnet directly connected to Leaf-1 but not directly connected/visible to Spine-1 (172.16.112.0/24):
Spine-1#show ip route VRF: default Codes: C - connected, S - static, K - kernel, O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1, E2 - OSPF external type 2, N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary, NG - Nexthop Group Static Route, V - VXLAN Control Service, DH - DHCP client installed default route, M - Martian Gateway of last resort is not set C 172.16.0.1/32 is directly connected, Loopback0 O 172.16.0.3/32 [110/20] via 172.16.200.0, Ethernet2 O 172.16.112.0/24 [110/20] via 172.16.200.0, Ethernet2 C 172.16.200.0/31 is directly connected, Ethernet2
This is just a tip of the iceberg into the world of OSPF. The goal here was to give you a nice, easy starting point to become your own L3 Grandmaster.
NOTE: With exception to the interface numbering syntax (which I’ve simplified here for use in vEOS), these configurations were tested on Arista 7020R, 7504R, & 7508R (where both 7500 series modular switches were outfitted with the 7500R2-36CQ (Jericho+) linecards) under EOS 4.22.3M. Please also be aware that if you try this on your own with an EOS version of 4.23.0 or higher, additional OSPF commands (not used in this article) may have had some minor syntax changes: https://www.arista.com/en/support/advisories-notices/fieldnotices/7097-field-notice-39