Kitz Forum
Chat => Tech Chat => Topic started by: burakkucat on March 12, 2022, 07:08:50 PM
-
It was last August, 2021, that I was migrated to a VDSL2 based service by my service provider, TalkTalk. Nothing special; no drama; no fuss.
As is probably well known by forum regulars, I had no great desire or need for such a service. Up until then, my experience of things VDSL2 was gained by setting up local circuits in "The Cattery", often with deliberate faults to see exactly how the service would be degraded.
Last month I decided to take a look at the real, live, service. As TalkTalk use IPoE for all residential services there is a field for a "DHCP Option 60 Vendor ID" string within the service configuration. I use a ZyXEL device as my CPE and, as I assume with all ZyXEL devices, the field is pre-populated with the string "dslforum.org". Having examined the D-Link device that TalkTalk had provided before the service was migrated and concluded that it was essentially junk, I was not going to use it. For fun, I decided to configure my ZyXEL device with "No_TalkTalk_Back_Door" as the DHCP Option 60 Vendor ID string.
The night before the experiment, I laid out the various items I was going to use and connected them all together. They were --
- An unlocked Huawei EchoLife HG612, with GUI, VLAN 301 deleted and QoS turned off.
- A Watchfront Firebrick, FB105, with port 1 mirrored to port 4. (The LAN1 port of the HG612 was connected to port 0 of the FB105. A computer, to perform a Wireshark capture, was connected to port 4 of the FB105.) Port 0 is on the untrusted side of the firewall, whilst ports 1 - 4 are on the trusted side of the firewall.
- My spare, backup, just-in-case, ZyXEL device was configured exactly as the normally used device with the exception that the xDSL interface was disabled and the EWAN interface was enabled. (Port 1 of the FB105 was connected to the EWAN port of the ZyXEL device.)
- A headless Raspberry Pi was connected to the LAN1 port of the ZyXEL device.
On the day of the experiment, the xDSL port of the HG612 was connected to the centralised filter. Then --
- The FB105 was powered on.
- The computer was booted up and a Wireshark capture was started.
- The HG612 was powered on and allowed to synchronise with the cabinet based DSLAM.
- The ZyXEL device was powered on and the flurry of frames captured were closely watched in real-time. First the string "No_TalkTalk_Back_Door" was seen to be passed in the DHCP dialogue. :D (DHCP discovery sent via the WAN interface / DHCP offer received / DHCP accept sent to the gateway which provided the offer / DCHP acknowledgement received from the gateway, with all the usual gubbins.) Then the ZyXEL device synchronised its idea of the date and time with a host from the pool of UK time servers.
- The Raspberry Pi was powered on and, eventually, it too was seen to synchronise its idea of the date and time with a host from the pool of UK time servers.
The Wireshark capture was then ended as, by this time, it had become very uninteresting. I then settled down with a laptop computer and performed my usual, daily, ritual. At the end of the day which, of course, included doing my normal tasks here everything was powered off and disconnected. The usual hardware configuration was then restored.
After considering the results obtained, above, I wondered what would be seen in a Wireshark capture if instead of the HG612 being the VLAN 101 endpoint, the ZyXEL was configured as that VLAN endpoint. A quick ASCII art diagram --
Centralised filter <--> HG612 <--> FB105 <--> ZyXEL device
VDSL2 ^ VLAN 101
& PTM | endpoint.
endpoints. | IPoE endpoint.
monitoring
computer
As can be seen above, I am considering monitoring "outside" of the VLAN. Does anyone have any idea what might be seen? (If anything.) Your opinions & comments will be appreciated, please. :)
[Edited to insert a [hr] separator.]
-
Excellent. What traffic do you expect to see? Anything odd?
-
Does anyone have any idea what might be seen? (If anything.) Your opinions & comments will be appreciated, please. :)
A DHCP discovery with some options set, a DHCP offer and a DHCP acknowledgement. After that Ethernet frames with a destination of the next layer 2 hop and IP of whatever your default gateway is on 101. Unless there's a TR-069 VLAN as well that'll probably be your lot. DSLAM strips any other VLAN tags, modem handles everything not Ethernet.
-
What traffic do you expect to see? Anything odd?
Last question first -- No, nothing odd whatsoever.
First question last -- Initially, the DHCP dialogue with the TalkTalk gateway, followed by my ZyXEL router setting its date & time (from a NTP server from the UK pool) and then all the normal traffic. Once I had seen the first two of those events, everything else was rather boring! There was the usual "ping - pong", "to and froing", between my ZyXEL router and a Juniper router in TalkTalk-land. (E.g. "Who's got X, tell Y". "Who's got Y, tell X". Almost ad infinitum but, logically, terminated when the session was terminated at the end of the day.)
-
A DHCP discovery with some options set, a DHCP offer and a DHCP acknowledgement. After that Ethernet frames with a destination of the next layer 2 hop and IP of whatever your default gateway is on 101. Unless there's a TR-069 VLAN as well that'll probably be your lot. DSLAM strips any other VLAN tags, modem handles everything not Ethernet.
Thank you.
As the novice that I am in such things ( :baby: ) I'll have to perform the experiment to gain some first hand experience. Once performed and the results analysed all should become clear.
[Edited to fix a grammatical mishap.]
-
Following with interest.
-
The second experiment was performed.
Hardware.
[1] <---> [2] <---> [3] <---> [4] <---> [5]
|
|
[6]
[1] NTE5/A and SSFP.
[2] Huawei HG610.
[3] Firebrick FB105.
[4] ZyXEL VMG1312-B10A.
[5] Computer requiring normal Internet access.
[6] Computer to perform the Wireshark package capture.
The Huawei HG610 was configured to be a VDSL2/PTM endpoint. (The HG610 was given a 192.168.1.1 IPv4 address.)
The Firebrick FB105 was configured so that Port 1 (the first port on the trusted side of the firewall) was monitored by Port 4 (the fourth port on the trusted side of the firewall). Port 4 was configured with all normal I/O disabled. (The FB105 was left with its default, "stealth", 217.169.0.1 IPv4 address.)
The ZyXEL VMG1312-B10A had its LAN4 port configured as an EWAN port. The EWAN port was configured for IPoE, with its DHCP Option 60 string set as "No_TalkTalk_Back_Door", and as the VLAN (tagged 101) endpoint. The LAN-side DHCP server was disabled, along with all the other frivolous configuration options. (The VMG1312-B10A was given a 192.168.0.254 IPv4 address.)
The computer requiring normal Internet access was running minimalist configured RHEL7 as OS with a Linux-5.17.1 kernel. (It was given a 192.168.0.10 IPv4 address.)
The computer running the Wireshark (v3.6.3) package capture was given a 192.168.0.60 IPv4 address and had no gateway nor DNS server defined.
Endpoints.
The HG610 was my VDSL2/PTM endpoint with a Huawei MA5603T, in a cabinet (https://www.google.com/maps/@52.2594849,0.7114381,3a,15y,300.41h,82.81t/data=!3m6!1e1!3m4!1siS2tiTgM9XZr-j0FlEmxJg!2e0!7i13312!8i6656) (associated with EABSE P28), as it peer.
The VMG1312-B10A was my VLAN (tagged 101) endpoint but where is its peer? The OLT? The MA5603T? :-\
Cables and Ports.
An Ethernet patch cable linked the LAN1 port of the HG610 to the LAN1 port of the FB105.
An Ethernet patch cable linked the LAN2 port of the FB105 to the EWAN port of the VMG1312-B10A.
An Ethernet patch cable linked the LAN1 port of the VMG1312-B10A to the computer requiring normal Internet access.
An Ethernet patch cable linked the LAN4 port of the FB105 to the computer performing the Wireshark packet capture.
Procedure.
The FB105 was powered on. (It performed its usual "cycling of lights", as a "look at me", whilst waiting for other devices to become active.)
A Wireshark packet capture was started.
The HG610 was powered on and achieved synchronisation with the DSLAM. Frames 1 to 54 were captured.
After approximately five minutes frame 55 was captured.
The VMG1312-B10A was powered on. Frames 56 to 64 were captured.
Following the establishment of the IPoE session, frames 65 to 118 were captured.
Frame 119 & onwards followed the boot of the RHEL7 system.
Having logged into the RHEL7 system, a "ping -c10 kitz.co.uk" command was issued and the process was observed in frame 297 & onwards.
The Wireshark capture was terminated after frame 380.
Observations from the Wireshark Capture.
A display filter of !vlan showed that frames 1 to 52, 54 to 57, 61 & 117 matched.
A display filter of vlan showed that frames 53, 58 to 60, 62 to 116 & 118 to 380 matched.
A display filter of !vlan && dhcp showed nothing.
A display filter of vlan && dhcp showed that frames 58 to 60, 62, 148 to 157, 359 & 360 matched.
A display filter of dhcp showed that frames 58 to 60, 62, 148 to 157, 359 & 360 matched, as expected by sight of the above.
Concluding Comments.
There are many other details that can be teased out of the capture with the application of appropriate display filters. For example, the synchronisation of the computer clock with an NTP server.
To my eye, there is nothing outstanding nor confidential. In view of the latter two words, the Wireshark capture can be provided to anyone who is interested in taking a look. Just send me a PM, detailing an e-mail address to which the approx. 62kB capture file (pcapng format) may be sent . . . :)
-
I would recommend a read of something like Openreach SIN 527 regarding VLAN 101. It doesn't go any further than the DSLAM. I imagine it's more to keep end user traffic off the native VLAN. Without tags most of our equipment will automatically map to VLAN 1. Having traffic destined for the DSLAM in the same VLAN isn't a good plan. Broadcasts go out all ports in the VLAN.
-
I would recommend a read of something like Openreach SIN 527 regarding VLAN 101.
Thank you for the pointer.
On checking for that SIN I find it is missing. ??? Is https://www.bt.com/about/sinet/sins/downloads still the correct URL?
-
https://www.openreach.co.uk/cpportal/help/suppliers-information-notes-(sins)
SIN 527: https://www.openreach.co.uk/cpportal/content/dam/cpportal/public/images-and-documents/home/help-and-support/sins/documents/SIN_527.pdf
-
Thank you. The Openreach SIN URL has been bookmarked for future use and a copy of SIN527 has been downloaded.
-
I would recommend a read of something like Openreach SIN 527 regarding VLAN 101. It doesn't go any further than the DSLAM. I imagine it's more to keep end user traffic off the native VLAN. Without tags most of our equipment will automatically map to VLAN 1. Having traffic destined for the DSLAM in the same VLAN isn't a good plan. Broadcasts go out all ports in the VLAN.
I wonder if its more down to the legacy of supporting IPTV, VoIP, over their own VLANs? I'd imagine it should be blocking broadcasts no matter what VLAN its going down as in bridge mode surely broadcasts can still escape down VLAN 101?