Re: [j-nsp] SRX100 for dual 100M uplink routing network in packet mode.
Thx, i am mostly disappointed in their implementation of nat/ipsec require flow processing, it's totally unnecessary! i hate session tables too! Although i heard horrible things about boot time on lower level srx devices, it claims to need 5 minutes to boot up. how is yours ?I'm mostly interested in boot time under 10.4 (jtac recommend version) On Tue, Nov 27, 2012 at 11:08 PM, Michel de Nostredame d.nos...@gmail.com wrote: On Tue, Nov 27, 2012 at 2:52 PM, 叶雨飞 sunyuc...@gmail.com wrote: Hi, I currently have 2 100mbps uplink (about 50% bandwidth utilization, 10kpps each), I am hoping to get a srx100 as the router, run it in packet mode for most traffic except some low traffic nat/ipsec management tunnels. Is that going to be enough? or should I aim for srx210 or higher? From the SPEC, SRX100 can runs Firewall+Routing at 64 Byte-Packet to 70Kpps. It should able to move your 10Kpps x 2 = 20Kpps traffics around with no problem in packet-mode. However, if NAT/IPsec are also needed, you will have to run the box in flow-mode or selective-packet-mode for certain packets in flow-mode and others in packet-mode. Not sure if SRX100 can keeps the performance when doing things in selective-packet-mode, but consider it is implemented by using ACL (stateless firewall filter) on the inbound interfaces. Things sound worth a try. LAB testing or POC won't hurt, right? If you do able to perform some POC, please share the result to list :) PS: I just got a SRX100 and am going to do some POC with selective-packet-mode. Basically I want to route my traffic into GRE tunnel in packet-mode and route GRE packet over IPsec to remote SSG site in flow-mode because IPsec needs flow module. Hopefully this can suppress my session-table usage to only one for two records. I hate flow-mode JUNOS for a long long long time since J-series, but the SRX prices are simply irresistible. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX100 for dual 100M uplink routing network in packet mode.
11.4 actually, sorry! On Tue, Nov 27, 2012 at 11:56 PM, 叶雨飞 sunyuc...@gmail.com wrote: Thx, i am mostly disappointed in their implementation of nat/ipsec require flow processing, it's totally unnecessary! i hate session tables too! Although i heard horrible things about boot time on lower level srx devices, it claims to need 5 minutes to boot up. how is yours ?I'm mostly interested in boot time under 10.4 (jtac recommend version) On Tue, Nov 27, 2012 at 11:08 PM, Michel de Nostredame d.nos...@gmail.com wrote: On Tue, Nov 27, 2012 at 2:52 PM, 叶雨飞 sunyuc...@gmail.com wrote: Hi, I currently have 2 100mbps uplink (about 50% bandwidth utilization, 10kpps each), I am hoping to get a srx100 as the router, run it in packet mode for most traffic except some low traffic nat/ipsec management tunnels. Is that going to be enough? or should I aim for srx210 or higher? From the SPEC, SRX100 can runs Firewall+Routing at 64 Byte-Packet to 70Kpps. It should able to move your 10Kpps x 2 = 20Kpps traffics around with no problem in packet-mode. However, if NAT/IPsec are also needed, you will have to run the box in flow-mode or selective-packet-mode for certain packets in flow-mode and others in packet-mode. Not sure if SRX100 can keeps the performance when doing things in selective-packet-mode, but consider it is implemented by using ACL (stateless firewall filter) on the inbound interfaces. Things sound worth a try. LAB testing or POC won't hurt, right? If you do able to perform some POC, please share the result to list :) PS: I just got a SRX100 and am going to do some POC with selective-packet-mode. Basically I want to route my traffic into GRE tunnel in packet-mode and route GRE packet over IPsec to remote SSG site in flow-mode because IPsec needs flow module. Hopefully this can suppress my session-table usage to only one for two records. I hate flow-mode JUNOS for a long long long time since J-series, but the SRX prices are simply irresistible. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LAG on Ex4200 fiber + copper
As far as I know and according to all Juniper docs you can only use optical pic ports and of course the dedicated vc port for this eg. https://www.juniper.net/techpubs//en_US/junos/topics/example/virtual-chassis-ex4200-link-aggregation-over-extended-vcps.html Regards, Darius On Wed, Nov 28, 2012 at 10:28 AM, Riccardo S dim0...@hotmail.com wrote: On ex-4200-24T is it possible to create a LAG using a 1 Gb up-link fiber port + a 1 Gb copper port ? Any juniper.net reference about that ? Tks ___ 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] SRX100 for dual 100M uplink routing network in packet mode.
On Tuesday 27 November 2012 23:08:04 Michel de Nostredame wrote: PS: I just got a SRX100 and am going to do some POC with selective-packet-mode. Basically I want to route my traffic into GRE tunnel in packet-mode and route GRE packet over IPsec to remote SSG site in flow-mode because IPsec needs flow module. Hopefully this can suppress my session-table usage to only one for two records. I hate flow-mode JUNOS for a long long long time since J-series, but the SRX prices are simply irresistible. Michel, We wanted to do that with some SRX650s. Doesn't work. Sorry. Seems like some flag is on the packet saying it's packet-mode, which isn't removed/reset when it's wrapped in a GRE header, so IPSec sees a packet-mode packet and drops it. This was with 10.4R6.5, we didn't get the chance to try anything newer. -- Mike Williams ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX100 for dual 100M uplink routing network in packet mode.
On 28/11/12 11:24, Mike Williams wrote: On Tuesday 27 November 2012 23:08:04 Michel de Nostredame wrote: PS: I just got a SRX100 and am going to do some POC with selective-packet-mode. Basically I want to route my traffic into GRE tunnel in packet-mode and route GRE packet over IPsec to remote SSG site in flow-mode because IPsec needs flow module. Hopefully this can suppress my session-table usage to only one for two records. I hate flow-mode JUNOS for a long long long time since J-series, but the SRX prices are simply irresistible. Michel, We wanted to do that with some SRX650s. Doesn't work. Sorry. Seems like some flag is on the packet saying it's packet-mode, which isn't removed/reset when it's wrapped in a GRE header, so IPSec sees a packet-mode packet and drops it. This was with 10.4R6.5, we didn't get the chance to try anything newer. Have you seen this: http://www.juniper.net/us/en/local/pdf/app-notes/3500192-en.pdf I have successfully used an SRX 210 in packet mode and flow mode, to do MPLS-over-GRE-over-IPSEC. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX100 for dual 100M uplink routing network in packetmode.
Hi Mike, I must disagree here, although I never verified it myself a Juniper Engineer I know did show me some in production configurations showing MPLS over GRE over IPSec on a single branch router (I think J not SRX) so it is possible. This was on 10.3R1.9. You must use the lt-0/0/0 interface to send the GRE packets into a separate virtual router for encryption/transport over IPSec as this clears the packet-mode flag. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mike Williams Sent: Wednesday, 28 November 2012 10:25 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX100 for dual 100M uplink routing network in packetmode. On Tuesday 27 November 2012 23:08:04 Michel de Nostredame wrote: PS: I just got a SRX100 and am going to do some POC with selective-packet-mode. Basically I want to route my traffic into GRE tunnel in packet-mode and route GRE packet over IPsec to remote SSG site in flow-mode because IPsec needs flow module. Hopefully this can suppress my session-table usage to only one for two records. I hate flow-mode JUNOS for a long long long time since J-series, but the SRX prices are simply irresistible. Michel, We wanted to do that with some SRX650s. Doesn't work. Sorry. Seems like some flag is on the packet saying it's packet-mode, which isn't removed/reset when it's wrapped in a GRE header, so IPSec sees a packet-mode packet and drops it. This was with 10.4R6.5, we didn't get the chance to try anything newer. -- Mike Williams ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] utilization based policer changes?
I'm interested in possibly using junoscript to adjust policing based on a utilization ceiling. Example, let's say that I've got 2Gb/sec of bandwidth that I can use. At busy times, it's appropriate to police users at 7Mb, but if I'm only using around 70% of that 2Gb, adjust policing up to something like 10Mb/sec. I already have policers established, just looking for a sane way to do this. I'd want to take a sample for the previous 15minutes. Given the need to use average stats, I assume that I probably just need to do triggers from a monitoring host. Any suggestions on the path to follow for this? I know junos has various hooks, but until now I haven't pursued using them. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX100 for dual 100M uplink routing network in packet mode.
Our experience with performance-limited branch SRX systems lately has made us use the 1/3-rule. If you don't use more than 1/3 of the rated max of any one metric the box will perform well and have some headroom for fluctuations. Going above that, our boxes fill the logs with warnings that the FPC is working over 85% capacity all the time (all the way up to 99%, 100% is apparently not possible :-). We mainly have experience with SRX240H, where 100 Mbit/s IPsec VPN is OK (rated max 300), and 500 Mbit/s fire walled/routed throughput is ok (1500 Mbit/s rated). /Per 28 nov 2012 kl. 08:08 skrev Michel de Nostredame: On Tue, Nov 27, 2012 at 2:52 PM, 叶雨飞 sunyuc...@gmail.com wrote: Hi, I currently have 2 100mbps uplink (about 50% bandwidth utilization, 10kpps each), I am hoping to get a srx100 as the router, run it in packet mode for most traffic except some low traffic nat/ipsec management tunnels. Is that going to be enough? or should I aim for srx210 or higher? From the SPEC, SRX100 can runs Firewall+Routing at 64 Byte-Packet to 70Kpps. It should able to move your 10Kpps x 2 = 20Kpps traffics around with no problem in packet-mode. However, if NAT/IPsec are also needed, you will have to run the box in flow-mode or selective-packet-mode for certain packets in flow-mode and others in packet-mode. Not sure if SRX100 can keeps the performance when doing things in selective-packet-mode, but consider it is implemented by using ACL (stateless firewall filter) on the inbound interfaces. Things sound worth a try. LAB testing or POC won't hurt, right? If you do able to perform some POC, please share the result to list :) PS: I just got a SRX100 and am going to do some POC with selective-packet-mode. Basically I want to route my traffic into GRE tunnel in packet-mode and route GRE packet over IPsec to remote SSG site in flow-mode because IPsec needs flow module. Hopefully this can suppress my session-table usage to only one for two records. I hate flow-mode JUNOS for a long long long time since J-series, but the SRX prices are simply irresistible. -- Michel~ ___ 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] Detecting OSPF packet drops
When I do a commit on an somewhat buxy MX80, I see Nov 27 21:14:10.443024 OSPF dropped 172 received packets due to flow blockage as long as I have set ospf traceoptions flag error. Without traceoptions, the error is not logged. Now, JTAC is telling me that I cannot run with any traceoptions on that box in production. That leaves me completely in the dark when it comes to dropped OSPF packets, and I will have no way of knowing if the packet drops hit a level where I risk losing neighbors. Is there anything I can do to monitor those drops, without using traceoptions? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Detecting OSPF packet drops
When I do a commit on an somewhat buxy MX80, I see Nov 27 21:14:10.443024 OSPF dropped 172 received packets due to flow blockage as long as I have set ospf traceoptions flag error. Without traceoptions, the error is not logged. Now, JTAC is telling me that I cannot run with any traceoptions on that box in production. That leaves me completely in the dark when it comes to dropped OSPF packets, and I will have no way of knowing if the packet drops hit a level where I risk losing neighbors. Is there anything I can do to monitor those drops, without using traceoptions? Probably not. The MX80 has a significantly underpowered RE CPU. Bad enough that we have basically stopped buying MX80s, mostly for that reason alone. 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] SRX100 for dual 100M uplink routing network in packet mode.
On Wed, Nov 28, 2012 at 12:09 AM, 叶雨飞 sunyuc...@gmail.com wrote: 11.4 actually, sorry! On Tue, Nov 27, 2012 at 11:56 PM, 叶雨飞 sunyuc...@gmail.com wrote: Thx, i am mostly disappointed in their implementation of nat/ipsec require flow processing, it's totally unnecessary! i hate session tables too! Although i heard horrible things about boot time on lower level srx devices, it claims to need 5 minutes to boot up. how is yours ?I'm mostly interested in boot time under 10.4 (jtac recommend version) Although I have some other SRX devices as firewall in production environment, but I actually have no chance to frequently reboot them that I have no real feeling about bootup time. During lunch, I had a little time to play with this SRX100 and upgraded it to 11.4 R5.5. It took like forever to bootup, compares to SSG5 (ScreenOS 6.3). It took 3 mins 10+ secs to be able to display login prompt on serial console (but actually not able to login at this moment). And another 1 min few secs to bring up interfaces (the interface started to blink, and able to login at this moment.) There is only my account, interface ip, default route, and permit all from trust to untrust zone rule inside the box... not sure how long it will take to bootup if I put many rules/policies in config. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] DHCP interface as next hop
Hey all, I haven't found an answer to this question (except for Cisco options which doesn't help me). I want to configure a static route to a DHCP interface on an SRX240. Here's the scenario: ge-0/0/0 connected to CX111 (4G modem/DHCP) t1-0/1/0 connected to an L3VPN (with BGP) st0.0 should connect over ge-0/0/0 The t1 is considered trusted, so we do not want to form the IPSec tunnel over it. There is a default route coming in via BGP on the T1. The goal: Statically route the IPSec tunnel endpoint over the 4G modem as a /32 Statically route 0/0 over st0.0 (and set precedence to 170, or set BGP down to 4) Receive 0/0 from BGP over the T1 (or alternately not, with no need to alter precedence, and use two next-hops for one static 0/0) The purpose is to have the tunnel up but not used until the T1 or BGP over it goes away. However, I cannot set ge-0/0/0.0 as the next-hop because it's not a point to point interface. I cannot set an IP address as the next-hop because I don't know when it will change. Any ideas on how to address that? Thanks! Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Detecting OSPF packet drops
On (2012-11-28 22:30 +0100), sth...@nethelp.no wrote: Probably not. The MX80 has a significantly underpowered RE CPU. Bad enough that we have basically stopped buying MX80s, mostly for that reason alone. I'm quite worried if we are able to use MX80 long time enough due to the RE, so I can fully understand your decision. RSP720 is lower spec pq3 than MX80 yet it runs circles around MX80 in terms of convergence and scale. In fact when I heard about MX80, I wasn't worried about RE performance at all, top-of-the-line pq3, faster than RSP720, should suffice no problems, how naive I was. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Detecting OSPF packet drops
I run a few MX80's but doing very basic BGP with full tables, some minor OSPF, nothing major. Where exactly are you guys running into restrictions with regards to the RE? Thanks, Morgan On Wed, Nov 28, 2012 at 3:02 PM, Saku Ytti s...@ytti.fi wrote: On (2012-11-28 22:30 +0100), sth...@nethelp.no wrote: Probably not. The MX80 has a significantly underpowered RE CPU. Bad enough that we have basically stopped buying MX80s, mostly for that reason alone. I'm quite worried if we are able to use MX80 long time enough due to the RE, so I can fully understand your decision. RSP720 is lower spec pq3 than MX80 yet it runs circles around MX80 in terms of convergence and scale. In fact when I heard about MX80, I wasn't worried about RE performance at all, top-of-the-line pq3, faster than RSP720, should suffice no problems, how naive I was. -- ++ytti ___ 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] Detecting OSPF packet drops
On (2012-11-28 15:08 -0700), Morgan McLean wrote: I run a few MX80's but doing very basic BGP with full tables, some minor OSPF, nothing major. Where exactly are you guys running into restrictions with regards to the RE? Just generally slow to converge BGP, long commit times with occasional rpd slips. Compared to Intel boxes, it's just unexpectedly slow. But maybe JNPR will make RPD SMP safe and enable second core :) -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] rib-group requirement for master rib
Hi All,
I have a requirement for performing Filter-based Forwarding on traffic that is
ingressing via a routing-instance (instance-type virtual-router):
show routing-options:
interface-routes {
rib-group inet FBF-PBR;
}
rib-groups {
FBF-PBR {
import-rib [ CUSTOMER-A.inet.0 FBF-PBR.inet.0 ];
}
}
Problem I have is that I can't seem to commit without including inet.0 in the
rib-group:
root@srx240-lab# commit check
[edit routing-options interface-routes]
'rib-group'
FBF-PBR: primary rib for instance master was not found in ribgroup
configuration.
error: configuration check-out failed
Putting inet.0 in the rib-group isn't desirable, as it exposes direct routes
into the RI which I'm trying to hide in the first place. is there a
better/different way to be doing this?
Cheers,
Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX5-error while booting.
Hi, My new MX5 died today. If I try to boot it up, it stuck at following message. U-Boot 1.1.6 (Jun 10 2011 - 00:50:30) CPU: 8572, Version: 2.1, (0x80e00021) Core0: E500, Version: 3.0, (0x80210030) Clock Configuration: CPU0:1333 MHz,CPU1:1333 MHz, CCB: 533 MHz, DDR: 267 MHz (533 MT/s data rate) (Synchronous), LBC: 33 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: MX5-T 1.8 CPLD: Version 0x1f DRAM: Initializing - DDR: 2048 MB Testing DRAM from 0x to 0x8000 DRAM test phase 1: DRAM test fails at: 7ff63e24 hang at function = 0xfffbe504 ### ERROR ### Please RESET the board ### Any suggestions? Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] rib-group requirement for master rib
Configure interface-routes at the [edit routing-instances CUSTOMER-A
routing-options] hierarchy rather than the [edit routing-options] hierarchy.
Continue to define rib-groups at the [edit routing-options] hierarchy.
[edit]
root@srx210# show routing-options
rib-groups {
FBF-PBR {
import-rib [ CUSTOMER-A.inet.0 FBF-PBR.inet.0 ];
}
}
[edit]
root@srx210# show routing-instances
CUSTOMER-A {
instance-type virtual-router;
routing-options {
interface-routes {
rib-group inet FBF-PBR;
}
}
}
[edit]
root@srx210# commit check
configuration check succeeds
--Stacy
On Nov 28, 2012, at 5:39 PM, Ben Dale bd...@comlinx.com.au wrote:
Hi All,
I have a requirement for performing Filter-based Forwarding on traffic that
is ingressing via a routing-instance (instance-type virtual-router):
show routing-options:
interface-routes {
rib-group inet FBF-PBR;
}
rib-groups {
FBF-PBR {
import-rib [ CUSTOMER-A.inet.0 FBF-PBR.inet.0 ];
}
}
Problem I have is that I can't seem to commit without including inet.0 in the
rib-group:
root@srx240-lab# commit check
[edit routing-options interface-routes]
'rib-group'
FBF-PBR: primary rib for instance master was not found in ribgroup
configuration.
error: configuration check-out failed
Putting inet.0 in the rib-group isn't desirable, as it exposes direct routes
into the RI which I'm trying to hide in the first place. is there a
better/different way to be doing this?
Cheers,
Ben
___
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] rib-group requirement for master rib
Perfect - thanks Stacy
On 29/11/2012, at 12:00 PM, Stacy W. Smith st...@acm.org wrote:
Configure interface-routes at the [edit routing-instances CUSTOMER-A
routing-options] hierarchy rather than the [edit routing-options] hierarchy.
Continue to define rib-groups at the [edit routing-options] hierarchy.
[edit]
root@srx210# show routing-options
rib-groups {
FBF-PBR {
import-rib [ CUSTOMER-A.inet.0 FBF-PBR.inet.0 ];
}
}
[edit]
root@srx210# show routing-instances
CUSTOMER-A {
instance-type virtual-router;
routing-options {
interface-routes {
rib-group inet FBF-PBR;
}
}
}
[edit]
root@srx210# commit check
configuration check succeeds
--Stacy
On Nov 28, 2012, at 5:39 PM, Ben Dale bd...@comlinx.com.au wrote:
Hi All,
I have a requirement for performing Filter-based Forwarding on traffic that
is ingressing via a routing-instance (instance-type virtual-router):
show routing-options:
interface-routes {
rib-group inet FBF-PBR;
}
rib-groups {
FBF-PBR {
import-rib [ CUSTOMER-A.inet.0 FBF-PBR.inet.0 ];
}
}
Problem I have is that I can't seem to commit without including inet.0 in
the rib-group:
root@srx240-lab# commit check
[edit routing-options interface-routes]
'rib-group'
FBF-PBR: primary rib for instance master was not found in ribgroup
configuration.
error: configuration check-out failed
Putting inet.0 in the rib-group isn't desirable, as it exposes direct routes
into the RI which I'm trying to hide in the first place. is there a
better/different way to be doing this?
Cheers,
Ben
___
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] MX5-error while booting.
Here are some more errors if it helps tunefs: soft updates remains unchanged as disabled Creating initial configuration...Interface control process: /usr/libexec/ld-elf.so.1: Shared object libcrypto.so.3 not found, required by cgatool umass0: at uhub0 port 3 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device g_vfs_done():da0s1a[WRITE(offset=8192, length=2048)]error = 6 umass0: detached umass1: at uhub0 port 2 (addr 3) disconnected (da1:umass-sim1:1:0:0): lost device g_vfs_done():da1s1f[WRITE(offset=8192, length=2048)]error = 6 mgd: warning: panic: vinvalbuf: dirty bufs Uptime: 1m29s (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0 (da1:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0 Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM On Thu, Nov 29, 2012 at 12:21 PM, Ali Sumsam ali+juniper...@eintellego.netwrote: Hi, My new MX5 died today. If I try to boot it up, it stuck at following message. U-Boot 1.1.6 (Jun 10 2011 - 00:50:30) CPU: 8572, Version: 2.1, (0x80e00021) Core0: E500, Version: 3.0, (0x80210030) Clock Configuration: CPU0:1333 MHz,CPU1:1333 MHz, CCB: 533 MHz, DDR: 267 MHz (533 MT/s data rate) (Synchronous), LBC: 33 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: MX5-T 1.8 CPLD: Version 0x1f DRAM: Initializing - DDR: 2048 MB Testing DRAM from 0x to 0x8000 DRAM test phase 1: DRAM test fails at: 7ff63e24 hang at function = 0xfffbe504 ### ERROR ### Please RESET the board ### Any suggestions? Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-error while booting.
it says DRAM test fails, my guess is you need to replace memory. On Wed, Nov 28, 2012 at 8:57 PM, Ali Sumsam ali+juniper...@eintellego.net wrote: Here are some more errors if it helps tunefs: soft updates remains unchanged as disabled Creating initial configuration...Interface control process: /usr/libexec/ld-elf.so.1: Shared object libcrypto.so.3 not found, required by cgatool umass0: at uhub0 port 3 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device g_vfs_done():da0s1a[WRITE(offset=8192, length=2048)]error = 6 umass0: detached umass1: at uhub0 port 2 (addr 3) disconnected (da1:umass-sim1:1:0:0): lost device g_vfs_done():da1s1f[WRITE(offset=8192, length=2048)]error = 6 mgd: warning: panic: vinvalbuf: dirty bufs Uptime: 1m29s (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0 (da1:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0 Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM On Thu, Nov 29, 2012 at 12:21 PM, Ali Sumsam ali+juniper...@eintellego.netwrote: Hi, My new MX5 died today. If I try to boot it up, it stuck at following message. U-Boot 1.1.6 (Jun 10 2011 - 00:50:30) CPU: 8572, Version: 2.1, (0x80e00021) Core0: E500, Version: 3.0, (0x80210030) Clock Configuration: CPU0:1333 MHz,CPU1:1333 MHz, CCB: 533 MHz, DDR: 267 MHz (533 MT/s data rate) (Synchronous), LBC: 33 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: MX5-T 1.8 CPLD: Version 0x1f DRAM: Initializing - DDR: 2048 MB Testing DRAM from 0x to 0x8000 DRAM test phase 1: DRAM test fails at: 7ff63e24 hang at function = 0xfffbe504 ### ERROR ### Please RESET the board ### Any suggestions? Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ 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] MX5-error while booting.
I'd try to use install-media to get everything back to factory defaults. Have you tried this yet? With best regards, Vitaly Vlasenko On 29.11.2012, at 12:04, 叶雨飞 sunyuc...@gmail.com wrote: it says DRAM test fails, my guess is you need to replace memory. On Wed, Nov 28, 2012 at 8:57 PM, Ali Sumsam ali+juniper...@eintellego.net wrote: Here are some more errors if it helps tunefs: soft updates remains unchanged as disabled Creating initial configuration...Interface control process: /usr/libexec/ld-elf.so.1: Shared object libcrypto.so.3 not found, required by cgatool umass0: at uhub0 port 3 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device g_vfs_done():da0s1a[WRITE(offset=8192, length=2048)]error = 6 umass0: detached umass1: at uhub0 port 2 (addr 3) disconnected (da1:umass-sim1:1:0:0): lost device g_vfs_done():da1s1f[WRITE(offset=8192, length=2048)]error = 6 mgd: warning: panic: vinvalbuf: dirty bufs Uptime: 1m29s (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0 (da1:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0 Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM On Thu, Nov 29, 2012 at 12:21 PM, Ali Sumsam ali+juniper...@eintellego.netwrote: Hi, My new MX5 died today. If I try to boot it up, it stuck at following message. U-Boot 1.1.6 (Jun 10 2011 - 00:50:30) CPU: 8572, Version: 2.1, (0x80e00021) Core0: E500, Version: 3.0, (0x80210030) Clock Configuration: CPU0:1333 MHz,CPU1:1333 MHz, CCB: 533 MHz, DDR: 267 MHz (533 MT/s data rate) (Synchronous), LBC: 33 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: MX5-T 1.8 CPLD: Version 0x1f DRAM: Initializing - DDR: 2048 MB Testing DRAM from 0x to 0x8000 DRAM test phase 1: DRAM test fails at: 7ff63e24 hang at function = 0xfffbe504 ### ERROR ### Please RESET the board ### Any suggestions? Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ 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] MX5-error while booting.
DRAM: Initializing - DDR: 2048 MB Testing DRAM from 0x to 0x8000 DRAM test phase 1: DRAM test fails at: 7ff63e24 hang at function = 0xfffbe504 ### ERROR ### Please RESET the board ### Any suggestions? Yep - its broke. RMA? DOA? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] M120 : Arp broadcast messages causes irradic behaviour
Hello Gentlemen, Problem faced: When a large broadcast generated by the downstream network(1,00,000Pkts per sec) hits the Juniper gigE interface it causes the node to behave erratically, not allowing remote login, LSPs flap, until the port is shut down. I understand that a default arp policer is applied on the interface. What is the value of this policer? And whether its a good idea to modify this policer? Thanks in advance. Sunil Mayenkar ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DHCP interface as next hop
However, I cannot set ge-0/0/0.0 as the next-hop because it's not a point to point interface. I cannot set an IP address as the next-hop because I don't know when it will change. Any ideas on how to address that? Missing functionality in JunOS. Complain to your SE. Other vendors can do this. (Also available in JunOSe, for the E-series.) I can understand the choice of not including this functionality. Juniper can avoid the well known of problem of pointing a default route at an Ethernet interface, leading to an ARP for every new/unknown destination. However, in my opinion Juniper *should* still offer this functionality, leaving the user with plenty of rope to hang himself :-) 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] M120 : Arp broadcast messages causes irradic behaviour
On 11/28/12 10:56 PM, Sunil Mayenkar wrote: Hello Gentlemen, Problem faced: When a large broadcast generated by the downstream network(1,00,000Pkts per sec) hits the Juniper gigE interface it causes the node to behave erratically, not allowing remote login, LSPs flap, until the port is shut down. I understand that a default arp policer is applied on the interface. What is the value of this policer? And whether its a good idea to modify this policer? The policer is global and iirc varies by platform and release, you can police arp storms to lower per interface limits than the global limits which does reduce the likelyhood of the box becoming unusable. I recall having to experiment in order to get it right. Thanks in advance. Sunil Mayenkar ___ 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
