[j-nsp] Proper Break of MPLS RSVP Ring

[Levi Pederson]

Ben,

Thank you for the thought out response.

I'll dive into the L2 side.

Thank you,


*Levi Pederson*
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipederson at mankatonetworks.net


On Thu, Jul 16, 2015 at 2:58 PM, Ben Dale <bdale at comlinx.com.au> wrote:

> Hi Levi,
>
> > On 17 Jul 2015, at 5:22 am, Levi Pederson <
> levipederson at mankatonetworks.net> wrote:
> > This is displaying it self in my output by not having an RSVP Neighbor
> > (neighbor down hellos sent) between C&D (and therefore sending my traffic
> > inefficiently 3/4 way around the ring instead of the 1/4 hop it could.
> > Last bit of information is that D sees C as a neighbor but is down.  C
> does
> > not even see D as a neighbor at all.
>
> This sounds like an L2 issue, or perhaps a misconfiguration - all nodes
> should be RSVP neighbours in order to be able to signal LSPs across those
> interfaces.
>
> Check your protocols rsvp config for the logical interfaces between D.
>
> Use monitor traffic interface <D-C interface> on D to confirm that RSVP is
> being sent out of the box.
>
> Check any control-plane filtering/firewall filters you have configured on
> C (though it seems to be receiving just fine from B).
>
> > I'm wondering how RSVP breaks that link.  All the documentation I can
> find
> > are focused on LSP validation/creation and not on Link Breaks to stop
> layer
> > 2 loops (is my assumption).  If one of my intervening links goes own I
> > would like to correct it and then move the break to the specified point.
> > But the RSVP documentation is rather...limited to only LSPs if I am
> reading
> > it correctly.
>
> RSVP won’t break the link to stop loops (the LSPs will carry service
> labels which may not even be L2 services), it will simply establish the LSP
> across the best/shortest path between endpoints (based on your TE
> settings), and if this becomes unavailable (and depending on your
> configuration) it will simply re-establish over any alternate path (which
> it sounds like is working well).
>
> Cheers,
>
> Ben
>
>