Question:
he is trying to configure 2 network cards & bootp.
Env:
Mod 560 standard ethernet adapter bnc format
Mod 580 standard ethernet adapter bnc format and a fddi network adapter
AIX 3.2.5
Desc:
As far as the customer knows bootp is not working on the 580's fddi
network.
Action:
First added a route from the 560 to the fddi network. This worked fine.
Then had the customer run bootp in the debug mode to see if there was
a problem with bootp itself. This did not prove fruitful, the xstation
did not boot up at all. The customer did mention a laptop which could
be used.
Told the customer that I would like him to get the laptop and use
it to see if the problem is local only to the fddi network.
Env:
Had the customer attempt to boot up a laptop on the ethernet
segment and this worked fine with the desired configuration.
Then attempted to boot up the same machine on the fddi network.
This failed, the RISC did however get the initial bootp request,
recognize the hardware address and then attempt to send out the
requsite ip address. Some where between the fddi cable connecting
to the 580 and the HUB.
The consensus is that the bootp packet is getting perhaps once it
goes through the HUB bootp is lost. The suggestion was to use a
sniffer to see if this is the problem. The customer is also going
to send in a copy of bootp in debug mode for us to confirm that
the packet is being sent by the RISC.
Action:
Called the customer back to get the information he wanted IBM to have.
The customer referenced RFC 1390 saying that the HUB that they were
using actually has a front end on it that goes from fddi to ethernet.
This HUB uses the new arp code (either 6 or 1) and the RISC uses the
older ARP code. It might be that the differeing arp code will not
forward the bootp packet through the HUB. The customer said that
he had cabletron looking into the issue.
Nxt : I will leave item in my queue until the customer gets
back to me.
Action:
Customer called in and wanted to know the arp code type IBM uses.
As per PMR 020X0 B653 and PMR 8X087 B068 IBM supports arp code
one. Here is the info from RFC 1390:
According to RFC 1390, Transmission of IP and ARP over FDDI Networks,
this is incorrect. The passage goes as follows:
.Unfortunately, differing values between Ethernet and IEEE 802
networks cause interoperability problems in bridged environments. In
order to not preclude interoperability with Ethernets in a bridged
environment, ARP packets shall be transmitted with a hardware type
code of 1 [ethernet]. ARP packets shall be accepted if received with
a hardware type code of 1.
Relayed this to the customer.
The customer said that he talked to the people at CableTron and
(after configuring a RISC to exactly the same specifications as
the customer's) CableTron found that the bootp request from the
fddi hub to the fddi media into the RISC and then out of the
ethernet adapter onto the ethernet segment.
Action:
Call the customer back in the morning and get the following
information:
-ifconfig fi0
-ifconfig en0
-netstat in
-netstat -rn
-host \
-host \
-host \
-reconfirm picture of the network
Action:
Called the customer back to see exactly what the routes on his RISC
were and if there was correct hostname resolution. Here are the results:
/etc/hosts
cardinal 192.8.8.3 \#en0
cardinal 192.8.9.3 \#fi0
Route Tree for Protocol Family 2:
(root node)
127 127.0.0.1 U lo0
192.8.8 192.8.8.3 U en0
192.8.9 192.8.9.3 U fi0
ifconfig fi0
fi0: flags=2008063\
inet 192.8.9.3 netmask 0xffffff00 broadcast 192.8.9.255
ifconfig en0
en0: flags=000063\
inet 192.8.8.3 netmask 0xffffff00 broadcast 192.8.8.255
Action:
Called the customer back to ask for the iptrace to be emailed
to me at my address, also asked the customer to give me
CableTron's address so that I could talk to them.
Action:
CableTron called and left me voice mail. The person that
I am supposed to contact is Phil. Calling CableTron to
get some specific information on the hub.
Next:
Found out that this hub acts as a bridge and cannot be a
gateway. The hub converts the fddi packets/frames to
ethernet frames and vice versa. Also Phil asked me to look
at where was listening and responding to ensure that the
RISC was correct.
Action:
The customer left me the names of the people he is working with
at CableTron. I will call them and get some preliminary
information on the hub.
Action:
Recieved the following information from the customer through internet
mail: -iptrace done during an attempt to boot a PC using bootp -the
results of bootp in debug mode from the PC booting successfully on the
ethernet segment and unsuccessfully from the fddi segment -the
/etc/bootptab file from the 580 We have currently researched the
information and talked to CableTron on the issue, and what was
discovered is that there bootp on the RISC is getting the packet and
then recognizing the hardware address and sending the PC its correct
hardware address.
Next Action:
Talk to CableTron on the issue to see how the customer can best be
helped.
Test Case:
Carefully look at the information that the customer has sent in:
1) Here is the information from the /etc/bootptab file, the hardware
address and the ip address of the PC
lt001:ip=192.8.9.66:
ht=1:ha=0080C7A9E40F:sm=255.255.255.0:
2) The two entries of bootpd in debug mode show up as exactly the same
(excluding ip addresses). The only major differences are the network
media, 10baseT ethernet and fddi, and the fact that when the PC is on
the ethernet segment it will boot when the PC is on the fddi segment
the PC will not boot.
3) the iptrace done when attempting to boot on the fddi segment:
Packet Number 1
FDDI: =====( packet transmitted on interface fi0 )=====Tue Nov 22 09:25:11 1994
FDDI: FDDI packet FDDI: FDDI MAC header:
FDDI: frame control field = 50
FDDI: [ src = 10:00:5a:b8:21:b8, dst = ff:ff:ff:ff:ff:ff]
FDDI: 802.2 LLC header:
FDDI: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: \< SRC = 192.8.9.3 > (cardinal)
IP: \< DST = 192.8.9.255 >
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=72, ip_id=34118, ip_off=0
IP: ip_ttl=30, ip_sum=844c, ip_p = 17 (UDP)
UDP: \
UDP: [ udp length = 52 | udp checksum = d54a ]
UDP: 00000000 02010000 00020000 c0080800 00000000 |................|
UDP: 00000010 00000000 00000001 00020000 c0080900 |................|
UDP: 00000020 00000000 00000000 00000001 |............ |
Packet Number 2
FDDI: =====( packet received on interface fi0 )=====Tue Nov 22 09:25:16 1994
FDDI: FDDI packet FDDI: FDDI MAC header:
FDDI: frame control field = 51
FDDI: [ src = 00:01:e3:95:27:f0, dst = ff:ff:ff:ff:ff:ff]
FDDI: 802.2 LLC header:
FDDI: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: \< SRC = 0.0.0.0 >
IP: \< DST = 255.255.255.255 >
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=1, ip_off=0
IP: ip_ttl=60, ip_sum=7da5, ip_p = 17 (UDP)
UDP: \
UDP: [ udp length = 308 | udp checksum = 0 ]
UDP: 00000000 01010600 c7a9e40f 00010000 00000000 |................|
UDP: 00000010 00000000 00000000 00000000 0080c7a9 |................|
UDP: 00000020 e40f0000 00000000 00000000 00000000 |................|
UDP: 00000030 00000000 00000000 00000000 00000000 |................|
UDP: 00000040 00000000 00000000 00000000 00000000 |................|
UDP: 00000050 00000000 00000000 00000000 00000000 |................|
UDP: 00000060 00000000 00000000 00000000 00000000 |................|
UDP: 00000070 00000000 00000000 00000000 00000000 |................|
UDP: 00000080 00000000 00000000 00000000 00000000 |................|
UDP: 00000090 00000000 00000000 00000000 00000000 |................|
UDP: 000000a0 00000000 00000000 00000000 00000000 |................|
UDP: 000000b0 00000000 00000000 00000000 00000000 |................|
UDP: 000000c0 00000000 00000000 00000000 00000000 |................|
UDP: 000000d0 00000000 00000000 00000000 00000000 |................|
UDP: 000000e0 00000000 00000000 00000000 63825363 |............c.Sc|
UDP: 000000f0 00000000 00000000 00000000 00000000 |................|
UDP: 00000100 00000000 00000000 00000000 00000000 |................|
UDP: 00000110 00000000 00000000 00000000 00000000 |................|
UDP: 00000120 00000000 00000000 00000000 |............ |
Packet Number 3
FDDI: =====( packet transmitted on interface fi0 )=====Tue Nov 22 09:25:16 1994
FDDI: FDDI packet FDDI: FDDI MAC header:
FDDI: frame control field = 50
FDDI: [ src = 10:00:5a:b8:21:b8, dst = 00:80:c7:a9:e4:0f]
FDDI: 802.2 LLC header:
FDDI: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: \< SRC = 192.8.9.3 > (cardinal)
IP: \< DST = 192.8.9.66 >
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=34377, ip_off=0
IP: ip_ttl=30, ip_sum=8306, ip_p = 17 (UDP)
UDP: \
UDP: [ udp length = 308 | udp checksum = f965 ]
UDP: 00000000 02010600 c7a9e40f 00010000 00000000 |................|
UDP: 00000010 c0080942 c0080903 c0080903 0080c7a9 |...B............|
UDP: 00000020 e40f0000 00000000 00000000 00000000 |................|
UDP: 00000030 00000000 00000000 00000000 00000000 |................|
UDP: 00000040 00000000 00000000 00000000 00000000 |................|
UDP: 00000050 00000000 00000000 00000000 00000000 |................|
UDP: 00000060 00000000 00000000 00000000 00000000 |................|
UDP: 000000UDP: 000000a0 00000000 00000000 00000000 00000000 |................|
UDP: 000000b0 00000000 00000000 00000000 00000000 |................|
UDP: 000000c0 00000000 00000000 00000000 00000000 |................|
UDP: 000000d0 00000000 00000000 00000000 00000000 |................|
UDP: 000000e0 00000000 00000000 00000000 63825363 |............c.Sc|
UDP: 000000f0 0104ffff ff00ff00 00000000 00000000 |................|
UDP: 00000100 00000000 00000000 00000000 00000000 |................|
UDP: 00000110 00000000 00000000 00000000 00000000 |................|
UDP: 00000120 00000000 00000000 00000000 |............ |
Packet Number 4
FDDI: =====( packet received on interface fi0 )=====Tue Nov 22 09:25:31 1994
FDDI: FDDI packet FDDI: FDDI MAC header:
FDDI: frame control field = 51
FDDI: [ src = 00:01:e3:95:27:f0, dst = ff:ff:ff:ff:ff:ff]
FDDI: 802.2 LLC header:
FDDI: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: \< SRC = 0.0.0.0 >
IP: \< DST = 255.255.255.255 >
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=2, ip_off=0
IP: ip_ttl=60, ip_sum=7da4, ip_p = 17 (UDP)
UDP: \
UDP: [ udp length = 308 | udp checksum = 0 ]
UDP: 00000000 01010600 c7a9e40f 0e010000 00000000 |................|
UDP: 00000010 00000000 00000000 00000000 0080c7a9 |................|
UDP: 00000020 e40f0000 00000000 00000000 00000000 |................|
UDP: 00000030 00000000 00000000 00000000 00000000 |................|
UDP: 00000040 00000000 00000000 00000000 00000000 |................|
UDP: 00000050 00000000 00000000 00000000 00000000 |................|
UDP: 00000060 00000000 00000000 00000000 00000000 |................|
UDP: 00000070 00000000 00000000 00000000 00000000 |................|
UDP: 00000080 00000000 00000000 00000000 00000000 |................|
UDP: 00000090 00000000 00000000 00000000 00000000 |................|
UDP: 000000a0 00000000 00000000 00000000 00000000 |................|
UDP: 000000b0 00000000 00000000 00000000 00000000 |................|
UDP: 000000c0 00000000 00000000 00000000 00000000 |................|
UDP: 000000d0 00000000 00000000 00000000 00000000 |................|
UDP: 000000e0 00000000 00000000 00000000 63825363 |............c.Sc|
UDP: 000000f0 00000000 00000000 00000000 00000000 |................|
UDP: 00000100 00000000 00000000 00000000 00000000 |................|
UDP: 00000110 00000000 00000000 00000000 00000000 |................|
UDP: 00000120 00000000 00000000 00000000 |............ |
Packet Number 5
FDDI: =====( packet transmitted on interface fi0 )=====Tue Nov 22 09:25:31 1994
FDDI: FDDI packet FDDI: FDDI MAC header:
FDDI: frame control field = 50
FDDI: [ src = 10:00:5a:b8:21:b8, dst = 00:80:c7:a9:e4:0f]
FDDI: 802.2 LLC header:
UDP: 00000080 00000000 00000000 00000000 00000000 |................|
UDP: 00000090 00000000 00000000 00000000 00000000 |................|
FDDI: [ src = 10:00:5a:b8:21:b8, dst = 00:80:c7:a9:e4:0f]
FDDI: 802.2 LLC header:
FDDI: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: \< SRC = 192.8.9.3 > (cardinal)
IP: \< DST = 192.8.9.66 >
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=328, ip_id=34994, ip_off=0
IP: ip_ttl=30, ip_sum=809d, ip_p = 17 (UDP)
UDP: \
UDP: [ udp length = 308 | udp checksum = eb65 ]
UDP: 00000000 02010600 c7a9e40f 0e010000 00000000 |................|
UDP: 00000010 c0080942 c0080903 c0080903 0080c7a9 |...B............|
UDP: 00000020 e40f0000 00000000 00000000 00000000 |................|
UDP: 00000030 00000000 00000000 00000000 00000000 |................|
UDP: 00000040 00000000 00000000 00000000 00000000 |................|
UDP: 00000050 00000000 00000000 00000000 00000000 |................|
UDP: 00000060 00000000 00000000 00000000 00000000 |................|
UDP: 00000070 00000000 00000000 00000000 00000000 |................|
UDP: 00000080 00000000 00000000 00000000 00000000 |................|
UDP: 00000090 00000000 00000000 00000000 00000000 |................|
UDP: 000000a0 00000000 00000000 00000000 00000000 |................|
UDP: 000000b0 00000000 00000000 00000000 00000000 |................|
UDP: 000000c0 00000000 00000000 00000000 00000000 |................|
UDP: 000000d0 00000000 00000000 00000000 00000000 |................|
UDP: 000000e0 00000000 00000000 00000000 63825363 |............c.Sc|
UDP: 000000f0 0104ffff ff00ff00 00000000 00000000 |................|
UDP: 00000100 00000000 00000000 00000000 00000000 |................|
UDP: 00000110 00000000 00000000 00000000 00000000 |................|
UDP: 00000120 00000000 00000000 00000000 |............ |
++++++ END OF REPORT ++++++
Summary of RPC CALL packets
\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#
\#\# end ipreport \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#
\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#
-Note: Packets 2&4 show the boot prequest (denoted by the source address
of 0.0.0.0 [for further reference please see RFC 1532 on the Bootstrap
Protocol])
Also packets 3&5 show the RISC's response to the request notice the ip
address which looks identical to the the ip adress found in the
/etc/bootptab file.
-Also, this informtion is being faxed to both the customer and
CableTron. We will continue to work with CableTron on the
issue to ensure that the problem is solved.
Response:
Spoke to Phil at CableTron and agreed to ask the customer the
following things:
-does the customer have any kind of sniffer?
answer: no
-what is the most current level of fddi software?
answer: the customer has the following PTF's, U422541 and U428325
-does the PC require any type of tftp file to boot up
answer: no, not as far as the customer knows (note: The
customer reminded me that the PC booted up without any problem
on an ethernet segment from the same 580 with the ethernet
Phil also is sending IBM CableTron's bootptab file on their
test RISC and some information on the bridge.
Response:
Act : Here is the level 3 response :
This is a known problem. fddi is not supported by bootpd in 3.2.5
and will not be supported until release 4.1. Here is more information PAGE
on the problem: 7
This problem is mentioned in rfc 1188 : OF
"In order to not preclude interoperability in a bridged environment, 9
the hardware addresses in ARP packets (ar$sha, ar$tha) must be
carried in "canonical" bit order, with the Group bit positioned as
the low order bit of the first octet. As FDDI addresses are normally
expressed with the Group bit in the high order bit position, the
addresses must be bit-reversed within each octet."
There is a workaround:
circumvention is to ping the xstation server from the xstation,
so that the inverted hw-addr. is in the arp-table,, then
the xstation can boot normally. OID
Possible options: BDC
1) Try workaround
2) change bootpd code so that the client hardware address put in the
arp-table is bit-reversed within each octet. (Code is in PAGE
/usr/lib/dwm/bootp as bootpd.c) The bootpd code is provide on the 8
machine with a makefile so changes like this could be made. I OF
have a code change that has worked in other situations but I am not 9
sure it would work in this one. It would not be supported.
Nxt : CC
Support Line: Xstations wont boot over fddi. ITEM: P1172L
Dated: April 1995 Category: N/A
This HTML file was generated 99/06/24~13:30:38
Comments or suggestions?
Contact us