SubnetZero

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.

We begin with no label switched paths (LSPs) on R2 at all:

root@r2> show mpls lsp
 
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
 
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
 
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

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

root@r2> show route table inet.3
 
root@r2>

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:

[edit]
 
root@r2# set protocols mpls lsp r2-to-r9 to 200.255.255.9

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

root@r2# run show mpls lsp
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
200.255.255.9   200.255.255.2   Up     0 *                      r2-to-r9

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:

root@r2> show route table inet.3 detail
 
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
200.255.255.9/32 (1 entry, 1 announced)
State: <FlashAll>
*RSVP   Preference: 7/1
Next hop type: Router
Address: 0x9298568
Next-hop reference count: 5
Next hop: 200.1.23.3 via ge-0/0/2.0 weight 0x1, selected
Label-switched-path r2-to-r9
Label operation: Push 300288
Label TTL action: prop-ttl
Session Id: 0x1
State: <Active Int>
Age: 5:04       Metric: 30
Validation State: unverified
Task: RSVP
Announcement bits (1): 1-Resolve tree 1
AS path: I


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:

traceroute to 200.9.9.9 (200.9.9.9), 30 hops max, 40 byte packets
1  200.1.23.3 (200.1.23.3)  14.953 ms  19.146 ms  20.115 ms
MPLS Label=300288 CoS=0 TTL=1 S=1
2  200.1.35.5 (200.1.35.5)  20.124 ms  19.381 ms  20.141 ms
MPLS Label=300640 CoS=0 TTL=1 S=1
3  200.1.56.6 (200.1.56.6)  25.098 ms  29.589 ms  30.074 ms
MPLS Label=300128 CoS=0 TTL=1 S=1
4  200.1.68.8 (200.1.68.8)  30.176 ms  29.526 ms  30.140 ms
MPLS Label=300224 CoS=0 TTL=1 S=1
5  200.9.9.9 (200.9.9.9)  40.275 ms  39.379 ms  40.171 ms

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:

inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
200.9.9.0/24 (1 entry, 1 announced)
*BGP    Preference: 170/-101
Next hop type: Indirect
Address: 0x9298698
Next-hop reference count: 3
Source: 200.255.255.9
Next hop type: Router, Next hop index: 553
Next hop: 200.1.23.3 via ge-0/0/2.0 weight 0x1, selected
Label-switched-path r2-to-r9
Label operation: Push 300288
Label TTL action: prop-ttl
Session Id: 0x1
Protocol next hop: 200.255.255.9
Indirect next hop: 9544000 262142 INH Session ID: 0x3
State: <Active Int Ext>
Local AS:   100 Peer AS:   100
Age: 11:05      Metric2: 30
Validation State: unverified
Task: BGP_100.200.255.255.9+179
Announcement bits (2): 0-KRT 5-Resolve tree 4
AS path: I
Accepted
Localpref: 100
Router ID: 200.255.255.9

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:

root@r2> show route 200.255.255.9
 
inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
200.255.255.9/32   *[IS-IS/15] 02:55:02, metric 30
> to 200.1.23.3 via ge-0/0/2.0
 
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
200.255.255.9/32   *[RSVP/7/1] 00:05:48, metric 30
> to 200.1.23.3 via ge-0/0/2.0, label-switched-path r2-to-r9


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:

root@r2# set routing-options static route 200.255.255.9/32 next-hop 200.1.23.3
 
[edit]
root@r2# commit
commit complete
 
[edit]
root@r2# run show route 200.255.255.9
 
inet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
200.255.255.9/32   *[Static/5] 00:00:07
> to 200.1.23.3 via ge-0/0/2.0
[IS-IS/15] 03:02:09, metric 30
> to 200.1.23.3 via ge-0/0/2.0
 
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
200.255.255.9/32   *[RSVP/7/1] 00:00:02, metric 65535
> to 200.1.23.3 via ge-0/0/2.0, label-switched-path r2-to-r9

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:

root@r2# run traceroute 200.9.9.9
traceroute to 200.9.9.9 (200.9.9.9), 30 hops max, 40 byte packets
1  200.1.23.3 (200.1.23.3)  24.946 ms !N  29.036 ms !N  28.544 ms !N
 
[edit]
root@r2# run ping 200.9.9.9
PING 200.9.9.9 (200.9.9.9): 56 data bytes
36 bytes from 200.1.23.3: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 638d   0 0000  40  01 6706 200.1.23.2  200.9.9.9

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.