In my last post (Routed Port vs. Switch Virtual Interface (SVI)), I have mentioned a consequence of using routed ports to interconnect access and core switches:
You have to route the traffic on the access switches.
Routing on the network access, the edge of the network, is not a question of performance. It is more of a management issue. Depending on the size of your network, and the number of subnets, you have to deal with lots of routes.
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.
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.
IPv6 is not really new. According to Google, 10% of all users that access Google, do this over an IPv6 connection (Source). My blog is also accessible over IPv6 since its start in January 2014 (and since January 2016 only over HTTPS - thanks to Let’s Encrypt!).
When I talk with customers about IPv6, I often hear things like “Oh, we had to disable it. Too much problems!” or “We had to disable it.
Disclaimer: Thanks to ALE Deutschland GmbH, the german subsidiary of Alcatel-Lucent Enterprise, for loaning me two OmniSwitch 6450 switches.
Who’s Alcatel-Lucent Enterprise? I’m quite sure that you know Alcatel-Lucent, a leading vendor for telecommunication and networking equipment. But do you know Alcatel-Lucent Enterprise (ALE)? In April 2015, Nokia placed an offer to buy Alcatel-Lucent for ~ 15 billion euro. Six months before, in October 2014, Alcatel-Lucent sold his enterprise business to China Huaxin.
