cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
860
Views
0
Helpful
10
Replies

Route-Map problem - not identifying / routing any packets

bill.morton
Level 1
Level 1

Working on a 3560 c3560-i5-mz.122-20.SE3.bin

Setup computer of interest is in Vlan1

Default gateway points to Pix with VPN link to second site, however I want to use a route map to identify and change the direction of database traffic destined for a specific host to use a T1 PtP connection.

ip access-l e DBWorkers

10 permit ip any 192.168.1.1 0.0.0.0

ip access-l e OtherTraffic

10 permit ip 192.168.2.0 0.0.0.255 any

route-map DB permit 5

match ip address DBWorkers

set ip address next-hop 192.168.2.253 (router in this subnet with the point-to-point T1)

route-map DB permit 10

match ip address OtherTraffic

set ip address next-hop 192.168.2.1 (default gateway/pix w/vpn)

----- All of this seems ok, but when I check it dosn't seem like the route-map is working at all.

#sh ip policy

interface route map

local DB

#sh route-m

Route-map DB, permit sequence 5

match clauses:

ip address (access-lists)DBWorkers

Set Clauses:

ip next-hop 192.168.2.253

policy routing matches (this number never changes)

Route-map DB, permit, sequence 10

Match clauses:

ip address (access-lists): OtherTraffic

ip next-hop 192.168.2.1

policy routing matches (this number never changes)

#sh ip cache policy

<no listings>

#sh route-m ipc

0 0 0 0 0 (All counters 0)

-----

The configuration does have ip routing enabled, cef enabled, ip local policy route-map DB, ip route-cache policy on Vlan1 (which is in use).

I just saw that it does have 'no ip classless' in the config ... humm.

I have made changes to the route-maps and access-lists without clearing/reloading/or reapplying anything since I am working on a production network.

any ideas?

10 Replies 10

You need to enable policy routing on the interface. Local policy routing only applies for traffic generated from the router itself. Configure this on the interface.

int vlan 1

ip policy route-map DBWorkers

HTH

Sundar

Richard Burts
Hall of Fame
Hall of Fame

Bill

A little more information would be helpful. You mention that you have configured ip local policy route-map DB. This will policy route any traffic that is originated by the router itself. It will not affect any traffic received on any router interface to be routed. Have you configured ip policy on any interfaces?

Also I notice that one access list selects traffic with a source address of 192.168.1.x and the other access list selects traffic with a source address of 192.168.2.x. Both access lists are used within the route map. Where is the 192.168.1.0 network and where is the 192.168.2.0 network? Do both of the interfaces through which they connect have ip policy configured? Remember that you need to configure ip policy on the interface where the traffic enters the router, not on the interface through which it exits the router.

I am also curious about the topology of the network. Your OtherTraffic access list selects traffic with source address of 192.168.2.x and then the route map sets a next hop of 192.168.2.1. So are you routing it back out the interface on which it arrived?

While I generally advocate that ip classless is better than no ip classless, I am not sure that this aspect is related to your issue. I suggest that you change to ip classless, but do not really expect it to change the behavior you are having problems with.

HTH

Rick

HTH

Rick

I'll get some more infomation posted soon, however, I wanted to give a quick reply that this is a 3560 Switch vs a Router (although it does have ip routing enabled). Given the suggestions so far that could cause an issue, as the traffic that I want to affect is in the native VLAN, so in effect it is not going through any L3 interface. This may be why it seems to work in my lab but not on the switch.

Bill

I think it would help if you could give us a bit more explanation about your environment and your network topology. Because right now I am a bit confused.

I am especially confused about your comment that the traffic does not go through any L3 interface. Policy Based ROUTING is for when you are routing traffic. If it is really not going through any L3 interface then PBR is not going to work.

So please help me understand where is 192.168.1.0 and where is 192.168.2.0?

It seems logical to me that Sundar's suggestion to put ip policy on interface vlan1 would be the thing to do. Perhaps if we understand better what your situation is, we might be able to give better answers.

HTH

Rick

HTH

Rick

Ok, a quick note before getting into the topology. I have a feeling that I have run into a bug that is causing these problems, however I have yet to master finding a productive way to use the bug-toolkit to get information that is relivent to what I want.

Topology:

SITE1 SITE2

Pix-----internet---------Pix

3560----2811T1---2811T1--HPSwitch

So there are 2 paths between site 1 and site 2. One, the default over an internet VPN terminated at a Pix at each site. Two, a private T1 Point-to-Point. Only 'high' priority database traffic and VoIP are to use the T1, and everything else goes over the VPN. This setup was already configured and assumed to be working though I have my doubts now. The only thing I was trying to do was add a few more hosts to the high priority T1 link by modifying the existing ACLs.

If any of this information conflicts with the first post, ignore the first post.

Site 1 is 192.168.1.0/24

Site 2 is 192.168.2.0/24

Site1:

3560 Vlan 1: 192.168.1.1

2811 fa0/0: 192.168.1.2

2811 fa0/1: (T1) 10.0.0.1/30

Pix: 192.168.1.253

Host: 192.168.1.100

Default gw: 192.168.1.253 (pix)

Site 2:

Pix: 192.168.2.253

2811: fa0/0: 192.168.2.2

2811: fa0/1: (T1) 10.0.0.2/30

HP Switch [notshown]: 192.168.2.1

DB Server: 192.168.2.100

Default gw: 192.168.2.253 (Pix)

