[j-nsp] Clearing corrupt ERX 1400 Line Card OS image
H. Zhang
zh73 at 163.com
Wed Apr 30 12:51:15 EDT 2008
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" <bryan.phillips at cybera.net>
To: "Dr Rocco DiSanto" <drdisanto at directus.net>;
<juniper-nsp at puck.nether.net>
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: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Dr Rocco
> DiSanto
> Sent: Friday, March 14, 2008 9:15 AM
> To: juniper-nsp at puck.nether.net
> 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: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
> juniper-nsp-request at puck.nether.net
> Sent: Thursday, March 13, 2008 10:47 AM
> To: juniper-nsp at puck.nether.net
> Subject: juniper-nsp Digest, Vol 64, Issue 15
>
> Send juniper-nsp mailing list submissions to
> juniper-nsp at puck.nether.net
>
> 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
> juniper-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
> juniper-nsp-owner at puck.nether.net
>
> 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 (salimlist at sdv.fr)
> 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 <mtinka at globaltransit.net>
> Subject: Re: [j-nsp] One router/two firewalls config question
> To: juniper-nsp at puck.nether.net
> Message-ID: <200803130014.14870.mtinka at globaltransit.net>
> 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 <jesper at skriver.dk>
> Subject: Re: [j-nsp] One router/two firewalls config question
> To: Mark Tinka <mtinka at globaltransit.net>
> Cc: juniper-nsp at puck.nether.net
> Message-ID: <20080312163748.GA19183 at skriver.dk>
> 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 juniper-nsp at puck.nether.net
>> 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 <mtinka at globaltransit.net>
> Subject: Re: [j-nsp] One router/two firewalls config question
> To: Jesper Skriver <jesper at skriver.dk>
> Cc: juniper-nsp at puck.nether.net
> Message-ID: <200803130115.21680.mtinka at globaltransit.net>
> 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 <amos at oasis-tech.net>
> Subject: Re: [j-nsp] One router/two firewalls config question
> To: juniper-nsp <juniper-nsp at puck.nether.net>
> Message-ID: <2E011715-5EAC-4272-B3B8-799D804F6ECC at oasis-tech.net>
> 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 <mtinka at globaltransit.net>
> Subject: Re: [j-nsp] One router/two firewalls config question
> To: juniper-nsp at puck.nether.net
> Message-ID: <200803130232.00248.mtinka at globaltransit.net>
> 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: salimlist at sdv.fr
> Subject: [j-nsp] OC48 to dual Gig question
> To: juniper-nsp at puck.nether.net
> Message-ID: <7.0.0.16.2.20080313084953.04678190 at sdv.fr>
> 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" <cscosunny at gmail.com>
> Subject: [j-nsp] (no subject)
> To: "Juniper-Nsp" <juniper-nsp at puck.nether.net>
> Message-ID: <000f01c88500$24f947f0$9b1ea8c0 at mixalis>
> 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: m.mihailidis at kestrel-is.gr
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 13 Mar 2008 09:41:37 -0400
> From: "Michiel Timmers" <michiel.timmers at gmx.net>
> Subject: [j-nsp] Nagios plugin to check Juniper hardware
> To: <juniper-nsp at puck.nether.net>
> Message-ID: <001701c88510$05d5ae80$7c00a8c0 at michiel>
> 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" <wjackson at sapphire.gi>
> Subject: [j-nsp] MX Series and SFP-GE-T
> To: <juniper-nsp at puck.nether.net>
> Message-ID:
> <9D30659ABCA7FB428CF91E386C3A5744CF96C0 at hermes.sapphire-int.gi>
> Content-Type: text/plain; charset="us-ascii"
>
> Does the MX Series support Copper 1000 BaseT SFP's?
>
>
>
> thanks
>
>
>
> ------------------------------
>
> _______________________________________________
> juniper-nsp mailing list
> juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> End of juniper-nsp Digest, Vol 64, Issue 15
> *******************************************
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list