10-31-2008 01:20 PM - edited 03-06-2019 02:14 AM
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
10-31-2008 03:55 PM
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
10-31-2008 06:46 PM
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.
11-01-2008 03:18 AM
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
11-01-2008 08:54 PM
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
---------------- ------------ ---- ---------------------------------
11-02-2008 01:08 AM
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
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
11-03-2008 11:46 AM
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
11-03-2008 12:12 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide