CE6810 trill + layer3 routing

Latest reply: Oct 27, 2015 14:36:35 2414 7 0 0

I have 2 CE6810 stacks and a CE5800 stack, as core switches in three different buildings on one site. Each stack consists of 2 units.

I don't want to stack all 6 devices because they're in different buildings - if a stack member (building) is isolated and rejoins, it tends to reboot (which means downtime for that building).

One of the CE6810 stacks is currently acting as a site router, using static routing (vlanif 's in each vlan configured for each active subnet on that vlan).

The stacks are connected together using 2 * 10Gb links, LACP, with spanning tree enabled across them.

In order to create a mesh connection between the buildings and make better used of the interbuilding links (LACP is rather inefficient and spanning tree would shut a redundant path down completely), I want to replace STP+LACP with TRILL. 

The edge switches within each building are likely to continue running STP in isolation but keeping them within one location helps reduce the size and convergence time of trees ( It is worth noting that if edge equipment such as servers are connected to a STP switch via LACP and that equipment reboots, a complete spanning tree rebuild is triggered, even if the edge equipment is not participating in the spanning tree.)

Here is my problem: 

After replacing one of the LACP/STP links with a TRILL one, routed L3 traffic is not going across the TRILL link. 

Anything staying within the same subnet passes across the TRILL link without any problems. It's only routed traffic which breaks.

Ideally, L3 routing should be distributed across all 3 cloudengine stacks  - as described in https://tools.ietf.org/html/draft-hao-trill-irb-04 - but at this point I'm unsure how to proceed. (VRRP isn't a distributed routing solution. one member of the group ends up as a designated router)

Am I forced to have a separate router, or can the cloudengines run TRILL and L3 routing simultaneously and if so, how do I achieve this?


  • x
  • convention:

Created Apr 4, 2015 16:59:05 Helpful(0) Helpful(0)

As an update to this, we've just been advised that L3+TRILL is now scheduled tfor Q3 2015


It's a bit more advanced than I was looking for, but on the othert hand there is no need for ospf or other protocols between the switches anymore.

As I said, we don't want to run an istack across multiple buildings because if the links are disrupted for any reason, the cloudengines will reboot when the links are reestablished.

  • x
  • convention:

Created Dec 7, 2014 13:22:26 Helpful(0) Helpful(0)

The edge switches are S5700-SI family (37 of them)

It is possible to run L3 routing on those but I do not believe they are capable of supporting a distributed routing protocol 

  • x
  • convention:

Created Dec 10, 2014 02:07:11 Helpful(0) Helpful(0)

In trill domain , the switch running trill protocol cant be the trill flow  L3 gateway . It means you need another switch to be the trill  gateway.  Or, you can wait to middle of 2015, we will solve this problem, which means you can establish trill gateway in swtich running trill.

  • x
  • convention:

Created Feb 10, 2015 02:31:06 Helpful(0) Helpful(0)

Reply 2 #

Hi there,

Its sounds like you have a similar setup to what we are going to implement with Huawei. We are putting in 4 x CE6810 as core L3 switches, 2 in one building and 2 in another. We will configure them in a single iStack cluster. We have S5700 SI as edge switches.

I may be completely wrong, but from my research I don't think Trill will work with a mixture of CE and Sx700 ranges of switches. They need to be either all CE (datacentre) or all Sx700 (campus).

Reply back if you are interested in sharing notes etc. We are putting this setup into a hospital. We have also been testing 3rd party optics to save a bit and it seems ok so far.

  • x
  • convention:

Created Feb 10, 2015 12:49:41 Helpful(0) Helpful(0)


The issue isn't the mixture. The problem is that CEs can't currently route and TRILL simultaneously.

(More specifically, routed packets are not sent across the TRILL links. They ARE passed out to non-TRILL ports)

As the other poster to this thread has indicated, there is a firmware update on the way to fix this. We've been told the ETA is around April 2015

  • x
  • convention:

Created Oct 27, 2015 14:32:07 Helpful(0) Helpful(0)

We are having the same problem here. Is there any update regarding this issue?

We are just putting 9 of them in production as initial topology.

  • x
  • convention:

Created Oct 27, 2015 14:36:35 Helpful(0) Helpful(0)

It's supposed to be solved in R005 firmware.

Actually "solved and more" - R005 implements distributed TRILL routing, per https://tools.ietf.org/html/draft-ietf-trill-irb-07

We installed R005 a couple of weeks ago, however I have not (yet) setup the distributed routing.

  • x
  • convention:


You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits