When I first started configuring MPLS on Juniper routers, I came across the strange and mysterious inet.3 table.  What could it possibly be?  When I worked in Cisco TAC I handled hundreds of MPLS VPN cases, but I never had encountered anything quite like inet.3 in IOS land.  As I researched inet.3 I found the documentation was sparse and confusing, so when I finally came to understand its purpose I decided to create a clear explanation for those who are searching in vain.  I will focus on the basics of how inet.3 works, leaving details of its use for later posts.

For this lab I will use my standard MPLS topology, which I am borrowing from the excellent book This Week:  Deploying MPLS from my employer, Juniper networks, with some slight modifications.  For this example, I have already configured an IGP (ISIS) between the core routers, as well as MPLS and RSVP.
Mpls topo
We begin with no label switched paths (LSPs) on R2 at all:

Let’s also look at the inet.3 table as it stands right now:

For this example, I will create an LSP from r2 over to R9.  A simple LSP is easy to set up by pointing it towards the R9 loopback address:

This command defines the LSP, and we can now see it active on r2:

Note:  r2 had no RSVP neighbors prior to activating the LSP.  This is normal.  You will not see an adjacency until there is an active LSP.

Our previously empty inet.3 table now has a route in it:

There are a few things to note here:

  1. R3 is the next hop.
  2. A label of 300288 will be pushed, so any traffic using this route will be label switched.
  3. The destination is the loopback of r9.

Stepping back a bit, we need to consider the following question:  If we have established an LSP, how exactly do we get traffic into it?  In other words, the router normally considers the IP routing table to determine the next hop to forward traffic to for a particular destination, so under what circumstances would it look in inet.3?
 
To answer this, I have set up an iBGP session between r2 and r9, and I have advertised one of r9’s interfaces (200.9.9.0/24, which is not in the IGP) into BGP.  A traceroute from r2 immediately shows the effect:

Note: It is interesting that this particular path was chosen, but it is not important to this particular discussion.
Here we can see that the simple traceroute has a label imposed on it, the same label we saw in inet.3, and that traffic entered the LSP automatically.  With the LSP established, the IBGP route took us into the LSP without any further configuration at all. Let’s examine further why this happened.  The following is the route entry on r2 for our destination of 200.9.9.0/24:

Remember that BGP forwards traffic by looking up the next hop recursively.  The important thing to note here is that the protocol next hop is 200.255.255.9, which is the loopback0.0 address of r9.  This starts us in the direction of our next hop, but because this is not a directly attached network, we need to resolve how we actually get to the next hop.  BGP has a couple of options:

BGP has two possible routes to consider.  In the inet.0 table we have an ISIS route with a preference of 15.  But in the inet.3 table, we have an RSVP route with a preference of 7.  There are three important points to keep in mind here:

  • BGP will consider the routes in the two tables as though they were in the same table, going with the lowest preference.
  • If the preferences were equal, Junos prefers inet.3
  • Only BGP uses inet.3.  No other protocol considers it.

Note:  In Junos, “preference” is the equivalent to “administrative distance” in Cisco IOS.

Basic preference rules cause BGP to use inet.3 for its next hop resolution, and the inet.3 route, which was built by RSVP, will send the traffic into the LSP.
What would happen if we learned the loopback with a lower preference than RSVP?  We can test this by using a static route instead of ISIS:

The lowest preference route is now the static route, although the inet.3 route is still there.  Will this preempt the RSVP route and direct traffic through normal IP routing instead of MPLS?  Let’s rerun our traceroute:

We can see that, indeed, the traffic does avoids the LSP.  Instead, it goes to r3 via normal IP routing.  Because we didn’t advertise the 200.9.9.0/24 network into the IGP, and we are only running BGP between r2 and r9, r3 knows nothing of the route and drops the traffic.

In summary, the following are the important points to remember about inet.3:

  • inet.3 is used by BGP to recursively resolve its next hop router.
  • inet.3 is populated by MPLS protocols.
  • inet.3 routes point to LSPs, and will cause a label push operation.
  • The inet.3 route will be considered by BGP only if its preference is lower than an equivalent route in inet.0.