Networking

Many years ago, networks consisted of repeaters, bridges and router. Switches are the successors of the bridges. A switch is nothing else than a multiport bridge, and a traditional switch doesn’t know how to pass traffic to a different broadcast domains (VLANs). Passing traffic between different broadcast domains, is a job for a router. A router has an IP interface in each broadcast domain, and the IP interface is used by the clients in the broadcast domain as a gateway.

The Virtual Router Redundancy Protocol (VRRP) was developed in 1998 as an open standard protocol. VRRP is the result of an Internet Engineering Task Force (IETF), and it’s described in RFC 5798 (VRRPv3). VRRP was designed as an open standard protocol, but it uses some patents from Cisco. Its function is comparable to Cisco Hot Standby Router Protocol (HSRP), or to the Common Address Redundancy Protocol (CARP). VRRP solves a very specific problem at the network edge: It offers highly available virtual router interfaces, or in simple words: A highly available default gateway. Its home is the network edge, and because of this, VRRP is a so called first hop redundancy protocol. When moving towards network core, VRRP loses importance. If you move from the network edge to the core, redundancy is primarily offered by dynamic routing protocols and redundant links.

Sometimes it’s necessary to have two DNS servers that are authoritative for the same DNS namespace. This is the case if you use the same namespace for your web site and your internal Active Directory domain, e.g. terlisten-consulting.de. Or that you have created the zone terlisten-consulting.de in your Windows DNS to point specific hosts to internal IP addresses. The DNS servers at your ISP would be authoritative, and the domain controllers of your Active Directory would also be authoritative for the same domain. The response to a query depends on which DNS server you ask. So what would happen if you try to resolve www.terlisten-consulting.de, and the internal DNS has no record for it?

Over the last weeks, I’ve tried to improve the performance of my blog. The side was very slow and the page load times varied between 5 and 10 seconds. Much too long! I’ve reduced time consuming plugins, checked the size of pictures, checked CSS and HTML for misconfiguration/ slow clode and tuned the database. The page load times have not really improved.

Yesterday, I checked the httpd.conf on my webserver and found a little typo (accidentally commented line). After a restart of the Apache webserver, the page load times have dramatically improved (down to 2 - 3 seconds). What had happened?

The embedded DHCP server on AOS 7 and AOS 8 is a less known feature. But it’s pretty handy in some cases, e.g. if you have no servers on premises, or you don’t want that a a non redundant firewall or router acts as DHCP server. Because you can run two or more switches as a virtual chassis, you can easily make the DHCP server role highly available.

Configuring the DHCP server

The configuration is pretty easy.

Manually assigning ports to VLANs can be a time consuming and error prone process. Depending on the size of the network, there is a point where it doesn’t make sense to do this manually. Especially in SMB networks, VLANs are assigned manually, because the effort of automating the VLAN assignment exceeds the effort for manually assigning VLANs. Those environments are often very static. I know many SMB networks where VLAN have not been addressed for a long time. With declining costs for Layer 3 switches, the separation of workloads in VLANs for SMB customers became affordable. Server virtualization was another mainspring for VLANs and inter-VLAN routing. To be honest: I’m talking about SMB customers, not enterprise customers or enterprise-grade SMB customers (latter is my special term for SMB customers with enormous IT budgets…). But the main driver for VLANs was Voice over IP (VoIP). With the increasing proliferation of VoIP, even the smallest SMB customer were forced to use VLANs. But this led to situations, where customers had to change the switch config every time a new client or IP phone was added to the network. Common workarounds:

This is not a specific problem of Alcatel-Lucent Enterprise (ALE) OmniSwitches, but I’m affected by this behaviour and it’s really, really annoying. It’s not a problem with the switch, but with the device handling of Windows.

ALE delivers a micro USB-to-USB cable with each OmniSwtich 6860E. This cable is used to connect to the console port of the switch. Each time you connect the cable, Windows will discover a new USB-to-UART bridge and creates a new COM port. This happens each time you connect to a new switch or if you choose another USB port. Over time, you will see the number of COM ports increasing (COM 2, COM 3, COM 4, COM 5…).

Last week, I was surprisingly booked by a customer who observed a problem in his network. Unfortunately, colleagues worked on this network some day before (moving servers, routers etc. to a new pair of HP 7509 new core switches).

It was quickly clear, that some of the clients have received the wrong DNS servers from the DHCP server. The environment is a bit unusual. The customer is running two Active Directory domains (root and sub domain) in a single layer 2 broadcast domain. This nothing unusual, but he is also running two DHCP servers in the same layer 2 broadcast domain. To get this working, the customer uses exclusion ranges and reservations. This guarantees, that the client receives the correct DHCP information.

Today I saw an interesting behaviour of two Alcatel-Lucent Enterprise OmniSwitch 6450. Both switches has been configured as a stack, but one of the switches showed a flashing ID after the startup, and the stack was not formed. While I checked the logs and the status of the stack, I noticed that the slot number was incorrect. Furthermore the status showed “INC-LIC”.

-> show stack topology
                                         Link A  Link A          Link B  Link B
NI      Role      State   Saved  Link A  Remote  Remote  Link B  Remote  Remote
                          Slot   State   NI      Port    State   NI      Port
----+-----------+--------+------+-------+-------+-------+-------+-------+-------
   1 PRIMARY     RUNNING    1    UP       1001   StackB  DOWN        0        0
1001 PASS-THRU   INC-LIC    2    DOWN        0        0  UP          1   StackA

-> show log swlog
<snip>
THU MAR 03 13:07:29 2016  STACK-MANAGER    info == SM == Stack Port A Status Changed: DOWN
THU MAR 03 13:07:29 2016  STACK-MANAGER    info == SM == NI 0 down notification sent to LAG
THU MAR 03 13:08:41 2016  STACK-MANAGER    info == SM == Stack Port A Status Changed: UP
THU MAR 03 13:08:41 2016  STACK-MANAGER    info == SM == Stack Port A MAC Frames TX/RX Enabled
THU MAR 03 13:08:42 2016  STACK-MANAGER    info  Retaining Module Id for slot 2 unit 0 as 1
THU MAR 03 13:08:46 2016  STACK-MANAGER    info == SM == An element enters passthru mode (incompatible license)
<snip>

According to the stack status and the switch logs, there seems to be a problem with the licenses. So I checked the installed licenses on both switches. On switch showed Metro license:

A load balancer is an integral component of (nearly) every VMware Horizon View design. Not only to distribute the connections among a number of connection or security servers, but also to provide high availability in case of a connection or security server failure. Without a load balancer, connection attempts will fail, if a connection or security server isn’t available. Craig Kilborn wrote an excellent article about the different possible designs of load balancing. Craig highlighted Microsoft Network Load Balancing (NLB) as one of the possible ways to implement load balancing. Jason Langer also mentioned Microsoft NLB in his worth reading article “The Good, The Bad, and The Ugly of VMware View Load Balancing”.