The switches at both sites are setup with a mess of static routes and ip routing; all of hte hosts at each site use the switch Vlan1 IP as their default gateway, which in turn have their default gateway set as the Pix.

A route-map is enabled at site 1 to identify traffic from specific hosts in Site 1 to the DB server at site 2 to use the PtP T1 instead of the VPN/Default route. Site 2 switch has a mess of static routes to send the traffic back since it is not capable of routing/route-maps.

So I build an access list on site 1 switch:

ip access-list e DBTraffic

permit ip host 192.168.1.100 host 192.168.2.100

I build an access list on site 1 switch:

route-map Database permit 5

match ip address DBTraffic

set ip next-hop 192.168.1.253 (2811)

I apply that ACL to VLAN1

int vlan 1

ip policy route-map Database

ip route-cache policy

and I consider myself done. This is a bit simplified, but let me check a few of my assumptions. When referencing an ACL in a route map, if any statement in the ACL matches, it will apply the route-map condition (right)? Would this include deny statements? Route-maps are sequential, after the first match, the rest of the route-map is ignored. Multiple match statements in 1 line are logical 'OR' multiple match statements are logical 'And'

When I try to debug the policy map, there are no hits, and the access-list counters don't increment. Everything routs as if it were going straight to the routing table. I have applied the SDM prefer Routing template, and I do have an EMI image. I am starting to conclude that it is a bug in IOS or the hardware ACLs.

Bill

The additional information is helpful. I have a better (but not complete) understanding of what is going on. I have a couple of comments or questions:

- route-map Database permit 5

match ip address DBTraffic

set ip next-hop 192.168.1.253 (2811)

your parenthesis says 2811 but the info in beginning of the post says .253 is the PIX. which is it?

- your verbal description says that hosts are configured with their default gateway as the switch vlan interface. But the chart info has:

Default gw: 192.168.1.253 (pix)

which address is the default gateway?

If the PIX inside interface is in the same subnet as the hosts it will be difficult (at best) to get PBR to work, and if the PIX is configured as default gateway I believe it is impossible for PBR to work. If a host (192.168.1.x) is sending to some destination (192.168.2.y) and sends it to the vlan interface for forwarding, the switch should forward to the PIX and will send an ICMP redirect to the host indicating a better way to get to the destination. If the PC continues to forward to the vlan interface then PBR has some chance of working. If the PC begins forwarding to the PIX, or if the PC default gateway is the PIX then all traffic goes through the PIX and PBR has no chance.

It looks to me like if it is important for the PBR to work effectively then some re-design of the network is needed. If the PIX is in a separate subnet (perhaps even just in a separate VLAN on the switch) then you have a chance for PBR to do what you want. But with the PIX in the same subnet (in the same VLAN) then I understand your comment about traffic not going through a L3 interface.

HTH

Rick

HTH

Rick

Rick, sorry for the mix-up - I keep bouncing back and forth between the addresses that are actually in use and making a clear example which is turning out to not be quite as effective as I would wish. Route-map Database permit 5 should be 'set ip next-hop 192.168.1.2'

The hosts on the network use the Switch VLAN1 SVI address as their default gateway. The switch has a default gateway (and static routes) of the Pix.

Everything in Site 1 is in the default VLAN1 (pix, switch, 2811). I am trying to identify certain traffic based on source/destination and use a route-map to make the traffic go to the 2811 router with T1 link, instead of the (pix) which is being determined by the switch.

The destinations at Site 2 are in a separate subnet, so I would think that the site 1 traffic that is destined for site 2 has to go through the VLAN1 interface which may give the route-map a chance to be applied; but you have hit on my big question. Will this actually work or will route maps only be effective on routed interfaces?

So just to recap - normal traffic from hosts is sent to the switch VLAN1 SVI (the host's default gateway is set as the switch address), traffic we want to manipulate needs to be redirected to the 2811 instead of the switches default route to the pix.

I havent really found any great info on the down & drity on PBR, so if you could expand on the ICMP redirect process it would be greatly appreciated. If the PBR does not re-write the packet header, what you say makes sense; I just wonder if the ICMP redirect could be made effective in an WinXP envrionment.

As I piece this together, it seems that it would best to have the switch with two different routed interfaces / VLANs to be able to send the traffic down that are not in the same VLAN/subnet as the sending host.

But even so, if the switch has both the default gateway and the 2811 as adjacent nodes, it still seems possible it can PBR between the two by redirecting the traffic to the approperiate interface.

Thanks for you help.

Bill

First I would like to verify a couple of things:

- am I correct in assuming that ip routing is enabled on the switch?

- is it true that at this point the ip policy route-map is configured on the vlan 1 interface of the switch?

Assuming that those are right then try configuring this under interface vlan 1:

no ip redirect

Give that a try and let us know if the behavior changes.

HTH

Rick

HTH

Rick

Bill

Another thought just occurred to me: what SDM template is the switch running? You can find this by using the command show sdm prefer

PBR is not supported in the default and VLAN templates. So if the switch is running one of these you would need to change it to the routing template. You change it using the command sdm prefer routing. Note that this change does require a reboot of the switch.

HTH

Rick

HTH

Rick

Rick-

Yes, IP routing is enabled.

ip policy route-map is configured on vlan 1 SVI.

SDM prefer is 'desktop routing' (I did find and check that in the documentation)

I'll try the no ip redirect

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco