[j-nsp] RSVP LSP inconsistency
David Ball
davidtball at gmail.com
Fri Jan 19 20:39:54 EST 2007
LSPs are indeed unidirectional, and as per my previous email, the
router on one side of an LSP (NCP-LSP-00820-022-001) thought the LSP
was up, while the router on the other side of the SAME LSP said it was
down. Therein lies my confusion.
mpls is enabled on the 10GigE interfaces (otherwise my LDP LSPs
wouldn't have been established). traceoptions for RSVP is set to
'packets' (though I have yet to figure out what the log messages in my
previous email are indicating), which I neglected to mention below.
Topology-wise, it's just the 2 T640s with a single 10GigE link
between them. OSPF, BGP and LDP are all learning routes from the
opposite router, and RSVP 'is' establishing a proper LSP from ROUTER1
to ROUTER2, but the ROUTER2 to ROUTER1 LSP is the problem. ROUTER1
thinks it's fine, but ROUTER2 doesn't.
Can't get to my configs at this time unfortunately, but the RSVP
LSPs are configured to build between loopback addresses (1.7.1.1 on
ROUTER1, 1.7.1.22 on ROUTER2), and both routers can see each others'
loopbacks. No admin-groups active, and the appropriate 10GigE
interfaces are specified in the RSVP, LDP and MPLS config sections on
both routers.
David
On 1/19/07, Michael Long <mlong at sactechgroup.com> wrote:
>
> lsps are unidirectional so it's entirely possible to have one lsp up in
> one direction and down in the other direction. Without knowing your
> topology or configs first thing I'd look at is making sure you have
> family mpls enabled on all your interfaces and protocols rsvp has all
> the interfaces in there. Turning on traceoptions all for rsvp doesn't
> hurt either :)
>
> Mike
>
> David Ball wrote:
> > I have 2 T640s running 8.1R5 connected via 10GigE. OSPF and BGP
> > are up and exchanging routes. I have LDP configured and is building
> > LSPs as expected, and traffic is passing. I've also configured RSVP
> > on both routers, and it...almost...works.
> >
> > The issue I'm seeing is that according to 1 of the T640s, both
> > ingress and egress RSVP-signalled LSPs are 'Up'. However, according
> > to the other router, only 1 of them is up. I can't think of how it
> > may be possible that 2 routers think differently about the current
> > state of the same LSP. Was hoping someone here might have an idea.
> > I've already opened a TAC case, but I have yet to hear anything.
> > Thought I might try you good folks concurrently. Thanks in advance for
> > any guidance.
> >
> > First, a 'show rsvp session from ROUTER1:
> >
> > dball at ROUTER1-re0> show rsvp session
> > Ingress RSVP: 1 sessions
> > To From State Rt Style Labelin Labelout LSPname
> > 1.7.1.22 1.7.1.1 Up 0 1 FF - 3
> > NCP-LSP-00813-001-022
> > Total 1 displayed, Up 1, Down 0
> >
> > Egress RSVP: 1 sessions
> > To From State Rt Style Labelin Labelout LSPname
> > 1.7.1.1 1.7.1.22 Up 0 1 FF 3 -
> > NCP-LSP-00820-022-001
> > Total 1 displayed, Up 1, Down 0
> >
> > Transit RSVP: 0 sessions
> > Total 0 displayed, Up 0, Down 0
> >
> > dball at ROUTER1-re0>
> >
> >
> > And now, a 'show rsvp session' from ROUTER2, showing the same 2 LSPs,
> > but in different states:
> > dball at ROUTER2-re0> show rsvp session
> > Ingress RSVP: 1 sessions
> > To From State Rt Style Labelin Labelout LSPname
> > 1.7.1.1 1.7.1.22 Dn 0 0 - - -
> > NCP-LSP-00820-022-001
> > Total 1 displayed, Up 0, Down 1
> >
> > Egress RSVP: 1 sessions
> > To From State Rt Style Labelin Labelout LSPname
> > 1.7.1.22 1.7.1.1 Up 0 1 FF 3 -
> > NCP-LSP-00813-001-022
> > Total 1 displayed, Up 1, Down 0
> >
> > Transit RSVP: 0 sessions
> > Total 0 displayed, Up 0, Down 0
> >
> > dball at ROUTER2-re0>
> >
> >
> > A bit more info from ROUTER2 (the router that sees 1of the LSPs as 'Dn':
> >
> > dball at ROUTER2>show mpls lsp extensive
> > <snip>
> > 1.7.1.1
> > From: 1.7.1.22, State: Dn, ActiveRoute: 0, LSPname: NCP-LSP-00820-022-001
> > Description: NCP-LSP-00820-022-001
> > ActivePath: (none)
> > FastReroute desired
> > LoadBalance: Random
> > Encoding type: Packet, Switching type: Packet, GPID: IPv4
> > Primary State: Dn
> > OptimizeTimer: 30
> > SmartOptimizeTimer: 180
> > Reoptimization in 12 second(s).
> > Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1)
> > 1.7.2.21 S
> > 9283 Jan 19 15:36:30.800 Originate Call
> > 9282 Jan 19 15:36:30.800 Clear Call
> > 9281 Jan 19 15:36:30.800 CSPF: computation result accepted 1.7.2.21
> > 9280 Jan 19 15:36:01.368 Originate Call
> > 9279 Jan 19 15:36:01.368 Clear Call
> > 9278 Jan 19 15:36:01.368 CSPF: computation result accepted 1.7.2.21
> > 9277 Jan 19 15:35:32.356 Originate Call
> > 9276 Jan 19 15:35:32.356 Clear Call
> > <snip>
> >
> >
> > And finally, the log entries. I can't find decently descriptive info
> > on what the 'RSVP error' lines mean. Found what 'code 4' means, but
> > not much in the way of what I should/could do to fix it.
> >
> > dball at ROUTER2>show log rsvp (traceoptions are set to 'packets' and 'error')
> > Jan 19 15:35:05.474619 RSVP send Path 1.7.1.22->1.7.1.1 Len=248 ge-0/0/0.0
> > Jan 19 15:35:05.585878 RSVP recv Ack 1.7.2.1->1.7.2.22 Len=20 ge-0/0/0.0
> > Jan 19 15:35:06.056029 RSVP recv SummaryRefresh 1.7.2.1->1.7.2.22
> > Len=24 ge-0/0/0.0
> > Jan 19 15:35:06.056114 RSVP send Ack 1.7.2.22->1.7.2.1 Len=20 ge-0/0/0.0
> > Jan 19 15:35:06.056176 RSVP recv Path 1.7.2.1->1.7.2.22 Len=248 ge-0/0/0.0
> > Jan 19 15:35:06.056189 RSVP send Ack 1.7.2.22->1.7.2.1 Len=20 ge-0/0/0.0
> > Jan 19 15:35:06.185954 RSVP recv Resv 1.7.2.1->1.7.2.22 Len=132 ge-0/0/0.0
> > Jan 19 15:35:06.185999 RSVP send Ack 1.7.2.22->1.7.2.1 Len=20 ge-0/0/0.0
> > Jan 19 15:35:06.186053 RSVP error, recv resv no path info Resv
> > 1.7.2.1->1.7.2.22 Len=132
> > Jan 19 15:35:06.186067 RSVP error, originate ResvErr ResvErr
> > 1.7.2.22->1.7.2.1 Len=8 code 4 subcode 0
> > Jan 19 15:35:06.186075 RSVP send ResvErr 1.7.2.22->1.7.2.1 Len=104 ge-0/0/0.0
> >
> > David
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
More information about the juniper-nsp
mailing list