Dear all,
I've tried BFD with LSPs but I wasn't able to make it work.
If you've the possibility to use a Tunnel PIC - with a ficticious interface
(f.e. with private address)
and static routes (via the end-point of the interface you want to trigger) with
BFD - is a good option,
it works for me: in the instant the triggered interface fails, BFD goes down
and the tunnel too.
If you finally can use LSP's pleas keep us informed :)
Regards,
Dario D.
El Miércoles, 25 de Abril de 2007 12:13, Sailendra Mahanty escribió:
> 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/swconfig81-mpls-apps/download/swconfig81-mpls-apps.pdf
>
> thanks,
> -sail
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sinan Ilkiz
> Sent: Wednesday, April 25, 2007 1:55 AM
> To: [email protected]
> 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.
>
> [EMAIL PROTECTED]> 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"
>
> [EMAIL PROTECTED]> 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,
>
> [EMAIL PROTECTED]> 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 [email protected]
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list [email protected]
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
