Re: [j-nsp] High Memory Utilization on J2350

[Richmond, Jeff]

Quick way is to set mpls to packet-based which essentially makes the router 
packet-based as well (so you'll need to go back to standard firewall filters 
for router protection). I have about 60 or so RPM probes running on this J2350:

j...@rpm01.> show configuration security
forwarding-options {
family {
mpls {
mode packet-based;
}
}
}

j...@rpm01.> show chassis routing-engine
Routing Engine status:
Temperature 26 degrees C / 78 degrees F
CPU temperature 24 degrees C / 75 degrees F
Total memory  1024 MB Max   635 MB used ( 62 percent)
  Control plane memory 594 MB Max   321 MB used ( 54 percent)
  Data plane memory430 MB Max   310 MB used ( 72 percent)
CPU utilization:
  User  27 percent
  Real-time threads 14 percent
  Kernel15 percent
  Idle  44 percent
Model  RE-J2350-2500
Serial ID  
Start time 2010-04-22 17:56:59 PDT
Uptime 61 days, 20 hours, 45 minutes, 2 seconds
Last reboot reason 0x10:misc hardware reason
Load averages: 1 minute   5 minute  15 minute
   0.32   0.28   0.25

Hope this helps,
-Jeff


On Jun 23, 2010, at 6:11 AM, Tomas Lynch wrote:

> I'm doing some RPM tests using two J2350 [1], both are connected to an
> M10. Before any RPM configuration (or even any configuration or any
> packet forwarding) the memory utilization of the router was around 86%
> of 512 MB. I'm blaming this on the stateful firewall that is
> preconfigured but I cannot find any evidence/document/ etc. to support
> this. I have even deactivated the screen config and put all the
> interfaces on the trust zone but the memory utilization stays at the
> same level.
>
> Is there anything I can do to reduce the memory utilization? I really
> don't need the firewall feature.
>
> Any help will be useful. Thanks,
>
> Tomas L.
>
> [1] Before somebody recommends using another router, let me explain: I
> didn't choose that particular router; it was bought before I was hired
> but now is my problem ;)
> ___
> 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] Setting forwarding-class in firewall filter, non-match behaviour

[Richmond, Jeff]

I agree. One thing that we do fairly often is create a multifield classifier 
like this to just accept a couple of values to place into the appropriate 
forwarding-class, then for a default action reset to BE forwarding-class for 
all non-matching traffic. This works well in situations where you may not want 
to use a BA classifier as you don't trust the markings or you want them 
rewritten on egress.

Regards,
-Jeff

On Jun 20, 2010, at 6:47 AM, Addy Mathur wrote:

> I personally think Dale's firewall configuration is better.  The
> config allows for a packet to exit fw filter evaluation once a match
> condition is met, by being subjected to a single action.  Derick's FW
> filter forces a packet to traverse all terms regardless of a match,
> and is subjected to at least two actions via two different terms
> (fwd-class + next-term AND accept).  And there's no real need for the
> latter.
> 
> Regards,
> Addy.
> 
> 
> On 6/20/10, Derick Winkworth  wrote:
>> This is probably better:
>> 
>> term BEST-EFFORT
>> thenforwarding-class best-effort
>> next-term
>> term DSCP-EF
>> fromdscp ef
>> thenforwarding-class expedited-forwarding
>> next-term
>> term default-accept
>> thenaccept
>> 
>> 
>> You can insert additional terms later to modify loss-priority, sampling,
>> etc... after the classification portion of the filter but before the
>> default-accept.  I would use a rewrite rule to modify DSCP on egress, so
>> that its consistent across platforms.
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Dale Shaw 
>> To: juniper-nsp@puck.nether.net
>> Sent: Sun, June 20, 2010 3:59:12 AM
>> Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
>> behaviour
>> 
>> Hi all,
>> 
>> Re: setting the forwarding-class of a packet through a firewall filter.
>> 
>> Many (almost all) of the examples I've looked at do not include a
>> catch-all term to handle packets not matched by any explicitly-defined
>> terms. At the risk of exposing myself as a J-noob...
>> 
>> Is it safe to assume that, if the desired result is that packets NOT
>> matched by explicitly-defined terms are permitted, a catch-all term
>> must be configured with an 'accept' (or some other non-terminating)
>> action?
>> 
>> Using this input filter example:
>> (stolen from
>> http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
>> 
>> firewall {
>> filter filter1 {
>>  term 1 {
>>   from {
>>dscp 2;
>>   }
>>   then {
>>dscp 0;
>>forwarding-class best-effort;
>>   }
>>  }
>>  term 2 {
>>   from {
>>dscp 3;
>>   }
>>   then {
>>forwarding-class best-effort;
>>   }
>>  }
>> }
>> }
>> 
>> I read this as:
>> 
>> - if the packet is marked DSCP 2, set DSCP to 0 and place in
>> 'best-effort' forwarding class and accept the packet.
>> - if the packet is marked DSCP 3, place in 'best-effort' forwarding
>> class and accept the packet.
>> - discard all other packets
>> 
>> Am I missing something?
>> 
>> I think what I really want, to avoid dropping traffic, is something like:
>> 
>> firewall {
>> filter FILTER1 {
>>  term TERM1 {
>>   from {
>>dscp ef;
>>   }
>>   then forwarding-class expedited-forwarding;
>>  }
>>  term DEFAULT {
>>   then forwarding-class best-effort;
>>   accept;
>>  }
>> }
>> }
>> 
>> ...then rewrite DSCP bits on egress based on the forwarding-class, or
>> do it all within the firewall filter (depending on platform).
>> 
>> (I know I don't strictly need the 'accept;' command in the DEFAULT
>> term, but for the sake of clarity, I think it's a good option)
>> 
>> Cheers,
>> Dale
>> ___
>> 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
>> 
> 
> -- 
> Sent from my mobile device
> ___
> 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] What's the latest code you're running on a mx?

[Richmond, Jeff]

We have had pretty good luck so far with 9.5R4.3 on MX960s with DPCE-Rs.


On May 1, 2010, at 9:32 AM, Chuck Anderson wrote:

> On Sun, May 02, 2010 at 12:24:53AM +0800, Mark Tinka wrote:
>>> Until trio cards start getting deployed, there is pretty
>>> much no reason why any sensible network would be running
>>> 10.x on an MX today.
>> 
>> Or any platform, for that matter, I say.
> 
> Well, I've had pretty good luck with 10.x on EX4200.  I'm only 
> using Layer2 features though.
> ___
> 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] J2320 CoS and QoS

[Richmond, Jeff]

Nick, the correct terminology would be a Behavior Aggregate (which is what you 
are doing with the Classifier on the interface) or a MultiField Classifier 
(MFC), which is what you are proposing with a Src/Dst filter. These work just 
fine together, but just remember that an MFC is processed after the BA and 
therefore takes precedence over it if there is a conflicting value.

Regards,
-Jeff

On Apr 27, 2010, at 1:28 AM, Nick Ryce wrote:

> Hi Guys,
> 
> Is it possible to mix CoS and QoS per interface on a 2320 running 9.4?
> 
> Current CoS configured as follows:-
> 
> class-of-service {
>forwarding-classes {
>queue 0 best-effort;
>queue 1 expedited-forwarding;
>queue 2 assured-forwarding;
>queue 3 network-control;
>}
>interfaces {
>ge-* {
>scheduler-map cos-lumison;
>unit * {
>classifiers {
>dscp default;
>}
>}
>}
>}
>scheduler-maps {
>cos-lumison {
>forwarding-class network-control scheduler nc-scheduler;
>forwarding-class expedited-forwarding scheduler voice-scheduler;
>forwarding-class best-effort scheduler data-scheduler;
>forwarding-class assured-forwarding scheduler assured-scheduler;
>}
>}
>schedulers {
>voice-scheduler {
>transmit-rate percent 60;
>buffer-size percent 60;
>priority strict-high;
>}
>data-scheduler {
>transmit-rate percent 25;
>buffer-size percent 25;
>priority low;
>}
>nc-scheduler {
>transmit-rate percent 5;
>buffer-size percent 5;
>priority high;
>}
>assured-scheduler {
>transmit-rate percent 10;
>buffer-size percent 10;
>priority low;
>}
>}
> }
> 
> Customer would also like to use qos to prioritise backup traffic from a 
> source range to a destination range.  Is it possible to then use a filter to 
> prioritise the traffic from source to destination?
> 
> Many Thanks
> 
> Nick
> 
> --
> Nick Ryce
> Network Engineer
> Lumison
> 0845119
> 
> P.S. do you love Lumison?  Why not take a moment and vote for us?
> http://bit.ly/Vote_Lumison
> 
> 
> 
> --
> 
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender. Any
> offers or quotation of service are subject to formal specification.
> Errors and omissions excepted.  Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Lumison.
> Finally, the recipient should check this email and any attachments for the
> presence of viruses.  Lumison accept no liability for any
> damage caused by any virus transmitted by this email.
> 
> ___
> 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] /32 host routes on down interfaces

[Richmond, Jeff]

This has been there for a while, so if it was overlooked it has been ongoing. :)

We ran in to this when migrating from some M20s/M40e's to M320s. Had to 
remember to deactivate the interface on the old router as it was still showing 
the /32 side of the connected as active even when the fiber was pulled...

-Jeff

On Apr 22, 2010, at 12:09 PM, Paul Stewart wrote:

