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.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
--
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