DComTalk.com

In the past, I have posted about SNMP difficulties on Baystack 450's, e.g.,

http://groups.google.ca/group/comp.dcom ... a89079e78e

Today I have an issue that seperately affects a Baystack 470 and
a Baystack 5510 (configured for layer 2 switching only) that I'm hoping
someone will have a clue about.

On both devices, when I probe ipNetToMediaPhysAddr, some of the time
the entries that are returned are against the wrong interface. For example,

/* wrong -- not really on port 2 */
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.2.X.Y.Z.235 = 0:11:95:73:11:f7

/* right -- really is port 47 */
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.47.X.Y.Z.31 = 0:0:77:87:89:7a

On the 5510 the above is from, the incorrect port is always 2; on the
470, the incorrect port is always 1. There is nothing at all connected
on port 2 of the 5510; there does happen to be something on port 1 of
the 470.

The two hosts that this happens to most frequently are not even
trying to communicate directly with either device (and it's the same two
for both devices), so there shouldn't even -be- any ipNetToMediaTable
entries for them. We have verified with tcpdump, and we have reset the 470
in case old connection information was "stuck".

The incorrect ports do show up occasionally for two other IPs, but
those two IPs -are- doing SNMP monitoring of the switches, so it is
at least explicable as to why they have ipNetToMediaTable entries at all.

For now we can detect the situation by cross-checking
the MAC to port table at 17.4.3.1.2 and noting cases in which the MACs from
the output of the ipNetToMediaPhysAddress tables have an associated
17.4.3.1.2 port number which is not the same as the port from the
ipNetToMediaPhysAddress.

I am reading off the ipNetToMediaPhysAddress entries via an snmpwalk
starting from that node. I just checked, and I get the same results
of I walk the entire ip.ipNetToMediaTable table, so this is not
another instance of the problem mentioned in my referenced thread with
walking substructures of tables. And the entries are -not- marked as
invalid...


Would anyone be able to shed any light as to:

a) why some hosts are showing L3 connections to these managed L2 switches
even though the hosts are not trying to interact with the switch?; and

b) why the ipNetToMediaPhysAddress table sometimes has incorrect
interface numbers?


A sample walk from ip.ipnetToMediaTable is enclosed:

ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaIfIndex.2.X.Y.Z.152 = 2
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaIfIndex.2.X.Y.Z.235 = 2
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaIfIndex.47.X.Y.Z.31 = 47
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaIfIndex.47.X.Y.Z.134 = 47
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.2.X.Y.Z.152 = 0:f:1f:d6:53:8f
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.2.X.Y.Z.235 = 0:11:95:73:11:f7
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.47.X.Y.Z.31 = 0:0:77:87:89:7a
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.47.X.Y.Z.134 = 0:f:1f:d6:44:c
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaNetAddress.2.X.Y.Z.152 = IpAddress: 192.70.172.152
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaNetAddress.2.X.Y.Z.235 = IpAddress: 192.70.172.235
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaNetAddress.47.X.Y.Z.31 = IpAddress: 192.70.172.31
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaNetAddress.47.X.Y.Z.134 = IpAddress: 192.70.172.134
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaType.2.X.Y.Z.152 = dynamic(3)
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaType.2.X.Y.Z.235 = dynamic(3)
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaType.47.X.Y.Z.31 = dynamic(3)
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaType.47.X.Y.Z.134 = dynamic(3)
--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD

Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:

Today I have an issue that seperately affects a Baystack 470 and
a Baystack 5510 (configured for layer 2 switching only) that I'm hoping
someone will have a clue about.

Why would you want to query the ipNetToMediaTable (ARP Table) on a L2
switch anyway?

On both devices, when I probe ipNetToMediaPhysAddr, some of the time
the entries that are returned are against the wrong interface. For example,

Would anyone be able to shed any light as to:

a) why some hosts are showing L3 connections to these managed L2 switches
even though the hosts are not trying to interact with the switch?; and

The hosts are most likely incidentally sending traffic that the
switch's management TCP/IP stack is picking up, such as multicast,
broadcast, or scanning unicast traffic that the switch then attempts
to reply to, creating an ipNetToMediaTable entry.

b) why the ipNetToMediaPhysAddress table sometimes has incorrect
interface numbers?

I've seen similar weirdness on 8600 switches as well. If it is
incidental host traffic as described above, then perhaps this traffic
is arriving on a different interface or through a different path than
you would otherwise expect. Also, is it possible that the device used
to be on that other interface and had since moved, but the ARP entry
isn't updated because it is a L2 switch?

I just use the ARP entry to get the MAC, then cross reference the MAC
in the FDB to get the port number, ignoring the port number returned
by ipNetToMediaTable completely.

There are several reasons. One of those is that I am trying to
track the correspondance of MACs and IPs.

