Re: [j-nsp] RSVP hidden routes in inet.0

[Misak Khachatryan via juniper-nsp]

OK,

Seems I understood it. Look like igp shortcut for keeping rsvp signaling going. 
That's why routes in inet.0

Thanks everyone for useful comments.


On Mon, 11 Dec 2023, 21:57 Misak Khachatryan via juniper-nsp, 
mailto:juniper-nsp@puck.nether.net>> wrote:
The most annoying thing is that this is inet.0 table, not inet.3

Best regards,
Misak Khachatryan,

On Mon, Dec 11, 2023 at 7:30 PM Tom Beecher 
mailto:beec...@beecher.cc><mailto:beec...@beecher.cc<mailto:beec...@beecher.cc>>>
 wrote:
This is correct, they exist for the bypass LSPs.

I wouldn't characterize it as a dirty hack though. RFC4090 fast reroute 
requires the backup pathways to be pre-computed for a sub-10ms switchover. You 
put an export policy in place to make sure all labels (including bypass) are in 
the FIB already. Once a tear event occurs, the hidden RSVP route is just 
flipped to active, and LSPs using that /32 start pushing the bypass label on 
the stack. Since that label is already in the FIB, it just works from there.

On Mon, Dec 11, 2023 at 9:27 AM Michael Hare via juniper-nsp 
mailto:juniper-nsp@puck.nether.net><mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>>>
 wrote:
Hi Misak,

I think what you're seeing is normal for protection LSPs, "dirty hack on the 
control plane side", but I'm looking forward to be humbled on this list that my 
conclusion is incorrect.

We use "ldp interface link-protection dynamic-rsvp-lsp" and for all my bypass 
LSPs, 'show route hidden table inet.3 detail' tells me

Label-switched-path et-0/1/0.3402:BypassLSP->143.235.32.2
  ...
State: 
Inactive reason: Unusable path

I agree this is disconcerting if you are trying to get hidden routes to be 
zero, but there are other normal reasons for routes to be hidden such as 
rejection by bgp import policy.  Better IMHO to focus instead [or additionally] 
on " show route resolution unresolved "

-Michael

> -Original Message-
> From: juniper-nsp 
> mailto:juniper-nsp-boun...@puck.nether.net><mailto:juniper-nsp-boun...@puck.nether.net<mailto:juniper-nsp-boun...@puck.nether.net>>>
>  On Behalf Of
> Misak Khachatryan via juniper-nsp
> Sent: Monday, December 11, 2023 7:03 AM
> To: 
> juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net><mailto:juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>>
> Subject: [j-nsp] RSVP hidden routes in inet.0
>
> Hello,
>
> Recently I implemented RSVP in my network, nothing so fancy - automesh and
> autobandwidth with node-link protection.
>
> By doing final review i saw output of show route summary:
>
> inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
>   Direct:  6 routes,  5 active
>Local:  5 routes,  5 active
> OSPF:265 routes,264 active
> RSVP: 21 routes,  0 active
>  LDP:  1 routes,  1 active
>
> It is very curious for me why I see hidden RSVP routes in inet.0. It seems
> somehow related to bypass LSP's and how Juniper organises it. Here they are:
>
> > show route protocol rsvp table inet.0 hidden
>
> inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
>
> 10.255.0.21/32<http://10.255.0.21/32><http://10.255.0.21/32><http://10.255.0.21/32>
>   [RSVP] 01:11:54, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.21
> 10.255.0.29/32<http://10.255.0.29/32><http://10.255.0.29/32><http://10.255.0.29/32>
>   [RSVP] 1d 10:26:25, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.29
> 10.255.0.33/32<http://10.255.0.33/32><http://10.255.0.33/32><http://10.255.0.33/32>
>   [RSVP] 1d 10:26:25, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.33
> 10.255.0.38/32<http://10.255.0.38/32><http://10.255.0.38/32><http://10.255.0.38/32>
>   [RSVP] 1d 09:32:03, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.38
> 10.255.0.70/32<http://10.255.0.70/32><http://10.255.0.70/32><http://10.255.0.70/32>
>   [RSVP] 04:53:42, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.226->10.255.0.70
> 10.255.0.73/32<http://10.255.0.73/32><http://10.255.0.73/32><h

