[j-nsp] Juniper Ethernet MTU question

Ihsan Junaidi Ibrahim ihsan.junaidi at gmail.com
Sat Sep 30 12:49:06 EDT 2006


Referring to your example, on the CE-facing interface, if i were to do a
l2vpn, does the ccc encap OH counts against the interface MTU and
consequently, should the encap overhead be counted against the P-facing
interface? Example, the CE is sending 1518 bytes (includes vlan) and
the corresponding interface at PE adds another
4 bytes for vlan-ccc OH. If I follow you correctly that's 1522 + 8 +
14 (ethernet
core OH) = 1544 unless the 4 bytes ccc encap is localized to the CE-facing
interface only and is not carried over to the remote sites.

On 10/1/06, Harry Reynolds <harry at juniper.net> wrote:
>
> Three labels are typically seen in carrier of carrier apps. Normal
> l2/l3/vpls vpn is 2 labels (8 bytes), and as I mentioned the optional
> martini control word (applicable to l2circuits), adds another 4 bytes
> when enabled.
>
> The frame leaving the pe towards the p router will be the ethernet frame
> received from the CE minus preabmble/crc (may include a vlan tag), plus
> control word (optional and applicable to l2circuit), plus vrf label,
> plus mpls transport label, plus the L2 encap needed for that link.
>
> By way of example consider this l2vpn/circuit/vpls example. AFAIK they
> all use same encap excepting the optional control world for l2 circuits:
>
> Vlan
> tagging
>
> cpe-------------------pe---------------p
>
> 1518                 +8       +14
>
>                           vrf/mpls  eth encap
>
> Here the PE must encapsulate up to 1518 bytes of data received from CE
> (1500 + 4 (vlan) + 14 (Eth OH). Assuming no control word, the pe then
> pushes two labels for a total payload size of 1526. It then encapsulates
> for link-level transmission to p router, for ethernet this adds an
> another 14 bytes, for a grand total of 1540.
>
> The dfe pics only support a device mtu of 1532, so I think you have an
> issue. Loosing vlan tag reduces size by 4 bytes but the resulting 1536
> still exceeds dfe jumbo support.
>
> Only thing I can think of is to have the attached CEs reduce their Inet
> mtus by ~ 8 bytes, i.e. to 1492 including ip/tcp headers. This way the
> CEs can fragment as needed at ingress to the vpn. Not a very elegant
> solution, but should work.
>
> Regards
>
>
>
>
>
>
> ________________________________
>
>         From: Ihsan Junaidi Ibrahim [mailto:ihsan.junaidi at gmail.com]
>         Sent: Saturday, September 30, 2006 5:34 AM
>         To: Harry Reynolds
>         Cc: Juniper-NSP
>         Subject: Re: [j-nsp] Juniper Ethernet MTU question
>
>
>         The interface will be used for a P-facing temporarily until a
> better PIC can be POed. In what situation does an MPLS application
> warrant up to 3 labels or an additional of 8 bytes over stock header of
> 4 bytes? How many labels does a VPLS transport require?
>
>
>         On 9/29/06, Harry Reynolds <harry at juniper.net> wrote:
>
>                 Ah, dfe mtus. A subject near to my heart theses days.
>
>                 A few things.
>
>                 1. The device mtu includes 14 bytes of ethernet header,
> the real mtu is
>                 1500 bytes.
>
>                 2. The inet mtu is automatically set to 1500, which
> matches real
>                 ethernet mtu.
>
>                 3. The mpls mtu is automatically computed to be 12 bytes
> less than real
>                 mtu to accommodate up to 3 labels.
>
>                 In you case it does not sound that inet will be
> configured. The vlan tag
>                 does add an extra 4 bytes to the ethernet payload,
> resulting in need for
>                 1504 byes of information and total device mtu of 1518.
> JUNOS software
>                 automatically adjust the device mtu when you enable vlan
> tagging.
>
>                 As for support of mpls, I assume this is a ce facing
> interface. As such
>                 packets to and from this interface will not be labeled.
> Labels are
>                 pushed as the packet enters the core. In a typical l2
> vpn there would be
>                 two labels added; vrf and outer transport. The core
> interfaces will need
>                 an mtu of ethernet (1500) + vlan (4) + martini encap (0
> | 4) + labels
>                 (8) + what ever link encap is needed based on core
> interface type. If
>                 the core interfaces are also ethernet then this is
> another 14 for total
>                 of 1526-1530 (the latter is with optional martini
> control word). Pos
>                 only add 4 bytes for link encap so mtu for core would be
> at least
>                 1516-1520 for pos.
>
>                 As you seem aware the max mtu on the dfe cards is only
> 1532. In order to
>                 get this level of jumbo support you need to make sure
> you have the
>                 latest fpga. See below for tips on that. I believe that
> you will be OK
>                 with these cards as ce facing with the 1518 device mtu
> that results from
>                 simply enabling vlan tagging, but should be safe to
> enable a larger mtu
>                 as well. Technically the mtu of the CE devices should be
> used to
>                 dimension your ce and core facing interfaces, as best I
> can tell you
>                 will not need over 1518 device mtu if ce uses default
> ethernet mtu.
>
>                 To determine if you have the needed rev "c" 12x dfe
> firmware, do this
>                 (note hidden commands should only be used with Jtac
> guidance, and I'm
>                 not in jtac):
>
>
>                 Determine fpc/pic location. In this example its 0/2.
>
>                 Go to a shell, become root and vty to the fpc (0 in this
> case). Or use
>                 hidden command:
>
>                 start shell pfe network fpc0
>
>                 [edit interfaces fe-0/2/0]
>                 regress at boing# run start shell pfe network fpc0
>
>
>                 FPC platform (PPC 603e processor, 32MB memory, 256KB
> flash)
>
>                 FPC0(vty)#
>
>                 Now display the dfpga rev:
>
>                 FPC0(vty)# show dfe-pic 2 defpga
>
>                 PIC 2 DFE information:
>
>                 Dense FE PIC, 12 port(s) 1 GE links 1 cards
>                 Periodics are enabled
>                 Normal interrupts are enabled, total count is 406872
>                 IFD count is 12
>                 Main Card DE FPGA:
>                 Channel 0
>                    Transmit Packets :  4397, Transmit Bytes : 0
>                    Receive Packets :  11090, Receive Bytes : 0
>                    (0x850e1080)                  DFE CPU cntl  : 0x8004
>                    (0x850e1082)                    DFE Version : 0x000c
> <<<<< Rev c is
>                 needed to get over 1500 mtu
>                    (0x850e1086)           DFE interrupt enable : 0x0010
>                 Transmit Tagged Status:
>
>
>                 HTHs
>
>
>
>
>                 > -----Original Message-----
>                 > From: juniper-nsp-bounces at puck.nether.net
>                 > [mailto: juniper-nsp-bounces at puck.nether.net
> <mailto:juniper-nsp-bounces at puck.nether.net> ] On Behalf Of
>                 > Ihsan Junaidi Ibrahim
>                 > Sent: Friday, September 29, 2006 7:02 AM
>                 > To: Juniper-NSP
>                 > Subject: [j-nsp] Juniper Ethernet MTU question
>                 >
>                 > Hi all,
>                 >
>                 > 2 questions:
>                 >
>                 > 1) On a 12-port FE PIC, for vlan-cc encapsulation,
> should the
>                 > interface MTU be configured as 1518, 1522 or 1504? The
>                 > documentation below indicates that for vlan-ccc
>                 > encapsulation, it's a 4-byte field but I need to be
> certain.
>                 >
> http://www.junipernetworks.nl/techpubs/software/junos/junos76/
>                 >
> swconfig76-network-interfaces/html/interfaces-physical-config5
>                 .html#1085070
>                 >
>                 > 2) For a 12-port FE PIC, if I were to configure the
> maximum
>                 > physical MTU of 1532, will the PIC be able to
> accommodate MPLS MTU?
>                 >
>                 > --
>                 > Thank you for your time,
>                 > Ihsan Junaidi Ibrahim
>                 > _______________________________________________
>                 > juniper-nsp mailing list juniper-nsp at puck.nether.net
> <mailto:juniper-nsp at puck.nether.net>
>                 > https://puck.nether.net/mailman/listinfo/juniper-nsp
>                 >
>
>
>
>
>
>         --
>         Thank you for your time,
>         Ihsan Junaidi Ibrahim
>



-- 
Thank you for your time,
Ihsan Junaidi Ibrahim


More information about the juniper-nsp mailing list