- Test - lists.nanog.org

Shady areas of TCP window autotuning?
by Marian Ďurkovič 18 Mar '09

18 Mar '09

Hi all, TCP window autotuning is part of several OSs today. However, the actual implementations behind this buzzword differ significantly and might impose negative side-effects to our networks - which I'd like to discuss here. There seem to be two basic approaches which differ in the main principle: #1: autotuning tries to set rx window to a sensible value for a given RTT #2: autotuning just ensures, that rx window is always bigger than congestion window of the sender, i.e. it never limits the flow While both approaches succeed to achieve high throughput on high-RTT paths, their behaviour on low-RTT paths is very different - mainly because the fact, that #2 suffers from "spiraling death" syndrome. I.e. when RTT increases due to queueing at the bottleneck point, autotuning reacts by increasing the advertised window, which again increases RTT... So the net effect of #2 is, that after very short TCP connection lifetime it might advertise extermely huge RX window compared to BDP of the path: RTT when idle Max advertised window #1 Max advertised window #2 ---------------------------------------------------------------------- < 1 msec 66560 byte 3 Mbyte 3 msec 66560 byte 3 Mbyte 12 msec 243200 byte 3 Mbyte 24 msec 482048 byte 3 Mbyte (The above data were taken from the same host connected by 100 Mpbs ethernet to the network while running two OSs with different approaches and transferring 1 GByte of data) It's obvious, that #2 has significant impact on the network. Since it advertises really huge window, it will fill up all buffers at the bottleneck point, it might increase latency to >100 msec levels even at LAN context and prevent classic TCP implementations with fixed window size from getting a fair share of bandwidth. This however doesn't seem to be of any concern for TCP maintainers of #2, who claim that receiver is not supposed to anyhow assist in congestion control. Instead, they advise everyone to use advanced queue management, RED or other congestion-control mechanisms at the sender and at every network device to avoid this behaviour. My personal opinion is that this looks more like passing the problem to someone else, not mentioning the fact, that absolutely trusting the sender to perform everything right and removing all safety-belts at the receiver could be very dangerous. What do people here think about this topic? Thanks & kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian Ďurkovič network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 571 041 81 ---- ---- Computer Centre, Nám. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md(a)bts.sk ---- ---- ---- --------------------------------------------------------------------------

12 16

BGP nexthop-self vs. EIGRP redistribution
by phil＠mindfury.net 18 Mar '09

18 Mar '09

...which is better? We recently ran into what looks like an implementation flaw in our network design. After moving two GbE connections with Savvis (same edge device on both ends) into EBGP-multihop, we were encountering problems with iBGP churn. The network design is two buildings in the same AS, each building has two core switches, which are in a full iBGP mesh, and acting as route-reflectors for four border switches. Two border switches are in one building, the other two in the other building. The layout is shown here: http://img17.imageshack.us/img17/6562/bgplayout.jpg EIGRP is being used as the IGP, now border4 is the the newest switch to have been installed, and in it's EIGRP configuration, static and connected routes were being redistributed. The other border switches, however were not redistributing. They were using next-hop-self in their iBGP announcements to the cores. We ended the iBGP churn issue by changing border4 to use next-hop-self to cores 3 and 4. My question is, which is the correct method of implementing this? Should we be redistributing static and connected routes on our borders into IGP, and not using next-hop-self? Or should we not redistribute and use next-hop-self? -- Philip L.

5 5

Anyone using any Linux SSL proxies?
by Mike Lyon 18 Mar '09

18 Mar '09

Howdy, I am wondering what folks are recommending/using these days for Linux SSL proxies? I need to build a linux box that basically acts as an SSL offloader would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, decrypt the SSL and then forward the request onto the webserver on port 80. DSR is not required. Any suggestions? Offlist replies would probably be more appropriate. Thank You in advance. Cheers, Mike

7 6

Myspace NOC contact me please
by Leslie 17 Mar '09

17 Mar '09

I have already tried calling +1-310-215-1001 which is not in service as well as emailing peering(a)myspace.com and noc(a)myspace.com and checking peeringdb.com for any other contact info. Thanks Leslie Carr Craigslist also at 415/566-6394 x140

1 0

ADMIN: List FAQ/Monthly Post.
by NANOG Mail List Committee 17 Mar '09

17 Mar '09

This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins(a)nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins(a)nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php

1 0

Pro-actively publishing IRR data
by Steve Bertrand 16 Mar '09

16 Mar '09

I'm still working on trying to get my primary provider to BGP peer with us, but in the meantime, I'd like to pro-actively publish our objects and route policy to the IRR. My primary provider is currently advertising our IPv4 routes for us from their AS. Are there any potential dangers of publishing our information before we use it that I may be overlooking? Steve

2 2

AT&T Wireless Data Contact
by James Ribar 16 Mar '09

16 Mar '09

Hi, Our half or dozen or so iPhone users are experiencing issues with accessing our corporate website and email services. I spoke to AT&T's support who after a few minutes told me it wasn't an ATT problem and forwarded me to Apple who said it was an issue with the website and were unable to help. I have verified that the website and email in question work just fine when connecting from other networks, ruling out in my book an issue on our end. As far as I can tell the issue seems to be with AT&T's DNS servers which are not resolving our domains properly. Accessing services by IP address works fine. In an effort to avoid being bounced back and forth on the phone all day between AT&T and Apple, is there anyone that can contact me off list who is able to help with this issue or point me in the right direction? Thanks, James

1 0

Netflow on SUP720-3BXL
by Andy Bierlair 16 Mar '09

16 Mar '09

