Simple route-map path control prob

mguy

route-map POLICY, permit, sequence 10
Match clauses:
ip address (access-lists): CLIENT1
Set clauses:
ip next-hop 3.3.3.2
Policy routing matches: 20 packets, 2280 bytes
R4(config-ext-nacl)#do sh access-li
Extended IP access list CLIENT1
10 permit ip host 1.1.1.2 any (20 matches)

I have the above topology. I'm trying to to test path selection by pinging r2 from r1 (and it will fail)
*R1 has no ip routing but has default gateway, R4

I applied the route-map policy on f0/0 on R4

"ip policy route-map POLICY"

still does not work. Ideas?

is that right?

drkat

What does the routing table look like on R3 ? You're sending all packets from 1.1.1.2 to 3.3.3.4 for routing - so you're basically saying "to get to R2 go through R3 for any sourced traffic from 1.1.1.2"

NetworkVeteran

That access-list and policy-map are fine if you want R4 to forward all of R1's traffic to R3. They look good and work on my setup. If you want any sort of analysis, you're going to need to go beyond "does not work" and post the actual show and/or debug problems that you don't like. Accompany that with the real configs and you should be good to go!

mattau

as a refresher here, hows this possible to test policy routing with this lab? wouldnt it be better to create another segment behind R2 and R3 that is on the same subnet so there are 2 possible ways to get there. Either R4 forwards it to R2 or R3 depending on the policy?

NetworkVeteran

mattau wrote: »

as a refresher here, hows this possible to test policy routing with this lab?

One way would be to enable debugging commands on R4 to see which way the packets are going. Another would be to use show commands and monitor counters. Yet another would be to use a network sniffer such as Wireshark to view the packet flow.

wouldnt it be better to create another segment behind R2 and R3 that is on the same subnet so there are 2 possible ways to get there. Either R4 forwards it to R2 or R3 depending on the policy?

This would be the more natural scenario.

NetworkVeteran

Mattau, specifically, when I apply "ip policy route-map POLICY" on R4's fa0/0 interface and then ping from R1, I see this debug output--

R3 Output wrote:

R3#
*Mar 1 01:10:14.307: IP: s=1.1.1.2 (FastEthernet0/0), d=2.2.2.2, len 100, dispose ip.notgateway
R3#
*Mar 1 01:10:16.295: IP: s=1.1.1.2 (FastEthernet0/0), d=2.2.2.2, len 100, dispose ip.notgateway
R3#
*Mar 1 01:10:18.295: IP: s=1.1.1.2 (FastEthernet0/0), d=2.2.2.2, len 100, dispose ip.notgateway
R3#
*Mar 1 01:10:20.303: IP: s=1.1.1.2 (FastEthernet0/0), d=2.2.2.2, len 100, dispose ip.notgateway
R3#
*Mar 1 01:10:22.315: IP: s=1.1.1.2 (FastEthernet0/0), d=2.2.2.2, len 100, dispose ip.notgateway

This is conclusive evidence R4 performed policy-routing per the route-map.

R4 Output wrote:

R4#show route-map
route-map POLICY, permit, sequence 10
Match clauses:
ip address (access-lists): CLIENT1
Set clauses:
ip next-hop 3.3.3.2
Policy routing matches: 50 packets, 5700 bytes

The above is helpful, too!

mattau

ah I get you now. So we are just using R4 as the dummy test bed router to see the debugs to view where the traffic is going. Not so much gaining connectivity to the destination. Thanks

mguy

I got it.I made the error of configuring static routes in R2 and R3 to forward all traffic back to R4. So pings from R1 to R2 would be forwarded correctly by R4 to R3 BUT R3 would send it to R4 and R4 would pass it on to R2 (pings would succeed). I used wireshark for this and tested the theory.

mguy

NetworkVeteran wrote: »

One way would be to enable debugging commands on R4 to see which way the packets are going. Another would be to use show commands and monitor counters. Yet another would be to use a network sniffer such as Wireshark to view the packet flow.


This would be the more natural scenario.

i did a "show debug ip icmp" on R4 but did not really get anything. It was turned on in R2 and R3 but wireshark really revealed the answer

NetworkVeteran

mguy wrote: »

i did a "show debug ip icmp" on R4 but did not really get anything. It was turned on in R2 and R3 but wireshark really revealed the answer

That's because "debug ip icmp" doesn't display icmp echo-request messages, which are what ping sends out. Fortunately, Cisco IOS has many other commands that can help.

Learning the right show/debug commands for different situations is helpful.