We static-IP everything, but I have difficulties with people moving
devices around, swapping NICs, re-configuring IP addresses, bringing in
laptops from one of our other offices, and bringing in home laptops (or
even home computers.) Our people do genuinely need to move some
of the systems around in the course of their work, and our PC
install and repair operations are decentralized -- so I would need
to make a firm case to Management in order to put in MAC address
based security. If I can squeeze enough information out of devices
to be able to keep reasonable track without imposing a lockdown
(and thus bottlenecking other people's work on the small number
of network staff), that is preferable.

Hence, I probe what I can -- the ARP tables of L2 devices
contributes to the knowledge, as does the ARP tables of Novell,
and of printers. If, for example, a device is connected but
does not happen to try to talk outside of its subnet, then the
IP address is not going to be recorded on our LAN router
[which appears to be timing out it's ARP tables quite quickly at
the best of times :(], so I might find the MAC <-> IP
mapping for the host on one of the printers.

The ARP tables of the L2 switches also contributes to information
about routing leaks: if I see the wrong MAC associated with
one of the management stations that are indeed talking to the switch
itself, then I know that the device whose MAC I see must have
unexpectedly routed the packet.

Checking the ARP tables on the L2 switches also gives me information
about which devices are accessing the switches directly -- i.e.,
gives me information about whether someone is making unauthorized
connections to the switches or attempting unauthorized SNMP monitoring.


:> a) why some hosts are showing L3 connections to these managed L2 switches
:> even though the hosts are not trying to interact with the switch?; and

:The hosts are most likely incidentally sending traffic that the
:switch's management TCP/IP stack is picking up, such as multicast,
:broadcast, or scanning unicast traffic that the switch then attempts
:to reply to, creating an ipNetToMediaTable entry.

I noted in my original posting that we'd monitored the traffic.
No multicast at all, no unicast traffic to the affected switches,
and the only broadcasts from the hosts were completely explicable
regular ARP queries (none of which were of the switches' address.)


:> b) why the ipNetToMediaPhysAddress table sometimes has incorrect
:> interface numbers?

:I've seen similar weirdness on 8600 switches as well. If it is
:incidental host traffic as described above, then perhaps this traffic
:is arriving on a different interface or through a different path than
:you would otherwise expect.

I noted in my original post that on one of the two devices,
there isn't *anything* on the port being registered against
(the port is not connected and shows as down.) On the other device,
there is something on the port but it's a regular host. And as I
indicated in my original posting, the MAC corresponding to the
connection are *not* showing up against that port in the 17.* tables
that do the regular layer 2 mapping of MAC to port.

Both the 470 and 5510 are "leaf" switches: there is only one
uplink interface on each of them. And if there was an alternate
topology that I didn't know about, it wouldn't be just those
particular MACs that showed up misplaced, it would be everything
else that links via the switch.

: Also, is it possible that the device used
:to be on that other interface and had since moved, but the ARP entry
:isn't updated because it is a L2 switch?

I noted in my original post that we'd reset one of the two switches
against the possibility of stuck data; the oddities showed up again
within 30 minutes. I am also certain for one of the switches
that the affected port has never been used as an uplink. The
phantom devices are, by the way, not directly attached to the
affected switches... indeed, one of the two hosts showing up is
4 switch-hops removed.
--
Feep if you love VT-52's.

"We static-IP everything, but I have difficulties with people moving
devices around, swapping NICs, re-configuring IP addresses, bringing in

laptops from one of our other offices, and bringing in home laptops (or

even home computers.) Our people do genuinely need to move some
of the systems around in the course of their work, and our PC
install and repair operations are decentralized -- so I would need
to make a firm case to Management in order to put in MAC address
based security. If I can squeeze enough information out of devices
to be able to keep reasonable track without imposing a lockdown
(and thus bottlenecking other people's work on the small number
of network staff), that is preferable. "

Without getting too much into how your network topology setup, in my
view you could augment this by changing your processes slightly.
Sounds like a classic Network group versus the Helpdesk scenario you
got going there.


I would use STATIC IPs for routers/switches and servers ONLY! These
don't change often and should follow a documented change control
procedures, right?

I would use STATIC DHCP reservations for known static devices.
Printers for example (users can use DNS names for their queues so
MAC/IP changes are then transparent to them).

I would also use STATIC DHCP reservations for laptops at each site.

Everyone else uses Dynamic addresses (home PCs, ughh). That address
"range" would then have a limited or no access to services via Firewall
or Router filters.

Locking down your network this way will insure people follow your
access processes.

Then query your DHCP server logs to see who's asking for addressing,
who's using current addresses, etc. You have a standard Server,
Printer, PC naming standard right?

That way if a PC gets a new MAC address, they get an IP from the DHCP
server reservation you provide, if not, guess what it won't go
anywhere. You can note these unapproved changes, etc. Take control
man, you have the power! ;-)