Dot1Q Encapsulation

[VivSavage]

I have a situation in which 26 VLANs have been configured on a series of Cisco switches and they all feed to a Cisco router. For security purposes, the VLANs should NOT have any connectivity whatsoever. However, all the subinterfaces on the router are currently configured to use dot1Q Encapsulation so it is possible for someone on any VLAN to ping a host on another VLAN as the router will forward the traffic accordingly. And if they can ping, my thinking is that other traffic could cross VLAN boundaries as well.

After a little assistance from a couple posters here, I can now stop inter-VLAN traffic from happening by applying access lists on the router. However with 26 VLANs to manage I'm not too keen on that idea. If dot1Q Encapsulation enables inter-VLAN traffic, which I don't want, wouldn't I be better off to not use it? Does it serve any other purpose than that?

Since the router needs to act as the gateway for all VLANs, I'd need to configure it with a series of secondary addresses. My assumption is that using secondary addresses would not enable the router to pass traffic between VLANs like Dot1Q Encapsulation apparently does.

Bottom line, I need to make it as difficult as possible for traffic to go between VLANs. Any other thoughts or suggestions would be appreciated. Thanks.

 

[Degg]

you have to use some kind of encapsulation to setup trunking from the router to the switch so all the vlans will get to the router, unless you have a router with 26 physical ports. since all the Vlans are connected to the router, it will route between them regardless of whether they are dot1q or subinterfaces. You have to have ACL's to block traffic between the Vlans. with 26 Vlans, its going to be a lot of work.

Degg
Network Administrator

 

[VivSavage]

Ouch . . . I was afraid of that. I guess I'll get pretty good with ACLs. Thanks for your help.

 

[jneiberger]

You might be able to get really sneaky with Policy Based Routing and make this work with much less effort.

For example, you could apply PBR to the incoming subinterfaces. Create a list of approved next-hop destinations and then use PBR to enforce your routing decisions, like this:

1. Packet enters subinterface
2. PBR inspects the next hop and makes sure that this packet is not scheduled to be routed to one of your other subinterfaces
3. If packet is scheduled to go out an approved interface, then PBR allows the packet
4. If packet is scheduled to go out an unapproved interface then PBR will route it to a null interface.

I'm not even sure if this is possible, but it's food for thought. I'd be willing to try anything to avoid creating 26 different access lists!