MPLS Intro Series – Destination Routing

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 20.20.20.20 remote-as 1
 neighbor 20.20.20.20 update-source Loopback0
 !
 address-family ipv4
  network 10.10.10.10 mask 255.255.255.255
  neighbor 20.20.20.20 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 20.20.20.20 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 20.20.20.20
 *>   20.20.20.20/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 20.20.20.20
!!!!!
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.

Edge1

interface Loopback1
 ip address 1.0.1.1 255.255.255.255
!
router bgp 1
 address-family ipv4
 network 1.0.1.1 mask 255.255.255.255

Now, I have the following questions. For this exercise, assume we are running a modern version of IOS.

  1. Will 1.0.1.1 be in the BGP RIB at Edge2?
  2. Will 1.0.1.1 be in the RIB (route table) at Edge2?
  3. Will 1.0.1.1 be reachable from Edge2?
  4. 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 1.0.1.1
 *>i  1.0.1.1/32       10.10.10.10              0    100      0 i
//Question 1 is obviously YES

Edge2#show ip route | inc 1.0.1.1
B        1.0.1.1 [200/0] via 10.10.10.10, 00:06:19
//Question 2 is also YES

Edge2#ping 1.0.1.1 sour loop0
Sending 5, 100-byte ICMP Echos to 1.0.1.1, timeout is 2 seconds:
Packet sent with a source address of 20.20.20.20
U.U.U
Success rate is 0 percent (0/5)
//Question 3 is answered as NO

Something to notice here is that 1.0.1.1 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 1.0.1.1. 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 1.0.1.1/32 network into the OSPF process. R2 and R4 have no route to this destination.

R2#show ip route 1.0.1.1
% 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 1.0.1.1
% Network not in table
Edge2#show ip bgp 1.0.1.1
BGP routing table entry for 1.0.1.1/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 1.0.1.1 from Edge2? The following possibilities come to mind.

  1. Bring 1.0.1.1/32 natively into the OSPF Process
  2. Redistribute BGP into OSPF on Edge1
  3. Static or policy routing on R1-R4 (ughh, that’s duct tape)
  4. GRE (or other) transport tunnels
  5. Enable MPLS and make 10.10.10.10 (BGP next hop for 1.0.1.1 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.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design and tagged . Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.