DHCP option 3
-
Option 3 is the gateway setting. Why are you trying to set the same thing twice in two different places?
-
Option 3 is the gateway setting. Why are you trying to set the same thing twice in two different places?
I need to have two gateways. In case of shutdown or loss of communication with the first. This is dictated by our internal needs.
-
Your internal needs seem to ignore how the routing table works.
It is not possible to have two gateways.
If you find a way to do it you will become rich ;) -
Your internal needs seem to ignore how the routing table works.
It is not possible to have two gateways.
If you find a way to do it you will become rich ;)But still the operating system should receive them. When using a DHCP server that comes with Windows 2003 everything works fine.
If I understand correctly
http://technet.microsoft.com/ru-ru/library/bb878104%28en-us%29.aspx
the operating system will use the first available. -
This seems to be a shortcoming of the webgui, the gateway field in Services->DHCP Server->Gateway accepts only one address and there's only an option to override it per client, no option to specify additional values.
-
Ah well that would explain it. This needs to all be on one line in the config.
It should be:
option routers x.x.x.x, x.x.x.y;Might be fairly easy to accommodate in the GUI, actually, if it doesn't already take a comma-separated list.
-
If you want to do this and don't want to wait for the option to (maybe) make it into the GUI, you can just disable the input validation check on lines 193-195 of /usr/local/www/services_dhcp.php
Then put x.x.x.x, x.x.x.y into the gateway box, but be sure that you are careful of the syntax because if the input isn't proper, dhcp might break until you fix it.
I added a todo item so if someone picks it up it may eventually make it into the gui:
http://redmine.pfsense.org/issues/573
-
Your internal needs seem to ignore how the routing table works.
It is not possible to have two gateways.Not normally two default gateways for a single device/interface, but it is possible to have a list of a number of routers made known to the client.
This isn't usually dynamic, like a normal routing table can be; it's more common use is something like:"first, see if the router at aa.aa.aa.aa works, if not try router at bb.bb.bb.bb, if not try router cc.cc.cc.cc" etc
In fact, it is
slightly dynamicin the sense that it may change at a lease renewal (at least I assume so ) but more often this is used boot-time-only configuration/failover/redundancy method. In that sense it's more like the older bootp protocolseg: I have 6 or 7 routers in the code 3 field on one of my sites, it's quite useful for some purposes/devices, especially some types of SCADA equipment. More advanced OSs (by which I mean the Unix-y ones) generally don't need this sort of thing, because as Unix-y admins, we can manipulate our routing tables by hand, scripts or by configuring routing protocols just as easily. You wouldn't expect a Windows XP/Vista/Windows7 box to understand CDP, IS-IS, OSPF or BGP like ours can. They do advertise "RIS" but when you look into it they've created another FUD-soup by renaming/rebranding a PXE installation method to keep their customers nicely confused and keep sending them the dollar bills ;)
Bear in mind that the routers available for a network may not necessarily be at the same address as the DHCP server, or even on the same network/subnetwork. The initial DHCP lease negotiation takes place without IPs, and so the client may be issued a differing network/netmask and have different routers than the DHCP server itself (or the networks that the DHCP server hardware is directly connected to by it's own interfaces, masked by those interface's respective netmasks)
example: a "network appliance" style server runs a DHCP daemon; it's address is 172.16.24.21, but hands out addresses to clients in the block 10.0.1.0/23. The routers required by the clients are in vicinity of 10.0.0.224/27, and they connect to various other networks occupying other ranges of the IP spectrum. In this case, it acts as a standalone dhcp server - it doesn't even have to be on the same network as the clients, because the DHCP protocol negotiations happen without IPs. They are nonrouteable, which is why we sometimes have to use DHCP-Relays/"helpers" on routers. Many pfsense boxes perform this "standalone" DHCP role, whilst also providing limited routing or bridging to other networks, or it may run just DHCPd and a webcache. They do not necessarily provide a default gateway themselves to any clients. There are many topology possibilities when the pfsense is viewed as a network appliance like this.
I can vouch for at least 150 of such "unusual" pfsense boxes in enterprise useage for the last year or so (each with manually configured dhcpd.conf )As the size and complexity of the network increases, the overall amount of routers and gateways can reach large numbers indeed. The most I have seen in recent years is about 4000 clients and in the region of 40 routers, none of them "gateways" in th sense that SOHO users would recognise. These are all served by a small cluster of DHCP servers that are dedicated to that task alone, simply handing out IPs and strange options 24/7/365
As the network changes and converges/reconverges, the advertised routes may change (and hence many routing tables will change along the way) but some do not, they are either there, or not, depending on whether the engineering department is open on Sundays, or whether the vehicles are plugged into the workshop network for data transfer overnight. What the SOHO user would call "internet access via a normal default gateway" doesn't actually happen here, this is a large multi-level internetwork across two continents and three countries, none of the connected equipment is a desktop PC or laptop. It's things like inventory readers, RFID scanners, access control units, environmental sensors, power control and the like.Many client options can be configured and assigned by class declarations or group declarations contained within the dhcpd.conf ; in the case of large-scale industrial networks this file can grow to thousands of lines in size. In the more "normal" useage of a pfsense box in home or 1-5 user SOHO environment, the options are not commonly needed, becasue the single pfsense box performs all the actions for the whole network topology. However, you only have to add in a small CCNP/CCIE lab, LTSP, VoIP system (even a small one with 2 or 3 fones) or TFTP-booting devices into the topology and you'll find many situations where you need a few IPs in the routers field, as well as many other options for network booting and routing.
In my installations, I haven't even configured a single pfsense box that didn't require some (most of them need quite a few) of these extra DHCP options, so the capability to insert them at the GUI is most welcome as it enables many more people to safely admin the boxes than before. Thank you and keep up the good work devs :)
Summary: multiple "routers" option is sometimes used as a (very) crude method of failover, often used by "dumb" devices that don't understand router discovery protocols etc.
-
Summary: multiple "routers" option is sometimes used as a (very) crude method of failover, often used by "dumb" devices that don't understand router discovery protocols etc.
Give us scenario please with let's say 2 default routes. You say that Windows Vista is smart enough to monitor availability of two routers? How does it do that? What protocol is used?
-
Ok, one smart guy showed me this link http://technet.microsoft.com/ru-ru/library/bb878104%28en-us%29.aspx
Dead Gateway Detection
Dead gateway detection is used by the TCP component of Windows TCP/IP to detect the failure of the default gateway and to adjust the IP routing table to use the next default gateway when there are multiple default gateways configured.
When a TCP segment for a TCP connection forwarded via the default gateway is retransmitted three times (by default), dead gateway detection changes the Route Cache Entry (RCE) for that remote IP address to use the next default gateway in the list as its next-hop address. An RCE is an entry in the routing cache, which stores the next-hop IP address for a destination address.
When one fourth of the TCP connections routed through the default gateway have had their RCEs adjusted to the next default gateway, dead gateway detection informs IP to change the computer's default gateway to the one that the adjusted connections are now using. If TCP connections continue to fail, dead gateway detection attempts to use the next default gateway in the list, returning to the first default gateway after cycling through the entire list.
Dead gateway detection monitors only TCP traffic. If connectivity fails for other types of traffic, the default gateway is not switched. Dead gateway detection can cause the default gateway configuration to change when a remote router fails. Remote routers in the path between the host and the destination that fail might also cause TCP connections forwarded along that path to fail and for the host to switch its default gateway. Because dead gateway detection relies on an end-to-end protocol (such as TCP), a host can switch its default gateway even when the current default gateway is fully operational.
As to me it's very bad idea to switch gateways relying on TCP. And it's not clear when switch back to the first Gateway occurs.
-
||Quote from: gordslater on Yesterday at 01:52:07 pm||
||Summary: multiple "routers" option is sometimes used as a (very) crude method of failover, often used by "dumb" devices that don't understand router discovery protocols etc||
Give us scenario please with let's say 2 default routes. You say that Windows Vista is smart enough to monitor availability of two routers? How does it do that? What protocol is used?I wasn't referring to Vista but to "dumb" devices, though from what I hear many would refer to Vista in the same group :):):) I don't move in Microsoft circles, thankfully.
It's an "old" practice, give me a while I'll run to my dusty bookshelf and flip around a bit.As to me it's very bad idea to switch gateways relying on TCP. And it's not clear when switch back to the first Gateway occurs.
Yeah, to me too. The scenarios I've seen it is some SCADA kit and older non-workstation industrial eqpt, which (from the syslogs I've seen from anyways) seems to go through the list from first to the last, then gives up, either silently, or, more usually, spectacularly :)
G -
An hour or so spent chuckling at myself about "vista/dumb devices" and looking for books and manuals came up trumps. From an old box of papers marked "Packet-Switched Technology" I found a old daisywheel printout of RFC1122 - published in - wait for it - 1989!
Nowadays, they have a world-wide-web thing, but in those days this was all stuff of sci-fi and you had to trawl FTP servers at 1200baud for it ;)RFC1122-Section 3.3.1 is what you want. It's more about routing than workstation issues, involving a fair use of ICMP.
It's also far from perfect, I can recall a few years ago a that some changes in ISP routers broke some of it such that it's nowadays only useable out to one hop. Prior to that there were ways of getting a few hops out depending on the capabilities of your equipment. It all depended on the passing of some ICMP types through ISP cores, which is why it's nowadays fallen from favor for longer reaches.
Googling RFC1122 refers back to an even earlier RFC, 816, which is quite a good read to understand the whys/wherefores and is a conceptual overview - that one's dated 1982.Multiple gateways aren't that uncommon in the unix-y world, hoststated comes to mind which is a high-level (in OSI terms) way of dealing with some routing dilemmas. Anyone who bonds two cards into one comes up against problems somewhere along the line if they don't config it properly. Policy-based routing isn't run-of the mill stuff I admit, it caused a fair share of headscratching if it isn't working the way you think.
EDIT: clarification - that's Policy-Based Routing seen acting at the client end; be that client a workstation, hardware server with a interface talking to an upstream daemon, or a router box making decisions based on various settings (and possibly changing in the time domain too). I don't mean policy-based routing specifically in the pfsense-centric perspective. This is, I admit, a league or two above the intended use of desktop PCs running a MS-Windows desktop OS.The Linux kernel also handles route ageing reasonably with the gc_timeout function for HA clusters and routing purposes. But I have zero experience on Microsoft stuff, as I mentioned before - here's what I was actually saying my main post above:
"eg: I have 6 or 7 routers in the code 3 field on one of my sites, it's quite useful for some purposes/devices, especially some types of SCADA equipment. More advanced OSs (by which I mean the Unix-y ones) generally don't need this sort of thing, because as Unix-y admins, we can manipulate our routing tables by hand, scripts or by configuring routing protocols just as easily. You wouldn't expect a Windows XP/Vista/Windows7 box to understand CDP, IS-IS, OSPF or BGP like ours can. They do advertise "RIS" but when you look into it they've created another FUD-soup by renaming/rebranding a PXE installation method to keep their customers nicely confused and keep sending them the dollar bills ;)"Reading that Microsoft article it may well be that the Vista machines have an improved method compared to the XP ones, but why they used only TCP/IP is anyone's guess.
ICMP is quite versatile though not many people delve into the more rare aspects of it. Wireshark and a lan tap are useful to see it in action between Cisco/Juniper/Foundry boxes and the like though you'll see many instances of incompatibilities between brands and even within brands - I've got some Cisco kit that's particularly stubborn in that respect.
G -
Also would like to vote for multiple gateways settings :)
