Lag configuration question

[Stephen_McGuire]

I have an S4 (main campus) with a lag on one end and I have three stacked B5's (remote campus) on the other. They are connected via 1 mile long fiber.

Complaint from end user's has been poor internet speeds at the remote campus. They are on a VLAN and come back via the fiber to go out through our internet provider.

I just started this job and am new to the extreme EOS though I just finished the bootcamp and passed the switching and routing exam.

I started to just look at the VLAN performance and noted it was terrible and I'm on main campus side. I'm trying to document the existing switching design etc. So I began to dig into how things are connected L1/L2.

I did notice though that I have two ports on the S4 setup as a LAG to the stacked B5's but on the stacked B5's there are NO LAGs configured. Globally LACP is enabled on both ends but the stack hasn't been configured with a lag.

So first question is, how does this even work? I thought that you had to have both ends configured properly for the LAG to work. I know they can form automatically due to the global setting but I can't find anything on the B5's to indicate that has occurred.

Should I go ahead and setup the lag properly on each end with aadminkey's which one side appears to have already?

Port status shows the ports on the remote end to both be UP, all of the lag's appear as down this is the same as the main campus.

So it looks to me that the lag's are not configured and up properly and that neither end is setup.

Sorry for the long story but wanted to get some feed back on the situation. 🙂

Thoughts and suggestions are appreciated!
-Stephen

[Stephen_McGuire]

Excellent, our S4 only has two slots occupied plus we're nearly full so finding ports will be tough. However the B5's won't be an issue to spread them around.

Great stuff thanks!

-Stephen

[Erik_Auerswald]

Hi Stephen,

splitting the LAG links across the stack adds redundancy against one stack member failing, e.g. because of a defective PSU. This is similar to splitting LAG members across different modules in a chassis based switch.

Br,
Erik

[Stephen_McGuire]

Hello Erik, that's a really good consideration, something that made me think about what value that has and if it would really benefit us. Without getting to deep in the details, I think the value of the 3gb pipe vs. the redundancy of the one E1 switch isn't sufficient enough to warrant keeping that connection. The density of the office/classroom space has decreased to the point where we may be able to move most connections to the B5 stack and start removing some of the E1's. We rely more and more on WiFi and the fe.*.* ports are just not even in use or have patch cords available in the spaces they occupy. But I like the way you think!

Assuming we go with the 3 connections as ONE lag for 3gb, is there any value is splitting them across the stack? 1st in #1, 2nd in #2 and 3rd in #3? I thought it was mentioned as a best practice in my EOS bootcamp but my memory is fuzzy.

Thoughts?

-Stephen

[Erik_Auerswald]

Hi Stephen,

if you keep the direct connection between S4 and E1, you can reboot the B5 stack without losing connectivity to the remote campus. As such I would rather recommend to just add a new fiber link to the B5 stack, but keep the E1 connections.

I would recommend to enable CiscoDP and LLDP on the E1, or disable it on the respective S4 and B5 ports connecting to the E1.

According to an E1 manual for FW 3.07.xx the E1 supports CiscoDP, but not LLDP. So you should disable LLDP on the S4/B5 Ports connecting to the E1, and enable CiscoDP on the E1.

Thanks,
Erik