- Test - lists.nanog.org

Re: XO feedback
by Net 05 Jul '10

05 Jul '10

Thanks for reaching out Brian. We'll certainly keep Saavis in mind and advise as deemed fit. Regards, On 7/1/10, Bellis, Brian <Brian.Bellis(a)savvis.net> wrote: > Dear Funky Fun, > > Have you consider Savvis for IP transit. We are a Tier 1 IP backbone > provider operating AS-3561. We announce approximately 23% of all > internet routes on our backbone and are privately peered with all other > Tier 1 providers meaning we don't buy upstream to gain access to routes. > We are very price competitive and offer fixed and burstable pricing. We > are located in virtually every telehouse across the US and have PoPs in > London, Paris, Frankfurt and Amsterdam. > > No pressure here and no need to respond if you are not interested. Just > wanted to give you another option you may have not considered. Thank > you. > > Best regards, > > Brian > > > > Brian Bellis | Sr. Sales Director Service Providers > > > > Savvis > 2355 Dulles Corner Blvd, Herndon, VA 20171 > Office: 703.667.6254 | Mobile: 202.997.1336 | Fax: 703.880.7239 > > E-mail: brian.bellis(a)savvis.net > > www.savvis.net > > > > > -----Original Message----- > From: Net [mailto:funkyfun@gmail.com] > Sent: Thursday, July 01, 2010 7:52 AM > To: nanog(a)nanog.org > Subject: XO feedback > > Hi, > > We're currently looking to buy transit from XO for one of our DCs. > Their pricing is very competative compared to some of the other > providers we've considered to date. > > I'm hoping to get some feedback on their services, support, peering > arrangements and the overall stability of their core backbone network > from folks who've had experience or currently using them. > > Any info would be greatly appreciated. > > Thanks in advance > > -- > Sent from my mobile device > > > This message contains information which may be confidential and/or > privileged. Unless you are the intended recipient (or authorized to receive > for the intended recipient), you may not read, use, copy or disclose to > anyone the message or any information contained in the message. If you have > received the message in error, please advise the sender by reply e-mail and > delete the message and any attachment(s) thereto without retaining any > copies. > -- Sent from my mobile device

6 6

Re: Mikrotik & OC-3 Connection
by msokolov＠ivan.Harhan.ORG 05 Jul '10

05 Jul '10

Adrian Chadd <adrian(a)creative.net.au> wrote: > FreeBSD netgraph. It's clean, it's generalised, it's just not very well > documented. > [...] > Have a chat to the FreeBSD community. There's a powerpc port. Shoehorn > FreeBSD into it somehow, help tidy up the code to do whateveer you need > and start leveraging the very powerful network stack FreeBSD has. Thanks for the tip - that sounds very nice indeed, very much like what I had in mind. It's nice to know that *someone* in the generic free OS world has had the foresight to design this thing right. (Just to be clear, I have no political preferences between Linux and FreeBSD; to me it's all a matter of what works and what I'm familiar with.) But it won't matter until I build the hardware: I want to build the hardware first, the HW itself will be totally open source as in free schematics and full docs etc, and then we'll think about which free OS(es) we want to run on it. I still want to build my MPC866 router platform though: even if the software part has been solved by the fine FreeBSD folks, with the present situation (PCI as the expansion interface on FreeBSD/Linux-based routers) one still has the issue that the HDLC interface or the ATM SAR block has to be wheel-reinvented each time someone wants a different flavor of Layer 1 physical interface. The situation is even more pronounced when a given Layer 1 medium type (say, T1 or SDSL) exists in both HDLC and ATM flavors. I would really like to be able to have a single hardware card that supports both: it is trivial with MPC86x, but I expect it to be cost-prohibitive to do that on a PCI card. MS

1 0

Re: Mikrotik & OC-3 Connection
by msokolov＠ivan.Harhan.ORG 05 Jul '10

05 Jul '10

OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router thread. To make it clear where I'm coming from, I see the networking world from the viewpoint of non-Ethernet WAN interfaces. A world consisting of nothing but Ethernet is too bland and boring for me to live in, and I choose not to live in such an Ethernet-only world. I do indeed like the good old ifconfig & route better than Cisco IOS stuff: it's simpler, makes more sense to me, and fits my simple needs. However, this model works well for Ethernet because it's very simple: with Ethernet one generally has a 1:1 correspondence between the physical hardware unit and the logical "network interface" unit visible to ifconfig and the rest of the BSD/Linux network stack. But that is most definitely not the case for non-Ethernet WAN interfaces, and that is where I see a big shortcoming in what's currently available in the Linux router world. With non-Ethernet WAN interfaces one really needs an extra layer of highly configurable software functionality sandwiched in between the hardware interface unit and the ifconfig layer. The physical hardware interface is a synchronous serial bit stream processor that sends and receives either HDLC frames or ATM cells, and that is where the hardware-dictated part ends. Let's take the case of HDLC as it's more pleasant than ATM: in the case of HDLC the software layer between the HDLC controller and the ifconfig layer needs to do the following: * Let the user choose the encapsulation, and there are many choices: Cisco HDLC, straight PPP (RFC 1662), Frame Relay, PPP over FR (RFC 1973), ATM FUNI, etc. * If it's a Frame Relay encapsulation, let the user configure DLCIs. Oh, and there can be more than one, hence there may be multiple ifconfig-able entities on the same FR interface. * RFC 1490 (FR) and RFC 1483 (ATM) both allow bridged/MAC-encapsulated and true routed circuits; our software layer should support both, as as well as the possibility of mixing the two on different FR interfaces or different DLCIs on the same interface. These two modes need to look different to the ifconfig layer: if it's a bridged encapsulation, ifconfig needs to see a virtual Ethernet interface ("virteth0" or "macwan0"); if it's a true routed encapsulation, ifconfig needs to see a MAC-less and ARP-less point-to-point interface like "ipwan0". * Now let's support both HDLC and serial ATM (bit-by-bit cell delineation) if the underlying hardware is capable of both (like Freescale MPC862 and MPC866). Let's provide a user to switch between the two with a simple software command, and let's provide as much commonality as possible between the two configurations: let's support all RFC 1483 encapsulations on HDLC via FUNI, but make the configuration commands look just like ATM. Let's also support FRF.5 by allowing one to take an ATM PVC and treat its payload as a virtual HDLC interface, with possibly many FR DLCIs inside. I would love to be corrected on this, but I am not aware of anyone having implemented all of the above for Linux (or for any BSD variant) in a clean and generalized manner. Instead what we see is that each vendor of a PCI card for some non-Ethernet WAN interface has their own ad hoc solution which typically comes nowhere close to what I've outlined above in terms of generality and flexibility. Now here is something I'd like to build which will attempt to solve this mess. I'd like to build a modular WAN router based on the MPC866 chip from Freescale, former Motorola. MPC866 is a PowerPC with one very neat twist: it has 4 serial communication controller (SCC) cores on chip. Each SCC has a traditional 7-wire serial interface coming out of it (Rx data, Rx clock, Tx data, Tx clock, RTS, CTS and CD) and supports both HDLC and serial ATM. (The serial ATM mode supports both bit-by-bit cell delineation for a raw bit stream and octet-by-octet cell delineation for use with a framer that provides octet boundaries.) My modular router would be rather unique in that the interface to the pluggable WAN modules would not be PCI or anything of that sort, instead it would be the 7-wire serial interface coming from an MPC866 SCC, and there would be 4 possible daughtercard slots corresponding to the 4 SCCs. When the interface for pluggable WAN modules is something like PCI, the HDLC or ATM (including SAR) core has to be reimplemented anew by everyone who wants to build a new WAN module for a different flavor of Layer 1 physical interface, and I find it wasteful. The proliferation of such reinvented-wheel HDLC/ATM reimplementations is precisely the reason why there is no universally-accepted standardized framework for non-Ethernet WAN interfaces in Linux or *BSD. But if the cores implementing HDLC and ATM SAR reside inside the CPU chip like they do with MPC86x processors, we can have ONE well-written generic driver for these cores, and it will work exactly the same way and provide exactly the same array of configurable Layer 2 options to the user regardless of which Layer 1 interface is used: we can build daughtercards for T1/E1, for SDSL, for T3/E3, etc, and the specialized circuitry on each of these daughtercards will only concern itself with Layer 1, not with HDLC or ATM SAR. I would greatly appreciate any leads/ideas/suggestions as to who might possibly be interested in funding such a project. :-) MS

2 1

The Economist, cyber war issue
by Gadi Evron 04 Jul '10

04 Jul '10

The upcoming issue will be about cyber war. Check out the front page image: http://sphotos.ak.fbcdn.net/hphotos-ak-snc3/hs488.snc3/26668_410367784059_6… Gadi.

6 8

Feds disable movie piracy websites in raids
by Michael Painter 04 Jul '10

04 Jul '10

