Port Channel

[nst1]

I have several switch models for example MS25, MS425, MS250 and MS120

How can I configure port channel in each of them?

[Chris_M]

Meraki has a pretty good documentation library. The specific topic that you are asking for is here: https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Ports#Link_Aggregation

Enjoy!

[TimBisel]

This is petty, I know, buuuuut technically you can't.

Port (Ether) Channel is Cisco Proprietary.

Link Aggregation is open.

Meraki uses LACP (Link Aggregation)

Not really a big deal but if you are connecting to a non Meraki switch, just make sure you are using "Active" or "Passive" when configuring the other side of the bundle on the non-Meraki. if you use "on", "Auto" or "Desirable" it wont work.

[KirkMcCurdy]

I'm interested in how this went for you.  We just replaced our old core (Catalyst 4506) with a stack of MS250-48's.

Unfortunately, we identified the whole port-channel/channel-group Active/Passive instead of on/auto too late and our series of banks went down.  We went ahead and pulled one of the cables in the channel group thus temporarily solving the errors and issues.

Having provided all of that information, our intent is to re-configure the channel group configurations on the older Catalyst 2960's that we have at our banks.  So, just looking for an idea as to how anyone's situation went.  Were you successful in re-establishing the channel-group or did you have to scuttle that configuration and ultimately upgrade the various network gear downstream?

Any thoughts would be greatly appreciated!  Thanks!

[TerryMC]

I also like to here how this worked out. I'm setting up MS350 with dual ethernet fiber connections to Nexus core using port channel. I have the port channel and two fiber channels setup as trunk ports. I'm using a SVI on the Meraki and Nexus core for routing. I used channel-group 112 mode active to add the ethernet ports to channel group. It works, but not sure this is the best way to handle it. I'm having problems with Meraki pulling a Management IP address. I'm use to using layer 3 port channel groups.  I tried using a layer 3 port channel, but couldn't get it working. I like to know how you configured the ethernet ports and port channels. Also, are you using native Vlan 1, or Vlan number of the main SVI you created for uplink? Just trying to figure out best way to handle port channel group setup. 

[KirkMcCurdy]

An update to this...we had to wipe out the entire Port-Channel configuration...and leave it that way. The various down stream switches kept breaking and tossing all kinds of odd errors. Ultimately, we have decided to NOT re-implement port-channeling.

Fortunately for us, we will be replacing all of our old gear with Meraki gear and then we will set up aggregation...some others may not be so lucky. From what I've been able to surmise, through all of my research, is it is very hit or miss and depends greatly upon the type of hardware you are working with, IOS version and version of various operating system(s) of the network gear that is NOT Cisco.

I'll have more to include later as we are going to TRY and do this with another vendor and an Arris/Ruckus 7250...more to follow.

[TerryMC]

I got it working today. I had to create a second Layer 3 vlans on the Core switch and add a helper address. I added the same vlan to Meraki Management IP configuration and it passed the DHCP request through it. My aggregated ports through port-channel is working with Ethernet trunk ports, port-channel trunk ports and layer 3 vlans. I sent the configuration to Meraki to view and get some feedback on. I will reply if they can provide some useful info, or better way to handle it. I had to set the Ethernet ports to channel-group ### mode active. 

[its_Tricky83]

Hey @TerryMC , did you ever hear back from Meraki after sending the configuration to them to view and get feedback on? 

[TerryMC]

Hi Tricky83,

Yes, Meraki and Cisco both confirmed the configuration was good. In fact, they documented our configuration to help with future support cases and designing. Sounds like my reply helped you figure it out? Let me know if you need more details about the config. I'm happy to post an example of what it looks like. I was able to get OSPF routing, DHCP relay, multicast, and port aggregation to work using the same configuration. Multicast was a monster to figure out, but we got it working. 

[lcaruso]

If you would, please post the config. Thanks much.

[its_Tricky83]

Thanks TerryMC,

I haven't delved too far, but my initial attempts to do a two port aggregation between Meraki with Catalyst switches hasn't been successful. 

This switch has never made contact with the Meraki cloud to gather it's initial config, so I'm wondering if it has something to do with that.. I'm thinking I should just attempt to trunk one port first (without aggregation) to at least get it communicating with Meraki cloud platform, and then work on getting the port aggregation working.

Would you be so kind as to post your config changes to get it working for you? I'm very new to Catalyst and CISCO IOS stuff.

[BBagley]

Any chance you can post some examples of the config solution?  

I've been trying to resolve this issue as well.  I do have a ticket open with Meraki about it, but haven't gotten any resolution with them yet.

[Bruce]

@BBagley have you had a look at this document, https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Link_Aggregation_a.... The Cisco Meraki switches only support LACP. You will need to configure the other end to use LACP too, either in Active or Passive mode. If the other end is in Passive mode it will wait for the Meraki to attempt to negotiate the link aggregation, if its in Active mode then it will actively try and negotiate the the link aggregation whether the Meraki switch is set up for it or not.

