Re: [j-nsp] TASK_OS_MEMHIGH on ex2200
On Mon, Jan 2, 2012 at 11:44 PM, Maciej Jan Broniarz wrote: > Today my switch started dropping traffic and in logs it says: > > Jan 3 05:30:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of > memory, 100 percent of available > Jan 3 05:31:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of > memory, 100 percent of available > Jan 3 05:32:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of > memory, 100 percent of available It looks like vccpd has leaked a lot of memory. You may drop to the shell and kill off vccpd, hoping that the switch returns to a working condition momentarily, rather than freaking out and requiring a reboot. Personally, if I were you, I would just reboot it anyway. If you expect multi-year trouble-free uptimes from your switches you made a bad purchase with the EX-series, and I say that as someone who does advocate using them for certain things. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IPSEC tunnel
Hi, I have an IPSEC tunnel between an Juniper SRX (policy based) running 10.4R6.5 and a Cisco ASA 5510, the SA's are established but about once per 24h hours (but can also work for days) the tunnel stops forwarding traffic, the SA's are still established. has anyone seen this behavior before? The solution is to take the tunnel down and establish it again. Regards Johan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] TASK_OS_MEMHIGH on ex2200
Hi, I am running ex2200-48t-4g with 10.4R1.9 - it was fine for 350 days. Today my switch started dropping traffic and in logs it says: Jan 3 05:30:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of memory, 100 percent of available Jan 3 05:31:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of memory, 100 percent of available Jan 3 05:32:49 ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of memory, 100 percent of available It helped to disable port mirroring but i wonder what might be the issue here. All best, mjb ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
You can do this with a properly constructed XPath expression... I will look at this later in the lab Sent from Yahoo! Mail on Android ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Derick Winkworth writes: > Just do it sequentially and then write an op script that takes the > vlan(s) as an argument to show you the interface info you are looking > for... I am looking at this option, but it seems that there is no Junoscript command to get all objects with elements matching a specific pattern. More specifically, I can't even ask for "all interfaces which have vlan-id=1010". Can this really be true? Obviously I can just ask for all interfaces and loop. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 cluster - ethernet switching issue
Hi John, > > My issue is that I have 2 trunk links on each firewall passing completely > different VLAN's but when I enable any form of spanning tree, I'm seeing one > of those links blocked (3 out of the 4 links get blocked by STP). I've tried > rstp, stp and mstp - all with the same issue. This is expected behaviour. Neither RSTP nor STP are VLAN-aware, so they simply see a topology containing 3 bridges (SRX, EX, EX-VC) in a loop and block the port "furtherest" from the root bridge. A simple fix would be VSTP (per-VLAN Spanning-Tree), but the SRX platform didn't support it last time I checked. You can use MSTP can solve this issue by allowing multiple forwarding topologies, but it will require specific configuration all three devices - if you simply enable it with defaults, it will behave exactly the same way as RSTP. Plenty of info on the specifics of MSTP can be found here: http://www.juniper.net/techpubs/en_US/junos9.4/topics/example/spanning-trees-ex-series-mstp-configuring.html http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/8010065-001-EN.pdf Good luck! Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos terminal programm
And for MX80 with a ppc this doesn't work. root@cr1% sh ./auxport-terminal x - extracting /bin/tip x - extracting /tip-manifest (text) x - extracting /tip-manifest.certs (text) x - extracting /tip-manifest.sig (text) x - removed lock directory `_sh05839'. Verified tip-manifest signed by PackageDevelopment_7_6_0 Starting tip... Press ~ then ctrl-D to quit. /bin/tip: 1: Syntax error: "(" unexpected Anyone got it to work? -P On Mon, Oct 15, 2007 at 5:10 AM, Mr. James W. Laferriere wrote: > Hello Yevgeniy , If (as it seems you do) have shell access try , > > cd /usr/lib > ln -s /packages/mnt/jbase/usr/lib/libc.so.6 /usr/lib/libc.so.4 > > And give that a try . > Hth , JimL > > ps: No warrenties , ... > > On Sun, 14 Oct 2007, Richard A Steenbergen wrote: >> On Sun, Oct 14, 2007 at 10:37:17PM +0400, Yevgeniy Voloshin wrote: >>> Dear Richard, >>> >>> what I am do wrong? >> ... >>> JUNOS Base OS boot [8.5B2.2] >> ... >>> /usr/libexec/ld-elf.so.1: Shared object "libc.so.4" not found, required by >>> "tip" >> >> There are major FreeBSD changes between JUNOS 8.4 and 8.5, which came with >> a libc upgrade obviously. :P >> >> --- JUNOS 8.5B2.5 built 2007-09-07 01:02:08 UTC >> root@lab% ls -la /usr/lib/libc* >> lrwxr-xr-x 1 root wheel 37 Sep 30 00:56 /usr/lib/libc.so.6 -> >> /packages/mnt/jbase/usr/lib/libc.so.6 >> >> Thats a pretty major upgrade (libc from FreeBSD 4 -> 6), so you've pretty >> much got zero chance of binary compatibility between versions. Just nag >> Juniper to include tip, that'd be a much more sensible solution. :) >> >> > > -- > +-+ > | James W. Laferriere | System Techniques | Give me VMS | > | Network Engineer | 663 Beaumont Blvd | Give me Linux | > | bab...@baby-dragons.com | Pacifica, CA. 94044 | only on AXP | > +-+ > ___ > 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] Join my network on LinkedIn
LinkedIn Maurice Gil Cruz ha solicitado añadirte como contacto en LinkedIn: -- I'd like to add you to my professional network on LinkedIn. Aceptar invitación de Maurice Gil Cruz http://www.linkedin.com/e/u96119-gwxa5210-p/XqZSB0oknt5cTYQCxwU5LkoQzUifoQRJSaUSlk19WH/blk/I1965887415_3/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPnPkNd3sUe3kSej59bSFdjjhmhScPbPkNcPgMej0TcPkLrCBxbOYWrSlI/EML_comm_afe/?hs=false&tok=1uXqS3uYlh5R41 Ver invitación de Maurice Gil Cruz http://www.linkedin.com/e/u96119-gwxa5210-p/XqZSB0oknt5cTYQCxwU5LkoQzUifoQRJSaUSlk19WH/blk/I1965887415_3/3dvdj4QdPwUdjoVckALqnpPbOYWrSlI/svi/?hs=false&tok=2s9Bpepc1h5R41 -- ¿Por qué puede ser una buena idea conectar con Maurice Gil Cruz? Los contactos de Maurice Gil Cruz podrían serte útiles: Tras aceptar la invitación de Maurice Gil Cruz, revisa los contactos de Maurice Gil Cruz para ver a quién más conoces y a quién te gustaría que te presentaran. Forjar contactos puede crear oportunidades futuras. -- (c) 2011, LinkedIn Corporation ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS fast convergence without link information
Hi Thanks for help everybody. One further question: do you have recommendations of tools to perform network convergence testing? I.e. generally available sw that is capable of measuring network outage times in the order of magnitude of milliseconds? I have traditionally used linux and fping, something like fping -l -p 10 -i 10 -t 10 to get the low-precision measurement of outage in 10 milliseconds. Does this make sense to you? On Thu, Dec 29, 2011 at 9:36 PM, Phil Mayers wrote: > On 12/29/2011 06:48 PM, Mark Smith wrote: > >> I would not expect the L2 service provider to be able to tunnel >> ethernet OAM (CCM etc) traffic. > > > In general, or in this specific case? In general at this point. By building your stuff on the assumption that your "subcontractor" or partner is able to do something "specific" not mentioned in contract you increase the risk of extra problems and/or work in case something goes wrong or changes. For example let's assume you lease L2 lines and notice that OAM traffic is passed fine. You test and build your network to rely on this functionality. After some time your L2 provider experiences hardware failure and they decide to replace the failed component with different model, config, sw version etc. As a result OAM traffic is not forwarded anymore and you need to do changes to your configuration. The provider does not tell you anything, because your service (L2 line) is restored. Another example might be that you need to change L2 provider to different one and again they don't forward OAM. I have seen things like this happen on several occasions and I would like to avoid them if possible. Also remember the murphy's law: if (and when) anything goes wrong, it will happen on the worst possible moment. I.e. in the middle of midsummer night when you (and your capable colleagues) are 5 ‰ drunk ;/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp