Re: [j-nsp] Avoid transit LSPs
Luis- You could probably set the overload bit. -Colby On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" wrote: I'm not aware of any option that will do this. The three solutions that I can think of are: Link colouring like Adam suggests An explicit path that avoids the interfaces you are worried about Set the RSVP cost for the interfaces really high Dave On Thu, 24 Jan 2019 at 17:01, Luis Balbinot wrote: > It's a permanent thing. > > These boxes are PE routers that are not supposed to handle transit > traffic but during certain network events a few FRR bypass LSPs are > established through them because that's the only remaining path. > > Something easier like a "no-eligible-backup" toggle like the one we > have with OSPF LFA would be nice. > > Luis > > On Thu, Jan 24, 2019 at 2:53 PM wrote: > > > > > Luis Balbinot > > > Sent: Thursday, January 24, 2019 4:45 PM > > > > > > Hi. > > > > > > How could I prevent a device from getting transit RSVP LSPs being > > > established through it? I only want it to accept ingress LSPs destined > to > > that > > > box. > > > > > If this is a permanent thing, > > You could create a colouring scheme where all links connected to this > node > > have to be avoided by all LSPs with the exception of LSPs terminated on > this > > node (or originated by this node). > > > > If this is a maintenance thing, > > There's a command that can be enabled to drain all transit LSPs out the > box. > > But, all the LSPs would need to be configured with this capability in the > > first place. > > > > > > adam > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU= ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Use cases for IntServ in MPLS backbones
Adam- There are a couple of clever Diffserv-TE (what your calling IntServ) deployments out there. Both RDM & MAM are deployed. Truthfully, they are pretty quiet, mainly, because the upfront planning that is required to go into them and the relative lack of variations in the deployments. Diffserv-TE offers some interesting per class/sub-pool BW protection options that other deployments(see below) may not. Multi-class LSPs are also possible. What is much more commonly deployed is what I would refer to as Class-Based Forwarding. Your still combing COS based forwarding policies (like Diffserv-TE), in the data-plane, with LSP BW reservations in the control-plane but without the sub-pool BW reservations and relatively complicated BW sharing models offered by RDM or MAM. Both have their place depending on your specific service requirements. Hth, -Colby On 10/1/18, 6:45 AM, "juniper-nsp on behalf of adamv0...@netconsultings.com" wrote: Hi folks, Another pooling question from me, This time I'm interested on what are your thoughts on DiffServ vs IntServ in MPLS backbones and what use cases for IntServ can you think of please. So what I have in mind specifically is RSVP-TE in combination with DiffServ (standard QoS) vs IntServ (in all its glory i.e. BW pools and sub-pools, allocation models RDM/MAM, etc..). adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U=3QGSTryRPkSQi9gbZ4EEoEZq15OCtNIEr95BxH8E4Io=L1GMCwDLD4n9VecEVDCtJmZnunojow1JU1KeHEnFPwo= ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
In my experience, I have seen used the knob to only allocate labels for host routes or use a prefix-list match that covers ALL your nodes loopback addresses so that the prefix-list does not have to be constantly touched. router# configure terminal router(config)# mpls ldp label router(config-ldp-lbl)# allocate global host-routes -Colby On Aug 14, 2013, at 11:37 AM, Eric Van Tol e...@atlantech.net wrote: Hi all, We've had MPLS running on our network for years using JUNOS and until only very recently, we haven't had to deal with any of our Cisco equipment needing MPLS. That changed when we started purchasing ME3600X switches so we could provide VPN services in our metro fiber rings. I'm trying to wrap my head around how other people handle the label filtering in Cisco-world. As you know, JUNOS will only advertise a label for the local loopback, but IOS will advertise anything it has a destination to. Because of this, we've had to implement label filtering on the Cisco switches. While this works, it seems kind of cumbersome, especially when we need to add a new MPLS-capable device to the network, a prefix-list has to be updated. If a non-MPLS device is added, another prefix-list has to be updated. Is this the normal way of doing things, or is there something I am missing? I suppose we could assign a certain range of addresses out of our loopback subnet to be used solely for non-MPLS devices, but what happens when one day we need to add MPLS capabilities via a license or an entire hardware replacement? Any ideas or clue-bats upside the head would be appreciated. THanks, evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP RR for Labeled Unicast Family
You need to tell BGP to use rib inet.3 for the LU prefixes.
Set protocols bgp family inet label-unicast rib inet.3
... Or something like that.
Hope that helps.
-Colby
Sent from my iPhone
On Feb 16, 2013, at 4:06 PM, Farhat Abbasse ab_ferha...@hotmail.co.uk wrote:
HI Community,
I wonder if anyone has already tried to configure RR for labeled Unicast
family ?
I have configured the BGP RR for both families inet-vpn and labeled-unicast
on the same router, the RR for the inet-vpn worked perfectly, however for
Labeled Unicast family it did not work.
Below are the topology and the Configurations that I have done:
---
| RR |
//---\\
// \\
---
| R1 | | R2 |
---
RR Router:
group LU_M-iBGP {
type internal;
local-address 10.200.240.1;
family inet {
labeled-unicast
}
family inet-vpn {
unicast;
}
export Export-Loopback;
cluster 10.200.240.1;
neighbor 10.200.240.2;
neighbor 10.200.240.11;
}
policy-options policy-statement Export-Loopback
term Loopback {
from interface lo0.0;
then accept;
}
R1:
admin@R1# show protocols bgp
group LU_M-iBGP {
type internal;
local-address 10.200.240.2;
family inet {
labeled-unicast
}
family inet-vpn {
unicast;
}
export Export-Loopback;
neighbor 10.200.240.1;
}
admin@R1# show policy-options policy-statement Export-Loopback
term Loopback {
from interface lo0.0;
then accept;
}
R2:
admin@R2# show protocols bgp
group LU_M-iBGP {
type internal;
local-address 10.200.240.11;
family inet {
labeled-unicast
}
family inet-vpn {
unicast;
}
export Export-Loopback;
neighbor 10.200.240.1;
}
admin@R2# show policy-options policy-statement Export-Loopback
term Loopback {
from interface lo0.0;
then accept;
}
I do not know if Labeled unicast family do support Route-Reflector ?
Thanks in advance for your Support.
BR/
Farhat
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Traffic balancing over LSPs
The dest prefix needs to resolve over the LSP. IGP short-cuts is an easy way to make that happen and should work for you but I see you tried that already and had some issue. I would suggest trying to understand why igp shortcuts breaks something else. You can also use a rib-group on the LSP head-end to populate inet3 as needed. -cb On Jan 18, 2013, at 10:11 AM, James Ashton wrote: All, Just to clarify a few things, The destination is not in inet.3. I do not have a direct LSP to the destination and cannot create one (The destination doesn't support MPLS nor does it support BGP) The show route output is: jashton@cr01-re0 show route xx.xxx.xx.x/24 inet.0: 448173 destinations, 3298320 routes (445123 active, 39 holddown, 465440 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both xx.xxx.xx.x/24 *[OSPF/150] 1d 12:35:24, metric 20, tag 0 to xx.xxx.xx.x via xe-4/2/0.0 [BGP/170] 01:03:59, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via xe-5/2/0.0 [BGP/170] 6d 19:17:07, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via ae3.0 [BGP/170] 6d 18:57:09, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via ae2.0 [BGP/170] 6d 19:03:11, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via ae2.0 [BGP/170] 6d 19:02:45, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via ae2.0 [BGP/170] 6d 19:18:02, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via xe-4/2/0.0 [BGP/170] 6d 17:40:10, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via xe-5/2/0.0 [BGP/170] 2d 13:54:44, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via ae6.0 [BGP/170] 6d 19:20:12, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via xe-4/2/0.0 [BGP/170] 6d 17:31:28, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via xe-5/2/0.0 [BGP/170] 6d 17:40:12, MED 20, localpref 100, from xx.xxx.xx.x AS path: I to xx.xxx.xx.x via xe-5/2/0.0 inet.3: 1232 destinations, 1248 routes (9 active, 0 holddown, 1232 hidden) - Original Message - From: Colby Barth cba...@juniper.net To: James Ashton ja...@gitflorida.com Sent: Friday, January 18, 2013 9:31:51 AM Subject: Re: [j-nsp] Traffic balancing over LSPs James- Could you possibly send the output of 'show route x.x.x.x/y' for one of the destinations that you think should resolve over the LSP? I suspect that this destinations are not in inet3 for some reason. -Colby On Jan 18, 2013, at 8:49 AM, Phil Bedard wrote: Is it all one OSPF area or is the CMTS in an area other than 0? If the MX480 is an ABR you can restrict the OSPF routes and originate them on the MX480 as BGP instead using aggregate statements. Phil From: James Ashton Sent: 1/17/2013 11:07 To: juniper-nsp@puck.nether.net Subject: [j-nsp] Traffic balancing over LSPs I have an interesting situation that has me stumped for the moment. I have an OSPF speaking device (ARRIS CMTS) hanging off from an EX Switch. That switch is uplinked to an MX480 which is part of the network core. It has several paths into it from rest of the network. From several major traffic centers in the network I have 3 LSPs created to the MX480. I am running mpls traffic-engineering mpls-forwarding throughout the network. As the end users hanging off the CMTS are advertised onto the network via OSPF, and I cannot terminate LSPs on the CMTS, the traffic to these users is not being forwarded over the LSPs. I have tested enabling ospf traffic-engineering shortcuts but that is breaking several paths in the network to legacy areas with odd configs. My question is basically, how can I get this traffic into these LSPs in way that is more manageable at scale than a pile of static routes. I hope the above is clear, I am low on Caffeine at the moment. Thank you in advance for any help/ideas. James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6pe between Cisco and Juniper
Mihai-
Based on the error message:
peer: inet-unicast inet6-unicast inet6-labeled-unicast(273) us:
inet-unicast inet6-labeled-unicast(257)
You need to enable the unicast address family under ipv6
set protocols bgp group test family inet6 unicast
-cb
On Sep 3, 2012, at 11:04 AM, Mihai Gabriel wrote:
Hello,
Did any of you manage to configure a bgp session between Cisco and Juniper
using family inet6 labeled-unicast on Juniper? I am trying to configure 6PE
but the bgp session does not come up because Juniper does not send
ipv6-unicast capabity to Cisco
Juniper config:
group test {
type internal;
local-address 10.10.10.10;
import pol-reject-any;
family inet {
unicast;
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
export pol-reject-any;
neighbor 10.10.10.20;
Cisco config:
neighbor test peer-group
neighbor test remote-as 65500
neighbor test update-group loopback0
address-family ipv4
neighbor test send-community
neighbor test send-label
neighbor 10.10.10.10 activate
address-family ipv6
neighbor test send-community
neighbor test send-label
neighbor 10.10.10.10 activate
and the error:
Sep 3 17:33:31 juniper rpd[2115]: bgp_process_caps: mismatch NLRI with
10.10.10.20 (Internal AS 65500):
peer: inet-unicast inet6-unicast inet6-labeled-unicast(273) us:
inet-unicast inet6-labeled-unicast(257)
Any advice?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco IGP fast convergence
All-
JUNOS has a few config options and we have interop'd in the field for sometime
with Cisco's IGP FC config's:
SPF IW value defaults:
IOS-XR default: IW: 50ms, 2ndaryW: 200ms, MaxW: 5000ms
JUNOS defaults: IW: 200ms, MaxW: 5000ms, RRs: 3
The Cisco alg. is an exponentially increasing timer, whereas ours is not. As
an example, if a router receives a new LSP at time 0, Cisco will run a full SPF
50ms later. If a 2nd LSP is rx'd, the router will not run another SPF
computation for a minimum of 200ms. If a 3rd LSP is rx'd then the next SPF IW
timer is 400 msec and so on and so forth until the maximum wait achieved.
In the JUNOS implementation, we will run consecutive full SPFs on 200 ms
intervals 3 times and then we wait the holddown interval before we run another
full SPF. Forcing the implementations to approach one another requires config
on both sides. The end result is you really want to tune the IW values to
match, reduce the IOS-XR secondary wait timer and reduce both the JUNOS and
IOS-XR holddown timers to approach SPF alignment.
JUNSO config:
spf-options {
delay 50;
holdtime 3000;
rapid-runs 3;
}
IOS-XR SPF configuration:
spf-interval initial-wait 50 secondary-wait 100 maximum-wait 3200 level 2
I don't agree that you want the SPF IW to = 0. In the case of SRLG's in the
network you may want to have a bit of delay in there to try and capture all the
incoming LSPs before running an SPF. This is a personal preference and network
dependent but would be my recommendation. Your also gonna want to change the
IOS-XR lsp generation timers.
IOS-XR SPF configuration
spf-interval initial-wait 50 secondary-wait 100 maximum-wait 3200 level 2
This will align JUNOS and IOS-XR in that regard.
There are also changes recommended for cnsp intervals, LSP generation intervals
lsp intervals that require changes (mostly in IOS-XR) that you should
consider. Unicast me if you are interested in a thorough explanation and JUNOS
and IOS-XR config's.
thanks,
-Colby
On May 29, 2012, at 2:38 PM, Saku Ytti wrote:
On (2012-05-29 07:08 -0700), Doug Hanks wrote:
Or just use BFD ...
Not really solution for SPF timers though. Juniper is clearly lacking in
SPF configuration options. What you operationally want is 0 delay for SPF
calculation to start, to cover typical event of single link going down as
rapidly as possible. (Sure for some topologies LFA will cover that)
But if LSPs keep coming in, you want to exponentially back-off, to run SPF
less and less frequently.
Same thing as interface up/down dampening, here also JunOS has just static
values, no exponential back-off.
Both cause you to choose rather conservative value in JunOS, while in IOS
you can rock aggressive values.
--
++ytti
___
juniper-nsp mailing list
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
