- NANOG - lists.nanog.org

Cisco AGM
by Konstantin Bezruchenko 09 Apr '09

09 Apr '09

Hi all, I wonder if here any people who own/maintain Cisco AGM, or maybe used this device in past. I want to ask few questions. Please reply offlist. Thanks, Konstantin

1 0

L2 - L3 Etherchannel
by Amolak 09 Apr '09

09 Apr '09

Hi All, Is it possible to create L2 Etherchannel at one end and L3 etherchannel at another end? For Example: SW-1 ==== interface GigabitEthernet1/1 channel-group 1 mode desirable channel-protocol pagp ! interface GigabitEthernet1/2 channel-group 1 mode desirable channel-protocol pagp ! interface Port-channel 1 no ip address switchport switchport access vlan 10 switchport mode access ! int vlan10 ip address 1.1.1.1 255.255.255.252 ! ------------------------------------ SW-2 ==== interface Port-channel 2 ip address 1.1.1.2 255.255.255.252 ! interface GigabitEthernet1/1 no ip address channel-group 2 mode desirable channel-protocol pagp ! interface GigabitEthernet1/2 no ip address channel-group 2 mode desirable channel-protocol pagp ! I don't have a lab to test it, can somebody confirm if the connectivity will work between these devices as per this setup. Thanks, Amolak

2 2

Fwd: SLA packet loss base
by 정치영 09 Apr '09

09 Apr '09

Some people replied me about my questions. thanks for reply. However, what I want to know ultimately is something like technical proof or standard or experimentation information they can logically support SLA values in provider's IP network. For example, regarding packet loss, I found information it is based on voip service tolerance (al least below 1% packet loss). but some provider announce they can guarantee 0.3% packet loss. Where does 0.3% come from ? Can anyone give me an answer about this question ? In fact I am going to make some guideline of network quality of my network. Best regards, Chiyoung ------- Original Message ------- Sender : 정치영<lionair(a)samsung.com> 과장/인프라기술1팀/삼성네트웍스 Date : 2009-04-08 13:05 (GMT+09:00) Title : SLA packet loss base Hi all, I wonder where we can find the base of packet loss rate of Global famous provider. For example, the packet loss value of Sprint and NTT-Verio is same 0.3 % at their SLA. Best regards Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair(a)samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 =============================================

2 1

Verizon EVDO Issues
by Charles Wyble 08 Apr '09

08 Apr '09

Been troubleshooting a very strange problem for a couple of weeks now. I have a few hundred systems deployed throughout the United States utilizing EVDO connectivity with Verizon as a carrier. They are stationary. Over the past few weeks clusters of them in SF and Lewisville TX and a few other areas have been failing intermittently. They are offline for several days, then online for a few days then go offline again. They are running Linux and PPPD. Has anyone else seen anything like this? I realize that there are very few other organizations with a network footprint like ours (few hundred static EVDO cards). Other large users like FedEx and Amtrak aren't reporting any issues. Verizon wants to replace the cards, but that doesn't seem like a viable solution, as it's localized to a few areas and is intermittent. Replies on or off list appreciated.

1 1

Cisco Audit Tool?
by Pat Durkin 08 Apr '09

08 Apr '09

www.iquate.com <http://www.iquate.com/> audit large network infrastructure; Cisco plus others; very flexible as you can drive your own queries across thousands of devices; Any views expressed in this message are the sender's own, and do not represent the views of iQuate except where the sender specifically states them to be the views of iQuate. This e-mail should only be read by those persons to whom it is addressed. Accordingly, we disclaim all responsibility and accept no liability (including in negligence) for the consequences of any person other than the intended recipients acting, or refraining from acting, on such information. If you have received this e-mail in error, please accept our apologies and we simply request that you delete this document. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail is strictly prohibited iQuate is a trading name for eManageIT Ltd. Registered in Ireland - Number: 350019 Citywest National Digital Park, Dublin

1 0

SLA packet loss base
by 정치영 08 Apr '09

