Bridging, Bonding, and interfaces

Hi all,

Trying to migrate an existing network config from a brand similar to Cisco as a stop-gap due to some hardware failure. Looking to keep the redesign to a minimum. I picked to use a CCR1072 and CRS309 to get enough ports and processing power. The purpose of the CCR is to be a mini firewall, should do just fine. These rotuers essentially sit ontop of a fiber loop that starts at one DC, ends at the other, and uses vrrp to balance the VIP.

For the CCR we have traffic that goes in a few directions

  • Traffic down to the CRS309, which will be 2 interfaces bonded with 802.3d, so we shall call this bond1
  • Traffic that will go between two data centers, which is bond2
  • Traffic that goes to the server cluster at this DC, which is bond3
    Each bond has 2 interfaces. I could probably decrease this down to 1 interface since i am going from 1GB interfaces to 10GB. but bonding is not the problem here.

The problem is vlan and bridging, at least from the perspective of the CCR (have not gotten down to the switch yet)

  • Towards Bond1 i need to send vlans 30,800,40
  • Towards bond2 i need to send vlans 112,113,114,115,116,40

I obviously need a bridge here to add vlan 40. But a couple of questions here

  1. Can i add a bridge onto bond1 and 2, and still add vlans that do not require to go across interfaces directly to the bond? IE vlan 40 to the bond, but the remaining vlans that go one way, back to the interface directly?
  2. How do i handle a mix of bridges? Trying to mimic cisco where you can add a vlan to any interface you want. I am guessing If i need to do more complex vlan stuff, I will need to do it down at CRS level. I remember the last time i did vlaning on a CRS, i could do way more vlan abilities that on a router. In fact on a router, adding a vlan between interfaces on a cisco is just as much of pain and you need to use bridging and service-tags.

No. Either attach all /interface vlan to a single bridge with vlan-filtering=yes where both bond1 and bond2 are member ports, and configure which VLAN is allowed on which bond using /interface bridge vlan rows (mimicking VLAN handling on a Cisco switch).
Or attach all the /interface vlan rows to bond1 and bond2 as needed (mimicking VLAN handling on a Cisco router), so you’ll have two /interface vlan rows with vlan-id=40, each attached to another bond, and create a bridge for VLAN 40 traffic, which will have those two /interface vlan as members. But this approach doesn’t support xSTP well.

On the router, you can emulate a switch using the bridge. Since you only need L2 forwarding between two ports for VLAN 40, it depends on the traffic volume in that VLAN whether it is worth it to engage a hardware switch or whether the router’s CPU has enough capacity to handle it as well. Traffic in the other VLANs requires L3 handling anyway so the external switch won’t add any value.

For non-standard stuff, the router is more flexible as you can interconnect multiple layers of bridges to add/remove multiple VLAN tags. For standard stuff, the switch is faster but relatively limited in capabilities.