[c-nsp] Scheduling daily reload

[Hank Nussbacher]

At 11:45 AM 02-01-08 +0900, Aaron R wrote:

I had seen this when we had ATM interfaces.  When the carrier made some 
change in their switch, sometimes the ATM subint got hung.  A shut/no shut 
usually released the circuit.

-Hank

>Hi guys,
>
>The issue is more to do with the ISP making configuration changes at their
>end every now and then which causes the routers to hang. I think I will
>chase this up with the ISP. The connection is PPP based. See config below.
>
>
>interface ATM0
>  no ip address
>  no atm ilmi-keepalive
>  pvc 8/35
>   encapsulation aal5mux ppp dialer
>   dialer pool-member 1
>  !
>  dsl operating-mode auto
>!
>!
>interface Dialer0
>  ip address negotiated
>  encapsulation ppp
>  dialer pool 1
>  dialer-group 1
>  no keepalive
>  ppp authentication chap callin
>  ppp chap hostname <removed>
>  ppp chap password <removed>
>end
>
>
>Thanks Guys,
>
>Aaron.
>
>
>
>
>
>-----Original Message-----
>From: Tom Storey [mailto:tom at snnap.net]
>Sent: Wednesday, January 02, 2008 11:28 AM
>To: Aaron R
>Cc: 'Roland Dobbins'; cisco-nsp at puck.nether.net
>Subject: Re: [c-nsp] Scheduling daily reload
>
>
>On 02/01/2008, at 12:25 PM, Aaron R wrote:
>
> > Hi Roland,
> >
> > The problem is the ISP tends to make changes at the various
> > exchanges (The
> > links are ADSL) and this sometimes causes a problem whereby no
> > packets will
> > transmit / receive however the router still believes that the link
> > is up.
> > Maybe I need to look into setting some kind of keep alive feature
> > over the
> > ATM interface perhaps.
> >
> > Cheers,
> >
> > Aaron.
> >
>
>I couldnt imagine that an ISP would make daily changes to the effect
>that it would cause your services to stop working and require a
>reload. Maybe I expect too high operational standards? ;-)
>
>Perhaps there is some other issue worth investigating.
>
>Are the services layer 3 bridged by any chance, i.e. not PPP based?
>
>Perhaps it is an issue with ARP at the ISP end. If you dont send any
>traffic for a period of time and your ARP entry times out, this would
>cause data flow on a bridged service to stop, however, the ARP entry
>should return at their end once you start generating a bit of traffic,
>so that should be easily fixed.
>
>In the case above, something like an SLA monitor which simply pings an
>IP address accross the link, say, once a minute, should ensure that
>ARP stays "fresh" at the ISP end. It is always possible that the
>firmware their DSLAMs or hardware at their PoP runs has a bug and
>doesnt properly re-establish an ARP entry for your service(s).
>
>Otherwise, try a different IOS version (newer IOS images contain ADSL
>controller firmware updates too, just incase its a local bug), and
>failing all of that, log a fault with the provider and see if you can
>get them to fix their end. You shouldnt be needing to implement
>anything at your end to relieve yourself from their issues. But then
>again, am I expecting too high standards? :-)
>
>_______________________________________________
>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/