| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
Crossposted in hub_mngmt and etherworks.
After installing the Hubwatch software I'm not able to ping the hub. It
appears the ARP fails. The hubs IP addr is 128.116.2.100 the XL590's is
128.116.2.99, mask 255.255.0.0. I have Iris traces included of a
failed ARP and a Good ARP done by connecting the XL590 through a
Ethernet card to a tx port.
The bad ARP packet appears correct except it is padded with garbage in order
to acheive the required 60 byte min ethernet packet size. I can't tell
whether the packet had the garbage on the FDDI or not. I would assume
not since the packet size on the FDDI side has no minimum size.
Could these extra bytes not being zeroed cause ARP not to respond from the HUB.
Config:
----------
The customer has a XLServer 590 with a DEFPA FDDIUTP card he wants to
use for his Hubwatch station. The XL590 is connected to a 900MX
concentrator in a DECHUB 900. The 900 config looks like this.
Slot Module
1 empty
2 DECBridge90
3 empty
4 empty
5 empty
6 900TX
7 900TX
8 900MX
The hub has two lans the thinwire and one FDDI whitch the 2 900tx's and
the 900mx connect to. port 3 of the slot 6 900TX is connected to the
thinwire lan, all other ports are directed out the front.
Bad Trace
--------------
IRIS capture data
Page 1
Bad ARP 07/24/95 10:30:05
** Summary for frame 1 **
1 +25s Broadcast<- 4.100 ARP Request Target=128.116.2.100
** Detail for frame 1 **
ARP:
ARP: - - - - - Address Resolution Protocol - - - - -
ARP:
ARP: Hardware Address Space = 1
ARP: Protocol Address Space = 08-00
ARP: Length of hardware address = 6
ARP: Length of protocol address = 4
ARP: Opcode = 1 (Request)
ARP: Sender's Hardware Addr = AA-00-04-00-64-10
ARP: Sender's Protocol Addr = 128.116.2.99
ARP: Target Hardware Addr = 00-00-00-00-00-00
ARP: Target Protocol Addr = 128.116.2.100
** Hex for frame 1 **
0000: FF FF FF FF FF FF AA 00 04 00 64 10 08 06 00 01 ..........d.....
0010: 08 00 06 04 00 01 AA 00 04 00 64 10 80 74 02 63 ..........d..t.c
0020: 00 00 00 00 00 00 80 74 02 64 CA 68 19 ED 43 56 .......t.d.h..CV
0030: A0 00 31 31 31 31 30 30 30 30 2F 2F ..11110000//
IRIS capture data
Page 2
Bad ARP 07/24/95 10:30:05
** Summary for frame 2 **
2 +2s Broadcast<- 4.100 ARP Request Target=128.116.2.100
** Detail for frame 2 **
ARP:
ARP: - - - - - Address Resolution Protocol - - - - -
ARP:
ARP: Hardware Address Space = 1
ARP: Protocol Address Space = 08-00
ARP: Length of hardware address = 6
ARP: Length of protocol address = 4
ARP: Opcode = 1 (Request)
ARP: Sender's Hardware Addr = AA-00-04-00-64-10
ARP: Sender's Protocol Addr = 128.116.2.99
ARP: Target Hardware Addr = 00-00-00-00-00-00
ARP: Target Protocol Addr = 128.116.2.100
** Hex for frame 2 **
0000: FF FF FF FF FF FF AA 00 04 00 64 10 08 06 00 01 ..........d.....
0010: 08 00 06 04 00 01 AA 00 04 00 64 10 80 74 02 63 ..........d..t.c
0020: 00 00 00 00 00 00 80 74 02 64 CA 68 19 ED 50 10 .......t.d.h..P.
0030: 24 E6 5A 50 00 00 00 08 02 33 00 26 $.ZP.....3.&
GOOD ARP
-------------
IRIS capture data
Page 1
Good ARP 07/24/95 10:30:47
** Summary for frame 0 **
0 Broadcast<-00C095EC2DC7 ARP Request Target=128.116.2.100
** Detail for frame 0 **
ARP:
ARP: - - - - - Address Resolution Protocol - - - - -
ARP:
ARP: Hardware Address Space = 1
ARP: Protocol Address Space = 08-00
ARP: Length of hardware address = 6
ARP: Length of protocol address = 4
ARP: Opcode = 1 (Request)
ARP: Sender's Hardware Addr = 00-C0-95-EC-2D-C7
ARP: Sender's Protocol Addr = 128.116.2.99
ARP: Target Hardware Addr = 00-00-00-00-00-00
ARP: Target Protocol Addr = 128.116.2.100
** Hex for frame 0 **
0000: FF FF FF FF FF FF 00 C0 95 EC 2D C7 08 06 00 01 ..........-.....
0010: 08 00 06 04 00 01 00 C0 95 EC 2D C7 80 74 02 63 ..........-..t.c
0020: 00 00 00 00 00 00 80 74 02 64 00 00 00 00 00 00 .......t.d......
0030: 00 00 00 00 00 00 00 00 00 00 00 00 ............
--------------------------------------------------------------------------------
IRIS capture data
Page 2
Good ARP 07/24/95 10:30:47
** Summary for frame 1 **
1 +.8m 00C095EC2DC7<-08002BB2CCE0 ARP Response
Target=128.116.2.100 Addr=128.116.2.99
** Detail for frame 1 **
ARP:
ARP: - - - - - Address Resolution Protocol - - - - -
ARP:
ARP: Hardware Address Space = 1
ARP: Protocol Address Space = 08-00
ARP: Length of hardware address = 6
ARP: Length of protocol address = 4
ARP: Opcode = 2 (Reply)
ARP: Sender's Hardware Addr = 08-00-2B-B2-CC-E0
ARP: Sender's Protocol Addr = 128.116.2.100
ARP: Target Hardware Addr = 00-C0-95-EC-2D-C7
ARP: Target Protocol Addr = 128.116.2.99
** Hex for frame 1 **
0000: 00 C0 95 EC 2D C7 08 00 2B B2 CC E0 08 06 00 01 ....-...+.......
0010: 08 00 06 04 00 02 08 00 2B B2 CC E0 80 74 02 64 ........+....t.d
0020: 00 C0 95 EC 2D C7 80 74 02 63 00 00 00 00 00 00 ....-..t.c......
0030: 00 00 00 00 00 00 00 00 00 00 00 00 ............
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2552.1 | NETCAD::DOODY | Michael Doody | Tue Jul 25 1995 08:49 | 9 | |
Which slot is designated to provide IP services for the Hub?
Was it changed? It can take a while for the arp cache to age out.
Since you are connecting your NMS to the concentrator it makes
sense to use that (the 900MX) as the IPS module.
If you assign an IP address to the concentrator, can you ping that? It
might help isolate where the problem is occuring.
-Mike
| |||||
| 2552.2 | JULIET::LEE_CA | Tue Jul 25 1995 11:23 | 8 | ||
the 900MX is the management slot. I will try to assign an IP addr to it
and see what happens. There is also a 900EF in a DEChub1 on the same
FDDI and I can not ping it either. I beleive this would acheive the
same outcome as assigning an IP addr to the 900MX
Thanks,
Carey
| |||||
| 2552.3 | NETCAD::DOODY | Michael Doody | Tue Jul 25 1995 11:29 | 5 | |
Yes, sounds like you have a problem with your IP stack or
adapter/driver/cables.
-Mike
| |||||
| 2552.4 | JULIET::LEE_CA | Tue Jul 25 1995 11:38 | 8 | ||
Can someone clear me up on exactly what module or what point whitin the
hub I am actually trying to talk to. I quess what I need to known is
does the hub see the FFDI packet or a bridged ethernet packet after it
has the garbage in it.
Thanks again
Carey
| |||||
| 2552.5 | NETCAD::DOODY | Michael Doody | Tue Jul 25 1995 16:10 | 17 | |
When the concentrator is providing IP services to the MAM, it looks
for packets addressed to the MAM's in-band IP address and forwards
them to the MAM via the internal management channel. Replies from the
MAM go through the management channel to the concentrator, which then
puts them out on the wire/fiber.
Since in your case, your NMS is connected directly to the concentrator,
which is the IPS module, no LAN connections are necessarily involved. The
concentrator need not even be connected to the FDDI lan in the hub, nor
to any other module.
ARPs from your managment station are responded to by the concentrator.
The concentrator's MAC address will be associated with the MAM's in-band
address in your ARP table. This is because the MAM has no MAC and is
why it needs an IP services module.
-Mike
| |||||
| 2552.6 | JULIET::LEE_CA | Thu Jul 27 1995 18:14 | 10 | ||
Is there any reason that the MAM would get confused if a packet of les
than 60 bytes is sent to it.
The reason I ask is that the garbage at the end of the ethernet packet
has no bearing on the problem. I duplicated the good(0's at end) and
bad(junk at end) with IRIS from the ethernet size and the MAM responded
to both. The FDDI packet will be smaller than 60 bytes since padding is
not required. No min packet size.
Carey Lee
| |||||
| 2552.7 | DEFPA V1.14 | NPSS::LIZOTTE | Network Product Support | Tue Aug 08 1995 08:38 | 4 |
This issue was worked as an IPMT escalation CFS.30567. The fix is in
the lastest DEFPA driver V1.14 dated 7/17/95. A problem with IRQ
settings below 10 was seen in earlier versions.
| |||||