From mhuff at ox.com Sun Jan 1 01:02:24 2017 From: mhuff at ox.com (Matthew Huff) Date: Sun, 1 Jan 2017 01:02:24 +0000 Subject: Someone didn't get the leap second memo... Message-ID: <1b0e381ce8874b0aa190abbeb6f38182@pur-vm-exch13n1.ox.com> [root at hayden ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 20d 64 0 0.000 0.000 0.000 -clock.xmission. 132.163.4.103 2 u 169 256 377 66.078 -1.302 0.164 xclock.sjc.he.ne 10.200.208.2 2 u 13 256 315 65.689 999.633 2.015 +tock.usshc.com .GPS. 1 u 87 256 377 26.930 -0.550 0.121 *ntp.your.org .CDMA. 1 u 43 256 217 23.339 0.544 0.069 Our batch system went belly up, but other than that, no other apparent leap second issues. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 From hugo at slabnet.com Sun Jan 1 01:47:17 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Sat, 31 Dec 2016 17:47:17 -0800 Subject: Someone didn't get the leap second memo... In-Reply-To: <1b0e381ce8874b0aa190abbeb6f38182@pur-vm-exch13n1.ox.com> References: <1b0e381ce8874b0aa190abbeb6f38182@pur-vm-exch13n1.ox.com> Message-ID: <20170101014717.GA5132@bamboo.slabnet.com> Had a set of Cisco ASR1004s running 15.4(3)S1 (on IOS-XE 03.13.01.S) all restart at around midnight UTC, and all with `Last reload reason: Watchdog`, with those boxes being at separate DCs in different regions. I'm assuming when I call TAC I'll get a "whoops; sorry". -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Sun 2017-Jan-01 01:02:24 +0000, Matthew Huff wrote: >[root at hayden ~]# ntpq -p > remote refid st t when poll reach delay offset jitter >============================================================================== > LOCAL(0) .LOCL. 10 l 20d 64 0 0.000 0.000 0.000 >-clock.xmission. 132.163.4.103 2 u 169 256 377 66.078 -1.302 0.164 >xclock.sjc.he.ne 10.200.208.2 2 u 13 256 315 65.689 999.633 2.015 >+tock.usshc.com .GPS. 1 u 87 256 377 26.930 -0.550 0.121 >*ntp.your.org .CDMA. 1 u 43 256 217 23.339 0.544 0.069 > >Our batch system went belly up, but other than that, no other apparent leap second issues. > >---- >Matthew Huff???????????? | 1 Manhattanville Rd >Director of Operations???| Purchase, NY 10577 >OTA Management LLC?????? | Phone: 914-460-4039 >aim: matthewbhuff??????? | Fax:?? 914-694-5669 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From richard.hicks at gmail.com Sun Jan 1 02:17:05 2017 From: richard.hicks at gmail.com (Richard Hicks) Date: Sat, 31 Dec 2016 18:17:05 -0800 Subject: Someone didn't get the leap second memo... In-Reply-To: <20170101014717.GA5132@bamboo.slabnet.com> References: <1b0e381ce8874b0aa190abbeb6f38182@pur-vm-exch13n1.ox.com> <20170101014717.GA5132@bamboo.slabnet.com> Message-ID: We had some ASR1001s routers reboot. Looks like we hit this bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb01730 On Sat, Dec 31, 2016 at 5:47 PM, Hugo Slabbert wrote: > Had a set of Cisco ASR1004s running 15.4(3)S1 (on IOS-XE 03.13.01.S) all > restart at around midnight UTC, and all with `Last reload reason: > Watchdog`, with those boxes being at separate DCs in different regions. > I'm assuming when I call TAC I'll get a "whoops; sorry". > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > > On Sun 2017-Jan-01 01:02:24 +0000, Matthew Huff wrote: > > [root at hayden ~]# ntpq -p >> remote refid st t when poll reach delay offset >> jitter >> ============================================================ >> ================== >> LOCAL(0) .LOCL. 10 l 20d 64 0 0.000 0.000 >> 0.000 >> -clock.xmission. 132.163.4.103 2 u 169 256 377 66.078 -1.302 >> 0.164 >> xclock.sjc.he.ne 10.200.208.2 2 u 13 256 315 65.689 999.633 >> 2.015 >> +tock.usshc.com .GPS. 1 u 87 256 377 26.930 -0.550 >> 0.121 >> *ntp.your.org .CDMA. 1 u 43 256 217 23.339 0.544 >> 0.069 >> >> Our batch system went belly up, but other than that, no other apparent >> leap second issues. >> >> ---- >> Matthew Huff | 1 Manhattanville Rd >> Director of Operations | Purchase, NY 10577 >> OTA Management LLC | Phone: 914-460-4039 >> aim: matthewbhuff | Fax: 914-694-5669 >> >> >> From jlewis at lewis.org Sun Jan 1 05:14:15 2017 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 1 Jan 2017 00:14:15 -0500 (EST) Subject: Someone didn't get the leap second memo... In-Reply-To: References: <1b0e381ce8874b0aa190abbeb6f38182@pur-vm-exch13n1.ox.com> <20170101014717.GA5132@bamboo.slabnet.com> Message-ID: We manage a couple of these too, running an affected version. :( I've applied the suggested workaround, but not the recommended 24h in advance of the unexpected leap second. I'll find out tomorrow if that mattered. On Sat, 31 Dec 2016, Richard Hicks wrote: > We had some ASR1001s routers reboot. > > Looks like we hit this bug: > https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb01730 > > > On Sat, Dec 31, 2016 at 5:47 PM, Hugo Slabbert wrote: > >> Had a set of Cisco ASR1004s running 15.4(3)S1 (on IOS-XE 03.13.01.S) all >> restart at around midnight UTC, and all with `Last reload reason: >> Watchdog`, with those boxes being at separate DCs in different regions. >> I'm assuming when I call TAC I'll get a "whoops; sorry". >> >> -- >> Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com >> pgp key: B178313E | also on Signal >> >> >> On Sun 2017-Jan-01 01:02:24 +0000, Matthew Huff wrote: >> >> [root at hayden ~]# ntpq -p >>> remote refid st t when poll reach delay offset >>> jitter >>> ============================================================ >>> ================== >>> LOCAL(0) .LOCL. 10 l 20d 64 0 0.000 0.000 >>> 0.000 >>> -clock.xmission. 132.163.4.103 2 u 169 256 377 66.078 -1.302 >>> 0.164 >>> xclock.sjc.he.ne 10.200.208.2 2 u 13 256 315 65.689 999.633 >>> 2.015 >>> +tock.usshc.com .GPS. 1 u 87 256 377 26.930 -0.550 >>> 0.121 >>> *ntp.your.org .CDMA. 1 u 43 256 217 23.339 0.544 >>> 0.069 >>> >>> Our batch system went belly up, but other than that, no other apparent >>> leap second issues. >>> >>> ---- >>> Matthew Huff | 1 Manhattanville Rd >>> Director of Operations | Purchase, NY 10577 >>> OTA Management LLC | Phone: 914-460-4039 >>> aim: matthewbhuff | Fax: 914-694-5669 >>> >>> >>> > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From chuckchurch at gmail.com Sun Jan 1 13:05:25 2017 From: chuckchurch at gmail.com (Chuck Church) Date: Sun, 1 Jan 2017 08:05:25 -0500 Subject: Someone didn't get the leap second memo... In-Reply-To: References: <1b0e381ce8874b0aa190abbeb6f38182@pur-vm-exch13n1.ox.com> <20170101014717.GA5132@bamboo.slabnet.com> Message-ID: <008a01d2642f$bb0b5bd0$31221370$@gmail.com> That bug note indicates all 3.13.* are vulnerable to this, but our 3.13.3 lab router seemed ok, no reload. Logged: Dec 31 23:59:59: %IOSXE-5-PLATFORM: R0/0: kernel: Clock: inserting leap second 23:59:60 UTC But the release notes seem to indicate that bugs: CSCut82336 ASR1002-X: Handle leap second in ToD IN CSCut65374 PTP Leap Second: ASR1002-X incorporate leap second addition 6/30/15 are open caveats in 3.13.3, and resolved in 3.13.4. I guess I'll find out which of our 300+ ASR 1000s misbehaved on Tuesday. They're pretty much all on 3.13.5. Hopefully none had an issue. There are a lot of PSIRTs with ASRs, that's the main reason we're on later 3.13 versions. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Richard Hicks Sent: Saturday, December 31, 2016 9:17 PM To: Hugo Slabbert Cc: nanog at nanog.org Subject: Re: Someone didn't get the leap second memo... We had some ASR1001s routers reboot. Looks like we hit this bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb01730 On Sat, Dec 31, 2016 at 5:47 PM, Hugo Slabbert wrote: > Had a set of Cisco ASR1004s running 15.4(3)S1 (on IOS-XE 03.13.01.S) > all restart at around midnight UTC, and all with `Last reload reason: > Watchdog`, with those boxes being at separate DCs in different regions. > I'm assuming when I call TAC I'll get a "whoops; sorry". > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > > On Sun 2017-Jan-01 01:02:24 +0000, Matthew Huff wrote: > > [root at hayden ~]# ntpq -p >> remote refid st t when poll reach delay offset >> jitter >> ============================================================ >> ================== >> LOCAL(0) .LOCL. 10 l 20d 64 0 0.000 0.000 >> 0.000 >> -clock.xmission. 132.163.4.103 2 u 169 256 377 66.078 -1.302 >> 0.164 >> xclock.sjc.he.ne 10.200.208.2 2 u 13 256 315 65.689 999.633 >> 2.015 >> +tock.usshc.com .GPS. 1 u 87 256 377 26.930 -0.550 >> 0.121 >> *ntp.your.org .CDMA. 1 u 43 256 217 23.339 0.544 >> 0.069 >> >> Our batch system went belly up, but other than that, no other >> apparent leap second issues. >> >> ---- >> Matthew Huff | 1 Manhattanville Rd >> Director of Operations | Purchase, NY 10577 >> OTA Management LLC | Phone: 914-460-4039 >> aim: matthewbhuff | Fax: 914-694-5669 >> >> >> From fredrik at i2b.se Sun Jan 1 22:16:30 2017 From: fredrik at i2b.se (Fredrik Holmqvist / I2B) Date: Sun, 01 Jan 2017 21:16:30 -0100 Subject: microducts In-Reply-To: <03fb32c5-3377-a158-3b6e-d0024efee7af@gmail.com> References: <03fb32c5-3377-a158-3b6e-d0024efee7af@gmail.com> Message-ID: <03f463cbf824d4dfdc07a75748e7e57a@i2b.se> Hi. From my own experience i would recommend 7/3.5 mm DB (Direct Burial) ducts from a cabinet to each home, and put in for 100% when doing the digging, the cost for the duct is low, so it's a bad idea to not do it right away. You do not have to leave duct to reach all the way into the customers home, just leave it at the customers premise in the ground (don't forget to add a dust cap so that you do not get in moisture and/or dirt into the duct). We have blown 800 meters of EBFU in a 7/3.5 mm DB duct, so as long as you don't have lots of curves (or atleast not sharp ones and make good duct splices (which is not hard)) then you can go a long distance. How many cabinets you need depends on the cost of subscriber ducts/fiber vs. cabinet cust. We have had cases where we could do 100% uptake with just one cabinet, but it was 25% more expensive that just add another cabinet and put a 14/10 ducts with 96 fiber betweeen them. Another recommendation is to use 14/10 ducts from the CO and between the cabinets. Put in more than one so you can expand or use to go to the next area or CO. Example: CO > Cabinet 1 > Cabinet 2 > Cabinet 3 > Cabinet 4 Each cabinet in this case can have up to 48 subscribers. Start with a 192 fiber (which is available for the 14/10 ducts) between CO and cabinet 1. Go with 144 fiber from cabinet 1 to cabinet 2. Go with 96 fiber from cabinet 2 to cabinet 3. Go with 48 fiber from cabinet 3 to cabinet 4. You can also go with for example a 192 fiber all the way, and if you need to expand, just blow in a new fiber (in another 14/10 duct) between the CO and cabinet 1 and splice them into the rest of the fibers between cabinet 1 and cabinet 2. There is alot of different designs, but it's much cheaper to put in a cable of extra ducts day 1 than to dig up everything to put in another duct later. Here is some prices for reference (from distributors in Sweden, prices may differ and project pricing apply from your manufacturer): DB1 - 7/3.5 0.16 Euro/m DB4 - 7/3.5 0.82 Euro/m DB7 - 7/3.5 1.28 Euro/m DB12 - 7/3.5 2.06 Euro/m DB1 - 14/10 0.33 Euro/m DB2 - 14/10 1.05 Euro/m DB4 - 14/10 1.85 Euro/m DB7 - 14/10 2.94 Euro/m 24x SM Microfiber for 14/10 0.78 Euro/m 48x SM Microfiber for 14/10 1.15 Euro/m 72x SM Microfiber for 14/10 1.49 Euro/m 96x SM Microfiber for 14/10 1.89 Euro/m 144x SM Microfiber for 14/10 2.76 Euro/m 192x SM Microfiber for 14/10 3.56 Euro/m EBFU 2x SM for 7/3.5 0.166 Euro/m EBFU 4x SM for 7/3.5 0.194 Euro/m EBFU 8x SM for 7/3.5 0.353 Euro/m EBFU 12x SM for 7/3.5 0.454 Euro/m In Sweden most providers use this kind of material for their FTTH projects, but small providers to the incumbents. The old way of using 32 or 40 mm ducts is mostly used for long backbone links or where you use bigger fibertrunks (384, 480, 960, 1280 fibers (most often ribbon fiber)). Hope it helps, and if you have any questions, just ask. On 2016-12-29 20:45, Baldur Norddahl wrote: > Hi > > I am planing a new FTTH outside plant deployment. We are going to use > microducts but which system is the best? I see many resources > describing the options available but few if any will take a stance on > which one to choose. > > Some of the choices are: > > 1) Ducts with larger fixed tubes for direct burial 12/8 mm. Typically > 7 ducts in a larger tube. > 2) Ducts with smaller fixed tubes 5/3,5 mm. Typically 24 small tubes > with one larger centre tube for backbone. > 3) Ducts for direct burial arranged in a stripe side by side instead > of in a tube. 12/8 mm ducts. Makes it easier to access the tubes and > avoids problems with tubes of different length on the drum. > > And many more variations. > > I am planing to deploy in an area with the average distance between > houses of 10 meters (actually 20 meters but we can serve both sides > of > the road from one walkway, so that makes it 10 meters average). > > I want to support a low level of initial uptake of just 10%. The > problem is that most sources assume that I am planing for anything > between 100% and 50%. I do expect that we will get more customers > than > just 10%, but the solution might become too expensive, if I have to > pay all costs upfront years before I have any hope of that many > customers. > > Some people say just put a lot of plastic down because it is so > cheap. But it really isn't. I need to put down the correct amount of > tubes because tubes are everything but cheap. I also need a system > that is easy and quick to work with because labour is very expensive > (but also very skilled) around here. > > I would appreciate any pointers to articles about this subject. > > Regards, > > Baldur -- Fredrik Holmqvist I2B (Internet 2 Business) 070-740 5033 From henson at acm.org Wed Jan 4 02:56:13 2017 From: henson at acm.org (Paul B. Henson) Date: Tue, 3 Jan 2017 18:56:13 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing Message-ID: <20170104025613.GG3703@bender.cpp.edu> 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 , 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? From mel at beckman.org Wed Jan 4 04:01:03 2017 From: mel at beckman.org (Mel Beckman) Date: Wed, 4 Jan 2017 04:01:03 +0000 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <20170104025613.GG3703@bender.cpp.edu> References: <20170104025613.GG3703@bender.cpp.edu> Message-ID: Every time I?ve opened a FIOS ticket, Frontier can never find the ticket later. I even escalated all the way to the president of Frontier. Someone in his office took all my info and discussed the problems at length, and finally gave me something like a $150 credit. Now I just pray it never goes down, because when it does, Frontier is not competent to solve the problem in anything like a timely fashion. If a Frontier tech is on this list, I ask you kindly figure out what the blasted deal is with your vanishing ticket numbers. This has been going on for MONTHS! -mel beckman > On Jan 3, 2017, at 6:56 PM, Paul B. Henson wrote: > > 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 , 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? > From henson at acm.org Wed Jan 4 08:28:57 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 4 Jan 2017 00:28:57 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <20170104025613.GG3703@bender.cpp.edu> References: <20170104025613.GG3703@bender.cpp.edu> Message-ID: <20170104082856.GH3709@bender.unx.cpp.edu> On Tue, Jan 03, 2017 at 06:56:13PM -0800, Paul B. Henson wrote: > Hopefully it won't be three days this time. Well, my FIOS mysteriously came back online about 9:45pm, a bit over 18 hours after it mysteriously dropped offline. I happened to be in the wiring closet staring angrily at the ONT about 8:30ish and noticed that it reset itself 2 or 3 times over the course of about 10 minutes, so I get the feeling somebody was fiddling with it remotely. I suppose I'll never really know what was broken or how it ended up being fixed, other than having about 100% certainty it was on the far side of the fiber. It's understandable that equipment breaks, and people misconfigure things sometimes. What I find insanely frustrating is the complete disconnect between level 1/2 support and the network engineers that actually know what's going on. When I called this morning with a complete outage of my business class FIOS, somebody probably knew it was down, or at least should have been able to tell it was down. But instead I get to waste hours of my time going through meaningless troubleshooting steps because lower level support doesn't have that information. And then after actually getting an escalation to someone who confirms an outage and gives me a ticket #, later follow up once again yields a complete lack of knowledge of what's clearly an outage, whether of just my connection or more widespread. I'm about at the point where next time it goes down and it appears to be a remote issue I'm not going to bother to call it in; I'll just cross my fingers and hope it fixes itself within a day or so and only report it if it doesn't. I don't think my calls today did anything but waste my time. From henson at acm.org Wed Jan 4 08:32:43 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 4 Jan 2017 00:32:43 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: References: <20170104025613.GG3703@bender.cpp.edu> Message-ID: <20170104083242.GI3709@bender.unx.cpp.edu> On Wed, Jan 04, 2017 at 04:01:03AM +0000, Mel Beckman wrote: > If a Frontier tech is on this list, I ask you kindly figure out what > the blasted deal is with your vanishing ticket numbers. This has been > going on for MONTHS! The cynic in me wonders if somebody is trying to artificially inflate their metrics ;). Problems? Who's having problems 8-/? That's interesting though, I wonder if that's what happened to the reference number I was given in the morning that was MIA in the afternoon; it vanished into helpdesk limbo... At least my issue did get somehow fixed so I won't have to call again tomorrow; ah, small favors :). From dovid at telecurve.com Wed Jan 4 11:10:23 2017 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 4 Jan 2017 06:10:23 -0500 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <20170104082856.GH3709@bender.unx.cpp.edu> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: Whenever I call my local ISP with an issue I just make tier1 and tier2 dizzy so they escalate. On Wed, Jan 4, 2017 at 3:28 AM, Paul B. Henson wrote: > On Tue, Jan 03, 2017 at 06:56:13PM -0800, Paul B. Henson wrote: > > > Hopefully it won't be three days this time. > > Well, my FIOS mysteriously came back online about 9:45pm, a bit over 18 > hours after it mysteriously dropped offline. I happened to be in the > wiring closet staring angrily at the ONT about 8:30ish and noticed that > it reset itself 2 or 3 times over the course of about 10 minutes, so I > get the feeling somebody was fiddling with it remotely. I suppose I'll > never really know what was broken or how it ended up being fixed, other > than having about 100% certainty it was on the far side of the fiber. > > It's understandable that equipment breaks, and people misconfigure > things sometimes. What I find insanely frustrating is the complete > disconnect between level 1/2 support and the network engineers that > actually know what's going on. When I called this morning with a > complete outage of my business class FIOS, somebody probably knew it was > down, or at least should have been able to tell it was down. But instead > I get to waste hours of my time going through meaningless > troubleshooting steps because lower level support doesn't have that > information. And then after actually getting an escalation to someone > who confirms an outage and gives me a ticket #, later follow up once > again yields a complete lack of knowledge of what's clearly an outage, > whether of just my connection or more widespread. > > I'm about at the point where next time it goes down and it appears to be > a remote issue I'm not going to bother to call it in; I'll just cross my > fingers and hope it fixes itself within a day or so and only report it > if it doesn't. I don't think my calls today did anything but waste my > time. > From baldur.norddahl at gmail.com Wed Jan 4 12:54:07 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 4 Jan 2017 13:54:07 +0100 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: I solved this issue by making my own ISP. On 04-01-2017 12:10, Dovid Bender wrote: > Whenever I call my local ISP with an issue I just make tier1 and tier2 > dizzy so they escalate. > > > On Wed, Jan 4, 2017 at 3:28 AM, Paul B. Henson wrote: > >> On Tue, Jan 03, 2017 at 06:56:13PM -0800, Paul B. Henson wrote: >> >>> Hopefully it won't be three days this time. >> Well, my FIOS mysteriously came back online about 9:45pm, a bit over 18 >> hours after it mysteriously dropped offline. I happened to be in the >> wiring closet staring angrily at the ONT about 8:30ish and noticed that >> it reset itself 2 or 3 times over the course of about 10 minutes, so I >> get the feeling somebody was fiddling with it remotely. I suppose I'll >> never really know what was broken or how it ended up being fixed, other >> than having about 100% certainty it was on the far side of the fiber. >> >> It's understandable that equipment breaks, and people misconfigure >> things sometimes. What I find insanely frustrating is the complete >> disconnect between level 1/2 support and the network engineers that >> actually know what's going on. When I called this morning with a >> complete outage of my business class FIOS, somebody probably knew it was >> down, or at least should have been able to tell it was down. But instead >> I get to waste hours of my time going through meaningless >> troubleshooting steps because lower level support doesn't have that >> information. And then after actually getting an escalation to someone >> who confirms an outage and gives me a ticket #, later follow up once >> again yields a complete lack of knowledge of what's clearly an outage, >> whether of just my connection or more widespread. >> >> I'm about at the point where next time it goes down and it appears to be >> a remote issue I'm not going to bother to call it in; I'll just cross my >> fingers and hope it fixes itself within a day or so and only report it >> if it doesn't. I don't think my calls today did anything but waste my >> time. >> From jared at puck.nether.net Wed Jan 4 13:37:19 2017 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 4 Jan 2017 08:37:19 -0500 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: > On Jan 4, 2017, at 7:54 AM, Baldur Norddahl wrote: > > I solved this issue by making my own ISP. I?ve been thinking of the same in my underserved area. Labor is $5/foot here and despite friends and colleagues telling me to move, it seems I have a sub-60 month ROI (and sub-year for some areas I?ve modeled with modest uptake rates of 15-20% where the other options are fixed wireless, Cellular data or dial). Hope is to do a presentation in the fall or next year with progress. We have areas around here where Comcast, (AT&T or Frontier) don?t even serve. The municipality is off getting bids to build due to market failure by the incumbents to invest. municipal fiber is nigh on illegal here in Michigan but with no incumbent it is feasible and my hope is will lock out people who are unwilling to invest despite their market cap. - Jared From lguillory at reservetele.com Wed Jan 4 13:50:48 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 4 Jan 2017 13:50:48 +0000 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB029B75@RTC-EXCH01.RESERVE.LDS> Our model is 15k a mile all in, this is for aerial not underground for our HFC/Coax builds. A partner of ours models their underground fiber builds at 30k a mile. This is in south Louisiana so your market may vary as always. Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch Sent: Wednesday, January 04, 2017 7:37 AM To: Baldur Norddahl Cc: nanog at nanog.org Subject: Re: SoCal FIOS outage(?) / static IP readdressing > On Jan 4, 2017, at 7:54 AM, Baldur Norddahl wrote: > > I solved this issue by making my own ISP. I?ve been thinking of the same in my underserved area. Labor is $5/foot here and despite friends and colleagues telling me to move, it seems I have a sub-60 month ROI (and sub-year for some areas I?ve modeled with modest uptake rates of 15-20% where the other options are fixed wireless, Cellular data or dial). Hope is to do a presentation in the fall or next year with progress. We have areas around here where Comcast, (AT&T or Frontier) don?t even serve. The municipality is off getting bids to build due to market failure by the incumbents to invest. municipal fiber is nigh on illegal here in Michigan but with no incumbent it is feasible and my hope is will lock out people who are unwilling to invest despite their market cap. - Jared From shawnl at up.net Wed Jan 4 14:08:51 2017 From: shawnl at up.net (Shawn L) Date: Wed, 4 Jan 2017 09:08:51 -0500 (EST) Subject: =?utf-8?Q?RE=3A_SoCal_FIOS_outage=28=3F=29_=2F_static_IP_readdressing?= In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB029B75@RTC-EXCH01.RESERVE.LDS> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB029B75@RTC-EXCH01.RESERVE.LDS> Message-ID: <1483538931.114312187@upnet.mymailsrvr.com> Depending on the area and conditions (rock, etc). We're seeing $4 /foot Aerial $5-$7 /foot direct bury $10 - $14 /foot directional bore These are not including the fiber cable itself. -----Original Message----- From: "Luke Guillory" Sent: Wednesday, January 4, 2017 8:50am To: "Jared Mauch" , "Baldur Norddahl" Cc: "nanog at nanog.org" Subject: RE: SoCal FIOS outage(?) / static IP readdressing Our model is 15k a mile all in, this is for aerial not underground for our HFC/Coax builds. A partner of ours models their underground fiber builds at 30k a mile. This is in south Louisiana so your market may vary as always. Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch Sent: Wednesday, January 04, 2017 7:37 AM To: Baldur Norddahl Cc: nanog at nanog.org Subject: Re: SoCal FIOS outage(?) / static IP readdressing > On Jan 4, 2017, at 7:54 AM, Baldur Norddahl wrote: > > I solved this issue by making my own ISP. I?ve been thinking of the same in my underserved area. Labor is $5/foot here and despite friends and colleagues telling me to move, it seems I have a sub-60 month ROI (and sub-year for some areas I?ve modeled with modest uptake rates of 15-20% where the other options are fixed wireless, Cellular data or dial). Hope is to do a presentation in the fall or next year with progress. We have areas around here where Comcast, (AT&T or Frontier) don?t even serve. The municipality is off getting bids to build due to market failure by the incumbents to invest. municipal fiber is nigh on illegal here in Michigan but with no incumbent it is feasible and my hope is will lock out people who are unwilling to invest despite their market cap. - Jared From Valdis.Kletnieks at vt.edu Wed Jan 4 14:48:53 2017 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 04 Jan 2017 09:48:53 -0500 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <20170104082856.GH3709@bender.unx.cpp.edu> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: <6598.1483541333@turing-police.cc.vt.edu> On Wed, 04 Jan 2017 00:28:57 -0800, "Paul B. Henson" said: > I'm about at the point where next time it goes down and it appears to be > a remote issue I'm not going to bother to call it in; I'll just cross my > fingers and hope it fixes itself within a day or so and only report it > if it doesn't. I don't think my calls today did anything but waste my > time. Even if nothing else happens, calling in and reporting the problem *does* (or at least it *should*) set the clock running for any SLA-related compensation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dhubbard at dino.hostasaurus.com Wed Jan 4 15:00:46 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 4 Jan 2017 15:00:46 +0000 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <6598.1483541333@turing-police.cc.vt.edu> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <6598.1483541333@turing-police.cc.vt.edu> Message-ID: <23660CEA-1E0C-4515-960E-ABDC3BAB6176@dino.hostasaurus.com> Last 18 hour outage I experienced got me a fantastic half month credit. It cost us more to pay me for the time I spent on hold than the credit was worth, so I no longer call them if we?re down and downdetector shows others in the area are too. We?re in the process of moving the circuit to a backup role, but it?s proving to be a long process getting fiber run to an alternative. David On 1/4/17, 9:48 AM, "nanog-bounces at nanog.org on behalf of Valdis.Kletnieks at vt.edu" wrote: On Wed, 04 Jan 2017 00:28:57 -0800, "Paul B. Henson" said: > I'm about at the point where next time it goes down and it appears to be > a remote issue I'm not going to bother to call it in; I'll just cross my > fingers and hope it fixes itself within a day or so and only report it > if it doesn't. I don't think my calls today did anything but waste my > time. Even if nothing else happens, calling in and reporting the problem *does* (or at least it *should*) set the clock running for any SLA-related compensation. From morrowc.lists at gmail.com Wed Jan 4 16:42:09 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Jan 2017 11:42:09 -0500 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: On Wed, Jan 4, 2017 at 8:37 AM, Jared Mauch wrote: > > > On Jan 4, 2017, at 7:54 AM, Baldur Norddahl > wrote: > > > > I solved this issue by making my own ISP. > > I?ve been thinking of the same in my underserved area. Labor is $5/foot > here and despite friends and colleagues telling me to move, it seems I have > a sub-60 month ROI (and sub-year for some areas I?ve modeled with modest > uptake rates of 15-20% where the other options are fixed wireless, Cellular > data or dial). > > Hope is to do a presentation in the fall or next year with progress. We > have areas around here where Comcast, (AT&T or Frontier) don?t even serve. > The municipality is off getting bids to build due to market failure by the > incumbents to invest. municipal fiber is nigh on illegal here in Michigan > but with no incumbent it is feasible and my hope is will lock out people > who are unwilling to invest despite their market cap. > > and think about it, you could get ipv6 on your network... the OP still doesn't have that native on his fios I bet. From Matthew.Black at csulb.edu Wed Jan 4 17:40:59 2017 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 4 Jan 2017 17:40:59 +0000 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <20170104082856.GH3709@bender.unx.cpp.edu> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: I'm a Frontier FiOS customer in SoCal and have had trouble loading the Google home page for weeks. Had trouble loading Gmail last night. From henson at acm.org Wed Jan 4 21:52:15 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 4 Jan 2017 13:52:15 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <6598.1483541333@turing-police.cc.vt.edu> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <6598.1483541333@turing-police.cc.vt.edu> Message-ID: <05af01d266d4$d0859140$7190b3c0$@acm.org> > From: Valdis.Kletnieks at vt.edu > Sent: Wednesday, January 04, 2017 6:49 AM > > Even if nothing else happens, calling in and reporting the problem *does* > (or at least it *should*) set the clock running for any SLA-related > compensation. I'm pretty sure FIOS doesn't have any contractual SLA's. I suppose if you call and whine enough you might get a billing credit, but as another poster pointed out, it's generally not worth it. From henson at acm.org Wed Jan 4 21:53:49 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 4 Jan 2017 13:53:49 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: <05c701d266d5$085a79a0$190f6ce0$@acm.org> > From: Christopher Morrow > Sent: Wednesday, January 04, 2017 8:42 AM > > and think about it, you could get ipv6 on your network... the OP still > doesn't have that native on his fios I bet. Yeah, sure, pour salt on my still open wound ;). From rvandolson at esri.com Wed Jan 4 21:57:10 2017 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 4 Jan 2017 13:57:10 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <05af01d266d4$d0859140$7190b3c0$@acm.org> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <6598.1483541333@turing-police.cc.vt.edu> <05af01d266d4$d0859140$7190b3c0$@acm.org> Message-ID: <20170104215710.GA16419@esri.com> On Wed, Jan 04, 2017 at 01:52:15PM -0800, Paul B. Henson wrote: > > From: Valdis.Kletnieks at vt.edu > > Sent: Wednesday, January 04, 2017 6:49 AM > > > > Even if nothing else happens, calling in and reporting the problem *does* > > (or at least it *should*) set the clock running for any SLA-related > > compensation. > > I'm pretty sure FIOS doesn't have any contractual SLA's. I suppose if you > call and whine enough you might get a billing credit, but as another poster > pointed out, it's generally not worth it. > Have been evaluating going to more consumerish-grade circuits like this at remote locations, but this scenario is one that has kept me sticking with the more traditional (and more expensive) SLA-bound circuits. Ray From henson at acm.org Wed Jan 4 22:03:31 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 4 Jan 2017 14:03:31 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> Message-ID: <05db01d266d6$637fa570$2a7ef050$@acm.org> > From: Matthew Black > Sent: Wednesday, January 04, 2017 9:41 AM > > I'm a Frontier FiOS customer in SoCal and have had trouble loading the > Google home page for weeks. Had trouble loading Gmail last night. When it's up, I rarely have connectivity issues. Of course, I have business class fios and only use their pipe; I run my own DNS and other services, I don't know specifically what is causing your issue.. In the eight months since the cutover, I had some intermittent connectivity issues during the week of the cutover itself, one three-day complete outage pretty much identical to this 18 hour outage, and maybe two or three times I can recall having issues getting to some piece of the Internet which may or may not have been a Frontier problem. I'd say overall I'm pretty happy with it when it's working. My main complaint is that when it stops working I drop into a complete vacuum of helplessness where I am unable to speak to anybody who can actually diagnose and rectify whatever the underlying failure is which is preventing it from working. That and it's ridiculous not to have native IPv6 for business class Internet at this point. From morrowc.lists at gmail.com Wed Jan 4 22:16:43 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Jan 2017 17:16:43 -0500 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <05c701d266d5$085a79a0$190f6ce0$@acm.org> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <05c701d266d5$085a79a0$190f6ce0$@acm.org> Message-ID: On Wed, Jan 4, 2017 at 4:53 PM, Paul B. Henson wrote: > > From: Christopher Morrow > > Sent: Wednesday, January 04, 2017 8:42 AM > > > > and think about it, you could get ipv6 on your network... the OP still > > doesn't have that native on his fios I bet. > > Yeah, sure, pour salt on my still open wound ;). > > maybe now would be a good time to ask your vz rep about this 'feature'? From henson at acm.org Thu Jan 5 00:51:26 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 4 Jan 2017 16:51:26 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <20170104215710.GA16419@esri.com> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <6598.1483541333@turing-police.cc.vt.edu> <05af01d266d4$d0859140$7190b3c0$@acm.org> <20170104215710.GA16419@esri.com> Message-ID: <20170105005125.GJ3709@bender.unx.cpp.edu> On Wed, Jan 04, 2017 at 01:57:10PM -0800, Ray Van Dolson wrote: > Have been evaluating going to more consumerish-grade circuits like this > at remote locations, but this scenario is one that has kept me sticking > with the more traditional (and more expensive) SLA-bound circuits. I'd call my business FIOS "prosumer" ;). Honestly, I'm not sure why you'd get business FIOS over residential FIOS if you don't need static IP addresses, at least if you're at an address where both are available. I pay $125/month for 50/50 with 5 statics, which serves my household and my IT consulting home office. I don't think my budget could cover "more expensive" SLA-bound circuits :). I looked into whether I could get same speed lower cost or higher speed same cost after the Frontier cutover, but I'm afraid all I have to look forward to is same speed higher cost when my current two year legacy Verizon contract expires :(. Maybe I should move to Texas - Google business fiber 250/250 for $100/month, with 13 statics for some additional cost I can't find documented. Plus IPv6. Be nice to have some last mile competition around here. LA is on their "some day" list, but who knows what that means geographically plus they've pretty much stopped expanding and switched to wireless 8-/. From henson at acm.org Thu Jan 5 00:52:36 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 4 Jan 2017 16:52:36 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <05c701d266d5$085a79a0$190f6ce0$@acm.org> Message-ID: <20170105005235.GK3709@bender.unx.cpp.edu> On Wed, Jan 04, 2017 at 05:16:43PM -0500, Christopher Morrow wrote: > maybe now would be a good time to ask your vz rep about this 'feature'? Hah. I asked Frontier right after the cutover and got the same Verizon smoke "Currently in the planning stages with no firm timeline for deployment." From tim at baseworx.net Fri Jan 6 00:30:23 2017 From: tim at baseworx.net (Tim McKee) Date: Fri, 6 Jan 2017 00:30:23 +0000 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <20161229214731.BB4AECC@m0087797.ppops.net> References: <20161229214731.BB4AECC@m0087797.ppops.net> Message-ID: <1483662623.28358.25.camel@baseworx.net> Try times between Rio (Brasil) and Eastern US... depending on the date there are 4 different possible offsets... On Thu, 2016-12-29 at 21:47 -0800, Scott Weeks wrote: :: 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 From jason.iannone at gmail.com Fri Jan 6 15:25:32 2017 From: jason.iannone at gmail.com (Jason Iannone) Date: Fri, 6 Jan 2017 08:25:32 -0700 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: Message-ID: Hey Chris, Size has a lot to do with policy. For very large organizations, regional models make sense. Orwell had his regional divisions[1] and Level3 has theirs[2]. TW had a domestic version of regions before things were centralized. I'd argue for the organizational affect of standardization. Is operations centralized? Deployments should be standardized. Is operations distributed? Deployments should be centralized to those operational distributions. Do you have the resources to centralize? Technology research and acquisitions teams are expensive. Engineering teams are expensive. Operations teams are generally cheaper per unit, but one of the largest teams and therefore expensive. The bureaucracy supports whatever model you're after in a top-down way for the proverbial 80%. So many networks grow organically until operations break down and leadership implements centralized policy. Centralizing operations and empowering the Ops team's voice is an effective way to get to a more standardized environment. When Ops bucks and won't support clever (read: retarded) stuff and they have strong leadership to support them, things have to change. Rather than standardizing on a vendor, I support standardized deployments. Deployment X gets bill of materials Y. A significant assumption supporting this model includes well known variables that distinguish one deployment type from another, defined by centralized technology research, acquisitions, and engineering teams. Jason [1]https://en.wikipedia.org/wiki/Nations_of_Nineteen_Eighty-Four#/media/File:1984_fictitious_world_map_v2_quad.svg [2]http://www.level3.com/en/global-reach/ On Fri, Dec 23, 2016 at 1:36 PM, Chris Grundemann wrote: > Hail NANOGers! > > A global hospitality organization with 100+ locations recently asked us how > to weigh the importance of standardizing infrastructure across all their > locations versus allowing each international location to select on their > own kit. > > My first instinct was to jump on my favorite search engine and look for an > authoritative document covering the topic. To my surprise I have not been > able to find such a thing. So I've begun to write one myself, and as I > start I've realized that: > a) This is likely to be a document that will be helpful to the wider > community, and > b) This is likely a topic that many of you have a great deal of knowledge > and personal experience. > > If you have pointers to an existing doc, please share. > > If you have a case study, lesson learned, data point, or even just a strong > opinion; I'd love to hear it! > > My intention is to put this together BCOP style, but with more of a focus > on why rather than how this time around. Feel free to reply on or off list. > > Thanks in advance for your input! > > Cheers, > ~Chris > > PS - I won't use any direct quotes without advance permission and I'll > provide attribution to all that contribute meaningfully. > > -- > @ChrisGrundemann > http://chrisgrundemann.com From bicknell at ufp.org Fri Jan 6 16:21:53 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 6 Jan 2017 08:21:53 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <20170105005125.GJ3709@bender.unx.cpp.edu> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <6598.1483541333@turing-police.cc.vt.edu> <05af01d266d4$d0859140$7190b3c0$@acm.org> <20170104215710.GA16419@esri.com> <20170105005125.GJ3709@bender.unx.cpp.edu> Message-ID: <20170106162153.GA80335@ussenterprise.ufp.org> In a message written on Wed, Jan 04, 2017 at 04:51:26PM -0800, Paul B. Henson wrote: > I'd call my business FIOS "prosumer" ;). Honestly, I'm not sure why > you'd get business FIOS over residential FIOS if you don't need static > IP addresses, at least if you're at an address where both are available. I can't speak to Verizon, but I can speak to Comcast. At a past address I had Comcast Business (cable modem) service at a residential address, and then later downgraded it to Comcast Residential service. The similarities: - Both used the exact same cable coming into the house. - Both offered the same speeds. - Both offered static IP's for an additional fee. - Both clearly used the same routers, backbone, peering, etc. The differences I could see: - Cable Modem - Residential: could rent a consumer grade or BYO (I did, a good one) - Business: Comcast supplied and required their better-than-average, modem. It could be in bridge mode though. - Support - Residential: 0-30 minutes on hold, the one dispatch when I needed a truck roll took ~24 hours. - Business: 0-2 minutes on hold, I had two dispatches one where the truck arrived within 30 minutes, the other in about 2 hours. - Cost (At the time) - Residential: $75/month. - Business Class: $90/month. - Data Caps: - Residential: 250GB/month. - Business: None (with two paragraphs of disclaimer) Differences I could not see/verify: - Cable Modem Channel Selection - I'm told in some cases business class cable modems get different DOCSYS channels which have less congestion than typical residential channels. This of course varies greatly market to market, and is also dependent on the number of both resi and business subs on the segment. - Packet prioritization. - I'm told that business class packets are given somewhat higher priority (QoS) in the network. I could find no way to verify this, and generally had no packet loss issues inside the Comcast network with either service. Ultimately the reason to buy business class at a residential address (and I think the Prosumer description is correct) is generally faster repair times. On congested segments it may also result in slightly lesser packet loss. Maybe, depending on how caps are done, it could be worth while if you move a lot of data. Obviously if these differences are worth the delta in price depends on your situation and the exact delta in your location. At the time I had this I was working from home, so the extra $15/month insurance that I could do my job was money well spent. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From cscora at apnic.net Fri Jan 6 18:01:52 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Jan 2017 04:01:52 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170106180152.87AA9A2AEA@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 Jan, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 626575 Prefixes after maximum aggregation (per Origin AS): 221563 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 304704 Total ASes present in the Internet Routing Table: 55519 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 36265 Origin ASes announcing only one prefix: 15204 Transit ASes present in the Internet Routing Table: 6530 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 55 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 48 Unregistered ASNs in the Routing Table: 16 Number of 32-bit ASNs allocated by the RIRs: 16772 Number of 32-bit ASNs visible in the Routing Table: 12724 Prefixes from 32-bit ASNs in the Routing Table: 52257 Number of bogon 32-bit ASNs visible in the Routing Table: 704 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 386 Number of addresses announced to Internet: 2834813668 Equivalent to 168 /8s, 247 /16s and 210 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 207505 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156622 Total APNIC prefixes after maximum aggregation: 43098 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 171162 Unique aggregates announced from the APNIC address blocks: 70912 APNIC Region origin ASes present in the Internet Routing Table: 5189 APNIC Prefixes per ASN: 32.99 APNIC Region origin ASes announcing only one prefix: 1132 APNIC Region transit ASes present in the Internet Routing Table: 936 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 55 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2587 Number of APNIC addresses announced to Internet: 761626756 Equivalent to 45 /8s, 101 /16s and 128 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188103 Total ARIN prefixes after maximum aggregation: 89331 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195094 Unique aggregates announced from the ARIN address blocks: 89572 ARIN Region origin ASes present in the Internet Routing Table: 16073 ARIN Prefixes per ASN: 12.14 ARIN Region origin ASes announcing only one prefix: 5600 ARIN Region transit ASes present in the Internet Routing Table: 1706 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1688 Number of ARIN addresses announced to Internet: 1106782624 Equivalent to 65 /8s, 248 /16s and 41 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 150470 Total RIPE prefixes after maximum aggregation: 73223 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 161913 Unique aggregates announced from the RIPE address blocks: 99119 RIPE Region origin ASes present in the Internet Routing Table: 18144 RIPE Prefixes per ASN: 8.92 RIPE Region origin ASes announcing only one prefix: 7747 RIPE Region transit ASes present in the Internet Routing Table: 3048 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5101 Number of RIPE addresses announced to Internet: 709454464 Equivalent to 42 /8s, 73 /16s and 106 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 63697 Total LACNIC prefixes after maximum aggregation: 12613 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 80284 Unique aggregates announced from the LACNIC address blocks: 38029 LACNIC Region origin ASes present in the Internet Routing Table: 2480 LACNIC Prefixes per ASN: 32.37 LACNIC Region origin ASes announcing only one prefix: 551 LACNIC Region transit ASes present in the Internet Routing Table: 595 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3065 Number of LACNIC addresses announced to Internet: 170930496 Equivalent to 10 /8s, 48 /16s and 49 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15377 Total AfriNIC prefixes after maximum aggregation: 3291 AfriNIC Deaggregation factor: 4.67 Prefixes being announced from the AfriNIC address blocks: 17736 Unique aggregates announced from the AfriNIC address blocks: 6718 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 24.10 AfriNIC Region origin ASes announcing only one prefix: 174 AfriNIC Region transit ASes present in the Internet Routing Table: 181 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 283 Number of AfriNIC addresses announced to Internet: 85555712 Equivalent to 5 /8s, 25 /16s and 122 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3717 390 252 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2989 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2720 11133 741 KIXS-AS-KR Korea Telecom, KR 9829 2678 1497 543 BSNL-NIB National Internet Backbone, IN 9808 2281 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2047 428 217 TATACOMM-AS TATA Communications formerl 45899 1751 1265 100 VNPT-AS-VN VNPT Corp, VN 4808 1628 1792 459 CHINA169-BJ China Unicom Beijing Provin 24560 1559 562 243 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3611 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3239 1333 82 SHAW - Shaw Communications Inc., CA 18566 2195 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1957 2021 402 CHARTER-NET-HKY-NC - Charter Communicat 30036 1745 328 405 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1730 5066 642 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1678 848 227 ITCDELTA - Earthlink, Inc., US 701 1599 10629 661 UUNET - MCI Communications Services, In 16509 1526 3029 522 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3141 163 17 ALJAWWALSTC-AS , SA 20940 2969 1115 2113 AKAMAI-ASN1 , US 9121 2243 1706 92 TTNET , TR 34984 1990 327 375 TELLCOM-AS , TR 13188 1603 99 61 TRIOLAN , UA 12479 1422 1033 51 UNI2-AS , ES 6849 1312 355 22 UKRTELNET , UA 8551 1206 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 8402 1112 544 15 CORBINA-AS OJSC "Vimpelcom", RU 12389 996 1156 445 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3531 544 178 Telmex Colombia S.A., CO 8151 2476 3370 552 Uninet S.A. de C.V., MX 11830 1799 368 66 Instituto Costarricense de Electricidad 6503 1544 437 54 Axtel, S.A.B. de C.V., MX 7303 1523 974 252 Telecom Argentina S.A., AR 6147 1355 377 27 Telefonica del Peru S.A.A., PE 28573 1056 2271 177 CLARO S.A., BR 3816 1009 479 181 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 914 126 78 Alestra, S. de R.L. de C.V., MX 18881 879 1036 22 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1284 398 42 LINKdotNET-AS, EG 36903 687 345 122 MT-MPLS, MA 37611 676 67 6 Afrihost, ZA 36992 579 1373 25 ETISALAT-MISR, EG 24835 492 658 16 RAYA-AS, EG 8452 488 1474 16 TE-AS TE-AS, EG 37492 400 290 74 ORANGE-TN, TN 29571 368 36 10 CITelecom-AS, CI 15399 314 35 6 WANANCHI-KE, KE 2018 285 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3717 390 252 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3611 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3531 544 178 Telmex Colombia S.A., CO 6327 3239 1333 82 SHAW - Shaw Communications Inc., CA 39891 3141 163 17 ALJAWWALSTC-AS , SA 17974 2989 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2969 1115 2113 AKAMAI-ASN1 , US 4766 2720 11133 741 KIXS-AS-KR Korea Telecom, KR 9829 2678 1497 543 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3717 3465 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3611 3460 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3531 3353 Telmex Colombia S.A., CO 6327 3239 3157 SHAW - Shaw Communications Inc., CA 39891 3141 3124 ALJAWWALSTC-AS , SA 17974 2989 2918 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2281 2248 CMNET-GD Guangdong Mobile Communication 9121 2243 2151 TTNET , TR 9829 2678 2135 BSNL-NIB National Internet Backbone, IN 18566 2195 2086 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom 65001 PRIVATE 94.242.128.0/20 15468 KLGELECS-AS 38, Teatralnaya st Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:530 /14:1047 /15:1802 /16:13173 /17:7798 /18:13014 /19:25218 /20:38072 /21:40573 /22:73058 /23:61388 /24:349130 /25:543 /26:403 /27:287 /28:33 /29:18 /30:17 /31:0 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3035 3239 SHAW - Shaw Communications Inc., CA 39891 2896 3141 ALJAWWALSTC-AS , SA 22773 2812 3611 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2088 2195 MEGAPATH5-US - MegaPath Corporation, US 9121 1571 2243 TTNET , TR 30036 1555 1745 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1448 3531 Telmex Colombia S.A., CO 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1348 1603 TRIOLAN , UA 6983 1323 1678 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1588 2:813 4:23 5:2440 6:32 8:1023 12:1809 13:67 14:1784 15:25 16:2 17:106 18:128 19:1 20:51 23:2017 24:1802 27:2389 31:1841 32:83 33:11 34:1 35:3 36:378 37:2480 38:1295 39:44 40:99 41:2937 42:451 43:1911 44:53 45:2299 46:2550 47:120 49:1201 50:952 51:16 52:617 54:355 55:7 56:4 57:40 58:1600 59:975 60:388 61:1863 62:1503 63:1922 64:4539 65:2190 66:4398 67:2211 68:1161 69:3296 70:1302 71:560 72:2061 74:2593 75:403 76:417 77:1419 78:1558 79:921 80:1361 81:1420 82:961 83:720 84:861 85:1688 86:485 87:1129 88:773 89:2041 90:196 91:6094 92:947 93:2368 94:2348 95:2736 96:566 97:359 98:939 99:94 100:148 101:1205 103:13161 104:2629 105:146 106:471 107:1504 108:766 109:2543 110:1278 111:1660 112:1139 113:1181 114:1004 115:1640 116:1685 117:1592 118:2124 119:1585 120:943 121:1074 122:2263 123:1993 124:1586 125:1843 128:719 129:501 130:422 131:1384 132:584 133:187 134:515 135:210 136:382 137:395 138:1812 139:483 140:616 141:475 142:724 143:907 144:758 145:168 146:966 147:644 148:1402 149:560 150:688 151:797 152:704 153:312 154:725 155:955 156:545 157:558 158:427 159:1346 160:565 161:735 162:2454 163:534 164:776 165:1139 166:362 167:1235 168:2451 169:721 170:2502 171:261 172:887 173:1826 174:783 175:714 176:1753 177:4120 178:2422 179:1110 180:2075 181:1962 182:2173 183:1015 184:834 185:8397 186:3201 187:2257 188:2334 189:1767 190:7970 191:1296 192:9294 193:5764 194:4559 195:3859 196:1865 197:1245 198:5598 199:5794 200:7228 201:4123 202:10153 203:9814 204:4461 205:2767 206:2957 207:3151 208:3994 209:3910 210:3902 211:2083 212:2783 213:2450 214:854 215:65 216:5778 217:1973 218:824 219:602 220:1669 221:893 222:723 223:1116 End of report From Chris.Balmain at connectivityit.com.au Fri Jan 6 01:37:05 2017 From: Chris.Balmain at connectivityit.com.au (Chris Balmain) Date: Fri, 6 Jan 2017 01:37:05 +0000 Subject: NOC contact at IX Reach AS43531 Message-ID: <09bd21ee4e3c4565bb3c18fc3d6a566c@connectivityit.com.au> Hi all, Sorry for the noise - just after a NOC contact at AS43531 if there are any on-list. We're observing a routing issue at Equinix IX Silicon Valley, and need some insight from their side. Emails to NOC have gone unresponded to for a few days... Regards, Chris From owen at delong.com Fri Jan 6 19:55:56 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Jan 2017 11:55:56 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <20170106162153.GA80335@ussenterprise.ufp.org> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <6598.1483541333@turing-police.cc.vt.edu> <05af01d266d4$d0859140$7190b3c0$@acm.org> <20170104215710.GA16419@esri.com> <20170105005125.GJ3709@bender.unx.cpp.edu> <20170106162153.GA80335@ussenterprise.ufp.org> Message-ID: <1F1DFFB8-C849-4205-A516-00DC6C17A8BD@delong.com> > On Jan 6, 2017, at 08:21 , Leo Bicknell wrote: > > In a message written on Wed, Jan 04, 2017 at 04:51:26PM -0800, Paul B. Henson wrote: >> I'd call my business FIOS "prosumer" ;). Honestly, I'm not sure why >> you'd get business FIOS over residential FIOS if you don't need static >> IP addresses, at least if you're at an address where both are available. > > I can't speak to Verizon, but I can speak to Comcast. > > At a past address I had Comcast Business (cable modem) service at > a residential address, and then later downgraded it to Comcast > Residential service. > > The similarities: > - Both used the exact same cable coming into the house. > - Both offered the same speeds. > - Both offered static IP's for an additional fee. ? Not available in San Jose on residential service. If you want static, must go business here. > - Both clearly used the same routers, backbone, peering, etc. > > The differences I could see: > - Cable Modem > - Residential: could rent a consumer grade or BYO (I did, a good one) > - Business: Comcast supplied and required their better-than-average, > modem. It could be in bridge mode though. - San Jose, I was able to use BYO. Had to escalate several levels and pull several teeth to get bridge mode on the Comcast unit while I had it. > - Support > - Residential: 0-30 minutes on hold, the one dispatch when I needed > a truck roll took ~24 hours. > - Business: 0-2 minutes on hold, I had two dispatches one where the > truck arrived within 30 minutes, the other in about 2 > hours. > - Cost (At the time) > - Residential: $75/month. > - Business Class: $90/month. - San Jose, Residential and business both about $90/month. Difference is that Residential includes Television in that price. > - Data Caps: > - Residential: 250GB/month. - San Jose, I just received a notice indicating that they were just now instituting a 500GB/month limit on my service. Prior to that, no documented cap. I don?t think I?ve tried to move more than 1/2 a terabyte in any month, so I don?t know if there was an undocumented cap or not. > - Business: None (with two paragraphs of disclaimer) > One other visible difference: - Residential: One mac address only, 15 minutes to reset DHCP server if changing MAC address - Business: Multiple mac addresses supported > Differences I could not see/verify: > - Cable Modem Channel Selection > - I'm told in some cases business class cable modems get different > DOCSYS channels which have less congestion than typical > residential channels. This of course varies greatly market to > market, and is also dependent on the number of both resi and > business subs on the segment. > - Packet prioritization. > - I'm told that business class packets are given somewhat higher > priority (QoS) in the network. I could find no way to verify > this, and generally had no packet loss issues inside the Comcast > network with either service. > > Ultimately the reason to buy business class at a residential address > (and I think the Prosumer description is correct) is generally faster > repair times. On congested segments it may also result in slightly > lesser packet loss. Maybe, depending on how caps are done, it could be > worth while if you move a lot of data. In my case, I started residential and it was abysmal. There were so many problems and multiple truck rolls did not resolve anything. Finally, I resorted to business class in desperation (My choices here for any bandwidth >1.5Mbps/384k are Comcast, Comcast, or Comcast). Within a few days of installation, 3-4 truck-rolls later, I had about 3 months of free service in credits and working service that was stable for years. Later I downgraded back to residential and it seems that having gotten the neighborhood equipment up to business class standards has resolved the issues and things continue to be reliable. > Obviously if these differences are worth the delta in price depends on > your situation and the exact delta in your location. At the time I had > this I was working from home, so the extra $15/month insurance that I > could do my job was money well spent. The delta may be more variable than you describe as well. If you?re only looking at internet, then it?s about $15 or maybe even $0 in some cases (It was actually cheaper at one point to buy a la carte business class internet than residential here). However, if you add TV, then the double-play residential price is almost always such that your internet service price a la carte is roughly equal to double-play price for both on residential. They don?t offer double-play business pricing in my area and, in fact, refused to sell me business class TV service in a residential unit. When I was running business class internet, I was paying about $60 for TV and $90 for business class internet, so it was $150 vs. $90. For me, it was worth even that much larger differential at the time because at least the service worked and at least I could get them to fix things when it didn?t. To me, that was the single largest differentiator for business vs. residential service. OTOH, this was in the years when Comcast was consistently winning the most hated company in America award, so I believe there have been some significant improvements in their residential service since then. (Though I still wouldn?t call myself a ?happy? customer so much as one that is quite a bit less angry.) I?d still like to get a real internet provider here, or better yet, more than one that offered real bandwidth over fiber. Owen From rstory at tislabs.com Fri Jan 6 20:45:18 2017 From: rstory at tislabs.com (Robert Story) Date: Fri, 6 Jan 2017 15:45:18 -0500 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <1F1DFFB8-C849-4205-A516-00DC6C17A8BD@delong.com> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <6598.1483541333@turing-police.cc.vt.edu> <05af01d266d4$d0859140$7190b3c0$@acm.org> <20170104215710.GA16419@esri.com> <20170105005125.GJ3709@bender.unx.cpp.edu> <20170106162153.GA80335@ussenterprise.ufp.org> <1F1DFFB8-C849-4205-A516-00DC6C17A8BD@delong.com> Message-ID: <20170106154518.6e5a379a@ispx.vb.futz.org> On Fri, 6 Jan 2017 11:55:56 -0800 Owen wrote: OD> > On Jan 6, 2017, at 08:21 , Leo Bicknell wrote: OD> > At a past address I had Comcast Business (cable modem) service at OD> > a residential address, and then later downgraded it to Comcast OD> > Residential service. OD> > [...] OD> > The differences I could see: OD> > - Cable Modem OD> > - Residential: could rent a consumer grade or BYO (I did, a good one) OD> > - Business: Comcast supplied and required their better-than-average, OD> > modem. It could be in bridge mode though. OD> - San Jose, I was able to use BYO. Had to escalate several levels and pull several teeth to get OD> bridge mode on the Comcast unit while I had it. I'm using BYO on business class in Atlanta. I thing that a static IP requires that you use their modem. I'm happy with DHCP - my assigned IP hasn't changed in years. And as you say, I can plug in multiple boxes and each get's its own public IPv4 address. OD> > Ultimately the reason to buy business class at a residential address OD> > (and I think the Prosumer description is correct) is generally faster OD> > repair times. That's why I have it. Though if you BYOM, you'll likely have trouble getting service as they'll blame it on your 'unspoorted' device (even thought it's listed on supported devices page). I had to rent one of their modems for about 3 months once while they struggled to find something in the neighborhood with a flaky power supply that caused intermittent outages. Robert -- Senior Software Engineer @ Parsons -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From bicknell at ufp.org Fri Jan 6 22:20:32 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 6 Jan 2017 14:20:32 -0800 Subject: SoCal FIOS outage(?) / static IP readdressing In-Reply-To: <1F1DFFB8-C849-4205-A516-00DC6C17A8BD@delong.com> References: <20170104025613.GG3703@bender.cpp.edu> <20170104082856.GH3709@bender.unx.cpp.edu> <6598.1483541333@turing-police.cc.vt.edu> <05af01d266d4$d0859140$7190b3c0$@acm.org> <20170104215710.GA16419@esri.com> <20170105005125.GJ3709@bender.unx.cpp.edu> <20170106162153.GA80335@ussenterprise.ufp.org> <1F1DFFB8-C849-4205-A516-00DC6C17A8BD@delong.com> Message-ID: <20170106222032.GA89689@ussenterprise.ufp.org> It is interesting to see the differences. For instance to put my unit in bridge mode I just logged into it, said bridge mode, and rebooted it. That method was actually documented in their business class FAQ. I'm sure there are great differences in plant and capabilities. There's a lot of M&A history and a lot of historical reasons, good and bad. In a message written on Fri, Jan 06, 2017 at 11:55:56AM -0800, Owen DeLong wrote: > They don?t offer double-play business pricing in my area and, in fact, > refused to sell me business class TV service in a residential unit. When On some of the issues like this I wonder if the reason is regulatory. In the two areas I've checked there is double play business pricing. In one of them they offered business class TV at residential, or at least the rep tried to sell it to me. Its the sort of thing that just feels like a regulator issue to me. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From ryan.m.stephenson2.civ at mail.mil Fri Jan 6 21:15:33 2017 From: ryan.m.stephenson2.civ at mail.mil (Stephenson, Ryan M CIV DISA IE (US)) Date: Fri, 6 Jan 2017 21:15:33 +0000 Subject: Distributed Object Architecture versus DNS Message-ID: <17256A258438E7498D297EB402C8A2577D5E46A9@UCOLHPUG.easf.csd.disa.mil> Does anyone have any information about DOA versus DNS. Any ideas about security with DOA is better than DNS. Maybe pros and cons of DOA versus DNS? Matt Lewis -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5587 bytes Desc: not available URL: From kyle at neocities.org Fri Jan 6 22:27:02 2017 From: kyle at neocities.org (Kyle Drake) Date: Fri, 6 Jan 2017 22:27:02 +0000 Subject: FTC sues D-Link over router and camera security flaws Message-ID: <0101015975e47182-657219e5-8e49-4803-9fe1-5d9fb1b84d57-000000@us-west-2.amazonses.com> https://www.consumer.ftc.gov/blog/ftc-sues-d-link-over-router-and-camera-security-flaws That escalated quickly... -- Kyle Drake Neocities.org From rdobbins at arbor.net Sat Jan 7 01:24:36 2017 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 7 Jan 2017 08:24:36 +0700 Subject: Distributed Object Architecture versus DNS In-Reply-To: <17256A258438E7498D297EB402C8A2577D5E46A9@UCOLHPUG.easf.csd.disa.mil> References: <17256A258438E7498D297EB402C8A2577D5E46A9@UCOLHPUG.easf.csd.disa.mil> Message-ID: <41006BFC-011D-4164-9E04-F04814B86E1F@arbor.net> On 7 Jan 2017, at 4:15, Stephenson, Ryan M CIV DISA IE (US) wrote: > Does anyone have any information about DOA versus DNS. My understanding of 'DOA' is that it's a general category of software architecture (think CORBA) and nothing to do with name resolution or any sort of directory services, per se. Can you provide more context? ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sat Jan 7 06:48:32 2017 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 7 Jan 2017 13:48:32 +0700 Subject: Distributed Object Architecture versus DNS In-Reply-To: References: <17256A258438E7498D297EB402C8A2577D5E46A9@UCOLHPUG.easf.csd.disa.mil> <41006BFC-011D-4164-9E04-F04814B86E1F@arbor.net> Message-ID: On 7 Jan 2017, at 10:15, Joly MacFie wrote: > They are worried (as I understand it) 1) that it could be an ITU end > run to grab back numbering, 2) it could be abused by bad actors such > as repressive governments who want to use it for digital id. Based on seemingly cyclical statements of this nature, I've been waiting for the ITU to impose GOSIP or whatever on us for the last ~30 years or so - but so far, nothing much has happened in that regard. Is there actually a reason to suspect that this time it will be any different? ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sat Jan 7 07:47:41 2017 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 7 Jan 2017 14:47:41 +0700 Subject: Distributed Object Architecture versus DNS In-Reply-To: References: <17256A258438E7498D297EB402C8A2577D5E46A9@UCOLHPUG.easf.csd.disa.mil> <41006BFC-011D-4164-9E04-F04814B86E1F@arbor.net> Message-ID: On 7 Jan 2017, at 14:22, Joly MacFie wrote: > Blind backlash from IoT DDoS? Looming billions of rf tagged items?? None of this has anything to do with this 'DOA' thing, though. ----------------------------------- Roland Dobbins From gih at apnic.net Sat Jan 7 19:55:44 2017 From: gih at apnic.net (Geoff Huston) Date: Sun, 8 Jan 2017 06:55:44 +1100 Subject: Call For Presentations - DNS-OARC Workship 26, Madrid, 14-15 May 2017 Message-ID: <3988ACCD-C2C1-410F-9B9D-ED30A0CA04D7@apnic.net> [with apologies to those who see this on multiple lists] Call For Presentations The DNS-OARC 26th Workshop will take place in Madrid, Spain on May 14th and 15th 2017, the Sunday and Monday following the ICANN GDD Industry Summit 2017. The Workshop's Program Committee is now requesting proposals for presentations. This workshop intends to build from previous strong DNS-OARC workshops, where both operational content and research are welcome. All DNS-related subjects are welcome. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. A timeslot will be available for lightning talks (5-10 minutes) on Monday May 15th, for which submissions will be accepted during May 14th on a first-come first-served basis. Workshop Milestones: 6th January 2017, Call for Presentations posted and open for submissions 24th February 2017, Deadline for submission 17th March 2017, Draft Programme published 14th April 2017, Final Program published 28th April 2017, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/26/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Ray Bellis, for the OARC Programme Committee OARC depends on sponorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) From president at isoc-ny.org Sat Jan 7 03:15:04 2017 From: president at isoc-ny.org (Joly MacFie) Date: Fri, 6 Jan 2017 22:15:04 -0500 Subject: Distributed Object Architecture versus DNS In-Reply-To: <41006BFC-011D-4164-9E04-F04814B86E1F@arbor.net> References: <17256A258438E7498D297EB402C8A2577D5E46A9@UCOLHPUG.easf.csd.disa.mil> <41006BFC-011D-4164-9E04-F04814B86E1F@arbor.net> Message-ID: ?Oops, just replied to this on the wrong thread. Here it is again: ?ISOC released an info paper, back in October ahead of the ITU WTSA https://www.internetsociety.org/doc/overview-digital-object-architecture-doa They are worried (as I understand it) 1) that it could be an ITU end run to grab back numbering, 2) it could be abused by bad actors such as repressive governments who want to use it for digital id. Post WTSA there was this : Digital Object Architecture (DOA) WTSA-16 received 10 (ten) resolutions ranging from smart cities, combating counterfeit devices and cybersecurity to e-health, IoT that explicitly and implicitly referenced the DOA. Political momentum quickly grew around the DOA as some member states appeared to seek to alter the ITU?s technology neutral stance by selecting the DOA as the solution for a number of issues, including IoT. Agreement was reached to either replace DOA references with Recommendation ITU-T X.1255 (which is based on the DOA) or remove them entirely from the relevant resolutions if agreed text on identity management would be reflected in the summary record of the proceedings. The compromise text was a follows: ?*the Plenary recognized that identity management plays an important role in many telecommunications/ICT services and that it can be implemented using a range of technologies and solutions.*? We should expect prolonged debates as DOA has survived with a variety of hooks in Resolutions and Recommendations that will carry into Plenipotentiary 2018. It will be important for governments to consider interoperability, stability, security and scalability (at Internet scale) capabilities of any technologies that are deployed on the Internet to ensure that the Internet continues to remain secure and stable. -- Joly MacFie President - Internet Society New York Chapter (ISOC-NY) http://isoc-ny.org 218 565 9365 From president at isoc-ny.org Sat Jan 7 07:22:02 2017 From: president at isoc-ny.org (Joly MacFie) Date: Sat, 7 Jan 2017 02:22:02 -0500 Subject: Distributed Object Architecture versus DNS In-Reply-To: References: <17256A258438E7498D297EB402C8A2577D5E46A9@UCOLHPUG.easf.csd.disa.mil> <41006BFC-011D-4164-9E04-F04814B86E1F@arbor.net> Message-ID: On Sat, Jan 7, 2017 at 1:48 AM, Roland Dobbins wrote: > Is there actually a reason to suspect that this time it will be any > different? Blind backlash from IoT DDoS? Looming billions of rf tagged items?? -- Joly MacFie President - Internet Society New York Chapter (ISOC-NY) http://isoc-ny.org 218 565 9365 From rekordmeister at gmail.com Mon Jan 9 14:45:29 2017 From: rekordmeister at gmail.com (MKS) Date: Mon, 9 Jan 2017 14:45:29 +0000 Subject: PSN download speeds Message-ID: Hello I have been testing the download speed from PS4 store, downloading game demos etc. So far I have seen content coming from cloudfront.net, llnw.net and level3 Does someone know if the PlayStation/Sony has contracts with all these CDNs (and perhaps more) or if it's the publishers that choose/handle the distribution of files? So far i'm only getting download speeds of 10-20mbps even though i'm on a 100mbps connection, so downloading a 8Gbps file take too long. Are the PS4 downloads generally rate-limited or am I just unlucky? Regards MKS From A.L.M.Buxey at lboro.ac.uk Mon Jan 9 15:04:31 2017 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 9 Jan 2017 15:04:31 +0000 Subject: PSN download speeds In-Reply-To: References: Message-ID: <20170109150431.GA9611@lboro.ac.uk> Hi, really not the right place for this... however, its pretty well documented elsewhere, eg https://www.reddit.com/r/PS4/comments/5drvcc/an_update_on_psn_download_speeds/ alan From colton.conor at gmail.com Mon Jan 9 15:11:47 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 9 Jan 2017 09:11:47 -0600 Subject: Bonded VDSL2 / ADSL2+ Modems with 4 or more lines bonded Message-ID: What options are out there to bond 4 or more DSL lines together? I know Positron has a 4 and 8 pair VDSL2 modem http://www.positronaccess.com/AK626LC.php Adtran has a 8 port VDSL2 modem https://portal.adtran.com/web/page/portal/Adtran/product/1172868F1/470 and an Adtran 12 port ADSL2+ modem https://portal.adtran.com/web/page/portal/Adtran/product/1172850G1/470 Actelis has a 8 pair VDS2 Modem: http://actelis.com/actelis-products/ethernet-access-devices/ml700/ Is there anyone else out there? The problem with all these solutions is they each cost over $1000, which is a lot considering 2 port bonded VDSL2 modems are in the $75-150 range. I know demand for these products is low, but still hoping there is an OEM version. From mianosm at gmail.com Mon Jan 9 16:01:25 2017 From: mianosm at gmail.com (Steven Miano) Date: Mon, 9 Jan 2017 11:01:25 -0500 Subject: Bonded VDSL2 / ADSL2+ Modems with 4 or more lines bonded In-Reply-To: References: Message-ID: Zyxel SBG3600-N may be another offering you might want to look into? On Mon, Jan 9, 2017 at 10:11 AM, Colton Conor wrote: > What options are out there to bond 4 or more DSL lines together? > > I know Positron has a 4 and 8 pair VDSL2 modem > http://www.positronaccess.com/AK626LC.php > > Adtran has a 8 port VDSL2 modem > https://portal.adtran.com/web/page/portal/Adtran/product/1172868F1/470 > > > and an Adtran 12 port ADSL2+ modem > https://portal.adtran.com/web/page/portal/Adtran/product/1172850G1/470 > > Actelis has a 8 pair VDS2 Modem: > http://actelis.com/actelis-products/ethernet-access-devices/ml700/ > > > Is there anyone else out there? The problem with all these solutions is > they each cost over $1000, which is a lot considering 2 port bonded VDSL2 > modems are in the $75-150 range. I know demand for these products is low, > but still hoping there is an OEM version. > -- Miano, Steven M. http://stevenmiano.com From Joel.Snyder at opus1.com Mon Jan 9 16:15:00 2017 From: Joel.Snyder at opus1.com (Joel M Snyder) Date: Mon, 09 Jan 2017 09:15:00 -0700 Subject: premiumcolo.net IP address rental Message-ID: Folks: I've been getting mail from "premiumcolo.net" offering to rent unused IPv4/IPv6 space. Their web site is a farce of random phrases, grammatical errors, misspellings, and randomly inserted words, and won't even render in Firefox. That being said, I'm curious as to whether anyone has had any experience with them or knows the back story. Also, is there some reason that there is no official searchable archive of the nanog mailing list? (or dependable unofficial one...)? Best in the new year to you all, jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From mlfreita at mtu.edu Mon Jan 9 16:20:37 2017 From: mlfreita at mtu.edu (Matt Freitag) Date: Mon, 9 Jan 2017 11:20:37 -0500 Subject: premiumcolo.net IP address rental In-Reply-To: References: Message-ID: Joel, I can't speak to "premiumcolo.net" But http://seclists.org/nanog/ is, in my experience, a pretty good searchable archive of this list. Matt Freitag Network Engineer I Information Technology Michigan Technological University (906) 487-3696 <%28906%29%20487-3696> https://www.mtu.edu/ https://www.it.mtu.edu/ On Mon, Jan 9, 2017 at 11:15 AM, Joel M Snyder wrote: > Folks: > > I've been getting mail from "premiumcolo.net" offering to rent unused > IPv4/IPv6 space. Their web site is a farce of random phrases, grammatical > errors, misspellings, and randomly inserted words, and won't even render in > Firefox. > > That being said, I'm curious as to whether anyone has had any experience > with them or knows the back story. > > Also, is there some reason that there is no official searchable archive of > the nanog mailing list? (or dependable unofficial one...)? > > Best in the new year to you all, > > jms > -- > Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 > Senior Partner, Opus One Phone: +1 520 324 0494 > jms at Opus1.COM http://www.opus1.com/jms > From sander at steffann.nl Mon Jan 9 16:30:31 2017 From: sander at steffann.nl (Sander Steffann) Date: Mon, 9 Jan 2017 17:30:31 +0100 Subject: Bonded VDSL2 / ADSL2+ Modems with 4 or more lines bonded In-Reply-To: References: Message-ID: <48B56127-D171-4A27-B3CE-65F720AC6F13@steffann.nl> Hi, > Zyxel SBG3600-N may be another offering you might want to look into? I think those are limited to 2x VDSL + LTE. Cheers, Sander From brandon at rd.bbc.co.uk Mon Jan 9 16:45:07 2017 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 9 Jan 2017 16:45:07 GMT Subject: premiumcolo.net IP address rental Message-ID: <201701091645.QAA05665@sunf10.rd.bbc.co.uk> > I've been getting mail from "premiumcolo.net" offering to rent unused > IPv4/IPv6 space. Their web site is a farce of random phrases, > grammatical errors, misspellings, and randomly inserted words, and won't > even render in Firefox. You need a larger warning may be dodgy sign? > Also, is there some reason that there is no official searchable archive > of the nanog mailing list? (or dependable unofficial one...)? In each message header List-Archive: google site:mailman.nanog.org/pipermail/nanog/ your search terms brandon From coy.hile at coyhile.com Mon Jan 9 17:50:59 2017 From: coy.hile at coyhile.com (Coy Hile) Date: Mon, 9 Jan 2017 12:50:59 -0500 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <1483662623.28358.25.camel@baseworx.net> References: <20161229214731.BB4AECC@m0087797.ppops.net> <1483662623.28358.25.camel@baseworx.net> Message-ID: <6BBEAD85-4779-45C8-93B1-3B5F43261551@coyhile.com> Why would one not set everything that's not an eyeball workstation to UTC and be done with it? Sent from my iPad > On Jan 5, 2017, at 19:30, Tim McKee wrote: > > Try times between Rio (Brasil) and Eastern US... depending on the date there are 4 different possible offsets... > > > On Thu, 2016-12-29 at 21:47 -0800, Scott Weeks wrote: > > > > :: 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 > > > > From rsk at gsp.org Mon Jan 9 18:13:11 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 9 Jan 2017 13:13:11 -0500 Subject: premiumcolo.net IP address rental In-Reply-To: References: Message-ID: <20170109181311.GA32065@gsp.org> On Mon, Jan 09, 2017 at 09:15:00AM -0700, Joel M Snyder wrote: > I've been getting mail from "premiumcolo.net" offering to rent unused > IPv4/IPv6 space. [snip] It is quite interesting to look at the WHOIS records for that domain, for phoenixkv.com, for 162.213.212.0/22, and for 162.213.215.0/24. RFG, if you're reading this, it may be worthy of your skills. ---rsk From hannigan at gmail.com Mon Jan 9 18:40:23 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 9 Jan 2017 13:40:23 -0500 Subject: Safe IPv4 Was: Re: premiumcolo.net IP address rental Message-ID: On Mon, Jan 9, 2017 at 11:20 AM, Matt Freitag wrote: > Joel, > > I can't speak to "premiumcolo.net" > Neither can I, but that may not mean much. Perhaps someone else can validate that they're reputable and can execute a transaction end to end? If you need IPv4 addresses for your network: 1. Make sure you have an IPV6 allocation from your favorite RIR and are using it 2. Apply for and receive a last /22 from RIPE. EVERYONE can do this. 3. Contact a reputable broker. The ones I have experience with (Alphabetical): A. Peter Thimmesch at Addrex http://www.addrex.net B. Amy Cooper at Hilco Streambank http://www.ipv4auctions.com/ C. Mike Burns at http://www.IPTrading.com ARIN also publishes a list (which is not a requirement to be able to transact or support transfers): https://www.arin.net/resources/transfer_listing/facilitator_list.html Network operators have many choices for answering their IP numbering needs these days. Including IPv6. Sorry to be a broken record on this topic, but it seems to come up a lot. And if you search the archives I'll suspect you'll find something similar to this a few time now. An educated network operator is the best kind. That's why we are here. YMMV and Best, -M< From betty at nanog.org Mon Jan 9 18:55:37 2017 From: betty at nanog.org (Betty Burke ) Date: Mon, 9 Jan 2017 13:55:37 -0500 Subject: [NANOG-announce] NANOG 69 Update Message-ID: 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 page is now posted. The NANOG 69 Agenda Outline is available now, with the actual agenda 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 . Please be aware of the NANOG 69 Registration 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 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 at nanog.org for further information. We look forward to our NANOG visit back to DC and welcome those attendees and meeting 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 at nanog.org Respectfully, Betty Betty J. Burke NANOG Executive Director 2864 Carpenter Rd., Ste 100 Ann Arbor, MI 48108 +1 866-902-1336 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From rstory at tislabs.com Mon Jan 9 19:34:03 2017 From: rstory at tislabs.com (Robert Story) Date: Mon, 9 Jan 2017 14:34:03 -0500 Subject: Safe IPv4 Was: Re: premiumcolo.net IP address rental In-Reply-To: References: Message-ID: <20170109143403.109376c9@ispx.vb.futz.org> On Mon, 9 Jan 2017 13:40:23 -0500 Martin wrote: MH> 2. Apply for and receive a last /22 from RIPE. EVERYONE can do this. Not quite everyone. You have to be a RIPE NCC member, which not everyone can do. "Who can become a Local Internet Registry (LIR)/RIPE NCC member? Any organisation with a legally established office in the RIPE NCC service region can become a member of the RIPE NCC." https://www.ripe.net/manage-ips-and-asns/resource-management/faq/faq-ipv4-address-space Robert -- Senior Software Engineer @ Parsons -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From aaron at wholesaleinternet.net Mon Jan 9 19:35:59 2017 From: aaron at wholesaleinternet.net (Aaron) Date: Mon, 9 Jan 2017 13:35:59 -0600 Subject: Safe IPv4 Was: Re: premiumcolo.net IP address rental In-Reply-To: References: Message-ID: <43345f7c-fab1-5cca-1b64-2b0825e9e77b@wholesaleinternet.net> The emails I've seen are looking to rent FROM us, not TO us. I've received an email to every one of our ARIN POCs so I assumed they were scraping whois data and marked it all as spam. Aaron On 1/9/2017 12:40 PM, Martin Hannigan wrote: > On Mon, Jan 9, 2017 at 11:20 AM, Matt Freitag wrote: > >> Joel, >> >> I can't speak to "premiumcolo.net" >> > Neither can I, but that may not mean much. Perhaps someone else can > validate that they're reputable and can execute a transaction end to end? > > If you need IPv4 addresses for your network: > > 1. Make sure you have an IPV6 allocation from your favorite RIR and are > using it > 2. Apply for and receive a last /22 from RIPE. EVERYONE can do this. > 3. Contact a reputable broker. > > The ones I have experience with (Alphabetical): > > A. Peter Thimmesch at Addrex http://www.addrex.net > B. Amy Cooper at Hilco Streambank http://www.ipv4auctions.com/ > C. Mike Burns at http://www.IPTrading.com > > ARIN also publishes a list (which is not a requirement to be able to > transact or support transfers): > > > https://www.arin.net/resources/transfer_listing/facilitator_list.html > > Network operators have many choices for answering their IP numbering needs > these days. Including IPv6. > > Sorry to be a broken record on this topic, but it seems to come up a lot. > And if you search the archives I'll suspect you'll find something similar > to this a few time now. > > An educated network operator is the best kind. That's why we are here. > > YMMV and Best, > > -M< > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From bob at FiberInternetCenter.com Mon Jan 9 19:59:14 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 9 Jan 2017 11:59:14 -0800 Subject: Safe IPv4 Was: Re: premiumcolo.net IP address rental In-Reply-To: <43345f7c-fab1-5cca-1b64-2b0825e9e77b@wholesaleinternet.net> References: <43345f7c-fab1-5cca-1b64-2b0825e9e77b@wholesaleinternet.net> Message-ID: Well, since someone is listing wholesalers of IPV4 space. I never grabbed any list to spam rental space offers that we have available....but since all the large competitors are mentioned in your thread here. There is a lot of information on a site I maintain, http://RentIPv4.com It has some good tech information, for those unfamiliar with routing blocks where they can learn more about the IP shortage logistics and how router table limits are effected. Thank You Bob Evans CTO > The emails I've seen are looking to rent FROM us, not TO us. I've > received an email to every one of our ARIN POCs so I assumed they were > scraping whois data and marked it all as spam. > > Aaron > > > On 1/9/2017 12:40 PM, Martin Hannigan wrote: >> On Mon, Jan 9, 2017 at 11:20 AM, Matt Freitag wrote: >> >>> Joel, >>> >>> I can't speak to "premiumcolo.net" >>> >> Neither can I, but that may not mean much. Perhaps someone else can >> validate that they're reputable and can execute a transaction end to >> end? >> >> If you need IPv4 addresses for your network: >> >> 1. Make sure you have an IPV6 allocation from your favorite RIR and are >> using it >> 2. Apply for and receive a last /22 from RIPE. EVERYONE can do this. >> 3. Contact a reputable broker. >> >> The ones I have experience with (Alphabetical): >> >> A. Peter Thimmesch at Addrex http://www.addrex.net >> B. Amy Cooper at Hilco Streambank http://www.ipv4auctions.com/ >> C. Mike Burns at http://www.IPTrading.com >> >> ARIN also publishes a list (which is not a requirement to be able to >> transact or support transfers): >> >> >> https://www.arin.net/resources/transfer_listing/facilitator_list.html >> >> Network operators have many choices for answering their IP numbering >> needs >> these days. Including IPv6. >> >> Sorry to be a broken record on this topic, but it seems to come up a >> lot. >> And if you search the archives I'll suspect you'll find something >> similar >> to this a few time now. >> >> An educated network operator is the best kind. That's why we are here. >> >> YMMV and Best, >> >> -M< >> > > -- > ================================================================ > Aaron Wendel > Chief Technical Officer > Wholesale Internet, Inc. (AS 32097) > (816)550-9030 > http://www.wholesaleinternet.com > ================================================================ > > From leandrobachero at gmail.com Mon Jan 9 16:37:24 2017 From: leandrobachero at gmail.com (Leandro de Lima Camargo) Date: Mon, 9 Jan 2017 14:37:24 -0200 Subject: premiumcolo.net IP address rental In-Reply-To: References: Message-ID: <14E68DC2-B300-4238-9DD0-2AF5175A1CB9@gmail.com> We received a offer from premiumcolo.net too in Brazil. /24 - U$100/month. Regards, Leandro de Lima Camargo > On Jan 92017, at 2:20 PM, Matt Freitag wrote: > > Joel, > > I can't speak to "premiumcolo.net" > > But http://seclists.org/nanog/ is, in my experience, a pretty good > searchable archive of this list. > > Matt Freitag > Network Engineer I > Information Technology > Michigan Technological University > (906) 487-3696 <%28906%29%20487-3696> > https://www.mtu.edu/ > https://www.it.mtu.edu/ > > On Mon, Jan 9, 2017 at 11:15 AM, Joel M Snyder > wrote: > >> Folks: >> >> I've been getting mail from "premiumcolo.net" offering to rent unused >> IPv4/IPv6 space. Their web site is a farce of random phrases, grammatical >> errors, misspellings, and randomly inserted words, and won't even render in >> Firefox. >> >> That being said, I'm curious as to whether anyone has had any experience >> with them or knows the back story. >> >> Also, is there some reason that there is no official searchable archive of >> the nanog mailing list? (or dependable unofficial one...)? >> >> Best in the new year to you all, >> >> jms >> -- >> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 >> Senior Partner, Opus One Phone: +1 520 324 0494 >> jms at Opus1.COM http://www.opus1.com/jms >> From m8lund at gmail.com Mon Jan 9 17:19:40 2017 From: m8lund at gmail.com (Mike Lund) Date: Mon, 9 Jan 2017 18:19:40 +0100 Subject: Some standard of showing "this is how my network works"? Message-ID: 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! From lvanbever at ethz.ch Mon Jan 9 22:56:41 2017 From: lvanbever at ethz.ch (Laurent Vanbever) Date: Mon, 9 Jan 2017 23:56:41 +0100 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence Message-ID: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> 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 ** 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. From hannigan at gmail.com Tue Jan 10 02:01:03 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 9 Jan 2017 21:01:03 -0500 Subject: Safe IPv4 Was: Re: premiumcolo.net IP address rental In-Reply-To: <43345f7c-fab1-5cca-1b64-2b0825e9e77b@wholesaleinternet.net> References: <43345f7c-fab1-5cca-1b64-2b0825e9e77b@wholesaleinternet.net> Message-ID: On Mon, Jan 9, 2017 at 2:35 PM, Aaron wrote: > The emails I've seen are looking to rent FROM us, not TO us. I've received > an email to every one of our ARIN POCs so I assumed they were scraping > whois data and marked it all as spam. > > Aaron > > If you did have excess v4 space, IMHO you'd be better off selling purchase/transfer first right of refusal over the risk of rental and scorched earth. YMMV here, zero experience in rentals, but I can imagine. Cheers, -M< From baldur.norddahl at gmail.com Tue Jan 10 02:51:04 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 10 Jan 2017 03:51:04 +0100 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence In-Reply-To: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> References: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> Message-ID: <5056b52a-303a-be5a-dfc2-d0f9ca9b9cfc@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 Den 09/01/2017 kl. 23.56 skrev Laurent Vanbever: > 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 > > > ** 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. From baldur.norddahl at gmail.com Tue Jan 10 02:59:15 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 10 Jan 2017 03:59:15 +0100 Subject: Safe IPv4 Was: Re: premiumcolo.net IP address rental In-Reply-To: <43345f7c-fab1-5cca-1b64-2b0825e9e77b@wholesaleinternet.net> References: <43345f7c-fab1-5cca-1b64-2b0825e9e77b@wholesaleinternet.net> Message-ID: Den 09/01/2017 kl. 20.35 skrev Aaron: > The emails I've seen are looking to rent FROM us, not TO us. I've > received an email to every one of our ARIN POCs so I assumed they were > scraping whois data and marked it all as spam. > > Aaron I believe it is a safe assumption that requests to rent IP space received as spam (scraped and abused whois data) is for spamming. If you were to give these guys your space, you will likely find your space blacklisted on every imaginable service. And then you will find that the check bounced. And the company will turn out not to exist if you try to sue for your loss. We also receive these requests regularly. There is probably a very good reason these people do not just use the official brokers to buy some space like the rest of us. Not that it matters to me - we are a young expanding ISP so we are buying not selling. Regards, Baldur From joelja at bogus.com Tue Jan 10 05:51:40 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 9 Jan 2017 21:51:40 -0800 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence In-Reply-To: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> References: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> Message-ID: <6260f07f-083d-f88c-4656-1a0d14e7aee8@bogus.com> On 1/9/17 2:56 PM, Laurent Vanbever wrote: > 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 > > > ** 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. One of the phenomena that is relatively easy to observe by withdrawing a prefix entirely is the convergence towards longer and longer AS paths until the route disappears entirely. that is providers that are further away will remain advertising the route and in the interim their neighbors will ingest the available path will until they too process the withdraw. it can take a comically long time (like 5 minutes) to see the prefix ultimately disappear from the internet. When withdrawing a prefix from a peer with which you have a single adjacency this can easily happens in miniature. > > ** 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. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From jefftant.ietf at gmail.com Tue Jan 10 08:11:10 2017 From: jefftant.ietf at gmail.com (Jeff Tantsura) Date: Tue, 10 Jan 2017 00:11:10 -0800 Subject: IETF RTGWG interim meeting - Existing problems for routing in the large Data Centers and potential solutions Message-ID: /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 Reply-To: rtgwg-chairs Date: Tuesday, December 20, 2016 at 11:47 To: Subject: WebEx meeting invitation: Existing problems for routing in the large Data Centers and potentail solutions Resent-From: Resent-To: , Chris Bowers 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: WebEx_Meeting.ics Type: application/octet-stream Size: 3671 bytes Desc: not available URL: From wolfgang.tremmel at de-cix.net Tue Jan 10 08:41:23 2017 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Tue, 10 Jan 2017 08:41:23 +0000 Subject: Some standard of showing "this is how my network works"? In-Reply-To: References: Message-ID: <4E9BAF70-4A00-448C-AAFB-E2A69ACA6652@de-cix.net> > On 9 Jan 2017, at 18:19, Mike Lund wrote: > > Is this such a thing anywhere? Try RIPE-Stat: https://stat.ripe.net best regards Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel at de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG K?ln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From bicknell at ufp.org Tue Jan 10 13:32:42 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 10 Jan 2017 05:32:42 -0800 Subject: Fiber Costs [Was: Re: SoCal FIOS outage(?) / static IP readdressing] In-Reply-To: <1483538931.114312187@upnet.mymailsrvr.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB029B75@RTC-EXCH01.RESERVE.LDS> Message-ID: <20170110133242.GA55770@ussenterprise.ufp.org> I don't know about the rest of the list, but I find these numbers fascinating. There's probably not that many people who are allowed to share them, but if more could I think that would be educational for a lot of folks. In a message written on Wed, Jan 04, 2017 at 08:37:19AM -0500, Jared Mauch wrote: > I?ve been thinking of the same in my underserved area. Labor is $5/foot here and despite friends and colleagues telling me to move, it seems I have a sub-60 month ROI (and sub-year for some areas I?ve modeled with modest uptake rates of 15-20% where the other options are fixed wireless, Cellular data or dial). In a message written on Wed, Jan 04, 2017 at 01:50:48PM +0000, Luke Guillory wrote: > Our model is 15k a mile all in, this is for aerial not underground for our HFC/Coax builds. A partner of ours models their underground fiber builds at 30k a mile. In a message written on Wed, Jan 04, 2017 at 09:08:51AM -0500, Shawn L wrote: > Depending on the area and conditions (rock, etc). We're seeing > > $4 /foot Aerial > $5-$7 /foot direct bury > $10 - $14 /foot directional bore -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From jheitz at cisco.com Tue Jan 10 19:51:57 2017 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Tue, 10 Jan 2017 19:51:57 +0000 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence Message-ID: <34b51a38602a422dbdcfb3c42aeda43e@XCH-ALN-014.cisco.com> 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 > > 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 From job at instituut.net Tue Jan 10 19:58:02 2017 From: job at instituut.net (Job Snijders) Date: Tue, 10 Jan 2017 20:58:02 +0100 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence In-Reply-To: <5056b52a-303a-be5a-dfc2-d0f9ca9b9cfc@gmail.com> References: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> <5056b52a-303a-be5a-dfc2-d0f9ca9b9cfc@gmail.com> Message-ID: <20170110195802.GD2066@hanna.meerval.net> On Tue, Jan 10, 2017 at 03:51:04AM +0100, Baldur Norddahl wrote: > 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. Alternatively, if you reboot a router, perhaps you could first shutdown the eBGP sessions, then wait 5 to 10 minutes for the traffic to drain away (should be visible in your NMS stats), and then proceed with the maintenance? Of course this only works for planned reboots, not suprise reboots. Kind regards, Job From hugo at slabnet.com Tue Jan 10 20:14:21 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 10 Jan 2017 12:14:21 -0800 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence In-Reply-To: <20170110195802.GD2066@hanna.meerval.net> References: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> <5056b52a-303a-be5a-dfc2-d0f9ca9b9cfc@gmail.com> <20170110195802.GD2066@hanna.meerval.net> Message-ID: <20170110201421.GB5132@bamboo.slabnet.com> On Tue 2017-Jan-10 20:58:02 +0100, Job Snijders wrote: >On Tue, Jan 10, 2017 at 03:51:04AM +0100, Baldur Norddahl wrote: >> 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. > >Alternatively, if you reboot a router, perhaps you could first shutdown >the eBGP sessions, then wait 5 to 10 minutes for the traffic to drain >away (should be visible in your NMS stats), and then proceed with the >maintenance? > >Of course this only works for planned reboots, not suprise reboots. ...or link failures. > >Kind regards, > >Job -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jared at puck.nether.net Tue Jan 10 20:32:33 2017 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 10 Jan 2017 15:32:33 -0500 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence In-Reply-To: <20170110201421.GB5132@bamboo.slabnet.com> References: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> <5056b52a-303a-be5a-dfc2-d0f9ca9b9cfc@gmail.com> <20170110195802.GD2066@hanna.meerval.net> <20170110201421.GB5132@bamboo.slabnet.com> Message-ID: > On Jan 10, 2017, at 3:14 PM, Hugo Slabbert wrote: > > > On Tue 2017-Jan-10 20:58:02 +0100, Job Snijders wrote: > >> On Tue, Jan 10, 2017 at 03:51:04AM +0100, Baldur Norddahl wrote: >>> 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. >> >> Alternatively, if you reboot a router, perhaps you could first shutdown >> the eBGP sessions, then wait 5 to 10 minutes for the traffic to drain >> away (should be visible in your NMS stats), and then proceed with the >> maintenance? >> >> Of course this only works for planned reboots, not suprise reboots. > > ...or link failures. One other comment: there has been a long history of poorly behaving BGP stacks that would take quite some time to hunt through the paths. While this can still occur with people with nearing ancient software and hardware still in-use, many of the modern software/hardware options enable things like BGP-PIC (in your survey) by default. Many of these options you document as best practices like path mtu discovery are well known fixes for networks, as well as using jumbo mtu internally to obtain 9k+ mss for high performance TCP. Vendors have not always chosen to enable the TCP options by default like the protocols have, eg: BGP-PIC and like Jakob?s response, tout other solutions vs fixing the TCP stack first. Many of these performances were documented in 2002 and are considered best practices by many networks, but due to their obscure knobs may not be widely deployed as a result, or seen as risky to configure. (We had a vendor panic when we discovered a bug in their TCP-SACK code, they were almost frozen in not fixing the code because touching TCP felt dangerous and there was an inadequate testing culture around something seen as ?stable?). here?s the presentation from IETF 53, I don?t see it in the proceedings handily: http://morse.colorado.edu/~epperson/courses/routing-protocols/handouts/bgp_scalability_IETF.ppt - Jared From mike at mikejones.in Tue Jan 10 21:31:20 2017 From: mike at mikejones.in (Mike Jones) Date: Tue, 10 Jan 2017 21:31:20 +0000 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence In-Reply-To: <20170110195802.GD2066@hanna.meerval.net> References: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> <5056b52a-303a-be5a-dfc2-d0f9ca9b9cfc@gmail.com> <20170110195802.GD2066@hanna.meerval.net> Message-ID: On 10 January 2017 at 19:58, Job Snijders wrote: > On Tue, Jan 10, 2017 at 03:51:04AM +0100, Baldur Norddahl wrote: >> 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. > > Alternatively, if you reboot a router, perhaps you could first shutdown > the eBGP sessions, then wait 5 to 10 minutes for the traffic to drain > away (should be visible in your NMS stats), and then proceed with the > maintenance? > > Of course this only works for planned reboots, not suprise reboots. > > Kind regards, > > Job If I tear down my eBGP sessions the upstream router withdraws the route and the traffic just stops. Are your upstreams propagating withdraws without actually updating their own routing tables? I believe the simple explanation of the problem can be seen by firing up an inbound mtr from a distant network then withdrawing the route from the path it is taking. It should show either destination unreachable or a routing loop which "retreats" (under the right circumstances I have observed it distinctly move 1 hop at a time) until it finds an alternate path. My observed convergence times for a single withdraw are however in the sub-10 second range, to get all the networks in the original path pointing at a new one. My view on the problem is that if you are failing over frequently enough for a customer to notice and report it, you have bigger problems than convergence times. - Mike Jones From lvanbever at ethz.ch Tue Jan 10 07:00:06 2017 From: lvanbever at ethz.ch (Laurent Vanbever) Date: Tue, 10 Jan 2017 08:00:06 +0100 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence In-Reply-To: <5056b52a-303a-be5a-dfc2-d0f9ca9b9cfc@gmail.com> References: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> <5056b52a-303a-be5a-dfc2-d0f9ca9b9cfc@gmail.com> Message-ID: <3DF2077F-3DFC-4A14-B1DE-708434452674@ethz.ch> Dear Baldur, > 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. Thanks a lot for your input. Indeed, that case is a bit special. I?d say it is a kind of remote outage that remote ASes experience towards your prefix and, as such, requires a "BGP-only? convergence. I guess if your prefixes going via alternate transit are not visible at all prior to the switch (and I guess not), this is a kind of ?extreme? convergence where routes have to be withdrawn/updated Internet-wide. This reminds me of the paper by Craig Labovitz et al. (http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-5-2.pdf ) which I think classify these events as Tlong ("An active route with a short ASPath is implicitly replaced with a new route possessing a longer ASPath. This represents both a route failure and failover?). And indeed, these are the second slowest just before the withdraw of a prefix Internet-wide. You?re right that our survey targets more the case in which large bursts of UPDATEs/WITHDRAWs are exchanged. I guess a parallel case to the one you mention could be that your prime transit performs a planned maintenance (or experiences a failure) that triggers the sending of WITHDRAWs for your prefixes out. > 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. Maybe you could advertise better routes (i.e., with shorter AS-PATHs/longer prefixes) via the alternate transit prior to the take down? Ideally, if you could somehow make your primary transit switch to use an alternate transit prior to the maintenance (maybe with a special community?), you could completely avoid a disruption. This would go into the direction of minimizing the amount of WITHDRAWs in favor of UPDATEs. But, of course, this would only work in the case of planned maintenance. We would definitely welcome more input on the convergence issue you face! Best, Laurent From lvanbever at ethz.ch Tue Jan 10 07:13:51 2017 From: lvanbever at ethz.ch (Laurent Vanbever) Date: Tue, 10 Jan 2017 08:13:51 +0100 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence In-Reply-To: <6260f07f-083d-f88c-4656-1a0d14e7aee8@bogus.com> References: <00B3706F-6034-460F-8DD1-267EB57C4371@ethz.ch> <6260f07f-083d-f88c-4656-1a0d14e7aee8@bogus.com> Message-ID: Hi Joel, > On 10 Jan 2017, at 06:51, joel jaeggli wrote: > > On 1/9/17 2:56 PM, Laurent Vanbever wrote: >> 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 >> >> >> ** 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. > > One of the phenomena that is relatively easy to observe by withdrawing a > prefix entirely is the convergence towards longer and longer AS paths > until the route disappears entirely. that is providers that are further > away will remain advertising the route and in the interim their > neighbors will ingest the available path will until they too process > the withdraw. it can take a comically long time (like 5 minutes) to see > the prefix ultimately disappear from the internet. When withdrawing a > prefix from a peer with which you have a single adjacency this can > easily happens in miniature. Thanks! Yes, definitely. This relates to the issue Baldur was raising in which a less-preferred prefix (or not prefix at all in your case) has to take over a more preferred one. That case is definitely bad for BGP convergence. Our survey/study is more geared towards cases where there is diversity available (alternates paths are there and at least partially visible). We are especially interested in finding out whether, even when you take all the precautionary measures required by the book, long BGP convergence can still bite you and? whether we can do anything about it. Laurent PS: Thanks so much to the 21 operators who have answered already! If you haven?t so already, please help us out to find out about troublesome BGP convergence by answering our short anonymous survey (<10 minutes): https://goo.gl/forms/JZd2CK0EFpCk0c272 From fkittred at gwi.net Tue Jan 10 15:21:53 2017 From: fkittred at gwi.net (Fletcher Kittredge) Date: Tue, 10 Jan 2017 10:21:53 -0500 Subject: Fiber Costs [Was: Re: SoCal FIOS outage(?) / static IP readdressing] In-Reply-To: <20170110133242.GA55770@ussenterprise.ufp.org> References: <1483538931.114312187@upnet.mymailsrvr.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB029B75@RTC-EXCH01.RESERVE.LDS> <20170110133242.GA55770@ussenterprise.ufp.org> Message-ID: Numbers for building fiber optic systems are out there if you do the research. Joining the FTTH Council is a good start. One thing to recognise is that the numbers vary widely based on what is being built and where it is being built. There are large regional, technology, and product variations. Verizon has economies of scale few can match. Having said that, some of the numbers listed are unrecognizably low. On Tue, Jan 10, 2017 at 8:32 AM, Leo Bicknell wrote: > > I don't know about the rest of the list, but I find these numbers > fascinating. There's probably not that many people who are allowed > to share them, but if more could I think that would be educational > for a lot of folks. > > In a message written on Wed, Jan 04, 2017 at 08:37:19AM -0500, Jared Mauch > wrote: > > I?ve been thinking of the same in my underserved area. Labor is $5/foot > here and despite friends and colleagues telling me to move, it seems I have > a sub-60 month ROI (and sub-year for some areas I?ve modeled with modest > uptake rates of 15-20% where the other options are fixed wireless, Cellular > data or dial). > > In a message written on Wed, Jan 04, 2017 at 01:50:48PM +0000, Luke > Guillory wrote: > > Our model is 15k a mile all in, this is for aerial not underground for > our HFC/Coax builds. A partner of ours models their underground fiber > builds at 30k a mile. > > In a message written on Wed, Jan 04, 2017 at 09:08:51AM -0500, Shawn L > wrote: > > Depending on the area and conditions (rock, etc). We're seeing > > > > $4 /foot Aerial > > $5-$7 /foot direct bury > > $10 - $14 /foot directional bore > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net From jared at puck.nether.net Wed Jan 11 00:20:35 2017 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 10 Jan 2017 19:20:35 -0500 Subject: Fiber Costs [Was: Re: SoCal FIOS outage(?) / static IP readdressing] In-Reply-To: References: <1483538931.114312187@upnet.mymailsrvr.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB029B75@RTC-EXCH01.RESERVE.LDS> <20170110133242.GA55770@ussenterprise.ufp.org> Message-ID: <69724F27-6692-4BCC-A485-610FA409FB27@puck.nether.net> > On Jan 10, 2017, at 10:21 AM, Fletcher Kittredge wrote: > > Numbers for building fiber optic systems are out there if you do the > research. Joining the FTTH Council is a good start. One thing to recognise > is that the numbers vary widely based on what is being built and where it > is being built. There are large regional, technology, and product > variations. Verizon has economies of scale few can match. > > Having said that, some of the numbers listed are unrecognizably low. Labor can vary quite widely based on project, distance and environment. What is $5/foot in a rural location can be $150 or more in an urban environment. It?s not uncommon to see pricing around $12/foot before engineering and other permitting work. If you?re in an environment that has favorable permitting process and can work with an existing insured contractor, $5/foot is attainable. You are still up against 600-800 feet per day in favorable soil, which can easily turn to 200 should there be a rock or complex utility work involved. I?ll say depending on your project, you can start with the big-dreamer communities out there, or you go the other way and talk to folks that are doing it on the ground in your local area. I?ve talked to people about pole attach as well as underground. You can see costs as low as 10k per mile on poles, but that?s the really low end. All numbers I?ve mentioned are for Michigan in the communities around my home as well as outlying areas. If you?re around my area and want to talk costs and the projects, a private e-mail is welcome. If you?re in Maine, that granite rock is really tough, the hemlocks rot and fall more often than the birch, etc. Those risks make the situation tougher, and the population north of Bangor/Orono really thins out, but at least the speed limit is higher on 95 now. :-) - Jared From bicknell at ufp.org Wed Jan 11 14:09:24 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 Jan 2017 06:09:24 -0800 Subject: Fiber Costs [Was: Re: SoCal FIOS outage(?) / static IP readdressing] In-Reply-To: References: <1483538931.114312187@upnet.mymailsrvr.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB029B75@RTC-EXCH01.RESERVE.LDS> <20170110133242.GA55770@ussenterprise.ufp.org> Message-ID: <20170111140924.GB94346@ussenterprise.ufp.org> In a message written on Tue, Jan 10, 2017 at 10:21:53AM -0500, Fletcher Kittredge wrote: > Numbers for building fiber optic systems are out there if you do the > research. Joining the FTTH Council is a good start. One thing to recognise > is that the numbers vary widely based on what is being built and where it > is being built. There are large regional, technology, and product > variations. Verizon has economies of scale few can match. That's actually why I find this interesting. It's not so much the raw price, as I'm sure there is plenty written on that in various forums and anyone serious about putting fiber in the ground knows what they are. Rather it's the external factors that affect price. I'm sure everyone on this list could guess labor prices and permitting vary, but the anicdotal information about permitting, soil, working with other utilities, and so on that drives much of the cost is fascinating. Perhaps I could have phrased better, I don't care so much that it's $15/foot in Frostbite Falls, but I am very interested in why it is $15/foot in Frostbite Falls. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From ispcolohost at gmail.com Wed Jan 11 14:37:19 2017 From: ispcolohost at gmail.com (David H) Date: Wed, 11 Jan 2017 09:37:19 -0500 Subject: Advice re network compromise and "law enforcement" (PCI certification) Message-ID: Hi all, I figure there's probably some folks on the list that have hands in environments that touch credit cards. Unlike HIPAA compliance, or even social security numbers, PCI is very ambiguous about what must occur if a network/systems breach occurs that exposes credit card data. PCI, and its auditors, don't seem to want to tell you what your security policy should state with regard to what constitutes an event worthy of 'law enforcement' contact, nor what agency is appropriate, yet they require you to have such a policy in place. Anyone have pointers/advice on what you came up with for a reasonable definition of events that warrant involving law enforcement, and then what agency/agencies would be contacted? We're obviously not going to waste the time, on either side, of calling the FBI if one credit card number is stolen since they won't care, nor would the local police, who don't even have a cybercrime section. Generic policies covering network breaches and law enforcement would be welcome too; may be able to work it into something that is appropriate for our environment and credit card data. Thanks, David From rsk at gsp.org Wed Jan 11 15:19:42 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 11 Jan 2017 10:19:42 -0500 Subject: Advice re network compromise and "law enforcement" (PCI certification) In-Reply-To: References: Message-ID: <20170111151942.GA18010@gsp.org> On Wed, Jan 11, 2017 at 09:37:19AM -0500, David H wrote: > Anyone have pointers/advice on what you came up with for a reasonable > definition of events that warrant involving law enforcement, and then what > agency/agencies would be contacted? This question is best answered by an attorney with expertise in this area and with specific knowledge of your operation. ---rsk From mlfreita at mtu.edu Wed Jan 11 15:23:34 2017 From: mlfreita at mtu.edu (Matt Freitag) Date: Wed, 11 Jan 2017 10:23:34 -0500 Subject: Advice re network compromise and "law enforcement" (PCI certification) In-Reply-To: <20170111151942.GA18010@gsp.org> References: <20170111151942.GA18010@gsp.org> Message-ID: Adding to what Rich said, it's very easy for advice on this to cross into advice on legal matters. It's also usually very illegal for non-attorneys or non-licensed attorneys to offer advice on legal matters. I recommend finding a lawyer with expertise in this area and who has specific knowledge of your operation. Matt Freitag Network Engineer I Information Technology Michigan Technological University (906) 487-3696 <%28906%29%20487-3696> https://www.mtu.edu/ https://www.it.mtu.edu/ On Wed, Jan 11, 2017 at 10:19 AM, Rich Kulawiec wrote: > On Wed, Jan 11, 2017 at 09:37:19AM -0500, David H wrote: > > Anyone have pointers/advice on what you came up with for a reasonable > > definition of events that warrant involving law enforcement, and then > what > > agency/agencies would be contacted? > > This question is best answered by an attorney with expertise in this area > and with specific knowledge of your operation. > > ---rsk > From keiths at neilltech.com Wed Jan 11 15:39:45 2017 From: keiths at neilltech.com (Keith Stokes) Date: Wed, 11 Jan 2017 15:39:45 +0000 Subject: Advice re network compromise and "law enforcement" (PCI certification) In-Reply-To: References: <20170111151942.GA18010@gsp.org> Message-ID: What advice does your QSA have regarding writing the policy? There are generic templates available to write your company security policy. That policy doesn?t necessarily constitute legal definitions or requirements for any sort of breach, which may vary by locale and provider. I?m assuming EDUs will have their own set of rules as may non-profits. At best you will want to pass legal responsibility out of technical hands into C-Level/management hands to make decisions about whom is notified, what legal actions and third parties are called in. Your security policy can define when the buck is passed and left to a given committee. On Jan 11, 2017, at 9:23 AM, Matt Freitag > wrote: Adding to what Rich said, it's very easy for advice on this to cross into advice on legal matters. It's also usually very illegal for non-attorneys or non-licensed attorneys to offer advice on legal matters. I recommend finding a lawyer with expertise in this area and who has specific knowledge of your operation. Matt Freitag Network Engineer I Information Technology Michigan Technological University (906) 487-3696 <%28906%29%20487-3696> https://www.mtu.edu/ https://www.it.mtu.edu/ On Wed, Jan 11, 2017 at 10:19 AM, Rich Kulawiec wrote: On Wed, Jan 11, 2017 at 09:37:19AM -0500, David H wrote: Anyone have pointers/advice on what you came up with for a reasonable definition of events that warrant involving law enforcement, and then what agency/agencies would be contacted? This question is best answered by an attorney with expertise in this area and with specific knowledge of your operation. ---rsk --- Keith Stokes From jared at puck.nether.net Wed Jan 11 15:50:49 2017 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Jan 2017 10:50:49 -0500 Subject: OmanTel hijacking of IP space Message-ID: 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 From morrowc.lists at gmail.com Wed Jan 11 16:42:31 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 11 Jan 2017 11:42:31 -0500 Subject: OmanTel hijacking of IP space In-Reply-To: References: Message-ID: On Wed, Jan 11, 2017 at 10:50 AM, Jared Mauch wrote: > 206.125.164.0 thanks to everyone who's (not) filtering. You're making the internet a little (less) better each time this happens.. What year is it? From keenansingh at airlinktt.net Wed Jan 11 04:08:45 2017 From: keenansingh at airlinktt.net (Keenan Singh) Date: Tue, 10 Jan 2017 23:08:45 -0500 Subject: Bandwidth Savings Message-ID: 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 From marty at cloudflare.com Wed Jan 11 17:47:49 2017 From: marty at cloudflare.com (Marty Strong) Date: Wed, 11 Jan 2017 17:47:49 +0000 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: <1A8A9DE6-74B6-4BDF-975F-972D845AD8CD@cloudflare.com> The first step would be profiling your traffic sources. I would imagine you probably have a bunch of YouTube, Netflix et al. content, that those content providers will send you a cache box for, subject to minimum traffic requirements. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 11 Jan 2017, at 04:08, Keenan Singh 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 From lguillory at reservetele.com Wed Jan 11 18:15:51 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 11 Jan 2017 18:15:51 +0000 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB03D212@RTC-EXCH01.RESERVE.LDS> I reached out to my vendor and got back the following. Also what services have you seen move to HTTPS that you're not able to cache? Hi Luke, Regarding HTTPS Streaming and Netflix... Netflix announced in the spring of 2015 that it would move to HTTPS delivery by April of 2016. At the time of that first announcement, some concluded Netflix might not be able to afford the capital investment required to enable HTTPS delivery. Given Netflix did not complete the HTTPS project by their first deadline, we believe they have been focused on other priorities such as their global expansion, So, given this history, it's not clear just when or if Netflix will make the move to majority HTTPS for delivery. Furthermore, Netflix is under considerable pressure from investors to improve subscriber growth, revenue growth and profitability. The HTTPS project does not support any of these goals. In fact, Netflix reported net income is marginal and a move to full HTTPS delivery would likely consume all profits for the year. Along with the rest of the industry, we recognize the need for Open Caching systems to support HTTPS streaming from upstream content providers. This is one of the reasons why we were a Founding Member, along with 16 other streaming companies, in the Streaming Video Alliance in the fall of 2014. The SVA now includes almost 50 member companies from across the streaming ecosystem and around the world. More importantly, the Open Caching Working Group has issued functional requirements, unanimously approved by SVA members, which include support for HTTPS streams. The SVA Board has invited Netflix to join the Alliance and, in doing so, endorse the Open Caching work underway. This would open up a path in the short run to ensure any open cache can continue to support Netflix content even if Netflix moves to HTTPS delivery. We expect to see Netflix become more active in the SVA soon given other major streaming providers, such as Hulu and Amazon, are joining now. In conclusion, the SVA has developed a solution for Open Cache support of HTTPS streaming and we expect all streaming providers, including Netflix, will align with the SVA's direction. http://www.streamingvideoalliance.org/ Let me know if you have any more questions. Regards, Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Keenan Singh Sent: Tuesday, January 10, 2017 10:09 PM To: nanog at nanog.org Subject: Bandwidth Savings 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 From Valdis.Kletnieks at vt.edu Wed Jan 11 18:58:49 2017 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 11 Jan 2017 13:58:49 -0500 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: <16704.1484161129@turing-police.cc.vt.edu> On Tue, 10 Jan 2017 23:08:45 -0500, Keenan Singh said: > 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 Those will probably not help a lot with https: data, as a properly encrypted stream is very close to random bits and thus not very compressible. As others have noted, your best chances are getting content providers to give you a local cache of their most popular content. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From jheitz at cisco.com Wed Jan 11 19:13:14 2017 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Wed, 11 Jan 2017 19:13:14 +0000 Subject: Soliciting your opinions on Internet routing: A survey on BGP convergence Message-ID: <0d43ac8b32bb427291d150988883504a@XCH-ALN-014.cisco.com> 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 at nanog.org; 'baldur.norddahl at 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 > > > > 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 From lguillory at reservetele.com Wed Jan 11 20:10:16 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 11 Jan 2017 20:10:16 +0000 Subject: Bandwidth Savings In-Reply-To: <16704.1484161129@turing-police.cc.vt.edu> References: <16704.1484161129@turing-police.cc.vt.edu> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB03D7FF@RTC-EXCH01.RESERVE.LDS> Netflix won?t even begin talks for their cache if you're not doing a minimum of 5Gbps. They also require massive uploads to the cache often, these are things are 200TB now if I recall and they send everything unlike the transparent who only grab what's already being consumed. Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu Sent: Wednesday, January 11, 2017 12:59 PM To: Keenan Singh Cc: nanog at nanog.org Subject: Re: Bandwidth Savings On Tue, 10 Jan 2017 23:08:45 -0500, Keenan Singh said: > 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 Those will probably not help a lot with https: data, as a properly encrypted stream is very close to random bits and thus not very compressible. As others have noted, your best chances are getting content providers to give you a local cache of their most popular content. From richard.hicks at gmail.com Wed Jan 11 20:55:05 2017 From: richard.hicks at gmail.com (Richard Hicks) Date: Wed, 11 Jan 2017 12:55:05 -0800 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: ?? 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 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 > From eric.kuhnke at gmail.com Wed Jan 11 21:23:58 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 11 Jan 2017 13:23:58 -0800 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: 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 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 > 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 > > > From marty at cloudflare.com Wed Jan 11 21:34:23 2017 From: marty at cloudflare.com (Marty Strong) Date: Wed, 11 Jan 2017 21:34:23 +0000 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: 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 at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 11 Jan 2017, at 21:23, Eric Kuhnke 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 > 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 >> 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 >>> >> From marty at cloudflare.com Wed Jan 11 22:24:55 2017 From: marty at cloudflare.com (Marty Strong) Date: Wed, 11 Jan 2017 22:24:55 +0000 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: 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 at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 11 Jan 2017, at 22:17, Martin Hannigan 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 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 at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > > > On 11 Jan 2017, at 21:23, Eric Kuhnke 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 > > 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 > >> 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 > >>> > >> > > From cheetahmorph at gmail.com Wed Jan 11 23:29:43 2017 From: cheetahmorph at gmail.com (Jippen) Date: Wed, 11 Jan 2017 15:29:43 -0800 Subject: Advice re network compromise and "law enforcement" (PCI certification) In-Reply-To: References: <20170111151942.GA18010@gsp.org> Message-ID: I am not a lawyer, and this is not legal advice, but... General rule is to always notify the credit card companies, and to notify legal. One/both/neither may advice law enforcement activity. In either case, your PCI-required Incident response plan is required to do certain isolation steps explicitly to aid in digitial forensics if an investigation is needed. As for how many - thats a legal question, but under California breach laws, any breach must notify the affected person(s), and over 500 has additional requirements - and those numbers do provide a sane precedent to fall back to. Also, reporting to an FBI office is a good move to provide a liability shield to your company, as you did follow due diligence. If the FBI does not follow up, thats not your problem. On Wed, Jan 11, 2017 at 7:39 AM, Keith Stokes wrote: > What advice does your QSA have regarding writing the policy? > > There are generic templates available to write your company security > policy. That policy doesn?t necessarily constitute legal definitions or > requirements for any sort of breach, which may vary by locale and provider. > I?m assuming EDUs will have their own set of rules as may non-profits. > > At best you will want to pass legal responsibility out of technical hands > into C-Level/management hands to make decisions about whom is notified, > what legal actions and third parties are called in. Your security policy > can define when the buck is passed and left to a given committee. > > On Jan 11, 2017, at 9:23 AM, Matt Freitag ita at mtu.edu>> wrote: > > Adding to what Rich said, it's very easy for advice on this to cross into > advice on legal matters. > > It's also usually very illegal for non-attorneys or non-licensed attorneys > to offer advice on legal matters. > > I recommend finding a lawyer with expertise in this area and who has > specific knowledge of your operation. > > Matt Freitag > Network Engineer I > Information Technology > Michigan Technological University > (906) 487-3696 <%28906%29%20487-3696> > https://www.mtu.edu/ > https://www.it.mtu.edu/ > > On Wed, Jan 11, 2017 at 10:19 AM, Rich Kulawiec wrote: > > On Wed, Jan 11, 2017 at 09:37:19AM -0500, David H wrote: > Anyone have pointers/advice on what you came up with for a reasonable > definition of events that warrant involving law enforcement, and then > what > agency/agencies would be contacted? > > This question is best answered by an attorney with expertise in this area > and with specific knowledge of your operation. > > ---rsk > > > > --- > > Keith Stokes > > > > > From geoffk at geoffk.org Thu Jan 12 00:32:25 2017 From: geoffk at geoffk.org (Geoffrey Keating) Date: 11 Jan 2017 16:32:25 -0800 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: Keenan Singh writes: > 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. For Apple-originated data there's Caching Server, part of macOS Server, https://www.apple.com/macos/server/features/#caching-server You buy a Mac, and get macOS Server from the App Store. If you're using a typical single-outgoing-IP NAT, put the Mac behind the NAT, and make sure other hosts on the NAT can talk to it. If you're using public IP space, or you have NATs where you can't do that, you add DNS-SD TXT records to the search domain for your customers' machines (as configured with DHCP). Then your customers will use the Mac as a local caching source of Apple software updates and store content. You can have several and they'll automatically cluster and failover. There's documentation at https://help.apple.com/serverapp/mac/5.0/#/apd5E1AD52E-012B-4A41-8F21-8E9EDA56583A From fkittred at gwi.net Wed Jan 11 19:36:52 2017 From: fkittred at gwi.net (Fletcher Kittredge) Date: Wed, 11 Jan 2017 14:36:52 -0500 Subject: Bandwidth Savings In-Reply-To: <16704.1484161129@turing-police.cc.vt.edu> References: <16704.1484161129@turing-police.cc.vt.edu> Message-ID: The problem with the local cache[s] is the bandwidth cost of populating the cache and keeping it coherent can be greater than the bandwidth saved. From your description, I would expect this to be the case so a local cache will not help. Rule of thumb is if your downstream traffic is not at least 3gb/sec, you won't see a win from a cache. This problem can be mitigated if you can find other large bandwidth consumers on the island and partner to share a cache. Examples of potential partners would be your competitors, universities, government organisations, etc. The savings can be significant. If there is a local peering point on the islands, this would be the best place for shared caches. Sharing caches via an existing non-profit peering organization or having a non-profit, educational organization, or the government take the lead can lower the suspicion barrier and result in more sign-ups. On Wed, Jan 11, 2017 at 1:58 PM, wrote: > On Tue, 10 Jan 2017 23:08:45 -0500, Keenan Singh said: > > > 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 > > Those will probably not help a lot with https: data, as a properly > encrypted > stream is very close to random bits and thus not very compressible. > > As others have noted, your best chances are getting content providers to > give > you a local cache of their most popular content. > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net From fgont at si6networks.com Thu Jan 12 11:19:42 2017 From: fgont at si6networks.com (Fernando Gont) Date: Thu, 12 Jan 2017 08:19:42 -0300 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) Message-ID: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> Folks, I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 and/or IPv6 fragments targeted to BGP routers (off-list datapoints are welcome). In any case, you mind find it worth reading to check if you're affected (from Section 2 of recently-published RFC8021): ---- cut here ---- The security implications of IP fragmentation have been discussed at length in [RFC6274] and [RFC7739]. An attacker can leverage the generation of IPv6 atomic fragments to trigger the use of fragmentation in an arbitrary IPv6 flow (in scenarios in which actual fragmentation of packets is not needed) and can subsequently perform any type of fragmentation-based attack against legacy IPv6 nodes that do not implement [RFC6946]. That is, employing fragmentation where not actually needed allows for fragmentation-based attack vectors to be employed, unnecessarily. We note that, unfortunately, even nodes that already implement [RFC6946] can be subject to DoS attacks as a result of the generation of IPv6 atomic fragments. Let us assume that Host A is communicating with Host B and that, as a result of the widespread dropping of IPv6 packets that contain extension headers (including fragmentation) [RFC7872], some intermediate node filters fragments between Host B and Host A. If an attacker sends a forged ICMPv6 PTB error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario. Another possible scenario is that in which two BGP peers are employing IPv6 transport and they implement Access Control Lists (ACLs) to drop IPv6 fragments (to avoid control-plane attacks). If the aforementioned BGP peers drop IPv6 fragments but still honor received ICMPv6 PTB error messages, an attacker could easily attack the corresponding peering session by simply sending an ICMPv6 PTB message with a reported MTU smaller than 1280 bytes. Once the attack packet has been sent, the aforementioned routers will themselves be the ones dropping their own traffic. ---- cut here ---- Is this something waiting to be exploited? Am I missing something? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rsk at gsp.org Thu Jan 12 13:18:33 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 12 Jan 2017 08:18:33 -0500 Subject: Bandwidth Savings In-Reply-To: References: Message-ID: <20170112131833.GA16202@gsp.org> On Tue, Jan 10, 2017 at 11:08:45PM -0500, Keenan Singh wrote: > We are currently looking at any way we can save on > Bandwidth or to be more Efficient with the Bandwidth we currently have. Measure what you're doing in as much detail as you can. Slice-and-dice it by source, destination, time-of-day, protocol, day-of-week, etc. and plot the results. In most cases, the problems will make themselves leap off the page. (We could all probably predict what they are right now, but real live measurements are still a good idea.) Once you've identified the problems, you'll be much closer to enumerating possible solutions (and you can avoid wasting time on the issues that aren't worth addressing). ---rsk From nanog at ics-il.net Thu Jan 12 13:35:12 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 12 Jan 2017 07:35:12 -0600 (CST) Subject: Bandwidth Savings In-Reply-To: References: Message-ID: <472469347.3225.1484228111792.JavaMail.mhammett@ThunderFuck> Peering is great when you can get to the IX inexpensively. I assume that glass that goes underwater has a significant increase in cost and therefore the cost savings of peering would be minuscule in comparison to the cost of the rest of the connectivity. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Richard Hicks" To: "Keenan Singh" Cc: nanog at nanog.org Sent: Wednesday, January 11, 2017 2:55:05 PM Subject: Re: Bandwidth Savings 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 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 > From nanog at ics-il.net Thu Jan 12 13:38:22 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 12 Jan 2017 07:38:22 -0600 (CST) Subject: Bandwidth Savings In-Reply-To: References: Message-ID: <1705633336.3233.1484228302231.JavaMail.mhammett@ThunderFuck> I remember there were a couple different owners down there, but Columbus swallowed them up, then C&W got Columbus then Liberty got C&W. Not knowing the international cable market, is this like AT&T, Comcast or Verizon (the largest US last mile operators) being your only option? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Eric Kuhnke" To: "nanog at nanog.org list" Sent: Wednesday, January 11, 2017 3:23:58 PM Subject: Re: Bandwidth Savings 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 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 > 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 > > > From marty at cloudflare.com Thu Jan 12 13:41:03 2017 From: marty at cloudflare.com (Marty Strong) Date: Thu, 12 Jan 2017 13:41:03 +0000 Subject: Bandwidth Savings In-Reply-To: <1705633336.3233.1484228302231.JavaMail.mhammett@ThunderFuck> References: <1705633336.3233.1484228302231.JavaMail.mhammett@ThunderFuck> Message-ID: <36E506DA-EAB6-469E-9A70-81BEBE75C5F8@cloudflare.com> At the end of the day it?s a cost/benefit analysis, reading the OP?s message it?s clear that the IX or transit isn?t really the problem, but rather how much traffic traverses to the point of transit/IX. I think until we see some numbers both in terms of traffic and in terms of price to say Miami, Willemstad, etc. we can?t easily determine a good solution. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 12 Jan 2017, at 13:38, Mike Hammett wrote: > > I remember there were a couple different owners down there, but Columbus swallowed them up, then C&W got Columbus then Liberty got C&W. > > Not knowing the international cable market, is this like AT&T, Comcast or Verizon (the largest US last mile operators) being your only option? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Eric Kuhnke" > To: "nanog at nanog.org list" > Sent: Wednesday, January 11, 2017 3:23:58 PM > Subject: Re: Bandwidth Savings > > 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 > 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 >> 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 >>> >> > From saku at ytti.fi Thu Jan 12 14:43:06 2017 From: saku at ytti.fi (Saku Ytti) Date: Thu, 12 Jan 2017 16:43:06 +0200 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> Message-ID: On 12 January 2017 at 13:19, Fernando Gont wrote: Hey, > I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > welcome). Generally may be understood differently by different people. If generally is defined as single most typical behaviour/configuration, then generally people don't protect their infrastructure in any way at all, but fully rely vendor doing something reasonable. I would argue BCP is to have 'strict' CoPP. Where you specifically allow what you must then have ultimate rule to deny everything. If you have such CoPP, then this attack won't work, as you clearly didn't allow any fragments at all (as you didn't expect to receive BGP fragments from your neighbours). -- ++ytti From fgont at si6networks.com Thu Jan 12 15:02:05 2017 From: fgont at si6networks.com (Fernando Gont) Date: Thu, 12 Jan 2017 12:02:05 -0300 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> Message-ID: <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> Hi, Saku, On 01/12/2017 11:43 AM, Saku Ytti wrote: > On 12 January 2017 at 13:19, Fernando Gont wrote: > > Hey, > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are >> welcome). > > Generally may be understood differently by different people. If > generally is defined as single most typical behaviour/configuration, > then generally people don't protect their infrastructure in any way at > all, but fully rely vendor doing something reasonable. > > I would argue BCP is to have 'strict' CoPP. Where you specifically > allow what you must then have ultimate rule to deny everything. If you > have such CoPP, then this attack won't work, as you clearly didn't > allow any fragments at all (as you didn't expect to receive BGP > fragments from your neighbours). That's the point: If you don't allow fragments, but your peer honors ICMPv6 PTB<1280, then dropping fragments creates the attack vector. -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marka at isc.org Thu Jan 12 19:28:45 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 13 Jan 2017 06:28:45 +1100 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: Your message of "Thu, 12 Jan 2017 12:02:05 -0300." <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> Message-ID: <20170112192845.BD44D5F3097F@rock.dv.isc.org> In message <11ff128d-2fba-7c26-4a9c-5611433d85d2 at si6networks.com>, Fernando Gon t writes: > Hi, Saku, > > On 01/12/2017 11:43 AM, Saku Ytti wrote: > > On 12 January 2017 at 13:19, Fernando Gont wrote: > > > > Hey, > > > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > >> welcome). > > > > Generally may be understood differently by different people. If > > generally is defined as single most typical behaviour/configuration, > > then generally people don't protect their infrastructure in any way at > > all, but fully rely vendor doing something reasonable. > > > > I would argue BCP is to have 'strict' CoPP. Where you specifically > > allow what you must then have ultimate rule to deny everything. If you > > have such CoPP, then this attack won't work, as you clearly didn't > > allow any fragments at all (as you didn't expect to receive BGP > > fragments from your neighbours). > > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. And fragments are a *normal* part of IP for both IPv4 and IPv6. This obsession with dropping all fragments (and yes it is a obsession) is breaking the internet. Even if you don't want to allow all fragments through you can allow fragments between the two endpoints of a "active" connection. You can apply port filters to the offset 0 fragments. If that fragment doesn't have enough headers to be able to filter then drop it. If your firewall is incapable of doing this then find a better firewall as the current one is a piece of garbage and should be in the recycle bin. Which DoS is the bigger issue? Firewalls dropping fragments or reassembly buffers being exhausted? Yes, firewalls dropping fragments is a denial of service attack. The initial TCP exchange does not contain fragments. Most UDP protocols don't start with a packet that will need to be fragmented. For other protocols YMMV. Mark > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From saku at ytti.fi Thu Jan 12 19:31:53 2017 From: saku at ytti.fi (Saku Ytti) Date: Thu, 12 Jan 2017 21:31:53 +0200 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> Message-ID: On 12 January 2017 at 17:02, Fernando Gont wrote: > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. Thanks. I think I got it now. Best I can offer is that B could try to verify the embedded original packet? Hopefully attacker won't have access to that information. An if attacker has access to that information, they may as well do TCP RST, right? Didn't we have same issues in IPv4 with ICMP unreachable and frag neeeded, DF set? And vendors implemented more verification if the ICMP message should be accepted. -- ++ytti From fgont at si6networks.com Thu Jan 12 19:53:13 2017 From: fgont at si6networks.com (Fernando Gont) Date: Thu, 12 Jan 2017 16:53:13 -0300 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> Message-ID: Many (most?) Implementations don't even check the embedded port numbers...do tye attacker does not even need to guess the client port. besides, becaude of ipv6 ehs, you're not really guaranteed to receive e.g. the tcp header in the embedded payload (the embedded payload could easily be fixed ipv6 header + ehs). Cheers, Fernando El 12/1/2017 16:32, "Saku Ytti" escribi?: > On 12 January 2017 at 17:02, Fernando Gont wrote: > > That's the point: If you don't allow fragments, but your peer honors > > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > > Thanks. I think I got it now. Best I can offer is that B could try to > verify the embedded original packet? Hopefully attacker won't have > access to that information. An if attacker has access to that > information, they may as well do TCP RST, right? > > Didn't we have same issues in IPv4 with ICMP unreachable and frag > neeeded, DF set? And vendors implemented more verification if the ICMP > message should be accepted. > > -- > ++ytti > From saku at ytti.fi Thu Jan 12 20:06:27 2017 From: saku at ytti.fi (Saku Ytti) Date: Thu, 12 Jan 2017 22:06:27 +0200 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> Message-ID: On 12 January 2017 at 21:53, Fernando Gont wrote: > besides, becaude of ipv6 ehs, you're not really guaranteed to receive e.g. > the tcp header in the embedded payload (the embedded payload could easily be > fixed ipv6 header + ehs). If the CoPP drops what has not been explicitly allowed, then packets with EH should be dropped. Particularly if you're not allowing 'tcp' but you're allowing 'next-header tcp'. I.e. the real BGP session (that attacker is trying to disrupt) would not have EH, on account that it would not come up if it had. But I agree if you do need and do use EH, things can get really dirty really fast, fundamentally no one implements standard compliant IPv6, if we're insisting that even pathological EH chains should work (which is fair viewpoint, while not one that I share). Maybe embedded flow-label could used to add confidence ICMP message is for packet we've actually sent? Make flow-label hash, a'la syn cookie. Spooffed ICMP message to disrupt existing TCP isn't novel. Coincidentally one service I use stopped working yesterday, but just for me, after short debugging, there was route cache entry on the server for my client ip which needed to be flushed, perhaps ended up there due to rogue ICMP redirect. -- ++ytti From fgont at si6networks.com Thu Jan 12 20:17:22 2017 From: fgont at si6networks.com (Fernando Gont) Date: Thu, 12 Jan 2017 17:17:22 -0300 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: <20170112192845.BD44D5F3097F@rock.dv.isc.org> References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> <20170112192845.BD44D5F3097F@rock.dv.isc.org> Message-ID: El 12/1/2017 16:28, "Mark Andrews" escribi?: In message <11ff128d-2fba-7c26-4a9c-5611433d85d2 at si6networks.com>, Fernando Gon t writes: > Hi, Saku, > > On 01/12/2017 11:43 AM, Saku Ytti wrote: > > On 12 January 2017 at 13:19, Fernando Gont wrote: > > > > Hey, > > > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > >> welcome). > > > > Generally may be understood differently by different people. If > > generally is defined as single most typical behaviour/configuration, > > then generally people don't protect their infrastructure in any way at > > all, but fully rely vendor doing something reasonable. > > > > I would argue BCP is to have 'strict' CoPP. Where you specifically > > allow what you must then have ultimate rule to deny everything. If you > > have such CoPP, then this attack won't work, as you clearly didn't > > allow any fragments at all (as you didn't expect to receive BGP > > fragments from your neighbours). > > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. And fragments are a *normal* part of IP for both IPv4 and IPv6. This obsession with dropping all fragments (and yes it is a obsession) is breaking the internet. Vendors got the frag reassembly code wrong so many times , that I understand the folk that decides to drop them if deemed unnecessary. Even if you don't want to allow all fragments through you can allow fragments between the two endpoints of a "active" connection. At times folks want to get rid of fragments directed to them, rather than those going *through* them. You can apply port filters to the offset 0 fragments. If that fragment doesn't have enough headers to be able to filter then drop it. If your firewall is incapable of doing this then find a better firewall as the current one is a piece of garbage and should be in the recycle bin. Which DoS is the bigger issue? Firewalls dropping fragments or reassembly buffers being exhausted? If there is no way for an attacker to trigger the use of fragmentation, and you don't need fragments (e.g. only tcp-based services), from a security pov you're certainly better off dropping frags that are thrown at you. Not that I like it, but.... Thanks, Fernando From fgont at si6networks.com Thu Jan 12 20:19:42 2017 From: fgont at si6networks.com (Fernando Gont) Date: Thu, 12 Jan 2017 17:19:42 -0300 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> Message-ID: El 12/1/2017 16:32, "Saku Ytti" escribi?: On 12 January 2017 at 17:02, Fernando Gont wrote: > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. Thanks. I think I got it now. Best I can offer is that B could try to verify the embedded original packet? Hopefully attacker won't have access to that information. An if attacker has access to that information, they may as well do TCP RST, right? Didn't we have same issues in IPv4 with ICMP unreachable and frag neeeded, DF set? And vendors implemented more verification if the ICMP message should be accepted. Yes and no. 1) there was no way in v4 to trigger use of fragmentation for an arbitrary flow. 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. In ipv6, you aren't (think ipv6 EHs) Thanks, Fernando From JKrejci at usinternet.com Thu Jan 12 20:32:44 2017 From: JKrejci at usinternet.com (Justin Krejci) Date: Thu, 12 Jan 2017 20:32:44 +0000 Subject: BGP Route Reflector - Route Server, Router, etc Message-ID: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Nanog, I am working on some network designs and am adding some additional routers to a BGP network. I'd like to build a plan of changing all of the existing routers over from full iBGP mesh to something more scalable (ie route reflection). Fortunately, I am also going to be able to decommission some older routers from the network and so shrinking the existing iBGP full mesh is something I am all too happy to spend time and energy on. For the purpose of this thread though, I am not really interested in the route reflector vs confederation discussion. In doing some research[1][2][3][4][5] I see a lot of discussions, config examples, etc on using route reflectors but most suggest picking a router, or more appropriately a set of routers, to become route reflectors within an ASN. I have not found many resources discussing using a non-router box as a route reflector (ie a device not necessarily in the forwarding path of the through traffic). I am thinking things like OpenBGPd and BIRD could make a good route reflector though they are most often discussed in the context of IXPs (ie eBGP sessions). I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? Use a few existing live routers and just add the responsibility of being route reflectors, is there a performance hit? Install and run BIRD on new server hardware? Buy some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as route reflectors and add them to the iBGP topology? GNS3 running IOS on server hardware? Something else? How many reflectors should be implemented? Two? Four? What are the pros and cons of one design over another? On list or private off list replies would be great; I'd welcome real world experiences (especially any big gotchas or caveats people learned the hard way) as well as just links to previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion that covers this topic would be appreciated. [1] - iBGP-to-RR migration slideshow: http://meetings.ripe.net/ripe-42/presentations/ripe42-eof-bgp/sld015.html [2] - General RR design issues: http://www.netcraftsmen.com/bgp-route-reflector-design-issues/ [3] - Video intro to RR from Cisco: http://www.cisco.com/c/dam/en_us/training-events/le31/le46/cln/qlm/CCIP/bgp/introducing-route-reflectors-2/player.html [4] - Quagga and BIRD as RR example: https://bsdrp.net/documentation/examples/bgp_route_reflector_and_confederation_using_quagga_and_bird [5] - Countless hours on youtube: https://www.youtube.com/results?search_query=bgp+route+reflector Lots more data is out there of course as that is part of my problem. Thanks! Justin From lukasz at bromirski.net Thu Jan 12 22:41:20 2017 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Thu, 12 Jan 2017 23:41:20 +0100 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: > On 12 Jan 2017, at 21:32, Justin Krejci wrote: > > Nanog, > [?] You did some homework. In essence, there?s no immediate problem with running Quagga or OpenBGPd as RR apart from lack of different knobs and not-so-stellar performance/scalability. BIRD is grounds up built to act as high-performance BGP daemon, and it?s actually used as RR in live deployments, not only at IXes. > I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? Use a few existing live routers and just add the responsibility of being route reflectors, is there a performance hit? Install and run BIRD on new server hardware? Buy some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as route reflectors and add them to the iBGP topology? GNS3 running IOS on server hardware? Something else? How many reflectors should be implemented? Two? Four? Disclaimer: I work at Cisco. If You have some 7200VXRs that have 1 or 2GBs of RAM, that may be the best option (IF you have them). Loaded with 12.2S/15S software they may actually be the most cost-effective solution and at the same time support things like AddPath, BGP error handling, etc - when time comes to use such features. If that?s a NPE400 based chassis or something even older - leave it for lab/etc as You need rather performant CPU. So, if that?s not the option, try to work with the BIRD, CSR 1000v (IOS-XE on VM) or ASR 1001X/HX (currently, the most scaleable and fastest BGP route reflector out there, but one that will cost $$$). Two RRs provide ample redundancy to run even very large deployments (1000+ clients), so unless you?re trying to hit higher numbers or plan to play fancy games with one pair of RRs for IPv4/IPv6 unicast and other pair for different AFs, four may be an overkill to maintain, synchronize and monitor. Don?t go with GNS3, running compiled at runtime emulation is wrong idea for any production deployment, not to mention rights/licenses to do it. ? ?ukasz Bromirski From nanog at ics-il.net Thu Jan 12 22:59:26 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 12 Jan 2017 16:59:26 -0600 (CST) Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: <315593023.4287.1484261966308.JavaMail.mhammett@ThunderFuck> Your knowledge of OpenBGPd's scalability issues may be a bit dated. 1) I'm not sure many would have run into it anyway. 2) A patch was submitted and I believe is in a stable release now. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "?ukasz Bromirski" To: "Justin Krejci" Cc: "NANOG ?[nanog at nanog.org]?" Sent: Thursday, January 12, 2017 4:41:20 PM Subject: Re: BGP Route Reflector - Route Server, Router, etc > On 12 Jan 2017, at 21:32, Justin Krejci wrote: > > Nanog, > [?] You did some homework. In essence, there?s no immediate problem with running Quagga or OpenBGPd as RR apart from lack of different knobs and not-so-stellar performance/scalability. BIRD is grounds up built to act as high-performance BGP daemon, and it?s actually used as RR in live deployments, not only at IXes. > I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? Use a few existing live routers and just add the responsibility of being route reflectors, is there a performance hit? Install and run BIRD on new server hardware? Buy some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as route reflectors and add them to the iBGP topology? GNS3 running IOS on server hardware? Something else? How many reflectors should be implemented? Two? Four? Disclaimer: I work at Cisco. If You have some 7200VXRs that have 1 or 2GBs of RAM, that may be the best option (IF you have them). Loaded with 12.2S/15S software they may actually be the most cost-effective solution and at the same time support things like AddPath, BGP error handling, etc - when time comes to use such features. If that?s a NPE400 based chassis or something even older - leave it for lab/etc as You need rather performant CPU. So, if that?s not the option, try to work with the BIRD, CSR 1000v (IOS-XE on VM) or ASR 1001X/HX (currently, the most scaleable and fastest BGP route reflector out there, but one that will cost $$$). Two RRs provide ample redundancy to run even very large deployments (1000+ clients), so unless you?re trying to hit higher numbers or plan to play fancy games with one pair of RRs for IPv4/IPv6 unicast and other pair for different AFs, four may be an overkill to maintain, synchronize and monitor. Don?t go with GNS3, running compiled at runtime emulation is wrong idea for any production deployment, not to mention rights/licenses to do it. ? ?ukasz Bromirski From jwbensley at gmail.com Thu Jan 12 22:59:21 2017 From: jwbensley at gmail.com (James Bensley) Date: Thu, 12 Jan 2017 22:59:21 +0000 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: On 12 January 2017 at 20:32, Justin Krejci wrote: > . I have not found many resources discussing using a non-router box as a route reflector (ie a device not necessarily in the forwarding path of the through traffic). I am thinking things like OpenBGPd and BIRD could make a good route reflector though they are most often discussed in the context of IXPs (ie eBGP sessions). The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are deploying these in production and its increasing in popularity. Mark Tinka gave a good preso at a recent Nanog: https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_Route_Reflection.pdf https://www.youtube.com/watch?v=wLEjOj2fyp8&list=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg&index=21 Cheers, James. From emille at abccommunications.com Fri Jan 13 00:25:47 2017 From: emille at abccommunications.com (Emille Blanc) Date: Thu, 12 Jan 2017 16:25:47 -0800 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5E0A4EF2@exchange> > I am thinking things like OpenBGPd and BIRD could make a good route reflector though they are most often discussed in the context of IXPs (ie eBGP sessions). We use openbgpd - well, the native OpenBSD equivalent - for route-reflection in a couple of places, as well as a full bgp feed for at least one site, using (old) Poweredge 1950 Gen2's. They were on-hand, so the price was right. It's not caused us any grief to date. That said, neither have our 7204VXR's which do the same thing in some areas. Needless to say, we don't use the reflectors to actually move the bits, but have at least on one occasion measured ~88,000pp/s out of one of the 1950's that takes a full feed, before interrupts were starting to look worrisome on old non-smp safe code. But switches with bgp or ospf support are cheap provided you're not feeding them with a full table. Convergence times haven't been a problem for us, but we're only hovering around 1500 routes at the moment. Having something you can tcpdump on is nice for the few situations that call for it, pf is always extremely handy, re-distributing to/from ospfd is trivial (also in OpenBSD base). As long as you can find hardware with memory enough to scale to your number of routes, it's been a perfectly valid and sound option for us. My 5 cents. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Krejci Sent: January-12-17 12:33 PM To: NANOG ?[nanog at nanog.org]? Subject: BGP Route Reflector - Route Server, Router, etc Nanog, I am working on some network designs and am adding some additional routers to a BGP network. I'd like to build a plan of changing all of the existing routers over from full iBGP mesh to something more scalable (ie route reflection). Fortunately, I am also going to be able to decommission some older routers from the network and so shrinking the existing iBGP full mesh is something I am all too happy to spend time and energy on. For the purpose of this thread though, I am not really interested in the route reflector vs confederation discussion. In doing some research[1][2][3][4][5] I see a lot of discussions, config examples, etc on using route reflectors but most suggest picking a router, or more appropriately a set of routers, to become route reflectors within an ASN. I have not found many resources discussing using a non-router box as a route reflector (ie a device not necessarily in the forwarding path of the through traffic). I am thinking things like OpenBGPd and BIRD could make a good route reflector though they are most often discussed in the context of IXPs (ie eBGP sessions). I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? Use a few existing live routers and just add the responsibility of being route reflectors, is there a performance hit? Install and run BIRD on new server hardware? Buy some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as route reflectors and add them to the iBGP topology? GNS3 running IOS on server hardware? Something else? How many reflectors should be implemented? Two? Four? What are the pros and cons of one design over another? On list or private off list replies would be great; I'd welcome real world experiences (especially any big gotchas or caveats people learned the hard way) as well as just links to previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion that covers this topic would be appreciated. [1] - iBGP-to-RR migration slideshow: http://meetings.ripe.net/ripe-42/presentations/ripe42-eof-bgp/sld015.html [2] - General RR design issues: http://www.netcraftsmen.com/bgp-route-reflector-design-issues/ [3] - Video intro to RR from Cisco: http://www.cisco.com/c/dam/en_us/training-events/le31/le46/cln/qlm/CCIP/bgp/introducing-route-reflectors-2/player.html [4] - Quagga and BIRD as RR example: https://bsdrp.net/documentation/examples/bgp_route_reflector_and_confederation_using_quagga_and_bird [5] - Countless hours on youtube: https://www.youtube.com/results?search_query=bgp+route+reflector Lots more data is out there of course as that is part of my problem. Thanks! Justin From marka at isc.org Fri Jan 13 02:07:41 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 13 Jan 2017 13:07:41 +1100 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: Your message of "Thu, 12 Jan 2017 17:17:22 -0300." References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> <20170112192845.BD44D5F3097F@rock.dv.isc.org> Message-ID: <20170113020741.63FAC5F4B3FF@rock.dv.isc.org> In message , Fernando Gont writes: > El 12/1/2017 16:28, "Mark Andrews" escribi=C3=B3: > > > In message <11ff128d-2fba-7c26-4a9c-5611433d85d2 at si6networks.com>, Fernando Gont writes: > > > Hi, Saku, > > > > > > On 01/12/2017 11:43 AM, Saku Ytti wrote: > > > > On 12 January 2017 at 13:19, Fernando Gont > > wrote: > > > > > > > > Hey, > > > > > > > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > > > >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > > > >> welcome). > > > > > > > > Generally may be understood differently by different people. If > > > > generally is defined as single most typical behaviour/configuration, > > > > then generally people don't protect their infrastructure in any way at > > > > all, but fully rely vendor doing something reasonable. > > > > > > > > I would argue BCP is to have 'strict' CoPP. Where you specifically > > > > allow what you must then have ultimate rule to deny everything. If you > > > > have such CoPP, then this attack won't work, as you clearly didn't > > > > allow any fragments at all (as you didn't expect to receive BGP > > > > fragments from your neighbours). > > > > > > That's the point: If you don't allow fragments, but your peer honors > > > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > > > > And fragments are a *normal* part of IP for both IPv4 and IPv6. > > This obsession with dropping all fragments (and yes it is a obsession) > > is breaking the internet. > > Vendors got the frag reassembly code wrong so many times , that I > understand the folk that decides to drop them if deemed unnecessary. Most of them literally decades ago. 20+ years ago while you waited for you vendor to fix the bug it made some sense as most of your boxes were vulnerable. It was a new threat back then. It doesn't make sense today. Packet bigger than 1500 are a part of todays internet. Have a look a the stats for dropped fragments. They aren't for the most part attack traffic. Its legitmate reply traffic that has been requested. > > Even if you don't want to allow all fragments through you can allow > > fragments between the two endpoints of a "active" connection. > > > > > At times folks want to get rid of fragments directed to them, rather than > > those going *through* them. > > > > > > You > > can apply port filters to the offset 0 fragments. If that fragment > > doesn't have enough headers to be able to filter then drop it. If > > your firewall is incapable of doing this then find a better firewall > > as the current one is a piece of garbage and should be in the recycle > > bin. > > > Which DoS is the bigger issue? Firewalls dropping fragments or > > reassembly buffers being exhausted? > > > > If there is no way for an attacker to trigger the use of fragmentation, and > > you don't need fragments (e.g. only tcp-based services), from a security > > pov you're certainly better off dropping frags that are thrown at you. Not > > that I like it, but.... > > Thanks, > Fernando > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Fri Jan 13 02:14:50 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 13 Jan 2017 13:14:50 +1100 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: Your message of "Thu, 12 Jan 2017 17:19:42 -0300." References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> Message-ID: <20170113021450.E105B5F4B4B7@rock.dv.isc.org> In message , Fernando Gont writes: > El 12/1/2017 16:32, "Saku Ytti" escribi=C3=B3: > > On 12 January 2017 at 17:02, Fernando Gont wrote: > > That's the point: If you don't allow fragments, but your peer honors > > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > > Thanks. I think I got it now. Best I can offer is that B could try to > verify the embedded original packet? Hopefully attacker won't have > access to that information. An if attacker has access to that > information, they may as well do TCP RST, right? > > Didn't we have same issues in IPv4 with ICMP unreachable and frag > neeeded, DF set? And vendors implemented more verification if the ICMP > message should be accepted. > > > Yes and no. > > 1) there was no way in v4 to trigger use of fragmentation for an arbitrary > flow. > > 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. > In ipv6, you aren't (think ipv6 EHs) So drop the packet if you don't get to the end of the extension headers in the ICMPv6 payload. Has anyone, except in testing, seen a extension header chain that was not fully containable in the ICMPv6 payload? Mark > Thanks, > Fernando -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lane.powers at swat.coop Thu Jan 12 14:32:18 2017 From: lane.powers at swat.coop (Lane Powers) Date: Thu, 12 Jan 2017 08:32:18 -0600 Subject: Apple Caching Server question Message-ID: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> From James at arenalgroup.co Thu Jan 12 21:26:39 2017 From: James at arenalgroup.co (James Breeden) Date: Thu, 12 Jan 2017 21:26:39 +0000 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: Justin, Fusion has run Route Reflection for some time as we didn't want to play full mesh. Our current design is that we have 2 routers that are designated as the route reflectors, and every other router maintains RR sessions with those. There is no real additional overhead as the BGP transactions and messaging are handled at the management plane of most routers, not the routing plane. Ours are directly on our Brocade MLXe. As we are scaling past the initial build, we are running into certain minor routing hiccups dealing with remote routers sometime preferring routes from the reflectors vs their closer routes. We found this to be a function of ingesting transit and default routes directly into route reflector routers and that those routes tended to get preferred in the table than routes from other routers in the network. Our answer to this and what we are deploying this year is that we are picking a site per time zone to be a Route Reflector, which will give us 4 RRs in the states, but we will not use sites that are Transit ingest sites. This way we are more balancing the BGP table across the entire network. Also, I believe we will move to default-free status this year with this same move. Happy to discuss more indepth offlist if you'd like. ?-- James Breeden The Fusion Network jwb at gotfusion.net fusion 844.548.1421 direct 512.360.0000 cell 512.304.0745 www.gotfusion.net facebook.com/gotfusion -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Krejci Sent: Thursday, January 12, 2017 2:33 PM To: NANOG ?[nanog at nanog.org]? Subject: BGP Route Reflector - Route Server, Router, etc Nanog, I am working on some network designs and am adding some additional routers to a BGP network. I'd like to build a plan of changing all of the existing routers over from full iBGP mesh to something more scalable (ie route reflection). Fortunately, I am also going to be able to decommission some older routers from the network and so shrinking the existing iBGP full mesh is something I am all too happy to spend time and energy on. For the purpose of this thread though, I am not really interested in the route reflector vs confederation discussion. In doing some research[1][2][3][4][5] I see a lot of discussions, config examples, etc on using route reflectors but most suggest picking a router, or more appropriately a set of routers, to become route reflectors within an ASN. I have not found many resources discussing using a non-router box as a route reflector (ie a device not necessarily in the forwarding path of the through traffic). I am thinking things like OpenBGPd and BIRD could make a good route reflector though they are most often discussed in the context of IXPs (ie eBGP sessions). I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? Use a few existing live routers and just add the responsibility of being route reflectors, is there a performance hit? Install and run BIRD on new server hardware? Buy some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as route reflectors and add them to the iBGP topology? GNS3 running IOS on server hardware? Something else? How many reflectors should be implemented? Two? Four? What are the pros and cons of one design over another? On list or private off list replies would be great; I'd welcome real world experiences (especially any big gotchas or caveats people learned the hard way) as well as just links to previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion that covers this topic would be appreciated. [1] - iBGP-to-RR migration slideshow: http://meetings.ripe.net/ripe-42/presentations/ripe42-eof-bgp/sld015.html [2] - General RR design issues: http://www.netcraftsmen.com/bgp-route-reflector-design-issues/ [3] - Video intro to RR from Cisco: http://www.cisco.com/c/dam/en_us/training-events/le31/le46/cln/qlm/CCIP/bgp/introducing-route-reflectors-2/player.html [4] - Quagga and BIRD as RR example: https://bsdrp.net/documentation/examples/bgp_route_reflector_and_confederation_using_quagga_and_bird [5] - Countless hours on youtube: https://www.youtube.com/results?search_query=bgp+route+reflector Lots more data is out there of course as that is part of my problem. Thanks! Justin From bengelly at gmail.com Thu Jan 12 22:55:47 2017 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Thu, 12 Jan 2017 23:55:47 +0100 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: Dear Justin, You could take a look at this presentation from Mark Tinka during last NANOG : https://m.youtube.com/watch?v=wLEjOj2fyp8 HTH. Y. > Le 12 janv. 2017 ? 23:41, ?ukasz Bromirski a ?crit : > > >> On 12 Jan 2017, at 21:32, Justin Krejci wrote: >> >> Nanog, >> [?] > > You did some homework. In essence, there?s no immediate problem with running Quagga or OpenBGPd as > RR apart from lack of different knobs and not-so-stellar performance/scalability. BIRD is grounds up built > to act as high-performance BGP daemon, and it?s actually used as RR in live deployments, not only at IXes. > >> I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? Use a few existing live routers and just add the responsibility of being route reflectors, is there a performance hit? Install and run BIRD on new server hardware? Buy some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as route reflectors and add them to the iBGP topology? GNS3 running IOS on server hardware? Something else? How many reflectors should be implemented? Two? Four? > > Disclaimer: I work at Cisco. > > If You have some 7200VXRs that have 1 or 2GBs of RAM, that may be the best option (IF you have them). > Loaded with 12.2S/15S software they may actually be the most cost-effective solution and at the same > time support things like AddPath, BGP error handling, etc - when time comes to use such features. > If that?s a NPE400 based chassis or something even older - leave it for lab/etc as You need rather > performant CPU. > > So, if that?s not the option, try to work with the BIRD, CSR 1000v (IOS-XE on VM) or ASR 1001X/HX > (currently, the most scaleable and fastest BGP route reflector out there, but one that will cost $$$). > > Two RRs provide ample redundancy to run even very large deployments (1000+ clients), so unless you?re > trying to hit higher numbers or plan to play fancy games with one pair of RRs for IPv4/IPv6 unicast > and other pair for different AFs, four may be an overkill to maintain, synchronize and monitor. > > Don?t go with GNS3, running compiled at runtime emulation is wrong idea for any production deployment, > not to mention rights/licenses to do it. > > ? > ?ukasz Bromirski From hugo at slabnet.com Fri Jan 13 04:02:07 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 12 Jan 2017 20:02:07 -0800 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: <20170113040207.GA28625@bamboo.slabnet.com> On Thu 2017-Jan-12 22:59:21 +0000, James Bensley wrote: >On 12 January 2017 at 20:32, Justin Krejci wrote: >> . I have not found many resources discussing using a non-router box as a route reflector (ie a device not necessarily in the forwarding path of the through traffic). I am thinking things like OpenBGPd and BIRD could make a good route reflector though they are most often discussed in the context of IXPs (ie eBGP sessions). > >The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are >deploying these in production and its increasing in popularity. Any thoughts on vRR vs. vMX for this use case? I see Mark called out vRR as having morphed into vMX, but AFAIK vRR is just vMX minus the forwarding plane, is targeted as an out-of-path reflector, and coexists with vMX as a different deployment option rather than having been replaced by it. I would assume that vRR should come in a few bucks lower than the vMX as a result, but I've only previously gotten quotes on vRR not vMX. >Mark Tinka gave a good preso at a recent Nanog: >https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_Route_Reflection.pdf >https://www.youtube.com/watch?v=wLEjOj2fyp8&list=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg&index=21 > >Cheers, >James. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From chris at nifry.com Fri Jan 13 08:29:42 2017 From: chris at nifry.com (Chris Russell) Date: Fri, 13 Jan 2017 08:29:42 +0000 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: <42b7ba5a332585c10be3993ef840b72f@nifry.com> > The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People > are > deploying these in production and its increasing in popularity. > > Mark Tinka gave a good preso at a recent Nanog: > > https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_Route_Reflection.pdf > > https://www.youtube.com/watch?v=wLEjOj2fyp8&list=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg&index=21 +1 , not used in production but fantastic in a couple of our lab environments Chris From jwbensley at gmail.com Fri Jan 13 11:04:01 2017 From: jwbensley at gmail.com (James Bensley) Date: Fri, 13 Jan 2017 11:04:01 +0000 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <20170113040207.GA28625@bamboo.slabnet.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> <20170113040207.GA28625@bamboo.slabnet.com> Message-ID: On 13 January 2017 at 04:02, Hugo Slabbert wrote: > > On Thu 2017-Jan-12 22:59:21 +0000, James Bensley > wrote: > >> On 12 January 2017 at 20:32, Justin Krejci wrote: >>> >>> . I have not found many resources discussing using a non-router box as a >>> route reflector (ie a device not necessarily in the forwarding path of the >>> through traffic). I am thinking things like OpenBGPd and BIRD could make a >>> good route reflector though they are most often discussed in the context of >>> IXPs (ie eBGP sessions). >> >> >> The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are >> deploying these in production and its increasing in popularity. > > > Any thoughts on vRR vs. vMX for this use case? I see Mark called out vRR as > having morphed into vMX, but AFAIK vRR is just vMX minus the forwarding > plane, is targeted as an out-of-path reflector, and coexists with vMX as a > different deployment option rather than having been replaced by it. I would > assume that vRR should come in a few bucks lower than the vMX as a result, > but I've only previously gotten quotes on vRR not vMX. > > >> Mark Tinka gave a good preso at a recent Nanog: >> >> https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_Route_Reflection.pdf >> >> https://www.youtube.com/watch?v=wLEjOj2fyp8&list=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg&index=21 >> >> Cheers, >> James. > > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal Sorry I don't know about the pricing, but the newer vMX product is now split into two VMs, the virtual control plane and virtual forwarding plane. I think the vRR product is still like the "older" style vMX which was one combined control and forwarding plane image. At a guess, perhaps its heavy throughput limited? We have used the "older" style vMX images in the lab (14.something) which is the combined all in one VM, it works fine for us for actual network traffic testing as well as various BGP tests like router reflectors so I see know reason why it wouldn't work as a vRR. I think the actual "vRR" product from Juniper is just a more light weight VM, perhaps someone can clarify the tech behind it? We don't have any virtual RRs in production yet but we are running CSR1000v in lab tests right now which is working fine for us so we'll probably push that out to prod at some point in both scenarios (as an in path virtual router and out of path virtual route-reflector) but that is 12+ months away as we still have lots more testing to do. Cheers, James. From bedard.phil at gmail.com Fri Jan 13 13:02:49 2017 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 13 Jan 2017 08:02:49 -0500 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> <20170113040207.GA28625@bamboo.slabnet.com> Message-ID: <850590D6-740C-42B7-9BEE-B726F091C915@gmail.com> The vRR image and the vMX have always been separate. The vRR image is what Juniper sells as a solution for control-plane only applications like vRR. It?s also the image they run as part of their Northstar controller to speak BGP-LS to the network. It?s very lightweight, you can run a bunch of them in very little memory space, for instance if you want to do a vRR per AFI/SAFI, or service. I?ve tested it against the vMX in applications like vRR and the performance is pretty much identical with much less memory/cpu use. Cisco makes a distinction between IOS-XRv which is their simulation/test version of XR like you would find in VIRL/CML and the XRv-9000 which is optimized for higher throughput. They sell a vRR-specific version of the XRv-9000 that is very reasonably priced. XRv-9000 is a bit more cpu/memory intensive in my experience. Nokia also has a vRR version of their SR-OS virtual router. It has a lightweight cpu/memory footprint and is very fast. But really all of the virtual vRR solutions are fast and scale very high, little performance difference between them. I would recommend one based on the vendors you are most comfortable with and support for the AFI/SAFIs you are interested in. Phil -----Original Message----- From: NANOG on behalf of James Bensley Date: Friday, January 13, 2017 at 06:04 To: "NANOG ?[nanog at nanog.org]?" Subject: Re: BGP Route Reflector - Route Server, Router, etc On 13 January 2017 at 04:02, Hugo Slabbert wrote: > > On Thu 2017-Jan-12 22:59:21 +0000, James Bensley > wrote: > >> On 12 January 2017 at 20:32, Justin Krejci wrote: >>> >>> . I have not found many resources discussing using a non-router box as a >>> route reflector (ie a device not necessarily in the forwarding path of the >>> through traffic). I am thinking things like OpenBGPd and BIRD could make a >>> good route reflector though they are most often discussed in the context of >>> IXPs (ie eBGP sessions). >> >> >> The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are >> deploying these in production and its increasing in popularity. > > > Any thoughts on vRR vs. vMX for this use case? I see Mark called out vRR as > having morphed into vMX, but AFAIK vRR is just vMX minus the forwarding > plane, is targeted as an out-of-path reflector, and coexists with vMX as a > different deployment option rather than having been replaced by it. I would > assume that vRR should come in a few bucks lower than the vMX as a result, > but I've only previously gotten quotes on vRR not vMX. > > >> Mark Tinka gave a good preso at a recent Nanog: >> >> https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_Route_Reflection.pdf >> >> https://www.youtube.com/watch?v=wLEjOj2fyp8&list=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg&index=21 >> >> Cheers, >> James. > > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal Sorry I don't know about the pricing, but the newer vMX product is now split into two VMs, the virtual control plane and virtual forwarding plane. I think the vRR product is still like the "older" style vMX which was one combined control and forwarding plane image. At a guess, perhaps its heavy throughput limited? We have used the "older" style vMX images in the lab (14.something) which is the combined all in one VM, it works fine for us for actual network traffic testing as well as various BGP tests like router reflectors so I see know reason why it wouldn't work as a vRR. I think the actual "vRR" product from Juniper is just a more light weight VM, perhaps someone can clarify the tech behind it? We don't have any virtual RRs in production yet but we are running CSR1000v in lab tests right now which is working fine for us so we'll probably push that out to prod at some point in both scenarios (as an in path virtual router and out of path virtual route-reflector) but that is 12+ months away as we still have lots more testing to do. Cheers, James. From rblayzor.bulk at inoc.net Fri Jan 13 13:09:19 2017 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Fri, 13 Jan 2017 08:09:19 -0500 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: <4157AB47-FADA-4056-B460-292C717B5344@inoc.net> On Jan 12, 2017, at 5:59 PM, James Bensley wrote: > > The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are > deploying these in production and its increasing in popularity. +1 here on the CSR1000v, works very well. However, I?d have to give another +1 to XRv because RPL is more flexible and easier to manage than route-maps in IOS. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu From bicknell at ufp.org Fri Jan 13 13:23:04 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 13 Jan 2017 05:23:04 -0800 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: <20170113132304.GA74131@ussenterprise.ufp.org> In a message written on Thu, Jan 12, 2017 at 08:32:44PM +0000, Justin Krejci wrote: > I am working on some network designs and am adding some additional routers to a BGP network. I'd like to build a plan of changing all of the existing routers over from full iBGP mesh to something more scalable (ie route reflection). You might want to better define "scalable". I don't know your background or network so I can't guess. I can say I've seen the inner workings of some large ISP networks with a lot of hosts in iBGP that work fine, and then people with 5 routers try and tell me they have a scaling problem. What is your actual problem? Memory usage? Convergence time? Configuring the sessions? Staff understanding of how it works? > I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? This is a red flag to me, relative to the questions above. The 7206VXR, even with an NPE-G2, is a 1.5Ghz Power PC with a paltry 2GB of DRAM. It was not speedy when new, being roughly equivilent to the PowerPC G4 processors in Apple Laptops at the time. It is approximately 8 times slower than a current iPhone. Seriously. If convergence time is anything you care about, a 7206VXR is a very bad choice. It may also run out of memory if you have a lot of edges with full tables. So what's the actual "scaling" problem? -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From lane.powers at swat.coop Fri Jan 13 13:43:58 2017 From: lane.powers at swat.coop (lane.powers at swat.coop) Date: Fri, 13 Jan 2017 07:43:58 -0600 (CST) Subject: Apple Caching Server question In-Reply-To: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> Message-ID: <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> I saw the apple caching server mentioned on an earlier thread. Is this appropriate/functional/scaleable enough to implement as an ISP? It is an intriguing idea. From the docs I could find, I couldn't tell if it was only geared towards home / small business or if it could scale up to handle ISP level traffic. thanks, Lane From invite at eventbrite.com Fri Jan 13 15:08:54 2017 From: invite at eventbrite.com (St. Louis Regional Internet Exchange) Date: Fri, 13 Jan 2017 07:08:54 -0800 (PST) Subject: You're invited to St. Louis Regional Internet Exchange - Preview (Jan 19, 2017) Message-ID: <20170113150854.5BE404A0E9@prod-task-app8.aws-us-east-1.evbops.com> The St. Louis region to benefit from improved digital capacity and Smart City infrastructure capability.   To help address the demands of data oriented businesses and startups, the Internet of Things (IoT) and the Smart City, a team of industry recognized experts has developed the St. Louis Regional Internet Exchange or STL-RIX.   The St Louis Regional Internet Exchange is a not for profit corporation, in a collaborative partnership with the Smart City Internet Exchange (SCIX), the MidWest Internet Exchange and the St. Louis region.   When operational in February, this capability will provide an unprecedented opportunity for business collaboration, and Smart City economic development, for the St. Louis region.   Lightning Round Agenda: 10:30 AM Welcome - Owen Graham - Netrality Properties Keynote - Jerry Cox CEO Blendics and Founder of SLIAC Smart City St. Louis - Jim Highfill and David Sandel - Founders of Innovation Neighborhoods Business Structure - Andrew Ruben - PAULE, CAMAZINE & BLUMENTHAL, P.C Brief Tech and Ops Description - Mike Hammett and Justin Wilson (MIX), Nathan Schrenk (STL-RIX, SCIX) Market Perspective - Moderator: Noted Technical Writer David Strom, Ken Owens Cisco CTO Cloud Platforms and Services Group, Joe Wojtal VP SP Solutions WWT, Ken Harrington BayBerry Group, Richard Schreier Canadian Internet Registration Authority 11:40 AM Panel and Press - General Q&A Official Press Release Share this event on Facebook and Twitter We hope you can make it!Cheers,St. Louis Regional Internet Exchange ------------------------------ Event Summary: ------------------------------ Event: St. Louis Regional Internet Exchange - Preview Date: Thursday, January 19, 2017 from 10:30 AM to 12:00 PM (CST) Location: <b>CIC - The Havana Room</b><br />4240 Duncan Avenue <br />St. Louis, MO 63110<br /> ------------------------------ Event Details: ------------------------------ The St. Louis region to benefit from improved digital capacity and Smart City infrastructure capability. To help address the demands of data oriented businesses and startups, the Internet of Things (IoT) and the Smart City, a team of industry recognized experts has developed the St. Louis Regional Internet Exchange or STL-RIX. The St Louis Regional Internet Exchange is a not for profit corporation, in a collaborative partnership with the Smart City Internet Exchange (SCIX), the?MidWest Internet Exchange and the St. Louis region. When operational in February, this capability will provide an unprecedented opportunity for business collaboration, and Smart City economic development, for the St. Louis region. Lightning Round Agenda: 10:30 AM Welcome - Owen Graham - Netrality Properties Keynote - Jerry Cox CEO Blendics and Founder of SLIAC Smart City St. Louis?- Jim Highfill and David Sandel - Founders of Innovation Neighborhoods Business Structure - Andrew Ruben -?PAULE, CAMAZINE & BLUMENTHAL, P.C Brief Tech and Ops Description - Mike Hammett and Justin Wilson (MIX), Nathan Schrenk (STL-RIX, SCIX) Market Perspective - Moderator: Noted Technical Writer David Strom,?Ken Owens Cisco CTO Cloud Platforms and Services Group, Joe Wojtal VP SP Solutions WWT, Ken Harrington BayBerry Group, Richard Schreier Canadian Internet Registration Authority 11:40 AM Panel and Press?- General Q&A Official Press Release ------------------------------ Hosted By: ------------------------------ St. Louis Regional Internet Exchange The St Louis Regional Internet Exchange (STL-RIX), is a not-for-profit corporation in a collaborative partnership with the Midwest Internet Exchange (MIX), and Smart City Internet Exchange (SCIX). STL-RIX offers both traditional IX services as well as an additional switch fabric for the provisioning of Smart City and (IoT) services. ------------------------------ Register Online: ------------------------------ More information and online registration are available here: https://www.eventbrite.com/e/st-louis-regional-internet-exchange-preview-tickets-30329718003?ref=enivtefor001&invite=MTEzNDMwMjUvbmFub2dAbmFub2cub3JnLzA%3D ---------------------------------------------------------------------- Collect event fees online with Eventbrite http://www.eventbrite.com From joelja at bogus.com Fri Jan 13 16:45:08 2017 From: joelja at bogus.com (joel jaeggli) Date: Fri, 13 Jan 2017 08:45:08 -0800 Subject: Apple Caching Server question In-Reply-To: <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> Message-ID: <92fc8e67-3301-b5a1-c700-1d89dcc7ebd3@bogus.com> On 1/13/17 5:43 AM, lane.powers at swat.coop wrote: > I saw the apple caching server mentioned on an earlier thread. Is this appropriate/functional/scaleable enough to implement as an ISP? It is an intriguing idea. From the docs I could find, I couldn't tell if it was only geared towards home / small business or if it could scale up to handle ISP level traffic. It's a feature of macos server. You do get to register prefix with apple, but I don't imagine colocating a mac mini is isp level traffic. That said as714 peers extensively https://www.peeringdb.com/net/3554 so picking them up works too. > thanks, > Lane > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From blake at ispn.net Fri Jan 13 17:25:14 2017 From: blake at ispn.net (Blake Hudson) Date: Fri, 13 Jan 2017 11:25:14 -0600 Subject: Apple Caching Server question In-Reply-To: <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> Message-ID: lane.powers at swat.coop wrote on 1/13/2017 7:43 AM: > I saw the apple caching server mentioned on an earlier thread. Is this appropriate/functional/scaleable enough to implement as an ISP? It is an intriguing idea. From the docs I could find, I couldn't tell if it was only geared towards home / small business or if it could scale up to handle ISP level traffic. > > thanks, > Lane I have no experience with the Apple caching service specifically, but I have used Apple products (including some of their server software) for decades. Apple used to make mac mini models exclusively for server use. Their low power draw and relatively high density makes them an interesting choice for those that don't mind using "desktop grade" hardware for a project. There are some folks that even make rack-mount solutions for the Mac mini and Mac pro (search for RackMac). That said, my experience with several mac minis is that you will have at least one fault that will put them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3 year period when ran 24/7. With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect a mac mini to be as fast or faster than most other network appliances one might purchase. If one wanted something beefier, a mac pro would probably offer some expandability (on board dual 1gbps NICs + six 20Gbps thunderbolt 2 ports). I would see why one might be curious, especially if this could cache the IOS updates used for all those tablets and other iDevices folks purchase from Apple. From cscora at apnic.net Fri Jan 13 18:01:46 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Jan 2017 04:01:46 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170113180146.D6595C4501@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 14 Jan, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 628138 Prefixes after maximum aggregation (per Origin AS): 221607 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 304580 Total ASes present in the Internet Routing Table: 55581 Prefixes per ASN: 11.30 Origin-only ASes present in the Internet Routing Table: 36240 Origin ASes announcing only one prefix: 15211 Transit ASes present in the Internet Routing Table: 6557 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 55 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 51 Unregistered ASNs in the Routing Table: 16 Number of 32-bit ASNs allocated by the RIRs: 16861 Number of 32-bit ASNs visible in the Routing Table: 12784 Prefixes from 32-bit ASNs in the Routing Table: 52671 Number of bogon 32-bit ASNs visible in the Routing Table: 725 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 381 Number of addresses announced to Internet: 2832873956 Equivalent to 168 /8s, 218 /16s and 57 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 208158 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156458 Total APNIC prefixes after maximum aggregation: 43125 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 171200 Unique aggregates announced from the APNIC address blocks: 70946 APNIC Region origin ASes present in the Internet Routing Table: 5188 APNIC Prefixes per ASN: 33.00 APNIC Region origin ASes announcing only one prefix: 1135 APNIC Region transit ASes present in the Internet Routing Table: 941 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 55 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2610 Number of APNIC addresses announced to Internet: 761620356 Equivalent to 45 /8s, 101 /16s and 103 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188178 Total ARIN prefixes after maximum aggregation: 89286 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195218 Unique aggregates announced from the ARIN address blocks: 89636 ARIN Region origin ASes present in the Internet Routing Table: 16064 ARIN Prefixes per ASN: 12.15 ARIN Region origin ASes announcing only one prefix: 5595 ARIN Region transit ASes present in the Internet Routing Table: 1718 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1702 Number of ARIN addresses announced to Internet: 1104227488 Equivalent to 65 /8s, 209 /16s and 44 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 151356 Total RIPE prefixes after maximum aggregation: 73249 RIPE Deaggregation factor: 2.07 Prefixes being announced from the RIPE address blocks: 162799 Unique aggregates announced from the RIPE address blocks: 99050 RIPE Region origin ASes present in the Internet Routing Table: 18151 RIPE Prefixes per ASN: 8.97 RIPE Region origin ASes announcing only one prefix: 7762 RIPE Region transit ASes present in the Internet Routing Table: 3050 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5104 Number of RIPE addresses announced to Internet: 709410176 Equivalent to 42 /8s, 72 /16s and 189 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 64045 Total LACNIC prefixes after maximum aggregation: 12654 LACNIC Deaggregation factor: 5.06 Prefixes being announced from the LACNIC address blocks: 80795 Unique aggregates announced from the LACNIC address blocks: 37929 LACNIC Region origin ASes present in the Internet Routing Table: 2483 LACNIC Prefixes per ASN: 32.54 LACNIC Region origin ASes announcing only one prefix: 548 LACNIC Region transit ASes present in the Internet Routing Table: 592 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3082 Number of LACNIC addresses announced to Internet: 171021888 Equivalent to 10 /8s, 49 /16s and 150 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15378 Total AfriNIC prefixes after maximum aggregation: 3286 AfriNIC Deaggregation factor: 4.68 Prefixes being announced from the AfriNIC address blocks: 17745 Unique aggregates announced from the AfriNIC address blocks: 6672 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 24.11 AfriNIC Region origin ASes announcing only one prefix: 171 AfriNIC Region transit ASes present in the Internet Routing Table: 186 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 286 Number of AfriNIC addresses announced to Internet: 86134016 Equivalent to 5 /8s, 34 /16s and 77 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5544 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3731 390 255 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2731 11133 742 KIXS-AS-KR Korea Telecom, KR 9829 2684 1498 535 BSNL-NIB National Internet Backbone, IN 9808 2296 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2047 428 217 TATACOMM-AS TATA Communications formerl 45899 1808 1265 100 VNPT-AS-VN VNPT Corp, VN 4808 1638 1790 453 CHINA169-BJ China Unicom Beijing Provin 24560 1561 562 245 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3613 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3256 1333 82 SHAW - Shaw Communications Inc., CA 18566 2194 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2094 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1959 2023 403 CHARTER-NET-HKY-NC - Charter Communicat 209 1734 5066 637 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1721 322 436 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1678 848 227 ITCDELTA - Earthlink, Inc., US 701 1599 10629 661 UUNET - MCI Communications Services, In 16509 1520 3028 521 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 2995 1129 2135 AKAMAI-ASN1 , US 9121 2253 1707 94 TTNET , TR 34984 1991 327 374 TELLCOM-AS , TR 13188 1604 99 61 TRIOLAN , UA 12479 1427 1033 51 UNI2-AS , ES 6849 1312 355 22 UKRTELNET , UA 8551 1206 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 8402 1154 544 15 CORBINA-AS OJSC "Vimpelcom", RU 9198 1018 352 25 KAZTELECOM-AS , KZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3533 544 173 Telmex Colombia S.A., CO 8151 2479 3374 548 Uninet S.A. de C.V., MX 11830 1799 368 66 Instituto Costarricense de Electricidad 6503 1544 437 54 Axtel, S.A.B. de C.V., MX 7303 1525 974 254 Telecom Argentina S.A., AR 6147 1352 377 27 Telefonica del Peru S.A.A., PE 28573 1054 2271 177 CLARO S.A., BR 3816 1007 479 179 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 993 236 87 Techtel LMDS Comunicaciones Interactiva 17072 968 127 346 TOTAL PLAY TELECOMUNICACIONES SA DE CV, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1294 398 42 LINKdotNET-AS, EG 36903 703 353 122 MT-MPLS, MA 37611 679 67 6 Afrihost, ZA 36992 580 1373 25 ETISALAT-MISR, EG 24835 492 658 16 RAYA-AS, EG 8452 489 1474 16 TE-AS TE-AS, EG 37492 401 290 74 ORANGE-TN, TN 29571 368 36 10 CITelecom-AS, CI 15399 316 35 6 WANANCHI-KE, KE 2018 287 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5544 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3731 390 255 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3613 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3533 544 173 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3256 1333 82 SHAW - Shaw Communications Inc., CA 20940 2995 1129 2135 AKAMAI-ASN1 , US 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2731 11133 742 KIXS-AS-KR Korea Telecom, KR 9829 2684 1498 535 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3731 3476 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3613 3462 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3533 3360 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3256 3174 SHAW - Shaw Communications Inc., CA 17974 2984 2913 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2296 2263 CMNET-GD Guangdong Mobile Communication 9121 2253 2159 TTNET , TR 9829 2684 2149 BSNL-NIB National Internet Backbone, IN 18566 2194 2085 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom 65001 PRIVATE 94.242.128.0/20 15468 KLGELECS-AS 38, Teatralnaya st Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:532 /14:1051 /15:1789 /16:13162 /17:7788 /18:13039 /19:25193 /20:38097 /21:40682 /22:73358 /23:61448 /24:350212 /25:550 /26:406 /27:292 /28:33 /29:18 /30:17 /31:0 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3053 3256 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2814 3613 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2087 2194 MEGAPATH5-US - MegaPath Corporation, US 9121 1581 2253 TTNET , TR 30036 1536 1721 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1448 3533 Telmex Colombia S.A., CO 6389 1392 2094 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1349 1604 TRIOLAN , UA 6983 1323 1678 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1578 2:829 4:25 5:2423 6:32 8:1025 12:1811 13:71 14:1773 15:23 16:2 17:106 18:128 19:1 20:51 23:1980 24:1814 27:2402 31:1847 32:89 33:9 34:1 35:3 36:389 37:2484 38:1308 39:45 40:99 41:2890 42:452 43:1919 44:54 45:2319 46:2559 47:108 49:1203 50:948 51:17 52:619 54:355 55:6 56:4 57:40 58:1599 59:979 60:389 61:1863 62:1505 63:1933 64:4544 65:2186 66:4389 67:2223 68:1166 69:3295 70:1302 71:570 72:2055 74:2595 75:400 76:416 77:1384 78:1572 79:923 80:1364 81:1414 82:967 83:722 84:867 85:1689 86:484 87:1129 88:778 89:2041 90:197 91:6112 92:984 93:2339 94:2347 95:2779 96:567 97:360 98:937 99:97 100:148 101:1232 103:13272 104:2678 105:147 106:473 107:1511 108:767 109:2547 110:1284 111:1665 112:1146 113:1289 114:1007 115:1637 116:1712 117:1610 118:2045 119:1585 120:945 121:1073 122:2262 123:2028 124:1571 125:1819 128:732 129:502 130:421 131:1362 132:560 133:187 134:517 135:211 136:385 137:408 138:1838 139:484 140:616 141:511 142:728 143:915 144:762 145:165 146:996 147:648 148:1402 149:561 150:679 151:924 152:708 153:313 154:726 155:955 156:544 157:573 158:431 159:1353 160:567 161:734 162:2464 163:533 164:771 165:1141 166:361 167:1249 168:2456 169:721 170:2546 171:263 172:897 173:1832 174:785 175:708 176:1752 177:4143 178:2418 179:1141 180:2075 181:1964 182:2183 183:1013 184:838 185:8453 186:3241 187:2249 188:2332 189:1779 190:8168 191:1290 192:9308 193:5765 194:4557 195:3858 196:1876 197:1248 198:5606 199:5800 200:7307 201:4135 202:10041 203:9841 204:4463 205:2768 206:2965 207:3153 208:3990 209:3881 210:3879 211:2079 212:2769 213:2446 214:848 215:65 216:5782 217:1978 218:824 219:602 220:1678 221:897 222:714 223:1149 End of report From fgont at si6networks.com Fri Jan 13 19:29:43 2017 From: fgont at si6networks.com (Fernando Gont) Date: Fri, 13 Jan 2017 16:29:43 -0300 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: <20170113020741.63FAC5F4B3FF@rock.dv.isc.org> References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> <20170112192845.BD44D5F3097F@rock.dv.isc.org> <20170113020741.63FAC5F4B3FF@rock.dv.isc.org> Message-ID: On 01/12/2017 11:07 PM, Mark Andrews wrote: > In message > , Fernando Gont writes: >> El 12/1/2017 16:28, "Mark Andrews" escribi=C3=B3: >> >>> In message <11ff128d-2fba-7c26-4a9c-5611433d85d2 at si6networks.com>, Fernando Gont writes: >>>> Hi, Saku, >>>> >>>> On 01/12/2017 11:43 AM, Saku Ytti wrote: >>>>> On 12 January 2017 at 13:19, Fernando Gont >>> wrote: >>>>> >>>>> Hey, >>>>> >>>>>> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 >>>>>> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are >>>>>> welcome). >>>>> >>>>> Generally may be understood differently by different people. If >>>>> generally is defined as single most typical behaviour/configuration, >>>>> then generally people don't protect their infrastructure in any way at >>>>> all, but fully rely vendor doing something reasonable. >>>>> >>>>> I would argue BCP is to have 'strict' CoPP. Where you specifically >>>>> allow what you must then have ultimate rule to deny everything. If you >>>>> have such CoPP, then this attack won't work, as you clearly didn't >>>>> allow any fragments at all (as you didn't expect to receive BGP >>>>> fragments from your neighbours). >>>> >>>> That's the point: If you don't allow fragments, but your peer honors >>>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector. >>> >>> And fragments are a *normal* part of IP for both IPv4 and IPv6. >>> This obsession with dropping all fragments (and yes it is a obsession) >>> is breaking the internet. >> >> Vendors got the frag reassembly code wrong so many times , that I >> understand the folk that decides to drop them if deemed unnecessary. > > Most of them literally decades ago. Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been several one-packet crashes disclosed for Cisco's (an the list continues). > 20+ years ago while you waited > for you vendor to fix the bug it made some sense as most of your > boxes were vulnerable. It was a new threat back then. It doesn't > make sense today. Let's face it: The quality of many IPv6 implementations is that of IPv4 implementations in the '90s. Sad, but true. > Packet bigger than 1500 are a part of todays internet. Have a look > a the stats for dropped fragments. They aren't for the most part > attack traffic. Its legitmate reply traffic that has been requested. I don't disagree with you wrt the need for fragmentation in some scenarios. I'm just saying that when you only employ TCP-based services, it may make sense to drop fragments targeted *at you*. Fragmentation is only needed for non-TCP services. and if your system does not use non-tcp services, it may be a sensible thing to drop fragments targetted at you. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont at si6networks.com Fri Jan 13 19:35:36 2017 From: fgont at si6networks.com (Fernando Gont) Date: Fri, 13 Jan 2017 16:35:36 -0300 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: <20170113021450.E105B5F4B4B7@rock.dv.isc.org> References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> <20170113021450.E105B5F4B4B7@rock.dv.isc.org> Message-ID: <954a2fbd-580a-044b-07e7-63a0bf1bbfaa@si6networks.com> On 01/12/2017 11:14 PM, Mark Andrews wrote: > In message > , Fernando Gont writes: >> El 12/1/2017 16:32, "Saku Ytti" escribi=C3=B3: >> >> On 12 January 2017 at 17:02, Fernando Gont wrote: >>> That's the point: If you don't allow fragments, but your peer honors >>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector. >> >> Thanks. I think I got it now. Best I can offer is that B could try to >> verify the embedded original packet? Hopefully attacker won't have >> access to that information. An if attacker has access to that >> information, they may as well do TCP RST, right? >> >> Didn't we have same issues in IPv4 with ICMP unreachable and frag >> neeeded, DF set? And vendors implemented more verification if the ICMP >> message should be accepted. >> >> >> Yes and no. >> >> 1) there was no way in v4 to trigger use of fragmentation for an arbitrary >> flow. >> >> 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. >> In ipv6, you aren't (think ipv6 EHs) > > So drop the packet if you don't get to the end of the extension > headers in the ICMPv6 payload. Has anyone, except in testing, seen > a extension header chain that was not fully containable in the > ICMPv6 payload? Because of the extra IPv6+ICMPv6 headers that you need for sending the ICMP error, even if the original packet did have the entire IPv6 header chain, you might be unable to include it in the ICMPv6 payload. Yes, in practice you'd be fine dropping ICMP errors that don't embed a full payload. Whether vendors do it or not, is a different question. FWIW, it took me 6 years to publish RFC5927. And, because folks *opposed* to it in tcpm wg, it was published as Informational, rather than Std Track. RFC4443 points to it, still as informational thing that you might want to do. If we don't convey the right message in specs, not sure we can expect good implementations, and even less flame the folk that tries to run his network in the best possible way with "what he gets". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From JKrejci at usinternet.com Fri Jan 13 22:12:42 2017 From: JKrejci at usinternet.com (Justin Krejci) Date: Fri, 13 Jan 2017 22:12:42 +0000 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <20170113132304.GA74131@ussenterprise.ufp.org> References: <3E9C67DA261AC349B60FF3609F5E211D7D804324@USI-2K10EX02-MT.usicorp.usinternet.com> <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com>, <20170113132304.GA74131@ussenterprise.ufp.org> Message-ID: <587950dd.e8199d0a.8a03c.7bc6SMTPIN_ADDED_BROKEN@mx.google.com> Thanks for all of the replies (on and off list). It is appreciated. Scaling in this context is simply adding more and more routers and needing/wanting to avoid configuring full mesh iBGP due to the administrative burden of maintaining the growing size of full mesh topology. In one particular network in question, I have 11 routers fully meshed and need to add several more over the coming 6-12 months, possibly adding as many as 10 more routers in that time span. I'd prefer not to continue doing full mesh. As for 7206VXR with NPE-G1 or G2 cards, we have many sitting in a decommissioned state on shelves as well as a few still alive serving a handful of T-1 lines and various other legacy connections of that sort. These little 7200's sit and run, forever near as I can tell. As many routers in this network do contain full route eBGP connections I will strongly consider your suggestion of avoiding using the 7200's due to potential memory constraints and CPU/convergence time capabilities. I don't think I have done any full table feeds on a 7200 in many years (days of 200k-300k table size days) This fits in with the kind of feedback I was hoping for, Thanks! ________________________________________ From: NANOG [nanog-bounces at nanog.org] on behalf of Leo Bicknell [bicknell at ufp.org] Sent: Friday, January 13, 2017 7:23 AM To: nanog at nanog.org Subject: Re: BGP Route Reflector - Route Server, Router, etc In a message written on Thu, Jan 12, 2017 at 08:32:44PM +0000, Justin Krejci wrote: > I am working on some network designs and am adding some additional routers to a BGP network. I'd like to build a plan of changing all of the existing routers over from full iBGP mesh to something more scalable (ie route reflection). You might want to better define "scalable". I don't know your background or network so I can't guess. I can say I've seen the inner workings of some large ISP networks with a lot of hosts in iBGP that work fine, and then people with 5 routers try and tell me they have a scaling problem. What is your actual problem? Memory usage? Convergence time? Configuring the sessions? Staff understanding of how it works? > I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? This is a red flag to me, relative to the questions above. The 7206VXR, even with an NPE-G2, is a 1.5Ghz Power PC with a paltry 2GB of DRAM. It was not speedy when new, being roughly equivilent to the PowerPC G4 processors in Apple Laptops at the time. It is approximately 8 times slower than a current iPhone. Seriously. If convergence time is anything you care about, a 7206VXR is a very bad choice. It may also run out of memory if you have a lot of edges with full tables. So what's the actual "scaling" problem? -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ From nicotine at warningg.com Fri Jan 13 22:39:34 2017 From: nicotine at warningg.com (Brandon Ewing) Date: Fri, 13 Jan 2017 16:39:34 -0600 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: <20170113223934.GA18835@radiological.warningg.com> On Thu, Jan 12, 2017 at 08:32:44PM +0000, Justin Krejci wrote: > What are the pros and cons of one design over another? On list or private off list replies would be great; I'd welcome real world experiences (especially any big gotchas or caveats people learned the hard way) as well as just links to previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion that covers this topic would be appreciated. > One important thing to remember when migrating from full mesh to a RR design is that you are reducing information available to the routers in the ASN. When you had a full mesh, each router could select the best path from all available paths, according to its position in the IGP. In a RR environment, by default, routers only have available to them the best routes from the RR's position in the IGP, which can lead to suboptimal exits being selected. Work is being done to allow RRs to compute metrics from the client's position in the IGP: See https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13 for more information -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From fearghas at gmail.com Fri Jan 13 22:42:10 2017 From: fearghas at gmail.com (Fearghas Mckay) Date: Fri, 13 Jan 2017 17:42:10 -0500 Subject: Bandwidth Savings In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB03D7FF@RTC-EXCH01.RESERVE.LDS> References: <16704.1484161129@turing-police.cc.vt.edu> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB03D7FF@RTC-EXCH01.RESERVE.LDS> Message-ID: <3A8EE25C-CE4D-4D6B-8836-12796CA188B8@gmail.com> Keenan > On 11 Jan 2017, at 15:10, Luke Guillory wrote: > > Netflix won?t even begin talks for their cache if you're not doing a minimum of 5Gbps. Outside of the US I believe it is less based on presentations I have seen in Africa. > They also require massive uploads to the cache often, these are things are 200TB now if I recall and they send everything unlike the transparent who only grab what's already being consumed. Talk to their inter-connect team, the ones I know are very approachable. f From marka at isc.org Fri Jan 13 22:58:21 2017 From: marka at isc.org (Mark Andrews) Date: Sat, 14 Jan 2017 09:58:21 +1100 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: Your message of "Fri, 13 Jan 2017 16:29:43 -0300." References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> <20170112192845.BD44D5F3097F@rock.dv.isc.org> <20170113020741.63FAC5F4B3FF@rock.dv.isc.org> Message-ID: <20170113225821.A4D9C5F61873@rock.dv.isc.org> In message , Fernando Gont writes: > On 01/12/2017 11:07 PM, Mark Andrews wrote: > > In message > > , Fernando Gont writes: > >> El 12/1/2017 16:28, "Mark Andrews" escribi=C3=B3: > >> > >>> In message <11ff128d-2fba-7c26-4a9c-5611433d85d2 at si6networks.com>, Fernando Gont writes: > >>>> Hi, Saku, > >>>> > >>>> On 01/12/2017 11:43 AM, Saku Ytti wrote: > >>>>> On 12 January 2017 at 13:19, Fernando Gont > >>> wrote: > >>>>> > >>>>> Hey, > >>>>> > >>>>>> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > >>>>>> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > >>>>>> welcome). > >>>>> > >>>>> Generally may be understood differently by different people. If > >>>>> generally is defined as single most typical behaviour/configuration, > >>>>> then generally people don't protect their infrastructure in any way at > >>>>> all, but fully rely vendor doing something reasonable. > >>>>> > >>>>> I would argue BCP is to have 'strict' CoPP. Where you specifically > >>>>> allow what you must then have ultimate rule to deny everything. If you > >>>>> have such CoPP, then this attack won't work, as you clearly didn't > >>>>> allow any fragments at all (as you didn't expect to receive BGP > >>>>> fragments from your neighbours). > >>>> > >>>> That's the point: If you don't allow fragments, but your peer honors > >>>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > >>> > >>> And fragments are a *normal* part of IP for both IPv4 and IPv6. > >>> This obsession with dropping all fragments (and yes it is a obsession) > >>> is breaking the internet. > >> > >> Vendors got the frag reassembly code wrong so many times , that I > >> understand the folk that decides to drop them if deemed unnecessary. > > > > Most of them literally decades ago. > > Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been > several one-packet crashes disclosed for Cisco's (an the list continues). And they would have issued fixes for them. Machines get attacked from inside firewalls. Only idiots do not apply security fixes. > > 20+ years ago while you waited > > for you vendor to fix the bug it made some sense as most of your > > boxes were vulnerable. It was a new threat back then. It doesn't > > make sense today. > > Let's face it: The quality of many IPv6 implementations is that of IPv4 > implementations in the '90s. Sad, but true. Not really. For most of them the two stacks are in basically similar states. Most of the code is shared. > > Packet bigger than 1500 are a part of todays internet. Have a look > > a the stats for dropped fragments. They aren't for the most part > > attack traffic. Its legitmate reply traffic that has been requested. > > I don't disagree with you wrt the need for fragmentation in some > scenarios. I'm just saying that when you only employ TCP-based services, > it may make sense to drop fragments targeted *at you*. > > Fragmentation is only needed for non-TCP services. and if your system > does not use non-tcp services, it may be a sensible thing to drop > fragments targetted at you. Firstly framentation happens with TCP and IPv6 today. Just set IPV6_USE_MIN_MTU on the socket. It shouldn't happen as TCP is supposed to use the MTU information on the socket but it doesn't in many implementations. Secondly there is no site that doesn't use protocols that send fragmentent packets. They will all be using DNS and DNS sends fragmented UDP in its replies. This has been the case since the late 1990's. Mark > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at ics-il.net Fri Jan 13 23:33:32 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 13 Jan 2017 17:33:32 -0600 (CST) Subject: Apple Caching Server question In-Reply-To: <92fc8e67-3301-b5a1-c700-1d89dcc7ebd3@bogus.com> References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> <92fc8e67-3301-b5a1-c700-1d89dcc7ebd3@bogus.com> Message-ID: <456780052.5757.1484350411693.JavaMail.mhammett@ThunderFuck> There are far more ISPs with less than 10G of total traffic than ISPs with more than 10G of traffic. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "joel jaeggli" To: "lane powers" , nanog at nanog.org Sent: Friday, January 13, 2017 10:45:08 AM Subject: Re: Apple Caching Server question On 1/13/17 5:43 AM, lane.powers at swat.coop wrote: > I saw the apple caching server mentioned on an earlier thread. Is this appropriate/functional/scaleable enough to implement as an ISP? It is an intriguing idea. From the docs I could find, I couldn't tell if it was only geared towards home / small business or if it could scale up to handle ISP level traffic. It's a feature of macos server. You do get to register prefix with apple, but I don't imagine colocating a mac mini is isp level traffic. That said as714 peers extensively https://www.peeringdb.com/net/3554 so picking them up works too. > thanks, > Lane > From marka at isc.org Fri Jan 13 23:38:52 2017 From: marka at isc.org (Mark Andrews) Date: Sat, 14 Jan 2017 10:38:52 +1100 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: Your message of "Fri, 13 Jan 2017 16:35:36 -0300." <954a2fbd-580a-044b-07e7-63a0bf1bbfaa@si6networks.com> References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> <20170113021450.E105B5F4B4B7@rock.dv.isc.org> <954a2fbd-580a-044b-07e7-63a0bf1bbfaa@si6networks.com> Message-ID: <20170113233852.28E8A5F61AE9@rock.dv.isc.org> In message <954a2fbd-580a-044b-07e7-63a0bf1bbfaa at si6networks.com>, Fernando Gont writes: > On 01/12/2017 11:14 PM, Mark Andrews wrote: > > In message > > , Fernando Gont writes: > >> El 12/1/2017 16:32, "Saku Ytti" escribi=C3=B3: > >> > >> On 12 January 2017 at 17:02, Fernando Gont wrote: > >>> That's the point: If you don't allow fragments, but your peer honors > >>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > >> > >> Thanks. I think I got it now. Best I can offer is that B could try to > >> verify the embedded original packet? Hopefully attacker won't have > >> access to that information. An if attacker has access to that > >> information, they may as well do TCP RST, right? > >> > >> Didn't we have same issues in IPv4 with ICMP unreachable and frag > >> neeeded, DF set? And vendors implemented more verification if the ICMP > >> message should be accepted. > >> > >> > >> Yes and no. > >> > >> 1) there was no way in v4 to trigger use of fragmentation for an arbitrary > >> flow. > >> > >> 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. > >> In ipv6, you aren't (think ipv6 EHs) > > > > So drop the packet if you don't get to the end of the extension > > headers in the ICMPv6 payload. Has anyone, except in testing, seen > > a extension header chain that was not fully containable in the > > ICMPv6 payload? > > Because of the extra IPv6+ICMPv6 headers that you need for sending the > ICMP error, even if the original packet did have the entire IPv6 header > chain, you might be unable to include it in the ICMPv6 payload. 1280 - 40 - 8 which give a effective final header fitting in the initial 1252 bytes. Still bigger than header chains that you see in practice today. > Yes, in practice you'd be fine dropping ICMP errors that don't embed a > full payload. Whether vendors do it or not, is a different question. Dropping a payload that don't include the entire header chain. The entire packet is another thing. It is expected to be truncated at 1252 bytes unless you add extension headers to the ICMPv6 packet. > FWIW, it took me 6 years to publish RFC5927. And, because folks > *opposed* to it in tcpm wg, it was published as Informational, rather > than Std Track. RFC4443 points to it, still as informational thing that > you might want to do. > > If we don't convey the right message in specs, not sure we can expect > good implementations, and even less flame the folk that tries to run his > network in the best possible way with "what he gets". As a DNS developer I actually do look at ICMP packets if I don't want to timeout. A PTB can be used to trigger the resend of a DNS query (unlikely but possible). You can also remember that and set IPV6_USE_MIN_MTU=1 on future responses to that client rather than relying on the lower levels of the stack remembering the PTB and adjusting the packet size. You can extract data from the payload like the query id and even the question. You can assume that it is a EDNS response and reconstruct the response to resend assuming that DNS Cookie/TSIG/SIG(0) is not in use as all of that is at the end of the packet. Time exceeded and unreachables can move you onto the next server faster. I have code that does some of that after matching addresses, ports id etc. None of this is hard to do. All of this should be obvious to anyone with a little bit of thinking. Senders know that ICMPv6 packets are limited to 1280 bytes. They can construct their echoed back packets to fit the headers into the available size. They want the traffic to flow and that requires getting back the information to be able to restart the flow. Instead the firewall developers do as little as they can. They don't think about the ramifications of their actions. Mark > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont at si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Valdis.Kletnieks at vt.edu Fri Jan 13 23:49:12 2017 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Jan 2017 18:49:12 -0500 Subject: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers) In-Reply-To: <20170113225821.A4D9C5F61873@rock.dv.isc.org> References: <14a68ac0-b79b-f8d6-3545-e1814ecc6a92@si6networks.com> <11ff128d-2fba-7c26-4a9c-5611433d85d2@si6networks.com> <20170112192845.BD44D5F3097F@rock.dv.isc.org> <20170113020741.63FAC5F4B3FF@rock.dv.isc.org> <20170113225821.A4D9C5F61873@rock.dv.isc.org> Message-ID: <38548.1484351352@turing-police.cc.vt.edu> On Sat, 14 Jan 2017 09:58:21 +1100, Mark Andrews said: > In message , Fernando Gont writes: > > Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been > > several one-packet crashes disclosed for Cisco's (an the list continues). > > And they would have issued fixes for them. Machines get attacked > from inside firewalls. Only idiots do not apply security fixes. Evidence suggests that our industry is highly overstocked with idiots. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From randy at psg.com Sat Jan 14 03:46:24 2017 From: randy at psg.com (Randy Bush) Date: Sat, 14 Jan 2017 12:46:24 +0900 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <587950dd.e8199d0a.8a03c.7bc6SMTPIN_ADDED_BROKEN@mx.google.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D804324@USI-2K10EX02-MT.usicorp.usinternet.com> <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> Message-ID: > Scaling in this context is simply adding more and more routers and > needing/wanting to avoid configuring full mesh iBGP due to the > administrative burden of maintaining the growing size of full mesh > topology. In one particular network in question, I have 11 routers > fully meshed and need to add several more over the coming 6-12 months, > possibly adding as many as 10 more routers in that time span. I'd > prefer not to continue doing full mesh. if those numbers were x 10 or more, 'scaling' becomes a concern. the way to add to an ibgp mesh or any other topology, including those with rrs, is automation. > As for 7206VXR with NPE-G1 or G2 cards, we have many sitting in a > decommissioned state on shelves i suspect there is a reason. randy From hicks at adelphi.edu Fri Jan 13 18:51:04 2017 From: hicks at adelphi.edu (Fred Hicks) Date: Fri, 13 Jan 2017 13:51:04 -0500 Subject: Apple Caching Server question In-Reply-To: References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> Message-ID: We have been using this: http://qwilt.com/ It does all the Apple and IOS caching and is built for the ISP level and then some. On Fri, Jan 13, 2017 at 12:25 PM, Blake Hudson wrote: > lane.powers at swat.coop wrote on 1/13/2017 7:43 AM: > >> I saw the apple caching server mentioned on an earlier thread. Is this >> appropriate/functional/scaleable enough to implement as an ISP? It is an >> intriguing idea. From the docs I could find, I couldn't tell if it was only >> geared towards home / small business or if it could scale up to handle ISP >> level traffic. >> >> thanks, >> Lane >> > > I have no experience with the Apple caching service specifically, but I > have used Apple products (including some of their server software) for > decades. Apple used to make mac mini models exclusively for server use. > Their low power draw and relatively high density makes them an interesting > choice for those that don't mind using "desktop grade" hardware for a > project. There are some folks that even make rack-mount solutions for the > Mac mini and Mac pro (search for RackMac). That said, my experience with > several mac minis is that you will have at least one fault that will put > them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3 year > period when ran 24/7. > > With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect a > mac mini to be as fast or faster than most other network appliances one > might purchase. If one wanted something beefier, a mac pro would probably > offer some expandability (on board dual 1gbps NICs + six 20Gbps thunderbolt > 2 ports). > > I would see why one might be curious, especially if this could cache the > IOS updates used for all those tablets and other iDevices folks purchase > from Apple. > -- [image: email-signature-logo] *Fred Hicks* Director of Network Communications Information Technology hicks at adelphi.edu T 516.877.3338 From codygrosskopf at gmail.com Sat Jan 14 05:06:15 2017 From: codygrosskopf at gmail.com (Cody Grosskopf) Date: Sat, 14 Jan 2017 05:06:15 +0000 Subject: Apple Caching Server question In-Reply-To: References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> Message-ID: Maybe you can help.sell the product because that website doesn't do much in terms of selling the product. What does it do and why would we use it? On Fri, Jan 13, 2017, 8:29 PM Fred Hicks wrote: > We have been using this: > > http://qwilt.com/ > > It does all the Apple and IOS caching and is built for the ISP level and > then some. > > > > On Fri, Jan 13, 2017 at 12:25 PM, Blake Hudson wrote: > > > lane.powers at swat.coop wrote on 1/13/2017 7:43 AM: > > > >> I saw the apple caching server mentioned on an earlier thread. Is this > >> appropriate/functional/scaleable enough to implement as an ISP? It is an > >> intriguing idea. From the docs I could find, I couldn't tell if it was > only > >> geared towards home / small business or if it could scale up to handle > ISP > >> level traffic. > >> > >> thanks, > >> Lane > >> > > > > I have no experience with the Apple caching service specifically, but I > > have used Apple products (including some of their server software) for > > decades. Apple used to make mac mini models exclusively for server use. > > Their low power draw and relatively high density makes them an > interesting > > choice for those that don't mind using "desktop grade" hardware for a > > project. There are some folks that even make rack-mount solutions for the > > Mac mini and Mac pro (search for RackMac). That said, my experience with > > several mac minis is that you will have at least one fault that will put > > them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3 > year > > period when ran 24/7. > > > > With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect > a > > mac mini to be as fast or faster than most other network appliances one > > might purchase. If one wanted something beefier, a mac pro would probably > > offer some expandability (on board dual 1gbps NICs + six 20Gbps > thunderbolt > > 2 ports). > > > > I would see why one might be curious, especially if this could cache the > > IOS updates used for all those tablets and other iDevices folks purchase > > from Apple. > > > > > > -- > [image: email-signature-logo] > *Fred Hicks* > Director of Network Communications > Information Technology > hicks at adelphi.edu > T 516.877.3338 > From faisal at snappytelecom.net Sat Jan 14 05:24:36 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 14 Jan 2017 05:24:36 +0000 (GMT) Subject: External BGP Controller for L3 Switch BGP routing Message-ID: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> Hello, A while back there was a discussion on how to do optimized (dynamic) BGP routing on a L3 switch which is only capable of handing a subset of BGP Routing table. Someone has pointed out that there was a project to do just that, and had posted a link to a presentation on a European operator (Ireland ? ) who had done some code to take Exabgp and create such a setup.. (I am going by memory... )... Needless to say I am trying to find that link, or name of that project. Anyone who can help in refreshing my memory with the link (my search skill are failing to find that presentation !) would be greatly appreciated. Many Thanks in Advance. Faisal Imtiaz From jhaustin at gmail.com Sat Jan 14 05:32:10 2017 From: jhaustin at gmail.com (Jeremy Austin) Date: Fri, 13 Jan 2017 20:32:10 -0900 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> Message-ID: Tore Anderson: https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html On Fri, Jan 13, 2017 at 8:24 PM, Faisal Imtiaz wrote: > Hello, > > A while back there was a discussion on how to do optimized (dynamic) BGP > routing on a L3 switch which is only capable of handing a subset of BGP > Routing table. > > Someone has pointed out that there was a project to do just that, and had > posted a link to a presentation on a European operator (Ireland ? ) who had > done some code to take Exabgp and create such a setup.. > > (I am going by memory... )... Needless to say I am trying to find that > link, or name of that project. > > Anyone who can help in refreshing my memory with the link (my search skill > are failing to find that presentation !) > would be greatly appreciated. > > Many Thanks in Advance. > > Faisal Imtiaz > -- Jeremy Austin (907) 895-2311 (907) 803-5422 jhaustin at gmail.com Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC Schedule a meeting: http://doodle.com/jermudgeon From lguillory at reservetele.com Sat Jan 14 05:52:52 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Sat, 14 Jan 2017 05:52:52 +0000 Subject: Apple Caching Server question In-Reply-To: References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> , Message-ID: <0B1AE6FD-2D3C-4F15-8A57-239123C99CAC@reservetele.com> They sell transparent caching, works great and we've been using it for a few years. Not cheap on the CAPX side but it sure does work. I deliver 50% of all Netflix traffic while never hitting my transit links, Apple is even higher and windows updates is are near the 97% number. The great thing outside of cutting down on transit traffic is the increase speeds from serving it from within my network. The support folks rock and take care of everything, we haven't touched it since we racked it up. Simple 1u Dell server with 10g nics, we currently just port mirror to it and let it do its thing. I can share more if needed as well. Luke Sent from my iPad > Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . On Jan 13, 2017, at 11:07 PM, Cody Grosskopf wrote: > > Maybe you can help.sell the product because that website doesn't do much in > terms of selling the product. What does it do and why would we use it? > >> On Fri, Jan 13, 2017, 8:29 PM Fred Hicks wrote: >> >> We have been using this: >> >> http://qwilt.com/ >> >> It does all the Apple and IOS caching and is built for the ISP level and >> then some. >> >> >> >>> On Fri, Jan 13, 2017 at 12:25 PM, Blake Hudson wrote: >>> >>> lane.powers at swat.coop wrote on 1/13/2017 7:43 AM: >>> >>>> I saw the apple caching server mentioned on an earlier thread. Is this >>>> appropriate/functional/scaleable enough to implement as an ISP? It is an >>>> intriguing idea. From the docs I could find, I couldn't tell if it was >> only >>>> geared towards home / small business or if it could scale up to handle >> ISP >>>> level traffic. >>>> >>>> thanks, >>>> Lane >>>> >>> >>> I have no experience with the Apple caching service specifically, but I >>> have used Apple products (including some of their server software) for >>> decades. Apple used to make mac mini models exclusively for server use. >>> Their low power draw and relatively high density makes them an >> interesting >>> choice for those that don't mind using "desktop grade" hardware for a >>> project. There are some folks that even make rack-mount solutions for the >>> Mac mini and Mac pro (search for RackMac). That said, my experience with >>> several mac minis is that you will have at least one fault that will put >>> them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3 >> year >>> period when ran 24/7. >>> >>> With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect >> a >>> mac mini to be as fast or faster than most other network appliances one >>> might purchase. If one wanted something beefier, a mac pro would probably >>> offer some expandability (on board dual 1gbps NICs + six 20Gbps >> thunderbolt >>> 2 ports). >>> >>> I would see why one might be curious, especially if this could cache the >>> IOS updates used for all those tablets and other iDevices folks purchase >>> from Apple. >>> >> >> >> >> -- >> [image: email-signature-logo] >> *Fred Hicks* >> Director of Network Communications >> Information Technology >> hicks at adelphi.edu >> T 516.877.3338 >> From bernat at luffy.cx Sat Jan 14 07:04:49 2017 From: bernat at luffy.cx (Vincent Bernat) Date: Sat, 14 Jan 2017 08:04:49 +0100 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> (Faisal Imtiaz's message of "Sat, 14 Jan 2017 05:24:36 +0000 (GMT)") References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> Message-ID: <874m12yve6.fsf@luffy.cx> ? 14 janvier 2017 05:24 GMT, Faisal Imtiaz ?: > A while back there was a discussion on how to do optimized (dynamic) > BGP routing on a L3 switch which is only capable of handing a subset > of BGP Routing table. > > Someone has pointed out that there was a project to do just that, and > had posted a link to a presentation on a European operator (Ireland ? > ) who had done some code to take Exabgp and create such a setup.. Maybe: https://github.com/dbarrosop/sir -- The difference between the right word and the almost right word is the difference between lightning and the lightning bug. -- Mark Twain From saku at ytti.fi Sat Jan 14 12:37:30 2017 From: saku at ytti.fi (Saku Ytti) Date: Sat, 14 Jan 2017 14:37:30 +0200 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> Message-ID: On 14 January 2017 at 07:32, Jeremy Austin wrote: Hey, > https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html --- As described in a prevous post, we?re testing a HPE Altoline 6920 in our lab. The Altoline 6920 is, like other switches based on the Broadcom Trident II chipset, able to handle up to 720 Gbps of throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis. Its price is in all likelihood a single-digit percentage of the price of a traditional Internet router with a comparable throughput rating. --- This makes it sound like small-FIB router is single-digit percentage cost of full-FIB. Purely from BOM cost, high end XEON costs more than say Jericho. If this does not match market realities, full-FIB being expensive is fabricated problem. I don't believe we're anywhere near of full-FIB being uneconomic. Of course if you have solution where small-FIB gives very minor or no compromises, it makes no sense to use full-FIB, as it has convergence time cost too. But if you have to take compromises, I'd rather try to fix the underlaying economic issue. What is driving small-FIB boxes is not that full-FIB is inherently very expensive, but rather that densest possible box is most marketable to DC people, trading large FIB and deep buffers for higher density is no-brainer in some DC applications. I suspect most ports used are in DC, not in access, so market is not focused on access requirements. For same cost, that you buy ghetto cheap TridentII box, you should be able to buy slightly less dense full-FIB and deep buffers box. In access networks this is fine, because your port utilisation rate is poor anyhow. Also having Trident in Internet facing interface may be suspect, especially if you need to go from fast interface to slow or busy interface, due to very minor packet buffers. This obviously won't be much of a problem in inside-DC traffic. This is quite hard to test in lab, you can't reasonable test it in IXIA, the burst sizes it supports are too small, in Spirent you mostly can see the problem. -- ++ytti From nanog at ics-il.net Mon Jan 16 00:30:45 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 15 Jan 2017 18:30:45 -0600 (CST) Subject: St. Louis IX Launch In-Reply-To: <1976838468.7889.1484526390975.JavaMail.mhammett@ThunderFuck> Message-ID: <372923401.7904.1484526642238.JavaMail.mhammett@ThunderFuck> If you know someone that may be interested, we have a launch event later this week for our St. Louis IX. St. Louis is a bit different than our existing market in that we've partnered with a local non-profit that will be focusing on non-commercial Internet aspects. These sorts of things are innovation neighborhoods, IoT, healthcare, education, public safety, etc. They may (or may not) be the big volume things we're used to, but they need local, low-latency connectivity just as much. https://www.eventbrite.com/e/st-louis-regional-internet-exchange-preview-tickets-30329718003?aff=NANOG ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From math at sizone.org Mon Jan 16 00:36:20 2017 From: math at sizone.org (Ken Chase) Date: Sun, 15 Jan 2017 19:36:20 -0500 Subject: St. Louis IX Launch In-Reply-To: <372923401.7904.1484526642238.JavaMail.mhammett@ThunderFuck> References: <1976838468.7889.1484526390975.JavaMail.mhammett@ThunderFuck> <372923401.7904.1484526642238.JavaMail.mhammett@ThunderFuck> Message-ID: <20170116003620.GM9040@sizone.org> congrats! I am curious, is the IX non-for-profit as well? The wikipedia entry for IX's doenst indicate which IX's are non-profit. Im curious as to the prevalence and size (as well as the relative successes) of such IX's vs for profit models (equinix etc). /kc On Sun, Jan 15, 2017 at 06:30:45PM -0600, Mike Hammett said: >If you know someone that may be interested, we have a launch event later this week for our St. Louis IX. St. Louis is a bit different than our existing market in that we've partnered with a local non-profit that will be focusing on non-commercial Internet aspects. These sorts of things are innovation neighborhoods, IoT, healthcare, education, public safety, etc. They may (or may not) be the big volume things we're used to, but they need local, low-latency connectivity just as much. > >https://www.eventbrite.com/e/st-louis-regional-internet-exchange-preview-tickets-30329718003?aff=NANOG > > > > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP > -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From erich at gotfusion.net Mon Jan 16 01:20:54 2017 From: erich at gotfusion.net (Kaiser, Erich) Date: Sun, 15 Jan 2017 19:20:54 -0600 Subject: St. Louis IX Launch In-Reply-To: <372923401.7904.1484526642238.JavaMail.mhammett@ThunderFuck> References: <1976838468.7889.1484526390975.JavaMail.mhammett@ThunderFuck> <372923401.7904.1484526642238.JavaMail.mhammett@ThunderFuck> Message-ID: To bad such short notice... :( I am going to be out of town, would have been nice to be able to go... Erich Kaiser The Fusion Network erich at gotfusion.net Office: 630-621-4804 Cell: 630-777-9291 On Sun, Jan 15, 2017 at 6:30 PM, Mike Hammett wrote: > If you know someone that may be interested, we have a launch event later > this week for our St. Louis IX. St. Louis is a bit different than our > existing market in that we've partnered with a local non-profit that will > be focusing on non-commercial Internet aspects. These sorts of things are > innovation neighborhoods, IoT, healthcare, education, public safety, etc. > They may (or may not) be the big volume things we're used to, but they need > local, low-latency connectivity just as much. > > https://www.eventbrite.com/e/st-louis-regional-internet- > exchange-preview-tickets-30329718003?aff=NANOG > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From nanog at ics-il.net Mon Jan 16 01:26:36 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 15 Jan 2017 19:26:36 -0600 (CST) Subject: St. Louis IX Launch In-Reply-To: <20170116003620.GM9040@sizone.org> References: <1976838468.7889.1484526390975.JavaMail.mhammett@ThunderFuck> <372923401.7904.1484526642238.JavaMail.mhammett@ThunderFuck> <20170116003620.GM9040@sizone.org> Message-ID: <444065520.7946.1484529995937.JavaMail.mhammett@ThunderFuck> It is a partnership and I may not be the most qualified to speak on the terms of the partnership. However, the non-commercial side is not-for-profit, but the commercial side is fully commercial. While building out our IX brand, of those that have been able to have a rational discussion about their anti-commercial IX position, almost all of them (or maybe even all of them) weren't really anti-commercial. They were just anti-800-lb-gorilla. They didn't hate the independent building out IXes in markets that maybe never had a functional IX, but surely didn't have one now. They hated Equinix, Coresite, etc. They just wanted someone that wasn't going to be a jerk to them. We don't have any aspirations to get to Equinix size. We know we're going to small time places and that we'll only ever have small time IXes in the big picture. The building we started at in Indy only advertises something like 20 or 30 networks in the building. Now we've grown to other buildings and they aren't going to list every Tom, Dick and Harry, but it's not a 300 network market. We'll leave that to AMS-IX, DE-CIX, Megaport, etc. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ken Chase" To: "NANOG ???[nanog at nanog.org]???" Sent: Sunday, January 15, 2017 6:36:20 PM Subject: Re: St. Louis IX Launch congrats! I am curious, is the IX non-for-profit as well? The wikipedia entry for IX's doenst indicate which IX's are non-profit. Im curious as to the prevalence and size (as well as the relative successes) of such IX's vs for profit models (equinix etc). /kc On Sun, Jan 15, 2017 at 06:30:45PM -0600, Mike Hammett said: >If you know someone that may be interested, we have a launch event later this week for our St. Louis IX. St. Louis is a bit different than our existing market in that we've partnered with a local non-profit that will be focusing on non-commercial Internet aspects. These sorts of things are innovation neighborhoods, IoT, healthcare, education, public safety, etc. They may (or may not) be the big volume things we're used to, but they need local, low-latency connectivity just as much. > >https://www.eventbrite.com/e/st-louis-regional-internet-exchange-preview-tickets-30329718003?aff=NANOG > > > > >----- >Mike Hammett >Intelligent Computing Solutions > >Midwest Internet Exchange > >The Brothers WISP > -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From tore at fud.no Mon Jan 16 06:40:47 2017 From: tore at fud.no (Tore Anderson) Date: Mon, 16 Jan 2017 07:40:47 +0100 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> Message-ID: <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Hi Saku, > > https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html > > --- > As described in a prevous post, we?re testing a HPE Altoline 6920 in > our lab. The Altoline 6920 is, like other switches based on the > Broadcom Trident II chipset, able to handle up to 720 Gbps of > throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis. > Its price is in all likelihood a single-digit percentage of the price > of a traditional Internet router with a comparable throughput rating. > --- > > This makes it sound like small-FIB router is single-digit percentage > cost of full-FIB. Do you know of any traditional ?Internet scale? router that can do ~720 Gbps of throughput for less than 10x the price of a Trident II box? Or even <100kUSD? (Disregarding any volume discounts.) > Also having Trident in Internet facing interface may be suspect, > especially if you need to go from fast interface to slow or busy > interface, due to very minor packet buffers. This obviously won't be > much of a problem in inside-DC traffic. Quite the opposite, changing between different interface speeds happens very commonly inside the data centre (and most of the time it's done by shallow-buffered switches using Trident II or similar chips). One ubiquitous configuration has the servers and any external uplinks attached with 10GE to leaf switches which in turn connects to a 40GE spine layer with. In this config server<->server and server<->Internet packets will need to change speed twice: [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet] I suppose you could for example use a couple of MX240s or something as a special-purpose leaf layer for external connectivity. MPC5E-40G10G-IRB or something towards the 40GE spines and any regular 10GE MPC towards the exits. That way you'd only have one shallow-buffered speed conversion remaining. But I'm very sceptical if something like this makes sense after taking the cost/benefit ratio into account. Tore From sunyucong at gmail.com Mon Jan 16 07:00:48 2017 From: sunyucong at gmail.com (Yucong Sun) Date: Mon, 16 Jan 2017 07:00:48 +0000 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Message-ID: In my setup, I use an BIRD instance to combine multiple internet full tables, i use some filter to generate some override route to send to my L3 switch to do routing. The L3 switch is configured with the default route to the main transit provider , if BIRD is down, the route would be unoptimized, but everything else remain operable until i fixed that BIRD instance. I've asked around about why there isn't a L3 switch capable of handling full tables, I really don't understand the difference/logic behind it. On Sun, Jan 15, 2017 at 10:43 PM Tore Anderson wrote: > Hi Saku, > > > > > https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html > > > > --- > > As described in a prevous post, we?re testing a HPE Altoline 6920 in > > our lab. The Altoline 6920 is, like other switches based on the > > Broadcom Trident II chipset, able to handle up to 720 Gbps of > > throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis. > > Its price is in all likelihood a single-digit percentage of the price > > of a traditional Internet router with a comparable throughput rating. > > --- > > > > This makes it sound like small-FIB router is single-digit percentage > > cost of full-FIB. > > Do you know of any traditional ?Internet scale? router that can do ~720 > Gbps of throughput for less than 10x the price of a Trident II box? Or > even <100kUSD? (Disregarding any volume discounts.) > > > Also having Trident in Internet facing interface may be suspect, > > especially if you need to go from fast interface to slow or busy > > interface, due to very minor packet buffers. This obviously won't be > > much of a problem in inside-DC traffic. > > Quite the opposite, changing between different interface speeds happens > very commonly inside the data centre (and most of the time it's done by > shallow-buffered switches using Trident II or similar chips). > > One ubiquitous configuration has the servers and any external uplinks > attached with 10GE to leaf switches which in turn connects to a 40GE > spine layer with. In this config server<->server and server<->Internet > packets will need to change speed twice: > > [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet] > > I suppose you could for example use a couple of MX240s or something as > a special-purpose leaf layer for external connectivity. > MPC5E-40G10G-IRB or something towards the 40GE spines and any regular > 10GE MPC towards the exits. That way you'd only have one > shallow-buffered speed conversion remaining. But I'm very sceptical if > something like this makes sense after taking the cost/benefit ratio > into account. > > Tore > From josh at kyneticwifi.com Mon Jan 16 09:20:13 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 16 Jan 2017 03:20:13 -0600 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Message-ID: I'm going to be keeping a close eye on this: http://blogs.cisco.com/sp/a-bigger-helping-of-internet-please On Jan 16, 2017 1:03 AM, "Yucong Sun" wrote: > In my setup, I use an BIRD instance to combine multiple internet full > tables, i use some filter to generate some override route to send to my L3 > switch to do routing. The L3 switch is configured with the default route > to the main transit provider , if BIRD is down, the route would be > unoptimized, but everything else remain operable until i fixed that BIRD > instance. > > I've asked around about why there isn't a L3 switch capable of handling > full tables, I really don't understand the difference/logic behind it. > > On Sun, Jan 15, 2017 at 10:43 PM Tore Anderson wrote: > > > Hi Saku, > > > > > > > > https://www.redpill-linpro.com/sysadvent/2016/12/09/ > slimming-routing-table.html > > > > > > --- > > > As described in a prevous post, we?re testing a HPE Altoline 6920 in > > > our lab. The Altoline 6920 is, like other switches based on the > > > Broadcom Trident II chipset, able to handle up to 720 Gbps of > > > throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis. > > > Its price is in all likelihood a single-digit percentage of the price > > > of a traditional Internet router with a comparable throughput rating. > > > --- > > > > > > This makes it sound like small-FIB router is single-digit percentage > > > cost of full-FIB. > > > > Do you know of any traditional ?Internet scale? router that can do ~720 > > Gbps of throughput for less than 10x the price of a Trident II box? Or > > even <100kUSD? (Disregarding any volume discounts.) > > > > > Also having Trident in Internet facing interface may be suspect, > > > especially if you need to go from fast interface to slow or busy > > > interface, due to very minor packet buffers. This obviously won't be > > > much of a problem in inside-DC traffic. > > > > Quite the opposite, changing between different interface speeds happens > > very commonly inside the data centre (and most of the time it's done by > > shallow-buffered switches using Trident II or similar chips). > > > > One ubiquitous configuration has the servers and any external uplinks > > attached with 10GE to leaf switches which in turn connects to a 40GE > > spine layer with. In this config server<->server and server<->Internet > > packets will need to change speed twice: > > > > [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet] > > > > I suppose you could for example use a couple of MX240s or something as > > a special-purpose leaf layer for external connectivity. > > MPC5E-40G10G-IRB or something towards the 40GE spines and any regular > > 10GE MPC towards the exits. That way you'd only have one > > shallow-buffered speed conversion remaining. But I'm very sceptical if > > something like this makes sense after taking the cost/benefit ratio > > into account. > > > > Tore > > > From saku at ytti.fi Mon Jan 16 12:08:53 2017 From: saku at ytti.fi (Saku Ytti) Date: Mon, 16 Jan 2017 14:08:53 +0200 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Message-ID: On 16 January 2017 at 08:40, Tore Anderson wrote: Hey, > Do you know of any traditional ?Internet scale? router that can do ~720 > Gbps of throughput for less than 10x the price of a Trident II box? Or > even <100kUSD? (Disregarding any volume discounts.) It's really hard to talk about pricing, as it's very dependant on many factors. But I guess pretty much all Jericho boxes would fit that bill? Arista will probably set you back anywhere in range of 15<35k, will do full table (for now) and has deep packet buffers. NCS5501 is also sub 100k, even with external TCAM. Probably single unit around 40k without external TCAM and 60k with external TCAM and you lose 8x10G and 2x100G ports. But my comment wasn't really about what is available now, it was more fundament about economics of large FIB or large buffers, they are not inherently very BOM expensive. I wonder if true whitelabel is possible, would some 'real' HW vendor, of BRCM size, release HW docs openly? Then some integrator could start selling the HW with BOM+10-20%, no support, no software at all. And community could build the actual software on it. It seems to me, what is keeping us away from near-BOM prices is software engineering, and we cannot do it as a community, as HW docs are not available. > Quite the opposite, changing between different interface speeds happens > very commonly inside the data centre (and most of the time it's done by > shallow-buffered switches using Trident II or similar chips). Why I said it won't be a problem inside DC, is because low RTT, which means small bursts. I'm talking about backend network infra in DC, not Internet facing. Anywhere where you'll see large RTT and speed/availability step-down you'll need buffers (unless we change TCP to pace window-growth, unlike burst what it does now, AFAIK, you could already configure your Linux server to do pacing at estimate BW, but then you'd lose in congested links, as more aggressive TCP stack would beat you to oblivion). > I suppose you could for example use a couple of MX240s or something as > a special-purpose leaf layer for external connectivity. > MPC5E-40G10G-IRB or something towards the 40GE spines and any regular > 10GE MPC towards the exits. That way you'd only have one > shallow-buffered speed conversion remaining. But I'm very sceptical if > something like this makes sense after taking the cost/benefit ratio > into account. MPC indeed is on completely another level in BOM, as it's NPU with lookup and packets in DRAM, fairly complicated and space-inefficient. But we have pipeline chips in the market with deep buffers and full DFZ. There is no real reason that the markup on them would be significant, control-plane should cost more. This is why the promise of XEON router is odd to me, as it's fundamentally very expensive chip, combined with poorly predictable performance (jitter, latency...) -- ++ytti From tore at fud.no Mon Jan 16 12:36:54 2017 From: tore at fud.no (Tore Anderson) Date: Mon, 16 Jan 2017 13:36:54 +0100 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Message-ID: <20170116133654.5239831f@echo.ms.redpill-linpro.com> * Saku Ytti > Why I said it won't be a problem inside DC, is because low RTT, which > means small bursts. I'm talking about backend network infra in DC, not > Internet facing. Anywhere where you'll see large RTT and > speed/availability step-down you'll need buffers (unless we change TCP > to pace window-growth, unlike burst what it does now, AFAIK, you could > already configure your Linux server to do pacing at estimate BW, but > then you'd lose in congested links, as more aggressive TCP stack would > beat you to oblivion). But here you're talking about the RTT of each individual link, right, not the RTT of the entire path through the Internet for any given flow? Put it another way, my ?Internet facing? interfaces are typically 10GEs with a few (kilo)metres of dark fibre that x-connects into my IP-transit providers' routers sitting in nearby rooms or racks (worst case somewhere else in the same metro area). Is there any reason why I should need deep buffers on those interfaces? The IP-transit providers might need the deep buffers somewhere in their networks, sure. But if so I'm thinking that's a problem I'm paying them to not have to worry about. BTW, in my experience the buffering and tail-dropping is actually a bigger problem inside the data centre because of distributed applications causing incast. So we get workarounds like DCTCP and BBR, which is apparently cheaper than using deep-buffer switches everywhere. Tore From davidbass570 at gmail.com Mon Jan 16 13:41:44 2017 From: davidbass570 at gmail.com (David Bass) Date: Mon, 16 Jan 2017 08:41:44 -0500 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Message-ID: Arista has a version of their switches that can handle a full table. I think what the OP is asking about though is something like openflow though. Some have played around with using it to modify the switches routing table based on flows that exist. The same theory applies in regard to the presentation link provided (we don't need the full table 99%of the time, so just insert what you need). Using filters is an "old school" technique that's been around for a long time, and I don't think that's what he's asking. > On Jan 16, 2017, at 2:00 AM, Yucong Sun wrote: > > In my setup, I use an BIRD instance to combine multiple internet full > tables, i use some filter to generate some override route to send to my L3 > switch to do routing. The L3 switch is configured with the default route > to the main transit provider , if BIRD is down, the route would be > unoptimized, but everything else remain operable until i fixed that BIRD > instance. > > I've asked around about why there isn't a L3 switch capable of handling > full tables, I really don't understand the difference/logic behind it. > >> On Sun, Jan 15, 2017 at 10:43 PM Tore Anderson wrote: >> >> Hi Saku, >> >>>> >> https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html >>> >>> --- >>> As described in a prevous post, we?re testing a HPE Altoline 6920 in >>> our lab. The Altoline 6920 is, like other switches based on the >>> Broadcom Trident II chipset, able to handle up to 720 Gbps of >>> throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis. >>> Its price is in all likelihood a single-digit percentage of the price >>> of a traditional Internet router with a comparable throughput rating. >>> --- >>> >>> This makes it sound like small-FIB router is single-digit percentage >>> cost of full-FIB. >> >> Do you know of any traditional ?Internet scale? router that can do ~720 >> Gbps of throughput for less than 10x the price of a Trident II box? Or >> even <100kUSD? (Disregarding any volume discounts.) >> >>> Also having Trident in Internet facing interface may be suspect, >>> especially if you need to go from fast interface to slow or busy >>> interface, due to very minor packet buffers. This obviously won't be >>> much of a problem in inside-DC traffic. >> >> Quite the opposite, changing between different interface speeds happens >> very commonly inside the data centre (and most of the time it's done by >> shallow-buffered switches using Trident II or similar chips). >> >> One ubiquitous configuration has the servers and any external uplinks >> attached with 10GE to leaf switches which in turn connects to a 40GE >> spine layer with. In this config server<->server and server<->Internet >> packets will need to change speed twice: >> >> [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet] >> >> I suppose you could for example use a couple of MX240s or something as >> a special-purpose leaf layer for external connectivity. >> MPC5E-40G10G-IRB or something towards the 40GE spines and any regular >> 10GE MPC towards the exits. That way you'd only have one >> shallow-buffered speed conversion remaining. But I'm very sceptical if >> something like this makes sense after taking the cost/benefit ratio >> into account. >> >> Tore >> From james.jun at towardex.com Mon Jan 16 13:48:11 2017 From: james.jun at towardex.com (James Jun) Date: Mon, 16 Jan 2017 08:48:11 -0500 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <20170116133654.5239831f@echo.ms.redpill-linpro.com> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> <20170116133654.5239831f@echo.ms.redpill-linpro.com> Message-ID: <20170116134811.GA27008@mis10.towardex.com> On Mon, Jan 16, 2017 at 01:36:54PM +0100, Tore Anderson wrote: > > But here you're talking about the RTT of each individual link, right, > not the RTT of the entire path through the Internet for any given flow? > > Put it another way, my ??Internet facing?? interfaces are typically 10GEs with > a few (kilo)metres of dark fibre that x-connects into my IP-transit providers' > routers sitting in nearby rooms or racks (worst case somewhere else in > the same metro area). Is there any reason why I should need deep > buffers on those interfaces?a It would be RTT of the entire path through the Internet where TCP establishes sessions. Longer RTT, longer window, more burst. So, yes you'll need deeper buffers for serving IP transit, regardless of the local link (router-to-router) latency. For data centers, internal traffic within the DC is low latency end to end, so burst is relatively small. James From nanog at ics-il.net Mon Jan 16 13:48:42 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 16 Jan 2017 07:48:42 -0600 (CST) Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> Message-ID: <422229243.8232.1484574520799.JavaMail.mhammett@ThunderFuck> I thought your post was fairly self-explanatory, but people seem to be all over the place... except for what you actually asked about. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Faisal Imtiaz" To: "nanog list" Sent: Friday, January 13, 2017 11:24:36 PM Subject: External BGP Controller for L3 Switch BGP routing Hello, A while back there was a discussion on how to do optimized (dynamic) BGP routing on a L3 switch which is only capable of handing a subset of BGP Routing table. Someone has pointed out that there was a project to do just that, and had posted a link to a presentation on a European operator (Ireland ? ) who had done some code to take Exabgp and create such a setup.. (I am going by memory... )... Needless to say I am trying to find that link, or name of that project. Anyone who can help in refreshing my memory with the link (my search skill are failing to find that presentation !) would be greatly appreciated. Many Thanks in Advance. Faisal Imtiaz From saku at ytti.fi Mon Jan 16 13:59:16 2017 From: saku at ytti.fi (Saku Ytti) Date: Mon, 16 Jan 2017 15:59:16 +0200 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <20170116133654.5239831f@echo.ms.redpill-linpro.com> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> <20170116133654.5239831f@echo.ms.redpill-linpro.com> Message-ID: On 16 January 2017 at 14:36, Tore Anderson wrote: > But here you're talking about the RTT of each individual link, right, > not the RTT of the entire path through the Internet for any given flow? I'm talking about RTT of end-to-end, which will determine window-size, which will determine burst-size. Your worst burst will be half of needed window size, and you need to be able to ingest this burst at sender rate, regardless of receiver rate. > Put it another way, my ?Internet facing? interfaces are typically 10GEs with > a few (kilo)metres of dark fibre that x-connects into my IP-transit providers' > routers sitting in nearby rooms or racks (worst case somewhere else in > the same metro area). Is there any reason why I should need deep > buffers on those interfaces? Imagine content network having 40Gbps connection, and client having 10Gbps connection, and network between them is lossless and has RTT of 200ms. To achieve 10Gbps rate receiver needs 10Gbps*200ms = 250MB window, in worst case 125MB window could grow into 250MB window, and sender could send the 125MB at 40Gbps burst. This means the port receiver is attached to, needs to store the 125MB, as it's only serialising it at 10Gbps. If it cannot store it, window will shrink and receiver cannot get 10Gbps. This is quite pathological example, but you can try with much less pathological numbers, remembering TridentII has 12MB of buffers. -- ++ytti From bernat at luffy.cx Mon Jan 16 14:06:11 2017 From: bernat at luffy.cx (Vincent Bernat) Date: Mon, 16 Jan 2017 15:06:11 +0100 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: (Saku Ytti's message of "Mon, 16 Jan 2017 14:08:53 +0200") References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Message-ID: <87r343qeuk.fsf@luffy.cx> ? 16 janvier 2017 14:08 +0200, Saku Ytti ?: > I wonder if true whitelabel is possible, would some 'real' HW vendor, > of BRCM size, release HW docs openly? Then some integrator could start > selling the HW with BOM+10-20%, no support, no software at all. And > community could build the actual software on it. > It seems to me, what is keeping us away from near-BOM prices is > software engineering, and we cannot do it as a community, as HW docs > are not available. Mellanox with switches like the SN2700. I don't know how open is the hardware documentation, but they are pushing support for their ASIC directly into Linux (look at drivers/net/ethernet/mellanox/mlxsw). They are also contributing to the switchdev framework which will at some point allow transparent acceleration of the Linux box (switching, routing, tunneling, firewalling, etc.), as we already have with CumulusOS. The datasheet is quite scarce. There is a 88k L2 forwarding entries but no word for L3. Buffer sizes are not mentioned. But I suppose that someone interested would be able to get more detailed information. -- "Elves and Dragons!" I says to him. "Cabbages and potatoes are better for you and me." -- J. R. R. Tolkien From tore at fud.no Mon Jan 16 14:53:28 2017 From: tore at fud.no (Tore Anderson) Date: Mon, 16 Jan 2017 15:53:28 +0100 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> <20170116133654.5239831f@echo.ms.redpill-linpro.com> Message-ID: <20170116155328.13a10b42@envy.e1.y.home> * Saku Ytti > On 16 January 2017 at 14:36, Tore Anderson wrote: > > > Put it another way, my ?Internet facing? interfaces are typically > > 10GEs with a few (kilo)metres of dark fibre that x-connects into my > > IP-transit providers' routers sitting in nearby rooms or racks > > (worst case somewhere else in the same metro area). Is there any > > reason why I should need deep buffers on those interfaces? > > Imagine content network having 40Gbps connection, and client having > 10Gbps connection, and network between them is lossless and has RTT of > 200ms. To achieve 10Gbps rate receiver needs 10Gbps*200ms = 250MB > window, in worst case 125MB window could grow into 250MB window, and > sender could send the 125MB at 40Gbps burst. > This means the port receiver is attached to, needs to store the 125MB, > as it's only serialising it at 10Gbps. If it cannot store it, window > will shrink and receiver cannot get 10Gbps. > > This is quite pathological example, but you can try with much less > pathological numbers, remembering TridentII has 12MB of buffers. I totally get why the receiver need bigger buffers if he's going to shuffle that data out another interface with a slower speed. But when you're a data centre operator you're (usually anyway) mostly transmitting data. And you can easily ensure the interface speed facing the servers can be the same as the interface speed facing the ISP. So if you consider this typical spine/leaf data centre network topology (essentially the same one I posted earlier this morning): (Server) --10GE--> (T2 leaf X) --40GE--> (T2 spine) --40GE--> (T2 leaf Y) --10GE--> (IP-transit/"the Internet") --10GE--> (Client) If I understand you correctly you're saying this is a "suspect" topology that cannot achieve 10G transmission rate from server to client (or from client to server for that matter) because of small buffers on my "T2 leaf Y" switch (i.e., the one which has the Internet-facing interface)? If so would it solve the problem just replacing "T2 leaf Y" with, say, a Juniper MX or something else with deeper buffers? Or would it help to use (4x)10GE instead of 40GE for the links between the leaf and spine layers too, so there was no change in interface speeds along the path through the data centre towards the handoff to the IPT provider? Tore From saku at ytti.fi Mon Jan 16 15:07:02 2017 From: saku at ytti.fi (Saku Ytti) Date: Mon, 16 Jan 2017 17:07:02 +0200 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <20170116155328.13a10b42@envy.e1.y.home> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> <20170116133654.5239831f@echo.ms.redpill-linpro.com> <20170116155328.13a10b42@envy.e1.y.home> Message-ID: On 16 January 2017 at 16:53, Tore Anderson wrote: Hey, > (Server) --10GE--> (T2 leaf X) --40GE--> (T2 spine) --40GE--> > (T2 leaf Y) --10GE--> (IP-transit/"the Internet") --10GE--> (Client) > > If I understand you correctly you're saying this is a "suspect" topology > that cannot achieve 10G transmission rate from server to client (or > from client to server for that matter) because of small buffers on my > "T2 leaf Y" switch (i.e., the one which has the Internet-facing > interface)? This mostly isn't suspect, depending how utilised it is. If it's verbatim like above, then it's never going to be suspect, as the T2_leaf_Y is going to see large pauses between each frame coming from the 40Gbps side, so it's not going to need to store large burst of 40Gbps traffic, as no one is generating at 40Gbps, so it can cope with very small buffers. -- ++ytti From matthew at corp.crocker.com Mon Jan 16 15:11:11 2017 From: matthew at corp.crocker.com (Matthew Crocker) Date: Mon, 16 Jan 2017 15:11:11 +0000 Subject: Questions on IPv6 deployment Message-ID: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Hello, I?m AS7849 and I have an IP problem. I?m running IPv4 ( /16 legacy + /20) and have enough space to last me for a while, multi-homed, BGP4 full tables + peering, ect. I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core. I want to start building my IPv6 infrastructure. I have a /32 assigned from ARIN (2001:4918::/32) I?m looking for some direction/reading list of how to properly configure IPv6. I?ve read to use a /64 for PtP interfaces and I?ve read use a /128 instead. Assign all loopbacks from the same /64, use a different /64 for each loopback. Ect, ect. I?m trying not to light a religious war but what is the current best practice for IPv6 deployment in a service provider network? PS. I?ll be at NANOG69 in DC next month, 1st NANOG for me after 22 years. ? -Matt -- Matthew Crocker Crocker Communications, Inc. President From chris at nifry.com Mon Jan 16 15:20:03 2017 From: chris at nifry.com (Chris Russell) Date: Mon, 16 Jan 2017 15:20:03 +0000 Subject: Questions on IPv6 deployment In-Reply-To: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Message-ID: <805783a1f6b38ab899e583ae8edc32d2@nifry.com> > I have a /32 assigned from ARIN (2001:4918::/32) > > I?m looking for some direction/reading list of how to properly > configure IPv6. I?ve read to use a /64 for PtP interfaces and I?ve > read use a /128 instead. Assign all loopbacks from the same /64, > use a different /64 for each loopback. Ect, ect. > > I?m trying not to light a religious war but what is the current best > practice for IPv6 deployment in a service provider network? > > PS. I?ll be at NANOG69 in DC next month, 1st NANOG for me after 22 > years. ? At the start, the advice was to configure individual /64 for loopbacks, however latterly its assign a /64 for loopbacks and configure /128 instead. Stick with a /48 for sites/customers. The best advice is to use nibble boundaries (see: https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-subnetting-card) hence /52 /56 /60 I also recommend watching this (Tom Coffeen from Infoblox at UKNOF35 which covers this exact subject): https://www.youtube.com/watch?v=lWFcIk4oMMU&feature=youtu.be&list=PLjzK5ZtLlc90teq9-rGzytIVu-hvsF9hd Its worth a watch and covers the basics HTH Chris From cb.list6 at gmail.com Mon Jan 16 17:17:06 2017 From: cb.list6 at gmail.com (Ca By) Date: Mon, 16 Jan 2017 17:17:06 +0000 Subject: Questions on IPv6 deployment In-Reply-To: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Message-ID: Why do not you feel compelled to ask this question? Did you ask this question when you deployed ipv4? AFAIK, everyone deploys ipv4 in a unique way. Same for ipv6. IPv6 is not exotic or filled with unique pitfalls. A lot of networks have deployed production networks with ipv6, each one unique, so you don't need to watch out for that one weird bug ( at least any more than ipv4). So, just like ipv4, read about the standards, read about vendor implementation that are close to you, make informed decisions. My only nugget of advice is to deploy ipv6 in such a way it is not forever coupled with ipv4. There will be a day when you deploy ipv6 without ipv4, this day already came for Facebook, Comast, T-mobile and others. I have not read this, but you may find the discussion helpful https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-12 On Mon, Jan 16, 2017 at 7:13 AM Matthew Crocker wrote: > > > Hello, > > > > I?m AS7849 and I have an IP problem. > > > > I?m running IPv4 ( /16 legacy + /20) and have enough space to last me for > a while, multi-homed, BGP4 full tables + peering, ect. > > I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core. > > > > I want to start building my IPv6 infrastructure. > > > > I have a /32 assigned from ARIN (2001:4918::/32) > > > > I?m looking for some direction/reading list of how to properly configure > IPv6. I?ve read to use a /64 for PtP interfaces and I?ve read use a /128 > instead. Assign all loopbacks from the same /64, use a different /64 for > each loopback. Ect, ect. > > > > I?m trying not to light a religious war but what is the current best > practice for IPv6 deployment in a service provider network? > > > > PS. I?ll be at NANOG69 in DC next month, 1st NANOG for me after 22 > years. ? > > > > -Matt > > > > -- > > Matthew Crocker > > Crocker Communications, Inc. > > President > > From vwittkop at nanog.org Mon Jan 16 20:00:58 2017 From: vwittkop at nanog.org (Valerie Wittkop) Date: Mon, 16 Jan 2017 15:00:58 -0500 Subject: [NANOG-announce] NANOG 69 Hotel Room Block Message-ID: NANOGers - The NANOG 69 Hotel Room block has been extended through COB today. There are still a few rooms available - make sure to book now if you need a hotel for the meeting next month. Use this link to reserve your room: https://aws.passkey.com/event/14495515/owner/544/home Cheers, Valerie Valerie Wittkop NANOG Program Director Tel: +1 866 902 1336, ext 103 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mark.tinka at seacom.mu Mon Jan 16 21:47:32 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 16 Jan 2017 23:47:32 +0200 Subject: Fwd: APRICOT 2017 programme reminder In-Reply-To: References: Message-ID: <694da766-9cc1-ec74-aaf9-ca972f238bc2@seacom.mu> Hello all. FYI. Mark. -------- Forwarded Message -------- Subject: [apnic-talk] APRICOT 2017 programme reminder Date: Sun, 15 Jan 2017 16:51:22 -1000 From: Philip Smith To: apnic-talk at apnic.net Hi everyone, Just a reminder that APRICOT 2017 begins in around one month from now, and that we still have some presentation opportunities available! If you or a colleague would like to present something of interest and relevant at APRICOT 2017, be it a conference talk or a tutorial, or host a BoF, please submit on-line at: http://papers.apricot.net/user/login.php?event=48 The deadline for submissions is 30th January, as we mentioned in the CfP. However we are filling presentation slots on a first come first served basis, so if you would like to ensure your place on the programme please submit your presentation asap. More information at the CfP page for APRICOT 2017: https://2017.apricot.net/program/call-for-papers/ Looking forward to hearing from you! Philip Smith & Mark Tinka APRICOT 2017 Programme Chairs -- _______________________________________________ apnic-talk mailing list apnic-talk at lists.apnic.net https://mailman.apnic.net/mailman/listinfo/apnic-talk . From magicsata at gmail.com Mon Jan 16 22:01:00 2017 From: magicsata at gmail.com (Alistair Mackenzie) Date: Mon, 16 Jan 2017 22:01:00 +0000 Subject: IPv6 BGP prefix filters Message-ID: Hi, So recently I've come across an issue with a large ISP announcing a /22 and /25 of IPv6 space. We are currently filtering <28 and >48 which until now has worked fine for us. What are others using as their prefix filters in the DFZ? Thanks, Alistair From job at instituut.net Mon Jan 16 22:17:26 2017 From: job at instituut.net (Job Snijders) Date: Mon, 16 Jan 2017 23:17:26 +0100 Subject: IPv6 BGP prefix filters In-Reply-To: References: Message-ID: <20170116221726.GL1062@Vurt.local> On Mon, Jan 16, 2017 at 10:01:00PM +0000, Alistair Mackenzie wrote: > So recently I've come across an issue with a large ISP announcing a > /22 and /25 of IPv6 space. We are currently filtering <28 and >48 > which until now has worked fine for us. > > What are others using as their prefix filters in the DFZ? The NTT global backbone (AS 2914) generally accepts (barring the other filters) IPv6 prefixes within "2000::/3 ge 12 le 48" over eBGP. Longer prefixes are only accepted on customer sessions, when a valid IRR route6 object exists. Kind regards, Job From joelja at bogus.com Mon Jan 16 22:21:06 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 16 Jan 2017 14:21:06 -0800 Subject: IPv6 BGP prefix filters In-Reply-To: References: Message-ID: <1b2186ad-e84a-9a00-947c-aaafa9eceb6b@bogus.com> On 1/16/17 2:01 PM, Alistair Mackenzie wrote: > Hi, > > So recently I've come across an issue with a large ISP announcing a /22 and > /25 of IPv6 space. We are currently filtering <28 and >48 which until now > has worked fine for us. > > What are others using as their prefix filters in the DFZ? Currently the shortest prefix delegation to an RIR is a /12, the assigned global uni-cast range at present all fits within 2000::/3. I currently apply < 20, > /48 but I also have recourse to default. > Thanks, > Alistair > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From pete at fiberphone.co.nz Mon Jan 16 23:20:53 2017 From: pete at fiberphone.co.nz (Pete Mundy) Date: Tue, 17 Jan 2017 12:20:53 +1300 Subject: Apple Caching Server question In-Reply-To: References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> Message-ID: <93F22430-7A6C-48D6-BCE9-DCC72C020337@fiberphone.co.nz> > On 14/01/2017, at 6:25 am, Blake Hudson wrote: > > lane.powers at swat.coop wrote on 1/13/2017 7:43 AM: >> I saw the apple caching server mentioned on an earlier thread. Is this appropriate/functional/scaleable enough to implement as an ISP? It is an intriguing idea. From the docs I could find, I couldn't tell if it was only geared towards home / small business or if it could scale up to handle ISP level traffic. >> >> thanks, >> Lane > > I have no experience with the Apple caching service specifically, but I have used Apple products (including some of their server software) for decades. Apple used to make mac mini models exclusively for server use. Their low power draw and relatively high density makes them an interesting choice for those that don't mind using "desktop grade" hardware for a project. There are some folks that even make rack-mount solutions for the Mac mini and Mac pro (search for RackMac). That said, my experience with several mac minis is that you will have at least one fault that will put them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3 year period when ran 24/7. > > With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect a mac mini to be as fast or faster than most other network appliances one might purchase. If one wanted something beefier, a mac pro would probably offer some expandability (on board dual 1gbps NICs + six 20Gbps thunderbolt 2 ports). > > I would see why one might be curious, especially if this could cache the IOS updates used for all those tablets and other iDevices folks purchase from Apple. Those dual Mac Mini 1U rack-mount cases are great! Two of the quad-core 'server' versions of the Minis gave quite a bit of punch for only 1RU @ 300mm deep. I have a couple of these types of builds deployed for VoIP services in different DCs, both with auto failover from one Mini to the other. But in the 6 years they've been operation we've never had any failure requiring use of the failover machines :) Re the Apple Caching Server - I don't believe that will work at the ISP level. My understanding is that the clients requesting their updates are redirected (by Apple's own servers) to the caching server only if the caching server and the requesting client both appear (from Apple's perspective) to originate from behind the same (NAT'd) public IP address. Pete From theodore at ciscodude.net Mon Jan 16 23:47:44 2017 From: theodore at ciscodude.net (Theodore Baschak) Date: Mon, 16 Jan 2017 17:47:44 -0600 Subject: Apple Caching Server question In-Reply-To: <93F22430-7A6C-48D6-BCE9-DCC72C020337@fiberphone.co.nz> References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> <93F22430-7A6C-48D6-BCE9-DCC72C020337@fiberphone.co.nz> Message-ID: > On Jan 16, 2017, at 5:20 PM, Pete Mundy wrote: > > > Those dual Mac Mini 1U rack-mount cases are great! Two of the quad-core 'server' versions of the Minis gave quite a bit of punch for only 1RU @ 300mm deep. > > I have a couple of these types of builds deployed for VoIP services in different DCs, both with auto failover from one Mini to the other. But in the 6 years they've been operation we've never had any failure requiring use of the failover machines :) > > Re the Apple Caching Server - I don't believe that will work at the ISP level. My understanding is that the clients requesting their updates are redirected (by Apple's own servers) to the caching server only if the caching server and the requesting client both appear (from Apple's perspective) to originate from behind the same (NAT'd) public IP address. > > Pete > I haven't ever tried to do multiple public IPs (I only enable caching server once inside my home network as a test), but it looks like from the settings window that it is possible to have more than one public IP using your cache. http://imgur.com/eBT7IyX When the "serve clients with public addresses: on other networks" configuration is enabled, "client configuration" button gives generated DNS records which were also mentioned elsewhere in this thread (_aaplcache._tcp 259200. TXT record per network) Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ From lists at mtin.net Mon Jan 16 23:51:42 2017 From: lists at mtin.net (Justin Wilson) Date: Mon, 16 Jan 2017 18:51:42 -0500 Subject: Apple Caching Server question In-Reply-To: <93F22430-7A6C-48D6-BCE9-DCC72C020337@fiberphone.co.nz> References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> <93F22430-7A6C-48D6-BCE9-DCC72C020337@fiberphone.co.nz> Message-ID: <0A3698DB-83FF-44C2-B30E-3B8ACE34E90A@mtin.net> https://support.apple.com/en-us/HT204675 Content types supported by the Caching service Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Jan 16, 2017, at 6:20 PM, Pete Mundy wrote: > >> On 14/01/2017, at 6:25 am, Blake Hudson wrote: >> >> lane.powers at swat.coop wrote on 1/13/2017 7:43 AM: >>> I saw the apple caching server mentioned on an earlier thread. Is this appropriate/functional/scaleable enough to implement as an ISP? It is an intriguing idea. From the docs I could find, I couldn't tell if it was only geared towards home / small business or if it could scale up to handle ISP level traffic. >>> >>> thanks, >>> Lane >> >> I have no experience with the Apple caching service specifically, but I have used Apple products (including some of their server software) for decades. Apple used to make mac mini models exclusively for server use. Their low power draw and relatively high density makes them an interesting choice for those that don't mind using "desktop grade" hardware for a project. There are some folks that even make rack-mount solutions for the Mac mini and Mac pro (search for RackMac). That said, my experience with several mac minis is that you will have at least one fault that will put them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3 year period when ran 24/7. >> >> With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect a mac mini to be as fast or faster than most other network appliances one might purchase. If one wanted something beefier, a mac pro would probably offer some expandability (on board dual 1gbps NICs + six 20Gbps thunderbolt 2 ports). >> >> I would see why one might be curious, especially if this could cache the IOS updates used for all those tablets and other iDevices folks purchase from Apple. > > > Those dual Mac Mini 1U rack-mount cases are great! Two of the quad-core 'server' versions of the Minis gave quite a bit of punch for only 1RU @ 300mm deep. > > I have a couple of these types of builds deployed for VoIP services in different DCs, both with auto failover from one Mini to the other. But in the 6 years they've been operation we've never had any failure requiring use of the failover machines :) > > Re the Apple Caching Server - I don't believe that will work at the ISP level. My understanding is that the clients requesting their updates are redirected (by Apple's own servers) to the caching server only if the caching server and the requesting client both appear (from Apple's perspective) to originate from behind the same (NAT'd) public IP address. > > Pete > From joe at nethead.com Mon Jan 16 03:32:11 2017 From: joe at nethead.com (Joe Hamelin) Date: Sun, 15 Jan 2017 19:32:11 -0800 Subject: St. Louis IX Launch In-Reply-To: <444065520.7946.1484529995937.JavaMail.mhammett@ThunderFuck> References: <1976838468.7889.1484526390975.JavaMail.mhammett@ThunderFuck> <372923401.7904.1484526642238.JavaMail.mhammett@ThunderFuck> <20170116003620.GM9040@sizone.org> <444065520.7946.1484529995937.JavaMail.mhammett@ThunderFuck> Message-ID: Congrats to St Louis! I put in about 40 racks for Clearwire a few years back and enjoyed the city, even if it was winter. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Sun, Jan 15, 2017 at 5:26 PM, Mike Hammett wrote: > It is a partnership and I may not be the most qualified to speak on the > terms of the partnership. However, the non-commercial side is > not-for-profit, but the commercial side is fully commercial. > > While building out our IX brand, of those that have been able to have a > rational discussion about their anti-commercial IX position, almost all of > them (or maybe even all of them) weren't really anti-commercial. They were > just anti-800-lb-gorilla. They didn't hate the independent building out > IXes in markets that maybe never had a functional IX, but surely didn't > have one now. They hated Equinix, Coresite, etc. They just wanted someone > that wasn't going to be a jerk to them. > > We don't have any aspirations to get to Equinix size. We know we're going > to small time places and that we'll only ever have small time IXes in the > big picture. The building we started at in Indy only advertises something > like 20 or 30 networks in the building. Now we've grown to other buildings > and they aren't going to list every Tom, Dick and Harry, but it's not a 300 > network market. We'll leave that to AMS-IX, DE-CIX, Megaport, etc. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Ken Chase" > To: "NANOG ???[nanog at nanog.org]???" > Sent: Sunday, January 15, 2017 6:36:20 PM > Subject: Re: St. Louis IX Launch > > congrats! > > I am curious, is the IX non-for-profit as well? The wikipedia entry for > IX's > doenst indicate which IX's are non-profit. Im curious as to the prevalence > and size (as well as the relative successes) of such IX's vs for profit > models > (equinix etc). > > /kc > > > On Sun, Jan 15, 2017 at 06:30:45PM -0600, Mike Hammett said: > >If you know someone that may be interested, we have a launch event later > this week for our St. Louis IX. St. Louis is a bit different than our > existing market in that we've partnered with a local non-profit that will > be focusing on non-commercial Internet aspects. These sorts of things are > innovation neighborhoods, IoT, healthcare, education, public safety, etc. > They may (or may not) be the big volume things we're used to, but they need > local, low-latency connectivity just as much. > > > >https://www.eventbrite.com/e/st-louis-regional-internet- > exchange-preview-tickets-30329718003?aff=NANOG > > > > > > > > > >----- > >Mike Hammett > >Intelligent Computing Solutions > > > >Midwest Internet Exchange > > > >The Brothers WISP > > > > -- > Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 > Toronto Canada > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 > Front St. W. > > From joelja at bogus.com Tue Jan 17 01:45:00 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 16 Jan 2017 17:45:00 -0800 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <20170116155328.13a10b42@envy.e1.y.home> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> <20170116133654.5239831f@echo.ms.redpill-linpro.com> <20170116155328.13a10b42@envy.e1.y.home> Message-ID: On 1/16/17 6:53 AM, Tore Anderson wrote: > * Saku Ytti > >> On 16 January 2017 at 14:36, Tore Anderson wrote: >> >>> Put it another way, my ?Internet facing? interfaces are typically >>> 10GEs with a few (kilo)metres of dark fibre that x-connects into my >>> IP-transit providers' routers sitting in nearby rooms or racks >>> (worst case somewhere else in the same metro area). Is there any >>> reason why I should need deep buffers on those interfaces? >> >> Imagine content network having 40Gbps connection, and client having >> 10Gbps connection, and network between them is lossless and has RTT of >> 200ms. To achieve 10Gbps rate receiver needs 10Gbps*200ms = 250MB >> window, in worst case 125MB window could grow into 250MB window, and >> sender could send the 125MB at 40Gbps burst. >> This means the port receiver is attached to, needs to store the 125MB, >> as it's only serialising it at 10Gbps. If it cannot store it, window >> will shrink and receiver cannot get 10Gbps. >> >> This is quite pathological example, but you can try with much less >> pathological numbers, remembering TridentII has 12MB of buffers. > > I totally get why the receiver need bigger buffers if he's going to > shuffle that data out another interface with a slower speed. > > But when you're a data centre operator you're (usually anyway) mostly > transmitting data. And you can easily ensure the interface speed facing > the servers can be the same as the interface speed facing the ISP. unlikely given that the interfaces facing the server is 1/10/25/50 and the one facing the isp is n x 10 or n x 100 > So if you consider this typical spine/leaf data centre network topology > (essentially the same one I posted earlier this morning): > > (Server) --10GE--> (T2 leaf X) --40GE--> (T2 spine) --40GE--> > (T2 leaf Y) --10GE--> (IP-transit/"the Internet") --10GE--> (Client) > > If I understand you correctly you're saying this is a "suspect" topology > that cannot achieve 10G transmission rate from server to client (or > from client to server for that matter) because of small buffers on my > "T2 leaf Y" switch (i.e., the one which has the Internet-facing > interface)? you can externalize the cost of the buffer at the expense of latency from the t2, e.g. by enabling flow control faciing the host or other high capacity device, or engaging in packet pacing on the server if the network is fairly shallow. If the question is how can I ensure high link utilization rather than maximum throughput for this one flow, the buffer requirement may be substantially lower. e.g. if you are sizing based on buffer = (bandwidth delay * desired bandwidth) / sqrt(nr of flows) http://conferences.sigcomm.org/sigcomm/2004/papers/p277-appenzeller1.pdf rather than buffer = (bandwidth delay * bandwidth) > If so would it solve the problem just replacing "T2 leaf Y" with, say, > a Juniper MX or something else with deeper buffers? broadcom jericho/ptx/qfx whatever sure it's plausible to have a large buffer without using the feature rich extremely large fib asic. > Or would it help to use (4x)10GE instead of 40GE for the links between > the leaf and spine layers too, so there was no change in interface > speeds along the path through the data centre towards the handoff to > the IPT provider? it can reduce the demand on the buffer, you can however multiplex two our more flows that might otherwise run at 10Gb/s onto the same lag member. > Tore > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From pete at fiberphone.co.nz Tue Jan 17 03:44:42 2017 From: pete at fiberphone.co.nz (Pete Mundy) Date: Tue, 17 Jan 2017 16:44:42 +1300 Subject: Apple Caching Server question In-Reply-To: References: <9557BFCC-8F87-45CC-90AC-A75950BDF6A9@swat.coop> <455205723.1791974.1484315038361.JavaMail.zimbra@swat.coop> <93F22430-7A6C-48D6-BCE9-DCC72C020337@fiberphone.co.nz> Message-ID: <8502E964-3C6B-43B2-9FFF-9C9267578412@fiberphone.co.nz> > On 17/01/2017, at 12:47 pm, Theodore Baschak wrote: > > I haven't ever tried to do multiple public IPs (I only enable caching server once inside my home network as a test), but it looks like from the settings window that it is possible to have more than one public IP using your cache. > http://imgur.com/eBT7IyX > > Interesting! Thanks Theodore for pointing that out. It's been almost a year since I investigated caching server, and they've obviously extended the functionality since then (I've not seen that settings panel before). In that case I retract my statement about it not being suitable for use at an ISP level. Perhaps it is after all! :) Pete From joelja at bogus.com Tue Jan 17 05:22:16 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 16 Jan 2017 21:22:16 -0800 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Message-ID: <4ff16eef-8756-2e28-99c2-542e02079cb7@bogus.com> On 1/15/17 11:00 PM, Yucong Sun wrote: > In my setup, I use an BIRD instance to combine multiple internet full > tables, i use some filter to generate some override route to send to my L3 > switch to do routing. The L3 switch is configured with the default route > to the main transit provider , if BIRD is down, the route would be > unoptimized, but everything else remain operable until i fixed that BIRD > instance. > > I've asked around about why there isn't a L3 switch capable of handling > full tables, I really don't understand the difference/logic behind it. In practice there are several merchant silicon implmentations that support the addition of external tcams. building them accordingly increases the COGS and and various performance and packaging limitions. arista 7280r and cisco ncs5500 are broadcom jericho based devices that are packaged accordingly. Ethernet merchant silicon is heavily biased towards doing most if not all the IO on the same asic, with limitations driven by gate size, die size, heat dissipation pin count an so on. There was a recent packet pushers episode with Pradeep Sindhu that touched on some of these issues: http://packetpushers.net/podcast/podcasts/show-315-future-networking-pradeep-sindhu/ > On Sun, Jan 15, 2017 at 10:43 PM Tore Anderson wrote: > >> Hi Saku, >> >>>> >> https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html >>> >>> --- >>> As described in a prevous post, we?re testing a HPE Altoline 6920 in >>> our lab. The Altoline 6920 is, like other switches based on the >>> Broadcom Trident II chipset, able to handle up to 720 Gbps of >>> throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis. >>> Its price is in all likelihood a single-digit percentage of the price >>> of a traditional Internet router with a comparable throughput rating. >>> --- >>> >>> This makes it sound like small-FIB router is single-digit percentage >>> cost of full-FIB. >> >> Do you know of any traditional ?Internet scale? router that can do ~720 >> Gbps of throughput for less than 10x the price of a Trident II box? Or >> even <100kUSD? (Disregarding any volume discounts.) >> >>> Also having Trident in Internet facing interface may be suspect, >>> especially if you need to go from fast interface to slow or busy >>> interface, due to very minor packet buffers. This obviously won't be >>> much of a problem in inside-DC traffic. >> >> Quite the opposite, changing between different interface speeds happens >> very commonly inside the data centre (and most of the time it's done by >> shallow-buffered switches using Trident II or similar chips). >> >> One ubiquitous configuration has the servers and any external uplinks >> attached with 10GE to leaf switches which in turn connects to a 40GE >> spine layer with. In this config server<->server and server<->Internet >> packets will need to change speed twice: >> >> [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet] >> >> I suppose you could for example use a couple of MX240s or something as >> a special-purpose leaf layer for external connectivity. >> MPC5E-40G10G-IRB or something towards the 40GE spines and any regular >> 10GE MPC towards the exits. That way you'd only have one >> shallow-buffered speed conversion remaining. But I'm very sceptical if >> something like this makes sense after taking the cost/benefit ratio >> into account. >> >> Tore >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From bedard.phil at gmail.com Tue Jan 17 16:31:10 2017 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 17 Jan 2017 11:31:10 -0500 Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <4ff16eef-8756-2e28-99c2-542e02079cb7@bogus.com> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> <4ff16eef-8756-2e28-99c2-542e02079cb7@bogus.com> Message-ID: <861FE6AE-E88B-411E-8C5D-48BE97888B7E@gmail.com> Cisco and Arista are both able to squeeze a current full Internet table into the base space on their Jericho boxes, using the right space partitioning. Cisco added this in 6.1.2 without anything in the release notes, but you?ll notice they bumped the datasheet spec on the base 5502 to 1M FIB now where it used to be 256K. It works with the standard Internet table, but may not work if you have a ton of routes with lengths that do not work well with how the memory is carved up. Of course Jericho is more expensive than Trident. Phil -----Original Message----- From: NANOG on behalf of joel jaeggli Date: Tuesday, January 17, 2017 at 00:22 To: Yucong Sun , Tore Anderson , Saku Ytti Cc: nanog list Subject: Re: External BGP Controller for L3 Switch BGP routing On 1/15/17 11:00 PM, Yucong Sun wrote: > In my setup, I use an BIRD instance to combine multiple internet full > tables, i use some filter to generate some override route to send to my L3 > switch to do routing. The L3 switch is configured with the default route > to the main transit provider , if BIRD is down, the route would be > unoptimized, but everything else remain operable until i fixed that BIRD > instance. > > I've asked around about why there isn't a L3 switch capable of handling > full tables, I really don't understand the difference/logic behind it. In practice there are several merchant silicon implmentations that support the addition of external tcams. building them accordingly increases the COGS and and various performance and packaging limitions. arista 7280r and cisco ncs5500 are broadcom jericho based devices that are packaged accordingly. From bill at herrin.us Tue Jan 17 16:48:09 2017 From: bill at herrin.us (William Herrin) Date: Tue, 17 Jan 2017 11:48:09 -0500 Subject: Questions on IPv6 deployment In-Reply-To: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Message-ID: On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker wrote: > I?m looking for some direction/reading list of how to properly configure IPv6. I?ve read to use a /64 for PtP interfaces and I?ve read use a /128 instead. Assign all loopbacks from the same /64, use a different /64 for each loopback. Ect, ect. Hi Matthew, Suggest /128's for loopbacks and /124's for point to points, all from the same /64. This way you don't burn space needlessly, don't open yourself to neighbor discovery issues on point to points and can filter inbound Internet packets to that /64 in one fell swoop so that it's harder to hit your routers directly. Just make sure not to filter the outbound packets. Reminder: No matter what size you pick, use nibble boundaries for visual and DNS convenience. So /124, not /126. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bedard.phil at gmail.com Tue Jan 17 16:51:12 2017 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 17 Jan 2017 11:51:12 -0500 Subject: BGP Route Reflector - Route Server, Router, etc In-Reply-To: <20170113223934.GA18835@radiological.warningg.com> References: <3E9C67DA261AC349B60FF3609F5E211D7D80357D@USI-2K10EX02-MT.usicorp.usinternet.com> <20170113223934.GA18835@radiological.warningg.com> Message-ID: <0C7C8BB4-1E63-4C76-A0F6-DDFF9AC81239@gmail.com> Cisco and Juniper both have working ORR implementations, although config on the Juniper one is a bit clunky right now. One interesting thing is they also allow feeding topology data via BGP-LS, so BGP is the only protocol you need to run to/from it. Phil -----Original Message----- From: NANOG on behalf of Brandon Ewing Date: Friday, January 13, 2017 at 17:39 To: Justin Krejci Cc: Subject: Re: BGP Route Reflector - Route Server, Router, etc On Thu, Jan 12, 2017 at 08:32:44PM +0000, Justin Krejci wrote: > What are the pros and cons of one design over another? On list or private off list replies would be great; I'd welcome real world experiences (especially any big gotchas or caveats people learned the hard way) as well as just links to previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion that covers this topic would be appreciated. > One important thing to remember when migrating from full mesh to a RR design is that you are reducing information available to the routers in the ASN. When you had a full mesh, each router could select the best path from all available paths, according to its position in the IGP. In a RR environment, by default, routers only have available to them the best routes from the RR's position in the IGP, which can lead to suboptimal exits being selected. Work is being done to allow RRs to compute metrics from the client's position in the IGP: See https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13 for more information -- Brandon Ewing (nicotine at warningg.com) From sander at steffann.nl Tue Jan 17 17:32:21 2017 From: sander at steffann.nl (Sander Steffann) Date: Tue, 17 Jan 2017 18:32:21 +0100 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Message-ID: <2026DD72-59A2-4536-B5EA-43B2E9CDDFE0@steffann.nl> Hi, > Suggest /128's for loopbacks and /124's for point to points, all from > the same /64. This way you don't burn space needlessly, don't open > yourself to neighbor discovery issues on point to points I usually reserve one /64 for loopbacks, reserve a /64 per point-to-point connection and configure a /127 using ::a on one side and ::b on the other. All of these from a block reserved for infrastructure for filtering: > and can > filter inbound Internet packets to that /64 in one fell swoop so that > it's harder to hit your routers directly. Just make sure not to filter > the outbound packets. Having a single block for infrastructure makes this very easy. In most cases I don't need to worry about "burning space needlessly" so I reserve /64s per point-to-point. Worrying about "wasting" address space is more often an IPv4-ism than good practice with IPv6 IMHO :-) But it all depends on the complexity of your network. There are cases where it makes sense to think about this. > Reminder: No matter what size you pick, use nibble boundaries for > visual and DNS convenience. So /124, not /126. Good advice! Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From stillwaxin at gmail.com Tue Jan 17 17:48:02 2017 From: stillwaxin at gmail.com (Michael Still) Date: Tue, 17 Jan 2017 12:48:02 -0500 Subject: Questions on IPv6 deployment In-Reply-To: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Message-ID: Hi, a few years back some in the community got together to write this: On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker wrote: > > Hello, > > I?m AS7849 and I have an IP problem. > > I?m running IPv4 ( /16 legacy + /20) and have enough space to last me for > a while, multi-homed, BGP4 full tables + peering, ect. > I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core. > > I want to start building my IPv6 infrastructure. > > I have a /32 assigned from ARIN (2001:4918::/32) > > I?m looking for some direction/reading list of how to properly configure > IPv6. I?ve read to use a /64 for PtP interfaces and I?ve read use a /128 > instead. Assign all loopbacks from the same /64, use a different /64 for > each loopback. Ect, ect. > > I?m trying not to light a religious war but what is the current best > practice for IPv6 deployment in a service provider network? > > PS. I?ll be at NANOG69 in DC next month, 1st NANOG for me after 22 > years. ? > > -Matt > > -- > Matthew Crocker > Crocker Communications, Inc. > President > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From stillwaxin at gmail.com Tue Jan 17 17:48:24 2017 From: stillwaxin at gmail.com (Michael Still) Date: Tue, 17 Jan 2017 12:48:24 -0500 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Message-ID: Oops: http://nabcop.org/index.php/IPv6_Subnetting On Tue, Jan 17, 2017 at 12:48 PM, Michael Still wrote: > Hi, a few years back some in the community got together to write this: > > On Mon, Jan 16, 2017 at 10:11 AM, Matthew Crocker < > matthew at corp.crocker.com> wrote: > >> >> Hello, >> >> I?m AS7849 and I have an IP problem. >> >> I?m running IPv4 ( /16 legacy + /20) and have enough space to last me >> for a while, multi-homed, BGP4 full tables + peering, ect. >> I have some new shiny Juniper MX480s (RE-S-2X00x6, 64MB RAM) in my core. >> >> I want to start building my IPv6 infrastructure. >> >> I have a /32 assigned from ARIN (2001:4918::/32) >> >> I?m looking for some direction/reading list of how to properly configure >> IPv6. I?ve read to use a /64 for PtP interfaces and I?ve read use a /128 >> instead. Assign all loopbacks from the same /64, use a different /64 for >> each loopback. Ect, ect. >> >> I?m trying not to light a religious war but what is the current best >> practice for IPv6 deployment in a service provider network? >> >> PS. I?ll be at NANOG69 in DC next month, 1st NANOG for me after 22 >> years. ? >> >> -Matt >> >> -- >> Matthew Crocker >> Crocker Communications, Inc. >> President >> > > > > -- > [stillwaxin at gmail.com ~]$ cat .signature > cat: .signature: No such file or directory > [stillwaxin at gmail.com ~]$ > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From bill at herrin.us Tue Jan 17 21:01:40 2017 From: bill at herrin.us (William Herrin) Date: Tue, 17 Jan 2017 16:01:40 -0500 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Message-ID: On Tue, Jan 17, 2017 at 12:48 PM, Michael Still wrote: > http://nabcop.org/index.php/IPv6_Subnetting That's overall good advice. I quibble with a couple of points: 1. If you plan to use a /126 on a point to point and can't imagine how you would use a /64 on that point to point, don't allocate a /64. Odds are that by the time you can imagine some way to use a /64 there, the details will require you to assign a new block anyway. Why be concerned about resource consumption? Because it's a good habit. Don't overdo it, IPv6 is not resource constrained the way IPv4 is, but shrewd use of available resources is a good habit even when resources are plentiful. 2. Make all your point to points /124. That will work for all your point to points. Serial or ethernet. Even the ethernets which have two high-availability routers on both ends along with the failover address needing a total of 6 IPs plus 1 for your troubleshooting laptop. Configuring /124 every time allows you to standardize your configuration, the same way /64 standardizes the netmask on a LAN deployment. One additional point not brought up: Minimum assignment to a customer: /60. Never ever /64 or /128. How much more than a /60 you choose as your minimum is up to you. Common choices are /56 and /48. But never, ever less than a /60. Your customer will want to deploy a /64 to each LAN. And there are so many cases where he'll want to deploy more than one LAN. I've noticed a lot of hosting providers getting this wrong. Some of your customers do create VPNs on their VPC you know. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From mhuff at ox.com Tue Jan 17 21:07:50 2017 From: mhuff at ox.com (Matthew Huff) Date: Tue, 17 Jan 2017 21:07:50 +0000 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> Message-ID: <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> The reason for allocating a /64 for a point to point link is due to various denial of service attack vectors. Just do it. The numbers in IPv6 are staggering. The generally accepted best practice is to allocate a /64 and use a /128 within that /64 for point to point links. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William > Herrin > Sent: Tuesday, January 17, 2017 4:02 PM > To: Michael Still > Cc: nanog at nanog.org > Subject: Re: Questions on IPv6 deployment > > On Tue, Jan 17, 2017 at 12:48 PM, Michael Still > wrote: > > http://nabcop.org/index.php/IPv6_Subnetting > > That's overall good advice. I quibble with a couple of points: > > 1. If you plan to use a /126 on a point to point and can't imagine how > you would use a /64 on that point to point, don't allocate a /64. Odds > are that by the time you can imagine some way to use a /64 there, the > details will require you to assign a new block anyway. > > Why be concerned about resource consumption? Because it's a good > habit. Don't overdo it, IPv6 is not resource constrained the way IPv4 > is, but shrewd use of available resources is a good habit even when > resources are plentiful. > > 2. Make all your point to points /124. That will work for all your > point to points. Serial or ethernet. Even the ethernets which have two > high-availability routers on both ends along with the failover address > needing a total of 6 IPs plus 1 for your troubleshooting laptop. > Configuring /124 every time allows you to standardize your > configuration, the same way /64 standardizes the netmask on a LAN > deployment. > > > > One additional point not brought up: > > Minimum assignment to a customer: /60. Never ever /64 or /128. How > much more than a /60 you choose as your minimum is up to you. Common > choices are /56 and /48. But never, ever less than a /60. Your > customer will want to deploy a /64 to each LAN. And there are so many > cases where he'll want to deploy more than one LAN. > > I've noticed a lot of hosting providers getting this wrong. Some of > your customers do create VPNs on their VPC you know. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From owen at delong.com Tue Jan 17 21:12:06 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 17 Jan 2017 13:12:06 -0800 Subject: Questions on IPv6 deployment In-Reply-To: <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> Message-ID: I think you mean /127 since a /128 would not support 2 points on the point to point. Owen > On Jan 17, 2017, at 13:07 , Matthew Huff wrote: > > The reason for allocating a /64 for a point to point link is due to various denial of service attack vectors. Just do it. The numbers in IPv6 are staggering. The generally accepted best practice is to allocate a /64 and use a /128 within that /64 for point to point links. > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William >> Herrin >> Sent: Tuesday, January 17, 2017 4:02 PM >> To: Michael Still >> Cc: nanog at nanog.org >> Subject: Re: Questions on IPv6 deployment >> >> On Tue, Jan 17, 2017 at 12:48 PM, Michael Still >> wrote: >>> http://nabcop.org/index.php/IPv6_Subnetting >> >> That's overall good advice. I quibble with a couple of points: >> >> 1. If you plan to use a /126 on a point to point and can't imagine how >> you would use a /64 on that point to point, don't allocate a /64. Odds >> are that by the time you can imagine some way to use a /64 there, the >> details will require you to assign a new block anyway. >> >> Why be concerned about resource consumption? Because it's a good >> habit. Don't overdo it, IPv6 is not resource constrained the way IPv4 >> is, but shrewd use of available resources is a good habit even when >> resources are plentiful. >> >> 2. Make all your point to points /124. That will work for all your >> point to points. Serial or ethernet. Even the ethernets which have two >> high-availability routers on both ends along with the failover address >> needing a total of 6 IPs plus 1 for your troubleshooting laptop. >> Configuring /124 every time allows you to standardize your >> configuration, the same way /64 standardizes the netmask on a LAN >> deployment. >> >> >> >> One additional point not brought up: >> >> Minimum assignment to a customer: /60. Never ever /64 or /128. How >> much more than a /60 you choose as your minimum is up to you. Common >> choices are /56 and /48. But never, ever less than a /60. Your >> customer will want to deploy a /64 to each LAN. And there are so many >> cases where he'll want to deploy more than one LAN. >> >> I've noticed a lot of hosting providers getting this wrong. Some of >> your customers do create VPNs on their VPC you know. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Owner, Dirtside Systems ......... Web: From bill at herrin.us Tue Jan 17 21:55:35 2017 From: bill at herrin.us (William Herrin) Date: Tue, 17 Jan 2017 16:55:35 -0500 Subject: Questions on IPv6 deployment In-Reply-To: <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> Message-ID: On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff wrote: > The reason for allocating a /64 for a point to point link is due to various denial of service attack vectors. Hi Matthew, I'm always interested in learning something new. Please explain the DOS vectors you're referring to and how they're mitigated by allocating a /64 to the point to point link. > Just do it. No. But if you offer a good reason, I'll factor your reason in to my considerations. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From joelja at bogus.com Tue Jan 17 22:07:40 2017 From: joelja at bogus.com (joel jaeggli) Date: Tue, 17 Jan 2017 14:07:40 -0800 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> Message-ID: <3f893c5b-c03a-6270-2940-0920c53363b3@bogus.com> On 1/17/17 1:55 PM, William Herrin wrote: > On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff wrote: >> The reason for allocating a /64 for a point to point link is due to various denial of service attack vectors. if you mean allocating a /127, then... sure. Neighbor discovery on point to point links could be a problem as is the poential for looping behavior . There are of course ways other than allocating a longer prefix to a point to point link to achieve that, e.g. disabling it. among other things You have to disable DAD anyway if you ever plan to loop them up for testing. these are detailed in https://tools.ietf.org/html/rfc6164 >> Hi Matthew, >> >> I'm always interested in learning something new. Please explain the >> DOS vectors you're referring to and how they're mitigated by >> allocating a /64 to the point to point link. >> >> >> Just do it. > No. But if you offer a good reason, I'll factor your reason in to my > considerations. > > Regards, > Bill Herrin > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From mhuff at ox.com Tue Jan 17 22:13:02 2017 From: mhuff at ox.com (Matthew Huff) Date: Tue, 17 Jan 2017 22:13:02 +0000 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> Message-ID: Please check the nanog archives. There were some arguments that I and I assume others felt compelling why allocating a /64 per point to point link was a good idea. Your network, your rules. I was just responding to the argument that a /64 is wasteful and serves little purpose. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 > -----Original Message----- > From: William Herrin [mailto:bill at herrin.us] > Sent: Tuesday, January 17, 2017 4:56 PM > To: Matthew Huff > Cc: Michael Still ; nanog at nanog.org > Subject: Re: Questions on IPv6 deployment > > On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff wrote: > > The reason for allocating a /64 for a point to point link is due to > various denial of service attack vectors. > > Hi Matthew, > > I'm always interested in learning something new. Please explain the > DOS vectors you're referring to and how they're mitigated by > allocating a /64 to the point to point link. > > > > Just do it. > > No. But if you offer a good reason, I'll factor your reason in to my > considerations. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From sander at steffann.nl Tue Jan 17 23:06:10 2017 From: sander at steffann.nl (Sander Steffann) Date: Wed, 18 Jan 2017 00:06:10 +0100 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> Message-ID: Hi Bill, > Op 17 jan. 2017, om 22:55 heeft William Herrin het volgende geschreven: > > I'm always interested in learning something new. Please explain the > DOS vectors you're referring to and how they're mitigated by > allocating a /64 to the point to point link. One thing that comes to mind is that it seems that some routers only have limited space in their routing tables for prefixes longer than a /64. If you would configure a /127 on the link but push the /64 to the routing table then you might both avoid ND Cache exhaustion and avoid the limitations on longer-than-/64 prefixes. I personally prefer to set up my addressing plan that things like this are possible even if I don't do it today, but I also understand the choices you make. I don't think any of the choices is wrong. It mostly depends on expectations, used equipment and personal preference. And thanks for mentioning "Minimum assignment to a customer: /60". That is indeed a very important one! Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hannigan at gmail.com Tue Jan 17 23:28:03 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 17 Jan 2017 18:28:03 -0500 Subject: Safe IPv4 Was: Re: premiumcolo.net IP address rental In-Reply-To: <20170109143403.109376c9@ispx.vb.futz.org> References: <20170109143403.109376c9@ispx.vb.futz.org> Message-ID: On Mon, Jan 9, 2017 at 2:34 PM, Robert Story wrote: > On Mon, 9 Jan 2017 13:40:23 -0500 Martin wrote: > MH> 2. Apply for and receive a last /22 from RIPE. EVERYONE can do this. > > Not quite everyone. You have to be a RIPE NCC member, which not everyone > can do. > > "Who can become a Local Internet Registry (LIR)/RIPE NCC member? > > Any organisation with a legally established office in the RIPE NCC > service region can become a member of the RIPE NCC." > > https://www.ripe.net/manage-ips-and-asns/resource-management/faq/faq-ipv4- > address-space > > > I'm not sure this applies to the situation we're discussing. For example, a US based corporation can apply and will receive an allocation of a /22 from the RIPE last /8. I believe they do become an LIR. That does not require an EU subsidiary or physical office. This is "good" for a variety of reasons including providing for need and rushing towards exhaustion. This isn't surreptitious. It is within policy. Best, -M< From bill at herrin.us Tue Jan 17 23:53:04 2017 From: bill at herrin.us (William Herrin) Date: Tue, 17 Jan 2017 18:53:04 -0500 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> Message-ID: On Tue, Jan 17, 2017 at 6:06 PM, Sander Steffann wrote: > One thing that comes to mind is that it seems that some routers only have limited space in their routing tables for prefixes longer than a /64. If you would configure a /127 on the link but push the /64 to the routing table then you might both avoid ND Cache exhaustion and avoid the limitations on longer-than-/64 prefixes. Hi Sander, IIRC, the problem was that some routers could only fit the first 64 bits in the TCAM so routes longer than /64 fell out of the fast path. That was about half a decade ago. No idea if anything modern still suffers from this. That would impact every route in Matthew's proposed solution: the loopbacks from the infrastructure /64 and the /127's from otherwise unpopulated /64's. Because programmatically those /64's don't have one prefix, they have two: the /127 for the link and the implicit null route for everything else. The router has to honor the implicit null route so it can't aggregate the /127 to /64 and keep it in the fast path. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Tue Jan 17 23:53:46 2017 From: bill at herrin.us (William Herrin) Date: Tue, 17 Jan 2017 18:53:46 -0500 Subject: Questions on IPv6 deployment In-Reply-To: References: <742C49EB-205D-4C96-BF96-DD61B361BE21@corp.crocker.com> <7df96f3fbe704d7b92e43da732c73be5@pur-vm-exch13n1.ox.com> Message-ID: On Tue, Jan 17, 2017 at 5:13 PM, Matthew Huff wrote: > Please check the nanog archives. > I was just responding to the argument that a /64 is wasteful and serves little purpose. Then respond. With explanation, reasoning and evidence. Telling me to search a massive archive for nebulous discussions is a total cop-out. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From eric-list at truenet.com Wed Jan 18 00:04:31 2017 From: eric-list at truenet.com (Eric Tykwinski) Date: Tue, 17 Jan 2017 19:04:31 -0500 Subject: DNS CAA records... Message-ID: <280728E2-F42B-4058-9120-9C82A5CBA981@truenet.com> So I?ve come across this on Qualys and just wondering if there?s any practical examples out there in the wild. I know some BIND guys are on here, so I?m sure I?m missing something from the RFCs. Just wanted to test this out on my play domains before putting it out in the wild... Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 From MWicker at esri.com Tue Jan 17 19:12:26 2017 From: MWicker at esri.com (Mark Wicker) Date: Tue, 17 Jan 2017 19:12:26 +0000 Subject: Level3 Internet service, out of order packets causing issues Message-ID: <7fe15b4b857040caae4ed38a1b982bb5@RED-INF-MXMB-P1.esri.com> Hi, I have 1G Level3 ethernet dedicated internet service as one of my ISP's at my company based in the Los Angeles (Inland Empire) area. After seeing strange application behavior while using this circuit, I failed it out of service and have been troubleshooting it with a directly connected machine (publically addressed, no firewall, nothing between this machine and our Level3 router). I have taken several packet captures while accessing various sites and have noticed large numbers of out of order packets which are wreaking havoc with TCP connections and other traffic. In my experience, per-packet load balancing across various different links can cause this issue. I do not see this behavior with my other ISP's. I have had several tickets opened with Level3 but have had no success. Any help here? Anyone out there seen this and have any contacts that may be able to help? FYI - we own our own public IP space and advertise via BGP to Level3. Currently I am using a dedicated /24 of our space advertised to Level3 only to ensure that the return path is through Level3 and not another ISP. Also, everything is single linked from a layer 2 and 3 perspective from the router to the test machine to ensure that the cause of any out of order packets is not on our end. Thanks, -- Mark Wicker | Senior Network Engineer Esri | 380 New York St | Redlands, CA 92354 | USA T 909 793 2853 x2741 | mwicker at esri.com | esri.com From synack at live.com Tue Jan 17 21:59:02 2017 From: synack at live.com (Darin Herteen) Date: Tue, 17 Jan 2017 21:59:02 +0000 Subject: Common Reliable Out Of Band Management Options at Carrier Hotels Message-ID: Greetings list, We are exploring standardizing our Out Of Band options across our network and various off-net locations and the question was brought up "What about carrier hotels? What constraints might present themselves at those locations?" Assuming each hotel we are located in can provide either Ethernet or DSL I'm guessing that is going to come a cost (cross-connects, rack space etc..) that might end up being cost prohibitive. So my inquiry is... What does the list find to be a reasonably priced yet reliable solution in carrier hotels for OOB? Or is that contradictory :) Thoughts on Cellular? Any experience/insight would be appreciated. Thanks, Darin From mpeterman at apple.com Tue Jan 17 23:15:39 2017 From: mpeterman at apple.com (Matt Peterman) Date: Tue, 17 Jan 2017 15:15:39 -0800 Subject: Anyone from Frontier? Reachability Issues to AS5650 Message-ID: Hello all! I have been unable to find a good contact for Frontier?s NOC, so I am hoping to have success here. I have reached out to the listed contacts in AS5650?s ARIN record to no avail. I am having issues reaching seemingly all IPs announced from AS5650. I am an AT&T customer with IP block 76.233.227.0/25 assigned to me. My connectivity seems to die somewhere in the handoff between AT&T and Frontiers network. Looking glasses show that AT&T is announcing my IPs as the aggregate 76.224.0.0/11, however bgp.he.net seems to also show that Frontier is announcing 76.233.226.0/23 somewhere (although all looking glasses show the only route to me is 76.224.0.0/11). I?m thinking somewhere in the AT&T/Frontier DSL sell-off Frontier is either not accepting the /11 from AT&T or has a hold down route for 76.233.226.0/23 somewhere in their network. Any help or contacts are appreciated as there are a number of sites and services I am unable to reach. All MTRs to networks in AS5650 die at the edge of AT&Ts network. Matt MTR to 107.191.134.73 from 76.233.227.54 Jan 16 20:26:35 2017 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 76.233.227.1 0.0% 27 1.6 2.0 1.2 4.1 0.7 2. 10.11.8.1 0.0% 27 2.2 2.1 1.0 4.6 1.0 3. 172.17.17.129 0.0% 27 1.9 3.2 1.6 14.8 2.7 4. ??? 5. 71.145.0.184 0.0% 27 22.6 23.6 20.2 47.0 5.3 6. 12.83.39.177 0.0% 27 24.4 24.9 21.0 34.7 3.0 7. 12.123.15.125 0.0% 27 33.6 45.6 21.0 154.1 37.1 8. ??? From nolan.berry at RACKSPACE.COM Wed Jan 18 00:12:32 2017 From: nolan.berry at RACKSPACE.COM (Nolan Berry) Date: Wed, 18 Jan 2017 00:12:32 +0000 Subject: DNS CAA records... In-Reply-To: <280728E2-F42B-4058-9120-9C82A5CBA981@truenet.com> References: <280728E2-F42B-4058-9120-9C82A5CBA981@truenet.com> Message-ID: So a quick look into this I see one potential real world example: ;; ANSWER SECTION: google.com. 129 IN A 216.58.218.142 google.com. 74411 IN NS ns4.google.com. google.com. 74411 IN NS ns1.google.com. google.com. 74411 IN NS ns2.google.com. google.com. 74411 IN NS ns3.google.com. google.com. 3054 IN TXT "v=spf1 include:_spf.google.com ~all" google.com. 64 IN AAAA 2607:f8b0:4000:802::200e google.com. 54475 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D In RFC 6844 section 7.1 it states "IANA has assigned Resource Record Type 257 for the CAA Resource Record Type" and I am seeing: google.com. 54475 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D Nolan Berry Linux Systems Engineer DNS Engineering Rackspace Hosting ________________________________ From: NANOG on behalf of Eric Tykwinski Sent: Tuesday, January 17, 2017 6:04:31 PM To: nanog list Subject: DNS CAA records... So I?ve come across this on Qualys and just wondering if there?s any practical examples out there in the wild. I know some BIND guys are on here, so I?m sure I?m missing something from the RFCs. Just wanted to test this out on my play domains before putting it out in the wild... Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 From royce at techsolvency.com Wed Jan 18 01:54:28 2017 From: royce at techsolvency.com (Royce Williams) Date: Tue, 17 Jan 2017 16:54:28 -0900 Subject: DNS CAA records... In-Reply-To: <280728E2-F42B-4058-9120-9C82A5CBA981@truenet.com> References: <280728E2-F42B-4058-9120-9C82A5CBA981@truenet.com> Message-ID: On Tue, Jan 17, 2017 at 3:04 PM, Eric Tykwinski wrote: > So I?ve come across this on Qualys and just wondering if there?s any practical examples out there in the wild. > I know some BIND guys are on here, so I?m sure I?m missing something from the RFCs. > Just wanted to test this out on my play domains before putting it out in the wild... As of 2016-12-31, here are CAA records for 143 domains: https://gist.github.com/roycewilliams/a5b2d26edf3b64ecf77a75f943de079f That gist contains all CAA (or unparsed/raw type 257) records as seen in the Rapid7 "DNS ANY" dataset [1] from 2016-12-31. Interestingly, google.com as noted by Nolan side-thread isn't in this dataset. Since "DNS ANY" is a superset of all DNS picked up by other scans, it may be that Rapid7's scanning isn't incidentally catching many CAA records. An explicit scan for CAA records (against, say, in all domains seen in DNS ANY) would likely be interesting. Also, I've requested that cPanel add CAA support to the DNS management tools. If that would be of use to you, feel free to upvote the feature [2]. Some good CAA refs are [3],[4],and [5]. Royce 1. https://scans.io/study/sonar.fdns 2. https://features.cpanel.net/topic/add-support-for-caa-dns-records-type-257 3. https://tools.ietf.org/html/rfc6844 4. https://sslmate.com/labs/caa/ (includes info on which CAs support them; it's early) 5. https://blog.dnsimple.com/2017/01/introducing-caa-records/ From jason at rokeach.net Wed Jan 18 02:55:04 2017 From: jason at rokeach.net (Jason Rokeach) Date: Tue, 17 Jan 2017 21:55:04 -0500 Subject: Level3 Internet service, out of order packets causing issues In-Reply-To: <7fe15b4b857040caae4ed38a1b982bb5@RED-INF-MXMB-P1.esri.com> References: <7fe15b4b857040caae4ed38a1b982bb5@RED-INF-MXMB-P1.esri.com> Message-ID: Hi Mark, I'm going to throw out a guess here. By any chance, is the first octet of your router's MAC address a 4 or a 6? In general, modern routers do not load balance per-packet, which is what caused out-of-order issues in days gone. Load balancing is usually done based on a hash of the source and/or destination IP of the packet, MPLS label, or Ethernet (on a switched interface). The most common cause for actual unordering of packets/frames in a modern service provider network, in my experience, is actually this hashing mechanism. Many vendor's hashing implementations assume, based on position in the frame, that a frame with a MAC address beginning with 4 or 6 is an IPv4 or IPv6 frame, not an MPLS frame. This can result in out of order packets. The most common fix is control word being applied on a pseudowire (assuming you are being carried across a pseudowire in the SP network), but if this *is* what is occurring, you could also resolve the issue by changing your MAC address. _______________________ *Jason R. Rokeach* m: 603.969.5549 e: jason at rokeach.net On Tue, Jan 17, 2017 at 2:12 PM, Mark Wicker wrote: > Hi, > > I have 1G Level3 ethernet dedicated internet service as one of my ISP's at > my company based in the Los Angeles (Inland Empire) area. After seeing > strange application behavior while using this circuit, I failed it out of > service and have been troubleshooting it with a directly connected machine > (publically addressed, no firewall, nothing between this machine and our > Level3 router). I have taken several packet captures while accessing > various sites and have noticed large numbers of out of order packets which > are wreaking havoc with TCP connections and other traffic. In my > experience, per-packet load balancing across various different links can > cause this issue. I do not see this behavior with my other ISP's. I have > had several tickets opened with Level3 but have had no success. Any help > here? Anyone out there seen this and have any contacts that may be able to > help? > > > FYI - we own our own public IP space and advertise via BGP to Level3. > Currently I am using a dedicated /24 of our space advertised to Level3 only > to ensure that the return path is through Level3 and not another ISP. Also, > everything is single linked from a layer 2 and 3 perspective from the > router to the test machine to ensure that the cause of any out of order > packets is not on our end. > > > Thanks, > > > -- > Mark Wicker | Senior Network Engineer > Esri | 380 New York St | Redlands, CA 92354 | USA > T 909 793 2853 x2741 | mwicker at esri.com | > esri.com > > From jason at rokeach.net Wed Jan 18 02:56:51 2017 From: jason at rokeach.net (Jason Rokeach) Date: Tue, 17 Jan 2017 21:56:51 -0500 Subject: Level3 Internet service, out of order packets causing issues In-Reply-To: <7fe15b4b857040caae4ed38a1b982bb5@RED-INF-MXMB-P1.esri.com> References: <7fe15b4b857040caae4ed38a1b982bb5@RED-INF-MXMB-P1.esri.com> Message-ID: Hi Mark, I'm going to throw out a guess here. By any chance, is the first octet of your router's MAC address a 4 or a 6? In general, modern routers do not load balance per-packet, which is what caused out-of-order issues in days gone. Load balancing is usually done based on a hash of the source and/or destination IP of the packet, MPLS label, or Ethernet (on a switched interface). The most common cause for actual unordering of packets/frames in a modern service provider network, in my experience, is actually this hashing mechanism. Many vendor's hashing implementations assume, based on position in the frame, that a frame with a MAC address beginning with 4 or 6 is an IPv4 or IPv6 frame, not an MPLS frame. This can result in out of order packets. The most common fix is control word being applied on a pseudowire (assuming you are being carried across a pseudowire in the SP network), but if this *is* what is occurring, you could also resolve the issue by changing your MAC address. On Tue, Jan 17, 2017 at 2:12 PM, Mark Wicker wrote: > Hi, > > I have 1G Level3 ethernet dedicated internet service as one of my ISP's at > my company based in the Los Angeles (Inland Empire) area. After seeing > strange application behavior while using this circuit, I failed it out of > service and have been troubleshooting it with a directly connected machine > (publically addressed, no firewall, nothing between this machine and our > Level3 router). I have taken several packet captures while accessing > various sites and have noticed large numbers of out of order packets which > are wreaking havoc with TCP connections and other traffic. In my > experience, per-packet load balancing across various different links can > cause this issue. I do not see this behavior with my other ISP's. I have > had several tickets opened with Level3 but have had no success. Any help > here? Anyone out there seen this and have any contacts that may be able to > help? > > > FYI - we own our own public IP space and advertise via BGP to Level3. > Currently I am using a dedicated /24 of our space advertised to Level3 only > to ensure that the return path is through Level3 and not another ISP. Also, > everything is single linked from a layer 2 and 3 perspective from the > router to the test machine to ensure that the cause of any out of order > packets is not on our end. > > > Thanks, > > > -- > Mark Wicker | Senior Network Engineer > Esri | 380 New York St | Redlands, CA 92354 | USA > T 909 793 2853 x2741 | mwicker at esri.com | > esri.com > > From marka at isc.org Wed Jan 18 03:39:02 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 18 Jan 2017 14:39:02 +1100 Subject: DNS CAA records... In-Reply-To: Your message of "Wed, 18 Jan 2017 00:12:32 -0000." References: <280728E2-F42B-4058-9120-9C82A5CBA981@truenet.com> Message-ID: <20170118033902.AFA2B5FAFFB1@rock.dv.isc.org> Or use up-to-date code. CAA support was added in BIND 9.8.8 (already end of lifed), BIND 9.9.6, BIND 9.10.1 and BIND 9.11.0. [rock:~/git/bind9] marka% dig caa google.com ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> caa google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42490 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 5f52c5d222feb5c9583cb70c587ee11a8f16c403c5fdbbd5 (good) ;; QUESTION SECTION: ;google.com. IN CAA ;; ANSWER SECTION: google.com. 86400 IN CAA 0 issue "symantec.com" ;; Query time: 192 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jan 18 14:29:30 EST 2017 ;; MSG SIZE rcvd: 98 [rock:~/git/bind9] marka% Anyway this is a good real life example of how you can add new types and have them be looked up without having to update the servers or the clients. "dig TYPE257 google.com" would have also worked. Mark In message , Nolan Berry writes: > So a quick look into this I see one potential real world example: > > > ;; ANSWER SECTION: > google.com. 129 IN A 216.58.218.142 > google.com. 74411 IN NS ns4.google.com. > google.com. 74411 IN NS ns1.google.com. > google.com. 74411 IN NS ns2.google.com. > google.com. 74411 IN NS ns3.google.com. > google.com. 3054 IN TXT "v=spf1 include:_spf.google.com > ~all" > google.com. 64 IN AAAA 2607:f8b0:4000:802::200e > google.com. 54475 IN TYPE257 \# 19 > 0005697373756573796D616E7465632E636F6D > > > In RFC 6844 section 7.1 it states > > > "IANA has assigned Resource Record Type 257 for the CAA Resource Record > Type" > > > and I am seeing: > > > google.com. 54475 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D > > > > Nolan Berry > > Linux Systems Engineer > > DNS Engineering > > Rackspace Hosting > > ________________________________ > From: NANOG on behalf of Eric Tykwinski > > Sent: Tuesday, January 17, 2017 6:04:31 PM > To: nanog list > Subject: DNS CAA records... > > So I've come across this on Qualys and just wondering if there's any > practical examples out there in the wild. > I know some BIND guys are on here, so I'm sure I'm missing something from > the RFCs. > Just wanted to test this out on my play domains before putting it out in > the wild... > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dhubbard at dino.hostasaurus.com Wed Jan 18 13:55:28 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 18 Jan 2017 13:55:28 +0000 Subject: Common Reliable Out Of Band Management Options at Carrier Hotels In-Reply-To: References: Message-ID: <761B376D-E2ED-4C78-913D-E69FE52800C9@dino.hostasaurus.com> Provided you can get a cell signal, we?ve been very happy with Opengear boxes. We?d been using their ACM5508 which is eight serial ports, two Ethernet, cell. It runs linux, you can ssh into it, do fancy things like keep the cell side down and use text messages to bring it up if you need to get in, does VPN, PPTP, monitors environmental things if needed, etc. They replaced that model with the 7004 and 7008 (4 or 8 serial). They have console servers if you need more ports; we have a 32-port daisy chained to a 5508 in a location we had serial growth, but their 7200-series is cell plus high density serial in one. In a data center with particularly bad cell reception, Opengear recommended getting a high gain antenna from wpsantennas.com. I contacted them and the recommendation for my specific use case was a Panorama WMMG-7-27. We had it mounted above the overhead infrastructure on top of our cage and it dramatically improved the signal to make it a non-issue. David On 1/17/17, 4:59 PM, "NANOG on behalf of Darin Herteen" wrote: Greetings list, We are exploring standardizing our Out Of Band options across our network and various off-net locations and the question was brought up "What about carrier hotels? What constraints might present themselves at those locations?" Assuming each hotel we are located in can provide either Ethernet or DSL I'm guessing that is going to come a cost (cross-connects, rack space etc..) that might end up being cost prohibitive. So my inquiry is... What does the list find to be a reasonably priced yet reliable solution in carrier hotels for OOB? Or is that contradictory :) Thoughts on Cellular? Any experience/insight would be appreciated. Thanks, Darin From maxtul at netassist.ua Wed Jan 18 15:03:01 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 18 Jan 2017 17:03:01 +0200 Subject: Safe IPv4 Was: Re: premiumcolo.net IP address rental In-Reply-To: References: <20170109143403.109376c9@ispx.vb.futz.org> Message-ID: <587F83A5.8080900@netassist.ua> Very strange. Everytime it was open for all companies need IP network will be used in RIPE region. Not for those having (any? main? branch? legal address?) office in the RIPE region. And it is still possible to open a RIPE LIR for offshore companies like BVI, Belize, Seychelles without any questions. On 18.01.17 01:28, Martin Hannigan wrote: > On Mon, Jan 9, 2017 at 2:34 PM, Robert Story wrote: > >> On Mon, 9 Jan 2017 13:40:23 -0500 Martin wrote: >> MH> 2. Apply for and receive a last /22 from RIPE. EVERYONE can do this. >> >> Not quite everyone. You have to be a RIPE NCC member, which not everyone >> can do. >> >> "Who can become a Local Internet Registry (LIR)/RIPE NCC member? >> >> Any organisation with a legally established office in the RIPE NCC >> service region can become a member of the RIPE NCC." >> >> https://www.ripe.net/manage-ips-and-asns/resource-management/faq/faq-ipv4- >> address-space >> >> >> > > I'm not sure this applies to the situation we're discussing. For example, a > US based corporation can apply and will receive an allocation of a /22 from > the RIPE last /8. I believe they do become an LIR. That does not require an > EU subsidiary or physical office. This is "good" for a variety of reasons > including providing for need and rushing towards exhaustion. This isn't > surreptitious. It is within policy. > > > Best, > > -M< > From patrick at ianai.net Wed Jan 18 15:13:09 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 18 Jan 2017 10:13:09 -0500 Subject: Common Reliable Out Of Band Management Options at Carrier Hotels In-Reply-To: <761B376D-E2ED-4C78-913D-E69FE52800C9@dino.hostasaurus.com> References: <761B376D-E2ED-4C78-913D-E69FE52800C9@dino.hostasaurus.com> Message-ID: +1 for OpenGear + LTE / cell. Obviously POTS works and is available in any carrier hotel and not insanely expensive. Also, lots (not all) colocation providers will give you very cheap ethernet OOB. (E.g. Our colo gives you GigE for the cost of the xconn + 2 Mbps 95/5 free.) I would ask before looking at getting a 3G/4G modem. Assuming, of course, you are comfortable with the colo provider?s network being diverse enough from your own. -- TTFN, patrick > On Jan 18, 2017, at 8:55 AM, David Hubbard wrote: > > Provided you can get a cell signal, we?ve been very happy with Opengear boxes. We?d been using their ACM5508 which is eight serial ports, two Ethernet, cell. It runs linux, you can ssh into it, do fancy things like keep the cell side down and use text messages to bring it up if you need to get in, does VPN, PPTP, monitors environmental things if needed, etc. They replaced that model with the 7004 and 7008 (4 or 8 serial). They have console servers if you need more ports; we have a 32-port daisy chained to a 5508 in a location we had serial growth, but their 7200-series is cell plus high density serial in one. > > In a data center with particularly bad cell reception, Opengear recommended getting a high gain antenna from wpsantennas.com. I contacted them and the recommendation for my specific use case was a Panorama WMMG-7-27. We had it mounted above the overhead infrastructure on top of our cage and it dramatically improved the signal to make it a non-issue. > > David > > On 1/17/17, 4:59 PM, "NANOG on behalf of Darin Herteen" wrote: > > Greetings list, > > > We are exploring standardizing our Out Of Band options across our network and various off-net locations and the question was brought up "What about carrier hotels? What constraints might present themselves at those locations?" > > > Assuming each hotel we are located in can provide either Ethernet or DSL I'm guessing that is going to come a cost (cross-connects, rack space etc..) that might end up being cost prohibitive. > > > So my inquiry is... What does the list find to be a reasonably priced yet reliable solution in carrier hotels for OOB? Or is that contradictory :) > > > Thoughts on Cellular? > > > Any experience/insight would be appreciated. > > > Thanks, > > > Darin > > From lguillory at reservetele.com Wed Jan 18 15:18:42 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 18 Jan 2017 15:18:42 +0000 Subject: Common Reliable Out Of Band Management Options at Carrier Hotels In-Reply-To: References: <761B376D-E2ED-4C78-913D-E69FE52800C9@dino.hostasaurus.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB04F4D5@RTC-EXCH01.RESERVE.LDS> We were quoted sub $200 for 10M DIA from the datacenter which included a copper handoff which would be more diverse than the cell option. Luke Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick W. Gilmore Sent: Wednesday, January 18, 2017 9:13 AM To: NANOG list Subject: Re: Common Reliable Out Of Band Management Options at Carrier Hotels +1 for OpenGear + LTE / cell. Obviously POTS works and is available in any carrier hotel and not insanely expensive. Also, lots (not all) colocation providers will give you very cheap ethernet OOB. (E.g. Our colo gives you GigE for the cost of the xconn + 2 Mbps 95/5 free.) I would ask before looking at getting a 3G/4G modem. Assuming, of course, you are comfortable with the colo provider?s network being diverse enough from your own. -- TTFN, patrick > On Jan 18, 2017, at 8:55 AM, David Hubbard wrote: > > Provided you can get a cell signal, we?ve been very happy with Opengear boxes. We?d been using their ACM5508 which is eight serial ports, two Ethernet, cell. It runs linux, you can ssh into it, do fancy things like keep the cell side down and use text messages to bring it up if you need to get in, does VPN, PPTP, monitors environmental things if needed, etc. They replaced that model with the 7004 and 7008 (4 or 8 serial). They have console servers if you need more ports; we have a 32-port daisy chained to a 5508 in a location we had serial growth, but their 7200-series is cell plus high density serial in one. > > In a data center with particularly bad cell reception, Opengear recommended getting a high gain antenna from wpsantennas.com. I contacted them and the recommendation for my specific use case was a Panorama WMMG-7-27. We had it mounted above the overhead infrastructure on top of our cage and it dramatically improved the signal to make it a non-issue. > > David > > On 1/17/17, 4:59 PM, "NANOG on behalf of Darin Herteen" wrote: > > Greetings list, > > > We are exploring standardizing our Out Of Band options across our network and various off-net locations and the question was brought up "What about carrier hotels? What constraints might present themselves at those locations?" > > > Assuming each hotel we are located in can provide either Ethernet or DSL I'm guessing that is going to come a cost (cross-connects, rack space etc..) that might end up being cost prohibitive. > > > So my inquiry is... What does the list find to be a reasonably priced yet reliable solution in carrier hotels for OOB? Or is that contradictory :) > > > Thoughts on Cellular? > > > Any experience/insight would be appreciated. > > > Thanks, > > > Darin > > From patrick at ianai.net Wed Jan 18 15:29:43 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 18 Jan 2017 10:29:43 -0500 Subject: Common Reliable Out Of Band Management Options at Carrier Hotels In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB04F4D5@RTC-EXCH01.RESERVE.LDS> References: <761B376D-E2ED-4C78-913D-E69FE52800C9@dino.hostasaurus.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB04F4D5@RTC-EXCH01.RESERVE.LDS> Message-ID: <22B326CF-AA06-4701-B369-DE9A5557D596@ianai.net> That is a good price, and a nice service from the provider. However, why is that more diverse than LTE? If the colo provider uses the same transit and/or transit provider(s) you do, it sounds very not-diverse. -- TTFN, patrick > On Jan 18, 2017, at 10:18 AM, Luke Guillory wrote: > > We were quoted sub $200 for 10M DIA from the datacenter which included a copper handoff which would be more diverse than the cell option. > > > > Luke > > > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > _________________________________________________________________________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick W. Gilmore > Sent: Wednesday, January 18, 2017 9:13 AM > To: NANOG list > Subject: Re: Common Reliable Out Of Band Management Options at Carrier Hotels > > +1 for OpenGear + LTE / cell. > > Obviously POTS works and is available in any carrier hotel and not insanely expensive. > > Also, lots (not all) colocation providers will give you very cheap ethernet OOB. (E.g. Our colo gives you GigE for the cost of the xconn + 2 Mbps 95/5 free.) I would ask before looking at getting a 3G/4G modem. Assuming, of course, you are comfortable with the colo provider?s network being diverse enough from your own. > > -- > TTFN, > patrick > >> On Jan 18, 2017, at 8:55 AM, David Hubbard wrote: >> >> Provided you can get a cell signal, we?ve been very happy with Opengear boxes. We?d been using their ACM5508 which is eight serial ports, two Ethernet, cell. It runs linux, you can ssh into it, do fancy things like keep the cell side down and use text messages to bring it up if you need to get in, does VPN, PPTP, monitors environmental things if needed, etc. They replaced that model with the 7004 and 7008 (4 or 8 serial). They have console servers if you need more ports; we have a 32-port daisy chained to a 5508 in a location we had serial growth, but their 7200-series is cell plus high density serial in one. >> >> In a data center with particularly bad cell reception, Opengear recommended getting a high gain antenna from wpsantennas.com. I contacted them and the recommendation for my specific use case was a Panorama WMMG-7-27. We had it mounted above the overhead infrastructure on top of our cage and it dramatically improved the signal to make it a non-issue. >> >> David >> >> On 1/17/17, 4:59 PM, "NANOG on behalf of Darin Herteen" wrote: >> >> Greetings list, >> >> >> We are exploring standardizing our Out Of Band options across our network and various off-net locations and the question was brought up "What about carrier hotels? What constraints might present themselves at those locations?" >> >> >> Assuming each hotel we are located in can provide either Ethernet or DSL I'm guessing that is going to come a cost (cross-connects, rack space etc..) that might end up being cost prohibitive. >> >> >> So my inquiry is... What does the list find to be a reasonably priced yet reliable solution in carrier hotels for OOB? Or is that contradictory :) >> >> >> Thoughts on Cellular? >> >> >> Any experience/insight would be appreciated. >> >> >> Thanks, >> >> >> Darin >> >> > From lguillory at reservetele.com Wed Jan 18 15:48:14 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 18 Jan 2017 15:48:14 +0000 Subject: Common Reliable Out Of Band Management Options at Carrier Hotels In-Reply-To: <22B326CF-AA06-4701-B369-DE9A5557D596@ianai.net> References: <761B376D-E2ED-4C78-913D-E69FE52800C9@dino.hostasaurus.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB04F4D5@RTC-EXCH01.RESERVE.LDS>, <22B326CF-AA06-4701-B369-DE9A5557D596@ianai.net> Message-ID: <913F3A04-2493-478E-9E08-F03952A6E9B2@reservetele.com> Cell site has one network in and out, that being the providers own network. This data center has many transit providers blended into their DIA while I might only have two at the location. While cell sites in larger cities might be in better shape than down here in the south, I've seen way to many go down around here from storms. What's makes ATT LTE network different from the ATT transit network that sits in the datacenter? While it gives me access to a network outside the datacenter it seems to limit me to only one network. Sent from my iPhone On Jan 18, 2017, at 9:31 AM, Patrick W. Gilmore > wrote: That is a good price, and a nice service from the provider. However, why is that more diverse than LTE? If the colo provider uses the same transit and/or transit provider(s) you do, it sounds very not-diverse. -- TTFN, patrick On Jan 18, 2017, at 10:18 AM, Luke Guillory > wrote: We were quoted sub $200 for 10M DIA from the datacenter which included a copper handoff which would be more diverse than the cell option. Luke Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Luke Guillory Network Operations Manager [cid:image2f54cf.JPG at c142b4cb.4dad6009] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick W. Gilmore Sent: Wednesday, January 18, 2017 9:13 AM To: NANOG list Subject: Re: Common Reliable Out Of Band Management Options at Carrier Hotels +1 for OpenGear + LTE / cell. Obviously POTS works and is available in any carrier hotel and not insanely expensive. Also, lots (not all) colocation providers will give you very cheap ethernet OOB. (E.g. Our colo gives you GigE for the cost of the xconn + 2 Mbps 95/5 free.) I would ask before looking at getting a 3G/4G modem. Assuming, of course, you are comfortable with the colo provider?s network being diverse enough from your own. -- TTFN, patrick On Jan 18, 2017, at 8:55 AM, David Hubbard > wrote: Provided you can get a cell signal, we?ve been very happy with Opengear boxes. We?d been using their ACM5508 which is eight serial ports, two Ethernet, cell. It runs linux, you can ssh into it, do fancy things like keep the cell side down and use text messages to bring it up if you need to get in, does VPN, PPTP, monitors environmental things if needed, etc. They replaced that model with the 7004 and 7008 (4 or 8 serial). They have console servers if you need more ports; we have a 32-port daisy chained to a 5508 in a location we had serial growth, but their 7200-series is cell plus high density serial in one. In a data center with particularly bad cell reception, Opengear recommended getting a high gain antenna from wpsantennas.com. I contacted them and the recommendation for my specific use case was a Panorama WMMG-7-27. We had it mounted above the overhead infrastructure on top of our cage and it dramatically improved the signal to make it a non-issue. David On 1/17/17, 4:59 PM, "NANOG on behalf of Darin Herteen" on behalf of synack at live.com> wrote: Greetings list, We are exploring standardizing our Out Of Band options across our network and various off-net locations and the question was brought up "What about carrier hotels? What constraints might present themselves at those locations?" Assuming each hotel we are located in can provide either Ethernet or DSL I'm guessing that is going to come a cost (cross-connects, rack space etc..) that might end up being cost prohibitive. So my inquiry is... What does the list find to be a reasonably priced yet reliable solution in carrier hotels for OOB? Or is that contradictory :) Thoughts on Cellular? Any experience/insight would be appreciated. Thanks, Darin From faisal at snappytelecom.net Wed Jan 18 17:24:54 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 18 Jan 2017 17:24:54 +0000 (GMT) Subject: Common Reliable Out Of Band Management Options at Carrier Hotels In-Reply-To: References: Message-ID: <1181778062.1631367.1484760294278.JavaMail.zimbra@snappytelecom.net> I think you will have a tough time finding a universal solution that will fit for all DataCenters (speaking in the context of OOB communication method). Traditional connections via Ethernet / T1 /Phone lines will cost you a fair amount (monthly service and cross-connect). In some of the DataCenters you can use a cellular (M2M ) based solution.. (use something like a cradle point or other similar functioning devices) In many of our DC we will exchange (bidirectional) OOB connection with another network (which is multi-homed). Quite a few of the DC's also provide Courtesy Wifi for customer's use .. it is possible to configure an OOB to use that connection.. (takes a bit of creativity). Since part of our network is using Fixed Wireless Technologies, we are pretty familiar with Mikrotik Routerboards they have a number of small, inexpensive devices which allow for very flexible configurations (including devices with USB ports that support USB Cellular dongles). Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Darin Herteen" > To: "nanog list" > Sent: Tuesday, January 17, 2017 4:59:02 PM > Subject: Common Reliable Out Of Band Management Options at Carrier Hotels > Greetings list, > > > We are exploring standardizing our Out Of Band options across our network and > various off-net locations and the question was brought up "What about carrier > hotels? What constraints might present themselves at those locations?" > > > Assuming each hotel we are located in can provide either Ethernet or DSL I'm > guessing that is going to come a cost (cross-connects, rack space etc..) that > might end up being cost prohibitive. > > > So my inquiry is... What does the list find to be a reasonably priced yet > reliable solution in carrier hotels for OOB? Or is that contradictory :) > > > Thoughts on Cellular? > > > Any experience/insight would be appreciated. > > > Thanks, > > > Darin From MWicker at esri.com Wed Jan 18 18:57:37 2017 From: MWicker at esri.com (Mark Wicker) Date: Wed, 18 Jan 2017 18:57:37 +0000 Subject: Level3 Internet service, out of order packets causing issues In-Reply-To: References: <7fe15b4b857040caae4ed38a1b982bb5@RED-INF-MXMB-P1.esri.com> Message-ID: <82cd22423632432d820de88e14ed4041@RED-INF-MXMB-P1.esri.com> Hi Jason, I think that this was it. The first octet of our router?s Level3 facing interface MAC is a 6. Changed it to 0 and it does look much better now. Thanks! -- Mark Wicker | Senior Network Engineer Esri | 380 New York St | Redlands, CA 92354 | USA T 909 793 2853 x2741 | mwicker at esri.com | esri.com From: Jason Rokeach [mailto:jason at rokeach.net] Sent: Tuesday, January 17, 2017 6:57 PM To: Mark Wicker Cc: nanog at nanog.org Subject: Re: Level3 Internet service, out of order packets causing issues Hi Mark, I'm going to throw out a guess here. By any chance, is the first octet of your router's MAC address a 4 or a 6? In general, modern routers do not load balance per-packet, which is what caused out-of-order issues in days gone. Load balancing is usually done based on a hash of the source and/or destination IP of the packet, MPLS label, or Ethernet (on a switched interface). The most common cause for actual unordering of packets/frames in a modern service provider network, in my experience, is actually this hashing mechanism. Many vendor's hashing implementations assume, based on position in the frame, that a frame with a MAC address beginning with 4 or 6 is an IPv4 or IPv6 frame, not an MPLS frame. This can result in out of order packets. The most common fix is control word being applied on a pseudowire (assuming you are being carried across a pseudowire in the SP network), but if this is what is occurring, you could also resolve the issue by changing your MAC address. On Tue, Jan 17, 2017 at 2:12 PM, Mark Wicker > wrote: Hi, I have 1G Level3 ethernet dedicated internet service as one of my ISP's at my company based in the Los Angeles (Inland Empire) area. After seeing strange application behavior while using this circuit, I failed it out of service and have been troubleshooting it with a directly connected machine (publically addressed, no firewall, nothing between this machine and our Level3 router). I have taken several packet captures while accessing various sites and have noticed large numbers of out of order packets which are wreaking havoc with TCP connections and other traffic. In my experience, per-packet load balancing across various different links can cause this issue. I do not see this behavior with my other ISP's. I have had several tickets opened with Level3 but have had no success. Any help here? Anyone out there seen this and have any contacts that may be able to help? FYI - we own our own public IP space and advertise via BGP to Level3. Currently I am using a dedicated /24 of our space advertised to Level3 only to ensure that the return path is through Level3 and not another ISP. Also, everything is single linked from a layer 2 and 3 perspective from the router to the test machine to ensure that the cause of any out of order packets is not on our end. Thanks, -- Mark Wicker | Senior Network Engineer Esri | 380 New York St | Redlands, CA 92354 | USA T 909 793 2853 x2741 | mwicker at esri.com> | esri.com From alarig at swordarmor.fr Wed Jan 18 20:35:34 2017 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Wed, 18 Jan 2017 21:35:34 +0100 Subject: [outages] ntp.org DNS lookups failing In-Reply-To: <20170118202523.GW78624@greenie.muc.de> References: <14131ada-d8e2-faa2-8e96-29ee58734a96@iteris.com> <20170118202523.GW78624@greenie.muc.de> Message-ID: <20170118203534.s3vm7jb2qb3pfp5p@kaiminus> Hi, On Wed Jan 18 21:25:23 2017, Gert Doering via Outages wrote: > Trying to query directly, ns1/ns2.ntp.org return SERVFAIL as well, > and ns1/ns2.everett.org do not reply at all... so pure guesswork on > my side says "the original set is broken / under attack / ..., so > new servers have been added, but as long as the old NS records are > still being cached, things keep failing". I see the same behaviour: alarig at pikachu ~ % dig -t NS ntp.org ; <<>> DiG 9.11.0-P2 <<>> -t NS ntp.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44422 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ntp.org. IN NS ;; Query time: 52 msec ;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1) ;; WHEN: Wed Jan 18 21:28:08 CET 2017 ;; MSG SIZE rcvd: 36 alarig at pikachu ~ % ssh alarig at log.bzh alarig at log:~$ sudo unbound-control flush_zone ntp.org [sudo] password for alarig: ok removed 8 rrsets, 0 messages and 0 key entries ^D alarig at log:~$ d?connexion Connection to log.bzh closed. alarig at pikachu ~ % dig -t NS ntp.org ; <<>> DiG 9.11.0-P2 <<>> -t NS ntp.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53621 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ntp.org. IN NS ;; ANSWER SECTION: ntp.org. 3600 IN NS ns1.everett.org. ntp.org. 3600 IN NS ns2.everett.org. ntp.org. 3600 IN NS ns4.p20.dynect.net. ntp.org. 3600 IN NS dns2.udel.edu. ntp.org. 3600 IN NS anyns.pch.net. ntp.org. 3600 IN NS dns1.udel.edu. ntp.org. 3600 IN NS ns1.p20.dynect.net. ntp.org. 3600 IN NS ns2.p20.dynect.net. ntp.org. 3600 IN NS ns3.p20.dynect.net. ;; Query time: 178 msec ;; SERVER: 2a00:5884:8218::1#53(2a00:5884:8218::1) ;; WHEN: Wed Jan 18 21:31:51 CET 2017 ;; MSG SIZE rcvd: 236 -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From faisal at snappytelecom.net Fri Jan 20 01:27:59 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 20 Jan 2017 01:27:59 +0000 (GMT) Subject: External BGP Controller for L3 Switch BGP routing In-Reply-To: <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> References: <432759437.1584530.1484371476169.JavaMail.zimbra@snappytelecom.net> <20170116074047.4bb46a13@echo.ms.redpill-linpro.com> Message-ID: <666499756.1653425.1484875679748.JavaMail.zimbra@snappytelecom.net> Thank you for all the on-list and off-list replies.. The project I was looking for was/is called SIR.. (SDN Internet Router) and the original presentation was done by David Barroso.. Thanks to everyone who responded ! Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Tore Anderson" > To: "Saku Ytti" > Cc: "nanog list" > Sent: Monday, January 16, 2017 1:40:47 AM > Subject: Re: External BGP Controller for L3 Switch BGP routing > Hi Saku, > >> > https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html >> >> --- >> As described in a prevous post, we?re testing a HPE Altoline 6920 in >> our lab. The Altoline 6920 is, like other switches based on the >> Broadcom Trident II chipset, able to handle up to 720 Gbps of >> throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis. >> Its price is in all likelihood a single-digit percentage of the price >> of a traditional Internet router with a comparable throughput rating. >> --- >> >> This makes it sound like small-FIB router is single-digit percentage >> cost of full-FIB. > > Do you know of any traditional ?Internet scale? router that can do ~720 > Gbps of throughput for less than 10x the price of a Trident II box? Or > even <100kUSD? (Disregarding any volume discounts.) > >> Also having Trident in Internet facing interface may be suspect, >> especially if you need to go from fast interface to slow or busy >> interface, due to very minor packet buffers. This obviously won't be >> much of a problem in inside-DC traffic. > > Quite the opposite, changing between different interface speeds happens > very commonly inside the data centre (and most of the time it's done by > shallow-buffered switches using Trident II or similar chips). > > One ubiquitous configuration has the servers and any external uplinks > attached with 10GE to leaf switches which in turn connects to a 40GE > spine layer with. In this config server<->server and server<->Internet > packets will need to change speed twice: > > [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet] > > I suppose you could for example use a couple of MX240s or something as > a special-purpose leaf layer for external connectivity. > MPC5E-40G10G-IRB or something towards the 40GE spines and any regular > 10GE MPC towards the exits. That way you'd only have one > shallow-buffered speed conversion remaining. But I'm very sceptical if > something like this makes sense after taking the cost/benefit ratio > into account. > > Tore From cscora at apnic.net Fri Jan 20 18:01:48 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Jan 2017 04:01:48 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170120180148.4081EC4506@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Jan, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 628911 Prefixes after maximum aggregation (per Origin AS): 221875 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 305028 Total ASes present in the Internet Routing Table: 55644 Prefixes per ASN: 11.30 Origin-only ASes present in the Internet Routing Table: 36238 Origin ASes announcing only one prefix: 15200 Transit ASes present in the Internet Routing Table: 6554 Transit-only ASes present in the Internet Routing Table: 175 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 55 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 50 Unregistered ASNs in the Routing Table: 15 Number of 32-bit ASNs allocated by the RIRs: 16987 Number of 32-bit ASNs visible in the Routing Table: 12852 Prefixes from 32-bit ASNs in the Routing Table: 53001 Number of bogon 32-bit ASNs visible in the Routing Table: 791 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 382 Number of addresses announced to Internet: 2833896452 Equivalent to 168 /8s, 233 /16s and 212 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 208269 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156592 Total APNIC prefixes after maximum aggregation: 43096 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 171378 Unique aggregates announced from the APNIC address blocks: 70992 APNIC Region origin ASes present in the Internet Routing Table: 5182 APNIC Prefixes per ASN: 33.07 APNIC Region origin ASes announcing only one prefix: 1139 APNIC Region transit ASes present in the Internet Routing Table: 940 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 55 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2624 Number of APNIC addresses announced to Internet: 762086564 Equivalent to 45 /8s, 108 /16s and 132 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188456 Total ARIN prefixes after maximum aggregation: 89475 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195492 Unique aggregates announced from the ARIN address blocks: 89769 ARIN Region origin ASes present in the Internet Routing Table: 16064 ARIN Prefixes per ASN: 12.17 ARIN Region origin ASes announcing only one prefix: 5591 ARIN Region transit ASes present in the Internet Routing Table: 1722 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1721 Number of ARIN addresses announced to Internet: 1104147360 Equivalent to 65 /8s, 207 /16s and 243 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 151475 Total RIPE prefixes after maximum aggregation: 73402 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 162986 Unique aggregates announced from the RIPE address blocks: 99214 RIPE Region origin ASes present in the Internet Routing Table: 18152 RIPE Prefixes per ASN: 8.98 RIPE Region origin ASes announcing only one prefix: 7757 RIPE Region transit ASes present in the Internet Routing Table: 3040 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5110 Number of RIPE addresses announced to Internet: 709772672 Equivalent to 42 /8s, 78 /16s and 69 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 64000 Total LACNIC prefixes after maximum aggregation: 12598 LACNIC Deaggregation factor: 5.08 Prefixes being announced from the LACNIC address blocks: 80902 Unique aggregates announced from the LACNIC address blocks: 37944 LACNIC Region origin ASes present in the Internet Routing Table: 2480 LACNIC Prefixes per ASN: 32.62 LACNIC Region origin ASes announcing only one prefix: 542 LACNIC Region transit ASes present in the Internet Routing Table: 597 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3108 Number of LACNIC addresses announced to Internet: 171100736 Equivalent to 10 /8s, 50 /16s and 202 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15336 Total AfriNIC prefixes after maximum aggregation: 3297 AfriNIC Deaggregation factor: 4.65 Prefixes being announced from the AfriNIC address blocks: 17771 Unique aggregates announced from the AfriNIC address blocks: 6777 AfriNIC Region origin ASes present in the Internet Routing Table: 734 AfriNIC Prefixes per ASN: 24.21 AfriNIC Region origin ASes announcing only one prefix: 171 AfriNIC Region transit ASes present in the Internet Routing Table: 185 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 289 Number of AfriNIC addresses announced to Internet: 86341376 Equivalent to 5 /8s, 37 /16s and 119 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5542 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3735 390 254 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2979 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2732 11133 743 KIXS-AS-KR Korea Telecom, KR 9829 2695 1499 538 BSNL-NIB National Internet Backbone, IN 9808 2278 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2053 429 219 TATACOMM-AS TATA Communications formerl 45899 1767 1268 95 VNPT-AS-VN VNPT Corp, VN 4808 1646 1794 455 CHINA169-BJ China Unicom Beijing Provin 24560 1563 561 246 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3616 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3307 1333 83 SHAW - Shaw Communications Inc., CA 18566 2192 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2094 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1960 2027 404 CHARTER-NET-HKY-NC - Charter Communicat 209 1715 5066 639 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1697 319 463 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1679 848 227 ITCDELTA - Earthlink, Inc., US 701 1600 10629 662 UUNET - MCI Communications Services, In 16509 1580 3046 532 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3011 1136 2132 AKAMAI-ASN1 , US 9121 2207 1707 95 TTNET , TR 34984 1986 327 376 TELLCOM-AS , TR 13188 1604 99 61 TRIOLAN , UA 12479 1434 1033 51 UNI2-AS , ES 6849 1313 355 22 UKRTELNET , UA 8551 1223 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 8402 1107 544 15 CORBINA-AS OJSC "Vimpelcom", RU 12389 992 1161 447 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3538 545 156 Telmex Colombia S.A., CO 8151 2489 3380 553 Uninet S.A. de C.V., MX 11830 1800 368 66 Instituto Costarricense de Electricidad 6503 1547 437 54 Axtel, S.A.B. de C.V., MX 7303 1526 974 254 Telecom Argentina S.A., AR 6147 1352 377 27 Telefonica del Peru S.A.A., PE 28573 1062 2271 178 CLARO S.A., BR 11664 1017 279 32 Techtel LMDS Comunicaciones Interactiva 3816 1006 479 179 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 17072 972 127 345 TOTAL PLAY TELECOMUNICACIONES SA DE CV, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1289 398 42 LINKdotNET-AS, EG 36903 719 361 123 MT-MPLS, MA 37611 680 67 6 Afrihost, ZA 36992 584 1373 25 ETISALAT-MISR, EG 8452 484 1474 16 TE-AS TE-AS, EG 24835 454 594 16 RAYA-AS, EG 37492 410 324 75 ORANGE-TN, TN 29571 368 36 10 CITelecom-AS, CI 15399 318 35 6 WANANCHI-KE, KE 2018 287 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5542 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3735 390 254 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3616 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3538 545 156 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3307 1333 83 SHAW - Shaw Communications Inc., CA 20940 3011 1136 2132 AKAMAI-ASN1 , US 17974 2979 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2732 11133 743 KIXS-AS-KR Korea Telecom, KR 9829 2695 1499 538 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3735 3481 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3616 3465 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3538 3382 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3307 3224 SHAW - Shaw Communications Inc., CA 17974 2979 2908 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2278 2245 CMNET-GD Guangdong Mobile Communication 9829 2695 2157 BSNL-NIB National Internet Backbone, IN 9121 2207 2112 TTNET , TR 18566 2192 2083 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom 65001 PRIVATE 94.242.128.0/20 15468 KLGELECS-AS 38, Teatralnaya st Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:532 /14:1048 /15:1794 /16:13184 /17:7777 /18:13018 /19:25139 /20:38094 /21:40719 /22:73482 /23:61465 /24:350858 /25:553 /26:409 /27:294 /28:34 /29:20 /30:18 /31:1 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3103 3307 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2813 3616 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2085 2192 MEGAPATH5-US - MegaPath Corporation, US 9121 1549 2207 TTNET , TR 30036 1511 1697 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1449 3538 Telmex Colombia S.A., CO 6389 1392 2094 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1349 1604 TRIOLAN , UA 6983 1323 1679 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1575 2:823 4:25 5:2425 6:32 8:1038 11:1 12:1810 13:70 14:1782 15:23 16:2 17:104 18:128 19:1 20:51 23:1980 24:1818 27:2400 31:1861 32:83 33:11 34:1 35:19 36:349 37:2482 38:1299 39:44 40:100 41:2894 42:448 43:1921 44:55 45:2323 46:2564 47:109 49:1210 50:942 51:17 52:660 54:355 55:5 56:4 57:40 58:1604 59:983 60:390 61:1865 62:1495 63:1936 64:4551 65:2183 66:4388 67:2219 68:1163 69:3308 70:1301 71:570 72:2052 74:2588 75:401 76:412 77:1394 78:1562 79:913 80:1367 81:1413 82:971 83:721 84:869 85:1699 86:483 87:1129 88:779 89:2042 90:197 91:6117 92:1007 93:2350 94:2358 95:2785 96:570 97:360 98:939 99:91 100:148 101:1233 103:13310 104:2663 105:145 106:475 107:1515 108:782 109:2544 110:1286 111:1666 112:1148 113:1293 114:1005 115:1640 116:1719 117:1635 118:2050 119:1587 120:947 121:1071 122:2261 123:2026 124:1571 125:1818 128:703 129:507 130:418 131:1404 132:549 133:187 134:522 135:210 136:385 137:416 138:1837 139:486 140:614 141:513 142:729 143:916 144:761 145:167 146:1050 147:654 148:1400 149:563 150:682 151:928 152:709 153:313 154:738 155:959 156:543 157:578 158:436 159:1356 160:567 161:738 162:2464 163:531 164:770 165:1140 166:360 167:1247 168:2481 169:724 170:2622 171:264 172:916 173:1824 174:792 175:711 176:1747 177:4100 178:2432 179:1142 180:2071 181:1971 182:2191 183:1016 184:835 185:8547 186:3239 187:2264 188:2339 189:1782 190:8102 191:1331 192:9305 193:5767 194:4577 195:3852 196:1914 197:1240 198:5602 199:5814 200:7331 201:4130 202:10061 203:9841 204:4460 205:2762 206:2973 207:3154 208:3993 209:3881 210:3897 211:2090 212:2782 213:2462 214:849 215:65 216:5775 217:1970 218:825 219:600 220:1685 221:897 222:714 223:1150 End of report From universe at truemetal.org Fri Jan 20 20:50:53 2017 From: universe at truemetal.org (Markus) Date: Fri, 20 Jan 2017 21:50:53 +0100 Subject: Common Reliable Out Of Band Management Options at Carrier Hotels In-Reply-To: References: Message-ID: <49541264-caa0-594d-c065-fb343373c562@truemetal.org> Am 17.01.2017 um 22:59 schrieb Darin Herteen: > So my inquiry is... What does the list find to be a reasonably priced yet reliable solution in carrier hotels for OOB? Or is that contradictory :) I use a basic 3G/GSM broadband router (Huawai, year 2007, 80 USD or so) with a 10 USD/month SIM (500 megs data plan) and a Linux box where the broadband router is plugged into one of the physical interfaces on that Linux box. Then a 5 USD/month VPS in a far away Eastern European country that most people have never even heard of, where OpenVPN runs in server mode. On the Linux box in my LAN OpenVPN runs in client mode and then some static routes that point to the broadband router for the IP address of the OpenVPN server and it's done. If I want to access my LAN I will SSH into the VPS and from there SSH into the private IP that OpenVPN assigned to the client. Regards Markus From dcharlebois at gmail.com Sat Jan 21 03:25:04 2017 From: dcharlebois at gmail.com (David Charlebois) Date: Fri, 20 Jan 2017 22:25:04 -0500 Subject: Common Reliable Out Of Band Management Options at Carrier Hotels In-Reply-To: <49541264-caa0-594d-c065-fb343373c562@truemetal.org> References: <49541264-caa0-594d-c065-fb343373c562@truemetal.org> Message-ID: We use a Lantronix serial console box (SLC-32) with a small Cisco ASA 5505 + isolated internet. VPN is setup to assign IPs in the OOB network which allows direct access to most management IPs as well as console ports through the Lantronix. I also have a desktop connected with a 2nd NIC (and no gateway on the interface pointing to the OOB) which allows me to bounce to prod network. I love my out of band setup. I don't know your definition of "reasonably priced", but this setup works great! On Fri, Jan 20, 2017 at 3:50 PM, Markus wrote: > Am 17.01.2017 um 22:59 schrieb Darin Herteen: > >> So my inquiry is... What does the list find to be a reasonably priced yet >> reliable solution in carrier hotels for OOB? Or is that contradictory :) >> > > I use a basic 3G/GSM broadband router (Huawai, year 2007, 80 USD or so) > with a 10 USD/month SIM (500 megs data plan) and a Linux box where the > broadband router is plugged into one of the physical interfaces on that > Linux box. Then a 5 USD/month VPS in a far away Eastern European country > that most people have never even heard of, where OpenVPN runs in server > mode. On the Linux box in my LAN OpenVPN runs in client mode and then some > static routes that point to the broadband router for the IP address of the > OpenVPN server and it's done. If I want to access my LAN I will SSH into > the VPS and from there SSH into the private IP that OpenVPN assigned to the > client. > > Regards > Markus > > From benoit.panizzon at imp.ch Fri Jan 20 13:24:31 2017 From: benoit.panizzon at imp.ch (Benoit Panizzon) Date: Fri, 20 Jan 2017 14:24:31 +0100 Subject: S: Contact Qwest DNS Admin / Recovery Point Systems => Re Broken DNSSEC chain / unreachable DNS Addresses: www.bea.gov Message-ID: <20170120142431.3070f8bd@go.imp.ch> Hello There are several DNS issues with www.bea.gov (Bureau of Economic Analysis) which prevent our customers to reach that site (we have DNSSEC and IPv6 enabled resolvers). http://dnsviz.net/d/www.bea.gov/dnssec/ I did send emails to the the SOA contact records the bea.gov www.bea.gov and the DNS Server Domains. I did send emails to the tech contacts found in the ARIN IP Ranges of those DNS servers. I did send email to contacts found on the website itself. I did receive several read confirmations, during the last month. So I know my emails are being read. But nobody replies and the problem is not being fixed. bea.gov name server sauthns1.qwest.net. bea.gov name server sauthns2.qwest.net. sauthns1.qwest.net has address 63.150.72.5 sauthns1.qwest.net has IPv6 address 2001:428::7 sauthns2.qwest.net has address 208.44.130.121 sauthns2.qwest.net has IPv6 address 2001:428::8 Operated by: Qwest Communications Company, LLC www.bea.gov name server ns1.recoverypoint.net. www.bea.gov name server ns3.recoverypoint.net. ns1.recoverypoint.net has address 204.14.132.35 ns1.recoverypoint.net has IPv6 address 2607:f478:0:4005::35 ns3.recoverypoint.net has address 204.14.132.36 ns3.recoverypoint.net has IPv6 address 2607:f478:0:4005::36 CIDR: 204.14.132.0/22 NetName: RECOVERYPOINTSYSTEMS CIDR: 2607:F478::/32 NetName: RECOVERY-POINT-SYSTEMS So as a last resort I try the nanog list now, hoping that somebody reads this who is able to forward this email to the right person, or point me to the person in charge. Any Help appreciated. -Beno?t Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ From kenneth.mcrae at me.com Sat Jan 21 16:44:02 2017 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 21 Jan 2017 08:44:02 -0800 Subject: Passive Optical Network (PON) Message-ID: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> Greeting all, Is anyone out there using PON in a campus or facility environment? I am talking to a few vendors who are pushing PON as a replacement for edge switching on the campus and in some cases, ToR switch in the DC. Opinions on this technology would be greatly appreciated. Thanks, Kenneth From royce at techsolvency.com Sat Jan 21 17:37:46 2017 From: royce at techsolvency.com (Royce Williams) Date: Sat, 21 Jan 2017 08:37:46 -0900 Subject: DNS CAA records... In-Reply-To: References: <280728E2-F42B-4058-9120-9C82A5CBA981@truenet.com> Message-ID: On Tue, Jan 17, 2017 at 4:54 PM, Royce Williams wrote: [snip of CAA-record intro stuff] > An explicit scan for CAA records (against, say, in > all domains seen in DNS ANY) would likely be interesting. Out of curiosity, I used zscan/zdns [1] to scan the OpenDNS top 1 million domains [2] for CAA records. Only 37 popped up: appspot-preview.com appspot.com centos.org comodo.com compricer.se csswg.org dnsimple.com ekom21.de entrust.net fu-berlin.de google.com googleusercontent.com hr.nl hro.nl instantssl.com intra.net magticom.ge mail.de minuporno.com mobileread.com monash.edu ntplx.net pdgamedev.com posteo.de pstatic.net rio2016.com samba.org shat.net sumologic.com svwh.net symantec.com tensquaregames.com thefacebook.com tsheets.com unfcu.org uni-sofia.bg weddingwire.com 1. https://github.com/zmap/zdns 2. https://blog.opendns.com/2016/12/14/cisco-umbrella-1-million/ Royce From joelja at bogus.com Sat Jan 21 21:31:18 2017 From: joelja at bogus.com (joel jaeggli) Date: Sat, 21 Jan 2017 13:31:18 -0800 Subject: Passive Optical Network (PON) In-Reply-To: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> References: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> Message-ID: On 1/21/17 8:44 AM, Kenneth McRae wrote: > Greeting all, > > Is anyone out there using PON in a campus or facility environment? I am talking to a few vendors who are pushing PON as a replacement for edge switching on the campus and in some cases, ToR switch in the DC. Opinions on this technology would be greatly appreciated. The datacenter tor / host evironments I'm exposed to generally consider 10Gb/s or Nx10 to be the performance floor not the ceiling. To my thinking 100gig lr4 results in a substantial reduction in fiber/optic/port count which will in the long more than offset the increased cost something that didn't really happen with 40gig. > Thanks, > > Kenneth > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From nanog at ics-il.net Sat Jan 21 21:35:00 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 21 Jan 2017 15:35:00 -0600 (CST) Subject: Passive Optical Network (PON) In-Reply-To: References: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> Message-ID: <2026787981.15798.1485034499336.JavaMail.mhammett@ThunderFuck> Conversely, many places still can't even handle a full table. ;-) ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "joel jaeggli" To: "Kenneth McRae" , "NANOG" Sent: Saturday, January 21, 2017 3:31:18 PM Subject: Re: Passive Optical Network (PON) On 1/21/17 8:44 AM, Kenneth McRae wrote: > Greeting all, > > Is anyone out there using PON in a campus or facility environment? I am talking to a few vendors who are pushing PON as a replacement for edge switching on the campus and in some cases, ToR switch in the DC. Opinions on this technology would be greatly appreciated. The datacenter tor / host evironments I'm exposed to generally consider 10Gb/s or Nx10 to be the performance floor not the ceiling. To my thinking 100gig lr4 results in a substantial reduction in fiber/optic/port count which will in the long more than offset the increased cost something that didn't really happen with 40gig. > Thanks, > > Kenneth > From carlos at race.com Sun Jan 22 19:38:57 2017 From: carlos at race.com (Carlos Alcantar) Date: Sun, 22 Jan 2017 19:38:57 +0000 Subject: Passive Optical Network (PON) In-Reply-To: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> References: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> Message-ID: I think it's really depends on your use case. If you know your TOR switches are doing 1-2 gigs at all times PON would be quite expensive to keep up with this type of usage. If your talking distribution/access out to cameras ect it would work. We run gpon across our entire access network 99% of the time it's fine once in awhile you'll get that one user that is killing the pon port and will move them to an active ethernet port. Now when NG-PON2 starts to hit the market, now you're talking about something that could be used in the data center with it's capabilities to do 4X 10G PON bonding. Note this is not going to be cheap but doable. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com ________________________________ From: NANOG on behalf of Kenneth McRae Sent: Saturday, January 21, 2017 8:44:02 AM To: NANOG Subject: Passive Optical Network (PON) Greeting all, Is anyone out there using PON in a campus or facility environment? I am talking to a few vendors who are pushing PON as a replacement for edge switching on the campus and in some cases, ToR switch in the DC. Opinions on this technology would be greatly appreciated. Thanks, Kenneth From me at payam124.com Sat Jan 21 10:27:30 2017 From: me at payam124.com (Payam Poursaied) Date: Sat, 21 Jan 2017 02:27:30 -0800 Subject: Instagram --> SSL Message-ID: <1dff01d273d0$f95ba3d0$ec12eb70$@payam124.com> Hi folks Is there any publication/report/new/plan on migration of Instagram to server the content over SSL? Facebook serves media on SSL (to my knowledge). So I wonder to know Instagram would go in that way as well. From stas.bilder at gmail.com Sat Jan 21 21:22:20 2017 From: stas.bilder at gmail.com (Stas Bilder) Date: Sat, 21 Jan 2017 15:22:20 -0600 Subject: Passive Optical Network (PON) In-Reply-To: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> References: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> Message-ID: I evaluated several campus PON project on both vendor/provider and customer sides over the last 5 years. PON was designed as a last-mile technology for _operators_ to cover huge areas and save on OPEX - that's the usual vendor's mantra. GigE usually takes two fibers to deliver; GigE aggregation requires an Ethernet switch you need to power and maintain - "many points of failure" argument. PON only takes one fiber, splitting a PON signal is done by a cheap passive optical splitter which, once installed, lasts forever. Correct cost comparison between PON and Ethernet is pretty difficult. First, the cost of the actual network _equipment_ (switches, routers etc.) for an Access network (tens of thousands of subscribers) is nothing compared to the civil works - trenching, cabling, permits etc. Second, CPE cost is the most sensitive on that scale. $5 cheaper CPE saves more money than a $50k cheaper OLT. Without scale benefits and (assumed) OpEx reduction, PON projects are usually significantly more expensive. Now, to the projects. I have never heard of seen PON on a DC level. As for the campus, none of the projects took off, and here is why: - PON equipment is proprietary. An OLT (PON hub) from vendor X works only with ONTs from the same vendor. Every other vendor claims there is "some interop" but none was able to do demonstrate. - PON infrastructure - a passive fiber tree - is a) proprietary b) not flexible. You can make any physical topology of your usual p2p fiber segments but a tree is always a tree; plus PON usually requires green APC (angle polished) connectors. - PON US/DS bandwidth allocation is asymmetric. Training, maintenance and support are important, too. Ethernet is ubiquitous, PON engineers are a bit harder to find. Proprietary nature of the product implies that a Huawei PON would look and feel somewhat different than, say, Calix PON hence the knowledge is more vendor-specific. Also, nobody likes vendor lock. If an Access Ethernet switch fails, you can - potentially - replace it with another fairly easily. PON ONT of different vendors may all come from the same OEM like Cambridge but the firmware is different. What did I miss?... Ah, the usual cabling There is a more sophisticated WDM-PON. Ericsson and Teradata had it in development, Infinera offers it as iAccess product - but I haven't tried that yet. Overall, it really depends on a project (getting all the MTBF data and calculating the failure cost was quite a task) but I personally can't see any PON benefits over Ethernet for either campus or DC even in the midterm. >From my personal experience, flexibility with cables plus cheap CWDM filters and colored optics can do magic on the campus level. Stas On Sat, Jan 21, 2017 at 10:44 AM, Kenneth McRae wrote: > Greeting all, > > Is anyone out there using PON in a campus or facility environment? I am > talking to a few vendors who are pushing PON as a replacement for edge > switching on the campus and in some cases, ToR switch in the DC. Opinions > on this technology would be greatly appreciated. > > Thanks, > > Kenneth From maxtul at netassist.ua Mon Jan 23 17:03:44 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 23 Jan 2017 19:03:44 +0200 Subject: Passive Optical Network (PON) In-Reply-To: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> References: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> Message-ID: <58863770.7020302@netassist.ua> Hi, using in rural area, it works. Much cheaper than ETTH. On 21.01.17 18:44, Kenneth McRae wrote: > Greeting all, > > Is anyone out there using PON in a campus or facility environment? I am talking to a few vendors who are pushing PON as a replacement for edge switching on the campus and in some cases, ToR switch in the DC. Opinions on this technology would be greatly appreciated. > > Thanks, > > Kenneth > From bicknell at ufp.org Mon Jan 23 17:15:14 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 23 Jan 2017 09:15:14 -0800 Subject: Passive Optical Network (PON) In-Reply-To: References: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> Message-ID: <20170123171514.GB30659@ussenterprise.ufp.org> In a message written on Sat, Jan 21, 2017 at 03:22:20PM -0600, Stas Bilder wrote: > Now, to the projects. > I have never heard of seen PON on a DC level. A friend of mine told me of a fascinating in-data center PON solution. He had a customer that needed high speed multicast fan-out. They chose to use a 10G/1G PON solution, a single source node sending 10G PON with a 1G backchannel, 100% of the traffic was multicast. It could be passively split in DC up to 128:1 with zero "packet loss", good luck finding an Ethernet switch which can take in 10G of multicast in and turn it into 1280G of multicast out without dropping a frame. It was all done entirely inside of a single data center. Since then I've mentioned the trick to several other folks I know who need high speed multicast/broadcast replication. In the DC distance is rarely an issue, so the solution degenerates to special SFP's and a splitter, which is pretty dang simple. However, this is clearly a corner case, and I agree with your assessment overall. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From josh at kyneticwifi.com Mon Jan 23 17:25:19 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 23 Jan 2017 11:25:19 -0600 Subject: Passive Optical Network (PON) In-Reply-To: <20170123171514.GB30659@ussenterprise.ufp.org> References: <05285F2B-0BFD-4955-ABB6-3BD0DF39A561@me.com> <20170123171514.GB30659@ussenterprise.ufp.org> Message-ID: That's a genious idead On Jan 23, 2017 11:17 AM, "Leo Bicknell" wrote: > In a message written on Sat, Jan 21, 2017 at 03:22:20PM -0600, Stas Bilder > wrote: > > Now, to the projects. > > I have never heard of seen PON on a DC level. > > A friend of mine told me of a fascinating in-data center PON solution. > > He had a customer that needed high speed multicast fan-out. They > chose to use a 10G/1G PON solution, a single source node sending > 10G PON with a 1G backchannel, 100% of the traffic was multicast. > It could be passively split in DC up to 128:1 with zero "packet > loss", good luck finding an Ethernet switch which can take in 10G > of multicast in and turn it into 1280G of multicast out without > dropping a frame. It was all done entirely inside of a single > data center. > > Since then I've mentioned the trick to several other folks I know > who need high speed multicast/broadcast replication. In the DC > distance is rarely an issue, so the solution degenerates to special > SFP's and a splitter, which is pretty dang simple. > > However, this is clearly a corner case, and I agree with your > assessment overall. > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ > From benno at NLnetLabs.nl Mon Jan 23 17:30:57 2017 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Mon, 23 Jan 2017 18:30:57 +0100 Subject: Call for presentations RIPE 74 Message-ID: <7d681f76-b63b-e8f2-e3fe-e1dabd9bd570@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 74 below or at https://ripe74.ripe.net/submit-topic/cfp/. The deadline for submissions is *12 March 2017*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://ripe74.ripe.net/programme/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 74 will take place from 8-12 May 2017 in Budapest, Hungary. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 74. See the full descriptions of the different presentation formats, https://ripe74.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 12 March 2017. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe74.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. Allocation of lightning talks will start a few days before the meeting, and will continue throughout the meeting. During the meeting, they may be announced on the day before the talk or even on the same day as the talk. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From patrick at ianai.net Mon Jan 23 21:58:37 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 23 Jan 2017 16:58:37 -0500 Subject: How ISPs bill : Time Zones & 95th Percentile Calculations In-Reply-To: <9CD6577A-D7B9-4CAC-A9F3-6AE4E2656838@ianai.net> References: <9CD6577A-D7B9-4CAC-A9F3-6AE4E2656838@ianai.net> Message-ID: <33F89698-6C0F-4D84-86FA-50D5FDA5CE3F@ianai.net> NANOG?ers: Steve McManus of Akamai and I have a few questions regarding how providers use time zones for billing, and how the 95th percentile (95/5) is calculated. Many ISPs use UTC on logs and such for reasons which should be obvious. But do they use local time for billing? What if there are ports in multiple time zones? When calculating 95/5 for LACP groups, is the aggregate used or individual physical ports? Etc. We have created a short form to collect some real-world data on this. https://goo.gl/d1HRNb We fully understand this is far from a statistically randomized double-blind survey, but it is what we could do in the few minutes of spare time we had. The form is only 7 multiple-choice questions, with two optional ?comment? sections and an optional contact info section. We would really appreciate if people would share data (anonymously!) on how they bill or get billed. The form is designed to be used once per relationship. If you have two upstreams who use two different billing methods, we would greatly appreciate if you could fill in the form twice. It seemed easier to have you click 7 radio buttons twice than ask you to explain the different methods on one form. Thank you for your time. Results will be aggregated and published at some later date to be determined. If you would like the results faster, be sure to leave your email address in the contact section. -- TTFN, patrick -- TTFN, patrick From r.engehausen at gmail.com Tue Jan 24 00:09:05 2017 From: r.engehausen at gmail.com (Roy) Date: Mon, 23 Jan 2017 17:09:05 -0700 Subject: Trump names new FCC chairman Message-ID: Trump has picked Ajit Pai to serve as the next chairman of the Federal Communications Commission. Pai is currently the senior Republican commissioner at the FCC and does not require Senate approval. http://money.cnn.com/2017/01/23/technology/trump-fcc-chairman/index.html From joshuawark at hotmail.com Tue Jan 24 10:13:23 2017 From: joshuawark at hotmail.com (Joshua) Date: Tue, 24 Jan 2017 10:13:23 +0000 Subject: Major outage in Texas at&t Message-ID: Looks like almost the entire state is down. I don't have any other details From marty at cloudflare.com Tue Jan 24 10:37:09 2017 From: marty at cloudflare.com (Marty Strong) Date: Tue, 24 Jan 2017 10:37:09 +0000 Subject: Major outage in Texas at&t In-Reply-To: References: Message-ID: <4C2A12F2-18AB-420C-A1CB-28267675654F@cloudflare.com> Of The 6 RIPE Atlas probes on AT&T in Texas, only 1 went down, about 2 hours ago. http://i.imgur.com/YeM7inZ.png Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 24 Jan 2017, at 10:13, Joshua wrote: > > Looks like almost the entire state is down. I don't have any other details > From joshuawark at hotmail.com Tue Jan 24 10:49:36 2017 From: joshuawark at hotmail.com (Joshua) Date: Tue, 24 Jan 2017 10:49:36 +0000 Subject: Major outage in Texas at&t In-Reply-To: <4C2A12F2-18AB-420C-A1CB-28267675654F@cloudflare.com> References: , <4C2A12F2-18AB-420C-A1CB-28267675654F@cloudflare.com> Message-ID: Thanks for the info. I just know 100% of our users on att have no connection across the entire state. Sent from my iPhone > On Jan 24, 2017, at 4:37 AM, Marty Strong wrote: > > Of The 6 RIPE Atlas probes on AT&T in Texas, only 1 went down, about 2 hours ago. > > http://i.imgur.com/YeM7inZ.png > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > >> On 24 Jan 2017, at 10:13, Joshua wrote: >> >> Looks like almost the entire state is down. I don't have any other details >> > From joshuawark at hotmail.com Tue Jan 24 11:04:04 2017 From: joshuawark at hotmail.com (Joshua) Date: Tue, 24 Jan 2017 11:04:04 +0000 Subject: Major outage in Texas at&t In-Reply-To: References: , <4C2A12F2-18AB-420C-A1CB-28267675654F@cloudflare.com>, Message-ID: I spoke with at&t just now all they said was all major cities and surrounding areas in Texas were down. Sent from my iPhone > On Jan 24, 2017, at 4:50 AM, Joshua wrote: > > Thanks for the info. I just know 100% of our users on att have no connection across the entire state. > > Sent from my iPhone > >> On Jan 24, 2017, at 4:37 AM, Marty Strong wrote: >> >> Of The 6 RIPE Atlas probes on AT&T in Texas, only 1 went down, about 2 hours ago. >> >> http://i.imgur.com/YeM7inZ.png >> >> Regards, >> Marty Strong >> -------------------------------------- >> Cloudflare - AS13335 >> Network Engineer >> marty at cloudflare.com >> +44 7584 906 055 >> smartflare (Skype) >> >> https://www.peeringdb.com/asn/13335 >> >>> On 24 Jan 2017, at 10:13, Joshua wrote: >>> >>> Looks like almost the entire state is down. I don't have any other details >>> >> From maxsec at gmail.com Tue Jan 24 12:00:54 2017 From: maxsec at gmail.com (Martin Hepworth) Date: Tue, 24 Jan 2017 12:00:54 +0000 Subject: Major outage in Texas at&t In-Reply-To: References: <4C2A12F2-18AB-420C-A1CB-28267675654F@cloudflare.com> Message-ID: Looks like not just Texas.. https://twitter.com/ZMarotrix/status/823853561582850048 -- Martin Hepworth, CISSP Oxford, UK On 24 January 2017 at 11:04, Joshua wrote: > I spoke with at&t just now all they said was all major cities and > surrounding areas in Texas were down. > > Sent from my iPhone > > > On Jan 24, 2017, at 4:50 AM, Joshua wrote: > > > > Thanks for the info. I just know 100% of our users on att have no > connection across the entire state. > > > > Sent from my iPhone > > > >> On Jan 24, 2017, at 4:37 AM, Marty Strong wrote: > >> > >> Of The 6 RIPE Atlas probes on AT&T in Texas, only 1 went down, about 2 > hours ago. > >> > >> http://i.imgur.com/YeM7inZ.png > >> > >> Regards, > >> Marty Strong > >> -------------------------------------- > >> Cloudflare - AS13335 > >> Network Engineer > >> marty at cloudflare.com > >> +44 7584 906 055 > >> smartflare (Skype) > >> > >> https://www.peeringdb.com/asn/13335 > >> > >>> On 24 Jan 2017, at 10:13, Joshua wrote: > >>> > >>> Looks like almost the entire state is down. I don't have any other > details > >>> > >> > From dovid at telecurve.com Tue Jan 24 12:10:10 2017 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 24 Jan 2017 07:10:10 -0500 Subject: Major outage in Texas at&t In-Reply-To: References: <4C2A12F2-18AB-420C-A1CB-28267675654F@cloudflare.com> Message-ID: Is it backup for anyone? AS33322 went down about an hour+ ago. I wonder if it's related (they are out in CA). On Tue, Jan 24, 2017 at 6:04 AM, Joshua wrote: > I spoke with at&t just now all they said was all major cities and > surrounding areas in Texas were down. > > Sent from my iPhone > > > On Jan 24, 2017, at 4:50 AM, Joshua wrote: > > > > Thanks for the info. I just know 100% of our users on att have no > connection across the entire state. > > > > Sent from my iPhone > > > >> On Jan 24, 2017, at 4:37 AM, Marty Strong wrote: > >> > >> Of The 6 RIPE Atlas probes on AT&T in Texas, only 1 went down, about 2 > hours ago. > >> > >> http://i.imgur.com/YeM7inZ.png > >> > >> Regards, > >> Marty Strong > >> -------------------------------------- > >> Cloudflare - AS13335 > >> Network Engineer > >> marty at cloudflare.com > >> +44 7584 906 055 > >> smartflare (Skype) > >> > >> https://www.peeringdb.com/asn/13335 > >> > >>> On 24 Jan 2017, at 10:13, Joshua wrote: > >>> > >>> Looks like almost the entire state is down. I don't have any other > details > >>> > >> > From rsk at gsp.org Tue Jan 24 18:14:45 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 24 Jan 2017 13:14:45 -0500 Subject: Fwd: [info@arin.net: [arin-announce] ARIN DoS Attack] Message-ID: <20170124181445.GC19200@gsp.org> [FYI. ---rsk ] ----- Forwarded message from ARIN ----- > Date: Tue, 24 Jan 2017 12:59:04 -0500 > From: ARIN > To: arin-announce at arin.net > Subject: [arin-announce] ARIN DoS Attack > > Starting at 10:53 AM ET on Tuesday, 24 January, a DoS attack began > against ARIN. This was and continues to be a sustained attack against > our provisioning services, email, and website. We initiated our DoS > mitigation plan and are in the process of mitigating various types of > attack traffic patterns. All our other public-facing services (Whois, > Whois-RWS, RDAP, DNS, IRR, and RPKI repository services) are not > affected by this attack and are operating normally. We will announce an > all clear 24 hours after the attacks have stopped. > > Regards, > > Mark Kosters > Chief Technology Officer > American Registry for Internet Numbers (ARIN) > ----- End forwarded message ----- From rod.beck at unitedcablecompany.com Wed Jan 25 18:06:04 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 25 Jan 2017 18:06:04 +0000 Subject: Trump names new FCC chairman In-Reply-To: References: Message-ID: We live in scary times. - R. ________________________________ From: NANOG on behalf of Roy Sent: Tuesday, January 24, 2017 1:09 AM To: nanog Subject: Trump names new FCC chairman Trump has picked Ajit Pai to serve as the next chairman of the Federal Communications Commission. Pai is currently the senior Republican commissioner at the FCC and does not require Senate approval. http://money.cnn.com/2017/01/23/technology/trump-fcc-chairman/index.html [http://i2.cdn.turner.com/money/dam/assets/170123103242-ajit-pai-780x439.jpg] Ajit Pai named as new FCC chairman money.cnn.com President Donald Trump names Ajit Pai to head the FCC. From randy at psg.com Wed Jan 25 19:15:10 2017 From: randy at psg.com (Randy Bush) Date: Wed, 25 Jan 2017 11:15:10 -0800 Subject: radb mirroring Message-ID: [ where does one discuss IRR issues these days? ] ryuu.psg.com:/Users/randy> whois -h whois.radb.net 98.128.244.0/24 route: 98.128.244.0/24 descr: RGNET-98-244 origin: AS3130 notify: rw at rg.net mnt-by: MAINT-RGNET changed: randy at psg.com 20090411 source: RGNET but ryuu.psg.com:/Users/randy> whois -h whois.rg.net 98.128.244.0/24 % No entries found for the selected source(s). broken mirroring in some way? how to diagnose? randy From job at instituut.net Wed Jan 25 20:27:40 2017 From: job at instituut.net (Job Snijders) Date: Wed, 25 Jan 2017 21:27:40 +0100 Subject: radb mirroring In-Reply-To: References: Message-ID: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> This is a clear case of broken mirroring. Unfortunately this is not immediately apparent (for the operator) through the IRRd software. Usually this is resolved by directly contacting the other side. I've found RADB support staff to be responsive and courteous. radb-support at merit.edu (mailto:radb-support at merit.edu). This address is also useful for IRR hijacking issues or false entries. Kind regards, Job On 25 Jan 2017, 20:16 +0100, Randy Bush , wrote: > [ where does one discuss IRR issues these days? ] > > ryuu.psg.com:/Users/randy> whois -h whois.radb.net 98.128.244.0/24 > route: 98.128.244.0/24 > descr: RGNET-98-244 > origin: AS3130 > notify: rw at rg.net > mnt-by: MAINT-RGNET > changed: randy at psg.com 20090411 > source: RGNET > > but > > ryuu.psg.com:/Users/randy> whois -h whois.rg.net 98.128.244.0/24 > % No entries found for the selected source(s). > > broken mirroring in some way? > > how to diagnose? > > randy From cra at WPI.EDU Wed Jan 25 20:39:29 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 25 Jan 2017 15:39:29 -0500 Subject: radb mirroring In-Reply-To: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> References: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> Message-ID: <20170125203929.GS6587@angus.ind.wpi.edu> On a similar note, Level3's database has many stale entries from WCGDB which no longer exists as far as I can tell. Does anyone have a good contact at Level3 for removing all the entries with a source: WCGDB? There are some of mine that I'd like to have removed. Here is an example of Charter's AS object: [Querying rr.level3.net] [rr.level3.net] % RIPEdb(3.0.0a13) with ISI RPSL extensions aut-num: AS20115 as-name: Charter descr: AS record for Charter admin-c: IPCC-WCG tech-c: IPCC-WCG import: from AS7911 accept ANY export: to AS7911 announce AS20115 notify: noc at wcg.net mnt-by: MAINT-AS20115 changed: brent at wcg.com 20031216 source: WCGDB vs. [Querying whois.radb.net] [whois.radb.net] aut-num: AS20115 as-name: MAINT-CHTR-WD descr: Charter Communications (AS20115) import: from AS209 accept ANY import: from AS7018 accept ANY [...] notify: dlnociptier3 at charter.com mnt-by: MAINT-CHTR-WD changed: denny.derda at chartercom.com 20141028 #19:19:01Z ssource: RADB On Wed, Jan 25, 2017 at 09:27:40PM +0100, Job Snijders wrote: > This is a clear case of broken mirroring. Unfortunately this is not immediately apparent (for the operator) through the IRRd software. Usually this is resolved by directly contacting the other side. > > I've found RADB support staff to be responsive and courteous. radb-support at merit.edu (mailto:radb-support at merit.edu). This address is also useful for IRR hijacking issues or false entries. > > Kind regards, > > Job > > On 25 Jan 2017, 20:16 +0100, Randy Bush , wrote: > > [ where does one discuss IRR issues these days? ] > > > > ryuu.psg.com:/Users/randy> whois -h whois.radb.net 98.128.244.0/24 > > route: 98.128.244.0/24 > > descr: RGNET-98-244 > > origin: AS3130 > > notify: rw at rg.net > > mnt-by: MAINT-RGNET > > changed: randy at psg.com 20090411 > > source: RGNET > > > > but > > > > ryuu.psg.com:/Users/randy> whois -h whois.rg.net 98.128.244.0/24 > > % No entries found for the selected source(s). > > > > broken mirroring in some way? > > > > how to diagnose? > > > > randy From randy at psg.com Wed Jan 25 21:12:51 2017 From: randy at psg.com (Randy Bush) Date: Wed, 25 Jan 2017 13:12:51 -0800 Subject: radb mirroring In-Reply-To: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> References: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> Message-ID: > This is a clear case of broken mirroring. Unfortunately this is not > immediately apparent (for the operator) through the IRRd > software. Usually this is resolved by directly contacting the other > side. this is the IRR, there are potentially many other sides. the helpful folk at merit and i are in contact. randy From randy at psg.com Wed Jan 25 21:29:32 2017 From: randy at psg.com (Randy Bush) Date: Wed, 25 Jan 2017 13:29:32 -0800 Subject: radb mirroring In-Reply-To: <20170125203929.GS6587@angus.ind.wpi.edu> References: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> <20170125203929.GS6587@angus.ind.wpi.edu> Message-ID: do we have a central, updatable, registry of IRR instances and their mirrorable URLs? randy From jared at puck.nether.net Wed Jan 25 22:58:13 2017 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 25 Jan 2017 17:58:13 -0500 Subject: AT&T Mobility DNS blocking Message-ID: <87B9D8CD-C49A-444F-BFB0-95E72EB15687@puck.nether.net> Greetings, It seems AT&T Mobility is blocking EDNS1 queries such as the following on their mobile network, as seen in the details below. Does anyone have a colleague there that would be willing to investigate? - jared EDNS1 OPT RR ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15902 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; ., type = SOA, class = IN ; EDNS: version: 1, udp=4096, flags=0000 Sending: 000000 3e 1e 01 00 00 01 00 00 00 00 00 01 00 00 06 00 >............... 000010 01 00 00 29 10 00 00 01 00 00 00 00 ...)........ From kotikalapudi.sriram at nist.gov Wed Jan 25 23:19:07 2017 From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi (Fed)) Date: Wed, 25 Jan 2017 23:19:07 +0000 Subject: BGP route processing speed Message-ID: I am interested in measurements related to BGP route processing speed (i.e. routing engine capacity in terms of routes or updates processed per second). Folks from AMS-IX did an interesting study in 2012 in their Route Server / IXP environment. https://ams-ix.net/downloads/ams-ix-route-server-implementations-performance.pdf Are there other measurement studies available on this topic, especially in ISP/PE router scenarios, including BGP policy processing, best path selection, route filtering, etc.? Will appreciate much if you can share some pointers. Sriram From nick at foobar.org Wed Jan 25 23:55:35 2017 From: nick at foobar.org (Nick Hilliard) Date: Wed, 25 Jan 2017 23:55:35 +0000 Subject: radb mirroring In-Reply-To: References: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> <20170125203929.GS6587@angus.ind.wpi.edu> Message-ID: <58893AF7.2030306@foobar.org> Randy Bush wrote: > do we have a central, updatable, registry of IRR instances and their > mirrorable URLs? there's a list here, which ticks at least one of your multiple requirements: http://www.irr.net/docs/list.html Nick From mdkuch at merit.edu Wed Jan 25 21:38:56 2017 From: mdkuch at merit.edu (Mitchell Kuch) Date: Wed, 25 Jan 2017 16:38:56 -0500 (EST) Subject: radb mirroring In-Reply-To: References: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> <20170125203929.GS6587@angus.ind.wpi.edu> Message-ID: <262832219.2702189.1485380336203.JavaMail.zimbra@merit.edu> Randy - Merit maintains an updated list on the web. http://irr.net/docs/list.html - - Mitchell Mitchell Kuch mdkuch at merit.edu RADb Analyst Merit Network Inc. ----- Original Message ----- From: "Randy Bush" To: "Chuck Anderson" Cc: "North American Network Operators' Group" Sent: Wednesday, January 25, 2017 4:29:32 PM Subject: Re: radb mirroring do we have a central, updatable, registry of IRR instances and their mirrorable URLs? randy From randy at psg.com Thu Jan 26 14:40:28 2017 From: randy at psg.com (Randy Bush) Date: Thu, 26 Jan 2017 06:40:28 -0800 Subject: radb mirroring In-Reply-To: <262832219.2702189.1485380336203.JavaMail.zimbra@merit.edu> References: <3ce0b04c-32af-48d1-baf5-3087683d2ea5@Spark> <20170125203929.GS6587@angus.ind.wpi.edu> <262832219.2702189.1485380336203.JavaMail.zimbra@merit.edu> Message-ID: > Merit maintains an updated list on the web. > http://irr.net/docs/list.html and thank you for helping me update RGNET's entry randy From lists at mtin.net Thu Jan 26 16:04:41 2017 From: lists at mtin.net (Justin Wilson) Date: Thu, 26 Jan 2017 11:04:41 -0500 Subject: Electronic arts peering contact? Message-ID: <18C91A84-2EC4-42E7-95AA-4C5E5BBCD30C@mtin.net> Does anyone have a peering contact for Electronic Arts? Their peeringdb entry has no info. Thanks in advance. Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric From cscora at apnic.net Fri Jan 27 18:01:47 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Jan 2017 04:01:47 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170127180147.C312AC44A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Jan, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 630069 Prefixes after maximum aggregation (per Origin AS): 222004 Deaggregation factor: 2.84 Unique aggregates announced (without unneeded subnets): 305485 Total ASes present in the Internet Routing Table: 55692 Prefixes per ASN: 11.31 Origin-only ASes present in the Internet Routing Table: 36239 Origin ASes announcing only one prefix: 15215 Transit ASes present in the Internet Routing Table: 6561 Transit-only ASes present in the Internet Routing Table: 175 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 56 Unregistered ASNs in the Routing Table: 16 Number of 32-bit ASNs allocated by the RIRs: 17080 Number of 32-bit ASNs visible in the Routing Table: 12892 Prefixes from 32-bit ASNs in the Routing Table: 53317 Number of bogon 32-bit ASNs visible in the Routing Table: 862 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 381 Number of addresses announced to Internet: 2831917284 Equivalent to 168 /8s, 203 /16s and 160 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 208709 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156846 Total APNIC prefixes after maximum aggregation: 43166 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 171765 Unique aggregates announced from the APNIC address blocks: 71082 APNIC Region origin ASes present in the Internet Routing Table: 5186 APNIC Prefixes per ASN: 33.12 APNIC Region origin ASes announcing only one prefix: 1140 APNIC Region transit ASes present in the Internet Routing Table: 943 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2639 Number of APNIC addresses announced to Internet: 760184964 Equivalent to 45 /8s, 79 /16s and 128 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188672 Total ARIN prefixes after maximum aggregation: 89475 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195695 Unique aggregates announced from the ARIN address blocks: 89834 ARIN Region origin ASes present in the Internet Routing Table: 16064 ARIN Prefixes per ASN: 12.18 ARIN Region origin ASes announcing only one prefix: 5595 ARIN Region transit ASes present in the Internet Routing Table: 1724 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1732 Number of ARIN addresses announced to Internet: 1104311968 Equivalent to 65 /8s, 210 /16s and 118 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 151900 Total RIPE prefixes after maximum aggregation: 73441 RIPE Deaggregation factor: 2.07 Prefixes being announced from the RIPE address blocks: 163465 Unique aggregates announced from the RIPE address blocks: 99378 RIPE Region origin ASes present in the Internet Routing Table: 18152 RIPE Prefixes per ASN: 9.01 RIPE Region origin ASes announcing only one prefix: 7763 RIPE Region transit ASes present in the Internet Routing Table: 3048 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5111 Number of RIPE addresses announced to Internet: 709660288 Equivalent to 42 /8s, 76 /16s and 142 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 63915 Total LACNIC prefixes after maximum aggregation: 12605 LACNIC Deaggregation factor: 5.07 Prefixes being announced from the LACNIC address blocks: 80937 Unique aggregates announced from the LACNIC address blocks: 38074 LACNIC Region origin ASes present in the Internet Routing Table: 2482 LACNIC Prefixes per ASN: 32.61 LACNIC Region origin ASes announcing only one prefix: 546 LACNIC Region transit ASes present in the Internet Routing Table: 596 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3124 Number of LACNIC addresses announced to Internet: 171001408 Equivalent to 10 /8s, 49 /16s and 70 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15362 Total AfriNIC prefixes after maximum aggregation: 3310 AfriNIC Deaggregation factor: 4.64 Prefixes being announced from the AfriNIC address blocks: 17826 Unique aggregates announced from the AfriNIC address blocks: 6788 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 24.22 AfriNIC Region origin ASes announcing only one prefix: 171 AfriNIC Region transit ASes present in the Internet Routing Table: 183 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 286 Number of AfriNIC addresses announced to Internet: 86317568 Equivalent to 5 /8s, 37 /16s and 26 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5546 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3726 390 254 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2976 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2729 11133 744 KIXS-AS-KR Korea Telecom, KR 9829 2708 1501 542 BSNL-NIB National Internet Backbone, IN 9808 2282 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2054 429 217 TATACOMM-AS TATA Communications formerl 45899 1916 1284 99 VNPT-AS-VN VNPT Corp, VN 4808 1641 1788 450 CHINA169-BJ China Unicom Beijing Provin 24560 1564 566 246 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3628 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3299 1333 83 SHAW - Shaw Communications Inc., CA 18566 2192 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2094 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1963 2031 403 CHARTER-NET-HKY-NC - Charter Communicat 209 1713 5067 637 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1700 319 455 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1680 848 227 ITCDELTA - Earthlink, Inc., US 16509 1630 3047 532 AMAZON-02 - Amazon.com, Inc., US 701 1596 10613 658 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 2989 1123 2130 AKAMAI-ASN1 , US 9121 2202 1707 94 TTNET , TR 34984 1990 327 377 TELLCOM-AS , TR 13188 1598 99 62 TRIOLAN , UA 12479 1448 1033 51 UNI2-AS , ES 8551 1438 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 6849 1313 355 22 UKRTELNET , UA 8402 1100 544 15 CORBINA-AS OJSC "Vimpelcom", RU 9198 1010 352 24 KAZTELECOM-AS , KZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3534 545 171 Telmex Colombia S.A., CO 8151 2486 3380 556 Uninet S.A. de C.V., MX 11830 1800 368 66 Instituto Costarricense de Electricidad 6503 1547 437 54 Axtel, S.A.B. de C.V., MX 7303 1526 974 254 Telecom Argentina S.A., AR 6147 1296 377 27 Telefonica del Peru S.A.A., PE 28573 1063 2271 178 CLARO S.A., BR 3816 1005 479 179 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 992 279 32 Techtel LMDS Comunicaciones Interactiva 17072 970 127 357 TOTAL PLAY TELECOMUNICACIONES SA DE CV, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1294 398 42 LINKdotNET-AS, EG 36903 719 361 123 MT-MPLS, MA 37611 686 67 6 Afrihost, ZA 36992 587 1373 25 ETISALAT-MISR, EG 24835 491 658 16 RAYA-AS, EG 8452 480 1474 16 TE-AS TE-AS, EG 37492 395 324 75 ORANGE-TN, TN 29571 367 36 10 CITelecom-AS, CI 15399 321 35 6 WANANCHI-KE, KE 2018 288 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5546 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3726 390 254 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3628 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3534 545 171 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3299 1333 83 SHAW - Shaw Communications Inc., CA 20940 2989 1123 2130 AKAMAI-ASN1 , US 17974 2976 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2729 11133 744 KIXS-AS-KR Korea Telecom, KR 9829 2708 1501 542 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3628 3477 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3726 3472 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3534 3363 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3299 3216 SHAW - Shaw Communications Inc., CA 17974 2976 2905 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2282 2249 CMNET-GD Guangdong Mobile Communication 9829 2708 2166 BSNL-NIB National Internet Backbone, IN 9121 2202 2108 TTNET , TR 18566 2192 2083 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65512 PRIVATE 45.252.244.0/24 45899 VNPT-AS-VN VNPT Corp, VN 65512 PRIVATE 45.252.245.0/24 45899 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:532 /14:1049 /15:1792 /16:13183 /17:7770 /18:12968 /19:25169 /20:38034 /21:40726 /22:73669 /23:61693 /24:351696 /25:548 /26:405 /27:288 /28:34 /29:22 /30:18 /31:1 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3095 3299 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2824 3628 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2085 2192 MEGAPATH5-US - MegaPath Corporation, US 9121 1544 2202 TTNET , TR 30036 1512 1700 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1450 3534 Telmex Colombia S.A., CO 6389 1392 2094 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1348 1598 TRIOLAN , UA 6983 1323 1680 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1599 2:823 4:25 5:2423 6:32 8:1046 12:1810 13:70 14:1781 15:23 16:2 17:103 18:128 19:1 20:52 23:1976 24:1842 27:2380 31:1875 32:83 33:2 34:1 35:19 36:354 37:2512 38:1305 39:43 40:100 41:2904 42:450 43:1924 44:59 45:2342 46:2576 47:109 49:1211 50:943 51:18 52:701 54:356 55:3 56:4 57:40 58:1595 59:983 60:390 61:1878 62:1503 63:1931 64:4545 65:2207 66:4412 67:2209 68:1167 69:3310 70:1301 71:570 72:2048 74:2579 75:402 76:412 77:1431 78:1547 79:1122 80:1370 81:1415 82:962 83:723 84:868 85:1686 86:482 87:1128 88:780 89:2044 90:200 91:6112 92:971 93:2395 94:2344 95:2766 96:571 97:360 98:928 99:91 100:148 101:1242 103:13397 104:2670 105:160 106:477 107:1521 108:790 109:2535 110:1288 111:1670 112:1150 113:1293 114:1014 115:1625 116:1724 117:1641 118:2057 119:1566 120:944 121:1078 122:2273 123:1998 124:1546 125:1820 128:720 129:516 130:414 131:1407 132:550 133:189 134:521 135:213 136:385 137:417 138:1870 139:490 140:616 141:511 142:732 143:922 144:759 145:167 146:1060 147:658 148:1397 149:567 150:684 151:934 152:714 153:314 154:747 155:961 156:543 157:580 158:436 159:1364 160:565 161:734 162:2468 163:532 164:769 165:1147 166:360 167:1258 168:2455 169:721 170:2680 171:271 172:920 173:1829 174:796 175:709 176:1770 177:4120 178:2447 179:1138 180:2106 181:1934 182:2210 183:1020 184:835 185:8555 186:3222 187:2258 188:2354 189:1791 190:8108 191:1318 192:9315 193:5774 194:4591 195:3839 196:1924 197:1230 198:5582 199:5819 200:7338 201:4137 202:10062 203:9870 204:4458 205:2763 206:2972 207:3151 208:3982 209:3878 210:3922 211:2094 212:2781 213:2449 214:845 215:65 216:5808 217:1968 218:832 219:601 220:1688 221:901 222:728 223:1156 End of report From Casey.Schoonover at llcc.edu Thu Jan 26 16:14:48 2017 From: Casey.Schoonover at llcc.edu (Schoonover, Casey A) Date: Thu, 26 Jan 2017 16:14:48 +0000 Subject: Electronic arts peering contact? In-Reply-To: <18C91A84-2EC4-42E7-95AA-4C5E5BBCD30C@mtin.net> References: <18C91A84-2EC4-42E7-95AA-4C5E5BBCD30C@mtin.net> Message-ID: Responded off-list. Casey Schoonover ? CCNA R&S Network Administrator Information and Telecommunications Systems Lincoln Land Community College -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin Wilson Sent: Thursday, January 26, 2017 10:05 AM To: NANOG Subject: Electronic arts peering contact? Does anyone have a peering contact for Electronic Arts? Their peeringdb entry has no info. Thanks in advance. Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric From bruns at 2mbit.com Sat Jan 28 00:29:43 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 27 Jan 2017 17:29:43 -0700 Subject: Any Yahoo DNS admins on list? Message-ID: <69e0bbe3-a21d-2051-c96e-172505a25f04@2mbit.com> Hello! Don't suppose there's a Yahoo admin in the DNS department that can investigate/debug a Geolocation issue? It appears that Yahoo's Geolocation is putting CenturyLink's IPv6 addresses as being in .BR, causing not only the two CL/Qwest recursive servers (205.171.2.65/205.171.3.65/2001:428::1/2001:428::2), but recusive servers hosted on biz customer IPv6 6RD ranges to return non-US Yahoo servers (and be agonizingly slow). ===== View from local powerdns recursor, dual stacked, but preferring ipv6 for resolving: root at noc:~# dig mg.mail.yahoo.com @127.0.0.2 ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @127.0.0.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50638 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mg.mail.yahoo.com. IN A ;; ANSWER SECTION: mg.mail.yahoo.com. 1349 IN CNAME fd-geoycpi-uno.gycpi.b.yahoodns.net. fd-geoycpi-uno.gycpi.b.yahoodns.net. 300 IN A 200.152.162.161 fd-geoycpi-uno.gycpi.b.yahoodns.net. 300 IN A 200.152.162.135 ;; Query time: 240 msec ;; SERVER: 127.0.0.2#53(127.0.0.2) ;; WHEN: Fri Jan 27 17:20:52 MST 2017 ;; MSG SIZE rcvd: 116 ===== View from CL/Qwest IPv4 (likely dual stacked) and IPv6 recursors: root at noc:~# dig mg.mail.yahoo.com @205.171.2.65 ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @205.171.2.65 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8308 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mg.mail.yahoo.com. IN A ;; ANSWER SECTION: mg.mail.yahoo.com. 758 IN CNAME fd-geoycpi-uno.gycpi.b.yahoodns.net. fd-geoycpi-uno.gycpi.b.yahoodns.net. 138 IN A 200.152.162.161 fd-geoycpi-uno.gycpi.b.yahoodns.net. 138 IN A 200.152.162.135 ;; Query time: 17 msec ;; SERVER: 205.171.2.65#53(205.171.2.65) ;; WHEN: Fri Jan 27 17:21:35 MST 2017 ;; MSG SIZE rcvd: 127 root at noc:~# dig mg.mail.yahoo.com @2001:428::1 ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @2001:428::1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24138 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mg.mail.yahoo.com. IN A ;; ANSWER SECTION: mg.mail.yahoo.com. 464 IN CNAME fd-geoycpi-uno.gycpi.b.yahoodns.net. fd-geoycpi-uno.gycpi.b.yahoodns.net. 214 IN A 200.152.162.161 fd-geoycpi-uno.gycpi.b.yahoodns.net. 214 IN A 200.152.162.135 ;; Query time: 46 msec ;; SERVER: 2001:428::1#53(2001:428::1) ;; WHEN: Fri Jan 27 17:23:38 MST 2017 ;; MSG SIZE rcvd: 127 ===== Google recursor for reference: root at noc:~# dig mg.mail.yahoo.com @8.8.8.8 ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13327 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;mg.mail.yahoo.com. IN A ;; ANSWER SECTION: mg.mail.yahoo.com. 1459 IN CNAME fd-geoycpi-uno.gycpi.b.yahoodns.net. fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A 216.115.100.124 fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A 208.71.44.31 fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A 216.115.100.123 fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A 208.71.44.30 ;; Query time: 27 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jan 27 17:21:59 MST 2017 ;; MSG SIZE rcvd: 159 For reference, CL/Qwest's IPv6 range for 6RD is 2602::/24. This appears to be impacting Yahoo, Yahoo Mail, Flickr, etc (aka Yahoo owned properties). Thanks! -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From nolan.berry at RACKSPACE.COM Sat Jan 28 00:34:52 2017 From: nolan.berry at RACKSPACE.COM (Nolan Berry) Date: Sat, 28 Jan 2017 00:34:52 +0000 Subject: Any Yahoo DNS admins on list? In-Reply-To: <69e0bbe3-a21d-2051-c96e-172505a25f04@2mbit.com> References: <69e0bbe3-a21d-2051-c96e-172505a25f04@2mbit.com> Message-ID: <8CB1F8AA-C51A-4175-9825-F3B68C3D1D61@RACKSPACE.COM> There is a thread going on the outages mailing list talking about this issue. Seems to be no failures but increased latency to ns1.yahoo.com and ns3.yahoo.com with trace routes showing USA traffic hitting Asia on v6. Nolan > On Jan 27, 2017, at 6:30 PM, Brielle Bruns wrote: > > Hello! > > Don't suppose there's a Yahoo admin in the DNS department that can investigate/debug a Geolocation issue? > > It appears that Yahoo's Geolocation is putting CenturyLink's IPv6 addresses as being in .BR, causing not only the two CL/Qwest recursive servers (205.171.2.65/205.171.3.65/2001:428::1/2001:428::2), but recusive servers hosted on biz customer IPv6 6RD ranges to return non-US Yahoo servers (and be agonizingly slow). > > ===== > View from local powerdns recursor, dual stacked, but preferring ipv6 for resolving: > > root at noc:~# dig mg.mail.yahoo.com @127.0.0.2 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @127.0.0.2 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50638 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;mg.mail.yahoo.com. IN A > > ;; ANSWER SECTION: > mg.mail.yahoo.com. 1349 IN CNAME fd-geoycpi-uno.gycpi.b.yahoodns.net. > fd-geoycpi-uno.gycpi.b.yahoodns.net. 300 IN A 200.152.162.161 > fd-geoycpi-uno.gycpi.b.yahoodns.net. 300 IN A 200.152.162.135 > > ;; Query time: 240 msec > ;; SERVER: 127.0.0.2#53(127.0.0.2) > ;; WHEN: Fri Jan 27 17:20:52 MST 2017 > ;; MSG SIZE rcvd: 116 > > ===== > View from CL/Qwest IPv4 (likely dual stacked) and IPv6 recursors: > > root at noc:~# dig mg.mail.yahoo.com @205.171.2.65 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @205.171.2.65 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8308 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com. IN A > > ;; ANSWER SECTION: > mg.mail.yahoo.com. 758 IN CNAME fd-geoycpi-uno.gycpi.b.yahoodns.net. > fd-geoycpi-uno.gycpi.b.yahoodns.net. 138 IN A 200.152.162.161 > fd-geoycpi-uno.gycpi.b.yahoodns.net. 138 IN A 200.152.162.135 > > ;; Query time: 17 msec > ;; SERVER: 205.171.2.65#53(205.171.2.65) > ;; WHEN: Fri Jan 27 17:21:35 MST 2017 > ;; MSG SIZE rcvd: 127 > > > root at noc:~# dig mg.mail.yahoo.com @2001:428::1 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @2001:428::1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24138 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com. IN A > > ;; ANSWER SECTION: > mg.mail.yahoo.com. 464 IN CNAME fd-geoycpi-uno.gycpi.b.yahoodns.net. > fd-geoycpi-uno.gycpi.b.yahoodns.net. 214 IN A 200.152.162.161 > fd-geoycpi-uno.gycpi.b.yahoodns.net. 214 IN A 200.152.162.135 > > ;; Query time: 46 msec > ;; SERVER: 2001:428::1#53(2001:428::1) > ;; WHEN: Fri Jan 27 17:23:38 MST 2017 > ;; MSG SIZE rcvd: 127 > > ===== > Google recursor for reference: > > root at noc:~# dig mg.mail.yahoo.com @8.8.8.8 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13327 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com. IN A > > ;; ANSWER SECTION: > mg.mail.yahoo.com. 1459 IN CNAME fd-geoycpi-uno.gycpi.b.yahoodns.net. > fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A 216.115.100.124 > fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A 208.71.44.31 > fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A 216.115.100.123 > fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A 208.71.44.30 > > ;; Query time: 27 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Fri Jan 27 17:21:59 MST 2017 > ;; MSG SIZE rcvd: 159 > > > > For reference, CL/Qwest's IPv6 range for 6RD is 2602::/24. > > This appears to be impacting Yahoo, Yahoo Mail, Flickr, etc (aka Yahoo owned properties). > > > Thanks! > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Sat Jan 28 00:38:12 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 27 Jan 2017 17:38:12 -0700 Subject: Any Yahoo DNS admins on list? In-Reply-To: <8CB1F8AA-C51A-4175-9825-F3B68C3D1D61@RACKSPACE.COM> References: <69e0bbe3-a21d-2051-c96e-172505a25f04@2mbit.com> <8CB1F8AA-C51A-4175-9825-F3B68C3D1D61@RACKSPACE.COM> Message-ID: <7ca80325-c23a-cdd7-4c00-1e1583bb55d4@2mbit.com> On 1/27/17 5:34 PM, Nolan Berry wrote: > There is a thread going on the outages mailing list talking about > this issue. Seems to be no failures but increased latency to > ns1.yahoo.com and ns3.yahoo.com with trace routes showing USA traffic > hitting Asia on v6. > > Nolan Interesting - these performance issues have been going on for around 3 weeks now, I just tonight decided to try and get to the bottom of it and did actual diagnostics (and noticed the issues with geolocation). Good to know I'm not the only one! -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From sh.vahabzadeh at gmail.com Sat Jan 28 11:22:32 2017 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sat, 28 Jan 2017 14:52:32 +0330 Subject: Akamai and Instagram Ranges Message-ID: Hello Hello, Can anybody help me to find out IP Address Ranges of Akamai and Instagram? I wanna do some optimizations on my cache side? Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 6163 From lists at mtin.net Sat Jan 28 13:40:40 2017 From: lists at mtin.net (Justin Wilson) Date: Sat, 28 Jan 2017 08:40:40 -0500 Subject: Akamai and Instagram Ranges In-Reply-To: References: Message-ID: <96FB33E5-3F96-41FE-9B66-4B9A9CDD8AB9@mtin.net> 104.104.0.0/16 is a good place to start. Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Jan 28, 2017, at 6:22 AM, Shahab Vahabzadeh wrote: > > Hello Hello, > Can anybody help me to find out IP Address Ranges of Akamai and Instagram? > I wanna do some optimizations on my cache side? > Thanks > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 6163 > From royce at techsolvency.com Sat Jan 28 15:54:20 2017 From: royce at techsolvency.com (Royce Williams) Date: Sat, 28 Jan 2017 06:54:20 -0900 Subject: Akamai and Instagram Ranges In-Reply-To: References: Message-ID: On Sat, Jan 28, 2017 at 2:22 AM, Shahab Vahabzadeh wrote: > > Hello Hello, > Can anybody help me to find out IP Address Ranges of Akamai and Instagram? > I wanna do some optimizations on my cache side? > Thanks I do not know the difference between Akamai's corporate blocks and those used for caching. I also do not know the value of what you're trying to accomplish. But searching naively, there are at least 7291 Akamai IP blocks: http://bgp.he.net/search?search%5Bsearch%5D=AKAMAI-AS&commit=Search Those 7291 blocks can be summarized on bit boundaries down to 172 blocks: https://gist.github.com/roycewilliams/31c3eeb030bdd5f557d845c344933c67 Using this approach is a good start, but it cannot be complete. Some caches are colocated with ISPs and use their IP space. Royce From patrick at ianai.net Sat Jan 28 16:37:44 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 28 Jan 2017 11:37:44 -0500 Subject: Akamai and Instagram Ranges In-Reply-To: References: Message-ID: <00DA7DA8-2258-42D8-B722-0D082573DC9E@ianai.net> Akamai does not give out the IP space they use, for good and valid reasons. Also, Akamai -is- a cache (just pretend for sake of this argument that none of you is ridiculously overly pedantic). If you are trying to cache on-net, why not just ask them to do it for you? It?s free. https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf If you do not qualify for free on-net caches, and cannot peer with them anywhere, you could try doing a lookup on some popular Akamai customers, or even just www.akamai.com, then ?optimize? that block. But that might not work as well as you hope. Akamai customers want to see every hit, many of them put in ?cache busting? code. Good luck. -- TTFN, patrick > On Jan 28, 2017, at 6:22 AM, Shahab Vahabzadeh wrote: > > Hello Hello, > Can anybody help me to find out IP Address Ranges of Akamai and Instagram? > I wanna do some optimizations on my cache side? > Thanks > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 6163 From hannigan at gmail.com Sat Jan 28 19:02:33 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 28 Jan 2017 14:02:33 -0500 Subject: Akamai and Instagram Ranges In-Reply-To: References: Message-ID: On Saturday, January 28, 2017, Royce Williams wrote: > On Sat, Jan 28, 2017 at 2:22 AM, Shahab Vahabzadeh > > wrote: > > > > Hello Hello, > > Can anybody help me to find out IP Address Ranges of Akamai and > Instagram? > > I wanna do some optimizations on my cache side? > > Thanks > > I do not know the difference between Akamai's corporate blocks and > those used for caching. I also do not know the value of what you're > trying to accomplish. Insignificant. Dont waste any time on it. If you do have a corp question ask peering@ to redirect. Also read Patrick Gilmores response for color. Best, -M< From lists at velder.li Sat Jan 28 16:17:30 2017 From: lists at velder.li (Patrick Velder) Date: Sat, 28 Jan 2017 17:17:30 +0100 Subject: Netflow/sFlow generator for Linux with BGP support Message-ID: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li> Hi there I'm currently switching from MikroTik CCR 1009 to SuperMicro 5018D-FN8T as small router. Now I'd love to integrate BGP infos into netflow/sflow, as MikroTik still doesn't have any support for that. Are there any alternatives to nProbe (which supports BGP but is ways too expensive with its 300?)? Regards Patrick From joelja at bogus.com Sun Jan 29 04:18:55 2017 From: joelja at bogus.com (joel jaeggli) Date: Sat, 28 Jan 2017 20:18:55 -0800 Subject: Akamai and Instagram Ranges In-Reply-To: References: Message-ID: <0cb4be56-c499-0199-8f85-0a23bffe0615@bogus.com> On 1/28/17 3:22 AM, Shahab Vahabzadeh wrote: > Hello Hello, > Can anybody help me to find out IP Address Ranges of Akamai and Instagram? > I wanna do some optimizations on my cache side? > Thanks > Instagram should be exclusively https since 2014 or so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From mel at beckman.org Sun Jan 29 04:55:16 2017 From: mel at beckman.org (Mel Beckman) Date: Sun, 29 Jan 2017 04:55:16 +0000 Subject: Netflow/sFlow generator for Linux with BGP support In-Reply-To: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li> References: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li> Message-ID: <8B8E3F7F-761A-4A5D-8F1F-465475B89F57@beckman.org> Patrick, nProbe Pro is very good and worth the price for its proprietary high-speed ring PF_RING packet buffer implementation and plug-in support. If you can't afford the Pro version, the $50 embedded version lets you get familiar with outboard flow generation using a cheap EdgeOS device. -mel via cell > On Jan 28, 2017, at 7:36 PM, Patrick Velder wrote: > > Hi there > > I'm currently switching from MikroTik CCR 1009 to SuperMicro 5018D-FN8T as small router. Now I'd love to integrate BGP infos into netflow/sflow, as MikroTik still doesn't have any support for that. > > Are there any alternatives to nProbe (which supports BGP but is ways too expensive with its 300?)? > > Regards > Patrick > From mel at beckman.org Sun Jan 29 06:18:32 2017 From: mel at beckman.org (Mel Beckman) Date: Sun, 29 Jan 2017 06:18:32 +0000 Subject: Netflow/sFlow generator for Linux with BGP support In-Reply-To: <8B8E3F7F-761A-4A5D-8F1F-465475B89F57@beckman.org> References: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li>, <8B8E3F7F-761A-4A5D-8F1F-465475B89F57@beckman.org> Message-ID: <65FE5066-A03C-450F-A67F-19AC5FEC073A@beckman.org> Patrick Here's a link to the How-To for a cheap EdgeOS hardware probed: http://www.ntop.org/nprobe/how-to-build-a-100e-augmented-netflowipfix-probe-ubiquity/ -mel > On Jan 28, 2017, at 8:56 PM, Mel Beckman wrote: > > Patrick, > > nProbe Pro is very good and worth the price for its proprietary high-speed ring PF_RING packet buffer implementation and plug-in support. If you can't afford the Pro version, the $50 embedded version lets you get familiar with outboard flow generation using a cheap EdgeOS device. > > -mel via cell > >> On Jan 28, 2017, at 7:36 PM, Patrick Velder wrote: >> >> Hi there >> >> I'm currently switching from MikroTik CCR 1009 to SuperMicro 5018D-FN8T as small router. Now I'd love to integrate BGP infos into netflow/sflow, as MikroTik still doesn't have any support for that. >> >> Are there any alternatives to nProbe (which supports BGP but is ways too expensive with its 300?)? >> >> Regards >> Patrick >> From peter.phaal at gmail.com Sun Jan 29 06:43:02 2017 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 28 Jan 2017 22:43:02 -0800 Subject: Netflow/sFlow generator for Linux with BGP support In-Reply-To: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li> References: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li> Message-ID: Patrick, You might want to try pmacct: http://www.pmacct.net/ Peter On Sat, Jan 28, 2017 at 8:17 AM, Patrick Velder wrote: > Hi there > > I'm currently switching from MikroTik CCR 1009 to SuperMicro 5018D-FN8T as > small router. Now I'd love to integrate BGP infos into netflow/sflow, as > MikroTik still doesn't have any support for that. > > Are there any alternatives to nProbe (which supports BGP but is ways too > expensive with its 300?)? > > Regards > Patrick > > From tom at ninjabadger.net Mon Jan 30 01:14:30 2017 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 30 Jan 2017 01:14:30 +0000 Subject: Netflow/sFlow generator for Linux with BGP support In-Reply-To: References: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li> Message-ID: <1cb0db4c-6706-ddfb-01e6-37fc7e9c410a@ninjabadger.net> On 29/01/17 06:43, Peter Phaal wrote: > You might want to try pmacct: > http://www.pmacct.net/ That's definitely a good idea. +1 -- Tom From marty at cloudflare.com Mon Jan 30 13:48:46 2017 From: marty at cloudflare.com (Marty Strong) Date: Mon, 30 Jan 2017 13:48:46 +0000 Subject: Looking for AS6327/Shaw contact Message-ID: <8F160FE2-C467-4A1D-AABB-37181D22A36B@cloudflare.com> Hi NANOG members, Could somebody responsible for peering at AS6327/Shaw contact me off-list? I?ve tried the regular peering alias and got automated replies, but no human replies. Thanks! Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 From marty at cloudflare.com Mon Jan 30 15:45:25 2017 From: marty at cloudflare.com (Marty Strong) Date: Mon, 30 Jan 2017 15:45:25 +0000 Subject: Looking for AS6327/Shaw contact In-Reply-To: <8F160FE2-C467-4A1D-AABB-37181D22A36B@cloudflare.com> References: <8F160FE2-C467-4A1D-AABB-37181D22A36B@cloudflare.com> Message-ID: <0A8E2C37-A5F6-48C5-84F7-BAE6806DB424@cloudflare.com> Somebody contacted me off list, thanks all! Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 30 Jan 2017, at 13:48, Marty Strong wrote: > > Hi NANOG members, > > Could somebody responsible for peering at AS6327/Shaw contact me off-list? I?ve tried the regular peering alias and got automated replies, but no human replies. > > Thanks! > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > From michael.patterson at plixer.com Sun Jan 29 12:24:20 2017 From: michael.patterson at plixer.com (Mike Patterson) Date: Sun, 29 Jan 2017 12:24:20 +0000 Subject: Netflow/sFlow generator for Linux with BGP support In-Reply-To: <8B8E3F7F-761A-4A5D-8F1F-465475B89F57@beckman.org> References: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li> <8B8E3F7F-761A-4A5D-8F1F-465475B89F57@beckman.org> Message-ID: <3F566BF3F77F3D4A86D74682410FEFD7BED61E77@PLXRDC01.plxr.local> I agree. nProbe is a great solution. It scales and provides tons of metrics if you decide you need visibility beyond BGP. Michael Patterson www.plixer.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mel Beckman Sent: Saturday, January 28, 2017 11:55 PM To: Patrick Velder Cc: nanog at nanog.org Subject: Re: Netflow/sFlow generator for Linux with BGP support Patrick, nProbe Pro is very good and worth the price for its proprietary high-speed ring PF_RING packet buffer implementation and plug-in support. If you can't afford the Pro version, the $50 embedded version lets you get familiar with outboard flow generation using a cheap EdgeOS device. -mel via cell > On Jan 28, 2017, at 7:36 PM, Patrick Velder wrote: > > Hi there > > I'm currently switching from MikroTik CCR 1009 to SuperMicro 5018D-FN8T as small router. Now I'd love to integrate BGP infos into netflow/sflow, as MikroTik still doesn't have any support for that. > > Are there any alternatives to nProbe (which supports BGP but is ways too expensive with its 300?)? > > Regards > Patrick > From nagarjun.govindraj at imaginea.com Mon Jan 30 06:41:13 2017 From: nagarjun.govindraj at imaginea.com (Nagarjun Govindraj) Date: Mon, 30 Jan 2017 06:41:13 +0000 Subject: BGP IP prefix hijacking Message-ID: Hi All, I am planning to write a tool to detect real time BGP IP prefix hijacking. I am glad to know some of the open problems faced by providers/companies/community. I would like to know how the community is currently dealing and mitigating with such problems. It will be very helpful to know some of the adopted strategies by the community to detect bgp IP prefix hijacking and problems that are yet to be solved. Also I would like to know some of the very well industry standard open source tools used in the area of BGP which makes life easier. Regards, Nagarjun From bob at FiberInternetCenter.com Mon Jan 30 18:16:54 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 30 Jan 2017 10:16:54 -0800 Subject: -Spam- BGP IP prefix hijacking In-Reply-To: References: Message-ID: <86030da34c1228a0a51320f5c695a1f6.squirrel@66.201.44.180> The more tools the better the net can become. I find that BGPmon.net is pretty good. I have not yet found anything else as good. You put in your prefixes and they email notify you of bgp changes they see with the AS hop string announcing. Helpful not just for hijacks - but to know that peers of peers are receiving your prefixes with your ASN. Thank You Bob Evans CTO > Hi All, > > I am planning to write a tool to detect real time BGP IP prefix hijacking. > I am glad to know some of the open problems faced by > providers/companies/community. > I would like to know how the community is currently dealing and mitigating > with such problems. > It will be very helpful to know some of the adopted strategies by the > community to detect bgp IP prefix hijacking and problems that are yet to > be > solved. > Also I would like to know some of the very well industry standard open > source tools used in the area of BGP which makes life easier. > > Regards, > Nagarjun > From bob at FiberInternetCenter.com Mon Jan 30 18:21:41 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 30 Jan 2017 10:21:41 -0800 Subject: BGP IP prefix hijacking In-Reply-To: <86030da34c1228a0a51320f5c695a1f6.squirrel@66.201.44.180> References: <86030da34c1228a0a51320f5c695a1f6.squirrel@66.201.44.180> Message-ID: OOPs the Spam thing is just our firewall indicator to possibility - meet a threshold level - i forgot to remove it when replying. Didnt mean to call your email spam. Thank You Bob Evans CTO > The more tools the better the net can become. > I find that BGPmon.net is pretty good. I have not yet found anything else > as good. > > You put in your prefixes and they email notify you of bgp changes they see > with the AS hop string announcing. Helpful not just for hijacks - but to > know that peers of peers are receiving your prefixes with your ASN. > > Thank You > Bob Evans > CTO > > > > >> Hi All, >> >> I am planning to write a tool to detect real time BGP IP prefix >> hijacking. >> I am glad to know some of the open problems faced by >> providers/companies/community. >> I would like to know how the community is currently dealing and >> mitigating >> with such problems. >> It will be very helpful to know some of the adopted strategies by the >> community to detect bgp IP prefix hijacking and problems that are yet to >> be >> solved. >> Also I would like to know some of the very well industry standard open >> source tools used in the area of BGP which makes life easier. >> >> Regards, >> Nagarjun >> > > > From dstates at yahoo-inc.com Tue Jan 31 03:04:40 2017 From: dstates at yahoo-inc.com (Dan States) Date: Tue, 31 Jan 2017 03:04:40 +0000 (UTC) Subject: Fwd: Any Yahoo DNS admins on list? In-Reply-To: References: <69e0bbe3-a21d-2051-c96e-172505a25f04@2mbit.com> <8CB1F8AA-C51A-4175-9825-F3B68C3D1D61@RACKSPACE.COM> Message-ID: <1468333261.237161.1485831880531@mail.yahoo.com> Looks like this may be a peering issue, we're investigating. ? Regards -- ? Dan States - Yahoo DNS Operations On Saturday, January 28, 2017, 4:29:12 AM PST, Stephen Strowes wrote:I assume somebody knows about this thread :-) S. ---------- Forwarded message ---------- > On Jan 27, 2017, at 6:30 PM, Brielle Bruns wrote: > > Hello! > > Don't suppose there's a Yahoo admin in the DNS department that can investigate/debug a Geolocation issue? > > It appears that Yahoo's Geolocation is putting CenturyLink's IPv6 addresses as being in .BR, causing not only the two CL/Qwest recursive servers (205.171.2.65/205.171.3.65/ 2001:428::1/2001:428::2), but recusive servers hosted on biz customer IPv6 6RD ranges to return non-US Yahoo servers (and be agonizingly slow). > > ===== > View from local powerdns recursor, dual stacked, but preferring ipv6 for resolving: > > root at noc:~# dig mg.mail.yahoo.com @127.0.0.2 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @127.0.0.2 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50638 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;mg.mail.yahoo.com.? ? ? ? IN? ? A > > ;; ANSWER SECTION: > mg.mail.yahoo.com.? ? 1349? ? IN? ? CNAME? ? fd-geoycpi-uno.gycpi.b. yahoodns.net. > fd-geoycpi-uno.gycpi.b. yahoodns.net. 300 IN A? ? 200.152.162.161 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 300 IN A? ? 200.152.162.135 > > ;; Query time: 240 msec > ;; SERVER: 127.0.0.2#53(127.0.0.2) > ;; WHEN: Fri Jan 27 17:20:52 MST 2017 > ;; MSG SIZE? rcvd: 116 > > ===== > View from CL/Qwest IPv4 (likely dual stacked) and IPv6 recursors: > > root at noc:~# dig mg.mail.yahoo.com @205.171.2.65 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @205.171.2.65 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8308 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com.? ? ? ? IN? ? A > > ;; ANSWER SECTION: > mg.mail.yahoo.com.? ? 758? ? IN? ? CNAME? ? fd-geoycpi-uno.gycpi.b. yahoodns.net. > fd-geoycpi-uno.gycpi.b. yahoodns.net. 138 IN A? ? 200.152.162.161 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 138 IN A? ? 200.152.162.135 > > ;; Query time: 17 msec > ;; SERVER: 205.171.2.65#53(205.171.2.65) > ;; WHEN: Fri Jan 27 17:21:35 MST 2017 > ;; MSG SIZE? rcvd: 127 > > > root at noc:~# dig mg.mail.yahoo.com @2001:428::1 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @2001:428::1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24138 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com.? ? ? ? IN? ? A > > ;; ANSWER SECTION: > mg.mail.yahoo.com.? ? 464? ? IN? ? CNAME? ? fd-geoycpi-uno.gycpi.b. yahoodns.net. > fd-geoycpi-uno.gycpi.b. yahoodns.net. 214 IN A? ? 200.152.162.161 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 214 IN A? ? 200.152.162.135 > > ;; Query time: 46 msec > ;; SERVER: 2001:428::1#53(2001:428::1) > ;; WHEN: Fri Jan 27 17:23:38 MST 2017 > ;; MSG SIZE? rcvd: 127 > > ===== > Google recursor for reference: > > root at noc:~# dig mg.mail.yahoo.com @8.8.8.8 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13327 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com.? ? ? ? IN? ? A > > ;; ANSWER SECTION: > mg.mail.yahoo.com.? ? 1459? ? IN? ? CNAME? ? fd-geoycpi-uno.gycpi.b. yahoodns.net. > fd-geoycpi-uno.gycpi.b. yahoodns.net. 184 IN A? ? 216.115.100.124 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 184 IN A? ? 208.71.44.31 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 184 IN A? ? 216.115.100.123 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 184 IN A? ? 208.71.44.30 > > ;; Query time: 27 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Fri Jan 27 17:21:59 MST 2017 > ;; MSG SIZE? rcvd: 159 > > > > For reference, CL/Qwest's IPv6 range for 6RD is 2602::/24. > > This appears to be impacting Yahoo, Yahoo Mail, Flickr, etc (aka Yahoo owned properties). > > > Thanks! > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org? ? /? ? ?http://www.ahbl.org From dstates at yahoo-inc.com Tue Jan 31 04:03:27 2017 From: dstates at yahoo-inc.com (Dan States) Date: Tue, 31 Jan 2017 04:03:27 +0000 (UTC) Subject: Fwd: Any Yahoo DNS admins on list? In-Reply-To: <1468333261.237161.1485831880531@mail.yahoo.com> References: <69e0bbe3-a21d-2051-c96e-172505a25f04@2mbit.com> <8CB1F8AA-C51A-4175-9825-F3B68C3D1D61@RACKSPACE.COM> <1468333261.237161.1485831880531@mail.yahoo.com> Message-ID: <1170472986.254770.1485835407314@mail.yahoo.com> Hello Brielle, The issue has been resolved, I confirmed the Qwest/CenturyLink resolver you mentioned is being properly routed. -- ? Dan?States - Yahoo DNS Operations On Monday, January 30, 2017, 7:04:40 PM PST, Dan States wrote:Looks like this may be a peering issue, we're investigating. ? Regards -- ? Dan States - Yahoo DNS Operations On Saturday, January 28, 2017, 4:29:12 AM PST, Stephen Strowes wrote:I assume somebody knows about this thread :-) S. ---------- Forwarded message ---------- > On Jan 27, 2017, at 6:30 PM, Brielle Bruns wrote: > > Hello! > > Don't suppose there's a Yahoo admin in the DNS department that can investigate/debug a Geolocation issue? > > It appears that Yahoo's Geolocation is putting CenturyLink's IPv6 addresses as being in .BR, causing not only the two CL/Qwest recursive servers (205.171.2.65/205.171.3.65/ 2001:428::1/2001:428::2), but recusive servers hosted on biz customer IPv6 6RD ranges to return non-US Yahoo servers (and be agonizingly slow). > > ===== > View from local powerdns recursor, dual stacked, but preferring ipv6 for resolving: > > root at noc:~# dig mg.mail.yahoo.com @127.0.0.2 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @127.0.0.2 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50638 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;mg.mail.yahoo.com.? ? ? ? IN? ? A > > ;; ANSWER SECTION: > mg.mail.yahoo.com.? ? 1349? ? IN? ? CNAME? ? fd-geoycpi-uno.gycpi.b. yahoodns.net. > fd-geoycpi-uno.gycpi.b. yahoodns.net. 300 IN A? ? 200.152.162.161 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 300 IN A? ? 200.152.162.135 > > ;; Query time: 240 msec > ;; SERVER: 127.0.0.2#53(127.0.0.2) > ;; WHEN: Fri Jan 27 17:20:52 MST 2017 > ;; MSG SIZE? rcvd: 116 > > ===== > View from CL/Qwest IPv4 (likely dual stacked) and IPv6 recursors: > > root at noc:~# dig mg.mail.yahoo.com @205.171.2.65 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @205.171.2.65 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8308 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com.? ? ? ? IN? ? A > > ;; ANSWER SECTION: > mg.mail.yahoo.com.? ? 758? ? IN? ? CNAME? ? fd-geoycpi-uno.gycpi.b. yahoodns.net. > fd-geoycpi-uno.gycpi.b. yahoodns.net. 138 IN A? ? 200.152.162.161 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 138 IN A? ? 200.152.162.135 > > ;; Query time: 17 msec > ;; SERVER: 205.171.2.65#53(205.171.2.65) > ;; WHEN: Fri Jan 27 17:21:35 MST 2017 > ;; MSG SIZE? rcvd: 127 > > > root at noc:~# dig mg.mail.yahoo.com @2001:428::1 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @2001:428::1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24138 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com.? ? ? ? IN? ? A > > ;; ANSWER SECTION: > mg.mail.yahoo.com.? ? 464? ? IN? ? CNAME? ? fd-geoycpi-uno.gycpi.b. yahoodns.net. > fd-geoycpi-uno.gycpi.b. yahoodns.net. 214 IN A? ? 200.152.162.161 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 214 IN A? ? 200.152.162.135 > > ;; Query time: 46 msec > ;; SERVER: 2001:428::1#53(2001:428::1) > ;; WHEN: Fri Jan 27 17:23:38 MST 2017 > ;; MSG SIZE? rcvd: 127 > > ===== > Google recursor for reference: > > root at noc:~# dig mg.mail.yahoo.com @8.8.8.8 > > ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13327 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;mg.mail.yahoo.com.? ? ? ? IN? ? A > > ;; ANSWER SECTION: > mg.mail.yahoo.com.? ? 1459? ? IN? ? CNAME? ? fd-geoycpi-uno.gycpi.b. yahoodns.net. > fd-geoycpi-uno.gycpi.b. yahoodns.net. 184 IN A? ? 216.115.100.124 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 184 IN A? ? 208.71.44.31 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 184 IN A? ? 216.115.100.123 > fd-geoycpi-uno.gycpi.b. yahoodns.net. 184 IN A? ? 208.71.44.30 > > ;; Query time: 27 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Fri Jan 27 17:21:59 MST 2017 > ;; MSG SIZE? rcvd: 159 > > > > For reference, CL/Qwest's IPv6 range for 6RD is 2602::/24. > > This appears to be impacting Yahoo, Yahoo Mail, Flickr, etc (aka Yahoo owned properties). > > > Thanks! > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org? ? /? ? ?http://www.ahbl.org From karl_gerh at gmx.at Tue Jan 31 15:17:14 2017 From: karl_gerh at gmx.at (Karl Gerhard) Date: Tue, 31 Jan 2017 16:17:14 +0100 Subject: DWDM Optics cheaper than CWDM Optics? Message-ID: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> Hello, fs.com offers DWDM optics that are cheaper than CWDM optics: CWDM 80km 10G for 600$ http://www.fs.com/c/cisco-cwdm-sfp-plus-2425?70-80km DWDM 80km 10G for 420$ http://www.fs.com/c/cisco-dwdm-sfp-plus-2485?70-80km This is significant. Is this for real? Has anybody bought their DWDM optics? Going with DWDM and passive Mux/Demux seems to be cheaper nowadays than going with CWDM. Regards Karl From lguillory at reservetele.com Tue Jan 31 15:37:00 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 31 Jan 2017 15:37:00 +0000 Subject: DWDM Optics cheaper than CWDM Optics? In-Reply-To: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> References: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB069988@RTC-EXCH01.RESERVE.LDS> Karl, I've bought at least 20k in optics from them in the last 2 years, from QSFP DAC, QSFP to 10g breakouts and everything in between and the only thing to fail was 1 QSFP breakout cable. A partner of ours uses their DWDM optics and passive MUXs while I've used their CWDM with no issues. Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Karl Gerhard Sent: Tuesday, January 31, 2017 9:17 AM To: nanog at nanog.org Subject: DWDM Optics cheaper than CWDM Optics? Hello, fs.com offers DWDM optics that are cheaper than CWDM optics: CWDM 80km 10G for 600$ http://www.fs.com/c/cisco-cwdm-sfp-plus-2425?70-80km DWDM 80km 10G for 420$ http://www.fs.com/c/cisco-dwdm-sfp-plus-2485?70-80km This is significant. Is this for real? Has anybody bought their DWDM optics? Going with DWDM and passive Mux/Demux seems to be cheaper nowadays than going with CWDM. Regards Karl From bob at FiberInternetCenter.com Tue Jan 31 15:39:26 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 31 Jan 2017 07:39:26 -0800 Subject: DWDM Optics cheaper than CWDM Optics? In-Reply-To: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> References: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> Message-ID: <0a15c86fa15f66a2ed20d5a9e211253c.squirrel@66.201.44.180> I have been under the impression for years now that the age of the fiber may play a roll in which you prefer due to channel spacing needed to cram in more frequencies. Never really came across a real world situation where one didn't work as well as the other. There is probably more things to consider than the fiber's age. Thank You Bob Evans CTO > Hello, > > fs.com offers DWDM optics that are cheaper than CWDM optics: > CWDM 80km 10G for 600$ > http://www.fs.com/c/cisco-cwdm-sfp-plus-2425?70-80km > DWDM 80km 10G for 420$ > http://www.fs.com/c/cisco-dwdm-sfp-plus-2485?70-80km > > This is significant. > Is this for real? Has anybody bought their DWDM optics? > > Going with DWDM and passive Mux/Demux seems to be cheaper nowadays than > going with CWDM. > > Regards > Karl > From lists.nanog at monmotha.net Tue Jan 31 15:39:55 2017 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 31 Jan 2017 10:39:55 -0500 Subject: DWDM Optics cheaper than CWDM Optics? In-Reply-To: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> References: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> Message-ID: <5890AFCB.701@monmotha.net> On 01/31/2017 10:17 AM, Karl Gerhard wrote: > Hello, > > fs.com offers DWDM optics that are cheaper than CWDM optics: > CWDM 80km 10G for 600$ http://www.fs.com/c/cisco-cwdm-sfp-plus-2425?70-80km > DWDM 80km 10G for 420$ http://www.fs.com/c/cisco-dwdm-sfp-plus-2485?70-80km > > This is significant. > Is this for real? Has anybody bought their DWDM optics? > > Going with DWDM and passive Mux/Demux seems to be cheaper nowadays than > going with CWDM. I came to the same conclusion a couple years ago. At the time, CWDM was about the same price as DWDM or maybe still just a hair cheaper, but the DWDM system is a) so much more capable, and b) typically has better tools/monitoring, etc. (if you're using muxponders, etc.) that it made sense to just go DWDM. Given advances in optics, I'm not surprised that DWDM is now cheaper than CWDM outright. Of course, the same may not be true if you're buying a fully engineered system from a major vendor. CWDM can be a little easier to engineer...sometimes. -- Brandon Martin From s+Mailinglisten.nanog at sloc.de Tue Jan 31 16:55:17 2017 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Tue, 31 Jan 2017 17:55:17 +0100 Subject: BGP route processing speed In-Reply-To: References: Message-ID: <5890C175.9040307@sloc.de> Hey Sriram, hope, you are doing fine. my BSc thesis from 2010 might be relevant to what you are looking for. https://drive.google.com/file/d/0B5kLBHCcFJjFZk5RTUtwbUstbm8/view?usp=sharing Best, Sebastian Sriram, Kotikalapudi (Fed) schrieb: > I am interested in measurements related to BGP route processing speed > > (i.e. routing engine capacity in terms of routes or updates processed per second). > > Folks from AMS-IX did an interesting study in 2012 > > in their Route Server / IXP environment. > > https://ams-ix.net/downloads/ams-ix-route-server-implementations-performance.pdf > > > > Are there other measurement studies available > > on this topic, especially in ISP/PE router scenarios, > > including BGP policy processing, best path selection, route filtering, etc.? > > Will appreciate much if you can share some pointers. > > > > Sriram > From me at nek0.net Tue Jan 31 17:02:29 2017 From: me at nek0.net (Stanislaw Datskevich) Date: Tue, 31 Jan 2017 19:02:29 +0200 Subject: Netflow/sFlow generator for Linux with BGP support In-Reply-To: <1cb0db4c-6706-ddfb-01e6-37fc7e9c410a@ninjabadger.net> References: <85205db5-3d5f-400c-2839-75f2ca409c66@velder.li> <1cb0db4c-6706-ddfb-01e6-37fc7e9c410a@ninjabadger.net> Message-ID: Affirmative, works like a charm. Also the author is very responsive (has even answered to my dumb questions in the list). 30.01.2017 03:14, Tom Hill ?????: > On 29/01/17 06:43, Peter Phaal wrote: >> You might want to try pmacct: >> http://www.pmacct.net/ > That's definitely a good idea. +1 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 850 bytes Desc: OpenPGP digital signature URL: From faisal at snappytelecom.net Tue Jan 31 17:42:05 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 31 Jan 2017 17:42:05 +0000 (GMT) Subject: DWDM Optics cheaper than CWDM Optics? In-Reply-To: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> References: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> Message-ID: <1288588190.1747973.1485884525626.JavaMail.zimbra@snappytelecom.net> Since I am in the middle of doing something similar, I will share my observations. CWDM Advantage:- Passive CWDM Muxes are less expensive than the DWDM counterparts. Short Range optics (CWDM) are favorable priced Long Range optics are not so favorably priced. ( I guess that is due to production volume). Deploying a CWDM passive mux solution, can allow you to stack a DWDM mux on the 1530-1560 CWDM channel. (one has to pay attention to the loss/attenuation calcs). If you need to Regen the light.. then there are a lot of solutions (cost effective) available for the DWDM channel range (have not been able to find any kind of amps for CWDM.. if anyone has suggestions, I would be open to them). Amount of channels available on CDWM are limited in qty when compared to what is possible with DWDM. When using long rage optics, pay attention to the equipment you are plugging them in.. not all optical ports are capable of supplying the amount of power and heat dissipation required. As to the original question about the quality of optics from FS.COM.. We have no complaints, when there were mistakes made, they stood behind their products and corrected them. I would recommend that you deal with one of their many Sales Rep's vs just placing order online. Their products match the specs they list.. They are also able to do some custom stuff which is not listed on their web site.. (i.e. provide muxes which have a lower insertion loss in certain configurations). Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Karl Gerhard" > To: "nanog list" > Sent: Tuesday, January 31, 2017 10:17:14 AM > Subject: DWDM Optics cheaper than CWDM Optics? > Hello, > > fs.com offers DWDM optics that are cheaper than CWDM optics: > CWDM 80km 10G for 600$ http://www.fs.com/c/cisco-cwdm-sfp-plus-2425?70-80km > DWDM 80km 10G for 420$ http://www.fs.com/c/cisco-dwdm-sfp-plus-2485?70-80km > > This is significant. > Is this for real? Has anybody bought their DWDM optics? > > Going with DWDM and passive Mux/Demux seems to be cheaper nowadays than going > with CWDM. > > Regards > Karl From colton.conor at gmail.com Tue Jan 31 18:21:22 2017 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 31 Jan 2017 12:21:22 -0600 Subject: DWDM Optics cheaper than CWDM Optics? In-Reply-To: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> References: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> Message-ID: Just so you know, FS.com now stocks many of the common optics in Seattle Washington for next day delivery. So they now are stocking more and more items in the USA. When we order an item from China on Monday USA time, we get it it Thursday morning USA time if its in stock in China! On Tue, Jan 31, 2017 at 9:17 AM, Karl Gerhard wrote: > Hello, > > fs.com offers DWDM optics that are cheaper than CWDM optics: > CWDM 80km 10G for 600$ http://www.fs.com/c/cisco-cwdm > -sfp-plus-2425?70-80km > DWDM 80km 10G for 420$ http://www.fs.com/c/cisco-dwdm > -sfp-plus-2485?70-80km > > This is significant. > Is this for real? Has anybody bought their DWDM optics? > > Going with DWDM and passive Mux/Demux seems to be cheaper nowadays than > going with CWDM. > > Regards > Karl > From cra at WPI.EDU Tue Jan 31 18:46:58 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 31 Jan 2017 13:46:58 -0500 Subject: DWDM Optics cheaper than CWDM Optics? In-Reply-To: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> References: <0c64d2c9-1be1-0443-0432-b73b9ae49f46@gmx.at> Message-ID: <20170131184658.GF3933@angus.ind.wpi.edu> I've bought their DWDM 80km 10gig and they are working beautifully on a couple amplified circuits with both Cisco and Juniper routers. I've also bought gray optics and DACs. The only issue I've noted with some QSFP+ DACs is some kind of programming issue where the serial number is mis-read by some models of our Juniper switches. Another oddity is that each end of some of our DACs have a separate serial number...we just record both in our inventory tracking system. On Tue, Jan 31, 2017 at 04:17:14PM +0100, Karl Gerhard wrote: > Hello, > > fs.com offers DWDM optics that are cheaper than CWDM optics: > CWDM 80km 10G for 600$ http://www.fs.com/c/cisco-cwdm-sfp-plus-2425?70-80km > DWDM 80km 10G for 420$ http://www.fs.com/c/cisco-dwdm-sfp-plus-2485?70-80km > > This is significant. > Is this for real? Has anybody bought their DWDM optics? > > Going with DWDM and passive Mux/Demux seems to be cheaper nowadays than going with CWDM. > > Regards > Karl