[c-nsp] Monitoring ethernet circuits with GRE

[William]

David,

I've configured 'keepalive 10 3' on both sides and still have the same
issue, this is the current status:

Router#sh int tunnel1
Tunnel1 is up, line protocol is down
  Hardware is Tunnel
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (10 sec), retries 3
  Tunnel source 1.1.1.2, destination 1.1.1.1
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Tunnel TTL 255
  Checksumming of packets disabled,  fast tunneling enabled
  Last input 00:09:10, output 00:00:03, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     1004 packets input, 48192 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     771 packets output, 37008 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

3550switch#sh int tunnel1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (10 sec), retries 3
  Tunnel source 1.1.1.1, destination 1.1.1.2, fastswitch TTL 255
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Tunnel TTL 255
  Checksumming of packets disabled
  Last input 00:00:02, output 00:00:09, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     779 packets input, 37772 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1089 packets output, 53792 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out


up/up one side, up/down on the other.. fun.

Cheers,

Will


On 28/11/06, David Prall <dcp at dcptech.com> wrote:
> You'll need to enable tunnel keepalives for the interface to actually go
> down if the route to the destination stays present. Another option for
> Ethernet interfaces is to monitor the routing protocol instead.
>
> David
>
> --
> David C Prall dcp at dcptech.com http://dcp.dcptech.com
>
>
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of William
> > Sent: Tuesday, November 28, 2006 10:03 AM
> > To: [c-nsp]
> > Subject: [c-nsp] Monitoring ethernet circuits with GRE
> >
> > Hi list,
> >
> > With the increasing amount of Ethernet circuits being used within our
> > business I'm looking for a simple way to monitor the links. As we all
> > know, most of the time the WAN interface will be up/up even if there
> > is a problem in the 'cloud' it uses to get to the other end point.
> >
> > I've been looking into using a simple GRE tunnel from one end to the
> > other, if there is a serious amount of packet loss on the link and the
> > tunnel goes up/down I can use one of our systems to alert us.
> >
> > Config goes like this:
> >
> > interface Tunnel1
> >  no ip address
> >  tunnel source 1.1.1.1
> >  tunnel destination 1.1.1.2
> >
> >
> > With the last two lines reversed for the other side, everything should
> > come up and just *work*
> >
> > I'm currently testing this with a 2600 and 3550, the port on the 3550
> > is routed and has an ip address applied to it.
> >
> > My problem consists of the tunnel being up/up, and sometimes just
> > being down. Having to issue a shut+no shut on either interface to
> > bring the tunnel back up. Sometimes the 3550 is reporting the tunnel
> > is up when the 2600 isn't contactable over IP!! (having shut down the
> > interface on the 2600)
> >
> > Am I running into silly issues because the 3550 isn't capable of GRE?
> > Most of the networks I'm currently looking after consist of L3 3750's
> > with routed ports to connect to WANs. Just need some guidance if I'm
> > doing something wrong or if the hardware I'm dealing with just cant do
> > it!
> >
> > Thank you for your time.
> >
> > William
> > _______________________________________________
> > 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/
> >
>
>