Community discussions

 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

VLAN VRRP

Thu Jun 27, 2019 1:13 pm

I will like to add bond0 device with unttaged vlan but pushing trunk inside it. All that needs to be served in VRRP. Is it even possible?

https://www.lucidchart.com/publicSegmen ... XWwZeGIa8c
 
User avatar
cdiedrich
Forum Veteran
Forum Veteran
Posts: 905
Joined: Thu Feb 13, 2014 2:03 pm
Location: Basel, Switzerland // Bremen, Germany
Contact:

Re: VLAN VRRP

Thu Jun 27, 2019 1:24 pm

It's absolutely possible.
First, add vlans to the bonding interface and then add vrrp interfaces to the vlans.
Or, if you want one vrrp interface being the master of the whole subsequent trunk port, add just one vrrp on the bonding interface and then add vlans to the vrrp interface.
Done.
-Chris
Christopher Diedrich
MTCNA, MTCUME, MTCWE
Basel, Switzerland
Bremen, Germany

There are 10 types of people: Those who understand binary and those who don't.
There are two types of people: Those who can extrapolate from incomplete data
 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

Re: VLAN VRRP

Mon Jul 08, 2019 4:16 pm

Ok but which IP Should I chose when they ale are tagged (trunk) ?
 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

Re: VLAN VRRP

Mon Jul 08, 2019 8:00 pm

Ok but which IP Should I chose when they ale are tagged (trunk) ?
And is it possible with that vlan config
https://wiki.mikrotik.com/wiki/Manual:B ... witch_chip
RB4011 has no built-in switch chip so I Wanted to have bonding in VRRP. On that configuration
 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

Re: VLAN VRRP

Mon Jul 08, 2019 10:03 pm

/interface bridge
add name=BR_TRUNK protocol-mode=none vlan-filtering=yes
add name=bridge1
add fast-forward=no name=loopback
/interface bridge port
add bridge=bridge1 comment=defconf interface=ether7
add bridge=BR_TRUNK hw=no interface=bond_core
/interface bridge vlan
add bridge=BR_TRUNK tagged=vrrp-lan,bond_core,BR_TRUNK vlan-ids=254,1313,1322,1323,1350,1351,1680
/interface vlan
add disabled=yes interface=vrrp-lan name=Azure vlan-id=1000
add interface=vrrp-lan name=CCTV_1313 vlan-id=1313
add interface=vrrp-lan name=DMZ_1351 vlan-id=1351
add interface=vrrp-lan name=Guest_1680 vlan-id=1680
add interface=vrrp-lan name=MGMT_254 vlan-id=254
add interface=vrrp-lan name=SRV_1350 vlan-id=1350
add interface=vrrp-lan name=TV_1322 vlan-id=1322
add interface=vrrp-lan name=Voice_1323 vlan-id=1323
add address=10.0.0.1/24 comment=defconf interface=bridge1 network=10.0.0.0
add address=10.13.13.1/27 interface=CCTV_1313 network=10.13.13.0
add address=10.255.254.253/24 interface=bond_core network=10.255.254.0
add address=10.13.22.1/28 interface=TV_1322 network=10.13.22.0
add address=10.13.51.1/24 interface=DMZ_1351 network=10.13.51.0
add address=10.13.23.1/28 interface=Voice_1323 network=10.13.23.0
add address=192.168.50.1/23 interface=Guest_1680 network=192.168.50.0
add address=10.13.50.1/24 interface=SRV_1350 network=10.13.50.0
add address=10.255.254.254 interface=vrrp-lan network=10.255.254.254
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: VLAN VRRP

Mon Jul 08, 2019 11:00 pm

VRRP is an L3 matter, so you'll need one VRRP setup in each VLAN on the trunk (which means one /interface vlan per each trunk on each of the two machines) and one on the native/tagless/default VLAN. If you want L2 redundancy, you have to use other means than VRRP.

An additional headache with the "one VRRP in each VLAN" setup is that the MAC address spaces of these VRRPs are independent from each other, so you may theoretically end up with the same MAC address being active on one device for some VLANs and on another device for other VLANs, so all L2 devices around must support independent per-VLAN learning in order to keep track with that.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

