ethernet keepalive

If I have two cisco routers connected over two switches (router1 - switch1

- switch2 - router2), is there a kind of keepalive mechanism or somethink like it, that would give me possibility to SEE on routers if link between switch1 and switch2 is broken.

thanks

Reply to
max
Loading thread data ...

I take it that you want to avoid router 1 from sending traffic to router 2 in the event that the connection between the switches are down.

Personally, I would use IP SLA monitor and track the address of router

2's IP address from router 1. If you search Cisco for IP SLA you will find lots of reference material.

NB You don't mention what your switches are or whether the connection between the routers and switches is 1 x subnet.

Regards

Darren

Reply to
Darren Green

no, I want to ne able to detect if link is broken. I have metro ethernet service from provider (switch1 and switch2) connected to my routers (router1 and router2) and I want to be able to detect thet "line" is down. Foe example if I could get router ethernet interface to go down in case of broken line in provider cloud, I could detect it by simple ping on interface.

Reply to
max

Use a dynamic routing protocol between router 1 and router 2 and log the loss of neighbour adjacency

Reply to
Merv

ok, I taught of that, but I have external monitoring system that uses pings for detection ... so I was hope to use this kind of detection. If I want to use routing protocol ... I must write some ne scripts for that, but thanks for idea

Reply to
max

Does the external monitoring system have paths to routers 1 and router

2 that do not have to traverse the path router1-switch1-switch2- router2

i.e. if you ping router2 does the ping packet have to travel path router1-switch1-switch2-router2 ?

Reply to
Merv

yes, there is paralel path to this one :-)))

Reply to
max

Then a simple ping itest s an insufficient as you probably have already realized.

The router interfaces facing the switch could both be up and traffic may not flow between then because of issue on the Metro Ethernet switches. A simple ping will be successful but there is no path ...

If you telnet to say router 1 and use extended ping specifying the source address of the interface facing router 2, then IOS should always try to route the ICMP echo packet out via the directly connected interface. If the Metro Ethernet is down, then the extended ping should fail.

Reply to
Merv

Or perhaps another way of doing this would be if you can generate pings to test the MetroEthernet with a different source address (i.e logical loopback interface on NMS), then you could policy route those pings packets to always go out the interface facing the Metro Ethernet

Reply to
Merv

If that's Metro Ethernet, You could actually use OAM functionalities to achieve that. If that's more common network scenario, you can still use IP SLA to track the L3 reachability between routers, or some routing protocol (if you need fast convergence then there's BFD), or some additional tunneling method (GRE/IPsec) supporting keepalives.

Reply to
Łukasz Bromir

If the OP is not using a dynamic routing protocol on the parallel links between router 1 and router 2 then it should be seriously consider implementing that immediately.

The NMS ping issue is a secondary issue in relationship to having a Metro Ethernet blackhole ...

Reply to
Merv

ok, plan B was to use some kind of tunnel ... mybe just for this purpose, and this OAM functionality ..... do you have link for this to Cisco documentation?

Reply to
max

A tunnel destination will follow the same routing path as your pings ... The only tunnel that I am aware that you can control the path are MPLS TE tunnels

OAM for Carrier Ethernet Networks: End-to-End Manageability to the Customer

formatting link

I doubt that you will be able to use IEEE 802.3ah OAM

Whar models are the routers and what IOS version(s0 are being used ?

Reply to
Merv

formatting link

7204VXR 12.3 ip plus
Reply to
max

AFAIK that router has no support for IEEE 802.3ah OAM

BTW later version of IOS let one specify the source address in a one line command ( i.e do not have to use extended ping)

HUB#ping 172.16.1.3 source 172.16.1.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.3, timeout is 2 seconds: Packet sent with a source address of 172.16.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Reply to
Merv

the funcionality where the metro link drops the ports if there is no end to end path doesnt have a standard name - "link loss forwarding" is what it is called on some equipment.

if the carrier doesnt use equipment that does this, or doesnt know how to turn it on, then you will have to work around the issue.

there are lots of workarounds - but the preferred way to do this is a routing protocol - that should detect faults in the routers at each end as well, and possibly on other equipment further into your network.

And you dont need any of this to use "ping" - if the path to the far end vanishes, then your pings are not going to get to the router, and losing pings tells you there is a fault.....

Reply to
stephen

Pings will succeed to both router interfaces iused for the Metro Ethernet path if there is a parallel path between the two routers which the OP stated that there is and that a dynamic routing protocol is advertising the subnet which is used on the Metro Ethernet subnet.

Reply to
Merv

Reply to
carlfugate

not always.

imagine you have Enet WAN link between 4 routers - 2 parallel independent paths.

run a routing protocol between them - i prefer OSPF but it doesnt really matter which one you pick.

ping all 4 Enet WAN interfaces from a monitoring station "somewhere".

there should be 1 preferred to each Ethernet WAN - 1 end the "ping" will be via a local router, the other via the Ethernet WAN to the remote router.

Now if you lose the Ethernet, but the interface stays up on the routers, the subnet still gets advertised, so the ping traffic flow is the same. Except - the ping to the far end Ethernet port cannot get there, as the path crosses the broken Ethernet WAN.

so - as long as the monitor pings flow "in band" across the monitored network, (and the path to 1 end of the link uses the monitored Enet WAN for each link) you still detect WAN failures with loss of ping.

now - at work the preferred way is to send SNMP traps and Syslog to a monitoring tool, and let the routing protocol loss of adjacency declare the link down. Then since none of this stuff is perfect we use ping as a backup.

Reply to
stephen

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.