All, Double Checked the Layer 2 ring today and it seems solid.
Once again we have B and C co-located and A and D in remote locations with a link between them. Currently there is no RSVP between C and D and this is making my ring go right instead of left! I can Ping from D to C (it's next hop on the ring) if I force it out the MPLS interface. However when I ping the LSP interfaces (loopbacks) it takes the long way around). Short is 10ms and the long goes up to almost 26ms (pinging loops , again the long way around). Current production traffic backs this up. This leads me to believe there is not a Layer 2 issue but something more enigmatic. Currently reading up on RSVP priority/preference but that seems like taking a 2Ton Electromagnetic Sentient WreckingBall to hammer in a nail. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net On Thu, Jul 16, 2015 at 2:58 PM, Ben Dale <bd...@comlinx.com.au> wrote: > Hi Levi, > > > On 17 Jul 2015, at 5:22 am, Levi Pederson < > levipeder...@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 > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp