|
List Info
Thread: RSVP LSP inconsistency
|
|
| RSVP LSP inconsistency |
|
2007-01-19 16:58:12 |
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 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
dballROUTER1-re0>
And now, a 'show rsvp session' from ROUTER2, showing the
same 2 LSPs,
but in different states:
dballROUTER2-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
dballROUTER2-re0>
A bit more info from ROUTER2 (the router that sees 1of the
LSPs as 'Dn':
dballROUTER2>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.
dballROUTER2>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-nsppuck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
|
|
| Re: RSVP LSP inconsistency |
|
2007-01-19 19:39:54 |
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 <mlongsactechgroup.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:
> >
> > dballROUTER1-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
> >
> > dballROUTER1-re0>
> >
> >
> > And now, a 'show rsvp session' from ROUTER2,
showing the same 2 LSPs,
> > but in different states:
> > dballROUTER2-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
> >
> > dballROUTER2-re0>
> >
> >
> > A bit more info from ROUTER2 (the router that sees
1of the LSPs as 'Dn':
> >
> > dballROUTER2>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.
> >
> > dballROUTER2>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-nsppuck.nether.net
> >
https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
|
|
[1-2]
|
|