08 Apr '09

Hi all, I wonder where we can find the base of packet loss rate of Global famous provider. For example, the packet loss value of Sprint and NTT-Verio is same 0.3 % at their SLA. Best regards Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair(a)samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 =============================================

1 0

nytimes.com: How the Internet Got Its Rules
by Tony Patti 08 Apr '09

08 Apr '09

Hopefully these RFC's have (in sum total over the last 40 years) sufficient operational content to merit mention per the NANOG AUP. Tony Patti CIO S. Walter Packaging Corp. tony(a)swalter.com http://www.nytimes.com/2009/04/07/opinion/07crocker.html?_r=1&emc=eta1 How the Internet Got Its Rules By STEPHEN D. CROCKER Published: April 6, 2009 Bethesda, Md. TODAY is an important date in the history of the Internet: the 40th anniversary of what is known as the Request for Comments. Outside the technical community, not many people know about the R.F.C.'s, but these humble documents shape the Internet's inner workings and have played a significant role in its success. When the R.F.C.'s were born, there wasn't a World Wide Web. Even by the end of 1969, there was just a rudimentary network linking four computers at four research centers: the University of California, Los Angeles; the Stanford Research Institute; the University of California, Santa Barbara; and the University of Utah in Salt Lake City. The government financed the network and the hundred or fewer computer scientists who used it. It was such a small community that we all got to know one another. A great deal of deliberation and planning had gone into the network's underlying technology, but no one had given a lot of thought to what we would actually do with it. So, in August 1968, a handful of graduate students and staff members from the four sites began meeting intermittently, in person, to try to figure it out. (I was lucky enough to be one of the U.C.L.A. students included in these wide-ranging discussions.) It wasn't until the next spring that we realized we should start writing down our thoughts. We thought maybe we'd put together a few temporary, informal memos on network protocols, the rules by which computers exchange information. I offered to organize our early notes. What was supposed to be a simple chore turned out to be a nerve-racking project. Our intent was only to encourage others to chime in, but I worried we might sound as though we were making official decisions or asserting authority. In my mind, I was inciting the wrath of some prestigious professor at some phantom East Coast establishment. I was actually losing sleep over the whole thing, and when I finally tackled my first memo, which dealt with basic communication between two computers, it was in the wee hours of the morning. I had to work in a bathroom so as not to disturb the friends I was staying with, who were all asleep. Still fearful of sounding presumptuous, I labeled the note a "Request for Comments." R.F.C. 1, written 40 years ago today, left many questions unanswered, and soon became obsolete. But the R.F.C.'s themselves took root and flourished. They became the formal method of publishing Internet protocol standards, and today there are more than 5,000, all readily available online. But we started writing these notes before we had e-mail, or even before the network was really working, so we wrote our visions for the future on paper and sent them around via the postal service. We'd mail each research group one printout and they'd have to photocopy more themselves. The early R.F.C.'s ranged from grand visions to mundane details, although the latter quickly became the most common. Less important than the content of those first documents was that they were available free of charge and anyone could write one. Instead of authority-based decision-making, we relied on a process we called "rough consensus and running code." Everyone was welcome to propose ideas, and if enough people liked it and used it, the design became a standard. After all, everyone understood there was a practical value in choosing to do the same task in the same way. For example, if we wanted to move a file from one machine to another, and if you were to design the process one way, and I was to design it another, then anyone who wanted to talk to both of us would have to employ two distinct ways of doing the same thing. So there was plenty of natural pressure to avoid such hassles. It probably helped that in those days we avoided patents and other restrictions; without any financial incentive to control the protocols, it was much easier to reach agreement. This was the ultimate in openness in technical design and that culture of open processes was essential in enabling the Internet to grow and evolve as spectacularly as it has. In fact, we probably wouldn't have the Web without it. When CERN physicists wanted to publish a lot of information in a way that people could easily get to it and add to it, they simply built and tested their ideas. Because of the groundwork we'd laid in the R.F.C.'s, they did not have to ask permission, or make any changes to the core operations of the Internet. Others soon copied them - hundreds of thousands of computer users, then hundreds of millions, creating and sharing content and technology. That's the Web. Put another way, we always tried to design each new protocol to be both useful in its own right and a building block available to others. We did not think of protocols as finished products, and we deliberately exposed the internal architecture to make it easy for others to gain a foothold. This was the antithesis of the attitude of the old telephone networks, which actively discouraged any additions or uses they had not sanctioned. Of course, the process for both publishing ideas and for choosing standards eventually became more formal. Our loose, unnamed meetings grew larger and semi-organized into what we called the Network Working Group. In the four decades since, that group evolved and transformed a couple of times and is now the Internet Engineering Task Force. It has some hierarchy and formality but not much, and it remains free and accessible to anyone. The R.F.C.'s have grown up, too. They really aren't requests for comments anymore because they are published only after a lot of vetting. But the culture that was built up in the beginning has continued to play a strong role in keeping things more open than they might have been. Ideas are accepted and sorted on their merits, with as many ideas rejected by peers as are accepted. As we rebuild our economy, I do hope we keep in mind the value of openness, especially in industries that have rarely had it. Whether it's in health care reform or energy innovation, the largest payoffs will come not from what the stimulus package pays for directly, but from the huge vistas we open up for others to explore. I was reminded of the power and vitality of the R.F.C.'s when I made my first trip to Bangalore, India, 15 years ago. I was invited to give a talk at the Indian Institute of Science, and as part of the visit I was introduced to a student who had built a fairly complex software system. Impressed, I asked where he had learned to do so much. He simply said, "I downloaded the R.F.C.'s and read them." Stephen D. Crocker is the chief executive of a company that develops information-sharing technology.