Re: [j-nsp] RSVP hidden routes in inet.0

[Misak Khachatryan via juniper-nsp]

The most annoying thing is that this is inet.0 table, not inet.3

Best regards,
Misak Khachatryan,

On Mon, Dec 11, 2023 at 7:30 PM Tom Beecher 
mailto:beec...@beecher.cc>> wrote:
This is correct, they exist for the bypass LSPs.

I wouldn't characterize it as a dirty hack though. RFC4090 fast reroute 
requires the backup pathways to be pre-computed for a sub-10ms switchover. You 
put an export policy in place to make sure all labels (including bypass) are in 
the FIB already. Once a tear event occurs, the hidden RSVP route is just 
flipped to active, and LSPs using that /32 start pushing the bypass label on 
the stack. Since that label is already in the FIB, it just works from there.

On Mon, Dec 11, 2023 at 9:27 AM Michael Hare via juniper-nsp 
mailto:juniper-nsp@puck.nether.net>> wrote:
Hi Misak,

I think what you're seeing is normal for protection LSPs, "dirty hack on the 
control plane side", but I'm looking forward to be humbled on this list that my 
conclusion is incorrect.

We use "ldp interface link-protection dynamic-rsvp-lsp" and for all my bypass 
LSPs, 'show route hidden table inet.3 detail' tells me

Label-switched-path et-0/1/0.3402:BypassLSP->143.235.32.2
  ...
State: 
Inactive reason: Unusable path

I agree this is disconcerting if you are trying to get hidden routes to be 
zero, but there are other normal reasons for routes to be hidden such as 
rejection by bgp import policy.  Better IMHO to focus instead [or additionally] 
on " show route resolution unresolved "

-Michael

> -Original Message-
> From: juniper-nsp 
> mailto:juniper-nsp-boun...@puck.nether.net>>
>  On Behalf Of
> Misak Khachatryan via juniper-nsp
> Sent: Monday, December 11, 2023 7:03 AM
> To: juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
> Subject: [j-nsp] RSVP hidden routes in inet.0
>
> Hello,
>
> Recently I implemented RSVP in my network, nothing so fancy - automesh and
> autobandwidth with node-link protection.
>
> By doing final review i saw output of show route summary:
>
> inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
>   Direct:  6 routes,  5 active
>Local:  5 routes,  5 active
> OSPF:265 routes,264 active
> RSVP: 21 routes,  0 active
>  LDP:  1 routes,  1 active
>
> It is very curious for me why I see hidden RSVP routes in inet.0. It seems
> somehow related to bypass LSP's and how Juniper organises it. Here they are:
>
> > show route protocol rsvp table inet.0 hidden
>
> inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
>
> 10.255.0.21/32<http://10.255.0.21/32><http://10.255.0.21/32>  [RSVP] 
> 01:11:54, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.21
> 10.255.0.29/32<http://10.255.0.29/32><http://10.255.0.29/32>  [RSVP] 1d 
> 10:26:25, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.29
> 10.255.0.33/32<http://10.255.0.33/32><http://10.255.0.33/32>  [RSVP] 1d 
> 10:26:25, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.33
> 10.255.0.38/32<http://10.255.0.38/32><http://10.255.0.38/32>  [RSVP] 1d 
> 09:32:03, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.38
> 10.255.0.70/32<http://10.255.0.70/32><http://10.255.0.70/32>  [RSVP] 
> 04:53:42, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.226->10.255.0.70
> 10.255.0.73/32<http://10.255.0.73/32><http://10.255.0.73/32>  [RSVP] 1d 
> 10:26:21, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.73
> 10.255.0.122/32<http://10.255.0.122/32><http://10.255.0.122/32> [RSVP] 1d 
> 10:26:21, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.122
> 10.255.0.126/32<http://10.255.0.126/32><http://10.255.0.126/32> [RSVP] 1d 
> 10:26:41, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.126
> 10.255.0.134/32<http://10.255.0.134/32><http://10.255.0.134/32> [RSVP] 1d 
> 05:2

