Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

The difference between IEEE802.1Q Native VLAN sub-interface and Physical interface?

Hello

 

I think the following topologies are supported for Cisco Routers

And the Physical interface also can be using as Native VLAN interface right? 

################################################

Topology 1.

 R1 Gi0.1 ------ IEEE802.1Q Tunneling  L2SW ------ Gi0 R2

 

R1 - configuration

interface GigabitEthernet0.1
 encapsulation dot1Q 1 native

 ip address 10.0.0.1 255.255.255.0

################################################

Topology 2.

R1 Gi0 ------ IEEE802.1Q Tunneling L2SW ------ Gi0 R2

interface GigabitEthernet0

ip address 10.0.0.1 255.255.255.0

################################################

 And is it ok to use the physical interface and sub-interface with dynamic routing such as EIGRP or OSPF etc?

R1 Gi 0 ---- Point to Multipoint EIGRP or OSPF ---- Gi0 R2 / R3 

      Gi 0.20--- Point to Point EIGRP or OSPF --- Gi0.10 R4  (same VLAN-ID) 

 

R1 - configuration

interface GigabitEthernet0
 ip address 10.0.0.1 255.255.255.0

!

interface GigabitEthernet8.20
 encapsulation dot1Q 20
 ip address 20.0.0.1 255.255.255.0

################################################

Any information is very appreciated. but if there is any CCO document please let me know.

Thank you very much and regards,

 

Masanobu Hiyoshi

 

  

 

 

Everyone's tags (2)
6 REPLIES
Cisco Employee

Hello,Your basic question is:

Hello,

Your basic question is: Is the physical Ethernet interface operation equivalent to the operation of a subinterface for the native VLAN?

The answer is: yes, it is, save for one exception described later. The difference between the physical interface and configuring a "native subinterface" is mostly related to the configuration style. However, once configured, both the physical interface and the "native subinterface" operate in the same way. You are completely free to use any configuration style you want, and everything will work just fine (routing protocols, ACLs, NAT, DHCP, IPsec, policy based routing, etc.). You just need to make sure that if you use "native subinterfaces", you have to put all relevant configuration into their section in the running-config and not in the physical interface section anymore.

There is only one difference between the operation of physical interfaces and "native subinterfaces" I am aware of. You surely know that an 802.1Q tag also contains three priority bits (the class-of-service, or CoS bits). If a sender of a frame needs to indicate that this frame is more important than usual, it needs to insert an 802.1Q tag and set the CoS bits appropriately. It may happen that even in the native VLAN, a sender is sending a frame that is more important than ordinary frames. In such case, the frame needs to be tagged even if it is in the native VLAN. So in effect, it is possible, for absolutely legal reasons, to receive a tagged frame even in the native VLAN.

For a router that is configured to handle the native VLAN on its physical interface, this poses a problem. If a tagged frame arrives to a router, the router will try to look up the particular subinterface whose configured 802.1Q VLAN matches the VLAN ID in the frame tag. Because, however, such subinterface does not exist as the native VLAN configuration is placed on the physical interface itself, the router simply does not know that this frame is not a frame for some unknown VLAN but just a priority-marked frame within the native VLAN. As a result, the frame will be dropped.

If the router is configured with "native subinterface" then all is OK - because even if the frame in the native VLAN arrives as a tagged frame, the router will be able to find the corresponding subinterface by the VLAN ID, and process the frame correctly.

I have to say that seeing CoS-marked traffic in the native VLAN is very uncommon and most sources do not even talk about it - and besides that, you should actually avoid using the native VLAN - so for all practical purposes, you can forget about this peculiarity and simply assume that the physical interface and the "native subinterface" are simply two ways of configuring the same thing.

Please feel welcome to ask further!

Best regards,
Peter

 

New Member

Hello PeterThank you for your

Hello Peter

Thank you for your precious information.

I simply understood that this is two ways of the same configuration to use physical or Native sub-interface.

By the wey can you think the following topology is also functioning?

I have already confirmed with cisco routers but I appreciate to let me know your opinion.