1 0

Call for participants, NANOG 46: ISP Security BOF
by Warren Kumari 07 Apr '09

07 Apr '09

Hello all, So, for once in my life I have not left things till the last minute :-) NANOG 46 is still a ways off, but I'd like to invite y'all to start thinking about topics for the ISP Security BOF, either things that you would like to present, or things that you are interested in and would like to see someone else present. You (Yes! You!) can give a security related presentation at the upcoming NANOG, thereby earning fame, respect and adoration from your friends and colleagues. W -- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett

1 0

Re: AS6079
by Colin Alston 07 Apr '09

07 Apr '09

On 2009/04/07 03:33 PM Chris Jackman wrote: > On Tue, Apr 07, 2009 at 11:53:07AM +0200, Colin Alston wrote: >> I've reported spam to this AS before, and I don't recall ever getting a >> response. >> >> I'm wondering how many others see spam from it? Is it worth while >> continuing or should I just stop accepting SMTP from there? >> >> They seem to have some dubious customers hosted on there, a large amount >> seems to come from the domain mailiz.biz and out of idealhosting.com > > > I've replied offlist. This is being addressed. > Thank you Chris. Apologies for my assumption based on the silence :)

1 0

shipping pre-built cabinets vs. build-on-site
by Joe Abley 07 Apr '09

07 Apr '09

Hi all, Anybody here have experience shipping pre-built cabinets, with ~20U of routers and servers installed, connected and tested, to remote sites for deployment? The idea is to increase the consistency of the deployments by having them all built in one place by the same set of people, and to reduce the amount of time required by warm bodies on-site (bodies that would otherwise have to receive individual components and install/cable them). We've located a few vendors who sell shock-tolerant cabinets, but they're expensive and seem to me to be aimed at people who need to ship a set of equipment frequently (e.g. to support movie shoots, outside broadcasts, etc), rather than people who want to ship just once. The destination in all cases would be a commercial, modern data centre. The equipment would be shipped from LA. Do I even need to spend time wondering about shock-tolerant cabinets, or should I instead be concentrating on finding the right company to wrap the cabinets for shipping, and to do the shipping itself? Joe

15 16