Re: [j-nsp] RSVP hidden routes in inet.0

[Tom Beecher via juniper-nsp]

This is correct, they exist for the bypass LSPs.

I wouldn't characterize it as a dirty hack though. RFC4090 fast reroute
requires the backup pathways to be pre-computed for a sub-10ms switchover.
You put an export policy in place to make sure all labels (including
bypass) are in the FIB already. Once a tear event occurs, the hidden RSVP
route is just flipped to active, and LSPs using that /32 start pushing the
bypass label on the stack. Since that label is already in the FIB, it just
works from there.

On Mon, Dec 11, 2023 at 9:27 AM Michael Hare via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hi Misak,
>
> I think what you're seeing is normal for protection LSPs, "dirty hack on
> the control plane side", but I'm looking forward to be humbled on this list
> that my conclusion is incorrect.
>
> We use "ldp interface link-protection dynamic-rsvp-lsp" and for all my
> bypass LSPs, 'show route hidden table inet.3 detail' tells me
>
> Label-switched-path et-0/1/0.3402:BypassLSP->143.235.32.2
>   ...
> State: 
> Inactive reason: Unusable path
>
> I agree this is disconcerting if you are trying to get hidden routes to be
> zero, but there are other normal reasons for routes to be hidden such as
> rejection by bgp import policy.  Better IMHO to focus instead [or
> additionally] on " show route resolution unresolved "
>
> -Michael
>
> > -Original Message-
> > From: juniper-nsp  On Behalf Of
> > Misak Khachatryan via juniper-nsp
> > Sent: Monday, December 11, 2023 7:03 AM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] RSVP hidden routes in inet.0
> >
> > Hello,
> >
> > Recently I implemented RSVP in my network, nothing so fancy - automesh
> and
> > autobandwidth with node-link protection.
> >
> > By doing final review i saw output of show route summary:
> >
> > inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
> >   Direct:  6 routes,  5 active
> >Local:  5 routes,  5 active
> > OSPF:265 routes,264 active
> > RSVP: 21 routes,  0 active
> >  LDP:  1 routes,  1 active
> >
> > It is very curious for me why I see hidden RSVP routes in inet.0. It
> seems
> > somehow related to bypass LSP's and how Juniper organises it. Here they
> are:
> >
> > > show route protocol rsvp table inet.0 hidden
> >
> > inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
> > @ = Routing Use Only, # = Forwarding Use Only
> > + = Active Route, - = Last Active, * = Both
> >
> > 10.255.0.21/32<http://10.255.0.21/32>  [RSVP] 01:11:54, metric 1
> > >  to 10.255.0.226 via ae1.7, label-switched-path
> Bypass-
> > >10.255.0.222->10.255.0.21
> > 10.255.0.29/32<http://10.255.0.29/32>  [RSVP] 1d 10:26:25, metric 1
> > >  to 10.255.0.226 via ae1.7, label-switched-path
> Bypass-
> > >10.255.0.230->10.255.0.29
> > 10.255.0.33/32<http://10.255.0.33/32>  [RSVP] 1d 10:26:25, metric 1
> > >  to 10.255.0.226 via ae1.7, label-switched-path
> Bypass-
> > >10.255.0.230->10.255.0.33
> > 10.255.0.38/32<http://10.255.0.38/32>  [RSVP] 1d 09:32:03, metric 1
> > >  to 10.255.0.230 via ae4.7, label-switched-path
> Bypass-
> > >10.255.0.222->10.255.0.38
> > 10.255.0.70/32<http://10.255.0.70/32>  [RSVP] 04:53:42, metric 1
> > >  to 10.255.0.230 via ae4.7, label-switched-path
> Bypass-
> > >10.255.0.226->10.255.0.70
> > 10.255.0.73/32<http://10.255.0.73/32>  [RSVP] 1d 10:26:21, metric 1
> > >  to 10.255.0.226 via ae1.7, label-switched-path
> Bypass-
> > >10.255.0.230->10.255.0.73
> > 10.255.0.122/32<http://10.255.0.122/32> [RSVP] 1d 10:26:21, metric 1
> > >  to 10.255.0.226 via ae1.7, label-switched-path
> Bypass-
> > >10.255.0.230->10.255.0.122
> > 10.255.0.126/32<http://10.255.0.126/32> [RSVP] 1d 10:26:41, metric 1
> > >  to 10.255.0.226 via ae1.7, label-switched-path
> Bypass-
> > >10.255.0.230->10.255.0.126
> > 10.255.0.134/32<http://10.255.0.134/32> [RSVP] 1d 05:27:20, metric 1
> > >  to 10.255.0.230 via ae4.7, label-switched-path
> Bypass-
> > >10.255.0.222->10.255.0.134
> > 10.255.0.174/32<http://1

