Send Netdot-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://osl.uoregon.edu/mailman/listinfo/netdot-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netdot-users digest..."
Today's Topics:
1. All-zeros MAC (Brian Candler)
2. Re: All-zeros MAC (William Bulley)
3. Re: All-zeros MAC (Carlos Vicente)
4. Re: Auto DNS entries (Carlos Vicente)
5. Re: All-zeros MAC (Phil Regnauld)
6. Re: All-zeros MAC (Mike Hertrick)
7. Re: All-zeros MAC (Brian Candler)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Sep 2012 00:06:17 +0000
From: Brian Candler <[email protected]>
Subject: [Netdot-users] All-zeros MAC
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Odd situation arose here in a campus environment, which I thought I'd
report.
Watching traffic on a switch port showed unicast traffic to another host on
the subnet with dest MAC address 00:00:00:00:00:00
The switch had refused to put this in its bridge table (obviously bogus MAC
address) so the packets were going out of all ports. We managed to identify
it via its hostname in DHCP logs.
The upstream router did have an ARP entry for that IP address with
0000.0000.0000 as the MAC address.
However, Netdot had no record for 000000000000 on the network. I'm not sure
if Netdot had filtered it out when collecting ARP tables, or the router had
not returned it when its ARP table was queried via SNMP.
If Netdot *is* filtering it out, then I think that's not helpful; we would
have realised that this bogus MAC address was live on the network sooner if
we could have seen it in Netdot.
I think the proper solution would be if the (Cisco) router upstream were to
ignore ARP replies with 0000.0000.0000; then the offending machine would
have found itself isolated. However that is not what actually happened.
Regards,
Brian.
------------------------------
Message: 2
Date: Thu, 20 Sep 2012 23:21:14 -0400
From: William Bulley <[email protected]>
Subject: Re: [Netdot-users] All-zeros MAC
To: Brian Candler <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
According to Brian Candler <[email protected]> on Thu, 09/20/12 at 20:06:
>
> Odd situation arose here in a campus environment, which I thought I'd
> report.
>
> Watching traffic on a switch port showed unicast traffic to another host on
> the subnet with dest MAC address 00:00:00:00:00:00
>
> The switch had refused to put this in its bridge table (obviously bogus MAC
> address) so the packets were going out of all ports. We managed to identify
> it via its hostname in DHCP logs.
>
> The upstream router did have an ARP entry for that IP address with
> 0000.0000.0000 as the MAC address.
>
> However, Netdot had no record for 000000000000 on the network. I'm not sure
> if Netdot had filtered it out when collecting ARP tables, or the router had
> not returned it when its ARP table was queried via SNMP.
>
> If Netdot *is* filtering it out, then I think that's not helpful; we would
> have realised that this bogus MAC address was live on the network sooner if
> we could have seen it in Netdot.
>
> I think the proper solution would be if the (Cisco) router upstream were to
> ignore ARP replies with 0000.0000.0000; then the offending machine would
> have found itself isolated. However that is not what actually happened.
I know netdisco does this in a function called walk_fwtable():
my $fw_mac = $device->fw_mac();
#snip#
foreach my $fw_index (keys %$fw_mac)
{
my $mac = $fw_mac->{$fw_index};
#snip#
next if $mac eq '00:00:00:00:00:00';
#snip#
}
In NETDOT version 1.0.1 there is a call to PhysAddr->validate() in
function walk_fwt() found in Netdot/Model/Device.pm.
In Netdot/Model/PhysAddr.pm the method validate() contains this:
sub validate {
#snip#
}elsif ( $addr =~ /^([0-9A-F]{1})/ && $addr =~ /$1{12}/ ) {
# Assume the all-equal-bits address is invalid
$logger->debug(sub{ "PhysAddr::validate: Bogus address: $addr" });
return 0;
#snip#
}
Could this cause the filtering out of MAC address 000000000000 ??
Regards,
web...
--
William Bulley Email: [email protected]
72 characters width template ----------------------------------------->|
------------------------------
Message: 3
Date: Fri, 21 Sep 2012 10:03:14 -0400
From: Carlos Vicente <[email protected]>
Subject: Re: [Netdot-users] All-zeros MAC
To: William Bulley <[email protected]>
Cc: [email protected], Brian Candler <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 9/20/12 11:21 PM, William Bulley wrote:
> In Netdot/Model/PhysAddr.pm the method validate() contains this:
>
> sub validate {
> #snip#
> }elsif ( $addr =~ /^([0-9A-F]{1})/ && $addr =~ /$1{12}/ ) {
> # Assume the all-equal-bits address is invalid
> $logger->debug(sub{ "PhysAddr::validate: Bogus address: $addr" });
> return 0;
> #snip#
> }
>
> Could this cause the filtering out of MAC address 000000000000 ??
Yes, indeed.
Brian, bogus addresses are a problem because they will likely not be
unique, so there is the potential to create more harm than good.
--
cv
------------------------------
Message: 4
Date: Fri, 21 Sep 2012 10:04:27 -0400
From: Carlos Vicente <[email protected]>
Subject: Re: [Netdot-users] Auto DNS entries
To: Florian Schoedel <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi Frorian,
On 9/20/12 5:32 AM, Florian Schoedel wrote:
> Hello,
>
> does anyone know which dependencies have to be fulfit in order to get
> auto generated dns a records and ptr records?
>
> I've created the forward and reverse zone so far; linked my forward zone
> with my ip subnet; set all interfaces to "Auto DNS" as well es the device.
>
> But after I create a new device "manually", add some interfaces and add
> some IPs to these devices (with auto dns = on) I don't get auto
> generated dns entries.
>
> In the config file I have set "UPDATE_DEVICE_IP_NAMES => 1, # You can
> disable the whole thing"
>
> What's wrong? How can I force netdot to create all dns entries for all
> existing devices?
>
> Is Auto DNS only possible with snmp discovery?
>
I'm afraid so.
cv
------------------------------
Message: 5
Date: Fri, 21 Sep 2012 16:38:37 +0200
From: Phil Regnauld <[email protected]>
Subject: Re: [Netdot-users] All-zeros MAC
To: Carlos Vicente <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Carlos Vicente (cvicente) writes:
> >
> > Could this cause the filtering out of MAC address 000000000000 ??
>
> Yes, indeed.
>
> Brian, bogus addresses are a problem because they will likely not be
> unique, so there is the potential to create more harm than good.
And, they're already in the debug log. Maybe there should be
somewhere more visible to log this kind of stuff ? Stuff that
you really would like to know about.
------------------------------
Message: 6
Date: Fri, 21 Sep 2012 15:36:13 +0000
From: Mike Hertrick <[email protected]>
Subject: Re: [Netdot-users] All-zeros MAC
To: Phil Regnauld <[email protected]>
Cc: "[email protected]" <[email protected]>,
Carlos Vicente <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Phil,
I would use syslog for that. Netdot is not a monitoring system.
On the Cisco Catalyst 4k platform, for example, your condition could be logged
with:
%C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET
Cisco port security features (or equivalent from other brands) deal with this,
too, by rate limiting or dropping frames with invalid MAC addresses.
Then you add a check to your monitoring system to alert you of those syslog
messages.
Regards,
Michael Hertrick
Neovera, Inc.
On Sep 21, 2012, at 10:39, "Phil Regnauld"
<[email protected]<mailto:[email protected]>> wrote:
Carlos Vicente (cvicente) writes:
Could this cause the filtering out of MAC address 000000000000 ??
Yes, indeed.
Brian, bogus addresses are a problem because they will likely not be
unique, so there is the potential to create more harm than good.
And, they're already in the debug log. Maybe there should be
somewhere more visible to log this kind of stuff ? Stuff that
you really would like to know about.
_______________________________________________
Netdot-users mailing list
[email protected]<mailto:[email protected]>
https://osl.uoregon.edu/mailman/listinfo/netdot-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20120921/e94e5a27/attachment-0001.html
------------------------------
Message: 7
Date: Fri, 21 Sep 2012 17:10:48 +0000
From: Brian Candler <[email protected]>
Subject: Re: [Netdot-users] All-zeros MAC
To: Carlos Vicente <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, Sep 21, 2012 at 10:03:14AM -0400, Carlos Vicente wrote:
> Brian, bogus addresses are a problem because they will likely not be
> unique, so there is the potential to create more harm than good.
What sort of harm?
I would rather know that a (non-unique) MAC address is active, than have it
completely ignored.
------------------------------
_______________________________________________
Netdot-users mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-users
End of Netdot-users Digest, Vol 46, Issue 15
********************************************
