[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