Re: [j-nsp] RSVP hidden routes in inet.0

[Michael Hare via juniper-nsp]

Hi Misak,

I think what you're seeing is normal for protection LSPs, "dirty hack on the 
control plane side", but I'm looking forward to be humbled on this list that my 
conclusion is incorrect.

We use "ldp interface link-protection dynamic-rsvp-lsp" and for all my bypass 
LSPs, 'show route hidden table inet.3 detail' tells me

Label-switched-path et-0/1/0.3402:BypassLSP->143.235.32.2
  ...
State: 
Inactive reason: Unusable path

I agree this is disconcerting if you are trying to get hidden routes to be 
zero, but there are other normal reasons for routes to be hidden such as 
rejection by bgp import policy.  Better IMHO to focus instead [or additionally] 
on " show route resolution unresolved "

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Misak Khachatryan via juniper-nsp
> Sent: Monday, December 11, 2023 7:03 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] RSVP hidden routes in inet.0
> 
> Hello,
> 
> Recently I implemented RSVP in my network, nothing so fancy - automesh and
> autobandwidth with node-link protection.
> 
> By doing final review i saw output of show route summary:
> 
> inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
>   Direct:  6 routes,  5 active
>Local:  5 routes,  5 active
> OSPF:265 routes,264 active
> RSVP: 21 routes,  0 active
>  LDP:  1 routes,  1 active
> 
> It is very curious for me why I see hidden RSVP routes in inet.0. It seems
> somehow related to bypass LSP's and how Juniper organises it. Here they are:
> 
> > show route protocol rsvp table inet.0 hidden
> 
> inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> 
> 10.255.0.21/32<http://10.255.0.21/32>  [RSVP] 01:11:54, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.21
> 10.255.0.29/32<http://10.255.0.29/32>  [RSVP] 1d 10:26:25, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.29
> 10.255.0.33/32<http://10.255.0.33/32>  [RSVP] 1d 10:26:25, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.33
> 10.255.0.38/32<http://10.255.0.38/32>  [RSVP] 1d 09:32:03, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.38
> 10.255.0.70/32<http://10.255.0.70/32>  [RSVP] 04:53:42, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.226->10.255.0.70
> 10.255.0.73/32<http://10.255.0.73/32>  [RSVP] 1d 10:26:21, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.73
> 10.255.0.122/32<http://10.255.0.122/32> [RSVP] 1d 10:26:21, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.122
> 10.255.0.126/32<http://10.255.0.126/32> [RSVP] 1d 10:26:41, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.126
> 10.255.0.134/32<http://10.255.0.134/32> [RSVP] 1d 05:27:20, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.134
> 10.255.0.174/32<http://10.255.0.174/32> [RSVP] 1d 07:19:25, metric 1
> >  to 10.255.0.230 via ae4.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.174
> 10.255.0.181/32<http://10.255.0.181/32> [RSVP] 1d 10:26:19, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.181
> 10.255.0.185/32<http://10.255.0.185/32> [RSVP] 1d 10:26:19, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.230->10.255.0.185
> 10.255.0.201/32<http://10.255.0.201/32> [RSVP] 1d 10:17:37, metric 1
> >  to 10.255.0.226 via ae1.7, label-switched-path Bypass-
> >10.255.0.222->10.255.0.201
> 10.255.0.214/32<http://10.255.0.214/32> [RSVP] 03:16:59, metric 1
> >  to 10.255.0.222 via ae0.7, label-switched-path Bypass-
> >10.255.0.226->10.255.0.214
> 10.255.0.222/32<http:/