> Hey Richard...
> 
> That is an interesting find - my thought would have been the same.  Don't
> install the route OR the host route into the table unless it's active.
> 
> Why would you have a route entry exist to an interface that is down and
> could never pass traffic?  Just my thoughts...
> 
> Would be interesting to hear from JTAC if this was a design "feature" or an
> overlooked "oops"
> 
> Paul
> 
> 
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Richard A
> Steenbergen
> Sent: April-22-10 3:03 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] /32 host routes on down interfaces
> 
> So I just noticed an interesting behavior which I think is a bad thing, 
> but I want to see what other people think.
> 
> If you take an interface and put an IP route on it, like say:
> 
> interfaces {
>xe-0/0/0 {
>unit 0 {
>family inet {
>address 1.1.1.1/30;
>}
>}
>}
> }
> 
> And the above interface is DOWN, the 1.1.1.0/30 route is not installed 
> to the routing table like one would expect, but the 1.1.1.1/32 HOST 
> ROUTE is:
> 
> inet.0: 326321 destinations, 3502101 routes (319320 active, 11 holddown,
> 316892 hidden)
> Restart Complete
> + = Active Route, - = Last Active, * = Both
> 
> 1.1.1.1/32 *[Local/0] 00:00:05
>  Reject
> 
> And if you try to route traffic through the box for 1.1.1.1, it is
> rejected. The same is true even if you admin down the interface with
> "interface xe-0/0/0 disable", it always installs the /32 local route.
> 
> This seems like a bad thing to me. If the interface is down (either link
> or admin) I don't see why you'd need the local route installed in the
> routing table?
> 
> I'm assuming the reason nobody has complained before is it doesn't break
> that much stuff, since the only time most people talk to an interface
> host route is via the directly conected interface. The only reason I
> noticed it at all was we were doing router migrations and pre-staging
> the config on new router ports, so the IP existed on multiple routers 
> but only 1 link would be active at any given moment. And yes I know you 
> can always work around this by deactivating the interface so the IP 
> config doesn't go into the parser at all, I'm just wondering why it 
> would be designed this way in the first place. :)
> 
> -- 
> Richard A Steenbergenhttp://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


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] read-only config account, "rancid" user

[Richmond, Jeff]

Create your own class is probably the easiest since you have total control over 
what they can or can't do. You could do something simple like this:

   class RO-USERS {
permissions [ view view-configuration ];

Just depends on what you want to accomplish. You can then further lock it down 
so they can only view certain interface types, etc. with the deny and 
deny-configuration command options.

Good luck,
-Jeff


On Feb 4, 2010, at 9:14 AM, matthew zeier wrote:

> Not clear how to create a dumbed down read-only user who can just view the 
> config.  
> 
> In a Cisco world I'd use "privilege exec level" .  In JunOS, a read-only 
> class can't run "show configuration".
> 
> What's the nugget of info I'm missing?
> ___
> 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] JunOS Syslog / Excluding Messages

[Richmond, Jeff]

Michael, just for reference, I wanted to parse out RPM probe data out of 
messages and put into a separate file, and did it in a similar fashion. I did 
this a while back so I can't remember if I had to use a period in the regex or 
not, but depending on the message info, you certainly might need to.

file messages {
any any;
authorization info;
match "!(.*rmopd.*)";
}
file rpmtest.log {
any any;
match .*rmopd.*;
}  

 -Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of O'Connor, Michael [michael.ocon...@txstate.edu]
Sent: Tuesday, January 12, 2010 8:00 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] JunOS Syslog / Excluding Messages

Greetings,

The following notifications have/had for some time filled my syslog messages 
file, and according to JTAC (after several cases) are kernel messages that can 
be ignored and were fixed in JunOS 10.x:

Nov 13 03:00:14  VC_2_Bottom /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)
Nov 13 03:00:14  VC_2_Bottom fpc2 RT-HAL,rt_entry_add_msg_check,989: unknown 
vlan index 1
Nov 13 03:00:20  VC_2_Bottom fpc2 RT-HAL,rt_entry_add_msg_check,989: unknown 
vlan index 1
Nov 13 03:00:20  VC_2_Bottom /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)
Nov 13 03:00:20  VC_2_Bottom /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)
Nov 13 03:00:20  VC_2_Bottom fpc3 RT-HAL,rt_entry_add_msg_check,989: unknown 
vlan index 1
Nov 13 03:00:22  VC_2_Bottom fpc2 RT-HAL,rt_entry_add_msg_check,989: unknown 
vlan index 1

Without the luxury or want of a code upgrade (due to buggy virtual-chassis 
code) I'm left with trying to parse the unwanted messages. (We're running code 
that is unaffected by the recently released security bulletin)

The following config line was provided by JTAC to alleviate those particular 
messages to no avail:
#set system syslog file messages match 
<"!*RT-HAL,rt_msg_handler,403: route check failed* | *RT_PFE: RT msg* | 
*RT-HAL,rt_entry_add_msg_check*"

I've left the devices with the following configured, and thought I had resolved 
the problem until some planned maintenance that should have generated some log 
messages did not populate. Turns out this has killed any notifications to the 
file.

file messages {
any notice;
authorization info;
match "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] vulnerability fix not available for 8.5 ?

[Richmond, Jeff]

I agree. I broke protocol and opened a P1 case on this yesterday as I was 
irritated by the whole thing an I needed the SR software asap. Got a quick 
response, but still took them a couple of hours to get me the link. If you are 
going to list a specific SR release in the PSN, then include the link to 
download it or list it on the software download page. You need a uname/passwd 
to get it, so it isn't like someone is going to forward the PSN to their friend 
with no service contract and all of a sudden be able to download it. I made my 
feelings on this known to our account team as well as putting them in the 
ticket notes. Just stupid IMO.

-Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of Chuck Anderson [...@wpi.edu]
Sent: Thursday, January 07, 2010 12:29 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] vulnerability fix not available for 8.5 ?

On Thu, Jan 07, 2010 at 03:14:17PM -0500, Chuck Anderson wrote:
> On Thu, Jan 07, 2010 at 01:55:21PM -0600, Kevin Hunt wrote:
> > I just logged in and 8.5r4.2 seems to be the same build I have now, which is
> > prior to 01/2009.
> > Anyone gotten any word on a fix for it ?  We don't want to upgrade to 9
> > because of the possible removal of the GE-SX-B drivers and the non-support
> > of our older FPCs...
>
> Contact JTAC for the 8.5 service release.

I have to point out that JTAC isn't on the ball with this.  I called
to get the fixed release and the engineer didn't know the where to
find it and had to go ask someone else who "might not be around so it
may take a while for the answer"...  Given the high profile of these
security advisories, you would think JTAC would have been briefed in
advance to be able to immediately answer all the common questions like
"Where do I download the fix?".
___
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] KRT Queue issue (was: Re: bfd = busted failure detection :)

[Richmond, Jeff]

