Re: [j-nsp] SRX, UDP traffic, routing asymmetry
On 12/03/2012 03:48 AM, Dale Shaw wrote: Sometimes (due to OSPF's route selection process when presented with equal cost routes) the path traffic takes from A to B is not the same as the path from B to A -- the intermediate device to hair-pin on (for A-B and B-A) is different. In performance terms, the difference is insignificant. Most of the time the intermediate devices are sitting next to each other in a rack (e.g. primary and secondary routers). How does this even work? Surely TCP flows through the device just won't go? Does the SRX do something special with asymmetric UDP flows? When I say UDP I mean UDP generically, because I'm aware of special cases like set security flow allow-dns-reply. I have an ever-growing suspicion that we are throwing packets on the floor in certain circumstances. What kind of special were you thinking of? Obviously each flow will appear as a separate uni-directional session to the SRX, since each device only sees half the traffic. It's possible something funny happens in this situation e.g. if the flow runs for X seconds without a packet in the other direction, drop it. But that's purely speculation. This is probably not what you want to hear, but OSPF is a nightmare in this situation; you end up balancing route metrics constantly (if you want multiple devices forwarding) or just running one device active at a time. We used to do it, and I hated it... cheers, Dale (..on the never-ending quest to make SRXs behave like routers w/IPsec) I feel your pain. It's a mystery to me why vendors seem to be abandoning traditional IPSec on routers in favour of small firewalls with all their attendant problems re: flow symmetry. That said: we run flow-based devices in dual-active mode using BGP rather than OSPF. The reason this works is that judicious use of BGP communities and routing policy can be used to ensure both sides of a flow route via the same path in the steady state - though not in every topology, I'm afraid. The other option is to stick a load-balancer in front of the IPSec terminators. All very yucky. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
Perhaps these are useful: http://kb.juniper.net/InfoCenter/index?page=contentid=KB25094 http://kb.juniper.net/InfoCenter/index?page=contentid=KB24566 Does the SRX do something special with asymmetric UDP flows? When I say UDP I mean UDP generically, because I'm aware of special cases like set security flow allow-dns-reply. I have an ever-growing suspicion that we are throwing packets on the floor in certain circumstances. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] export OSPF routes as type 1
Ah there it is!
Don't i feel silly.
Thank you
From: Chris Kawchuk [juniperd...@gmail.com]
Sent: Monday, 3 December 2012 6:21 PM
To: Luca Salvatore
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] export OSPF routes as type 1
I'm trying to export some OSPF routes as type 1 external instead of the
default type 2 external.
I can't seem to find where it is done - I thought it would be done in the
policy map but I don't see an option.
policy-options {
policy-statement my-ospf-export-policy {
term static-and-direct-as-type-1 {
from protocol [ static direct ];
then {
external {
type 1;
}
accept;
}
}
}
}
- CK.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX 240 to SRX 650 E1 connectivty Problem
Hi Experts, Currently I have following scenario. SRX650 Cluster - Nortel Router - SRX240 (remote site) The nortel router has E1 terminating from the remote SRX240 firewalls. The objective is to remove the Nortel router from the network and terminate the E1 directly on the primary SRX 650. For this we have installed the Quad channelized T1/E1 card on the SRX650. When I migrated the link to the SRX650 everything seemed to work fine but when i logged in the remote srx240 through telnet and did a show config | no-more, the session hanged. The remote site also started to have problems with their applications. On reverting back to the Nortel Router everything starting working. All the devices are working on the default MTU size. If it's working fine with the nortel router, it should not have any issues with the srx650 since it's the same platform. Also it's hard to play with the MTU because i don't want to loose connectivty of the remote site. Further I changed the E1 link, the remote router, also did a failover (both rd0 rd1) on the srx 650 and used the E1 interfaces on the backup firewall but faced the same issue. The JUNOS is 10.4 R7.5. I would appreciate if someone can help me out with this issue. Adnan. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Error while validating a JunOS
The export junos does not support SSH and HTTPS. Only the Domestic seems to. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Error while validating a JunOS
On 03/12/12 14:45, Jason Fortier wrote: The export junos does not support SSH and HTTPS. Only the Domestic seems to. Correct. Interestingly, I recently seem to have lost access to download domestic JunOS for J-series, which I did previously have. I have retained domestic download access for SRX. Anyone else run into something similar? Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] netflow to Jflow
Hi All, I am moving from Cisco to Juniper MX5. My Cisco router was sending netflow information to a server(NFSEN). I cant see any update on the same server from my MX5 router, after we have done the migration. Following are the Cisco and Juniper configs. Cisco: ip flow-export version 5 origin-as ip flow-export destination 10.3.3.3 9995 interface GigabitEthernet5/0.3 encapsulation dot1Q 3 ip address 10.1.1.1 255.255.255.252 ip flow ingress Juniper: set forwarding-options sampling input rate 100 set forwarding-options sampling family inet output flow-server 10.3.3.3 port 9995 set forwarding-options sampling family inet output flow-server 10.3.3.3 version 5 set forwarding-options sampling family inet output flow-server 10.3.3.3 autonomous-system-type origin set interfaces ge-1/1/1 unit 24 family inet sampling input *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] netflow to Jflow
you should probably define the source ip address from the router. On Dec 3, 2012, at 11:28 AM, Ali Sumsam wrote: Hi All, I am moving from Cisco to Juniper MX5. My Cisco router was sending netflow information to a server(NFSEN). I cant see any update on the same server from my MX5 router, after we have done the migration. Following are the Cisco and Juniper configs. Cisco: ip flow-export version 5 origin-as ip flow-export destination 10.3.3.3 9995 interface GigabitEthernet5/0.3 encapsulation dot1Q 3 ip address 10.1.1.1 255.255.255.252 ip flow ingress Juniper: set forwarding-options sampling input rate 100 set forwarding-options sampling family inet output flow-server 10.3.3.3 port 9995 set forwarding-options sampling family inet output flow-server 10.3.3.3 version 5 set forwarding-options sampling family inet output flow-server 10.3.3.3 autonomous-system-type origin set interfaces ge-1/1/1 unit 24 family inet sampling input *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] netflow to Jflow
instead
set interfaces ge-1/1/1 unit 24 family inet sampling input
try applying the below filter on inbound and outbound direction of
interface ge-1/1/1.24
filter sample {
term 1 {
then {
sample;
accept;
}
}
On Mon, Dec 3, 2012 at 8:41 PM, OBrien, Will obri...@missouri.edu wrote:
you should probably define the source ip address from the router.
On Dec 3, 2012, at 11:28 AM, Ali Sumsam wrote:
Hi All,
I am moving from Cisco to Juniper MX5. My Cisco router was sending
netflow
information to a server(NFSEN).
I cant see any update on the same server from my MX5 router, after we
have
done the migration. Following are the Cisco and Juniper configs.
Cisco:
ip flow-export version 5 origin-as
ip flow-export destination 10.3.3.3 9995
interface GigabitEthernet5/0.3
encapsulation dot1Q 3
ip address 10.1.1.1 255.255.255.252
ip flow ingress
Juniper:
set forwarding-options sampling input rate 100
set forwarding-options sampling family inet output flow-server 10.3.3.3
port 9995
set forwarding-options sampling family inet output flow-server 10.3.3.3
version 5
set forwarding-options sampling family inet output flow-server 10.3.3.3
autonomous-system-type origin
set interfaces ge-1/1/1 unit 24 family inet sampling input
*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] netflow to Jflow
You have NTP enabled, and it's properly synced? - CK. On 2012-12-04, at 4:28 AM, Ali Sumsam ali+juniper...@eintellego.net wrote: 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] Error while validating a JunOS
On 04/12/12 02:28, Phil Mayers wrote: On 03/12/12 14:45, Jason Fortier wrote: The export junos does not support SSH and HTTPS. Only the Domestic seems to. Correct. Interestingly, I recently seem to have lost access to download domestic JunOS for J-series, which I did previously have. I have retained domestic download access for SRX. It's probably the new download page, there's a dropdown for domestic vs worldwide that's a little non-obvious. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Error while validating a JunOS
After the last site maintenance my support account was completely foo. I had to have them reset it for me. On Dec 3, 2012, at 8:13 PM, Julien Goodwin jgood...@studio442.com.au wrote: On 04/12/12 02:28, Phil Mayers wrote: On 03/12/12 14:45, Jason Fortier wrote: The export junos does not support SSH and HTTPS. Only the Domestic seems to. Correct. Interestingly, I recently seem to have lost access to download domestic JunOS for J-series, which I did previously have. I have retained domestic download access for SRX. It's probably the new download page, there's a dropdown for domestic vs worldwide that's a little non-obvious. -- Julien Goodwin Studio442 Blue Sky Solutioneering ___ 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] small multitenant datacenter
Thanks Benny. DMVPN boxes (cisco x8xx), and MPLS boxes (MX80s). All those L3 addresses are in customer-specific routing-instance (or, VRF on cisco) and there's a per-customer ospf instance keeping things knitted together. That design is somewhat similar to one that I am familiar with; it all looks sane. Do you see an issue with blowing up ex4200s with all this ospf and vrrp? I'm labbing tomorrow and will try to get the boxes to thrash. From a routing table size POV I'm not worried (many customers having no extra routes, lots have 4-6, a handful having as many as 30 or 40), I'm a little concerned all those processes might upset the RE if things get flappy. I can handle a little bump but if they just freak out that wouldn't be good. Will your design hit any problems if a customer already uses 10.144.x? Yeah. I'd have to pick some other subnet for that customer, which would break the tidiness of everything, but so be it. In a green-field deployment today I would move all the special traffic to IPv6 and only care about public IP addresses in IPv4. The MPLS would still move customer traffic with IPv4 private IPs and the hosted servers and firewalls would still have private IPv4 addresses, but all monitoring traffic would be IPv6. Good thought. One thing was different in the design: The equivalents of your VLANs 2000-2999 and 3000-3999 are carried inside q-in-q, to make it possible to eventually grow beyond 4000 customers and to ensure that overlap between customer VLANs and other VLANs would not cause problems. Good thought. Can you hook up L3 addresses to the inner tags on EX boxes? I'll have to play with that. Ryan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] small multitenant datacenter
On Mon, Dec 3, 2012 at 11:06 PM, Ryan Goldberg rgoldb...@compudyne.net wrote: Do you see an issue with blowing up ex4200s with all this ospf and vrrp? I'm labbing tomorrow and will try to get the boxes to thrash. I'm interested to know your thoughts on RE performance after you have labbed this scenario. I've read the EX4200 supports 256 VRF-Lite instances, but like you, I imagine the control-plane may become sluggish before it gets to that point. I noticed you include the EX3300 in your design. I also considered this switch and decided against it once I read the feature table. I would like to use them once additional features are working, but right now, it lacks critical items like storm-control. https://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html Also, you mention both EX4200 virtual-chassis, and VRRP. I think it is unusual to choose BOTH V-C and STP+VRRP as redundancy mechanisms, because you get the worst of both worlds in terms of potential failure modes. For example, you get the unknown-unicast problems associated with ingress traffic arriving on the VRRP non-master and potentially being flooded out many ports of that switch, because it may never learn MAC addresses of downstream servers while it is the non-master. You also get any problems that you might encounter with virtual-chassis, meaning, bugs. I think you should pick one: V-C or STP+VRRP, depending on which technology you are most comfortable with. Mixing the two is IMO not smart, not because of any unique problems that arise from this combination, but simply because you have decided to expose yourself to two sets of gotchas without necessarily gaining anything. My experience with EX4200 virtual-chassis has been extremely good since Junos 10.4. Before then, we had problems with file system corruption on the EX4200, but this was fixed in 10.4. I have not had any serious stacking-specific bugs since about Junos 9.5. I rely totally on EX4200 virtual-chassis for redundancy in many environments, and am very pleased with the results. Good luck with your project. I hope my comments are constructive and helpful! -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] small multitenant datacenter
Thanks Jeff- Do you see an issue with blowing up ex4200s with all this ospf and vrrp? I'm labbing tomorrow and will try to get the boxes to thrash. I'm interested to know your thoughts on RE performance after you have labbed this scenario. I've read the EX4200 supports 256 VRF-Lite instances, but like you, I imagine the control-plane may become sluggish before it gets to that point. I also saw the vrf limits in the docs http://www.juniper.net/techpubs/en_US/junos11.1/topics/concept/bridging-vrf-ex-series.html but if you look at 11.2 http://www.juniper.net/techpubs/en_US/junos11.2/topics/concept/bridging-vrf-ex-series.html poof, limits gone? I'm working remote right now and just have one MX80 plumbed to one 4200. I brought up 300 virtual-routers with ospf between them. During the commit on the 4200s that initially fired the ospfs load went to about 6.5 and then fell off quickly. From load of .05 to 6.5 and back to .05 was under 2 minutes (roughly). Each of the 300 vrfs has just the connected routes between the boxes and then another route on the other side of the MX80. So I loaded 12k static routes onto the MX80 into one of the vrfs and there was almost no noticeable impact on the 4200, cpu climbed to like 50% for maybe 20 seconds. I then dropped the link briefly between the boxes and the impact to the 4200 was about the same, 50% or so for maybe 20-30 seconds. I'll have more time to play tomorrow, and will report back findings. I noticed you include the EX3300 in your design. I also considered this switch and decided against it once I read the feature table. I would like to use them once additional features are working, but right now, it lacks critical items like storm-control. https://www.juniper.net/techpubs/en_US/release- independent/junos/topics/concept/ex-series-software-features- overview.html I will re-review what we may need/what may be lacking. It seems the 3300s are catching up, and we have had good luck in small single-tenant deployments (3 vmware host + SAN), using them strictly as stacked L2 switches, generally in place of a pair of 3750x or 2960s. Also, you mention both EX4200 virtual-chassis, and VRRP. I think it is unusual to choose BOTH V-C and STP+VRRP as redundancy mechanisms, because you ... I think you should pick one: V-C or STP+VRRP, depending on which This has been causing me loss of sleep. On the one hand, I like independent brains and feel that hinging everything on IRF, VC, VSS, etc, just puts you in a riskier spot, with invisible magic keeping things afloat My experience with EX4200 virtual-chassis has been extremely good since Junos 10.4. Before then, we had problems with file system corruption on the EX4200, but this was fixed in 10.4. I have not had any serious stacking-specific bugs since about Junos 9.5. I rely totally on EX4200 virtual-chassis for redundancy in many environments, and am very pleased with the results. But like you, I've had really good luck with the 4200s. In fact, I have had zero issues. We didn't start getting them till 10.4, so I think we escaped some initial ick. The invisible magic might be better than a relatively delicate and somewhat complex configuration. Good luck with your project. I hope my comments are constructive and helpful! Very much so. As I play with the failure modes, and try and balance performance and manageability with meeting the various business goals and constraints, I think it will be a bunch of fun. Thanks- Ryan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
