[TimmyDee51]

I've searched these fora and far and wide across the net to no avail. Here's the deal.

I'm working to implement a NetInstall-NetRestore setup at St. Olaf College. I have a Mac OS X 10.2.8 Server running a successful NetRestore image set (it works in our local subnet). That's all well and good, but I need it to work across subnets so we can have a campus wide solution. That's where Mike Bombich's NetBoot Across Subnets comes in.

The client machine appears to initially boot up fine via NetBoot when on a different subnet, but then stalls and gives me the following error message:

arplookup xxx.xxx.xxx.xxx failed: could not allocate llinfo

with the IP address being the server (static IP). I do a search on arplookup and get a billion hits (or so it seems) for people with problems on their BSD boxes, but nothing on the Mac and even less pertaining to NetBoot. The client computer actually begins the NetBoot process normally, but fails at arplookup. Is there any way I can disable arplookup? Any other ideas? Can anyone help?

[kampl]

Here's my thought on this FWIW. Being that ARP is bombing out for NetBoot, my first thought would be to look at whether or not proxy-arp is turned on on the routers.

I would imagine your clients are ARPing for a server to get their configs from (as they don't have IP addrs yet). ARP being a broadcast protocol for a local segment would not get though a router without proxy-arp.

Can you stick all your Macs on the same VLAN and extend that VLAN around the campus, or can you enable proxy-arp on the routers? Gets you a chatty network, but it should work. Let me know.

[TimmyDee51]

Thanks for the help. We took some of your ideas and tried further modifying the NVRAMs so that it would find the router IP and subnet mask automatically based on the subnet. Unfortunately, those didn't work. Creating a new VLAN for the Macs on campus would be a lot of work (we have them on almost all of our 55 subnets), create an enormous VLAN, and would be tricky to implement as it would necessitate that the Macs be plugged into the proper jacks at all times. I'm not ripping your idea down by any means (it's a good one), just saying that it's not really feasible on our campus.

In the mean time, we're going to try a packet dump on the client machine and see what's coming out of it. I'm also going to be emailing Mike Bombich and see what he has to say. I'll let you know as I get more info.

[kampl]

Best I could do without ever really using the service. I hear ya about creating one huge VLAN and trunking it all over the place, pain in the ass, can't do it on my campuses either. I was expecting a smaller envirenment I guess. I'll have to read a few docs on how it's supposed to work and go from there.

I would really like to see that capture file (anonymized or not as you see fit), if you don't mind sending it to me that is. I've done a lot of traffic analysis for intrusion detection and forensics purposes. Perhaps I might see something someone else on your team overlooks or vice versa.

I just glanced at the Apple info about it and all it says is to allow BootP through the router. So, not much of a suggestion as it is probably already implemented but you have an ip helper-address set already I assume (obvious Cisco background) ,and ip bootp ignore is not enabled if you are using IOS DHCP.

[mousehouse]

i'm not into the Mac'way of doing this but,
you can setup a "relayer" in each subnet. at least, that's the way you get it to work with SUN Jumpstart (which does the same BOOTP/RARP sequence). each subnet could have a BOOTP server that supplies the parameters of the central server holding the images.

on the other hand, if Mac works with DHCP you need to configure the forwarding of the DHCP packets using the 'ip helper-address' or equivalent on your default-gateway routers.

[TimmyDee51]

We've been working on this a bit more and it appears as though we have a weird network issue. We're trying find a work around that does not involve allowing the NetBoot broadcast through (we don't want students booting to the server, erasing their hard drives, and then whining to us). Plus, configuring the switches would be a lot of work. It's been done before for the PCs, but if we can do it better, we will.

We successfully booted a laptop to the server while it was plugged into the switch stack but still had issues when it was plugged into a jack on the periphery of the network. We could have a problem with the jack not being activated soon enough to provide the proper services, but that doesn't appear to be the answer. We even specified the router and the subnet mask in an attempt to preempt the arplookup issue, but that didn't work either.

I should be able to get a good look at it this week, so I'll let you know how it goes.

[mousehouse]

the switchport not being available at bootup was one of the problems we had with out Jumpstart environment. with Ciscos you can lower this spanning-tree convergence time by setting "portfast" on the specific port that only end-stations will connect to. otherwise it'll take the better of 50 seconds for the port to be available.

[kampl]

Good point, span-tree portfast would be a good thing to have on the endstations' ports' so as to not go through the whole STP routine.

Also, you could allow the relay and kill off access at the router or MSFC with an ACL to the netboot server for the vlans you want/don't want to have access to the netboot server. Just a thought.

[TimmyDee51]

We did some more testing yesterday and found some interesting things. Portfast is on on the routers, so that's not the issue. We did a packet capture and saw some interesting traffic. The machine appears to be booting fine, gets a correct and valid IP, and receives all TFTP traffic. Then the kernel does an "automatic reboot," drops the IP, and then requests the same IP. The router passes the correct IP (I think) but the client fails to pick it up (0.0.0.0). Then the client picks up the servers IP as its own, so it is both the sender and target of the packet. The router sends a reply that is correct but the client insists on sending malformed APR packets. At this point, verbose booting appears to halt but the same network traffic loops in the background, keeping the boot process from continuing.

I found someone who has had the exact same problem (the network traffic even looks the same). I'm going to email him today, but in the meantime, here is a link to his thread as he offers a more detailed explaination (I don't have the packet capture file in front of me).

http://forums.bombich.com/viewtopic....6df1c19f0a7270