David, thank you, much appreciated. Our biggest issue was on recovery times 
when using LS's and GRES/NSR. We don't use LS's in production, but at the time 
I only had a single MX960 in the lab to start testing with (along with other 
routers: M320s, M40e's, etc.). So, I carved it up a bit into a few LSs and that 
is when we started seeing extremely long recovery times during link and RE 
failure testing. Turns out it isn't really supported when using LS's (at least 
not in 9.5), but since we don't use them in production I hadn't really 
researched it ahead of time like I normally would. The other major issue we 
have had with 9.5R3.7 is with FRR or node/link-protection. We ran into this 
with a POC lab setup back in November and currently ATAC has it now in their 
lab and can reproduce it, but haven't figured out why the problem is happening. 
Basically when a failure occurs, the forwarding entry for the prefixes on the 
LSP are withdrawn and never readvertised, so instant blackhole. I am hoping to 
have another update by the end of the week that has more specifics on what is 
triggering the issue and the exact behavior. There is still a lot of confusion 
surrounding it, but it is good that they can see it, I suppose.

Thanks,
-Jeff


From: David Ball [davidtb...@gmail.com]
Sent: Thursday, January 07, 2010 10:12 AM
To: Richmond, Jeff
Cc: Felix Schueren; juniper-nsp@puck.nether.net; Richard A Steenbergen
Subject: Re: [j-nsp] KRT Queue issue (was: Re: bfd = busted failure detection   
:)

  Hi Jeff.  They initially figured they had this solved a while ago,
and provided the PRs and fixes associated (PR291407, fixed in 9.3R3,
9.4R3, 9.5R2/3, 9.6R1).  As such, we too were in the process of
eval'ing 9.5R3, though we were just getting going with it this week in
the lab (on Ts and MXs).  I'm now waiting to hear back as to whether
we were hitting the same PR this time around (the trigger appeared to
be different) before finalizing on an upgrade path.  I'd be interested
to hear about your 9.5R3 testing and associated problems...we
don't currently use logical systems, but you never know.

David


2010/1/7 Richmond, Jeff :
> David, did ATAC give any indication if this was a widespread issue over all 
> releases of JUNOS, or are they thinking it is more localized to one more more 
> specific versions? I am still doing a 9.5R3.7 lab evaluation with GRES and 
> NSR on MX960s, and I know we have seen a couple of strange issues that looked 
> to have been related to Logical Systems in conjunction with GRES/NSR, but I 
> want to go back and take a closer look (seem Richard specifically mentioned 
> 9.5R3.7 in one of his earlier emails).
>
> Thanks,
> -Jeff
> 
> From: juniper-nsp-boun...@puck.nether.net 
> [juniper-nsp-boun...@puck.nether.net] On Behalf Of David Ball 
> [davidtb...@gmail.com]
> Sent: Thursday, January 07, 2010 9:31 AM
> To: Felix Schueren
> Cc: juniper-nsp@puck.nether.net; Richard A Steenbergen
> Subject: Re: [j-nsp] KRT Queue issue (was: Re: bfd = busted failure 
> detection :)
>
>  GRES with NSR, yes.  Apparently the stalling has to do with the
> master RE not receiving 'ok' from backup RE when it says it has an
> update.  It won't install the new route to the forwarding table until
> the 'ok' is received from the backup, or similar, based on ATAC's
> information.  At any rate, running core dumps went fine last night,
> but entire box reset (including SIBs) when GRES and NSR were
> deactivated (deactivating/reactivating was supposed to flush the
> queuethe outage was obviously not anticipated).
>
> David
>
>
> 2010/1/7 Felix Schueren :
>> David,
>>
>>>  I'm working with ATAC tonight to get them a running kernel core dump
>>> so they can look for root cause, but apparently disabling GRES,
>>> committing, re-enabling GRES, and committing again, somehow can
>>> temporarily resolve the issue (get the routes installed, I guess
>>> ?!?!).  Don't ask me how GRES has anything to do with it
>>>
>> is that GRES with or without NSR (nonstop-routing)? It it's with NSR, then I
>> could potentially see how this "stalling" might happen.
>>
>> Kind regards,
>>
>> Felix
>>
>> --
>> Felix Schüren
>> Head of Network
>>
>> ---
>> Host Europe GmbH - http://www.hosteurope.de
>> Welserstraße 14 - 51149 Köln - Germany
>> Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
>> HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
>> Geschäftsführer:
>> Uwe Braun - Alex Collins - Ma

Re: [j-nsp] KRT Queue issue (was: Re: bfd = busted failure detection :)

[Richmond, Jeff]

David, did ATAC give any indication if this was a widespread issue over all 
releases of JUNOS, or are they thinking it is more localized to one more more 
specific versions? I am still doing a 9.5R3.7 lab evaluation with GRES and NSR 
on MX960s, and I know we have seen a couple of strange issues that looked to 
have been related to Logical Systems in conjunction with GRES/NSR, but I want 
to go back and take a closer look (seem Richard specifically mentioned 9.5R3.7 
in one of his earlier emails).

Thanks,
-Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of David Ball [davidtb...@gmail.com]
Sent: Thursday, January 07, 2010 9:31 AM
To: Felix Schueren
Cc: juniper-nsp@puck.nether.net; Richard A Steenbergen
Subject: Re: [j-nsp] KRT Queue issue (was: Re: bfd = busted failure 
detection :)

  GRES with NSR, yes.  Apparently the stalling has to do with the
master RE not receiving 'ok' from backup RE when it says it has an
update.  It won't install the new route to the forwarding table until
the 'ok' is received from the backup, or similar, based on ATAC's
information.  At any rate, running core dumps went fine last night,
but entire box reset (including SIBs) when GRES and NSR were
deactivated (deactivating/reactivating was supposed to flush the
queuethe outage was obviously not anticipated).

David


2010/1/7 Felix Schueren :
> David,
>
>>  I'm working with ATAC tonight to get them a running kernel core dump
>> so they can look for root cause, but apparently disabling GRES,
>> committing, re-enabling GRES, and committing again, somehow can
>> temporarily resolve the issue (get the routes installed, I guess
>> ?!?!).  Don't ask me how GRES has anything to do with it
>>
> is that GRES with or without NSR (nonstop-routing)? It it's with NSR, then I
> could potentially see how this "stalling" might happen.
>
> Kind regards,
>
> Felix
>
> --
> Felix Schüren
> Head of Network
>
> ---
> Host Europe GmbH - http://www.hosteurope.de
> Welserstraße 14 - 51149 Köln - Germany
> Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
> HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
> Geschäftsführer:
> Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller
>
> (*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
>
>
> __ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 4749
> (20100106) __
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.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

Re: [j-nsp] J-series

[Richmond, Jeff]

Yes, they support it. I have several lab 2320s and 2350s with ls-0/0/0 mlppp 
interfaces.

-Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of Flavio Schappo [fscha...@gmail.com]
Sent: Wednesday, December 09, 2009 11:45 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] J-series

Hi,

Does anyone know if J2300 supports mlppp or other layered 2 services?
Documentation is not clear about each family (j63xx, 43xx, 23xx) and I can
not see ls-0/0/0 interface in the box.


Regards,

Flavio
___
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] rsvp using logical systems

[Richmond, Jeff]

There is nothing to it. We do it all the time for lab testing. Here is a config 
snippet from an MX960:

j...@cor01> show configuration protocols rsvp 
interface ge-0/0/0.0;
interface ge-0/0/6.0;
interface ge-0/1/6.0;
interface ge-1/0/0.0;
interface fxp0.0 {
disable;
}
interface xe-1/0/0.0;


j...@cor01> show configuration logical-systems COR02 protocols rsvp 
interface ge-0/0/1.0;
interface ge-0/1/5.0;
interface ge-0/0/5.0;
interface xe-1/1/0.0;
interface xe-4/2/0.0;


j...@cor01> show configuration logical-systems CBR01 protocols rsvp
interface ge-0/1/0.0;
interface ge-0/1/1.0;

Remember, if you are using the show rsvp session command you need to make sure 
you have your corresponding LSPs built as well before you see anything.

Regards,
-Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of chandrasekaran iyer [shekar1...@gmail.com]
Sent: Tuesday, December 08, 2009 10:29 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] rsvp using logical systems

Hi,
i am trying to establish RSVP session using logical systems.
My configs doesn't seem to work. Could anyone help me with working configs.

--
Thanks with regards

Shekar.B
--
___
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 Training Courses

[Richmond, Jeff]

I have done a number of the years and most of them are pretty good. I  
started teaching OJRE and AJRE a while ago as well and those are  
pretty good for someone new to JUNOS. Ping me offlist if you have any  
specific questions.

Sent from my iPhone

On Dec 2, 2009, at 5:53 PM, "Paul Stewart"  wrote:

> Hey folks..
>
>
>
> We're migrating towards a Juniper network beginning of next year -  
> we're
> Cisco folks today...
>
>
>
> As we scramble to learn JunOS and the M, ERX, J, SRX and other  
> series, the
> question of training has come up on a few occasions.  Has anyone on  
> this
> list done the 5 day Juniper courses (various courses) at many of the
> training locations offered?
>
>
>
> Just looking for feeback from folks that may have taken some of these
> courses and what their experiences were...
>
>
>
> Thanks ;)
>
>
>
> 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] Loop Interface between logical-systems

[Richmond, Jeff]

Definitely cool but be aware that there are limitations/issues with
some HA features when using logical systems at least on the MX
platform. I had to revert to a true JPOC lab to test as the logical
systems in my lab were killing my test results.

Sent from my iPhone

On Dec 2, 2009, at 3:40 PM, "Stefan Fouant"  wrote:

> Use logical-tunnels (lt-x/x/x) to connect logical systems.  The
> coolest thing is you can even specify the encapsulation, i.e.
> Ethernet, PPP, etc. to simulate different types of environments.   I
> used this almost exclusively for JNCIE preparation with just a
> single MX.
>
> Regards,
>
> Stefan Fouant
> www.shortestpathfirst.net
> --Original Message--
> From: Alfred Schweder
> Sender: juniper-nsp-boun...@puck.nether.net
> To: juniper-nsp@puck.nether.net
> Cc: Alfred Schweder
> Subject: [j-nsp] Loop Interface between logical-systems
> Sent: Dec 2, 2009 6:05 PM
>
> Hello
>
> I'm new in logical-systems, but it looks great.
>
> I like to collect some old routers (access and distribution layer) in
> one system, but I miss one point - Is there a way to configure a
> virtual interface to interconnect these logical systems internaly ?
>
> Or is a cable between two phy. interfaces the only way to do this ?
>
> Thanks and regards,
>
> --
> Alf
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> Sent from my Verizon Wireless BlackBerry
> ___
> 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] RPM for performance monitoring?

[Richmond, Jeff]

I am using these today, on both M-series and J-series and they work relatively 
well. There are some caveats when dealing with Jitter, however, so I would 
suggest that you do test in your own lab to see if it will provide an 
acceptable solution. I had a very good JTAC engineer work with me to work 
through some of those issues and I think it ended up being a learning 
experience for both of us, but at the end of the day we finally ended up with a 
good workable Jitter solution.

Thanks,
-Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of Nalkhande Tarique Abbas [ntari...@juniper.net]
Sent: Monday, September 14, 2009 9:09 AM
To: Stefan Fouant; Juniper List
Subject: Re: [j-nsp] RPM for performance monitoring?

I think the key differentiator here would be the RPM timestamps for
which you have two versions viz RE based timestamps or Hardware
timestamps.

The RE based version keeps timestamps in memory when packets are sent
and received.  This is not very accurate due to the delay added by PFE
to RE transit and waiting for CPU time. The desired accuracy for ICMP
Echo probes is on the order of that seen via the CLI 'ping' command

On the other side MS-PIC based time stamps provide the best performance
and accuracy since we have dedicated resources for time stamping.