Re: VLAN VRRP

Tue Jul 09, 2019 12:31 pm

So this is different approach that was provided by cdiedrich ? Because I'm confused right now.

Above config looks like that
Image
 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

Re: VLAN VRRP

Tue Jul 09, 2019 12:58 pm

VRRP is an L3 matter, so you'll need one VRRP setup in each VLAN on the trunk (which means one /interface vlan per each trunk on each of the two machines) and one on the native/tagless/default VLAN. If you want L2 redundancy, you have to use other means than VRRP.
Could you explain that more or have an Example?

You mean so each pair of vlan and vrrp? so If I have 8 vlans so additional plus 8 vrrp interfaces attached to those vlans?
vlan1
 vrrp1
vlan2
 vrrp2
....
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: VLAN VRRP

Tue Jul 09, 2019 9:17 pm

Well... your picture mentions a single IP address but several VLANs, so I've understood your requirement as "use of VRRP to provide redundancy at L2 level" which is not what VRRP is intended for. As you can see, @cdiedrich has suggested both ways:
  • first, the "correct" one which I've tried to describe in deeper detail (one VRRP interface per each VLAN interface),
  • second, the highly creative one about which the VRRP authors never even thought, which is based on the specific implementation of VRRP on Mikrotik which allows to use /interface vrrp as a carrier interface for /interface vlan. This way, the VRR protocol can actually run only on the native VLAN of the physical interface, and all the /interface vlan which use the /interface vrrp as a carrier just follow the state of that carrier inteface, much like they would if it was a physical one. So you control on which machine all the IP addresses in the individual VLANs will be active by a single instance of VRRP protocol. I don't feel competent to judge whether it is a reliable solution from the point of view of redundancy, i.e. what other scenarios that a completely dead physical interface and misconfiguration may occur. For a completely dead physical interface, the approach is fine with me.
However, if you actually want to switch over between the two physical interfaces with the aim to use the VLANs in the trunk for L2 forwarding, you'll have to use the "own bridge for each VLAN" approach, as if you use the "common bridge for all VLANs" one, the bridge will always be up - a bridge doesn't use any interface as a carrier one, so it stays up even if all its member ports are down.

I'm not sure whether I've explained it clearly enough.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

Re: VLAN VRRP

Wed Jul 10, 2019 3:36 pm

I set it differently. I mean there is Interlink vlan which I created between switch (bond interface) and mikrotik bond. Added that bond to the bridge and assigned vlans to bridge. After that I created a VRRP in the network where Interlink is and added that specific interlink vlan from trunk to the vrrp because all not-known networks which mikrotik doesn't know about are routed statically through that intelink. So the interlink is crucial here to be supported by VRRP.
But.. I have issue with that configuration. User from different vlan which came from SWITCH wasn't able to go out to the internet using switch as a gatewy.. an switch has nexthop gateway mikrotik. So..

Using that https://wiki.mikrotik.com/wiki/Manual:B ... witch_chip configuration

user -> switch (gatewy for user vlan) -> interlink vlan between switch and mikrotik -> mikrotik -> Internet.

When I switched to software vlans. So setting vlans and assigned them on Bond device instead bridge it so the Interlink vlan between Switch and Mikrotik for routing purpose was also assigned to directly to Bond started to work. I mean user was able to go to Internet using switch as a gateway and gateway has default route pointing to mikrotik interlink vlan IP address. Strange.
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: VLAN VRRP

Wed Jul 10, 2019 4:27 pm

You're freely mixing switching (bridging) and routing together, saying in one sentence that the external switch is a gateway (router) for a host connected to some VLAN and in another sentence implying that the gateway (router) should be the Mikrotik instead. That's an indication that you have some mess at least in the vernacular if not the whole concept. May I ask what is your native language? And may I ask you to draw what you expect to get as a result?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

Re: VLAN VRRP

Wed Jul 10, 2019 6:58 pm

