Re: [j-nsp] MX80 BGP performance after reboot
* Sebastian Wiesinger juniper-...@ml.karotte.org [2013-02-15 00:55]: I just tested this after talking to JTAC. Just for reference: I had ~70k routes from 40 peers that I deactivated. I then turned them up again and measured with inline-jflow disabled and enabled. With inline-jflow ON: around 10-12 minutes until KRT settles With inline-jflow OFF: around 2 minutes until KRT settles To build a full table (after reboot) it's even longer of course. So... ATAC says this is expected behavior for this platform. Nothing wrong with the router. He even sent me lab tests that he did which proved that it takes them the same time in the lab. I now sent him the NANOG slides and PR mentioned here. Waiting for an answer... Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
* Sebastian Wiesinger juniper-...@ml.karotte.org [2013-02-19 10:20]: So... ATAC says this is expected behavior for this platform. Nothing wrong with the router. He even sent me lab tests that he did which proved that it takes them the same time in the lab. I now sent him the NANOG slides and PR mentioned here. Waiting for an answer... Okay, so ATAC says that the NANOG PR has nothing to do with this case. This is a hardware limitation on MX and cannot be improved according to them. This is really frustrating and limits the scope where we can put the MX80 platform. Would it have been so much more expensive to put a faster CPU/RE into that thing? Or is this just a case of diversifying the product line? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] After reboot optic doesn't send light
Every now and then we happen to a see strange case with our linecards (MPC 3D 16x 10GE). After a linecard reboot one of the optics sometimes stops sending light: Physical interface: xe-2/3/3 Laser bias current: 0.000 mA Laser output power: 0. mW / - Inf dBm Module temperature: 22 degrees C / 71 degrees F Module voltage: 3.2220 V Receiver signal average optical power : 0.2459 mW / -6.09 dBm Reseating interface help, but in remote locations it is not really handy. Disabling/enabling interface doesn't help. Any tips of how to deal with it without asking remote hands support? I will greatly appreciate anything that helps. -- Grzegorz Janoszka ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Dynamic VPN timers reconfiguration
Hi I'm using dynamic-vpn feature on SRX. I would like to adjust timers for idle-timeout and hello/keepalive-interval and hello/keepalive-timeout. Is it possible ? I didn't found it in docs. Default values are: - Idle-timeout = 15 minutes - Hello/Keepalive-Interval = 30 seconds - Hello/Keepalice-Timeout = 90 seconds I'm using 11.4R6. Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] After reboot optic doesn't send light
On Tue, Feb 19, 2013 at 11:27 AM, Grzegorz Janoszka grzeg...@janoszka.pl wrote: Every now and then we happen to a see strange case with our linecards (MPC 3D 16x 10GE). After a linecard reboot one of the optics sometimes stops sending light: Did you tried power-on/power-off optics ? Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On Tue, Feb 19, 2013 at 10:54 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: This is really frustrating and limits the scope where we can put the MX80 platform. Would it have been so much more expensive to put a faster CPU/RE into that thing? Or is this just a case of diversifying the product line? It's not about slow CPU. MX80 has very fast PPC (fastest from it's like) processor but RPD code sucks. Same family was used eg. in RSP720 in Cisco 7600 which is much faster - but it's probably becouse IOS preforms better than JunOS in terms of performance/scheduling on PPC platform. New MX80 is coming (with Dual-RE) but RE is so small and I don't think it will be Intel instead of PPC. Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On (2013-02-19 10:54 +0100), Sebastian Wiesinger wrote: Okay, so ATAC says that the NANOG PR has nothing to do with this case. This is a hardware limitation on MX and cannot be improved according to them. I think they are missing the point completely. There is no excuse to blackhole, poorly performing code does not justify it, poorly performing hardware does not justify it. Do NOT send routes out, if you are not sure that you've installed them, by the time neighbour gets the update. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
* Saku Ytti s...@ytti.fi [2013-02-19 13:09]: On (2013-02-19 10:54 +0100), Sebastian Wiesinger wrote: Okay, so ATAC says that the NANOG PR has nothing to do with this case. This is a hardware limitation on MX and cannot be improved according to them. I think they are missing the point completely. There is no excuse to blackhole, poorly performing code does not justify it, poorly performing hardware does not justify it. Do NOT send routes out, if you are not sure that you've installed them, by the time neighbour gets the update. Yes, I agree. But that's a design decision so ATAC is not interested. I'll try to get this to Juniper trough my SE but I don't know if that'll do any good. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IPSec Tunnel between Remote office and main Office
Hi, One of our client has currently below topology to connect all remote sides to main office. Remote Site-1(SRX240) --E1- Router --GE- Main Office (SRX 650) | | | Remote Site-x(SRX240) --E1 Following are other part of configuration: 1. All devices running RIP because Router is very old and need extra support license for OSPF. 2. Route based IPSec tunnel is configured between both Remote site SRX240 and SRX650. 3. All E1 links on remote side and Ge link between SRX650 are in Untrust Zone 4. All st interfaces are in VPN Zone, LAN interfaces are in Trust Zone. 5. Policies are allowed between different sources and destination between VPN and Trust Zone. 6. Traffic is denied between Untrust and VPN/Trust Zone. Client want to remove Router from topology and connect of E1 links on SRX650. We have perform following steps to migrate one link for testing: 1. Remove E1 link from router and connect it to SRX650. 2. Put above E1 link in RIP and Untrust Zone. 3. Put Routing Policies on SRX650 E1 link in RIP to stop learning Trust subnets of remote office from E1 link. So that only routes will learn from St link. 3. We didn't change any VPN configuration on both side and IPSec tunnel is comes up and also traffic is passing. External interface in VPN Configuration on SRX650 still is Ge interface VPN IKE Gateway on Remote site is same Ge interface IP on SRX650. We observe following thing: -- Regards, Muhammad Atif Jauhar (+966-56-00-04-985) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPSec Tunnel between Remote office and main Office
Hi, One of our client has currently below topology to connect all remote sides to main office. Remote Site-1(SRX240) --E1- Router --GE- Main Office (SRX 650) | | | Remote Site-x(SRX240) --E1 Following are other part of configuration: 1. All devices running RIP because Router is very old and need extra support license for OSPF. 2. Route based IPSec tunnel is configured between both Remote site SRX240 and SRX650. 3. All E1 links on remote side and Ge link between SRX650 are in Untrust Zone 4. All st interfaces are in VPN Zone, LAN interfaces are in Trust Zone. 5. Policies are allowed between different sources and destination between VPN and Trust Zone. 6. Traffic is denied between Untrust and VPN/Trust Zone. Client want to remove Router from topology and connect of E1 links on SRX650. We have perform following steps to migrate one link for testing: 1. Remove E1 link from router and connect it to SRX650. 2. Put above E1 link in RIP and Untrust Zone. 3. Put Routing Policies E1 link in RIP to stop learning Trust subnets from E1 link. So that only routes will learn from St link. Only Ge interface IP is learned from E1 link. 3. We didn't change any VPN configuration on both side and IPSec tunnel is comes up and also traffic is passing. External interface in VPN Configuration on SRX650 still is Ge interface VPN IKE Gateway on Remote site is same Ge interface IP on SRX650. We observe following thing: 1. When we access remote firewall, session hanged sometime and also output of any command displayed slowly. 2. When we access remote firewall directly from main office SRX, session completely hanged, Once we put command of bigger output like request support information or show configuration etc. 3. If we access same way in step 2 for other remote firewalls there is no issue. Kindly let us know, there is any issue If we have Directly connected link but we are establishing IPSec tunnel with other Interface IP like Ge interface on SRX650. IKE Gateway on SRX650 for remote firewall is same E1 link Interface. Means on remote firewall IKE gateway is Ge interface of SRX650 and On SRX650 IKE Gateway is E1 link of remote firewall. Any way to troubleshoot session hanging and slowness. Regards, Muhammad Atif Jauhar (+966-56-00-04-985) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On 2/19/2013 6:22 AM, Robert Hass wrote: On Tue, Feb 19, 2013 at 10:54 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: This is really frustrating and limits the scope where we can put the MX80 platform. Would it have been so much more expensive to put a faster CPU/RE into that thing? Or is this just a case of diversifying the product line? It's not about slow CPU. MX80 has very fast PPC (fastest from it's like) processor but RPD code sucks. Same family was used eg. in RSP720 in Cisco 7600 which is much faster - but it's probably becouse IOS preforms better than JunOS in terms of performance/scheduling on PPC platform. Last I checked, MX80 was only using a single core of the dual core PPC CPU - because JUNOS (32 bit) cannot gracefully handle SMP. -DMM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPSec Tunnel between Remote office and main Office
http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-41894.html set security flow tcp-mss ipsec-vpn mss 1300 - should fix it. Thanks Alex - Original Message - From: Muhammad Atif Jauhar atif.jau...@gmail.com To: juniper-nsp@puck.nether.net Sent: Tuesday, February 19, 2013 3:25 PM Subject: Re: [j-nsp] IPSec Tunnel between Remote office and main Office Hi, One of our client has currently below topology to connect all remote sides to main office. Remote Site-1(SRX240) --E1- Router --GE- Main Office (SRX 650) | | | Remote Site-x(SRX240) --E1 Following are other part of configuration: 1. All devices running RIP because Router is very old and need extra support license for OSPF. 2. Route based IPSec tunnel is configured between both Remote site SRX240 and SRX650. 3. All E1 links on remote side and Ge link between SRX650 are in Untrust Zone 4. All st interfaces are in VPN Zone, LAN interfaces are in Trust Zone. 5. Policies are allowed between different sources and destination between VPN and Trust Zone. 6. Traffic is denied between Untrust and VPN/Trust Zone. Client want to remove Router from topology and connect of E1 links on SRX650. We have perform following steps to migrate one link for testing: 1. Remove E1 link from router and connect it to SRX650. 2. Put above E1 link in RIP and Untrust Zone. 3. Put Routing Policies E1 link in RIP to stop learning Trust subnets from E1 link. So that only routes will learn from St link. Only Ge interface IP is learned from E1 link. 3. We didn't change any VPN configuration on both side and IPSec tunnel is comes up and also traffic is passing. External interface in VPN Configuration on SRX650 still is Ge interface VPN IKE Gateway on Remote site is same Ge interface IP on SRX650. We observe following thing: 1. When we access remote firewall, session hanged sometime and also output of any command displayed slowly. 2. When we access remote firewall directly from main office SRX, session completely hanged, Once we put command of bigger output like request support information or show configuration etc. 3. If we access same way in step 2 for other remote firewalls there is no issue. Kindly let us know, there is any issue If we have Directly connected link but we are establishing IPSec tunnel with other Interface IP like Ge interface on SRX650. IKE Gateway on SRX650 for remote firewall is same E1 link Interface. Means on remote firewall IKE gateway is Ge interface of SRX650 and On SRX650 IKE Gateway is E1 link of remote firewall. Any way to troubleshoot session hanging and slowness. Regards, Muhammad Atif Jauhar (+966-56-00-04-985) ___ 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] LACP to NetApp
We have a mixed virtual chassis of two EX4500s and two EX4200s. They
are connected to
two NetApp filers. Each filer has a LACP aggregate to the VC
consisting of two 10-Gig links
to each of the 4500s (so four xe interfaces in each one). Once things
are up and running,
it works fine, but things do not always come up cleanly after one of
the filers does a
hand back or reboots.
The problem happens most times, but not every time. It happens with
both controllers. It
does not happen to the same physical link in a bundle each time, and
it does not happen
only with links associated with one of the 4500 chassis. That seems to
imply a software
problem, not physical.
The trouble is one of the links in a bundle will end up stuck in the
Defaulted state as
seen from show lacp interfaces output. The symptom seen to the
network users is that
connectivity to specific machines on a network are lost, something
like the host with
192.168.2.100 is reachable, but 192.168.2.99 is not. I think this has
to do with the hashing
to chose a link in the LACP. The combinations that get sent to the
Defaulted link are
being lost, while others work.
From the Juniper EX side, the problem looks like the system is not
receiving any LACPDUs
on the affected link. The show lacp statistics interfaces counters
are not incrementing for
Rx PDUs. However, we have not been able to determine whether the
problem is that the
NetApp is not sending PDUs, or the Juniper is not processing them.
Recovery from the condition is easy. On the switch side, the interface
in the Defaulted
state is manually downed and upped,
# ifconfig xe-0/0/6 down
# ifconfig xe-0/0/6 up
And the LACP happily completes proper negotiations.
We have been trying to work with JTAC and NetApp support. The problem
has been finding
downtime to reboot the filers.
Both Juniper and NetApp have said they have seen issues like this, but
they were resolved by
specifying the following settings for the aggregate interface on the
switch-side,
aggregated-ether-options {
lacp {
active;
periodic slow;
}
}
To make the EX switch match the NetApp's defaults (defaults that
cannot be changed on their
side). But this did not solve the problem for us.
Has anyone here seen LACP problems with NetApp or other vendors? The
plan, if we ever get
the chance to do some troubleshooting, is to do analyzer captures to
see what's happening
with the LACPDUs. In the mean time, we were trying to also think of a
reliable way to automate
the reset of interfaces in the bundles if they fall into the Defaulted state.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPSec Tunnel between Remote office and main Office
Hi Alex, Its already configured with value 1350. Regards, Atif. On Tue, Feb 19, 2013 at 8:03 PM, Alex Arseniev alex.arsen...@gmail.comwrote: http://www.juniper.net/**techpubs/software/junos-** security/junos-security10.2/**junos-security-swconfig-** security/topic-41894.htmlhttp://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-41894.html set security flow tcp-mss ipsec-vpn mss 1300 - should fix it. Thanks Alex - Original Message - From: Muhammad Atif Jauhar atif.jau...@gmail.com To: juniper-nsp@puck.nether.net Sent: Tuesday, February 19, 2013 3:25 PM Subject: Re: [j-nsp] IPSec Tunnel between Remote office and main Office Hi, One of our client has currently below topology to connect all remote sides to main office. Remote Site-1(SRX240) --E1--**--- Router --GE--**--- Main Office (SRX 650) | | | Remote Site-x(SRX240) --E1--**-- Following are other part of configuration: 1. All devices running RIP because Router is very old and need extra support license for OSPF. 2. Route based IPSec tunnel is configured between both Remote site SRX240 and SRX650. 3. All E1 links on remote side and Ge link between SRX650 are in Untrust Zone 4. All st interfaces are in VPN Zone, LAN interfaces are in Trust Zone. 5. Policies are allowed between different sources and destination between VPN and Trust Zone. 6. Traffic is denied between Untrust and VPN/Trust Zone. Client want to remove Router from topology and connect of E1 links on SRX650. We have perform following steps to migrate one link for testing: 1. Remove E1 link from router and connect it to SRX650. 2. Put above E1 link in RIP and Untrust Zone. 3. Put Routing Policies E1 link in RIP to stop learning Trust subnets from E1 link. So that only routes will learn from St link. Only Ge interface IP is learned from E1 link. 3. We didn't change any VPN configuration on both side and IPSec tunnel is comes up and also traffic is passing. External interface in VPN Configuration on SRX650 still is Ge interface VPN IKE Gateway on Remote site is same Ge interface IP on SRX650. We observe following thing: 1. When we access remote firewall, session hanged sometime and also output of any command displayed slowly. 2. When we access remote firewall directly from main office SRX, session completely hanged, Once we put command of bigger output like request support information or show configuration etc. 3. If we access same way in step 2 for other remote firewalls there is no issue. Kindly let us know, there is any issue If we have Directly connected link but we are establishing IPSec tunnel with other Interface IP like Ge interface on SRX650. IKE Gateway on SRX650 for remote firewall is same E1 link Interface. Means on remote firewall IKE gateway is Ge interface of SRX650 and On SRX650 IKE Gateway is E1 link of remote firewall. Any way to troubleshoot session hanging and slowness. Regards, Muhammad Atif Jauhar (+966-56-00-04-985) __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp -- Regards, Muhammad Atif Jauhar (+966-56-00-04-985) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
is not possible to run junos 64 bits on mx80 ? PPC dual core supports it ? why not to use 8 GB dram instead of 2 only ? Sent from my iPhone On 19/02/2013, at 12:59, David Miller dmil...@tiggee.com wrote: On 2/19/2013 6:22 AM, Robert Hass wrote: On Tue, Feb 19, 2013 at 10:54 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: This is really frustrating and limits the scope where we can put the MX80 platform. Would it have been so much more expensive to put a faster CPU/RE into that thing? Or is this just a case of diversifying the product line? It's not about slow CPU. MX80 has very fast PPC (fastest from it's like) processor but RPD code sucks. Same family was used eg. in RSP720 in Cisco 7600 which is much faster - but it's probably becouse IOS preforms better than JunOS in terms of performance/scheduling on PPC platform. Last I checked, MX80 was only using a single core of the dual core PPC CPU - because JUNOS (32 bit) cannot gracefully handle SMP. -DMM ___ 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] LACP to NetApp
Date: Tue, 19 Feb 2013 10:43:07 -0800
From: Crist Clark cjc+j-...@pumpky.net
Subject: [j-nsp] LACP to NetApp
aggregated-ether-options {
lacp {
active;
periodic slow;
}
}
I prefer to always set fast active on either side. So far it has
avoided and fixed more issues then all the vendors telling me I
shouldn't have two sides active...
Has anyone here seen LACP problems with NetApp or other vendors?
Did see a weird issues once with a Nexus vPC and NetApp. Nothing so
far with MixedMode EX VC and various NetApps, LACP on GE's and 10GE's.
Have you tried a monitor traffic session on the EX VC to see if you
do or do not see LACPDU's ?
Also, remember the NetApp LAG (ifgrp) commands can also give you an
idea of what it is thinking/believing about it all... Especially
nested groups have an actual traffic test built-in it seems...
Kind regards,
JP Velders
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