Thanks & Regards,
Tarique A. Nalkhande

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stefan Fouant
Sent: Monday, September 14, 2009 9:18 PM
To: Juniper List
Subject: [j-nsp] RPM for performance monitoring?

Folks,

I'm interested in gauging performance metrics between nodes (basically
looking for minimum, maximum, and average latency) and was wondering if
RPM
might be a suitable utility for measuring such performance.  Before I
take
an exhaustive look at this in the lab, I'd like to hear your
experiences.
Ideally, I'd like to push out an SNMP trap in the event the latency
exceeds
a certain threshold, but at a bare minimum I'll need to be able to look
at
this data in a historical context.

Any thoughts?

--
Stefan Fouant
___
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] MPLS for management VPN question

[Richmond, Jeff]

Jeff,

This isn't typically something that can be described in just a few short 
emails, as there are so many ways to do things. However, that said, here is a 
short sample config for an L3VPN VRF:

j...@br01.> show configuration routing-instances
VPN.TEST {
instance-type vrf;
interface lo0.125;
route-distinguisher 1.1.1.1:125;
vrf-target target::125;
}

In this case I have no physical interfaces in the VRF, just a loopback address 
on lo0.125. For this VPN I am just doing a simple vrf-target statement which 
uses the configured value as an import and export value for the VRF. So lo0.125 
will be tagged with the community :125, and any routes learned that also 
have that matching community will also get automatically imported in to the 
VRF. You can get much more granular, however, using explicit import and export 
filters.

Hope this helps.
-Jeff


From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of Jeff Meyers [jeff.mey...@gmx.net]
Sent: Thursday, June 04, 2009 4:13 AM
To: Truman Boyes
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MPLS for management VPN question

Truman Boyes schrieb:

Hi,

thanks for your answer so far.

> You then need to define a route-distinguisher, and route targets (or
> simply vrf-target under the VRF) to import/export the routes for this
> VPN from other PEs.

Can you provide an example for that? That would be a L3VPN, right? Why
would I need any routes to be known on the router? Basically I only need
192.168.0.0/16 to be the management subnet globally without any default
gateways.

> Later on you might want to connect some of your NMS/OSS systems into the
> VRF so they can reach the the devices on the management VPN.

So I simply add the devices to the vlan 100 on the existing ae Link with
.1q tagged vlans? No special encapsulation needed on juniper side?


Thanks,
Jeff

___
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] J4350 Performance

[Richmond, Jeff]

Kevin, I am not using them in production but I have a personal lab of 3 J4350s 
that I am pretty much doing anything and everything on. Right now I am not 
currently listening to full routes, but if you don't get any decent answers 
before Monday, I'll throw a couple full tables on them and give you a summary 
of CPU and Memory utilizations if you are interested. I don't have my Ixia and 
Smartbits here in my home lab, so unfortunately I can't tell you what the 
tipover numbers are for throughout (and I don't have any 4350s in our main lab, 
unfortunately).

Regards,
-Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of Kevin Wormington [kw...@sofnet.com]
Sent: Friday, May 29, 2009 9:24 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] J4350 Performance

I was wondering what kind of real world performance list members have
seen out of the J4350 in regards to Mbps throughput and BGP with a
couple of full tables?

Kevin

___
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's policy on auto-escalation for JNCIP/JNCIE holders

[Richmond, Jeff]

Not sure. I know that none of my cases have ever been auto-escalated either. I 
haven't had any problems manually escalating, but I agree, that is BS.

-Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of Richard A Steenbergen [...@e-gerbil.net]
Sent: Tuesday, April 07, 2009 12:22 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Juniper's policy on auto-escalation for JNCIP/JNCIE holders

Can anyone from Juniper clarify the policy which is published here:

http://www.juniper.net/us/en/training/certification/300060.pdf

Which clearly states that JNCIP or JNCIE holders opening P1 or P2 cases
will get auto-escalation to Advanced JTAC. JTAC is outright refusing to
honor this, claiming that it isn't their policy and that anything which
says otherwise is "incorrect". Not even my account manager seems to have
any luck getting this handled as described. Is there some reason why
Juniper does not want to honor its published policies here? This
document seems pretty explicit and current.

--
Richard A Steenbergenhttp://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] M10i - %KERN-1-RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 6 (No Memory) / RT msg op 3 (PREFIX CHANGE) failed, err 6 (No Memory)

[Richmond, Jeff]

Agreed, we had this happen on older M20s as well. Depending on your routing 
table, a quick bandaid fix might be to just clean up more specific prefixes if 
you can so that your forwarding table doesn't have as many entries. For 
example, I have had cases where we have a bunch of smaller internal routes in 
RR clients that really didn't need to be there as long as the RR server routers 
had the more specifics. More memory is certainly the long term solution though.

Regards,
-Jeff

From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of sth...@nethelp.no [sth...@nethelp.no]
Sent: Monday, January 19, 2009 10:35 AM
To: listensamm...@gmx.de
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] M10i - %KERN-1-RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 6 (No Memory) / RT msg op 3 (PREFIX CHANGE) failed, err 6 (No Memory)

> i have a problem on one of our M10i.
> System log continously shows following errors:
>
> Jan 19 15:59:03 MYROUTER /kernel: %KERN-1-RT_PFE: RT msg op 3 (PREFIX
> CHANGE) failed, err 5 (Invalid)
> Jan 19 15:59:03 MYROUTER /kernel: %KERN-1-RT_PFE: RT msg op 1 (PREFIX
> ADD) failed, err 6 (No Memory)
> Jan 19 15:59:07 MYROUTER /kernel: %KERN-1-RT_PFE: RT msg op 3 (PREFIX
> CHANGE) failed, err 6 (No Memory)
> Jan 19 15:59:15 MYROUTER /kernel: %KERN-1-RT_PFE: RT msg op 1 (PREFIX
> ADD) failed, err 6 (No Memory)
> Jan 19 15:59:23 MYROUTER /kernel: %KERN-1-RT_PFE: RT msg op 3 (PREFIX
> CHANGE) failed, err 5 (Invalid)
> Jan 19 15:59:27 MYROUTER /kernel: %KERN-1-RT_PFE: RT msg op 1 (PREFIX
> ADD) failed, err 6 (No Memory)
> Jan 19 15:59:27 MYROUTER /kernel: %KERN-1-RT_PFE: RT msg op 3 (PREFIX
> CHANGE) failed, err 5 (Invalid)
> Jan 19 15:59:30 MYROUTER /kernel: %KERN-1-RT_PFE: RT msg op 1 (PREFIX
> ADD) failed, err 6 (No Memory)
>
> But there is no traffic impact
> I tried further investigation with some commands i found in older mailings.
> But without success...
>
> u...@myrouter> start shell pfe network cfeb0
> vty: connect: Connection refused

This probably doesn't work precisely because there is insufficient CFEB
memory. We have seen exactly this happen. Sooner or later it probably
*will* impact traffic.

> I could imagine that a reload will clear the problem, but i would like
> to avoid it...

A reload is probably the only fix. And you *really* want to monitor your
CFEB memory utilization (show chassis cfeb).

We are in the process of upgrading all our M7i/M10i CFEBs to 256 MB.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
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] multiple lsp between 2 router

[Richmond, Jeff]

I haven't done that, but you should be able to do something with a policy to 
accomplish this. For example, I have a very simple policy I use in conjunction 
with my LB forwarding policy. Looks kind of like this:

j...@r5> show configuration policy-options policy-statement LSP-SELECTION
term SEQ-100 {
from community TEST-VPN;
then {
install-nexthop lsp R5-R3-TEST;
accept;
}
}
term SEQ-200 {
from protocol bgp;
then {
install-nexthop lsp R5-R3;
accept;
}
}

j...@r5> show configuration routing-options forwarding-table
export [ LOAD-BAL-PER-PACKET LSP-SELECTION ];

I would think that maybe if you did a from term looking for a DSCP/EXP marking, 
you could steer traffic into a particular LSP that way. Again, I haven't done 
this, so I can't say for sure, but that is where I would start.

Hope this helps,
-Jeff

From: The Drifter [prophecy...@hotmail.com]
Sent: Wednesday, January 07, 2009 9:26 PM
To: Richmond, Jeff; s...@clarke-3.demon.nl; faizal...@gmail.com
Cc: juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] multiple lsp between 2 router

On top of this is it possible to assign b/w onto each LSP? For example on a 
100mbps link

1. 20mbps on LSP1 mapped to COS Gold
2. 30mbps on LSP2 mapped to COS Silver
3. 50mbps on LSP3 mapped to COS bronze

Thanks,
Jimmy

> From: jeff.richm...@frontiercorp.com
> To: s...@clarke-3.demon.nl; faizal...@gmail.com
> Date: Wed, 7 Jan 2009 09:01:57 -0500
> CC: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] multiple lsp between 2 router
>
> To confirm what Sean says, it does work just like this. I have a number of 
> places that have multiple LSPs that load balance, and I have others that have 
> multiple LSPs that I bypass load balancing with policies for various reasons 
> (for example, to test different path latencies, etc.).
>
> -Jeff
>
>
> 
> From: juniper-nsp-boun...@puck.nether.net 
> [juniper-nsp-boun...@puck.nether.net] On Behalf Of Sean Clarke 
> [s...@clarke-3.demon.nl]
> Sent: Tuesday, January 06, 2009 9:14 PM
> To: Faizal Rachman
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] multiple lsp between 2 router
>
> Faizal Rachman wrote:
> > Hi All,
> > Did anywone know how to config 2 lsp in 2 back-to-back routers while
> > implementing mpls loadbalancing?
> > Thank you.
> >
> > Faizal R
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> >
> You can configure as many RSVP signalled LSP's as you like.
>
> Configure per-packet load balancing, and it should just work.
>
> # show routing-options forwarding-table
> export lbpp;
>
> # show policy-options policy-statement lbpp
> then {
> load-balance per-packet;
> }
>
>
> # show protocols mpls
> label-switched-path LSP-1 {
> to 2.2.2.2;
> }
> label-switched-path LSP-2 {
> to 2.2.2.2;
> }
>
>
>
>
> cheers
> Sean
>
> ___
> 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



