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...

Remove

ip local policy route-map prefroute

and try again from the workstation.

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"?

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 ?

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

I need to see packets with s=10.1.1.69

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....

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....

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

gee...so your's works and mine doesn't....

what version ios do you have running?

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....

Version 12.2(25)SEE4

I don't think it's an IOS version.

Can you post a show tech-support from the switch ?