RE: Ahoy, SLA boffins!
Bill, To be brief, but hopefully not too fleeting, the majority of the standards orgs - ITU, MEF - use packet loss to derive availability. Loss% = the % of packets which were transmitted but not received by the destination host. As for availability, loss is measured across some time period. If during that period X% of the transmitted packets were NOT lost, then the network is said to be available. Typically a 20% figure is used, e.g. if 20% of the packets transmitted during a 5-minute period were received then the network is said to be 100% Available for that 5-minute time period. Some Carriers have taken this to the extreme to say that if at least 1 packet was successfully transmitted then the network was 100% Available for the time period. Loss is a measure of the networks usability, Availability is ...?? (Meaningless??) What utility does a network have that is Available yet sustaining a loss rate which renders it inoperable? Rich -Original Message- From: Bill Woodcock [mailto:wo...@pch.net] Sent: Wednesday, July 29, 2009 12:34 AM 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: Ahoy, SLA boffins!
I think the desired goal here is to separate the access SLA from the backbone SLA. That is, consider a simple picture: Network Cloud--Provider Edge Router-Local Loop-Customer Router Network availability is the % of the time the customer router and provider edge router can communicate, and is designed to measure if the local loop is up. For instance, let's say the provider edge router looses all its uplinks to the Network Cloud, your local loop is up and functioing but you have 100% packet loss to all destinations. The packet loss SLA kicks in on a per-destination basis. Everything is up and working, but the provider has a full circuit and is dropping 20% of the packets on that link. You catch it, you get a credit. I think the technical reason why these are separate has to do with the expectations. If my local loop is dropping 0.5% of the packets due to errors, it is broken and must be fixed. If some random destination on the Internet is dropping 0.5% of the packets well, that's a normal day in the life of the network. Plus, if your local loop takes errors then you get a credit. However, if there's a full link in the backbone but none of your packets take it, and thus you are unaffected, you don't. Now, having said all that, and having been one of the people who've attempted to communicate sane, rational, technical ideas to marketing and legal the chance that anything sane made it in the actual contract is, well, nil. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpmHITc36X9A.pgp Description: PGP signature
Cisco Security Advisory: Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities Advisory ID: cisco-sa-20090729-bgp http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml Revision: 1.0 = For Public Release 2009 July 29 1600 UTC (GMT) Summary === Recent versions of Cisco IOS Software support RFC4893 (BGP Support for Four-octet AS Number Space) and contain two remote denial of service (DoS) vulnerabilities when handling specific Border Gateway Protocol (BGP) updates. These vulnerabilities affect only devices running Cisco IOS Software with support for four-octet AS number space (here after referred to as 4-byte AS number) and BGP routing configured. The first vulnerability could cause an affected device to reload when processing a BGP update that contains autonomous system (AS) path segments made up of more than one thousand autonomous systems. The second vulnerability could cause an affected device to reload when the affected device processes a malformed BGP update that has been crafted to trigger the issue. Cisco has released free software updates to address these vulnerabilities. No workarounds are available for the first vulnerability. A workaround is available for the second vulnerability. This advisory is posted at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml Affected Products = Vulnerable Products +-- These vulnerabilities affect only devices running Cisco IOS and Cisco IOS XE Software (here after both referred to as simply Cisco IOS) with support for RFC4893 and that have been configured for BGP routing. The software table in the section Software Versions and Fixes of this advisory indicates all affected Cisco IOS Software versions that have support for RFC4893 and are affected by this vulnerability. A Cisco IOS software version that has support for RFC4893 will allow configuration of AS numbers using 4 Bytes. The following example identifies a Cisco device that has 4 byte AS number support: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#router bgp ? 1-65535Autonomous system number 1.0-XX.YY 4 Octets Autonomous system number Or: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#router bgp ? 1-4294967295 Autonomous system number 1.0-XX.YY Autonomous system number The following example identifies a Cisco device that has 2 byte AS number support: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#router bgp ? 1-65535 Autonomous system number A router that is running the BGP process will contain a line in the configuration that defines the autonomous system number (AS number), which can be seen by issuing the command line interface (CLI) command show running-config. The canonical textual representation of four byte AS Numbers is standardized by the IETF through RFC5396 (Textual Representation of Autonomous System (AS) Numbers). Two major ways for textual representation have been defined as ASDOT and ASPLAIN. Cisco IOS routers support both textual representations of AS numbers. For further information about textual representation of four byte AS numbers in Cisco IOS Software consult the document Explaining 4-Byte Autonomous System (AS) ASPLAIN and ASDOT Notation for Cisco IOS at the following link: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/white_paper_c11_516829.html Cisco IOS Software with support for RFC4893 is affected by both vulnerabilities if BGP routing is configured using either ASPLAIN or ASDOT notation. The following example identifies a Cisco device that is configured for BGP using ASPLAIN notation: router bgp 65536 The following example identifies a Cisco device that is configured for BGP using ASDOT notation: router bgp 1.0 To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to Cisco Internetwork Operating System Software or Cisco IOS Software. The image name displays in parentheses, followed by Version and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2
Re: Ahoy, SLA boffins!
Now, having said all that, and having been one of the people who've attempted to communicate sane, rational, technical ideas to marketing and legal the chance that anything sane made it in the actual contract is, well, nil. I disagree. If someone takes the trouble to publish a technical document describing a sane technical way to measure a network SLA, and they also provide code for measuring/calculating the SLA, then there is a good chance that the industry will pick it up. Look at 95th percentile billing. Dave Rand at Abovenet thought it up, probably to simplify the billing process and keep billing overhead costs down. Then UUNet picked it up and suddenly just about everyone was offering a 95th percentile billing model. -- Michael Dillon
RE: OT: Voice Operators' Group forming
Hi All, We're making progress... I registered the domains voiceops.org and voiceops.net. No matter what the final name becomes, at least we've got some domains that aren't too hard on the eyes. Some noble souls have already volunteered to host it on a proper mailman server. Nothing is set up yet, but it's coming together. Thanks, David Hiers -Original Message- From: Charles Wyble [mailto:char...@thewybles.com] Sent: Tuesday, July 28, 2009 3:17 PM To: nanog@nanog.org Subject: Re: OT: Voice Operators' Group forming jamie wrote: puck.nether.net http://puck.nether.net. Right. That's what I meant. way to volunteer someone else's box :-) Good point. My apologies. Google groups then. :) This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
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: Ahoy, SLA boffins!
On Wed, Jul 29, 2009 at 12:34 AM, Bill Woodcockwo...@pch.net wrote: Am I over-thinking this? The SLA's I've looked at promise me that if their service is hard down for a week (with no ambiguity whatsoever) they'll credit my bill for upwards of 2% of the $50k/year or so I spend on the Internet connection for my mutli-million dollar online service. So yeah, you're overthinking it. When they start coupling those SLAs with some sort of serious business loss insurance, then paying attention to the SLA and carefully examining what constitutes failure may make some kind sense at a technical level. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Ahoy, SLA boffins!
William Herrin wrote: On Wed, Jul 29, 2009 at 12:34 AM, Bill Woodcockwo...@pch.net wrote: Am I over-thinking this? The SLA's I've looked at promise me that if their service is hard down for a week (with no ambiguity whatsoever) they'll credit my bill for upwards of 2% of the $50k/year or so I spend on the Internet connection for my mutli-million dollar online service. I'm really surprised anyone considers this an SLA, or anything special in a business contract. I automatically expect to get a credit of 1.923% if the service were not provided for a period of 168 hours, no questions asked and no SLA required. When service is simply not provided, there's nothing special about not having to pay for it. I don't know of any business where you can have a contract that requires you to pay your monthly/annual fee for services when said services are not provided. If you have a housekeeping or lawn service that is supposed to come once a week, and you have an annual contract with them for this service at $50/week, and they miss a week (provide no service) you don't pay them anyway for that missed week. You don't need an SLA in your contract with them to have this right to withhold payment for the period of time when the services are not provided *at all*. An SLA comes into play when a service is degraded below the quality you contracted for. What credit do they give you when you have 168 hours of degraded service, e.g. 50% of the service level you specified in your RFQ? That's where your SLA comes in. The SLA specifies at what point your service is considered degraded (how much below the contracted service level, and how long of a time period is required before it is considered below grade) and what $credit you may receive when you are provided some service, but not to the level specified in your contract. jc
Re: Ahoy, SLA boffins!
On Wed, Jul 29, 2009 at 4:19 PM, JC Dilljcdill.li...@gmail.com wrote: William Herrin wrote: The SLA's I've looked at promise me that if their service is hard down for a week (with no ambiguity whatsoever) they'll credit my bill for upwards of 2% of the $50k/year or so I spend on the Internet connection for my mutli-million dollar online service. An SLA comes into play when a service is degraded below the quality you contracted for. What credit do they give you when you have 168 hours of degraded service, e.g. 50% of the service level you specified in your RFQ? That's where your SLA comes in. The SLA specifies at what point your service is considered degraded (how much below the contracted service level, and how long of a time period is required before it is considered below grade) and what $credit you may receive when you are provided some service, but not to the level specified in your contract. Hi JC, Perhaps you miss my point: what the ISP is offering to pay me as a result of a failure to deliver adequate service is so much less than my loss for the same as to render the payment meaningless. I'm gonna terminate the contract for nonperformance and hire someone who can get the job done long before its worth my time to chase you for an SLA-based service credit. And we both know it. The only way I ever chase you for an SLA credit is I'm playing the blame game instead of doing my job for my customers. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: OT: Voice Operators' Group forming
Brandon Butterworth wrote: NAVOG works for me. I'd prefer Voice Operators' Group Online Network brandon *claps*
Re: OT: Voice Operators' Group forming
On 29.07.2009, at 22:52, Jason LeBlanc wrote: Brandon Butterworth wrote: NAVOG works for me. I'd prefer Voice Operators' Group Online Network brandon *claps* Imagine the poetry you have to listen to when _those_ guys put you on hold...
Re: Subnet Size for BGP peers.
On 30/07/2009, at 7:59 AM, Jim Wininger wrote: I have a question about the subnet size for BGP peers. Typically when we turn up a new BGP customer we turn them up on a /29 or a /30. That seems to be the norm. We connect to many of our BGP peers with ethernet. It would be a simple matter to allocate a /24 for connectivity to the customer on a shared link. This would help save on some address space. My question is, is this in general good or bad idea? Have others been down this path and found that it was a bad idea? I can see some of the pothols on this path (BGP session hijacking, incorrectly configured customer routers etc). These issues could be at least partially mitigated. Are there larger issues when doing something like this or is it a practical idea? What is your access network? Do you have a switch port per customer? If so, look in to private VLANs on Cisco, or whatever similar feature exists for your vendor. -- Nathan Ward
RE: Subnet Size for BGP peers.
/29's here for everyone great for troubleshooting and any future additions typically required...;) -Original Message- From: Jim Wininger [mailto:jbot...@gmail.com] Sent: July 29, 2009 4:00 PM To: nanog@nanog.org Subject: Subnet Size for BGP peers. I have a question about the subnet size for BGP peers. Typically when we turn up a new BGP customer we turn them up on a /29 or a /30. That seems to be the norm. We connect to many of our BGP peers with ethernet. It would be a simple matter to allocate a /24 for connectivity to the customer on a shared link. This would help save on some address space. My question is, is this in general good or bad idea? Have others been down this path and found that it was a bad idea? I can see some of the pothols on this path (BGP session hijacking, incorrectly configured customer routers etc). These issues could be at least partially mitigated. Are there larger issues when doing something like this or is it a practical idea? -- Jim Wininger -- Jim Wininger jbot...@gmail.com The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: Subnet Size for BGP peers.
Imagine two of your clients are competitors, they probably don't want to be on the same IP range. And yes, when you sell your service to several customers, you don't want one of them blowing up all the other's SLA. IXs use /24, as far as I know, and peers connected there can usually use md5 password if they want to. But in that case, some troubles like arp broadcast storm could happen, coming from any of the connected network. I guess it's not the same level of service, but I agree, many /30 or /29 are a big loss of addresses. It reminds me GLBP with two gateways: on 10.0.0.0/29, you got 10.0.0.0 : network 10.0.0.7 : broadcast 10.0.0.1 : gw1 10.0.0.2 : gw2 10.0.0.6 : virtual gw only 3, 4 and 5 for other equipments. Who knows any other good way to lose IP addresses? Jim Wininger a écrit : I have a question about the subnet size for BGP peers. Typically when we turn up a new BGP customer we turn them up on a /29 or a /30. That seems to be the norm. We connect to many of our BGP peers with ethernet. It would be a simple matter to allocate a /24 for connectivity to the customer on a shared link. This would help save on some address space. My question is, is this in general good or bad idea? Have others been down this path and found that it was a bad idea? I can see some of the pothols on this path (BGP session hijacking, incorrectly configured customer routers etc). These issues could be at least partially mitigated. Are there larger issues when doing something like this or is it a practical idea?
Re: Dan Kaminsky
--- On Wed, 7/29/09, Scott Weeks sur...@mauigateway.com wrote: From: Scott Weeks sur...@mauigateway.com Subject: Re: Fwd: Dan Kaminsky To: andrew.wallace andrew.wall...@rocketmail.com Date: Wednesday, July 29, 2009, 10:10 PM --- andrew.wall...@rocketmail.com wrote: http://www.leetupload.com/zf05.txt -- This one is off line: Site Temporarily Unavailable We apologize for the inconvenience. Please contact the webmaster/ tech support immediately to have them rectify this. error id: bad_httpd_conf scott Dan Kaminsky mirrors: http://r00tsecurity.org/files/zf05.txt http://antilimit.net/zf05.txt Much thanks, Andrew
Re: Fwd: Dan Kaminsky
LAS VEGAS — Two noted security professionals were targeted this week by hackers who broke into their web pages, stole personal data and posted it online on the eve of the Black Hat security conference. boring. randy
Re: Fwd: Dan Kaminsky
Randy Bush wrote: LAS VEGAS — Two noted security professionals were targeted this week by hackers who broke into their web pages, stole personal data and posted it online on the eve of the Black Hat security conference. boring. randy Two noted security professionals, and Kevin Mitnick, whom no one gives a damn about, were targeted... FTFY Andrew D Kirch
Re: Fwd: Dan Kaminsky
LAS VEGAS — Two noted security professionals were targeted this week by hackers who broke into their web pages, stole personal data and posted it online on the eve of the Black Hat security conference. boring. Two noted security professionals, and Kevin Mitnick, whom no one gives a damn about, were targeted... Ettore Bugatti, maker of the finest cars of his day, was once asked why his cars had less than perfect brakes. He replied something like, Any fool can make a car stop. It takes a genius to make a car go. so i am not particularly impressed by news of children making a car stop. randy
Re: Subnet Size for BGP peers.
- Original Message - From: Jim Wininger jbot...@gmail.com To: nanog@nanog.org Sent: Wednesday, July 29, 2009 3:59 PM Subject: Subnet Size for BGP peers. I have a question about the subnet size for BGP peers. Typically when we turn up a new BGP customer we turn them up on a /29 or a /30. That seems to be the norm. We connect to many of our BGP peers with ethernet. It would be a simple So what is wrong with a /31? We use /30s but if you are short on IP space, look at using /31 rather than /30 links. Cuts your space usage in half. If I remember correctly, the BIG problem with using /31s when they first became legal was to decide if the customer still gets the higher numbered IP address (or you the lower one), or if you still get the ODD number. No kidding, it is a problem for some! Where you are on ethernet, use a seperate 802.1q vlan per customer and have your switch give the customer untagged packets. If you have downstreams in your COLO, and either free or as a paid service, offer to setup private vlans in your switch for any pair or group of customers that need to also connect to each other privately for whatever they are doing. In that latter case, they will be getting tagged packets but their routers or switches should have no problem dealing with them. We don't charge for physical crossconnects, so this has saved us having to do physical crossconnects between customers, and has saved customers router ports.
Re: Subnet Size for BGP peers.
On Thu, 30 Jul 2009, Benjamin Billon wrote: Who knows any other good way to lose IP addresses? I know how to not lose them: int lo30 ip address 192.168.0.1 255.255.255.0 int gi2.10 encap dot1q 10 desc cust 1 ip address unnumbered lo30 int gi2.11 encap dot1q 11 desc cust 2 ip address unnumbered lo30 ip route 192.168.0.2 255.255.255.255 gi2.10 ip route 192.168.0.3 255.255.255.255 gi2.11 etc. Now you can have one customer per vlan but still have them share the same IP subnet. This works with vlan interfaces as well. I don't remember if you have to do local-proxy-arp or not, but if you're running bgp you could always do next-hop-self to be sure it hops via the gateway. -- Mikael Abrahamssonemail: swm...@swm.pp.se
