Ip Feature Config Overview Revd
Ip Feature Config Overview Revd
Ip Feature Config Overview Revd
Introduction
This guide describes how to configure IPv4 addressing and the protocols used to help IP
function on your network.
As well as the familiar Internet (with uppercase “I”), the term internet (with lowercase “i”)
can refer to any network (usually a wide area network) that uses the Internet Protocol. This
guide concentrates on this definition—a generalized network that uses IP as its network
protocol.
However, feature support and implementation varies between products. To see whether a
product supports a particular feature or command, see the following documents:
These documents are available from the above links on our website at alliedtelesis.com.
Feature support may change in later software versions. For the latest information, see the
above documents.
C613-22007-00
x REV D alliedtelesis.com
Internet Protocol (IP) Addressing and Protocols
Content
Introduction ........................................................................................................................ 1
Products and software version that apply to this guide .............................................. 1
Checking IP Connections................................................................................................. 22
Ping............................................................................................................................ 22
Traceroute .................................................................................................................. 22
Assigning an IP Address
To configure your device to perform IP routing (for example, to access the Internet) you
need to configure IP. You also need to configure IP if you want to manage your device
from any IP-based management process (such as SSH, Telnet, or SNMP).
Add an IP address to each of the interfaces to or from which you want to route IP, or which
you want to use as a management interface on the device. You can configure an interface
on your device with a static IP address, or with a dynamic IP address assigned using your
device’s DHCP client.
Static IP To add a static IP address to an interface, enter interface mode for the interface that you
addresses want to configure, then use the command:
For example, to give the interface vlan1 an address of 192.168.10.10, with a class C
subnet mask, use the command:
The secondary parameter allows you to add multiple IP addresses to an interface using
this command. Each interface must have a primary IP address before you can add a
secondary address. Your device treats secondary addresses the same as primary
addresses in most respects, such as responding for ARP requests for the IP address.
However, the only packets generated that have a secondary address as source address
are routing updates. You can define up to 32 secondary addresses on a single interface.
DHCP When you use the DHCP client, it obtains the IP address and subnet mask for the
dynamic interface, and other IP configuration parameters, from a DHCP server. To configure an
addresses
interface to gain its IP configuration using the DHCP client, use the command:
If you need to make a static entry in the DHCP server from which the device is obtaining
its IP address, you need your device's MAC address, which you can display by using
the command: show interface
See the DHCP Feature Overview and Configuration Guide for more information about
DHCP.
When your device needs to forward packets to a destination whose Layer 2 address it
does not know, it broadcasts an ARP request to determine the Layer 2 destination
address to put on the packet. The ARP request is a broadcast packet and includes the
target IP address. All stations on the LAN receive this broadcast but only one host
recognizes its own IP address. It replies, thereby giving your device its physical address.
Your device creates a dynamic ARP entry in its ARP cache, to record the IP address to
physical address mapping (also called a binding). It uses that ARP entry to find that host's
physical address when forwarding further packets to that address.
The ARP protocol is described in RFC 826, An Ethernet Address Resolution Protocol—
or—Converting Network Protocol Addresses to 48 bit Ethernet Address for Transmission
on Ethernet Hardware.
Increasing the ARP timeout reduces the amount of network traffic. Decreasing the timeout
makes your device more responsive to changes in network topology.
To set a timeout period, enter the interface mode, then use the command:
The ARP cache will be repopulated by the normal ARP learning mechanism. As long as
the entries are relearned quickly enough, deleting dynamic ARP entries does not affect:
routes
VRRP status
Proxy ARP
Proxy ARP (defined in RFC 1027) deals with the situation where hosts in one subnet are
sending ARP requests for IP addresses that are in a different subnet. Typically, this
happens when the subnet mask configured on the requesting hosts does not match the
subnet mask that has actually been allocated to their subnet.
Your device intercepts these ARP broadcast packets that are requesting IP addresses that
are outside the local subnet, and substitutes its own physical address for that of the
remote host. This occurs only if your device has the best route to the remote host.
By responding to the ARP request, your device is effectively saying to the requesting host
'send that traffic to me, and I will ensure it gets to that requested destination'. So, that
subsequent packets from the local host, destined for the IP address outside the local
subnet, are directed to your device's physical address, and it can then forward these to
the remote host. The process is symmetrical.
Proxy ARP is disabled by default. To enable proxy ARP on an interface, use the
commands
awplus(config-if)# no ip proxy-arp
To check Proxy ARP is enabled on an interface, use the show running-config command.
If Proxy ARP has been enabled an entry shows ip proxy-arp below the interface it is
enabled on. No ip proxy-arp entry below an interface in the config indicates Proxy ARP is
disabled on that interface.
See the sample configuration commands and validation command with resulting output
showing proxy ARP enabled on VLAN 2 below:
awplus#configure terminal
awplus(config)#interface vlan2
awplus(config-if)#ip proxy-arp
awplus(config-if)#end
awplus(config)#exit
awplus#show running-config
!
interface vlan2
ip proxy-arp
ip address 192.168.2.2/24
!
See the sample configuration commands and validation command with resulting output
showing proxy ARP disabled on VLAN 2 below:
awplus#configure terminal
awplus(config)#interface vlan2
awplus(config-if)#no ip proxy-arp
awplus(config-if)#end
awplus(config)#exit
awplus#show running-config
!
interface vlan2
ip address 192.168.2.2/24
!
Local Proxy ARP extends proxy ARP by intercepting and responding to ARP requests
between hosts within a subnet. Local proxy ARP responds to ARP requests with your
device’s own MAC address details instead of those from the destination host. This stops
hosts from learning the MAC address of other hosts within its subnet.
When Local Proxy ARP is operating on an interface, your device does not generate or
forward any ICMP-Redirect messages on that interface.
Local Proxy ARP is disabled by default. To enable local proxy ARP on an interface, use the
commands:
awplus(config-if)# no ip local-proxy-arp
To check Local Proxy ARP is enabled on an interface, use the show running-config
command. If Local Proxy ARP has been enabled an entry shows ip local-proxy-arp
below the interface it is enabled on. If there is no ip local-proxy-arp entry below an
interface in the config, that indicates Local Proxy ARP is disabled on it.
See the sample configuration commands and validation command with resulting output
showing local proxy ARP enabled on VLAN 1 below:
awplus#configure terminal
awplus(config)#interface vlan1
awplus(config-if)#ip local-proxy-arp
awplus(config-if)#end
awplus(config)#exit
awplus#show running-config
!
interface vlan1
ip local-proxy-arp
ip address 192.168.1.2/24
!
See the sample configuration commands and validation command with resulting output
showing Local Proxy ARP disabled on VLAN 1 below:
awplus#configure terminal
awplus(config)#interface vlan1
awplus(config-if)#no ip local-proxy-arp
awplus(config-if)#end
awplus(config)#exit
awplus#show running-config
!
interface vlan1
ip address 192.168.1.2/24
!
ARP logging
You can enable your device to log events that happen in the ARP cache, like the adding
and deleting of static and dynamic ARP entries, and you can select either default
hexadecimal notation (HHHH.HHHH.HHHH) or standard IEEE format hexadecimal
notation (HH-HH-HH-HH-HH-HH) for the MAC addresses displayed in the ARP log
output.
If this feature is enabled, ARP log messages are stored on the device in RAM. If the device
is rebooted the ARP log messages are lost. ARP logging is disabled by default.
You can specify whether the MAC address is displayed in the default hexadecimal
notation HHHH.HHHH.HHHH or in the standard IEEE format HH-HH-HH-HH-HH-HH.
See the sample ARP log output and descriptions of the fields displayed in the sample ARP
log output in the arp log command.
AlliedWare Plus has the ability to resolve domain names for internally generated
commands (DNS Client) as well as providing the DNS information to connected hosts (via
DNS Relay and DHCP Server. The DNS Client is enabled automatically when at least one
DNS server is configured on the device, with the command ip name-server <ip-addr>.
This client allows you to use domain names instead of IP addresses when using
commands on your device, like ping, SSH, and copy.
The DNS Relay provides the presence of a local virtual DNS server which can service DNS
lookup requests sent to it from local hosts. The DHCP Server can be configured to
provide DNS information to DHCP clients during the lease process.
Server hierarchy
A network of domain name servers maintains the mappings between domain names and
their IP addresses. This network operates in a hierarchy that is similar to the structure of
the domain names. When a local DNS server cannot resolve your request it sends the
request to a higher level DNS server.
For example, to access the site “alliedtelesis.com”, your PC sends a DNS inquiry to its
local DNS server asking for the IP address matching alliedtelesis.com. If this address is
already locally cached (following its recent use), the DNS server returns the IP address
that matches alliedtelesis.com. If the DNS server does not have this address cached, it
forwards the request upwards through the hierarchy of DNS servers until a DNS server
can resolve the mapping. This means an often-used domain name is resolved quickly,
while an uncommon or nonexistent domain may take longer to resolve or fail.
As well as the hierarchy of domain name servers accessible through the Internet, you can
operate your own DNS server to map to private IP addresses within your network.
The DHCP server IP address can be either statically defined, or can be dynamically
assigned via DHCPv4 option 6 using the ip name-server command and DHCP option 15
using the ip domain-name command if the DHCP client is configured.
See the DHCP Feature Overview and Configuration Guide for more information about
DHCP and DHCP options.
DNS client
Your AlliedWare Plus device has a DNS Client that is enabled automatically when you
configure a Name server address on to your device. This client allows you to use domain
names instead of IP addresses when using commands on your device.
To add a DNS server to the list of servers that the device sends DNS queries to, use the
command:
To check the list of servers that the device sends DNS queries to, use the command:
To add a default domain name used to append to DNS requests, use the command:
For example, to use DNS to match hostnames to your internal network “example.net”,
use the command:
If you then use the command ping host2, your device sends a DNS request for
host2.example.net. To check the domain name configured with this command, use the
command:
Alternatively you can create a list of domain names that your device will try in turn by
using the command:
For example, to use DNS to match incomplete hostnames to the top level domains
“.com”, and “.net”, use the commands:
If you then use the command ping alliedtelesis, your device sends a DNS request for
alliedtelesis.com and if no match was found your device would then try alliedtelesis.net.
awplus(config)# no ip domain-lookup
To check the status of the DNS client on your device, and the configured servers and
domain names, use the command:
DNS Relay
Enabling DNS Relay your switch provides the capability for it to act as a local virtual DNS
server. It can then service DNS lookup requests sent to it from local hosts. Acting as a
DNS Relay, the switch will usually relay the requests to an external, or upstream, DNS
server. By default, DNS Relay is disabled.
Note: When running VRF-lite, the DNS Relay functions will apply separately within each
VRF Instance.
Optionally, DNS name resolver caching may be enabled on the DNS Relay, which can
provide some lookup speed advantage and avoid unnecessary repeated requests to
external DNS servers. By default, DNS caching is disabled.
When the DNS Relay name resolver cache is enabled on your switch, the switch will
maintain a cache of recently used mappings between domain names and IP addresses so
that other identical requests can be responded to without further reference to an external,
or upstream DNS server. When the switch receives a DNS query from a client the switch
will attempt to match the request with entries in this cache. If the switch does not have
this address cached, it forwards the request upwards through the hierarchy of DNS
servers for resolution. The DNS cache has a limited size, and times out entries after a
specified period of up to 60 minutes.
The relaying of DNS queries is required for use in networks where the network
administrator wishes to have the flexibility to easily change to using a different DNS
server. By configuring just the gateway device with the actual DNS address(es), and
configuring all other devices to send their DNS requests to the gateway device, the
administrator need only update the DNS address(es) in one place (on the gateway device)
when changing to a different DNS server. This is far more convenient than having to
update DNS addresses in all the individual hosts in the network.
DNS Relay uses the DNS server list configured by the ip name-server command to
forward DNS query packets. To enable DNS Relay you need to configure the list of servers
that the device sends DNS queries to and then enable DNS forwarding, as shown in the
following example for a DNS server with an IPv4 address:
DNS Relay requires that IP domain lookup is enabled. IP domain lookup is enabled by
default, but if it has been disabled, you can re-enable it by using the command:
awplus(config)# ip domain-lookup
Note both IPv4 and IPv6 support DNS record types. IPv4 and IPv6 are supported in DNS
name-to-address and DNS address-to-name lookup processes. Specifying a name server
and enabling DNS forwarding maps both IPv4 and IPv6 addresses.
You can configure DNS Relay to use IPv6 addresses using the same commands used to
configure DNS Relay to use IPv4 addresses, as shown in the following example:
You can then configure DNS Relay behavior with the following commands:
To set the number of times a switch will retry to forward DNS queries, use the command:
To set the number of seconds to wait for a response, use the command:
To set the DNS forwarding dead-time period in seconds, use the command:
At the dead-time period set, the switch stops sending requests to an unresponsive server.
To set the interface to use for forwarding and receiving DNS queries, use the command:
To specify the DNS Relay name resolver cache size and lifetime, use the command:
To remove entries from the DNS Relay name resolver cache, use the command:
Information which may be useful for troubleshooting DNS Relay is available using the DNS
Relay debugging function. To enable DNS Relay debugging, use the command:
To display the status of DNS Relay name servers, use the command:
To display the DNS Relay name resolver cache, use the command:
For all general DNS lookups such as www.Example.com, use name server 1.2.3.4.
For internal domain names such as atlnz.lc, use the name server received on interface
ppp1.
otherwise everything else will be sent to the primary DNS server 30.1.1.1.
1. When a DNS request for "mail.example.com" is received, the longest successful match
is "example.com", so the request will be forwarded on to DNS server 20.1.1.1.
2. When a DNS request for "something.com" is received, the longest successful match is
against "com", so the request will be forwarded on to DNS server 10.1.1.1.
Note that this feature will only work for DNS lookups from a down-stream host that are
relayed via the device, which is enabled by using the ip dns forwarding command. The
feature functionality does not apply to DNS lookups originating from the device itself, for
example "ping hostname" executed on the device.
The following example shows you how to create a domain list that can be used as a suffix-
list for DNS lookups. The domain list includes domains that are internal to the company
such as “engineering.acme” or “intranet.acme”.
The configuration command, ip dns forwarding, will apply to all VRF instances
configured on the device and not on a per VRF basis.
The configuration commands listed below apply to all VRF instances configured on the
device and not on a per VRF basis. Timeouts are in seconds as per existing commands:
ip dns forwarding retry
The following show commands provide output information for the VRF instance specified.
If a VRF instance is not specified, output is shown for all VRF instances, including the
global instance and the output will be formatted in a way that distinguishes the
information for each VRF.
The DNS cache can also be cleared on a per VRF instance basis by using the clear ip dns
[vrf <name>|global] forwarding cache command.
The following commands show how to configure a DNS relay name-server for both the
specified VRF instance VRF red, and the global VRF instance.
DHCP options
When your device is using its DHCP client for an interface, it can receive the following
DHCP options from the DHCP server:
Option 6 - a list of DNS servers. This list appends to the DNS servers set on your device
with the ip name-server command.
Option 15 - a domain name used to resolve host names. This option replaces the
domain name set with the ip domain-name command.
See the DHCP Feature Overview and Configuration Guide for more information about
DHCP and DHCP options.
DHCP messages between DHCP Clients and a DHCP Server are then able to be relayed
between VLAN interfaces within a VRF-lite instance.
When an DHCP Relay instance is enabled on a VLAN interface, using the command:
ip dhcp-relay server-address, the relay will be placed within the same VRF-lite instance
that the VLAN belongs to. If the VLAN does not belong to a VRF-lite instance, then the
DHCP Relay will be placed in the default (global) VRF.
Note that DHCP option 82 is still supported on a DHCP Relay operating within a VRF-lite
instance.
Example The following example shows how to configure DHCP relay for a VLAN interface that is
associated with named VRF-lite instance VRF red:
The following table lists the ICMP messages implemented by your device.
Table 1: ICMP messages
Echo reply (0) This is used to implement the ping command. Your device sends out
an echo reply in response to an echo request.
Destination unreachable (3) This message is sent when your device drops a packet because it
did not have a route to the destination.
Redirect (5) Your device issues this message to inform a local host that its target
is located on the same LAN (no routing is required) or when it
detects a host using a non-optimal route (usually because a link has
failed or changed its status).
For example, if your device receives a packet destined to its own
MAC address, but with a destination IP address of another host in
the local subnet, it returns an ICMP redirect to the originating host.
ICMP redirects are disabled on interfaces on which local proxy ARP
is enabled.
Echo request (8) This is related to echo replies. If your device receives an echo
request, it sends an echo reply. If you enter the ping command, your
device generates echo requests.
Router Advertisements (10) These are Router Discovery Protocol messages. If Router Discovery
is enabled, your device sends these to announce the IP addresses
of the sending interface.
Time to Live Exceeded (11) If the TTL field in a packet falls to zero, your device sends this
message.This occurs when there are too many hops in the path that
a packet is traversing.
ICMP messages are enabled on all interfaces by default. You can control the flow of ICMP
messages across different interfaces using the access-list commands. See the following
sections in your product’s Command Reference, available on alliedtelesis.com:
Router Discovery
Some AlliedWare Plus devices support the router specification sections of IRDP (RFC
1256, ICMP Router Discovery Messages). If this feature is configured, your device sends
router advertisements periodically and in response to router solicitations. It does not
support the Host Specification section of this RFC.
Benefits
Before an IP host can send an IP packet, the host has to know the IP address of a
neighboring router that can forward the packet to its destination. ICMP Router Discovery
messages let routers automatically advertise themselves to hosts. Other methods either
require someone to manually keep these addresses current, or require DHCP to send
router addresses.
WHEN... THEN...
A host starts up. The host may send a router solicitation message.
Your device receives a router solicitation. Your device multicasts an early router
advertisement from the interface on which it
received the router solicitation.
A host receives a router advertisement. The host stores the IP address and preference
level for the advertisement lifetime.
The lifetimes of all existing router advertisements The host sends a router solicitation.
on a host expire.
A host does not receive a router advertisement The host waits for the next unsolicited router
after sending a small number of router advertisement.
solicitations.
A host needs a default router address. The host uses the IP address of the router or L3
switch with the highest preference level.
Router Discovery advertising is deleted from the Your device multicasts a router advertisement
interface. with the IP address(es) that stopped advertising,
and a lifetime of zero. It continues to periodically
multicast router advertisements for other
interfaces, if configured to.
The router receives a router advertisement from The router does nothing but silently discards the
another router. message.
Advertisement messages
A router advertisement is an ICMP (type 10) message that contains the following:
in the Router Address and Preference Level fields, the addresses and preference levels
of all the logical interfaces that are set to advertise.
Solicitation message
A router solicitation is an ICMP (type 10) message containing:
source address: an IP address belonging to the interface from which the message is
sent
Advertisement interval
The router advertisement interval is the time between router advertisements. For the first
few advertisements sent from an interface (up to 3), your device sends the router
advertisements at intervals of at most 16 seconds. After these initial transmissions, it
sends router advertisements at random intervals between the minimum and maximum
intervals that the user configures, to reduce the probability of synchronization with the
advertisements from other routers on the same link. By default, the minimum is 450
seconds (7.5 minutes), and the maximum is 600 seconds (10 minutes).
Preference level
The preference level is the preference of the advertised address as a default router
address relative to other router addresses on the same subnet. By default, all routers and
Layer 3 switches have the same preference level, zero. While it is entered as a decimal
from 0 to 2147483647, it is encoded in router advertisements as a two’s-complement hex
integer from 0x8000000 to 0x7fffffff. A higher preference level is preferred over a lower
value.
Lifetime
The lifetime of a router advertisement is how long the information in the advertisement is
valid. By default, the lifetime of all advertisements is 1800 seconds (30 minutes).
Address type
Your device can send its router advertisements using either a broadcast or multicast
destination address. By default, your device sends router advertisements using the
all-systems multicast address (224.0.0.1). However, on networks where the hosts do not
support IP multicast you must use the broadcast address (255.255.255.255). To change
the address type to broadcast on an interface, use the command:
To change the address type back to multicast, use the no variant of the above command,
or use the command:
Configuration procedure
Perform the following to configure your device to send router advertisements:
Enter the configuration mode for the interface, using the command:
awplus(config)# interface <interface>
By default, your device sends router advertisements every 7.5 to 10 minutes, with a
lifetime of 30 minutes. These settings are likely to work well in most situations, and will
not cause a large amount of extra traffic, even if there are several routers on the LAN.
If you change these settings, keep the following proportions:
lifetime=3 x maxadvertisementinterval
minadvertisementinverval=0.75 x maxadvertisementinterval
You cannot set the maximum advertisement interval below the minimum interval. If
you are lowering the maximum interval to a value below the current minimum interval,
you must change the minimum value first. This also applies to changing the minimum
interval above the current maximum interval.
To change the lifetime for your device’s router advertisements, use the command:
awplus(config-if)# ip irdp lifetime <0-9000>
By default, every interface has the same preference for becoming a default router. To
give the interface a higher preference, increase the preference level. To give it a lower
preference, decrease this value.
To set the preference level for all addresses on this interface, use the command:
awplus(config-if)# ip irdp preference <0-2147483647>
To set the preference for a specific address on the interface, use the command:
awplus(config-if)# ip irdp address <ip-address> preference
<0-2147483647>
To enable router advertisements on an interface, enter the interface mode and use the
command:
awplus(config-if)# ip irdp
To view the global IRDP configuration for your device, use the command:
awplus# show ip irdp
Debugging IRDP
Information which may be useful for troubleshooting IRDP is available using the IRDP
debugging function. To enable IRDP debugging, use the command:
awplus# debug ip irdp {event|nsm|receive|send|both|detail|all}
Checking IP Connections
To verify connections between networks and network devices, use the ping (Packet
Internet Groper) and trace route functions on your device.
Ping
Ping tests the connectivity between two network devices to determine whether each
network device can ‘see’ the other device. Echo request packets are sent to the
destination addresses and responses are displayed on the console.
If you can ping the end destination, then the physical, Layer 2 and Layer 3 links are
functioning, and any difficulties are in the network or higher layers.
If pinging the end destination fails, use traceroute to discover the point of failure in the
route to the destination.
Traceroute
You can use traceroute to discover the route that packets traverse between two systems
running the IP protocol. Traceroute sends an initial UDP packet with the Time To Live (TTL)
field in the IP header set to a starting value of 1. The TTL field is increased by one for every
subsequent packet sent until the destination is reached. Each hop along the path
between two systems responds with a TTL exceeded packet (ICMP type 11) and from this
the path is determined.
Enter either the hostname or the IP address of the device you are trying to reach.
Page 22 | Ping
Internet Protocol (IP) Addressing and Protocols
When the IP Helper feature is enabled on a VLAN interface, the UDP broadcast packets
received on the interface are processed for forwarding out through another interface into
another subnet. Depending on the nature of the ip-helper addresses configured, the UDP
broadcasts will be unicast forwarded to a single host in the destination subnet, or unicast
forwarded to multiple hosts in the destination subnet, or broadcast to the broadcast
address of the destination subnet. Not all UDP broadcasts will be forwarded when IP
Helper is configured. The set of broadcasts to be forwarded can be defined by specifying
the destination UDP port(s) of the packets you wish to forward.
The command to enable the forwarding of UDP broadcasts received on a given interface
is ip helper-address (entered in interface configuration mode). The ip forward-protocol
udp command specifies types of broadcast packets to forward.
Likewise, multiple different types of UDP packet can be specified for forwarding by
specifying multiple different destination ports using the ip forward-protocol udp
command.
Note: The types of UDP broadcast packets that the switch will forward are only those
specified by the ip forward-protocol command(s). The IP Helper process does not
forward any other UDP packet types by default.
Traceroute | Page 23
Internet Protocol (IP) Addressing and Protocols
IP Directed Broadcast
IP directed-broadcast is enabled and disabled per VLAN interface. When enabled, a
directed broadcast packet is forwarded to an enabled VLAN interface if received on
another subnet.
Introduction
NLB is one of the clustering technologies available from Microsoft®. It provides high
availability for services such as HTTP and FTP, by grouping identical servers into a cluster
and sharing the network load between all currently-available servers in the cluster.
Note that clustering only works, in multicast or unicast mode, if all packets sent to the
cluster's IP address are sent to all nodes in the cluster. This means that the cluster-side
switch must flood traffic to all ports that are connected to the members of the cluster.
Page 24 | Introduction
Internet Protocol (IP) Addressing and Protocols
Unicast mode
In unicast mode, all hosts in the cluster share a single unicast ‘cluster’ MAC address, to
go with the cluster IP address. This mode has the disadvantage that it stops cluster hosts
from using their own ‘burned-in’ MAC addresses, so hosts cannot contact each other
unless you install a second NIC card on each host and use that for intra-cluster
communication.
The cluster operation forces the switch to flood all packets that are destined for the
cluster, by stopping the switch from learning the cluster MAC address. The switch cannot
learn the cluster MAC address because it never appears in the source field of the Ethernet
headers of packets sent from the clustered servers.
Instead, each NIC uses a special unicast MAC address in the source field of the Ethernet
header. The cluster MAC address must never be found in the source field of the Ethernet
header, because otherwise the switch will learn the cluster MAC address, and stop
flooding packets to all ports, and only one node in the cluster will receive traffic for the
cluster's IP.
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1
2
Client Workstation
IP address: 172.16.0.40
3
MAC address: 00-00-54-1A-71-B3
AR
P ARP request - who has IP address 172.16.0.127?
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1 AR
2 P
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1
2
Client Workstation
3 FDB Table
Port MAC
1 02-01-AC-10-00-7F
2 02-02-AC-10-00-7F
3 02-03-AC-10-00-7F
ARP Table
IP MAC
172.16.0.127 02-BF-AC-10-00-7F
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1
2
Client Workstation
IP address: 172.16.0.40 3 FDB Table
MAC address: 00-00-54-1A-71-B3
Port MAC
1 02-01-AC-10-00-7F
IP 2 02-02-AC-10-00-7F
IP Packet 3 02-03-AC-10-00-7F
Clustered Servers
ver
IP Ser
1
2
IP
Client Workstation
IP address: 172.16.0.40 3 FDB Table
MAC address: 00-00-54-1A-71-B3
Port MAC
1 02-01-AC-10-00-7F
2 02-02-AC-10-00-7F
3 02-03-AC-10-00-7F
ARP Table
IP MAC
172.16.0.127 02-BF-AC-10-00-7F
Multicast mode
In multicast mode, hosts in the cluster use their real ‘burned-in’ MAC address in the
source field of the Ethernet header. However, they answer ARP requests for the cluster IP
address with a multicast MAC in the ARP packet's payload, while the Ethernet header on
the ARP reply still has the real MAC address. This allows cluster hosts to contact each
other.
In both multicast and unicast mode the mechanism to cause flooding is as such:
ARP requests for the cluster IP are answered with the virtual cluster MAC address in
the ARP packet's payload.
The node must send all packets, including ARP requests and replies, with a different
source MAC in the Ethernet header.
This prevents the switch from entering the virtual cluster MAC into the forwarding
database (FDB).
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1
2
Client Workstation
IP address: 172.16.0.40
3
MAC address: 00-00-54-1A-71-B3
AR
P ARP request - who has IP address 172.16.0.127?
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1 AR
2 P
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1
2
Client Workstation
3 FDB Table
Port MAC
1 02-01-AC-10-00-7F
2 02-02-AC-10-00-7F
3 02-03-AC-10-00-7F
ARP Table
IP MAC
172.16.0.127 01-00-11-22-33-44
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1
2
Client Workstation
IP address: 172.16.0.40 3 FDB Table
MAC address: 00-00-54-1A-71-B3
Port MAC
1 02-01-AC-10-00-7F
IP 2 02-02-AC-10-00-7F
IP Packet 3 02-03-AC-10-00-7F
Clustered Servers
ver
IP Ser
1
2
IP
Client Workstation
IP address: 172.16.0.40 3 FDB Table
MAC address: 00-00-54-1A-71-B3
Port MAC
1 02-01-AC-10-00-7F
2 02-02-AC-10-00-7F
3 02-03-AC-10-00-7F
ARP Table
IP MAC
172.16.0.127 01-00-11-22-33-44
This mode also causes the cluster to use its real ‘burned in’ MAC address in the source
field of the Ethernet header. The cluster will answer ARP requests for the cluster IP
address with a multicast MAC in the ARP packet's payload, while the Ethernet header on
the ARP reply still has the real MAC address. Note though, that the MAC address is
slightly different to the previously discussed multicast mode—the MAC address starts
with the bytes 01:00:5e, which still identifies it as an IP-multicast MAC address:
The Windows client will happily add this IP / MAC combination to its internal ARP table
(on a Windows or Linux PC, use the command arp-a to see all ARP entries). All IP traffic
destined for 172.16.0.127 is then sent with an Ethernet destination of 01:00:5e:7f:00:7f.
The cluster node responds with its burned in MAC in the Ethernet source field.
Microsoft's IGMP multicasting mode cleverly turns the concept of IGMP clients and hosts
on its head. As far as an Allied Telesis switch is concerned, the clustered servers are seen
as IGMP clients and the IGMP multicast data (stream) is sent by the workstations trying to
access the cluster. To ensure that the switches do correctly forward the multicast data, the
servers send IGMP reports for a group that corresponds to the MAC address they are
putting in their ARP responses. Reports are sent frequently by the NLB servers so there is
no concern about IGMP entries timing out on the switch.
The following diagrams illustrate multicast mode with the IGMP option selected:
Clustered Servers
Client Workstation
IP address: 172.16.0.40 3 IGMP snooping Table
MAC address: 00-00-54-1A-71-B3
Group Ports
AR 224.127.0.127 1, 2, 3
P ARP request - who has IP address (01-00-5F-7F-00-7F)
172.16.0.127?
Clustered Servers
ver
Ser
1 AR
2 P
Client Workstation
IP address: 172.16.0.40
MAC address: 00-00-54-1A-71-B3
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1
2
ARP Table
IP MAC
172.16.0.127 01-00-5E-7F-00-7F
Clustered Servers
ver
Ser
ver
Ser
ver
Ser
1
2
IP MAC
172.16.0.127 01-00-5E-7F-00-7F
Clustered Servers
ver
IP Ser
1
2
IP
Client Workstation
IP address: 172.16.0.40 3
IGMP snooping Table
MAC address: 00-00-54-1A-71-B3
Group Ports
224.127.0.127 1, 2, 3
(01-00-5F-7F-00-7F)
ARP Table
IP MAC
172.16.0.127 01-00-5E-7F-00-7F
In the purely Layer 2 environment, it is the client workstation that learns the ARP entry for
the cluster's virtual IP/virtual MAC, and then sends cluster-directed packets to the virtual
MAC. The Layer 2 switches in between then behave as described in the illustrations
above.
For a Layer 2 network, the requirements on the switches are simple. In fact, NLB has been
designed to make use of standard behaviors of Layer 2 switches. Therefore, in this
environment, the switches don't even need to be aware that NLB is being used in the
network.
Allied Telesis x-series switches, like almost all switches in the market, provide good
support for NLB when operating at Layer 2.
When the switches are operating at Layer 3, the situation is rather different. If the client
workstations are in one subnet, and the clustered servers are in another subnet, and a
switch in between is performing the Layer 3 routing between those subnets, then the
switch needs to be explicitly NLB-aware.
The key point is that the switch needs to learn the ARP entries for the Cluster's virtual IP
and Virtual MAC, and apply those ARP entries to multiple egress ports. It is not standard
for a switch to apply the same ARP entry to multiple ports, and, as will be discussed
below, each of the NLB modes required other non-standard behavior on the part of the
Layer 3 switch.
Unicast Mode
When a switch operating at Layer 3 sits in front of a set of clustered servers operating in
Unicast Mode, the ARP conversation is as below:
Clustered Servers
ver
AR
P Ser
AR ver
P Ser
1
2 AR
P
Subnet 2 ARP request - who has
Client Workstation
IP address: 192.168.54.23
MAC address: 00-00-54-1A-71-B3
Clustered Servers
ARP response: 172.16.0.127 is at HW address
02-BF-AC-10-00-7F Cluster virtual IP: 172.16.0.127
Cluster virtual MAC: 02-BF-AC-10-00-7F
Source MAC address: 02-01-AC-10-00-7F
Dest MAC address: 00-00-CD-12-34-56
Sender Hardware address: 02-BF-AC-10-00-7F
Sender IP address: 172.16.0.127 ver
Target HW address: 00-00-CD-12-34-56 Ser
Target IP address: 172.16.0.23 A RP
ver
Ser
AR
P ver
Ser
1 AR
2 P
Subnet 2
Subnet 1 3
Switch
IP address: 172.16.0.23
MAC address: 00-00-CD-12-34-56
Client Workstation
IP address: 192.168.54.23
MAC address: 00-00-54-1A-71-B3
The ARP responses in which the Sender MAC address does not match the Source MAC in
the Ethernet header is referred to as a Disparate ARP.
In Allied Telesis x-series switches, the default behavior upon receiving a Disparate ARP
response is:
An ARP entry is created, pointing to the IP/MAC address in the content of the ARP
packet, with the egress port being the port on which the ARP packet was received.
An FDB entry is created for the MAC address in the content of the ARP packet,
associated with the port on which the ARP was received. This is despite the fact that
the MAC address in question was not the source MAC in the Ethernet header of the
ARP packet. This FDB entry is not created by normal MAC learning, but is specifically
created when the ARP entry is created, so that the hardware forwarding process (which
uses the FDB as the way to find the egress port) works correctly.
The problem, though, is that the ARP entry (and FDB entry) is only ever associated with
one egress port. So, rather than associating itself with multiple egress ports, it will jump
from port to port as the replies from multiple servers arrive in quick succession. This fails
to provide the behavior that the cluster requires—whereby packets destined to the cluster
are sent to all cluster members at once.
So, AlliedWare Plus provides a specific, NLB-friendly, mode of dealing with Disparate ARP
responses. In this mode, the behavior upon receiving a disparate ARP response is:
An ARP entry is created, pointing to the IP/MAC address in the content of the ARP
packet, with no specific egress port - the 'egress port' is set to ‘flood', which means
that packets matching this ARP entry are flooded to all ports in the egress VLAN.
ATX8106M2#show arp
IP Address MAC Address Interface Port Type
192.168.200.34 001a.a004.25ef vlan200 flood dynamic
172.21.0.3 02bf.ac15.0005 vlan40 flood dynamic
172.21.0.4 02bf.ac15.0005 vlan40 flood dynamic
No FDB entry is created for the MAC address in the content of the ARP packet. This
ensures that packets destined to this MAC address are flooded to all ports of the VLAN.
This mode is configured by the command arp-mac-disparity unicast on the VLAN that
faces the clustered servers.
For example:
con t
int vlan10
arp-mac-disparity unicast
Multicast Mode
In multicast mode, not only is the ARP response from the clustered servers disparate (i.e.
the source MAC on the Ethernet header differs from the sender MAC within the ARP
packet content) it also has the unusual property that the sender IP address in the packet is
unicast, but the sender MAC address is multicast.
By default, x-series switches simply drop such ARP responses, deeming a multicast
sender MAC to be invalid.
However, the command arp-mac-disparity multicast, entered on the VLAN that faces
the clustered servers, puts the switch into a mode whereby it will accept such ARP
responses, and upon receiving them will do the same as it does when receiving unicast
disparate ARPs when arp-mac-disparity unicast has been configured. That is, an ARP
entry is created for the IP/MAC in the content of the ARP packet, but with the egress port
set to ‘flood’, and no FDB entry is created for the MAC address.
As a result, packets destined to the IP address in question are flooded to the destination
VLAN.
This behavior makes no distinction between clusters operating in Multicast mode and
those operating in multicast mode with the IGMP option. The fact that a cluster is sending
IGMP reports to the switch does not make any difference, it still floods the packets to all
ports in the egress VLAN.
In both cases, when the ARP entries are learnt, they appear in the output of the command
show arp as:
ATX8106M2#show arp
IP Address MAC Address Interface Port Type
10.100.0.50 03bf.0a64.0032 vlan200 flood dynamic
10.100.0.56 0100.5e7f.0013 vlan200 flood dynamic
10.100.0.75 03bf.0a64.0044 vlan200 flood dynamic
10.100.0.76 03bf.0a64.0032 vlan200 flood dynamic
10.100.0.60 0100.5e7f.0013 vlan200 flood dynamic
It is also possible to create static ARP entries with multicast destination MAC, and
multiple egress ports, with the arp command:
In this case, an ARP entry is created for the IP/MAC in question, associated with all the
egress ports specified in the command. At Layer 2 a special hardware forwarding entry is
created, that associates the MAC address with the set of egress ports. So, packets
destined to the IP/MAC in question are forwarded just to the egress ports specified in the
command, and are not flooded to the whole egress VLAN.
C613-22007-00 REV D
NETWORK SMARTER
North America Headquarters | 19800 North Creek Parkway | Suite 100 | Bothell | WA 98011 | USA | T: +1 800 424 4284 | F: +1 425 481 3895
Asia-Pacific Headquarters | 11 Tai Seng Link | Singapore | 534182 | T: +65 6383 3832 | F: +65 6383 3830
EMEA & CSA Operations | Incheonweg 7 | 1437 EK Rozenburg | The Netherlands | T: +31 20 7950020 | F: +31 20 7950021
alliedtelesis.com
© 2015 Allied Telesis, Inc. All rights reserved. Information in this document is subject to change without notice. All company names, logos, and product designs that are trademarks or registered trademarks are the property of their respective owners.