check out the rest of the Windows Live™. More than mail–Windows Live™ goes way 
beyond your inbox. More than 
messages<http://www.microsoft.com/windows/windowslive/>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] multiple lsp between 2 router

[Richmond, Jeff]

To confirm what Sean says, it does work just like this. I have a number of 
places that have multiple LSPs that load balance, and I have others that have 
multiple LSPs that I bypass load balancing with policies for various reasons 
(for example, to test different path latencies, etc.).

-Jeff



From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of Sean Clarke [s...@clarke-3.demon.nl]
Sent: Tuesday, January 06, 2009 9:14 PM
To: Faizal Rachman
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] multiple lsp between 2 router

Faizal Rachman wrote:
> Hi All,
> Did anywone know how to config 2 lsp in 2 back-to-back routers while
> implementing mpls loadbalancing?
> Thank you.
>
> Faizal R
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
You can configure as many RSVP signalled LSP's as you like.

Configure per-packet load balancing, and it should just work.

# show routing-options forwarding-table
export lbpp;

# show policy-options policy-statement lbpp
then {
load-balance per-packet;
}


# show protocols mpls
label-switched-path LSP-1 {
to 2.2.2.2;
}
label-switched-path LSP-2 {
to 2.2.2.2;
}




cheers
Sean

___
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] copy vpn routes to inet.0

[Richmond, Jeff]

Ok, I'll try to answer all your questions, but am in a rush, so if I miss 
something, just let me know.

1. The default route is for jumping out of the VPN to inet.0. You don't need 
this if you don't want to leave the VPN. In other words you can still advertise 
your VPN routes to inet.0 just using auto-export and rib groups.

2. Yes, as I showed in the example, I am publishing the VRF-specific loopback 
to inet.0 using auto-export. Same exact formula for physical interfaces as well.

3. As for the remote routes, it will not work. Basically, if the local PE 
learns routes from other PEs, it will not readvertise them to inet.0 like it 
will with the local PE routes. This really stinks for me as I can't use a 
single PE as a gateway into the VRF (well, not easily anyway).

4. As for an explanation of auto-export, I am probably not the best person to 
explain all of its details or differences with other junos knobs. I would 
suggest getting with your SE and having them dig up the detailed info for you.

Take care,
-Jeff

From: snort bsd [snort...@yahoo.com.au]
Sent: Wednesday, December 24, 2008 10:12 PM
To: juniper-nsp; Richmond, Jeff
Subject: RE: [j-nsp] copy vpn routes to inet.0

thanks, jeff

but your primary table is inet.0 but the default route 0/0 point to next table 
of inet.0. how does that work?

actually i am very interested in your old post:

"Just be aware that you can only do this with local routes in the VRF, not
remotely learned routes from other PEs. At one point I was wanting to make a
"gateway" PE using auto-export and RIB groups to enter/exit the VRF on a single
PE, which works great with local routes (interface, static, etc.), but will not
work with remotely learned VRF routes (via MBGP). I asked Juniper about this,
and was basically told it just won't work. So, I ended up having each PE do
auto-export... "

indeed i am trying to copy vpn routes learned from other PE routers into inet.0 
and as you had pointed before, it would not work. now i am dying to know why 
not...:)

also how could you get that vpn specific loopback into inet.0? via 
"auto-export" statement?

what does that "auto-export" statement mean? automatically export all of routes 
under that VRF to route tables of inet.0 and 300.inet.0? honestly i still can't 
get clear meaning of this "auto-export" statement.

in fact, if that just for the lo0.300, i could just use "interface-routes" 
statement under that vpn instance to achieve the same result.



--- On Wed, 24/12/08, Richmond, Jeff  wrote:

From: Richmond, Jeff 
Subject: RE: [j-nsp] copy vpn routes to inet.0
To: "snort bsd" , "juniper-nsp" 

Received: Wednesday, 24 December, 2008, 6:20 PM

Here is a sample from one of my lab routers. I am just using a loopback IP 
inside VRF 300, but as you can see, it is now seen in inet.0.

j...@r2> show configuration routing-instances 300
description "Customer 2 VRF";
instance-type vrf;
interface lo0.300;
vrf-target target:65100:300;
vrf-table-label;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
auto-export {
family inet {
unicast {
rib-group CUST300-RIB;
}
}
}
}


j...@r2> show configuration routing-options rib-groups
CUST300-RIB {
import-rib [ inet.0 300.inet.0 ];
import-policy RESTRICT-VRF300;
}


j...@r2> show configuration interfaces lo0 unit 300
family inet {
address 10.99.99.1/32;
}

j...@r2> show route 10.99.99.1
inet.0: 152 destinations, 167 routes (104 active, 0 holddown, 48 hidden)
+ = Active Route, - = Last Active, * = Both

10.99.99.1/32  *[Direct/0] 14:18:57
> via lo0.300

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

10.99.99.1/32  *[Direct/0] 14:18:57
> via lo0.300



From: 
juniper-nsp-boun...@puck.nether.net
 
[juniper-nsp-boun...@puck.nether.net]
 On Behalf Of snort bsd 
[snort...@yahoo.com.au]
Sent: Tuesday, December 23, 2008 3:27 PM
To: juniper-nsp
Subject: [j-nsp] copy vpn routes to inet.0

Hi all:

Could those routes in the L3VPN table be copied to inet.0? I tried to use 
policy and it doesn't seem to be working:

term l3vpn->inet.0 {
from {
rib l3vpn.inet.0;
route-filter 100.100.0.0/16 orlonger;
}
to rib inet.0;
then {
accept;
}
}

_dave


  Stay connected to the people that matter most with a smarter inbox. Take 
a look http://au.docs.yahoo.com/mail/smarterinbox
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



Stay connected to the 

Re: [j-nsp] copy vpn routes to inet.0

[Richmond, Jeff]

Here is a sample from one of my lab routers. I am just using a loopback IP 
inside VRF 300, but as you can see, it is now seen in inet.0.

j...@r2> show configuration routing-instances 300
description "Customer 2 VRF";
instance-type vrf;
interface lo0.300;
vrf-target target:65100:300;
vrf-table-label;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
auto-export {
family inet {
unicast {
rib-group CUST300-RIB;
}
}
}
}


j...@r2> show configuration routing-options rib-groups
CUST300-RIB {
import-rib [ inet.0 300.inet.0 ];
import-policy RESTRICT-VRF300;
}


j...@r2> show configuration interfaces lo0 unit 300
family inet {
address 10.99.99.1/32;
}

j...@r2> show route 10.99.99.1
inet.0: 152 destinations, 167 routes (104 active, 0 holddown, 48 hidden)
+ = Active Route, - = Last Active, * = Both

10.99.99.1/32  *[Direct/0] 14:18:57
> via lo0.300

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

10.99.99.1/32  *[Direct/0] 14:18:57
> via lo0.300



From: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] 
On Behalf Of snort bsd [snort...@yahoo.com.au]
Sent: Tuesday, December 23, 2008 3:27 PM
To: juniper-nsp
Subject: [j-nsp] copy vpn routes to inet.0

Hi all:

Could those routes in the L3VPN table be copied to inet.0? I tried to use 
policy and it doesn't seem to be working:

term l3vpn->inet.0 {
from {
rib l3vpn.inet.0;
route-filter 100.100.0.0/16 orlonger;
}
to rib inet.0;
then {
accept;
}
}

_dave


  Stay connected to the people that matter most with a smarter inbox. Take 
a look http://au.docs.yahoo.com/mail/smarterinbox
___
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] Junos sticker

[Richmond, Jeff]

I have one sitting here on my desk. Actually it is sitting right next to my 
mini Cisco license plate with the "IP loves ATM" phrase. heh.

-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Junos Juniper [EMAIL 
PROTECTED]
Sent: Wednesday, December 10, 2008 3:51 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Junos sticker

Has anybody seen these?
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=180313229707
or
http://tinyurl.com/5wemy5

I guess there is a video on youtube of they guy who created it, just
sure if that's a spoof or not.
___
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] Meaning of "except" in firewall filters

[Richmond, Jeff]

Try adding a source-address of 0/0 in conjunction with the prefix-list match 
condition. Here is a portion of my filter which works great:

term SEQ-100 {
from {
source-address {
0.0.0.0/0;
}
source-prefix-list {
NMS-NETWORKS except;
}
destination-port [ telnet ssh ftp ftp-data snmp ntp ];
}
then {
syslog;
discard;
}
}

HTH,
-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Kevin Oberman [EMAIL 
PROTECTED]
Sent: Thursday, October 30, 2008 8:43 AM
To: Tore Anderson
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Meaning of "except" in firewall filters