You're freely mixing switching (bridging) and routing together, saying in one sentence that the external switch is a gateway (router) for a host connected to some VLAN and in another sentence implying that the gateway (router) should be the Mikrotik instead. That's an indication that you have some mess at least in the vernacular if not the whole concept. May I ask what is your native language? And may I ask you to draw what you expect to get as a result?
It's better to draw it because it will be a problem for us. Mine is Polish. Why?
Maybe could you confirm that the configuration above with Vlan Filtering on devices without built-in switch chip will not work on RB4011 as it's doesn't support Brigde Vlan Filtering ? From What I see it doesn't: https://wiki.mikrotik.com/wiki/Manual:I ... Offloading
So only software vlans will work on this?
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: VLAN VRRP

Wed Jul 10, 2019 7:44 pm

Mine is Polish. Why?
1. because I can express myself better than in English in some other languages; my Polish is worse than my English so no point here, and 2. because knowing the native language of the other user of English often helps understand the intended meaning of some words even if their precise meaning in English is slightly different (words with wider meaning are rarely mapped 1:1 between languages); since technical Polish is very unambiguous, it's also not relevant here.

So my concern regarding what you had in mind when saying that the switch should be a gateway for some devices in the VLAN remains - a gateway is an L3 term, meaning that there should be an IP address in each VLAN already on the external switch, and in that case, the external switch would have to take care also about routing from the subnet in each VLAN to other subnets, including external ones. On the other hand, if the external switch just provides access ports to various VLANs for the connected devices, and the Mikrotik is the L3 gateway for each of the IP subnets used inside the VLANs, the switch cannot be called a gateway as that word has a very precise and distinctive meaning in L2/L3 context so using it improperly causes confusion when the overall concept is unclear and unusual.

Maybe could you confirm that the configuration above with Vlan Filtering on devices without built-in switch chip will not work on RB4011 as it's doesn't support Brigde Vlan Filtering ? From What I see it doesn't: https://wiki.mikrotik.com/wiki/Manual:I ... Offloading
So only software vlans will work on this?
That's what I've tried to explain in one of the previous posts. What Mikrotik calls "vlan-filtering" as a parameter of a bridge in fact switches on several behaviours of the bridge, not just VLAN filtering itself but also tagging and untagging of frames on ingress/egress. Without vlan-filtering=yes, VLAN tags cannot be added or removed as the frame crosses the bridge boundary. So all ports of a bridge with vlan-filtering=no can be hybrid ones, but the "native VLAN" of all of them will be the same and will never get tagged.

So vlan-filtering=yes will work on 4011 as good as on any other Mikrotik model, but you cannot combine it with VRRP the way you want for the reason I've explained above. There are two options:
  • either you use /interface vrrp, /interface ethernet, or /interface bonding as a carrier interface for /interface vlan, but in that case, the carrier interface cannot be a port (or slave if you want) of a bridge,
  • or you make /interface vrrp, /interface ethernet, or /interface bonding a port of a bridge, but in that case, the carrier interfaca for /interface vlan must be the bridge.
