just try : conf t slot erase x or: slot accept x where x is the slot number of your DPFE the root cause is that you had inserted an OC3 Line Card before, so the box kept this information of this slot. you need to tell the box that this slot had been changed to a new type of Line Card. issue " sh hard", you can confirm of this.
----- Original Message ----- From: "Bryan Phillips" <[EMAIL PROTECTED]> To: "Dr Rocco DiSanto" <[EMAIL PROTECTED]>; <[email protected]> Sent: Wednesday, April 30, 2008 3:38 AM Subject: Re: [j-nsp] Clearing corrupt ERX 1400 Line Card OS image > > 1. What ver of JUNOSe are you running? > 2. If you have dual SRP's, have you tried a SRP switch? > 3. backup .scr config, revert the ERX to factory default, reload a fresh > copy or upgraded copy of JUNOSe, then load the backup.scr - config from > file > > Not sure if this will fix it, but we have had some weird issues on our > ERX's with 7.3.x code. We have had to do some of this. We do not have > any FastE cards. > > Bryan > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dr Rocco > DiSanto > Sent: Friday, March 14, 2008 9:15 AM > To: [email protected] > Subject: [j-nsp] Clearing corrupt ERX 1400 Line Card OS image > > Hi all, > > Would anyone be able to advise me on how I might go about clearing a > corrupt > image load on an ERX line card? I have a DPFE (duel port fast eth) card > in > failed mode. > > Watching it boot through its diag port it appears that the hardware > passes > all tests. It begins to load the image for fast eth but as the boot > continues begins to load the image for an OC3 line card, eventually just > going to a failed status. I am interested in figuring out if we can > flush > the OS load and have the card pull the proper fast Eth load from the > SRP/NVRAM. > > Any advice would be much appreciated. > > Rocco > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, March 13, 2008 10:47 AM > To: [email protected] > Subject: juniper-nsp Digest, Vol 64, Issue 15 > > Send juniper-nsp mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://puck.nether.net/mailman/listinfo/juniper-nsp > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of juniper-nsp digest..." > > > Today's Topics: > > 1. Re: One router/two firewalls config question (Mark Tinka) > 2. Re: One router/two firewalls config question (Jesper Skriver) > 3. Re: One router/two firewalls config question (Mark Tinka) > 4. Re: One router/two firewalls config question (Amos Rosenboim) > 5. Re: One router/two firewalls config question (Mark Tinka) > 6. OC48 to dual Gig question ([EMAIL PROTECTED]) > 7. (no subject) (sunnyday) > 8. Nagios plugin to check Juniper hardware (Michiel Timmers) > 9. MX Series and SFP-GE-T (William Jackson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 13 Mar 2008 00:14:14 +0800 > From: Mark Tinka <[EMAIL PROTECTED]> > Subject: Re: [j-nsp] One router/two firewalls config question > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > On Tuesday 11 March 2008, Chuck Anderson wrote: > >> Any my switch has multiple switch fabrics, multiple CPUs, >> multiple fan trays, and multiple power supplies :-) > > I've found it's easier to justify this on edge and border > routers, where the box-level redundancy depends on the > connectivity density required and where multiple links > would be aggregated into one chassis without the need to > multi-home them. > > Of course, box-level redundancy goes without saying for core > routers. > > However, for core switches in a specific site/PoP, I've > always wondered whether having redundant switch fabrics and > CPU's was necessary, especially if those switch fabrics and > CPU's don't contribute to the forwarding of traffic unless > the primary switch fabric has failed. > > Since all connections to the core switches are mirrored to > the corresponding routers, the failure of one switch would > be mitigated by the presence of another, with a similar > hardware/software configuration. > > On paper, core switches this redundant make sense. In > practice, however, given the "reliability" of today's > platforms, having this in a mirrored state seems more like > just a nice-to-have. > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 832 bytes > Desc: This is a digitally signed message part. > Url : > https://puck.nether.net/pipermail/juniper-nsp/attachments/20080313/acd9d > 862/ > attachment-0001.bin > > ------------------------------ > > Message: 2 > Date: Wed, 12 Mar 2008 17:37:48 +0100 > From: Jesper Skriver <[EMAIL PROTECTED]> > Subject: Re: [j-nsp] One router/two firewalls config question > To: Mark Tinka <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > On Thu, Mar 13, 2008 at 12:14:14AM +0800, Mark Tinka wrote: >> On Tuesday 11 March 2008, Chuck Anderson wrote: >> >> > Any my switch has multiple switch fabrics, multiple CPUs, >> > multiple fan trays, and multiple power supplies :-) >> >> I've found it's easier to justify this on edge and border >> routers, where the box-level redundancy depends on the >> connectivity density required and where multiple links >> would be aggregated into one chassis without the need to >> multi-home them. >> >> Of course, box-level redundancy goes without saying for core >> routers. > > I'd say exactly the opposite, it's trivial to build a core network > with redundancy, so it doesn't depend on any single box or link. > But on the edge a given customer is typically connected to one > box, when that box goes down, the customer looses connectivity, so > on edge boxes you need redundant boxes much more than in the core. > > /Jesper > >> However, for core switches in a specific site/PoP, I've >> always wondered whether having redundant switch fabrics and >> CPU's was necessary, especially if those switch fabrics and >> CPU's don't contribute to the forwarding of traffic unless >> the primary switch fabric has failed. >> >> Since all connections to the core switches are mirrored to >> the corresponding routers, the failure of one switch would >> be mitigated by the presence of another, with a similar >> hardware/software configuration. >> >> On paper, core switches this redundant make sense. In >> practice, however, given the "reliability" of today's >> platforms, having this in a mirrored state seems more like >> just a nice-to-have. >> >> Mark. > > > >> _______________________________________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > https://puck.nether.net/pipermail/juniper-nsp/attachments/20080312/2b309 > 2dc/ > attachment-0001.bin > > ------------------------------ > > Message: 3 > Date: Thu, 13 Mar 2008 01:15:21 +0800 > From: Mark Tinka <[EMAIL PROTECTED]> > Subject: Re: [j-nsp] One router/two firewalls config question > To: Jesper Skriver <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > On Thursday 13 March 2008, Jesper Skriver wrote: > >> I'd say exactly the opposite, it's trivial to build a >> core network with redundancy, so it doesn't depend on any >> single box or link. But on the edge a given customer is >> typically connected to one box, when that box goes down, >> the customer looses connectivity, so on edge boxes you >> need redundant boxes much more than in the core. > > This is why I mentioned the exception being in a multi-homed > situation. > > But given a case where most customers will single-home to an > ISP, it would seem harder to justify having several more > boxes than necessary. However, if a customer is dual-homed > to you, sure, that justifies itself no problem. > > A network may have multiple edge routers and provision > customers onto them in a round-robin fashion to mitigate > impact in case one of them fails, but that single-homed > customer still loses his connection to the ISP if his edge > router was the one that died. > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 832 bytes > Desc: This is a digitally signed message part. > Url : > https://puck.nether.net/pipermail/juniper-nsp/attachments/20080313/9e0a0 > 8e3/ > attachment-0001.bin > > ------------------------------ > > Message: 4 > Date: Wed, 12 Mar 2008 19:32:41 +0200 > From: Amos Rosenboim <[EMAIL PROTECTED]> > Subject: Re: [j-nsp] One router/two firewalls config question > To: juniper-nsp <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > Quote: > > A network may have multiple edge routers and provision > customers onto them in a round-robin fashion to mitigate > impact in case one of them fails, but that single-homed > customer still loses his connection to the ISP if his edge > router was the one that died. > > End of quote. > > The exception to that is when the customer access circuit is Ethernet > based (and we see more and more of this). > In such situation what we do is put a layer 2 switch to connect > customer circuits, and connect two edge routers to this switch. > Then we either configure the customer with two bgp sessions (one for > each router) or do vrrp between the edge routers and ask the customer > to point his 0.0.0.0/0 to the virtual address. > > You can argue that the layer 2 switch is a single point of failure, > and it is. > However, since it's a much simpler device it's less prone to SW > failures and human mistakes. > Also it allows us flexibility in performing maintenance on the edge > routers. > > The last point is that the new EX switches are the only fixed > configuration switches I know that comes with dual power supplies and > field replaceable fans. > > Regards > > Amos > > > > > > ------------------------------ > > Message: 5 > Date: Thu, 13 Mar 2008 02:31:55 +0800 > From: Mark Tinka <[EMAIL PROTECTED]> > Subject: Re: [j-nsp] One router/two firewalls config question > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > On Thursday 13 March 2008, Amos Rosenboim wrote: > >> The exception to that is when the customer access circuit >> is Ethernet based (and we see more and more of this). >> In such situation what we do is put a layer 2 switch to >> connect customer circuits, and connect two edge routers >> to this switch. Then we either configure the customer >> with two bgp sessions (one for each router) or do vrrp >> between the edge routers and ask the customer to point >> his 0.0.0.0/0 to the virtual address. > > Right - this achieves Layer 3 redundancy, but not Layer 1 or > 2. That notwithstanding, yes, it's better than nothing. > > Terminations not-of-an-Ethernet-persuasion are, however, > left in a quagmire for single-homed customers. > >> The last point is that the new EX switches are the only >> fixed configuration switches I know that comes with dual >> power supplies and field replaceable fans. > > C also have switches that support field-replaceable fan > trays as well as RPS (DC). > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 832 bytes > Desc: This is a digitally signed message part. > Url : > https://puck.nether.net/pipermail/juniper-nsp/attachments/20080313/e32b4 > 92f/ > attachment-0001.bin > > ------------------------------ > > Message: 6 > Date: Thu, 13 Mar 2008 09:01:55 +0100 > From: [EMAIL PROTECTED] > Subject: [j-nsp] OC48 to dual Gig question > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > Hi ! > > I'm new to Juniper and we are trying here to setup a M20 to switch > traffic between an OC48 interface to an aggregate of 2 Ethernet Gig > interfaces . > > So far, we managed to setup the M20 to do OC48 to 1 Gig Interface > with the following config : > ------------------------------------------------------------------------ > ---- > -------- > interfaces { > ge-0/0/0 { > description "The Gig Interface side A"; > encapsulation ethernet-tcc; > unit 0 { > family tcc { > proxy { > inet-address 192.168.0.1; > } > remote { > inet-address 192.168.0.2; > } > } > } > } > so-3/0/0 { > enable; > description "The OC48 Interface side B"; > encapsulation ppp-tcc; > sonet-options { > fcs 32; > } > unit 0; > } > > protocols { > mpls { > interface ge-0/0/0.0; > interface se-3/0/0.0; > } > connections { > interface-switch Gig-To-OC48 { > interface ge-0/0/0.0; > interface so-3/0/0.0; > } > } > } > ------------------------------------------------------------------------ > ---- > -------- > > This config is working perfectly but is limited to 1Gb/s, as we have > 4 Gig interfaces on this box, we would like to aggregate 2 (or 3) Gig > Interfaces. > I have tryed with ae0 interface, but this kind of interface does not > seems to support ethernet-tcc encapsulation (only ccc seems supported) > > Any idea if this is even possible, if yes any help is welcome . > > Best regards, > > Salim > > > > ------------------------------ > > Message: 7 > Date: Thu, 13 Mar 2008 13:48:21 +0200 > From: "sunnyday" <[EMAIL PROTECTED]> > Subject: [j-nsp] (no subject) > To: "Juniper-Nsp" <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > hello > i have configured a lag interface > and assigned a qos profile > > when the show egress-queue rates interface command is issued > the output is this > > > ip lag .1 best-effort 0 0 250000000 > tc-xxxxx 4183208 0 12288000 > > should best-effort appear at the output? > is it possible to remove it? > > > > > > Mihalis Mihailidis > Network Engineer > > Kestrel Information Systems S.A. > 340 Kifisias Ave, Neo Psychico > 154 51 Athens, Greece > Phone: +30 210 6747740 ext: 106 > Mobile: +30 693 6807 512 > Email: [EMAIL PROTECTED] > > > ------------------------------ > > Message: 8 > Date: Thu, 13 Mar 2008 09:41:37 -0400 > From: "Michiel Timmers" <[EMAIL PROTECTED]> > Subject: [j-nsp] Nagios plugin to check Juniper hardware > To: <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > > I post this here because I think that there are a lot of Nagios users on > this list that might find the following useful. > > I have enriched a Nagios plugin to check all sorts of Juniper hardware > (Routing Engine, Fans, PSU...etc) using SNMP. > The plugin is the based on the 'check_snmp_env' script from Patrick Proy > (http://nagios.manubulon.com/) with the addition to check hardware > components for Juniper equipment. > > Here are some example outputs of a Juniper M5 router: > #./check_snmp_environment.pl -H <ip> -C <snmp> -T juniper > (Routing Engine PCMCIA Card 0): status Unknown, : 14/15 components OK : > UNKNOWN > > #./check_snmp_environment.pl -H <ip> -C <snmp> -T juniper > (Power Supply B): status Down, : 14/15 components OK : CRITICAL > > See the following site for more details and download: > http://www.nagiosexchange.org/Networking.53.0.html?&tx_netnagext_pi1[p_v > iew] > =1269 > > Please post your comments.. > > Michiel > > > > > ------------------------------ > > Message: 9 > Date: Thu, 13 Mar 2008 16:46:54 +0100 > From: "William Jackson" <[EMAIL PROTECTED]> > Subject: [j-nsp] MX Series and SFP-GE-T > To: <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Does the MX Series support Copper 1000 BaseT SFP's? > > > > thanks > > > > ------------------------------ > > _______________________________________________ > juniper-nsp mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > > End of juniper-nsp Digest, Vol 64, Issue 15 > ******************************************* > > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
