[nsp] IP-EIGRP: Neighbor A.B.C.D not on common subnet...

[Yuval Ben-Ari]

> -----Original Message-----
> From: sthaug at nethelp.no [mailto:sthaug at nethelp.no] 
> Sent: Sunday, February 02, 2003 12:18 PM
> To: Yuval Ben-Ari
> Cc: gert at greenie.muc.de; cisco-nsp at puck.nether.net; 
> thomas.renzy at veritas.com
> Subject: RE: [nsp] IP-EIGRP: Neighbor A.B.C.D not on common subnet...
> 
> 
> > > > I suspect the root for the problem is EIGRP hello packets being
> > > > multicast and the fact that the L2 switches (Catalyst XL 
> > > series in this
> > > > case) flood multicast frames on all ports including 
> ports from other
> > > > Vlans. 
> > > 
> > > If they do that, it is a major bug.  Flooding MUST NOT 
> spill over to
> > > other broadcast domains.  NEVER.
> > 
> > Well, it sure looks like this is what is happening, the port of the
> > router sending the hello's is explicitly configured on Vlan4:
> > 
> > interface FastEthernet0/33
> >  description XXX
> >  duplex full
> >  speed 100
> >  switchport access vlan 4
> >  spanning-tree portfast
> > 
> > while the port of the router complaining about the "Neighbor not on
> > common subnet" (on an adjacent switch connected by trunk) 
> is left on the
> > Native VLAN (1):
> > 
> > interface FastEthernet0/9
> >  description XXX
> >  duplex full
> >  speed 100
> >  spanning-tree portfast
> > 
> > The trunk between the switches is a 4 port etherchannel 
> with this config
> > (VLAN 4 is not even allowed):
> > 
> > interface FastEthernet0/45-48
> >  description TRUNK
> >  load-interval 30
> >  duplex full
> >  speed 100
> >  port group 2
> >  switchport trunk encapsulation dot1q
> >  switchport trunk allowed vlan 1,400,1002-1005
> >  switchport mode trunk
> > 
> > Is anything wrong with the config or is it really Catalyst 
> 3500XL flaw ?
> 
> Which IOS release are you running on the 3500XL? See 

12.0(5.1)XW
 
> 	http://online.securityfocus.com/archive/1/26008
> 
> for a description of how they got packets to hop from one VLAN to
> another. Note:
> 
> - This specifically involves having one host on the same VLAN as the
> "native"/default VLAN on an 802.1q trunk.
> 
> - I tried very hard to reproduce this problem with the same setup and
> newer IOS versions (basically the latest IOS available IOS for 3500XL
> as of about 6 months ago), and was unable to do so. I believe the 
> problem described by the SecurityFocus article has been fixed in newer
> IOS versions.
> 
> In any case, it's generally a bad idea to use the "native"/default
> VLAN on an 802.1q trunk for normal traffic. It's even better not to
> have any "native"/default VLAN at all, meaning that *all* traffic on
> an 802.1q trunk is tagged. This is possible in newer IOS versions for
> 3550 and 6500 with the
> 
> 	vlan dot1q tag native
> 
> command. Not available on the 3500XL, as far as I know.

there is no actual VLAN1 traffic passing the trunk, the trunk is there
more for historical reasons, I guess I will try to eliminate it rather
than dig more in these VLAN leaking problems ;)

thanks for all the help
 
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>