Re: [j-nsp] Proper Break of MPLS RSVP Ring
Chris, I do understand. My initial thoughts were all theoretical. Helping me understand RSVP and the MPLS more. With some help I did discover i had a typo between the links forcing them not to pull up any protocol even OSPF (my internal MPLS routing). So my entire config was right but I had that one mistake. Thank you all to those who provided their two cents and more. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net On Tue, Jul 21, 2015 at 5:44 PM, Chris Kawchuk juniperd...@gmail.com wrote: Post relevant configs and an actual diagram (Visio - PDF) Without this, anything we say is pure speculation -- and we end up playing '20 questions' with you. Getting an MPLS/RSVP/LDP/IGP/BGP/Mesh/TE network setup involves multiple steps and config-knobs being turned on and turned on correctly. Missing any one of them can result in undesirable behaviour. 1. RSVP priority/preference (?) has no bearing on forming an MPLS forwarding path adjacent between two LSRs. 2. There is no break in an MPLS network if it happens to be attached in a ring. This is not Spanning Tree. You have a fully routed network. Topology can be arbitrary. 3. How are you setting broken RSVP down? RSVP only goes up to a neighbour IF it actually has a reason to talk to it's neighbour. If you do not book an RSVP LSP across the link (due to ERO or following the IGP to the egress point), the two LSR's never exchange RSVP packets, because they have no reason to do so. This is known and expected behaviour. This is not LDP, which is 'chatty' and tries to reach out and touch it's neighbour and dynamically create FECs and transport label tables. RSVP only is invoked on an LSR-LSR link if an actual reservation needs to be made on that link. 4. What does your IGP suggest about the shortest path in the topology? 5. do you have family mpls enabled on all the relevant interfaces? 6. do you have all the relevant interfaces you want to run rsvp on, declared in protocols rsvp, and protocols mpls? etc.. ;) - Ck. On 22/07/2015, at 5:18 AM, Levi Pederson levipeder...@mankatonetworks.net wrote: 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, ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Proper Break of MPLS RSVP Ring
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 CD (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
Re: [j-nsp] Proper Break of MPLS RSVP Ring
Post relevant configs and an actual diagram (Visio - PDF) Without this, anything we say is pure speculation -- and we end up playing '20 questions' with you. Getting an MPLS/RSVP/LDP/IGP/BGP/Mesh/TE network setup involves multiple steps and config-knobs being turned on and turned on correctly. Missing any one of them can result in undesirable behaviour. 1. RSVP priority/preference (?) has no bearing on forming an MPLS forwarding path adjacent between two LSRs. 2. There is no break in an MPLS network if it happens to be attached in a ring. This is not Spanning Tree. You have a fully routed network. Topology can be arbitrary. 3. How are you setting broken RSVP down? RSVP only goes up to a neighbour IF it actually has a reason to talk to it's neighbour. If you do not book an RSVP LSP across the link (due to ERO or following the IGP to the egress point), the two LSR's never exchange RSVP packets, because they have no reason to do so. This is known and expected behaviour. This is not LDP, which is 'chatty' and tries to reach out and touch it's neighbour and dynamically create FECs and transport label tables. RSVP only is invoked on an LSR-LSR link if an actual reservation needs to be made on that link. 4. What does your IGP suggest about the shortest path in the topology? 5. do you have family mpls enabled on all the relevant interfaces? 6. do you have all the relevant interfaces you want to run rsvp on, declared in protocols rsvp, and protocols mpls? etc.. ;) - Ck. On 22/07/2015, at 5:18 AM, Levi Pederson levipeder...@mankatonetworks.net wrote: 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, ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Proper Break of MPLS RSVP Ring
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 CD (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
Re: [j-nsp] Proper Break of MPLS RSVP Ring
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 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 CD (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
[j-nsp] Proper Break of MPLS RSVP Ring
All, I've been having a great time with all your help in creating an MPLS ring and I've made tons of headway. My issue now my ring is L2 broken using RSVP at an inconvenient point. I am assuming this break is natural to the creation of an MPLS Ring. Note the MPLS transport works. Just taking a +15ms path. However , I would like it broken at a point where two devices are co-located. Device A and B are co-located Device C and D are geographically separated but have a link between them. Currently I have the following RSVPs A A-B A-D B B-A B-C C C-D (Broken rsvp down) C-B D D-C (Broken rsvp down) D-A Incidentally The C-D link was the last MPLS Core link I turned up. This is displaying it self in my output by not having an RSVP Neighbor (neighbor down hellos sent) between CD (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. 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. Any and all assistance would be much appreciated. Thank you *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp