Yes, we are going to talk about destination routing. I know it sounds boring and archaic, and it is. But it is also necessary to contrast against another topic that I intend to introduce. As I scour PacketU, I see a substantial number of page views on articles about segmentation and VRFs. One thing I often tell my customers is that once a VRF-lite implementation reaches a certain scale, the configuration can become unwieldy.
This article is a first in a series where we will discuss MPLS. This technology enables VPNv4 and is a common method of networking. MPLS can connect VRFs without compromising their segmentation characteristics. In this first article, we are going to examine traditional destination-based routing. This is meant to nail down some of the typical behavior of an IPv4 routed network. These characteristics will not go away entirely, but it is important to understand how routing changes as we introduce label switching concepts.
Throughout this series, we will use a common topology. In later articles, we will expand as necessary to introduce the relevant topics.
To illustrate a point, I have pre-configured OSPF on all links and loopback 0 of all routers. In a minute, I will bring up an iBGP session between the edge nodes, configure another loopback interface and advertise it via BGP only.
Edge1 Base Configuration
interface GigabitEthernet2 description to P1 ip address 10.100.1.2 255.255.255.0 ip ospf cost 1 ! interface GigabitEthernet3 description to P3 ip address 10.100.3.2 255.255.255.0 ip ospf cost 1 ! interface Loopback0 description Loopback ip address 10.10.10.10 255.255.255.255 end router ospf 1 network 10.10.10.10 0.0.0.0 area 0 network 10.100.0.0 0.0.255.255 area 0
OSPF is enabled and properly configured on R1 through R4. Edge2 is configured similarly to Edge1. There is nothing special in the configuration and everything is in the OSPF Backbone area.
From Edge2, I can ping Edge1’s loopback (10.10.10.10)
Edge2#ping 10.10.10.10 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 19/27/40 ms
All routing is done by doing a destination based lookup of 10.10.10.10 at each hop that sees that packet. The same thing occurs for the ICMP ECHO-REPLY packets that are returning.
I want to set the stage for some critical thinking by creating an iBGP session between Edge1 and Edge2. I’ll go ahead and allow the respective loopbacks into the BGP RIB as well.
Edge1 BGP Base Configuration
router bgp 1 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 184.108.40.206 remote-as 1 neighbor 220.127.116.11 update-source Loopback0 ! address-family ipv4 network 10.10.10.10 mask 255.255.255.255 neighbor 18.104.22.168 activate exit-address-family ! Edge1#show ip bgp | inc 10.10.10.10 BGP table version is 4, local router ID is 10.10.10.10 *> 10.10.10.10/32 0.0.0.0 0 32768 i
Edge2 BGP Base Configuration
router bgp 1 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 10.10.10.10 remote-as 1 neighbor 10.10.10.10 update-source Loopback0 ! address-family ipv4 network 22.214.171.124 mask 255.255.255.255 neighbor 10.10.10.10 activate exit-address-family ! Edge2#show ip bgp | inc 20.20 BGP table version is 5, local router ID is 126.96.36.199 *> 188.8.131.52/32 0.0.0.0 0 32768 i
At this point, Edge2 can still ping Edge1.
Edge2#ping 10.10.10.10 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 3/35/57 ms
Now I will add another loopback to Edge1 and include it in the BGP Process.
interface Loopback1 ip address 220.127.116.11 255.255.255.255 ! router bgp 1 address-family ipv4 network 18.104.22.168 mask 255.255.255.255
Now, I have the following questions. For this exercise, assume we are running a modern version of IOS.
- Will 22.214.171.124 be in the BGP RIB at Edge2?
- Will 126.96.36.199 be in the RIB (route table) at Edge2?
- Will 188.8.131.52 be reachable from Edge2?
- For any of these that would be answered as no–why did they fail?
So let’s just take a look at the first three of these questions by jumping straight to Edge2.
Edge2#show ip bgp | inc 184.108.40.206 *>i 220.127.116.11/32 10.10.10.10 0 100 0 i //Question 1 is obviously YES Edge2#show ip route | inc 18.104.22.168 B 22.214.171.124 [200/0] via 10.10.10.10, 00:06:19 //Question 2 is also YES Edge2#ping 126.96.36.199 sour loop0 Sending 5, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 U.U.U Success rate is 0 percent (0/5) //Question 3 is answered as NO
Something to notice here is that 220.127.116.11 was learned by BGP. The next hop is 10.10.10.10 so there would be a recursive lookup to that destination. That will succeed and load-balance to R2 and R4. It is important to consider what R2 and R4 might do with a packet being destination routed to 18.104.22.168. Since we didn’t enable BGP on those and create a full mesh of iBGP (or configure a route reflector), there are no BGP routes on R2 and R4 (or R1 and R3). We also did not pull the 22.214.171.124/32 network into the OSPF process. R2 and R4 have no route to this destination.
R2#show ip route 126.96.36.199 % Network not in table
It is worth mentioning that Edge2 allowed the installation of this route because BGP Sync is disabled by default in current versions. That is the specific reason why I said an assumption should be made around a modern version of IOS. Enabling BGP sync will prevent this route from being installed on Edge2 because OSPF is unaware of that prefix.
Example – Enabling BGP Sync (disabled by default)
Edge2(config)#router bgp 1 Edge2(config-router)#sync Edge2(config-router)#exit Edge2(config)#exit Edge2#clear ip bgp * Edge2#show ip route 188.8.131.52 % Network not in table Edge2#show ip bgp 184.108.40.206 BGP routing table entry for 220.127.116.11/32, version 0 Paths: (1 available, no best path) Flag: 0x4100 Not advertised to any peer Refresh Epoch 1 Local 10.10.10.10 (metric 4) from 10.10.10.10 (10.10.10.10) Origin IGP, metric 0, localpref 100, valid, internal, not synchronized rx pathid: 0, tx pathid: 0
So what are possible solutions to the problem of accessing 18.104.22.168 from Edge2? The following possibilities come to mind.
- Bring 22.214.171.124/32 natively into the OSPF Process
- Redistribute BGP into OSPF on Edge1
- Static or policy routing on R1-R4 (ughh, that’s duct tape)
- GRE (or other) transport tunnels
- Enable MPLS and make 10.10.10.10 (BGP next hop for 126.96.36.199 at Edge2) available via LSP over R1-R4.
The next article will look at the last option above. We will utilize MPLS to build a label switched path between Edge2 and Edge1.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This
may or may does not reflect the position of past, present or future employers.