I found late last night that my workaround didn't always work around the problem; Windows doesn't always take the static route as its first preference.
But there's always another way to flay a feline, and I enabled routing on the server and configured DHCP to hand out the server's address as the gateway for iPXE requests from the client. My unnecessary hop is now through an 8 core server with two teamed 1Gb NIC's when browsing the internet, rather than through a cheap ADSL modem on a 100Mb segment when accessing my disks. You certainly notice the difference. The iBFT approach sounds interesting. Anything that will make it 'just work' will always get my vote. Lee. -----Original Message----- From: Michael Brown [mailto:[email protected]] Sent: Thursday, 10 February 2011 11:45 PM To: [email protected] Cc: Andrew Bobulsky; [email protected] Subject: Re: [ipxe-devel] Curious routing problem with iPXE On Thursday 10 Feb 2011 01:46:36 Andrew Bobulsky wrote: > 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. I suspect this should be possible to work around in sanbootconf. We should be able to configure the TCP/IP stack with the correct gateway address (as we already do) and then replace the gateway address in the iBFT with the target IP address (assuming that it really *is* in the same subnet). That should cause Windows to set up the iSCSI target route 'correctly'. For Windows versions where the boot-capable iSCSI initiator includes its own iBFT driver (iscsibp.sys), i.e. every version other than XP, it would also be necessary to ensure that sanbootconf.sys loads before iscsibp.sys. Michael _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo/ipxe-devel
