Category Archives: Networking

Redundancy on the first hop – VRRP

This posting is ~7 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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.

Fun fact: Its home is the network edge, but most edge switches, doesn’t support VRRP…

As already mentioned, VRRP is comparable to HSRP, CARP, Cisco Gateway Load Balancing Protocol (GLBP), or the Extreme Standby Router Protocol (ESRP).

VRRPv3 supports IPv6 and IPv4.

How does it work?

Pretty easy:

at least two routers or switches that support VRRP
a virtual IP address
a virtual mac address

Okay, maybe it’s not that easy.

Key point is the virtual router. A virtual router is defined on each physical router or switch that should offer high availability for a virtual IP address. A virtual router is defined on a per-vlan base, and it consists of a virtual router identifier (VRID), one or more virtual IP addresses, and a statement that declares a router or switch as a master or backup virtual router.

The virtual mac address is build upon the VRID. The mac address is always 00-00-5E-00-01-xx, in which xx is the VRID in hexadecimal format.

The interface IP address, or switch virtual interface (SVI), that is configured for a specific VLAN, and the virtual IP address of a virtual router configured for the same VLAN, must belong to the same subnet.

Master, Backup, Owner

A router or switch can have one of two roles:

master virtual router
backup virtual router

You can have one master, but multiple backup virtual router. The master virtual router answers to ARP requests and forwards packets for the virtual IP address. The backup virtual router comes into play, in case of a failure of the master virtual router. If a backup virtual router doesn’t receive packets from the master virtual router (a period longer than three times of the advertisement time), the backup virtual routers assume that the master virtual router is dead. An election process is then initiated, to select a new master virtual router.

Master and backup virtual routers communicate via multicast using the multicast IP address 224.0.0.18.

The virtual IP address must also be a real interface IP address on a router or switch. This router or switch is called IP address owner. The IP address owner has always the priority 255. Because of this. the IP address owner will always become the master virtual router, regardless what the configuration says.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

As you can see, R1 has the IP 10.0.0.1/24 and the virtual IP address (VIP) is also 10.0.0.1. In this case, R1 is the master virtual router and the IP address owner.

Some vendors allow a no owner design.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

As you can see, R1 and R2 are both configured as backup virtual router, but R1 has a higher priority. In this case, R1 will answer to ARP requests and will forward packets for 10.0.0.254. Another interesting fact: The VIP is a true VIP, and it’s not a real interface IP address of any of the participating routers or switches.

Not all vendors seem to support such a design, and RFC 5798 has no references to it. According to some other vendor docs and RFC 5798, VRRP requires that the master virtual router has the virtual IP address configured as a physical IP address, which means that the master virtual router must also the IP address owner (as mentioned above).

VRRP-E – extended VRRP

Brocade and HPE offer VRRP-E, an extended and proprietary version of VRRP. Extended means, that it overcomes limitations of VRRP (told by Brocade and HPE).

VRRP-E doesn’t know the concept of master and backup virtual routers. All routers are acting as backup virtual routers. A priority value is used to determine, which router will act as master virtual router. Furthermore, VRRP-E doesn’t know the concept of the IP address owner.

Brocade states in one of their docs:

The most important difference is that all VRRP-E routers are Backups. There is no Owner router. VRRP-E overcomes the limitations in standard VRRP by removing the Owner.

VRRP and dynamic routing protcols

If VRRP is used together with dynamic routing protocols, like OSPF, there’s a worth mentioning fact: Not a single dynamic routing protocol like it, if the IP address, which is used to build adjacencies, moves to another router. It’s not the IP address that is the problem, but perhaps the not matching routing protocol configuration, a changed router ID or similar. Because of this, the VRRP VIP must not be used in the configuration for dynamic routing protocols. A no owner design can have some benefits if you have to use VRRP and dynamic routing protocols on the same router or switch. In this case, the real interface IP addresses can be used for the dynamic routing protocol configuration, and not the floating VIP.

Changing DHCP server config on AOS 7

This posting is ~7 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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.

-> cd /flash/switch
-> cp dhcpd.conf.template dhcpd.conf
-> vi dhcpd.conf

Edit the dhcpd.conf as necessary. Then start the DHCP server.

-> dhcp-server enable
-> dhcp-server restart

The “enable” enables the DHCP server, but it’s not started. “restart” is used to start or restart the DHCP server.

Change the dhcpd.conf

But how do you change the dhcpd.conf? Sure, simply use VI and edit it. Not quite… After starting the DHCP server, the owner of the dhcpd.conf changes from “admin” to “root”. So with your normal “admin” user, you don’t have the permission to write the file.

In order to change the dhcpd.conf, we need an account with more privileges. In this case, the maintenance shell can help.

Maintenance Shell commands should only be used by Alcatel-Lucent Enterprise personnel or under the direction of Alcatel-Lucent Enterprise.

-> su
Entering maintenance shell. Type 'exit' when you are done.
TOR #-> vi /flash/switch/dhcpd.conf

With higher privileges it’s no problem to edit the dhcpd.conf. Make sure to leave the maintenance shell after the change, and don’t forget to restart the DHCP server.

-> dhcp-server restart

I assume that this behaviour is caused by a bug. I don’t know, if AOS 8 shows the same behaviour. I will update this blog post with further information, as soon as I get them.

Dynamic VLAN assignment with AOS 6

This posting is ~7 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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:

