A series of cascading design woes threatens to overwhelm what should be a simple setup.
Sometimes, you run into a series of uncoordinated, inexplicable design
decisions that defy logic and reason, create a larger problem — and can
only be dealt with via another questionable design decision.
Case in point: I was recently asked to help figure out an odd problem with a small-business network and a networked automation and security system. The automation and security system controlled lights, provided intercoms, ran security cameras, the works. It did not, however, allow for static IP information to be configured into the controller. The only way the system could function was via DHCP, full stop.
This by itself was thoroughly bizarre. From an architectural point of view, this was a fundamentally flawed design because it made the entire system dependent on other systems for normal function.
You may assume that a network of any size will have DHCP services present and to provide the ability to use those services, but to completely omit the capability to set specific IP information on such a critical component is unconscionable. Further, control of the system via mobile or desktop application might work via broadcast when on the local network, but if you want to control or use the system remotely, you must connect by IP address — which you cannot statically set.
Typically, systems like this (and most network devices of any type) use IP stacks developed by others. Whether the foundation is Linux, VxWorks, BSD, or what have you, IP stacks are among the most baked-in code available. There's no excuse not to support a basic, fundamental feature like a static IP address. I won’t even go into the fact that the Web UI does not offer authentication, or the suggested remote access method is to open a hole in the firewall directly to the controller. The mind boggles.
Enough about that — there are ways to mitigate such problems. For instance, every major DHCP server has the capability to set address reservations, which ensure that a specific host will always receive the same IP. At least then we can allow remote access via VPN from a mobile device and connect to the UI at a known IP address that is reliably delivered by the DHCP server. However, that wasn’t an option either.
The Cisco ASA5505 firewall at this installation, which functions as the DHCP server, handles many tasks well. It terminates IPSec VPNs, offers SSL VPN access, performs content inspection, and generally upholds Cisco’s solid reputation as a leader in the networking world. What it does not do, however, is provide any form of DHCP reservation capability — so simple, yet unachievable, in a $600 firewall with a Cisco name on the front.
It might have been as simple as using existing static ARP declarations within the ASA code to cause the DHCP service to assign the same IP address to a requesting MAC address, but no, that’s a nonstarter. You simply cannot do DHCP reservations with an ASA5505. Back to the drawing board.
Next on the list of possible solutions: Use one of the Apple AirPort Extreme wireless access points as a DHCP server, as they support DHCP address reservations. In this network, however, the AirPorts were used as access points only, not routers. They were simply bridging the wireless and wired network, not providing NAT or routing services (a fully supported configuration in the AirPort).
Unfortunately, that meant DHCP services were unavailable. There was no way to configure one of them to provide DHCP while acting as a bridge. Further, even as a stand-alone DHCP server, the AirPort would always want to deliver its own LAN IP address as the default route, rendering that method unusable. Back to the drawing board (again).
To recap, we’re simply trying to cause a networked device to be consistently available at the same IP address. We cannot assign it statically on the device. Several possible DHCP servers on the network are unsuitable for the task for one reason or another.
What should have been the work of a few minutes with existing hardware turned out to be impossible. The network at this particular site does not have any local server-class systems — they're either in the cloud or at other locations. We can’t simply provide DHCP services from a file server or a similar item. Back to the drawing board (once more).
Ultimately, I picked a Buffalo router running DD-WRT for $60. I disabled the wireless and WAN networking and set it up as only a DHCP server. It provides address reservations like a champ and sits alongside the Cisco ASA5505 with a single cable run into the LAN.
I am certain that at some point down the road someone will look at that setup without any prior knowledge and ask why on earth is this router/firewall plugged into the network like that and what could it possibly be doing. When they’re told the Buffalo only does DHCP, the questions will intensify.
The lesson here is that bad design decisions force further bad designs. Also, if you’re adding networking to anything, make sure you support the full stack. Not doing so should be a felony.
Read More News :- Techies | Update
Case in point: I was recently asked to help figure out an odd problem with a small-business network and a networked automation and security system. The automation and security system controlled lights, provided intercoms, ran security cameras, the works. It did not, however, allow for static IP information to be configured into the controller. The only way the system could function was via DHCP, full stop.
This by itself was thoroughly bizarre. From an architectural point of view, this was a fundamentally flawed design because it made the entire system dependent on other systems for normal function.
You may assume that a network of any size will have DHCP services present and to provide the ability to use those services, but to completely omit the capability to set specific IP information on such a critical component is unconscionable. Further, control of the system via mobile or desktop application might work via broadcast when on the local network, but if you want to control or use the system remotely, you must connect by IP address — which you cannot statically set.
Typically, systems like this (and most network devices of any type) use IP stacks developed by others. Whether the foundation is Linux, VxWorks, BSD, or what have you, IP stacks are among the most baked-in code available. There's no excuse not to support a basic, fundamental feature like a static IP address. I won’t even go into the fact that the Web UI does not offer authentication, or the suggested remote access method is to open a hole in the firewall directly to the controller. The mind boggles.
Enough about that — there are ways to mitigate such problems. For instance, every major DHCP server has the capability to set address reservations, which ensure that a specific host will always receive the same IP. At least then we can allow remote access via VPN from a mobile device and connect to the UI at a known IP address that is reliably delivered by the DHCP server. However, that wasn’t an option either.
The Cisco ASA5505 firewall at this installation, which functions as the DHCP server, handles many tasks well. It terminates IPSec VPNs, offers SSL VPN access, performs content inspection, and generally upholds Cisco’s solid reputation as a leader in the networking world. What it does not do, however, is provide any form of DHCP reservation capability — so simple, yet unachievable, in a $600 firewall with a Cisco name on the front.
It might have been as simple as using existing static ARP declarations within the ASA code to cause the DHCP service to assign the same IP address to a requesting MAC address, but no, that’s a nonstarter. You simply cannot do DHCP reservations with an ASA5505. Back to the drawing board.
Next on the list of possible solutions: Use one of the Apple AirPort Extreme wireless access points as a DHCP server, as they support DHCP address reservations. In this network, however, the AirPorts were used as access points only, not routers. They were simply bridging the wireless and wired network, not providing NAT or routing services (a fully supported configuration in the AirPort).
Unfortunately, that meant DHCP services were unavailable. There was no way to configure one of them to provide DHCP while acting as a bridge. Further, even as a stand-alone DHCP server, the AirPort would always want to deliver its own LAN IP address as the default route, rendering that method unusable. Back to the drawing board (again).
To recap, we’re simply trying to cause a networked device to be consistently available at the same IP address. We cannot assign it statically on the device. Several possible DHCP servers on the network are unsuitable for the task for one reason or another.
What should have been the work of a few minutes with existing hardware turned out to be impossible. The network at this particular site does not have any local server-class systems — they're either in the cloud or at other locations. We can’t simply provide DHCP services from a file server or a similar item. Back to the drawing board (once more).
Ultimately, I picked a Buffalo router running DD-WRT for $60. I disabled the wireless and WAN networking and set it up as only a DHCP server. It provides address reservations like a champ and sits alongside the Cisco ASA5505 with a single cable run into the LAN.
I am certain that at some point down the road someone will look at that setup without any prior knowledge and ask why on earth is this router/firewall plugged into the network like that and what could it possibly be doing. When they’re told the Buffalo only does DHCP, the questions will intensify.
The lesson here is that bad design decisions force further bad designs. Also, if you’re adding networking to anything, make sure you support the full stack. Not doing so should be a felony.
Read More News :- Techies | Update
Hello, my name is Mohd Azahar. I'm a self-employed Pivrate from the India.
No comments:
Post a Comment