[j-nsp] RSVP hidden routes in inet.0

[Misak Khachatryan via juniper-nsp]

Hello,

Recently I implemented RSVP in my network, nothing so fancy - automesh and 
autobandwidth with node-link protection.

By doing final review i saw output of show route summary:

inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
  Direct:  6 routes,  5 active
   Local:  5 routes,  5 active
OSPF:265 routes,264 active
RSVP: 21 routes,  0 active
 LDP:  1 routes,  1 active

It is very curious for me why I see hidden RSVP routes in inet.0. It seems 
somehow related to bypass LSP's and how Juniper organises it. Here they are:

> show route protocol rsvp table inet.0 hidden

inet.0: 296 destinations, 298 routes (275 active, 0 holddown, 21 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

10.255.0.21/32  [RSVP] 01:11:54, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.222->10.255.0.21
10.255.0.29/32  [RSVP] 1d 10:26:25, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.0.29
10.255.0.33/32  [RSVP] 1d 10:26:25, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.0.33
10.255.0.38/32  [RSVP] 1d 09:32:03, metric 1
>  to 10.255.0.230 via ae4.7, label-switched-path 
Bypass->10.255.0.222->10.255.0.38
10.255.0.70/32  [RSVP] 04:53:42, metric 1
>  to 10.255.0.230 via ae4.7, label-switched-path 
Bypass->10.255.0.226->10.255.0.70
10.255.0.73/32  [RSVP] 1d 10:26:21, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.0.73
10.255.0.122/32 [RSVP] 1d 10:26:21, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.0.122
10.255.0.126/32 [RSVP] 1d 10:26:41, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.0.126
10.255.0.134/32 [RSVP] 1d 05:27:20, metric 1
>  to 10.255.0.230 via ae4.7, label-switched-path 
Bypass->10.255.0.222->10.255.0.134
10.255.0.174/32 [RSVP] 1d 07:19:25, metric 1
>  to 10.255.0.230 via ae4.7, label-switched-path 
Bypass->10.255.0.222->10.255.0.174
10.255.0.181/32 [RSVP] 1d 10:26:19, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.0.181
10.255.0.185/32 [RSVP] 1d 10:26:19, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.0.185
10.255.0.201/32 [RSVP] 1d 10:17:37, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.222->10.255.0.201
10.255.0.214/32 [RSVP] 03:16:59, metric 1
>  to 10.255.0.222 via ae0.7, label-switched-path 
Bypass->10.255.0.226->10.255.0.214
10.255.0.222/32 [RSVP] 1d 10:17:34, metric 1
>  to 10.255.0.230 via ae4.7, label-switched-path 
Bypass->10.255.0.222
10.255.0.226/32 [RSVP] 02:45:52, metric 1
>  to 10.255.0.222 via ae0.7, label-switched-path 
Bypass->10.255.0.226
10.255.0.230/32 [RSVP] 1d 10:26:17, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230
10.255.25.69/32 [RSVP] 1d 10:26:17, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.25.69
10.255.25.73/32 [RSVP] 1d 10:26:15, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.25.73
10.255.25.150/32[RSVP] 1d 10:26:50, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.25.150
10.255.25.158/32[RSVP] 1d 10:26:50, metric 1
>  to 10.255.0.226 via ae1.7, label-switched-path 
Bypass->10.255.0.230->10.255.25.158

The /32 routes here are the IPs of adjacent routers. The only thing I found in 
inet is that Juniper does something similar with LDP over RSVP.

It seems like some dirty hack on the control plane side, but I will be very 
grateful if someone can explain.

Best regards,
Misak Khachatryan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net