I figured I would throw this one on here...
I was seeing these log messages on a remote VPLS site:
%DUAL-6-NBRINFO: EIGRP-IPv4 #: Neighbor x.x.x.x (Vlan #) is blocked: not on common subnet (x.x.x.x/y)
This appears in the log once every 10 seconds and is completely filling it. Very annoying.
My hub is running EIGRP to some remote sites through a VPLS cloud. Because it's in broadcast mode, EIGRP is multicasting hellos. But for whatever reason, the hellos from all the hub interfaces are making their way to all the VPLS sites. I expected each site to only receive hellos from the matching hub interface, but not from all hub interfaces.
Well-known range multicasts and broadcasts are normally forwarded out all switch interfaces, but only the interfaces in a common VLAN. A different VLAN is on a different subnet, so you should not see broadcasts and multicasts from that VLAN crossing into another VLAN.
I think this is something that the VPLS provider needs to fix. I got sick of seeing it after bringing up a new site, so I did something about it. I ended up doing this on the site router:
ip access-list EIGRP
permit eigrp x.x.x.x y.y.y.y any <--Subnet of the WAN segment to this site
deny eigrp any any <--Denies EIGRP packets, including multicasts from all other subnets
permit ip any any
And I applied it inbound on the WAN layer 3 interface of the spoke. I also used EIGRP authentication. And that stopped all those log messages.
But I think a better solution would be, if the VPLS provider can't correct it, to run EIGRP in non-broadcast mode. Using passive interface and manual neighbor entries would change the EIGRP hellos from multicasts to unicasts.
And if even unicasts are sent to the wrong sites, and cause those log messages, then we have bigger problems to work on.
No comments:
Post a Comment