As randy said not too long ago, First they came for... BURBANK, Calif. (AP) -- U.S. officials on Wednesday announced a major crackdown on movie piracy that involved disabling nine websites that were offering downloads of pirated movies in some cases hours after they appeared in theaters. Officials also seized assets from 15 bank, investment and advertising accounts, and executed residential search warrants in North Carolina, New Jersey, New York and Washington. Immigration and Customs Enforcement officials worked with the U.S. Attorney for the Southern District of New York and other government agencies. The investigation involved about 100 agents in 11 states and the Netherlands. Officials wouldn't say how many people were suspected of intellectual property theft, but said the penalties could include prison time. The raids were the first actions in a new "Operation In Our Sites" initiative to combat Internet counterfeiting and piracy. The government only seized domain names for the sites in question, however, meaning the computers that run the sites could still be used under a different name. http://www.technologyreview.com/wire/25690/?nlid=3195&a=f

10 13

Re: Mikrotik & OC-3 Connection
by Mike 04 Jul '10

04 Jul '10

Butch Evans wrote: > > More functionality from a Cisco? You MUST be joking. MT (and > ImageStream for that matter) can do WAY more than Cisco for a > fraction > of the price. Both will offer a much better firewall option, > infinitely > better QOS capability and is easily as good with dynamic routing > (BGP, > OSPF, etc.). What's more, you can have a spare on the shelf and > STILL > not spend as much money as you would for a Cisco device. > Yeah, that's what the brochure says anyways, but I don't know of many highly scaled networks using 'mikrotic' and some of the reasons come down to management, software stability and a readily available pool of knowledgeable admins ready to build the next google with it. Don't get me wrong - I believe in linux and am a network operator as well as embedded systems software developer who makes network appliances with it (linux) that do all of the above for use in my network of a 1000+ subscribers, and I sleep very well at night. However, that sleep comes with the price of having to be a linux guru in order to do most network config operations, and in the 8 years I have been eating my own dog food and running in my network now, I've not encountered many who I could successfully pass off network admin duties too for these boxes (quagga, iproute2, ebtables, iptables for instance) and centralized management and configuration control is non-existent. These commercial systems you scoff at also support advanced and important features such as online insertion/removal - which lets you take a card like a gigE switch module, or a fiber/sonet interface, or a ds3, and just plug it in and immediately without a reboot or driver searching/updating/missing dance, start working. Another important difference is that these commercial units are NOT hosts and don't have silly host/desktop type stuff going on within them, like periodic flash writes, file systems filling with junk that causes system hangs, or hundeds of other possible reasons and causes that create 'system down' on host type machines that DON'T affect the commercial boxes, and contribute (in theory anyways) to the continued prospect of very long uptimes and reliable operation. Also basic hardware features like dual and triple redundant power supplies, good fans and overall rugged design that further contribute to long lives (again in theory), that PC/x86 and other COTS SBC type hardware does not have. So in summary, for small jobs, yeah you're right, but once your jobs aren't small anymore and you need more of these features or business continuity becomes really critical, these commercial solutions are far more likely to take you there today. $0.02 Mike-

2 1

Inquiries to Acquire IPs
by Crist Clark 03 Jul '10

03 Jul '10

We got a strange and out of the blue inquiry from someone wishing to pay us for a chunk of our ARIN allocation, > Hello, > > According to Whois data, you company owns the following > IP address space: > > 206.220.220.0/24 > > We would like to get this block of IP addresses for our business > needs. Is it possible to assign this block for our company with > PI (Provider Independent) or PA (Provider Assigned) status? > > We ready to pay about $5,000 for the net block itself > and all related procedures. > > Would you be interested in such an offer? The amount of compensation > is subject to negotiation. We're not interested, mostly because we use our allocation, but also because I think this is not allowed by our agreement with ARIN. Seems a bit fishy. I should add the sender identified himself and his company clearly. It wasn't from some free mail account. (Although it could of course be spoofed.) Is this a new thing? IP speculation as we come upon free pool depletion? A front for spammers?

20 22

Finland makes broadband access a legal right
by Gadi Evron 02 Jul '10

02 Jul '10

http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt… Interesting...

12 13

OT: Career Advice
by Gerren Murphy 02 Jul '10

02 Jul '10

Hello All, Anyone out there willing to entertain a few career advice-related questions off list? Nothing too deep, I promise, just a little advice from those of you who have been in the industry a bit longer than I have? Thanks for any and all assistance, and have a great weekend.

1 0

BGP Update Report
by cidr-report＠potaroo.net 02 Jul '10

02 Jul '10

