[j-nsp] MPLS and QoS at penultimate hop ?

Eduardo Barrios Eduardo.Barrios at LCRA.ORG
Wed Feb 6 10:44:13 EST 2013


Just looking at the output on the PHP router the S bit is set to 0, so this means there is at least one additional label present - most likely the VPN label?

I too would echo what others have that the classification is done before the POP action. Once the transport label is popped, then the VPN label with S=1 (bottom of stack) is sent the tail end router.

In our case we have classifiers applied to handle the VPNs labels coming into the LSI "logical interface" on the tail end PE routers:


ebarrios at Router.re0> show configuration class-of-service routing-instances
Corp-VPLS-555 {
    classifiers {
        exp backbone;
    }
}

{master}


Thanks,
Eduardo

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Alexandre Snarskii
Sent: Tuesday, February 05, 2013 3:31 AM
To: Christopher E. Brown
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] MPLS and QoS at penultimate hop ?

On Mon, Feb 04, 2013 at 09:36:10AM -0900, Christopher E. Brown wrote:
>
> The packet is classified on input.
>
> *UNLESS* you use table-label in a l3vpn, then it gets re-classified
> after the label POP.

Intresting. However, my question is not about l3vpn, it is about plain
old IPv4 packet with one MPLS header entering PHP router programmed to Pop
this header and forward this packet towards next (egress) router..

Example:

ingress router:

AA.BBB.205.0/25    *[BGP/170] 6w1d 22:28:33, MED 100, localpref 200, from AA.BBB.224.5
                    > to AA.BBB.233.133 via ae2.6, Push 604050

(BA-classification is done on ipprec/dscp of ingress packet)

PHP router:

604050             *[LDP/9] 4d 00:37:22, metric 1
                    > to AA.BBB.233.13 via ae4.9, Pop
604050(S=0)        *[LDP/9] 4d 00:37:22, metric 1
                    > to AA.BBB.233.13 via ae4.9, Pop

(BA-classification is most possibly done on ip-prec after Pop is done,
but that's the point where I'm not sure.... Classification on EXP may be
more accurate: as there are no "payload type" field in MPLS header, this
router just can't know that packet's content is IPv4).


> On 2/3/13 6:03 PM, Chris Kawchuk wrote:
> > It was my understanding that the label was "logically" popped on
> > Egress (in terms of how one would envision the packet flow); hence
> > the outer label EXP bits were evaluated by the BA classifier on
> > ingress properly. (Whether it's popped on ingress, yet evaluated
> > prior-to-pop is a mechanics thing..)
> >
> > But yes, I have no documentation I can point to; off the top of my
> > head that the above is indeed true. I would be interested to know for
> > future information sake that the JNPR box is indeed "doing the right
> > thing" so to speak? i.e. since the PIC/MPC pops the Layer-2
> > information as well, it needs to be able to read the 802.1P bits, if
> > there is a 1p-VLAN tag BA applied to the interface. Hopefully we're
> > also reading the outer EXP label at the same time; as this would make
> > sense.
> >
> > i.e. if you're doing VLAN pop/swapping, you'd need to retain any
> > BA-p-tag specific classification there as well, prior to any tag
> > manipulation.
> >
> > 400 quatloos says it's done on ingress before the label is popped.
> >
> > - Ck.
> >
> >
> >>
> >> Simple question I'm not able to find answer for: what is the order
> >>  of label pop operation and BA classification on penultimate router
> >> ?
> >>
> >> I have a gut feeling that label is stripped first and then BA
> >> classification is done on a "naked" packet, f.e., ipprec-based in
> >> case of IP packet, without taking (already stripped) EXP bits into
> >>  account, but I can't find any documentation proving or disproving
> >> it...
> >
> >
> > _______________________________________________ juniper-nsp mailing
> > list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
> --
> ------------------------------------------------------------------------
> Christopher E. Brown   <chris.brown at acsalaska.net>   desk (907) 550-8393
>                                                      cell (907) 632-8492
> IP Engineer - ACS
> ------------------------------------------------------------------------
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

--
In theory, there is no difference between theory and practice.
But, in practice, there is.

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





More information about the juniper-nsp mailing list