> From: Tore Anderson <[EMAIL PROTECTED]>
> Date: Wed, 29 Oct 2008 23:24:36 +0100
> Sender: [EMAIL PROTECTED]
>
> Hi,
>
> I'm trying to restrict SSH access on some of my routers to allow
> connections from just a few known source networks (defined in a prefix
> list called "ssh-allowed").  I then came up with the following, and
> applied it as an input filter on lo0.0:
>
> [edit firewall filter lo0-input]
> term restrict-ssh {
> from {
> source-prefix-list {
> ssh-allowed except;
> }
> protocol tcp;
> destination-port ssh;
> }
> then {
> syslog;
> reject;
> }
> }
> term fallthrough {
> then accept;
> }
>
> This didn't work as expected, SSH connections was still allowed from any
> host (both from inside networks found inside ssh-allowed as well as from
> outside).  It seems like the restrict-ssh term never matched.
>
> If I removed the "except", it worked as I would have thought -
> connections from hosts inside prefixes found in the ssh-allowed prefix
> list was denied, while connections from the rest of the internet was
> allowed.  Of course, this is the opposite behaviour of what I want.
>
> I can work around it by making first a term that accepts SSH from the
> known prefixes, then another term that rejects all other SSH
> connections, and finally the fallthrough that accepts the rest.  However
> this behaviour made me really curious...  Isn't "except" supposed to
> invert the logic of the match?  That's how I understand the help text,
> at least:
>
> except   Match addresses not in this prefix list
>
> It doesn't seem to work that way, though.  Does anyone know how it's
> supposed to be used?

I don't normally see 'except' used quite like this.

Why not just do the boolean inverse:

filter router-inet.0-access {
term ssh-accept {
from {
source-prefix-list {
management-access;
other-access;
vendor-debug-access;
}
destination-port ssh;
}
then accept;
}
term ssh-reject {
from {
destination-port ssh;
}
then {
log;
reject tcp-reset;
}
}
[...]

This is just the ssh snippet from the much longer filter we put on lo0,
but I don't see a reason not to do it this way.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JNCIP-M Preparation

[Richmond, Jeff]

Yep. I took and passed the JNCIP-M using that book exclusively. Obviously there 
is no replacement for hands-on experience, but the book is a great guide.

Regards,
-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Jens Hoffmann [EMAIL 
PROTECTED]
Sent: Tuesday, September 23, 2008 5:46 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] JNCIP-M Preparation

Hi,



in preparation fort he JNCIP-M certification I'm using the  "JNCIP Study
Guide" (Harry Reynolds).



But this book is about 5 years old.



Is this book nevertheless useful considering the content of the current
JNCIP certification ?



Regards,

Jens







___
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] Router Reflector and L3 VPN support on same router

[Richmond, Jeff]

How did it fail? I do this without issue. You might want to check your IBGP 
next-hop policy though if your problem is just missing routes. Also, if you 
have an RR client, make sure you add a static discard route in inet.3 or a 
1-way LSP from the RR server to the client.

Regards,
-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Abhi [EMAIL PROTECTED]
Sent: Friday, September 19, 2008 6:08 AM
To: Juniper Puck
Subject: [j-nsp] Router Reflector and L3 VPN support on same router

Hi Every Body

I am configuring Juniper router in a Lab Setup i am able to establish full mesh 
connectivity will configuring router to support L3 VPN functionality with other 
3 router by explicitly configuring them. i tried configuring one of the Router 
to be RR and simultaneously be a peer for L3 VPN peer.

It failed to work in this manner.

1) Can we do this if yes how. I know this would not have a practical 
application but we need to test the same.

 regards
abhijeet.c
___
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] Difference Between E Series and Rest of the Router Family

[Richmond, Jeff]

One HUGE difference that should be pointed out in all fairness is that while 
the M/T/J routers run JUNOS and were developed in-house, the E-series was 
acquired from Unisphere and as such are nothing at all like the other routers 
in terms of OS (JUNOSe is nothing like JUNOS) or hardware (even the E320, while 
being much different than the rest of the E-series is nothing like the M/T 
series).

Do not expect even the slightest bit of config portability between them, nor 
should you expect training portability either (though in fairness if you are 
vendor-C trained, JUNOSe is a fairly quick jump).

While the E-Series certainly has a lot of features that it supports, like 
anything else, I would highly recommend you decide what features you need and 
then test them out all running together to make sure it behaves as you would 
expect.

Regards,
-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Truman Boyes [EMAIL 
PROTECTED]
Sent: Friday, August 01, 2008 1:21 PM
To: Abhi
Cc: Juniper Puck
Subject: Re: [j-nsp] Difference Between E Series and Rest of the Router Family

Hi Abhi,

The E-series run JUNOSe which is Juniper's mature broadband edge
software. Some of the broadband friendly features include the L2TP
functionality (LAC/LNS/Tunnel Switching), some of the DHCP
functionality, subscriber management functionality(some with the SRC),
and the number of queues / CoS behaviour on the number of interfaces
that the E-series support.

One feature that does not have parity between platforms at this time
is PPP termination capabilities. Today many service providers are
PPPoE or PPPoA and the E-series is designed to scale in this regard.

The subscriber management functionality and the QoS features are very
specific to broadband/customer termination applications. For example,
the shared shaping functionality, and parameter usage in QoS profiles
is also very broadband centric.

Another thing is ATCP capabilities that allow QoS mechanisms to take
into account the actual line speed of a DSL customer in order to
provide the appropriate congestion avoidance mechanisms.

Regards,
Truman


On 1/08/2008, at 3:53 AM, Abhi wrote:

> Hi All
>
> I have a doubt what is difference from technical perspective between
> the E Series router family and rest of the routers. What are those
> unique feature that make them broadband friendly those are missing
> on the Junos family of devices.
>
> regards
> abhijeet.c
> ___
> 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] Bulk config migration between interfaces?

[Richmond, Jeff]

Maybe I am not understanding what you are asking, but this is exactly what the 
copy command is for:

For example:
[EMAIL PROTECTED] copy interfaces ge-0/0/0 to ge-1/0/0

That will move over the interface and all logical units associated to it.

Or, if you are doing it from router to router, just copy the interface command 
from the source router/interface, put it in to a text editor and change the 
pertinent FPC/PIC/SLOT info and paste in to new router...

Hope this helps,
-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Jonathan Brashear [EMAIL 
PROTECTED]
Sent: Tuesday, February 19, 2008 2:14 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Bulk config migration between interfaces?

I have a facility(3, actually) I'm upgrading and part of this upgrade
involves moving a circuit from one PIC on a M20 FPC to a new PIC on the
same FPC.  I have a few dozen VLANs that will be migrated as well.
Obviously I could do this one by one, but I was curious if anyone knew a
way within JunOS that I could move all the logical configuration from
one physical interface to another.  It would save me a significant
amount of time.

Network Engineer
> 214-981-1954 (office)
> 214-642-4075 (cell)
> [EMAIL PROTECTED]
http://www.speakeasy.net
___
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 M40e and ALU 7450 InterOp

[Richmond, Jeff]

It has been almost 2 years (if memory serves), but I did have this configured 
in our lab between a couple of M10i/M7i's and a 7750. It took a bit to actually 
get it to work from what I remember, but if you'd like I can dig up my old 
notes and see if I have the 7750 config archived (this would have been with the 
beta 3.x release, for what its worth).

Regards,
-Jeff


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Atul Kant [EMAIL 
PROTECTED]
Sent: Tuesday, February 05, 2008 7:05 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Juniper M40e and ALU 7450 InterOp

Hi,



Does anyone tried or know if MPLS tunnel can be established between Juniper 
M40e and ALU 7450.



ALU 7x50 defines SDP for inter-node service tunnel. I am wondering if it is 
possible when defining the SDP to give the far-end address that is actually a 
Juniper M40e loopback

address and do a similar Juniper specific Config on the M40e.



Will this work ? I am planning to test this once I get the lab organized, 
meanwhile just trying to find out if anyone else has done it or has similar 
requirements.



Thanks,



Atul Kant

Data Solutions Specialist

IP Services

Alcatel-Lucent Australia

Phone ~ +617 3367 4149

Mobile ~ +614 4841 0812
___
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] Telnet e320

[Richmond, Jeff]

Interesting, has that always been there? Funny, nobody at Juniper seemed to 
know about it when I asked. I did just confirm it was there though, but any 
idea if there is a corresponding SSH command of some sorts?

Thanks,
-Jeff

From: Nitin Vig [EMAIL PROTECTED]
Sent: Monday, January 28, 2008 7:12 AM
To: Richmond, Jeff; sunnyday; Juniper-Nsp
Subject: RE: [j-nsp] Telnet e320

Not true.You can use 'telnet listen' command in the VR.

1440-2:t1#sh ip int br
 Interface   IP-AddressStatusProtocol
Description
 --- -- ---
---
null0255.255.255.255/32  up up

FastEthernet0/0.20   10.10.10.1/24   up up

1440-2:t1#
1440-2:t1#ping 10.10.10.2
Sending 5 ICMP echoes to 10.10.10.2, timeout = 2 sec.
!
Success rate = 100% (5/5), round-trip min/avg/max = 1/3/12 ms
1440-2:t1#telnet 10.10.10.2
1440-2:t1#
1440-2:t1#conf t
Enter configuration commands, one per line.  End with ^Z.
1440-2:t1(config)#vir t2
1440-2:t2(config)#telnet listen
1440-2:t2(config)#^Z
1440-2:t2#vir t1
1440-2:t1#telnet 10.10.10.2

