Re: [j-nsp] Olive for EX Switches and M Series with JunOS 10.0R2
At this time!? Try never. Olive is NOT a JunOS or Juniper router emulator! Olive is JunOS running naively on standard x86 hardware without a PFE. So you get all control plane features but no forwarding plane features. Good for testing some BGP policy or OSPF config, but beyond that it won't do much more like QoS, any services, etc. Olive is not like dynamips/dynagen/gns3 in which real hardware is emulated. I am tired of people referring to that. Since the EX is PowerPC based and all features are on the EX-PFEs you won't see an "Olive" probably ever. Now if you can just look right here at my men-in-black pen I need to wipe your memories. Remember... olive is just a fruit and tasty in a dirty martini. *wink* *wink* -Brandon On Thu, Feb 4, 2010 at 6:53 PM, Truman Boyes wrote: > Hi, > > You can not run an EX-olive at this time. > > Truman > > > On 3/02/2010, at 6:05 PM, Ashok Kumar wrote: > >> Dear Team; >> >> Has any one configured/tested Olive with >> *jinstall-10.0R2.10-export-signed.tgz >> *. Also is it possible to configure Olive for EX switches. >> >> If yes then please share the procedure? >> >> Thanks for your support >> >> regards >> Ashok Kumar >> ___ >> 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] not able to login
Something looks wrong with the passwd file being in sync with the [edit system login] stanza. Try to 'commit full' Or delete the user and re-add them. Truman On 3/02/2010, at 8:34 PM, Taqdir Singh wrote: > Hi, > > I am trying to login one of our juniper router remotelty with correct > username and password but it logins and throws me out with msg. what could > be the reason ? > > This is J series > > login: > Password: > --- JUNOS 9.3R2.8 built 2008-12-17 23:24:14 UTC > invalid user: getpwuid fails > Connection to host lost. > > > > > > -- > Taqdir Singh > Network Engineering > (+91) 991-170-9496 | (+91) 801-041-5988 > > One who asks is a fool for a moment, one who doesn't ask remains fool for > ever > ___ > 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] Olive for EX Switches and M Series with JunOS 10.0R2
Hi, You can not run an EX-olive at this time. Truman On 3/02/2010, at 6:05 PM, Ashok Kumar wrote: > Dear Team; > > Has any one configured/tested Olive with *jinstall-10.0R2.10-export-signed.tgz > *. Also is it possible to configure Olive for EX switches. > > If yes then please share the procedure? > > Thanks for your support > > regards > Ashok Kumar > ___ > 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] MX-Series JUNOS Version
On Friday 05 February 2010 03:31:39 am Richard A Steenbergen wrote: > Of course > you can't assume that just because it is an R4 that it > will be stable, since any new issues which come in after > that just get moved to being dealt with in future > versions (where there are all new bugs!), and there are > no R5's. :) Indeed :-). But now we have "Service" releases :-). The world is well again, if your choice of JUNOS gets the E- EOL sticker :-). But look at this way, if your 'slow FIB' issue does get fixed, you'll probably need to move to some flavour of JUNOS 10 :-\. > Groan. What's the latest on this, last I heard it was > supposed to be out last week? Yep, but, nope! Messed up another upgrade cycle we planned for this weekend. 9.5R4 is currently being tested. Potential release scheduled for 3rd week of this month. Hopefully the delayed release is a sign of good things to come, hehe. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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
Excerpts from matthew zeier's message of Thu Feb 04 09:14:52 -0800 2010:
> 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?
Define a system login class that includes the "view" and
"view-configuration" permissions. You could also explicitly place a
regexp in the class to allow certain CLI command patterns to be allowed.
This could be useful if you're also setting rancid to fetch things other
than the configuration.
For example:
system {
login {
class only-see-config {
permissions [ view view-configuration ];
}
user rancid {
class only-see-config;
authentication {
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
I think cleupon has some 3rd party modules that are known to work. Running 9.6 mine looks as follows with 128M on the CFEB: show chassis cfeb CFEB status: State Online Intake temperature 14 degrees C / 57 degrees F Exhaust temperature20 degrees C / 68 degrees F CPU utilization 6 percent Interrupt utilization 0 percent Heap utilization 42 percent Buffer utilization 26 percent Total CPU DRAM128 MB Internet Processor II Version 2, Foundry IBM, Part number 164 Start time: 2009-10-02 20:24:57 CDT Uptime: 124 days, 17 hours, 58 minutes, 58 seconds CSBR0(m7ino2 vty)# show jtree 0 memory Memory Statistics: 8388608 bytes total (2 banks) 4675952 bytes used 3712656 bytes free 8128 pages total 4556 pages used 3572 pages free 31 max freelist size Free Blocks: Size(b)Total(b)Free TFree Alloc -- -- -- -- 8 32672722483 1 405925 16 1165904 328 0 72541 24 504 1 0 20 32 384 10 0 2 40 0 0 0 0 48 0 0 0 0 56 0 0 0 0 64 128 1 0 1 72 0 0 0 0 80 0 0 0 0 88 0 0 0 0 96 0 0 0 0 104 0 0 0 0 Total 4434192 Context: 0xbb0480 Brendan Mannella wrote: I just looked and mine is only 128M on the CFEB. As with the RE, is there a third party memory upgrade that could be bought? Part Numbers welcome. Brendan On 2/4/10 12:53 PM, "sth...@nethelp.no" wrote: Sounds like we'll need the RE-850 if we want to take more than our 2 full feeds though -- although others have said we may run out of CFEB RAM first? Excuse the newbie question, but what is the CFEB RAM used for -- we have one router with one full feed and the CFEB is at 42% RAM, another with two full feeds and the CFEB is at 42% also... The CFEB memory utilization you get from "show chassis cfeb", e.g. CFEB status: State Online Intake temperature 39 degrees C / 102 degrees F Exhaust temperature46 degrees C / 114 degrees F CPU utilization11 percent Interrupt utilization 0 percent Heap utilization 26 percent Buffer utilization 27 percent Total CPU DRAM256 MB is only part of the story. This shows the DRAM memory on the CFEB, which is used for the operating system kernel running there, a copy of the RIB, and some other stuff. What is equally important is the high speed memory used for packet pushing (static RAM for the traditional CFEB), which is a rather small amount, and which you only see if you login to the CFEB and use the "show jtree 0 memory" command. E.g.: CSBR0(ar1.xxx vty)# show jtree 0 memory Memory Statistics: 8388608 bytes total (2 banks) 5017384 bytes used 3371224 bytes free 8128 pages total 4876 pages used 3252 pages free 31 max freelist size This memory holds the FIB, nexthops and similar stuff. Notice only *8 Megabytes* total, and about 60% of this memory in use in the example above. If you run out of *this* memory, your box is in real trouble. The "plain old" M7i/M10i CFEB comes with 128 MBytes of CFEB DRAM, which can be upgraded to 256 MBytes. 256 MBytes is mentioned as a requirement for JunOS 9.x. The CFEB SRAM cannot be upgraded (but you can buy a new enhanced CFEB instead...) 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX-Series JUNOS Version
On Fri, Feb 05, 2010 at 02:18:24AM +0800, Mark Tinka wrote: > We generally try to stay away from anything pre-R3 or R4 > (depending on the history of R1 and R2). I haven't had a > chance to try JUNOS 9.6 or 10.0, but this is mostly > influenced by how terrible 9.x has been, and we're done > "chasing" JUNOS. Couldn't agree more. Everything since 8.4 has averaged out to two bugs added for every one bug fixed. Of course you can't assume that just because it is an R4 that it will be stable, since any new issues which come in after that just get moved to being dealt with in future versions (where there are all new bugs!), and there are no R5's. :) > Too bad 9.5R4 has been seriously delayed. Groan. What's the latest on this, last I heard it was supposed to be out last week? -- 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
Re: [j-nsp] Peering with loopback
On Thu, Feb 04, 2010 at 09:57:03AM -0800, Bill Blackford wrote: > I don't have the session live anymore but my recollection after looking in > the syslog is that I was trying to peer up with the loopback address and > getting errors that the interface of the local interconnect couldn't > establish peer. > > As Harry Reynolds posted earlier, > > > When lo0 peering, as long as both ends are active, you can get by with just > one end correctly configured to use lo0 as source. Not so when neither end is. > > > This explains why my C to J worked but the J to J did not. > > Thanks all. I will try this on my next window. You may want to just configure system default-address-selection, which makes outbound connection attempts default to using the loopback address rather than the IP on the interface that the packet went out (like Cisco does). This is usually "better" in all respects, and solves the IBGP problem too (and without having to hard-code specific router IP addresses in your IBGP groups). -- 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
Re: [j-nsp] Peering with loopback
On Thu, Feb 04, 2010 at 09:07:59AM -0800, Bill Blackford wrote: > I'm running a mixed environment of Juniper and Cisco and have noticed > some odd behavior with some of iBGP peers. It's my understanding that > Junos has no equivalent to the Cisco 'update-source loobback0'. I > haven't run into to problems peering with the respective loopback > between a Cisco to Juniper but have with a Juniper to Juniper (that is > attempting to bring the peers up via the loopbacks). Although my tests > were limited and lack too many details, I'm curious if anyone has run > up against this issue and what your recommendations are. The issue I was talking about previously was when carrying multiple AFI's and trying to do next-hop self on an IPv6 next-hop while using an IPv4 neighbor. You should be fine with local-address and next-hop self if you're just doing IPv4 next-hops. -- 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
Re: [j-nsp] MX-Series JUNOS Version
On Thu, Feb 04, 2010 at 12:42:29PM -0500, Eric Van Tol wrote: > Hi all, > We just took shipment of some MX960s and MX240s for a much needed > network upgrade. They came shipped with 10.0R2.10. This seems to be > the latest and greatest version of JUNOS. The question is, is anyone > currently running it and is it "stable"? Any serious bugs I should be > aware of that might not be listed in the JTAC site? We've been over this a lot recently, so check the archives. I personally recommend you wait for 9.5R4, which is due out just about any time now. 9.6R3 might not be a bad option either, but I can't personally vouch for it quite yet. From what I've seen, I don't see any particularly interesting features for MX between 9.6 and 10.1 (it seems like a healthy majority of the dev work being done lately is for SRX). As generic advice I would say that if you are a "classic" Juniper user, you need to put aside any notions you used to have about Juniper routinely putting out solid, well tested, working code. For all intents and purposes they are now Cisco 2.0, and should be treated as such if you want a working network. You really don't want to rush out and try the latest and greatest code without doing some very extensive testing, and anything before R3 is probably a bad idea if you have any kind of complexity in your network/configuration at all. FYI for the bug I previously mentioned which crashes rpd in 9.5R3 when an interface flaps, it appears to be related to accept-remote-nexthop, and can probably be avoided by not configuring that. We've still working on the slow fib issue too, haven't quite found the cause yet, but the Juniper guys have done a great job helping document the behavior at least. http://www.e-gerbil.net/slowfib.jpg The red line shows the pending routes. The current working theory is that installation of the routes into the pfe is blocked until rpd is able to advertise them to IBGP. In the graph above, you can see that the pending routes don't start to clear until IBGP fully converges, which happens after a local transit interface converges and there are no new routes to send into IBGP. This is the closest I've felt to actually finding and fixing the cause of the problem in...well... ever, so hopefully I'll have more good news soon. :) -- 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
Re: [j-nsp] Peering with loopback
On Thu, 4 Feb 2010, Bill Blackford wrote: I don't have the session live anymore but my recollection after looking in the syslog is that I was trying to peer up with the loopback address and getting errors that the interface of the local interconnect couldn't establish peer. I've found that IPv4 IBGP via loopbacks requires specifying 'local-address' to work (Juniper to Juniper) whereas IPv6 IBGP via loopbacks does not. But I never quite figured out why this was so. Could this be similar to your problem? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
I just looked and mine is only 128M on the CFEB. As with the RE, is there a third party memory upgrade that could be bought? Part Numbers welcome. Brendan On 2/4/10 12:53 PM, "sth...@nethelp.no" wrote: >> Sounds like we'll need the RE-850 if we want to take more than our 2 full >> feeds >> though -- although others have said we may run out of CFEB RAM first? Excuse >> the newbie question, but what is the CFEB RAM used for -- we have one router >> with one full feed and the CFEB is at 42% RAM, another with two full feeds >> and >> the CFEB is at 42% also... > > The CFEB memory utilization you get from "show chassis cfeb", e.g. > > CFEB status: > State Online > Intake temperature 39 degrees C / 102 degrees F > Exhaust temperature46 degrees C / 114 degrees F > CPU utilization11 percent > Interrupt utilization 0 percent > Heap utilization 26 percent > Buffer utilization 27 percent > Total CPU DRAM256 MB > > is only part of the story. This shows the DRAM memory on the CFEB, > which is used for the operating system kernel running there, a copy > of the RIB, and some other stuff. > > What is equally important is the high speed memory used for packet > pushing (static RAM for the traditional CFEB), which is a rather > small amount, and which you only see if you login to the CFEB and > use the "show jtree 0 memory" command. E.g.: > > CSBR0(ar1.xxx vty)# show jtree 0 memory > Memory Statistics: > 8388608 bytes total (2 banks) > 5017384 bytes used > 3371224 bytes free >8128 pages total >4876 pages used >3252 pages free > 31 max freelist size > > This memory holds the FIB, nexthops and similar stuff. > > Notice only *8 Megabytes* total, and about 60% of this memory in use > in the example above. If you run out of *this* memory, your box is in > real trouble. > > The "plain old" M7i/M10i CFEB comes with 128 MBytes of CFEB DRAM, > which can be upgraded to 256 MBytes. 256 MBytes is mentioned as a > requirement for JunOS 9.x. > > The CFEB SRAM cannot be upgraded (but you can buy a new enhanced > CFEB instead...) > > 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] MX-Series JUNOS Version
On Friday 05 February 2010 01:42:29 am Eric Van Tol wrote: > Hi all, > We just took shipment of some MX960s and MX240s for a > much needed network upgrade. They came shipped with > 10.0R2.10. This seems to be the latest and greatest > version of JUNOS. The question is, is anyone currently > running it and is it "stable"? Any serious bugs I > should be aware of that might not be listed in the JTAC > site? We generally try to stay away from anything pre-R3 or R4 (depending on the history of R1 and R2). I haven't had a chance to try JUNOS 9.6 or 10.0, but this is mostly influenced by how terrible 9.x has been, and we're done "chasing" JUNOS. Too bad 9.5R4 has been seriously delayed. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Peering with loopback
> > I'm running a mixed environment of Juniper and Cisco and have noticed > some odd behavior with some of iBGP peers. It's my understanding that > Junos has no equivalent to the Cisco 'update-source loobback0'. Try, "local-address x.x.x.x" under edit protocols bgp where x.x.x.x is your lo0 loopback IP. James ___ 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
Hi,
Am 04.02.10 18:14 schrieb matthew zeier:
> 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?
system {
login {
class rancid {
permissions [ secret view view-configuration ];
}
}
}
rgds,
Malte
--
Malte v. dem Hagen
Teamleitung Network Engineering & Operation
Abteilung Technik
---
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
signature.asc
Description: OpenPGP digital signature
___
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
How 'bout this:
ran...@breakme> show configuration system
login {
class rancid {
permissions view-configuration;
allow-commands "show configuration.*|quit";
deny-commands .*;
}
user rancid {
uid 2003;
class rancid;
authentication {
encrypted-password /* SECRET-DATA */; ## SECRET-DATA
}
}
}
ran...@breakme> ?
Possible completions:
quit Exit the management session
show Show system information
ran...@breakme> show ?
Possible completions:
configurationShow current configuration
ran...@breakme> show configuration ?
Possible completions:
<[Enter]>Execute this command
> access Network access configuration
> accounting-options Accounting data configuration
> applications Define applications by protocol characteristics
+ apply-groups Groups from which to inherit configuration data
> chassis Chassis configuration
> class-of-service Class-of-service configuration
> firewall Define a firewall configuration
> forwarding-options Configure options to control packet forwarding
> groups Configuration groups
> interfaces Interface configuration
> logical-systems Logical systems
> policy-options Routing policy option configuration
> protocolsRouting protocol configuration
> routing-instancesRouting instance configuration
> routing-options Protocol-independent routing option configuration
> security Security configuration
> services Service PIC applications settings
> snmp Simple Network Management Protocol configuration
> system System parameters
|Pipe through a command
ran...@breakme>
--Stacy
On Feb 4, 2010, at 10: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] read-only config account, "rancid" user
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] Need suggestions..
> What is the PN# for the "new" CFEB? Looks like that may be in our future.. FEB-M10i-M7i-E-S M10i, M7i Enhanced Forwarding Engine Board, Spare $17.000 list price Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Friday 05 February 2010 12:55:58 am TCIS List Acct wrote: > Excuse the > newbie question, but what is the CFEB RAM used for -- we > have one router with one full feed and the CFEB is at > 42% RAM, another with two full feeds and the CFEB is at > 42% also... There's a couple of "memories" on the CFEB: - RAM for packet memory - RAM for the microkernel - RAM for the FIB. - RAM for other control functions Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] m7i as pppoe bras
On Thursday 04 February 2010 08:39:45 pm vvasi...@vvasilev.net wrote: > P.S. PPPoE is currently supported on M120 and M320 > routers only. And on the MPC's supported on the MX-series routers. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Friday 05 February 2010 01:58:07 am TCIS List Acct wrote: > Nope. We are running 8.4 In addition to Steinar's comments, the enhanced CFEB requires JUNOS 9.4, minimum. So you definitely don't have it :-). Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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
I use, Set system login class NOC permissions view Set system login class NOC permissions view-configuration Set system login user rancid uid 2001 Set system login user rancid class NOC YMMV -b -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of matthew zeier Sent: Thursday, February 04, 2010 9:15 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] read-only config account, "rancid" user 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] Need suggestions..
Of course it is :-/ What is the PN# for the "new" CFEB? Looks like that may be in our future.. sth...@nethelp.no wrote: I've seen several references to CFEB-E's in this thread -- we have a PN# 750-010463 in all of our M7i's -- is that the "enhanced" CFEB that folks are referring to? Nope, that's a "plain old" CFEB. Steinar Haug, Nethelp consulting, sth...@nethelp.no -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
Nope. We are running 8.4 Mark Tinka wrote: On Friday 05 February 2010 12:36:59 am TCIS List Acct wrote: I've seen several references to CFEB-E's in this thread -- we have a PN# 750-010463 in all of our M7i's -- is that the "enhanced" CFEB that folks are referring to? Are you running JUNOS 9.4 or later? ... yes, it's a trick question ... Cheers, Mark. -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Peering with loopback
I don't have the session live anymore but my recollection after looking in the syslog is that I was trying to peer up with the loopback address and getting errors that the interface of the local interconnect couldn't establish peer. As Harry Reynolds posted earlier, When lo0 peering, as long as both ends are active, you can get by with just one end correctly configured to use lo0 as source. Not so when neither end is. This explains why my C to J worked but the J to J did not. Thanks all. I will try this on my next window. -b -Original Message- From: Mark Tinka [mailto:mti...@globaltransit.net] Sent: Thursday, February 04, 2010 9:52 AM To: juniper-nsp@puck.nether.net Cc: Bill Blackford Subject: Re: [j-nsp] Peering with loopback On Friday 05 February 2010 01:07:59 am Bill Blackford wrote: > I'm running a mixed environment of Juniper and Cisco and have noticed > some odd behavior with some of iBGP peers. > It's my understanding that Junos has no equivalent to the Cisco > 'update-source loobback0'. I haven't run into to problems peering > with the respective loopback between a Cisco to Juniper but have with > a Juniper to Juniper (that is attempting to bring the peers up via > the loopbacks). Although my tests were limited and lack too many > details, I'm curious if anyone has run up against this issue and what > your recommendations are. What kinds of issues are you facing? Specify the 'local-address' feature as part of your session parametres. Cheers, Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
We are running 8.4R4.2.. inet.0: 306438 destinations, 579016 routes (305221 active, 0 holddown, 191417 hidden) + = Active Route, - = Last Active, * = Both Routing Engine status: Temperature 31 degrees C / 87 degrees F CPU temperature 29 degrees C / 84 degrees F DRAM 768 MB Memory utilization 56 percent CPU utilization: User 1 percent Background 0 percent Kernel 2 percent Interrupt 0 percent Idle 96 percent Model RE-5.0 sth...@nethelp.no wrote: What JunOS version are you running? This is an M7i with RE-400, a full Internet routing table, inet.0: 314795 destinations, 629302 routes (314784 active, 0 holddown, 19 hidden) a handfull of MPLS L3VPNs (around 3K routes here) and a few interfaces, running JunOS 9.5R3.7. Memory usage: Routing Engine status: Temperature 33 degrees C / 91 degrees F CPU temperature 30 degrees C / 86 degrees F DRAM 768 MB Memory utilization 94 percent Model RE-5.0 I'd say *any* RE-400 box with a full routing table and a recent JunOS version is reason for worry. We have been unpleasantly surprised a few times (boxes starting to show swap usage). -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
> Sounds like we'll need the RE-850 if we want to take more than our 2 full > feeds > though -- although others have said we may run out of CFEB RAM first? Excuse > the newbie question, but what is the CFEB RAM used for -- we have one router > with one full feed and the CFEB is at 42% RAM, another with two full feeds > and > the CFEB is at 42% also... The CFEB memory utilization you get from "show chassis cfeb", e.g. CFEB status: State Online Intake temperature 39 degrees C / 102 degrees F Exhaust temperature46 degrees C / 114 degrees F CPU utilization11 percent Interrupt utilization 0 percent Heap utilization 26 percent Buffer utilization 27 percent Total CPU DRAM256 MB is only part of the story. This shows the DRAM memory on the CFEB, which is used for the operating system kernel running there, a copy of the RIB, and some other stuff. What is equally important is the high speed memory used for packet pushing (static RAM for the traditional CFEB), which is a rather small amount, and which you only see if you login to the CFEB and use the "show jtree 0 memory" command. E.g.: CSBR0(ar1.xxx vty)# show jtree 0 memory Memory Statistics: 8388608 bytes total (2 banks) 5017384 bytes used 3371224 bytes free 8128 pages total 4876 pages used 3252 pages free 31 max freelist size This memory holds the FIB, nexthops and similar stuff. Notice only *8 Megabytes* total, and about 60% of this memory in use in the example above. If you run out of *this* memory, your box is in real trouble. The "plain old" M7i/M10i CFEB comes with 128 MBytes of CFEB DRAM, which can be upgraded to 256 MBytes. 256 MBytes is mentioned as a requirement for JunOS 9.x. The CFEB SRAM cannot be upgraded (but you can buy a new enhanced CFEB instead...) Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Peering with loopback
On Friday 05 February 2010 01:07:59 am Bill Blackford wrote: > I'm running a mixed environment of Juniper and Cisco and > have noticed some odd behavior with some of iBGP peers. > It's my understanding that Junos has no equivalent to > the Cisco 'update-source loobback0'. I haven't run into > to problems peering with the respective loopback between > a Cisco to Juniper but have with a Juniper to Juniper > (that is attempting to bring the peers up via the > loopbacks). Although my tests were limited and lack too > many details, I'm curious if anyone has run up against > this issue and what your recommendations are. What kinds of issues are you facing? Specify the 'local-address' feature as part of your session parametres. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Peering with loopback
Bill- JunOS supports a 'local-address' statement within a neighbor or BGP group, which is pretty much the same as update-source on cisco, although it uses an IP rather than interface name. David On 2/4/2010 12:07 PM, Bill Blackford wrote: I'm running a mixed environment of Juniper and Cisco and have noticed some odd behavior with some of iBGP peers. It's my understanding that Junos has no equivalent to the Cisco 'update-source loobback0'. I haven't run into to problems peering with the respective loopback between a Cisco to Juniper but have with a Juniper to Juniper (that is attempting to bring the peers up via the loopbacks). Although my tests were limited and lack too many details, I'm curious if anyone has run up against this issue and what your recommendations are. Thank you, -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD this message was composed using 100% recycled electrons ___ 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] Peering with loopback
There is an equivalent. Local-address. When lo0 peering, as long as both ends are active, you can get by with just one end correctly configured to use lo0 as source. Not so when neither end is. HTHs -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Bill Blackford Sent: Thursday, February 04, 2010 9:08 AM To: 'juniper-nsp@puck.nether.net' Subject: [j-nsp] Peering with loopback I'm running a mixed environment of Juniper and Cisco and have noticed some odd behavior with some of iBGP peers. It's my understanding that Junos has no equivalent to the Cisco 'update-source loobback0'. I haven't run into to problems peering with the respective loopback between a Cisco to Juniper but have with a Juniper to Juniper (that is attempting to bring the peers up via the loopbacks). Although my tests were limited and lack too many details, I'm curious if anyone has run up against this issue and what your recommendations are. Thank you, -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD this message was composed using 100% recycled electrons ___ 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] MX-Series JUNOS Version
Hi all, We just took shipment of some MX960s and MX240s for a much needed network upgrade. They came shipped with 10.0R2.10. This seems to be the latest and greatest version of JUNOS. The question is, is anyone currently running it and is it "stable"? Any serious bugs I should be aware of that might not be listed in the JTAC site? TIA, evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
I agree about the services. We just hang an EX4200 off of ours for more density - won't help you if you need more than 6GB of throughput though. Mark Tinka wrote: On Friday 05 February 2010 12:26:09 am TCIS List Acct wrote: We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with taking full routes (we are at 55% memory usage right now). With all of the comments on this topic, should we be worried? If you: - add new upstreams in the future with full feeds from them - add new services, e.g., l3vpn's, e.t.c. - anything else that requires enough control plane memory ... you may start hitting the limits. Chances are that if you're happy with the RE-400 memory- utilization-wise, the RE-850 may yet be a viable upgrade for you in that department. But then again, I recall you say the M7i isn't dense enough for you, Gig-E wise. Been there :-)... Cheers, Mark. ___ 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] Need suggestions..
Here is ours on 9.6R1.3, two full feeds, approx 500 logical interfaces inet.0: 305813 destinations, 604735 routes (305813 active, 0 holddown, 1 hidden) Routing Engine status: Temperature 19 degrees C / 66 degrees F CPU temperature 16 degrees C / 60 degrees F DRAM 768 MB Memory utilization 95 percent Model RE-5.0 Start time 2009-10-02 20:21:49 CDT Uptime 124 days, 15 hours, 52 minutes, 58 seconds Last reboot reason Router rebooted after a normal shutdown. Load averages: 1 minute 5 minute 15 minute 0.00 0.00 0.00 sth...@nethelp.no wrote: We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with taking full routes (we are at 55% memory usage right now). With all of the comments on this topic, should we be worried? What JunOS version are you running? This is an M7i with RE-400, a full Internet routing table, inet.0: 314795 destinations, 629302 routes (314784 active, 0 holddown, 19 hidden) a handfull of MPLS L3VPNs (around 3K routes here) and a few interfaces, running JunOS 9.5R3.7. Memory usage: Routing Engine status: Temperature 33 degrees C / 91 degrees F CPU temperature 30 degrees C / 86 degrees F DRAM 768 MB Memory utilization 94 percent Model RE-5.0 I'd say *any* RE-400 box with a full routing table and a recent JunOS version is reason for worry. We have been unpleasantly surprised a few times (boxes starting to show swap usage). Our units push ~200Mbit traffic, so they are nowhere near capacity CPU wise. Packet forwarding is done in hardware on this platform, the CPU is not involved. 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
[j-nsp] read-only config account, "rancid" user
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
Re: [j-nsp] Need suggestions..
On Friday 05 February 2010 12:51:49 am Kevin Wormington wrote: > As far as I now, the CPU usage doesn't have anything to > due with the amount of traffic that is transiting the > router since it's done by the PFE hardware. You would be correct about that. With the M7i (as with other Juniper hardware-based platforms), if it's not done in hardware, it's not done :-). Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
> I've seen several references to CFEB-E's in this thread -- we have a PN# > 750-010463 in all of our M7i's -- is that the "enhanced" CFEB that folks are > referring to? Nope, that's a "plain old" CFEB. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Friday 05 February 2010 12:36:59 am TCIS List Acct wrote: > I've seen several references to CFEB-E's in this thread > -- we have a PN# 750-010463 in all of our M7i's -- is > that the "enhanced" CFEB that folks are referring to? Are you running JUNOS 9.4 or later? ... yes, it's a trick question ... Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
CFEB memory is where the actual paths/routes are stored in the hardware for forwarding. IIRC it's usage is based on the number of distinct paths not how many feeds you have. ie. you could have 1 or 4 full feeds and still have ~300k paths which is what you observe with your 1 or 2 feeds. The original CFEB will hold ~500k paths, the CFEB-E ~1mil. Kevin TCIS List Acct wrote: All we use them for is IPv4 routing and BGP. Nothing else. Very few local routes also. Sounds like we'll need the RE-850 if we want to take more than our 2 full feeds though -- although others have said we may run out of CFEB RAM first? Excuse the newbie question, but what is the CFEB RAM used for -- we have one router with one full feed and the CFEB is at 42% RAM, another with two full feeds and the CFEB is at 42% also... Kevin Wormington wrote: We also have a few M7is with RE-400s and 768MB RAM and don't have any problems with a thousand or so logical interfaces and 2 full bgp feeds each (only 300+k routes in FIB, and full IPV6 tables). The memory usage is at 95% but they don't swap and I think I remember seeing somewhere that the memory usage reported is always high in later JunOS releases (these are at 9.6R1.3). I think where you run into problems is if you are using some of the advanced services - ie a bunch of MPLS L3VPNs, etc. If you are just routing IPV4/IPV6, dhcp relaying, BGP then I personally think they have quite a bit of life left in them. As far as I now, the CPU usage doesn't have anything to due with the amount of traffic that is transiting the router since it's done by the PFE hardware. Kevin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
> We also have a few M7is with RE-400s and 768MB RAM and don't have any > problems with a thousand or so logical interfaces and 2 full bgp feeds > each (only 300+k routes in FIB, and full IPV6 tables). The memory usage > is at 95% but they don't swap and I think I remember seeing somewhere > that the memory usage reported is always high in later JunOS releases > (these are at 9.6R1.3). > > I think where you run into problems is if you are using some of the > advanced services - ie a bunch of MPLS L3VPNs, etc. If you are just > routing IPV4/IPV6, dhcp relaying, BGP then I personally think they have > quite a bit of life left in them. I wouldn't bet on RE-400 / 768 MB having a lot of life left *with full Internet routing tables and recent JunOS versions*. If you remove one or both of those qualifications, you should be fine for quite a while yet. > As far as I now, the CPU usage doesn't have anything to due with the > amount of traffic that is transiting the router since it's done by the > PFE hardware. Correct. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Peering with loopback
I'm running a mixed environment of Juniper and Cisco and have noticed some odd behavior with some of iBGP peers. It's my understanding that Junos has no equivalent to the Cisco 'update-source loobback0'. I haven't run into to problems peering with the respective loopback between a Cisco to Juniper but have with a Juniper to Juniper (that is attempting to bring the peers up via the loopbacks). Although my tests were limited and lack too many details, I'm curious if anyone has run up against this issue and what your recommendations are. Thank you, -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD this message was composed using 100% recycled electrons ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Friday 05 February 2010 12:30:18 am TCIS List Acct wrote: > What is the anticipated price on the MX80? Doubt you'll get any response to this here since most information on the MX80 is likely under NDA. Would recommend talking to your account team. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Friday 05 February 2010 12:26:09 am TCIS List Acct wrote: > We have 4 M7i's with RE-400's and 768M RAM and have never > had a problem with taking full routes (we are at 55% > memory usage right now). > > With all of the comments on this topic, should we be > worried? If you: - add new upstreams in the future with full feeds from them - add new services, e.g., l3vpn's, e.t.c. - anything else that requires enough control plane memory ... you may start hitting the limits. Chances are that if you're happy with the RE-400 memory- utilization-wise, the RE-850 may yet be a viable upgrade for you in that department. But then again, I recall you say the M7i isn't dense enough for you, Gig-E wise. Been there :-)... Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
I seem to remember some discussion about how memory usage was reported changing between the 8.x and 9.x releases. ie, it would report much higher usage in newer releases but was still using basically the same amount of memory. Perhaps a change in the underlying freebsd. Brendan Mannella wrote: What version of code are you using. I have two m7i's, each taking one full table. One runs 8.5 and the other 9.3 and there is a VERY big difference in memory usage. Brendan Mannella, CEO TeraSwitch Networks Inc. Office: 412.224.4333 x303 Mobile: 412.592.7848 Efax: 412.202.7094 On Feb 4, 2010, at 11:43 AM, TCIS List Acct wrote: We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with taking full routes (we are at 55% memory usage right now). With all of the comments on this topic, should we be worried? Our units push ~200Mbit traffic, so they are nowhere near capacity CPU wise. I can confirm your worry about the RE-850. We had one box with a full Internet table (~310K prefixes) *and* a reasonable number of L3VPNs with a total of ~160K prefixes, *and* a high number of interfaces. This box needed enough RE memory that we started seeing swap usage. Not good. Now the box has a reduced Internet table, and is happy. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.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] Need suggestions..
Hello, I've got one M7i (RE-400 & 768MB Ram) running JunOS 9.6R2 and dealing with more than 900,000 prefixes. Memory utilisation is at %92. I've been monitoring it for more than 4 months and I've never had any troubles. Regards, Vladislav --Original Message-- From: TCIS List Acct Sender: juniper-nsp-boun...@puck.nether.net To: NSP Juniper Subject: Re: [j-nsp] Need suggestions.. Sent: 4 Feb 2010 16:26 We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with taking full routes (we are at 55% memory usage right now). With all of the comments on this topic, should we be worried? Our units push ~200Mbit traffic, so they are nowhere near capacity CPU wise. > I can confirm your worry about the RE-850. > > We had one box with a full Internet table (~310K prefixes) *and* a > reasonable number of L3VPNs with a total of ~160K prefixes, *and* a > high number of interfaces. This box needed enough RE memory that we > started seeing swap usage. Not good. > > Now the box has a reduced Internet table, and is happy. > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Sent using BlackBerry® from Orange ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
> Isn't the # of routes it can hold just a function of how much RAM the RE-'s > can > take? No. The RE only holds the RIB. The FIB is held in static (SRAM) memory in the CFEB (may be RLDRAM in the enchanced CFEB). Both are important, the CFEB is what performs the actual packet pushing. Having a box with many Gigs of RE memory won't help if you overflow the CFEB (or in general the PFE) memory. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
> We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with > taking full routes (we are at 55% memory usage right now). > > With all of the comments on this topic, should we be worried? What JunOS version are you running? This is an M7i with RE-400, a full Internet routing table, inet.0: 314795 destinations, 629302 routes (314784 active, 0 holddown, 19 hidden) a handfull of MPLS L3VPNs (around 3K routes here) and a few interfaces, running JunOS 9.5R3.7. Memory usage: Routing Engine status: Temperature 33 degrees C / 91 degrees F CPU temperature 30 degrees C / 86 degrees F DRAM 768 MB Memory utilization 94 percent Model RE-5.0 I'd say *any* RE-400 box with a full routing table and a recent JunOS version is reason for worry. We have been unpleasantly surprised a few times (boxes starting to show swap usage). > Our units push ~200Mbit traffic, so they are nowhere near capacity CPU wise. Packet forwarding is done in hardware on this platform, the CPU is not involved. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
All we use them for is IPv4 routing and BGP. Nothing else. Very few local routes also. Sounds like we'll need the RE-850 if we want to take more than our 2 full feeds though -- although others have said we may run out of CFEB RAM first? Excuse the newbie question, but what is the CFEB RAM used for -- we have one router with one full feed and the CFEB is at 42% RAM, another with two full feeds and the CFEB is at 42% also... Kevin Wormington wrote: We also have a few M7is with RE-400s and 768MB RAM and don't have any problems with a thousand or so logical interfaces and 2 full bgp feeds each (only 300+k routes in FIB, and full IPV6 tables). The memory usage is at 95% but they don't swap and I think I remember seeing somewhere that the memory usage reported is always high in later JunOS releases (these are at 9.6R1.3). I think where you run into problems is if you are using some of the advanced services - ie a bunch of MPLS L3VPNs, etc. If you are just routing IPV4/IPV6, dhcp relaying, BGP then I personally think they have quite a bit of life left in them. As far as I now, the CPU usage doesn't have anything to due with the amount of traffic that is transiting the router since it's done by the PFE hardware. Kevin -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
We also have a few M7is with RE-400s and 768MB RAM and don't have any problems with a thousand or so logical interfaces and 2 full bgp feeds each (only 300+k routes in FIB, and full IPV6 tables). The memory usage is at 95% but they don't swap and I think I remember seeing somewhere that the memory usage reported is always high in later JunOS releases (these are at 9.6R1.3). I think where you run into problems is if you are using some of the advanced services - ie a bunch of MPLS L3VPNs, etc. If you are just routing IPV4/IPV6, dhcp relaying, BGP then I personally think they have quite a bit of life left in them. As far as I now, the CPU usage doesn't have anything to due with the amount of traffic that is transiting the router since it's done by the PFE hardware. Kevin TCIS List Acct wrote: We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with taking full routes (we are at 55% memory usage right now). With all of the comments on this topic, should we be worried? Our units push ~200Mbit traffic, so they are nowhere near capacity CPU wise. I can confirm your worry about the RE-850. We had one box with a full Internet table (~310K prefixes) *and* a reasonable number of L3VPNs with a total of ~160K prefixes, *and* a high number of interfaces. This box needed enough RE memory that we started seeing swap usage. Not good. Now the box has a reduced Internet table, and is happy. 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] Need suggestions..
We are running 8.4 on a few, and 8.5 on the others. Brendan Mannella wrote: What version of code are you using. I have two m7i's, each taking one full table. One runs 8.5 and the other 9.3 and there is a VERY big difference in memory usage. Brendan Mannella, CEO TeraSwitch Networks Inc. Office: 412.224.4333 x303 Mobile: 412.592.7848 Efax: 412.202.7094 On Feb 4, 2010, at 11:43 AM, TCIS List Acct wrote: We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with taking full routes (we are at 55% memory usage right now). With all of the comments on this topic, should we be worried? Our units push ~200Mbit traffic, so they are nowhere near capacity CPU wise. I can confirm your worry about the RE-850. We had one box with a full Internet table (~310K prefixes) *and* a reasonable number of L3VPNs with a total of ~160K prefixes, *and* a high number of interfaces. This box needed enough RE memory that we started seeing swap usage. Not good. Now the box has a reduced Internet table, and is happy. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
What version of code are you using. I have two m7i's, each taking one full table. One runs 8.5 and the other 9.3 and there is a VERY big difference in memory usage. Brendan Mannella, CEO TeraSwitch Networks Inc. Office: 412.224.4333 x303 Mobile: 412.592.7848 Efax: 412.202.7094 On Feb 4, 2010, at 11:43 AM, TCIS List Acct wrote: We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with taking full routes (we are at 55% memory usage right now). With all of the comments on this topic, should we be worried? Our units push ~200Mbit traffic, so they are nowhere near capacity CPU wise. I can confirm your worry about the RE-850. We had one box with a full Internet table (~310K prefixes) *and* a reasonable number of L3VPNs with a total of ~160K prefixes, *and* a high number of interfaces. This box needed enough RE memory that we started seeing swap usage. Not good. Now the box has a reduced Internet table, and is happy. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.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] Need suggestions..
Isn't the # of routes it can hold just a function of how much RAM the RE-'s can take? sth...@nethelp.no wrote: Also, unless you get the enchanced CFEB, there's no hope of getting four full routing tables into an M7i/M10i. Agree on M7i/M10i getting a bit long in the tooth. We have many of them in production, and they are very solid boxes. But especially the RE-400 is clearly showing its age. Steinar Haug, Nethelp consulting, sth...@nethelp.no -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
I've seen several references to CFEB-E's in this thread -- we have a PN# 750-010463 in all of our M7i's -- is that the "enhanced" CFEB that folks are referring to? 陈江 wrote: Per FIB, CEFB-E is same as MX80's TRIO, either has 1M FIB for IPv4. Per RIB, Yes, MX80 will be more powerful than RE400 or RE850. -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
What is the anticipated price on the MX80? One of the reasons that the MX80 looks like it is going to be so popular is that it specifically addresses this problem by providing a much cheaper entry level platform, especially if you are able to get by with the fixed config version (4x XFP, 48x 10/100/1000 copper) rather than the MIC version. The list price difference between the above fixed config MX80 and a MX240 base (with non-redundant and non-upgraded fabric and RE) and the same interfaces in a full routing config is something like 3.6x. I expect there will probably be some backwards movement on the level of discounts Juniper will be willing to give on the new products, but it is pretty darn hard to change the overall picture when there is a 360% difference in price. IMHO wait for the MX80, it looks like it is going to be a real winner. -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
We have 4 M7i's with RE-400's and 768M RAM and have never had a problem with taking full routes (we are at 55% memory usage right now). With all of the comments on this topic, should we be worried? Our units push ~200Mbit traffic, so they are nowhere near capacity CPU wise. I can confirm your worry about the RE-850. We had one box with a full Internet table (~310K prefixes) *and* a reasonable number of L3VPNs with a total of ~160K prefixes, *and* a high number of interfaces. This box needed enough RE memory that we started seeing swap usage. Not good. Now the box has a reduced Internet table, and is happy. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
We are open to any gear, Juniper or otherwise (we have a mixed Cisco and Juniper environment now). We have a RE-400 w/768M RAM in all of our existing M7i's and have never had an issue with taking full routes. Should we be worried? Mark Tinka wrote: On Thursday 04 February 2010 03:32:17 pm sth...@nethelp.no wrote: Agree on M7i/M10i getting a bit long in the tooth. We have many of them in production, and they are very solid boxes. But especially the RE-400 is clearly showing its age. If the OP is in a hurry and isn't alternative-averse, you could take a look at Cisco's ASR1002. It fits this bill nicely (except that it doesn't run JUNOS, hehe). Cheers, Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Thu, Feb 04, 2010 at 09:09:33AM -0700, Chris Kawchuk wrote: > SRX650 would foot the Bill - High Memory (2G), 4 GE Ports, does all > the VLAN switching/tagging/fun stuff. > > Put it in packet-mode (JunOS 9.6+), add an Ethernet blade to the > chassis, and voila. Instant core router. SRX is still quite lacking in the reliability department. I'm trying to use an SRX210-POE for home use, just a couple uplinks (cable, dsl, t1) and some IPSEC tunnels, and it has been what can only be described as an epic failure so far. At this point I have to restart rpd every few hours to keep it from getting into a state where it times out the single BGP session on the box (passing 1 route in each direction) every 30-60 secs. And every time I do that, it has about a 25% chance of kicking dhcpd into a 100% cpu loop, where it just sits and spins inside a select loop like so: #0 0x20a77844 in select () from /usr/lib/libc.so.6 #1 0x209d144c in pselect () from /usr/lib/libc.so.6 #2 0x206fd928 in __evGetNext () from /usr/lib/libisc.so.2 #3 0x206fe09c in __evMainLoop () from /usr/lib/libisc.so.2 #4 0x00451b40 in dhcpd_loop () If it wasn't for the fact that the box was free, I'd have thrown it straight into the trash by now. I wouldn't recommend trying to run a production router on this platform to my worst enemy right now. -- 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
[j-nsp] ex series odd message on ether-options deactivation
We are running into some wonky issues with some servers interfaces linking to
an EX-3200-48. In our troubleshooting, I set an interface (ge-0/0/1) to
hard-set 1G/full-duplex (instead of the default autoneg). That didn't cause any
'issues' per se, but when I attempted to deactivate this section of the
configuration, I got some odd messages, and I ended up having to delete the
options instead of merely deactivating them.
Configuration portion in question-
=
[edit interfaces ge-0/0/1]
da...@nap-r13-san-2# show
description hyperv12-san-2-2;
ether-options {
no-auto-negotiation;
link-mode full-duplex;
speed {
1g;
}
}
The command-
da...@nap-r13-san-2# deactivate ether-options
The error-
da...@nap-r13-san-2# commit check
error: could not add object to patricia tree
error: failed to add object created in interface-range
error: copy of interface-range hierarchy failed
error: interface-ranges expansion failed
[edit]
Like I said, when I deleted this section everything was fine- but has anyone
else run into this? Figured I'd ask here prior to opening a ticket with JTAC.
Thanks,
Dan Farrell
Director of Network Operations
Applied Innovations Corp.
da...@appliedi.net
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Thu, Feb 04, 2010 at 09:03:28PM +0800, ?? wrote: > Per FIB, CEFB-E is same as MX80's TRIO, either has 1M FIB for IPv4. > > Per RIB, Yes, MX80 will be more powerful than RE400 or RE850. CFEB-E is the same as the current MX hardware (I-Chip), not the same as MX80's Trio. Not sure on the exact specs of the MX80 RE, I'm expecting something integrated and probably lower powered than the RE-2000, but it's hard to do worse than a 10 year old Celery 400MHz. :) -- 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
Re: [j-nsp] Need suggestions..
SRX650 would foot the Bill - High Memory (2G), 4 GE Ports, does all the VLAN switching/tagging/fun stuff. Put it in packet-mode (JunOS 9.6+), add an Ethernet blade to the chassis, and voila. Instant core router. ...and half the price of an ASR1002. =) - Chris. On 2010-02-04, at 2:29 AM, Mark Tinka wrote: > On Thursday 04 February 2010 03:32:17 pm sth...@nethelp.no > wrote: > >> Agree on M7i/M10i getting a bit long in the tooth. We >> have many of them in production, and they are very solid >> boxes. But especially the RE-400 is clearly showing its >> age. > > If the OP is in a hurry and isn't alternative-averse, you > could take a look at Cisco's ASR1002. It fits this bill > nicely (except that it doesn't run JUNOS, hehe). > > Cheers, > > Mark. > ___ > 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] Need suggestions..
On Thursday 04 February 2010 04:46:52 pm Pekka Savola wrote: > FWIW, OP may have meant 4 full tables in RIB+FIB, 4 in > RIB and 1 in FIB, or something else. I thought the > second. A more recent RE could do the trick, but it's a > different issue if that's the most sensible approach in > the grand scheme of things.. Concerns about the RE-850 abound. With the way JUNOS + the Internet routing table are growing, I'm worried. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Thu, Feb 04, 2010 at 12:41:31PM +0200, Pekka Savola wrote: > Well, I don't know about i's, but FWIW plain old M10 runs e.g. RE-600 > (2G memory etc.) just fine. I still have an M10 floating around (doing a chds3 termination for a handful of t1's, nothing special), and rest assured it can NOT reliably take a full table when running even vaguely modern code (9.4), even after we upgraded the DRAM on the FEB. After a few weeks it would start dropping routes it was trying to install to the PFE, occasionally blackholing traffic in the process, and requiring a reboot to fix. The only solution was to stop taking a full table. The only way this could possibly work is if you can get away with running some really old and unsupported code, from back in the day when JUNOS wasn't a giant buggy bloated pile of crap. Of course, they also aren't maintaining security fixes for the really old versions, so the next time something like the last batch of issues comes along you may be left out in the cold. I also have a huge pile of fwdd.core files from a J2300 running 9.3R4 (the last release of code for old J-series hw) from my attempts to use it as an IPSEC endpoint over the last couple weeks, which prove Juniper isn't even leaving you with a reliable/working "final image" before they pull the plug. IMHO it would be damn near suicidal to think you can get away with running an old EOL platform like the M10 in production and expect future code to work on it reliably, regardless of RE performance (and the p3 600MHz isn't really that much faster anyways :P). -- 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
Re: [j-nsp] Need suggestions..
On Thursday 04 February 2010 01:30:54 pm Richard A Steenbergen wrote: > The price of an MX240 chassis is quite a bit "off" from > where it should be, IMHO. That is to say, the difference > in price between an MX960 and an MX240 chassis is so > small that the total cost per unit of bandwidth goes to > complete and total hell if you aren't buying fully > loaded MX960s. Agree, same reason we can't seem to buy MX240's and instead go for MX480's, because every time we try to get an MX240, the MX480 is just within reach that buying an MX240 makes no sense. The only reason I would buy an MX240 is space constraints, but then again, the era of the MX80 is upon us. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Thursday 04 February 2010 03:32:17 pm sth...@nethelp.no wrote: > Agree on M7i/M10i getting a bit long in the tooth. We > have many of them in production, and they are very solid > boxes. But especially the RE-400 is clearly showing its > age. If the OP is in a hurry and isn't alternative-averse, you could take a look at Cisco's ASR1002. It fits this bill nicely (except that it doesn't run JUNOS, hehe). Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
Per FIB, CEFB-E is same as MX80's TRIO, either has 1M FIB for IPv4. Per RIB, Yes, MX80 will be more powerful than RE400 or RE850. On Thu, Feb 4, 2010 at 2:27 PM, Richard A Steenbergen wrote: > On Thu, Feb 04, 2010 at 12:01:18AM -0600, TCIS List Acct wrote: > > No, we are not spaced constrained. > > > > I forgot to mention we are looking to spend as little money as possible, > > and are OK with older gear :-) We've got 4 M7i's at the edge in > production > > now and could probably buy a few more to use for this, but the # of Gig-E > > interfaces in the M7i might constrain us eventually (will not be a > > throughput constraint at all). > > > > Maybe a M10i or even some of the J-series might work? These devices will > > be gateway devices for our distribution switches and not sit at the edge > of > > the network. They just need to be able to hold at least a full routing > > table (when I said 4 full tables before, that was the # of upstreams we > > take routes from, but I know we have only ~300K or so routes actually > > active in the router) > > Existing M7i/M10i boxes are pretty darn old, and IMHO are getting very > close to the end of their useful lifespans. Even with the new CFEB-E > boards (which bring I-chip capabilities and put the old ABC-chip design > out to pasture), RE-400 or even an upgraded RE-850 are not exactly > modern or stellar performers on the control-plane, especially given the > rate that JUNOS is bloating itself. For about the same price as a > redundant M10i with 4xGE you could wait and get an MX80 with 4x10GE and > 48x10/100/1000, and have a throughly modern platform which is FAR more > likely to still be useable in 2-5 years from now. Unless you're putting > this up against a $4k ebay special, you should really be far better off > buying an MX80 when they come out. > > -- > 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 > -- BR! James Chen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] m7i as pppoe bras
Hi Piotr, I would consider an ERX-310 or Redback SE-100 BRAS to go into PPPoE. Especially the Redback is affordable and easy to use. Kind regards, Frans. > From: Piotr Chytla > Date: Thu, 4 Feb 2010 12:33:48 +0100 > To: > Subject: [j-nsp] m7i as pppoe bras > > Hi, > > Experts I've question I need to use m7i with RE-850 as pppoe bras . > how many pppoe sessions I can put on re-850 ? also I need some special > PICs for that ? I've try to google for it but there are only examples > for ERX series. > > /pch > > -- > Dyslexia bug unpatched since 1977 ... > exploit has been leaked to the underground. > ___ > 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] m7i as pppoe bras
P.S. PPPoE is currently supported on M120 and M320 routers only. Regards, Vladi Sent using BlackBerry® from Orange -Original Message- From: vvasi...@vvasilev.net Date: Thu, 4 Feb 2010 12:26:32 To: Piotr Chytla; ; Subject: Re: [j-nsp] m7i as pppoe bras Hi Piotr, Subscriber access is not available on M7i. Regards, Vladi --Original Message-- From: Piotr Chytla Sender: juniper-nsp-boun...@puck.nether.net To: juniper-nsp@puck.nether.net Subject: [j-nsp] m7i as pppoe bras Sent: 4 Feb 2010 11:33 Hi, Experts I've question I need to use m7i with RE-850 as pppoe bras . how many pppoe sessions I can put on re-850 ? also I need some special PICs for that ? I've try to google for it but there are only examples for ERX series. /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Sent using BlackBerry® from Orange ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] m7i as pppoe bras
Hi Piotr, Subscriber access is not available on M7i. Regards, Vladi --Original Message-- From: Piotr Chytla Sender: juniper-nsp-boun...@puck.nether.net To: juniper-nsp@puck.nether.net Subject: [j-nsp] m7i as pppoe bras Sent: 4 Feb 2010 11:33 Hi, Experts I've question I need to use m7i with RE-850 as pppoe bras . how many pppoe sessions I can put on re-850 ? also I need some special PICs for that ? I've try to google for it but there are only examples for ERX series. /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Sent using BlackBerry® from Orange ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] m7i as pppoe bras
Hi, Experts I've question I need to use m7i with RE-850 as pppoe bras . how many pppoe sessions I can put on re-850 ? also I need some special PICs for that ? I've try to google for it but there are only examples for ERX series. /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QOS rewrite-rule and classifier on MX
Hello group,
I want to mark the packets on Juniper MX240 and to check on Cisco router how
the packets are received marked.
I use classifier and rewrite rules for this.
My understanding is that we can use classifier to mark packets on input
interface and rewrite-rule to remark packets as they leave the interface.
Also I want to find a good example of how can we forward packets on
different next-hop using Class based forwarding (I want to match by
source-class/destination class and to forward to different next-hop with
different IP precedence but i did not found any good examples until now.
My question is why I receive DSCP default packets when I ping from Logical
router to CIsco ME ?
I have the following setup on my lab:
n...@lab> show interfaces descriptions | match ME
ge-2/1/0upup Link To ME6524-GI1/29
ae0.4011upup Link to ME6524
n...@lab> show interfaces descriptions | match Jo
irb.111 upup Link to Logical-router-JOHN
Logical router John -interface ge-2/0/2.111 -- int irb.111 ---Real
router John --interface ae0.4011 Cisco ME6524
n...@lab> show ospf neighbor
Address Interface State ID Pri Dead
150.1.12.1 ae0.4011 Full 172.16.1.1 1 3
150.111.111.2irb.111Full 150.111.111.212838
n...@lab:John> show ospf neighbor
Address Interface State ID Pri Dead
150.111.111.1ge-2/0/2.111 Full 172.25.231.176 12839
n...@lab> show configuration class-of-service
classifiers {
inet-precedence JOHN {
forwarding-class best-effort {
loss-priority high code-points 000;
loss-priority low code-points [ 010 001 ];
}
forwarding-class assured-forwarding {
loss-priority low code-points 011;
loss-priority high code-points 100;
}
forwarding-class expedited-forwarding {
loss-priority high code-points 101;
}
forwarding-class network-control {
loss-priority high code-points 111;
loss-priority low code-points 110;
}
}
}
interfaces {
ge-*/*/* {
unit * {
classifiers {
inet-precedence JOHN;
}
rewrite-rules {
inet-precedence JOHN;
}
}
}
ae0 {
unit * {
classifiers {
inet-precedence JOHN;
}
rewrite-rules {
inet-precedence JOHN;
}
}
}
irb {
unit * {
classifiers {
inet-precedence JOHN;
}
rewrite-rules {
inet-precedence JOHN;
}
}
}
}
rewrite-rules {
inet-precedence JOHN {
forwarding-class best-effort {
loss-priority low code-point 001;
loss-priority high code-point 000;
}
forwarding-class assured-forwarding {
loss-priority low code-point 011;
loss-priority high code-point 100;
}
forwarding-class expedited-forwarding {
loss-priority low code-point 101;
loss-priority high code-point 101;
}
forwarding-class network-control {
loss-priority low code-point 110;
loss-priority high code-point 111;
}
}
}
ME6524-Laborator#show ip ospf neighbor vlan 4011
Neighbor ID Pri State Dead Time Address Interface
172.25.231.176 128 FULL/BDR00:00:03150.1.12.2 Vlan4011
E6524-Laborator#show running-config interface gi1/29
Building configuration...
Current configuration : 284 bytes
!
interface GigabitEthernet1/29
description link to Juniper-port 1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 4011,4013
switchport mode trunk
mtu 9216
no ip address
mls qos vlan-based
channel-protocol lacp
channel-group 1 mode active
end
ME6524-Laborator#show running-config interface vlan 4011
Building configuration...
Current configuration : 214 bytes
!
interface Vlan4011
mtu 9000
ip address 150.1.12.1 255.255.255.0
ip ospf hello-interval 1
ip ospf mtu-ignore
tag-switching ip
bfd interval 500 min_rx 500 multiplier 3
service-policy input FROM_JUNIPER
end
class-map match-any EF
match ip precedence 5
match dscp ef
match mpls experimental topmost 5
class-map match-any BE
match dscp default
match ip precedence 0
match mpls experimental topmost 0
When I ping from logical-router to ME6524 the traffic is matched by
policy-map FROM_JUNIPER as DSCP default like you can see:
ME6524-Laborator#show policy-map int vlan 4011
Vlan4011
Service-policy input: FROM_JUNIPER
Class-map: EF (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: ip precedence 5
0 packets, 0 bytes
5 minu
Re: [j-nsp] Need suggestions..
> > Not for the M7i/M10i. > > > > We have explicitly asked Juniper about a beefier RE for M7i/M10i, and > > the answer so far has been "no plans". > > Well, I don't know about i's, but FWIW plain old M10 runs e.g. RE-600 > (2G memory etc.) just fine. Sure. But the M10 is EoS while the M7i/M10i is not. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Thu, 4 Feb 2010, sth...@nethelp.no wrote: Not for the M7i/M10i. We have explicitly asked Juniper about a beefier RE for M7i/M10i, and the answer so far has been "no plans". Well, I don't know about i's, but FWIW plain old M10 runs e.g. RE-600 (2G memory etc.) just fine. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
> > Concerns about the RE-850 abound. > > > > With the way JUNOS + the Internet routing table are growing, > > I'm worried. > > I would be worried as well, but there are also REs with more memory > and processing power that work fine AFAICT on older gear. Not for the M7i/M10i. We have explicitly asked Juniper about a beefier RE for M7i/M10i, and the answer so far has been "no plans". Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
> > FWIW, OP may have meant 4 full tables in RIB+FIB, 4 in > > RIB and 1 in FIB, or something else. I thought the > > second. A more recent RE could do the trick, but it's a > > different issue if that's the most sensible approach in > > the grand scheme of things.. > > Concerns about the RE-850 abound. > > With the way JUNOS + the Internet routing table are growing, > I'm worried. I can confirm your worry about the RE-850. We had one box with a full Internet table (~310K prefixes) *and* a reasonable number of L3VPNs with a total of ~160K prefixes, *and* a high number of interfaces. This box needed enough RE memory that we started seeing swap usage. Not good. Now the box has a reduced Internet table, and is happy. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need suggestions..
On Thu, 4 Feb 2010, Mark Tinka wrote: On Thursday 04 February 2010 04:46:52 pm Pekka Savola wrote: FWIW, OP may have meant 4 full tables in RIB+FIB, 4 in RIB and 1 in FIB, or something else. I thought the second. A more recent RE could do the trick, but it's a different issue if that's the most sensible approach in the grand scheme of things.. Concerns about the RE-850 abound. With the way JUNOS + the Internet routing table are growing, I'm worried. I would be worried as well, but there are also REs with more memory and processing power that work fine AFAICT on older gear. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 routing issue
What software version do you use? I've seen routing troubles with
software prior to 9.6R2/9.5R3
Cyrill
On 03.02.2010 23:50, Stacy W. Smith wrote:
It sounds like the forwarding table may not be in sync with the routing table
during this time. You can check the Routing Engine's view of the forwarding
table with:
show route forwarding-table destination 10.10.134.0 extensive
That output may help you determine if it's the Routing Engine or the PFE that
has an incorrect forwarding entry.
--Stacy
On Feb 3, 2010, at 12:53 PM, Cord MacLeod wrote:
I have a very strange routing issue in progress. The short of it is, I am advertising
10.10.134.0/24 from gsw1.xxx with BGP, which is an ex4200 6 member switch. I advertise
this to crs1.xxx which is an ex4200 2 member switch and a route reflector. When one of
the crs1.xxx member switches dies, all routing dies as expected. However when routing
re-establishes for some reason 10.10.134.0/24 is no longer reachable even though a route
exists for this network in BGP through out the whole network. crs1.xxx even claims
"no route to host" even when showing a route in it's routing table.
When the 2nd member of crs1.xxx comes back online, everything is fixed.
Obviously this is a major issue because I now essentially have no redundancy at
my aggregation layer, crs1.xxx.
Here's normal operation:
r...@crs1.xxx> show virtual-chassis
Virtual Chassis ID: 0026.8868.4080
MastershipNeighbor List
Member ID Status Serial NoModelpriorityRole ID Interface
0 (FPC 0) PrsntBM0x0 ex4200-24t 200 Master*1 vcp-0
1 (FPC 1) PrsntBM0x2 ex4200-24t 200 Backup 0 vcp-1
r...@crs1.xxx> show virtual-chassis
r...@crs1.xxx> show route 10.10.134.0
inet.0: 20 destinations, 21 routes (20 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
10.10.134.0/24 *[BGP/170] 00:20:46, localpref 100, from 10.10.135.47
AS path: I
to 10.10.135.58 via ge-1/0/23.0
to 10.10.135.62 via ge-0/0/23.0
r...@crs1.xxx> show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table Tot Paths Act Paths SuppressedHistory Damp StatePending
inet.0 4 4 0 0 0 0
Peer AS InPkt OutPktOutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
10.10.135.13 11XXX 27 29 0 0 10:53
1/1/1/0 0/0/0/0
10.10.135.14 11XXX 26 29 0 0 10:47
1/1/1/0 0/0/0/0
10.10.135.47 11XXX 28 28 0 0 10:56
2/2/2/0 0/0/0/0
r...@crs1.xxx> ping 10.10.134.1
PING 10.10.134.1 (10.10.134.1): 56 data bytes
64 bytes from 10.10.134.1: icmp_seq=0 ttl=64 time=1.324 ms
64 bytes from 10.10.134.1: icmp_seq=1 ttl=64 time=1.570 ms
64 bytes from 10.10.134.1: icmp_seq=2 ttl=64 time=1.285 ms
64 bytes from 10.10.134.1: icmp_seq=3 ttl=64 time=1.297 ms
Here's abnormal operation:
Virtual Chassis ID: 0026.8868.4080
MastershipNeighbor List
Member ID Status Serial NoModelpriorityRole ID Interface
0 (FPC 0) PrsntBM0x0 ex4200-24t 200 Master*
1 (FPC 1) NotPrsnt BM0x2 ex4200-24t
r...@crs1.xxx> show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table Tot Paths Act Paths SuppressedHistory Damp StatePending
inet.0 4 4 0 0 0 0
Peer AS InPkt OutPktOutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
10.10.135.13 11XXX 3 5 0 0 8
1/1/1/0 0/0/0/0
10.10.135.14 11XXX 2 5 0 0 2
1/1/1/0 0/0/0/0
10.10.135.47 11XXX 4 3 0 0 11
2/2/2/0 0/0/0/0
r...@crs1.xxx> show route 10.10.134.0
inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
10.10.134.0/24 *[BGP/170] 00:03:35, localpref 100, from 10.10.135.47
AS path: I
to 10.10.135.62 via ge-0/0/23.0
{master:0}
r...@crs1.xxx> ping 10.10.134.1
PING 10.10.134.1 (10.10.134.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list
Re: [j-nsp] Need suggestions..
On Thu, 4 Feb 2010, sth...@nethelp.no wrote: Existing M7i/M10i boxes are pretty darn old, and IMHO are getting very close to the end of their useful lifespans. Even with the new CFEB-E boards (which bring I-chip capabilities and put the old ABC-chip design out to pasture), RE-400 or even an upgraded RE-850 are not exactly modern or stellar performers on the control-plane, especially given the rate that JUNOS is bloating itself. Also, unless you get the enchanced CFEB, there's no hope of getting four full routing tables into an M7i/M10i. FWIW, OP may have meant 4 full tables in RIB+FIB, 4 in RIB and 1 in FIB, or something else. I thought the second. A more recent RE could do the trick, but it's a different issue if that's the most sensible approach in the grand scheme of things.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
