Good day!
I’ve read a lot of docs, forums and wiki about mikrotik-cisco trunking and link reservation.
Here is my scheme:
two Mikrotik routers with two trunk ports to each catalyst switch
two access-layer Cisco switches
When each Mikrotik has just one trunk link to the switch, it is quite clear “Mikrotik router on the catalyst stick” http://wiki.mikrotik.com/wiki/File:Image12005.gif
But what to do, when each catalyst has two trunk links to each mikrotik router?
If we’ll have two L3 switches (3750 for example) instead of mikrotik, we’ll create vlan 3
vlan 4
!
int vlan 3
ip …
int vlan 4
ip …
!
int g0/1
sw mode trunk
int g0/2
sw mode trunk
and that’s all - vlans are travelling through the trunk links and communicate with other vlans with the help of inter-vlan routing.
How to configure the same thing on the Mikrotik?
Let’s create the analog of “int vlan 3” on the Mikrotik 2 /interface vlan
add name=VLAN3 vlan-id=3 interface=ether2 disabled=no
/ip address
add address=10.1.1.2/24 interface=VLAN3
from this config we can see, that int VLAN3 belongs to ethernet2 only! but what about ethernet1 for example?
How could the clients from sw1 communicate with mikrotik2 when mikrotik1 fails? (in case of vrrp of course)
How can we make the eth1 and eth2 interfaces full-fledged trunk links?
If you goal is to have VLAN 3 and VLAN 4 on Cisco switches with VLAN interfaces on the two RouterBOARDs and redundancy via VRRP I think your network diagram - thank you very much for providing one, by the way, way too few people do - is not how I’d run that.
I would configure one trunk port on the left switch to connect to RB1, one trunk port on the right switch to connect to RB2, and one trunk between the two switches. I would leave out the switch chip on the RBs completely because, to put it bluntly, it isn’t very good when used for anything than a quick switch group similar to what D-Link or Neatgear routers do. I don’t see why you need two trunks per router.
I’m also a little bit confused why you’re creating VLAN interfaces on the 3750 if you’re going to use RouterOS as the gateway for the VLANs.
If that’s a design that achieves what you want it to with the components you have on hand I can help you with that.
And here the relevant config. ether9 on both RouterBOARDs is assumed to be the WAN uplink. Cisco switch A gi0/1 links to ether1 on RB1, Cisco switch A gi0/2 links to Cisco switch B gi0/2, Cisco switch B gi0/1 links to ether1 on RB2. The two RouterBOARDs act as layer 3 gateways for VLANs 3 and 4 and back each other up via VRRP, RB1 is the default master for VLAN 3 and RB2 is the default master for VLAN 4.
Cisco switch A:
conf t
vlan 3
name vlan3
vlan 4
name vlan4
int g0/1
desc uplink-rb1-eth1
sw tru encap dot1q
sw tru allowed vlan 3-4
sw mode trunk
no shut
int gi0/2
desc uplink-cisco-b-gi0/2
sw tru encap dot1q
sw tru all vl 3-4
sw mode trunk
no shut
int gi0/3
desc user-vlan-3
sw acc vl 3
sw mode acc
no shut
int gi0/4
desc user-vlan-4
sw acc vl 4
sw mode acc
no shut
end
Cisco switch B:
conf t
vlan 3
name vlan3
vlan 4
name vlan4
int g0/1
desc uplink-rb2-eth1
sw tru encap dot1q
sw tru allowed vlan 3-4
sw mode trunk
no shut
int gi0/2
desc uplink-cisco-a-gi0/2
sw tru encap dot1q
sw tru all vl 3-4
sw mode trunk
no shut
int gi0/3
desc user-vlan-3
sw acc vl 3
sw mode acc
no shut
int gi0/4
desc user-vlan-4
sw acc vl 4
sw mode acc
no shut
end
The variant with one trunk link for each Mikrotik is not so redundant, as the scheme with two uplink for each switch.
Imagine the situation, when R1 and SW2 fails - then all LAN-devices will have no access to the R1.
But If the SW1 has also one trunk to the R2, the scheme remains functional
That’s why we need SVI interfaces (L3 VLAN) for several eth links
I’ve already fixed this problem with the help of bridge interface:
/interface bridge
add name=br12
/interface bridge port
add bridge=br12 interface=ether1
add bridge=br12 interface=ether2
/interface vlan
add name=vlan3 vlan-id=3 interface=br12 disabled=no
add name=vlan4 vlan-id=4 interface=br12 disabled=no
But this variant gives us the restriction of using only two physical intefaces per group of SVI-interfaces.
Thats seems strange to me… why Mikrotik OS doesn’t provide the ability to make any amount of SVI-interfaces and bind them to any amount of trunk eth-intefaces?
p.s. 3750 sw was only for example, we do not use them in these scheme
You can also check STP on switches and Mikrotiks - ensure that switches have lower STP bridge IDs than bridges on Mikrotiks (so you won’t get situations when link between switches gets disabled by STP and all traffic between switches gets forwarded through one of Mikrotiks). Almost definitely this is the default, but anyway it’s good to be aware of this.
