Re: [j-nsp] AS Path regular expression for Null AS
Just a guess but try ^ $ to match beginning and end with nothing in
between. Or you can match against ^ 1234{0,1} $ which matches the
null as or a single occurrence of only AS 1234 (just insert any unused
AS).
-J Scott
On Mon, Jun 21, 2010 at 3:10 PM, Leah Lynch leah.ly...@clearwire.com wrote:
I cannot seem to get any of the regular expressions that I know of for null
AS to work. I have tried () and * and neither expression returns any
results. Does anyone out there have a known working expression for this on
M/MX routers?
Leah
This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review, use, distribution or disclosure by
others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.
___
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
[j-nsp] MS-DPC Licensing (CLI)
Does anyone know how to show licensing info (through cli specifically for MS-DPC) or know of a doc specifically related to MS-DPC for MX series (again, cli, not marketing)? I can't find any cli command to confirm we have the licenses required, nor do I see any error messages saying that there is a licensing issue. Does MS-DPC hook into 'show system license' ? Additionally, configuring services has proved to be cumbersome. Does anyone know of a guide or two relating to this besides Services Interfaces Configuration Guide. Something with a working explained config would be nice ... -J Scott ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Understanding DPC Cards
I don't have time to get all of it but very quickly the command you mentioned:
set chassis network-services ip;
refers to if you want this MX to be a L2 or L3 box. Changing this
requires a reset AFAIK. When in network-services ethernet mode you
can only use the DPC-X cards which are priced cheaper and have limited
L3 functionality. Chances are you want to keep this in IP mode since
you are using an R card (I assume they are both R cards, and not X
cards).
Also, comparing EX vs MX configs should be viewed like comparing cisco
ios to ios-xr. AFAIK, these are separate codebases. You need to
compare to J, T, or M series configs.
-J Scott
On Tue, May 4, 2010 at 2:05 PM, Paul Stewart p...@paulstewart.org wrote:
Hi there..
I'm not sure if I'm asking this right . again, as I mentioned earlier - I'm
a Cisco guy jumping into the JunOS world so pardon me if I've missed this
somewhere in the docs. my translation between the two worlds is slow but
steady..
Working on an MX480 that has a pair of DPC cards (DPCE 20x 1GE + 2x 10GE R).
Some questions ;)
Can someone give me in simple terms what the differences are between
chassis network-services Ethernet and chassis network-services IP?
Secondly, on EX switches (which I'm just getting used too) we can do:
ge-0/0/12 {
description xxx;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ ]
On the MX it seems this is quite different? I have the following:
ge-5/0/2 {
description ;
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 61;
}
}
I'm sure this isn't correct J This is what I created after reading some of
the Juniper docs with a lack of understanding what
flexible-ethernet-services actually refers too..
My goal is to have a dot1q trunk come in with a dozen or so VLAN's on it and
then create layer3 RVI's for them. The RVI configuration I have is this
(which again I know is wrong):
vlan {
unit 61 {
family inet {
address xxx.xx.235.34/24;
}
family inet6 {
address xxx:xxx:235::34/64;
}
}
Any assistance is much appreciated - thanks again to those folks who helped
earlier with my BGP questions.
Paul
___
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] RFC2544 on Juniper MX960 10G ports
Yes what you see is correct behavior (for those MX DPCs). I doubt it's a cell size issue or you would see a saw-tooth. Instead what you can infer is that each of the 4 PFE's are limited to the packets-per-second they can process depending on the transport type involved. I.E. VPLS is really bad at low packet sizes but pure L3 is good. -J Scott On Thu, Feb 18, 2010 at 5:08 PM, OBrien, Will obri...@missouri.edu wrote: We have been running 10G R cards exclusively in our pair of MX960s - so far we have had no issues with vpn tunnels coming in/out and we have many of them. We don't run voip over that particular connection either. In fact, we've really seen no problems with traffic going through them at all. We do run them exclusively at the edge of our network as border routers for I1 and I2 traffic. Typical I1 load is near a Gb and I2 usually has a few. Will On Feb 18, 2010, at 6:28 PM, Serge Vautour wrote: Hello, We recently used a traffic generator to run RFC2544 tests against a Juniper MX960. The 1G ports work flawlessly. 0% packet loss at all frame sizes. The 10G ports (4x10G R card) didn't do as well. They dropped up to 25% packets with certain small frames (ex: 70 byte frames). The packet loss goes away almost completely for frames larger than 100 bytes. Our SE tells us this is normal and is due to how the MX chops the frames up into 64 byte cells inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G port) and each of them has 10G of bandwidth. 10G of small frames essentially creates more than 10G of traffic inside the PFE. That explanation may not be 100% correct but I think it paints the right picture. Now the questions. Is this a problem on production networks with real world traffic? What about on VPN networks with alot of small frames like VoIP? Has anyone seen this problem creep it's head in production? It seems very unlikely to me that a maxed 10Gbps link would carry 7.5Gbps of frame sizes less than 100 byte. I would expect larger frames to use up the majority of the bandwidth. Can anyone correlate this with real world traffic? As usual, the help received on this distribution list is invaluable. Thanks in advance to anyone who replies. Serge __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. ___ 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] bfd = busted failure detection :)
In lab tests, RSVP success during ISSU was hit-or-miss. There were several cases that is did work but It seemed to be not entirely based on configuration (some degree of random failure). AFAIK it still hasn't been officially listed as supported in release notes or upgrade guides. Am I missing something? -J Scott On Tue, Dec 15, 2009 at 4:04 PM, Richard A Steenbergen r...@e-gerbil.netwrote: On Tue, Dec 15, 2009 at 04:53:44PM +0800, Mark Tinka wrote: We've always been in favour of the NSR concept since inception, but the reason we didn't choose it at the time was because of limited protocol support (early days of JUNOS 9.x). Also, only a handful of boxes on the Cisco side support(ed) NSR, yet we like to standardize feature sets even between vendors. As at today, NSR supports nearly all major protocols in JUNOS, so it's come back to the table for consideration. Your feedback is certainly encouraging. Until then, it's Graceful Restart for now (which, for better or worse, we've been happy with these past 2 years). It's been slowly trickling in over the last couple years, with each new code rev. The last protocol support we were waiting on for NSR was RSVP, which finally came in 9.6. Of course we aren't running 9.6 anywhere yet, but NSR+ISSU has been working reasonably well in tests of prior versions with only modest RSVP traffic disruptions, which is still better than nothing. The only thing to note is that the process takes FOREVER to complete, reminds me of trying to do GR back in the day of RE-2.0's, where it took 30 minutes to sync up after a restart. When 9.6R3 comes out we're planning to start limited deployment experiments in a couple select test sites, and with any luck our next round of widespread upgrades will be something where NSR+ISSU is fully working. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] QoS in L2VPN
A book that did well for my colleagues was http://search.barnesandnoble.com/Advanced-QoS-for-Multi-Service-Based-IP-Mpls-Networks/Ram-Balakrishnan/e/9780470293690although it's ALU-centric. On Tue, Dec 1, 2009 at 4:43 AM, Ibariouen Khalid ibariouen.kha...@ericsson.com wrote: Dear community Can someone send me a document which explains QoS in L2VPN. Thank you very much ___ 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] juniper trinity
The datasheet for the new MX 3D line cards is a little strange. Assuming that a find-and-replace of KB to K will make it more coherent, this is an awesome amount of queues when comparing to competitors. However, the new FPC/PIC-like card strategy is in 30Gb/s and 60Gb/s flavors. Given that the 16x10GE card is oversubscribed this looks like the old DPC 4x10Gb/s stacked complex design (except now it is 4x30Gb/s?). I guess this because the numbering is much like the DPC in that they are 0/0-3 1/0-3 2/0-3 3/0-3. Would Juniper really come out with a 30Gb/s (full duplex) chipset? With no 40GE announcement I can only assume this chipset is going to be damn hard (or expensive) to do 40GE interfaces. Am I just missing something? -J Scott On Mon, Oct 26, 2009 at 12:16 AM, magno massimo.magn...@gmail.com wrote: I agree, and I am pretty sure the new chipset will encompass and largely extend all the qos functionalities provided today by ez-chip chip. Cheers. Max On 24/10/2009, Richard A Steenbergen r...@e-gerbil.net wrote: On Sat, Oct 24, 2009 at 06:38:53PM +0200, magno wrote: I repeat, Trinity has nothing to do with ez-chip. My advice is to stop elucubrating around any ez-chip whatever. Ez-chip proved to be quite limited for some qos functions, so I really don't think juniper wants to be qos feature limited by a third-party chip anymore. I believe the original question was do the new asics integrate the functionality of ezchip, thus eliminating the need for it, and from what I've heard I believe the answer is yes. That is why we're talking about the ezchip in the first place. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] CLI/OP Script Interaction
Actually, I was talking about the more automated features rather than an extra ruleset. Thanks for this info, though, I was unaware of this ability which also sounds very powerful. -J Scott On Thu, Oct 22, 2009 at 6:50 PM, Nilesh Khambal nkham...@juniper.netwrote: I think you should be looking for commit-script for your requirements. I don't think JUNOS can validate the configuration as they are being entered. It can only perform the built-in CLI validity checks. Commit-script has the ability to validate your candidate configuration at commit time against the rules you define in the script. It can either add/fix your broken configuration by adding the missing configuration or fail your commit with an error or give you a commit time warning if the configuration being committed does not meet the standard you define in commit-script. AFAIK, OP scripts are mainly used for simplifying or automating some cli operations to show you the customized outputs or do some other customized tasks. It is generally not a good practice to perform configuration changes/commits using OP scripts. I am not a script expert. So I would defer it to the experts on the list. Thanks, Nilesh. On 10/22/09 6:31 PM, Judah Scott judah.scott@gmail.com wrote: I am just starting to look into the scripting abilities of the JUNOS software and am wondering just in general how it interacts with the configuration performed through CLI. I have some general questions such as: When a configuration change happens simultaneously as an admin is building a candidate config to be commited... Do the scripting changes get incorporated into this candidate config or are they commited through another channel? Does the user editing the config see the changes being added to his config changes or are the scripting changes applied in the background to the running config? Does the 'config exclusive' mode block the script? Does config private/dynamic affect this behavior? Thanks in advance! -J Scott ___ 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] CLI/OP Script Interaction
Thanks Phil. Both responses are very helpful. Just a quick clarification on: Long answer: Commit scripts can emit both normal changes and transient changes, and an op script can make data (say by defining an apply-macro) that will trigger an op script to make transient changes, but an op script cannot do these itself. What is a transient change? Is this one that goes straight into the running config (almost like running a partial commit or bypassing commit stage entirely). Also do you mean an op script can trigger a commit-script to make transient changes? (It looks like the second op script was meant to say commit-script. Thanks, -J Scott On Thu, Oct 22, 2009 at 6:57 PM, Phil Shafer p...@juniper.net wrote: Nilesh Khambal writes: It is generally not a good practice to perform configuration changes/commits using OP scripts. Op scripts can build config from command line arguments, user answers to interactive questions, operational state, or any combination of the above. This means you can get scripts like: u...@cli op tunnel Enter remote endpoint address [ipaddr]: 10.5.22.2 [opening connection to 10.5.22.2 ... ] [connected] remote endpoint rdu is a m7i running 9.5R1 (S/N A6789) Choose Style of tunnel [gre,ipsec]: gre Enter Local Endpoint Address: 10.5.1.2 Enter Remote Endpoint Address: 10.5.16.2 Configure Numbered link? (default: no) [yes/no]: yes Enter Link Prefix: 10.11.22.1/30 Entering data for Local Interface: Available tunnel interfaces: gr-1/2/0 (3 tunnel(s) configured) gr-1/2/0.0: 10.3.2.1/30 (Link from dent to rdu) gr-1/2/0.1: 10.6.5.5/30 (Link from dent to rdu) gr-1/2/0.2: 10.3.222.1/30 (Link from dent to rdu) Enter Tunnel interface (default: gr-1/2/0.3): Entering data for Remote Interface: Available tunnel interfaces: gr-1/2/0 (3 tunnel(s) configured) gr-1/2/0.0: () gr-1/2/0.1: 10.3.222.2/30 (Link from rdu to dent) gr-1/2/0.2: 10.3.2.2/30 (Link from rdu to dent) Enter Tunnel interface (default: gr-1/2/0.3): Configuration: Style of tunnel: GRE tunnel Local Endpoint Address: 10.5.1.2 Remote Endpoint Address: 10.5.16.2 Numbered link: Link Prefix: 10.11.22.1/30 Local Interface: Tunnel interface: gr-1/2/0.3 Remote Interface: Tunnel interface: gr-1/2/0.3 Is this configuration accurate? (default: no) [yes/no]: yes [loading local configuration ...] [loading remote configuration ...] [finished] u...@cli Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CLI/OP Script Interaction
Got it. Thanks for taking the time to explain all that. On Fri, Oct 23, 2009 at 11:13 AM, Phil Shafer p...@juniper.net wrote: Judah Scott writes: What is a transient change? Here's some (long-ish) explanatory text: You can use commit scripts to generate transient changes, which are changes that are not saved in the candidate configuration but are propagated to the components of the system. Transient changes are made to the copy of the database that is exported to JUNOS components, but not to the candidate or committed configuration databases. This allows configuration changes to be transient, in the sense that they are not preserved by the system. You can use transient changes to eliminate the repetition of well-known policies, thus allowing these policies to be performed implicitly. For example, if MPLS must be enabled on every ISO-enabled interface, the change can be transient, so that the repetitive or redundant configuration data need not be carried and displayed to the user. The syntax for transient changes is nearly identical to that for permanent changes. To make transient changes to the configuration, include a transient-change element within the commit-script-output element. The transient-change element contains the desired change in the format required by a JUNOScript load-configuration RPC operation. For example: transient-change system host-namerdu-03-42/host-name /system /transient-change To enable transient changes, you must configure the allow-transients statement at the [system scripts commit] level of the configuration hierarchy. Without this statement, the UI will ignore transient changes. To view and test transient changes, use the show | display commit-scripts command. This command displays the post-commit scripts contents of the database without actually changing the database. It displays both transient and standard changes. [edit] cli# show | display commit-scripts Actually, I think emitting transient changes without allow-transients is now a commit error. Also do you mean an op script can trigger a commit-script to make transient changes? (It looks like the second op script was meant to say commit-script. I mean that you could have a script that asks the user some questions, builds some config from it in the form of an apply-macro, loads that config, and performs a commit-configuration operation. As part of that commit, any commit scripts (that are configured) will be run, and those scripts could generate transient changes from that apply-macro. So your op script can't make transient changes, but it can performs commits, which will trigger commit scripts that can generate transient changes. Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] CLI/OP Script Interaction
I am just starting to look into the scripting abilities of the JUNOS software and am wondering just in general how it interacts with the configuration performed through CLI. I have some general questions such as: When a configuration change happens simultaneously as an admin is building a candidate config to be commited... Do the scripting changes get incorporated into this candidate config or are they commited through another channel? Does the user editing the config see the changes being added to his config changes or are the scripting changes applied in the background to the running config? Does the 'config exclusive' mode block the script? Does config private/dynamic affect this behavior? Thanks in advance! -J Scott ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AS-path
I think the most important note on regexp in as-path is that the basic matching unit is the AS number and not individual characters. For AS-Path, the guide notes the ! as not operator and no mention of the [^] which is the negated character set, or except operator, as Paul mentioned. However, according to the guide the community strings are matched on a per-character basis and they do note the [] and use of [^] operators. The whole thing is a little confusing given the two regexp engines. Below are the links where I found this info. AS-Path: http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-policy/policy-configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html#id-10278439 Community Strings: http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-policy/policy-defining-bgp-communities-and-extended-communities-for-use-in-routing-policy-match-conditions.html#id-10247318 Thanks, J Scott On Thu, Aug 13, 2009 at 5:25 AM, Paul Goyette pgoye...@juniper.net wrote: IIRC, the standard RegExp except operator IS supported: set as-path 100not1000orig .* 100 .* (!1000)$ set as-path 100not1000orig .* 100 .* [^1000]$ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AS-path
Without testing It seems like: set as-path 100not1000orig .* 100 .* (!1000)$ should work. Thanks, J Scott On Wed, Aug 12, 2009 at 11:24 AM, Fahad Khan fahad.k...@gmail.com wrote: Dear Folks, what should be the As-path reg expression for getting the routes transiting AS 100 and not originating from AS 100 regards -- Muhammad Fahad Khan IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-321-2370510 +92-301-8247638 http://www.linkedin.com/in/muhammadfahadkhan http://fahad-internetworker.blogspot.com ___ 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
[j-nsp] IGMP Join Rate Limiting
When testing IGMP join rates I see an unusual rate of ~500pps. In an example I look at interface stats and see 1000 packets in, 539 input to local, 461 input to transit. Corresponding to this I see 539 IGMP groups setup. If I burst the same range again in the next second I don't learn any more. If I burst a new range of joins then these will go through. This leads me to believe that there is some filter or DOS protection for multicast packets because looking at the CPU I only see ~10% utilization. I only see the default arp l2-policer being applied on this interface. Does anyone have experience with DOS protection in JUNOS? Thanks, J Scott ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP Fast Reroute Node Protection
Thanks everyone for your help/examples. I tried this with an all-JUNOS
topology and node-link-protection worked. One important thing to note is
that a complete Route-Record on the primary lsp seems required for
node-protection. Also, 'set protocols rsvp [interface] link-protection' is
required only on the primary path interface as mentioned earlier by others.
Thanks,
J Scott
On Fri, Jul 31, 2009 at 8:58 AM, Harry Reynolds ha...@juniper.net wrote:
Well, not enough time for me to wade through your ted. ;) I was able to do
a quick sanity test and find both link and node bypass working.
Watch for wrap in the below ascii topo. If you expand enough it should take
the form of:
r2-r3
| \ -\ |
R0---r1-r4r5
Here, r1 is ingress with an lsp that is constrained through r2 and r3,
egressing at r4. R2 has link-protection enabled under only the fe-1/0/0
interface (along the primary lsp path). No other interfaces are enabled for
link protection.
test topo:
++ ++
|| ||
| vpn09 | fe-1/0/0 | vpn05 |
| R2|---| R3|
| P1| fe-1/1/2 | P2|
|| ||
++ ++
t3-0/1/2 | | so-1/2/2 ___| | fe-1/0/3
| | / t3-0/0/1 |
| | / |
| | / |
| |/_ |
| / | |
t3-0/3/1 | /so-1/2/2 | | fe-1/1/2
++ ++ /++
++
| vpn07 | | vpn03 |_/ t3-0/3/0 | vpn11 | |
vpn08 |
| R0| fe-1/1/3 | R1| | R4| fe-1/1/3 |
R5|
| CE1 |-| PE1 | so-0/1/0 | PE2 |-|
CE2 |
|| fe-1/1/1 ||---|| fe-1/0/3 |
|
|| || so-0/3/0 || |
|
++ ++ ++
++
R0 (vpn07)m10
lo0.0 10.255.14.177abcd::10:255:14:177
R0-R1: fe-1/1/3 1.1.1.1/30
R1 (vpn03)m20
lo0.0 10.255.71.24 abcd::10:255:71:24
R0-R1: fe-1/1/1
R1-GR: gr-3/0/0
R1-R2: t3-0/3/1 10.1.2.1/30
R1-R3: t3-0/3/0 10.1.3.1/30
R1-R4: so-0/1/0 10.1.4.1/30
R2 (vpn09)m10
lo0.0 10.255.14.179abcd::10:255:14:179
R1-R2: t3-0/1/2 10.1.2.2/30
R2-R3: fe-1/0/0 10.2.3.1/30
R2-R4: so-1/2/2 10.2.4.1/30
R3 (vpn05)m10
lo0.0 10.255.14.175abcd::10:255:14:175
R1-R3: t3-0/0/1 10.1.3.2/30
R2-R3: fe-1/1/2 10.2.3.2/30
R3-R4: fe-1/0/3 10.3.4.1/30
R4 (vpn11)m10
lo0.0 10.255.14.181abcd::10:255:14:181
R1-R4: so-0/3/0 10.1.4.2/30
R2-R4: so-1/2/2 10.2.4.2/30
R3-R4: fe-1/1/2 10.3.4.2/30
R4-GR: gr-1/3/0
R4-R5: fe-1/1/3
R5 (vpn08)m10
lo0.0 10.255.14.178abcd::10:255:14:178
R4-R5: fe-1/0/3 1.1.1.2/30
ingress set for link protection, transit node r2 has a link bypass:
[edit]
regr...@vpn09# run show rsvp session ingress bypass detail
Ingress RSVP: 1 sessions
10.255.14.175
From: 10.255.14.179, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass-10.2.3.2
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 301760
Resv style: 1 SE, Label in: -, Label out: 301760
Time left:-, Since: Fri Jul 31 08:47:46 2009
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 20116 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.2.4.2 (so-1/2/2.0) 4 pkts
RESV rcvfrom: 10.2.4.2 (so-1/2/2.0) 3 pkts
Explct route: 10.2.4.2 10.3.4.1
Record route: self 10.2.4.2 10.3.4.1
Total 1 displayed, Up 1, Down 0
set node-link:
{master}[edit]
regr...@vpn03# set protocols mpls label-switched-path r1_vpn03-to-r4_vpn11
node-link-protection
{master}[edit]
regr...@vpn03# commit
warning: graceful-switchover is enabled, commit
[j-nsp] RSVP Fast Reroute Node Protection
Anyone have a config example of Fast Reroute Node Protection? The mpls config guide is unclear which interface (the primary path interface or the bypass path interface) you must add link-protection and bypass blocks to. My bypass is not being used. I've tried but can only get a dynamic link-protection bypass even though upstream node is requesting node protection. Are dynamic node-protection bypasses supported in JUNOS 9.5? Thanks, J Scott ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP Fast Reroute Node Protection
Thanks all for your help, however still only link protection is being
created instead of the desired node protection. I am going to use a transit
lsp case for my example. The ted database shows links which if you take
time to map it out visually could/should be used to provide node protection
however only link protection bypass is created. I've included
(transitlsp.txt) much output and a map of what the links look like. It's
best viewed with a monospace font.
Maybe there is something else that is required which I am missing for node
protection to work.
Thanks,
J Scott
On Thu, Jul 30, 2009 at 3:52 PM, Harry Reynolds ha...@juniper.net wrote:
Thanks Kari, you appear correct. I was looking at a config that did not
match the topo in my head. Sorry for the mis-info.
Regards
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:
juniper-nsp-boun...@puck.nether.net] On Behalf Of Kari Asheim
Sent: Thursday, July 30, 2009 3:10 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] RSVP Fast Reroute Node Protection
On Thu, Jul 30, 2009 at 02:15:04PM -0700, Harry Reynolds wrote:
I think that you only need to configure the rsvp interface
interface-name link-protection statement on the lsp's protection
paths. That is to say, if the primary path exits a transit node on
fe-0/1/1, and you want that node to provide link or link-node
protection for that LSP, you would add the link-protection statement
to some other rsvp/mpls enabled interface that is not Fast
Ethernet-0/1/1. Adding the statement to the lsp's primary path
interfaces should have no ill effect, but obviously no gain as the
primary and link protection interfaces now share the same fate.
I think you need to configure rsvp interface link-protection on the
links of the primary path. A very simple example, link-protecting a one-hop
LSP:
k...@m320-1# run show mpls lsp ingress detail
Ingress LSP: 1 sessions
10.0.0.5
From: 10.0.0.4, State: Up, ActiveRoute: 0, LSPname: to-m320-2
ActivePath: (primary)
Link protection desired
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*PrimaryState: Up
Priorities: 7 0
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1)
10.0.1.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node
10=SoftPreempt):
10.0.1.2(Label=3)
Total 1 displayed, Up 1, Down 0
k...@m320-1# run show mpls lsp bypass ingress detail
Ingress LSP: 2 sessions
10.0.0.5
From: 10.0.0.4, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass-10.0.1.2
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 299872
Resv style: 1 SE, Label in: -, Label out: 299872
Time left:-, Since: Thu Jul 30 23:54:23 2009
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 22134 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.0.2.2 (ge-1/0/9.0) 18 pkts
RESV rcvfrom: 10.0.2.2 (ge-1/0/9.0) 18 pkts
Explct route: 10.0.2.2 10.0.3.1
Record route: self 10.0.2.2 10.0.3.1 Total 1 displayed, Up 1, Down 0
k...@m320-1# run show route 10.0.0.5
inet.0: 21 destinations, 21 routes (20 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.5/32*[OSPF/10] 00:07:39, metric 1
to 10.0.1.2 via ge-1/1/0.1 ...
k...@m320-1# show protocols rsvp
interface ge-1/1/0.1 {
link-protection;
}
interface ge-1/0/9.0;
Kari
___
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
(cspf) PRIMARY LSP: M320 - 1 - 2 - ...
(desired) NODE BYPASS: M320 - 3 - 4 - 2
(unwanted) LINK BYPASS: M320 - 3 - 1
1.1.1.1 100.0.0.1 100.0.1.1
-+ 10.0.1.1 +---+ 101.0.0.1 +---+
M320 || 1 || 2 |-
-+ 10.0.1.2 +---+ 101.0.0.2 +---+
| ||
| | 101.0.0.100| 101.0.1.100
| ||
| | 101.0.0.200| 101.0.1.200
| ||
| 10.0.2.1 +---+ 101.0.0.10 +---+
+---| 3 || 4 |-.
10.0.2.2 +---+ 101.0.0.20 +---+
102.0.0.1 102.0.0.1
ad...@re-0 show mpls lsp transit detail
Transit LSP: 2 sessions
100.0.5.1
From: 10.0.0.2, LSPstate: Up,
