Tag Archives: sub

Native vlan subinterfaces

The subinterface is an invaluable tool in your belt. I pretty must use subinterfaces whenever I connect routers to each other via ethernet, even if initially they are only going to have a single point-to-point connection to each other.

Why? Well a subinterface allows you to stick a dot1q header on your frames. Just like running a trunk between 2 switches, it allows you to run multiple logical links between 2 routers. As noted above, even if you only have a single point-to-point connection between 2 routers I still run them. In the past I’ve had to change or add to a design. If I was running just the physical interfaces and needed to change it, I would require downtime and possibly even going to site to actually reconfigure the CPE device. If I used subinterfaces from the start I can just add another subinterface to the mix. There is ways to get around this though.

You can also mix regular and subiterfaces together on the same interface. You can also tag a subinterface as the native vlan. Let’s look at a couple of different examples and see what we see.

dot1qnative Native vlan subinterfaces

Let’s just start with a simple physical interface setup.
R1:

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0

R2:

interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/25/68 ms

dot1qnative 11 Native vlan subinterfaces

Let’s say now that for whatever reason we need to run another logical link between these 2 routers. Let’s also say that R2 happens to be on the other side of the country and we need to do this now. Well I did note above that there is a workaround for this as you can run both a physical and subinterface on the router at the same time. Let’s leave the above config in and add this:
R1:

interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.0.0.1 255.255.255.0
interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.0.0.2 255.255.255.0
R1#ping 10.0.0.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 28/28/28 ms
R1#ping 192.168.1.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 24/24/24 ms

Both still work. Now you could log onto R2 via the 10.0.0.2 link and remove the 192.168.1.0/24 address if you wanted without worry. Wireshark shows traffic going over the physical interface has no dot1q tag, while the subinterface has a dot1q tag of 10:
dot1qnative 2 Native vlan subinterfaces
dot1qnative 3 Native vlan subinterfaces

Now let’s mix it up a bit. I can say that a subinterface is tagged with the native vlan. i.e. no vlan tag:
R1:

interface FastEthernet0/0.20
 encapsulation dot1Q 20 native
 ip address 20.20.20.1 255.255.255.0

R2:

interface FastEthernet0/0
 ip address 20.20.20.2 255.255.255.0 secondary
 ip address 192.168.1.2 255.255.255.0
R1#ping 20.20.20.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 20.20.20.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 24/24/24 ms

dot1qnative 4 Native vlan subinterfaces

On R1 I created a subinterface with the native vlan. On R2 I added a secondary IP address. Traffic for the 20.20.20.0/24 range goes over the wire without a dot1q tag. Why not just use a secondary address? Well you can stick a subinterface into a vrf, while you can’t do that with a secondary address. Your IGP behavior also changes somewhat.

I don’t quite like doing the above though. I don’t like have layer2 seperation between networks that should be separated. However it proves the point that a native subinterface’s traffic outbound is exactly the same format as a physical interface. Just a standard ethernet layer2 header with no dot1q tag.

There is another advantage to using a native subinterface. If I want to shut down the link for 20.20.20.0/24, on R1 I can shut down the subinterface. All other subinterfaces stay up. If I do this on R2 however, all subinterfaces go down:
R1:

R1(config)#int fa0/0.20
R1(config-subif)#shut
R1(config-subif)#end
R1#
*Mar  1 00:33:31.023: %SYS-5-CONFIG_I: Configured from console by console
R1#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.1.1     YES manual up                    up
FastEthernet0/0.10         10.0.0.1        YES manual up                    up
FastEthernet0/0.20         20.20.20.1      YES manual administratively down down
R2(config)#int fa0/0
R2(config-if)#shut
R2(config-if)#end
R2#
*Mar  1 00:34:51.955: %SYS-5-CONFIG_I: Configured from console by console
R2#sh ip int
*Mar  1 00:34:53.347: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar  1 00:34:54.347: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R2#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.1.2     YES manual administratively down down
FastEthernet0/0.10         10.0.0.2        YES manual administratively down down

