Virtual Interface goes down but not the physical interface.

[cbrowne]

Hi,

I have five 877 routers connected to ADSL circuits provided by Vodafone. Each has a VPN tunnel back to a PIX.

Occasionally one of the sites will lose it's connection to the PIX.

When we check the log, we find entries like these:-

Apr  5 01:31:54.085 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
Apr  5 01:33:19.344 UTC: %CRYPTO-6-EZVPN_CONNECTION_DOWN: (Client)  User=  Group=EZVPN-group  Server_public_addr=xxx.xxx.xxx.xxx
Apr  5 01:33:19.352 UTC: EZVPN(vpn-hw-client): Dialer interface has not yet got the ip address
Apr  5 01:33:19.352 UTC: EZVPN(vpn-hw-client): Dialer interface has not yet got the ip address
Apr  5 01:33:28.045 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
Apr  5 01:43:28.445 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
Apr  5 01:44:02.649 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
Apr  5 01:54:02.994 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
Apr  5 01:54:13.475 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up

As you can see, the physical interface (ATM0) is not being reported as changing state to down, neither is the Dialer interface.

When the router is in this state we have to SSL to the public IP address of it and manually restart the ISAKMP SA.

When the router sees the ATM interface go down and subsequently come back up, the VPN connection to the PIX also recovers.

So - in a long winded way I think I'm asking....why does the Virtual interface go down and is there anything I can do to stop it happening?

I have attached a sanitised config.

Many thanks in advance

CB

[Latchum Naidu]

Hi,

Is this PPPoATM used to connect to some kind of DSL ISP? I've seen some ISPs that will timeout a PPPoE session after a certain amount of time, regardless of the presence of traffic. It forces all of the routers/modems to renegotiate the PPP sessions periodically (say every 24 hours for example). That would also explain why it comes right back up again. Just a thought.

And also it look at the main interface in question for errors "sh controll x/x"  If this is a consistent then contact your ISP to get them to look at the line, if its random its still provider but its just taking random hits of the circuit being up.

Please rate the helpfull posts.
Regards,
Naidu.

[cbrowne]

Thanks for the response.

There's a PIX at the company HQ and 877's at the regional offices. The PIX has a leased line to an ISP, the 877's use ADSL's (all provided by Vodafone).

The 877's don't allow the office users to connect to the Internet, just to the HQ via a site-to-site VPN using EZVPN

If the ADSL drops, we see the following happen on the 877:

Virtual Interface goes down

Virtual Interface unbinds from the Dialer Interface

EZVPN connection goes down

Line protocol on the Virtual Interface goes down

ATM Interface goes down

Line protocol on the ATM Interface goes down

When it comes back up we sort of see the same in reverse, the VPN tunnel re-establishes and everyone is happy.

However, at other times the 877 only sees:

EZVPN connection goes down

Virtual Interface goes down

Virtual Interface comes up

At this point the VPN tunnel has to be re-established manually.

It appears as if the ATM interface doesn't actually go down in this last instance and I cannot find why the EZVPN or the Virtual Interface are going down.

This is happening at five different sites and there doesn't seem to be any pattern (time of day, after x-amount of hours etc.,) behind when this happens.

CB

[gersoto]

Hi,

So it looks like  you have two different  problems: 1) Virtual-access interface flapping & 2) ATM interface  flapping.

From those two, the ATM interface flapping is the  most urgent to fix.  Everything runs on top of the physical layer, thus  if ATM flaps, nothing works.  You want to start monitoring the ATM  interface for errors (CRC errors and/or any other type of input error).   CRC and input errors in the ATM interface are generally associated to a  dirty (noisy) circuit.  Get your ISP involved if that's the case.   Troubleshooting physical layer problems may also require to test with  other equipment (DSL modem or even replacing the router), replacing the  telephone cable, and Telco performing a line inspection.  Sometimes  problem can also be incompatibility with the DSL switch (DSLAM), this  may be true if Telco has recently replaced their DSLAMs or performed  firmware upgrades in them.

About the virtual interface  flapping, that may happen when the PPP layer fails.  Things that may  cause PPP to flap are:

PPP losying sync (lost or  missing PPP keepalives)

Termination Request from either side

Virtual  circuit (PVC) failure (lost communication at the VC level)

From  the debugs, we see the virtual interface flapping up and down.  This  sometime happens when PPP authentication fails.  To get more information  get around 1 minute worth of "debug ppp negotiation" & "debug ppp  error"

Other valuable outputs to get during a failure:

show version

show  dsl interface (x2 w/ 30-sec interval)

show atm pvc 0/38 (x3 w/ 30-sec interval)

show interface atm0 (x3 w/ 30-sec interval)

Regards,

Gerardo