<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Multiple VLANs on an IP interface in Switching</title>
    <link>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577842#M158366</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Kevin,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-external-small" href="http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swpvlan.html"&gt;http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swpvlan.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Best regards,&lt;/P&gt;&lt;P&gt;Peter&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Sun, 24 Oct 2010 19:30:56 GMT</pubDate>
    <dc:creator>Peter Paluch</dc:creator>
    <dc:date>2010-10-24T19:30:56Z</dc:date>
    <item>
      <title>Multiple VLANs on an IP interface</title>
      <link>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577839#M158363</link>
      <description>&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;(not cisco)10.10.10.1: ----vlan10 + vlan20------- 10.10.10.2 (cisco)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;!&lt;BR /&gt;interface FastEthernet2/0&lt;BR /&gt;ip address 10.10.10.2 255.255.255.0&lt;BR /&gt;duplex half&lt;BR /&gt;speed 10&lt;BR /&gt;vlan-id dot1q 10&lt;BR /&gt;&amp;nbsp; exit-vlan-config&lt;BR /&gt;!&lt;BR /&gt;vlan-id dot1q 20&lt;BR /&gt;&amp;nbsp; exit-vlan-config&lt;BR /&gt;!&lt;BR /&gt;no mop enabled&lt;BR /&gt;end&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;K.&lt;/P&gt;</description>
      <pubDate>Wed, 06 Mar 2019 21:42:18 GMT</pubDate>
      <guid>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577839#M158363</guid>
      <dc:creator>kfowler1960</dc:creator>
      <dc:date>2019-03-06T21:42:18Z</dc:date>
    </item>
    <item>
      <title>Re: Multiple VLANs on an IP interface</title>
      <link>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577840#M158364</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Kevin,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The &lt;STRONG&gt;vlan-id dot1q&lt;/STRONG&gt; 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:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE class="jive_text_macro jive_macro_code"&gt;&lt;P&gt;interface FastEthernet0/0&lt;/P&gt;&lt;P&gt; pppoe enable group global&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE class="jive_text_macro jive_macro_code"&gt;&lt;P&gt;interface FastEthernet0/0&lt;/P&gt;&lt;P&gt; no shutdown&lt;/P&gt;&lt;P&gt;!&lt;/P&gt;&lt;P&gt;interface FastEthernet0/0.101&lt;/P&gt;&lt;P&gt; encapsulation dot1q 101&lt;/P&gt;&lt;P&gt; pppoe enable group Group1&lt;/P&gt;&lt;P&gt;!&lt;/P&gt;&lt;P&gt;interface FastEthernet0/0.102&lt;/P&gt;&lt;P&gt; encapsulation dot1q 102&lt;/P&gt;&lt;P&gt; pppoe enable group Group2&lt;/P&gt;&lt;P&gt;!&lt;/P&gt;&lt;P&gt;interface FastEthernet0/0.103&lt;/P&gt;&lt;P&gt; encapsulation dot1q 103&lt;/P&gt;&lt;P&gt; pppoe enable group Group3&lt;/P&gt;&lt;P&gt;! ... and so on&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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 &lt;STRONG&gt;show idb&lt;/STRONG&gt; command in your router). In large deployments, creating hundreds of subinterfaces could indeed exhaust the available IDB space. Therefore, a new command, &lt;STRONG&gt;vlan-id dot1q&lt;/STRONG&gt; 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:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;PRE class="jive_text_macro jive_macro_code"&gt;&lt;P&gt;interface FastEthernet0/0&lt;/P&gt;&lt;P&gt; no shutdown&lt;/P&gt;&lt;P&gt; !&lt;/P&gt;&lt;P&gt; vlan-id dot1q 101&lt;BR /&gt;&amp;nbsp; pppoe enable group Group1&lt;BR /&gt;&amp;nbsp; exit-vlan-config&lt;BR /&gt; !&lt;BR /&gt; vlan-id dot1q 102&lt;BR /&gt;&amp;nbsp; pppoe enable group Group2&lt;BR /&gt;&amp;nbsp; exit-vlan-config&lt;BR /&gt; !&lt;BR /&gt; vlan-id dot1q 103&lt;BR /&gt;&amp;nbsp; pppoe enable group Group3&lt;BR /&gt;&amp;nbsp; exit-vlan-config&lt;BR /&gt; !&lt;/P&gt;&lt;/PRE&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As all these PPPoE access server configuration are now placed on a single interface, only one IDB is allocated.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;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 &lt;STRONG&gt;vlan-id dot1q&lt;/STRONG&gt; 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 &lt;STRONG&gt;always be untagged&lt;/STRONG&gt;. 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I hope this helps a bit.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Best regards,&lt;/P&gt;&lt;P&gt;Peter&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 23 Oct 2010 06:56:02 GMT</pubDate>
      <guid>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577840#M158364</guid>
      <dc:creator>Peter Paluch</dc:creator>
      <dc:date>2010-10-23T06:56:02Z</dc:date>
    </item>
    <item>
      <title>Re: Multiple VLANs on an IP interface</title>
      <link>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577841#M158365</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Thanks Peter,&lt;/P&gt;&lt;P&gt;your explanation explained both why the configuration "took" and why it was not what I am really after.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;One VLAN is associated with one IP Subnet&lt;/LI&gt;&lt;LI&gt;Any router on that Subnet has one IP interface on a given Subnet&lt;/LI&gt;&lt;LI&gt;So a router has one IP interface associated with one VLAN. &lt;/LI&gt;&lt;LI&gt;Multiple IP sub-interfaces can share the same Ethernet port using 802.1Q tagging.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Sound correct?&lt;/P&gt;&lt;P&gt;Kevin&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 24 Oct 2010 16:36:56 GMT</pubDate>
      <guid>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577841#M158365</guid>
      <dc:creator>kfowler1960</dc:creator>
      <dc:date>2010-10-24T16:36:56Z</dc:date>
    </item>
    <item>
      <title>Re: Multiple VLANs on an IP interface</title>
      <link>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577842#M158366</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Kevin,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-external-small" href="http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swpvlan.html"&gt;http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swpvlan.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Best regards,&lt;/P&gt;&lt;P&gt;Peter&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 24 Oct 2010 19:30:56 GMT</pubDate>
      <guid>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577842#M158366</guid>
      <dc:creator>Peter Paluch</dc:creator>
      <dc:date>2010-10-24T19:30:56Z</dc:date>
    </item>
    <item>
      <title>Re: Multiple VLANs on an IP interface</title>
      <link>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577843#M158367</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Thanks Peter,&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Kevin&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 24 Oct 2010 20:57:11 GMT</pubDate>
      <guid>https://community.cisco.com/t5/switching/multiple-vlans-on-an-ip-interface/m-p/1577843#M158367</guid>
      <dc:creator>kfowler1960</dc:creator>
      <dc:date>2010-10-24T20:57:11Z</dc:date>
    </item>
  </channel>
</rss>

