cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3648
Views
61
Helpful
10
Replies

ROAS: Native vlan configured on a router's physical interface - but how to configure the native vlan first?

Gord
Level 1
Level 1

I understand that the following configuration will associate the native vlan with physical interface G0/0 on a router:

R1# conf t

R1(config)# int G0/0

R1(config-if)# ip address 10.1.10.1 255.255.255.0

R1(config-if)# no shutdown

 

But what is the command one would use on a router to change the native vlan ID to something other than 1 prior to placing the native vlan on the physical interface?

 

 

Thanks

 

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

My friends,

Please allow me to join.

I am not going to say anything substantially new - Rick, Joe and Giuseppe have covered the ground excellently, as they always do. Just wanted to share a few observations and comments.

Indeed, on routers, the concept of a "native VLAN" is a very vague one. The router does not need to know the ID of the VLAN that is supposed to be untagged. All it needs to know is what other VLANs need to be tagged, and it knows that through the configuration of its subinterfaces. This aligns with the common configuration approach that for tagged VLANs, we create subinterfaces, and for the native VLAN, we configure the physical interface itself.

However, the subinterface configuration command encapsulation dot1q also supports the native keyword, allowing to explicitly designate a VLAN as the native VLAN. In that case, configuring the physical interface no longer makes sense, and all configuration can be done on subinterfaces. So in other words, the following two configuration snippets are practically equivalent:

interface GigabitEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface GigabitEthernet0/0.11
 encapsulation dot1q 11
 ip address 192.168.11.1 255.255.255.0
interface GigabitEthernet0/0
 no shutdown
!
interface GigabitEThernet0/0.10
 encapsulation dot1q 10 native
 ip address 10.0.0.1 255.255.255.0
!
interface GigabitEthernet0/0.11
 encapsulation dot1q 11
 ip address 192.168.11.1 255.255.255.0

The first configuration uses the physical interface approach, the second configuration performs all configurations using subinterfaces. These two configurations are, to my best knowledge and experience, equivalent and can be used interchangeably - you can use any that sits more comfortably with you.

There are only two very minor things to consider that I am aware of, and both are corner cases.

The first consideration is that some veeeeeeery old routers of the 2600 series with 10Mbps Ethernet interfaces did not support the subinterface style for native VLAN. While you could configure them, the traffic in the native VLAN was not properly processed on the subinterface. You had to configure the physical interface instead. Obviously, these routers are long gone.

The second consideration is that if the 802.1p CoS marking is used in the native VLAN, then the router needs to be prepared to receive tagged frames even in the native VLAN because the tag is where the CoS bits are stored. For that purpose, the configuration on the physical interface would not work - the router would not understand that the tagged frames are really "different-than-best-effort" frames in the native VLAN because it would not be able to associate them with a subinterface. So in that case, arguably rare, the configuration style to be used would be the second one with the encapsulation dot1q ... native command on subinterfaces.

My 0.02€...

Best regards,
Peter

View solution in original post

10 Replies 10

marce1000
Hall of Fame
Hall of Fame

 

 - Ref : https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/interfaces/521_N11/b_5k_Interfaces_Config_Guide_Release_521N11/b_5k_Interfaces_Config_Guide_Release_521N11_chapter_011.pdf

 >...

                                   A routed interface is a physical port
that can route IP traffic to another device. A routed interface is a Layer 3 interface only and does not support
Layer 2 protocols, such as the Spanning Tree Protocol (STP)

                 That being said it is not associative with a vlan 

 

 M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Richard Burts
Hall of Fame
Hall of Fame

The original poster seems to want to "change the native vlan ID to something other than 1 prior to placing the native vlan on the physical interface?"  There is no command on the router to do this. The router does not need a command to change the vlan ID. And really the router does not care what is the vlan ID of the native vlan. The router simply looks for Ethernet frames that do not contain a vlan tag and processes those frames on the physical interface.

Assuming that the router interface is connected to a switch port which is configured as a trunk most of the Ethernet frames will include a vlan tag. And to process those Ethernet frames with a vlan tag the router must be configured with subinterfaces with parameters identifying the vlan ID. Ethernet frames in the native vlan do not have vlan tags. It does not matter whether the vlan ID is the default of vlan 1, or is vlan 100, or any other vlan number. When the router sees an Ethernet frame with no vlan tag it does not matter what vlan ID the switch is using for the native vlan, the router simply processes that Ethernet frame on the physical interface. The router does not know and does not care what is the vlan ID of that frame.

HTH

Rick

Hello @Gord ,

there are two ways to configure a Router on a Stick:

