Re: [j-nsp] Best route reflector platform
On Sun, Apr 21, 2013 at 02:47:58PM +0400, Pavel Lunin wrote: 2. Branch SRX do not support more than 2G of RAM. Moreover about 700M+ is preallocated for flow session table and it is not released even when you switch the box into packed mode (well, at least used to be last time I checked a year or so ago). Plus JUNOS itself. In practice you have just about ~700M of free control plane memory on SRX650. A decent amount of memory is required for RR purposes too. We're pretty much to the point that if its not running 64-bit JUNOS (which actualley only bumps the max rpd memory from 2GB to 3GB, so it's not that big an improvement :P) it either won't work at all, or won't survive for very long. And that's after taking a lot of steps to reduce core IBGP mesh route load. I haven't touched any of the virtual SRX stuff, does it run 64-bit JUNOS? In fairness I really don't think there is a big market for dedicated RR's, so I'm sure it isn't on the top of anyone's radar. That said, it is an absurdly easy problem to solve, with almost no work required (ship JUNOS on 1U PC and call it JCS100). So besides greatly pissing off many of its largest customers, they're leaving money on the floor and forcing people into other solutions with other vendors. I really can't imagine that the benefit of selling an extra MX240 chassis, even if sold at regular price, is worth the money being lost from everyone else. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
On Wed, Apr 24, 2013 at 07:24:18AM -0500, Richard A Steenbergen wrote: In fairness I really don't think there is a big market for dedicated RR's, so I'm sure it isn't on the top of anyone's radar. That said, it is an absurdly easy problem to solve, with almost no work required (ship JUNOS on 1U PC and call it JCS100). Even easier: ship a VM image of JUNOS, call it Olivia and a day. But that would be /too/ easy. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
2013/4/24 Richard A Steenbergen r...@e-gerbil.net wrote: it either won't work at all, or won't survive for very long. And that's after taking a lot of steps to reduce core IBGP mesh route load. I haven't touched any of the virtual SRX stuff, does it run 64-bit JUNOS? I haven't either (it's just rumors :) but I don't believe it will be any better than normal JUNOS from this perspective. There is another caveat. The difference of boxes like SRX or J (be it virtual or not) is that their PFE (fwdd process) also holds FIB (not only the flow session table), which is stored in the same RAM. You might be able to reduce it with a RIB-FIB policy, though I don't know whether it'll save any memory. For the Internet routes FIB might be not that huge thing, especially in comparison with the flow table, but for a VPN environment it might consume quite a noticeable amount of RAM. One might prefer to just totally shut up the fwdd on such an RR, but I don't believe it will work (at least stably). In fairness I really don't think there is a big market for dedicated RR's, so I'm sure it isn't on the top of anyone's radar. That said, it is an absurdly easy problem to solve, with almost no work required (ship JUNOS on 1U PC and call it JCS100). So besides greatly pissing off many of its largest customers, they're leaving money on the floor and forcing people into other solutions with other vendors. Agree. I really can't imagine that the benefit of selling an extra MX240 chassis, even if sold at regular price, is worth the money being lost from everyone else BTW, does an empty chassis with just an SCB and RE work here? BGP will definitely run through fxp0 but I haven't ever tried to run an MX with no line cards. It seems this should work, but does it, anyone tried in production? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
20.04.2013 01:45, Chip Marshall write: So, I have an MX5 with it's fxp0 management interface connect to one network, which I've placed in a logical-system so it can have it's own default route for out-of-band management. This is what I never understood. Why people want to use fxp0 (or any other dedicated management) iface for real production management? Well, of course we need some sort of special management VLAN or routed infrastructure to separate management from the payload-carrying network, but what is the reason to bypass data plane and plug it right into the RR? Even leaving apart all the troubles like discussed in this thread, implied by impossibility to use a lot of forwarding features (you can't even connect it to two switches for backup), this deprives you to protect the RE using hardware filters and policers. Say, I saw a couple quite serious cases when a crazy trusted NMS DoSed routers with lots of ICMP probes and SNMP. In my opinion fxp0 is a thing much like console port, which is useful when you intentionally need to access the control plane directly (and this is why you better thing in advance of where it's plugged into and which subnet it belongs), but as a full-time management interface it seems to bring more troubles than benefits. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Wed, 24 Apr 2013, Pavel Lunin wrote: This is what I never understood. Why people want to use fxp0 (or any other dedicated management) iface for real production management? Many operators have backbone routers with 10's of 10GbE ports and maybe even a few 40 or 100GbE ports at this point, perhaps a variety of SONET still, etc. Are you suggesting that they should purchase a 10/100/1000 copper card just for management? Or are you suggesting that they should buy 10GbE switches for their out of band management network? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Wed, Apr 24, 2013 at 7:17 PM, Brandon Ross br...@pobox.com wrote: On Wed, 24 Apr 2013, Pavel Lunin wrote: This is what I never understood. Why people want to use fxp0 (or any other dedicated management) iface for real production management? Are you suggesting that they should purchase a 10/100/1000 copper card just for management? Or are you suggesting that they should buy 10GbE switches for their out of band management network? No, he's questioning the wisdom of doing SNMP queries, and other automated, routine management functions, against fxp0 instead of an interface that is protected by the hardware CoPP. One of my clients uses an NMS that sometimes starts sending ~3k PPS of SNMP BulkGets to a router. They don't know why. If that traffic was hitting fxp0 with no policer, etc. then it would consume a lot of CPU. My view is that fxp0 is an out-of-band interface for manual intervention; not one that I ever use for SNMP. -- 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
[j-nsp] J/SRX ICMP handling
Hi all, This post relates to a previous post of mine on asymmetrically routed UDP traffic: https://puck.nether.net/pipermail/juniper-nsp/2012-December/024878.html It seems as though a J/SRX in flow mode will drop ICMP packets such as unreachable and ttl-exceeded if, after consulting the session table, an entry corresponding to the header embedded in the ICMP packet is not found. In other words, I'm gonna drop any ICMP packets[1] I see if I didn't handle the associated conversation. Assume I send a UDP packet between hosts A and D and it's routed outbound via SRX B, and for whatever reason an ICMP unreachable or ttl-exceeded is generated (think traceroute). If that ICMP packet is sent towards host D not via SRX B but via SRX C, SRX C drops it: (src/dst IPs replaced with A and D) Jan 23 14:53:45 14:53:44.938394:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT: st0.1033:D-A, icmp, (3/3) Jan 23 14:53:45 14:53:44.938424:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT: find flow: table 0x63ce7688, hash 494060(0x7), sa D, da A, sp 33438, dp 47488, proto 17, tok 7 Jan 23 14:53:45 14:53:44.938483:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT: packet dropped, no session found for embedded icmp pak Jan 23 14:53:45 14:53:44.938495:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT: flow find session returns error. Seems like perfectly reasonable behaviour for a firewall, right? Right, except when it's not :-) Can this behaviour be modified without fully or selectively running in packet mode? I'm running JUNOS 10.4R11. Cheers, Dale [1] Well, any ICMP packets that include a copy of the original datagram's header: echo request/reply are forwarded (subject to being permitted by security policy, of course). ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
