cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
995
Views
0
Helpful
7
Replies

PBR difficulties

brad-denham
Level 1
Level 1

I am attempting to introduce a new UTM appliance within our network and I want to cutover subnets one at a time for testing purposes starting with us in IT.

Currently all user traffic not destined for our network follows a default route of 0.0.0.0 0.0.0.0 141.232.173.54 which points to the internal interface of our firewall. What I need to do is route Internet traffic for users on the 10.10.200.0/24 subnet through the new UTM appliance first before it gets sent over to our firewall and then out.

I have been experimenting with PBR but I can't seem to get it working correctly.

Below are snippets of the PBR config:

USER VLAN

interface GigabitEthernet6/0.200

description IT VLAN

encapsulation isl 200

ip address 10.10.200.2 255.255.255.0

no ip redirects

ip nbar protocol-discovery

ip policy route-map UTM

mls rp ip

no snmp trap link-status

standby 200 ip 10.10.200.1

standby 200 timers 5 15

standby 200 priority 110

standby 200 preempt

UTM VLAN

interface GigabitEthernet6/0.202

encapsulation isl 202

ip address 10.10.202.2 255.255.255.0

no ip redirects

no snmp trap link-status

standby 202 ip 10.10.202.1

standby 202 timers 5 15

standby 202 priority 110

standby 202 preempt

Route-map UTM permit 10

Match ip address 10

Set ip next-hop 10.10.202.4

Access-list 10 permit ip 10.10.200.0 0.0.0.255

After I have the configuration complete, and test from my laptop (10.10.200.19) I am following the all zeros route. I have verified this through a traceroute.

I am hoping that someone can point me in the right direction and show me what I may be missing.

Attached is a Visio 2002 file that provides a physical look at this configuration.

Thank you

7 Replies 7

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Brad,

I see there is

mls rp ip

in your g6/0.200 config are you using MLS with this device acting as RP for a L2 switch ?

In this case may be it is the L2 switch that has cached the normal routing entry that doesn't send the packets to this device and so PBR is not working

Hope to help

Giuseppe

Giuseppe,

Our core router isn't acting as a RP. its there for the NFFC on our SUP3 in our 5509 core switch. All inter-VLAN routing is being done on the core router.

Is this what is most likely causing my problem? Any way to work around it?

I have been begging for a 6509, but we are a newspaper and Ad revenue isn't what it used to be.

Hello Brad,

I was thinking it was a 5509 with NFFC using flow based multilayer switching.

We have still some of them on some sites.

To verify if MLS is effective on the L2 supervisor use

sh mls

and see if the RP mac-address is known.

on the RSM/RSFC use

sh mls rp

You should be using MLS with the RP= routing card RSFC or RSM.

This could be a problem of caching :

if you have just configured PBR but the NFFC cache has already an entry it uses it.

But entries are removed after some time of inactivity.

You can try to use a different flow mask:

on L2 supervisor use:

set mls flow [destination | destination-source | full].

this should at least reset the NFFC cache.

Hope to help

Giuseppe

Hey Giuseppe,

Below are the results of the sh mls command. I also ran a sh mls entry and this came back with no active mls rp.

When you asked about an RP earlier, I was thinking of something else completely. I'm not sure where else to look unless you see something I fat fingered with the core router config.

Brad

TRIBSW1> (enable) sh mls

Multilayer switching enabled

Multilayer switching aging time = 256 seconds

Multilayer switching fast aging time = 0 seconds, packet threshold = 0

Current flow mask is Destination flow

Configured flow mask is Destination flow

Total packets switched = 0

Active shortcuts = 0

Netflow Data Export disabled

Netflow Data Export port/host is not configured.

Total packets exported = 0

MLS-RP IP MLS-RP ID XTAG MLS-RP MAC-Vlans

---------------- ------------ ---- ---------------------------------

Hello Brad,

not all C5509 are really capable of performing multilayer switching:

we had a case some mounths ago.

the requirements are:

MLS is also supported on the following software and hardware:

• Catalyst 5000 series switch with Supervisor Engine software Release 4.1(1) or later.

• Cisco IOS Release 12.0W5 or later.

• Supervisor Engine IIG or IIIG with an RSFC daughter card.

#

Cisco IOS® Software Release 11.3(2)WA4(4) or later on the RSM, or on Cisco 7500, 7200, 4700, and 4500 series routers

#

Cisco IOS Software Release 12.0(3c)W5(8a) or later on the RSFC

Actually in your case if MLS is not operational there isn't a reason for PBR not to work.

The only trouble you should have is the lack of verify next-hop availability (CDP neighbor for routing card is the L2 supervisor).

I would suggest in a maintanence window to use the debug policy command to see what happens.

see also for MLS on C5500

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a00800ab513.shtml

Despite this issue if your system supports MLS it is wise to enable it because it will provide you a performance gain.

Hope to help

Giuseppe

Giuseppe,

Our 5509 does not have a RSM or an RSFC on the supervisor, all of our inter-VLAN routing is being handled on our core router. The router and 5509 have an ISL trunk that ties them together.

I have actually wondered about if the next-hop availability was an issue as well, but didn't think it would be due to the VLAN's being configured on the same interface on the same router. Maybe I am missing something.

Attached is the config from our core router that shows all of our VLAN's on Gigabit 6/0. If there is another config I could send that may help, please let me know.

Thank you,

Brad

Hello Brad,

ok the router is the only device that performs L3 routing and switching.

MLS is configured but not active.

I see that in the config you have attached:

route-map UTM permit 10

match ip address 101

set ip next-hop 10.10.202.4

!

but the ACL is 10 not 101

access-list 10 permit 10.10.200.0 0.0.0.255

access-list 101 doesn't exist

This if it isn't a mistyping explains why PBR doesn't work: the acl 101 doesn't exist so nothing matches the PBR route-map.

in your first post was:

access-list 10 permit 10.10.200.0 0.0.0.255

route-map UTM permit 10

match ip address 10

set ip next-hop 10.10.202.4

!

the command to be used for troubleshooting is debug ip policy

Hope to help

Giuseppe

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: