[j-nsp] Juniper Ethernet MTU question
Harry Reynolds
harry at juniper.net
Sat Sep 30 12:57:04 EDT 2006
If I follow, the OH added by the PE counts towards the PE-P facing (and
other core) interfaces.
In my diagram I tried to show that:
CE facing interface with vlan will need 1504 + 14 or 1518 device mtu
P facing interface will need that, plus (optional control word, vrf/mpls
label, link encap).
The pe does not add any additional vlan tags, unless you have vlan
tagging on the p-facing interface, which I did not include in my
example. I would say that the OH added by the PE affects the core
facing, not CE facing side. This is why I started by saying the small
jumbo supported on the DFE should be OK for a VRF (PE-CE) interface. As
a core interface I think you will have issues.
I hope this clarifies.
________________________________
From: Ihsan Junaidi Ibrahim [mailto:ihsan.junaidi at gmail.com]
Sent: Saturday, September 30, 2006 9:49 AM
To: Harry Reynolds
Cc: Juniper-NSP
Subject: Re: [j-nsp] Juniper Ethernet MTU question
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
<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