pre-configuring switches, eg. port 1 to 12 for clients and 13 to 24 for IP phones
connecting clients behind IP phones and pre-configuring all switch ports (untagged client and tagged VoIP VLAN)

Suitable for small environments, but difficult to handle if environments grow over time. And I’m not a friend of connecting clients behind IP phones… Enterprise, or enterprise-grade SMB customers tend to implement 802.1x to manage access to their network. With 802.1x it’s possible to assign ports to VLANs depending on the user identity. But 802.1x is complex. If you have the the knowhow, the time and the budget, please do 802.1x! But you should take the complexity into account. Today I want to show options, offisde of 802.1x, to dynamically assign ports to VLANs with Alcatel-Lucent Enterprise OmniSwitches.

First of all: We have to differ between AOS 6, AOS 7 and AOS 8. Alcatel-Lucent Enterprise (ALE) currently uses three different software releases, depending on the switch platform.

Switch model	AOS release
OmniSwitch 6250	AOS 6
OmniSwitch 6350	AOS 6
OmniSwitch 6450	AOS 6
OmniSwitch 6850E	AOS 6
OmniSwitch 6855	AOS 6
OmniSwitch 6860(E)	AOS 8
OmniSwitch 6900	AOS 7
OmniSwitch 9000(E)	AOS 6
OmniSwitch 9900	AOS 6
OmniSwitch 10K	AOS 7

