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