Route-Map Help.

Answered Question
Apr 11th, 2008
User Badges:

Hello,

I am attempting to create an environment where my current production traffic continues to use the current route to the current firewall but traffic from a specific network to the same destination is directed to a different firewall to head to the internet.


Current Static route

ip route 172.1.20.0 255.255.255.0 10.1.1.1


Instead I want to have the following:

Traffic from 10.2.1.1 destined to 172.1.20.0 needs to go to firewall 10.1.1.50

all other traffic destined to 172.1.20.0 needs to continue to go to firewall 10.1.1.1


Please let me know your suggestions.. Thanks in advance.




Correct Answer by Edison Ortiz about 9 years 2 weeks ago

This configuration will be better:


interface vlan 102

ip policy route-map firewall-test


access-list 102 permit ip 10.2.1.0 255.255.255.0 172.1.20.0 255.255.255.0


route-map firewall-test permit 10

match ip address 102

set ip default next-hop 10.1.1.50



In short, traffic not matching the src/dst pair from the ACL will take the normal routing table so please leave your static routes as they are today.


HTH,


__


Edison.




  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
p-blake Fri, 04/11/2008 - 10:59
User Badges:

Will I need to eliminate the current static route when implementing the new PBR?

Edison Ortiz Fri, 04/11/2008 - 11:01
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

No.

Richard Burts Fri, 04/11/2008 - 11:13
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Paul


Policy Based Routing does not change the existing routing process. PBR acts as an over-ride to the normal routing decision for certain traffic that you identify through an access list in a route map.


When properly implemented your traffic from the specified subnet will use the alternate firewall and all other traffic will continue to use the existing static route.


HTH


Rick

p-blake Fri, 04/11/2008 - 11:14
User Badges:

Based on the original criteria is the following headed in the right direction? Do I need to add a 3 access list for ALL of the other traffic that currently has static route assignments so that they are not broken in the process?


access-list 102 permit ip 10.2.1.0 255.255.255.0 172.1.20.0 255.255.255.0

access-list 103 permit ip 0.0.0.0 0.0.0.0 172.1.20.0 255.255.255.0


interface vlan 102

ip policy route-map firewall-test


route-map firewall-test permit 10

match ip address 102

set ip default next-hop 10.1.1.50

route-map firewall-test permit 20

match ip address 103

set ip default next-hop 10.1.1.1




Thanks..



Correct Answer
Edison Ortiz Fri, 04/11/2008 - 11:19
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

This configuration will be better:


interface vlan 102

ip policy route-map firewall-test


access-list 102 permit ip 10.2.1.0 255.255.255.0 172.1.20.0 255.255.255.0


route-map firewall-test permit 10

match ip address 102

set ip default next-hop 10.1.1.50



In short, traffic not matching the src/dst pair from the ACL will take the normal routing table so please leave your static routes as they are today.


HTH,


__


Edison.




p-blake Fri, 04/11/2008 - 11:23
User Badges:

Did I mix up the masks on the access-list? they are supposed to be wildcard masks and not network masks right? Just want to make sure for my scripts.


Thanks..


Edison Ortiz Fri, 04/11/2008 - 11:25
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

yes, they should be inverse-mask 0.0.0.255 :)


You should also use the "set ip next-hop" instead of the "set ip default next-hop".


The latter inspects the routing table before performing the route-map. You want the former.



p-blake Fri, 04/11/2008 - 12:07
User Badges:

I am not getting a hit on the access list or on the route map when we are trying to test this. any thoughts?


p-blake Fri, 04/11/2008 - 12:32
User Badges:

I think I got it working. I had moved the policy map to the interface where the originating device was sitting, not the outbound interface. That seems to have it working.


Thank you for all of your help.



Actions

This Discussion