Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: juniper

Juniper MPLS VPN using PE-P and P-PE LSPs !

  

 
nsp juniper RSS feed   Index | Next | Previous | View Threaded


svaibhava at gmail

Dec 25, 2011, 2:22 AM

Post #1 of 13 (1030 views)
Permalink
Juniper MPLS VPN using PE-P and P-PE LSPs !
Dear All

I am working on a requirement to enable the MPLS Backbone with MPLS TE
in such a way that I have LSPs running from PE-P routers and P-PE
routers to avoid full mesh of LSPs.

I can not make it working with RSVP as I think I need to enable LDP on
the RSVP TE Tunnel but unable to find a way to do so..The MPLS
Backbone has separate dedicated VPNv4 RRs . On RRs and PEs I have used
a Discard Default Route under inet.3 which helps to reflect the vpnv4
routes from RR and accept them on PEs.

Even I tried to announce the LSP into IGP but that did not work and I
have to instead manually configure static route under inet.3. I
understand this is because the tunnels were PE-P and not PE-PE..

Now how can I solve the issue of passing MPLS VPN Traffic across
broken LSPs in the backbone..

Setup is as below

RR1
!
!
----------LSP1------------------Core1-------------LSP2---------------------
CE1-PE1 MPLS TE-OSPF Area 0
PE2-CE2
----------LSP3------------------Core2-------------LSP4---------------------
!
!
RR2
--
Regards
Vaibhava Varma
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


mtinka at globaltransit

Dec 25, 2011, 5:02 AM

Post #2 of 13 (1011 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
On Sunday, December 25, 2011 06:22:18 PM vaibhava varma
wrote:

> I am working on a requirement to enable the MPLS Backbone
> with MPLS TE in such a way that I have LSPs running from
> PE-P routers and P-PE routers to avoid full mesh of
> LSPs.

So you mean H-LSP's (RFC's 4206, 6107)

> I can not make it working with RSVP as I think I need to
> enable LDP on the RSVP TE Tunnel but unable to find a
> way to do so..

You mean LDPoRSVP (LDP Tunneling, in Juniper speak):

tinka [at] la# show groups mpls-group
protocols {
mpls {
icmp-tunneling;
label-switched-path <*> {
ldp-tunneling;
least-fill;
node-link-protection;
adaptive;
}
interface <xe-*>;
interface <ge-*>;
interface <ae*>;
}
}

{master}[edit]
tinka [at] la#


You're interested in the 'ldp-tunneling' command as noted
above.

> The MPLS Backbone has separate dedicated
> VPNv4 RRs . On RRs and PEs I have used a Discard Default
> Route under inet.3 which helps to reflect the vpnv4
> routes from RR and accept them on PEs.

Why don't you consider the installation of the IGP routes
toward the BGP next-hops into 'inet.3' and 'inet6.3'
instead? We do the same (as we don't run MPLS on our
dedicated route reflectors) as below (you're interested in
the 'rib-group' piece mostly):

tinka [at] la# show groups isis-group
protocols {
isis {
lsp-lifetime 65535;
ignore-attached-bit;
rib-group inet IGP-RIB;
topologies ipv6-unicast;
overload;
level 1 disable;
level 2 {
authentication-key "<hidden>"; ## SECRET-DATA
authentication-type md5;
wide-metrics-only;
}
interface lo0.0 {
passive;
}
interface <ge-*>;
}
}

{master}[edit]
tinka [at] la#


tinka [at] la# show routing-options rib-groups
IGP-RIB {
import-rib [ inet.0 inet.3 inet6.3 ];
}

{master}[edit]
tinka [at] la#


That should sort you out on the route reflectors so you
don't have to hassle with static default routes.

> Now how can I solve the issue of passing MPLS VPN Traffic
> across broken LSPs in the backbone..

Just a question - have you not considered just running LDP,
or RSVP-TE a must?

Cheers,

Mark.
Attachments: signature.asc (0.82 KB)


svaibhava at gmail

Dec 25, 2011, 5:35 AM

Post #3 of 13 (1067 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
HI Mark
Thanks a lot for your response..I have everything working fine withLDP
without any issues..I just wanted to deploy RSVP-TE for fasterfailover
in the backbone..And there I got stuck up with the full-meshof TE
among PEs or using Broken Static LSPs between PE-P and P-PE..
Thanks for sharing the rib-import methodology to get rid of
staticroutes for inet.3 resolution for BGP-Next Hops..
Just a clarification on the "ldp-tunneling" part..Do I need to
applythis at all the PE/P routers to run LDP over broken LSPs between
PEs..Is there a provision in Junos without using LDP Tunneling to
passtraffic between PEs when using broken LSPs ?
On Sun, Dec 25, 2011 at 6:32 PM, Mark Tinka <mtinka [at] globaltransit> wrote:
> On Sunday, December 25, 2011 06:22:18 PM vaibhava varma
> wrote:
>
>> I am working on a requirement to enable the MPLS Backbone
>> with MPLS TE in such a way that I have LSPs running from
>> PE-P routers and P-PE routers to avoid full mesh of
>> LSPs.
>
> So you mean H-LSP's (RFC's 4206, 6107)
>
>> I can not make it working with RSVP as I think I need to
>> enable LDP on the RSVP TE Tunnel but unable to find a
>> way to do so..
>
> You mean LDPoRSVP (LDP Tunneling, in Juniper speak):
>
> tinka [at] la# show groups mpls-group
> protocols {
>    mpls {
>        icmp-tunneling;
>        label-switched-path <*> {
>            ldp-tunneling;
>            least-fill;
>            node-link-protection;
>            adaptive;
>        }
>        interface <xe-*>;
>        interface <ge-*>;
>        interface <ae*>;
>    }
> }
>
> {master}[edit]
> tinka [at] la#
>
>
> You're interested in the 'ldp-tunneling' command as noted
> above.
>
>> The MPLS Backbone has separate dedicated
>> VPNv4 RRs . On RRs and PEs I have used a Discard Default
>> Route under inet.3 which helps to reflect the vpnv4
>> routes from RR and accept them on PEs.
>
> Why don't you consider the installation of the IGP routes
> toward the BGP next-hops into 'inet.3' and 'inet6.3'
> instead? We do the same (as we don't run MPLS on our
> dedicated route reflectors) as below (you're interested in
> the 'rib-group' piece mostly):
>
> tinka [at] la# show groups isis-group
> protocols {
>    isis {
>        lsp-lifetime 65535;
>        ignore-attached-bit;
>        rib-group inet IGP-RIB;
>        topologies ipv6-unicast;
>        overload;
>        level 1 disable;
>        level 2 {
>            authentication-key "<hidden>"; ## SECRET-DATA
>            authentication-type md5;
>            wide-metrics-only;
>        }
>        interface lo0.0 {
>            passive;
>        }
>        interface <ge-*>;
>    }
> }
>
> {master}[edit]
> tinka [at] la#
>
>
> tinka [at] la# show routing-options rib-groups
> IGP-RIB {
>    import-rib [ inet.0 inet.3 inet6.3 ];
> }
>
> {master}[edit]
> tinka [at] la#
>
>
> That should sort you out on the route reflectors so you
> don't have to hassle with static default routes.
>
>> Now how can I solve the issue of passing MPLS VPN Traffic
>> across broken LSPs in the backbone..
>
> Just a question - have you not considered just running LDP,
> or RSVP-TE a must?
>
> Cheers,
>
> Mark.



--
Regards
Vaibhava Varma

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


mtinka at globaltransit

Dec 25, 2011, 8:09 AM

Post #4 of 13 (995 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
On Sunday, December 25, 2011 09:35:52 PM vaibhava varma
wrote:

> Thanks a lot for your response..I have everything working
> fine withLDP without any issues..I just wanted to deploy
> RSVP-TE for fasterfailover in the backbone..

Ah okay. Got you.

> And there I
> got stuck up with the full-meshof TE among PEs or using
> Broken Static LSPs between PE-P and P-PE..

What we've done, in one of our networks, to scale MPLS-TE
was to enable RSVP only in the core, run LDP everywhere else
and tunnel LDP in RSVP in the core.

This was mostly to create single-hop LSP's so that we can
solve unequal-cost path issues in the IGP to better utilize
previously idle core links.

That said, "MPLS-Enabled Applications" by Ina Minei & Julian
Lucek is one place where I've seen RFC 4206 mechanisms
documented in some form:

http://books.google.com.my/books?id=3MszQLz2cdwC&pg=PT66&lpg=PT66&dq=mpls+enabled+applications+label+operations+are+analogous+to+those+in+the+ldp&source=bl&ots=Abxedzafk8&sig=ZlvuaQ0PLqpMmZIqQVp5tL_Zppw&hl=en&sa=X&ei=00j3TtXzDMnOrQePvexD&ved=0CB0Q6AEwAA#v=onepage&q&f=false


Page 30 is what you're after. Maybe that can help - I can
theorize its operations, but we haven't deployed this
particular architecture in the field.

> Thanks for
> sharing the rib-import methodology to get rid of
> staticroutes for inet.3 resolution for BGP-Next Hops..

Most welcome.

> Just a clarification on the "ldp-tunneling" part..Do I
> need to applythis at all the PE/P routers to run LDP
> over broken LSPs between PEs..Is there a provision in
> Junos without using LDP Tunneling to passtraffic between
> PEs when using broken LSPs ?

I usually recommend that LDPoRSVP always be enabled on
ingress routers for all LSP's. I also encourage them to be
enabled on P routers that are also acting as ingress routers
for RSVP LSP's.

Otherwise, if a P router is merely a transit node for an
LSP, then you wouldn't even be able to enabled LDPoRSVP, as
you wouldn't have an LSP or tunnel under which to do that,
both in IOS and Junos.

Cheers

Mark.
Attachments: signature.asc (0.82 KB)


svaibhava at gmail

Dec 25, 2011, 11:24 PM

Post #5 of 13 (993 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
Hi Mark

Thanks for the help so far..I tried to use "ldp-tunneling" under RSVP
TEs from PE-P to P-PE but it does not works as I do not have LDP
enabled anywhere to tunnel it via RSVP..

My setup is as below:

CE1-PE1--RSVP-LSP1--P1--RSVP-LSP2--PE2--CE2

How can I make the traffic flow from CE1 to CE2 in the MPLS VPN under
this setup..I am really confused on this and not getting any
solution..I am seeing all the routes and required lables for CE2
routes at PE1 but no traffic flow is happening

lab [at] edge1# run show route table CE1A.inet.0 172.16.251.1 extensive

CE1A.inet.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden)
172.16.251.1/32 (2 entries, 1 announced)
TSI:
KRT in-kernel 172.16.251.1/32 -> {indirect(131071)}
Page 0 idx 1 Type 1 val 8f0d594
Nexthop: Self
AS path: [64513] 64513 I
Communities: target:64513:100
Path 172.16.251.1 from 10.0.2.1 Vector len 4. Val: 1
*BGP Preference: 170/-101
Route Distinguisher: 64513:1
Next hop type: Indirect
Next-hop reference count: 10
Source: 10.0.2.1
Next hop type: Router, Next hop index: 131070
Next hop: 10.0.10.2 via ge-0/0/0.0, selected
Label operation: Push 16
Next hop: 10.0.10.10 via ge-0/0/1.0
Label operation: Push 16
Protocol next hop: 10.0.6.1
Push 16
Indirect next hop: 8ffc000 131071
State: <Secondary Active Int Ext>
Local AS: 64513 Peer AS: 64513
Age: 30:55 Metric: 0 Metric2: 2
Task: BGP_64513.10.0.2.1+63485
Announcement bits (2): 0-KRT 1-BGP RT Background
AS path: 64514 I (Originator) Cluster list: 10.0.2.1
AS path: Originator ID: 10.0.6.1
Communities: target:64513:100
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 10.0.2.1
Primary Routing Table bgp.l3vpn.0
Indirect next hops: 1
Protocol next hop: 10.0.6.1 Metric: 2
Push 16
Indirect next hop: 8ffc000 131071
Indirect path forwarding next hops: 2
Next hop type: Router
Next hop: 10.0.10.2 via ge-0/0/0.0
Next hop: 10.0.10.10 via ge-0/0/1.0
10.0.6.1/32 Originating RIB: inet.3
Metric: 2 Node path count: 1
Forwarding nexthops: 2
Nexthop: 10.0.10.2 via ge-0/0/0.0
Nexthop: 10.0.10.10 via ge-0/0/1.0
BGP Preference: 170/-101
Route Distinguisher: 64513:1
Next hop type: Indirect
Next-hop reference count: 10
Source: 10.0.5.1
Next hop type: Router, Next hop index: 131070
Next hop: 10.0.10.2 via ge-0/0/0.0, selected
Label operation: Push 16
Next hop: 10.0.10.10 via ge-0/0/1.0
Label operation: Push 16
Protocol next hop: 10.0.6.1
Push 16
Indirect next hop: 8ffc000 131071
State: <Secondary NotBest Int Ext>
Inactive reason: Not Best in its group - Update source
Local AS: 64513 Peer AS: 64513
Age: 30:55 Metric: 0 Metric2: 2
Task: BGP_64513.10.0.5.1+56350
AS path: 64514 I (Originator) Cluster list: 10.0.5.1
AS path: Originator ID: 10.0.6.1
Communities: target:64513:100
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 10.0.5.1
Primary Routing Table bgp.l3vpn.0
Indirect next hops: 1
Protocol next hop: 10.0.6.1 Metric: 2
Push 16
Indirect next hop: 8ffc000 131071
Indirect path forwarding next hops: 2
Next hop type: Router
Next hop: 10.0.10.2 via ge-0/0/0.0
Next hop: 10.0.10.10 via ge-0/0/1.0
10.0.6.1/32 Originating RIB: inet.3
Metric: 2 Node path count: 1
Forwarding nexthops: 2
Nexthop: 10.0.10.2 via ge-0/0/0.0
Nexthop: 10.0.10.10 via ge-0/0/1.0

I have the Label for the Next-Hop 10.0.6.1 on the Core Router but on
PE1 its just OSPF route..I think thats the problem here but how can I
get label for remote PE loopback with broken LSPs..LDP tunneling is
not the solution here I think..I tried announcing the PE1-P1 RSVP-LSP
into OSPF but that also did not work..

lab [at] core1# run show route 10.0.6.1

inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.6.1/32 *[RSVP/7/1] 06:28:58, metric 1
> to 10.0.10.22 via ge-0/0/3.0,
label-switched-path to_edge1.pop2
[OSPF/10] 00:03:14, metric 1
> to 10.0.10.22 via ge-0/0/3.0

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.6.1/32 *[RSVP/7/1] 06:28:58, metric 1
> to 10.0.10.22 via ge-0/0/3.0,
label-switched-path to_edge1.pop2

root [at] edge1# run show route 10.0.6.1

inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.6.1/32 *[OSPF/10] 00:04:16, metric 2
to 10.0.10.2 via ge-0/0/0.0
> to 10.0.10.10 via ge-0/0/1.0

inet.3: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.6.1/32 *[OSPF/10] 00:04:16, metric 2
to 10.0.10.2 via ge-0/0/0.0
> to 10.0.10.10 via ge-0/0/1.0

Announcing LSP into IGP OSPF

lab [at] edge1# run show route 10.0.6.1 extensive

inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
10.0.6.1/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.0.6.1/32 -> {10.0.10.10}
*OSPF Preference: 10
Next hop type: Router
Next-hop reference count: 6
Next hop: 10.0.10.2 via ge-0/0/0.0
Next hop: 10.0.10.10 via ge-0/0/1.0, selected
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
State: <Active Int>
Local AS: 64513
Age: 11 Metric: 2
Area: 0.0.0.0
Task: OSPF
Announcement bits (1): 0-KRT
AS path: I
Secondary Tables: inet.3

inet.3: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)

10.0.6.1/32 (1 entry, 1 announced)
*OSPF Preference: 10
Next hop type: Router
Next-hop reference count: 6
Next hop: 10.0.10.2 via ge-0/0/0.0
Next hop: 10.0.10.10 via ge-0/0/1.0, selected
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
State: <Secondary Active Int>
Local AS: 64513
Age: 11 Metric: 2
Area: 0.0.0.0
Task: OSPF
Announcement bits (1): 2-Resolve tree 1
AS path: I
Primary Routing Table inet.0

I even tried manullay setting nect-hop of remote PE2 as LSP but that
also did not work

lab [at] edge1# run show route 10.0.6.1 extensive

inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden)
10.0.6.1/32 (2 entries, 1 announced)
TSI:
KRT in-kernel 10.0.6.1/32 -> {10.0.10.2}
*Static Preference: 5
Next hop type: Router
Next-hop reference count: 1
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1, selected
Label-switched-path to_core1.pop1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
State: <Active Int Ext>
Local AS: 64513
Age: 12
Task: RT
Announcement bits (1): 0-KRT
AS path: I
OSPF Preference: 10
Next hop type: Router
Next-hop reference count: 6
Next hop: 10.0.10.2 via ge-0/0/0.0
Next hop: 10.0.10.10 via ge-0/0/1.0, selected
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
State: <Int>
Inactive reason: Route Preference
Local AS: 64513
Age: 4:19 Metric: 2
Area: 0.0.0.0
Task: OSPF
AS path: I
Secondary Tables: inet.3

inet.3: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)

10.0.6.1/32 (1 entry, 1 announced)
*OSPF Preference: 10
Next hop type: Router
Next-hop reference count: 6
Next hop: 10.0.10.2 via ge-0/0/0.0
Next hop: 10.0.10.10 via ge-0/0/1.0, selected
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
State: <Secondary Active Int>
Local AS: 64513
Age: 4:19 Metric: 2
Area: 0.0.0.0
Task: OSPF
Announcement bits (1): 2-Resolve tree 1
AS path: I
Primary Routing Table inet.0

Thanks & Regards
Vaibhava Varma
On Sun, Dec 25, 2011 at 9:39 PM, Mark Tinka <mtinka [at] globaltransit> wrote:
> On Sunday, December 25, 2011 09:35:52 PM vaibhava varma
> wrote:
>
>> Thanks a lot for your response..I have everything working
>> fine withLDP without any issues..I just wanted to deploy
>> RSVP-TE for fasterfailover in the backbone..
>
> Ah okay. Got you.
>
>> And there I
>> got stuck up with the full-meshof TE among PEs or using
>> Broken Static LSPs between PE-P and P-PE..
>
> What we've done, in one of our networks, to scale MPLS-TE
> was to enable RSVP only in the core, run LDP everywhere else
> and tunnel LDP in RSVP in the core.
>
> This was mostly to create single-hop LSP's so that we can
> solve unequal-cost path issues in the IGP to better utilize
> previously idle core links.
>
> That said, "MPLS-Enabled Applications" by Ina Minei & Julian
> Lucek is one place where I've seen RFC 4206 mechanisms
> documented in some form:
>
> http://books.google.com.my/books?id=3MszQLz2cdwC&pg=PT66&lpg=PT66&dq=mpls+enabled+applications+label+operations+are+analogous+to+those+in+the+ldp&source=bl&ots=Abxedzafk8&sig=ZlvuaQ0PLqpMmZIqQVp5tL_Zppw&hl=en&sa=X&ei=00j3TtXzDMnOrQePvexD&ved=0CB0Q6AEwAA#v=onepage&q&f=false
>
>
> Page 30 is what you're after. Maybe that can help - I can
> theorize its operations, but we haven't deployed this
> particular architecture in the field.
>
>> Thanks for
>> sharing the rib-import methodology to get rid of
>> staticroutes for inet.3 resolution for BGP-Next Hops..
>
> Most welcome.
>
>> Just a clarification on the "ldp-tunneling" part..Do I
>> need to applythis at all the PE/P routers to run LDP
>> over broken LSPs between PEs..Is there a provision in
>> Junos without using LDP Tunneling to passtraffic between
>> PEs when using broken LSPs ?
>
> I usually recommend that LDPoRSVP always be enabled on
> ingress routers for all LSP's. I also encourage them to be
> enabled on P routers that are also acting as ingress routers
> for RSVP LSP's.
>
> Otherwise, if a P router is merely a transit node for an
> LSP, then you wouldn't even be able to enabled LDPoRSVP, as
> you wouldn't have an LSP or tunnel under which to do that,
> both in IOS and Junos.
>
> Cheers
>
> Mark.



--
Regards
Vaibhava Varma

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


ivanov.ivan at gmail

Dec 26, 2011, 2:23 AM

Post #6 of 13 (978 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
Hi,

Try to enable LDP on the loopbacks on PE1, P1 and PE2 and you will have
FECs from PE1 to PE2 via LDP tunneled in both RSVP LSPs.

If I understand you correctly this what your trying to accomplish.

HTH
Ivan,

On Mon, Dec 26, 2011 at 09:24, vaibhava varma <svaibhava [at] gmail> wrote:

> Hi Mark
>
> Thanks for the help so far..I tried to use "ldp-tunneling" under RSVP
> TEs from PE-P to P-PE but it does not works as I do not have LDP
> enabled anywhere to tunnel it via RSVP..
>
> My setup is as below:
>
> CE1-PE1--RSVP-LSP1--P1--RSVP-LSP2--PE2--CE2
>
> How can I make the traffic flow from CE1 to CE2 in the MPLS VPN under
> this setup..I am really confused on this and not getting any
> solution..I am seeing all the routes and required lables for CE2
> routes at PE1 but no traffic flow is happening
>
> lab [at] edge1# run show route table CE1A.inet.0 172.16.251.1 extensive
>
> CE1A.inet.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden)
> 172.16.251.1/32 (2 entries, 1 announced)
> TSI:
> KRT in-kernel 172.16.251.1/32 -> {indirect(131071)}
> Page 0 idx 1 Type 1 val 8f0d594
> Nexthop: Self
> AS path: [64513] 64513 I
> Communities: target:64513:100
> Path 172.16.251.1 from 10.0.2.1 Vector len 4. Val: 1
> *BGP Preference: 170/-101
> Route Distinguisher: 64513:1
> Next hop type: Indirect
> Next-hop reference count: 10
> Source: 10.0.2.1
> Next hop type: Router, Next hop index: 131070
> Next hop: 10.0.10.2 via ge-0/0/0.0, selected
> Label operation: Push 16
> Next hop: 10.0.10.10 via ge-0/0/1.0
> Label operation: Push 16
> Protocol next hop: 10.0.6.1
> Push 16
> Indirect next hop: 8ffc000 131071
> State: <Secondary Active Int Ext>
> Local AS: 64513 Peer AS: 64513
> Age: 30:55 Metric: 0 Metric2: 2
> Task: BGP_64513.10.0.2.1+63485
> Announcement bits (2): 0-KRT 1-BGP RT Background
> AS path: 64514 I (Originator) Cluster list: 10.0.2.1
> AS path: Originator ID: 10.0.6.1
> Communities: target:64513:100
> Import Accepted
> VPN Label: 16
> Localpref: 100
> Router ID: 10.0.2.1
> Primary Routing Table bgp.l3vpn.0
> Indirect next hops: 1
> Protocol next hop: 10.0.6.1 Metric: 2
> Push 16
> Indirect next hop: 8ffc000 131071
> Indirect path forwarding next hops: 2
> Next hop type: Router
> Next hop: 10.0.10.2 via ge-0/0/0.0
> Next hop: 10.0.10.10 via ge-0/0/1.0
> 10.0.6.1/32 Originating RIB: inet.3
> Metric: 2 Node path count: 1
> Forwarding nexthops: 2
> Nexthop: 10.0.10.2 via ge-0/0/0.0
> Nexthop: 10.0.10.10 via ge-0/0/1.0
> BGP Preference: 170/-101
> Route Distinguisher: 64513:1
> Next hop type: Indirect
> Next-hop reference count: 10
> Source: 10.0.5.1
> Next hop type: Router, Next hop index: 131070
> Next hop: 10.0.10.2 via ge-0/0/0.0, selected
> Label operation: Push 16
> Next hop: 10.0.10.10 via ge-0/0/1.0
> Label operation: Push 16
> Protocol next hop: 10.0.6.1
> Push 16
> Indirect next hop: 8ffc000 131071
> State: <Secondary NotBest Int Ext>
> Inactive reason: Not Best in its group - Update source
> Local AS: 64513 Peer AS: 64513
> Age: 30:55 Metric: 0 Metric2: 2
> Task: BGP_64513.10.0.5.1+56350
> AS path: 64514 I (Originator) Cluster list: 10.0.5.1
> AS path: Originator ID: 10.0.6.1
> Communities: target:64513:100
> Import Accepted
> VPN Label: 16
> Localpref: 100
> Router ID: 10.0.5.1
> Primary Routing Table bgp.l3vpn.0
> Indirect next hops: 1
> Protocol next hop: 10.0.6.1 Metric: 2
> Push 16
> Indirect next hop: 8ffc000 131071
> Indirect path forwarding next hops: 2
> Next hop type: Router
> Next hop: 10.0.10.2 via ge-0/0/0.0
> Next hop: 10.0.10.10 via ge-0/0/1.0
> 10.0.6.1/32 Originating RIB: inet.3
> Metric: 2 Node path count: 1
> Forwarding nexthops: 2
> Nexthop: 10.0.10.2 via ge-0/0/0.0
> Nexthop: 10.0.10.10 via ge-0/0/1.0
>
> I have the Label for the Next-Hop 10.0.6.1 on the Core Router but on
> PE1 its just OSPF route..I think thats the problem here but how can I
> get label for remote PE loopback with broken LSPs..LDP tunneling is
> not the solution here I think..I tried announcing the PE1-P1 RSVP-LSP
> into OSPF but that also did not work..
>
> lab [at] core1# run show route 10.0.6.1
>
> inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 10.0.6.1/32 *[RSVP/7/1] 06:28:58, metric 1
> > to 10.0.10.22 via ge-0/0/3.0,
> label-switched-path to_edge1.pop2
> [OSPF/10] 00:03:14, metric 1
> > to 10.0.10.22 via ge-0/0/3.0
>
> inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 10.0.6.1/32 *[RSVP/7/1] 06:28:58, metric 1
> > to 10.0.10.22 via ge-0/0/3.0,
> label-switched-path to_edge1.pop2
>
> root [at] edge1# run show route 10.0.6.1
>
> inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 10.0.6.1/32 *[OSPF/10] 00:04:16, metric 2
> to 10.0.10.2 via ge-0/0/0.0
> > to 10.0.10.10 via ge-0/0/1.0
>
> inet.3: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 10.0.6.1/32 *[OSPF/10] 00:04:16, metric 2
> to 10.0.10.2 via ge-0/0/0.0
> > to 10.0.10.10 via ge-0/0/1.0
>
> Announcing LSP into IGP OSPF
>
> lab [at] edge1# run show route 10.0.6.1 extensive
>
> inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden)
> 10.0.6.1/32 (1 entry, 1 announced)
> TSI:
> KRT in-kernel 10.0.6.1/32 -> {10.0.10.10}
> *OSPF Preference: 10
> Next hop type: Router
> Next-hop reference count: 6
> Next hop: 10.0.10.2 via ge-0/0/0.0
> Next hop: 10.0.10.10 via ge-0/0/1.0, selected
> Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
> Label-switched-path to_core1.pop1
> Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
> Label-switched-path to_core1.pop2
> State: <Active Int>
> Local AS: 64513
> Age: 11 Metric: 2
> Area: 0.0.0.0
> Task: OSPF
> Announcement bits (1): 0-KRT
> AS path: I
> Secondary Tables: inet.3
>
> inet.3: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
>
> 10.0.6.1/32 (1 entry, 1 announced)
> *OSPF Preference: 10
> Next hop type: Router
> Next-hop reference count: 6
> Next hop: 10.0.10.2 via ge-0/0/0.0
> Next hop: 10.0.10.10 via ge-0/0/1.0, selected
> Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
> Label-switched-path to_core1.pop1
> Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
> Label-switched-path to_core1.pop2
> State: <Secondary Active Int>
> Local AS: 64513
> Age: 11 Metric: 2
> Area: 0.0.0.0
> Task: OSPF
> Announcement bits (1): 2-Resolve tree 1
> AS path: I
> Primary Routing Table inet.0
>
> I even tried manullay setting nect-hop of remote PE2 as LSP but that
> also did not work
>
> lab [at] edge1# run show route 10.0.6.1 extensive
>
> inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden)
> 10.0.6.1/32 (2 entries, 1 announced)
> TSI:
> KRT in-kernel 10.0.6.1/32 -> {10.0.10.2}
> *Static Preference: 5
> Next hop type: Router
> Next-hop reference count: 1
> Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1, selected
> Label-switched-path to_core1.pop1
> Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
> Label-switched-path to_core1.pop2
> State: <Active Int Ext>
> Local AS: 64513
> Age: 12
> Task: RT
> Announcement bits (1): 0-KRT
> AS path: I
> OSPF Preference: 10
> Next hop type: Router
> Next-hop reference count: 6
> Next hop: 10.0.10.2 via ge-0/0/0.0
> Next hop: 10.0.10.10 via ge-0/0/1.0, selected
> Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
> Label-switched-path to_core1.pop1
> Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
> Label-switched-path to_core1.pop2
> State: <Int>
> Inactive reason: Route Preference
> Local AS: 64513
> Age: 4:19 Metric: 2
> Area: 0.0.0.0
> Task: OSPF
> AS path: I
> Secondary Tables: inet.3
>
> inet.3: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
>
> 10.0.6.1/32 (1 entry, 1 announced)
> *OSPF Preference: 10
> Next hop type: Router
> Next-hop reference count: 6
> Next hop: 10.0.10.2 via ge-0/0/0.0
> Next hop: 10.0.10.10 via ge-0/0/1.0, selected
> Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
> Label-switched-path to_core1.pop1
> Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
> Label-switched-path to_core1.pop2
> State: <Secondary Active Int>
> Local AS: 64513
> Age: 4:19 Metric: 2
> Area: 0.0.0.0
> Task: OSPF
> Announcement bits (1): 2-Resolve tree 1
> AS path: I
> Primary Routing Table inet.0
>
> Thanks & Regards
> Vaibhava Varma
> On Sun, Dec 25, 2011 at 9:39 PM, Mark Tinka <mtinka [at] globaltransit>
> wrote:
> > On Sunday, December 25, 2011 09:35:52 PM vaibhava varma
> > wrote:
> >
> >> Thanks a lot for your response..I have everything working
> >> fine withLDP without any issues..I just wanted to deploy
> >> RSVP-TE for fasterfailover in the backbone..
> >
> > Ah okay. Got you.
> >
> >> And there I
> >> got stuck up with the full-meshof TE among PEs or using
> >> Broken Static LSPs between PE-P and P-PE..
> >
> > What we've done, in one of our networks, to scale MPLS-TE
> > was to enable RSVP only in the core, run LDP everywhere else
> > and tunnel LDP in RSVP in the core.
> >
> > This was mostly to create single-hop LSP's so that we can
> > solve unequal-cost path issues in the IGP to better utilize
> > previously idle core links.
> >
> > That said, "MPLS-Enabled Applications" by Ina Minei & Julian
> > Lucek is one place where I've seen RFC 4206 mechanisms
> > documented in some form:
> >
> >
> http://books.google.com.my/books?id=3MszQLz2cdwC&pg=PT66&lpg=PT66&dq=mpls+enabled+applications+label+operations+are+analogous+to+those+in+the+ldp&source=bl&ots=Abxedzafk8&sig=ZlvuaQ0PLqpMmZIqQVp5tL_Zppw&hl=en&sa=X&ei=00j3TtXzDMnOrQePvexD&ved=0CB0Q6AEwAA#v=onepage&q&f=false
> >
> >
> > Page 30 is what you're after. Maybe that can help - I can
> > theorize its operations, but we haven't deployed this
> > particular architecture in the field.
> >
> >> Thanks for
> >> sharing the rib-import methodology to get rid of
> >> staticroutes for inet.3 resolution for BGP-Next Hops..
> >
> > Most welcome.
> >
> >> Just a clarification on the "ldp-tunneling" part..Do I
> >> need to applythis at all the PE/P routers to run LDP
> >> over broken LSPs between PEs..Is there a provision in
> >> Junos without using LDP Tunneling to passtraffic between
> >> PEs when using broken LSPs ?
> >
> > I usually recommend that LDPoRSVP always be enabled on
> > ingress routers for all LSP's. I also encourage them to be
> > enabled on P routers that are also acting as ingress routers
> > for RSVP LSP's.
> >
> > Otherwise, if a P router is merely a transit node for an
> > LSP, then you wouldn't even be able to enabled LDPoRSVP, as
> > you wouldn't have an LSP or tunnel under which to do that,
> > both in IOS and Junos.
> >
> > Cheers
> >
> > Mark.
>
>
>
> --
> Regards
> Vaibhava Varma
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



