| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 744.1 | | MARVIN::HART | Tony Hart, InterNetworking Prod. Eng. Group | Thu Feb 06 1997 11:57 | 46 |
| > 1.- Configure IP on Routeabout and DECnis. It is properly running
> so no discussion on that point.
OK, so I can assume that you can ping the DHCP Server from the PC
and vice-versa, if not then BOOTP Relay isn't likely to work.
> 1.- Did i missed any configuration Step. Do i have to configure
> anything on the DECnis?
Everything's fine, the DECNIS plays no part in this, other than to
forward IP packets.
> 2.- Can somebody explain how the WNT_server knows what DHCP scope
> allocate to PCs on LAN A?
I'm not familar with the NT DHCP Server, but you must have to key
the address range off the PC's MAC address, or possibly its node
name if the PC knows its name. The DHCP Server must have a route
back to the RouteAbout, if ping works then it has.
> 3.- Is this supported on Frame Relay and normal Leased Lines using
> in both cases PPP.
Yes.
From the ELS messages the routeabout is certainly receiving the
BOOTP request messages, but there's no indication that its
receiving replies from the Server.
You could use DTF to trace the PPP link and see whether the BOOTP
requests are actually being sent. If you don't see any then the
problem is on the RouteAbout, otherwise the problem is elsewhere.
On your UNIX box you could turn on debug messages on the bootp
deamon, on Ultrix this is done by adding -d to the bootp line in
inetd.conf (you'll need to restart inetd afterwards). This should
result in a message being written to the syslog file for every BOOTP
request received.
I'm not sure what you can do on the DHCP Server directly, I suspect
not much. If you have the Clearvision Router Configurator installed
on the server, then fire up its BOOTP Server, it will log all the
requests it sees.
Tony
|
| 744.2 | Get a trace of the relayed packet on the PPP link | MARVIN::RIGBY | No such thing as an alpha beta | Thu Feb 06 1997 12:16 | 8 |
| A bootp relay inserts its address in the gateway field of the BOOTP request. It
is this address that you can make the DHCP server use for its scope so that it
gives out an IP address for the correct subnet.
As Tony says, use DTF to get the actual packets sent out on the PPP link traced
by the RouteAbout. (You won't be able to trace them on the DECNIS as they will
be forwarded by the linecards without ever going near the management processor
as the DECNIS is in no way involved in the BOOTP relay process this way round.)
|
| 744.3 | Multiple personality of BOOTP Relay! | IB001::AMBROSIO | | Fri Feb 07 1997 05:07 | 91 |
| Hi,
Thanks for your suggestions. I investigated a little more and this is
what i got:
1.- ROUTEABOUT is catching DHCP request form PCs on LAN A and
forwarding them to WNT_Server. This can be checked with BTP
EVENTS on RouteAbout. But we traced on LAN B with a PacketProbe
and we found DHCP packets with this form:
Level 1 / Ethernet
Dest Address : 00-00-f8-00-ca-d2
Source Address : DEC -00-82-cc
Type : DoD IP
Level 2 / DoD IP
Protocol : 17 (DODUDP)
Source Address : 16.254.197.2 <----- The key
Dest Address : 16.190.32.6
Level 3 / DoD UDP
Source Port : 67 (BOOTPS)
Dest Port : 67 (BOOTPS)
This is an extract but if you need detailed packet just let me know
2.- Tracing BOOTP service on UNIX system showed that BOOTP request
coming from LAN A sometimes are identified with Source Address of
Ethernet interface of Routeabout and other times the Source Address is
the address of the Serial Line of the Routeabout. This detail seems not
to bother to BOOTP but is not good for DHCP.
3.- On WNT_Server i have no LOG of DHCP request but we did a simple
test. We created a DHCP SCOPE with IP WAN SUBNET (16.254.197.0) and
then IT WORKS, but assigning IP addresses of PPP link instead of IP
addresses of LAN A. So this is not the solution.
My conclusions:
A.- Routeabout is forwarding DHCP requests fine, except that in the
Source Address of DHCP packet it should stamp the IP address of the
Ethernet interface.
B.- Routeabout randomly stamps on Source Address of DHCP packet either
the address of the Ethernet interface or the address of Serial Line
interface.
C.- DHCP identifies the scope to assign an IP address from looking at
the Source Address on the DHCP relayed packet.
D.- WNT Server do not let define a DHCP SCOPE identified by the IP WAN
address of the PPP link but allocating addresses of IP LAN subnet.
Or at least i do not know how to do it.
Questions:
I.- Can i configure Routeabout to stamp its Ethernet interface IP
address on BOOTP relay packets?
II.- Is this a BUG and can be solved?
III.- And if i have several IP addresses defined on Ethernet interface?
IV.- What would stamp Routeabout on BOOTP relayed packets if Serial
Line is IP Unnumbered?
V.- Have anyone teste RIP over IP Unnumbered between Routeabout and
DECnis? In my case it never worked so i have to use IP WAN addresses.
DETAILS OF MY CONFIGURATION:
a) Ethernet Interface has two addresses (16.190.16.1 and 16.190.208.1).
Even though the DHCP subnet is 16.190.208.0
b) Serial Line has its own IP address (16.254.197.1 on DECnis and
16.254.197.2 on Routeabout)
c) IP routing protocol i need to configure is RIP (still used in
EASYnet)
d) Data-Link is PPP over Serial Linea but i have also one RouteAbout
with Frame Relay.
Any quick answer is welcome because this problem is affecting a Digital
site Barcelona and our deployement of W-NT program.
Cheers,
Andres.
|
| 744.4 | | MARVIN::HART | Tony Hart, InterNetworking Prod. Eng. Group | Mon Feb 10 1997 04:11 | 12 |
| The code uses the outgoing interface address as the gwaddr field in the BOOTP
and as the source address in the IP header (the gwaddr field is the address
that the Server uses to send the reply to, I assume its also using that as its
key into the database).
I supprised that you saw both the Ethernet and Sync line addresses, you should
only have seen the Sync address, maybe you could post a complete packet ?
In any case, you might want to submit an IPMT case to get this behaviour looked
at, if this is serious enough it might make it into a fix kit.
Tony
|
| 744.5 | Mi gozo en un pozo = :-( | IB001::AMBROSIO | | Tue Feb 11 1997 11:30 | 235 |
| Hello,
After more detailed on-site investigations i have to modify some of my
statements on 744.3 and i can now reply to 744.4:
> A.- Routeabout is forwarding DHCP requests fine, except that in the
> Source Address of DHCP packet it should stamp the IP address of the
> Ethernet interface.
This "should" means "in order to make DHCP service work without
modifying anything in the WNT-server". It really depends on RFCs.
> B.- Routeabout randomly stamps on Source Address of DHCP packet either
> the address of the Ethernet interface or the address of Serial Line
> interface.
Unfortunately i cannot support this statement anymore, i've been
looking at UNIX daemon's logs of 7 days and i find that BOOTP Relay
modyle is always using the OUTGOING INTERFACE ADDRESS in the
gwaddr field. The only evidence is reflected on notes
TURRIS::DIGITAL_UNIX note 8381.0 posted by a collegue on my group.
> C.- DHCP identifies the scope to assign an IP address from looking at
> the Source Address on the DHCP relayed packet.
That is still true but anyway this has to be answered in other
conference.
But my problem was: WHY the DHCP service was running on only one building and
not working on four other buildings? Yesterday i got the answer:
PC_CLIENT
|
+---+-------+-----------------+-------+ LAN A (Barcelona)
| |* IP Subnets: 16.190.16
ROUTEABOUT(A) ROUTEABOUT(B) 16.190.208
|* |
| isdn
|
PPP (backup)
|
| isdn
| |
DECNIS(A) DECNIS(B)
| |
+----+----------+------+---+ LAN B (Madrid)
|
WNT_Server
DHCP scopes: 16.190.32.[...]
16.190.208.[...]
LAN A is connected to LAN B with a configuration shown in above picture.
Normal link is running on A routers while if something fails on A connection
i can setup ISDN connection through B routers.
Both ROUTEABOUTS have BOOTP relay feature enabled and in wildcards (*) is
signaled the OUTGOING INTERFACE of a BOOTP relayed packet to be sent to
BOOTP servers (WNT_Server). The outgoing interfaces of ROUTEABOUTS are:
Routeabout Outoging Interface Address
A PPP/0 16.254.197.2
B Eth/0 16.190.16.13 AND 16.190.208.4
BOOTP packets relayed from ROUTEABOUT A are discarded by WNT-Server because it
has not defined a SCOPE for addresses 16.254.197, while ROUTEABOUT B can send
packets either with address 16.190.16.13 or 16.190.208.4. ONLY IF ROUTEABOUT B
sends packets with GWADDR = 16.190.208.4 THEN the WNT-Server allocates an IP
address from SCOPE 16.190.208.
But Eth/0 IP address stamped by ROUTEABOUT B seems to be random and it not
always work on this config. Today i deleted address 16.190.16.13 so it is now
working OK.
Below is an output of DTF utility taken from PPP Interface on ROUTEABOUT A
showing BOOTP protocol information only, and the registered requests logged
on an UNIX system which is supposted to load LPSs with BOOTP also. It receives
the DHCP request but is not answered.
I will now investigate more on the W-NT and DHCP configuration side because
it seems that ROUTEABOUT is working according to BOOTP standards which it is
supposed support DHCP standards.
Question: Did anybody configured DHCP for BOOTP relay environment?
Cheers,
Andres.
--- BEGIN ---
--- DTF output of protocol BOOTP on PPP INTERFACE * on ROUTEABOUT A ---
-DTF- 0 Tx 332 of 332 at 3788001 PPP/0 3100
Status: 00000000 Context: 00000000 Function: 00000082
--------------------------------------------------------------------
UDP port: BOOTPS
----------------
operation Request
Hardware type Ethernet (10Mb)
Hardware length 16
Hops 1
XID 0xF403B109
Boot attempt time 00:42:40
Flags 0x8000
Client IP address 0.0.0.0
Your IP address 0.0.0.0
Gateway IP address 16.254.197.2
Client hardware address 52-41-53-20-10-E6
Server name
File
Magic Identifier: Standard options
----------------------------------
Message DHCPrequest
Client Identifier 015241532010E62EB85C91BA0102000000
Requested IP Address 16.190.208.102
Hostname string NANO19
End of options
-DTF- 0 Tx 332 of 332 at 3788001 PPP/0 3101
Status: 00000000 Context: 00000000 Function: 00000082
--------------------------------------------------------------------
UDP port: BOOTPS
----------------
operation Request
Hardware type Ethernet (10Mb)
Hardware length 16
Hops 1
XID 0xF403B109
Boot attempt time 00:42:40
Flags 0x8000
Client IP address 0.0.0.0
Your IP address 0.0.0.0
Gateway IP address 16.254.197.2
Client hardware address 52-41-53-20-10-E6
Server name
File
Magic Identifier: Standard options
----------------------------------
Message DHCPrequest
Client Identifier 015241532010E62EB85C91BA0102000000
Requested IP Address 16.190.208.102
Hostname string NANO19
End of options
-DTF- 0 Tx 332 of 332 at 3789443 PPP/0 6285
Status: 00000000 Context: 00000000 Function: 00000082
--------------------------------------------------------------------
UDP port: BOOTPS
----------------
operation Request
Hardware type Ethernet (10Mb)
Hardware length 16
Hops 1
XID 0x18177434
Boot attempt time 00:42:40
Flags 0x8000
Client IP address 0.0.0.0
Your IP address 0.0.0.0
Gateway IP address 16.254.197.2
Client hardware address 52-41-53-20-10-E6
Server name
File
Magic Identifier: Standard options
----------------------------------
Message DHCPrequest
Client Identifier 015241532010E62EB85C91BA0101000000
Requested IP Address 16.190.208.101
Hostname string NANO19
End of options
-DTF- 0 Tx 332 of 332 at 3789443 PPP/0 6286
Status: 00000000 Context: 00000000 Function: 00000082
--------------------------------------------------------------------
UDP port: BOOTPS
----------------
operation Request
Hardware type Ethernet (10Mb)
Hardware length 16
Hops 1
XID 0x18177434
Boot attempt time 00:42:40
Flags 0x8000
Client IP address 0.0.0.0
Your IP address 0.0.0.0
Gateway IP address 16.254.197.2
Client hardware address 52-41-53-20-10-E6
Server name
File
Magic Identifier: Standard options
----------------------------------
Message DHCPrequest
Client Identifier 015241532010E62EB85C91BA0101000000
Requested IP Address 16.190.208.101
Hostname string NANO19
End of options
--- UNIX DAEMON.LOG record ---
Feb 11 17:15:58 ib003 bootpd[554]: bootptab mtime: Tue Feb 11 15:04:56 1997
Feb 11 17:15:58 ib003 bootpd[554]: recvd pkt from IP addr 16.254.197.2
Feb 11 17:15:48 ib003 bootpd[554]: unknown client Ethernet address 52.41.53.20.1
0.E6
Feb 11 17:15:48 ib003 bootpd[554]: bad addr len from from Ethernet address 52.41
.53.20.10.E6
Feb 11 17:15:48 ib003 bootpd[554]: request from Ethernet address 52.41.53.20.10.
E6
Feb 11 17:15:48 ib003 bootpd[554]: bootptab mtime: Tue Feb 11 15:04:56 1997
Feb 11 17:15:48 ib003 bootpd[554]: recvd pkt from IP addr 16.254.197.2
Feb 11 17:15:33 ib003 bootpd[554]: unknown client Ethernet address 52.41.53.20.1
0.E6
Feb 11 17:15:33 ib003 bootpd[554]: bad addr len from from Ethernet address 52.41
.53.20.10.E6
Feb 11 17:15:33 ib003 bootpd[554]: request from Ethernet address 52.41.53.20.10.
E6
Feb 11 17:15:33 ib003 bootpd[554]: bootptab mtime: Tue Feb 11 15:04:56 1997
Feb 11 17:15:33 ib003 bootpd[554]: recvd pkt from IP addr 16.254.197.2
Feb 11 17:15:22 ib003 bootpd[554]: unknown client Ethernet address 52.41.53.20.1
0.E6
---- END ----
|
| 744.6 | DHCP <> BOOTP 8-( | IB001::AMBROSIO | | Wed Feb 12 1997 04:00 | 28 |
| Hi,
Looking at Microsoft Knowledge Database (microsoft.com WEB) i found one
interesting article:
Article Q143127
> The following is an excerpt from RFC 1542
>
> if the relay agent dos decide to relay request, it MUST examine the
> "giaddr" ("gateway" IP address) field. If this field is zero, the
> relay agent MSUT fill this field with the IP address of the interface
> on which the request was received. If the interface has more than one
> IP address logically associated with it, the relay agent SHOULD
> choose one IP address associated with that interface and use it
> consistently for all BOOTP messages it relays.
>
> Because only one address is used in giaddr field by the relay agent,
> only one of the logical subnets is serviced through DHCP.
That's interesting, isn't it?
So that explains why Routeabout BOOTP relay agent do not support DHCP
functions, or RFC 1542.
Cheers,
Andres.
|
| 744.7 | | MARVIN::HART | Tony Hart, InterNetworking Prod. Eng. Group | Wed Feb 12 1997 07:39 | 6 |
| Andres,
There's no question that the RouteAbout is doing the wrong thing (at
least as a default behaviour), please log a call so that this gets on the
fixlist.
Tony
|