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;
}
}

With a new week came new challenges. Since I passed my JNCIA-ER test a couple of weeks ago someone decided I must be an expert and asked me to work on configuring some switches for a company that decided to go with Juniper for the network in their brand new office but have no one on staff with any experience…. Joy

Yesterday I got to unbox the equipment and take inventory of what we have and it basically breaks down to 5 EX4200 and 2 EX4500 with miscellaneous accessories (redundant power supplies and the like). Given their current environment and goals for the project here’s the general idea.

With an MDF and IDF they still want to manage the EX4200s as a single chassis so the 5th switch will have to be connected by 10Gb links setup as VCE links. Connections to the EX4500s is going to be 2x10Gb uplinks configured as an LACP link to provide some load balancing and redundancy, there will also be a 2x10Gb link between the 4500s.

Configuration process.
I want to be able to define which switch of the 4200s is going to be the Master and which is going to be the backup which means preconfiguring the master switch before powering on any of the others once the VCP cables are connected.

SW1:
The first thing you have to do is set a root password so we’ll do that and setup some other basics and save a rescue configuration (mostly just to turn off the alarm light).

Unless I’m doing more than a handful of commands at a certain hierarchy I tend to run most commands at the top level which I think also helps me to remember which level things are configured.

Sw1# set system root-authentication plain-text-password
New password:

Sw1# set system services ssh
Sw1# set system services web-management http (will be changed to https or disabled when the hardware is installed)
Sw1# set chassis alarm management-ethernet link-down ignore (again, just to turn off the alarm light)
Sw1# set vlans VLAN1 vlan-id 1 description 10.1.0.0 l3-interface vlan.1
Sw1# set interfaces vlan.1 family inet address 10.1.0.1/24
Sw1# exit

Sw1> request system configuration rescue save


Now we have a very basic configuration it’s time to start configuring the virtual chassis options. Since I want to define which members of the chassis are going to be master and backup REs I need to gather the serial numbers for all the switches.

Sw1# set virtual-chassis preprovisioned
Sw1# set virtual-chassis member 0 role routing-engine serial-number xxxxxxxx00
Sw1# set virtual-chassis member 1 role routing-engine serial-number xxxxxxxx01
Sw1# set virtual-chassis member 2 serial-number xxxxxxxx02
Sw1# set virtual-chassis member 3 serial-number xxxxxxxx03
Sw1# set virtual-chassis member 4 serial-number xxxxxxxx04

At this point we can power on the other switches making up the VC and make sure everything comes up and joins the chassis as expected then get back to some supporting commands.

Sw1# set system commit synchronize (to made sure any config commits are copied to other REs)

Sw1# set chassis redundancy graceful-switchover (speedier L2 failover)
Sw1# set routing-options graceful-restart (speedier L3 failover)

On the switches connected to the VCE link we need to run an extra operational mode command to turn their uplink ports into VCE ports:

Sw1> request virtual-chassis vc-port set pic-slot 1 port 0
Sw4> request virtual-chassis vc-port set pic-slot 1 port 2
SW5> request virtual-chassis vc-port set pic-slot 1 port 0
Sw5> request virtual-chassis vc-port set pic-slot 1 port 2


And that’s really all it takes to get a virtual-chassis up and running. Once I’ve configured the links between the chassis and the EX4500s I will post some of that configuration as well.

As of 10:41am Saturday March 20th 2010,  I am CCENT certified and officially on the Cisco certification track…. scary… I’ve taken a couple of weeks off hard studying but now it’s time to get back at it and finish the CCNA so I can move up to either JNCIA-EX or CCNP.

Having passed the ICND1 test I can finally start using the lab equipment i’ve been collecting for the last month or so – ICND1 material is a good start to get a grasp of the technologies on a small network but it always stopped short of the interesting material – a lot of chapters in the Cisco press book end with “… is beyond the scope of this book – see ICND2 for more information”.  Since i’m using a combination of Jeremy Cioara’s CBT Nuggets videos and the Cisco Press book I decided to build a lab similar to what they are demonstrating and here it is:

The cloud in this case is the “lab” VLAN on my home network (10.10.10.0/24) so I will eventually be able to configure NAT on R2 for the 192.168.200.0/24 network but for now it just sits out there looking all cloudy.  What isn’t shown in the picture is the 2509 Access Server (also connected to the 10.10.10.0/24 network) that means I can connect from work and work on the lab should the urge arise.

Goals I have for the lab include getting another switch to be able to do more with STP and VTP and possibly adding an 830 series router off of R5.  I also want to add a PC/server to the network so i can do config archiving since things change frequently and I rarely remember to pull a config before i start messing with it.  As it stands now I have VTP and STP running on the switches with one being a VTP server and the other configured as a client.  I have OSPF (3 areas) running on R1 (area 1), R2 (area 0), R3 (area 0) and R4 (area 2) with R5 running EIGRP and R4 redistributing routes between the two protocols.  Im not sure if it’s a CCNA level technology but I will probably setup VRRP or HSRP on R3 and R5 for redundancy to R4.  Once I start getting into the details of the configuration of STP, routing, etc.. I will upload more complete diagrams with configuration specific information and maybe device configs but as it stands now, that’s the lab.