--
Best Regards!

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


mtinka at globaltransit

Dec 26, 2011, 4:19 AM

Post #7 of 13 (969 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
On Monday, December 26, 2011 03:24:21 PM vaibhava varma
wrote:

> Thanks for the help so far..I tried to use
> "ldp-tunneling" under RSVP TEs from PE-P to P-PE but it
> does not works as I do not have LDP enabled anywhere to
> tunnel it via RSVP..

That's interesting, because I recall you mentioned that you
have LDP enabled everywhere and that is already working;
that you only needed RSVP for MPLS-FRR and MPLS-TE.

Mark.
Attachments: signature.asc (0.82 KB)


svaibhava at gmail

Dec 26, 2011, 6:37 AM

Post #8 of 13 (1015 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
HI Mark

Oh Yes what I mentioned for using LDP was without RSVP-TE at all..I
was trying to run RSVP-TE without using LDP at all..

With Ivan's suggestion I was enabled to get lables for the remote PE's
Loopback,,,

Thanks much to You and Ivan for your support on getting hold of this issue..

I finally summarize the network setup requirement to establish MPLS
VPN Traffic flow across Broken LSP as

1. Enable PE-P and P-PE RSVP TEs
2. Announce the RSVP-TEs into the IGP on PE and P routers
5. Import inet.0 routes to inet.3 using rib-group import at PE-Routers/RRs
3.Enable LDP Tunneling on the RSVP-TE at PE and P routers
4.Enable LDP on the Loopback interface at PE and P routers.

Thanks much again for all your help..

lab [at] edge1# run traceroute 10.0.6.1
traceroute to 10.0.6.1 (10.0.6.1), 30 hops max, 40 byte packets
1 10.0.10.10 (10.0.10.10) 3.943 ms 1.811 ms 2.832 ms
MPLS Label=300688 CoS=0 TTL=1 S=1
2 10.0.6.1 (10.0.6.1) 11.451 ms 3.897 ms 8.285 ms

[edit]
lab [at] edge1#



lab [at] edge1# run show route 10.0.6.1 extensive

inet.0: 17 destinations, 22 routes (17 active, 0 holddown, 0 hidden)
10.0.6.1/32 (2 entries, 2 announced)
State: <FlashAll>
TSI:
KRT in-kernel 10.0.6.1/32 -> {Push 300688}
*LDP Preference: 9
Next hop type: Router
Next-hop reference count: 3
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Label operation: Push 300608
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Label operation: Push 300608
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1, selected
Label-switched-path to_core1.pop2
Label operation: Push 300688
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
Label operation: Push 300688
State: <Active Int>
Local AS: 64513
Age: 53 Metric: 1
Task: LDP
Announcge-0/0/ent bits (1): 0-KRT
AS path: I
Secondary Tables: inet.3
OSPF Preference: 10
Next hop type: Router
Next-hop reference count: 5
Next hop: 10.0.10.2 via ge-0/0/0.0
Next hop: 10.0.10.10 via ge-0/0/1.0, selected
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
State: <Int>
Inactive reason: Route Preference
Local AS: 64513
Age: 22:46 Metric: 2
Area: 0.0.0.0
Task: OSPF
Announcge-0/0/ent bits (1): 3-LDP
AS path: I
Secondary Tables: inet.3

inet.3: 10 destinations, 15 routes (10 active, 0 holddown, 0 hidden)