Depending on the specific AOS release, there are various ways to enable dynamic VLAN assignment. The main reason for the different AOS releases is, that ALE shifts its networking core platform from Windriver VxWorks (AOS 6) to Linux (AOS 7 and AOS 8) (source #1, source #2).

This blog post will focus on

OmniSwitch 6250/ 6350/ 6450 running AOS 6.7.1

I plan to publish similar blog posts for

OmniSwitch 6900/ 10k running AOS 7.3.4
OmniSwitch 6860/ 6860E running AOS 8.2.1

Dynamic VLAN assignment with AOS 6

In general, there are three different ways to dynamically assign ports to VLANs with AOS 6:

VLAN mobility
User Network Profiles (UNP)
LLDP Media Endpoint Detection (LLDP-MED)

Let’s take a look at VLAN mobility. VLAN mobility is used to dynamically assign one or more VLANs to a port, based on traffic characteristics that were received on that port. The following information can be used to classify traffic:

802.1Q VLAN ID tag
DHCP MAC address
DHCP MAC range
DHCP port
DHCP generic
MAC address
MAC address range
Network address
Protocol
Port

You can’t use VLAN mobility on ports that

is an 802.1Q tagged port
belongs to a Link Aggregation Group (LAG)
has Spanning Tree enabled and the BPDU ignore status is disabled
is used to mirror traffic

To allow the switch to dynamically assign ports to VLANs, VLAN mobility has to be enabled. By default, all ports are non-mobile ports. A non-mobile port is statically assigned to a specific VLAN.

To enable VLAN mobility for a port:

vlan port mobile 1/1

You can also use a port range.

vlan port mobile 1/1-22 2/1-22

To disable VLAN mobility use the “no” form of the command.

vlan no port mobile 1/1-22 2/1-22

If a device sends ethernet frames with a 802.1Q VLAN ID tag, you can use the VLAN ID tag to dynamically assign a port to a VLAN. With VLAN mobility enabled, you only have to enable the “mobile-tag” option for the desired VLAN.

vlan 199 mobile-tag enable

As soon as the switch receives a frame with a 802.1Q VLAN ID tag for VLAN 199, the port that received this frame is dynamically assigned to VLAN 199. That’s VLAN mobility based on 802.1Q VLAN ID tags. But you can also use VLAN rules. VLAN rules are created per VLAN. You can have one or more rules per VLAN. You can use the

Source MAC address
Source MAC address ranges
Switch ports, or
the DHCP request itself

to dynamically assign a port to a VLAN. This rule matches to DHCP requests from a single MAC address.

vlan 199 dhcp mac 68:F7:28:FA:A0:D5

If a DHCP request with the specified MAC address is received, the port is dynamically assigned to VLAN 199. Because managing MAC addresses is not very handy, you can use MAC address ranges:

vlan 199 dhcp mac 68:F7:28:FA:00:00 68:F7:28:FA:FF:FF

To use all DHCP requests on a specific port, use the DHCP port rule:

vlan 199 dhcp port 1/1-22 2/1-22

To use all received DHCP requests, use the DHCP generic rule:

vlan 199 dhcp generic

To remove a rule, use the “no” form of the command.

vlan 199 no dhcp ...

Once the device has received an IP address from the DHCP server, the VLAN port assignment is dropped! Because of this, you can combine DHCP and network address rules. A network address rule dynamically assigns the VLAN depending on the IP subnet.

vlan 199 ip 192.168.20.0 255.255.255.0

This rule assigns VLAN 199 to a port, that receives traffic from a client in the subnet 192.168.20.0/24. If the DHCP server in VLAN 199 assigns IP addresses from this subnet, you can easily combine the DHCP and network address rule.

A MAC address rule assigns the VLAN depending on a single MAC address

vlan 199 mac range 68:F7:28:FA:A0:D5

or on a range of MAC addresses.

vlan 199 mac range 68:F7:28:FA:00:00 68:F7:28:FA:FF:FF

Less frequently used are port and protocol rules. A port rule doesn’t require incoming traffic to trigger dynamic VLAN assignment. The specified mobile port is immediately assigned to the specified VLAN. Port rules only apply to outgoing broadcast traffic. You still need rules for the incoming traffic. To create a VLAN port rule:

vlan 199 port 1/1

A protocol rule uses the protocol type in an ethernet frame to assign VLANs to ports. Valid values for the port type are:

IP Ethernet-II
IP SNAP
Ethernet II
DECNet
AppleTalk
Ethertype
DSAP/SSAP
SNAP

A protocol rule is created by issuing

vlan 199 protocol ip-snap

As always, the “no” form of the command removes the rule.

vlan no 199 protocol ip-snap

vlan no 199 mac range 68:F7:28:FA:00:00 68:F7:28:FA:FF:FF

User Network Profiles (UNP) is a feature of Access Guardian. Access Guardian refers to security functions, like

Authentication and Classification
Host Integrity Check (HIC)
User Network Profiles (UNP), and
Virtual Network Profile (VPN)

UNP are available in AOS 6, AOS 7 and AOS 8. In AOS 6 we need a

policy condition
policy action
policy rule, and a
policy list

These four characteristics belong to the QoS feature of AOS. But a UNP needs a policy list, more specific the policy rules that are part of the policy list, to classify traffic and devices. The policy condition is necessary to identifiy a devices on which this policy should match.

policy condition ip_phones source mac 68:F7:28:00:00:00 mask 00:00:00:FF:FF:FF

Beside the MAC address, you can use source and destionation IP addresses, switch ports, source and destination TCP/ UDP ports, VLANs and many more. To use one or more IP addresses, simple use a network group.

policy network group sales 192.168.20.0 mask 255.255.255.0 192.168.30.0 mask 255.255.255.0

The group “sales” consists of two subnets. To remove a subnet, use the “no” form of the command.

policy network group sales no 192.168.20.0 mask 255.255.255.0

The policy action is used to determine, what should happen with the traffic. In this case: Priorize the traffic.

policy action high_prio priority 7 802.1p 7

The rule binds condition and action.

policy rule rule_voip condition ip_phones action high_prio log no default-list

A policy list is used to group one or more policy rules.

policy list qos_list_voip rules rule_voip

A UNP binds a name, a VLAN and a policy list together.

aaa user-network-profile name voip vlan 199 policy-list-name qos_list_voip

A third way to dynamically assign ports to VLANs is LLDP Media Endpoint Detection (LLDP-MED). LLDP Media Endpoint Detection was developed to increase the interoperability of VoIP devices with other devices on the network (eg. PC, switches etc). AOS uses LLDP-MED network policies to advertise information to devices. A network policy contains information about VLAN ID and L2/ L3 priorities. First, we have to enable network policy support, either for a port or for the chassis.

lldp 1/1 tlv med network-policy enable

To enable network policies for the chassis use the keyword “chassis” instead of a port.

lldp chassis tlv med network-policy enable

To create a network policy enter:

lldp network-policy 1 application voice vlan 100 l2-priority 5 dscp 46

The created policy (ID 1) will advertise the VLAN 100, L2 priority 5 and DSCP 46 to voice devices. The next step is to bind the policy to a port or the chassis.

lldp chassis med network-policy 1

Or for a specific port.

lldp 1/1 med network-policy 1

Furthermore, you need to enable VLAN mobility on the ports. If the IP phones sends tagged VLAN frames, you also have to enable the “mobile tag” feature for the VLAN.

vlan 100 mobile-tag enable

The IP phone receives the configuration information over of the network policy. VLAN mobility and “mobile tag” will make sure, that the VoIP phone is pushed to the correct VLAN.

Summary

Manually assigning VLANs can be a time consuming and error prone process. AOS 6 offers

VLAN mobility
User Network Profiles, and
LLDP-MED

to dynamically assign ports to VLANs. Each of the options has its pros and cons. Especially the combination of VLAN mobility and LLDP-MED is really easy to implement. I will publish more blog posts about the same topic, but with AOS 7 and AOS 8.

Microsoft Windows: Avoiding COM port proliferation

This posting is ~7 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Furthermore, you have to reconfigure your client software (PuTTY etc.) each time. This is annoying! But there’s a workaround.

Workaround

All you need is the product ID and the vendor ID. You can find these values in the properties of the device.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The VID for this device is 10C4, the PID EA60. Now create a reg file, which is used to import registry values.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags]
"IgnoreHWSerNum10C4EA60"=hex:01

You can see that the VID and PID was added to the string “IgnoreHWSerNum”. Import the reg file (double click or import it using RegEdit) and remove all unnecessary COM ports from the device manager.

Next time, Windows will not create a new COM port, as long as you use the same USB port. If you change the USB port, Windows will create an additional COM port.

Windows recieves wrong DNS server from DHCP after DHCPINFORM

This posting is ~7 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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.

Observations

