Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jelv]

There's some nonsense around the SIN498 tests - see http://www.revk.uk/2016/08/pointless-tests-at-bt-martlesham.html

Separated from the thread where it was originally posted - Roseway

[kitz]

I'm probably missing something here if someone would enlighten me :/

Main gripe.

• The Zyxel VMG1312-B10A when used in bridge mode doesn't handle 1508 byte packets.

Question by me - Does it when used as a modem/router?  This will presumably will have been how it went through MCT testing. 
I don't envisage BT hooking it up to another router during testing when its sold as an all-in-one consumer unit.

The technical bits

SIN 498 says

"The modem shall support an Ethernet frame size of between 68 and 1534 bytes. For clarity, this figure includes 4 bytes for the C-VLAN, and excludes bits allocated to pre-amble, Inter-Frame Gap, and Frame Check Sequence at the user network interface (UNI). Support for frame sizes above 1534 bytes (inclusive of C-VLAN) is not guaranteed."

BT confirm

They have confirmed categorically that if a modem only supported packets of 68 bytes it would pass that part of the test.

Which would seem to imply that "an" in SIN 498 means "any".

[sevenlayermuddle]

Hmm, clearly BT tests are failing to find that bug, but is it entirely fair to make it their fault?

Imagine you work for a device manufacturer, you are responsible for checking all protocol specs and requirements, before submitting it for BT approval.   You hope that the testers won't find any bugs but, if they do, you are grateful for it as it is one less bug to be reported by the CP who deploys your device.  Eventually comes the good news, BT have approved the device.

But some time later, a bug is subsequently reported by the CP deploying your product.  So BT failed to find it, and hopefully they will close the loophole in their test scripts that allowed the bug to go undetected.  But does that make them to blame for the underlying product bug?   Not in my book... blame for the bug rests with the device manufacturer, he should not be depending upon BT to find his bugs for him.

Just my opinion, based on first impressions of what's being discussed.

[ejs]

The test for the Ethernet frame size is described in BT SIN 498 A.4.2.3.1 - am I reading it wrong, or does it describe testing using only an Ethernet frame size of 1534 bytes?

[kitz]

Not sure could depend on interpretation.  It says

Configure the Ethernet tester port connected to the Head End and provision it to generate downstream traffic with the following attributes:
..
...

(e) Set Frame Size as Fixed Mode and set to 1534 bytes.  Note that the modem shall support an Ethernet frame size of between 68 and 1534 bytes.  ).

Expected outcome

(step 3) Provisioning should be completed successfully for the Headend connected port on the Ethernet tester
(step 4) Provisioning should be completed successfully for the modem connected port on the Ethernet tester.  The maximum Ethernet frame size supported should be between 68 and 1534 bytes. 

Which would imply they do only test using 1534, but Im not sure about the expected outcome when it says maximum size.

But even so... I think the crux of the problem is explained here.

Bridging 1508 bytes ethernet

Issue Description

Bridging does work, but we'd very much like the router to support baby jumbo frames bridging to VDSL and ADSL, to support *at least* 1508 bytes to allow RFC4638 PPPoE to a connected device.

Which goes back to the question... would BT even be testing a combined modem/router to see how it works in bridge mode? 

Figs 30 & 31 shows the ethernet tester connected directly to the CPE.

[kitz]

would BT even be testing a combined modem/router to see how it works in bridge mode?

Further thoughts on that.   If the modem offers bridge mode, then I suppose it should still pass the test.
Though that gives Zyxel an easy option to not allow bridging

Obviously it appears to pass the test of 'provisioning should be completed successfully' because even RevK admits it does even in bridge mode.
Where things start to get woolly for me is when it says 'The maximum Ethernet frame size supported should be between 68 and 1534 bytes.' does that mean they dont care if fragmentation occurs?

Also another thought I dont know if its the same on the VMG1312 as it is on the others, but Im assuming so..  but what bearing does the fact that the MTU is fixed at 1492 have?

[ejs]

I don't think an Ethernet NIC can fragment frames, IP packets would be fragmented at the IP layer.

It's probably that the MCT only tested the functionality as an integrated modem+router. Using it as a bridged modem would also require the device's Ethernet switch to support the baby jumbo frames.

[kitzuser87430]

you can manually run via the CLI after boot makes it work

Anybody know the script?

{Moderator edited to add an attribution to the quotation.]

[kitz]

TBH reading it again I don't think BT give too much credence in to the actual packet size

Note the specific mention (section A.4.2.3)

"The modem shall support an Ethernet frame size of between 68 and
1534 bytes.  For clarity, this figure includes 4 bytes for the C-VLAN, and excludes
bits allocated to pre-amble,"

../snip/..

This test procedure incorporates tests for:

R.ETH.1
R.WAN.1
R.WAN.2
R.WAN.4
R.WAN.5
R.WAN.6

I didn't realise what all the R.WANs were at first, but if you look on page 29, it gives a deeper insight what they are testing for.
Every single reference is making sure that the VLAN tags are identified correctly.

Then back to section A.4.2.3 See the notes at the bottom - Note 1 & 2 which say IEEE 802.1q VLAN encapsulation.
This test is intended to show that only VLAN 101 is used.  Any other VLANs used will be identified to feedback incorrect usage to CP.

It seems to me they dont really care about the actual packet size as long as its between 68 and 1534 bytes and identifies the correct VLAN.
Once you realise they are talking about correct VLAN identification, the whole test becomes much clearer and you realise that its not really about the size of packet.

Capture the packets at the ingress of DSLAM by applying port mirroring and
verify VLAN ID as 101. The modem shall support IEEE 802.1q VLAN
encapsulation and all ingress frames shall be encapsulated within 802.1q
VLAN. Traffic without a correct VLAN ID will be dropped.

