Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

Policy based routing issue

We are implementing policy based routing for a customer who has a cisco 2801 router.

He needs to send www, ftp, icmp traffic to ip address 192.168.1.50 and everything else including smtp to 192.168.1.38. both these ip addresses are on the local lan, 192.168.1.x . fastethernet 0/0 is 192.168.1.1

config is below, any ideas why this is not working ?

interface FastEthernet0/0

ip address 192.168.1.1 255.255.255.0

ip policy route-map normal

!

access-list 101 permit tcp any any eq www

access-list 101 permit tcp any any eq 443

access-list 101 permit tcp any any eq ftp

access-list 101 permit tcp any any eq echo

access-list 102 permit tcp any any eq smtp

access-list 102 permit tcp any any

route-map normal permit 10

match ip address 101

set ip next-hop 192.168.1.50

set ip default next-hop 192.168.1.50

!

route-map normal permit 20

match ip address 102

set ip next-hop 192.168.1.38

set ip default next-hop 192.168.1.38

10 REPLIES

Re: Policy based routing issue

Hi

Can you revert y u r configuring both ip next-hop as well as default next-hop ??

hope ur aware that next-hop straight away does the policy routing regardles of the availability of the route in the routing table.

but its not the case with default next-hop which checks up the routing table and if it sees the route for the destination network it will take normal routing process to do so.if theres no route present in the routing table then it does policy routing ..

BTW hows the behaviour here ?? is it taking normal routing path or how you say that its not working out here ?

regds

Community Member

Re: Policy based routing issue

hi,

i have tried this with just the default next-hop and then also just the ip next hop.

there are no ip routes in the routing table on both occations.

the debug messages just mentioned about policy rejected -- normal forwarding.

but this is when i initiate internet explorer which would match one of the access lists , this should then use the 192.168.1.254 address in the route-map statement.

any ideas

Hall of Fame Super Gold

Re: Policy based routing issue

Chris

There are a couple of things about your statement of the requirements and this configuration that deserve comment. You state that they want to send icmp to 192.168.1.50 but the closest you come to that is when the access list 101 tests for tcp eq echo. The tcp echo is not the same as the icmp ping echo. And there is no test in the access list for any icmp. So if your statement was correct about wanting to send icmp to 192.168.1.50 then the access list needs some adjustment.

Also in your statement of the requirements you say that everything else should be sent to 192.168.1.38. Is there some reason that you are not setting a default route to route everything else to that address rather than using Policy Based Routing? Secondarily I think the way that you have constructed instance 20 of the route map will not accomplish your stated requirement. In instance 20 you match against access list 102. But 102 does not catch everything else, it only catches tcp traffic. So no UDP traffic is affected, or ICMP, or any IP traffic that is not TCP. If you really want an access list here it should include the permit ip any any. And I would suggest that if you really want PBR to send everything else to the address you specify that instance 20 should have the set statement but not the match statement. The set without a match statement is a much more reliable way to be sure that you catch all other traffic.

HTH

Rick

Cisco Employee

Re: Policy based routing issue

The "ip policy route-map" has to be applied to the inbound interface. Fa0/0 is the outbound interface in your scenario.

two more things.

1- "access-list 101 permit tcp any any eq echo" will not match icmp packets. It needs to be as follow:

access-list 101 permit icmp any any

2- "access-list 102 permit tcp any any" will not match all remaining packets. It needs to be:

access-list 102 permit ip any any

Hope this helps,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Community Member

Re: Policy based routing issue

i have now altered the config to the following

access-list 101 permit tcp any any eq www

access-list 102 permit ip any any

!

route-map test permit 10

match ip address 101

set ip default next-hop 192.168.1.254

!

route-map test permit 20

match ip address 102

set ip default next-hop 192.168.1.252

ping is now working, however, web traffic is still not working and goes to policy 20 instead of policy 10

Hall of Fame Super Gold

Re: Policy based routing issue

Chris

Are you saying that access list 101 is now just a single line? If so I suggest that you add the line access-list 101 permit tcp any any eq 443

try this and let us know what happens.

HTH

Rick

VIP Purple

Re: Policy based routing issue

Hello all,

wouldn´t you also need UDP 53 for DNS to go through permit 10, that is:

access-list 101 permit udp any any eq 53

I am not sure what happens to the web traffic when the accompanying DNS lookup goes through another interface...

Regards,

GP

Hall of Fame Super Gold

Re: Policy based routing issue

Georg

As long as the name gets resolved why does it matter where the request is sent? In fact I think it would be quite common that DNS requests get routed to a DNS server on the inside of the network through one interface while the default route for Internet access is out a different interface of the router.

HTH

Rick

VIP Purple

Re: Policy based routing issue

Rick, Chris,

I guess my reasoning was based on what 192.168.1.252, the next hop for, as it is configured now, DNS traffic, does with those DNS requests.

Can you try and put an IP address in your web browser instead of a www address, e.g.:

http://198.133.219.25

in order to confirm that it is NOT a DNS problem ?

Regards,

GP

Community Member

Re: Policy based routing issue

Yeh already tried that and still no joy.

I have tried some testing on a lower release of code and it seems to be working now.

281
Views
0
Helpful
10
Replies
CreatePlease to create content