Logged in on vty 1 via telnet.
Copyright (c) 1999-2007 Juniper Networks, Inc.  All rights reserved.

1440-2:t2>
1440-2:t2>
1440-2:t2>exit
Logging out.


1440-2:t1#

Regards,
Nitin

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richmond, Jeff
Sent: Monday, January 28, 2008 7:38 PM
To: sunnyday; Juniper-Nsp
Subject: Re: [j-nsp] Telnet e320

Unless something has changed in recent code versions, you cannot
Telnet/SSH in to a VR other than Default. This is very annoying to say
the least...

-Jeff

From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of sunnyday
[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 1:28 AM
To: Juniper-Nsp
Subject: [j-nsp] Telnet e320

hello
i want to know if i can telnet to a virtual router configured on the box
since the only way i do it now is through the default virtual router, is
this possible?
thanks in advance
___
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] Telnet e320

[Richmond, Jeff]

Unless something has changed in recent code versions, you cannot Telnet/SSH in 
to a VR other than Default. This is very annoying to say the least...

-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of sunnyday [EMAIL 
PROTECTED]
Sent: Monday, January 28, 2008 1:28 AM
To: Juniper-Nsp
Subject: [j-nsp] Telnet e320

hello
i want to know if i can telnet to a virtual router configured on the box since 
the only way i do it now is through the default virtual router, is this 
possible?
thanks in advance
___
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] About CFEB Master and Backup

[Richmond, Jeff]

You can just do a mastership switch on the CFEB, just like you would an RE. You 
will experience an outage during the switch, however, so be prepared for that.

[EMAIL PROTECTED]> request chassis cfeb ?
Possible completions:
  master   Set CFEB mastership
  offline  Take CFEB offline
  online   Bring CFEB online
  restart  Restart CFEB

-Jeff


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] [EMAIL 
PROTECTED]
Sent: Friday, January 25, 2008 9:49 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] About CFEB  Master and Backup

Hello , how are you ...
I have a question about CFEB .  I have juniper m10i with 2 CFEBs , i don´t
have any configuration about the CFEBs.

show chassis
redundancy {
routing-engine 0 master;
routing-engine 1 backup;
cfeb 0 preferred;
failover on-loss-of-keepalives;
graceful-switchover {
enable;
}
}


CFEB status:
Slot 0 information:
  State Master
  Intake temperature 23 degrees C / 73 degrees F
  Exhaust temperature32 degrees C / 89 degrees F
  CPU utilization24 percent
  Interrupt utilization  15 percent
  Heap utilization   35 percent
  Buffer utilization 28 percent
  Total CPU DRAM128 MB
  Internet Processor II Version 1, Foundry IBM, Part
number 164
  Start time:   2007-09-25 23:22:22 CST
  Uptime:   121 days, 10 hours, 41 minutes, 19
seconds
Slot 1 information:
  State Backup



My question is ..  I need to make a test with the CFEBs so,  i need to use
the cfeb in slot 1 as master ( now cfeb master is in slot 0 ) . what
should be the procedure ?? ..
can i put offline the cfeb 0  ? .. can i make this with remote
administration  or via console ?   and the most important,  how many time
could experiment traffic interrupt  ??   .  I have bgp configuration,
mpls, ldp, ibgp, vrfs in that juniper.

thanks so much , for your comments . i will apreciate it so much.

luis





Este correo electrónico puede contener información confidencial y
protegida legalmente bajo secreto profesional. La información está
dirigida solamente a la persona o entidad indicada como destinatario y su
acceso por cualquier otra persona no está autorizado. Si usted recibió
este mensaje electrónico por error, infórmeselo al remitente y bórrelo.
Aclaramos que los conceptos y opiniones comprendidos en este correo
electrónico, deben atribuirse exclusivamente a su autor y no deben
entenderse como necesariamente coincidentes con las de NAVEGA.COM, S.A. y
en consecuencia, absolutamente ajenos a la responsabilidad de sus
directores y ejecutivos, en tanto no hayan participado de su confesión y/o
emisión y quede esta participación expresamente consignada en el mensaje.
La divulgación pública de este correo electrónico, como así su copia,
reproducción total o parcial queda prohibida, dando lugar en caso de
inobservancia de esta todas las acciones legales que pudiesen
corresponder. Muchas Gracias.
___
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] New to Juniper (re-try)

[Richmond, Jeff]

You want "compare". See example below:

[EMAIL PROTECTED] show system host-name
host-name br01.mcln;

[edit]
[EMAIL PROTECTED] set system host-name testrouter

[edit]
[EMAIL PROTECTED] show | compare
[edit system]
-  host-name br01.mcln;
+  host-name testrouter;


Regards,
-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Wayne Lansdowne [EMAIL 
PROTECTED]
Sent: Thursday, December 27, 2007 11:06 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] New to Juniper (re-try)

Hello all,

I apologize..my first posting attempt did not come through correctly.

I'm new to the Juniper routers having previously worked with Riverstone.
Within the Riverstone CLI I had the ability to preview all the pending
(non-committed) changes via a 'scratchpad' command.  Does the Juniper
have a similar feature?  I'm unable to find anything thus far to display
a list of yet to be committed changes.  Thus far I'm simply doing a
'commit check' then 'commit' and hoping I had remembered to implement
all my changes.  I'm basically looking for a way to review all the
pending changes before making that commit.

I've done some searching and have come up empty.  Is there a CLI command
I'm missing?

Regards,

Wayne



___
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] RES: Juniper Junos 8.4

[Richmond, Jeff]

FWIW, speaking of PLL issues, I had issues early this morning with 8.2 code 
versions regarding PLL issues on M20s and M320s. I have a JTAC case open and 
they are researching. They pointed out the bug with the M40e and were surprised 
that I am seeing the same exact error symptoms on the other platforms as well. 
BTW, we never had this issue in 8.2R2.4, just the latest 8.2R4.x code...

-Jeff

From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Mario Ravnjak [EMAIL 
PROTECTED]
Sent: Friday, December 14, 2007 12:38 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] RES:  Juniper Junos 8.4

It seems that there is a confirmed bug in 8.4R2.3 for flapping of
interfaces:

There is a problem with PLL circuitry on interfaces.
The problem only impacts the M40e platform. This issue was fixed and
committed in the versions "8.4R3 8.5R2 9.1R1 9.0R1 8.5R1 8.5R1.12 8.3R4".

M.

-Original Message-
From: Gunjan GANDHI [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 13, 2007 7:21 AM
To: Beny Dwi Setyawan; Edson Cardoso; Mario Ravnjak;
juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] RES: Juniper Junos 8.4

I do not have the details, probably best to wait for accurate information to
be released by Juniper.

-Original Message-
From: Beny Dwi Setyawan [mailto:[EMAIL PROTECTED]
Sent: Thursday, 13 December 2007 5:08 PM
To: Gunjan GANDHI; 'Edson Cardoso'; 'Mario Ravnjak';
juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] RES: Juniper Junos 8.4

Hi Gunjan,

It is true this BGP bug only problem on BGP configuration without MD5
authentication, this mean no issue when you implement BGP with MD5 auth.
Is the patch will be major upgrade?

Thanks,
Benny DS

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gunjan GANDHI
Sent: Thursday, December 13, 2007 11:36 AM
To: Edson Cardoso; Mario Ravnjak; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] RES: Juniper Junos 8.4

FYI, update from Juniper today. They have advised there is a critical BGP
bug currently on some JUNOS releases where if a BGP peer receives a
malformed update from another BGP peer - the router closes and
re-establishes the BGP session.

Apparently we are going to get a tech bulletin today/tomorrow with all the
info about the bug.  The release date of the fix is Thursday (US time).

Cheers
///

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Edson Cardoso
Sent: Thursday, 13 December 2007 3:25 AM
To: Mario Ravnjak; juniper-nsp@puck.nether.net
Subject: [j-nsp] RES: Juniper Junos 8.4
Importance: High

Hi Mario,
We saw this same behavior on a M20 router also... Interfaces, OSPF and BGP
flapping .. Seens that version 8.4R2.3 is not totally stable... We did not
find any PR's related yet..

Regards

Qos Serviços
"Excelência em Serviços IP"

Edson R. Cardoso
Professional & Educational Services
[EMAIL PROTECTED]
www.qos.com.br  tel 55 11 3704 0438 fax 55 11 3704
0492



De: [EMAIL PROTECTED] em nome de Mario Ravnjak
Enviada: qua 12-dez-07 12:38
Para: juniper-nsp@puck.nether.net
Assunto: [j-nsp] Juniper Junos 8.4



Hi,

Does anyone have problems with flaping interfaces on Juniper M40 when
upgraded to junos 8.4R2.3?
We see radnom flaping of STM1 (SONET) and E3 interfaces.
We also see frequent OSPF flaps. Juniper guys says, they are investigating
the problem. I think they have problems with with this issue.

Mario R.


-- T - C o m - - W e b m a i l --
Ova poruka poslana je upotrebom T-Com Webmail usluge
Uzivajte u shoppingu ne napustajuci udobnost svoga doma!
http://shopping.tportal.hr 

___
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

___
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] Route import export on Juniper

[Richmond, Jeff]

