[c-nsp] Monitoring failed state of DSL / Cable (Ethernet)interfaces

Joe Maimon jmaimon at ttec.com
Thu Mar 3 06:04:10 EST 2005


Odd that -- one would imagine that the outgoing interface and source IP 
for saa might change in the event of the 0/0 pointing elsewhere.

How about try a loopback interface as source for saa rtr 
instance,(optionaly: nat the loopback, so you get to make up the address 
[helps when cookie cutting]), local policy route the loopback to next 
hop/interface.

This is easily repeatable for as many interfaces you wish.



Brian Feeny wrote:
> Yes, very true.  What I do, is I policy route all traffic for the WAN 
> interface IP's anyways.  I assume in the absense
> of loopbacks, that SAA sources using the outgoing interface IP.   I 
> policy route my WAN interface IP's out to the next
> hop.
> 
> Brian
> 
> On Mar 2, 2005, at 7:29 AM, Rodney Dunn wrote:
> 
> 
>>That's why with SAA you have to policy route
>>the probe out the interface you want to monitor
>>until SAA is enhanced to allow you to specify
>>the exit interface explicitly.
>>
>>Rodney
>>
>>On Tue, Mar 01, 2005 at 04:44:19PM -0800, Ted Mittelstaedt wrote:
>>
>>>
>>>>-----Original Message-----
>>>>From: cisco-nsp-bounces at puck.nether.net
>>>>[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Dan Martin
>>>>Sent: Tuesday, March 01, 2005 12:33 PM
>>>>To: Brian Feeny; cisco-nsp
>>>>Subject: RE: [c-nsp] Monitoring failed state of DSL / Cable
>>>>(Ethernet)interfaces
>>>>
>>>>
>>>>You may try "rping" on the router to ping some router upstream of the
>>>>dsl modem.  When the poll fails, you take the message and use that to
>>>>admin down the Ethernet interface on the router, thus triggering some
>>>>switch over.
>>>>
>>>>Once its switched over, you will need to bring the interface back up 
>>>>so
>>>>you can keep pinging so you will know when the dsl line comes back to
>>>>life.
>>>>
>>>
>>>That won't work because as soon as the line is switched over the pings
>>>will start working again - since they now will be routed around 
>>>through
>>>the backup link.
>>>
>>>ALL of the commercial solutions I've seen that use DSL for a primary
>>>assume PPP-mode DSL.  If the DSL line goes down the PPP packets don't
>>>come in anymore and it is easy for the router to understand that the
>>>DSL line went away.
>>>
>>>If it's bridged DSL then one way is to set your script up to ping the
>>>default gateway on the DSL side then check for the existence of the
>>>MAC address in the arp table for that IP number.  If it isn't there 
>>>then
>>>you know the DSL line is down and you can rewrite the default route.
>>>And when the DSL line comes back you will know because the ARP will
>>>reappear.
>>>Unfortunately this is beyond the capabilities of Cisco routers.
>>>
>>>Running OSPF out both interfaces would be a better way to do it.  That
>>>would require the provider to support it, though.
>>>
>>>Ted
>>>
>>>_______________________________________________
>>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 


More information about the cisco-nsp mailing list