BGP Update Report Interval: 24-Jun-10 -to- 01-Jul-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6298 105080 6.2% 39.2 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 2 - AS9808 72242 4.2% 164.2 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 3 - AS24400 69052 4.1% 5754.3 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 4 - AS22773 23744 1.4% 14.5 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 5 - AS14420 23556 1.4% 49.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 6 - AS210 19720 1.2% 54.8 -- WEST-NET-WEST - Utah Education Network 7 - AS5800 17170 1.0% 79.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 8 - AS9116 15708 0.9% 29.7 -- GOLDENLINES-ASN 012 Smile Communications Main Autonomous System 9 - AS35931 13107 0.8% 2184.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 10 - AS32528 13049 0.8% 1631.1 -- ABBOTT Abbot Labs 11 - AS577 11432 0.7% 17.7 -- BACOM - Bell Canada 12 - AS10474 10432 0.6% 267.5 -- NETACTIVE 13 - AS18910 9606 0.6% 600.4 -- BIG-SANDY-BROADBAND-INC - Big Sandy Broadband Inc 14 - AS8151 9388 0.6% 6.1 -- Uninet S.A. de C.V. 15 - AS17974 9251 0.5% 8.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS45464 9109 0.5% 211.8 -- NEXTWEB-AS-AP Room 201, TGU Bldg 17 - AS7552 9069 0.5% 10.9 -- VIETEL-AS-AP Vietel Corporation 18 - AS14522 9053 0.5% 26.8 -- Satnet 19 - AS7459 7700 0.5% 32.1 -- GRANDECOM-AS1 - Grande Communications Networks, Inc. 20 - AS36992 7588 0.5% 11.7 -- ETISALAT-MISR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS24400 69052 4.1% 5754.3 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 2 - AS35931 13107 0.8% 2184.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS32528 13049 0.8% 1631.1 -- ABBOTT Abbot Labs 4 - AS30372 2446 0.1% 1223.0 -- SBS-NEWARK-CA - SIEMENS BUSINESS SERVICES 5 - AS11613 762 0.0% 762.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 6 - AS55482 1266 0.1% 633.0 -- DIGITAL-WAVE-MY Level 12 Menara Sunway, Jalan Lagoon Timur, 7 - AS18910 9606 0.6% 600.4 -- BIG-SANDY-BROADBAND-INC - Big Sandy Broadband Inc 8 - AS38596 288 0.0% 288.0 -- INNODATA-MDE-AS-PH Innodata-ISOGEN, Inc 9 - AS45936 285 0.0% 285.0 -- AE-MANILA-AS-AP Affinity Express 10 - AS9556 1697 0.1% 282.8 -- ADAM-AS-AP Adam Internet Pty Ltd 11 - AS10474 10432 0.6% 267.5 -- NETACTIVE 12 - AS28863 253 0.0% 253.0 -- THALES-TTLS Thales Transport and Security Ltd 13 - AS45598 1260 0.1% 252.0 -- BLUEMEDIACOM-PH Unit 503 5th Floor Net One Center 14 - AS21115 245 0.0% 245.0 -- AS-NESTLE NESTLE Autonomous System 15 - AS45647 486 0.0% 243.0 -- LBCBANK-AS-AP LBC Development Bank 16 - AS17894 5089 0.3% 242.3 -- APMI-AS-AP AyalaPort Makati, Inc. / Data Center Operator 17 - AS23964 241 0.0% 241.0 -- GLOBALSTRIDE-AS-AP Globalstride 18 - AS18249 481 0.0% 240.5 -- GLOBEIDC-AS-AP Globe Telecom Internet Data Center 19 - AS9821 240 0.0% 240.0 -- DOST-PH-AP Department of Science and Technology 20 - AS9232 240 0.0% 240.0 -- CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 111.10.4.0/24 14236 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 2 - 111.10.3.0/24 14231 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 3 - 111.10.0.0/24 14229 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 4 - 111.10.2.0/24 14227 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 5 - 111.10.1.0/24 14225 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 6 - 196.2.16.0/24 10315 0.6% AS10474 -- NETACTIVE 7 - 117.131.0.0/17 10062 0.6% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 8 - 120.204.0.0/16 9886 0.5% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 9 - 117.136.8.0/24 9834 0.5% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 10 - 117.135.128.0/18 9735 0.5% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 11 - 117.135.0.0/17 9724 0.5% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 12 - 198.140.43.0/24 7497 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - 130.36.34.0/24 6507 0.4% AS32528 -- ABBOTT Abbot Labs 14 - 130.36.35.0/24 6506 0.4% AS32528 -- ABBOTT Abbot Labs 15 - 190.65.228.0/22 6110 0.3% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 16 - 221.181.64.0/18 5973 0.3% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 17 - 63.211.68.0/22 5531 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 18 - 143.138.107.0/24 4251 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 19 - 211.136.96.0/19 3461 0.2% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 20 - 211.136.128.0/19 3459 0.2% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0