Mailing List Archive

On 01.10.10 07:26, Michel de Nostredame wrote:
> Hi,
>
> I was checking my EX4200 trying to resolve a strange connection
> problem with my vendor through a Metro Ethernet.
> During that time I found another weird situation (it is not related to
> the metroEthernet connection).
>
> I setup two topology to test
>
> EX4200.ae0 ===(LACP,trunk)=== ae0.M10
>
> On above setup, the interface link-level MTU on EX4200 side (interface
> ae0) shows MTU 1514. But on M10 the interface link-level MTU shows
> 1518.
> The 1518 is what I expect to have as a VLAN trunk interface should be.
>
the EXes do their (routed) vlans like most switches - in a weird way :)

I think this is a display bug - I see the same values (using 9.6) of
EX1514, MX1518 in a similiar setup.

I just tested this, and if I put an EX port in "family inet" mode, then
the display is correct, if I use "family ethernet-switching", then it's
incorrect but works anyway. The "interface vlan" shows an MTU of 1518,
and all my physical ports (ae or no) show 1514 yet do pass 1500 byte
frames correctly, regardless of whether I use vlan-tagging or pure
access ports. The displayed MTU is 1514 without vlan-tagging, and it
stays 1514 even with vlan-tagging.

Kind regards,

Felix

--
Felix Schüren
Head of Network

-----------------------------------------------------------------------
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - 51149 Köln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller

(*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

This is just the way Juniper do things, just that it's not consistent
across all of their platforms. I've once been told by a Juniper
engineer that 1514 vs. 1518 MTU value is displayed (on the EX
platform at least) because the 4 bytes of CRC are not taken into
account as the CRC is not part of the media MTU (which kind of makes
sense). Excerpt from "Configure the Media MTU" in Juniper docs:

"The actual frames transmitted also contain cyclic redundancy check
(CRC) bits, which are not part of the media MTU. For example, the
media MTU for a gigabit Ethernet interface is specified as 1500 bytes,
but the largest possible frame size is actually 1504 bytes; you need
to consider the extra bits in calculations of MTUs for
interoperability."

So while not really a problem, this does cause some confusion.

HTH,

Cheers,
Wojciech


-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Felix
Schueren
Sent: 01 October 2010 06:59
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] weird MTU size on "show interface"

On 01.10.10 07:26, Michel de Nostredame wrote:
> Hi,
>
> I was checking my EX4200 trying to resolve a strange connection
> problem with my vendor through a Metro Ethernet.
> During that time I found another weird situation (it is not related to
> the metroEthernet connection).
>
> I setup two topology to test
>
> EX4200.ae0 ===(LACP,trunk)=== ae0.M10
>
> On above setup, the interface link-level MTU on EX4200 side (interface
> ae0) shows MTU 1514. But on M10 the interface link-level MTU shows
> 1518.
> The 1518 is what I expect to have as a VLAN trunk interface should be.
>
the EXes do their (routed) vlans like most switches - in a weird way :)

I think this is a display bug - I see the same values (using 9.6) of
EX1514, MX1518 in a similiar setup.

I just tested this, and if I put an EX port in "family inet" mode, then
the display is correct, if I use "family ethernet-switching", then it's
incorrect but works anyway. The "interface vlan" shows an MTU of 1518,
and all my physical ports (ae or no) show 1514 yet do pass 1500 byte
frames correctly, regardless of whether I use vlan-tagging or pure
access ports. The displayed MTU is 1514 without vlan-tagging, and it
stays 1514 even with vlan-tagging.

Kind regards,

Felix

--
Felix Schüren
Head of Network

-----------------------------------------------------------------------
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - 51149 Köln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller

(*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


--
-

Wojciech Owczarek

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Fri, Oct 1, 2010 at 4:10 AM, Wojciech Owczarek
<wojciech@owczarek.co.uk> wrote:
> This is just the way Juniper do things, just that it's not consistent
> across all of their platforms. I've once been told by a Juniper
> engineer that  1514 vs. 1518 MTU value is  displayed (on the EX
> platform at least) because the 4 bytes of CRC are not taken into
> account as the CRC is not part of the media MTU (which kind of makes
> sense). Excerpt from "Configure the Media MTU" in Juniper docs:
>
> "The actual frames transmitted also contain cyclic redundancy check
> (CRC) bits, which are not part of the media MTU. For example, the
> media MTU for a gigabit Ethernet interface is specified as 1500 bytes,
> but the largest possible frame size is actually 1504 bytes; you need
> to consider the extra bits in calculations of MTUs for
> interoperability."
>
> So while not really a problem, this does cause some confusion.
>
> HTH,
>
> Cheers,
> Wojciech

Thanks Felix and Wojciech,

As you mentioned that is display problem and causes some confusion. I
checked other Cisco Catalyst switches and I found similar "display"
problem (or feature :p ). The switch interfaces no matter access or
trunk are displayed with MTU 1500.

I assume that is common display behavior on the switch interface in
both Cisco and Juniper.

Regards,
--
Michel~

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Cisco is different. They typically don't include layer 2 overhead on the
display/config where as juniper does...
On Oct 1, 2010 4:55 PM, "Michel de Nostredame" <d.nostra@gmail.com> wrote:
> On Fri, Oct 1, 2010 at 4:10 AM, Wojciech Owczarek
> <wojciech@owczarek.co.uk> wrote:
>> This is just the way Juniper do things, just that it's not consistent
>> across all of their platforms. I've once been told by a Juniper
>> engineer that 1514 vs. 1518 MTU value is displayed (on the EX
>> platform at least) because the 4 bytes of CRC are not taken into
>> account as the CRC is not part of the media MTU (which kind of makes
>> sense). Excerpt from "Configure the Media MTU" in Juniper docs:
>>
>> "The actual frames transmitted also contain cyclic redundancy check
>> (CRC) bits, which are not part of the media MTU. For example, the
>> media MTU for a gigabit Ethernet interface is specified as 1500 bytes,
>> but the largest possible frame size is actually 1504 bytes; you need
>> to consider the extra bits in calculations of MTUs for
>> interoperability."
>>
>> So while not really a problem, this does cause some confusion.
>>
>> HTH,
>>
>> Cheers,
>> Wojciech
>
> Thanks Felix and Wojciech,
>
> As you mentioned that is display problem and causes some confusion. I
> checked other Cisco Catalyst switches and I found similar "display"
> problem (or feature :p ). The switch interfaces no matter access or
> trunk are displayed with MTU 1500.
>
> I assume that is common display behavior on the switch interface in
> both Cisco and Juniper.
>
> Regards,
> --
> Michel~
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Saturday, October 02, 2010 04:58:35 am Chris Evans wrote:

> Cisco is different. They typically don't include layer 2
> overhead on the display/config where as juniper does...

In IOS XR, Cisco now do.

On Ethernet, for instance, in IOS XR on the CRS, for
example, you'd have to explicitly add the Layer 2 overhead
if you want to get the MTU accurate, just like in JUNOS.

But in regular IOS, no, they still don't include it.

Cheers,

Mark.