a) using an IP address on the main interface that will process ethernet frames in the native VLAN whatever it is as defined on the switch side as explained by @Richard Burts 

b) You do not put an IP address under the main interface and you have all subinterfaces

in this case the encapsulation dot1q 100 native will make the vlan 100 native for the associated subinterface

 

These two modes of configuration are mutually exclusive you cannot have at the same time an IP address under the main interface and a subinterface with the enc .... native option

 

I am used to option b) in ROAS that is I leave the main interface with no ip address and I use subinterfaces.

The default native vlan is 1 for routers too.

 

Hope to help

Giuseppe

 

The original post made it clear that they would be using the approach to have the native vlan on the physical interface and that is what I focused on in my explanation. I thank Giuseppe for pointing out that there are 2 approaches. In addition to processing the native vlan on the physical interface it is possible to process the native vlan on a subinterface by including the parameter native in the command. Many people do prefer to use the subinterface configuration, perhaps because it is more consistent to have all the vlans on subinterfaces, and perhaps because for analysis and perhaps in troubleshooting it is nice to have the vlan number specified for the native vlan (and easier to match up the router configuration with the switch configuration. Either approach works.

HTH

Rick

Joseph W. Doherty
Hall of Fame
Hall of Fame

"But what is the command one would use on a router to change the native vlan ID to something other than 1 prior to placing the native vlan on the physical interface?"

The only command that comes to mind would be to remove any subinterface using the VLAN ID you wish to use as "native".

On a router interface, the "native" VLAN is whatever the main interface is (which uses untagged frames).

Basically, the main interface always uses untagged frames.  So, it's up to you, to configure the IP for the corresponding untagged frames and insure there's not a subinterface defined using the VLAN ID.

Consider this is somewhat also the situation on a switch.  Whenever an untagged frame is received on a trunk port, the switch assigns it to whatever "native" VLAN is defined for that trunk port.  I.e. it has no other way to validate an untagged frame should be assigned to a particular VLAN other than how the port is configured.

The one major difference between a switch trunk port and a router port, the former can accept "native" VLAN frames as both untagged and tagged while the latter can only accept "native" VLAN frames as untagged.  Both, though, transmit "native" VLAN frames as untagged.

@Joseph W. Doherty makes an interesting suggestion about removing any subinterface configured on the router for the vlan that is used as the native vlan. If, for example, the switch trunk port identifies vlan 100 as the native vlan, then Joseph suggests that you need to remove any router subinterface configured for vlan 100. While I agree that it make sense that you would want to remove that subinterface, I would suggest from a technical perspective that it is not necessary to remove the subinterface. The subinterface says that any Ethernet frame that has a vlan tag for 100 gets processed on the subinterface. But if the switch is configured with vlan 100 as the native vlan then there will not be any Ethernet frames with a vlan tag for 100. The router subinterface for vlan 100 would not be used - therefore better to remove it. But if it remains in the config it does not hurt anything. It is necessary that if the router subinterface for vlan 100 remains in the config that it must not have the same IP subnet as the physical interface.

HTH

Rick

Peter Paluch
Cisco Employee
Cisco Employee

My friends,

Please allow me to join.

I am not going to say anything substantially new - Rick, Joe and Giuseppe have covered the ground excellently, as they always do. Just wanted to share a few observations and comments.

Indeed, on routers, the concept of a "native VLAN" is a very vague one. The router does not need to know the ID of the VLAN that is supposed to be untagged. All it needs to know is what other VLANs need to be tagged, and it knows that through the configuration of its subinterfaces. This aligns with the common configuration approach that for tagged VLANs, we create subinterfaces, and for the native VLAN, we configure the physical interface itself.

However, the subinterface configuration command encapsulation dot1q also supports the native keyword, allowing to explicitly designate a VLAN as the native VLAN. In that case, configuring the physical interface no longer makes sense, and all configuration can be done on subinterfaces. So in other words, the following two configuration snippets are practically equivalent:

interface GigabitEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface GigabitEthernet0/0.11
 encapsulation dot1q 11
 ip address 192.168.11.1 255.255.255.0
interface GigabitEthernet0/0
 no shutdown
!
interface GigabitEThernet0/0.10
 encapsulation dot1q 10 native
 ip address 10.0.0.1 255.255.255.0
!
interface GigabitEthernet0/0.11
 encapsulation dot1q 11
 ip address 192.168.11.1 255.255.255.0

The first configuration uses the physical interface approach, the second configuration performs all configurations using subinterfaces. These two configurations are, to my best knowledge and experience, equivalent and can be used interchangeably - you can use any that sits more comfortably with you.

There are only two very minor things to consider that I am aware of, and both are corner cases.

The first consideration is that some veeeeeeery old routers of the 2600 series with 10Mbps Ethernet interfaces did not support the subinterface style for native VLAN. While you could configure them, the traffic in the native VLAN was not properly processed on the subinterface. You had to configure the physical interface instead. Obviously, these routers are long gone.

The second consideration is that if the 802.1p CoS marking is used in the native VLAN, then the router needs to be prepared to receive tagged frames even in the native VLAN because the tag is where the CoS bits are stored. For that purpose, the configuration on the physical interface would not work - the router would not understand that the tagged frames are really "different-than-best-effort" frames in the native VLAN because it would not be able to associate them with a subinterface. So in that case, arguably rare, the configuration style to be used would be the second one with the encapsulation dot1q ... native command on subinterfaces.

My 0.02€...

Best regards,
Peter

Peter, when using the subinterface native option, the interface will then accept either untagged frames or tagged frames with the corresponding VLAN ID (i.e. much as a switch trunk will)?  The main interface approach, would not accept tagged frames, correct?

Also, I recall a recent (?) thread that noted you can have tagged frames w/o a VLAN ID for the purpose of carrying just the CoS tag.  If so, would the native subinteface also accept these frames as being part of the native VLAN?

 

Hey, watch what you're saying about 2600 ISRs being "very old", such remarks have implications for those of who used Cisco equipment before that series was marketed.  (laugh)

Always good to learn new things.  My guess, the subinterface native option would be very useful on non-Cisco equipment which, on tagged trunks, do not send any VLAN untagged.

BTW, I've noticed you been a bit more active on the forums, recently.  Hope to see more of your posts.

Hello Joe : )

