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/acd9d862/ 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/2b3092dc/ 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/9e0a08e3/ 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/e32b492f/ 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_view] =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
