Comments on: HELPME: BGP + Route Map + Next Hop.

By: nunya

nunya — Thu, 07 Aug 2008 22:43:14 +0000

“IP LOCAL POLICY matches any packets doesn’t matter where it was originated.”

This is actually not true. The local policy only matches on traffic that is generated by the local router.

By: Anthony Fajri

Anthony Fajri — Mon, 29 Jan 2007 01:45:21 +0000

I’m not master in cisco, but I will try to explain about traceroute. Yes, correct! Most of the traceroute programs are using UDP to check each hop status instead of ICMP. But the tracert command in windows is still using ICMP. You also can use -I option in unix to do a traceroute by using ICMP. For traceroute command under cisco IOS, I dont know how to set it using ICMP.

I blog this stuff last week. please check my blog http://fajri.freebsd.or.id/index.php/2007/01/26/traceroute/

By: Sam Wilson

Sam Wilson — Tue, 23 Jan 2007 14:14:57 +0000

“… he [Richard Stevens] was trying to say that traceroute program uses the combination of ICMP and UDP to reach its destination”

That’s true for the original Unix-y version of traceroute. The later Windows-y version (aka tracert) uses ICMP echo requests (pings) as the probe packets rather than UDP packets.

By: David Sudjiman

David Sudjiman — Tue, 23 Jan 2007 13:04:48 +0000

Ricky and TripleH were right. IP LOCAL POLICY matches any packets doesn't matter where it was originated. IP POLICY matched any packets particularly to the applied interface and NOT from the router itself. Basically what I tried was attaching another router to R1E0 and did ping 20.20.20.1. From the R1, I got these matched packets. Oh, BTW, I need to change the access-list on R1 to

access-list 100 permit icmp 10.10.10.0 0.0.0.255 host 20.20.20.1. You can change the access-list on R2 as well.

00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1, len 100, policy match
00:13:20: IP: route map FROM-10.10.10.1-TO-20.20.20.1, item 10, permit
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1 (Serial1), len 100, policy routed
00:13:20: IP: Ethernet0 to Serial1 131.108.1.6
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1, len 100, policy match
00:13:20: IP: route map FROM-10.10.10.1-TO-20.20.20.1, item 10, permit
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1 (Serial1), len 100, policy routed
00:13:20: IP: Ethernet0 to Serial1 131.108.1.6
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1, len 100, policy match
00:13:20: IP: route map FROM-10.10.10.1-TO-20.20.20.1, item 10, permit
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1 (Serial1), len 100, policy routed
00:13:20: IP: Ethernet0 to Serial1 131.108.1.6
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1, len 100, policy match
00:13:20: IP: route map FROM-10.10.10.1-TO-20.20.20.1, item 10, permit
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1 (Serial1), len 100, policy routed
00:13:20: IP: Ethernet0 to Serial1 131.108.1.6
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1, len 100, policy match
00:13:20: IP: route map FROM-10.10.10.1-TO-20.20.20.1, item 10, permit
00:13:20: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1 (Serial1), len 100, policy routed
00:13:20: IP: Ethernet0 to Serial1 131.108.1.6


However, when I checked the using traceroute. It was still using path 131.108.1.1-131.108.1.2.

R3#traceroute 20.20.20.1

Type escape sequence to abort.
Tracing the route to 20.20.20.1

  1 10.10.10.1 4 msec 4 msec 8 msec
  2 131.108.1.2 32 msec 28 msec * 



Before, I thought that traceroute was only using ICMP packet to determine path. Richard Stevens, on his book, TCP/IP Illustrated, Volume 1, page 98, explained that:



We can now guess the operation of Traceroute. It sends an IP datagram with a TTL of 1 to the destination host. The first router to handle the datagram decrements the TTL, discards the datagram, and sends back the ICMP time exceeded. This identifies the first router in the path. Traceroute then sends a datagram with a TTL of 2, and we find the IP address of the second router. This continues until the datagram reaches the destination host. But even though the arriving IP datagram has a TTL of 1, the destination host won't throw it away and generate the ICMP time exceeded, since the datagram has reached its final destination. How can we determine when we've reached the destination?

Traceroute sends UDP datagrams to the destination host, but it chooses the destination UDP port number to be an unlikely value (larger than 30,000), making it improbable that an application at the destination is using that port. This causes the destination host's UDP module to generate an ICMP "port unreachable" error (Section 6.5) when the datagram arrives. All Traceroute needs to do is differentiate between the received ICMP messages-time exceeded versus port unreachable-to know when it's done.


So, basically he was trying to say that traceroute program uses the combination of ICMP and UDP to reach its destination.

Knowing it also uses UDP, we need to ammend the access-list to permit UDP packets as well.