[Weaver]

I read RevK's post and was too full of drugs to follow all of it. 

Is there a _usable_ mod which would allow 1508 byte packets and allow a full 1500 MTU without fragmentation? (that is, one that survives a reboot.)

[WWWombat]

I think RevK has the wrong end of the stick here.

These tests aren't to check the breadth of modem capability (though an ISP might care about that). BT cares about the narrower concept of compatibility and if the modem supports one single fixed length it remains compatible provided that length is one supported by BT.

Now, the ISP might care that the modem works with a full range of sizes, to retain compatibility with routers, MTUs, Ethernet, IP fragmentation, etc. But that's for the ISP to confirm.

This thinking matches up with @kitz's observations that BT care much more about the VLAN handling.

[Weaver]

Yes, RevK (and everyone else) wants 1500 byte IP PDU capability so we can get a lovely MRU / MTU of 1500, and BT simply aren't interested in that (any more)mand their focus is elsewhere. (Although that is weird given that they've  provided 1500 byte MTU with 21CN, and with FTTC and their Huawei VDSL modems.) - If I'm understanding his post correctly.

What is the VLAN thing all about?

[kitz]

I think RevK has the wrong end of the stick here.

Yep They are testing that the modem will correctly identify the VLAN tags regardless of what packet size it handles.

If you read section A.4.2.3 in full (rather than part quote it), it becomes clear that they are not testing for what packet size the modem itself uses.   All they care about is if fragmentation does occur, then the modem will still recognise the VLAN tags.

BT makes extensive use of VLANs on their 21CN network/for FTTC.  We will all have seen that S-VLANs form the BT wholesale backhaul.   These are equivalent of the old VPs where congestion can occur.  They also use C-VLANs for tagging customer traffic.

On  the  GEA  Cablelink,  all  traffic  will  be  presented  using  single  tagging  or  double
tagging on a per VLAN basis.  Both options can be used on the same GEA Cablelink on a per GEA order basis.
The tagging option to use for a specific GEA order is explicitly selected by the CP when ordering. 
The VLAN used for End User traffic is referred to as a Customer VLAN or “C-VLAN”.
A  CP  may  optionally  choose  to  use  an  additional  level  of VLAN tagging  so  that
C-VLANs  can  be  grouped  within  another  VLAN,  referred  to  as  a Service  VLAN  or “S-VLAN”

Section 2.1.3 describes the usage of VLAN tags in a lot more detail and what options can be set.

----

Back to A.4.2.3 which is the test RevK is querying

Basically the important part of the test involves:-

• Setting up a VDSL2 line profile and giving the 'line' a VLAN tag at the headend and DSLAM.
• Set the frame size to fixed 1534 bytes
• Start sending the modem 1534 byte frames
• Capture packets

To pass the test the modem:

• Must pick up the correct profile
• Provisioning be completed successfully.
• Not drop any packets due to fragmentation.

From the captured data:

• VLAN id 101 must be present with 802.1q tag.
• Incorrect VLAN ID traffic should be discarded

BT really doesnt care what size packets the modem itself uses.  Things like that can be tweaked using MTU etc.  All they care is that the modem doesnt drop the VLAN tags due to fragmentation.

[kitz]

Yes, RevK (and everyone else) wants 1500 byte IP PDU capability so we can get a lovely MRU / MTU of 1500, and BT simply aren't interested in that (any more)mand their focus is elsewhere. (Although that is weird given that they've  provided 1500 byte MTU with 21CN, and with FTTC and their Huawei VDSL modems.) - If I'm understanding his post correctly.

He really should be taking that up with the modem manufacturer.   :/
Things like MTU can easily be tweaked or over-ridden by the EU if they so wish, therefore BT need to ensure that any tweaking or using different size packets wont cause fragmentation and loss of those important VLAN id and tags.

What is the VLAN thing all about?

See IEEE 802.1Q and IEEE P802.1p

In simple terms its how BT 1.) sections off parts of their network and 2.) ensures traffic gets the correct priority.   

[Weaver]

Thanks or that exellent explanation, I didn't really make myself clear - I knew what 802.1q is, but didn't understand what BT or whoever  is doing with it. So BT (and its wholesale customers) are really using Ethernet headers. What does a modem do with them? (a big answer, perhaps belongs in another thread)

As I'm only used to ADSL with PPPoA or PPPoE, I'm simply used to protocol stacks where there is either no Ethernet framing at all, it's all about IP after all, or where any Ethernet "---oE" headers are useless and are simply junked afaik. I realise that I know absolutely nothing at all about FTTC or FTTP’s associated higher level protocol stacks (equally ignorant about the lower levels too), to my shame, so I could do with some pointers to some reading matter, just in case the brain fog from all the fatigue and/or the current drugs ever clears. After all, FTTx might as well be only available on Mars at the moment, unless the USO becomes not only real but also honest (ie no satellite crap or shared bandwidth RF lottery con). Things might be different here in 2025, depending on the whims of politicians. So I've not had a reason - and so been too idle - to research FTTx.

Bit surprised they need this, I just assumed that they would be using MPLS's facilities for all they need, but that isn't going to extend all the way to an EU, if that's also a requirement for some reason. (I seem to remember that Zen offer MPLS to some if their business customers even, iirc.)

But what on earth do I know. My scant knowledge is simply now a decade behind the civilised world, since here in the land of the lost decade nothing at all happened between ADSL Max in 2006 and the extremely welcome arrival of 21CN and ADSL2+ in December, to which I'm still adjusting.