Re: [j-nsp] Could you pls clarify a bit about OAM for link fault management?
Hi Victor, Something like this should do the trick once you've configured it on both ends: set protocols oam ethernet link-fault-management action-profile UDLD event link-adjacency-loss set protocols oam ethernet link-fault-management action-profile UDLD action syslog set protocols oam ethernet link-fault-management action-profile UDLD action link-down set protocols oam ethernet link-fault-management interface ge-0/0/23.0 apply-action-profile UDLD We had a similar issue to solve at some sites connected via Free-Space Optics units. Cheers, Ben On 11 Jul 2014, at 12:45 pm, Victor Sudakov v...@mpeks.tomsk.su wrote: Colleagues, I have pairs of EX4200 switches connected via third party MUXes. When the actual physical medium goes down, the MUXes do not shutdown their Ethernet interfaces. So I need some sort of point-to-point L2 link fault management between the EX4200s. I thought OAM could be used for this purpose. However after reading http://www.juniper.net/techpubs/en_US/junos9.4/topics/task/configuration/lfm-ethernet-oam-configuring-ex-series-cli.html and references therein I am a bit confused. I don't need those remote-loopback and allow-remote-loopback features, profiles and other complicated stuff, do I? All I need from OAM is some kind of L2 keepalive. Do you have a good configuration example? Thanks a lot for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] QinQ interface configuration question
I have never used such a configuration but I can't understand from look at this how it would possible work? Having the same inner and outer tag means there is no way to differentiate between the incoming frames. How did you imagine that would work? Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP Prefrence Query
Hi, Abhijeet, That is preference2 aka secondary preference. With best regards, Vladimir Blazhkun. On Mon, Jul 7, 2014 at 4:47 PM, Abhi vyaaghrah-...@yahoo.com wrote: i have a doubt about rsvp preference in Junos. The preference value is associated with /1 or /2 what these value denote? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384
Hi, after further investigation, i saw that another log message immediately before the first occurence of the rtslib message: /kernel: %KERN-5: Process (1299,chassisd) has exceeded 85% of RLIMIT_DATA: used 124472 KB Max 131072 KB And since yesterday evening, i see these messages on additional 2 routers (also M10i with same JUNOS installed). Regards, Alex Am 11.07.2014 06:18, schrieb Morgan McLean: Other KB articles with similar failed to allocate block errors point to memory related issues and recommend restarting the routing engine. Any log messages that came up right before the failed to allocate message? Thanks, Morgan On Thu, Jul 10, 2014 at 1:53 PM, Alex D. listensamm...@gmx.de mailto:listensamm...@gmx.de wrote: Hi, since yesterday, i see the following syslog messages from several M10i running JUNOS 10.4R8.5: chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384 This message occurs in irregular intervals and doesn't result in routing issues. Does anybody know what it means ? Regards, Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net mailto: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] juniper-nsp Digest, Vol 140, Issue 8
Hi Alex, Are you using CFEB on this node? You might want to look at this PR for details, fixed in 10.4R10. https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR718652 Chassisd leaks 4KB memory roughly every 33 minutes on M7i or M10i using cfeb namely Internet Processor II, Enhanced CFEB is NOT affected; No specific trigger is needed: Due to software bug, CFEB sends the CHASSIS_MSG_SCB status periodically, Chassisd goes and allocates 12 bytes of memory and comes out without freeing - amouting to a leak of 3.96KB every 33 minutes.Offline/online FRU will also call this function thus aggravate Chassisd mem leak. Thank You, Siva Date: Thu, 10 Jul 2014 22:53:03 +0200 From: Alex D. listensamm...@gmx.de To: juniper-nsp@puck.nether.net Subject: [j-nsp] chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384 Message-ID: 53befd2f.3020...@gmx.de Content-Type: text/plain; charset=ISO-8859-15; format=flowed Hi, since yesterday, i see the following syslog messages from several M10i running JUNOS 10.4R8.5: chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384 This message occurs in irregular intervals and doesn't result in routing issues. Does anybody know what it means ? Regards, Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384
Hi Alex, Are you using CFEB on this node? You might want to look at this PR for details, fixed in 10.4R10. https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR718652 Chassisd leaks 4KB memory roughly every 33 minutes on M7i or M10i using cfeb namely Internet Processor II, Enhanced CFEB is NOT affected; No specific trigger is needed: Due to software bug, CFEB sends the CHASSIS_MSG_SCB status periodically, Chassisd goes and allocates 12 bytes of memory and comes out without freeing - amouting to a leak of 3.96KB every 33 minutes.Offline/online FRU will also call this function thus aggravate Chassisd mem leak. Thank You, Siva Date: Thu, 10 Jul 2014 22:53:03 +0200 From: Alex D. listensamm...@gmx.de To: juniper-nsp@puck.nether.net Subject: [j-nsp] chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384 Message-ID: 53befd2f.3020...@gmx.de Content-Type: text/plain; charset=ISO-8859-15; format=flowed Hi, since yesterday, i see the following syslog messages from several M10i running JUNOS 10.4R8.5: chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384 This message occurs in irregular intervals and doesn't result in routing issues. Does anybody know what it means ? Regards, Alex -- Thanks, Subramania Siva Madhu Mob: +91-9840453317 Nothing is wrong until you are caught ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper ex9200
Hi guys, Just wondering if anyone out there is already using the ex9200 switches. Im interested on knowing about stability in virtual chassis mode. Also, does anyone have idea about the bw per slot with the new SF2? Thanks in advance. Have a great weekend. Santiago ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Dual Dynamic VPNS
All, Just a quick question. I'm looking at creating a new Dynamic VPN into the office here that allows internet throughput and other cool and sexy options. We however already have one setup. We're using an SRX210 with the basic license. I'm wondering if I can create the test dynamic VPN while the other is still in production. I'm looking at the hierarchy of the commands required seem to overlap the current configuration. Has anyone tried this before? Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper ex9200
Not sure about vc mode but ex9200 is a disaster when it comes to dhcp-relay or you have mtu configuration for jumbo frames on any interface. Sent from my iPhone On Jul 11, 2014, at 7:25 PM, Santiago Martinez santiago.martinez...@gmail.com wrote: Hi guys, Just wondering if anyone out there is already using the ex9200 switches. Im interested on knowing about stability in virtual chassis mode. Also, does anyone have idea about the bw per slot with the new SF2? Thanks in advance. Have a great weekend. Santiago ___ 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] Juniper ex9200
Hi Ahmed, I’m not too worried about the dhcp-relay (for my case) but the jumbo frames worries me. Please can you provide mode information about it. Issues, workaround... Santiago On Friday 11 July 2014 15:35:33 Iftikhar Ahmed wrote: Not sure about vc mode but ex9200 is a disaster when it comes to dhcp-relay or you have mtu configuration for jumbo frames on any interface. Sent from my iPhone On Jul 11, 2014, at 7:25 PM, Santiago Martinez santiago.martinez...@gmail.com wrote: Hi guys, Just wondering if anyone out there is already using the ex9200 switches. Im interested on knowing about stability in virtual chassis mode. Also, does anyone have idea about the bw per slot with the new SF2? Thanks in advance. Have a great weekend. Santiago ___ 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] Juniper ex9200
Depending upon your configuration, you will have to choose one image. I was using 13.2r2. Mtu was 9050, after couple of interface flaps mtu value was not functional any more and i was unable to have ae link up on same configuration until i removed and re-created it. Later it was confirmed as bug after my coordination with atac. Sent from my iPhone On Jul 11, 2014, at 7:44 PM, Santiago Martinez santiago.martinez...@gmail.com wrote: Hi Ahmed, I’m not too worried about the dhcp-relay (for my case) but the jumbo frames worries me. Please can you provide mode information about it. Issues, workaround... Santiago On Friday 11 July 2014 15:35:33 Iftikhar Ahmed wrote: Not sure about vc mode but ex9200 is a disaster when it comes to dhcp-relay or you have mtu configuration for jumbo frames on any interface. Sent from my iPhone On Jul 11, 2014, at 7:25 PM, Santiago Martinez santiago.martinez...@gmail.com wrote: Hi guys, Just wondering if anyone out there is already using the ex9200 switches. Im interested on knowing about stability in virtual chassis mode. Also, does anyone have idea about the bw per slot with the new SF2? Thanks in advance. Have a great weekend. Santiago ___ 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] chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384
Hi Siva, yes i am using CFEB. Many thanks for pointing me out to PR718652. I think i will upgrade all M10i running 10.4R8.5 to the currently recommended JUNOS release (12.3R6.6 i think) Regards, Alex Am 11.07.2014 14:58, schrieb MSusiva: Hi Alex, Are you using CFEB on this node? You might want to look at this PR for details, fixed in 10.4R10. https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR718652 Chassisd leaks 4KB memory roughly every 33 minutes on M7i or M10i using cfeb namely Internet Processor II, Enhanced CFEB is NOT affected; No specific trigger is needed: Due to software bug, CFEB sends the CHASSIS_MSG_SCB status periodically, Chassisd goes and allocates 12 bytes of memory and comes out without freeing - amouting to a leak of 3.96KB every 33 minutes.Offline/online FRU will also call this function thus aggravate Chassisd mem leak. Thank You, Siva Date: Thu, 10 Jul 2014 22:53:03 +0200 From: Alex D.listensamm...@gmx.de To: juniper-nsp@puck.nether.net Subject: [j-nsp] chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384 Message-ID:53befd2f.3020...@gmx.de Content-Type: text/plain; charset=ISO-8859-15; format=flowed Hi, since yesterday, i see the following syslog messages from several M10i running JUNOS 10.4R8.5: chassisd[1299]: %DAEMON-3: rtslib: ERROR Failed to allocate new block of size 16384 This message occurs in irregular intervals and doesn't result in routing issues. Does anybody know what it means ? Regards, Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX PPPoE issue on JunOS 12.1X44-D35.5
Hi, I am trying to upgrade an SRX210H from the previous recommended version (11.4R11.4) to the current one (12.1X44-D35.5), however with the exact same configuration the PPP session doesn't come up. I rolled back to the previous recommended version and it works back perfectly. It appears that the Link Control Protocol phase is stuck in `Creq-sent` state, and then times out (see https://paste.oxynux.org/zwq8hb-3053?raw). I didn't find anything relevant in the release notes but I might have missed something. Here are the relevant parts of my configuration: https://paste.oxynux.org/qqtbqg-3052?raw Would anyone have a clue or could help me towards the right direction, before I dig more and start some intrusive wire-listening? Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