10.0.6.1/32 (2 entries, 2 announced)
State: <FlashAll>
*LDP Preference: 9
Next hop type: Router
Next-hop reference count: 3
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Label operation: Push 300608
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Label operation: Push 300608
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1, selected
Label-switched-path to_core1.pop2
Label operation: Push 300688
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
Label operation: Push 300688
State: <Secondary Active Int>
Local AS: 64513
Age: 53 Metric: 1
Task: LDP
Announcge-0/0/ent bits (1): 2-Resolve tree 1
AS path: I
Primary Routing Table inet.0
OSPF Preference: 10
Next hop type: Router
Next-hop reference count: 5
Next hop: 10.0.10.2 via ge-0/0/0.0
Next hop: 10.0.10.10 via ge-0/0/1.0, selected
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label-switched-path to_core1.pop1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label-switched-path to_core1.pop2
State: <Secondary Int>
Inactive reason: Route Preference
Local AS: 64513
Age: 22:46 Metric: 2
Area: 0.0.0.0
Task: OSPF
Announcge-0/0/ent bits (1): 1-LDP
AS path: I
Primary Routing Table inet.0

[edit]
lab [at] edge1#


lab [at] edge1# run show route table CE1A.inet.0 172.16.251.1 extensive

CE1A.inet.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden)
172.16.251.1/32 (2 entries, 1 announced)
TSI:
KRT in-kernel 172.16.251.1/32 -> {indirect(131071)}
Page 0 idx 1 Type 1 val 8f0d8a4
Nexthop: Self
AS path: [64513] 64513 I
Communities: target:64513:100
Path 172.16.251.1 from 10.0.2.1 Vector len 4. Val: 1
*BGP Preference: 170/-101
Route Distinguisher: 64513:1
Next hop type: Indirect
Next-hop reference count: 10
Source: 10.0.2.1
Next hop type: Router, Next hop index: 131075
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label operation: Push 16, Push 300608(top)
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1, selected
Label operation: Push 16, Push 300608(top)
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label operation: Push 16, Push 300688(top)
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label operation: Push 16, Push 300688(top)
Protocol next hop: 10.0.6.1
Push 16
Indirect next hop: 8ffc000 131071
State: <Secondary Active Int Ext>
Local AS: 64513 Peer AS: 64513
Age: 28 Metric: 0 Metric2: 1
Task: BGP_64513.10.0.2.1+63485
Announcge-0/0/ent bits (2): 0-KRT 1-BGP RT Background
AS path: 64514 I (Originator) Cluster list: 10.0.2.1
AS path: Originator ID: 10.0.6.1
Communities: target:64513:100
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 10.0.2.1
Primary Routing Table bgp.l3vpn.0
Indirect next hops: 1
Protocol next hop: 10.0.6.1 Metric: 1
Push 16
Indirect next hop: 8ffc000 131071
Indirect path forwarding next hops: 4
Next hop type: Router
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
10.0.6.1/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 4
Nexthop: 10.0.10.2 via ge-0/0/0.0
Nexthop: 10.0.10.2 via ge-0/0/0.0
Nexthop: 10.0.10.10 via ge-0/0/1.0
Nexthop: 10.0.10.10 via ge-0/0/1.0
BGP Preference: 170/-101
Route Distinguisher: 64513:1
Next hop type: Indirect
Next-hop reference count: 10
Source: 10.0.5.1
Next hop type: Router, Next hop index: 131075
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Label operation: Push 16, Push 300608(top)
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1, selected
Label operation: Push 16, Push 300608(top)
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label operation: Push 16, Push 300688(top)
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Label operation: Push 16, Push 300688(top)
Protocol next hop: 10.0.6.1
Push 16
Indirect next hop: 8ffc000 131071
State: <Secondary NotBest Int Ext>
Inactive reason: Not Best in its group - Update source
Local AS: 64513 Peer AS: 64513
Age: 28 Metric: 0 Metric2: 1
Task: BGP_64513.10.0.5.1+56350
AS path: 64514 I (Originator) Cluster list: 10.0.5.1
AS path: Originator ID: 10.0.6.1
Communities: target:64513:100
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 10.0.5.1
Primary Routing Table bgp.l3vpn.0
Indirect next hops: 1
Protocol next hop: 10.0.6.1 Metric: 1
Push 16
Indirect next hop: 8ffc000 131071
Indirect path forwarding next hops: 4
Next hop type: Router
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1
10.0.6.1/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 4
Nexthop: 10.0.10.2 via ge-0/0/0.0
Nexthop: 10.0.10.2 via ge-0/0/0.0
Nexthop: 10.0.10.10 via ge-0/0/1.0
Nexthop: 10.0.10.10 via ge-0/0/1.0

[edit]
lab [at] edge1#

On Mon, Dec 26, 2011 at 5:49 PM, Mark Tinka <mtinka [at] globaltransit> wrote:
> On Monday, December 26, 2011 03:24:21 PM vaibhava varma
> wrote:
>
>> Thanks for the help so far..I tried to use
>> "ldp-tunneling" under RSVP TEs from PE-P to P-PE but it
>> does not works as I do not have LDP enabled anywhere to
>> tunnel it via RSVP..
>
> That's interesting, because I recall you mentioned that you
> have LDP enabled everywhere and that is already working;
> that you only needed RSVP for MPLS-FRR and MPLS-TE.
>
> Mark.



--
Regards
Vaibhava Varma
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


mtinka at globaltransit

Dec 26, 2011, 7:10 AM

Post #9 of 13 (987 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
On Monday, December 26, 2011 10:37:12 PM vaibhava varma
wrote:

> Oh Yes what I mentioned for using LDP was without RSVP-TE
> at all..I was trying to run RSVP-TE without using LDP at
> all..

Ah okay. That makes sense, then, as I assumed you were still
running LDP even after turning on RSVP for "LDP and RSVP" as
opposed to "LDP or RSVP".

> With Ivan's suggestion I was enabled to get lables for
> the remote PE's Loopback,,,
>
> Thanks much to You and Ivan for your support on getting
> hold of this issue..

Glad to hear it's working out.

> I finally summarize the network setup requirement to
> establish MPLS VPN Traffic flow across Broken LSP as

Just from our own point of view (if you can find this
useful), we use both LDP and RSVP in our network.

LDP is used everywhere (especially the Metro-E Access
switches) and RSVP is only used among the PE Aggregation
routers. RSVP is used there as this is the point in the
network where we terminate p2mp LSP's for NG-MVPN (IPTv
Multicast services). This also includes facility backup
(node-link protection) for p2mp and p2p LSP's.