########################################################################################

PHY Interface              ----L2SW --- SUB Interface(Native VLAN1) or PHY Interface
  *EIGRP Point-to-Multipoint
SUB Interface(VLAN2-4094)               SUB Interface(VLAN2-4094)
  *EIGRP Point-to-Point

########################################################################################

Thank you very much

Best Regards,

 

Masanobu Hiyoshi

 

Cisco Employee

Hello,You are very much

Hello,

You are very much welcome.

Regarding your second question - I must admit I am not entirely sure I understand it. Can you perhaps try to explain it in words, or post a diagram showing the exact topology?

Best regards,
Peter

New Member

Hello PeterThank you very

Hello Peter

Thank you very much, well to explain in words is little bit difficult for me. so I have prepared for the topology diagram attached. I appreciate if you can check it.

And If possible I would like to know any CCO domumentation link related to this, however  in my opinion , using both Native Subinterface and IEEE802.1 Q Tag Subinterface and using EIGRP unicast routing is general so I do not worry about this condition,

however using both Physical and IEEE802.1Q Tag Subinterface and using EIGRP unicast routing is quite rare case so there might be not any related CCO link.;)...

 

Thank you very much and Best Regards,

 

Masanobu Hiyoshi

 

 

Cisco Employee

Hello,The diagram is helpful

Hello,

The diagram is helpful.

If I am getting you correctly, you have three routers interconnected by a switch, and you want them to operate in a hub-and-spoke fashion even though the switch is capable of allowing direct communication between any of these routers.

Your first scenario is concerned with all three routers being in the same VLAN, and by using neighbor commands, you force these routers to establish targeted EIGRP adjacencies R1-R2 and R1-R3, with R1 being the hub.

Your second scenario is concerned with creating one VLAN per spoke, having subinterfaces for each spoke VLAN created on R1 as the router, and putting each spoke just in its own VLAN.

Your scenarios are not really concerned with the concept of native VLAN or the way it is configured, to be honest. Whether you use a native VLAN in either of your scenarios, or whether you configure the native VLAN on a subinterface or on the physical interface makes no difference. There is simply no difference to using or not using a native VLAN in any of your scenarios, and there is no difference to the native VLAN configuration being placed on a physical interface or a subinterface. It's as plain as that. Both your scenarios will work.

My personal opinion, though, is that forcing routers on a broadcast multi-access segment such as Ethernet to operate in a hub-and-spoke fashion is somewhat artificial. Why would you want to do this? Both scenarios have drawbacks: in the first scenario, you need to add a neighbor statement for each spoke to the hub, limiting the scalability. In the second scenario, you waste VLANs and IP subnets if there are many spokes. The primary question is, though: why would you want an Ethernet segment to operate as a hub-and-spoke network? Sure, these things are done but they are motivated by specific needs so I would like to know if you have any.

Even if you needed your network to operate in a hub-and-spoke mode, there are more efficient means of achieving that: Cisco switches support so-called protected ports that are prevented from talking to each other. By configuring the switch ports to spokes as protected, you will prevent the spokes from seeing each other. You would not need, then, to configure static neighbors in EIGRP, or to waste VLANs for individual spokes. What you would need to do would be deactivating the split horizon on R1's interface, and using the ip next-hop-self eigrp command on R1 to tweak the next hop information to point to R1 so that the spokes do not attempt to route packets to each other directly but rather route them over R1.

I do not believe I have seen any special CCO documents regarding the use of physical interfaces or subinterfaces for native VLAN or for your scenarios.

Best regards,
Peter

 

New Member

Hello PeterThank you for your

Hello Peter

Thank you for your great information.

It will be very helpful to me.

Beside as for your personal opinion, I think point-to-multipoint on this case is litte bit old fasion network bcause of some policy or scalability at that time, it might be operating for a long time. but point-to-point network has its own segment and I think no concern about split horizon rule. So I think it is better to change this simple network.

Best Regards,

Masanobu Hiyoshi

 

554
Views
0
Helpful
6
Replies
CreatePlease to create content