*** In the process of writing this email I've figured this out. I
thought I'd send the email anyway for other's benefit (and
entertainment?) ***
Because of a very old configuration I found on a router we have, I lab'd
this scenario up to see how this would work (or not work, as the case
may be).
Example traffic flow (see configs below): Let's say R1 pings R2 on each
of it's two interfaces. R1 does not tag any frames. The switch
receives the untagged frames and sends them untagged to R2. R2,
believing that all untagged traffic it receives belongs on Fa0/0.1,
returns the pings to 1.1.1.1 but gives the 'debug arp' output below for
the 3.3.3.2 arp request because it sees the request on it's 1.1.1.0/24
subnet for a different subnet (3.3.3.0/24).
So even though R1 and R2 will send traffic from the main interface, the
only way this would work the way it's configured here would be to tag
frames on all subinterfaces and then the main interface would send
traffic on the native vlan (untagged).
R1
interface FastEthernet0/0
ip address 3.3.3.1 255.255.255.0
!
interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 1.1.1.1 255.255.255.0
R2
interface FastEthernet0/0
ip address 3.3.3.2 255.255.255.0
!
interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 1.1.1.2 255.255.255.0
Switch
interface FastEthernet0/1
switchport trunk encapsulation dot1q (native vlan = 1)
switchport mode trunk
!
interface FastEthernet0/2
switchport trunk encapsulation dot1q (native vlan = 1)
switchport mode trunk
debug arp on R2 when pinging from R1 (3.3.3.1) to R2 (3.3.3.2):
*Oct 10 01:37:35.555: IP ARP req filtered src 3.3.3.1 0018.19c2.c106,
dst 3.3.3.2 0000.0000.0000 wrong cable, interface FastEthernet0/0.1
Thanks,
Jake
Blogs and organic groups at http://www.ccie.net
Received on Fri Oct 09 2009 - 22:11:05 ART
This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:50:59 ART