Glen Turner (vk5tu) wrote,

The naming and reachability of network elements

I have written before about the naming of network items, but someone asked for a summary.

You carve out a part of DNS as yours, and .net.example.edu.au is a good choice as that prevents name clashes with "user-visible" DNS names. You name devices within that with no further DNS hierarchy. Obviously we do need some hierarchy, we simply don't use DNS dots to do it as they are elided by almost all network management systems.

I strongly recommend a geographical-then-function-then-counter naming system. Sort of like b4-f1-sw2 for the management interface of Building #4, Floor 1, switch 2. But you'll need to adjust the basic outline so it works well for your local circumstances. Do not put the make and model in the name, upgrading a switch should be cheap and simple, so the less to change the better. Try to avoid using L or O or I next to digits. Names are in lower case only.

For the non-management interfaces DNS hierarchy is a good idea. Take VLAN4 of eth0 of the router b4-f1-r1, that would get the DNS name vlan4.eth0.b4-f1-r1.net.example.edu.au. Use the vendor's name for the interface, so if they call it GigabitEthernet0 then you say vlan4.gigabitethernet0.b4-f1-r1.net.example.edu.au and if they call it ge-0/0/0 then you say vlan4.ge-0-0-0.b4-f1-r1.net.example.edu.au. But do use your own names for the subinterface technology as this rapidly brings errors to the fore, "vlan4", "isl4", "lane4", "mpls0", "gre0", and so on. Use the same names for IPv4 and IPv6.

Sometimes you'll provide the IP address for use by someone else. Name these gateways links with additional hierarchy: both the customer identifier (an order number, or customer ID, or ASN for a peering link) and a counter. If you are doing split service delivery (unicast here, multicast there) then note that in the naming too. Typically gw1.cust1234.vlan4.eth0.b4-f1-r1.net.example.edu.au, but a worst case could be as ugly as gw1.multicast.ipv6.as666.vlan4.eth0.b4-f1-r1.net.example.edu.au.

Accessing your management interfaces

You can, and should, place management access in a VLAN away from users. In a small network there is no need to route that VLAN. Instead drop a couple of bastion servers on the management LAN. Connect those servers to your non-management network and give those servers plenty of backdoor connectivity: PSTN modems attached to a POTS phone line, GSM modems, ADSL service. Set up a SSH CA and use that to control SSH access. Run your standard authentication, but put a replica of the authentication on each of the bastions (maybe subsetting that if you have a lot of users). That way the bastion users are running the corporate password policy but network engineers are able to log in when the only device in the entire network which is reachable is the bastion server (via one of its backdoor links). Also have those servers run a lot of VPN options: the typical network engineer workstation can simply bring up that VPN rather than SSH through the bastion. The network management platforms can be on the "real" network, getting the benefits of easy administration (eg, puppet) whilst running VPN tunnels to all of the bastion server to query the management interfaces of the networking devices.

Run one bastion server per network core. Remember that these servers need not be large, a low power 1RU server with a couple of ethernet interfaces is overkill). You might need a USB hub to be able to plug in all of the PSTN, GSM and ADSL modems. If you have new switches with USB consoles then plug them into the hub as well. If you have the older RS-232 consoles then plug them into a 8 or 16 port RS-232/USB concentrator.

You can buy "console servers" commercially, and they are worth a look. Usually they fail as bastion servers as they can't replicate the corporate authentication database and don't run a range of VPN choices. In a big datacentre use a console server and plug it into the management VLAN and use the bastion server to reach it. Some console servers have two management interfaces, and one can run directly to the bastion server.

After doing all of this good work, make sure the system administrators don't do an end-run around it. Their KVM switches go onto the management network, as do their ILMI interfaces. As the number of hosts on this network can get large do try to run IPv6-only whereever possible (just doing that for the ILMI interfaces can save a lot of IPv4 addressing). Furthermore, using IPv6's autoconf is much more resilient to networking issues than IPv4's DHCP. You should use static addressing on major assets and obviously on routers. Closet switches and the like should all use DHCP to obtain their address (even if you statically assign the addressing back at the DHCP server) because the aim there is to drive the administration overhead to the floor.

Ignore people who tell you to use NAT for the management VLAN. One day you'll find yourself on a router with no VRFs where you want to suppress all private networks whilst trying to keep the range you need for management connectivity. You will then hunt that person down and kill them. With a spoon, because it is more painful.

Use a iptables rule to set DSCP = CS6 (control) for ssh as packets exit out of the bastion server into the management network. Set them back to DSCP = BE as they exit out of the bastion server into the customer network (otherwise they'll get policed by the router). Also set that DSCP on the devices in the management network ("ip ssh dscp 48"). Resist the temptation to set DSCP for SNMP, as it can be like a bulk data transfer at times. Use the same QoS design in the management network as you do for the customer network.

Some auditors don't like the network management names appearing in DNS. In that case run a DNS forwarder on the bastion servers. Set that forwarder up to look in the zones for .net.example.edu.au and the reverse zone for the IP addressing, then to forward other zones. Or you can use dnsmasq to do the same with a hosts file. Using dnsmasq has the advantage that you can suppress the DNS names of the router's forwarding interfaces too. Obviously the network elements point to the DNS forwarder at their nearest core. When people connect using the VPN then it can replace their laptop's DNS resolver list and then they'll automatically see the verboten names. But really, getting better auditors is the correct answer, because making your network more difficult to diagnose is to increase the risks to the business, not to decrease them.

Tip

Typing:

$ ssh b4-f1-sw2.net.example.edu.au

can be painful. Especially from a corporate laptop where you can't change the DNS search list. Use a SSH ~/.ssh/config file to do the expansion:

Host *-*-*
  Hostname %h.net.example.edu.au

Ask the systems' administrators to set up a ssh CA and generate keys for devices. That's easy to do when starting out, and a major pain to do afterwards.

Tags: gear
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 2 comments