- NANOG - lists.nanog.org

real hardware router VS linux router
by Deric Kwok 18 Mar '09

18 Mar '09

Hi All Actually, what is the different hardware router VS linux router? Have you had experience to compare real router eg: cisco VS linux router? eg: streaming speed... tcp / udp Thank you for your information

47 74

Off topic contact needed for Sangoma
by J. Oquendo 18 Mar '09

18 Mar '09

Apologies all, does anyone have a security contact on the network side for Sangoma. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "Enough research will tend to support your conclusions." - Arthur Bloch "A conclusion is the place where you got tired of thinking" - Arthur Bloch 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E

1 0

Leap second tonight
by Kevin Day 18 Mar '09

18 Mar '09

Just a reminder that there's a leap second tonight. Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+… I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours. -- Kevin

20 27

RIPE NCC Regional Meeting/MENOG 4: Updated Agenda
by Paul Rendek 18 Mar '09

18 Mar '09

[Apologies for duplicate emails] Dear Colleagues, Join us at the RIPE NCC Regional Meeting/MENOG 4 in Manama, Bahrain, on 5–9 April 2009 at the Mövenpick Hotel. This unique event for network operators and network engineers from the Middle East offers an exciting opportunity for you and your peers to discuss cross-regional issues, share experiences and meet with key players in the local and global Internet industry. This meeting includes tutorials, conference sessions and social events as well as two special world-class workshops on Routing and IPv6 for network operators and engineers from the Middle East. These three-day interactive workshops include a full lab designed for network engineers and operators who are running existing ISP infrastructure. Agenda ----------- The meeting agenda has been *updated* and is available online at: http://www.menog.net/meetings/menog4/agenda.php Registration ------------ The tutorials, conference sessions and social dinner are free to attend and are open to everyone. The special three-day workshops on Routing and IPv6 for network operators and engineers from the Middle East require an attendance fee of €235 per workshop. The workshops run from Sunday through Tuesday, 5-7 April. The meeting takes place in three weeks time, so please register now at: http://www.menog.net/dyn.php?page=menog4registration Meeting Venue and Accommodation ------------------------------- Rooms at the Mövenpick Hotel have been reserved at a special discounted rate for attendees. You must act by 22 March to secure a room at our special meeting rate! Room Rate per night: Single room is BD 85 Double room is BD 95 The booking form and details about the hotel can be found at: http://www.menog.net/meetings/menog4/venue.php We look forward to meeting you and your colleagues at the RIPE NCC Regional Meeting/MENOG 4. Please extend this invitation to anyone you feel may be interested in participating in this event. If you have any questions, please email <menog-sec(a)menog.net>. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC On behalf of the RIPE NCC Regional Meeting/MENOG 4 Organisers

1 0

SUP720 vs. SUP32
by Bill Blackford 18 Mar '09

18 Mar '09

Anyone have any experience with SUP32? Please contact me off list. I'm trying to evaluate a lower-cost alternative to the 720-3bxl. I'm only pushing a few hundred megs of traffic, exchanging a few routes with less than 20 peers and don't see the need for a 720's worth of throughput in the near future. Can the 32 handle a full table? How does the MFSC2A compare to the MFSC3? V6 support? Thank you. -- Bill Blackford Senior Network Engineer my /home away from home

8 12

Re: Origin ASN seen vs Origin ASN in Whois Records Report?
by K. Sriram 18 Mar '09

18 Mar '09

Heather: This prior question from you (November 2008) was recently brought to our attention. Sorry about this delayed response, but we thought it would still be worthwhile to share pointers to some work that we are doing at NIST which relates closely to your question. Earlier Bill Woodcock provided you with a link where the actual discrepancies are listed. Our work at NIST focuses on the statistics of such anomalies, with the intention of: (A) generating score cards for accuracy/consistency of various registries, and (B) to glean the "good" data from what is available so that BGP robustness algorithms that rely on the data can work more effectively. We have done an analysis of registry information (RIRs, IRRs, RADB) and compared it with that from trace data (RIBs, update history) from RIPE-RIS and routeviews. We generate a variety of statistics on a per RIR basis (ARIN, RIPE, etc.) regarding whether announced {prefix, origin AS} pairs in updates correspond with those in the registries. We also report on whether the registered objects (NetHandle and AShandle in SWIP format and inetnum, aut-num, and route in RPSL format) appear self-consistent or not. We also looked at the NetHandles in ARIN that contain origin AS information, and have performed comparisons of those with what was historically seen in BGP updates for prefixes belonging to the ARIN region. A variety of results and discussion related to all this are presented in this set of slides: http://www.antd.nist.gov/bgp_security/publications/ARIN_NetHandle_OriginAS_… You may also look into a presentation we made in January at NANOG-45. There the focus was on BGP robustness algorithms that make combined use of filtered "good" data from registries as well as long-term trace data. http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTE5NSZuYW5vZzQ1&nm=… Here is a link for a detailed published paper related our NANOG-45 presentation: http://www.antd.nist.gov/pubs/NIST_BGP_Robustness.pdf (This paper was published in the Proceedings of DHS S&T CATCH 2009 conference.) Please let me know if you have any specific questions concerning the above. We are very interested in receiving feedback on how this work can be made more useful from the perspective of what ISP needs are. Sriram K. Sriram +1 301 975 3973 http://www.antd.nist.gov/~ksriram/ ----------------------------------------------------- >From nanog-bounces(a)nanog.org Wed Nov 19 19:14:58 2008 Date: Wed, 19 Nov 2008 19:16:43 -0500 From: Heather Schiller <heather.schiller(a)verizonbusiness.com> Subject: Origin ASN seen vs Origin ASN in Whois Records Report? To: gih(a)apnic.net, nanog <nanog(a)nanog.org>, info(a)BGPmon.net I don't know if a report like this already exists, but I haven't been able to find one. Can someone (CIDR Report? BGPMon? PCH?) offer a report that shows the discrepencies in Origin ASN according to the whois records, and routes in the [global/public] routing table? Publishing it on some regular interval would be even better. ARIN makes available a list of prefixes with OriginAS. I don't know if other RIR's do. ftp://ftp.arin.net/pub/originAS/ To be clear. I want a list of the prefixes where the actual origin ASN seen does not match the one in the whois record. Inconsistent Origin is fair game here. As a transit provider I'm interested in seeing what prefixes I am transiting for my customers that have this discrepancy, so something that shows the full path as part of the results would be most helpful. Thanks, --Heather

1 0

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