[c-nsp] Mysterious GRE tunnel flap

[Quinn Kuzmich]

No drops of any kinds on the interfaces.  Any of the usual culprits (carrier
resets, IPs reassigned, routing bugaboos etc) do not seem to match this.  We
aren't seeing any hits with EIGRP at ths time this happens, and the
interfaces do not see any hits on the counters.  To make this stranger, it's
only ONE end of the tunnel going down.  The other side stays up.

Q

On Wed, Jul 21, 2010 at 7:24 PM, Pete Lumbis <alumbis at gmail.com> wrote:

> I would take a box you can log outputs on (like a linux host).
>
> From site A set up a script that every 5 seconds prints the time then pings
> (say 10 packets):
> the local LAN interface, the local WAN interface, local the GRE IP, the
> remote WAN interface, remote LAN interface, remote GRE IP and if possible a
> host on the far side.
>
> Set up the same thing from side B.
>
> See if there are any drops anywhere along the path.
>
> I've seen issues like this where the carrier refreshes the IP but the lease
> always stays the same, or a batch job runs and congests the interface or
> anything else that would run on that kind of timer.
>
> Do you see any drops or anything on the physical interfaces from either
> side?
>
> Good luck, these kinds of problems can be hard to nail down.
>
> -Pete
>
>
> On Wed, Jul 21, 2010 at 8:10 PM, Quinn Kuzmich <lostinmoscow at gmail.com>wrote:
>
>> I appreciate the reply - the tunne source locall is actually an HSRP
>> virtual
>> interface, and it never goes down according to what I'm seeing.  And as
>> far
>> as I can recall, we get no errors on the interface that is acting as the
>> active router.
>>
>> Q
>>
>> On Wed, Jul 21, 2010 at 6:00 PM, Graham Wooden <graham at g-rock.net> wrote:
>>
>> > I'll take a stab at this ... I think it's something physical at one of
>> the
>> > sites.  Does any of the two interfaces has their line protocol go down?
>> Can
>> > you access down the link, outside the tunnel, ie. Ping your next hop
>> during
>> > this?
>> >
>> > I had something similar happen with some collocated gear at a remote
>> site.
>> > Around the same time everynight, err counters on an interface would go
>> nuts
>> > for about 2 minutes. Lots of finger pointing between LEC and us. Well,
>> come
>> > to find out that the building's emergency lighting would be tested at
>> this
>> > time, and it's cable run ran next to our T1s for a short distance before
>> > going into our room.
>> >
>> > Long story short here is check the physical layer first!
>> >
>> > -graham
>> >
>> > On 7/21/10 1:17 PM, "Quinn Kuzmich" <lostinmoscow at gmail.com> wrote:
>> >
>> > > Ok, I have a problem that I'm hoping someone can help out with.  I
>> have
>> > two
>> > > 1841s seperated by a Metro-E WAN.  Over this is a GRE tunnel to route
>> > > multicast.  Every morning at 8AM EST, give or take 3 minutes, the
>> tunnel
>> > > will go down for about 30 seconds.  This happens every morning at this
>> > time,
>> > > there are no errors in EIGRP, nor on the WAN side (plenty of tickets
>> > opened
>> > > and we were watching the circuit when the flap happened, no dice) and
>> > we're
>> > > at a real loss.  Maybe a bug in the IOS?  An angry voodoo priest
>> > somewhere?
>> > >
>> > >
>> > > Ideas?  Thanks in advance!
>> > >
>> > > Q
>> > > _______________________________________________
>> > > 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/
>>
>
>