The core routers also run LDP and RSVP (RSVP for transit
LSP's only).

We're looking to support mLDP for p2mp LSP's for data
Multicast services, as RSVP might be overkill for such
deployments.

All PE Aggregation routers run LDPoRSVP.

We don't generally plan to run RSVP in the Metro-E Access,
due to the sheer number of devices, but might if it makes
commercial sense for a couple of customers, e.g., those that
require 50ms failover between primary and protect circuits.

Cheers,

Mark.
Attachments: signature.asc (0.82 KB)


svaibhava at gmail

Dec 26, 2011, 7:23 AM

Post #10 of 13 (978 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
HI Mark

Thanks again for sharing your views :-)

I was wondering whether mLDP with Junos has been out of roadmap and
now ready for field deployment ?

Regards
Varma

On Mon, Dec 26, 2011 at 8:40 PM, Mark Tinka <mtinka [at] globaltransit> wrote:
> On Monday, December 26, 2011 10:37:12 PM vaibhava varma
> wrote:
>
>> Oh Yes what I mentioned for using LDP was without RSVP-TE
>> at all..I was trying to run RSVP-TE without using LDP at
>> all..
>
> Ah okay. That makes sense, then, as I assumed you were still
> running LDP even after turning on RSVP for "LDP and RSVP" as
> opposed to "LDP or RSVP".
>
>> With Ivan's suggestion I was enabled to get lables for
>> the remote PE's Loopback,,,
>>
>> Thanks much to You and Ivan for your support on getting
>> hold of this issue..
>
> Glad to hear it's working out.
>
>> I finally summarize the network setup requirement to
>> establish MPLS VPN Traffic flow across Broken LSP as
>
> Just from our own point of view (if you can find this
> useful), we use both LDP and RSVP in our network.
>
> LDP is used everywhere (especially the Metro-E Access
> switches) and RSVP is only used among the PE Aggregation
> routers. RSVP is used there as this is the point in the
> network where we terminate p2mp LSP's for NG-MVPN (IPTv
> Multicast services). This also includes facility backup
> (node-link protection) for p2mp and p2p LSP's.
>
> The core routers also run LDP and RSVP (RSVP for transit
> LSP's only).
>
> We're looking to support mLDP for p2mp LSP's for data
> Multicast services, as RSVP might be overkill for such
> deployments.
>
> All PE Aggregation routers run LDPoRSVP.
>
> We don't generally plan to run RSVP in the Metro-E Access,
> due to the sheer number of devices, but might if it makes
> commercial sense for a couple of customers, e.g., those that
> require 50ms failover between primary and protect circuits.
>
> Cheers,
>
> Mark.



--
Regards
Vaibhava Varma
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


mtinka at globaltransit

Dec 26, 2011, 7:49 AM

Post #11 of 13 (977 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
On Monday, December 26, 2011 11:23:38 PM vaibhava varma
wrote:

> I was wondering whether mLDP with Junos has been out of
> roadmap and now ready for field deployment ?

mLDP showed up in Junos 11.2:

http://www.juniper.net/techpubs/en_US/junos11.2/topics/example/mcast-
mbgp-mvpn-ldp.html


We haven't tried this yet since we're stuck on 10.4 for now.
We'll likely bring this online when both Cisco and Juniper
have parity for NG-MVPN driven by mLDP and RSVP.

Mark.
Attachments: signature.asc (0.82 KB)


jr at xor

Dec 27, 2011, 1:03 AM

Post #12 of 13 (978 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
On 26.12.2011 16:49, Mark Tinka wrote:
> On Monday, December 26, 2011 11:23:38 PM vaibhava varma
> wrote:
>
>> I was wondering whether mLDP with Junos has been out of
>> roadmap and now ready for field deployment ?
>
> mLDP showed up in Junos 11.2:
>
> http://www.juniper.net/techpubs/en_US/junos11.2/topics/example/mcast-
> mbgp-mvpn-ldp.html

FWIW, we're using NG-MVPN based on mLDP with 11.2 in production (MX/T).
Works well so far, but of course there are caveats, particularly on the
HA side - missing NSR/ISSU support, missing link-protection etc.
And, still no NSR/ISSU support for the NG-MVPN BGP AFI :/ That is not
specific to mLDP, though.

11.2 releases prior to 11.2R4 have quite a few nasty NG-MVPN PIM bugs,
would recommend to stay away of those.

cheers,
-jr

PS: we have ERs open to cover all the missing HA NG-MVPN/mLDP points. If
anyone else is interested in those features, drop me a mail. Might be
possible to speed up implementation if more customer demand can be
demonstrated to Juniper..
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


mtinka at globaltransit

Dec 27, 2011, 1:16 AM

Post #13 of 13 (967 views)
Permalink
Re: Juniper MPLS VPN using PE-P and P-PE LSPs ! [In reply to]
On Tuesday, December 27, 2011 05:03:06 PM Johannes Resch
wrote:

> FWIW, we're using NG-MVPN based on mLDP with 11.2 in
> production (MX/T). Works well so far,...

Great to hear.

Are you using it for real-time Multicast, e.g., IPTv, or
non-critical Multicast?

Our target is to use mLDP for non-critical, data Multicast
services, and leave RSVP for IPTv and such.

> but of course
> there are caveats, particularly on the HA side - missing
> NSR/ISSU support,

Is Graceful Restart supported, at least?

> missing link-protection etc.

Well, LDP has no link-protection capabilities, so not sure
how those would come to mLDP.

What I know Cisco are doing with their mLDP implementation
for now is link-protection, but via RSVP. I haven't tested
it, though.

> And,
> still no NSR/ISSU support for the NG-MVPN BGP AFI :/
> That is not specific to mLDP, though.

We're still relying on Graceful Restart for that.

> 11.2 releases prior to 11.2R4 have quite a few nasty
> NG-MVPN PIM bugs, would recommend to stay away of those.

As one would with any pre-R4 release :-).

> PS: we have ERs open to cover all the missing HA
> NG-MVPN/mLDP points. If anyone else is interested in
> those features, drop me a mail. Might be possible to
> speed up implementation if more customer demand can be
> demonstrated to Juniper..

Yes, we're certainly interested in having those features
there.

Cheers,

Mark.
Attachments: signature.asc (0.82 KB)

nsp juniper RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.