RE: Cisco 7200 PCI Limitations
For users with private DS3-based network links between sites, for the case where 2 or more of these DS3's are to be bundled together in a multi-link PPP connection, Cisco will not support this configuration due to insufficient 7200 cpu resources, so packet-by-packet load sharing must be used which could result in packets arriving out of sequence. Cisco will not support VoIP over packet-by-packet load sharing. Additionally, PIM multicast uses only a single DS3 under the packet-by-packet load sharing scenario, so all available bandwidth with 2 or more DS3s is not available. The 7200 will support 8 T1s in a logical multilink bundle, though, so for low speed circuits, the 7200 still provides complete IOS feature functionality. The 7200s have some very limited uses, but in my view they have no place in today's wire speed backbone networks, particularly when 3 or more 7200 GiGE interfaces can be used as a logical bundle. The biggest problem is the tendency of some to treat the 7200 as an Ethernet switch, define a portchannel with 2 or more GiGE interfaces, connect the 7200 portchannel to a modern Ethernet switch, and by this action define a network bottleneck where packets can be dropped due to a serious backplane/wire speed mismatch. -Original Message- From: PC [mailto:paul4...@gmail.com] Sent: Monday, August 06, 2012 10:05 AM To: david peahi Cc: nanog@nanog.org Subject: Re: Cisco 7200 PCI Limitations While I agree it may not be suitable for transit GigE purposes, it is certainly acceptable for many WAN aggregation scenarios and CPE scenarios well in excess of T1 speeds. There are still many out there in DS3, Fast-E, subrate ethernet subscriber, ATM, (DSL/L2TP/PPPOE), DMVPN, and other similar scenarios. For this, while often not ideal, they continue to work fine. On Mon, Aug 6, 2012 at 10:47 AM, david peahi davidpe...@gmail.com wrote: The 7200 architecture dates from the late 1990s, and is basically modeled on a PCI-bus UNIX workstation from that era. The 7200 is usable today as a WAN aggregation router for T1 access, and nothing else. Using it as a GiGE transit router will place a non-deterministic node in the network, unable to scale to the 4 GiGE full-duplex throughput. Even worse is creating a portchannel out of the 7200 GiGE interfaces and using dot1q sub-interfaces to emulate an Ethernet switch in 7200 software, then connecting the 7200 dot1q trunk to a modern Ethernet switch with a wire speed backplane (for example a Cisco 3560X Ethernet switch). Long since considered an unacceptable best practice (due to the 7200 backplane limitation vs adjacent, directly connected modern Ethernet switches), Cisco is still teaching portchannel in its router configuration classes, so relatively new network engineers have actually been known to use this ill-considered configuration. If a 4 port GiGE Cisco router is needed, then the ASR1001 is the modern version of the 7206, with wire speed throughput. On Fri, Aug 3, 2012 at 12:36 AM, shthead li...@shthead.com wrote: Hi all, I have a 7200 series router (7204) here and I am trying to figure out something with it. Currently the router has a NPE-G1 card in it, giving it 3 gig interfaces but I need an extra gig interface on it to make 4. Having a look around the available options are either get a PA-GE card that fits into one of the slots on the router or to get a C7200-I/O-GE+E (I/O controller with a gbit port on it). The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus will limit it to 300mbit full duplex (and it goes on further to say it will be limited to approx 200mbit in best case scenario due to the design of the card) [1]. The other option left is the I/O controller. I found that you can get a port adaptor jacket card [2] for the 7200's that let you stick a normal interface card into the I/O controller slot (instead of the I/O controller itself). My main concern is if the jacket card uses its own PCI bus I am assuming the C7200-I/O-GE+E also connects via PCI which means it would be subject to the same limitations as the PA-GE. Does anyone have any idea if that would be correct and the only option for another gbit port would be to get another device? Thanks for the help [1] http://www.cisco.com/en/US/**products/hw/routers/ps341/** products_tech_**note09186a00800c814a.shtml#**backinfo http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a00800c814a.shtml#backinfo [2] http://www.cisco.com/en/US/**prod/collateral/routers/ps341/** prod_qas0900aecd8045055e.html http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd8045055e.html This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that
RE: Programmers with network engineering skills
What about the case of the strong coder who decides that networking is more interesting as a life's work, moves into networking, will not consider employment where coding is even a remote possibility, and will successfully land another networking job elsewhere if management even brings up the subject of coding? I think this describes the great majority of networking professionals. -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Monday, February 27, 2012 2:14 PM To: david raistrick Cc: NANOG Subject: Re: Programmers with network engineering skills On Feb 27, 2012, at 12:31 PM, david raistrick wrote: On Mon, 27 Feb 2012, Owen DeLong wrote: I think you're more likely to find a network engineer with (possibly limited) programming skills. While I'll agree about the more likely, if I needed a coder who had a firm grasp of networking I'd rather teach a good coder networking, than try to teach the art and magic of good development to a network guy. Well, I won't call myself a hard-core coder, but, I think I have a reasonable grasp on the art and magic of good development. What I mostly lack is speed and efficiency in the language of choice for whatever project. I can write good code, it just takes me longer than it would take a hard-core coder. OTOH, having done both, I would say that I think you are not necessarily correct about which direction of teaching is harder. Yes, if you start with a network engineer that knows nothing about writing code or doesn't understand the principles of good coding, you're probably right. However, starting with a network engineer that can write decent code slowly, I think you will get a better result in most cases than if you try to teach network engineering to a hard-core coder that has only a minimal understanding of networking. I think it really comes down to which you need: a hardcore network engineer/architect who can hack up code, or a hardcore developer who has or can obtain enough of a grasp of networking fundementals and specifics to build you the software you need him to develop. I'm guessing that someone who needed a hard-core developer that could grasp fundamentals would have grabbed an existing coder and handed him a copy of Comer. The fact that this person posted to NANOG instead implies to me that he needs someone that has a better grasp than just the fundamentals. Of course I am speculating about that and I could be wrong. The ones who already know both ends extremely well are going to be -very- hard to find, but finding one who can learn enough of the other to accomplish what you need shouldn't be hard at all. Depends on what you need. However, I think it's faster to go from limited coding skills with a good basis in the fundamentals to usable development than to go from limited networking skills to a firm grasp on how networks behave in the real world. To the best of my knowledge, nothing but experience will teach you the latter. Even with 20+ years experience networks do still occasionally manage to surprise me. ...d (who is not exactly the former though I've played one for TV, and not at all the later) I am admittedly lost given the three choices as to which constitutes former or latter at this point. 1. Strong coder with limited networking 2. Strong networker with limited coding 3. Strong in both Owen Who is a strong network engineer Who has been a professional software engineer (though many years ago and my skills are rusty and out of date) This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Programmers with network engineering skills
But my point is that each person who is capable to do so generally chooses their life's work, after working in and trying out several capacities, and this is extremely common in IT environments where a person could have cycled through programming, system admin, dba, networking, security, etc. For me, I prefer networking, and even a substantial raise would not get me to design and write computer programs again. Life is short, networking professionals generally are in high demand, and are in networking because they like it. Yes Perl scripting may become a temporary, necessary evil at some point, but if the subject of coding comes up, many will move on. -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Monday, February 27, 2012 6:23 PM To: Holmes,David A Cc: North American Network Operators' Group Subject: Re: Programmers with network engineering skills programming is not being able to write a hundred lines of unreadable perl. a real programmer can be productive in networking tools in a matter of a month or two. i have seen it multiple times. a networker can become a useful real progammer in a year or three. randy This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Programmers with network engineering skills
Yes, a theoretical understanding of algorithms is a common element in programming and networking. But the thread seems to assume that highly capable programmers/network engineers are mere serfs, unable to forge their own destiny, at the beck and call of whomever they work for, instead of independent beings who are doing what they are doing because they like it and choose to continue doing so, even at the expense of foregoing substantial financial gain. -Original Message- From: Daniel Schauenberg [mailto:d...@unwiredcouch.com] Sent: Monday, February 27, 2012 7:09 PM To: Randy Bush Cc: Holmes,David A; North American Network Operators' Group Subject: Re: Programmers with network engineering skills a real programmer can be productive in networking tools in a matter of a month or two. i have seen it multiple times. a networker can become a useful real progammer in a year or three. Thank you! I always wonder when someone distinguishes between a networker and a programmer as if they came from completely different worlds. I find these fields to be highly related. They are algorithmic at the core and you need a good understanding of architecture and design to successfully make the concepts work. If you have ever tried to find a bug in a badly structured network, you should be able to understand that implementing all of your application's use cases in one module is not a good idea. After implementing a good serialization scheme for your class data, network protocols are not that strange anymore (I know I'm exaggerating on simple examples here, but I hope the idea comes across). My point is, if someone has a good understanding of applying architectural patterns to a problem and isolating error causes while debugging, it shouldn't matter if he wrote mostly software the last years or if she administered a large scale network. A good sysadmin can learn to write software and a good programmer can learn to love the datacenter. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: common time-management mistake: rack stack
The problem with using engineering as a model is that computer science networking theory is based upon mathematical logic and formal mathematics (for instance Finite State Machines, Turing Machines), and operates on what are essentially robotic automatons running in real time. Engineering as I have experienced it, operates according to construction time frames using CSI specifications, preliminary design reviews, and various iterations of final design reviews involving engineering drawings and CSI-format specification documents where a 6 year start-to-finish time frame is not unusual. The number of PEs who can operate in real time is but a fraction of all PEs, and those who can plan a project with a 1 week time frame, and implement the project at 3 am in the morning is a yet smaller fraction. ( and don't even think about the number of PEs who can get a 3 am call and must fix a broken network ASAP). Not everyone has the ability to grasp mathematical logic, even though they have been able to get an engineering degree. Engineers have no peers in the ability to build bridges, skyscrapers, and other large construction projects, but this ability does not transfer to computer science, and computer networking. -Original Message- From: Lamar Owen [mailto:lo...@pari.edu] Sent: Thursday, February 23, 2012 10:59 AM To: nanog@nanog.org Subject: Re: common time-management mistake: rack stack On Wednesday, February 22, 2012 03:37:57 PM Dan Golding wrote: I disagree. The best model is - gasp - engineering, a profession which many in networking claim to be a part of, but few actually are. In the engineering world (not CS, not development - think ME and EE), there is a strongly defined relationship between junior and senior engineers, and real mentorship. My degree is in EE, and I spent over a decade in the field as a 'broadcast engineer' Now, a 'broadcast engineer' is not a PE, and is not currently licensed as such, although many of the best consulting broadcast engineers do take the extra step and expense to get the PE license; technically, in many states, you're not even supposed to use the word 'engineer' in your title without having a PE license. By way of background, my specialty was phased array directional AM broadcast systems in the 5-50KW range, doing 'technician' things like phasor rocking, transmitter retubing and retuning, monitor point and radial measurements, transmitter installation, and tower climbing, in addition to more mathematical and engineering sorts of things like initial coverage and protection studies for pattern/power changes, measured radial ground conductivity/dielectric constant curve fitting/prediction contour overlap studies and models, as well as keeping up with FCC regulations and such. I left broadcasting full-time in 2003 for an IT position, as a stress-reducer (and it worked.). So I say this with some experience. Mentoring in broadcast is still practiced by associations like the Society of Broadcast Engineers and others. These days, much of this sort of thing is online with websites like www.thebdr.net and mailing lists like those hosted by broadcast.net; in this regard the network ops community isn't too dissimilar from the broadcast community. Now, while in the broadcast role I had the distinct honor of having three fantastic personal mentors, two of whom still stay in touch, and one who died twenty years ago, a few years after I got started in the field. RIP W4QA. He taught me more in half an hour about phased arrays and the way they worked in practice than ten hours of class time could have. Likewise, I know some old hands here, even if I've not physically met them, whose opinions I trust, even if I don't agree with them. The problem with networking is that TOO MANY skills are learned on the job (poorly), rather than folks coming in with solid fundamentals. This is not limited to networking. The parallels between broadcast engineering and IT/networking are a little too close for comfort, since there are more potential mentors with weak teaching skills and bad misconceptions that were valid 'back in the day' than there are who will teach practical, working, correct ways of doing things 'today' and why they are done the way they are done (which can involve some history, one of my favorite things). A mentor who will teach how to think about why you are doing what you are doing is priceless. A mentor who will honestly go over the pros and cons of his or her favorite technique and admit that is isn't the single 'correct' way to do something, and a mentor who will teach you how to think sideways, especially when things are broken, are beyond priceless. I especially like it when a mentor has told me 'now, this isn't necessarily the way I'd do it, and I'm not really fond of it, but you *can* do this to get this result if you need to do so...just don't ask me to fix it later.' And the recent thread on
RE: Common operational misconceptions
With telcos increasingly implementing Metro Ethernet Forum (MEF) networks, I have found that telco technicians tasked with maintaining and operating these carrier Ethernet networks appear to disregard common high availability practices. For instance, after diagnosing a routing protocol neighbor flap (consistently 20-30 seconds) and isolating the problem to the carrier MEF network, the carrier technician told me that the problem was a spanning tree convergence that took their primary and back-up links down during convergence, but that this is no big deal because the network was only down for 20-30 seconds. -Original Message- From: John Kristoff [mailto:j...@cymru.com] Sent: Wednesday, February 15, 2012 12:47 PM To: nanog@nanog.org Subject: Common operational misconceptions Hi friends, As some of you may know, I occasionally teach networking to college students and I frequently encounter misconceptions about some aspect of networking that can take a fair amount of effort to correct. For instance, a topic that has come up on this list before is how the inappropriate use of classful terminology is rampant among students, books and often other teachers. Furthermore, the terminology isn't even always used correctly in the original context of classful addressing. I have a handful of common misconceptions that I'd put on a top 10 list, but I'd like to solicit from this community what it considers to be the most annoying and common operational misconceptions future operators often come at you with. I'd prefer replies off-list and can summarize back to the list if there is interest. John This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: LX sfp minimum range
I have found that -5dB or -10dB attenuators must be used on the send or receive strands between Cisco LX connected switches at relatively short distances of 1 km over standard singlemode fiber. Other Vendors' SFPs rated up to 25 km do not need attenuators at distances 1 km. -Original Message- From: Jon Heise [mailto:j...@smugmug.com] Sent: Thursday, January 26, 2012 9:41 AM To: Pierre-Yves Maunier Cc: nanog@nanog.org Subject: Re: LX sfp minimum range Awesome, i got some single mode LC LC fiber off monoprice, sounds like i should be all set for this. Thanks for everyones info - Jon On Thu, Jan 26, 2012 at 6:24 AM, Pierre-Yves Maunier na...@maunier.orgwrote: 2012/1/26 David Storandt dstora...@teljet.com You can put a 3dB or 5dB optical pad on the link if the receiver can't handle zero-distance optical power. We're using SFP LX for a couple of years even in back to back configuration for equipments within the same rack with a 1 meter patch cord without any problem. Max TX is -3dBm, Max RX sensivity is -3dBm so there is no problem. 1. I don't think I've ever had a LX SFP that TX at -3 dBm, they're usually around -5 to -7 dBm. and example in a live router : pymaun...@re1.tcr1.rb.par show interfaces diagnostics optics ge-7/3/* | match Laser output power Laser output power: 0.3160 mW / -5.00 dBm Laser output power: 0.1800 mW / -7.45 dBm Laser output power: 0.2600 mW / -5.85 dBm Laser output power: 0.3210 mW / -4.93 dBm Laser output power: 0.3070 mW / -5.13 dBm Laser output power: 0.3200 mW / -4.95 dBm Laser output power: 0.3180 mW / -4.98 dBm Laser output power: 0.3140 mW / -5.03 dBm 2. You can assume a patch cord add between 0.2 to 0.5 dB of attenuation so even with a SFP TX at -3dBm, you won't receive at the Max RX sensitivity. -- Pierre-Yves Maunier This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: 10G switchrecommendaton
Check out Arista's white papers on low-latency networking, the use of merchant silicon, and queueing theory applied to serialization delay. -Original Message- From: James Braunegg [mailto:james.braun...@micron21.com] Sent: Thursday, January 26, 2012 5:28 PM To: Eddie Parra; Rodrick Brown Cc: nanog list Subject: RE: 10G switchrecommendaton Arista sounds interesting, although never knew of them ! How do they compare price wise / feature wise to Brocade / Juniper / Force10 ? That being said my preference is the S4810 - Force10 Kindest Regards James Braunegg W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braun...@micron21.com | ABN: 12 109 977 666 This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -Original Message- From: Eddie Parra [mailto:e...@eddieparra.net] Sent: Friday, January 27, 2012 8:23 AM To: Rodrick Brown Cc: nanog list Subject: Re: 10G switchrecommendaton +1 Arista -Eddie On Jan 26, 2012, at 1:02 PM, Rodrick Brown rodrick.br...@gmail.com wrote: http://www.aristanetworks.com/ Sent from my iPhone On Jan 26, 2012, at 3:20 PM, Deric Kwok deric.kwok2...@gmail.com wrote: Hi all I would like to have 10G switchrecommendaton Ipref software can test around 9.2G but we can have congestion over 6G in single port! Thank you This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: So... my colo was just bought.
In the 2002-2003 time frame I worked for a company that colo'd strategic business servers in various telco facilities (big names, some that are still in business today), but these telco's had no problem with closing down the colo and giving 6 months notice to all tenants, with very little advanced notice. So this created a situation where a replacement site had to be found, space leased, equipment purchased, network bandwidth negotiated and purchased, etc. within that 6 month timeframe, or face the consequences of being essentially out of business. I can't speak for the company that is the subject of the email though, only of what has happened to me in the past. -Original Message- From: Jay Ashworth [mailto:j...@baylink.com] Sent: Tuesday, January 10, 2012 7:58 AM To: NANOG Subject: So... my colo was just bought. By Knology. Should I be scared? My experiences with Knology have been fairly thin, but uniformly negative, for at least the last 5 years. But I know that the plural of 'anecdote' is not 'data'. That said, I'm accepting all anecdotes. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: next-best-transport! down with ethernet!
If I am not mistaken the IETF efforts to standardize the TRILL spec, and IEEE efforts to standardize the DCB spec will provide the desired features to Ethernet: lossless delivery, QoS, and bringing an IS-IS layer 3 model to layer 2. I think Cisco has a pre TRILL/DCB standards feature set called Fabricpath, and Brocade has a feature set called VCS. Both, I think, will converge Ethernet data and Fibre Channel over the same wire. -Original Message- From: Tom Hill [mailto:t...@ninjabadger.net] Sent: Thursday, December 29, 2011 11:58 AM To: nanog@nanog.org Subject: Re: next-best-transport! down with ethernet! On Thu, 2011-12-29 at 10:06 -0500, Christopher Morrow wrote: yes, let's get something with say fixed sized packets, ability to have predictable jitter and also, for fun, no more STP! Ethernet is too complex, maybe something simpler? I hear there's this new tech 'ATM'? it seems to fit the bill! Pfft. Everyone knows that Fibre Channel's going to replace everything... The minute we get those 128Gbit/sec transmission characteristics, Ethernet's gonna be as good as RS-485. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Range using single-mode SFPs across multi-mode fiber
The max limit for 100 base FX (100 Mbps Ethernet) is around 6600 feet. Many campus ductbank systems built in the 1990s when 10 and 100 Mbps Ethernet were the commodity speeds (before GiGE) used 62.5/125 MM fiber to connect buildings. It is not unusual to see long MM runs on campus facilities where 100 Mbps backbones once were the fastest speeds available. In those days, apart from longhaul telco use, singlemode fiber was usually only run for closed circuit TV (CCTV) use in the campus environment, and in places where 1990s SM was run for CCTV it can still be used for longhaul laser sfps, which to me shows that SM is future proof. SM even makes sense in short runs as attenuators can be placed on the send/receive strands to reduce the dB so the optical receiver is not saturated. -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Thursday, December 15, 2011 5:53 AM To: Keegan Holley Cc: nanog@nanog.org; oliver rothschild Subject: Re: Range using single-mode SFPs across multi-mode fiber On Wed, 14 Dec 2011, Keegan Holley wrote: 2011/12/14 oliver rothschild orothsch...@gmail.com How did you end up with a MM run this long? SX optics are only rated at 500 meters at best. Even with mode conditioning jumpers more the 1km is a risk. I'm glad it held up during testing though. Just out of curiosity did you purchase dark from a provider? Is it inside of a building? Legacy 10baseFL/100baseFX/FDDI can run fairly long distances over OM1. In the past I've run 100baseFX over OM1 runs with multiple cross-connects, out to about 2 km. jms This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Multiple ISP Load Balancing
From time to time some have posted questions asking if BGP load balancers such as the old Routescience Pathcontrol device are still around, and if not what have others found to replace that function. I have used the Routescience device with much success 10 years ago when it first came on the market, but since then a full BGP feed has become much larger, Routescience has been bought by Avaya, then discontinued, and other competitors such as Sockeye, Netvmg have been acquired by other companies. Doing some research on how load balancing can be accomplished in 2011, I have come across Cisco's performance routing feature, and features from load balancing companies such as F5's Link Controller. I have always found BGP to be easy to work with, and an elegant, simple solution to load balancing using a route-reflector configuration in which one BGP client (Routescience Pathcontrol in my background) learns the best route to destination networks, and then announces that best route to BGP border routers using common and widely understood BGP concepts such as communities and local pref, and found this to lead to a deterministic Internet routing architecture. This required a knowledge only of IETF standards (common BGP concepts and configurations), required no specialized scripting, or any other knowledge lying outside IETF boundaries, and it seemed reasonable to expect that network engineers should eagerly and enthusiastically want to master this technology, just as any other technology must be mastered to run high availability networks. So I am wondering if anyone has experience with implementing load balancing across multiple ISP links in 2011, and if there have been any comparisons between IETF standards-based methods using BGP, and other proprietary methods which may use a particular vendor's approach to solving the same problem, but involves some complexity with more variables to be plugged in to the architecture. David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: local_preference for transit traffic?
For this very reason I have advocated using longest prefix BGP routing for some years now, and checking periodically for the expected path, as it became obvious from investigating traceroutes that traffic was not being routed as intended using AS prepends. -Original Message- From: Keegan Holley [mailto:keegan.hol...@sungard.com] Sent: Wednesday, December 14, 2011 10:08 PM To: NANOG Subject: local_preference for transit traffic? Had in interesting conversation with a transit AS on behalf of a customer where I found out they are using communities to raise the local preference of routes that do not originate locally by default before sending to a other larger transit AS's. Obviously this isn't something that was asked of them and it took a few days to find since the customer is not a large company and neither them nor my company has a link or business relationship with the AS in question. This seemed strange to me for obvious reasons, but I was curious if anyone else was doing this and why. You obviously cannot use prepend to affect transit traffic again for obvious reasons. MED is a weak metric but it at least only affects traffic that was already going to transit your AS. The larger transit AS was favoring a lower bandwidth link for the customer and causing them to drop packets mysteriously. Just wondering if this practice seemed as strange to others as it does to me. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: BGP and Firewalls...
My concern is whether or not consolidating border router and firewall functions in the same device violates, if not explicitly, then the spirit of the defense in depth Internet edge design principle. Here is a link to a Department of Homeland Security document where this is discussed (for control systems, but has general application), but not addressed directly: http://www.inl.gov/technicalpublications/Documents/3375141.pdf The old Checkpoint/Nokia firewalls consolidated routing and firewall functions, but the question is one of layered defenses, such that it seems intuitive that it is inherently more difficult for the bad actor to penetrate network defenses the more devices that have to be penetrated. -Original Message- From: Gregory Croft [mailto:gcr...@shoremortgage.com] Sent: Wednesday, December 07, 2011 10:04 AM To: Christopher Morrow Cc: nanog@nanog.org Subject: RE: BGP and Firewalls... I'm not having problems... Well, not yet anyways. :) Just investigating to see if there is a reason I shouldn't use a firewall at the edge versus a dedicated router as well as to see if anyone can share their specific experience with the PAN devices. Thanks everyone! Greg -Original Message- From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] On Behalf Of Christopher Morrow Sent: Wednesday, December 07, 2011 12:44 PM To: Gregory Croft Cc: nanog@nanog.org Subject: Re: BGP and Firewalls... On Wed, Dec 7, 2011 at 12:31 PM, Gregory Croft gcr...@shoremortgage.com wrote: Hi All, Does anyone have any experience with using firewalls as edge devices when BGP is concerned? Specifically the Palo Alto series of devices. nokia/checkpoint has done this for ages. what's the problem you have? This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Internet Edge and Defense in Depth
Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Looking for a Tier 1 ISP Mentor for career advice.
Personally, I have worked in places where I have performed all of the skills below (router/switch/Unix/Linux/AD/firewall/proxy/web admin/sendmail admin, etc.), and also in places where just router/switch/architect layer 1-3 skills were the primary focus. I prefer the latter, and find this to be a personal choice as to what makes for a meaningful and fulfilling job. The fact that so few network engineers are to be found with all of these skills, I think, speaks for itself in that many network engineers have made the choice, and that choice is to be focused on layers 1-3, which, with DWDM through BGP, offers many challenging, different, and varied technology complexities the mastery of which makes work meaningful and rewarding. -Original Message- From: Mark Stevens [mailto:mana...@monmouth.com] Sent: Thursday, December 01, 2011 7:53 AM To: nanog@nanog.org Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. It takes me years to find such people and when I do, I try very hard to keep them! I have 3 key people that fit the soft attribute criteria Randal mentioned, but with a premium skill set in their specific function. Good luck with your task Leigh! Mark Stevens On 12/1/2011 10:21 AM, Leigh Porter wrote: I am looking for just such a person now. Good Juniper, some Cisco and Sysadmin experience with an ISP background.. I expect it will be immensely difficult to find somebody. What makes it even more frustrating is that just such a person was not all that long ago made redundant! So if anybody is looking for something to do around London... -- Leigh -Original Message- From: randal k [mailto:na...@data102.com] Sent: 01 December 2011 15:19 To: Bill Stewart Cc: nanog@nanog.org Subject: Re: Looking for a Tier 1 ISP Mentor for career advice. This is a huge point. We've had a LOT of trouble finding good network engineers who have all of the previously mentioned soft attributes - attitude, team player, can write, can speak, can run a small project - and are more than just Cisco pimps. I cannot explain how frustrating it is to meet a newly minted CCNP who has zero Linux experience, can't script anything, can't setup a syslog server, doesn't understand AD much less LDAP, etc. Imagine, an employee who can help themselves 90% of the time ... Finding the diamond that has strong niche skill, networking, with a broad just-deep-enough sysadmin background has been very, very hard. I cannot emphasize enough the importance of cross-training. Immensely valuable. Randal On Wed, Nov 30, 2011 at 4:39 PM, Bill Stewartnonobvi...@gmail.com wrote: And yeah, sometimes it means that you need to go learn technologies like Active Directory [snip] In addition to learning scripting languages __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: ATT GigE issue on 11/19 in Kansas City
What I have seen lately with telco's building and operating Metro Ethernet Forum (MEF) based Ethernet networks is that relatively inexperienced telco staff are in charge of configuring and operating the networks, where telco operational staff are unaware of layer 2 Ethernet network nuances, nuances that in an Enterprise environment network engineers must know, or else. I have seen numerous instances of telco MEF layer 2 outages of 20-30 seconds where my layer 3 routing keep-alives time out. Subsequent telco root cause analysis has determined that spanning tree convergence brought down multiple links in the telco MEF network. One telco technician, assigned to Ethernet switch configuration, told me that a 20-30 second network hang is not really a big deal. -Original Message- From: Brad Fleming [mailto:bdfle...@gmail.com] Sent: Wednesday, November 30, 2011 9:58 AM To: Joe Maimon Cc: nanog@nanog.org Subject: Re: ATT GigE issue on 11/19 in Kansas City In either case I'm a customer and will likely never be told what went wrong. I'm OK with that so long as it doesn't happen again! Does being told what happened somehow prevent it from happening it again? Nope. But if this same issue crops up again we'll have to work the system harder and demand calls with knowledgeable people; not an easy task for a customer my size (I'm not Starbucks with thousands of sites). A single outage can be understood, seeing repeated issues means I want to know what's going wrong. If the issue is something simply mitigated and the service provider hasn't taken steps, I need to start looking for a different service provider. Everything has a little downtime every now and again and I can live with it on lower speed circuits. What is the utilitarian value in an RFO? To determine whether its an honest mistake or a more systemic issue that should push me toward another option. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Verizon 3G/4G
For fixed 3G sites where 3G is used as a backup to wireline access, this has been found to be an acceptable solution, although round trip latency is quite high. My understanding is that the wireless and wireline backbone networks interconnect/peer in the eastern Texas area, meaning that a wireless-to-wireline connection where both ends are in Southern California must traverse the US back to Texas for every packet. Another issue for fixed 3G locations is their inadvertent association with microcell or picocell devices, where the geographical telco wireline/wireless backbone interconnect is also not geographically distributed throughout the US, resulting in longer round trip latency. Make sure that the telco's underlying cellular backbone, and its wireline interconnection/peering points are well understood. -Original Message- From: Elijah Savage [mailto:esav...@digitalrage.org] Sent: Thursday, November 17, 2011 9:10 PM To: NANOG list Subject: Verizon 3G/4G Multi question email. Is there anyone on this list that supports this infrastructure, (verizon 3G/4G Broadband) or is there a place a seasoned admin can go outside of the general support desk to get assistance when a major outage is occurring? Secondly has anyone on this list deployed this technology within their infrastructure and can speak on the experience. Thank you This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Cable standards question
Formal construction contract bids use the Construction Specification Institute (CSI) format. There are 2 versions, I am familiar with and use the 1998 version. The 1998 CSI format is broken up into 16 divisions (mechanical, civil, electrical, architectural, etc.). Electrical, where network cabling specs reside in the CSI 1998 version, are located in Division 16. The standard fiber optic spec is Division 16 16745. A web search on fiber optic 16745 spec will turn up various examples from real fiber optic construction bids, usually government contracts for large-scale construction projects such as highways, University campuses, municipal fiber builds, etc. My suggestion is to look at existing 16745 specs, and modify them to your requirements. -Original Message- From: Sam (Walter) Gailey [mailto:gaile...@mansfieldct.org] Sent: Monday, November 14, 2011 6:43 AM To: nanog@nanog.org Subject: Cable standards question Hello, newbie question of the morning time, but hopefully not too off-topic... I run a small town network. A new building is being built that the town wants fiber access to. I have to specify for vendors what it is that the town expects in the cabling. I am (obviously) not a fiber expert, and I'm having trouble phrasing the language of the RFP so that we are assured a quality installation. My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? I'm envisioning something like; The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling. Any suggestions or examples of language would be very appreciated. Offlist contact is probably best. Many thanks, ---Sam This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: BGP conf
This is a perfect example of why it is crucial that inbound route filters be scrupulously maintained in upstream BGP providers. Who knows who is out there. -Original Message- From: McCall, Gabriel [mailto:gabriel.mcc...@thyssenkrupp.com] Sent: Tuesday, November 01, 2011 7:29 PM To: Edward avanti; nanog@nanog.org Subject: Re: BGP conf Google for team cymru secure bgp template for a good starting point. -Original message- From: Edward avanti edward.ava...@gmail.com To: nanog@nanog.org nanog@nanog.org Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00 Subject: BGP conf Halo, First, I accept this might not really right list for request, have use nsp cisco list but only first post to was succeed, sent several other for past 4 day and none appear (verified by list archive) so please excuse request. I am in need of a cisco config for BGP setup, we have a require to include IX peering at new location as well as our Verizon link, we like to take full bgp from Verizon and send to IX what they send us, I spend days reading google, and so many conflict web site example, so many example seem insecure no prefix list so on. end result to date is only sore eyes, would someone who do same (not need be Verizon) be kind to send us off list working running config (yes without your password heh) or at least how to apply to BGP router including access/prefix list and interfaces so we have an idea on what do, if you take two full BGP feed from two transit carrierin load share and IX, that good, because that our stage three plan, but I can work without two transit. I am not ignorant with cisco 7201, but am total newby to BGP. Best Thanks Edwardo This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Did Internap lose all clue?
Looking at the link referenced below, the route optimization method mentioned appears to be very similar to the old Routescience or Sockeye BGP optimization products. -Original Message- From: Jay Nakamura [mailto:zeusda...@gmail.com] Sent: Thursday, October 20, 2011 1:54 PM To: bas Cc: nanog Subject: Re: Did Internap lose all clue? Well, it didn't say router hops... They could mean AS hops I guess. I never trust marketing garbage anyway. It makes my head hurt. On Thu, Oct 20, 2011 at 4:48 PM, bas kilo...@gmail.com wrote: Recently I was contacted by an Internap sales person. The third line of the email read: As you know well, BGP makes all routing decisions simply based on HOP COUNT I blinked my eyes a couple of times.. Yes it really said hop count. Then I replied to the guy that if he tries to sell a technical product to technical people he should get his info straight. But he replied BGP actually makes decisions based on hop count. He even sent an URL from the internap website that states this http://www.internap.com/it-iq/route-optimization-miro/ On that page there is also this gem: BGP relies on the premise that hops are responsible for packet loss and congestion, and therefore a route with fewer hops is inherently better. I can imagine blatant misinformation like this from a shady startup trying to trick some sales with smoke and mirrors, but from Internap? -- Bas This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Route Optimization Software / Appliance
I used Pathcontrol with great success, moving bandwidth from one provider to another at a very granular level. It beat the Netflow/CAIDA tools manual approach hands down. I don't understand the performance issue, though, and this is not the first time performance has been raised as an issue. Some have seemed to think that the Pathcontrol existed inline in the data plane, so, it was maintained, Pathcontrol could not scale to 10 GiGE and higher ISP links. But Pathcontrol was defined as a route-reflector BGP client in the control plane, and functioned as a method of calculating the fastest path to destination BGP prefixes, and then advertising the best BGP route to IBGP route-reflector peers, which, in the absence of route table churn, did not require a super high-performing device. Avaya should either bring the product back, or release the licensing for someone else to use. -Original Message- From: Gregor Visconty [mailto:gvisco...@gmail.com] Sent: Tuesday, August 23, 2011 11:15 AM To: Drew Weaver Cc: nanog@nanog.org Subject: Re: Route Optimization Software / Appliance I used the PathControl for years (~2003-2007) and it rocked. We used it for both performance and cost, preferring cheaper links as long as the performance was comparable. It was super stable, I think we had one or two problems with it the entire time it was installed. The only drawback was it was too good, we got lazy and just let it do everything. -Gregor On Tue, Aug 23, 2011 at 10:34 AM, Drew Weaver drew.wea...@thenap.com wrote: Honestly someone should just convince Avaya to opensource and/or sell the Route Science product. It's only real flaws (even today) are the performance of the hardware it was built on and the lack of IPv6 support. Give it an x64 kernel that supports 32GB of RAM and you could probably still be using it today. -Drew -Original Message- From: David Israel [mailto:da...@otd.com] Sent: Tuesday, August 23, 2011 12:12 PM To: nanog@nanog.org Subject: Re: Route Optimization Software / Appliance This is basically Arbinet's Optimized product; it uses actual measurements for loss, round trip time, and jitter to choose routes. Right now, it is just sold as a service, going through the providers they sell access to; I don't know if you could purchase/license the software for your own use. -Dave (Full disclosure: Arbinet is my current employer.) On 8/22/2011 1:27 PM, Babak Pasdar wrote: Hello Group, I was wondering if anyone could share their experience with any route optimization approaches, methodologies or platforms, either open source or commercial (Internap FCP), that can actively adjust BGP parameters based on latency and number of layer 3 hops to a network rather than AS hops. We have upstreams all over the country and we would like to automate optimization to take the best egress path. Thank you for your feedback in advance. Best Regards, Babak -- Babak Pasdar President CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability . Performance (p) 212.461.3322 x3005 | (f) 212.584. | (w) www.BatBlue.com Bat Blue is proud to be the Official WiFi Provider for ESPN's X Games Bat Blue's AS: 25885 | BGP Policy | Peering Policy Receive Bat Blue's Daily Security Intelligence Report Bat Blue's Legal Notice This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: VMware ESX LACP Support
ESX does support link aggregation, if by that is meant more than one Ethernet switch-to-ESX bundle, acting as a single logical pipe, and with stacked TOR switch configurations the bundles Ethernet links can connect to different TOR switches for redundancy. Nexus 1000V is better for network visibility and management, though. -Original Message- From: Josh Smith [mailto:juice...@gmail.com] Sent: Monday, June 20, 2011 1:43 PM To: Manu Chao Cc: nanog@nanog.org Subject: Re: VMware ESX LACP Support ESX does NOT support LACP out of the box. Not sure about the nexus 1kv. Thanks, Josh Smith KD8HRX email/jabber: juice...@gmail.com phone: 304.237.9369(c) On Mon, Jun 20, 2011 at 4:39 PM, Manu Chao linux.ya...@gmail.com wrote: I would like to design VSS LACP based MECs with ESX hosts. Does VMware ESX support LACP? Do we need Nexus 1000 for ESX LACP support? R/ Manu This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
I think this shows the need for an Internet-wide multicast implementation. Although I can recall working on a product that delivered satellite multicast streams (with each multicast group corresponding to individual TV stations) to telco CO's. This enabled the telco to implement multicast at the edge of their networks, where user broadband clients would issue multicast joins only as far as the CO. If I recall this was implemented with the old Cincinnati Bell telco. I admit there are a lot of CO's and cable head-ends though for this solution to scale. -Original Message- From: Michael Holstein [mailto:michael.holst...@csuohio.edu] Sent: Wednesday, May 18, 2011 12:46 PM To: Roy Cc: nanog Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company http://e.businessinsider.com/public/184962 Somebody should invent a a way to stream groups of shows simultaneously and just arrange for people to watch the desired stream at a particular time. Heck, maybe even do it wireless. problem solved, right? Cheers, Michael Holstein Cleveland State University This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Level 3 Agrees to Purchase Global Crossing
Way too many players ... means that the telecom marketplace is good for the consumer, with competition keeping prices low. Many network users feel that prices are still way too high, particularly for high speed circuits and dark fiber, areas in which Level 3 and Global Crossing have specialized. -Original Message- From: William Allen Simpson [mailto:william.allen.simp...@gmail.com] Sent: Monday, April 11, 2011 7:14 AM To: NANOG list Subject: Level 3 Agrees to Purchase Global Crossing http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html The deal will combine two unprofitable companies with total revenue of $6.26 billion as of last year, and cut annualized capital spending by about $40 million, according to the statement. It will also help reduce the pressure on prices, which have declined by as much as 30 percent a year in the industry, said Donna Jaegers, an analyst at DA Davidson Co. This is what telecom has needed for a long time, said Denver-based Jaegers, who recommends buying both stocks. You have way too many players. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
RE: Ethernet circuit testing
EXFO purchased the BRIX active management system a couple of years ago. BRIX can be used to determine basic rtt, packet loss, jitter, and also contains a suite of application tests such as ftp, various voice codecs, etc. -Original Message- From: Dustin Swinford [mailto:dustinna...@gmail.com] Sent: Monday, March 07, 2011 12:07 PM To: nanog@nanog.org Subject: Ethernet circuit testing More often on Ethernet services, we experience a customer wanting to see more than an Ookla based server test from our network. Our hands in the field are limited in the number of Ethernet smart loopback devices that they own. If we do have a tester on site, we can generate traffic from an Exfo purpose built appliance toward the loop and determine results. Too often, we have found things such as ftp downloads to be unreliable based on use of server, windows PC doing the download, etc. What other methods are you guys using for testing these services?
Is anyone Using Talari Networks WAN Optimizer?
Talari management apparently has experience at the old Routescience BGP load-balancer startup, so this warrants a closer look. Has anyone used their products?
RE: Auditing a network to add Voice
One of the best active measurement products is the BRIX monitoring system, now owned by EXFO. Active measurement systems have the capability of sending out emulated application probes (for instance G.711 calls), or alternatively simple ping tests to gather round trip times (RTT), jitter, and packet loss. The tests are run, and the data is gathered at random intervals over an extended time period, thus providing a statistically accurate picture of network performance at different times, and under various traffic blends and loads. Using queuing theory, it can be shown that only 3 variables are required to accurately predict network performance: RTT, jitter, and packet loss. Designing a network which will produce the right combination of these 3 variables, mitigates the need for QoS, except as a failsafe to be used in emergency cases such as DoS attacks. QoS-free networks (FIFO queuing only) have been designed and implemented which easily support MPEG4 video, HD videoconferencing, and VoIP. -Original Message- From: Bret Clark [mailto:bcl...@spectraaccess.com] Sent: Monday, November 22, 2010 8:42 AM To: Kasper Adel Cc: nanog@nanog.org Subject: Re: Auditing a network to add Voice I'm not sure if Wireshark will let you do this...at least with TCP, we do use Wireshark to analyze RTP traffic which provides jitter/loss data, maybe a vendor provided LAN analyzer would provide this information I still think you're better of on using some type of tools and do the measurement in their network's live at various times of the day. Every path through the network is going to have different delays/jitter/loss at various times of the the day. You can probably get loss via RMON statistics in switches/routers, but delays/jitter requires that you are monitoring a data conversation at the TCP/IP layer and I'm not aware of network equipment (switches/routers) that watch individual TCP/IP layers to provide jitter/delay...that would require quite a bit of a devices resources. If you run the apps on their network live, they you are basically going to get the information you need about the overall quality of their network they have in place today. Bret On 11/22/2010 11:17 AM, Kasper Adel wrote: Hi Bret, These guys are not looking for measuring traffic generated by a tool, they want to measure what they have running now (not only Voice). I am not sue if measuring what they have or generating traffic and measuring it is the same thing. what do u think? thanks, Kim On Mon, Nov 22, 2010 at 5:54 PM, Bret Clark bcl...@spectraaccess.com mailto:bcl...@spectraaccess.com wrote: Iperf can be used to measure jitter and delay as well as simulate a quasi VoIP call. You can also use mtr under Linux which provides jitter and delay measurements from one point to another point. A g.729 call (lower quality) takes about ~40kbps and a g.711 (high quality) used about ~100Kbps of bandwidth. With most of today's networks, the problem isn't bandwidth related, but more with jitter, delay, and packet loss through the network...personally I'm a big fan of deploying QoS through out an infrastructure...well at least in our WAN infrastructure. Bret On 11/22/2010 09:59 AM, Kasper Adel wrote: Hi, My customer would like to add VoIP over their network and they asked us for an audit. the result of the audit would be simply you guys are ready for it Breaking it down [high level] for me sounds like : (suggestions are more than welcomed) : 1) Looking at hardware computation finite resources (cpu, memory...etc) 2) Looking at available bandwidth 3) QoS policy 4) High Availability and Fast Convergence Any thing else? They asked us to measure the KPIs (jitter, delay...etc) of their existing traffic, is there a way to do that? Thanks, Kim
RE: OT: VM slicing and dicing
1 GiGE switches at a minimum; some vendors (e.g., arista) have low cost 48 port 1000/1 switches. Cisco's UCS system uses 8 10 GiGE uplinks where the servers (running a hypervisor kernel) plug into a chassis backplane with 2 10 GiGE connectors each, that mux 10 GiGE and 4/8/16 GiG FC over the combined 80 Gig uplinks. Think about latency, not just bandwidth. 100 Mb is 100 times slower in serialization/deserialization of bits on/off the wire. Also, do you really want the cable management issues associated with multiples of 48 copper cables from servers to top-of-rack switches? -Original Message- From: Brandon Kim [mailto:brandon@brandontek.com] Sent: Tuesday, November 16, 2010 5:04 AM To: mysi...@gmail.com Cc: nanog group Subject: RE: OT: VM slicing and dicing Thanks for the suggestions James! One of the issues I had, (which is why I turned to NANOG) was that I wasn't entirely sure what keywords to search for!! So thank you for that. All of the criteria's you brought up are valid and I will add them to the list of things to consider. It's awfully difficult to figure out who can do what as it's just not possible to test all the different vendors out there unless you have a large RD team and a lot of time. I think we are on the same page as far as what We think I need. But just to clarify. 1) We'd like to be able to have a web portal where new or existing clients could request servers of all types: windows, linux etc... Configure what it is that they need and in some amount of time, the VM's are provisioned. They receive some kind of email confirming that their new provisioned server is available. 2) Backend - Since we haven't invested much time into the backend, we're open to all possibilities. It doesn't need to be VMware at all. Xen seems to be extremely popular. 3) Licensing - Of course this will be all unique to each vendor but the more complicated the licensing, the more it's a turn off and difficult to keep track of. Not to plug. But so far OnApp's pricing is very straightforward. 4) Multi-Tenant - Absolutely needs to support this. I don't expect anyone here to do research for me, but I assume that being a network operator, many of us would have some input and clearly I've received great feedback. I've been in touch with numerous vendors that were given to me from this thread and I can't wait to demo/try their products One question I do have for any that actually read through this entire email (haha) is about the physical network switch. Is there a case for the switch, especially in today's high density environment to go with 1GIG switches as the minimum? It seems pretty obvious but I'm wondering if it's really a necessity? Can anyone on this list argue that 10/100 will be suffice? Thanks again! Brandon Date: Mon, 15 Nov 2010 21:13:51 -0600 Subject: Re: OT: VM slicing and dicing From: mysi...@gmail.com To: brandon@brandontek.com CC: nanog@nanog.org On Tue, Nov 9, 2010 at 10:17 AM, Brandon Kim brandon@brandontek.com wrote: I'm not looking for companies that offer this service, but the actual software engines that allow you to create VM's on the fly. So a customer goes to your website and says I want Win2008 with 8gigs of RAM and 120gigs of HDD. Just like custom configuring a new PC. How about I send you some terms to search for, using your favorite search engine... Multi-Tenant Hosting Cloud ComputingIaaS / HaaS (Infrastructure as a Service)Self-Service Provisioning Because the question is so vague, I think you need more research. If you read the documentation of portal software, you should be able to tell to what extent it would be turn key Before looking too closely at any offering... some things to think about are.. How would you go about handling virtual networks and access to them? Will you want one shared network (with requisite Layer 2 security minefield), or will your portal of choice somehow decide to permission and make certain LANs available to certain users' VMs? There will be security and performance considerations that some portal software programs allow you to answer, and some do not. So you need to decide the hard requirements for security, management flexibility, UI attractiveness/ease of use, functionality for the end user, resource management, and price :) Different portals have different options, so define requirements first. A Multi-Tenant IaaS environment (meaning different users sharing pieces of metal, storage, etc) brings in some complexity. Think about how will the resources be balanced? E.g. Will you have a portal place workloads on its own, or rely on some outside system like vmware DRS. Will the portal implement and enforce resource SLAs for Network latency/loss, limit the number of VMs per NIC or per datastore, Memory, CPU and provide I/O response delay assurances, or will machines be left underutilized / overutilized, because the portal is bad
RE: Current trends in capacity planning and oversubscription
Sometimes it is a hard sell, but the factor most overlooked when designing high speed networks is that of designing for low latency. Bandwidth and over/under subscription are only part of the network design. Low latency networks (regional RTTs of 1-5 milliseconds; campus RTTs in the sub millisecond range for GiGE, and microsecond range for 10 GiGE) by their nature solve a lot of QoS problems, often relegating QoS as a method to be used in emergency cases only, such as DoS attacks. Here is something I have been thinking is not too far over the horizon: commodity 48 port x 10/100 GiGE switches; 10 GiG NICs on the desktop; commodity-priced 10,40, or 100 GiGE WAN links; while user bandwidth requirements rise at a much slower rate. Some switch vendors even today have 48 port 10 GiGE switches in the $25K range. My rule of thumb is that 1 GiGE link is an order of magnitude lower latency than a 100 Mbps link, and a 10 GiGE link is an order of magnitude lower latency than a GiGE link. -Original Message- From: Sean Donelan [mailto:s...@donelan.com] Sent: Tuesday, November 09, 2010 9:26 PM To: nanog@nanog.org Subject: Current trends in capacity planning and oversubscription While the answer is always it depends, I was wondering what the current rules of thumb university network engineers are using for capacity planning and oversubscription for resnets and admin networks? For K-12, SETDA (http://www.setda.org/web/guest/2020/broadband) is recommending: - An external Internet connection to the Internet Service Provider of at least 100 Mbps per 1,000 students/staff - Internal wide area network connections from the district to each school and between schools of at least 1 Gbps per 1,000 students/staff How does that compare with university and enterprise network rules of thumb?
RE: AS path question.
Some use AS prepends, not for traffic engineering, as ISPs often override AS prepends with private peering (communities/local pref settings), but for the simple purpose of making advertised prefixes stand out amongst a welter of BGP routes. -Original Message- From: Greg Whynott [mailto:greg.whyn...@oicr.on.ca] Sent: Wednesday, November 10, 2010 12:22 PM To: nanog@nanog.org list Subject: AS path question. Recently I adjusted the maxas-limit option on our router,logs started reporting routes being refused because the AS path is to long. seems to work as expected. when I looked at the logs I was a bit confused at what i was looking at... why is it there are multiple AS's in the path that appear to be the same AS? I expected an AS path comprised of mostly unique ASs. instead of this: 476330: Nov 10 14:55:07.247 EDT: %BGP-6-ASPATH: Long AS path 549 26677 6939 21011 43022 43022 43022 43022 43022 47359 47359 47359 47359 47359 47359 47359 47359 received from isp router: More than configured MAXAS-LIMIT i expected it would look more like: 476330: Nov 10 14:55:07.247 EDT: %BGP-6-ASPATH: Long AS path 549 26677 6939 21011 43022 47359 received from ... .. . thanks for your time again, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
RE: VM slicing and dicing
We've been looking at Cisco's Unified Computing System (UCS) blade server, which appears to have great potential. Very fast, and eliminates almost all top-of-rack copper cabling from servers to top-of-rack switch. Custom-built for VMWare optimization, but other virtualization OS's will run also from what I have read. Ten GiGE and FCoE are the entry points at the server access layer. -Original Message- From: Brandon Kim [mailto:brandon@brandontek.com] Sent: Tuesday, November 09, 2010 8:18 AM To: nanog group Subject: OT: VM slicing and dicing Hey gents: As always I value your input. Best resource on the planet! =) I'm hoping this isn't too off-topic if so please respond to me offline if so. I figured since most of everyone here are operators working in a datacenter, you may or may not have experience with virtualization software that allows you to configure VM's on the fly. I'm not looking for companies that offer this service, but the actual software engines that allow you to create VM's on the fly. So a customer goes to your website and says I want Win2008 with 8gigs of RAM and 120gigs of HDD. Just like custom configuring a new PC. Does anyone here have experience or knowledge of companies that offer this type of software engine? Thanks in advance! Brandon
RE: Ethernet performance tests
EXFO also sells the BRIX SLA verifier, which calculates RTT, packet loss, and jitter for various applications running on top of the link layer. -Original Message- From: Tim Jackson [mailto:jackson@gmail.com] Sent: Wednesday, October 27, 2010 6:54 PM To: Diogo Montagner Cc: nanog@nanog.org Subject: Re: Ethernet performance tests We dispatch a technician to an end-site and perform tests either head-head with another test set, or to a loop at a far-end.. We do ITU-T Y.156sam/EtherSAM and/or RFC2544 tests depending on the customer requirements. (some customers require certain tests for x minutes) http://www.exfo.com/en/Products/Products.aspx?Id=370 ^--All of our technicians are equipped with those EXFO sets and that module. Also covers SONET/DS1/DS3 testing as well in a single easy(er) to carry set.. -- Tim On Wed, Oct 27, 2010 at 6:32 PM, Diogo Montagner diogo.montag...@gmail.com wrote: Hello everyone, I am looking for performance test methodology for ethernet-based circuits. These ethernet circuits can be: dark-fiber, l2circuit (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet circuit can be a mix of these technologies, like below: CPE - metro-e - l2circuit - l2vpn - l2circuit - metro-e - CPE The goal is verify the performance end-to-end. I am looking for tools that can check at least the following parameters: - loss - latency - jitter - bandwidth - out-of-order delivery At this moment I have been used IPerf to achieve these results. But I would like to check if there is some test devices that can be used in situations like that to verify the ethernet-based circuit performance. The objective of these tests is to verify the signed SLAs of each circuit before the customer start to use it. I checked all MEF specifications and I only find something related to performance for Circuit Emulation over Metro-E (which is not my case). Appreciate your comments. Thanks! ./diogo -montagner
RE: Mobile Operator Connectivity
With the assumption that you will have a wired backhaul to your HQ over which the retail access-layer devices connect to commerce servers, make sure that the wireless carrier's gateways to their wired network (where the wired backhaul is connected to) are geographically well-dispersed such that wireless access traffic from (for example) suburban Los Angeles destined for a Los Angeles HQ data center, does not traverse the US back to the east coast before it enters the carrier's wired backbone. Surprisingly, some large wireless carriers appear to think that 2 continental traversals for each packet is an acceptable network design. I have experienced round trip latency between sites 50 miles apart measured at 750-1500 milliseconds when using GSM/CDMA wireless as the access layer method. The key is to ask the wireless carrier where the network-to-network interfaces between the wireless and wired backbone networks are located, and moreover, how many interfaces are there. Some large wireless carriers have a single wireless/wired gateway for the entire US! -Original Message- From: Leo Woltz [mailto:leo.wo...@gmail.com] Sent: Saturday, September 25, 2010 1:37 PM To: nanog@nanog.org Subject: Mobile Operator Connectivity I am looking for some guidance from the list. We will soon be deploying wireless payment devices (CDMA/GSM). We are looking at options on where to locate the servers that will run the backend payment gateways; we would like the least amount of latency between the servers and the wireless networks as possible. The wireless networks we will be deploying the devices on are: ATT Wireless Verizon Wireless Sprint PCS Rogers Wireless Bell Mobility Telus Mobility Vodafone I was thinking we have a few options, to try and peer with the wireless networks directly, buy bandwidth from networks that are directly peered with the wireless operators or the Global Roaming Exchange Peering service that Equinix runs but I have not been able to find out much more then what is on Equinix's public web site. We also have a need to peer with PayPal and Amazon. I welcome the lists comments and recommendations.
RE: US hunters shoot down Google fibre
Modern telephone pole aerial fiber uses all dialectric self-supporting (ADSS) technology, where the self-supporting component consists primarily of aramid yarn, the same material used for bullet-proof vests. This makes for an extremely light weight, almost indestructible fiber bundle. My guess is that ADSS fiber would deflect any bullets, or it would take a very good marksman using a very high caliber weapon to actually sever an aerial fiber. Now in the case described below where optical ground wire (OPGW) fiber is used as a component in the ground wire running at the top of high voltage transmission towers, it may be possible to hit the insulators at the top of the towers, but the ground wire itself is usually armored, with ADSS inside. Seems far-fetched to me. -Original Message- From: Eugen Leitl [mailto:eu...@leitl.org] Sent: Tuesday, September 21, 2010 3:05 AM To: nanog@nanog.org Subject: US hunters shoot down Google fibre http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre. aspx Repairers forced to ski in to Oregon back woods. Google has revealed that aerial fibre links to its data centre in Oregon were regularly shot down by hunters, forcing the company to put its cables underground. The search and advertising giant's network engineering manager Vijay Gill told the AusNOG conference in Sydney last week that people were trying to hit insulators on electricity distribution poles. The poles also hosted aerially-deployed fibre connected to Google's $US600 million ($A635 million) data centre in the Dalles, a small city on the Columbia River in the US state of Oregon. What people do for sport or because they're bored, they try to shoot at the insulators, Gill said. I have yet to see them actually hit the insulator, but they regularly shoot down the fibre. Every November when hunting season starts invariably we know that the fibre will be shot down, so much so that we are now building an underground path [for it]. Gill said that on one occasion, a snowstorm and avalanche prevented Google from transporting repairers and gear into the area of the cut. It usually used a helicopter or a Caterpillar D9 tractor for transport. It improvised by sending three technicians on skis to repair the fibre that got shot down. These guys had to cross country ski for three days, Gill said. [One guy] is carrying what is known as a fusion splicing kit on his backpack. He joked: These guys had to go in and fix the fibre while facing gunshots So [the] internet... [it's] more dangerous than you realise.
RE: Future of WiMax
For business purposes such as fixed wireless access for small branch offices, it would seem that Wi-Max is superior to current GSM and CDMA proprietary networks in that the upload/download speeds are symmetric. It appears that GSM and CDMA networks are based on the asymmetric low upload bandwidth/high download bandwidth model, thus placing severe restrictions on business use for fixed locations. -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Wednesday, June 16, 2010 12:35 PM To: nanOG list Subject: Future of WiMax A while back I remember reading a comment here that WiMax is not a future proof technology and that several manufacturers have dropped it or something to that effect. I think it was in the starting a WiMax ISP thread. This has stuck in my head, and I was curious if there was any truth to this. WiMax sounds promising, but I certainly don't hear a lot about it other than Sprint/Clear. Is it just that everyone that's doing wireless is sticking with relatively inexpensive 802.11 a/b/g/n products, or is WiMax really a dead end? ~Seth
RE: Router for Metro Ethernet
We use Cisco 3750 L3 switches for Metro Ethernet connectivity. The 3750 SFPs can run at wire speed up to 1 GiGE. The 3750s are very reliable, and have good, follow-the-sun technical support in case of problems. Some caveats: 1. only the ME version supports MPLS, in case you want to overlay an MPLS TE/VPN network on a Metro Ethernet Forum (MEF) ELAN raw Ethernet service. 2. If you are using IP multicast, make sure that the Metro Ethernet provider supports PIM snooping, otherwise (S,G) directed multicast packets will be flooded out all service provider ports that connect to your devices, emulating a 1993-style Ethernet hub. -Original Message- From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] Sent: Monday, April 12, 2010 9:43 PM To: Jeffrey Negro Cc: nanog@nanog.org Subject: Re: Router for Metro Ethernet On Mon, 12 Apr 2010, Jeffrey Negro wrote: In our case I believe we would be dealing with just static routes and a lines of ACL. Do you think the routing protocols are your largest resource usage in your scenario, or is it also just simple routing as well? Get a used 3550 or a new 3400ME or something. Sounds likeyuou'll get by just fine using an L3 switch. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Competition for Internap's FCP product.
The ability to manage bandwidth over multiple ISP links each of which may charge variable rates per Mb, and also be billed by the 95th percentile billing method, is the main justification for a device like the Routescience product. In my experience ROI is captured in a relatively short time. Since Routescience uses the second and third packets of the TCP 3-way handshake to calculate the fastest route to destination prefixes, then this is an added bonus to the ability to dial bandwidth up or down over numerous ISP links. Also Routescience-type devices free up the person who sits and calculates BGP best routes manually, so that person can perform more productive and efficient work in other areas. -Original Message- From: Rubens Kuhl [mailto:rube...@gmail.com] Sent: Thursday, February 25, 2010 11:23 AM To: nanog@nanog.org Subject: Re: Competition for Internap's FCP product. Is your burstable bandwidth cost high enough to pay 100K for a gear just to meet the commitments ? NAGIOS/CACTI monitoring alerts sent to someone (which may be hired help from any place in the world) would probably beat that in cost effectiveness. The performance requirement is where a line is drawn between manual configuration and automated BGP manipulation. Rubens On Thu, Feb 25, 2010 at 11:08 AM, Drew Weaver drew.wea...@thenap.com wrote: Hi, As my Avaya CNA/Route Science box begins to seriously age, and without the support of Avaya for 'Service Provider' uses of the product, I have been looking for alternatives to the product. The value we get from this product is mainly in the ability to easily manage our bandwidth commitments in a hands off way without having to manually manipulate anything. I have no real illusions that the 'performance' side of things is 'arguable' at best with these sorts of products due to the nature of the Internet. Internap to me stands out as essentially the only alternative to this product, but they have been tremendously difficult to work with, they won't allow us to demo a unit to see if it offers the same functionality as our current solution. The reason they won't allow us to a demo a unit is because they 'don't stock them'. So basically they have 0 units until someone orders one, that is fine if that is their policy but that hasn't really been our experience with other hardware vendors that want close to 100K for a piece of niche equipment. My questions are: -What are other people doing who currently use or used the Avaya/RS product in the past? -Does anyone know of any competition in this space (aside from hiring a guy that sits there and does this for us manually)? -Has Cisco's OER/PFR made any progress in the last few years (is anyone using it?) Sorry to disturb, -Drew
RE: Experiences with Comcast Ethernet/Transit service
PIM-snooping is not in the MEF specs, but should be if multicast is to work properly over a carrier's Ethernet service. Regardless of the specs, RFPs and other user requirements for Ethernet services should include a must have clause requiring PIM-snooping functionality. -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Monday, January 04, 2010 12:13 PM To: Holmes,David A Cc: Brandon Galbraith; nanog@nanog.org Subject: RE: Experiences with Comcast Ethernet/Transit service On Mon, 4 Jan 2010, Holmes,David A wrote: I do not know of Comcast's Ethernet services specifically, but a general problem with carrier Ethernet services that are based upon the Metro Ethernet Forum (MEF) is that PIM-snooping is not implemented for multicast traffic. The absence of PIM-snooping results in the carrier's Ethernet service operating like a 1990's style Ethernet hub in which (S,G) multicast packets are incorrectly flooded out all user ports. Not implemented because it's not in the MEF specs or not implemented because of carrier operational practice? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
RE: FTTH Active vs Passive
Running fiber in the sewers can lead to many very expensive problems for homeowners. This is so because some municipalities consider the lateral sewer line running from the main sewer line in the street to the homeowners' house the responsibility of the homeowner. If the lateral should get blocked in any way, it is the homeowners' responsibility to fix and/or replace it. Assuming the costs associated with digging a 30 foot long, 15 foot deep trench from the homeowner's property line to tie into the city sewer system can easily cost US $10,000.00 - $15,000.00. This is not usually covered by homeowners' insurance. -Original Message- From: Michael Holstein [mailto:michael.holst...@csuohio.edu] Sent: Wednesday, December 02, 2009 8:34 AM To: Curtis Maurand Cc: NANOG list Subject: Re: FTTH Active vs Passive I'd look more to what they're doing in Rochester, NY: http://rocwiki.org/Sewer_Fiber_Optic_Network Run it in the sewers. The sewer system runs to every building and household in the municipality. No need to re-trench anything. Ahh .. the TISP : http://www.google.com/tisp/install.html Regards, Michael Holstein Cleveland State University
RE: Failover how much complexity will it add?
Most purpose-built routing appliances use ternary content addressable memory (TCAM) in order to accomplish deterministic, hardware-based, longest-prefix lookups in large routing tables, such as a full Internet BGP feed. TCAM is used to replace software-based table lookup algorithms which have been empirically shown to lack scalability as the number of routes in the routing table increases, and as the line rate in/out of the routers increases. Current TCAM hardware-based routing engines scale to 10 Gbps, and beyond. Much research has been done in this area in the last 15 years. I don't think general purpose BSD/Linux systems meet the scalability requirement for deterministic network design. Nothing political about that. -Original Message- From: a...@baklawasecrets.com [mailto:a...@baklawasecrets.com] Sent: Monday, November 09, 2009 8:36 AM To: nanog@nanog.org Subject: Re: Failover how much complexity will it add? Hi Joe, I agree with most of what you say below regarding linux sysadmin, BSD etc. I'm quite happy and actually would prefer building a linux solution on our own hardware. However, politically I think this is going to be difficult. I just feel that they will be more comfortable with embedded network boxes as a pose to a linux solution. I guess what I'm saying is this is partially a political thing. Adel On Mon 3:20 PM , Joe Greco jgr...@ns.sol.net wrote: Thanks, I've taken your advice and decided to reconsider my requirement for a full routing table. I believe I'm being greedy and a partial table will be sufficient. With regards to Linux/BSD, its not the CLI of quagga that will be an issue, rather the sysadmin and lack of supporting infrastructure for Linux boxes within the organisation. So things like package management, You don't need to run Apache on your router. syslog servers, If you didn't have syslog servers for the Cisco, you don't need one for the Quagga. monitoring, If you didn't monitor the Cisco, you don't need to monitor the Quagga. understanding of security issues etc. What security issues? The thing is, people get all tied up over this idea that it is some major ongoing burden to support a Linux based device. I have a shocker for you. The CPE your residential broadband relies on may well run Linux, and you didn't even know it. The wifi router you use may run Linux. There are thousands of embedded uses for Linux. I highly doubt that the average TiVo user has a degree in Linux. Many different things you use in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly without any need of someone to handhold them on security issues. Of course, security issues do come up. But they do with Cisco as well. A proper Linux router doesn't have ports open, aside from bgp and ssh, and those can be firewalled appropriately. This makes it very difficult to have any meaningful security problems relating to the platform... You can expect the occasional issue. Just like anything else. But trying to compare it to security issues on a general Linux platform is only meaningful if you're trying to argue against the solution. (I'm a BSD guy myself, but I don't see any reason for undue Linux paranoia) I don't want to leave them with a linux/bsd solution that they won't be able to maintain/manage effectively when I am gone. If they're unable to maintain something as straightforward as BSD or Linux when you're gone, this raises alarm bells as to whether or not BGP is really suited for them. BGP is *much* more arcane, relatively speaking. You can go to your local bookstore and pick up a ton of Linux or BSD sysadm books, but you'll be lucky to find a book on BGP. Thanks for your comments. Look forward to hearing which solutions come back into the mix having dropped the full routing table requirement. There's a whole plethora of BGP-capable gear that becomes possible once you make that call. Cisco and Juniper both make good gear. A variety of other mfrs do as well. Something as old as an Ascend GRF 400 (fast ethernet, line speed, 150K routes, ~1998?) is perfectly capable of dealing with the load, though I mention this primarily to make the point that there is a lot of equipment within the last decade that can support this. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net [1] We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. Links: -- [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net
RE: bgp best path compare-routerid implementation example
BGP load-balancing appliances such as the old Routescience Pathcontrol provided a deterministic end-to-end solution by measuring the RTTs of the second and third packets of the TCP 3-way handshake between the commercial web site and user destination networks. A full BGP feed was required from each ISP in the commercial web site's border routers. Over time, by measuring the 3-way handshake's RTTs, Pathcontrol would statistically determine the best route to destination networks, and cause that route to be injected into the border router's BGP table using a BGP route-reflector configuration wherein the Pathcontrol was a route-reflector client that advertised the calculated best route. I think that this scientific approach to BGP load-balancing is intuitively and formally superior to other methods, although bandwidth scalability may be a drawback of the appliance load-balancing approach. -Original Message- From: Austin Wilson [mailto:aust...@bandcon.com] Sent: Friday, September 25, 2009 11:22 AM To: devang patel Cc: nanog@nanog.org Subject: RE: bgp best path compare-routerid implementation example Dev, Yes, using that command, it will use the lowest routerid as its preferred tie breaker path. Though, if all of your providers have different MEDs and you are using MEDs to engineer you traffic, your router should never have to tie break any traffic. Also any of the higher preference metrics will interfere with what you are trying to accomplish with a lower metric. Dani suggested changing the origin code so it wouldn't affect what you are trying to do with MEDs. Everything else is dependent on how you want to manage your network. Austin Wilson From: devang patel [mailto:devan...@gmail.com] Sent: Friday, September 25, 2009 11:07 AM To: Austin Wilson Cc: nanog@nanog.org Subject: Re: bgp best path compare-routerid implementation example Hi... So according to command it will select the path received from lowest router id right... so if you are sure about the path selection pattern then its good idea to use it... And true that path selection change based on own network design... is it good idea to set all received route attribute to particular origin code i as Dani showed in presentation... well again I guess answer will be depends on network design... Thanks, Dev On Fri, Sep 25, 2009 at 11:50 AM, Austin Wilson aust...@bandcon.commailto:aust...@bandcon.com wrote: Dev, This is usually used to offset the oldest route metric. The problem is that when a link fails and comes back online, traffic can shift from one provider to another in the middle of your billing cycle. This then could mean you get double billed for that traffic. People use the command to basically turn off the oldest route metric and use the routerid (not peering ip) to make the last decision on where to send your traffic. This is commonly called tie breaker traffic. If a peer fails with this command enabled, when the peer comes back online, traffic should be restored to the original level before the failure. A possible issue with this command is that if a local peer's route/session flaps it could have more of an effect on your network/router as it will always try move those routes back to the FIB. That's probably why they implemented this metric in the first place, the oldest route is the most stable. Another issue is that you are at the mercy of vendor's routerid when your router decides where to send your tie breaker traffic. Level3 gets most of this traffic since they have such low routeids. There are ways to get around this problem and take back control of your tie breaker traffic. Dani did a pretty good tutorial on this issue and its located here: http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2nm=n anog46 Basically he suggests using MEDs to change the tie breaker as part of a complete BGP traffic engineering solution. Doing the things listed there and elsewhere will mean you won't even have to use this command. Austin Wilson -Original Message- From: devang patel [mailto:devan...@gmail.commailto:devan...@gmail.com] Sent: Thursday, September 24, 2009 9:24 PM To: nanog@nanog.orgmailto:nanog@nanog.org Subject: bgp best path compare-routerid implementation example Hello Nanog, I am looking for the *bgp best path compare*-*routerid* implementation example? I know the function of it but looking for some scenario where its been used... Thanks, Dev
RE: Network Ring
An additional requirement often overlooked by Metro Ethernet architects is to ensure that layer 3 multicast stateful protocols are implemented in the carrier equipment. In order to ensure that PIM (S,G) stateful packets are not flooded out all ports in customers' geographically-dispersed switches, PIM snooping must be implemented in the carrier's equipment. Otherwise, the carriers' Metro Ethernet service operates like a 1990's-style shared hub incorrectly flooding (S,G) packets. For customers that have constant 10+ Mbps (S,G) multicast streams, the absence of PIM snooping effectively renders 10+ Mbps ports useless. -Original Message- From: ty chan [mailto:chanty...@yahoo.com] Sent: Friday, September 11, 2009 12:29 AM To: Rubens Kuhl Cc: nanog@nanog.org Subject: Re: Network Ring Does anyone have best practise for implementing those technologies ? I am currently doing a testing LAB with CISCO REP since i have a few Metro on hand. It works quite well in my LAB. There is one Request Time Out if the link break BUT it is physical layer not REP :) From: Rubens Kuhl rube...@gmail.com To: ty chan chanty...@yahoo.com Cc: nanog@nanog.org Sent: Monday, September 7, 2009 8:15:23 PM Subject: Re: Network Ring My vote goes to proprietary ring protection from the vendor you choose: - EAPS (Extreme) - REP (Cisco) - MRP (Foundry/Brocade) - EPSR (Allied Telesis) Although EAPS is implemented in all Extreme switches, select models from the other vendors implement ring protection, but these models also do other things you might want your network to have (QinQ, per-VLAN controls). Rubens On Mon, Sep 7, 2009 at 1:14 AM, ty chanchanty...@yahoo.com wrote: Dear all, I am in process of planning ring network to cover 15 POPs in City. Some technologies are chosen for consideration like SDH(Huawei), PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). The purpose is to provide L2 Ethernet connectivities from POPs to central point (DC) and ring protection. I know you all are in those network for years. can you give me some advises? Best regards, chanty
RE: SA pigeon 'faster than broadband'
This says more about current ADSL technology not really being broadband than it does about South Africa's telecommunications infrastructure. Doing the arithmetic, my Southern California ATT 384/1.5 ADSL connection would take approximately 23 hours to transmit 32 Gb (4 GB x 8) with the 384 Kbps upload speed. The referenced BBC article says that the South African link took 2 hours to transmit 4% of the 32 Gb, but assuming wire speed my ADSL connection would transmit 8% of 32 Gb in that same 2 hour time span. The BBC article does not mention the ADSL upload speed, but my feeling is that the slow transfer rate has much more to do with ADSL than South Africa's government. -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Friday, September 11, 2009 2:21 PM To: William Herrin Cc: na...@merit.edu Subject: Re: SA pigeon 'faster than broadband' On 11/09/2009 21:13, William Herrin wrote: 180kbps is more or less middle-of-the-road for ADSL. In terms of technology, it's about as close to bottom of the range as you can get. The south african incumbent, Telkom, have three different products, described here: http://www.telkom.co.za/products_services/dsl/cost_dsl_cost.html I love the product names: their 128k/384k product is called FastDSL. Their top-of-the-range, gold plated product is a 512k/4M trailblazer service called FastestDSL. The irony of it all... There is hope for telecoms in ZA, though - there's been several major changes to the ZA telecoms scene over the last year. A court ruling in august last year effectively opened up the telecoms market so that any company could get a generic telecoms license (VANS - value-added network service). The court case was fought tooth and nail by the ministry of communications who seemed desperate to protect the telkom / neotel duopoly. This was possibly related to the fact that Telkom is 39.8% owned by the ZA government and is something of a money-spinner. But in a major step forward for the country, the high court in Jo'burg disagreed that licenses should be restricted and refused leave to appeal after the ruling. There are now ~600 VANS license holders in south africa, up from 2 last year. The second event was that the ZA minister of communications for the last 10 years, Ivy Matsepe-Casaburri, retired from her position as minister due to natural causes. As usual for controversial figures, there were different points of view expressed on her life's work. One - typically held by government and other official figures - praised her role in communications, saying that with her incisive intellect she has made an invaluable contribution to the development of policy in various fields, including information and communication technology. Another point of view from the industry put things slightly differently: http://blogs.timeslive.co.za/patternrecognition/2009/04/07/ivy-matsepe-c asaburri-has-died/ Last, but not least, the Seacom cable linking ZA to Marseille, Mumbai and a bunch of countries up the east coast of Africa - a cable which Matsepe-Casaburri did her best to prevent from landing in south africa - is nearing completion. This will take away Telkom's monopoly on international connectivity, which is the second major step after market liberalisation required to actually improve the industry's infrastructure. So, good news all around. Let's hope that IP over carrier pigeon will soon become a thing of the past. Nick
RE: Multi-homed implementation and BGP convergence time
The time should be measured in seconds for your BGP advertised prefixes to propagate to most of the Internet. It may take longer for some isolated ISP's to receive the routes. If you use the longest prefix method to advertise to your preferred ISP, a convergence to the backup ISP (where shorter prefixes are advertised) may take 30 seconds or so max. Converging back to the preferred ISP should take a few seconds max. -Original Message- From: andrew.clayba...@securian.com [mailto:andrew.clayba...@securian.com] Sent: Friday, September 11, 2009 1:55 PM To: nanog@nanog.org Subject: Multi-homed implementation and BGP convergence time Hello - my company currently has two connections with a single tier 1 ISP. We are using the AS from our ISP at this time. In the next month we will be implementing a third connection with a second tier 1 ISP, so we will now be using our own AS number on all three routers. My question is when we implement the new connection and update our existing connections to use are own AS number, how much downtime will there be? So far the second ISP has only said that it could be hours for BGP to fully converge. We are looking for more detail about how long the outage will be and how widespread. Will it be relatively short to our customers that are on one of the ISPs we are directly connected to? Is downtime less for customers on other tier 1 ISPs versus tier 2, etc. ISPs? We will only be receiving a default route on each of the three connections. Our routers will be advertising a small number of routes - 6 to 8. Thank you. Andy Claybaugh
RE: WS-X6148A-GE-TX performance question
Cisco recommends both cards for access-layer use, principally as wiring closet aggregation for desktop users. Cisco recommends 65xx or 67xx line cards for backbone (read deterministic) connections, which means that only 65xx devices with sup720s, or older switch fabric modules can be used for deterministic network design. Note that Etherchannel limitations apply to both cards. Also running one port in a group of 8 at line rate ( for example using that port as a SPAN destination for a VLAN where traffic exceeds 1 Gbps) will cause drops on the other ports in the group. (see http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a 0080094714.shtml ) -Original Message- From: Crooks, Sam [mailto:sam.cro...@experian.com] Sent: Thursday, September 10, 2009 2:59 PM To: Bill Blackford; Scott Spencer Cc: nanog@nanog.org Subject: RE: WS-X6148A-GE-TX performance question the other difference between WS-X6148-GE-TX and WS-X6148A-GE-TX is the A has better QoS queuing potential (more hardware queues available) and a lower list price... As I recall, there are 6 ethernet controllers with 8 ports on each... (8:1 oversubscription among the adjacent ports in a port group which use the same ethernet controller). The card is a Classic card, so the whole card is limited to 32 Gbps to the backplane, which given the oversubscription ratio, shouldn't be much of an issue... -Original Message- From: Bill Blackford [mailto:bblackf...@gmail.com] Sent: Thursday, September 10, 2009 4:40 PM To: Scott Spencer Cc: nanog@nanog.org Subject: Re: WS-X6148A-GE-TX performance question There was a good thread on Cisco-nsp regarding this exact subject recently. My recollection is that both X6148 and X6148A have just 6 1GB ASICs. Therefore the over subscription rate is 8:1. The biggest difference between these LC's is that X6148A will support large MTU whereas X6148 will not. -b On Thu, Sep 10, 2009 at 2:17 PM, Scott Spencer sc...@dwc-computer.comwrote: Are the X6148A cards dedicated 1 gb/s uplink for each port ( shared 32 Gb/s bus , as long as each port is it's own 1 gb/s still to the 32gb/s bus and not shared with 7 other ports, so effectively just 125Mb/s per port then if all used at full/even capacity) ? I can't really find anything much on X6148A internal architecture online, but it would seem that each port gets its own 1gb/s link to the card/backplane, and that the bottleneck then is the 32gb/s backplane (which is fine, as long as it's not 1 gb/s per each set of 8 ports!). Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 mailto:sc...@dwc-computer.com sc...@dwc-computer.com http://www.dwc-it.com/ www.dwc-it.com Sales of new and used Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ -- Bill Blackford Network Engineer
RE: Link capacity upgrade threshold
Another approach to collecting buffer utilization is to infer such utilization from other variables. Active measurement of round trip times (RTT), packet loss, and jitter on a link-by-link basis is a reliable way of inferring interface queuing which leads to packet loss. A link that runs with good values on all 3 measures (low RTT, little or no packet loss, low jitter with small inter-packet arrival variation) can be deemed not a candidate for bandwidth upgrades. The key to active measurement is random measurement of the links so as to catch the bursts. The BRIX active measurement product (now owned by EXFO) is a good active measurement tool which randomizes probe data so as to, over time, collect a randomized sample of link behavior. -Original Message- From: Aaron J. Grier [mailto:agr...@poofygoof.com] Sent: Tuesday, September 01, 2009 12:19 PM To: nanog@nanog.org Subject: Re: Link capacity upgrade threshold On Tue, Sep 01, 2009 at 11:55:45AM +0100, Paul Jakma wrote: On Sun, 30 Aug 2009, Nick Hilliard wrote: In order to get a really good idea of what's going on at a microburst level, you would need to poll as often as it takes to fill the buffer of the port in question. This is not feasible in the general case, which is why we resort to hacks like QoS to make sure that when there is congestion, it is handled semi-sensibly. Or some enterprising vendor could start recording utilisation stats? do any router vendors provide something akin to hardware latches to keep track of highest buffer fill levels? poll as frequently/infrequently as you like... -- Aaron J. Grier | Not your ordinary poofy goof. | agr...@poofygoof.com
RE: Alternatives to storm-control on Cat 6509.
In my opinion the Sup32 platform has some limitations when the technology is considered for high data rate, deterministic carrier customer-facing scenarios. Cisco sells the Sup32 as a wiring closet aggregation switch the main purpose of which is to connect desktop users to central core switches. In addition to the lack of storm-control/broadcast suppression mentioned below, the 61XX line cards also have a limit of, I believe, 2 ports in an Etherchannel. Additionally, and perhaps most significantly for deterministic network design, the copper cards share input hardware buffers for every 8 ports. Running one port of the 8 at wire speed will cause input drops on the other 7 ports. Also, the cards connect to the older 32 Gbps shared bus. In my view, with high data rates, it is difficult, if not impossible, to build a deterministic network with Sup32s. Cisco's solution for designing a deterministic network is the sup720 which has a 720 Gbps crossbar bus. The 67XX 48 port copper line cards have 2 20 Gbps connectors to the 720 Gbps bus, the 24 port fiber sfp line cards have a single 20 Gbps connector to the crossbar bus, and the 10 GiG 67XX line cards have 2 20 Gbps bus connectors. The crossbar bus connects line card connectors to each other in a point-to-point fashion. 67XX line cards are adequately provisioned with input and output buffers. There is still 40/48 (1 GiGE copper), 20/24 (1 GiGE sfp), and 40/160 (10 GiGE X2) oversubscription of ports to switch fabric connectors, however. Sup720 routing table lookups via Ternary Content Addressable Memory (TCAM) still use the 32 Gbps bus to access the TCAM to search for next hop for destination IP network. -Original Message- From: Peter George [mailto:peter.geo...@lumison.net] Sent: Friday, August 21, 2009 3:40 AM To: nanog@nanog.org Subject: Alternatives to storm-control on Cat 6509. Hello, I have several Catalyst 6500 (Supervisor 32) aggregation switches with WS-X6148A-GE-TX and WS-X6148-GE-TX line cards. These line cards do not support storm-control/broadcast suppression. This impacted us badly during a recent spanning tree event. As it stands, we are at risk of overwhelming control planes with excess broadcast or multicast traffic, and I need to find alternative ways to protect these switches. I have been researching STP enhancements, and control-plane policing in the following documents, and would appreciate advice from engineers who may have had to implement similar workarounds for storm-control in a service provider setting. * Configuring Denial of Service Protection http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con figuration/guide/dos.pdf * Configuring Control Plane Policing http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/con figuration/guide/cntl_pln.pdf * Configuring Optional STP Features http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/con figuration/guide/stp_enha.pdf So, if we can't mitigate against STP events using storm-control or broadcast suppression, what might be the best combination of STP enhancements and control-plane policing? For example, is it possible to rate-limit broadcast/multicast, STP and ARP on a per VLAN basis? If so, how? Many thanks, P -- Peter George Lumison t: 0845 1199 900 d: 0131 514 4022 P.S. Lumison have changed the way businesses communicate forever http://www.unified-communications.net/ -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email.
RE: TransAtlantic 40 Gig Waves
It seems intuitive, but according to basic queuing theory splitting up a single channel into N fixed smaller channels makes the response time (T), N times worse, where T= (queuing + transmission time). -Original Message- From: Rod Beck [mailto:rod.b...@hiberniaatlantic.com] Sent: Monday, August 17, 2009 9:14 AM To: Richard A Steenbergen Cc: nanog@nanog.org Subject: RE: TransAtlantic 40 Gig Waves Rod, do you know if the 40G waves increased the spectrum efficiency of your fiber? On land systems they pretty much break even, i.e. you can have a 100GHz 40G channels or 4x25GHz 10G channels but at the end of the day you still get the same amount of signal out of the fiber. I don't know whats being done on undersea cables though. Eventually this will get better too, and 40G will become the native wavelength standard with 10G being muxed onto them, similar to what we saw with the transition from 2.5G-10G 10 years ago. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) Rod. This is direct from engineering: The number of wavelengths or channels Hibernia have on their DWDM infrastructure remains the same, however now each wave can be at a rate of 40Gb/s instead of only 10Gb/s. In the extreme case, we get 4 times the capacity, but in reality, because of the existing installed 10G's, we would not necessarily swap out all existing cards. We could say the overall increase in capacity is up-to 4 times. The enabling technology is based on advanced encoding techniques allowing a greater rate of symbol transfer.
RE: Ahoy, SLA boffins!
We use the BRIX active measurement system (BRIX now owned by EXFO) which gathers round trip time, packet loss, and jitter randomly every minute 24x7x365 for our major backbone links to calculate SLAs. Network Availability can be measured empirically using BRIX calculated values of packet loss, and expressed in terms of #9's, which BRIX will also calculate over any time period for which BRIX historical data is being kept. BRIX historical data is kept on an embedded Oracle data base. BRIX usually runs on a Solaris SMP server. -Original Message- From: Bill Woodcock [mailto:wo...@pch.net] Sent: Tuesday, July 28, 2009 9:34 PM To: nanog Subject: Ahoy, SLA boffins! So I've embarked on the no-doubt-futile task of trying to interpret SLAs as empirically-verifiable technical specifications, rather than as marketing blather. And there's something that I'm finding particularly puzzling: In most SLAs, there seem to be two separate guarantees proffered: one concerning network availability and one concerning packet loss. Now, if I were to put my engineer hat on, and try to _imagine_ what the difference might be, I might imagine network availability to have something to do with layer-2 link status being presented as up, while packet loss would be the percentage of packets dropped. But when I actually read SLAs, network availability is generally defined as the portion of the month that the path from the customer's local loop to the transit or peering routers was available to transmit packets. Packet loss, on the other hand, is generally defined as the portion of packets which are lost while crossing that exact same piece of network. Now, what am I missing here? Is this one of those Heisenberg things, where network availability is the time the network _could have_ delivered a packet _when you weren't actually doing so_, while packet loss is the time the network _couldn't_ deliver a packet when you _were_ actually doing so? Is network availability inherently unmeasurable on a network that's less than 100% utilized? Am I over-thinking this? Seriously, though, I know there are people who don't consider SLAs to be fantasy-fiction, and some of them must not be innumerate, and some subset of those must be on NANOG, and the intersection set might be equal to or greater than one, right? Can anybody explain this to me in a way I can translate into code, while still taking myself seriously? -Bill
RE: Unicast Flooding
In a layer 3 switch I consider unicast flooding due to an L2 cam table timeout a design defect. To test vendors' L3 switches for this defect we have used a traffic generator to send 50-100 Mbps of pings to a device that does not reply to the pings, where the L3 switch was routing from one vlan to another to forward the pings. In defective devices the L2 cam table entry expires, causing the 50-100 Mbps unicast stream to be flooded out all ports in the destination vlan. In my view the L3 and L2 forwarding state machines must be synchronized such that the L3 forwarding continues as long as there are packets entering the L3 switch on one vlan, and exiting the switch on another vlan via routing. It seems that gratuitous arps are a workaround which serves to reset the cam entry timeout interval, but not an elegant solution. -Original Message- From: Matthew Huff [mailto:mh...@ox.com] Sent: Wednesday, June 17, 2009 2:58 PM To: 'Brian Shope'; 'nanog@nanog.org' Subject: RE: Unicast Flooding Unicast flooding is a common occurrence in large datacenters especially with asymmetrical paths caused by different first hop routers (via HSRP, VRRP, etc). We ran into this some time ago. Most arp sensitive systems such as clusters, HSRP, content switches etc are smart enough to send out gratuitous arps which eliminates the worries of increasing the timeouts. We haven't had any issues since we made the changes. After debugging the problem we added mac-address-table aging-time 14400 to our data center switches. That syncs the mac aging time to the same timeout value as the ARP timeout Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Brian Shope [mailto:blackwolf99...@gmail.com] Sent: Wednesday, June 17, 2009 5:33 PM To: nanog@nanog.org Subject: Unicast Flooding Recently while running a packet capture I came across some unicast flooding that was happening on my network. One of our core switches didn't have the mac-address for a server, and was flooding all packets destined to that server. It wasn't learning the mac-address because the server was responding to packets out on a different network card on a different switch. The flooding I was seeing wasn't enough to cause any network issues, it was only a few megs, but it was something that I wanted to fix. I've ran into this issue before, and solved it by statically entering the mac-address into the cam tables. I want to avoid this problem in the future, and I'm looking at two different things. The first is preventing it in the first place. Along those lines, I've seen some recommendations on-line about changing the arp and cam timeouts to be the same. However, there seems to be a disagreement on which is better, making the arp timeouts match the cam table timeouts, or vice versa. Also, when talking about this, everyone seems to be only considering routers, but what about the timers on a firewall? I'm worried that I might cause other issues by changing these timers. The second thing I'm considering is monitoring. I'd like to setup something to monitor for any excessive unicast flooding in the future. I understand that a little unicast flooding is normal, as the switch has to do a little bit of flooding to find out where people are. While looking for a way to monitor this, I came across the 'mac-address-table unicast-flood' command on Cisco switches. This looked perfect for what I needed, but apparently it is currently not an option on 6500 switches with Sup720s. Since there doesn't appear to be an option on Cisco that monitors specificaly for unicast floods, I thought that maybe I could setup a server with a network card in promiscuous mode and then keep stats of all packets received that aren't destined for the server and that also aren't legitimate broadcasts or multicasts. The only problem with that is that I don't want to have to completely custom build my own solution. I was hoping that someone may have already created something like this, or that maybe there is a good reporting tool for wireshark or something that could generate the report that I want. Anyone have any suggestions on either prevention/monitoring? Thanks!! -Brian
RE: NPE-G2 vs. Sup720-3BXL
Some things to remember about the MSFC2s when designing a deterministic network: Without the switch fabric module, the 6509 only has a 32 Gbps contention-based BUS as a backplane. Also I believe only classic line cards work without the switch fabric module. Classic line cards share hardware port buffers between adjacent ports (groups of 8 ports for copper cards) such that it is possible when one port is run at sustained wire speed, the hardware port buffer capacity is exhausted, causing drops on the other ports. The sup720 has the 720 Gbps switch fabric module integrated on the supervisor engine freeing up slots 5/6 where the switch fabric line cards are inserted with an MFSC2. -Original Message- From: Adam Armstrong [mailto:li...@memetic.org] Sent: Monday, May 18, 2009 4:20 AM To: David Storandt; nanog@nanog.org Subject: Re: NPE-G2 vs. Sup720-3BXL David Storandt wrote: We're stuck in an engineering pickle, so some experience from this crew would be useful in tie-breaking... We operate a business-grade FTTx ISP with ~75 customers and 800Mbps of Internet traffic, currently using 6509/Sup2s for core routing and port aggregation. The MSFC2s are under stress from 3x full route feeds, pared down to 85% to fit the TCAM tables. One system has a FlexWAN with an OC3 card and it's crushing the CPU on the MSFC2. System tuning (stable IOS and esp. disabling SPD) helped a lot but still doesn't have the power to pull through. Hardware upgrades are needed... We need true full routes and more CPU horsepower for crunching BGP (+12 smaller peers + ISIS). OC3 interfaces are going to be mandatory, one each at two locations. Oh yeah, we're still a larger startup without endless pockets. Power, rack space, and SmartNet are not concerns at any location (on-site cold spares). We may need an upstream OC12 in the future but that's a ways out and not a concern here. Our engineering team has settled on three $20k/node options: - Sup720-3BXLs with PS and fan upgrades - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing off to NPE-G2s across a 2-3Gbps port-channel - Sup2s as switches + ISIS + statics and no BGP, push BGP edge routing off to a 12008 with E3 engines across a 2-3Gbps port-channel. Have a look at the ASR1002 + ESP5/10G Stable for BGP+ISIS as far as our experience goes. adam.
RE: integrated KVMoIP and serial console terminal server
We have just implemented Avocent console and power concentrators. Console servers are reachable via a highly customizable web interface. The Avocent software can also be virtualized on VMWare. Console connectivity can be provisioned to first try SSH via the IP network, and automatically failover to a dial-up modem connection if the network is down. For power both AC and DC power supplies are supported. With DC the battery plant main fuse panel connects to the device that is used to power cycle the electronic equipment using low amperage grasshopper fuses for each device. I believe that Avocent is the only vendor with DC power-cycle support. The serial cables for the device consoles do not require power supplies as indicated below. -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Friday, April 24, 2009 9:52 AM To: Joe Abley Cc: NANOG list Subject: Re: integrated KVMoIP and serial console terminal server I haven't really found a combo unit I like as yet. For KVM, I like the Raritan products. For Serial, I prefer the Avocent line. Owen On Apr 23, 2009, at 3:17 PM, Joe Abley wrote: Hi all, What is everybody's favourite combination rack-mount VGA/USB KVM- over-IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/RJ45 plant is not necessary; in this application everything is in the same cabinet. Avocent seem to make a likely-looking box, but (a) it's a bit insanely expensive, and (b) the adapters that you connect using RJ45 to the avocent and via RS232 to the serial devices *each seem to require a power supply* which frankly makes me recoil in horror. Perhaps I mis-read the glossy web page. Advice would be appreciated; direct mail is fine; I can summarise back to the list if there is interest in me doing so. Joe
RE: IXP
But I recollect that FORE ATM equipment using LAN Emulation (LANE) used a broadcast and unknown server (BUS) to establish a point-to-point ATM PVC for each broadcast and multicast receiver on a LAN segment. As well as being inherently unscalable (I think the BUS ran on an ASX1000 cpu), this scheme turned the single stream concept of multicast on its head, creating essentially a unicast stream for each multicast PVC client. -Original Message- From: Lamar Owen [mailto:lo...@pari.edu] Sent: Tuesday, April 21, 2009 1:21 PM To: nanog@nanog.org Subject: Re: IXP On Monday 20 April 2009 18:57:01 Niels Bakker wrote: Ethernet has no administrative boundaries that can be delineated. Spanning one broadcast domain across multiple operators is therefore a recipe for disaster. Isn't this the problem that NBMA networks like ATM were built for? Cheap, fast, secure. It is obvious which two Ethernet chose. And which two ATM chose. Although secondhand ATM gear is coming down in price ATM has its own issues, but the broadcast layer 2 problem isn't one of them. Seems to me Ethernet layer 2 stuff is just trying today to do what ATM gear did ten years ago. Faster, of course, but still much the same. But, again, too bad ATM was just too expensive, and too different, and Gigabit Ethernet just too easy (at the time).
RE: Network SLA
From the network operators' standpoint, designing a network that operates at 50% utilization (without using ponderous QoS schemes) assumes that there is no random queuing behavior in the network that can result in dropped packets and large variations in packet arrival jitter. An active measurement tool such as BRIX gathers empirical data for packet drops and jitter from which accurate predictions about network behavior can be made. Think of active measurement tools as a means of implementing a scientific approach to determining network behavior. From the users' standpoint, BRIX can be used to validate the service providers' contractual SLA, and provide empirical data to support SLA violation penalties. -Original Message- From: Saqib Ilyas [mailto:msa...@gmail.com] Sent: Wednesday, April 15, 2009 4:11 AM To: nanog@nanog.org Subject: Re: Network SLA Hmmm. Good point. Perhaps the Internet traffic gets only a small share of the link capacity and the rest is reserved for corporate clients' VPN traffic etc. I was thinking more along the lines of corporate SLAs, not for Internet traffic. On Wed, Apr 15, 2009 at 4:05 PM, Rod Beck rod.b...@hiberniaatlantic.comwrote: Congestion is more common than you think. And by the way, if congestion is not a problem in Pakistan, then why is the VoIP qualit so poor? :) Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.b...@hiberniaatlantic.com rodb...@erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -Original Message- From: Saqib Ilyas [mailto:msa...@gmail.com msa...@gmail.com] Sent: Wed 4/15/2009 11:22 AM To: nanog@nanog.org Subject: Re: Network SLA I talked to the NOC personnel at a small (compared to North American standards) ISP in Pakistan. They said that their core links are operating at less than 50% utilization most of the time. Under such conditions, violating SLA conditions in the core is unlikely. If such is also the case with most service providers in the North America as well, then why would they even use active measurement such as iPerf or BRIX or Cisco IP SLAs before signing an SLA? Thanks and best regards On Thu, Feb 19, 2009 at 8:50 PM, Saqib Ilyas msa...@gmail.com wrote: Greetings I am curious to know about any tools/techniques that a service provider uses to assess an SLA before signing it. That is to say, how does an administrator know if he/she can meet what he is promising. Is it based on experience? Are there commonly used tools for this? Thanks and best regards -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences
RE: Looking for ATT / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome
My understanding is that ATT uses an MPLS/VRF CE router facing the user such that the resulting network connectivity is a private MPLS VPN. VZW apparently requires the user to implement a GRE/IPSec configuration just to reach their MPLS/VRF layer. The resulting user router config is thus much simpler with ATT. Haven't heard about Sprint though. -Original Message- From: Crooks, Sam [mailto:sam.cro...@experian.com] Sent: Tuesday, April 14, 2009 9:26 PM To: nanog@nanog.org Subject: Looking for ATT / Verizon / Sprint WWAN service impressions - on oroff-list replies welcome I'm considering use of ATT / Verizon / Sprint WWAN services and the Cisco 3G router interface cards/integrated module in C880 routers for primary or backup WAN network connectivity for routers. I'm looking for information from users of these services on the following: - addressing - Do these WWAN services use dynamic, PPPoE or static IP assignment typically? Any of the 3? All? - is static IP assignment available? - do these service providers use NAT within their network? - How is the service reliability? In most cases, is the service available for use when you need to use it? - How is the service coverage area? Do you have problems getting sufficient coverage in the deplouyment location to support desired speeds (say 512kbps up/down as a minimum)? - is ESP / IKE / IPsec permitted through un-rate-limited and un-molested by the providers? - If you build a IPsec/GRE tunnel over these services, do you have frequent issues with the tunnel dropping, or a dynamic routing protocol running through the tunnel going down frequently? Also interested in similar information on impressions of similar EMEA WWAN service providers, particularly Vodaphone and T-Mobile, if anyone has experiences with these. Replies on-list or off-list are welcome Your choice. Cisco 3G interface and provider information: http://www.cisco.com/en/US/products/ps7272/index.html http://www.cisco.com/en/US/prod/routers/networking_solutions_products_ge nericcontent0900aecd80601f7e.html#~north-america Regards, Sam Crooks
RE: Fiber cut in SF area
Wireless RF links have their drawbacks: 1. Current GHz Frequency technology places upper limit of 1 Gbps on point-to-point links, and distance at 1 Gbps is limited. Commercial GiGE radios are just now appearing, replacing 100 Mbps Ethernet and oc3 SONET radios. Telco use of wireless links to backup 10/40 GiGE fiber trunks in metropolitan areas is not scalable. 2. Wireless technology contains hardware plethora of nuts, bolts, cables, fasteners, custom-tuned crystals, dishes, passive/active reflectors, in addition to layer 1 tuning best performed by EE specializing in RF. 3. Relative to fiber optic technologies, there is a very small circle of RF companies that can install, tune, and maintain wireless links correctly and reliably. 4. Tower-climbing/working skills are essential. But, what is the state of diverse telco fiber paths such that this fiber cut was not transparent to users in such a key US metropolitan area? -Original Message- From: Gino Villarini [mailto:g...@aeronetpr.com] Sent: Tuesday, April 14, 2009 1:42 PM To: Deepak Jain; Jorge Amodio; nanog@nanog.org Subject: RE: Fiber cut in SF area Good points, some variables are dependant on the network infrastructure of the wireless provider. Localy, the main 2 providers have a copper/fiber independent networks. Gino A. Villarini g...@aeronetpr.com Aeronet Wireless Broadband Corp. tel 787.273.4143 fax 787.273.4145 -Original Message- From: Deepak Jain [mailto:dee...@ai.net] Sent: Tuesday, April 14, 2009 4:36 PM To: Gino Villarini; Jorge Amodio; nanog@nanog.org Subject: RE: Fiber cut in SF area I don't mean to jump in here and state the obvious, but wireless links are not a panacea. At least a few folks have presented that fiber grooming has affected their *region*. It's not difficult to imagine that wherever the head link side (or agg point) of these regional wireless networks is... probably coincides with a fiber network or other telecom POP. You are just moving where your last mile vulnerabilities are (slightly.. as you are picking up multiple power vulnerabilities, Line of Sight, and other things along the way). In the example of a tornado or other weather disturbance, wireless links are subject to fade just as much as any kind of aerial wired asset. Deepak Jain AiNET -Original Message- From: Gino Villarini [mailto:g...@aeronetpr.com] Sent: Tuesday, April 14, 2009 4:12 PM To: Jorge Amodio; nanog@nanog.org Subject: RE: Fiber cut in SF area Here in my area most of business outfits that require maximum availability of Internet or WAN conenctions have implemented dual connections from dual providers, most with a fiber/copper main and a fixed wireless backup. This trend goes from banks to Mcdonalds Gino A. Villarini g...@aeronetpr.com Aeronet Wireless Broadband Corp. tel 787.273.4143 fax 787.273.4145 -Original Message- From: Jorge Amodio [mailto:jmamo...@gmail.com] Sent: Tuesday, April 14, 2009 11:21 AM To: nanog@nanog.org Subject: Re: Fiber cut in SF area Earth is a single point of failure. On top of that, one basic principle of telecommunications: No matter how much diversity and path redundancy, tons of concrete or titanium sealed fiber vaults you have, in the data exchange between points A and B there will be always two single points of failure: A and B. IMHO, this thread is getting way off topic, boring and useless. Fiber cut is over, there will be many more, move on ... Cheers Jorge
RE: SLA packet loss base
Take a look at the BRIX active measurement instrumentation product which is now owned by EXFO. Many carriers use the BRIX probes to produce empirical data representing SLA values such as jitter, packet loss and round trip times for their network links. BRIX also has other more sophisticated application tests (VoIP codecs, etc.) which can be run from their distributed probes to any network end-point. -Original Message- From: 정치영 [mailto:lion...@samsung.com] Sent: Wednesday, April 08, 2009 5:14 PM To: nanog@nanog.org Subject: Fwd: SLA packet loss base 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 : 정치영lion...@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: lion...@samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 =
RE: Recommendation for wiring contractor in Scottsdale, AZ
In cases where lengthy in-house DS3 demarc extensions must be run, we have found it expedient to have the local telco provider (Qwest in Scottsdale?) extend the demarc. That way the telco is responsible for end-to-end CSU-to-CSU wiring diagnosis and repair. -Original Message- From: Jay Hennigan [mailto:j...@west.net] Sent: Wednesday, March 25, 2009 9:57 AM To: nanog@nanog.org Subject: Recommendation for wiring contractor in Scottsdale, AZ We have a need for a DS-3 extension (734 duplex co-ax, 300 foot run, BNC termination) in Scottsdale, AZ. A recommendation for a clueful wiring contractor familiar with this type of work would be greatly appreciated! -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
RE: SUP720 vs. SUP32
Important network design parameters to take into consideration when planning SUP720 vs SUP32: 1. SUP720 has 720 Gb backplane (switchfabric) on supervisor card, and 32 Gb shared bus backplane. 2. SUP32 only has 32 Gb shared bus backplane 3. New Cisco line cards with dual 20 Gb connections to 720 Gb backplane only work in the SUP720, and some only in IOS version (such as the 16 port 10 GiGE line cards) 4. Older line cards that work with SUP32 have relatively small shared hardware buffers for every 8 ports, such that it is possible to run line rate through one port and cause drops on the other 7 ports 5. Cisco recommends SUP32 for the wiring closet, as a desktop aggregation device -Original Message- From: Norrie, David [mailto:david.nor...@thus.net] Sent: Wednesday, March 18, 2009 9:48 AM To: Adrian Chadd; Bill Blackford Cc: nanog@nanog.org Subject: RE: SUP720 vs. SUP32 Hi, I have been searching cisco-nsp archive but not been able to find the article discussed below. I would appreciate it if someone does find the article if they can provide a copy/link to this : Check the cisco-nsp archive, specifically from Rodney; he has talked about what the CPU load versus throughput implications are on the G1 and G2. It might surprise you a little. Thanks, David
RE: SUP720 vs. SUP32
Make sure that the new 10 GiGE line cards are not in your plans if you choose the SUP32. This holds for some of the other copper and fiber line cards where line card buffer capacity may be critical to effective throughput. Some new line cards only connect to the 720 Gig backplane. -Original Message- From: Bill Blackford [mailto:bblackf...@nwresd.k12.or.us] Sent: Wednesday, March 11, 2009 11:18 AM To: nanog@nanog.org Subject: SUP720 vs. SUP32 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
RE: Redundant Array of Inexpensive ISP's?
The Talari device appears to operate like the old Routescience Pathcontrol BGP load balancer circa 2002 (Routescience is now owned by Avaya I believe). Routescience was able to compile the best path to Internet BGP prefixes so that a web site could connect to multiple 2nd tier ISPs (for circuit cost and redundancy reasons), and control the Mbps traffic over the best path, irrespective of the BGP feed supplied by the upstream ISP. In my experience devices such as Routescience automated the tedious work of using CAIDA tools to manually calculate the best BGP path to destination prefixes, and eliminated the almost daily reconfiguration of BGP route maps on Internet border routers. Routescience was a great product that put dashboard BGP routing control in the hands of the network engineer, and saved MRC circuit costs to pay for itself within a few months. -Original Message- From: Tim Utschig [mailto:t...@tetro.net] Sent: Tuesday, March 10, 2009 4:02 PM To: nanog@nanog.org Subject: Redundant Array of Inexpensive ISP's? [Please reply off-list. I'll summarize back to the list if there is more than a little interest in me doing so.] I'm curious if anyone has experience with products from Talari Networks, or anything similar, and would like to share. Did they live up to your expectations? Caveats? -- - Tim Utschig t...@tetro.net
RE: Network SLA
We use BRIX for SLA's by measuring round trip times, jitter, and packet loss across all of our backbone links. In conjunction with a traffic generator to add background traffic, and potentially invoke queueing on interfaces, we have found that BRIX enables us to accurately predict the behavior of new applications, particularly multicast and HD video, without the need to implement elaborate QoS configurations. BRIX is now owned by EXFO, a fiber optic test equipment manufacturer. Low values for rtt, jitter, and packet loss imply a relatively queue-free network, which makes confident predictions about network behavior easier. When we last looked at the technology, the Cisco IP SLA probes did not capture a random distribution of network events, as the probes are triggered every N minutes. BRIX randomizes the probes within a configurable window, so that, over time, all time intervals are covered by the accumulated probes. -Original Message- From: Saqib Ilyas [mailto:msa...@gmail.com] Sent: Saturday, March 07, 2009 3:12 AM To: nanog@nanog.org Subject: Re: Network SLA I must thank everyone who has answered my queries. Just a couple more short questions. For instance, if one is using MRTG, and wants to check if we can meet a 1 Mbps end-to-end throughput between a couple of customer sites, I believe you would need to use some traffic generator tools, because MRTG merely imports counters from routers and plots them. Is that correct? We've heard of the BRIX active measurement tool in replies to my earlier email. Also, I've found Cisco IP SLA that also sends traffic into the service provider network and measures performance. How many people really use IP SLA feature? Thanks and best regards On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi zart...@gmail.com wrote: As I gather, there is a mix of answers, ranging from building the resources according to requirements and HOPE for the best to use of arguably sophisticated tools and perhaps sharing the results with the legal department. I would be particularly interested in hearing the service providers' viewpoint on the following situation. Consider a service provider with MPLS deployed within its own network. (A) When the SP enters into a relation with the customer, does the SP establish new MPLS paths based on customer demands (this is perhaps similar to building based on requirements as pointed out by David)? If yes, between what sites/POPs? I assume the answer may be different depending upon a single-site customer or a customer with multiple sites. (B) For entering into the relationship for providing X units of bandwidth (to another site of same customer or to the Tier-1 backbone), does the SP use any wisdom (in addition to MRTG and the likes)? If so, what scientific parameters are kept in mind? (C) How does the customer figure out that a promise for X units of bandwidth is maintained by the SP? I believe customers may install some measuring tools but is that really the case in practice? Thanks, Zartash On Fri, Feb 20, 2009 at 1:16 AM, Stefan netfort...@gmail.com wrote: Saqib Ilyas wrote: Greetings I am curious to know about any tools/techniques that a service provider uses to assess an SLA before signing it. That is to say, how does an administrator know if he/she can meet what he is promising. Is it based on experience? Are there commonly used tools for this? Thanks and best regards Not necessarily as a direct answer (I am pretty sure there'll be others on this list giving details in the area of specific tools and standards), but I think this may be a question (especially considering your end result concern: *signing the SLA!) equally applicable to your legal department. In the environment we live, nowadays, the SLA could (should?!? ... unfortunately) be refined and (at the other end - i.e. receiving) interpreted by the lawyers, with possibly equal effects (mostly financial and as overall impact on the business) as the tools we (the technical people) would be using to measure latency, uptime, bandwidth, jitter, etc... Stefan -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences
RE: switch speed question
Arista claims to have the fastest 1/10 Gig 24 and 48 port 1RU switch, with a backplane capacity guaranteeing 10 Gig full duplex line rate per port. Cisco's CEF is local only and functions to download the arp cache and routing table into ASICs for hardware switching; but look at Cisco's NSF/SSO for cases where adjacent devices are all defined in the same packet forwarding state machine. -Original Message- From: Deric Kwok [mailto:deric.kwok2...@gmail.com] Sent: Monday, February 23, 2009 5:08 PM To: nanog@nanog.org Subject: switch speed question Hi Can you share your experience what is fastest Gig switch? I see there is CEF feature in cisco. ls it big different when i enable it in switch vs other switch? ls there any problem? Thank you
RE: Single fiber 10Gb/s X2 or Xenpak transceiver
Haven't seen one. With the huge heat sink and serialization circuitry on the X2, what advantage would a single strand connector bring? MRV may have one if anyone does, though. -Original Message- From: Andrey Slastenov [mailto:a.slaste...@gmail.com] Sent: Thursday, February 19, 2009 1:06 AM To: nanog@nanog.org Subject: Single fiber 10Gb/s X2 or Xenpak transceiver Hi Guys. Do you ever see single fiber 10Gb/s X2 or Xenpak transceiver? (I know about SFP, but never see X2 or Xenpak before)
RE: Network SLA
We use the BRIX active measurement instrumentation product to measure round-trip, jitter, and packet loss SLA conformity. -Original Message- From: Saqib Ilyas [mailto:msa...@gmail.com] Sent: Thursday, February 19, 2009 7:50 AM To: nanog@nanog.org Subject: Network SLA Greetings I am curious to know about any tools/techniques that a service provider uses to assess an SLA before signing it. That is to say, how does an administrator know if he/she can meet what he is promising. Is it based on experience? Are there commonly used tools for this? Thanks and best regards -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences
Dark Fiber in Parker Arizona
I am in need of dark fiber in the Parker, Arizona area. If anyone can help please contact me off list. Thanks, David
RE: 97.128.0.0/9 allocation to verizon wireless
We're not a big verizon wireless customer, (we have been allocated a /25
for remote data access devices). We run multi-homed BGP with vw. vw says
that they must advertise 48 summarized prefixes to us, instead of just
the /25. The 48 prefixes are apparently advertised to all of the
de-aggregated users contained in the summarized 48 prefixes. Is this a
common practice? If so is it a best practice?
-Original Message-
From: Mike Leber [mailto:mle...@he.net]
Sent: Sunday, February 08, 2009 10:39 PM
To: David Conrad
Cc: nanog@nanog.org
Subject: Re: 97.128.0.0/9 allocation to verizon wireless
David Conrad wrote:
On Feb 8, 2009, at 7:37 PM, Aaron Glenn wrote:
so if they don't deploy IPv6 then ('extremely high growth period'),
when will they?
Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled?
haha, I went insane for a moment and though you said Freenix top 1000,
and so I just checked that. Here is the answer to the question you
didn't ask:
Top 1000 Usenet Servers in the World
list here: http://news.anthologeek.net/top1000.current.txt
details here: http://news.anthologeek.net
1000 usenet server names
913 are potentially valid hostnames (in usenet news a server name does
necessarily correspond directly to a hostname)
722 have ipv4 address records (A)
67 have ipv6 address records ()
9.2% of the top 1000 usenet servers have added support for ipv6
I'm sure there are more this took exactly 183 seconds of work. ;)
Here they are:
feeder.erje.net 2001:470:992a::3e19:561
feeder4.cambrium.nl 2a02:58:3:119::4:1
news.dal.ca 2001:410:a010:1:214:5eff:fe0a:4a4e
news.nonexiste.net 2002:6009:93d5::1
nrc-news.nrc.ca 2001:410:9000:2::2
news.z74.net 2001:610:637:4::211
news.kjsl.com 2001:1868:204::104
npeer.de.kpn-eurorings.net 2001:680:0:26::2
feeder6.cambrium.nl 2a02:58:3:119::6:1
feeder3.cambrium.nl 2a02:58:3:119::3:1
news.belnet.be 2001:6a8:3c80::38
feeder2.cambrium.nl 2a02:58:3:119::2:1
feeder5.cambrium.nl 2a02:58:3:119::5:1
syros.belnet.be 2001:6a8:3c80::17
vlad-tepes.bofh.it 2001:1418:13:1::5
news.stack.nl 2001:610:1108:5011:230:48ff:fe12:2794
ikarus.belnet.be 2001:6a8:3c80::38
news.space.net 2001:608::1000:7
feed.news.tnib.de 2001:1b18:f:4::4
newsfeed.velia.net 2a01:7a0:3::254
news.isoc.lu 2001:a18:0:405:0:a0:456:1
ikaria.belnet.be 2001:6a8:3c80::39
newsfeed.teleport-iabg.de 2001:1b10:100::119:1
news.tnib.de 2001:1b18:f:4::2
kanaga.switch.ch 2001:620:0:8::119:2
erode.bofh.it 2001:1418:13:1::3
irazu.switch.ch 2001:620:0:8::119:3
bofh.it 2001:1418:13::42
newsfeed.atman.pl 2001:1a68:0:4::2
news.mb-net.net 2a01:198:292:0:210:dcff:fe67:6b03
news.gnuher.de 2a01:198:293::2
switch.ch 2001:620:0:1b::b
news.k-dsl.de 2a02:7a0:1::5
news.task.gda.pl 2001:4070:1::fafe
news1.tnib.de 2001:1b18:f:4::2
aspen.stu.neva.ru 2001:b08:2:100::96
novso.com 2001:1668:2102:4::4
citadel.nobulus.com 2001:6f8:892:6ff::11:133
feeder.news.heanet.ie 2001:770:18:2::c101:db29
news-zh.switch.ch 2001:620:0:3::119:1
news.szn.dk 2001:1448:89::10:d85d
news.litech.org 2001:440:fff9:100:202:b3ff:fea4:a44e
news.weisnix.org 2001:6f8:892:6ff:213:8fff:febb:bec3
news.panservice.it 2001:40d0:0:4000::e
nntp.eutelia.it 2001:750:2:3::20
bolzen.all.de 2001:bf0::60
newsfeed.esat.net 2001:7c8:3:1::3
news.snarked.org 2607:f350:1::1:4
feed1.news.be.easynet.net 2001:6f8:200:2::5:46
aotearoa.belnet.be 2001:6a8:3c80::58
news.babsi.de 2a01:198:292:0:230:48ff:fe51:a68c
news.muc.de 2001:608:1000::2
newsfeed.carnet.hr 2001:b68:e160::3
news.nask.pl 2001:a10:1:::3:c9a2
news.linuxfan.it 2001:4c90:2::6
texta.sil.at 2001:858:2:1::2
news.stupi.se 2001:440:1880:5::10
news.supermedia.pl 2001:4c30:0:3::12
news.trigofacile.com 2001:41d0:1:6d44::1
nuzba.szn.dk 2001:6f8:1232::263:8546
geiz-ist-geil.priv.at 2001:858:666:f001::57
newsfeed.sunet.se 2001:6b0:7:88::101
news.pimp.lart.info 2001:6f8:9ed::1
glou.fr.eu.org 2001:838:30b::1
news.germany.com 2001:4068:101:119:1::77
feeder.z74.net 2001:610:637:4::211
news.nask.org.pl 2001:a10:1:::3:c9a2
Mike.
--
+ H U R R I C A N E - E L E C T R I C +
| Mike LeberWholesale IPv4 and IPv6 Transit 510 580 4100 |
| Hurricane Electric AS6939 |
| mle...@he.net Internet Backbone Colocation http://he.net |
+-+
RE: -48VDC equipment recommendations
For large plants, the Sageon brand is excellent and for small scale, 48 VDC @ 30 amps the Argus brand is excellent. The Sageon units are stand-alone. The Argus units are rm @ 19 and 23. We use both. David -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Wednesday, January 28, 2009 2:27 PM To: dee...@ai.net; nanog list Subject: RE: -48VDC equipment recommendations We're using this a product by CD and happy with it: http://www.cdstandbypower.com/product/power_sys/system/sageon.html Runs very quietly, very efficient (compared to what we used to have) For our smaller sites, we use Valere: http://www.eltekvalere.com/wip4/telecom/c/detail.epl?cat=11071 It's amazing how compact they've made these units. Frank -Original Message- From: Deepak Jain [mailto:dee...@ai.net] Sent: Tuesday, January 27, 2009 5:35 PM To: nanog list Subject: -48VDC equipment recommendations Who does everyone like for -48VDC power systems nowadays (say in the 60A @48VDC and 6...@48vdc sizes). Something like you'd deploy in a POP or a 10-rack MMR with AB. Management/no-management, not a big deal. Off-list is fine, and I'll be glad to summarize for the list. Thanks in advance, Deepak
RE: Hirschmann Switches?
If an Industrial Ethernet switch is required it may be productive to look at Ruggedcom products. Ruggedcom has a published upper operating range of +85 C, which we have deployed in outside non-HVAC enclosures in environments where the outside ambient temperature can reach +49 to +55 C for extended periods. The L2 software is reliable, supporting rapid spanning tree, and IGMP snooping, among other features. Short and Long range SFP optics (up to 80 Km) are available that are also spec'd out at +85 C operating range. -Original Message- From: Paul Wall [mailto:pauldotw...@gmail.com] Sent: Monday, January 05, 2009 9:27 PM To: NANOG list Subject: Hirschmann Switches? I'm looking for feedback from users of the Hirschmann (Belden) ethernet switches in a service provider environment. Private or public appreciated. Drive Slow, Paul Wall
RE: Stress Testing LAN/WAN
I have used Solarwinds Wan Killer, but have yet to discover a method of initiating round-trip traffic from a single generator, but Solarwinds can stress a GiGE MAN link using a desktop PC with a GiGE card as the generator. -Original Message- From: Stephens, Josh [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 2:53 PM To: Nathan Ward; nanog list Subject: RE: Stress Testing LAN/WAN You can download a copy of the SolarWinds toolset from our website (the eval is free). There's a traffic generator in there called WAN Killer. Give it a try. Josh -Original Message- From: Nathan Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 4:27 PM To: nanog list Subject: Re: Stress Testing LAN/WAN On 5/12/2008, at 11:23 AM, Brian Feeny wrote: I have the need to stress test a LAN and WAN. The primary concern is the WAN which is at most OC-3. The LAN would be an additional bonus if I could do that as well. I am familiar with tools such as those from Spirent and IXIA which are very expensive. I was wondering if someone has had to do this and can recommend some open source tools that would work well. I need to test a few different types of traffic, specifically trying to push traffic into various switch/ router policies to make sure everything is performing as expected. If anyone knows of some software that works well for this I would appreciate letting me know. iPerf. -- Nathan Ward
Metro Ethernet Multicast Support
The Metro Ethernet Forum (MEF) MEF10-1 ELAN multipoint-to-multipoint specification says that multicast packets must be replicated out all ports in the ELAN, except the ingress port. Some carriers have taken this literally and built a virtual ELAN service emulating a 1990's style hub in which all multicast packets are replicated out all ports regardless of the L3 multicast routing protocol in use. In the case of PIM sparse mode real physical Ethernet switches use IGMP snooping to construct a directed path through the switch fabric, so that a given established multicast stream is forwarded just like a directed unicast connection with mac/port table entries establishing a single path through the L2 fabric, and no flooding is done. Some carriers flood directed multicast traffic out all ELAN ports even though a single path should be taken. In networks with a large number of directed multicast streams, flooding out all ports uses unnecessary bandwidth, sometimes rendering a 10 Mb port useless due to oversubscription caused by this unnecessary flooding. Can anyone suggest a carrier MEF ELAN multipoint-to-multipoint service that does not flood established directed PIM sparse mode streams?
RE: Network topology [Solved]
If the switches are Cisco, then Cisco Works has a L2 STP forwarding path graphical display which can be used in cases where the L3 path is a logical abstraction overlaid on the underlying L2 topology. -Original Message- From: Larry Sheldon [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2008 11:49 AM Cc: NANOG list Subject: Re: Network topology [Solved] Colin Alston wrote: Maybe there should be something (I mean like, someone should come up with a standard :P) to trace switches in a path... Problem is I think even then the simple devices won't bother to support it. I have been away from it for ma while and in truth don't know the answer--but-- To the best of my knowledge, Layer two Switches in fact operate as multi-port bridges. If that is true, then they ought to be transmitting BDUs which should be detectable and used for mapping. If the switches are all from the same manufacturer, there is a chance that the manufacture has a proprietary mapping tool. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actioInfallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs
