Excerpts from Paul Stewart's message of Fri Mar 26 06:10:47 -0700 2010:
> Hi there..
>
> I just wanted to follow up on this - I'd open a case at JTAC but honestly
> have no idea where to get started with them yet...;)
>
> So, the MAC filtering worked for one of the exchange points yesterday ...
> then late last night one of our upstream providers dropped off. With the
> upstream provider I've asked them for port security logs so I can start
> hunting for MAC's they are seeing .... this will hopefully provide a clue.
Oh no! Hopefully you're multihomed :)
It's strange that a transit provider would drop a connection because of
layer 2 traffic it doesn't like. Perhaps the outage was unrelated?
Every transit I've dealt with delivers service over a point-to-point
link (an Ethernet segment with just two routers on it), with no port
security or spanning tree.
IXes on the other hand seem to regularly implement port security as a
way of preventing loops in a switched environment without spanning tree
running. It's a hassle to deal with spanning tree across administrative
boundaries.
If you're still trying to track down traffic that's appearing without
explaination, and have a free PC with a GigE NIC, attach it to an
analyzer port and just start capturing.
> Is there a way in a filter to log denied MAC addresses? Snippet looks like
> this:
>
> family ethernet-switching {
> filter core2_peering_filter {
> term expected_mac_address {
> from {
> source-mac-address {
> 00:0b:45:b6:f5:00;
> }
> }
> then accept;
> }
> term block {
> then discard;
> }
> }
>
> I tried to add "then discard log" to the term block but I get:
>
> 'filter'
> Referenced filter 'core1_peering_filter' can not be used as log not
> supported on egress
> error: configuration check-out failed
Looks like it's not supported on egress then. This has the potential to
log a LOT.
--j