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.
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.
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).
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.
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.
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.
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.
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.