Peter, when using the subinterface native option, the interface will then accept either untagged frames or tagged frames with the corresponding VLAN ID (i.e. much as a switch trunk will)?

Precisely.

The main interface approach, would not accept tagged frames, correct?

Correct. The main interface configuration handles untagged traffic only - because tagged frames are always dispatched to the subinterfaces for handling.

Also, I recall a recent (?) thread that noted you can have tagged frames w/o a VLAN ID for the purpose of carrying just the CoS tag. If so, would the native subinteface also accept these frames as being part of the native VLAN?

This is a great question for which I don't have an answer yet. I would need to lab this. Here, we are talking about tagged frames with VLAN ID 0. It would indeed be interesting to see if the subinterface with the encapsulation dot1q ... native command also handles frames with VLAN ID 0. I'll need some time setting a lab for this.

Hey, watch what you're saying about 2600 ISRs being "very old", such remarks have implications for those of who used Cisco equipment before that series was marketed. (laugh)

Ah, I suspected that someone would object ; ) In my defense, by referring to those routers and commenting on their idiosyncrasies I had hands-on experience with, I am also betraying my age myself ; )

My guess, the subinterface native option would be very useful on non-Cisco equipment which, on tagged trunks, do not send any VLAN untagged.

Possibly but there is a gotcha - while the subinterface with the encapsulation dot1q ... native configuration will accept untagged as well as tagged frames (with the matching VLAN ID), it will only send out untagged frames. Notice the asymmetry: We accept both, tagged and untagged, but only send out untagged (unless we, perhaps, did some explicit CoS marking on egress traffic through policy maps). Now the question is whether the attached device would like that and be able to handle incoming untagged traffic.

A device that only sends out tagged traffic is the easiest to handle since it can be reasonably assumed to also expect only tagged traffic back - then, for each VLAN, your router just needs to have a subinterface without the native keyword and you're done.

Personally, I have seen the encapsulation dot1q ... native approach being motivated by two aspects: First, allowing all configuration to be done completely using subinterfaces only and not create the somewhat messy configuration having some networks attached to subinterfaces and the one for the native VLAN on the physical interface itself (that is, "once a subinterface, always a subinterface"). Second, the configuration gets closer to the switch style of configuration where the ID of the native VLAN is known - it's not "just an untagged VLAN with no particular ID" but rather "it is a particular VLAN with a specific ID for which, on this particular trunk, we don't insert and don't expect tags in frames, save for very exceptional cases".

BTW, I've noticed you been a bit more active on the forums, recently. Hope to see more of your posts.

My friend... THANK YOU. Sincerely. I missed these forums and our discussions very badly. I'm still swamped but I'm coming here as a part of my psychohygiene, so to say : ) I also hope to be more around again.

Best regards,
Peter

Gord
Level 1
Level 1

Thank you all for your help. Each of you added to my understanding, and Peter's comprehensive summary, including the configuration commands and the exceptional cases, was like being handed an aquascope - all was suddenly clear! What a great first experience for a newbie! Thanks again, guys!