Sail,
Just one error in my last e-mail:
On the static route at Router B
[Router B]
route 10.0.0.1/32 {
next-hop public_address_1; ----> not _2!!
bfd-liveness-detection {
minimum-interval 1000;
multiplier 1;
}
no-readvertise;
}
Have you tried this conf? It works fine for me :)
Regards,
Dario D.
El Miércoles, 25 de Abril de 2007 13:25, Dario escribió:
> Sail,
>
> The Tunnel is only for be informed when the triggered interface is failing or
> not.
> When the interface is ok the tunnel will be up and when it fails the tunnel
> is down.
>
> Is a bit tricky ;) I'll try to explain it.
>
> Suposse you want to check the ge between router A and B:
>
> RouterA --- [GE] --- SW1--SW2--SW2 --- [GE] --- RouterB
>
> The interface you want to monitor: (Router A)
>
> ge-0/0/0 {
> description "-- Triggered interface --";
> vlan-tagging;
> unit X {
> vlan-id X;
> family inet {
> no-redirects;
> address "public_address_1/30; --> the
> end-point is public_address_2
> }
> }
> }
>
> No way to monitor when it fails due to the path in the middle.
> I've tried LSP's/BFD but... never works!
>
> Then I configure a tunnel interface: (Router A)
>
> ip-x/x/x {
> unit 666 {
> description "-- Tunel CANT-CANL --";
> tunnel {
> source 10.0.0.1; ---> these addreses
> are not used in your network
> destination 10.0.0.2;
> }
> }
> }
>
> The tunnel goes up when you define an static route via the triggered
> interface:
>
> (Router A)
> route 10.0.0.2/32 {
> next-hop public_address_2;
> no-readvertise;
> }
>
> No traffic will go via this tunnel, is only UP or (as you can see when BFD
> is configured :) ) DOWN.
>
> To force the tunnel to be down I use BFD.
>
> [Router A]
> route 10.0.0.2/32 {
> next-hop public_address_2;
> bfd-liveness-detection {
> minimum-interval 1000; ---> hello packets every second
> multiplier 1;
> }
> no-readvertise;
> }
>
> [Router B]
> route 10.0.0.1/32 {
> next-hop public_address_2;
> bfd-liveness-detection {
> minimum-interval 1000;
> multiplier 1;
> }
> no-readvertise;
> }
>
> (this static route in router B is only to establish the BFD session)
>
> When the GE fails (but it's UP), the BFD goes DOWN, the static route
> dissapear and the Tunnel IP goes
> DOWN too, then you receive an SNMP_TRAP_LINK_DOWN from this Tunnel and you
> can be sure the GE
> is failing.
>
> The Tunnel is only to be noticed of the GE fails, no used for traffic. No way
> to force the GE to goes DOWN,
> but you can monitor it in this indirect way.
>
> Hope it helps.
>
> Regards,
>
> Dario D.
>
>
> El Miércoles, 25 de Abril de 2007 12:38, Sailendra Mahanty escribió:
> > Hi Dario,
> >
> > Removing the j-nsp list.
> >
> > Good to know that you have explored these options however the lt interface
> > (of tunnel pic) may be a bottle neck for the traffic if you are making your
> > traffic pass thru this interface. I am sure you are aware of this.
> >
> > BTW, is it possible to share your config with me to check if there are any
> > other potential problems.
> >
> > Thanks,
> > -sail
> >
> >
> > -----Original Message-----
> > From: Dario [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, April 25, 2007 3:28 AM
> > To: juniper-nsp@puck.nether.net
> > Cc: Sailendra Mahanty; Sinan Ilkiz
> > Subject: Re: [j-nsp] MPLS OAM not triggering LSP
> >
> > 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: juniper-nsp@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.
> > >
> > > [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 juniper-nsp@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> > >
> >
> >
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