I’m trying to run netflow on one of our Cisco core routers (SUP720-3BXL), but I think I am hitting some limitations because of this: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [99%] The setup of netflow looks like this: ip flow-cache entries 524288 mls aging fast time 5 threshold 32 mls aging long 300 mls aging normal 60 mls netflow usage notify 80 300 mls flow ip full no mls flow ipv6 mls nde sender version 5 no mls verify ip checksum no mls acl tcam share-global ip flow-export source Loopback0 ip flow-export version 5 origin-as ip flow-export destination <ip> <port> Then I have this enabled on all border interfaces/vlans (peering / transit / other core routers) that are of interest for my stats: ip route-cache flow Some more details about the problem: #sh mls netflow table-contention detailed Earl in Module 5 Detailed Netflow CAM (TCAM and ICAM) Utilization ================================================ TCAM Utilization : 100% ICAM Utilization : 13% Netflow TCAM count : 262033 Netflow ICAM count : 17 Netflow Creation Failures : 4822220 Netflow CAM aliases : 1 #sh mls netflow table-contention aggregate Earl in Module 5 Aggregate Netflow CAM Contention Information ============================================= Netflow Creation Failures : 130003616 Netflow Hash Aliases : 4 I understand that the TCAM is full, but what can I do against it? This is a busy core router: Aggregated traffic: 7-8 GBIT/s Packets per Second: 1.0 - 1.2 Million I wouldn't mind analyzing only every 10th or 100th flow, which seems to be a common practice. Any good piece of advice is welcome. Thanks! - Andy

4 3

Dynamic IP log retention = 0?
by Brett Charbeneau 16 Mar '09

16 Mar '09

I've been nudging an operator at Covad about a handful of hosts from his DHCP pool that have been attacking - relentlessly port scanning - our assets. I've been informed by this individual that there's "no way" to determine which customer had that address at the times I list in my logs - even though these logs are sent within 48 hours of the incidents. The operator advised that I block the specific IP's that are attacking us at my perimeter. When I mentioned the fact that blocking individual addresses will only be as effective as the length of lease for that DHCP pool I get the email equivalent of a shrug. "Well, maybe you want to ban our entire /15 at your perimeter..." I'm reluctant to ban over 65,000 hosts as my staff have colleagues all over the continental US with whom they communicate regularly. I realize these are tough times and that large ISP's may trim abuse team budgets before other things, but to have NO MECHANISM to audit who has what address at any given time kinda blows my mind. Does one have to get to the level of a subpoena before abuse teams pull out the tools they need to make such a determination? Or am I naive enough to think port scans are as important to them as they are to me on the receiving end? -- ******************************************************************** Brett Charbeneau, GSEC Gold, GCIH Gold Network Administrator Williamsburg Regional Library 7770 Croaker Road Williamsburg, VA 23188-7064 (757)259-4044 www.wrl.org (757)259-4079 (fax) brett(a)wrl.org ********************************************************************

34 57

Re: Netflow on SUP720-3BXL
by Andy Bierlair 15 Mar '09

15 Mar '09

yes ip cef, this is enabled: IP fast switching is enabled IP fast switching on the same interface is disabled IP Flow switching is enabled IP CEF switching is enabled IP Flow switching turbo vector IP Flow CEF switching turbo vector and so on... - Andy On Sun, Mar 15, 2009 at 3:08 AM, Bill Blackford <BBlackford(a)nwresd.k12.or.us> wrote: > > just a shot in the dark. Do you have 'ip cef' in global config? > > -b > ________________________________________ > From: Andy Bierlair [globichen(a)gmail.com] > Sent: Saturday, March 14, 2009 6:55 PM > To: nanog(a)nanog.org > Subject: Netflow on SUP720-3BXL > > I’m trying to run netflow on one of our Cisco core routers (SUP720-3BXL), > but I think I am hitting some limitations because of this: > > > > %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM > Utilization [99%] > > > > The setup of netflow looks like this: > > > > ip flow-cache entries 524288 > > mls aging fast time 5 threshold 32 > > mls aging long 300 > > mls aging normal 60 > > mls netflow usage notify 80 300 > > mls flow ip full > > no mls flow ipv6 > > mls nde sender version 5 > > no mls verify ip checksum > > no mls acl tcam share-global > > > > ip flow-export source Loopback0 > > ip flow-export version 5 origin-as > > ip flow-export destination <ip> <port> > > > > Then I have this enabled on all border interfaces/vlans (peering / transit / > other core routers) that are of interest for my stats: > > > > ip route-cache flow > > > > Some more details about the problem: > > > > #sh mls netflow table-contention detailed Earl in Module 5 Detailed Netflow > CAM (TCAM and ICAM) Utilization > ================================================ > > TCAM Utilization : 100% > > ICAM Utilization : 13% > > Netflow TCAM count : 262033 > > Netflow ICAM count : 17 > > Netflow Creation Failures : 4822220 > > Netflow CAM aliases : 1 > > > > > > #sh mls netflow table-contention aggregate Earl in Module 5 Aggregate > Netflow CAM Contention Information > ============================================= > > Netflow Creation Failures : 130003616 > > Netflow Hash Aliases : 4 > > > > > > I understand that the TCAM is full, but what can I do against it? This is a > busy core router: > > > > Aggregated traffic: 7-8 GBIT/s > > Packets per Second: 1.0 - 1.2 Million > > > > I wouldn't mind analyzing only every 10th or 100th flow, which seems to be a > common practice. > > > > Any good piece of advice is welcome. > > > > Thanks! > > > > - > Andy

2 1