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