[TerryMC]

Not a problem. This is the only configuration we found to work. Love to hear if anyone found another way. This is just an example. 

interface port-channel1

  switchport mode trunk

  switchport trunk native vlan 1000

  switchport trunk allowed vlan 1,90,1000

interface Vlan1000

  ip address 10.255.255.x/30

  ip ospf authentication message-digest

  ip ospf message-digest-key (keyhere)

  ip router ospf 1 area 0.0.0.0

  ip dhcp relay address x.x.x.x

interface Ethernet1/1

  switchport mode trunk

  switchport trunk native vlan 1000

  switchport trunk allowed vlan 1,90,1000

  channel-group 1 mode active

I created an SVI on Meraki that matches the uplink 1000 VLAN and on the same /30 network. On the Meraki switchport uplink I configured native VLAN 1000 and the same allowed VLANS. We worked with Cisco TAC and Meraki Support to figure this out. They collected our configuration and using it as an example for Cisco Nexus to Meraki configurations. I recent connected a Cisco Catalyst 3750 model to Meraki  using the same configuration. The VLAN90 is for the Meraki management network and need to have a DHCP scope created, so the switch get an address assigned and connect to the Meraki dashboard. 

Be a lot easier if Meraki would allow an IP address to be assigned to a physical port, but not possible. 

Hope this helps. 

T-MC

[BBagley]

This whole situation went on the back-burner for a bit, but we finally got it resolved.

I also ended up with tickets on both the Meraki and Cisco side, with the two support techs trying to figure out what was happening.

In my case, I'm using Cisco 3850s and Meraki MS425s.

The connections would come up fine, negotiate LACP with no errors, then after about 5 minutes, the ports on the Cisco side would err-disable due to a channel problem.

We had to issue this command on the Cisco 3850 stack:

no spanning-tree etherchannel guard misconfig

If I've understood correctly what's happening, once I get all my Cisco 3850 stacks up and running with LACP, then I should be able to turn this back on.  STP is behaving in different ways because of the different configurations.  Once they are all essentially the same, it should work. . .hopefully.

[its_Tricky83]

I've done things a bit differently:

At the core we have 2 x Catalyst WS-C3750X-24S, which is the existing core switch stack, and remains that way for the time being. So the Meraki network is currently sitting off the edge of the Catalyst core, utilising 2 x Ten Gigibit SFP's.

The Catalyst stack and the whole of the Catalyst network is utilising Rapid PVST (Rapid Per VLAN Spanning Tree) and this Catalyst Core Switch Stack has a Bridge Priority of 8192 (architecturally, this bridge priority was intended rather than 0 purely so that it would be possible to slide in a higher bridge priority device if needed, anyway!)

The Meraki's comes into play..

We have 2 x Meraki MS425-32's connected via 10G SFP etherchannel to the Catalyst Stack's TenGigEth ports:

MerakiMS425-Switch1 / 32 <> Catalyst Te1/1/2

MerakiMS425-Switch2 / 32 <> Catalyst Te2/1/2

Goes without saying, this link between the Meraki Stack to the Catalyst Stack is Aggregated.

The 2 x Meraki425's are stacked via 40GBASE-CR4 cables for redundancy if either of of the aggregated pair breaks.

The Meraki 425 Stack is set to use RSTP with a Bridge Priority of 12288, and all Meraki Edge Switches use the default bridge priority of 32768.

NOW! The important bit:

Rapid PVST only passes BDPU's across the default (VLAN 1). Because Meraki does not support Rapid PVST, we have chosen not to trunk VLAN 1 on the etherchannel connecting the Catalyst and Meraki Stacks. In effect creating two segregated STP networks, but allowing all other VLAN's other than VLAN1 to trunk traffic end-to-end.

The meaning of all this:

With this RSTP config, the Meraki 425's are the Root for all Meraki EDGE switches; and,

The Catalyst WS-C3750X stack is the Root for all Catalyst EDGE switches.

If by chance/mistake the Meraki Network's STP does converge with the Catalyst Network's STP, I'm hoping the higher bridge priority on the Meraki 425's somehow will instruct them to not take over bridge priority from the upstream Catalyst stack.

This is as close to the ideal scenario I can get to without reconfiguration Rapid PVST on the Catalysts to use something more standard/supported by the Meraki's.

We do have plans to remove the Catalyst Edge Core at some point, but for now it is needed because it is doing some fancy BGP stuff that I haven't got my head around yet. The Catalyst Edge switches have had ALL of their end-devices migrated to the Meraki's. So from a edge distribution point of view, the Catalyst Edge switches are sitting there doing not a lot. 

Sheesh, I hope some or all of that makes sense.