R1(config)#access-list 100 permit icmp 10.10.10.0 0.0.0.255  host 20.20.20.1   
R1(config)#access-list 100 permit udp 10.10.10.0 0.0.0.255  host 20.20.20.1 


R2(config)#access-list 100 permit icmp host 20.20.20.1 10.10.10.0 0.0.0.255            
R2(config)#access-list 100 permit udp host 20.20.20.1 10.10.10.0 0.0.0.255 


Now test the traceroute again.


fr_switch#traceroute 20.20.20.1

Type escape sequence to abort.
Tracing the route to 20.20.20.1

  1 10.10.10.1 4 msec 4 msec 8 msec
  2 131.108.1.6 40 msec 36 msec * 


Voila!, it is now using 131.108.1.6. Looking at R1 debug ip policy gives more assurance.

00:17:50: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1, len 28, policy match
00:17:50: IP: route map FROM-10.10.10.1-TO-20.20.20.1, item 10, permit
00:17:50: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1 (Serial1), len 28, policy routed
00:17:50: IP: Ethernet0 to Serial1 131.108.1.6
00:17:59: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1, len 28, policy match
00:17:59: IP: route map FROM-10.10.10.1-TO-20.20.20.1, item 10, permit
00:17:59: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1 (Serial1), len 28, policy routed
00:17:59: IP: Ethernet0 to Serial1 131.108.1.6
00:17:59: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1, len 28, policy match
00:17:59: IP: route map FROM-10.10.10.1-TO-20.20.20.1, item 10, permit
00:17:59: IP: s=10.10.10.2 (Ethernet0), d=20.20.20.1 (Serial1), len 28, policy routed
00:17:59: IP: Ethernet0 to Serial1 131.108.1.6


Thanks to TripleH and Rick!

CASE CLOSED



By: Rick
Rick — Tue, 23 Jan 2007 11:50:21 +0000
There is no significant configuration error.

The route map did not take effect in the first configuration.

Reason: The policy only works on the router interface where it is applied to. The ping test was condected in R1 and the traffic did not pass that interface. So the policy did not work in your test run.

In the second configuration, the local policy works for the whole route, not the certain interface (Global command). That was why you could see it did work.

Also, don’t forget use sh access-list to verify the access-list and check whether the route-map is working.



By: David Sudjiman
David Sudjiman — Tue, 23 Jan 2007 10:15:22 +0000
[tripleH] Tried that using a host connected to R1E0. No Luck.

davids@nebuchadnezzar:~$ ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
64 bytes from 10.10.10.1: icmp_seq=1 ttl=255 time=7.85 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=255 time=3.01 ms

--- 10.10.10.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 3.016/5.436/7.856/2.420 ms
davids@nebuchadnezzar:~$ ping 131.108.1.1
PING 131.108.1.1 (131.108.1.1) 56(84) bytes of data.
64 bytes from 131.108.1.1: icmp_seq=1 ttl=255 time=3.25 ms
64 bytes from 131.108.1.1: icmp_seq=2 ttl=255 time=3.17 ms
64 bytes from 131.108.1.1: icmp_seq=3 ttl=255 time=3.14 ms

--- 131.108.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 3.141/3.190/3.256/0.081 ms
davids@nebuchadnezzar:~$ ping 131.108.1.2
PING 131.108.1.2 (131.108.1.2) 56(84) bytes of data.
64 bytes from 131.108.1.2: icmp_seq=1 ttl=254 time=35.8 ms
64 bytes from 131.108.1.2: icmp_seq=2 ttl=254 time=32.0 ms

--- 131.108.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 32.064/33.977/35.891/1.922 ms
davids@nebuchadnezzar:~$ ping 20.20.20.1
PING 20.20.20.1 (20.20.20.1) 56(84) bytes of data.
64 bytes from 20.20.20.1: icmp_seq=1 ttl=254 time=33.1 ms
64 bytes from 20.20.20.1: icmp_seq=2 ttl=254 time=32.3 ms
64 bytes from 20.20.20.1: icmp_seq=3 ttl=254 time=32.3 ms

--- 20.20.20.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 32.302/32.613/33.162/0.416 ms

davids@nebuchadnezzar:~$ traceroute 20.20.20.1
traceroute to 20.20.20.1 (20.20.20.1), 30 hops max, 40 byte packets
 1  10.10.10.1 (10.10.10.1)  3.028 ms  2.651 ms  2.906 ms
 2  131.108.1.2 (131.108.1.2)  24.913 ms  22.618 ms *



By: tripleH
tripleH — Tue, 23 Jan 2007 10:01:01 +0000
ip local policy = for traffic generated by the router itself, in your test you tried to ping from the router and not from the client…

the ip policy route-map will work for all traffic from the clients behind the router