- NANOG - lists.nanog.org

Re: Bandwidth Savings
by Marty Strong 11 Jan '17

11 Jan '17

Seemingly also a GGC is there: https://ix.tt/cache-services-now-live-at-ttix/ maybe if the cost is low it might be worth it, assuming the incumbent doesn’t make it prohibitive. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty(a)cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 11 Jan 2017, at 22:17, Martin Hannigan <hannigan(a)gmail.com> wrote: > > > > > There's also an IXP in Trinidad: > > https://www.peeringdb.com/ix/940 > > [ .. ] > > https://ix.tt/membership/founding-members/ > > That doesn't mean a lot other than there's an IXP with at least Akamai and Columbus. I know the Akamai cache is there because I put it there. > > I was going to point at CaribNOG, but the MX is null and they're off the air. > > Best, > > -M< > > > > > On Wed, Jan 11, 2017 at 4:34 PM, Marty Strong via NANOG <nanog(a)nanog.org> wrote: > I believe the ISP is located in Trinidad & Tobago. > > There are five international submarine cables that land on the island: > - SG-SCS > - Americas-II > - ECFS > - Southern Caribbean Fiber > - ECLink > > Of those, 1 go to the closest real interconnectivity hub of Miami, with the others requiring another pair onwards. > > ECLink lands in Curaçao, which could give access to AMS-IX Caribbean, which may help with connectivity to content providers, both Akamai and Goole are live and we are in the process of connecting (https://cw.ams-ix.net/connected_parties) Pricing however, is probably just as expensive on that cable than to Miami. > > It would be interesting to hear from the OP the rough pricing for connectivity to Miami, vs. elsewhere. > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty(a)cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > > > On 11 Jan 2017, at 21:23, Eric Kuhnke <eric.kuhnke(a)gmail.com> wrote: > > > > The challenges are almost certainly economics related, at the lack of > > competition and high costs for layer 1/2 transport from his Caribbean > > island to Miami. Via whatever submarine cables exist that are controlled by > > larger ILEC type entities/telcos. Or satellite (whether geostationary > > transponder capacity or o3b). > > > > Depending on what island we're talking about, the $$$$$/month for a single > > 1GbE or 10GbE layer 2 transport service from $ISLAND to Miami will be very > > high compared to what a network operator in the US 48 states is accustomed > > to paying. > > > > On Wed, Jan 11, 2017 at 12:55 PM, Richard Hicks <richard.hicks(a)gmail.com> > > wrote: > > > >> > >> I don't know the the Caribbean Internet Exchanges market. Are any worth > >> peering at versus buying additional L2 bandwidth to Miami? > >> > >> https://cw.ams-ix.net/ > >> http://www.ocix.net/ocix/ > >> > >> Rick > >> > >> On Tue, Jan 10, 2017 at 8:08 PM, Keenan Singh <keenansingh(a)airlinktt.net> > >> wrote: > >> > >>> Hi Guys > >>> > >>> We are an ISP in the Caribbean, and are faced with extremely high > >> Bandwidth > >>> costs, compared to the US, we currently use Peer App for Caching however > >>> with most services now moving to HTTPS the cache is proving to be less > >> and > >>> less effective. We are currently looking at any way we can save on > >>> Bandwidth or to be more Efficient with the Bandwidth we currently have. > >> We > >>> do have a Layer 2 Circuit between the Island and Miami, I am seeing there > >>> are WAN Accelerators where they would put a Server on either end and sort > >>> of Compress and decompress the Traffic before it goes over the Layer 2, I > >>> have never used this before, has any one here used anything like this, > >> what > >>> results would I be able to expect for ISP Traffic? > >>> > >>> If not any ideas on Bandwidth Savings, or being more Efficient with want > >> we > >>> currently. > >>> > >>> Many thanks for any Help > >>> > >>> Keenan > >>> > >> > >

1 0

RE: Soliciting your opinions on Internet routing: A survey on BGP convergence
by Jakob Heitz (jheitz) 11 Jan '17

11 Jan '17

