What I thought was going to be a simple 5 minute procedure ended up taking 3 hours! My goal was very simple - add some security amongst a set of VLANs on a Cisco 6000 (CatOS 7-6-17) switch based on the following requirements:
-VLAN 30 cannot initiate connections to VLAN 50 and VLAN 60 but must get to the Internet
-VLAN 50, is the Admin VLAN and can get to everything
-VLAN 60 cannot initiate connections to VLAN 50 and VLAN 30 but must get to the Internet
Piece of cake, right? I quickly define the filters on the MSFC, deciding, as it should be to place the filters closest to the initiating traffic on VLANs 30 and 60 and have no filters on VLAN 50. The configuration turned out to be like this:
interface Vlan30
description Corp VLAN
ip address 10.30.0.2 255.255.0.0
ip access-group 130 in
!
interface Vlan500
description Admin VLAN
ip address 10.50.0.2 255.255.0.0
!
interface Vlan600
description Test VLAN
ip address 10.60.0.2 255.255.0.0
ip access-group 160 in
ip route 0.0.0.0 0.0.0.0 10.30.0.11
access-list 130 permit tcp any any established
access-list 130 deny ip 10.30.0.0 0.0.255.255 10.50.0.0 0.0.255.255
access-list 130 deny ip 10.30.0.0 0.0.255.255 10.60.0.0 0.0.255.255
access-list 130 permit ip any any
access-list 160 permit tcp any any established
access-list 160 deny ip any 10.50.0.0 0.0.255.255
access-list 160 deny ip any 10.30.0.0 0.0.255.255
access-list 160 permit ip any any
We begin testing this and yay, the traffic from VLAN 30 to 50 is blocked and....then... wait a minute now it's not blocked. I check the hit counter on ACL 130 and there were a couple denies from 10.30.0.0/16 to 10.60.0.0/16 but nothing more. What's going on here? We test from VLAN 30 to VLAN 50 and then from VLAN 60 to both VLAN 30 and VLAN 50 - the same result. The first packet observe the filter rules but thereafter access to each VLAN from any other VLAN is wide open. Grrrr!
At this point I know that my filters are good - there's no rocket science to setting these so I figured that it must be beyond just the filter that was causing this. The clue that led me to the solution was the result of a trace route from a source device (10.30.0.20) to 10.60.0.20. The icmp packet got there in just one hop! Now I expected the VLAN interface hop first before getting to the destination. This wreaked of a cached entry somewhere. But, how did it bypass the Layer 3 routing functionality or...did it? And then it hit me! My theories of Multilayer Switching (MLS) came flooding back and I remembered how the switch consults the router for the initial routing of the packet (Router on a Stick) and then caches the Layer 3 entry in the switch itself for subsequent routing of the paket (Layer3 switching). Of course!
Remember, I had not worked on a Cisco 6000 switch for years so I had to do some digging and found that MLS is enabled by default on this switch (with an MSFC of course). To disable it, merely add the 'no ip mls' command to each VLAN interface. So for VLAN30 it looked like this:
interface Vlan30
description Corp VLAN
ip address 10.30.0.2 255.255.0.0
ip access-group 130 in
no ip mls
I did this on all three layer 3 interfaces and the filters are now doing the work it was supposed to. You can clear the MLS cache by issuing clear mls on the switch itself.
Switch Details
WS-C6009 Software, Version NmpSW: 7.6(17)
System Bootstrap Version: 5.3(1)
System Boot Image File is 'bootflash:cat6000-supk8.7-6-17.bin'
Modules:
WS-X6K-SUP1A-2GE
WS-F6K-PFC
WS-F6K-MSFC2
MSFC:
ROM: System Bootstrap, Version 12.1(3r)E2, RELEASE SOFTWARE (fc1)
BOOTLDR: MSFC2 Software (C6MSFC2-BOOT-M), Version 12.1(8b)E9, EARLY DEPLOYMENT RELEASE SOFTWARE (fc3)
cisco Cat6k-MSFC2 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD04450FV5
No comments:
Post a Comment