8 mins read
RSVP – install option
1. Intro
By default, only /32 prefixes are installed in the inet.3 table. Using the install option, you can add additional prefixes to inet.3. By including the active parameter, the prefix is also added to the inet.0 table, which means that the IGP can also use this prefix. Remember that by default only BGP can use prefixes in the inet.3 table.
This is the topology we will be using to test the install feature:
And the starting config:
### R1 config:
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 17.0.0.1
set protocols bgp group iBGP family inet unicast
set protocols bgp group iBGP family inet-vpn unicast
set protocols bgp group iBGP neighbor 17.0.0.4
set protocols bgp group iBGP neighbor 17.0.0.7
set protocols mpls label-switched-path R1-to-R7 to 17.0.0.7
### R7 config:
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 17.0.0.7
set protocols bgp group iBGP family inet unicast
set protocols bgp group iBGP family inet-vpn unicast
set protocols bgp group iBGP neighbor 17.0.0.1
set protocols bgp group EBGP type external
set protocols bgp group EBGP export BGP-EXPORT
set protocols bgp group EBGP peer-as 64599
set protocols bgp group EBGP neighbor 17.7.9.9
set policy-options policy-statement BGP-EXPORT from route-filter 17.0.0.1/32 exact
set policy-options policy-statement BGP-EXPORT then accept
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 passive
### R9 config:
set protocols bgp group EBGP type external
set protocols bgp group EBGP export BGP-EXPORT
set protocols bgp group EBGP peer-as 64512
set protocols bgp group EBGP neighbor 17.7.9.7
set policy-options policy-statement BGP-EXPORT from route-filter 17.0.0.9/32 exact
set policy-options policy-statement BGP-EXPORT then accept2. R1 to R9 fails
This is a network with a BGP free core, so R1 to R9 ping fails on the P routers:
### We have a route to 17.0.0.9 :
root@R1# run show route 17.0.0.9
inet.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.9/32 *[BGP/170] 00:02:24, localpref 100, from 17.0.0.7
AS path: 64599 I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0
### We get this route from R7, which has no next-hop-self:
root@R1# run show route 17.0.0.9 extensive
inet.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)
17.0.0.9/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 17.0.0.9/32 -> {indirect(1048575)}
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x7bbe964
Next-hop reference count: 2, key opaque handle: 0x0, non-key opaque handle: 0x0
Kernel Table Id: 0
Source: 17.0.0.7
Next hop type: Router, Next hop index: 646
Next hop: 17.1.3.3 via ge-0/0/2.0, selected
Session Id: 147
Protocol next hop: 17.7.9.9
Indirect next hop: 0x791dbb8 1048575 INH Session ID: 383
State: <Active Int Ext>
Local AS: 64512 Peer AS: 64512
Age: 2:59 Metric2: 3001
Validation State: unverified
Task: BGP_64512.17.0.0.7
Announcement bits (2): 0-KRT 5-Resolve tree 4
AS path: 64599 I
Accepted
Localpref: 100
Router ID: 17.0.0.7
Thread: junos-main
Indirect next hops: 1
Protocol next hop: 17.7.9.9 Metric: 3001 ResolvState: Resolved
Indirect next hop: 0x791dbb8 1048575 INH Session ID: 383
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 17.1.3.3 via ge-0/0/2.0
Session Id: 147
17.7.9.0/24 Originating RIB: inet.0
Metric: 3001 Node path count: 1
Forwarding nexthops: 1
Next hop type: Router
Next hop: 17.1.3.3 via ge-0/0/2.0
Session Id: 147
### We see the BGP next hop via OSPF:
root@R1# run show route 17.7.9.9
inet.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.7.9.0/24 *[OSPF/10] 01:16:37, metric 3001
> to 17.1.3.3 via ge-0/0/2.0
### OSPF passive interface was configured on R7:
root@R7# show protocols ospf | match passive | display set
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 passive
### But ping is not working, R3 is responding with 'Destination Net Unreachable':
root@R1# run ping 17.0.0.9 source 17.0.0.1
PING 17.0.0.9 (17.0.0.9): 56 data bytes
36 bytes from 17.1.3.3: Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 a315 0 0000 40 01 b58a 17.0.0.1 17.0.0.9
[...]
^C
--- 17.0.0.9 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
### This is a BGP free core, so the P routers don't have the BGP prefixes (17.0.0.9):
root@R3# run show route 17.0.0.9
[edit]
root@R3#We could redistribute BGP routes in OSPF, but that is not really a good idea.
Instead, we should use MPLS, but we will not extend MPLS/RSVP beyond the R7 router. This is where the install feature comes handy.
3. install feature
Typically only Loopbacks are installed in the inet.3 table, how to tell the router to use MPLS for prefixes to R9? It is rather simple actually, configure the install feature on the RSVP LSP.
We are using inet.3 for BGP next-hop resolution, so we need to add the next-hop to R9: 17.7.9.9.
### Let's add the full subnet to inet.3:
root@R1# set protocols mpls label-switched-path R1-to-R7 install 17.7.9.0/24
[edit]
root@R1# show | compare
[edit protocols mpls label-switched-path R1-to-R7]
+ install 17.7.9.0/24;
[edit]
root@R1# commit
commit complete
### Now we have that subnet in the inet.3 table:
root@R1# run show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.7/32 *[RSVP/7/1] 00:00:04, metric 3000
> to 17.1.3.3 via ge-0/0/2.0, label-switched-path R1-to-R7
17.7.9.0/24 *[RSVP/7/1] 00:00:04, metric 3000
> to 17.1.3.3 via ge-0/0/2.0, label-switched-path R1-to-R7
### Our ping works now:
root@R1# run ping 17.0.0.9 source 17.0.0.1
PING 17.0.0.9 (17.0.0.9): 56 data bytes
64 bytes from 17.0.0.9: icmp_seq=0 ttl=61 time=5.710 ms
64 bytes from 17.0.0.9: icmp_seq=1 ttl=61 time=5.420 ms
64 bytes from 17.0.0.9: icmp_seq=2 ttl=61 time=5.798 ms
^C
--- 17.0.0.9 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.420/5.643/5.798/0.161 msLet’s do some tcpdump captures to better understand what is happening:
### Capture on the R3-to-R6 link:
16:08:53.662357 MPLS (label 302880, exp 0, [S], ttl 63) IP 17.0.0.1 > 17.0.0.9: ICMP echo request, id 2574, seq 98, length 64
16:08:53.664501 IP 17.0.0.9 > 17.0.0.1: ICMP echo reply, id 2574, seq 98, length 64
### Capture on the R6-to-R7 link:
16:10:29.110227 IP 17.0.0.1 > 17.0.0.9: ICMP echo request, id 2574, seq 193, length 64
16:10:29.111662 IP 17.0.0.9 > 17.0.0.1: ICMP echo reply, id 2574, seq 193, length 64Note: we can even remove the passive OSPF interface on the R7 router and it will still work.
### In inet.0 table, R1 learns the 17.7.9.7/24 route form R7:
root@R1# run show route 17.7.9.7/24
inet.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.7.9.0/24 *[OSPF/10] 21:08:39, metric 3001
> to 17.1.3.3 via ge-0/0/2.0
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.7.9.0/24 *[RSVP/7/1] 19:33:40, metric 3000
> to 17.1.3.3 via ge-0/0/2.0, label-switched-path R1-to-R7
### Remove the passive interface on R7:
root@R7# show | compare
[edit protocols ospf area 0.0.0.0]
- interface ge-0/0/4.0 {
- passive;
- }
[edit]
root@R7# commit
commit complete
### The prefix is no longer there in inet.0
### In inet.3 we still have the route because of the configured install option
root@R1# run show route 17.7.9.7/24
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.7.9.0/24 *[RSVP/7/1] 19:38:21, metric 3000
> to 17.1.3.3 via ge-0/0/2.0, label-switched-path R1-to-R7
### We still have connectivity:
root@R1# run ping 17.0.0.9 source 17.0.0.1
PING 17.0.0.9 (17.0.0.9): 56 data bytes
64 bytes from 17.0.0.9: icmp_seq=0 ttl=61 time=5.877 ms
64 bytes from 17.0.0.9: icmp_seq=1 ttl=61 time=6.353 ms
64 bytes from 17.0.0.9: icmp_seq=2 ttl=61 time=5.911 ms
^C
--- 17.0.0.9 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.877/6.047/6.353/0.217 ms4. active knob
### We can install the route in inet.0 (instead of inet.3) by configuring the 'active' knob:
root@R1# show | compare
[edit protocols mpls label-switched-path R1-to-R7 install 17.7.9.0/24]
+ active;
root@R1# commit
commit complete
### Now the route is in inet.0 instead of inet.3:
root@R1# run show route 17.7.9.7/24
inet.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.7.9.0/24 *[RSVP/7/1] 00:08:54, metric 3000
> to 17.1.3.3 via ge-0/0/2.0, label-switched-path R1-to-R7
### Ping still works:
root@R1# run ping 17.0.0.9 source 17.0.0.1
PING 17.0.0.9 (17.0.0.9): 56 data bytes
64 bytes from 17.0.0.9: icmp_seq=0 ttl=61 time=5.311 ms
64 bytes from 17.0.0.9: icmp_seq=1 ttl=61 time=6.841 ms
^C
--- 17.0.0.9 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.311/6.076/6.841/0.765 ms5. Conclusion
This is really interesting, in the R1-to-R9 direction:
- traffic is using the R1-to-R7 LSP, hence the P routers are using labels to forward the ping
- we can see the penultimate hop popping that R6 is doing.
- R7-to-R9 unlabeled forwarding (in fact, family mpls is not even activate on the link)
In the R9-to-R1 direction:
- the full path is using unlabeled forwarding
- this is working because all core routers know how to reach R1
- not the case here, but in some scenarios we might need to use the install feature for the return traffic as well
External Resources: