Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
(resending with nanog-approved address..) On 18. jan. 2013 01:30, Jeff Kell wrote: On 1/17/2013 6:50 PM, Owen DeLong wrote: Vonage will, in most cases fail through CGN as will Skype, Xbox-360, and many of the other IM clients. Not sure about Vonage, but Skype, Xbox, and just about everything else imaginable (other than hosting a server) works just fine over NAT with default-deny inbound here, and we have several thousand students in the dorms that bang the heck out of those services. Most applications have adapted to the SOHO NATing router that is prevalent today on broadband internet. And if it didn't work, believe me, I'd hear about it :) Your users must have fairly low expectations :-) That snide comment aside, a single level of NAT44 works OK now for most current consumer level applications. But this is about multiple levels of NAT, where the usual "hacks" with UPNP IGD/NAT-PMP to get inbound ports are not likely to work. Even if you dont support these tricks on your end today, its likely that it is supported at the other side. Most "p2p" traffic like Skype only needs the mapping to work at one end, as they have to signal/negotiate addresses and portnumbers through some third party anyway. So currently, even double NAT at one end, it is likely to work out (within the current expectations of users.) When CGN gets to critical mass, where both ends of a connection is likely to be even more crippled than today*, things change. Now you have to bounce all the data of some third party, like a DC, maybe not even on the same continent. When Skype fails to map ports at both ends today the experience is pretty horrible actually, at least over here, even with the backing of Microsofts infrastructure. Also makes me wonder how expensive running such services will become (Only feasable for Google and Microsoft?) * Some support for mapping ports at CGN is in development, but requires new or updated CPE/home gateways, software support/awareness and support for it in the CGN (riiight.)
Re: High throughput bgp links using gentoo + stipped kernel
On 18. mai 2013 17:39, Nick Khamis wrote: Hello Everyone, We are running: Gentoo Server on Dual Core Intel Xeon 3060, 2 Gb Ram Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (rev 03) 2 bgp links from different providers using quagga, iptables etc We are transmitting an average of 700Mbps with packet sizes upwards of 900-1000 bytes when the traffic graph begins to flatten. We also start experiencing some crashes at that point, and not have been able to pinpoint that either. I was hoping to get some feedback on what else we can strip from the kernel. If you have a similar setup for a stable platform the .config would be great! Also, what are your thoughts on migrating to OpenBSD and bgpd, not sure if there would be a performance increase, but the security would be even more stronger? This is some fairly ancient hardware, so what you can get out if it will be limited. Though gige should not be impossible. The usual tricks are to make sure netfilter is not loaded, especially the conntrack/nat based parts as that will inspect every flow for state information. Either make sure those parts are compiled out or the modules/code never loads. If you have any iptables/netfilter rules, make sure they are 1) stateless 2) properly organized (cant just throw everything into FORWARD and expect it to be performant). You could try setting IRQ affinity so both ports run on the same core, however I'm not sure if that will help much as its still the same cache and distance to memory. On modern NICS you can do tricks like tie rx of port 1 with tx of port 2. Probably not on that generation though. The 82571EB and 82573E is, while old, PCIe hardware, there should not be any PCI bottlenecks, even with you having to bounce off that stone age FSB that old CPU has. Not sure well that generation intel NIC silicon does linerate easily though. But really you should get some newerish hardware with on-cpu PCIe and memory controllers (and preferably QPI). That architectural jump really upped the networking throughput of commodity hardware, probably by orders of magnitude (people were doing 40Gbps routing using standard Linux 5 years ago). Curious about vmstat output during saturation, and kernel version too. IPv4 routing changed significantly recently and IPv6 routing performance also improved somewhat.
Re: High throughput bgp links using gentoo + stipped kernel
(oops, I keep forgetting to send with my nanog identity..) On 19. mai 2013 17:48, Nick Khamis wrote: We do use a statefull iptables on our router, some forward rules... This is known to be on of our issues, not sure if having a separate iptables box would be the best and only solution for this? Ah, statefullness/conntrack .. once you load it you kinda lost already.. Sorry. Any gains from other tunables will likely be dwarfed by the cpu cycles spent by the kernel to track all connections. The more diverse the traffic the more it will hurt. Connection tracking is just inherently non-scalable (and fragile - by the way.) However, the cheapest and simplest is probably just to throw more modern hardware at it. A Xeon E3 (or two for redudancy ;)) is quite cheap.. The long term, scalable solution is a deeper network like you hinted at, with statefullness - if really needed at all - pushed as close to your edge and as far away from your border as possible. But.. More boxes, more to manage, more power, more stuff that can fail, more redudancies needed.. adds up. Then again if you are close to gig actual traffic already, you might want to at least think about future scalability.. Any ideas of the setup??? Maybe as far as naming some chipset, interface? And xserver that is the best candidate. Will google.. :) The big shift to integrated (and fast) I/O happened around 2008 IIRC, anything introduced after that is usually quite efficient at moving packets around, at least if Intel based. Even desktop i3/i5/i7 platforms can do 10gig as long as you make sure you put the network chips/cards on the cpu pcie controllers lanes. With anything new its hard to go wrong. xserver?? xserve? That is quite old.. Curious about vmstat output during saturation, and kernel version too. IPv4 routing changed significantly recently and IPv6 routing performance also improved somewhat. Will get that output during peak on monday for you guys. Newest kernel 3.6 or 7... Good. That is at least fairly recent and has most of the more modern networking stuff (and better defaults)
Re: High throughput bgp links using gentoo + stipped kernel
Minor nitpicking I know.. On 20. mai 2013 01:23, Ben wrote: With Linux you have to disable reverse path filtering, screw around with iptables to do bypass on stateful filtering. You dont have to "screw around" with iptables. The kernel wont load the conntrack modules/code unless you actually try to load stateful rulesets*. rp filtering on by default I'd also argue is the better default setting, for the 99% of other usecases :-P With quagga I would tend to agree - but as you I have not used it ages and things do change for the better over time -- occasionally. * you CAN configure your kernel to always load it, but that is silly.
Re: Typical additional latency for CGN?
On 08. okt. 2012 11:27, Daniel Roesen wrote: On Sun, Oct 07, 2012 at 03:18:56PM -0700, Cameron Byrne wrote: On Oct 7, 2012 1:48 PM, "Tom Limoncelli" wrote: Have there been studies on how much latency CGN adds to a typical internet user? I'd also be interested in anecdotes. Anecdote. Sub-millasecond, with full load. (gigs and gigs) . CGN does not meaningfully add latency. CGN is not enough of a factor to impact happy eyeballs in a way that improves ipv6 use. Confirmed by my experience. Latency of the CGN's themselfes are not going to be significant if it is properly scaled and configured. Most of the added latency will be in the network path to it, depending on how the CGN's are deployed relative to the path that particular flow normally would go and how big your network is. A small detour within a DC is obviously not very noticable for most. However if you're skipping peering oppurtunities and such closer to the customer when using a big central CGN, that clearly becomes sub-optimal in terms of network performance.
Re: Linux: concerns over systemd adoption and Debian's decision to switch
On 22. okt. 2014 03:40, Matt Palmer wrote: > On Tue, Oct 21, 2014 at 07:20:12PM -0500, Jimmy Hess wrote: >> Yikes. What's next? Built-in DNS server + LDAP/Hesiod + Kerberos + >> SMB/Active Directory client and server + Solitaire + Network >> Neighborhood functionality built into the program ? > > You missed "font renderer". > https://technet.microsoft.com/library/security/ms14-058 I am not convinced having font rendering *IN THE KERNEL* is much better for security.. and I doubt they put it in pid 1. Now, should consoled, the new ntp and dhcp services have been stuffed into the systemd tarball.. I dont know.
.biz DNSSEC borked
Seems the entire .biz tld is failing DNSSEC validation now. All of my DNSSEC validating resolvers are tossing all domains in .biz. The non-signed domains too of course because trust of the tld itself cannot be established. http://dnssec-debugger.verisignlabs.com/nic.biz
Re: .biz DNSSEC borked
On 22. juni 2013 20:45, Andre Tomt wrote: Seems the entire .biz tld is failing DNSSEC validation now. All of my DNSSEC validating resolvers are tossing all domains in .biz. The non-signed domains too of course because trust of the tld itself cannot be established. http://dnssec-debugger.verisignlabs.com/nic.biz Looks like it is clearing up now. Flushing the caches of your resolvers might be wise. I wonder who made the boo-boo
Re: If you're on LinkedIn, and you use a smart phone...
On 26. okt. 2013 08:06, Jimmy Hess wrote: Perhaps a prudent countermeasure would be to redirect all POP, IMAP, and Webmail access to your corporate mail server from all of LinkedIn's IP space to a "Honeypot" that will simply log usernames/credentials attempted. The list of valid credentials, can then be used to dispatch a warning to the offender, and force a password change. This could be a useful proactive countermeasure against the UIT (Unintentional Insider Threat); of employees inappropriately entering corporate e-mail credentials into a known third party service with outside of organizational control. Seeing as Linkedin almost certainly is not providing signed NDAs and privacy SLAs; it seems reasonable that most organizations who understand what is going on, would not approve of use of the service with their internal business email accounts. Depends on linkedin beeing nice, but could this be an idea? In addition to the proposed network level controls of course. At least users could get a informative response rather than just some dumb error / "it doesnt work" if you block Intro. http://feedback.intro.linkedin.com/forums/227301-linkedin-intro-feedback/suggestions/4801236-some-way-to-block-intro-per-domain Votes maybe? I considered proposing making it opt-in on the domain level, but that wont fly for them I'm sure.
Re: Mikrotik Cloud Core Router and BGP real life experiences?
On 27. des. 2013 17:26, Jim Shankland wrote: Routing table size was completely not an issue in our environment; we were looking at a number of concurrent flows in the high-5 to low-6-digit range, and since Linux uses a route cache, it was that number, rather than the number of full tables we carried, that was important. FYI, Linux no longer has a routing cache, so any performance numbers with the cache in place is void on modern kernels. It was deemed too fragile, handled mixed traffic badly, and was way easy to DoS. It wasnt simply just ripped out of course, the full lookups was made way faster and a bunch of scalability issues got plugged in the process. All in all, in PPS, Linux should now handle mixed traffic much better, but less diverse traffic patterns might be a little slower than before. However, all in all, much more consistent and predictable. Not everything is peachy though, there are still some cases that sucked last I checked. Running tons of tunnels beeing one. Multicast rx was severely gimped for a while after the removal, but that got fixed.