It was quicky clear, that some of the clients have received the wrong DNS servers from the DHCP server. That is the (defaced) output of a SUBDOM client with the correct IP settings.

   IPv4 Address  . . . . . . . . . . : 10.1.1.146(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . : 10.1.1.1
   DHCP Server . . . . . . . . . . . : 10.1.1.2
   DNS Servers . . . . . . . . . . . : 10.1.1.2
                                       10.10.1.2

And this is the output of the same client, after a reboot:

   IPv4 Address  . . . . . . . . . . : 10.1.1.146(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . : 10.1.1.1
   DHCP Server . . . . . . . . . . . : 10.1.1.2
   DNS Servers . . . . . . . . . . . : 172.16.1.2
                                       172.16.1.3

As you can see, the client got its DHCP information from the same DHCP server, but with the wrong DNS settings. The DNS servers are the servers from the ROOTDOM.

only clients from SUBDOM were affected
only Windows XP and Windows 7 clients were affected
Windows 8.1 and Windows 10 clients were not affected
Igel Thin Clients were not affected
after an “ipconfig /renew”, the correct DNS servers were registered
after an “ipconfig /release” and “ipconfig /renew”, the wrong DNS servers were registered
the same happened after a reboot
Wireshard packet trace showed, that the correct DNS information were included in the DHCPOFFER

The sum of observation told me, that this has nothing (or less) to do with the network changes. Interestingly, the correct DNS information were included in the DHCPOFFER and the behaviour was only observed on Windows XP and Windows 7. In addition, only clients of SUBDOM were affected.

The smoking gun

The packet trace with Wireshark showed, that the correct DNS information was included in the DHCPOFFER. But I also saw, that the client has sent a DHCPINFORM, which was answered by all available DHCP servers.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

DHCPINFORM is used by a client to discover more information, e.g. router, proxy, static routes… or DNS. The DHCPINFORM request was only sent after a reboot, or after a DHCPRELEASE and a subsequent DHCPDISCOVER. I saw that all available DHCP servers answered the DHCPINFORM request with a DHCPACK. This DHCPACK included the requested information, including DNS. I quickly developed the hypothesis, that the DHCPACK from the ROOTDOM DHCP servers was used by the client, to add the wrong DNS information to the configuration.

With this information, I quickly found a references (Meraki, Laurent Gaffié) to a registry key, that can be used to disable DHCPINFORM. This registry key is valid for Windows 2000, 2003, Windows XP, Windows Vista and Windows 7. Especially the blog post from Laurent Gaffié gave is interesting:

A vulnerability in Windows DHCP (http://www.ietf.org/rfc/rfc2131.txt) was found on Windows OS versions ranging from Windows 2000 through to Windows server 2003. This vulnerability allows an attacker to remotely overwrite DNS, Gateway, IP Addresses, routing, WINS server, WPAD, and server configuration with no user interaction.

It’s useful to disable DHCPINFORM, even if you don’t have a problem!

Disable DHCPINFORM

To disable DHCPINFORM, you must add a registry key for the network interface, that shouldn’t sent DHCPINFORM messages.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface GUID} 
Value Type: DWORD
Value name: UseInform
DWORD Value: 0

Unfortunately the GUID of the interface differs between clients. I build this Visual Basic script (like Dr. Frankenstein: Different sources, plugged together, but it works) to add the registry key. You can run this script as part of a startup script with a Group Policy.

You should test this script very carefully! I provide this script “AS IS” with no warranties.

I don’t know why this has happened. I assume that the customer had this problem for some time. But due to some strange effects, he never noticed it. One hypothesis is, that the sequence of the DHCPACK messages after a DHCPINFORM has an influence. The DHCP server of ROOTDOM was moved to the new core switches, and maybe this changed the sequence of the answer packets. But it’s only a hypothesis, not a theory.

ALE OmniSwitch stack does not form due to incompatible licenses

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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:

-> show license info
 NI          Application           License Type                Time Left
-----------+---------------------+---------------------------+--------------
 1              METRO                 Permanent                   0
 1              10G                   Permanent                   0
 1001           10G                   Permanent                   0

The other switch not:

 -> show license info
 NI          Application           License Type                Time Left
-----------+---------------------+---------------------------+--------------
 1              10G                   Permanent                   0

Don’t be confused because of the slot numbering. I pulled the stacking cable.

The solution was easy: I removed the metro license and after a reboot of the switch, from which I removed the license, the stack formed properly.

-> 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 SECONDARY   RUNNING    1    UP          2   StackB  DOWN        0        0
   2 PRIMARY     RUNNING    2    DOWN        0        0  UP          1   StackA

An attempt to restore the reputation of IPv6

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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. With IPv6 enabled, we had connectivity problems.”. Sometimes it went wrong. Especially in this cases, where IPv6 was only unbind from the network adapter. That’s the wrong way to “disable” IPv6.

Troublemaker IPv6

I have often heard that IPv6 causes connectivity problems. One of the most common examples is slow internet access. Often in conjuction with Windows Vista, Server 2008 or later, or with Linux (I don’t have a Mac and I don’t have many customers that use Macs a significant number). But every time, disabling IPv6 was the “solution”.

Another example: Domain-joined Windows Clients lose connection to the Active Directory, or can’t join an Active Directory domain. Disabling IPv6 was the “solution”.

This third example is particularly nice: Some of you will know this. It’s the default setting on Active Directory Domain Controllers since Server 2008:

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

This setting results in an ugly “unknown” in nslookup.

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\windows\system32>nslookup
Default Server:  UnKnown
Address:  ::1

>

Many admins change the setting to “Obtain DNS server address automatically”. Then they will start wondering, why the Active Directory domain has stopped working. Solution? Disabling IPv6.

IPv6 seems to be quite a waste, right? Sometimes it helps to understand why something has happened.

IPv6 Autoconfiguration

With IPv4, you need a DHCP server or static IP addresses. Okay, RFC3927 describes a third way (Dynamic Configuration of IPv4 Link-Local Addresses), but this was added long after the release of IPv4. IPv6 includes an autoconfiguration process. This process is specified in RFC4862 (IPv6 Stateless Address Autoconfiguration). This process is called SLAAC, StateLess Address AutoConfiguration. RFC4862 describes:

The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link.

These IPv6 link-local addresses are assigned, or changed, whenever an interfaces is

initialized (for example on system startup),
an interface is enabled for IPv6,
an interfaces is re-initialized or,
an interface is attached to a new network

These IPv6 link-local addresses share a common IPv6 prefix (FE80::/10) and are only valid for the local network (layer 2 domain). They will not be routed. An IPv6 link-local address is dynamically generated and consists of the link-local prefix (FE80::/10) and an interface identifier. Latter is generated from the world-wide unique MAC address. This should ensure that a IPv6 link-local address is unique. Neverless, there is a Duplicate Address Detection (DAD). The relationship between link-local and MAC address is handy, but to protect your privacy, the interface identifier will include a random part (RFC4941 – Privacy Extensions for Stateless Address Autoconfiguration in IPv6).

Open a terminal/ command prompt and check your IP addresses. You will find a IPv6 IP starting with FE80 for each interface (if not, continue reading and re-enable IPv6…). This output is taken from my laptop running Windows 8.1 (german localization).

Drahtlos-LAN-Adapter WiFi:

   Verbindungsspezifisches DNS-Suffix: fritz.box
   Beschreibung. . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 7265
   Physische Adresse . . . . . . . . : 4C-34-88-07-12-28
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::89d4:4eb0:3ff4:9172%6(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.20.17(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.224
   Lease erhalten. . . . . . . . . . : Freitag, 1. Januar 2016 12:47:13
   Lease läuft ab. . . . . . . . . . : Montag, 1. Februar 2016 15:15:57
   Standardgateway . . . . . . . . . : 192.168.20.30
   DHCP-Server . . . . . . . . . . . : 192.168.20.30
   DHCPv6-IAID . . . . . . . . . . . : 139211912
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1D-9C-96-3B-4C-34-88-07-12-28

   DNS-Server  . . . . . . . . . . . : 192.168.20.30
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Notice the IPv6 link-local address in the output: fe80:0000:0000:0000:89d4:4eb0:3ff4:9172, or shorter fe80::89d4:4eb0:3ff4:9172. Check your clients, your servers, your switches and routers. Most of them will have an IPv6 link-local address.

Explore the neighborhood

With an IPv6 link-local address, your host has everything to explore the neighborhood. RFC4861 specifies the “Neighbor Discovery for IP version 6 (IPv6)”.

IPv6 nodes on the same link use Neighbor Discovery to discover each other’s presence, to determine each other’s link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.

Now multicast comes into play. The host will send a request to the multicast address ff02::2 (all routers in the local network). This is called a Router Solicitation. A router will respond to this request with a Router Advertisement. This advertisement include information about the MTU, lifetime and the prefix. The host can use this prefix to create its own local (fc00::/7) or global (2000::/3) unicast IPv6 address. This address also sets together from prefix (included in the Router Advertisement) and an interface identifier (randomly generated due to privacy extension or based on the MAC address of the physical interface). Router Advertisements are sent periodically (default 200 seconds) or as response to a Router Solicitation. Router Advertisements are only sent by routers. Because of this, the sender address of a Router Advertisement is used as default gateway by the host. If multiple routers are available, a in RFC4861 described algorithm will make the selection. If there are no routers available on the local network, there will be no response on a Router Solicitation and the default gateway will not be changed. A Router Advertisement doesn’t include information about DNS servers, domain name etc. The packet offers two flags, that can be used by the host to determine if there is a DHCPv6 server: The M-bit (managed address config flag) is set to 1 if a stateful DHCPv6 is available. The O-bit (other config flag) is set to 1 if the host should ask a stateless DHCPv6 server for DNS servers, domain name etc. If the M-bit is set to 1, the O-bit will be ignored. If the M-bit is set, the IPv6 unicast address is assigned by the stateful DHCPv6 server.

A stateful DHCPv6 server can assign IPv6 IP addresses. A statefless DHCPv6 can’t! Latter can only provide information about optional IP parameters like DNS server, domain name, SNTP server etc.

Neighbor Discovery can do so much more. There are five ICMPv6 packet types, and Router Solicitation and Advertisement are only two of them. The Neighbor Solicitation is used by hosts to determine the link-local address of a neighbor host. It’s also used to verify that a neighbor host is still reachable via a cached link-local address. Neighbor Advertisements are used in the same way as Router Advertisements: They are used to respond a Neighbor Solicitation. Redirect is used to inform hosts that there is a better first hop router for a specific destination. Some admins have the strong wish to block ICMP. Don’t even think about blocking ICMPv6. You will get into trouble.

Putting the pieces together

Imagine you have a network with multiple clients, servers, routers etc. Now you add a new router to your network. It’s a router for home users, but it was cheap and it’s only for a cable connection, that you want to use for downloads. You add the router to your network and the fun starts. Clients can’t connect to the domain network. Your domain controllers are going mad. Branch offices aren’t reachable any more. You disable IPv6 on clients and servers and everything is fine. You enable IPv6, you remove the new router, and everything is fine. But with your new router active and IPv6 enabled, everything is fucked up.

Let me explain what has happened. The new router has started to send Router Advertisements. Your clients and servers now have a new, additional default gateway. Since Microsoft Server 2008 and Windows Vista, IPv6 has precedence over IPv4. Maybe the new router acts as stateless DHCPv6 server. Your clients and servers are now using your ISPs DNS servers. It is logical that services, that relies on your corporate DNS, doesn’t work anymore. If internet is slow, this is mainly a DNS problem. Your ISP or the router treats AAAA DNS requests wrong.

Lessons learned

You should not disable IPv6. Microsoft doesn’t recommend this. It will break things.

We do not recommend that you disable IPv6 or its components, or some Windows components may not function.

If you have trouble with IPv6, check what is wrong and fix it. If a device sends RA or acting as a stateless DHCPv6, configure the device the right way. But stop blaming IPv6. It’s that easy. ;)

First hands-on experience with Alcatel-Lucent OmniSwitches

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

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. Since october 2014, ALE offers communication, cloud and networking solutions for business of all sizes. More than 2700 employees in 100 countries and 2900 partners serve solutions for more than 830000 customers worldwide. ALE offers solutions for unified communications and collaboration, which benefit from intelligent and converged networks. Solutions that scale from the local office to the cloud. Unified communication and collaboration solutions include business telephony solutions (e.g. voice, video and conferencing across the enterprise), mobility solutions (e.g. wired and wireless voice and unified communications across the enterprise and across devices) and collaboration solutions (e.g. cloud or on-premises web conferencing).

I will focus on the OmniSwitch campus access switches in this blog post.

A simple comparison

ALE has sent me two OmniSwitch 6450 (OS6450) to play with. The OS6450 is stackable gigabit and fast ethernet switch for the network and metro access. Depending on the model, the OS6450 has 24 or 48 RJ-45 ports and two SFP+ tranceiver slots for 1 GigE or 10 GigE uplinks. There is also a model with 22 SFP slots, as well as models with PoE+ and without PoE. Up to 8 switches can be added to a single stack. The HW for the fast ethernet switches is gigabit ethernet capable, so a simple software license can upgrade a fast ethernet to a gigabit ethernet switch. You can also upgrade a 1 GbE uplink to a 10 GbE uplink by adding a license key. Optional metro ethernet features (e.g. IEEE 802.1ad Provider Bridge, IEEE 802.1ag Ethernet OAM or ITU-T G.8032 Ethernet Ring Protection) can easily added with a software license. The OS6450 can do basic L3 routing (static and RIP) and it supports IPv4, IPv6 and OpenFlow. A complete overview over the ALE campus and data center switch products can be found in this product brochure.

With which devices can the OS6450 be compared? I have chosen two switches from competitors and set them into comparsion with a OS6450: The HP 2920-48G-POE+ and a Cisco Catalyst 2960X-48LPD-L. All switches have 48 gigabit ethernet ports and PoE+ support. Please note that this is only a comparison based on specs. Just to get a feeling for the range.

	OS6450-P48	HP 2920-48G-POE+	Cisco Catalyst 2960X-48LPD-L
Ports	48x RJ-45 10/100/1000 ports 2x SFP+ Transceivoer Slots (10 Gigabit capable with additional software license) 2x Expansion slots for Stacking, SFP(+) or RJ-45 Uplinks	44x RJ-45 10/100/1000 ports + 4x SFP+/ RJ-45 dual personality 2x Expansion slots with 2 Ports for Stacking, SFP(+) or RJ-45 Uplinks	48x RJ-45 10/100/1000 ports 2x SFP+ Transceiver Slots One expansion slot for FlexStack module
Power Supplies	Internal power supply, internal RPS possible	Internal power supply, external RPS possible	Internal power supply, external RPS possible
Switching throughput	131.0 Mpps	131.0 Mpps	131.0 Mpps
Switching capacity	176 Gbps	176 Gbps	216 Gbps
Stacking capacity	40 Gb/s	80 Gb/s	80 Gb/s
Switching latency	< 4 µs	< 4 µs	< 4 µs
MAC table size	16000 entries	16000 entries	16000 entries
Max. VLANs	4000	256	1023 (active)
Routing Protocols	Static routing and RIP, IPv4 and IPv6	Static routing and RIP, IPv4 and IPv6	Static routing, IPv4 and IPv6
Routing Table (unicast, direct routes)	256 entries for IPv4 and 128 entries for IPv6	2048 entries for IPv4 and 256 entries for IPv6	2000 entries (IPv4) and 2000 entries (IPv6)
Protocols and Features	Nearly no difference. All switches support a common set of features and protocols.
Datasheet	Link to ALE	Link to HP	Link to Cisco

As you can see: Not much differences. And that proves once again: Switches are commodities. And because of this, it’s not a question of hardware, it’s about the ecosystem around, OPEX and your connection to your favorite VAR.

If it is not the hardware, why should I draw ALE into consideration? ALE offers the vision of the Application Fluent Network…

The Application Fluent Network

To support the requirements in the best possible way, ALE has developed the vision and the products for the Application Fluent Network. The Application Fluent Network is based upon three components:

a resilient architecture,
streamlined operations, and
automatic control

A resilient architecture is often a simplified, lean architecture. In the context of networking, a simplified and lean architecture is often based upon two (core and access layer), and not three tiers (core, distribution, access). Streamlined operations mean automatic provisioning of switches and enpoints, such as WiFi access points, converged management for data and voice, centralized troubleshooting and a common OS for all switches. Automatic control describes how the requirements of users and application, like VLAN, ACL or QoS settings, are automatically applied by profiles, policies and auto-sensing of users and endpoints.

Alcatel-Lucent Enterprise/ al-enterprise.com

Needless to say that software defined networking (SDN) is an important part of the Application Fluent Network. Most switch models offer RESTful API, Python, OpenFlow and OpenStack integration. If you are interested to see, how ALE OmniSwitches can be integrated with VMware NSX, check this whitepaper: VMware NSX and OmniSwitch 6900 interoperability setup. You can’t manage what you don’t know. To address this, ALE developed the OmniSwitch 6860. On the first look a classy high-density gigabit ethernet switch. But under the hood, ALE added a hardware-based application recognition engine. This engine allows the switch to detect the traffic of more than 2000 applications in real time. This capability can be used to apply policies to business-critical applications like Citrix XenApp/ XenDesktop (ICA protocols) or communications applications using Session Initiation Protocol (SIP). If you want to read more about this, check out this whitepaper: Delivering application analytics for an Application Fluent Network.

Lab setup

The two OS6450 are stacked, so the two physical switches form a virtual chassis/ logical switch. My lab equipment is connected to both switches, e.g. each ESXi host has two 1 GbE links to each OS6450. My Synology DS414slim is connected with a LACP LAG, spanning both switches. The OS6450 is configured with multiple VLANs and it does L3 routing between the VLANs and to my lab firewall.

The setup was really easy. With the correct slot number assignment, the stack is formed automatically. Both switches had a stacking module, so all I had to do was plug in the stacking cable and turn on the switches on.

Welcome to the Alcatel-Lucent OmniSwitch 6450
Software Version 6.6.5.63.R02 GA, December 16, 2014.

Copyright(c), 1994-2014 Alcatel-Lucent. All Rights reserved.

OmniSwitch(TM) is a trademark of Alcatel-Lucent registered
in the United States Patent and Trademark Office.

-> 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          2   StackB  DOWN        0        0
   2 SECONDARY   RUNNING    2    DOWN        0        0  UP          1   StackA

->

The switches are running AOS 6.6.5 R02. The current release is 6.7.1 R01. Unfortunately there is no public download available. You need access to the business partner portal. Contact your VAR so he can assist you.

I’m a CLI guy. For the configuration, I’ve used the CLI. The CLI is nothing special. The command set differs from Cisco or HP, but the same applies to Juniper Junos or Arista EOS. If you have understood the technology, then the rest is syntax. Get the CLI guide and everything will be fine. Let’s go through the configuration of my stack.

There is no configuration mode. Each command you enter will be immediately effective. AOS knows to different operation modes:

working, and
certified

In working mode you can modify the configuration, but not in certified mode. During the boot process, working and certified config were compared and if they differ, the switch will use the certified config. If you have changed the switch config and you messed it up… just reboot the switch. Just a few lines to get a brief overview over the CLI and configuration steps.

First, the switch needs a name, a system contact, date/ time etc.

system name OS6540-Stack
system contact "Patrick Terlisten"
system location "ML Network GmbH"
system timezone CET
system daylight savings time enable

To add an NTP server, just enter:

ntp server 192.168.200.65 key 0 version 4 minpoll 6
ntp client enable

To create a VLAN with the ID 2 and the name “Management” enter:

vlan 2 enable name "Management"

To assign a specific VLAN to a port, use this command.:

vlan 2 port default 1/13
vlan 2 port default 2/13

With this command, the port 13 on the first and second chassis is assigned to VLAN 2. This is similar to an access port (Cisco IOS or HP Comware). If you need 802.1Q VLAN tags, use

vlan 2-6 100 200 802.1q 1/1 "ESX1 Onboard Port 1"

to configure a port for the VLANs 2 to 6, 100 and 200. For inter-VLAN routing you need to add IP interfaces to the VLANs. With

ip interface "SVI VLAN 2" address 192.168.200.62 mask 255.255.255.224 vlan 2

you create an interface with the IPv4 address 192.168.200.62 in VLAN 2. If you need an IPv6 address, you need two steps. First, you have to create an IPv6 interface. During this step, a IPv6 link-local IP address is assigned. In a second step, an IPv6 address is assigned (in this case a unique local address).

ipv6 interface "IPv6 SVI VLAN 2" vlan 2
ipv6 address fdda:28ad:487:2:ffff:ffff:ffff:fffe/64 "IPv6 SVI VLAN 2"

To configure Spanning Tree and set the bridge priority to 0, enter:

bridge mode flat
bridge 1 priority 0

Bridge mode flat implies a single spanning tree instance, whereas mode 1×1 is similar to Ciscos PVST. With

bridge mode 1x1 pvst+ enable

you can enable PVST+ interoperability mode. IP helper addresses are also something really fundamental. It’s no problem to configure multiple addresses.

ip helper per-vlan only
ip helper address 192.168.200.65 vlan 3
ip helper address 192.168.200.65 vlan 4

The first command enables per-vlan IP helper addresses. The next commands configure 192.168.200.65 as helper address for VLAN 3 and 4. To save the configuration use

-> write memory
File /flash/working/boot.cfg replaced.
This file may be overwritten if "takeover" is executed before "certify"

and

-> copy working certified flash-synchro
Setting CERTIFY Timeout for 800 seconds
from /flash/working to /flash/certified
Copying boot.cfg                             ....................          completed

CERTIFY process completed successfully
Flash Synchronization process started
+++ == CSM == Stack 1 Certify process Completed
+++ == CSM == Stack 2 Certify process Completed
Flash Synchronization process completed successfully

The first command saves the running configuration to the working configuration. The next command saves the working configuration to the certified configuration and synchronizes the configuration between the stack members. Sometimes you need to take a look into the logs. With

-> show log swlog level alarm
Displaying file contents for '/flash/swlog2.log'
FILEID: fileName[/flash/swlog2.log], endPtr[63779],  configSize[64000], mode[2]
Time Stamp               Application    Level   Log Message
------------------------+--------------+-------+--------------------------------
THU NOV 30 01:20:50 2000    DHCP-SERVER   alarm Load initial policy file failed.  Error=13893637
THU NOV 30 01:20:50 2000    DHCP-SERVER   alarm Cannot open QDHCP configuration file: /flash/switch/dhcpd.conf.  Error=13893637
THU NOV 30 01:20:50 2000    DHCP-SERVER   alarm Cannot open QDHCP configuration file: /flash/switch/dhcpd.conf.lastgood.  Error=
THU NOV 30 01:20:50 2000    DHCP-SERVER   alarm [Count.]13893637

you get a listing of all alarm messages. But you can also use one of the other log levels:

-> show log swlog level ?
                       ^
                       WARNING OFF INFO ERROR DEBUG3 DEBUG2 DEBUG1 ALERT ALARM
                       <num>
 (System Service & File Mgmt Command Set)

AOS also has a web interface, called Web View. I haven’t played much with it. It’s not a beauty, but it’s fast and suitable suitable for all non-networking nerds.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Click on the picture to enlarge it.

What is coming?

This is only a first look. I really like the OmniSwitches, and I like the approach to score with added value, and not with “feature fucking”. The next step is to get OmniVista 2500 Network Management System up and running in my lab. I will certainly write about it. Stay tuned for more ALE OmniSwitch content on vcloudnine.de.

HP Comware and Windows NLB cluster in multicast mode

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

In January 2014 I wrote a blog post about network flooding because of Windows NLB clusters in unicast mode. Yesterday, Windows NLB, HP switches and I met again.

After moving a customers core network from HP 5400zl switches to two IRF stacks with HP 7506 switches, multiple Windows NLB clusters stopped working. Because the Windows NLB used multicast operation mode, it was instantly clear that the switches were the problem.

The explanation is easy: By default, a Comware based switch does not learn multicast MAC addresses. And because of this, the switch does not add them to the ARP table. And you can’t add static multicast MAC address entries. You have to disable the ARP entry check.

To do so, you have to login and change to the system-view. Then disable the ARP entry check option, which is enabled by default.

<HP> system-view
[HP] undo arp check enable

A few seconds after issuing the command, the NLB clusters started working again and I saw ARP entries with MAC addresses starting with 03-BF.

HP Comware: Forwarding subnet-directed broadcasts for Wake-on-LAN

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Last week, my colleague Claudia and I have ported a HP ProVision configuration to HP Comware. Unexpectedly, it wasn’t routing or VLANs or OSPF that caused headaches, it was a Wake-on-LAN (WoL). Depending on the used tool, the magic packet (which wakes up the computer) is a broadcast (255.255.255.255) or a subnet-directed broadcast (e.g. 192.168.200.255). So it was important to know what tool the customer used.

This is how HP ProVision implements subnet-directed broadcasts:

ip directed-broadcast
ip udp-bcast-forward
vlan 99
     ip address 192.168.200.254 255.255.255.0
     ip forward-protocol udp 10.0.0.255 9
vlan 3
     ip address 10.0.0.254 255.255.255.0

The first two commands are issued globally. The “ip forward-protocol” statement has to be entered in the source VLAN (from which the magic packets are sent). The “ip forward-protocol” statement includes the protocol (udp), the destination (the broadcast address of the subnet) and the udp port (WoL uses port 9). Pretty simple, right? But please note that this config works only for sunet-directed broadcasts. And it only works for WoL. If you need another port (e.g. udp port 7), you have to add an additional “ip forward-protocol” statement.

If you use HP Comware, the configuration differs in some points. You can enable the reception of subnet-directed broadcasts by entering “ip forward-broadcast” globally in the system-view. This is mandatory.

<HP> system-view
[HP] ip forward-broadcast

The next step is to tell the switch, to which destination it should forward subnet-directed broadcasts. This can be done by entering “ip forward-protocol” in the vlan-interface context.

[HP-Vlan-Interface99] ip forward-broadcast

The downside: All subnet-directed broadcasts will be forwarded, regardless of source, destination or protocol. To avoid this, you have to create a ACL and add this to the “ip forward-broadcast” statement. To create an ACL enter:

[HP]acl number 3001
[HP-acl-adv-3001] rule 10 permit udp source 192.168.200.0 0.0.0.255 destination 10.0.0.255 0 destination-port eq 9
[HP-acl-adv-3001] quit
[HP] interface Vlan-interface 99
[HP-vlan99] ip forward-broadcast acl 3001

You have to bound the ACL to the source VLAN interface. The subnet-directed broadcast will be forwarded to the VLAN interface which is directly connected to the destination subnet, or if there is no directly connected interface, to a router which knows the way to the destination. If you have applied packet filter ACLs to VLAN interfaces, make sure that your forwarded subnet-directed broadcasts aren’t filtered!