Re: [j-nsp] l2circuit (martini) vlan-mismatch
On (2013-09-19 10:09 +0300), Saku Ytti wrote: Now consider in B-END if some of the SVLANs need to go to the L2VPN circuit and some SVLAN needs to be locally terminated. s/SVLAN/CVLAN/g sorry about that -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Steel-Belted RADIUS backups
Hi there, You might consider using RAID mirroring if your servers support it :) /ET On 8/30/13 12:42 PM, Jed Laundry jlaun...@jlaundry.com wrote: If it's Linux, are you using LVM as a storage layer? LVM snapshots are your friend for making a consistent backup, regardless of if you use a tar script or VM snapshot/image. Thanks, Jed. Sent from a mobile device. On 29/08/2013 11:12 pm, Dale Shaw dale.shaw+j-...@gmail.com wrote: Hi all, Does anyone out there use SBR? We have the Global Enterprise Edition (GEE) version v6.1.7 running on Linux. I'm putting something in place to back up SBR itself; currently we just tar up /opt/JNPRsbr/radius (after stopping sbrd) but it's occurred to me that we have never tested a recovery using this method. JTAC are telling me there is no automated way to perform the XML export function normally performed in the GUI. The product docs don't make it clear whether taking a copy of everything in /opt/JNPRsbr/radius/ is enough, or whether the XML export is also required. Looking at what the supplied install/upgrade scripts do, it's just a recursive 'cp' with some unnecessary folders excluded. We also take backups of the VM guest that's running SBR but I'm not familiar enough with SBR's back-end databases to know whether that results in a recoverable data set; there'll be open files for sure (hence the stop;tar;start method described above). What do you do? use FreeRADIUS instead is a valid but unwelcome response :-)) Cheers, Dale ___ 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] NAT on MX platforms?
The new MS-MIC is coming too... http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/ms-mic-and-mpc-overview.html So, it fits in MPC1/MPC2, if you have a free MIC slot. It costs a lot less than the MS-DPC, although it has about the same capacity. Fits in the back of MX80 too... -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tomasz Mikolajek Sent: Wednesday, September 18, 2013 9:13 PM To: rkramer Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] NAT on MX platforms? Hi. Now we are testing Juniper device do CGNAT. MX240 with MS-DPC card. Everything work fine. I heard that in new year will be shipped new service card. Can any one say more about new MS-DPC? 2013/9/18 rkramer rkra...@gmail.com I currently use MX240's throughout my routing environment today, and I'm looking to upgrade my existing NAT boxes, which are Cisco ASR's. They are running out of horsepower, and from what I'm seeing, MS-DPC's on MX's provide more than enough capacity... I'm not planning to do any firewalling at the NAT locations, just nat pools and 1:1 nat translations, with some 6to4 thrown in for good measure. Anyway, I'm assuming someone on the list has to be running MX's doing NAT? How is it working out for you? Any pitfalls? Ryan Kramer ___ 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] l2circuit (martini) vlan-mismatch
- Original Message - From: Saku Ytti s...@ytti.fi To: juniper-nsp@puck.nether.net Everything works just fine. Only I find it really strange B-END cannot push arbitrary S-VLAN, considering A-END is going to change it anyhow. If it's not 101, A-END vill be down with 'vlan-mismatch'. Use explicit encapsulation-type ethernet under [protocols l2circuit interface ] and You won't be seeing this mismatch. On both sides of course. HTH Thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ICMP Type - IP Unreachable Notification
Hi All I have following ICMP type (ip unreachable notification) and I want to know if our MX/J series routers responds to this ICMP type or not. i.e. I have checked for another ICMP type ip mask reply with following command and I don`t get anything response back which means JUNOS doesn`t reply for mask request. sudo nping -icmp --icmp-type mask-request x.x.x.x --count 5 x.x.x.x is our internet facing IP address. I am looking for something similar which I can try to get the behavior of JUNOS. I know if we want to block this type of ICMP , then we have to apply a filter which I really don`t want at the moment. Thanks in adavance !! Eddie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Steel-Belted RADIUS backups
On Aug 30, 2013 1:46 AM, Jed Laundry jlaun...@jlaundry.com wrote: If it's Linux, are you using LVM as a storage layer? LVM snapshots are your friend for making a consistent backup, regardless of if you use a tar script or VM snapshot/image. Unless developers have made major structural changes to LVM snapshots they're nearly useless. They require large swaths of contiguous kernel RAM for the CoW bitmap so once a machine is running for a while and thus has fragmented its RAM free space you end up with LVM bailing out while trying to snapshot. The other side of that is if your snapshot routine doesn't shutdown services and unmount the filesystem you're essentially snapshotting a crashed server and hoping filesystem and database recovery goes well when you restore that backup Thanks, Jed. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX104 Power Draw (AC)
Does anyone have an MX104 deployed with dual AC power supplies and using the 4X10G built-in that could give me an idea of how much amperage (AC 110v) it draws? I can pull up the specs on it but looking for a reasonable estimate on amperage draw, hopefully based on real world. Many thanks, Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Automation of EX code upgrade
Unix expect script? SSH keys can make scp'ing files and logging in to run commands pretty painless. Good luck! Morgan On Thu, Sep 19, 2013 at 3:04 PM, Mick Burns bmx1...@gmail.com wrote: Hey all, I am looking for ideas/previous experience in the best way to automate the upgrade of multiple (let's say about a hundred units) EX switches in large datacenters. Let's assume here they are a mix of 3200 and 4200 and all of them runs the same JunOS release. Any failure must be quickly identified for a manual upgrade. Any help or advice is much appreciated. Mick B. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Automation of EX code upgrade
If you're talking green fields (out-of-the-box) then there are a couple of ways depending on the current Junos release the switch is running: 12.2 - Automatic Software Download http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/ex-series-software-automatic-download-upgrading.html =12.2 - Zero Touch Provisioning http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/software-image-and-configuration-automatic-provisioning-understanding.html Try to stagger upgrades if you can, or learn the effects of having a hundred switches hitting a TFTP server for a ~110MB image file. Neither of these methods will display the success of the upgrades though. If your switches are already deployed, then a better way to do it is with Junos Space. The nice thing about the Space method is that you can upgrade smaller groups of switches at a time, pre-stage the images up to each switch and schedule the entire process. Each upgrade is given a Job ID and that Job ID will return success or failure depending on the outcome, even in the pre-staging if you don't have room on your flash for the image.. This functionality is built into the base Space platform too, which you can download and install with a 60(?)-day trial license. Cheers, Ben On 20/09/2013, at 8:04 AM, Mick Burns bmx1...@gmail.com wrote: Hey all, I am looking for ideas/previous experience in the best way to automate the upgrade of multiple (let's say about a hundred units) EX switches in large datacenters. Let's assume here they are a mix of 3200 and 4200 and all of them runs the same JunOS release. Any failure must be quickly identified for a manual upgrade. Any help or advice is much appreciated. Mick B. ___ 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] Automation of EX code upgrade
Hey all, I am looking for ideas/previous experience in the best way to automate the upgrade of multiple (let's say about a hundred units) EX switches in large datacenters. Let's assume here they are a mix of 3200 and 4200 and all of them runs the same JunOS release. Any failure must be quickly identified for a manual upgrade. Any help or advice is much appreciated. Mick B. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Automation of EX code upgrade
Junos Space (VM version) is pretty inexpensive as well for required functionality using the built in application Network Management Platform. Thanks, George -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ben Dale Sent: Friday, September 20, 2013 1:33 AM To: Mick Burns Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Automation of EX code upgrade If you're talking green fields (out-of-the-box) then there are a couple of ways depending on the current Junos release the switch is running: 12.2 - Automatic Software Download http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/ex-ser ies-software-automatic-download-upgrading.html =12.2 - Zero Touch Provisioning http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/software-imag e-and-configuration-automatic-provisioning-understanding.html Try to stagger upgrades if you can, or learn the effects of having a hundred switches hitting a TFTP server for a ~110MB image file. Neither of these methods will display the success of the upgrades though. If your switches are already deployed, then a better way to do it is with Junos Space. The nice thing about the Space method is that you can upgrade smaller groups of switches at a time, pre-stage the images up to each switch and schedule the entire process. Each upgrade is given a Job ID and that Job ID will return success or failure depending on the outcome, even in the pre-staging if you don't have room on your flash for the image.. This functionality is built into the base Space platform too, which you can download and install with a 60(?)-day trial license. Cheers, Ben On 20/09/2013, at 8:04 AM, Mick Burns bmx1...@gmail.com wrote: Hey all, I am looking for ideas/previous experience in the best way to automate the upgrade of multiple (let's say about a hundred units) EX switches in large datacenters. Let's assume here they are a mix of 3200 and 4200 and all of them runs the same JunOS release. Any failure must be quickly identified for a manual upgrade. Any help or advice is much appreciated. Mick B. ___ 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
