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.
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:
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:
encapsulation dot1q 101
pppoe enable group Group1
encapsulation dot1q 102
pppoe enable group Group2
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:
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.
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.
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:
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.
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.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...