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
The Way of the New Bridge obviously didn't translate well in the upgrade especially if you messed with the Switch chip settings (I hear RB4011 doesn't even have a switch chip menu!). You're going to have to manually redo the configurations using the new VLAN and Bridge methods. It's going to be a loooooooooooooong weekend. On Thu, 8 Nov 2018 at 06:56, Damien Gardner Jnr <rendrag@rendrag.net> wrote:
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
HI Damien, In 6.42 there were major changes to the bridge environment, changelogs are your friend there, there is a pretty solid warning on the changelog about bridge and switch changes after upgrading, or the chance of them, and it sounds lke you have been unfortunately enough to be affected by the situation. We haven't had anything break around it but we don't using bridging a lot, mostly just to transport vlans through routers and for loopback adaptors. Your setup sounds really complicated, my understanding of the switch chip, and I don't really use it much, is do your vlans in the switch chip or in a bridge, but it sounds like perhaps you have both operating which might be causing the issues. I would forget the switch chip for the moment and just get everything work in a bridge or bridges, or take the other route but I'm not sure of the best way for that. If you are not actually using it as a switch then maybe just bridging the ports you need is the answer ? Regards Paul -----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 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
Hey Paul, Thanks, I wasn't using bridges at all except for their 'normal' purpose - bridging vlans to wifi - like you would in cisco land ;) - But now it looks like Mikrotik want us to stop using the switch chip (WTF, why did they make us start using it then??), and do our port joinings in bridges again.. But what I think is causing issues is the fact that I have a Mikrotik *switch*, not router, so I have multiple VLAN's on each port, and I also need some of those vlan's bridged to wifi interfaces, so I have bridge with vlans, and some of those vlans are members of bridges.. The switch chip made things fairly clean. I could leave vlans that didn't need to hit RouterOS in the switch chip, and not bring them up to the CPU, or bring them up to the CPU but leave them disabled unless I need to debug something (everything except vlan 99-102 are disabled on mine - vlan 99 is the VDSL bridge from the SFP in the CRS in the living room. 100 is lan, 101 is DMZ being routed from the CRS in the living room on a separate PPPOE session, and 102 is the kids) How you handling bridges on vlans in your environment post 6.41? Or have you not needed to do that yet? I'm not keen on leaving STP disabled :\ Thanks, Damien On Thu, 8 Nov 2018 at 07:08, Paul Julian <paul@buildingconnect.com.au> wrote:
HI Damien,
In 6.42 there were major changes to the bridge environment, changelogs are your friend there, there is a pretty solid warning on the changelog about bridge and switch changes after upgrading, or the chance of them, and it sounds lke you have been unfortunately enough to be affected by the situation. We haven't had anything break around it but we don't using bridging a lot, mostly just to transport vlans through routers and for loopback adaptors.
Your setup sounds really complicated, my understanding of the switch chip, and I don't really use it much, is do your vlans in the switch chip or in a bridge, but it sounds like perhaps you have both operating which might be causing the issues.
I would forget the switch chip for the moment and just get everything work in a bridge or bridges, or take the other route but I'm not sure of the best way for that.
If you are not actually using it as a switch then maybe just bridging the ports you need is the answer ?
Regards Paul
-----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 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
Hi Damien, We just do it pretty simply, basically a VLAN on the outside interface, and VLAN on the inside interface, and a bridge which has both VLAN interfaces as ports on it. No reason you can't put that same VLAN ID on multiple vlan interfaces attached to thernet interfaces and then put all of the VLAN interfaces into a bridge As we work with quite a range of the MT devices using switch chips would have meant we would have two designs, even though VLAN through a bridge is more CPU it's a consistent approach for us whether it's a wireless backhaul link or fibre or anything else really. Don't blame you about the STP bit, our biggest issue at the moment is there seems to be some weird stuff going on with LSA's and OSPF convergence, slowness is a big issue even for a basic link flap. We are just about to start implementing BFD so hopefully that might help. Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Damien Gardner Jnr Sent: Thursday, 8 November 2018 7:20 AM 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? :) Hey Paul, Thanks, I wasn't using bridges at all except for their 'normal' purpose - bridging vlans to wifi - like you would in cisco land ;) - But now it looks like Mikrotik want us to stop using the switch chip (WTF, why did they make us start using it then??), and do our port joinings in bridges again.. But what I think is causing issues is the fact that I have a Mikrotik *switch*, not router, so I have multiple VLAN's on each port, and I also need some of those vlan's bridged to wifi interfaces, so I have bridge with vlans, and some of those vlans are members of bridges.. The switch chip made things fairly clean. I could leave vlans that didn't need to hit RouterOS in the switch chip, and not bring them up to the CPU, or bring them up to the CPU but leave them disabled unless I need to debug something (everything except vlan 99-102 are disabled on mine - vlan 99 is the VDSL bridge from the SFP in the CRS in the living room. 100 is lan, 101 is DMZ being routed from the CRS in the living room on a separate PPPOE session, and 102 is the kids) How you handling bridges on vlans in your environment post 6.41? Or have you not needed to do that yet? I'm not keen on leaving STP disabled :\ Thanks, Damien On Thu, 8 Nov 2018 at 07:08, Paul Julian <paul@buildingconnect.com.au> wrote:
HI Damien,
In 6.42 there were major changes to the bridge environment, changelogs are your friend there, there is a pretty solid warning on the changelog about bridge and switch changes after upgrading, or the chance of them, and it sounds lke you have been unfortunately enough to be affected by the situation. We haven't had anything break around it but we don't using bridging a lot, mostly just to transport vlans through routers and for loopback adaptors.
Your setup sounds really complicated, my understanding of the switch chip, and I don't really use it much, is do your vlans in the switch chip or in a bridge, but it sounds like perhaps you have both operating which might be causing the issues.
I would forget the switch chip for the moment and just get everything work in a bridge or bridges, or take the other route but I'm not sure of the best way for that.
If you are not actually using it as a switch then maybe just bridging the ports you need is the answer ?
Regards Paul
-----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 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 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----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
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
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. their wifi 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
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
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Thursday, 8 November 2018 5:59 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? :)
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.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
Hi Damien, Maybe I should have tried that before re-writing the configs from scratch on our office switches! :-D Bridge performance is 'OK' for CRS109, but a feint shade of capacity with hardware switching (as you would expect ;) https://mikrotik.com/product/CRS109-8G-1S-2HnD-IN#fndtn-testresults Essentially 1Gbps for bridge compared to wire speed for hardware ;) Cheers, Mike. 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
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
-----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
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! 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
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
-----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)
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
How SHOULD I be doing this? Should I be creating multiple bridge_switchip_vlanblah bridges, each with its own vlanid set? And only
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
add 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.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
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. 2. though. 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
-----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)
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
How SHOULD I be doing this? Should I be creating multiple bridge_switchip_vlanblah bridges, each with its own vlanid set? And only
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
add 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.mikrot ik .com .au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrot ik .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
Not sure if it's of any use, but we had a bit of fun with this stuff at the recent MTCRE course and it seemed that the 'untagged' setting did nothing if you were also tagginv vlans on the port unless you also set the PVID - Makes sense, but also doesn't at the same time. Cheers -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Friday, 14 December 2018 1:08 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? :) 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. 2. though. 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
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_Hardware_O... - 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.
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.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
-----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)
_______________________________________________ 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
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_Hardware_O... - 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)
> 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.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
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
- 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
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
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
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
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)
>> 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
>> '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
new bridge printing, thought 2. the 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
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Bridge_Hardware_O... then the 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.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
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
- 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
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
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)
> >> 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
> >> > 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
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Bridge_Hardware_O... then the the 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.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
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_Hardware_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.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.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
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
- 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
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 <
> > > 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
> > > > 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
> > > >> '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
out the 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
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Bridge_Hardware_O... then public@talk.mikrotik.com.au> figure 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.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://download.mikrotik.com/routeros/6.43.7/routeros-mipsbe-6.43.7.npk 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
- 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 <
> > > > 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
> > > > 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
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:
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Bridge_Hardware_O... public@talk.mikrotik.com.au> the wifi figure 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.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
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.npk
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 > >
> - 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 <
> > > 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,
> 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
> > > > > > 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
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
> 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
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Bridge_Hardware_O... public@talk.mikrotik.com.au> that'd style the passing 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.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
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_Hard 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
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_Hard 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
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 the 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 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_Hard 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
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 well.. 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 the 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 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
Ok, so I borrowed an RB951-2n, and an RB2011-2HnD-IN from work for the holidays to do some more in-depth testing, alongside a spare CRS-109-8G-1S-2HnD-IN. Rolled all three back to 6.40.9 and defaulted configuration. Some interesting notes.. 1) CRS* looks to be the only platform which supports vlan-egress* and vlan-ingress* nodes under the switch chip config. Must admit, I'd assumed that was just a standard RouterOS feature, as I couldn't imagine why it *wouldn't* exist, as all our Huawei and Extreme gear at work does it out of the box. - working CRS config https://nextcloud.rendrag.net/index.php/s/tjLNA5WoyfYt7Ae 2) RB951 doesn't work at all for having access ports on something other than the default vlan (i.e. NOT on a vlan at all) - i.e. documentation suggests that the following should do it (and RB2011 works perfectly like this): - nonworking RB951 config: https://nextcloud.rendrag.net/index.php/s/ag3MqjQBnXdmMEK /interface vlan add interface=ether2 name=vlan100 vlan-id=100 /interface ethernet switch port set 1 default-vlan-id=100 vlan-header=always-strip vlan-mode=secure set 2 default-vlan-id=100 vlan-header=always-strip vlan-mode=secure RB2011 works perfectly with the above to drop vlan100 as the untagged vlan onto ether2 and ether3. Ethernet->RouterOS and Wifi->Ethernet work perfectly this way. -> https://nextcloud.rendrag.net/index.php/s/xFFc25ng2Ea2w32 3) If you mistakenly think that 'format NAND' is the fastest way to clear the config on an RB2011, and needed to run netinstall in a windows VM in parallels Desktop on your mac, you want to completely shutdown Parallels, and look for the config.pvs file inside the VM directory, and then look for the PktFilter noded in the XML, and set all three options (PreventPromisc, PreventIpSpoof, and PreventMacSpoof) to 0, then start Parallels back up. That was an hour of my life I want back :D Upgrading the three devices to 6.42.9... The RB2011 works exactly was everyone has suggested things should work. Create a bridge for each vlan, create a vlan under the main bridge, and then put the vlan and the wifi into the vlan-specific bridge. VOILA, works perfectly. -> https://nextcloud.rendrag.net/index.php/s/TBrnmRcxwgpsos6 The RB951 then works correctly. Weirdly, on this platform, your IP can be on EITHER the bridge or the vlan, and still works fine. Also interestingly, the wlan interface can actually be in either bridge, and it can talk to ethernet fine (Neither of these is the case on the RB2011, I went back and checked..). -> https://nextcloud.rendrag.net/index.php/s/aaG8ZGypMSGCaWj The CRS109 Also works correctly, which is interesting! 400mbps between switch ports pushes the CPU to 95%. 80mbps between Wifi and a switch port pushes the CPU to 30%, so would probably be about the same. Has me wondering now why my main CRS109 was falling in a heap at ~20mbps.. I'll re-try reconfiguring the main CRS tomorrow morning :) - https://nextcloud.rendrag.net/index.php/s/aMpzbKxBQpCbcsc If I turn VLAN Filtering *off*, and try to use vlan translations to do customer-vlan=100 new-customer-vlan=0 on egress and vice-versa on ingress on the ether2-5 ports, then wlan-sourced packets are egressing to ethernet still tagged, so looks like a bug with the CRS. - config at https://nextcloud.rendrag.net/index.php/s/6qoRM7xz7bawaEx So question: Is there any point me trying to lodge a bug with Mikrotik? The previous times I've tried to lodge support issues with them (granted, that was 4+ years ago), I haven't even had a reply for six months, and then it has been 'please contact the company you purchased your device through in the first instance'... It seems like a pretty big bug, that would be great to have fixed, as it's basically stopping you doing ethernet->wifi bridging while still maintaining wire speed switching on the CRS1/2 series devices. On Fri, 28 Dec 2018 at 20:02, 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 well.. 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 the 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 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
-- 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
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 well.. 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 the 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 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
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
participants (6)
-
Andrew Radke -
Damien Gardner Jnr -
Dave Browning -
Jason Hecker (Up & Running Tech) -
Mike Everest -
Paul Julian