[j-nsp] LSP types in M-Series

Pedro Fortuna pedro.fortuna at gmail.com
Fri Oct 28 06:41:26 EDT 2005


Hello Rafal,

Thanks, that was quite helpfull.

I haver other (related) questions I'd like to ask, if you don't mind.

How this configuration would have to be changed to:
a) Provide CoS based forwarding, based on Ethernet L2 QoS information
(802.1p bits)
   A LER would receive Ethernet VLAN frames from the client side, and
would split a VLAN's traffic based on 802.1p bit, to different LSP's

b) The same as a), but forwarding to different l2circuits (not LSPs)

Thanks in advance,
Pedro Fortuna

On 27/10/05, Rafal Szarecki (WA/EPO) <rafal.szarecki at ericsson.com> wrote:
> Pedro,
>
> I have no working and readable snapshot, but:
>
> 1) create as many LSP as many QoS classes you want. (E.g for 4LSPs for EF, AF1, NC, BE)
>
> 2) look at CBF (attached slides can help).
>
> 3) JUNOS support E-LSP as well as L-LSP. This is unrelated to DiffServ-Aware Traffic Engineering. DS-TE extend capabilities of constrain routing in way which give the ingress LSR (head-end LSR) information about avaliable bandwidth for each QoS Class on eny link in ISIS/OSPF area. So, in addition to link BW, IS-IS/OSPF carry also information about BW for EF, AF, BE, etc for each link.
> JUNIPER implementation of DS-TE is follow IETF draft and currently support L-LSP and E-LSP. (Cisco implementation of DS-TE is proprytary)
>
>
> Here is working config, but can be hard to read due to use of Logical Routers.
> As next hop there are p-t-p interfaces, but this can be also lsp names...
>
> root# show |no-more
> version 7.0R1.5;
> logical-routers {
>     LR1 {
>         protocols {
>             ospf {
>                 area 0.0.0.0 {
>                     interface all;
>                     interface ge-0/2/0.0 {
>                         passive;
>                     }
>                 }
>             }
>         }
>         policy-options {
>             policy-statement cbf-case1 {
>                 term 1 {
>                     from {
>                         route-filter 10.0.2.0/24 orlonger;
>                     }
>                     then cos-next-hop-map nh-case1;
>                 }
>             }
>         }
>         routing-options {
>             forwarding-table {
>                 export cbf-case1;
>             }
>         }
>     }
> }
> chassis {
>     alarm {
>         management-ethernet {
>             link-down ignore;
>         }
>     }
> }
> interfaces {
>     ge-0/1/0 {
>         unit 0 {
>             family inet {
> .....
> }
> protocols {
>     ospf {
>         area 0.0.0.0 {
>             interface all;
>         }
>     }
> }
> policy-options {
>     policy-statement cbf-case1 {
>         term 1 {
>             from {
>                 route-filter 10.0.2.0/24 orlonger;
>             }
>             then cos-next-hop-map nh-case1;
>         }
>     }
> }
> class-of-service {
>     forwarding-policy {
>         next-hop-map nh-case1 {
>             forwarding-class expedited-forwarding {
>                 next-hop [ at-0/3/0.1 10.0.0.14 ];
>             }
>             forwarding-class best-effort {
>                 next-hop at-0/3/0.0;
>             }
>         }
>     }
>     classifiers {
>         dscp case1 {
>             forwarding-class expedited-forwarding {
>                 loss-priority low code-points 101110;
>             }
>             forwarding-class best-effort {
>                 loss-priority low code-points 000000;
>             }
>         }
>     }
>     interfaces {
>         ge-0/2/0 {
>             unit 0 {
>                 classifiers {
>                     dscp case1;
>                 }
>             }
>         }
>     }
> }
> firewall {
>     family inet {
>         filter m-cast {
>             term igmp {
>                 from {
>                     protocol igmp;
>                 }
>                 then {
>                     count igmp-count;
>                     log;
>                     accept;
>                 }
>             }
>             term unlegal {
>                 from {
>                     destination-address {
>                         224.0.0.0/4;
>                     }
>                 }
>                 then {
>                     discard;
>                 }
>             }
>             term accept-all {
>                 then accept;
>             }
>         }
>     }
> }
>
> Rafal Jan Szarecki JNCIE #136
> Senior Consultant - Datacom Networks
> Ericsson Poland EPO/S/D
> Office: +48 22 6916635
> ECN:    837 6635
> Mobile: +48 602418971
> Skype: callto://Rafal_Szarecki <callto://Rafal_Szarecki/>
>
>
> > -----Original Message-----
> > From: juniper-nsp-bounces at puck.nether.net
> > [mailto:juniper-nsp-bounces at puck.nether.net]On Behalf Of Pedro Fortuna
> > Sent: Thursday, October 27, 2005 6:02 PM
> > To: Piotr Marecki
> > Cc: juniper-nsp at puck.nether.net
> > Subject: Re: [j-nsp] LSP types in M-Series
> >
> >
> > On 06/09/05, Piotr Marecki <peter at mareccy.org> wrote:
> > > >
> > > > What I think that should be possible to setup with Juniper NEs:
> > > > [1]. E-LSP: setting up non-TE tunnels with LDP carrying multiple
> > > > traffic classes (excluding guaranteed bandwidth which requires TE)
> > > > [2]. E-LSP: setting up TE tunnels with RSVP-TE carrying multiple
> > > > traffic classes (including guaranteed bandwidth)
> > > > [3]. L-LSP: setting up TE tunnels with RSVP-TE carrying a single
> > > > traffic class (including guaranteed bandwidth)
> > > >
> > > > Doubts:
> > > > a) If I understood well, Juniper is only able to setup [2]  with
> > > > multiclass LSPs. If this is true, it is highly limiting,
> > as [2] can
> > > > only traverse Juniper NEs. Can you confirm this?
> > >
> > > Juniper RSVP-TE implementation is mostly compatible with Cisco IOS ,
> > > exlcuding
> > > topic such as DS-TE , Fast-reroute ( one-to-one protection
> > ). Notice however
> > > that
> > > things may change when considering IOS-XR.
> > >
> > > >
> > > > b) I am not sure if it is possible to setup [3] with
> > Juniper M-Series
> > > > NEs. I read about classifiers, forwarding classes and
> > policies, but Im
> > > > not yet sure if this mechanisms can be used to split a
> > VLAN's traffic
> > > > according to the 802.1p traffic classes, and forward them
> > to different
> > > > l2circuits. Does anybody knows if [3] can be setup this
> > way? (or any
> > > > other way)
> > > >
> > >
> > > You can classify packets based on 802.1p and forward them
> > to different LSP
> > > with class based forwarding
> > > ( doesn't have to be DS-TE , works also with normal TE) -
> > works great on
> > > E-FPC. But it is not different l2circuit - y
> > > ou can choose LSP but not l2circuit since logical interface
> > can be assigned
> > > to only one l2circuit
> >
> > Can you please provide an example, or a reference where I can see an
> > example of this type of setup?
> >
> > Thanks,
> > Pedro Fortuna
> >
> > >
> > > regards
> > >
> > > Piotr Marecki
> > > > Thanks in advance!
> > > >
> > > > Best Regards,
> > > > Pedro Fortuna
> > > >
> > > > _______________________________________________
> > > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > > http://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > http://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
>


--
Cumprimentos,
Pedro Fortuna



More information about the juniper-nsp mailing list