cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2145
Views
5
Helpful
4
Replies

Is it possible to send an ICMP echo reply through the same interface the echo request came in ?

Ludovic Kuty
Level 1
Level 1

Hello,

The router is connected to the Internet through two ISPs and thus two interfaces: VLAN3 statically configured with IP 192.168.2.254 and connected to ISP1 (4G module with IP 192.168.2.1) and GigabitEthernet1 which receives a dynamic IP from ISP 2 (satellite router/modem). Everything is working good.

 

I would like that any incoming ICP echo request to the routeur on GigabitEthernet1 is answered with an ICMP echo reply going out through the same GigabitEthernet1 interface and not through the default route interface as it is in the routing table (S* 0.0.0.0/0 [1/0] via 192.168.2.1, Vlan3).

 

I tried to use PBR with an "ip local policy" but to no avail. I guess the reply is considered as originating from the routeur but I can't see a way to somehow link the reply with the request.

 

I tried something like below but it is not good because the link is not established and I probably used a few useless commands for my use case.

ip access-list extended ping-backup
 permit icmp any any echo
 permit icmp any any echo-reply

route-map udp-echo permit 3
 match ip address ping-backup
 match interface GigabitEthernet1
 set ip next-hop dynamic dhcp
 set interface GigabitEthernet1
 set default interface GigabitEthernet1

 

Any idea if it is possible ?

 

Thanks in advance

 

1 Accepted Solution

Accepted Solutions

Answer for future readers: it is not possible.

Thanks, I simplified stuff as you proposed but realized that it is not possible to have a PBR for outgoing ICMP echo replies that is linked somehow to the echo requests. They are independant by design from the point of view of the ACL and PBR.

Anyway, I already use IP SLA UDP echo to get both WAN IPs (WAN IP 1, WAN IP 2) and also to know the WAN IP used by the default route (current WAN IP) by sending them to a remote Ruby server which does the reply and decoding.

Thus, if the remote Ruby server sends a ping to the currently used WAN IP, I will get the RTT and check if "current WAN IP == WAN IP 1" or "current WAN IP == WAN IP 2" and consequently know the RTT for ISP 1 (which should be in the 30-50ms range) or ISP 2 (which should be in the 700-800ms range) and act accordingly (stop responding to UDP echo and then force the change of the default route thanks to a track object).

 

View solution in original post

4 Replies 4

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @Ludovic Kuty ,

 

your route-map has too many statements

 

route-map udp-echo permit 3
 match ip address ping-backup
 
 set interface GigabitEthernet1
 

 This may work as it forces matching traffic to go out Giga1 set interface giga1.

 

The other commands that I have removed can be misleading:

 

set default interface GigabitEthernet1

This looks at IP routing table first and if you have a default route out the other link it is not triggered.

 

match interface GigabitEthernet1

 

This is also misleading as it can match on the outgoing interface, but given the default route out the other link it will never match.

 

Try the simplified version above with local policy.

 

Hope to help

Giuseppe

 

Doesn't that mean that every ICMP echo reply will exit through GigabitEthernet1, even if the echo request came on another interface like VLAN3 or VLAN1 (IP: 192.168.123.254/24) which is the LAN interface (with a ping from a local host to the router) ?

Hello @Ludovic Kuty ,

your understanding is correct your ACL needs to be refined to deny the cases where the answer should go out other internal interfaces.

 

Otheriwise you can break ICMP tests on the internal side.

 

Hope to help

Giuseppe

 

Answer for future readers: it is not possible.

Thanks, I simplified stuff as you proposed but realized that it is not possible to have a PBR for outgoing ICMP echo replies that is linked somehow to the echo requests. They are independant by design from the point of view of the ACL and PBR.

Anyway, I already use IP SLA UDP echo to get both WAN IPs (WAN IP 1, WAN IP 2) and also to know the WAN IP used by the default route (current WAN IP) by sending them to a remote Ruby server which does the reply and decoding.

Thus, if the remote Ruby server sends a ping to the currently used WAN IP, I will get the RTT and check if "current WAN IP == WAN IP 1" or "current WAN IP == WAN IP 2" and consequently know the RTT for ISP 1 (which should be in the 30-50ms range) or ISP 2 (which should be in the 700-800ms range) and act accordingly (stop responding to UDP echo and then force the change of the default route thanks to a track object).

 

Review Cisco Networking for a $25 gift card