Following on from the previous post about the VC configuration, this post is a quick and dirty look at link aggregation in JunOS. For such a flat network there wasn’t really much to consider with spanning tree other than making sure the right switch became the root and that the redundant path was used when necessary so there isn’t much to write about leaving more time for LACP.
We’ll start at the beginning with the configuration of ports for LACP between the three switches to make use of as many of those fancy 10G ports as we can. Since it’s exactly the same network as the previous post, it will look exactly the same.
Similar to Cisco port channel interfaces, JunOS allows each aggregated interface to have a total of 8 member links and the EX4200 virtual chassis allows for a maximum of 128 aggregated interfaces. I’m not going to get anywhere near the limits with what I’m doing here but it’s good to know what you can do.
I think the virtual chassis will be a good place to start and I’m looking forward to trying out LACP across different member switches and the first configuration change we need to make is to define how many logical devices we are going to need:
[edit chassis]
aggregated-devices {
ethernet {
device-count 2;
}
}
Once you have defined the number of logical interfaces you are going to be using you can add the physical ports to them at the interface level configuration. To add interfaces to a LACP group you simply need to add the logical interface number that it will be a part of (as with all things JunOS, the counting starts at 0). One thing to remember when adding a port to an LACP group is to remove the unit configuration from that port or your config will fail to commit. Once added to an LACP group all unit level commands are configured on the aggregated interface.
[edit interfaces]
xe-0/1/2 {
ether-options {
802.3ad ae0;
}xe-1/1/0 {
ether-options {
802.3ad ae1;
}
}
Now we have 2 interfaces as members on the aggregated link we can configure some options there.
[edit interfaces}
ae0 {
aggregated-ether-options {
minimum-links 1;
link-speed 10g;
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members all;
}
}
}
}
For anyone that has worked on aggregated links on Cisco devices everything here should be pretty obvious but I'll explain the commands and my reasons for using them. There's nothing ground breaking here
minimum links - This defines how many member links need to be available for the aggregated link to be "up". This is a useful configuration option when you're using redundant links on a larger network and want to make sure you have the necessary bandwidth available throughout the entire flow of traffic. Here we wont be gaining much by failing over to a secondary path if one of the two member links fail.
link-speed 10g - Here we define the speed that the individual member links will be operating it, in this case it wouldnt be a problem to omit this command but connecting a 1000 switch to a 10/100 switch would require you to set this to "link-speed 100".
lacp { active } - The LACP protocol requires a link to be either active or passive for the link to come up. Active links initiate the LACP link and passive links respond to LACP packets so you will need to consider this when configuring both sides of the link.
Once you have configured the aggregated link portion of the interface you can move to the unit configuration just as you would with any other interface and since these links are connecting switches they will be trunk links passing traffic for all vlans.
For the other side of the link you will repeat the same configuration and should see the links come up shortly after commiting the changes.
To confirm that a member link is configured to be part of a correct aggreagated link you can use the command
> show interfaces terse | match ae
To verify that the LACP links are operating correctly you can use the command:
> show lacp interfaces
For further verification you can use LLDP to see the links!
>show lldp neighbors
From the outputs you can see that I have configured LACP to span the virtual chassis and have no two links on the same chassis member, this means that the LACP link will survive if any one of the chassis members fail. Tell me if I'm wrong but I think that's pretty cool.
Finally, the all powerful "traceoptions" can be configured to log/show LACP events for debugging purposes. One thing that may not be obvious is where you need to configure the traceoptions, after a few minutes of poking arounf the configuration I found that they need to be set under the protocols lacp hierarchy.
[edit protocols]
lacp {
traceoptions {
file lacp.log;
flag all;
}
}
