[j-nsp] MPLS OAM not triggering LSP
Sinan İlkiz
sinan.ilkiz at borusantelekom.com
Fri Apr 27 03:59:31 EDT 2007
Thanks for the replies.
There is no IGP in this scenario. LSP ingress and egress routers belong to different ASs. Loopback connectivity is maintained by static routes. There are l2circuits between these two routers. We don't want LDP session to go down in order to NOT to notify customer ends (via OAM or etc.). So I think using BFD for LDP would not be a wise solution.
Because the nature of the failures is indirect, we utilize BFD for static routes to the loopbacks. The only solution that we can find for the moment is about RSVP neighborship timers. We decrease keep-multiplier and hello-interval values to have RSVP neighborship timeout faster.
We are assessing remote-interface-switch solution also. As far as I know we can not utilise link-protection feature for transmit or receive LSPs (I couldn't understand the reason behind this). So we rely on secondary standby paths. All of these solutions tend to provide restoration based on RSVP neighborship timers.
Basicaly the problem description is something like this: We are trying to achieve fast restoration times without notifying some protocols about this failure. I mean LDP. I know this description has some contradictions to itself :)
We are still in test phases and there are many things to test. I will keep the list informed.
Regards.
-----Original Message-----
From: Harry Reynolds [mailto:harry at juniper.net]
Sent: 25 Nisan 2007 Çarşamba 17:43
To: Sailendra Mahanty; Sinan İlkiz
Cc: juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] MPLS OAM not triggering LSP
Sinan, have you tried enabling bfd for the igp session that is in turn supporting the rsvp session? I've not tested personally but have indications from developers that bfd will inform the igp of the link down, and this will in turn cause the igp to start updating the TED, which in turn triggers control plan action for mpls recovery (FRR, use of standby secondary, signal new lsp).
Not saying it will be sonet aps fast, but indications are this will help speed up convergence in a situation such as yours.
HTHs
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Sailendra
> Mahanty
> Sent: Wednesday, April 25, 2007 3:13 AM
> To: Sinan Ilkiz
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] MPLS OAM not triggering LSP
>
> Hi Sinan,
>
> Current version of JunOS that you are using, logs an error message
> when LSP goes down because of BFD as mentioned in
> page-191 of the following doc. However it doesn't make the LSP down.
>
> http://www.juniper.net/techpubs/software/junos/junos81/swconfi
> g81-mpls-apps/download/swconfig81-mpls-apps.pdf
>
> thanks,
> -sail
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Sinan Ilkiz
> Sent: Wednesday, April 25, 2007 1:55 AM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] MPLS OAM not triggering LSP
>
> Hi all,
>
> We are trying to achieve fast convergence times for one of our links.
> We can not detect link failures in this link directly, i.e. interface
> never goes down in case of failures.
> We decided that we can benefit from BFD for LSPs. We are testing this
> configuration;
>
> label-switched-path lsp_to_bt_j_2_sifir {
> from 192.168.100.1;
> to 192.168.100.2;
> ldp-tunneling;
> no-cspf;
> link-protection;
> primary via_sifir {
> oam {
> bfd-liveness-detection {
> minimum-interval 300;
> multiplier 3;
> }
> }
> }
> }
>
>
> When we simulate an indirect failure, we see that BFD session goes
> down but LSP's path does not change. So this causes extended downtimes
> as long as RSVP states time out. We couldn't find out what we are
> doing wrong. In my opinion, when BFD detects the failure, it should
> signal to the local router and say "this path is no longer available,
> you should find another way". We tested both secondary standby and
> link-protection options but nothing changed. We used both
> 7.6R4 and 8.1R3. Test lab consists of one m7i and J4300 connected via
> their ethernet links.
>
> M7i === switch1 === switch2 === J4300
>
> One ethernet link is used as LSP path and other is used as backup
> link. Switch configuration is done in such a way that (using VLANs)
> fe-1/3/0 of M7i and fe-0/0/0 of J4300 form the first path; fe-1/3/1 of
> M7i and fe-0/0/1 of J4300 form second path. To simulate a failure we
> plug off the fist cable between switch1 and switch2 so neither M7i nor
> J4300 knows this problem directly and only the first path (between
> fe-1/3/0 and fe-0/0/0) is affected. This way, we tried to simulate an
> indirect failure.
>
> lab at BT-M-1> show mpls lsp ingress extensive
> Ingress LSP: 1 sessions
>
> 192.168.100.2
> From: 192.168.100.1, State: Up, ActiveRoute: 0, LSPname:
> lsp_to_bt_j_2_sifir
> ActivePath: via_sifir (primary)
> Link protection desired
> LoadBalance: Random
> Encoding type: Packet, Switching type: Packet, GPID: IPv4
> *Primary via_sifir State: Up
> SmartOptimizeTimer: 180
> Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node
> 10=SoftPreempt):
> 10.1.1.2(Label=3)
> OAM state : BFD session up LSP-ping up
> 5 Apr 25 08:34:23.102 Link-protection Up
> 4 Apr 25 08:33:29.085 Selected as active path
> 3 Apr 25 08:33:29.084 Record Route: 10.1.1.2(Label=3)
> 2 Apr 25 08:33:29.084 Up
> 1 Apr 25 08:33:29.073 Originate Call
> Created: Wed Apr 25 08:33:28 2007
> Total 1 displayed, Up 1, Down 0
>
> Then we plug off the appropriate cable at "2007-04-25 08:37:55 UTC"
>
> lab at BT-M-1> show mpls lsp ingress extensive
> Ingress LSP: 1 sessions
>
> 192.168.100.2
> From: 192.168.100.1, State: Up, ActiveRoute: 0, LSPname:
> lsp_to_bt_j_2_sifir
> ActivePath: via_sifir (primary)
> Link protection desired
> LoadBalance: Random
> Encoding type: Packet, Switching type: Packet, GPID: IPv4
> *Primary via_sifir State: Up
> SmartOptimizeTimer: 180
> Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node
> 10=SoftPreempt):
> 10.1.1.2(Label=3)
> OAM state : BFD session not up LSP-ping up
> 7 Apr 25 08:38:01.917 Link-protection Up
> 6 Apr 25 08:38:01.914 Link-protection Down
> 5 Apr 25 08:34:23.102 Link-protection Up
> 4 Apr 25 08:33:29.085 Selected as active path
> 3 Apr 25 08:33:29.084 Record Route: 10.1.1.2(Label=3)
> 2 Apr 25 08:33:29.084 Up
> 1 Apr 25 08:33:29.073 Originate Call
> Created: Wed Apr 25 08:33:28 2007
> Total 1 displayed, Up 1, Down 0
>
> LSP is still traversing the down link. After a short while,
>
> lab at BT-M-1> show mpls lsp ingress extensive
> Ingress LSP: 1 sessions
>
> 192.168.100.2
> From: 192.168.100.1, State: Up, ActiveRoute: 0, LSPname:
> lsp_to_bt_j_2_sifir
> ActivePath: via_sifir (primary)
> Link protection desired
> LoadBalance: Random
> Encoding type: Packet, Switching type: Packet, GPID: IPv4
> *Primary via_sifir State: Up
> SmartOptimizeTimer: 180
> Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node
> 10=SoftPreempt):
> 10.1.1.6
> OAM state : BFD session not up LSP-ping up
> 11 Apr 25 08:38:38.265 Record Route: 10.1.1.6
> 10 Apr 25 08:38:38.264 Record Route: 10.1.1.6
> 9 Apr 25 08:38:35.237 Tunnel local repaired
> 8 Apr 25 08:38:35.237 Down
> 7 Apr 25 08:38:01.917 Link-protection Up
> 6 Apr 25 08:38:01.914 Link-protection Down
> 5 Apr 25 08:34:23.102 Link-protection Up
> 4 Apr 25 08:33:29.085 Selected as active path
> 3 Apr 25 08:33:29.084 Record Route: 10.1.1.2(Label=3)
> 2 Apr 25 08:33:29.084 Up
> 1 Apr 25 08:33:29.073 Originate Call
> Created: Wed Apr 25 08:33:28 2007
> Total 1 displayed, Up 1, Down 0
>
> So it takes for LSP to switch to backup path from 08:37:55 to
> 08:38:38. I couldn't find a logical explanation why BFD does not
> trigger LSP.
>
> Anyone of you tried to use MPLS OAM and hit the same problem?
>
> Regards.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> 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