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

Question

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

Answer 1

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