CRS-109, Vlan Translations, and SFP's.. Am I missing something?
Hi Folks, (Sorry, this is a bit long, but hoping I'm just missing something bleedingly obvious..) Playing with one of the VDSL SFP's this evening, working quite nicely. However hitting a weird snag. On the Huawei HG658 i was using, I had vlan100 set on the PTM bridge, so was simply doing ingress/egress translations of vlan 0 to vlan 99 on the switch chip in the CRS109. (Vlan100 is already in use in my network, so my PPPOE bridge network ended up on vlan 99) Something like: /interface ethernet switch vlan add ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99 /interface ethernet switch egress-vlan-tag add tagged-ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99 /interface ethernet switch egress-vlan-translation add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=0 ports=ether2-huawei-bridge service-vlan-format=untagged-or-tagged /interface ethernet switch ingress-vlan-translation add new-customer-vid=99 ports=ether2-huawei-bridge That way the bridged VDSL traffic on native VLAN from the huawei ends up in VLAN99 on the RouterOS CPU interface (And ether1-master-local which goes to my other CRS-109 which sometimes brings up a separate PPPOE session). Plugging in the VDSL SFP, I knew I needed to do the vlan 100 tagging myself, so figured I can simply do VLAN translations 100<>99, instead of 0<>99 on the sfp1-slave-local interface (ether1-master-local is master port to all ports on the CRS-109). I'm using similar to this on another CRS at work doing Vlan translations on my uplink port, and it's working fine on the ether1 port.. Is the SFP port special in any way? Adding the appropriate rules similar to above to add vlan 99 being re-written as vlan 100 on SFP side as below, doesn't end up with any traffic passing: /interface ethernet switch vlan add ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local,switch1-cpu vlan-id=99 /interface ethernet switch egress-vlan-tag add tagged-ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local,switch1-cpu vlan-id=99 /interface ethernet switch egress-vlan-translation add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=100 ports=sfp1-slave-local bridge service-vlan-format=untagged-or-tagged /interface ethernet switch ingress-vlan-translation add customer-vid=100 new-customer-vid=99 ports=sfp1-slave-local I'd have thought this SHOULD work? If I pull the SFP1 interface out of the switch chip (i.e. master=none), and create vlan100 under it, and then assign the pppoe interface to sfp1_vlan100, it comes up instantly. If I leave it IN the switch chip, and instead just add vlan 100 to sfp port, and then use vlan100 for the pppoe dialler, it also works - but I don't want PPPOE traffic on vlan100 internally, as that's the LAN.. Is this maybe a hiccup with the CRS109's switch chip vlan translations, that you can't do translations between two vlan ID's which it's using internally or somesuch? Thanks, Damien -- 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
Answering my own question ;) That took a lot of pain (Silly me upgraded to 6.41 to see if that helped things....), but after dragging out my spare CRS109 and a couple of fibre SFP's and labbing it up, I did figure out the issue.. It seems that in the translation rules, customer-vid=0 is not the same as customer-vid=''.... There was an earlier rule in my ingress-translation-rules which was matching '', not 0, to tag them onto a different vlan for testing (was wanting to see if I could find a management interface at all..). But it seems that vid='' performs a wildcard match, so the more specific rule for customer-vid=100 was being ignored completely. Working perfectly now! On 30 January 2018 at 19:00, Damien Gardner Jnr <rendrag@rendrag.net> wrote:
Hi Folks,
(Sorry, this is a bit long, but hoping I'm just missing something bleedingly obvious..)
Playing with one of the VDSL SFP's this evening, working quite nicely. However hitting a weird snag. On the Huawei HG658 i was using, I had vlan100 set on the PTM bridge, so was simply doing ingress/egress translations of vlan 0 to vlan 99 on the switch chip in the CRS109. (Vlan100 is already in use in my network, so my PPPOE bridge network ended up on vlan 99)
Something like: /interface ethernet switch vlan add ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-tag add tagged-ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-translation add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=0 ports=ether2-huawei-bridge service-vlan-format=untagged- or-tagged
/interface ethernet switch ingress-vlan-translation add new-customer-vid=99 ports=ether2-huawei-bridge
That way the bridged VDSL traffic on native VLAN from the huawei ends up in VLAN99 on the RouterOS CPU interface (And ether1-master-local which goes to my other CRS-109 which sometimes brings up a separate PPPOE session).
Plugging in the VDSL SFP, I knew I needed to do the vlan 100 tagging myself, so figured I can simply do VLAN translations 100<>99, instead of 0<>99 on the sfp1-slave-local interface (ether1-master-local is master port to all ports on the CRS-109). I'm using similar to this on another CRS at work doing Vlan translations on my uplink port, and it's working fine on the ether1 port.. Is the SFP port special in any way?
Adding the appropriate rules similar to above to add vlan 99 being re-written as vlan 100 on SFP side as below, doesn't end up with any traffic passing:
/interface ethernet switch vlan
add ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-tag
add tagged-ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-translation
add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=100 ports=sfp1-slave-local bridge service-vlan-format=untagged-or-tagged
/interface ethernet switch ingress-vlan-translation
add customer-vid=100 new-customer-vid=99 ports=sfp1-slave-local
I'd have thought this SHOULD work?
If I pull the SFP1 interface out of the switch chip (i.e. master=none), and create vlan100 under it, and then assign the pppoe interface to sfp1_vlan100, it comes up instantly.
If I leave it IN the switch chip, and instead just add vlan 100 to sfp port, and then use vlan100 for the pppoe dialler, it also works - but I don't want PPPOE traffic on vlan100 internally, as that's the LAN..
Is this maybe a hiccup with the CRS109's switch chip vlan translations, that you can't do translations between two vlan ID's which it's using internally or somesuch?
Thanks,
Damien
--
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: Tuesday, 30 January 2018 8:46 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] CRS-109, Vlan Translations, and SFP's.. Am I missing something?
Answering my own question ;)
That took a lot of pain (Silly me upgraded to 6.41 to see if that helped things....), but after dragging out my spare CRS109 and a couple of fibre SFP's and labbing it up, I did figure out the issue..
It seems that in the translation rules, customer-vid=0 is not the same as customer-vid=''.... There was an earlier rule in my ingress-translation-rules which was matching '', not 0, to tag them onto a different vlan for testing (was wanting to see if I could find a management interface at all..). But it seems that vid='' performs a wildcard match, so the more specific rule for customer-vid=100 was being ignored completely.
Working perfectly now!
On 30 January 2018 at 19:00, Damien Gardner Jnr <rendrag@rendrag.net> wrote:
Hi Folks,
(Sorry, this is a bit long, but hoping I'm just missing something bleedingly obvious..)
Playing with one of the VDSL SFP's this evening, working quite nicely. However hitting a weird snag. On the Huawei HG658 i was using, I had vlan100 set on the PTM bridge, so was simply doing ingress/egress translations of vlan 0 to vlan 99 on the switch chip in the CRS109. (Vlan100 is already in use in my network, so my PPPOE bridge network ended up on vlan 99)
Something like: /interface ethernet switch vlan add ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-tag add tagged-ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-translation add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=0 ports=ether2-huawei-bridge service-vlan-format=untagged- or-tagged
/interface ethernet switch ingress-vlan-translation add new-customer-vid=99 ports=ether2-huawei-bridge
That way the bridged VDSL traffic on native VLAN from the huawei ends up in VLAN99 on the RouterOS CPU interface (And ether1-master-local which goes to my other CRS-109 which sometimes brings up a separate PPPOE session).
Plugging in the VDSL SFP, I knew I needed to do the vlan 100 tagging myself, so figured I can simply do VLAN translations 100<>99, instead of 0<>99 on the sfp1-slave-local interface (ether1-master-local is master port to all ports on the CRS-109). I'm using similar to this on another CRS at work doing Vlan translations on my uplink port, and it's working fine on the ether1 port.. Is the SFP port special in any way?
Adding the appropriate rules similar to above to add vlan 99 being re-written as vlan 100 on SFP side as below, doesn't end up with any traffic passing:
/interface ethernet switch vlan
add ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local,switch 1-cpu vlan-id=99
/interface ethernet switch egress-vlan-tag
add tagged-ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local ,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-translation
add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=100 ports=sfp1-slave-local bridge service-vlan-format=untagged-or-tagged
/interface ethernet switch ingress-vlan-translation
add customer-vid=100 new-customer-vid=99 ports=sfp1-slave-local
I'd have thought this SHOULD work?
If I pull the SFP1 interface out of the switch chip (i.e. master=none), and create vlan100 under it, and then assign the pppoe interface to sfp1_vlan100, it comes up instantly.
If I leave it IN the switch chip, and instead just add vlan 100 to sfp port, and then use vlan100 for the pppoe dialler, it also works - but I don't want PPPOE traffic on vlan100 internally, as that's the LAN..
Is this maybe a hiccup with the CRS109's switch chip vlan translations, that you can't do translations between two vlan ID's which it's using internally or somesuch?
Thanks,
Damien
--
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
Thanks for the post/s! Who would have guessed that blank vlan ID means 'all'?! I've filed that little gem away in the back of my mind for that day when I need to match 'all' vlan IDs :-D (irony observed ;) 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
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Tuesday, 30 January 2018 8:46 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] CRS-109, Vlan Translations, and SFP's.. Am I missing something?
Answering my own question ;)
That took a lot of pain (Silly me upgraded to 6.41 to see if that helped things....), but after dragging out my spare CRS109 and a couple of fibre SFP's and labbing it up, I did figure out the issue..
It seems that in the translation rules, customer-vid=0 is not the same as customer-vid=''.... There was an earlier rule in my ingress-translation-rules which was matching '', not 0, to tag them onto a different vlan for testing (was wanting to see if I could find a management interface at all..). But it seems that vid='' performs a wildcard match, so the more specific rule for customer-vid=100 was being ignored completely.
Working perfectly now!
On 30 January 2018 at 19:00, Damien Gardner Jnr <rendrag@rendrag.net> wrote:
Hi Folks,
(Sorry, this is a bit long, but hoping I'm just missing something bleedingly obvious..)
Playing with one of the VDSL SFP's this evening, working quite nicely. However hitting a weird snag. On the Huawei HG658 i was using, I had vlan100 set on the PTM bridge, so was simply doing ingress/egress translations of vlan 0 to vlan 99 on the switch chip in the CRS109. (Vlan100 is already in use in my network, so my PPPOE bridge network ended up on vlan 99)
Something like: /interface ethernet switch vlan add ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-tag add tagged-ports=ether1-master-local,ether2-huawei-bridge,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-translation add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=0 ports=ether2-huawei-bridge service-vlan-format=untagged- or-tagged
/interface ethernet switch ingress-vlan-translation add new-customer-vid=99 ports=ether2-huawei-bridge
That way the bridged VDSL traffic on native VLAN from the huawei ends up in VLAN99 on the RouterOS CPU interface (And ether1-master-local which goes to my other CRS-109 which sometimes brings up a separate PPPOE session).
Plugging in the VDSL SFP, I knew I needed to do the vlan 100 tagging myself, so figured I can simply do VLAN translations 100<>99, instead of 0<>99 on the sfp1-slave-local interface (ether1-master-local is master port to all ports on the CRS-109). I'm using similar to this on another CRS at work doing Vlan translations on my uplink port, and it's working fine on the ether1 port.. Is the SFP port special in any way?
Adding the appropriate rules similar to above to add vlan 99 being re-written as vlan 100 on SFP side as below, doesn't end up with any traffic passing:
/interface ethernet switch vlan
add ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local,switch 1-cpu vlan-id=99
/interface ethernet switch egress-vlan-tag
add tagged-ports=ether1-master-local,ether2-huawei-bridge,sfp1-slave-local ,switch1-cpu vlan-id=99
/interface ethernet switch egress-vlan-translation
add customer-vid=99 customer-vlan-format=untagged-or-tagged new-customer-vid=100 ports=sfp1-slave-local bridge service-vlan-format=untagged-or-tagged
/interface ethernet switch ingress-vlan-translation
add customer-vid=100 new-customer-vid=99 ports=sfp1-slave-local
I'd have thought this SHOULD work?
If I pull the SFP1 interface out of the switch chip (i.e. master=none), and create vlan100 under it, and then assign the pppoe interface to sfp1_vlan100, it comes up instantly.
If I leave it IN the switch chip, and instead just add vlan 100 to sfp port, and then use vlan100 for the pppoe dialler, it also works - but I don't want PPPOE traffic on vlan100 internally, as that's the LAN..
Is this maybe a hiccup with the CRS109's switch chip vlan translations, that you can't do translations between two vlan ID's which it's using internally or somesuch?
Thanks,
Damien
--
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
https://www.mikrotik.com/product/rb951ui-2nd Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Mike Everest <mike@duxtel.com> Sent: Wednesday, January 31, 2018 9:59:21 AM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] CRS-109, Vlan Translations, and SFP's.. Am I missing something? Thanks for the post/s! Who would have guessed that blank vlan ID means 'all'?! I've filed that little gem away in the back of my mind for that day when I need to match 'all' vlan IDs :-D (irony observed ;) 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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Sorry in advance if this is the wrong Forum .. I have a small client in Wetherill Park 2164 who wants some Routing set up on a 750 that I have installe. ( we use them for AAPT SIP trunks but I always reserve port 1 in case they want to use it as their Internet IF ) This customer wants to use the MT as their Internet connection + set up some VPN's ( which is where i don't have the skill set ) Please email me directly if you want to pick up a new client & I will pass their details onto you to look after
participants (4)
-
Damien Gardner Jnr
-
joel@gotelco.com.au
-
Mike Everest
-
Paul Parnis