VLAN ACL Query

[Hulkster]

I wish to add 2 VLANs to an existing Layer 3 switch. I am currently testing using another switch with the same config.

I want them to be able to talk to eachother, but not to the main VLAN (VLAN1). I've added ACLs In/Out (to allow dest/source of new VLAN IP ranges) on the new VLAN interfaces (not touched Vlan1) and everything is working as I wish, expect that hosts on VLAN1 can still ping the layer 3 interfaces for the new VLANs that live on the switch..despite the only permit rules being for IPs in the new subnets. They cannot get any further, though. I don't really want the new addresses pingable from production machines, and I would rather not add ACLs to VLAN1.

Any ideas where I am going wrong? Sorry if this is a little vague!

 

[V-Spec]

I wish to add 2 VLANs to an existing Layer 3 switch. I am currently testing using another switch with the same config.

I want them to be able to talk to eachother, but not to the main VLAN (VLAN1). I've added ACLs In/Out (to allow dest/source of new VLAN IP ranges) on the new VLAN interfaces (not touched Vlan1) and everything is working as I wish, expect that hosts on VLAN1 can still ping the layer 3 interfaces for the new VLANs that live on the switch..despite the only permit rules being for IPs in the new subnets. They cannot get any further, though. I don't really want the new addresses pingable from production machines, and I would rather not add ACLs to VLAN1.

Any ideas where I am going wrong? Sorry if this is a little vague!

The reason they can all ping each other is because all the SVIs (vlan interfaces) are sharing the same routing table, and obviously the inter-vlan routing has no control over it, unless you add ACLs - which is always a painful affair.

If it's a layer-3 switch, I'm assuming it's a 3550 or better? if it's running a decent layer-3 image and IOS you should be able to put the two interfaces you want to keep seperate from Vlan 1, into a VRF (different routing table)


so the config would look something like this:

ip vrf Hulkster
rd 1:1

interface vlan 1
ip address x.x.x.x/x

interface vlan 10
ip vrf forwarding Hulkster
ip address x.x.x.x/x

Interface vlan 20
ip vrf forwarding Hulkster
ip address x.x.x.x/x


So basically, vlans 10 and 20 would inter-vlan route between each other, only in the Hulkster VRF (because those interfaces are inside that routing table) Vlan 1 would continue to use the default routing table, and would not be able to talk to either of those interfaces, no need for any ACLs - as it's part of a separate routing table.

If you do a 'show ip route' you'll see the default routing table,

If you do a 'show ip route vrf Hulkster' you'll see the routes for that routing table.

The fact those interfaces are part of a VRF has no effect on the layer-2 element, switched layer-2 access ports will still use the SVI as their gateway so long as hosts are forwarding traffic to it..

If you can't do VRF, then your only option is a whole bunch of ACLs.

 

[Plus1]

Vrf-lite is too major for this, management would be hell if he doesn't have a clue.
Would suggest trunking the interfaces, and allowing only the newly created vlans access, while making one of them the native vlan. An access-list to say.

access-list 100 permit ip source/destination
access-list 100 permit ip destination/source
an implicit deny all will be followed.

Just a suggestion.

 

[Hulkster]

Thanks for the input chaps. A second routing instance did cross my mind - but I am not too sure how to do this on an HP5500G (i should have mentioned the switches I am using!). I will refer to the Layer 3 config documentation.

The ACL creation isn't really an issue; I just wanted to keep the filtering on the new VLAN interfaces. If the IP interface of the new VLAN can be pinged, it's not really the end of the world - the reality is however that in the real solution, no hosts will have the switches in question as their default gateway, so there won't be routes to it from production workstations.

Trunking is not required as they all exist on the same single switch so there are no additional connections to allow/deny specific VLANs over.

I will check out how to create a separate routing table.