[j-nsp] Clearing corrupt ERX 1400 Line Card OS image
Bryan Phillips
bryan.phillips at cybera.net
Tue Apr 29 15:38:10 EDT 2008
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
More information about the juniper-nsp
mailing list