So while the native subinterface and physical interface send traffic the same, I can shut a native subinterface without affecting any other subinterface, while the shutting down of a physical interface shuts down all the subinterfaces attached to it

Now let’s get deeper…

R1:

interface FastEthernet0/0.10
 encapsulation dot1Q 10 native
 ip address 10.10.10.1 255.255.255.0

R2:

interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.10.10.2 255.255.255.0

Here I have R1 configured with a native subinterface, while R2 is configured with a dot1q header of 10. You would expect there would be no communication between them, but you would be incorrect. I’m going to turn on debug ip packet on both routers for this to see who sees what
R1:

R1#ping 10.10.10.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:

*Mar  1 00:08:07.763: IP: tableid=0, s=10.10.10.1 (local), d=10.10.10.2 (FastEthernet0/0.10), routed via FIB
*Mar  1 00:08:07.763: IP: s=10.10.10.1 (local), d=10.10.10.2 (FastEthernet0/0.10), len 100, sending.
Success rate is 0 percent (0/1)

dot1qnative 5 Native vlan subinterfaces
So the ping failed, but look more closely. R1 was able to encapsulate the packet, which means it has a MAC address. Let’s look at the ARP table:

R1#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.10.1              -   c200.3e78.0000  ARPA   FastEthernet0/0.10
Internet  10.10.10.2              2   c201.3e78.0000  ARPA   FastEthernet0/0.10

Let’s try the other way around now.
R2:

R2#ping 10.10.10.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:

*Mar  1 00:11:20.807: IP: tableid=0, s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), routed via RIB
*Mar  1 00:11:20.811: IP: s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), len 100, sending
*Mar  1 00:11:20.815: IP: s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), len 100, encapsulation failed.
Success rate is 0 percent (0/1)

dot1qnative 6 Native vlan subinterfaces
Let’s have a look at the ARP cache:

R2#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.10.1              0   Incomplete      ARPA
Internet  10.10.10.2              -   c201.3e78.0000  ARPA   FastEthernet0/0.10

Somehow R1 learned R2′s MAC address so communication was there, but it seems it’s only one way. Let’s clear the ARP cache on both and debug ARP to see what happens.

The first thing you notice when you clear the ARP cache is that the local router will send a gratuitous ARP out to let everyone else know about it. Let’s see what we see on R1 when we clear R2′s cache:
R2:

R2#clear arp
R2#
*Mar  1 00:18:45.135: ARP: flushing ARP entries for all interfaces
*Mar  1 00:18:45.143: IP ARP: sent rep src 10.10.10.2 c201.3e78.0000,
                 dst 10.10.10.2 ffff.ffff.ffff FastEthernet0/0.10

R1:

R1#
*Mar  1 00:18:31.231: IP ARP: rcvd rep src 10.10.10.2 c201.3e78.0000, dst 10.10.10.2 FastEthernet0/0.10

R1 receives this gratuitous ARP and installs the MAC address into it’s ARP cache. Wireshark shows that R2 is sending this gratuitous ARP with a dot1q tag:
dot1qnative 7 Native vlan subinterfaces

What about the other way?
R1:

R1#clear arp
R1#
*Mar  1 00:20:53.847: ARP: flushing ARP entries for all interfaces
*Mar  1 00:20:53.855: IP ARP: sent rep src 10.10.10.1 c200.3e78.0000,
                 dst 10.10.10.1 ffff.ffff.ffff FastEthernet0/0.10

R2:

R2#
*Mar  1 00:21:07.831: IP ARP rep filtered src 10.10.10.1 c200.3e78.0000, dst 10.10.10.1 ffff.ffff.ffff wrong cable, interface FastEthernet0/0

dot1qnative 8 Native vlan subinterfaces

R2 complains that this ARP is coming in on ‘the wrong cable’ while wireshark shows the gratuitous ARP being sent without a dot1q header as expected.

What can we get from this? Well if you have a native subinterface, it will accept both untagged AND tagged frames in the vlan, vlan 10 in my example above. However it will only SEND untagged traffic. Good to know. It can also explain why you sometimes see an ARP entry on one side, while not on the other.