APRICOT 2013 in Singapore
Hi everyone, Just to let you know that the call for papers for APRICOT 2013 (in Singapore next February) opened a few days ago. Rather than posting the whole cfp here, you can see it via the programme page on the APRICOT website - www.apricot2013.net/program. NANOG and APRICOT are the network operations conferences for adjacent regions - and indeed both regions have considerable overlap and interests in common. Please give some thought to presenting something topical at APRICOT - the Programme Committee would love to hear from you. You can submit your proposal via http://papers.apricot.net. Thanks! philip (on behalf of the APRICOT PC) --
RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
Hi, I thought I would share an extract from an email I sent off list to a peer. My mail was a rather ramberly stream of consciousness exploring the issue, which worked its way to a potential solution... Hence why I am sharing an extract from it. I am not sure how practicably implementable it would be with the use of communities and some extra filtering logic implemented by the router software to enable prefix matching on less specific. I include for open discussion, I am sure there are things wrong with this idea, but maybe we can move towards a solution that works for everyone, rather than continuing in a straight line and having a bloated v6 route soup of indistinguishable /48s all over the place. Maybe the below has some legs, I leave it for those clever than me to see if this can be incorporated into an emergent BCP that might address what we should be doing and give everyone clear guidelines and keep everything on track. snip As I said its not the content networks I have issue with, it the rest of the access networks and hosting networks that are going to abuse a relaxation policy of you should only announce /32 and use communities and no export for TE to adjacent ASes, but because there are a lot of island networks that require /48 support yours will also get accepted but please don't do this for TE reasons. What we need is a way to filter that says throw this prefix away if I can see it inside of another prefix. Ie discard this /48 if it is part of a /32 (or bigger) that I also have in my RIB and then insert the /32 into FIB and discard the /48. That would dump off all the TE nonsense, while keeping the island networks /48s. This new functionality could be used in a route map so it could be augmented with community matching or AS filter lists. That would solve the problem, all be it at the cost of the processing overhead to examine each /48 in the table and recurse its route, versus simple application of a filter list based on net block and minimum allocation size. I guess another thing that might work is if we all start passing communities and then we can tag some /48s as I am a TE prefix with a cover route and use a different community to tag I am an island prefix with no cover route, and then we can filter or permit those in a route map as the recipient sees fit and next the route map could filter everything left on RIR minimums for the block. That might work a lot better, if everyone passed communities At least people would be incentivised to tag the island routes which would be guaranteed to be permitted, we might have to worry about some people tagging a TE route as an island route. So I guess the logic becomes /48 Routes tagged with an island community permit as long as there is not a less specific covering route in the RIB. /48 Routes tagged with a TE community can be permitted or denied as chosen by the recipient end AS but should be carried in the DFZ by transit providers. /48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid. Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 maximum announced prefix size - rather than carried in the same block as PA (Aggregated) / ISP blocks that have a /32 minimum. If we do that, it keeps the existing problem the size it is currently and solves it for future assignments, allows the island networks to work, prevents people cheating by trying to sneak a TE route in as an island route when there is covering /32 route, dumps off the rubbish from spurious announcements and hijacking, while allowing PI end user /48s to continue to work... I think that would address the problem. /snip Thoughts...? Ben -Original Message- From: Ben S. Butler Sent: 15 November 2012 00:05 To: 'Michael Smith'; William Herrin Cc: nanog@nanog.org Subject: RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. Hi, Again, I thought the discussion was about PI, not PA. I don't announce any PA. My point, which I feel may be getting lost, and for which ARIN may already have policies in place for, is that an IP assignment is made out of a block with a defined minimum assignment size. Now some people simply advertise the assignment that is made to them, some people chose to advertise more specifics with a covering route, I have no problem with any of this. What I am saying, is if people chose to deagregate to create islands, for which I can completely understand the commercial and networking reason and why it is then by extension impossible for them to advertise the covering route. Then in these specific cases of islands then these assignments should be made by the RIR from a block with a minimum prefix size of a /48. Then the
Dns sometimes fails using Google DNS / automatic dnssec
Hi, We've been seeing automatic RRSIG records on Google DNS lately, the 8.8.8.8 en 8.8.4.4. They are not always provided. They cause problems for some of our customers in a weird way I cannot explain. For them these records do not resolve but I cannot reproduce it. So when I run dig command dig @8.8.8.8 m1.mailplus.nl it often provides the RRSIG record (but e.g. the TXT record will not be signed). I've heard that DNS may fall back to TCP and/or may be filtered by firewalls if UDP is over 512 bytes. However, the request is not that long, about 200 bytes if I interpret the answer correctly. Can someone come up with a good explanation why a tiny percentage of our customers cannot resolve (some of) our domains? Btw, our nameservers (transip.nl) only provide DNSSEC records if explicitly asked. What is standard here? Thanks, David Hofstee
RE: Eaton 9130 UPS feedback
Note the EATON Press release. Maybe the burn on the bench is the way they get to the California energy reduction Standards? If it isn't working it isn't using power. Date: 23 October 2012 Latest Eaton Thought Leadership White Paper Provides Technical Analysis of Eaton's Energy Saver System Eaton today announced the release of its latest white paper, Understanding Eaton Energy Saver System. In the paper, George Navarro, an Eaton technical solutions engineering specialist, explains how Eaton's Energy Saver System (ESS) enables large uninterruptible power systems (UPSs) to operate at up to 99 percent efficiency without sacrificing reliability. Though ESS is rapidly gaining support in the UPS industry for its ability to build on the strengths of traditional double-conversion architectures, many consultants and end users have questions about how ESS works and what enables it to lower power consumption while maintaining high levels of availability. In the paper, Navarro answers these questions by providing in-depth technical information about ESS's architecture, reliability characteristics, computational infrastructure and surge suppression attributes. Ralph Brandt -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Tuesday, November 13, 2012 2:59 PM To: nanog@nanog.org Subject: Eaton 9130 UPS feedback Does anyone use Eaton 9130 series UPS for anything? I'm curious how they've worked out for you. I bought a 700VA model to give it a whirl versus the traditional APC since the Eaton is an online type with static bypass and also does some high efficiency thing where it normally stays on bypass, but the first thing it did on the bench was have the inverter/rectifier or bypass section catch on fire and destroy itself. ~Seth
Re: Dns sometimes fails using Google DNS / automatic dnssec
Hi, David I work at Google Public DNS and will take a look at this issue. No RRSIG should be returned unless the client set the DO bit to ask for it. Thanks Yunhong On Thu, Nov 15, 2012 at 9:12 AM, MailPlus| David Hofstee da...@mailplus.nl wrote: Hi, We've been seeing automatic RRSIG records on Google DNS lately, the 8.8.8.8 en 8.8.4.4. They are not always provided. They cause problems for some of our customers in a weird way I cannot explain. For them these records do not resolve but I cannot reproduce it. So when I run dig command dig @8.8.8.8 m1.mailplus.nl it often provides the RRSIG record (but e.g. the TXT record will not be signed). I've heard that DNS may fall back to TCP and/or may be filtered by firewalls if UDP is over 512 bytes. However, the request is not that long, about 200 bytes if I interpret the answer correctly. Can someone come up with a good explanation why a tiny percentage of our customers cannot resolve (some of) our domains? Btw, our nameservers (transip.nl) only provide DNSSEC records if explicitly asked. What is standard here? Thanks, David Hofstee
RE: Eaton 9130 UPS feedback
Yeah, that's about right. When I had one fail that was not set in power saver mode, it just shut off intermittently before letting out the genie. When I had one go out while it was in energy saver mode, it continued to operate but put out a weak ~80Vrms with heavy distortion that caused equipment damage. Foul. Also in regards to OutBack - the Radian GS8048 is beautiful. I'd highly recommend it. It is basically two inverter/charger modules paralleled in one chassis, each being 4Kw. I was playing with one and yoinked the control cable to one module -- the power stayed on without incident and the MATE3 control unit (which is fun and Ethernet equipped) reported the error. If you use the 8048 in half capacity it's redundant. It gives 120/240 (l1, neutral, l2) out of the box and is pure sine. I recommend getting the matching GS load center with it because it makes the install super easy and includes the requisite breakers. Tom Morris, KG4CYX Chairman, South Florida Tropical Hamboree Mad Scientist, Miami Children's Museum This message sent from a mobile device. Silly typos provided free of charge. On Nov 15, 2012 9:29 AM, Brandt, Ralph ralph.bra...@pateam.com wrote: Note the EATON Press release. Maybe the burn on the bench is the way they get to the California energy reduction Standards? If it isn't working it isn't using power. Date: 23 October 2012 Latest Eaton Thought Leadership White Paper Provides Technical Analysis of Eaton's Energy Saver System Eaton today announced the release of its latest white paper, Understanding Eaton Energy Saver System. In the paper, George Navarro, an Eaton technical solutions engineering specialist, explains how Eaton's Energy Saver System (ESS) enables large uninterruptible power systems (UPSs) to operate at up to 99 percent efficiency without sacrificing reliability. Though ESS is rapidly gaining support in the UPS industry for its ability to build on the strengths of traditional double-conversion architectures, many consultants and end users have questions about how ESS works and what enables it to lower power consumption while maintaining high levels of availability. In the paper, Navarro answers these questions by providing in-depth technical information about ESS's architecture, reliability characteristics, computational infrastructure and surge suppression attributes. Ralph Brandt -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Tuesday, November 13, 2012 2:59 PM To: nanog@nanog.org Subject: Eaton 9130 UPS feedback Does anyone use Eaton 9130 series UPS for anything? I'm curious how they've worked out for you. I bought a 700VA model to give it a whirl versus the traditional APC since the Eaton is an online type with static bypass and also does some high efficiency thing where it normally stays on bypass, but the first thing it did on the bench was have the inverter/rectifier or bypass section catch on fire and destroy itself. ~Seth
Re: Brasil/Mexico/Argentina connectivity
On Wednesday, November 14th, 2012, Olivier CALVANO wrote: I am search one or more carrier for connect 3 sites in Brasil, Mexico and Argentina to one of our pop in USA or Spain. I don't deal with it directly, but my employer has used MPLS offerings from (in alphabetical order) BT, Level 3/Global Crossing, and Verizon in a number of countries. I suspect any of the three have access in all of the countries listed. I imagine there are others, but those are the ones that sprung to mind. Jima
RE: Dns sometimes fails using Google DNS / automatic dnssec
root@e3:/home/services# dig @8.8.8.8 m1.mailplus.nl ; DiG 9.7.3 @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38880 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl.IN A ;; ANSWER SECTION: m1.mailplus.nl. 1867IN A 46.31.50.16 m1.mailplus.nl. 1867IN RRSIG A 7 3 3600 20130517082302 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1pQRo8YIcxzlSN tHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0bMKYKIDuK8Gtz47AVDJaU0eX 0FR8F5qqw897ClGf5ISa0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWF ujs= ;; Query time: 5 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 16:05:26 2012 ;; MSG SIZE rcvd: 219 --- David Hofstee -Oorspronkelijk bericht- Van: Yunhong Gu [mailto:g...@google.com] Verzonden: donderdag 15 november 2012 15:47 Aan: MailPlus| David Hofstee CC: nanog@nanog.org Onderwerp: Re: Dns sometimes fails using Google DNS / automatic dnssec Hi, David I work at Google Public DNS and will take a look at this issue. No RRSIG should be returned unless the client set the DO bit to ask for it. Thanks Yunhong On Thu, Nov 15, 2012 at 9:12 AM, MailPlus| David Hofstee da...@mailplus.nl wrote: Hi, We've been seeing automatic RRSIG records on Google DNS lately, the 8.8.8.8 en 8.8.4.4. They are not always provided. They cause problems for some of our customers in a weird way I cannot explain. For them these records do not resolve but I cannot reproduce it. So when I run dig command dig @8.8.8.8 m1.mailplus.nl it often provides the RRSIG record (but e.g. the TXT record will not be signed). I've heard that DNS may fall back to TCP and/or may be filtered by firewalls if UDP is over 512 bytes. However, the request is not that long, about 200 bytes if I interpret the answer correctly. Can someone come up with a good explanation why a tiny percentage of our customers cannot resolve (some of) our domains? Btw, our nameservers (transip.nl) only provide DNSSEC records if explicitly asked. What is standard here? Thanks, David Hofstee
RE: Dns sometimes fails using Google DNS / automatic dnssec
It looks like if the server has the RRSIG RR, it returns it. For example, a query with +dnssec will cause it to cache the RRSIG, after which it returns it even if +dnssec not specified. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 query without +dnssec before RRSIG is cached; RRSIG not returned : dig @8.8.8.8 m1.mailplus.nl ; DiG 9.8.1-P1 @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 3665 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl.IN A ;; ANSWER SECTION: m1.mailplus.nl. 2985IN A 46.31.50.16 ;; Query time: 15 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:02 2012 ;; MSG SIZE rcvd: 48 query with +dnssec; RRSIG is returned : dig +dnssec +multi @8.8.8.8 m1.mailplus.nl ; DiG 9.8.1-P1 +dnssec +multi @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 58877 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;m1.mailplus.nl.IN A ;; ANSWER SECTION: m1.mailplus.nl. 2978 IN A 46.31.50.16 m1.mailplus.nl. 2978 IN RRSIG A 7 3 3600 20130517082302 ( 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1p QRo8YIcxzlSNtHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0 bMKYKIDuK8Gtz47AVDJaU0eX0FR8F5qqw897ClGf5ISa 0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWFujs= ) ;; Query time: 16 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:10 2012 ;; MSG SIZE rcvd: 230 query without +dnssec after RRSIG is cached; RRSIG returned : dig +multi @8.8.8.8 m1.mailplus.nl ; DiG 9.8.1-P1 +multi @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 13524 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl.IN A ;; ANSWER SECTION: m1.mailplus.nl. 2974 IN A 46.31.50.16 m1.mailplus.nl. 2974 IN RRSIG A 7 3 3600 20130517082302 ( 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1p QRo8YIcxzlSNtHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0 bMKYKIDuK8Gtz47AVDJaU0eX0FR8F5qqw897ClGf5ISa 0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWFujs= ) ;; Query time: 17 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:13 2012 ;; MSG SIZE rcvd: 219
Re: Dns sometimes fails using Google DNS / automatic dnssec
Hi, we have found the bug that caused this problem. It was introduced in a very recent release. The fix is on its way. Thanks very much for the report, Yunhong On Thu, Nov 15, 2012 at 12:26 PM, Jay Ford jay-f...@uiowa.edu wrote: It looks like if the server has the RRSIG RR, it returns it. For example, a query with +dnssec will cause it to cache the RRSIG, after which it returns it even if +dnssec not specified. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 query without +dnssec before RRSIG is cached; RRSIG not returned : dig @8.8.8.8 m1.mailplus.nl ; DiG 9.8.1-P1 @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 3665 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl.IN A ;; ANSWER SECTION: m1.mailplus.nl. 2985IN A 46.31.50.16 ;; Query time: 15 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:02 2012 ;; MSG SIZE rcvd: 48 query with +dnssec; RRSIG is returned : dig +dnssec +multi @8.8.8.8 m1.mailplus.nl ; DiG 9.8.1-P1 +dnssec +multi @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 58877 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;m1.mailplus.nl.IN A ;; ANSWER SECTION: m1.mailplus.nl. 2978 IN A 46.31.50.16 m1.mailplus.nl. 2978 IN RRSIG A 7 3 3600 20130517082302 ( 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1p QRo8YIcxzlSNtHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0 bMKYKIDuK8Gtz47AVDJaU0eX0FR8F5qqw897ClGf5ISa 0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWFujs= ) ;; Query time: 16 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:10 2012 ;; MSG SIZE rcvd: 230 query without +dnssec after RRSIG is cached; RRSIG returned : dig +multi @8.8.8.8 m1.mailplus.nl ; DiG 9.8.1-P1 +multi @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 13524 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl.IN A ;; ANSWER SECTION: m1.mailplus.nl. 2974 IN A 46.31.50.16 m1.mailplus.nl. 2974 IN RRSIG A 7 3 3600 20130517082302 ( 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1p QRo8YIcxzlSNtHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0 bMKYKIDuK8Gtz47AVDJaU0eX0FR8F5qqw897ClGf5ISa 0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWFujs= ) ;; Query time: 17 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 11:22:13 2012 ;; MSG SIZE rcvd: 219
Re: Brasil/Mexico/Argentina connectivity
Hi Jima, I can help you contacting BT if you need so. Alejandro, --Mensaje original-- De: Jima Para: nanog@nanog.org Asunto: Re: Brasil/Mexico/Argentina connectivity Enviado: 15 nov, 2012 11:35 On Wednesday, November 14th, 2012, Olivier CALVANO wrote: I am search one or more carrier for connect 3 sites in Brasil, Mexico and Argentina to one of our pop in USA or Spain. I don't deal with it directly, but my employer has used MPLS offerings from (in alphabetical order) BT, Level 3/Global Crossing, and Verizon in a number of countries. I suspect any of the three have access in all of the countries listed. I imagine there are others, but those are the ones that sprung to mind. Jima Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet
RE: Dns sometimes fails using Google DNS / automatic dnssec
Jay Ford jay-f...@uiowa.edu wrote: It looks like if the server has the RRSIG RR, it returns it. For example, a query with +dnssec will cause it to cache the RRSIG, after which it returns it even if +dnssec not specified. It's weird. If you repeatedly query 8.8.4.4 without the DO bit, you get a mixture of responses with and without an RRSIG and with varying TTLs. With DO it appears to consistently return an RRSIG in the answer and the TTL drops monotonically. 8.8.8.8 is similar except DO=0 replies don't include RRSIGs. (Querying from JANET UK and hitting some servers a lethargic 12ms away.) while sleep 1; do dig +dnssec @8.8.4.4 m1.mailplus.nl; done Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
RE: authority to route?
..for some blocks I've taken over admin for. Make sure you are visibly listed as a Point of Contact on those records in the appropriate RIR, so that folks who get your request can verify you. Even better, register in your RIR's RPKI program and generate a ROA for it. Info about ARIN's here: https://www.arin.net/resources/rpki/index.html Then yes, notify their upstreams/peers if needed and post here if things get really desperate - have your records in order first. --Heather -Original Message- From: Jim Mercer [mailto:j...@reptiles.org] Sent: Monday, November 12, 2012 2:44 PM To: nanog@nanog.org Subject: authority to route? Hi, Is there a common practice of providers to vet / validate requests to advertise blocks? Who is the authority when it comes to determining if a request for routing is valid? Is it the WHOIS data maintained by the various RIR? It seems I'm playing whack-a-mole to get some routes shut down for some blocks I've taken over admin for. If I email the contacts for the AS in WHOIS, and get no response, or a negative response, should I start going to their peers? Some practical advice would be appreciated. -- Jim Mercer Reptilian Research j...@reptiles.org+1 416 410-5633 He who dies with the most toys is nonetheless dead
MPLS acceptable latency?
Hello! I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Thanks,
Re: MPLS acceptable latency?
On 11/15/12 12:54 -0600, Mikeal Clark wrote: Hello! I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? I recently had a scenario with some MPLS sites within the state nearly doubling in latency (below 50ms round trip). Typically I see round trip latency in the 20-35ms range, and those sites are within about a 90 minute drive from each other (Oklahoma, mostly T1s). When I asked an ATT tech to investigate, he did not see log entries to explain the increase or admit to any trouble, and stated that the service levels for these MPLS circuits allowed for 75-80ms and I don't recall if that was one way or round trip. He said that was to allow for coast to coast latency scenarios. Delay returned to typical levels about 4 days later, without explanation. -- Dan White
Re: MPLS acceptable latency?
Acceptable from a technical standpoint (in that stuff works) or acceptable from an expected service standpoint? In the case of the former, MPLS can run over really high latencies, so you're nowhere near the limit. For the latter, 85ms would be highly unacceptable to me for a circuit to a site that's so close. I would think your traffic is either being routed really, really badly or their circuits are way over-subscribed. On Thu, Nov 15, 2012 at 10:54 AM, Mikeal Clark mikeal.cl...@gmail.comwrote: Hello! I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Thanks, -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Re: MPLS acceptable latency?
--- mikeal.cl...@gmail.com wrote: From: Mikeal Clark mikeal.cl...@gmail.com I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Coast-to-coast latency is around 60-65msec, so that's high. scott
Re: MPLS acceptable latency?
On Nov 15, 2012, at 1:54 PM, Mikeal Clark wrote: Hello! I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? MPLS as a technology should not add any significant delay as it is just a few bytes of label on the packet. What is the physical path of the circuits involved? Have you asked for the design of them? - Jared
Re: MPLS acceptable latency?
On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: --- mikeal.cl...@gmail.com wrote: From: Mikeal Clark mikeal.cl...@gmail.com I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Coast-to-coast latency is around 60-65msec, so that's high. What link speed? Perhaps he's using ISDN or a T1? Serialization delay is not to be ignored. - Jared
Re: MPLS acceptable latency?
The location in question is 7 T1s. They were not willing to give us fiber. On Thu, Nov 15, 2012 at 1:20 PM, Jared Mauch ja...@puck.nether.net wrote: On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: --- mikeal.cl...@gmail.com wrote: From: Mikeal Clark mikeal.cl...@gmail.com I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Coast-to-coast latency is around 60-65msec, so that's high. What link speed? Perhaps he's using ISDN or a T1? Serialization delay is not to be ignored. - Jared
Re: MPLS acceptable latency?
Your provider is likely backhauling the circuits opposite directions to PE routers in a different geographic local than the sites. It's time to have a discussion with your sales engineer about the physical pathing of your circuits and PE router locations. When I know I have latency critical circuits, I always insist on backhaul to the same geographic region and/or Pe. It's unlikely the MPLS or circuits themselves have anything to do with the latency, assuming this is T1, Ethernet, or similar. It's possible it could be a routing issue SP side, but is not as likely as a general pathing issue. On Thu, Nov 15, 2012 at 12:20 PM, Jared Mauch ja...@puck.nether.net wrote: On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: --- mikeal.cl...@gmail.com wrote: From: Mikeal Clark mikeal.cl...@gmail.com I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Coast-to-coast latency is around 60-65msec, so that's high. What link speed? Perhaps he's using ISDN or a T1? Serialization delay is not to be ignored. - Jared
Re: MPLS acceptable latency?
I concur. We have sites all over the US and it is about 80-100 ms from coast to coast with both of our MPLS providers. 45 minutes away your latency should be 5ms on a decent network. - --- mikeal.cl...@gmail.com wrote: From: Mikeal Clark mikeal.cl...@gmail.com I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Coast-to-coast latency is around 60-65msec, so that's high. scott
Re: MPLS acceptable latency?
--- ja...@puck.nether.net wrote: On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: --- mikeal.cl...@gmail.com wrote: I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Coast-to-coast latency is around 60-65msec, so that's high. What link speed? Perhaps he's using ISDN or a T1? Serialization delay is not to be ignored. - I believe serialization delay is so small as to not be very noticeable. A coast-to-coast T1 (that is not full) should have no more latency than a coast-to-coast DS-3 or any other circuit. After all, the T1 is muxed up and then down crossing the same BACs in the middle. The only serialization delay that is different is at the end points. scott (BAC = Big Ass Circuit :)
Fwd: MPLS acceptable latency?
-- Forwarded message -- From: david peahi davidpe...@gmail.com Date: Thu, Nov 15, 2012 at 12:15 PM Subject: Re: MPLS acceptable latency? To: Mikeal Clark mikeal.cl...@gmail.com Assuming no configuration errors, this underscores the need to negotiate SLAs, and serious SLA penalties, with the telcos, and to always request a telco network map, with the telco path that data will be transitting end-to-end.. My rule of thumb in network design is that data over copper or fiber takes 10 ms per 1000 miles, which is governed by the speed of light. Network devices along the path add serialization/de-serialization delay, but with modern network devices this delay is negligible. So according to this rule of thumb 85 ms is almost enough time for data to traverse the USA 3 times. I have found that telcos have been setting round trip SLAs so high that they are meaningless (e.g. 50 ms for a GigE MEF ELAN service, 20 ms for Gold MEF EVPL service), and border on being fraudulent. In one case I also noted 100 ms round trip times between sites less than 1 mile away, and discovered that every packet was being sent back to east Texas from Southern California, almost a 5000 mile detour. On Thu, Nov 15, 2012 at 10:54 AM, Mikeal Clark mikeal.cl...@gmail.comwrote: Hello! I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. What is considered normal/acceptable? Thanks,
re: Fwd: MPLS acceptable latency?
boldMy humble opinion/bold SLAs are more for accountants and lawyers. Get the right tech support on the phone and you can solve most issues without all the hassle. SLAs really are minimal if you can contact the right people and work through the problem. +1 to Level3 and Cogent as I have had some of the best trouble shooting for even minimal problems... From: david peahi davidpe...@gmail.com Sent: Thursday, November 15, 2012 3:31 PM To: nanog@nanog.org Subject: Fwd: MPLS acceptable latency? -- Forwarded message -- From: david peahi davidpe...@gmail.com Date: Thu, Nov 15, 2012 at 12:15 PM Subject: Re: MPLS acceptable latency? To: Mikeal Clark mikeal.cl...@gmail.com Assuming no configuration errors, this underscores the need to negotiate SLAs, and serious SLA penalties, with the telcos, and to always request a telco network map, with the telco path that data will be transitting end-to-end.. My rule of thumb in network design is that data over copper or fiber takes 10 ms per 1000 miles, which is governed by the speed of light. Network devices along the path add serialization/de-serialization delay, but with modern network devices this delay is negligible. So according to this rule of thumb 85 ms is almost enough time for data to traverse the USA 3 times. I have found that telcos have been setting round trip SLAs so high that they are meaningless (e.g. 50 ms for a GigE MEF ELAN service, 20 ms for Gold MEF EVPL service), and border on being fraudulent. In one case I also noted 100 ms round trip times between sites less than 1 mile away, and discovered that every packet was being sent back to east Texas from Southern California, almost a 5000 mile detour.
Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Thu, Nov 15, 2012 at 2:15 AM, Ben S. Butler ben.but...@c2internet.net wrote: Hi, ... snip ... What we need is a way to filter that says throw this prefix away if I can see it inside of another prefix. Ie discard this /48 if it is part of a /32 (or bigger) that I also have in my RIB and then insert the /32 into FIB and discard the /48. Would you want this logic to still apply if you have ::/0 in your table anywhere? It really is the ultimate covering route for everything else, and for some set of sites that advertise non-aggregated /48s, their thought process may wander into the territory of it doesn't matter so much if you don't see the more specifics, you'll just follow your default route to your upstream provider, and it'll reach me that way. It seems that this particular problem space only occurs for networks that want to implement strict filters to limit their routing table size, but also want to run completely default-free. It sounds a little bit like such people may be trying to shift the cost burden around in an odd fashion. I don't want to listen to your more specifics; I worry about my routing table resources, and whether or not I can keep up with the rest of the internet. But I also want to look like I'm one of the big default-free providers, which means I'm creating reachability problems to your network through my own choices. Won't you help me solve my self-created problem by altering how you build and configure your network? I have no issues with people filtering out more specific prefixes to limit the size of their view of the routing table; I do it for routers I administer that don't have adequate resources to take a full view. But I also ensure that those devices have a covering default route towards something that *does* know how to get closer to the destination. [more snippage...] So I guess the logic becomes /48 Routes tagged with an island community permit as long as there is not a less specific covering route in the RIB. /48 Routes tagged with a TE community can be permitted or denied as chosen by the recipient end AS but should be carried in the DFZ by transit providers. If you're having reachability problems to /48s that you're filtering out, you must be trying to play in the DFZ; otherwise, your default route would cover you, and this would be a non-issue. And if you're playing in the DFZ, by your own rule here, you should be carrying those routes rather than filtering them out. /48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid. Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 maximum announced prefix size - rather than carried in the same block as PA (Aggregated) / ISP blocks that have a /32 minimum. If we do that, it keeps the existing problem the size it is currently and solves it for future assignments, allows the island networks to work, prevents people cheating by trying to sneak a TE route in as an island route when there is covering /32 route, dumps off the rubbish from spurious announcements and hijacking, while allowing PI end user /48s to continue to work... I think that would address the problem. I think your use of the term cheating here is misapplied. You've stated that the more specifics *must* be accepted by the DFZ providers, so that downstreams can make their own decisions as to whether to accept and use them or not. You're implying that your network is default free, and thus by not accepting the more specific prefixes, you would see reachabiliity issues: It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable. Contrary to that line, you've stated you _do_ expect that DFZ providers should accept those TE routes with or without a coverall, in order to provide reachability. I don't think it's reasonable for you to expect to have it both ways. It really sounds like you want every other DFZ provider to have to carry the longer prefixes *except you*--and I don't think you'll see much support from the rest of the community for a proposal like that. And if you *do* carry ::/0 in your network from an upstream, this is all a moot point; filter away to whatever level your heart desires, you won't be creating a reachability problem; at worst, you'll create some inefficient routing, but the packets will still flow. /snip Thoughts...? Ben tl;dr -- this is what those HE sessions are for. Matt probably way off in the weeds in left field at this point...I should never try to reply to messages during the day; so many distractions, I never remember what it was I was trying to say back when I started the sentence. ^_^;
Re: MPLS acceptable latency?
On Thu, Nov 15, 2012 at 1:54 PM, Mikeal Clark mikeal.cl...@gmail.com wrote: I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. I've noticed this with ATT's MPLS product when dealing with the internal corporate network here. I don't know what they're doing wrong but it is so very wrong. What is considered normal/acceptable? Less than 10ms unless you're using a sub-T1 interface or going a very long distance. 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: MPLS acceptable latency?
--- On Thu, 11/15/12, William Herrin b...@herrin.us wrote: From: William Herrin b...@herrin.us Subject: Re: MPLS acceptable latency? To: Mikeal Clark mikeal.cl...@gmail.com Cc: NANOG [nanog@nanog.org] nanog@nanog.org Date: Thursday, November 15, 2012, 1:23 PM On Thu, Nov 15, 2012 at 1:54 PM, Mikeal Clark mikeal.cl...@gmail.com wrote: I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. I've noticed this with ATT's MPLS product when dealing with the internal corporate network here. I don't know what they're doing wrong but it is so very wrong. circa 2007, noticed same thing: never below 90ms coast-to-coast across as13979. atm ds3 handoffs on both ends. What is considered normal/acceptable? Less than 10ms unless you're using a sub-T1 interface or going a very long distance. 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: MPLS acceptable latency?
Perhaps the network is oldish and there are BW bottlenecks that lead to queues on the switches/routers that results in higher latency. This would depend alot on the internal QoS strategy used by ATT, the type of equipment used and the load in different parts of the network. The only way to know what happens inside their MPLS cloud is to get past support and ask someone from the technical staff. On 11/16/2012 12:06 AM, Randy wrote: --- On Thu, 11/15/12, William Herrin b...@herrin.us wrote: From: William Herrin b...@herrin.us Subject: Re: MPLS acceptable latency? To: Mikeal Clark mikeal.cl...@gmail.com Cc: NANOG [nanog@nanog.org] nanog@nanog.org Date: Thursday, November 15, 2012, 1:23 PM On Thu, Nov 15, 2012 at 1:54 PM, Mikeal Clark mikeal.cl...@gmail.com wrote: I have some ATT MPLS sites under a managed contract with latency averaging 75-85 ms without any load. These sites are only 45 minutes away. I've noticed this with ATT's MPLS product when dealing with the internal corporate network here. I don't know what they're doing wrong but it is so very wrong. circa 2007, noticed same thing: never below 90ms coast-to-coast across as13979. atm ds3 handoffs on both ends. What is considered normal/acceptable? Less than 10ms unless you're using a sub-T1 interface or going a very long distance. 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: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
Hi, Ok. I am trying to encourage an inclusive exploration of an issue that seems to be emergent. I am trying to get the community to articulate BCP not dictate it. Would you want this logic to still apply if you have ::/0 in your table anywhere? Yes obviously limits would apply to the filter on min and max in a recursive filter. It sounds a little bit like such people may be trying to shift the cost burden around in an odd fashion. I am seeking community input before we manage to screw things up. I do not want a route table with 10M+ prefixes. One of the points of v6 is aggregation, would it not be silly to adopt a liaise a faire view to route pollution and associated security considerations. But I also want to look like I'm one of the big default-free providers I struggle to not use direct language here. Firstly I never asserted I was DFZ or want to be, quiet the opposite, seeking clarification of BCP. default route towards something that *does* know how to get closer to the destination. Filtering exists for internet security not route table size, your default return path trashes that. you must be trying to play in the DFZ Lol, understand the issue at hand I think your use of the term cheating here is misapplied. Read my suggestion, if you deliberately falsely tag a route with the wrong community under my proposed model, what would you call it? You're implying that your network is default free Nope, I am trying to find a solution that works for everyone that empowers the recipient AS with the choice of what they filter in an informed fashion for mutual benefit. DFZ provider to have to carry the longer prefixes *except you* Firstly that was a comment to the sub informed way some people work, however, my point is we have a legacy that can not be solved by new policy. We have to accommodate that legacy and the answer is not to say lets just go with a /48 no questions asked. Networks involve design and engineering, we can accommodate all peoples needs within a structure. And if you *do* carry ::/0 in your network from an upstream, this is all a moot point; filter away to whatever level your heart desires, You just agreed with me. # We are at the start of a new network, lets learn from the past. My posts are open and non judgemental, please, keep to the issue, if you don't get it yet then clue up. Arms open here, can anyone else see the future cast issue I am tryin to raise if all the aggregate deag without control, we were all worried about PI multihoming a year ago and route table bloat. Lets try to stay on point. Ben
Re: authority to route?
Jeez, isn't RPKI supposed to solve this problem? On Thu, Nov 15, 2012 at 10:36 AM, Schiller, Heather A heather.schil...@verizon.com wrote: ..for some blocks I've taken over admin for. Make sure you are visibly listed as a Point of Contact on those records in the appropriate RIR, so that folks who get your request can verify you. Even better, register in your RIR's RPKI program and generate a ROA for it. Info about ARIN's here: https://www.arin.net/resources/rpki/index.html Then yes, notify their upstreams/peers if needed and post here if things get really desperate - have your records in order first. --Heather -Original Message- From: Jim Mercer [mailto:j...@reptiles.org] Sent: Monday, November 12, 2012 2:44 PM To: nanog@nanog.org Subject: authority to route? Hi, Is there a common practice of providers to vet / validate requests to advertise blocks? Who is the authority when it comes to determining if a request for routing is valid? Is it the WHOIS data maintained by the various RIR? It seems I'm playing whack-a-mole to get some routes shut down for some blocks I've taken over admin for. If I email the contacts for the AS in WHOIS, and get no response, or a negative response, should I start going to their peers? Some practical advice would be appreciated. -- Jim Mercer Reptilian Research j...@reptiles.org+1 416 410-5633 He who dies with the most toys is nonetheless dead -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer
