User experience - ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2

I made a comment on VDSL SFP Bridge Modem - #39 by andre - Turris Omnia - Turris forum

I just bridge the sfp into a management vlan and have the windows box see that)

and @anon50890781 asked me to elaborate.
So there an example how I have set it up on an test rig.

First keep in mind what the DSL SFP really is, a DSL modem connected to an ethernet port condensed into an SFP. Therefore to talk to the modem (for stats) you need to address it by using the modem’s MAC address (the one printed on the SFP). If you would use the address of eth1 you would address the Omnia.
In addition note that this is all L2, e.g. no IP/routing involved (the windows box in my example doesn’t have an IP address at all).
Therefore a “simple” bridge will get the result required because a packet with an destination MAC the bridge doesn’t know yet (when the first packet from the Windows box to the modem arrives) will be flooded onto all bridge ports. The bridge will learn where the MAC is when the response from the modem arrives and then send it out the correct port without flooding. (normal switch/bridge principles).

Now to the test setup for illustration.

Setup Overview

I started of with an factory reset Omnia with “current” aka 3.11.2.
Then I deleted some unnecessary stuff plus reconfigured the switch into tagged mode by:

  • enabled VLAN functionality on switch0
  • switched the CPU port into tagged mode
  • removed all other LAN ports from VLAN 1 but LAN0/Port 0 and CPU (tagged mode)
  • replaced eth0 with eth0.1 in the “LAN” interface definition
    Note: only “apply” after all the last step or you will lose connectivity
    In this way I’m free to use all other ports assigning them to other then the default vlan.

Next I set up the config the the DSL and SFP so that the windows box connected to LAN1 was able to talk to the modem inside the SFP and set up an example PPPoE connection on VLAN 7 via the modem. I picked VLAN 111 as for sfp management.

  • added an “SFP” interface as eth1 (SFP port) for visibility, not really required
  • changed the “WAN” interface definition to use eth1.7 (VLAN 7 on SFP port) and PPPoE
  • created new VLAN 111 on switch0 and added LAN1/Port 1 (the one the windows box is connected to)
  • added an “SFPMGT” network interface bridging eth1 (the SFP port) and eth0.111
    Apply and it started working.
    Note that the bridge needs to be “up” (ifconfig br-sfpmgt up) or it will not pass traffic. OpenWRT sometimes takes “unmanaged” as meaning not to up the interface. In that case I usually assign an random IP (unused private) to it.

The net result is below

LUCI switch0 config

  • Port 0 (on VLAN 1): Client device which can browse the internet via the Omnia
  • Port 1 (on VLAN 111): Windows host with the DSLMonitor software running which can only access the modem inside the SFP
  • Port 5 (tagged): CPU port between switch and Omnia CPU
  • Port 6 (VLAN 2): 2nd CPU port left unchanged
swconfig dev switch0 show output
root@turris:/etc/config# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
Port 0:
        mask: 0x0000: (0)
        qmode: 3
        pvid: 1
        link: port:0 link:up speed:1000baseT full-duplex
Port 1:
        mask: 0x0000: (1)
        qmode: 3
        pvid: 111
        link: port:1 link:up speed:1000baseT full-duplex
Port 2:
        mask: 0x0000: (2)
        qmode: 0
        pvid: 0
        link: port:2 link:down
Port 3:
        mask: 0x0000: (3)
        qmode: 0
        pvid: 0
        link: port:3 link:down
Port 4:
        mask: 0x0000: (4)
        qmode: 3
        pvid: 2
        link: port:4 link:down
Port 5:
        mask: 0x0000: (5)
        qmode: 3
        pvid: 0
        link: port:5 link:up speed:1000baseT full-duplex
Port 6:
        mask: 0x0000: (6)
        qmode: 3
        pvid: 2
        link: port:6 link:up speed:1000baseT full-duplex
VLAN 1:
        port_based: 0
        vid: 1
        ports: 0 5t
VLAN 2:
        port_based: 0
        vid: 2
        ports: 4 6
VLAN 3:
        port_based: 0
        vid: 111
        ports: 1 5t
root@turris:/etc/config#
LUCI Interfaces overview

LUCI interface SFPMGT general

dsl-test-luci-sfpmgt-general

LUCI interface SFPMGT physical

/etc/config/network file content
root@turris:/etc/config# cat network    

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdad:76d0:3276::/48'

config interface 'lan'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option _orig_ifname 'eth0 eth2 radio0.network1 radio1.network1'
        option _orig_bridge 'true'
        option ifname 'eth0.1'

config interface 'wan'
        option _orig_ifname 'eth1'
        option _orig_bridge 'false'
        option ifname 'eth1.7'
        option proto 'pppoe'
        option username 'hello'
        option password 'world'
        option ipv6 'auto'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 5t'
        option vid '1'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '4 6'
        option vid '2'

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option ports '1 5t'
        option vid '111'

config interface 'sfp'
        option proto 'none'
        option ifname 'eth1'

config interface 'sfpmgt'
        option ifname 'eth0.111 eth1'
        option _orig_ifname 'eth0.111'
        option _orig_bridge 'false'
        option proto 'none'
        option type 'bridge'

root@turris:/etc/config#
DSLMonitor output

Any questions are welcome.
Just a warning, don’t bridge the SFP onto your standard internal network. After all whatever is visible to the modem will be visible to the remote end.

3 Likes

Excellent write up! :+1:

One thing I am not comprehending is the extra step with the bridging. To my humble understanding the switch does flood as well to any client on the same vlan id. But then it lacks the intelligence to deal with responses and that is where the bridge/kernel comes in?

No, as far as I know (and shown there https://doc.turris.cz/doc/en/howto/vlan_settings_omnia ) the SFP/WAN port is connected to the CPU directly (not a switch port on the switch) and the only way going from LANX to SFP is via CPU because the switch has no “wire” to the SFP/WAN.
Therefore the switch floods it to the CPU port and the CPU bridge then floods it to it’s directly connected connect SFP.
In a way the packet from the windows box travels via two connected switches. So similarly to chaining two desktop switches with the modem connected to one and the windows box to the other.

The ALLNET support clarified on Super-Vectoring which apparently is not downward compatible to VDSL.
They might be looking into a new unit of this size that supports g.fast which is said to be downward compatible.

Some reference design seems to be existing already since '15/'16 but I haven’t found yet an actual unit in retail.

https://www.proscend.com/en-gb/product/sfp/190t.html
http://www.sckipio.com/first-gfast-sfp-design-announced/
http://www.methode.com/documents/technicallibrary/Marketing Data sheet%20 DM7087 G.Fast Rev 4p1.pdf

Yep, waiting for those for a while too to upgrade my connectivity (can’t lay fibre or copper down but got a nice phone line between floors of a building).

Pardon my ignorance but where/how is VLAN 7 achieved with

config interface 'sfp'
        option proto 'none'
        option ifname 'eth1'

Not with that one. That just gives “eth1” a nice name of “sfp”. I think I could delete that definition with no effect.

The one with vlan 7 on the sfp is there:

The way to do that in the UI is to tick “custom interface” on the “physical settings” tab and type “eth1.7” into the text box.

If I do that wan is not connecting and the log showing

err pppd[20618]: Unable to complete PPPoE Discovery.

wan pppoe settings
config interface 'wan'
	option proto 'pppoe'
	option username ''
	option password ''
	option peerdns '0'
	option zone 'wan'
	option zone_dslite 'wan'
	option zone_map 'wan'
	option zone_464xlat 'wan'
	option ipv6 '1'
	option ifname 'eth1.7'
	option keepalive '2 5'

config interface 'wan6'
	option ifname '@wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '0'

No issue with eth1. Is eth1.7 sending a vlan tag 7 to the ISP?

Yes, all traffic from/to eth1.7 is expected to have a vlan id (tag) with value 7.
If eth1 works it would imply that your ISP runs the pppoe untagged and not within some vlan.
In that case the pppoe would go onto the bridge SFPMGT in my example. Note that in that case the monitoring client (windows box) would see part of the pppoe traffic too then.

Your ISP’s connectivity instructions including this vlan id (tag) with value 7 then and you did not just pulled that out of the blue? My ISP never mentioned anything about such vlan tag.

VLAN-tag 7 is in Germany for example used by Deutsche Telekom (and therefore for all resellers of their VDSL/Super Vectoring(?)- connections).
Edit: Can be found on Wikipedia :nerd_face:

1 Like

Well, good to know that it is particular to DT but apparently not necessarily a common standard a/o deployed by other ISP

Do you mean tag 7? Or do you mean tagging in general? If i remember correctly, the Switzerland’s init7-company uses also tagging (but for fibre traffic).

In a way both. Suppose that tag 7 is specific to DT and not a standard digit for tagging ISP per se.
And tagging in general deployed by ISP does not seem to be common industry standard either, or is it?

With the switch from the old BRAS access servers (to terminate the PPPoE tunnel) to the new more decentralized/closer BNG access servers, DT now also requires users still on ADSL to use VLAN7, so this is not a question of the specific dsl-tech but whether a link is still on the old platform or migrated to the new one (almost all links should be on the new platform by now).

Exactly, there is no default correct VLAN tag to use that will work with all ISPs that require VLAN tags in the first place. DT just happens to use VLAN7 (in the past they also used an additional VLAN8 for IPTV on some links).

VLAN tags them selves are standardized, but whether an ISP uses VLANs in its access network or not is not standardized, but a decision each ISP needs to evaluate for themselves.

Now that dsl_monitor working directly via the TO, thanks to @andre, I ought to

share for comparison

@anon50890781 that is interesting, it shows “META” as peer vendor id (profile / peer vendor id). I had expected so see the id of the peer and I’m pretty sure your peer isn’t Metanoia. That feels like a bug but good to know.

Sorry I had forgot to mention that I emulated the common DT setup with vlan 7 for internet.
For example Inode in Austria uses (at least when I was using them) vlan 31 with dhcp direct with no PPPoE.
Similarly most of UK uses vlan 101 with PPPoE.

The use of VLANs are very common (but not mandatory) to segregate services (Data/IPTV/VoIP/management). This is the same as PPPoE, it is used a lot so authenticate/terminate a user while some are happy with vlan segregation/identification only.

That or out of privacy concerns it is a (declared design) feature :slight_smile:

If you scroll up the thread to User experience - ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2 - #66 by seiichiro0185 - Omnia HW tweaks - Turris forum you will find the same on a screenshot posted by another user.

Beginner’s question: Could I expect it will work in Czech VDSL networks?

Do you recommend where to buy it and expect easy return if it will not work?