Just be aware that you can only do this with local routes in the VRF, not 
remotely learned routes from other PEs. At one point I was wanting to make a 
"gateway" PE using auto-export and RIB groups to enter/exit the VRF on a single 
PE, which works great with local routes (interface, static, etc.), but will not 
work with remotely learned VRF routes (via MBGP). I asked Juniper about this, 
and was basically told it just won't work. So, I ended up having each PE do 
auto-export...

Hope this helps,
-Jeff


-Original Message-
From:   [EMAIL PROTECTED] on behalf of Jonathan Crawford
Sent:   Thu 11/15/2007 11:25 AM
To: 'ganesh nagpure'; 'Juniper List'
Cc: 
Subject:Re: [j-nsp] Route import export on Juniper

You can use a rib-group in order to do this...

routing-options {
 rib-groups {
  oam-vrf-inet-0-to-inet-0 {
   import-rib [ oam-vrf.inet.0 inet.0 ]
   import-policy 
  }
 }
}

Then you need to apply the rib-group.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ganesh nagpure
Sent: Thursday, November 15, 2007 10:06 AM
To: Juniper List
Subject: [j-nsp] Route import export on Juniper

Hi,

How do I import route 10.108.8.64/26  from
OAM-VRF.inet.0 to inet.0 ? 


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

10.145.0.2/32  *[Local/0] 2w0d 01:18:24
  Reject
10.145.0.4/30  *[OSPF/10] 12:21:31, metric 1643
> to 10.145.0.34 via fe-1/3/1.0
10.145.0.28/30 *[OSPF/10] 12:21:30, metric 1743

> to 10.145.0.34 via fe-1/3/1.0
10.145.1.3/32  *[Direct/0] 2w0d 01:19:58
> via lo0.0
10.145.1.4/32  *[OSPF/10] 2w0d 01:18:14, metric
1000
> to 10.145.0.34 via fe-1/3/1.0
224.0.0.5/32   *[OSPF/10] 2w0d 01:19:59, metric 1
  MultiRecv

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

10.145.1.1/32  *[RSVP/7] 12:21:25, metric 1743
> to 10.145.0.34 via fe-1/3/1.0,
label-switched-path KINTC2_R1-KINNTC_R1
[LDP/9] 12:21:25, metric 1743
> to 10.145.0.34 via fe-1/3/1.0,
label-switched-path KINTC2_R1-KINNTC_R1
10.145.1.2/32  *[LDP/9] 12:21:25, metric 1643
> to 10.145.0.34 via fe-1/3/1.0,
label-switched-path KINTC2_R1-KINTC2_R2
10.145.1.4/32  *[RSVP/7] 2w0d 01:16:49, metric
1000
> to 10.145.0.34 via fe-1/3/1.0,
label-switched-path KINTC2_R1-KINTC2_R2
[LDP/9] 12:21:26, metric 1000
> to 10.145.0.34 via fe-1/3/1.0,
label-switched-path KINTC2_R1-KINTC2_R2

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

OAM-VRF.inet.0: 28 destinations, 34 routes (28 active,
0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.2.0.0/16*[BGP/170] 00:06:42, localpref 100,
from 10.145.1.2
  AS path: I
> to 10.145.0.34 via fe-1/3/1.0,
Push 177840, Push 291984(top)
[BGP/170] 00:06:42, localpref 100,
from 10.145.1.1
  AS path: I
> to 10.145.0.34 via fe-1/3/1.0,
label-switched-path KINTC2_R1-KINNTC_R1
10.108.8.64/26 *[BGP/170] 00:06:42, localpref 100,
from 10.145.1.2
  AS path: I
> to 10.145.0.34 via fe-1/3/1.0,
Push 177840, Push 291984(top)
[BGP/170] 00:06:42, localpref 100,
from 10.145.1.1
  AS path: I
> to 10.145.0.34 via fe-1/3/1.0,
label-switched-path KINTC2_R1-KINNTC_R1
10.144.2.128/26*[BGP/170] 00:06:42, localpref 100,
from 10.145.1.2
  AS path: I
> to 10.145.0.34 via fe-1/3/1.0,
Push 177856, Push 291984(top)
[BGP/170] 00:06:42, localpref 100,
from 10.145.1.1
  AS path: I




 


Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.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] PE to PE ping

[Richmond, Jeff]

I would really need some more info to really help, but are you pinging via the 
routing instance from PE2 to PE1 and that is working (as opposed to pinging via 
inet.0)? When you say PE1 has no routes, are you saying at all, or just the 
VRF, inet.0, or both? 

-Jeff


-Original Message-
From:   [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent:   Thu 10/11/2007 6:11 PM
To: juniper-nsp@puck.nether.net
Cc: 
Subject:[j-nsp] PE to PE ping




i am not able to ping b/w pe1 and pe2, but pe2 can ping pe1 vrf interface? PE1 
does not have any routes

in VPNA VRF to other PE's VRF, but it can still answer a ping? i dont think 
this is a right behavior?

I may be wrong but do like to see if you guys have seen this..





JS





Email and AIM finally together. You've gotta check out free AOL Mail! - 
http://mail.aol.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

Re: [j-nsp] JUNOS Training (was Re: Juniper M-series vs 72xx/NPE-G2)

[Richmond, Jeff]

Indeed. What really stinks is when you have a mix of M and E series, as well as 
IOS in your network. One forgets how much better JUNOS really is until you have 
to go back to IOS or JUNOSe...

-Jeff 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of john heasley
Sent: Thursday, May 24, 2007 11:36 AM
To: Stacy W. Smith
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] JUNOS Training (was Re: Juniper M-series vs
72xx/NPE-G2)


Wed, May 23, 2007 at 12:44:39AM -0600, Stacy W. Smith:
> We now have a free eLearning course available on the Juniper Web site  
> entitled "JUNOS as a Second Language (JSL)". It's a quick  
> introduction to JUNOS that leverages the student's existing Cisco IOS  
> knowledge. The course is not designed to teach the student everything  
> about JUNOS, but to get them over the common misconception that JUNOS  
> is hard because it's different than IOS.

Given a choice, its hard to believe that anyone would choose IOS{-like}
over JunOS.  Besides the obvious, this was the one disappointing thing
about Procket.
___
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 E-320 features

[Richmond, Jeff]

There are a number of differences. The E320 is the way Juniper wants to go 
going forward, as it addresses some of the deficiencies of the older E series 
line. While we have had growing pains with the E320s in our network, some of 
the new features, like LM redundancy, work great. Contact me offlist if you 
want more info. I will be honest and say though that Juniper still has a way to 
go on the software side, though the latest 7.3.1 release is a lot more mature 
than the initial 7.3.1 (assuming the use of 320Gb SRPs and SFMs, not the 100Gb 
counterparts, as I have no experience with the 100Gb modules).

-Jeff

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of julio roca
Sent: Thursday, May 24, 2007 12:11 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Juniper E-320 features


Hi all, i have a question to the list
i was wondering what are the new features of the new Juniper router E-320
and what makes it different from the previous E-Series Routers ?
In which case the E320 is the router to be adquired?
Are there only hardware differences or also software diffs ??


 Thanks in advance!!!

BR, J.A.R
___
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] multiprotocol bgp and bgp reflection

[Richmond, Jeff]

The only other thing you have to watch for is how you have your next-hop self 
policy configured. The way we traditionally did it was causing problems when 
using route reflection. Instead of reworking the whole thing, I went and 
updated the policy with a new term to ignore anything with a community of 
target:*:* (basically if you match on that community, accept and jump out).

Shoot me an email if you want more detail.

-Jeff



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Sean Clarke
Sent: Tuesday, January 23, 2007 6:40 AM
To: Benny Sumitro
Cc: juniper-nsp
Subject: Re: [j-nsp] multiprotocol bgp and bgp reflection



--

Not so long ago you wrote :
BS> The configuration is the same like configuring normal route
BS> reflector except you must enable family inet-vpn for L3VPN. The
BS> important thing is you must have a LSP to all PEs because without
BS> LSP or reachability, the RR will mark the routes as unusable and not 
advertised it to the PEs.

  Or  ..  you  add a discard route to the loopback addresse network on
  the  P-router  in  inet.3,  then  the  routes  will not be marked as
  unusable.  It's  easier  than  configuring  LSP's  between PE - P
  routers.

i.e.

# show routing-options
rib inet.3 {
static {
route 192.168.0.0/24 discard;
}
}  

cheers
Sean
___
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] showing uncommittted config

[Richmond, Jeff]

If you just mean you want to look at changes you just made in config mode but 
haven't committed yet, just do a show conf. Your uncommitted changes will be 
there. To compare to the running (committed) configuration, do a "show | 
compare rollback 0"

Hth,
-Jeff

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Aamir Amin
Sent: Tuesday, January 23, 2007 8:04 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] showing uncommittted config


Hi Guys, 

 

Is there a way of showing configuration that hasn't been committed?

 

thanks
 
--- 
The information in this email and any files transmitted with it are intended 
for the named recipient and may be confidential, privileged or otherwise 
protected from disclosure. If you are not the intended recipient you must not 
read, copy, disclose, forward or otherwise use the information contained in 
this email or in any files transmitted with it. If you have received this 
e-mail in error, please notify the sender immediately by reply e-mail and 
delete the message and any files transmitted with it without retaining any 
copies. Any representations or commitments expressed in this email are subject 
to contract. AboveNet Communications UK Limited is a company registered in 
England under No. 372. Registered office: Anchorage House, 2 Clove 
Crescent, London, E14 2BE.
___
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