12-17-2007 06:45 AM - edited 03-05-2019 08:02 PM
I am still working with route maps to make a particular route be the prefered route for certain destination addresses. My lab has 3750's for the switch at either end, 2-2800s for the routers at each end. The routers are all attached to a 7200 configured as a frame relay switch emulator in between. Pings back and forth work fine and the route map appears to work, if I ping from the switch at the "A" end to the switch at the "B" end of the link, and vice versa as well. Trace routes show that the routes are load balanced when they should be, and are prefering a special route when they should be...that is so long as I perform these operations from the switch.
But if I attach a workstation to one end and try to ping various addresses at the other end using that workstation it ALWAYS takes the least prefered route.
I thought at first it was not applying my route map statement. I checked, and the port to which my workstation is attached is configured in Vlan1 (by default) where the route map is applied. But even if that weren't set up right, then it *should* load balance and it doesn't even do that...
Below is key parts of config on the switch at the end where the workstation is, and the route table and traceroute results. Can anyone spot what is happening here?
SDM Prefer Routing was issued and the unit reset
IP Routing
interface Vlan1
ip address 10.1.1.11 255.255.0.0
ip policy route-map prefroute
router eigrp 1
network 10.1.0.0 0.0.255.255
no auto-summary
ip local policy route-map prefroute
ip route 0.0.0.0 0.0.0.0 10.1.2.103
access-list 118 permit ip any 10.128.0.0 0.63.255.255
access-list 118 deny ip any any
route-map prefroute permit 10
match ip address 118
set ip next-hop 10.1.1.33 10.1.1.22
SHOW IP ROUTE:
D EX 10.132.20.0/24 [170/442368] via 10.1.1.33, 2d04h, Vlan1
[170/442368] via 10.1.1.22, 2d04h, Vlan1
Traceroute from switch at 10.1.1.11 to 10.132.20.1:
1 10.1.1.33 0 msec 0 msec 8 msec
2 68.136.221.66 9 msec 8 msec 9 msec
3 10.32.1.1 8 msec * 0 msec
Tracert from workstation at 10.1.1.69 with def. gw = 10.1.1.11 to 10.132.20.1
1 <1 ms 2ms 2ms 10.1.1.11
2 1 ms 1ms 1ms 10.1.1.22
3 3 ms 3ms 3ms 172.20.45.153
4 5 ms 4ms 4ms 10.132.20.1
12-17-2007 06:55 AM
This may just be the way the load balancing is done. Generally "load-balancing" is a misnomer, and normally you have something that could be called "flow balancing". That is, traffic with any particular source and destination IP addresses will always take the same path. Change the source address, and it may take the other path. It just so happens that your router-to-destination flow takes one path, and your PC-to-destination takes another.
Have a look at show ip cef and show ip cef detail, and see if that gives you any clues.
Kevin Dorrell
Luxembourg
12-17-2007 07:34 AM
That's an odd behavior, according to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hirp_r/rte_pih.htm#wp1125447
"If the interface associated with the first next hop specified with the set ip next-hop command is down, the optionally specified IP addresses are tried in turn."
__________________
Don't expect load balancing with route-maps.
Also, the set ip next-hop option bypasses the routing table, so EIGRP does not come into the equation when calculating best path.
If you want to use the routing table and then PBR, you need to use set ip default next-hop
12-17-2007 08:59 AM
thank you both. Good information in the show ip cef detail.
Answering the question about what outcome I'm wanting...I have the routes being built by EIGRP so I expect two equal cost routes in the table and by default, I would expect load balancing across them. Now that I understand load balancing is not by packet but by flow, at least it makes more sense that the packet would take the same route every time.
I wanted to try to make certain destinations take one path over the other, but still be able to use the 'less' prefered path if the interface for the prefered route is down. Hence the route amp and the use of the next-hop with two ip addresses in it. For those destinations I want to bypass the routing table and just use the hops listed in order of preference.
Here's the interesting thing: When I show the IP CEF table I do see two routes to 10.132.20.0; listed with the least prefered route (10.1.1.22) listed first and per-destination as the choice. So the fact that my workstation picks .22 and stays there is now not so perplexing....
Except that the route map should be overriding that. Debug route-map does not show an increase in packets when I trace from the workstation to the address on the other side of the net, although it does for a traceroute issued from the switch itself.
Adding to the confusion: from the router if I do SHOW IP CEF EXACT-ROUTE (ws ip) (dest IP) it indicates that the exact route is to take 10.1.1.33!! Which is NOT what the workstation does! I've cleared IP ROUTE on the switch hoping to rebuild CEF but it built back the same way. I've changed the IP address on the workstation but I still get the same route...through the lesser prefered 10.1.1.22.
The interface is up for both "next-hop" ip addresses....
It very clearly is NOT applying my route map for the workstation, I just don't know why...
12-17-2007 09:13 AM
Remove
ip local policy route-map prefroute
and try again from the workstation.
12-17-2007 10:04 AM
ah, no help with that but...I did turn on debug ip policy and...it's pretty interesting.
for one thing, I see NO entries where the source is 10.1.1.69, meaning indeed my policy map is not even being applied to the inbound interface where this workstation is connected.
I do however see entries for the response from 10.1.1.11 going out to 10.1.1.69, saying the policy is rejected and normal processing will occur. Which means the map works on the inbound interface of Vlan1 (10.1.1.11 is the IP assigned to int Vlan1).
So that means I have completely misunderstood how to apply my policy map.
I read in various docs that the policy map is applied to INBOUND traffic for the interface in question.
I read that to mean vlan1.
Is it possible there's some odd restriction to the route map where vlan1 (default vlan) is concerned? I have searched all over internet not finding anything to that effect.
Have I misunderstood the use of the word "inbound" in this context? From what interface would traffic generated by workstation on vlan1 be considered "inbound"?
12-17-2007 10:31 AM
No, you got it right. It needs to be place on the ingress interface, on this case Vlan1.
Can you post the debug ip policy output ?
12-17-2007 10:42 AM
Sure:
01:16:49: IP: s=10.1.1.11 (local), d=10.1.1.69, len 73, policy rejected -- norma
l forwarding
01:16:49: IP: s=10.1.1.11 (local), d=10.132.20.1, len 28, policy match
01:16:49: IP: route map VERIZON, item 10, permit
01:16:49: IP: s=10.1.1.11 (local), d=10.132.20.1 (Vlan1), len 28, policy routed
01:16:49: IP: local to Vlan1 10.1.1.33
12-17-2007 11:05 AM
I need to see packets with s=10.1.1.69
12-17-2007 11:19 AM
that's the problem...there aren't any....even though 10.1.1.69 is the address of the ws generating my tests. What I'm infering that to mean is, the policy is not being applied to the interface that unit connects to therefore, there is nothing in the ip policy debug output.
What I don't know is why that would be. Or maybe I'm barking up the wrong tree....
12-17-2007 11:38 AM
that's the problem...there aren't any....even though 10.1.1.69 is the address of the ws generating my tests. What I'm infering that to mean is, the policy is not being applied to the interface that unit connects to therefore, there is nothing in the ip policy debug output.
What I don't know is why that would be. Or maybe I'm barking up the wrong tree....
I changed the vlan my ws was on and gave it an appropriate IP address. It now takes the prefered route for everything....regardless of destination. Still debug ip policy does not show this new address a a source of traffic....I gotta be misunderstanding what the debug output represents...or at what point it is generating its output....
the output "debug ip policy" gives me after I ping from my workstation (now 10.10.16.2) is ALWAYS from 10.10.16.1 to 10.10.16.2...as if the only thing it outputs is the return traffic from that traceroute command....
grrr....I feel like I have a big brick in my head where my brain should be....
12-17-2007 11:40 AM
I did a recreate with your config (verbatim).
00:12:48: IP: s=10.1.1.69 (Vlan1), d=10.132.20.1, len 100, FIB policy match
00:12:48: IP: s=10.1.1.69 (Vlan1), d=10.132.20.1, g=10.1.1.33, len 100, FIB policy routed
00:12:50: IP: s=10.1.1.69 (Vlan1), d=10.132.20.1, len 100, FIB policy match
00:12:50: IP: s=10.1.1.69 (Vlan1), d=10.132.20.1, g=10.1.1.33, len 100, FIB policy routed
interface Vlan1
ip address 10.1.1.11 255.255.0.0
ip policy route-map prefroute
access-list 118 permit ip any 10.128.0.0 0.63.255.255
access-list 118 deny ip any any
route-map prefroute permit 10
match ip address 118
set ip next-hop 10.1.1.33 10.1.1.22
12-17-2007 11:46 AM
gee...so your's works and mine doesn't....
what version ios do you have running?
12-17-2007 11:48 AM
gee...so your's works and mine doesn't....
what version ios do you have running?
I noticed your debug output specified 10.1.1.69 is in vlan 1. All I ever get is the local stuff....
12-17-2007 11:49 AM
Version 12.2(25)SEE4
I don't think it's an IOS version.
Can you post a show tech-support from the switch ?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide