White Paper

Technical white paper | HPN SDN Controller Link Discovery

When the controller is configured for hybrid.mode=true, the controller installs a flow rule on every OpenFlow instance to

steal these packets:

Packets which match this flow rule are forwarded to the controller from the OpenFlow instance and port where they were

received. Using the origin information contained within the received packet, the controller derives the source and destination

of the link that this packet traversed and records a link between the OpenFlow instances. The link type is derived from the

destination MAC address of the packet (direct or multi-hop). If a link is direct, it will be discovered as both “direct” and “multi-

hop” from the reporting OpenFlow instance, but the type of “direct” has precedence over the type of “multi-hop”, so the link

is recorded as “direct”.

Keys to Correct Link Discovery

In order to ensure that the desired link topology is correctly discovered, configure the switches such that all OpenFlow

instances are configured for the same vlan mapping throughout the topology AND one of the following conditions are met:

• The link discovery packet is correctly tagged by the OpenFlow instance when it egresses the port to which it is injected.

• The untagged link discovery packet is stolen to the controller by the correct OpenFlow instance agent on a switch when it

is received.

Though the HPN SDN Controller link discovery method works well in many network configurations, there are some

situations where links are not discovered as intended. This may include missing links, links with an incorrect type, or

discovering a link where one should not exist. If the untagged discovery packets can’t be associated with the correct

OpenFlow instance on the destination switch, then the discovery packet will be dropped or associated with the wrong

OpenFlow instance. This can occur for reasons explained in the following sections, including ambiguous vlan association

across all OpenFlow instances in the topology.

The consequences of link discovery problems will be observed as impacts to other functionality, such as node discovery or

topology calculation. For instance, a missing link in the middle of the network may cause a node’s location to bounce from

the edge of the network to the middle of the network.

Known issues

All known link discovery problems relate to one of the following situations:

• The received link discovery packet is dropped by a switch in the network, because the packet is untagged and received on

a tagged-only port.

• The received link discovery packet is associated with the wrong OpenFlow instance, because the packet is untagged and

received on a port which associates untagged packets with a vlan not in the OpenFlow instance. Another manifestation of

this situation occurs when the OpenFlow instance configurations across all switches are not configured with the same

vlan set and a discovery packet gets associated with only one OpenFlow instance (see switch C in the example below).

Vendors follow various interpretations in their association of vlans to OpenFlow instances. Various implementations allow a

single vlan per OpenFlow instance, multiple vlans per OpenFlow instance, or all vlans in a single OpenFlow instance. Thus

when the controller injects an untagged packet into an OpenFlow instance, the vlan association for the packet is sometime

ambiguous in the OpenFlow instance.