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.
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.;)...
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.
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...