But as said, the intended use is important here. If the VLANs from your trunk port need not be bridged to any other port of the Mikrotik, and you only need to put up an /interface vlan internally for each of them, to attach to it an IP address to be used as a gateway for hosts from the IP subnet hosted by that VLAN, the "innovative" use proposed by @cdiedrich is still fine (with the disclaimer I've given before), because in that case there is no need to have a bridge at Mikrotik side, so you can use the /interface bonding as a carrier for the /interface vrrp, and in turn use the /interface vrrp as a carrier interface for all the /interface vlan, and the single instance of vrrp protocol will control the up/down state of the /interface vrrp and through it also of all the /interface vlan which use it as their underlying carrier. If you need the vlans to be bridged with other ports of the Mikrotik, you can still do that if you use a separate bridge for each such VLAN (so to bridge a single VLAN between two ethernet or bonding interfaces, you need two /interface vlan with the same vlan-id, each attached to one of the interfaces and both member ports of a dedicated bridge where the frames of that VLAN will be forwarder between them tagless). But:
  • if you'd want to use a single bridge for all VLANs (and this is the only scenario where use of vlan-filtering=yes makes sense), you'd have to make that bridge a carrier interface of all those /interface vlans, and in that case, they would be unable to track the up/down state of the /interface vrrp.
  • if you'd use the "one bridge per VLAN" approach, the VRRP would still control only the up/down state of the /interface vlan attached indirectly to the /interafce bonding to which the /interface vrrp would be attached; the /interafce vlan attached to other interfaces would stay up.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
eset
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Tue Dec 15, 2015 5:15 pm
Contact:

Re: VLAN VRRP

Thu Jul 11, 2019 12:51 am

Ok I analyzed your answer very carefully. There are some misunderstanding which I wanted to clear so we both be on the same page here.
So my concern regarding what you had in mind when saying that the switch should be a gateway for some devices in the VLAN remains - a gateway is an L3 term, meaning that there should be an IP address in each VLAN already on the external switch,
It is. Starting from beginning:
Here is a schema
Image

This is a software vlan configuration on MikroTik. By "software" I mean all vlans are attached on bond device and bond device has two interfaces of course attached in LACP mode.
Some of the vlans are set on MikroTik but some of them aren't. For example the user vlan 131 10.13.1.0/24
Both , MikroTik and Switch are connected with bond. This bond is for trunk capability and it pushes those vlans which are created on Switch and MikroTik is also participating in those vlans with ip address in each vlan which ends with .1 as it is in the picture. So when I said that about gateway I don't mean that switch is a gateway. What I said was that the end user in the user vlan 131 (10.13.1.0/24) has a DHCP server from Switch (switch is a DHCP server) and also for that user switch is a default gateway. So for 10.13.1.0/24 access to 0.0.0.0/0 is provided via 10.13.1.1 (switch dhcp server). On that switch there is a route entry which says 0.0.0.0/0 goes via 10.13.60.1 (which is the InterLink VLAN between switch and mikrotik). On MikroTik there has to be a static route entry ponting to network 10.13.1.0/24 via 10.13.60.2 (Switch IP on the Interlink vlan). So this configuration works on software vlans.
/interface bonding
add mode=802.3ad name="LACP to Core" slaves=ether3,ether4 transmit-hash-policy=layer-2-and-3

/interface vlan
add interface="LACP to Core" name=Azure vlan-id=1000
add interface="LACP to Core" name=CCTV vlan-id=1313
add interface="LACP to Core" name=DMZ vlan-id=1351
add interface="LACP to Core" name=Guest_Wifi vlan-id=1680
add interface="LACP to Core" name=Interlink-to-core vlan-id=1360
add interface="LACP to Core" name=Management vlan-id=254
add interface="LACP to Core" name=TV vlan-id=1322
add interface="LACP to Core" name=Voice vlan-id=1323

/interface vrrp
add interface=Interlink-to-core name=vrrp-core preemption-mode=no priority=254

/ip address pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 10.13.60.1/29 10.13.60.0 Interlink-to-core
1 10.13.13.1/27 10.13.13.0 CCTV
2 10.255.254.254/24 10.255.254.0 Management
3 10.13.22.1/28 10.13.22.0 TV
4 10.100.0.1/24 10.100.0.0 Azure
5 10.13.51.1/24 10.13.51.0 DMZ
6 10.13.22.1/28 10.13.22.0 Voice
7 192.168.50.1/23 192.168.50.0 Guest_Wifi
9 10.13.69.1/24 10.13.69.0 bridge
10 10.13.60.3/32 10.13.60.3 vrrp-core

/ip route
add distance=1 dst-address=10.13.1.0/24 gateway=10.13.60.2
So this is trivial vlan configuration.
This configuration works. So you see about that vrrp I've just added one vrrp and the vlan itself is the carrier. That works. Tested.

Now back to that https://wiki.mikrotik.com/wiki/Manual:I ... Offloading
RB4011 is the section described in "Other devices without a built-in switch chip". So this method suits for RB4011 devices.
You said that in that case carrier needs to
or you make /interface vrrp, /interface ethernet, or /interface bonding a port of a bridge, but in that case, the carrier interfaca for /interface vlan must be the bridge.
And it was. I showed you that already
/interface bridge port
add bridge=BR_TRUNK hw=no interface=bond_core
Only that I had bond_core which stands for = LACP to Core in current configuration

Rest was
/interface vlan
add disabled=yes interface=BR_TRUNK name=Azure vlan-id=1000
add interface=BR_TRUNK name=CCTV_1313 vlan-id=1313
add interface=BR_TRUNK name=DMZ_1351 vlan-id=1351
add interface=BR_TRUNK name=Guest_1680 vlan-id=1680
add interface=BR_TRUNK name=MGMT_254 vlan-id=254
add interface=BR_TRUNK name=SRV_1350 vlan-id=1350
add interface=BR_TRUNK name=TV_1322 vlan-id=1322
add interface=BR_TRUNK name=Voice_1323 vlan-id=1323
and
/interface bridge vlan
add bridge=BR_TRUNK tagged=vrrp-lan,BR_TRUNK vlan-ids=\
254,1313,1322,1323,1350,1351,1680,1360
So bond_core was a port of a bridge and carrier for vlans where that BR_TRUNK which is the bridge. Then that case with 10.13.1.0/24 didn't worked. I could only ping 10.13.1.1 (switch) but a DHCP client with ip 10.13.1.11 had timeouts on mikrotik and traceroute from client to internet didn't even go passed switch.

At the end about vrrp again

You mentioned
so you can use the /interface bonding as a carrier for the /interface vrrp, and in turn use the /interface vrrp as a carrier interface for all the /interface vlan, and the single instance of vrrp protocol will control the up/down state of the /interface vrrp and through it also of all the /interface vlan which use it as their underlying carrier
Yeah That didn't worked either when I had those vlans on the bridge. Like we said above I moved VRRP only to that interlink vlan so if the vlan connectivity fails it means that everything fails because user -> DHCP Switch -> 0.0.0.0/0 via 10.13.60.1 -> Mikrotik -> Internet. If 10.13.60.0/29 goes off it needs to switch traffic to backup MikroTik. Is it a bad configuration?

But having vlan-filtering=yes with VRRP in that case as you mention below will not work
if you'd want to use a single bridge for all VLANs (and this is the only scenario where use of vlan-filtering=yes makes sense), you'd have to make that bridge a carrier interface of all those /interface vlans, and in that case, they would be unable to track the up/down state of the /interface vrrp.
So it means I should resign from vlan-filtering=yes and stay with the configuration I showed.
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: VLAN VRRP

Fri Jul 12, 2019 12:02 pm

@eset, there still seems to be some misunderstanding regarding different elements of VLAN configuration. As I'll be unable to use my left hand for some time now, if you're still not happy with your existing configuration, we'll have to agree on a voice call (Viber, WhatsApp, Skype supported), but PMs are disabled on this forum so suggest some way of exchanging contacts. If it can wait, I'll come back once I regain my capability to type using "all 4".
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
mkx
Forum Guru
Forum Guru
Posts: 2985
Joined: Thu Mar 03, 2016 10:23 pm

Re: VLAN VRRP

Fri Jul 12, 2019 12:07 pm

As I'll be unable to use my left hand for some time now ...

Wow, bummer! I certainly hope you'll get well soon ...
BR,
Metod
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: VLAN VRRP

Fri Jul 12, 2019 5:13 pm

Wow, bummer! I certainly hope you'll get well soon ...
Thank you. "Soon" has been translated into "approximately four weeks" by the healthcare professionals. Maybe it will teach me how to express the same thoughts with less words 🙂
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1398
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: VLAN VRRP

Sat Jul 13, 2019 1:07 am

Trust you will make a quick and full recovery @sindy
MTCNA, MTCTCE, MTCRE & MTCINE
 
anav
Forum Guru
Forum Guru
Posts: 2973
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: VLAN VRRP

Sun Jul 14, 2019 11:24 pm

Sorry to hear about your injury. :-(
Having recently had a hand injury, understand the loss to some degree. Hoping you recover soonest!
I w i l l t y p e s l o w l y f o r y o u r p o s t s. ;-)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)

Who is online

Users browsing this forum: MSN [Bot] and 78 guests