[c-nsp] Monitoring ethernet circuits with GRE

Dario dario.donsion at soporte.rediris.es
Tue Nov 28 10:51:18 EST 2006


Dear all,

You need to configure keepalives in the tunnel (the tunnels are up by default), and use 
the correct IOS:

        12.2(8)T    This feature was introduced on several platforms. The keepalive command
			was modified to make it available for use on tunnel interfaces.
        12.0(23)S   This feature was incorporated.

You can also configure an mpls path, but not traps are generated if your IOS doesnt support the
"MPLS Label Switching Router MIB (MPLS-LSR-MIB)" MIB. Even no traps are generated you can 
see the LSP down and up in the log.

        The MPLS Label Switching Router MIB (MPLS-LSR-MIB) allows you to use the Simple Network 
        Management Protocol (SNMP) to remotely monitor a label switching router (LSR) that is using 
        the Multiprotocol Label Switching (MPLS) technology. The MPLS-LSR-MIB mirrors a portion of 
        the Cisco MPLS subsystem; specifically, it mirrors the MPLS Forwarding Infrastructure (MFI).

        12.0(14)ST     This feature was introduced on Cisco IOS Release 12.0(14)ST
        12.2(2)T        This feature was integrated into Cisco IOS Release 12.2(2)T.
        12.0(22)S      This feature was implemented on the Cisco 12000 series routers and integrated
			    into Cisco IOS Release 12.0(22)S.
        12.2(14)S       This feature was integrated into Cisco IOS Release 12.2(14)S and implemented 
		            on Cisco 7200 and Cisco 7500 series routers.
        12.2(25)S       This feature was updated to work in the MPLS High Availability environment with
			    the Cisco 7500 series routers.

Regards,

	Dario D.

El Martes, 28 de Noviembre de 2006 16:03, William escribió:
> 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/
> 
> 



More information about the cisco-nsp mailing list