Multiple VLANs on an IP interface

kfowler1960 · ‎10-22-2010

I am trying to understand whether it makes any sense to assign multiple VLANs to a single IP interface. The cisco router lets me do it, but I haven't figured out whether its a valid configuration.

Tagged packets arriving with one of the configured VLANs would probably be accepted and and processed (after stripping Ethernet header and vlan tag). But for packets in the reverse direction how would the router behave? How would it know which VLAN ID to put on the packet. Would it just punt and not tag it at all?

In the configuration I'm thinking about, the packets are coming from a single IP interface (non-Cisco gear) and are being tagged according to higher layer rules.

(not cisco)10.10.10.1: ----vlan10 + vlan20------- 10.10.10.2 (cisco)

!
interface FastEthernet2/0
ip address 10.10.10.2 255.255.255.0
duplex half
speed 10
vlan-id dot1q 10
exit-vlan-config
!
vlan-id dot1q 20
exit-vlan-config
!
no mop enabled
end

Thanks,

K.

Peter Paluch · ‎10-22-2010

Hi Kevin,

The vlan-id dot1q command is used in specific situations, mostly in broadband access concentrator scenarios. These scenarios include configuring a PPPoE access server functionality on an interface that has no IP address configured itself because it is not required for PPPoE operation, for example:

interface FastEthernet0/0

pppoe enable group global

Understandably, in large deployments, it may be useful to split the clients' PPPoE accesses into different VLANs according to technical or administrative requirements. The configuration would then be similar to:

interface FastEthernet0/0

no shutdown

!

interface FastEthernet0/0.101

encapsulation dot1q 101

pppoe enable group Group1

!

interface FastEthernet0/0.102

encapsulation dot1q 102

pppoe enable group Group2

!

interface FastEthernet0/0.103

encapsulation dot1q 103

pppoe enable group Group3

! ... and so on

This configuration is straightforward and understandable but it has a serious limitation: each subinterface consumes one Interface Descriptor Block - a data structure operated by IOS, internally describing the interface, its functions, operation and settings. There is a limit on the maximum number of IDBs in each IOS version, and if the IDB space is exhausted, no new interfaces or subinterfaces can be added to the configuration (check the show idb command in your router). In large deployments, creating hundreds of subinterfaces could indeed exhaust the available IDB space. Therefore, a new command, vlan-id dot1q was created to allow configuring the PPPoE access (and bridge-groups) on an interface without creating subinterfaces and allocating IDBs. The previous example could be rewritten as follows:

interface FastEthernet0/0

no shutdown

!

vlan-id dot1q 101
pppoe enable group Group1
exit-vlan-config
!
vlan-id dot1q 102
pppoe enable group Group2
exit-vlan-config
!
vlan-id dot1q 103
pppoe enable group Group3
exit-vlan-config
!

As all these PPPoE access server configuration are now placed on a single interface, only one IDB is allocated.

So this way of configuring VLANs on a routed interface is actually not intended to be used in IP scenarios where an IP address is configured on an interface. Note that you cannot configure an IP address specifically inside the vlan-id dot1q stanza. If this interface is to have an IP address, it will always be configured on the global interface level. The IP packets sent by such interface would always be untagged. Essentially, such an interface behaves just as a normal untagged IP interface, PLUS some special PPPoE functionality on explicitly declared VLANs. For dealing with IP networks and VLANs properly, you still have to create subinterfaces.

I hope this helps a bit.

Best regards,

Peter

kfowler1960 · ‎10-24-2010

Thanks Peter,

your explanation explained both why the configuration "took" and why it was not what I am really after.

After more research, the type of configuration I was looking for is that described in RFC 3069 on VLAN Aggregation. My understanding is that this RFC is not supported by cisco or other major router vendors. If that is the case I think my question is answered:

One VLAN is associated with one IP Subnet
Any router on that Subnet has one IP interface on a given Subnet
So a router has one IP interface associated with one VLAN.
Multiple IP sub-interfaces can share the same Ethernet port using 802.1Q tagging.

Sound correct?

Kevin

Peter Paluch · ‎10-24-2010

Hello Kevin,

I was new to the RFC 3069 so I've read it a few momens ago to see the ideas. The RFC was published in February 2001 and the RFC states that a working implementation is (or was) done by the Extreme Networks.

Honestly, this entire RFC with its notion of super-VLANs and sub-VLANs reminds me quite closely of the so-called Private VLAN feature that is supported on Cisco Catalyst switches starting from 3560 upwards. You may be interested in reading more about it here:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swpvlan.html

The basic idea of Private VLANs is that a there is a primary VLAN, similar to the super-VLAN, split into a set of secondary VLANs of a special type. This primary VLAN represents the IP space and all its members to the external world. However, internally, the primary VLAN is further split into an arbitrary number of secondary VLANs (sub-VLANs) with a specific type - a community secondary PVLAN, and an isolated secondary PVLAN. In a community PVLAN, all its members can communicate with each other but they cannot talk to any member of a different community PVLAN nor to a member of an isolated PVLAN. Members of an isolated PVLAN cannot talk to each other at all, and they also cannot talk to any member of a different community PVLAN under the same primary VLAN. However, all these secondary PVLANs share the IP space assigned to the primary VLAN. I believe it is quite similar to what the RFC 3069 describes.

Best regards,

Peter

kfowler1960 · ‎10-24-2010

Thanks Peter,

after I wrote my last message I did come across the Private VLAN RFC - I think it is Cisco's answer to RFC3069 and provides more flexibility. Though it seems that both RFCs are written with switches in mind. These allow there to be multiple VLANs per IP Subnet, but at any actual IP interface the one VLAN per IP interface rule holds.

Kevin