Active DACs vs Passive DACs vs Optics

I’ve had a couple of customers recently ask me about DACs and which one to use in different scenarios.

A passive copper Direct Attach Cable is a large gauge copper wire that doesn’t need to be powered.  It’s basically like running an plain copper cable over a short span.

An active copper Direct Attach Cable is a smaller gauge (read: thinner) that draws power from the switches or routers that it’s plugged into.  This allows it to ‘boost’ the signal to allow for less loss over longer spans.

And of course, there’s optics or SFP/SFP+/QSFP+.  These can allow you to go much, much further, but at a significantly higher cost.

Avaya gear (and several other manufacturers) are not specific about which DACs they will support.  This means it doesn’t matter whether you use a Passive or an Active as long as you’re within the constraints of the DAC itself.

A good rule of thumb is to use Passive DACs (SFP, SFP+, or QSFP+) over spans up to 10 meters.  From 10 meters to around 20 meters, you will want to use Active DACs, especially when doing 40 gigabit.  Anything larger than 20 meters, it’s a good idea to switch to optics. has a great article for anyone wanting more specifics, found HERE.  There’s a very good quick reference image located there that I keep on hand to remember the links.  It’s a bit of an old article, and at the time of writing, DACs were a bit expensive.  Now that they are more commonplace, they can be had at a fraction of the cost of a SFP+ or QSFP+ optic pair.

Avaya Fabric Attach Standalone-Proxy Sample Config

Here is a sample configuration for Fabric Attach using standalone-proxy mode.  4 VLANs have been created in Avaya Wireless Orchestration System (32 – Data, 160 – Students, 176 – Staff, 192 – Guest).  This configuration should work on ERS4800 and ERS5900.  The samples were prepared on a ERS4850.

ERS SW Version:

Identity Engines Ignition Server Version: 9.2.4

In order for the switch to authenticate devices on interfaces, EAP must be configured on the interfaces.  When a device is plugged into an interface, the switch must do MAC authentication (NEAP).  The MAC will be sent to Identity Engines, where it will be authenticated.  Identity Engines then tells the switch what VLANs to put on the port.  If the VLANs are not created, it will create the VLANs and put them on the designated trunk port or ports. Here is a sample EAPOL configuration for Fabric Attach:

eapol multihost allow-non-eap-enable
eapol multihost radius-non-eap-enable
eapol multihost auto-non-eap-mhsa-enable
eapol multihost use-radius-assigned-vlan
eapol multihost non-eap-use-radius-assigned-vlan
eapol multihost multivlan enable
interface Ethernet ALL
eapol multihost port 2-24 enable eap-mac-max 2 allow-non-eap-enable non-eap-mac-max 2 radius-non-eap-enable auto-non-eap-mhsa-enable use-radius-assigned-vlan non-eap-use-radius-assigned-vlan mac-max 2 mhsa-no-limit
no eapol multihost non-eap-pwd-fmt ip-addr
no eapol multihost non-eap-pwd-fmt port-number
interface Ethernet ALL
eapol port 2-24 status auto
eapol multihost fail-open-vlan vid 1
eapol multihost fail-open-vlan enable
eapol multihost fail-open-vlan continuity-mode enable

This configuration will configure all interfaces, except the uplink port of 1, to be EAPOL authenticated.  If there is a failure to communicate with Identity Engines, or a device fails to authenticate, it will automatically be dropped into VLAN 1 (eapol multihost fail-open-vlan vid 1).

This configuration allows the switch to continue to be used for 802.1x using a Windows supplicant while retaining the ability to do Fabric Attach for APs.

A sample configuration for Fabric Attach on the switch:

fa standalone-proxy
fa uplink port 1
fa zero-touch-option auto-port-mode-fa-client

This configures the switch to use standalone proxy mode for Fabric Attach. If you have a VSP switch upstream, you can configure as a proxy, instead. For the purpose of this document, standalone proxy mode will be used.
The uplink port is defined as port 1 in the example, but can be defined as any port or trunk. The switch will automatically configure Fabric Attach enabled VLANs as tagged on uplink ports.
Identity Engines should be configured to allow MAC authentication from the switch or switches.


Radius outbound policies should be created to return VLAN and Fabric Attach information to the switch.

Create an outbound attribute to tell the switch to create VLANs that don’t exist.


Create an outbound attribute to pass back the PVID of an interface.


Finally, create an outbound attribute to pass back VLANs and ISIDs to the switch.


Next, configure outbound values for these attributes in order to tell the switch which VLANs to apply to the ports for authenticated devices.  In the example, we create the PVID of 32 for the untagged management VLAN and VLANs 160, 176, and 192 are to be tagged.  Only VLAN 160 is shown here for brevity.


outbound-v-mgmt outbound-v-pvidoutbound-v-160

When not using a fabric-enabled switch, the ISID should be returned as 0. A value of FA-VLAN-ISID for vlan 176, would be 176:0.
A policy can now be created to pass these values back for a device contained within a group in Identity Engines.


As long as a device’s MAC address exists in the group “IgnitionTemplate-Fabric-Attach-Client-AP9100-Grp”, the identified values will be passed back.

Upon receiving the outbound values, the switch will automatically create the required VLANs, add them to the identified trunk, and add them to the port that is being authenticated.  PVID value will be created as an untaggedpvid, and the remaining ISID values will be created as tagged VLANs.