When you simply bring down an ebgp session, withdraws will propagate throughout the network. Soon after, the alternate routes will propagate. In the interim, some routers will lose connectivity. This problem is solved by graceful shutdown. This only works for planned shutdown This interim time can be many minutes because of the advertisement-interval (MRAI timer). A possible solution to reduce this interim to seconds instead of minutes is to set the MRAI timer to 0 on all routers. A potential problem with that is that any BGP instability in the network will cause some serious flapping. Another alternative is to use BGP add-path (rfc7911) to distribute backup routes. This will avoid the MRAI problem, but requires more memory on routers. This also works for accidental shutdown. Thanks, Jakob. > -----Original Message----- > From: Jakob Heitz (jheitz) > Sent: Tuesday, January 10, 2017 11:52 AM > To: nanog(a)nanog.org; 'baldur.norddahl(a)gmail.com' <baldur.norddahl(a)gmail.com> > Subject: RE: Soliciting your opinions on Internet routing: A survey on BGP convergence > > Hi Baldur, > > Have you tried graceful shutdown? > You need redundant links, but not to the same transit. > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06 > This draft is expired, but it is actually implemented by several vendors. > > I implemented this. > http://www.slideshare.net/bduvivie/bgp-graceful-shutdown-ios-xr > I added an option to configure AS-path prepends in case the gshut community was not supported by peers. > > Thanks, > Jakob. > > > > Date: Tue, 10 Jan 2017 03:51:04 +0100 > > From: Baldur Norddahl <baldur.norddahl(a)gmail.com> > > > > Hello > > > > I find that the type of outage that affects our network the most is > > neither of the two options you describe. As is probably typical for > > smaller networks, we do not have redundant uplinks to all of our > > transits. If a transit link goes, for example because we had to reboot a > > router, traffic is supposed to reroute to the remaining transit links. > > Internally our network handles this fairly fast for egress traffic. > > > > However the problem is the ingress traffic - it can be 5 to 15 minutes > > before everything has settled down. This is the time before everyone > > else on the internet has processed that they will have to switch to your > > alternate transit. > > > > The only solution I know of is to have redundant links to all transits. > > Going forward I will make sure we have this because it is a huge > > disadvantage not being able to take a router out of service without > > causing downtime for all users. Not to mention that a router crash or > > link failure that should have taken seconds at most to reroute, but > > instead causes at least 5 minutes of unstable internet. > > > > Regards, > > > > Baldur

1 0

OmanTel hijacking of IP space
by Jared Mauch 11 Jan '17

11 Jan '17

