Well, that sucks. At least I know now why it's happening - thanks, Andrew.
Option 249 allows me to specify static routes on the DHCP server - from the rather sparse documentation, I think it's a Microsoft variant of option 121. I specified a route for 10.10.10.2, mask 255.255.255.255, gateway 10.10.10.2. This then gets added to the routing table and takes precedence over the spurious route inserted by Windows. I did try adding it afterwards using the route command, but it wouldn't take it; besides, I need the network up before I log in so things like backups can still happen. Lee -----Original Message----- From: Andrew Bobulsky [mailto:[email protected]] Sent: Thursday, 10 February 2011 12:47 PM To: Michael Brown; [email protected] Cc: [email protected] Subject: Re: [ipxe-devel] Curious routing problem with iPXE Hello Lee, Michael, The issue you're seeing here is, most unfortunately, expected behavior. You can read up on it here: http://support.microsoft.com/kb/960104 As I recall it, this behavior is seen in pretty much every NT 5.1 OS, including WinPE 3.0, Windows 7, and 2008 R2. Microsoft basically made the executive decision that placing your network traffic and iSCSI traffic on the same NIC is insane, and decided that the only reason you'd have a gateway on your iSCSI NIC would be if that gateway were actually required to route traffic to and from your SAN. I wish I knew why they thought this was a good idea, because all it seems to really accomplish in my experience with it is to stifle iSCSI booting in low-cost setups. Take that with however many grains of salt you desire :P The only workaround I'm aware of is to establish a default gateway sometime *after* the iSCSI connection is in place and the client's routing table is initially populated. If you boot with no default gateway, you can then add one once the OS is online, and the trickle-down from the iBFT won't occur. Curious though, Lee, for your solution, what exactly did you do and what are the results? I've never configured option 249, so I'm puzzled :) Cheers, Andrew Bobulsky On Wed, Feb 9, 2011 at 7:52 PM, Michael Brown <[email protected]> wrote: > On Wednesday 09 Feb 2011 23:25:18 Lee Bradshaw wrote: >> I've now set up a native Windows iSCSI server and am booting from it. >> All >> is working fine, except that the routing to the server is odd. My PC >> is >> .244; the server is .2. When I list the routing table I get: >> >> IPv4 Route Table >> > ====================================================================== > ===== >> Active Routes: >> Network Destination Netmask Gateway Interface >> Metric >> 0.0.0.0 0.0.0.0 10.10.10.1 10.10.10.244 >> 266 >> 10.10.10.0 255.255.255.0 On-link 10.10.10.244 >> 266 >> 10.10.10.2 255.255.255.255 10.10.10.1 10.10.10.244 >> 266 ... >> >> You will notice the curious route to the server via a gateway at >> 10.10.10.1. This seems to be caused by iPXE not correctly processing >> the subnet from DHCP, which was 255.255.255.0. I know this is what it >> read from the DHCP server because it says so during the boot. > > Interesting. I'm pretty sure if you type "route" at the iPXE command > line, you'll find that iPXE's routing table doesn't include a > dedicated host route to 10.10.10.2, if only because iPXE doesn't even > support a concept of routing beyond a simple "network address, subnet > mask, gateway address" triplet. :) > > iPXE passes IP configuration information to Windows via the iBFT, > which can contain only a local IP address, subnet prefix, and gateway > address; there's no way that iPXE could pass host-specific routes to Windows even if it wanted to. > >> In many installations this wouldn't be a problem - although it's an >> unnecessary overhead - but in my case the gateway at 10.10.10.1 is on >> a 100Mb connection to the switch, whereas the rest of the network is 1000Mb. >> As you can imagine, this means the performance of my disks is not >> what it should be. >> >> I've been able to work around it by adding a static route (DHCP 249) >> to override the errant entry, but it would be nice if I didn't have >> to do >> this. Any ideas? > > I vaguely (and quite possibly inaccurately) remember that Shao Miller > has encountered this problem before. Shao: any thoughts? > > Michael > _______________________________________________ > ipxe-devel mailing list > [email protected] > https://lists.ipxe.org/mailman/listinfo/ipxe-devel > _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo/ipxe-devel
