Link Aggregation (LAG)Aggregate Ethernet (AE)Link Aggregation Control Protocol (LACP)
There are a couple of advantages to using LAG over a single physical interface.
One advantage is the survivability of the point-to-point link or trunk. If one of the physical interfaces or paths supporting an Aggregate Ethernet (AE) interface is lost the interface will survive (assuming that the AE interface has multiple physical interfaces associated).
Another advantage of an AE is to provided additional bandwidth over a single interface. An EX4300 can support up to a maximum of 16 physical interfaces in a LAG and up to 112 total LAG's per Virtual Chassis (VC).
Configuring LAG is really very simple but first let me discuss some of the guidelines before jumping into actual configuration:
- LAG must be configured on both sides of the link
- The interface speed must be the same on both sides of the link
- Firewall filters can be applied to AE/LAG interfaces
- When utilizing VC different Line Cards/member interfaces can be used to create the LAG bundle
Link Aggregation Control Protocol (LACP) is used to detect and report configuration errors between the LAG endpoints.
- Link Aggregation Control Protocol (LACP) can be configured for link protection and negotiation
- If LACP is not enabled on a LAG bundle the AE could attempt to send all packets to a single remote interface in the LAG.
- IF LACP is enables the remote end must be configured for LACP as well
- LACP can be implemented as active or passive but at least one endpoint must be active
- LACP can utilize slow or fast timers.
Now that we have some of the details lets press on with the configuration.
You'll notice in the diagram that there are two physical interfaces ge-0/0/0 and ge-0/0/2, between ACCESS-1 and AGG-1 that will be used to create our AE interface. Remember that we can have up to 16 physical interfaces in an AE on EX4300 and up to 112 total AE's per VC.
Now lets jump onto the ACCESS-1 switch and configure the LAG Bundle or AE0.
ACCESS-1:
First, tell the device how many AE interfaces will be instantiated on the device.
NOTE: This is the total AE interfaces being utilized on the device.
junspace@ACCESS-1# set chassis aggregated-devices ethernet device-count 1
junspace@ACCESS-1# delete interfaces ge-0/0/0 unit 0
junspace@ACCESS-1# delete interfaces ge-0/0/2 unit 0
NOTE: logical units cannot be assigned to physical interfaces when assigned to an AE.
Configure the physical interface ether-options for 802.3ad and assign it to the logical AE interface.
junspace@ACCESS-1# set interfaces ge-0/0/0 ether-options 802.3ad ae0
junspace@ACCESS-1# set interfaces ge-0/0/2 ether-options 802.3ad ae0
Since the AE interface is a trunk we need to configure it as such.
junspace@ACCESS-1# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk vlan members all
Now we can commit this and take a look at the interfaces:
junspace@ACCESS-1# run show interfaces terse | match ae0
ge-0/0/0.0 up up aenet --> ae0.0
ge-0/0/2.0 up up aenet --> ae0.0
ae0 up up
ae0.0 up up eth-switch
Before we jump to the AGG-1 switch let's configure LACP on the AE interfaces as well.
junspace@ACCESS-1# set interfaces ae0 aggregated-ether-options lacp active
junspace@ACCESS-1# set interfaces ae0 aggregated-ether-options minimum-links 1
NOTE: the minimum-links 1 knob can be used to make sure that the bandwidth is sufficient at all times. If for example you had 8 physical ge interfaces in a single link and you always wanted to have at least 4 gig available then you would set the minimum-links to 4. For this example we are only using two physical links so I am setting it to 1.
Now commit the configuration and move on to AGG-1.
AGG-1:
junspace@AGG-1# set chassis aggregated-devices ethernet device-count 1
junspace@AGG-1# delete interfaces ge-0/0/0
junspace@AGG-1# set interfaces ge-0/0/0 ether-options 802.3ad ae0
junspace@AGG-1# delete interfaces ge-0/0/2
junspace@AGG-1# set interfaces ge-0/0/2 ether-options 802.3ad ae0
junspace@AGG-1# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk vlan members V100
junspace@AGG-1# set interfaces ae0 aggregated-ether-options minimum-links 1
junspace@AGG-1# set interfaces ae0 aggregated-ether-options lacp active
junspace@AGG-1# commit
configuration check succeeds
commit complete
junspace@AGG-1# run show interfaces terse | match ae0
ge-0/0/0.0 up up aenet --> ae0.0
ge-0/0/2.0 up up aenet --> ae0.0
ae0 up up
ae0.0 up up eth-switch
LACP CHECK:
Now let's check LACP over the AE interface.
junspace@AGG-1# run show lacp statistics interfaces ae0
Aggregated interface: ae0
LACP Statistics: LACP Rx LACP Tx Unknown Rx Illegal Rx
ge-0/0/0 9932 9966 0 0
ge-0/0/2 9932 9966 0 0
junspace@AGG-1# run show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/0 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing
So there are a few things in this output that should be discussed. First, the LACP State table shows our two physical interfaces listed as actor and partner. Next we see Timeout is Fast and that they are both active. In the LACP Protocol table we see that mux state is distributing, and the periodic rate is fast. This periodic rate can be set to slow (every 30 seconds) but this can cause issues with other vendors and its best practice to leave the periodic rate to fast.
We can also see the LACP interaction across the physical links utilizing the monitor traffic command:
junspace@AGG-1# run monitor traffic interface ge-0/0/0 no-resolve detail
Address resolution is OFF.
Listening on ge-0/0/0, capture size 1514 bytes
22:21:42.651691 Out LACPv1, length 110
Actor Information TLV (0x01), length 20
System cc:e1:7f:8f:7a:c0, System Priority 127, Key 1, Port 1, Port Priority 127
State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]
Partner Information TLV (0x02), length 20
System 78:fe:3d:e4:01:80, System Priority 127, Key 1, Port 1, Port Priority 127
State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]
Collector Information TLV (0x03), length 16
Max Delay 0
Terminator TLV (0x00), length 0
22:21:43.120588 In LACPv1, length 110
Actor Information TLV (0x01), length 20
System 78:fe:3d:e4:01:80, System Priority 127, Key 1, Port 1, Port Priority 127
State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]
Partner Information TLV (0x02), length 20
System cc:e1:7f:8f:7a:c0, System Priority 127, Key 1, Port 1, Port Priority 127
State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]
Collector Information TLV (0x03), length 16
Max Delay 0
Terminator TLV (0x00), length 0
22:21:43.653671 Out LACPv1, length 110
Actor Information TLV (0x01), length 20
System cc:e1:7f:8f:7a:c0, System Priority 127, Key 1, Port 1, Port Priority 127
State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]
Partner Information TLV (0x02), length 20
System 78:fe:3d:e4:01:80, System Priority 127, Key 1, Port 1, Port Priority 127
State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]
Collector Information TLV (0x03), length 16
Max Delay 0
Terminator TLV (0x00), length 0
MAXIMUM-LINKS CHECK:
Now that we have an operational LAG Bundle using ge-0/0/0 and ge-0/0/2 across ae0.0 let's make sure I can ping the host hanging off of ACCESS-1.
junspace@AGG-1# run ping 172.16.100.2 routing-instance VIN
PING 172.16.100.2 (172.16.100.2): 56 data bytes
64 bytes from 172.16.100.2: icmp_seq=0 ttl=64 time=3.101 ms
64 bytes from 172.16.100.2: icmp_seq=1 ttl=64 time=2.417 ms
64 bytes from 172.16.100.2: icmp_seq=2 ttl=64 time=2.282 ms
^C
--- 172.16.100.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.282/2.600/3.101/0.359 ms
NOTE: I referenced a routing-instance here as my vlan.100 interface was used in a previous lab configuration where i have routing-instances supporting PIM.
Now let me disable one of the physical interfaces supporting the LAG bundle and check again.
junspace@AGG-1# set interfaces ge-0/0/2 disable
{master:0}[edit]
junspace@AGG-1# commit
configuration check succeeds
commit complete
{master:0}[edit]
junspace@AGG-1# run show interfaces terse | match ae0
ge-0/0/0.0 up up aenet --> ae0.0
ge-0/0/2.0 up down aenet --> ae0.0
ae0 up up
ae0.0 up up eth-switch
{master:0}[edit]
junspace@AGG-1# run ping 172.16.100.2 routing-instance VIN
PING 172.16.100.2 (172.16.100.2): 56 data bytes
64 bytes from 172.16.100.2: icmp_seq=0 ttl=64 time=4.100 ms
64 bytes from 172.16.100.2: icmp_seq=1 ttl=64 time=3.452 ms
^C
--- 172.16.100.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.452/3.776/4.100/0.324 ms
{master:0}[edit]
junspace@AGG-1# run show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No Yes No No No Yes Fast Active
ge-0/0/2 Partner No Yes No No No Yes Fast Passive
LACP protocol: Receive State Transmit State Mux State
ge-0/0/0 Current Fast periodic Collecting distributing
ge-0/0/2 Port disabled No periodic Detached
OK so several things here. First I disabled the ge-0/0/2 interface simulating a link break or optic issue (and then committed). Next I checked the interfaces supporting ae0 and see that ge-0/0/2 is indeed down but that ae0.0 is still up. Then I issued a ping to the host over the LAG and it still works! (Because we have multiple interfaces supporting the logical AE interface).
Then I checked LACP which has discovered that the ge-0/0/2 interfaces is disabled and is no longer distributing or collecting across that interface.
SUMMARY:
Pretty simple and easy to utilize Aggregate Ethernet across a LAN/CAN or WAN to improve the bandwidth available and survivability of connections where required. Just remember to set the chassis aggregated-devices to the number you need and supported on the device and you will be good to go.
No comments:
Post a Comment