There is an ongoing pattern of OmanTel hijacking IP space and advertising it to many of their peers (but not transits). here’s the most recent announcement. This could be mitigated in a few days, such as filtering your peers on a prefix basis, or at minimum rejecting the private ASN space, eg: 64512-65535, as well as the 4 byte variant range: 4200000000-4294967294 Please take a moment and update your AS_PATH filters to minimize the pollution you accept or propagate. - Jared (more details - http://dyn.com/blog/iran-leaks-censorship-via-bgp-hijacks/ ) route-views>sh ip bgp 206.125.164.0/24 long BGP table version is 38506351, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 206.125.164.0 193.0.0.56 0 3333 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 123.108.254.218 0 9902 24218 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 i * 195.208.112.161 0 3277 3267 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 194.85.40.15 0 3267 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 212.66.96.126 0 20912 1267 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 95.85.0.2 0 200130 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 5.101.110.2 0 202018 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i *> 103.247.3.45 0 58511 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i * 80.241.176.31 0 20771 47872 8529 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 12880 65050 i

2 1

SoCal FIOS outage(?) / static IP readdressing
by Paul B. Henson 11 Jan '17

11 Jan '17

So I woke up this morning to discover my business FIOS had croaked about 3:30 AM :(. Everything looked good on the ONT, but couldn't ping the gateway. Poked at it from the other side, and it looked like traceroute died a hop or so short of what I remember, so seemed to be a layer 3 issue on their side. Called support, killed an hour going through the level 1 checklist (I suppose I understand why they have to do it, but it doesn't make it any less frustrating to have to do the reset/power cycle/cable reseat dance when you already know it's not going to change a thing). Finally talked her into escalating the issue, and was told there was a known outage in my area with reference #37202878, no cause provided, and no ETA on resolution. Yay. So I opened a chat session a little bit ago to see if I could get an update on when my FIOS might come back. Of course the support tech wanted to lead me through the dance again <sigh>, but I explained my earlier conversation and asked him if he could just update me on the outage. He said he had no record of that outage. I talked him into escalating the issue again. He said his escalation engineer had never heard of that outage or that reference number, and that everything seemed fine with my FIOS, and I should just try resetting the ONT again 8-/. So here I am, still with no FIOS, a general outage that may or may not exist, and support techs with different stories :(. The last time I had a problem like this my FIOS was down about three days, level 1 and level 2 support swore there was nothing wrong with it and had actually scheduled a truck roll to replace my ONT, and it turned out to be an accidental misconfiguration that took a while to resolve. I'm assuming something similar happened again this time, same mysterious layer 3 breakage in the middle of the night, same claims by layer 1 and layer 2 support that there's nothing wrong, same obvious layer 3 functionality issues. I'm guessing it will eventually just start working again. Hopefully it won't be three days this time. If anybody in Frontier land wants to throw a fellow network admin a bone and has any information on this potential outage or when my FIOS might come back online I'd really appreciate knowing :). On another note, I was wondering if anybody has had their static FIOS IP addresses migrated from Verizon space to Frontier space yet? Last April they said they are going to do it by this April, which only leaves four months. So far I haven't heard anything about it regarding my account. Thanks…

16 27

RE: Soliciting your opinions on Internet routing: A survey on BGP convergence
by Jakob Heitz (jheitz) 10 Jan '17

10 Jan '17

Hi Baldur, Have you tried graceful shutdown? You need redundant links, but not to the same transit. https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06 This draft is expired, but it is actually implemented by several vendors. I implemented this. http://www.slideshare.net/bduvivie/bgp-graceful-shutdown-ios-xr I added an option to configure AS-path prepends in case the gshut community was not supported by peers. Thanks, Jakob. > Date: Tue, 10 Jan 2017 03:51:04 +0100 > From: Baldur Norddahl <baldur.norddahl(a)gmail.com> > > Hello > > I find that the type of outage that affects our network the most is > neither of the two options you describe. As is probably typical for > smaller networks, we do not have redundant uplinks to all of our > transits. If a transit link goes, for example because we had to reboot a > router, traffic is supposed to reroute to the remaining transit links. > Internally our network handles this fairly fast for egress traffic. > > However the problem is the ingress traffic - it can be 5 to 15 minutes > before everything has settled down. This is the time before everyone > else on the internet has processed that they will have to switch to your > alternate transit. > > The only solution I know of is to have redundant links to all transits. > Going forward I will make sure we have this because it is a huge > disadvantage not being able to take a router out of service without > causing downtime for all users. Not to mention that a router crash or > link failure that should have taken seconds at most to reroute, but > instead causes at least 5 minutes of unstable internet. > > Regards, > > Baldur

1 0

Some standard of showing "this is how my network works"?
by Mike Lund 10 Jan '17

10 Jan '17

Hey, sorry for bad title. I am wondering if there is some standard that is gaining traction which gives actual useful information regarding an IP. My biggest example is HE's rwhois referral, giving information about the given IPv6 IP -- if it's a /64, /48, etc. Such information that helps abuse admins make more-accurate policy decisions. This is just an example, there could be other useful information as well. Is this such a thing anywhere? Or is it like most networking things, where only the smaller companies do anything useful like this? Thanks for your time!

2 1

IETF RTGWG interim meeting - Existing problems for routing in the large Data Centers and potential solutions
by Jeff Tantsura 10 Jan '17

10 Jan '17

/RTGWG chair hat on Dear NANOG, For those, who might be interested, on January 25 we (IETF Routing Area RTGWG) will be having an interim online meeting, dedicated to Existing problems for routing in the large Data Centers and potential solutions. Presenters will be describing (15 minutes per presentation) problems in the space, followed by potential solutions Please join us. Presenters: Problem statements: Peter Lapukhov - FB Dmitry Afanasiev - YANDEX Russ White/ Shawn Zandi - LinkedIn Solutions proposed: Keyur Patel, Arrcus - Shortest Path Routing Extensions for BGP Protocol, draft-keyupate-idr-bgp-spf Naiming Shen , Cisco - IS-IS Routing for Spine-Leaf Topology, draft-shen-isis-spine-leaf-ext Tony Przygienda, Juniper - RIFT: Routing in Fat Trees, draft-przygienda-rift (draft to be published later this week) Bhumip Khasnabish, ZTE - Generic Fault-avoidance Routing Protocol for Data Center Networks, draft-sl-rtgwg-far-dcn Cheers, Jeff From: Routing Area Working Group <messenger(a)webex.com> Reply-To: rtgwg-chairs <rtgwg-chairs(a)ietf.org> Date: Tuesday, December 20, 2016 at 11:47 To: <rtgwg-chairs(a)tools.ietf.org> Subject: WebEx meeting invitation: Existing problems for routing in the large Data Centers and potentail solutions Resent-From: <alias-bounces(a)ietf.org> Resent-To: <jefftant.ietf(a)gmail.com>, Chris Bowers <cbowers(a)juniper.net> Resent-Date: Tue, 20 Dec 2016 11:47:19 -0800 (PST) Hello, Routing Area Working Group invites you to join this WebEx meeting. Existing problems for routing in the large Data Centers and potential solutions Wednesday, January 25, 2017 9:00 am | Pacific Standard Time (San Francisco, GMT-08:00) | 2 hrs 30 mins Meeting number (access code): 649 161 321 Meeting password: px3Gk22M Add to Calendar When it's time, join the meeting. Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Toll-free calling restrictions Can't join the meeting? IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

1 0

Soliciting your opinions on Internet routing: A survey on BGP convergence
by Laurent Vanbever 10 Jan '17

10 Jan '17

Hi NANOG, We often read that the Internet (i.e. BGP) is "slow to converge". But how slow is it really? Do you care anyway? And can we (researchers) do anything about it? Please help us out to find out by answering our short anonymous survey (<10 minutes). Survey URL: https://goo.gl/forms/JZd2CK0EFpCk0c272 <https://goo.gl/forms/WW7KX5kT45m6UUM82> ** Background: While existing fast-reroute mechanisms enable sub-second convergence upon local outages (planned or not), they do not apply to remote outages happening further away from your AS as their detection and protection mechanisms only work locally. Remote outages therefore mandate a "BGP-only" convergence which tends to be slow, as long streams of BGP UPDATEs (containing up to 100,000s of them) must be propagated router-by-router. Our initial measurements indicate that it can take state-of-the-art BGP routers dozens of seconds to process and propagate these large streams of BGP UPDATEs. During this time, traffic for important destinations can be lost. ** This survey: This survey aims at evaluating the impact of slow BGP convergence on operational practices. We expect the findings to increase the understanding of the perceived BGP convergence in the Internet, which could then help researchers to design better fast-reroute mechanisms. We expect the questionnaire to be filled out by network operators whose job relates to BGP operations. It has a total of 17 questions and should take less 10 minutes to answer. The survey and the collected data are anonymous (so please do *not* include information that may help to identify you or your organization). All questions are optional, so if you don't like a question or don't know the answer, please skip it. A summary of the aggregate results will be published as a part of a scientific article later this year. Thank you so much in advance, and we look forward to read your responses! Laurent Vanbever (ETH Zürich, Switzerland) PS: It goes without saying that we would be also extremely grateful if you could forward this email to any operator you might know who may not read NANOG.

7 8

[NANOG-announce] NANOG 69 Update
by Betty Burke <betty＠nanog.org> 09 Jan '17

09 Jan '17

NANOGers, We are in the final stages of preparation for NANOG 69, February 6-8, 2017 in Washington, DC. A few highlights and reminders follow: The NANOG 69 Highlights <http://nanog.org/meetings/nanog69/agendahighlights> page is now posted. The NANOG 69 Agenda Outline is available now, with the actual agenda <http://nanog.org/meetings/nanog69/agendaoutline>to be posted on or about January 16, 2017, with updates being provided as warranted. The NANOG Program Committee continues to receive submissions as part of the Call for Presentations <http://nanog.org/meetings/nanog69/callforpresentations>. Please be aware of the NANOG 69 Registration <http://nanog.org/meetings/nanog69/register> Fee dates, and the NANOG 69 Hotel Reservation deadline. - Late Registration starting January 9, 2017 (member $725, non-member $750, student $100) - On-Site Registration starting February 5, 2017 (member $925, non-member $950, student $100) - Cancellation Fee: $50.00, 2 weeks before meeting cancellation fee is $100.00 - January 23, 2017 - No refund will be offered after Sunday, February 5, 2017. The Grand Hyatt Washington <http://nanog.org/meetings/nanog69/hotelinfo> Group Rate Expires: Friday, January 13, 2017. Online Reservations can be made online: Group Name: NANOG 69 Room Rate: $249.00 Standard Room Single and Double Occupancy $274.00 Triple Occupancy $299.00 Quadruple Occupancy There are a few Sponsorship opportunities available, you can email sponsor-support(a)nanog.org for further information. We look forward to our NANOG visit back to DC and welcome those attendees <http://nanog.org/meetings/nanog69/attendee> and meeting sponsors <http://nanog.org/meetings/nanog69/sponsors>already planning their trip to NANOG 69. We encourage you to join us for what will be another great February NANOG meeting! Should you have any questions, do contact us at nanog-support(a)nanog.org Respectfully, Betty Betty J. Burke NANOG Executive Director 2864 Carpenter Rd., Ste 100 Ann Arbor, MI 48108 +1 866-902-1336 _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Re: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization
by Scott Weeks 09 Jan '17

09 Jan '17

:: and minimal time zones (still 5 hours :: between New York and Hawaii though). Apologies, I can't resist. :) Sometimes it's 6 hours and some times it's 5 between Hawaii and the East Coast. Hawaii is *always* -10 GMT. We don't do daylight savings time. scott

3 2