Hey Andrew, If you're just doing switching, and don't need wifi bridged to the vlans, then just use the switch chip (/interface ethernet switch {vlan|ingress-vlan-translation|egress-vlan-translation|egress-vlan-tag} commands) like you would have pre-6.41 - it still works perfectly. :) If you need wifi bridged into a vlan (rather than routed), then you'll need to use the vlan filtering on the new /interface bridge commands which will limit you to ~400mbps of switching capacity :\ You had me excited at the thought of hAP AC Lite's until I searched them up to find they only have 100mbps ethernet interfaces.. - if I could put something in to sit beside each of my CRS109's at home, I could turn off the VLAN filtering and go back to the switch chip configurations, and get my wire speed switching back! That said, for 99% of my use at home, a 400mbps limit is going to be fine anyway. Thankfully in the datacenter, my wifi is on it's own private /28, routed into the OSPF internal network, so I won't need to mess with VLAN filtering there either, and can just keep using the switch chip. At home, I need to talk to network connected printers from iDevices, so routed wifi isn't really an option :( As a sample, for your CRS, say you have ports ether1 and ether2 as trunk ports for vlans 100,101, and 102, and then want ether3/4 as access ports on vlan100, ether5/6 as access ports on vlan101, and ether7/8 as access ports on vlan102, and want a management IP on vlan100, you'll want something like this: # RouterOS 6.41+ will probably have done this for you anyway.. This
replaces master/slave ports.. /interface ethernet bridge add name=bridge1 /interface ethernet bridge port add bridge=bridge1 interface=ether1 add bridge=bridge1 interface=ether2 add bridge=bridge1 interface=ether3 add bridge=bridge1 interface=ether4 add bridge=bridge1 interface=ether5 add bridge=bridge1 interface=ether6 add bridge=bridge1 interface=ether7 add bridge=bridge1 interface=ether8
# setup the switch chip.. pre-6.41 style - still works fine in 6.42 with the exception of wifi sourced traffic not getting translated correctly # add the vlans /interface ethernet switch vlan add vlan-id=100 ports=ether1,ether2,ether3,ether4,switch1-cpu add vlan-id=101 ports=ether1,ether2,ether5,ether6 add vlan-id=102 ports=ether1,ether2,ether7,ether8 /interface ethernet switch egress-vlan-tag add vlan-id=100 tagged-ports=ether1,ether2,ether3,ether4,switch1-cpu add vlan-id=101 tagged-ports=ether1,ether2,ether5,ether6 add vlan-id=102 tagged-ports=ether1,ether2,ether7,ether8 # Setup the vlan translations to make the access ports ## on the way out /interface ethernet switch egress-vlan-translation /add customer-vid=100 new-customer-vid=0 ports=ether3,ether4 /add customer-vid=101 new-customer-vid=0 ports=ether5,ether6 /add customer-vid=102 new-customer-vid=0 ports=ether7,ether8 ## and on the way back in /interface ethernet switch ingress-vlan-translation /add customer-vid=0 new-customer-vid=100 ports=ether3,ether4 /add customer-vid=0 new-customer-vid=101 ports=ether5,ether6 /add customer-vid=0 new-customer-vid=102 ports=ether7,ether8
# and add the vlan for routeros's management IP /interface vlan add interface=bridge1 name=management_vlan100 vlan-id=100 /ip address add address=192.168.0.100/24 interface=management_vlan100 /ip route add gateway=192.168.0.1
On Sat, 29 Dec 2018 at 19:27, Andrew Radke <andrew@deepport.net> wrote:
Hi Mike,
I’m really only aiming to do the most basic setups that I didn't think I need vlan filtering for. Pretty much just a bunch of access ports for a few vlans and trunk ports between the switches.
One of the vlans would be a management vlan that I’d like to be the only access to the CRS management which means adding switch1-cpu into it (without loosing hw offload on the rest of switch). A bonus would be assigning the traffic from the wifi interface to a vlan, but honestly I could live without the wifi since the hAP ac lite’s work so well and are so cheap.
So is this possible on CRS1xx models in hardware since 6.41? I think I’ve been reading too many of the wiki pages and they’ve got so many crossed configs for pre vs post 6.41 that I hope I’m just missing the extremely simple obvious settings to achieve this.
I’d also like to achieve the same on some RB960’s if possible, but I’ll happily start with the CRS1xx’s. :-)
Cheers, Andrew
On 28 Dec 2018, at 7:01 pm, Mike Everest <mike@duxtel.com> wrote:
Hi Andrew,
CRS1xx do not support vlan filtering in hardware, as documented here:
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Bridge_Hardware_O...
The essence of the 'new style' bridge is that hardware offloading is
automatically enabled in all conditions where the underlying platform can support the bridge configuration:
"bridges will handle all Layer2 forwarding and the use of switch
chip (hw-offload) will automatically turn on if appropriate conditions are met"
The 'appropriate conditions' are listed in the table, which clearly
shows that van filtering is not supported in CRS1xx models :(
Therefore, if you need hardware switching of vlan, then you need to use
the switch menu features, or use one of the CRS2xx models.
Does it make any better sense? :-}
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Radke Sent: Friday, 28 December 2018 1:44 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] RouterOS 6.40->6.42 upgrade didn't go so
How should things work now? :)
Hi Damien,
I’ve just been looking to setup VLANs on my CRS109 and CRS125 and remembered this thread.
I’ve been bashing my head against a wall trying to do what seems to me should be very simple. Nothing worked as expected. Then I turned on vlan-filtering and viola everything does the right thing, except of course there is no hardware based switching. I absolutely can’t use the CRS125 like this so for now it all seems out of the question.
Has there been any further progress on the issue on the MT forums and do you know if this issue effects anything other the the CRS1xx devices?
Also if and when you do have it working would you mind posting a sample config as I think I’ve got my head in a complete knot from the bad docs on the MT wiki (first time I’ve hated it).
Maybe Mike you could pass on to Mikrotik that the need to break up all
VLAN docs on the wiki into totally seperate ones for pre and post bridge changes. Trying to put them into the same page with if before this but after
well.. the that and then
this, etc is worse than a mess.
Cheers, Andrew
On 21 Dec 2018, at 5:56 am, Damien Gardner Jnr <rendrag@rendrag.net> wrote:
Just thought I'd follow this up.
Looks like it's not a RouterOS issue, so much as a CRS109 issue..
Have been discussing this on the MT forums, and a known working config from an RB751, doing exactly what I want, still has this issue on the CRS109.. Dammit :(
On Sun, 16 Dec 2018 at 12:34, Mike Everest <mike@duxtel.com> wrote:
3 most important rules for upgrading routerOS:
1. if it aint broke, don't fix it 2. ONLY (ever ever) use bugfix (long-term) tree for production (including home!) devices 3. When you upgrade, download the file and store it somewhere handy in case you need/want to roll back in future BEFORE upgrading ;)
(4 cross your fingers and your toes ;)
Cheers, Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Saturday, 15 December 2018 5:23 PM To: jason@upandrunningtech.com.au; MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] RouterOS 6.40->6.42 upgrade didn't go so well.. How should things work now? :)
Hahahahahah! Work xmas party tonight... Maybe tomorrow ;)
On Sat, 15 Dec 2018 at 16:58, Jason Hecker (Up & Running Tech) < jason@upandrunningtech.com.au> wrote:
> https://download.mikrotik.com/routeros/6.43.7/routeros-mipsbe-6.43. > 7.n > pk > > I dare you! > > On Sat, 15 Dec 2018 at 16:52, Damien Gardner Jnr > <rendrag@rendrag.net> > wrote: > >> Wow, I spoke too soon! Walked away to go watch Plex, and the >> internet died again.. What do you know, those vlan tags are back >> on > wifi->ethernet >> packets! >> >> Rolled back to 6.42.9. And it's now been stable for 45 mins.. >> >> On Sat, 15 Dec 2018 at 15:57, Damien Gardner Jnr >> <rendrag@rendrag.net> >> wrote: >> >>> Ohhhh kay! I think perhaps there's a bug in the 6.42.10 image.. >>> Ended up going to Sydney for work this morning, and was mulling >>> things over on the drive down. It occurred to me, that enabling >>> RSTP on the base > bridge, >>> and then NOT enabling STP at all on the sub-bridges for the >>> vlan+wifi > might >>> be the go for having working STP on the network, while still >>> having multiple levels of bridges... So when I got home this >>> arvo, I gave > that a >>> burl. >>> >>> Imagine my surprise, when my packets being passed from wifi to >>> ethernet STILL had vlan tags attached (aka the vlan egress >>> translation rule on > the >>> switch chip was being ignored??) But this is working on my other > CRS109's >>> on 6.42.9!! So I downgraded to 6.42.9 just incase it was a version >>> difference - and voila, working wifi->ethernet! UPGRADED back to >>> 6.42.10.. and STILL have working ethernet... I'm confused, but >>> it's all working.. STP enabled on the main bridge, and no STP on >>> the sub-bridges for the vlan->wifi bridging, seems to be working well. >>> >>> On Sat, 15 Dec 2018 at 08:12, Damien Gardner Jnr >>> <rendrag@rendrag.net> >>> wrote: >>> >>>> BTW, I did a bunch more troubleshooting of the wifi->ethernet >>>> issue, > and >>>> figured out *why* it doesn't work, but not the resolution as yet.. >>>> >>>> It seems the switch chip config for vlan ingress/egress >>>> translations ignores packets sourced from wireless - so when >>>> your wireless > interfaces >>>> are told to use-tag=100 to get them onto your LAN, those packets >>>> get > passed >>>> out the ethernet ports set with vlan 100, but then they're still > TAGGED as >>>> vlan 100, even if you have an egress translation rule setting >>>> customer-id=100 new-customer-id=100. For now I've set my other >>>> two > CRS's >>>> back to use multiple bridges on sub-vlans, and disabled STP on >>>> the main bridge, and just left my main CRS (Which does the >>>> routing out the PPPOE >>>> diallers) using one bridge but with its wifi disabled, so I can >>>> do more testing if anyone thinks of anything :) >>>> >>>> >>>> >>>> On Sat, 15 Dec 2018 at 07:14, Damien Gardner Jnr >>>> <rendrag@rendrag.net> >>>> wrote: >>>> >>>>> I *can*, but then I'm back to where wifi can't talk to ethernet >>>>> :\ >>>>> >>>>> The *only* way I can get things to work 'properly', is to >>>>> disable STP on the main bridge which has all ethernet ports, >>>>> and then create > bridges >>>>> for each vlan which needs to go to a wifi SSID ( and drop the >>>>> vlan interface and the wifi into that bridge - aka the old way >>>>> of doing > it) - >>>>> but then STP is disabled, which is horrible. (If STP is >>>>> enabled on > the >>>>> main bridge, the network goes down as soon as I drop one of the >>>>> vlans > into >>>>> one of the vlan-specific bridges..) >>>>> >>>>> This *shouldn't* be a complicated need - at it's simplest (i.e. >>>>> the other two CRS109's in the house), it's to take three vlans >>>>> in on a > trunk >>>>> (management, LAN and kidsLAN), put an IP on the management >>>>> vlan, and > bridge >>>>> the LAN and kidsLAN vlans to two wifi interfaces. But I can't >>>>> do that > on a >>>>> CRS109 anymore with hw-offload still enabled, and supporting STP. >>>>> >>>>> I MUST be missing *something*, surely? This seems like the >>>>> target use case for the CRS109 - small office switch with wifi... >>>>> just enough > CPU to >>>>> also support up to 50-100mbps of PPPOE. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, 14 Dec 2018 at 9:43 pm, Jason Hecker (Up & Running >>>>> Tech) < jason@upandrunningtech.com.au> wrote: >>>>> >>>>>> I don't think you *have* to use this bridge VLAN filtering. >>>>>> Can't > you >>>>>> just >>>>>> set up a common bridge with the eth's attached (to enable >>>>>> hardware >>>>>> switching) and then go into the switch menu and set up the >>>>>> VLANs the good ol' switch menu way? >>>>>> >>>>>> On Fri, 14 Dec 2018 at 19:59, Damien Gardner Jnr < > rendrag@rendrag.net> >>>>>> wrote: >>>>>> >>>>>>> Have been having MASSIVE performance issues all night tonight >>>>>>> - as >>>>>> soon as >>>>>>> say my macbook starts a time machine backup across the wifi, >>>>>>> the >>>>>> whole >>>>>>> network falls apart. Start to try to figure out what's going on, >>>>>> and >>>>>>> realise hardware offload has somehow stopped working on the >>>>>>> bridge >>>>>> ports >>>>>>> since yesterday. >>>>>>> >>>>>>> Discovering this wiki.microtik.com site that Mike wonderfully >>>>>> pointed me >>>>>>> towards, I end up on >>>>>>> >>>>>>> >>>>>> > https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Bridge_H > ard > ware_Offloading >>>>>>> - and what do you know, enabling VLAN Filtering on >>>>>>> CRS1xx/CRS2xx >>>>>> disables >>>>>>> hw offload to the switch chip from the bridge.. What on >>>>>>> EARTH were Mikrotik thinking implementing this hodge podge? >>>>>>> Switch chip >>>>>> functionality >>>>>>> worked PERFECTLY. Now we have this new bridge functionality >>>>>>> that >>>>>> doesn't >>>>>>> do half of what the switch chip functionality did, AND it >>>>>>> doesn't >>>>>> support >>>>>>> the existing hardware, so I can't get more than ~20mbps of >>>>>> *SWITCHING* out >>>>>>> of my SWITCH. :( >>>>>>> >>>>>>> I'm truly flabbergasted. I now have four CRS-109's which are >>>>>> basically >>>>>>> glorified doorstops, as they certainly can't operate as >>>>>>> switches if >>>>>> I want >>>>>>> to keep them updated security-wise...? >>>>>>> >>>>>>> Well, I've been awake for 36 hours. I'm going to bed. Will > consider >>>>>> what >>>>>>> to do with my home and DC networks going forward, tomorrow. >>>>>>> :( >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, 14 Dec 2018 at 14:09, Mike Everest <mike@duxtel.com> > wrote: >>>>>>> >>>>>>>> Hi Damien! >>>>>>>> >>>>>>>> VLAN functionality supported by the bridge depends on the > available >>>>>>> switch >>>>>>>> chip, so it might be different for different routerboard >>>>>>>> models > :-J >>>>>>>> Specifically, CRS1xx and CRS2xx are different than CRS3xx - >>>>>>>> other routerBoard models also depend on what chip is on board. >>>>>>>> >>>>>>>> It's annoying, but I'm hopeful that they eventually >>>>>>>> implement > some >>>>>>>> automation in bridge the same way they have done the port > switching >>>>>>> thing. >>>>>>>> Wiki.mikrotik.com has some half decent articles about this >>>>>> different >>>>>>>> methods >>>>>>>> for trunking especially. >>>>>>>> >>>>>>>> I don't think you can do tag translation like you mention >>>>>>>> using >>>>>> bridge >>>>>>>> filter - for that job you'll need to go to switch menu and >>>>>>>> look >>>>>> under >>>>>>>> 'rule' >>>>>>>> tab. >>>>>>>> >>>>>>>> Cheers! >>>>>>>> >>>>>>>> Mike. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Public [mailto:public-bounces@talk.mikrotik.com.au] >>>>>>>>> On >>>>>> Behalf Of >>>>>>>>> Damien Gardner Jnr >>>>>>>>> Sent: Thursday, 13 December 2018 10:04 PM >>>>>>>>> To: MikroTik Australia Public List < > public@talk.mikrotik.com.au> >>>>>>>>> Subject: Re: [MT-AU Public] RouterOS 6.40->6.42 upgrade >>>>>>>>> didn't >>>>>> go so >>>>>>>> well.. >>>>>>>>> How should things work now? :) >>>>>>>>> >>>>>>>>> Ahhhhhh, right! I had assumed it was the same for the new >>>>>> bridges, as >>>>>>>> the >>>>>>>> filter >>>>>>>>> unknown vlans setting on the switch chip config - if you > enabled >>>>>> it, it >>>>>>>> would stop >>>>>>>>> passing vlans you hadn't specifically defined. But yes, if >>>>>>>>> it >>>>>> doesn't >>>>>>>> even turn on >>>>>>>>> any of the bridge vlan functionality until that is ticked, > that'd >>>>>>> explain >>>>>>>> it! >>>>>>>>> >>>>>>>>> So the last piece in the puzzle now... What function in >>>>>>>>> this > new >>>>>> bridge >>>>>>>>> functionality allows vlan translation? i.e. say the port >>>>>> facing my >>>>>>>>> provider has vlan 1275 on it, but I want to receive it into >>>>>>>>> the >>>>>> bridge >>>>>>> as >>>>>>>> vlan 35 (so >>>>>>>>> that it's seen in RouterOS, and all other ports on the >>>>>>>>> switch > as >>>>>> vlan >>>>>>>> 35), >>>>>>>> how do I >>>>>>>>> translate that in the bridge vlan config? With with the >>>>>>>>> switch >>>>>> chip >>>>>>>> config, I'd >>>>>>>>> simply have set ingress and egress translation rules for > ingress >>>>>>>> 1275->35, >>>>>>>> and >>>>>>>>> egress 35->1275 on ether1, and then dealt with it was >>>>>>>>> vlan35 >>>>>> from then >>>>>>>> on. >>>>>>>> Is >>>>>>>>> there a setting in the bridge configuration for that? Or >>>>>>>>> can I >>>>>> just >>>>>>> keep >>>>>>>> using >>>>>>>>> ingress/egress translations on the switch chip for that, >>>>>> alongside the >>>>>>>> new >>>>>>>> bridge >>>>>>>>> configs? >>>>>>>>> >>>>>>>>> On Thu, 13 Dec 2018 at 21:41, Mike Everest >>>>>>>>> <mike@duxtel.com> >>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Damien, >>>>>>>>>> >>>>>>>>>> What you describe seems 'expected' to me - 'vlan-filtering' > is >>>>>>>>>> intended as a switch to enable/disable vlan awareness. >>>>>> Without it >>>>>>>>>> enabled, the bridge essentially doesn't care whether >>>>>>>>>> packets >>>>>> are >>>>>>>>>> tagged or not and forwards them like a normal bridge. >>>>>>>>>> >>>>>>>>>> Unless I misunderstand your comment :-} >>>>>>>>>> >>>>>>>>>> Cheers! >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Public >>>>>>>>>>> [mailto:public-bounces@talk.mikrotik.com.au] > On >>>>>>> Behalf >>>>>>>>>>> Of Damien Gardner Jnr >>>>>>>>>>> Sent: Thursday, 13 December 2018 8:03 PM >>>>>>>>>>> To: MikroTik Australia Public List < >>>>>> public@talk.mikrotik.com.au> >>>>>>>>>>> Subject: Re: [MT-AU Public] RouterOS 6.40->6.42 upgrade >>>>>> didn't go >>>>>>> so >>>>>>>>>> well.. >>>>>>>>>>> How should things work now? :) >>>>>>>>>>> >>>>>>>>>>> Just wanted to follow this up ;) >>>>>>>>>>> >>>>>>>>>>> I've had niggling issues ever since with something of a >>>>>> split brain >>>>>>>>>> network >>>>>>>>>>> - nothing on the wifi ON the main CRS109 has been able to >>>>>> talk to >>>>>>>>>> anything >>>>>>>>>>> plugged into ethernet on the CRS109 (including devices on >>>>>> the wifi >>>>>>>>>>> on the >>>>>>>>>> other >>>>>>>>>>> CRS109's in the house). That's been a little annoying >>>>>>>>>>> for >>>>>>> printing, >>>>>>>>>>> but >>>>>>>>>> we just >>>>>>>>>>> switch to the time capsule's wireless and it works, so >>>>>>>>>>> I've >>>>>> been >>>>>>>> lazy. >>>>>>>>>> Got home >>>>>>>>>>> from work early tonight, and no-one was home for an hour, > so >>>>>>> thought >>>>>>>>>>> I'd >>>>>>>>>> fix it >>>>>>>>>>> for good. >>>>>>>>>>> >>>>>>>>>>> Pulled out all the existing switch chip VLAN configs > (tagged >>>>>> VLANs, >>>>>>>>>> ingress/egress >>>>>>>>>>> translations for untagged ports, etc), and replaced them >>>>>>>>>>> with bridge port pvid and bridge vlan configs. Then > spent >>>>>> an >>>>>>> hour >>>>>>>>>>> pulling my hair out with the entire network not working. >>>>>>>>>>> >>>>>>>>>>> As it turns out, untagged ports will not always get their >>>>>> untagged >>>>>>>>>> ingress >>>>>>>>>> data re- >>>>>>>>>>> mapped into the correct VLAN (it just completely gets >>>>>> dropped) >>>>>>>>>>> unless you >>>>>>>>>> bite >>>>>>>>>>> the bullet and set vlan-filtering=yes on the bridge. >>>>>>>>>>> Then everything >>>>>>>>>> just >>>>>>>>>> starts >>>>>>>>>>> working. Man that's a leap of faith though! I'm NOT > looking >>>>>>>>>>> forward to >>>>>>>>>> doing >>>>>>>>>>> that on the CRS109 in the DC! >>>>>>>>>>> >>>>>>>>>>> Just incase anyone comes up against it :D >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, 8 Nov 2018 at 17:58, Damien Gardner Jnr >>>>>>>>>>> <rendrag@rendrag.net> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thank Guys, >>>>>>>>>>>> >>>>>>>>>>>> So the fun thing is.. I got home, and started trying to >>>>>> figure >>>>>>> out >>>>>>>>>>>> why the kids' VRF wasn't working, and then went >>>>>>>>>>>> 'Hmmmmmm, >>>>>> when I >>>>>>>>>>>> make major bridging changes around a VRF, I occasionally >>>>>> need a >>>>>>>>>>>> reboot....'.. So I rebooted. And everything now works >>>>>> fine, even >>>>>>>>>>>> with RSTP turned on, on the bridge_switchchip bridge, >>>>>>>>>>>> and >>>>>> my vrrp >>>>>>>>>>>> interfaces turned on! :) >>>>>>>>>>>> >>>>>>>>>>>> That said, I'm going to wait to do the 109 in the >>>>>> datacenter >>>>>>> until >>>>>>>>>>>> I have a spare hour in the middle of the night ;) >>>>>>>>>>>> >>>>>>>>>>>> Out of interest, what is the bridging performance likely >>>>>> to be on >>>>>>>>>>>> a >>>>>>>>>>>> CRS109 if I did need to do the old-school routerboard > style >>>>>>>>>>>> vlan-interface->vlan-interface bridging? >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 8 Nov 2018 at 11:06, Mike Everest < > mike@duxtel.com >>>>>>> >>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ouch :-( >>>>>>>>>>>>> >>>>>>>>>>>>> Would you believe.... I did exactly the same thing to > our >>>>>> office >>>>>>>>>>>>> switches just a week ago :-} >>>>>>>>>>>>> >>>>>>>>>>>>> You really only have two choices here: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. roll back to pre-6.42 routerOS and restore a >>>>>>>>>>>>> backup >>>>>> (security >>>>>>>>>>>>> problems can be mitigated by firewall filter to >>>>>>>>>>>>> admin >>>>>>> interfaces) >>>>>>>> 2. >>>>>>>>>>>>> re-configure from scratch >>>>>>>>>>>>> >>>>>>>>>>>>> In the end, I took option 2, and manually >>>>>>>>>>>>> re-created the >>>>>> VLAN >>>>>>>>>>>>> configs using the method described by Paul Julian >>>>>>>>>>>>> in his >>>>>> most >>>>>>>> recent post. >>>>>>>>>>>>> >>>>>>>>>>>>> HOWEVER, note that it is not the optimal way to > configure >>>>>> vlan >>>>>>>>>>>>> support on CRS because new bridge hardware hand-off >>>>>>>>>>>>> does >>>>>> not >>>>>>>>>>>>> (yet) support vlan trunk configurations, and >>>>>>>>>>>>> therefore >>>>>> such >>>>>>>>>>>>> bridges still consume CPU for packet forwarding. >>>>>>>>>>>>> >>>>>>>>>>>>> The correct switch configuration for such >>>>>>>>>>>>> functionality > is >>>>>>>>>>>>> complicated and confusing (it dos my head in every >>>>>>>>>>>>> time >>>>>> ;) so >>>>>>> the >>>>>>>>>>>>> 'easy method' using bridge is usually fastest path >>>>>>>>>>>>> to > get >>>>>> back >>>>>>>>>>>>> online before taking some time to develop the more >>>>>> efficient >>>>>>>>>>>>> switch hardware based configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> Have fun with that :-) >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, Mike. >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Public [mailto: >>>>>> public-bounces@talk.mikrotik.com.au] On >>>>>>>>>>>>>> Behalf Of Damien Gardner Jnr >>>>>>>>>>>>>> Sent: Thursday, 8 November 2018 6:53 AM >>>>>>>>>>>>>> To: MikroTik Australia Public List >>>>>>>>>>>>>> <public@talk.mikrotik.com.au> >>>>>>>>>>>>>> Subject: [MT-AU Public] RouterOS 6.40->6.42 >>>>>>>>>>>>>> upgrade >>>>>> didn't go >>>>>>>>>>>>>> so >>>>>>>>>> well.. >>>>>>>>>>>>> How >>>>>>>>>>>>>> should things work now? :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hey All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have a bunch of CRS109's around the place which >>>>>>>>>>>>>> need >>>>>> to be >>>>>>>>>>>>>> upgraded >>>>>>>>>>>>> from >>>>>>>>>>>>>> 6.40 to 6.42 >>>>>>>>>>>>>> >>>>>>>>>>>>>> The one in the living room which basically just >>>>>>>>>>>>>> does >>>>>> switching >>>>>>>>>>>>>> went >>>>>>>>>>>>> fine. >>>>>>>>>>>>>> Silly me then went 'rad, lets do the core!'.. And >>>>>>>>>>>>>> all >>>>>> hell >>>>>>>>>>>>>> broke >>>>>>>>>> loose. >>>>>>>>>>>>>> After the upgrade, there was no bridge1 >>>>>>>>>>>>>> automatically >>>>>>> created, >>>>>>>>>>>>>> and all >>>>>>>>>>>>> my >>>>>>>>>>>>> vlan >>>>>>>>>>>>>> interfaces were still on ether2-master. >>>>>>>>>>>>>> >>>>>>>>>>>>>> After much googling on my phone, and messing >>>>>>>>>>>>>> about, I >>>>>> have it >>>>>>>>>>>>>> mostly >>>>>>>>>>>>> working, >>>>>>>>>>>>>> WITH RSTP turned off on the bridge I had to >>>>>>>>>>>>>> create, > and >>>>>> with >>>>>>> my >>>>>>>>>>>>>> VRRP >>>>>>>>>>>>> interfaces >>>>>>>>>>>>>> shutdown, and the IP's from them moved back to >>>>>>>>>>>>>> the >>>>>> bridges >>>>>>> they >>>>>>>>>>>>>> live >>>>>>>>>> on. >>>>>>>>>>>>>> However things are still quite hinkey, so I'm > wondering >>>>>> how >>>>>>>>>>>>>> things >>>>>>>>>>>>> SHOULD >>>>>>>>>>>>> be >>>>>>>>>>>>>> setup post 6.41? >>>>>>>>>>>>>> >>>>>>>>>>>>>> So I currently have: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + bridge_switchchip >>>>>>>>>>>>>> - vlan86 >>>>>>>>>>>>>> - vlan87 >>>>>>>>>>>>>> - vlan88 >>>>>>>>>>>>>> - vlan98 >>>>>>>>>>>>>> - vlan99 >>>>>>>>>>>>>> - vlan100 >>>>>>>>>>>>>> - vlan101 >>>>>>>>>>>>>> - vlan102 >>>>>>>>>>>>>> All ports are members of bridge_switchchip >>>>>>>>>>>>>> >>>>>>>>>>>>>> vlan100, is then a port in bridge_local, as >>>>>>>>>>>>>> that's our >>>>>> local >>>>>>>>>>>>>> LAN along >>>>>>>>>>>>> with three >>>>>>>>>>>>>> wifi virtual-interfaces >>>>>>>>>>>>>> vlan102 is a port in bridge_vlan102, as that's >>>>>>>>>>>>>> the >>>>>> kids' LAN >>>>>>>>>>>>>> along with >>>>>>>>>>>>> their wifi >>>>>>>>>>>>>> virtual-interface. it's also in a VRF along with >>>>>>>>>>>>>> one >>>>>> of the >>>>>>>>>>>>>> two pppoe >>>>>>>>>>>>> dialers on >>>>>>>>>>>>>> this CRS >>>>>>>>>>>>>> >>>>>>>>>>>>>> The switch chip is then also doing a bunch of >>>>>>>>>>>>>> vlan >>>>>> rules: >>>>>>>>>>>>>> vlan87: ether1,2,5,6,cpu >>>>>>>>>>>>>> vlan98: ether1,5,cpu >>>>>>>>>>>>>> vlan99: ether1,5,cpu >>>>>>>>>>>>>> vlan100: ethernet1-8,cpu >>>>>>>>>>>>>> vlan101: ether1-3,ether5-7,cpu >>>>>>>>>>>>>> vlan102: ether1,2,4,7,cpu >>>>>>>>>>>>>> >>>>>>>>>>>>>> And it's also translating vlan100 to native vlan >>>>>>>>>>>>>> on >>>>>> ether2-5 >>>>>>>>>>>>>> >>>>>>>>>>>>>> SO... Pre 6.41, I simply had my vlan interfaces >>>>>>>>>>>>>> on > the >>>>>> master >>>>>>>>>>>>>> port, had >>>>>>>>>>>>> all my >>>>>>>>>>>>>> interfaces as slaves, and then configured my vlan >>>>>> mappings per >>>>>>>>>>>>>> port on >>>>>>>>>>>>> the >>>>>>>>>>>>>> switch chip. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I now have a bridge with all ports in it, and >>>>>>>>>>>>>> then >>>>>> vlans under >>>>>>>>>>>>>> that >>>>>>>>>>>>> bridg.e >>>>>>>>>>>>>> However this seems to be causing problems since I >>>>>>>>>>>>>> have >>>>>> some of >>>>>>>>>>>>>> those >>>>>>>>>>>>> vlans >>>>>>>>>>>>> in >>>>>>>>>>>>>> bridges themselves? Disabling RSTP on >>>>>> bridge_switchchip let >>>>>>>>>>>>>> most things >>>>>>>>>>>>> talk to >>>>>>>>>>>>>> most other things, although the kids VRF is not > passing >>>>>>> traffic >>>>>>>>>>>>>> as >>>>>>>>>>>>> yet. I >>>>>>>>>>>>> haven't >>>>>>>>>>>>>> shoved my own test box onto that network to >>>>>>>>>>>>>> diagnose > it >>>>>> yet >>>>>>>> though. >>>>>>>>>>>>>> >>>>>>>>>>>>>> How SHOULD I be doing this? Should I be creating >>>>>> multiple >>>>>>>>>>>>>> bridge_switchip_vlanblah bridges, each with its >>>>>>>>>>>>>> own >>>>>> vlanid >>>>>>> set? >>>>>>>>>>>>>> And only >>>>>>>>>>>>> add >>>>>>>>>>>>>> the interfaces that should have those vlans to >>>>>>>>>>>>>> that >>>>>> bridge? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Or is all this weirdness just a hassle with >>>>>>>>>>>>>> 6.42.9, > and >>>>>> I >>>>>>>>>>>>>> should come >>>>>>>>>>>>> off >>>>>>>>>>>>> bugfix, >>>>>>>>>>>>>> and go to release? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Damien >>>>>>>>>>>>>> (Pulling my hair out, and considering pulling the >>>>>> config off >>>>>>> my >>>>>>>>>>>>>> core >>>>>>>>>>>>> CRS, >>>>>>>>>>>>> and >>>>>>>>>>>>>> throwing it on the one in the garage that hasn't >>>>>>>>>>>>>> been >>>>>> upgraded >>>>>>>>>>>>>> as >>>>>>>>>>>>>> yet!!!) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust >>>>>>>>>>>>>> rendrag@rendrag.net - http://www.rendrag.net/ >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> We rode on the winds of the rising storm, We ran >>>>>>>>>>>>>> to > the >>>>>>> sounds >>>>>>>>>>>>>> of >>>>>>>>>>>>> thunder. >>>>>>>>>>>>>> We danced among the lightning bolts, and tore >>>>>>>>>>>>>> the > world >>>>>>>>>>>>>> asunder > _______________________________________________ >>>>>>>>>>>>>> Public mailing list Public@talk.mikrotik.com.au >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikro >>>>>>> tik >>>>>>>>>>>>> .com >>>>>>>>>>>>> .au >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Public mailing list Public@talk.mikrotik.com.au >>>>>>>>>>>>> >>>>>>> http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikro >>>>>>> tik >>>>>>>>>>>>> .com >>>>>>>>>>>>> .au >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Damien Gardner Jnr >>>>>>>>>>>> VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - >>>>>>>>>>>> http://www.rendrag.net/ >>>>>>>>>>>> -- >>>>>>>>>>>> We rode on the winds of the rising storm, We ran to >>>>>>>>>>>> the >>>>>> sounds >>>>>>> of >>>>>>>>>>>> thunder. >>>>>>>>>>>> We danced among the lightning bolts, and tore the >>>>>>>>>>>> world >>>>>> asunder >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Damien Gardner Jnr >>>>>>>>>>> VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - >>>>>>>>>>> http://www.rendrag.net/ >>>>>>>>>>> -- >>>>>>>>>>> We rode on the winds of the rising storm, We ran to >>>>>>>>>>> the >>>>>> sounds of >>>>>>>>>> thunder. >>>>>>>>>>> We danced among the lightning bolts, and tore the >>>>>>>>>>> world >>>>>> asunder >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Public mailing list >>>>>>>>>>> Public@talk.mikrotik.com.au >>>>>>>>>>> >>>>>>> > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co >>>>>>>>>>> m.au >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Public mailing list >>>>>>>>>> Public@talk.mikrotik.com.au >>>>>>>>>> >>>>>>> >>>>>> > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. >>>>>>>>>> au >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Damien Gardner Jnr >>>>>>>>> VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - >>>>>>>>> http://www.rendrag.net/ >>>>>>>>> -- >>>>>>>>> We rode on the winds of the rising storm, We ran to the >>>>>>>>> sounds >>>>>> of >>>>>>>> thunder. >>>>>>>>> We danced among the lightning bolts, and tore the world >>>>>>>>> asunder _______________________________________________ >>>>>>>>> Public mailing list >>>>>>>>> Public@talk.mikrotik.com.au >>>>>>>>> >>>>>>> >>>>>> > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > au >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Public mailing list >>>>>>>> Public@talk.mikrotik.com.au >>>>>>>> >>>>>> > http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. > au >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Damien Gardner Jnr >>>>>>> VK2TDG. Dip EE. GradIEAust >>>>>>> rendrag@rendrag.net - http://www.rendrag.net/ >>>>>>> -- >>>>>>> We rode on the winds of the rising storm, We ran to the >>>>>>> sounds of thunder. >>>>>>> We danced among the lightning bolts, and tore the world >>>>>>> asunder _______________________________________________ >>>>>>> Public mailing list >>>>>>> Public@talk.mikrotik.com.au >>>>>>> >>>>>> >
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> <https://www.upandrunningtech.com.au> >>>>>> _______________________________________________ >>>>>> Public mailing list >>>>>> Public@talk.mikrotik.com.au >>>>>> >>>>>> >
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
>>>>>> >>>>> >>>> >>>> -- >>>> >>>> Damien Gardner Jnr >>>> VK2TDG. Dip EE. GradIEAust >>>> rendrag@rendrag.net - http://www.rendrag.net/ >>>> -- >>>> We rode on the winds of the rising storm, >>>> We ran to the sounds of thunder. >>>> We danced among the lightning bolts, >>>> and tore the world asunder >>>> >>> >>> >>> -- >>> >>> Damien Gardner Jnr >>> VK2TDG. Dip EE. GradIEAust >>> rendrag@rendrag.net - http://www.rendrag.net/ >>> -- >>> We rode on the winds of the rising storm, >>> We ran to the sounds of thunder. >>> We danced among the lightning bolts, >>> and tore the world asunder >>> >> >> >> -- >> >> Damien Gardner Jnr >> VK2TDG. Dip EE. GradIEAust >> rendrag@rendrag.net - http://www.rendrag.net/ >> -- >> We rode on the winds of the rising storm, >> We ran to the sounds of thunder. >> We danced among the lightning bolts, >> and tore the world asunder >> > > > -- > <https://www.upandrunningtech.com.au> > _______________________________________________ > Public mailing list > Public@talk.mikrotik.com.au >
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
>
--
Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of thunder. We danced among the lightning bolts, and tore the world asunder _______________________________________________ Public mailing list Public@talk.mikrotik.com.au
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
--
Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of thunder. We danced among the lightning bolts, and tore the world asunder _______________________________________________ Public mailing list Public@talk.mikrotik.com.au
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of thunder. We danced among the lightning bolts, and tore the world asunder