From randy at psg.com Thu Jan 1 03:34:36 2015 From: randy at psg.com (Randy Bush) Date: Thu, 01 Jan 2015 12:34:36 +0900 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A3E72F.20801@marcinkurek.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> Message-ID: > - Move RRs out of the forwarding path this remains contentious. there are those who think having the control plane not congruent to the data plane is a recipe for really fun debugging and has other issues. randy From stephen.lee at congressmail.com Thu Jan 1 03:38:56 2015 From: stephen.lee at congressmail.com (Stephen Lee) Date: Thu, 1 Jan 2015 03:38:56 +0000 Subject: MPLS VPN design - RR in forwarding path? Message-ID: . Yn ----- Reply message ----- From: "Randy Bush" To: "Marcin Kurek" Cc: "North American Network Operators' Group" Subject: MPLS VPN design - RR in forwarding path? Date: Wed, Dec 31, 2014 9:36 PM > - Move RRs out of the forwarding path this remains contentious. there are those who think having the control plane not congruent to the data plane is a recipe for really fun debugging and has other issues. randy From notify at marcinkurek.com Thu Jan 1 10:46:23 2015 From: notify at marcinkurek.com (Marcin Kurek) Date: Thu, 01 Jan 2015 11:46:23 +0100 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <20141231170539.GL18618@angus.ind.WPI.EDU> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <20141231170539.GL18618@angus.ind.WPI.EDU> Message-ID: <54A5257F.1090300@marcinkurek.com> Hello all, Thank you for insightful answers. I was thinking mostly about the second scenario Chuck mentioned - where some traffic naturally flows through the routers that are the RRs because of MPLS LSP. Setting next-hop-self on all reflected routes would be misconfiguration IMHO. I am also aware of products like vMX or CSR1000v/XRv and the example given by Saku makes me more interested in licensing/pricing options. Regards, Marcin W dniu 2014-12-31 o 18:05, Chuck Anderson pisze: > On Wed, Dec 31, 2014 at 01:08:15PM +0100, Marcin Kurek wrote: >> Hi everyone, >> >> I'm reading Randy's Zhang BGP Design and Implementation and I found >> following guidelines about designing RR-based MPLS VPN architecture: >> - Partition RRs >> - Move RRs out of the forwarding path >> - Use a high-end processor with maximum memory >> - Use peer groups >> - Tune RR routers for improved performance. >> >> Since the book is a bit outdated (2004) I'm curious if these rules >> still apply to modern SP networks. >> What would be the reasoning behind keeping RRs out of the forwarding >> path? Is it only a matter of performance and stability? > When they say "move RRs out of the forwarding path", they could mean > "don't force all traffic through the RRs". These are two different > things. Naive configurations could end up causing all VPN traffic to > go through the RRs (e.g. setting next-hop-self on all reflected > routes) whereas more correct configurations don't do that--but there > may be some traffic that natrually flows through the same routers that > are the RRs, via an MPLS LSP for example. That latter is fine in many > cases, the former is not. E.g. I would argue that a P-router can be > an RR if desired. From tvarriale at comcast.net Thu Jan 1 21:25:24 2015 From: tvarriale at comcast.net (Tony Varriale) Date: Thu, 01 Jan 2015 15:25:24 -0600 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A3E72F.20801@marcinkurek.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> Message-ID: <54A5BB44.9080208@comcast.net> On 12/31/2014 6:08 AM, Marcin Kurek wrote: > Hi everyone, > > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path > - Use a high-end processor with maximum memory > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules > still apply to modern SP networks. > What would be the reasoning behind keeping RRs out of the forwarding > path? Is it only a matter of performance and stability? > > Thanks, > Marcin > Overall, depends on your design and scale. But, I will comment on a few of your items... We have RRs in the forwarding path but have a project to move them out in 2015. We feel it gives us more options as well as more flexibility when we move to the next phase of RR design (hierarchical). Most vendors today have the performance numbers (sometimes they aren't published publically) for routers acting as RRs. Ask your vendor and pick one that suits you. We generally buy the middle or most memory and pick a reasonable processor. And, then we monitor :) As for peer groups, you should have a design that allows you to herd most of the config snips together. Use the features that make your life easier and allow you to simplify your routing policies. tv From tvarriale at comcast.net Thu Jan 1 21:32:26 2015 From: tvarriale at comcast.net (Tony Varriale) Date: Thu, 01 Jan 2015 15:32:26 -0600 Subject: The state of TACACS+ In-Reply-To: <54A08C19.2090307@direcpath.com> References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: <54A5BCEA.4020800@comcast.net> On 12/28/2014 5:02 PM, Robert Drake wrote: > 3. authentication and authorization caching and/or something else Is this related to the TACACS server being down and the long time out to hit local authen/author? Sorry, a little late to this party :) tv From baldur.norddahl at gmail.com Thu Jan 1 21:37:25 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 1 Jan 2015 22:37:25 +0100 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A5BB44.9080208@comcast.net> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <54A5BB44.9080208@comcast.net> Message-ID: Is there a good reason to use actual router hardware for the route reflector role? Even a cheap server has more CPU and memory. If it is not in the forwarding path, this is a computing task - not a move packets at line speed task. Are anyone using Bird, Quagga etc. for this? Regards, Baldur From nick at foobar.org Thu Jan 1 22:09:36 2015 From: nick at foobar.org (Nick Hilliard) Date: Thu, 01 Jan 2015 22:09:36 +0000 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <54A5BB44.9080208@comcast.net> Message-ID: <54A5C5A0.3040506@foobar.org> On 01/01/2015 21:37, Baldur Norddahl wrote: > Are anyone using Bird, Quagga etc. for this? there are patches for both code-bases and some preliminary support for vpnv4 in quagga, but other than that neither currently supports either ldp or the vpnv4/vpnv6 address families in the main-line code. Nick From jeff.tantsura at ericsson.com Fri Jan 2 01:54:32 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Fri, 2 Jan 2015 01:54:32 +0000 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A5C5A0.3040506@foobar.org> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <54A5BB44.9080208@comcast.net> , <54A5C5A0.3040506@foobar.org> Message-ID: <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> You don't need LDP on RR as long as clients support "not on lsp" flag (different implementation have different names for it) There are more and more reasons to run RR on a non router HW, there are many reasons to still run commercial code base, mostly feature set and resilience. Regards, Jeff > On Jan 1, 2015, at 2:11 PM, Nick Hilliard wrote: > >> On 01/01/2015 21:37, Baldur Norddahl wrote: >> Are anyone using Bird, Quagga etc. for this? > > there are patches for both code-bases and some preliminary support for > vpnv4 in quagga, but other than that neither currently supports either ldp > or the vpnv4/vpnv6 address families in the main-line code. > > Nick > > From nanog at ics-il.net Fri Jan 2 01:57:41 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 1 Jan 2015 19:57:41 -0600 (CST) Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> Message-ID: <28791241.19480.1420163823876.JavaMail.mhammett@ThunderFuck> Running various functions on a couple small VM clusters makes a lot of sense. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Jeff Tantsura" To: "Nick Hilliard" Cc: nanog at nanog.org Sent: Thursday, January 1, 2015 7:54:32 PM Subject: Re: MPLS VPN design - RR in forwarding path? You don't need LDP on RR as long as clients support "not on lsp" flag (different implementation have different names for it) There are more and more reasons to run RR on a non router HW, there are many reasons to still run commercial code base, mostly feature set and resilience. Regards, Jeff > On Jan 1, 2015, at 2:11 PM, Nick Hilliard wrote: > >> On 01/01/2015 21:37, Baldur Norddahl wrote: >> Are anyone using Bird, Quagga etc. for this? > > there are patches for both code-bases and some preliminary support for > vpnv4 in quagga, but other than that neither currently supports either ldp > or the vpnv4/vpnv6 address families in the main-line code. > > Nick > > From cb.list6 at gmail.com Fri Jan 2 02:17:37 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 1 Jan 2015 18:17:37 -0800 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <28791241.19480.1420163823876.JavaMail.mhammett@ThunderFuck> References: <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> <28791241.19480.1420163823876.JavaMail.mhammett@ThunderFuck> Message-ID: On Thursday, January 1, 2015, Mike Hammett wrote: > Running various functions on a couple small VM clusters makes a lot of > sense. > > > I agree, it makes some sense, especially if you are control plane bound. But, nearly all my routers run between 1% and 10% cpu. Ymmv. I have feeling that running a bgp rr on cheap / standard / commidity vm is pretty exotic from a support perspective. So running a bgp rr on a vm may make sense in theory, but my network control planes are not too busy and vm bgp is a unique/ exotic support model. Your network is probably different > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Jeff Tantsura" > > To: "Nick Hilliard" > > Cc: nanog at nanog.org > Sent: Thursday, January 1, 2015 7:54:32 PM > Subject: Re: MPLS VPN design - RR in forwarding path? > > You don't need LDP on RR as long as clients support "not on lsp" flag > (different implementation have different names for it) > There are more and more reasons to run RR on a non router HW, there are > many reasons to still run commercial code base, mostly feature set and > resilience. > > Regards, > Jeff > > > On Jan 1, 2015, at 2:11 PM, Nick Hilliard > wrote: > > > >> On 01/01/2015 21:37, Baldur Norddahl wrote: > >> Are anyone using Bird, Quagga etc. for this? > > > > there are patches for both code-bases and some preliminary support for > > vpnv4 in quagga, but other than that neither currently supports either > ldp > > or the vpnv4/vpnv6 address families in the main-line code. > > > > Nick > > > > > > From marco at paesani.it Fri Jan 2 09:48:12 2015 From: marco at paesani.it (Marco Paesani) Date: Fri, 2 Jan 2015 10:48:12 +0100 Subject: Contact request OOKLA Speedtester Message-ID: Hi, I need direct contact off list please. Thanks ! Best regards, Marco Paesani M. +39 348 6019349 From andriy.bilous at gmail.com Fri Jan 2 10:16:26 2015 From: andriy.bilous at gmail.com (Andriy Bilous) Date: Fri, 2 Jan 2015 11:16:26 +0100 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A3E72F.20801@marcinkurek.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> Message-ID: Given that you assign unique RD per PE, RR out of the forwarding path provides you with a neat trick for fast convergence (and debugging purposes) when CE has redundant paths to different PEs. Routes to those CEs will be seen as different routes on RR. On Wed, Dec 31, 2014 at 1:08 PM, Marcin Kurek wrote: > Hi everyone, > > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path > - Use a high-end processor with maximum memory > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules still > apply to modern SP networks. > What would be the reasoning behind keeping RRs out of the forwarding path? > Is it only a matter of performance and stability? > > Thanks, > Marcin > From rjs at rob.sh Fri Jan 2 13:29:07 2015 From: rjs at rob.sh (Rob Shakir) Date: Fri, 2 Jan 2015 13:29:07 +0000 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <54A5BB44.9080208@comcast.net> <, > <54A5C5A0.3040506@foobar.org> <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> Message-ID: <7C3A6598-B4EB-44BA-BDC4-7EECB76DDD15@rob.sh> > On 2 Jan 2015, at 01:54, Jeff Tantsura wrote: > > You don't need LDP on RR as long as clients support "not on lsp" flag (different implementation have different names for it) > There are more and more reasons to run RR on a non router HW, there are many reasons to still run commercial code base, mostly feature set and resilience. And test coverage. As Saku alluded to earlier in the thread, rr<->rr-client outages are painful. I’ve certainly seen a number of them caused by inter-op issues between implementations. Running at least one RR which matches the code-base of the client means that at least you’re likely to have fallen within the test-cases of that vendor’s implementation. r. From jeff.tantsura at ericsson.com Fri Jan 2 17:33:34 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Fri, 2 Jan 2015 17:33:34 +0000 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <7C3A6598-B4EB-44BA-BDC4-7EECB76DDD15@rob.sh> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <54A5BB44.9080208@comcast.net> <,> <54A5C5A0.3040506@foobar.org> <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com>, <7C3A6598-B4EB-44BA-BDC4-7EECB76DDD15@rob.sh> Message-ID: +100 Regards, Jeff > On Jan 2, 2015, at 5:29 AM, Rob Shakir wrote: > > >> On 2 Jan 2015, at 01:54, Jeff Tantsura wrote: >> >> You don't need LDP on RR as long as clients support "not on lsp" flag (different implementation have different names for it) >> There are more and more reasons to run RR on a non router HW, there are many reasons to still run commercial code base, mostly feature set and resilience. > > And test coverage. As Saku alluded to earlier in the thread, rr<->rr-client outages are painful. I’ve certainly seen a number of them caused by inter-op issues between implementations. Running at least one RR which matches the code-base of the client means that at least you’re likely to have fallen within the test-cases of that vendor’s implementation. > > r. From cscora at apnic.net Fri Jan 2 18:11:39 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Jan 2015 04:11:39 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201501021811.t02IBdjm006407@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 03 Jan, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 524053 Prefixes after maximum aggregation (per Origin AS): 201599 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 256561 Total ASes present in the Internet Routing Table: 48968 Prefixes per ASN: 10.70 Origin-only ASes present in the Internet Routing Table: 36361 Origin ASes announcing only one prefix: 16299 Transit ASes present in the Internet Routing Table: 6217 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 100 Max AS path prepend of ASN ( 55644) 93 Prefixes from unregistered ASNs in the Routing Table: 1641 Unregistered ASNs in the Routing Table: 432 Number of 32-bit ASNs allocated by the RIRs: 8291 Number of 32-bit ASNs visible in the Routing Table: 6390 Prefixes from 32-bit ASNs in the Routing Table: 22960 Number of bogon 32-bit ASNs visible in the Routing Table: 11 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 396 Number of addresses announced to Internet: 2718618692 Equivalent to 162 /8s, 10 /16s and 212 /24s Percentage of available address space announced: 73.4 Percentage of allocated address space announced: 73.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 176798 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 129283 Total APNIC prefixes after maximum aggregation: 37681 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 134136 Unique aggregates announced from the APNIC address blocks: 54942 APNIC Region origin ASes present in the Internet Routing Table: 5007 APNIC Prefixes per ASN: 26.79 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table: 864 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 100 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1238 Number of APNIC addresses announced to Internet: 740595776 Equivalent to 44 /8s, 36 /16s and 152 /24s Percentage of available APNIC address space announced: 86.6 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, 131072-135580 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: 174308 Total ARIN prefixes after maximum aggregation: 86308 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 176223 Unique aggregates announced from the ARIN address blocks: 82419 ARIN Region origin ASes present in the Internet Routing Table: 16418 ARIN Prefixes per ASN: 10.73 ARIN Region origin ASes announcing only one prefix: 6066 ARIN Region transit ASes present in the Internet Routing Table: 1711 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 305 Number of ARIN addresses announced to Internet: 1055482112 Equivalent to 62 /8s, 233 /16s and 97 /24s Percentage of available ARIN address space announced: 55.8 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, 393216-394239 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: 125806 Total RIPE prefixes after maximum aggregation: 63668 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 131835 Unique aggregates announced from the RIPE address blocks: 82713 RIPE Region origin ASes present in the Internet Routing Table: 17829 RIPE Prefixes per ASN: 7.39 RIPE Region origin ASes announcing only one prefix: 8176 RIPE Region transit ASes present in the Internet Routing Table: 2927 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3315 Number of RIPE addresses announced to Internet: 692034180 Equivalent to 41 /8s, 63 /16s and 154 /24s Percentage of available RIPE address space announced: 100.6 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, 196608-202239 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: 59103 Total LACNIC prefixes after maximum aggregation: 10919 LACNIC Deaggregation factor: 5.41 Prefixes being announced from the LACNIC address blocks: 68106 Unique aggregates announced from the LACNIC address blocks: 31173 LACNIC Region origin ASes present in the Internet Routing Table: 2397 LACNIC Prefixes per ASN: 28.41 LACNIC Region origin ASes announcing only one prefix: 641 LACNIC Region transit ASes present in the Internet Routing Table: 481 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1450 Number of LACNIC addresses announced to Internet: 167434112 Equivalent to 9 /8s, 250 /16s and 215 /24s Percentage of available LACNIC address space announced: 99.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12442 Total AfriNIC prefixes after maximum aggregation: 2979 AfriNIC Deaggregation factor: 4.18 Prefixes being announced from the AfriNIC address blocks: 13357 Unique aggregates announced from the AfriNIC address blocks: 4958 AfriNIC Region origin ASes present in the Internet Routing Table: 727 AfriNIC Prefixes per ASN: 18.37 AfriNIC Region origin ASes announcing only one prefix: 201 AfriNIC Region transit ASes present in the Internet Routing Table: 152 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 82 Number of AfriNIC addresses announced to Internet: 60958976 Equivalent to 3 /8s, 162 /16s and 41 /24s Percentage of available AfriNIC address space announced: 60.6 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 4766 2942 11559 925 Korea Telecom 17974 2816 904 77 PT Telekomunikasi Indonesia 7545 2489 336 127 TPG Telecom Limited 4755 1928 418 190 TATA Communications formerly 4538 1758 4190 71 China Education and Research 9829 1638 1323 28 National Internet Backbone 9808 1516 6719 19 Guangdong Mobile Communicatio 4808 1456 2211 431 CNCGROUP IP network China169 9583 1314 106 538 Sify Limited 9498 1298 336 97 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 2920 2956 142 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2563 10700 474 Level 3 Communications, Inc. 18566 2042 379 183 MegaPath Corporation 20115 1854 1825 445 Charter Communications 4323 1629 1054 409 tw telecom holdings, inc. 6983 1624 867 245 EarthLink, Inc. 30036 1509 312 582 Mediacom Communications Corp 701 1411 11262 695 MCI Communications Services, 22561 1340 411 242 CenturyTel Internet Holdings, 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 34984 1924 299 354 TELLCOM ILETISIM HIZMETLERI A 20940 1529 597 1127 Akamai International B.V. 8402 1415 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 1036 97 54 TOV "Bank-Inform" 8551 906 373 48 Bezeq International-Ltd 9198 851 349 26 JSC Kazakhtelecom 6830 824 2340 444 Liberty Global Operations B.V 12479 819 794 85 France Telecom Espana SA 9121 598 1693 21 Turk Telekomunikasyon Anonim 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 3059 496 238 Telmex Colombia S.A. 28573 2308 2126 115 NET Servi�os de Comunica��o S 6147 1793 374 30 Telefonica del Peru S.A.A. 7303 1771 1172 237 Telecom Argentina S.A. 8151 1488 3052 433 Uninet S.A. de C.V. 6503 1227 417 57 Axtel, S.A.B. de C.V. 7738 1000 1882 42 Telemar Norte Leste S.A. 26615 930 2325 35 Tim Celular S.A. 3816 911 396 148 COLOMBIA TELECOMUNICACIONES S 27947 889 129 50 Telconet S.A 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 8452 1479 958 13 TE-AS 24863 950 284 26 Link Egypt (Link.NET) 36903 482 243 89 Office National des Postes et 36992 369 845 29 ETISALAT MISR 37492 347 145 64 Orange Tunisie 24835 308 144 9 Vodafone Data 3741 250 921 213 Internet Solutions 29571 234 21 12 Cote d'Ivoire Telecom 36947 192 807 13 Telecom Algeria 15706 176 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3059 496 238 Telmex Colombia S.A. 4766 2942 11559 925 Korea Telecom 22773 2920 2956 142 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 17974 2816 904 77 PT Telekomunikasi Indonesia 3356 2563 10700 474 Level 3 Communications, Inc. 7545 2489 336 127 TPG Telecom Limited 28573 2308 2126 115 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation 4755 1928 418 190 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2891 2840 BellSouth.net Inc. 22773 2920 2778 Cox Communications Inc. 17974 2816 2739 PT Telekomunikasi Indonesia 7545 2489 2362 TPG Telecom Limited 28573 2308 2193 NET Servi�os de Comunica��o S 3356 2563 2089 Level 3 Communications, Inc. 4766 2942 2017 Korea Telecom 18566 2042 1859 MegaPath Corporation 6147 1793 1763 Telefonica del Peru S.A.A. 4755 1928 1738 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 50309 UNALLOCATED 5.250.170.0/24 12714 Net By Net Holding L 50309 UNALLOCATED 5.250.174.0/24 12714 Net By Net Holding L 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 36270 UNALLOCATED 8.24.66.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 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:12 /10:31 /11:92 /12:265 /13:502 /14:998 /15:1727 /16:13049 /17:7172 /18:11949 /19:24845 /20:35605 /21:38150 /22:56453 /23:48993 /24:281241 /25:1123 /26:1089 /27:687 /28:17 /29:18 /30:10 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2135 2920 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1355 1509 Mediacom Communications Corp 6147 1337 1793 Telefonica del Peru S.A.A. 6983 1311 1624 EarthLink, Inc. 34984 1231 1924 TELLCOM ILETISIM HIZMETLERI A 11492 1116 1175 CABLE ONE, INC. 10620 1087 3059 Telmex Colombia S.A. 8402 1084 1415 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1406 2:672 3:3 4:95 5:1209 6:21 8:1412 11:1 12:1839 13:4 14:1212 15:17 16:2 17:45 18:21 20:51 23:1069 24:1666 27:1828 31:1464 32:39 33:2 34:5 36:136 37:1859 38:970 39:14 40:226 41:3000 42:286 43:827 44:21 45:86 46:2134 47:32 49:779 50:784 52:12 54:60 55:7 56:8 57:31 58:1092 59:657 60:451 61:1736 62:1289 63:1888 64:4404 65:2266 66:4071 67:2004 68:1030 69:3246 70:905 71:428 72:1959 74:2612 75:326 76:410 77:1363 78:1034 79:783 80:1327 81:1303 82:813 83:675 84:676 85:1324 86:387 87:1215 88:520 89:1799 90:139 91:5861 92:794 93:1666 94:1941 95:1406 96:422 97:337 98:1045 99:48 100:69 101:792 103:6409 104:949 105:90 106:198 107:893 108:608 109:2048 110:1049 111:1453 112:741 113:897 114:799 115:1233 116:1288 117:1016 118:1670 119:1367 120:436 121:991 122:2192 123:1711 124:1466 125:1510 128:637 129:360 130:381 131:1066 132:430 133:167 134:388 135:87 136:330 137:298 138:382 139:176 140:224 141:420 142:621 143:438 144:507 145:111 146:687 147:565 148:1061 149:407 150:535 151:590 152:467 153:247 154:292 155:662 156:408 157:333 158:264 159:957 160:369 161:632 162:1854 163:369 164:651 165:663 166:322 167:722 168:1158 169:132 170:1426 171:223 172:50 173:1564 174:702 175:596 176:1472 177:3687 178:2098 179:816 180:1846 181:1686 182:1688 183:537 184:727 185:2584 186:2943 187:1683 188:2006 189:1561 190:7886 191:838 192:7970 193:5554 194:4047 195:3629 196:1665 197:853 198:5424 199:5497 200:6539 201:2946 202:9472 203:9056 204:4692 205:2718 206:2990 207:2968 208:3907 209:3848 210:3491 211:1832 212:2531 213:2245 214:829 215:73 216:5516 217:1778 218:649 219:453 220:1319 221:776 222:458 223:645 End of report From mark.tinka at seacom.mu Fri Jan 2 18:19:23 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Jan 2015 20:19:23 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A5257F.1090300@marcinkurek.com> References: <54A3E6C7.7070406@gmail.com> <20141231170539.GL18618@angus.ind.WPI.EDU> <54A5257F.1090300@marcinkurek.com> Message-ID: <201501022019.26800.mark.tinka@seacom.mu> On Thursday, January 01, 2015 12:46:23 PM Marcin Kurek wrote: > I am also aware of products like vMX or CSR1000v/XRv and > the example given by Saku makes me more interested in > licensing/pricing options. Our network spans Africa, South Asia and Europe. We have 2x RR's in each PoP running Cisco's CSR1000v on x86_64 hardware under VMware ESXi. Pricing is not too bad; we use the Premium license which enables all features (BFD, e.t.c.) that you don't get with the Standard license. Been running this configuration since July 2014 - very happy. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Jan 2 18:22:17 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Jan 2015 20:22:17 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A5BB44.9080208@comcast.net> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <54A5BB44.9080208@comcast.net> Message-ID: <201501022022.17472.mark.tinka@seacom.mu> On Thursday, January 01, 2015 11:25:24 PM Tony Varriale wrote: > Most vendors today have the performance numbers > (sometimes they aren't published publically) for routers > acting as RRs. Ask your vendor and pick one that suits > you. We generally buy the middle or most memory and > pick a reasonable processor. And, then we monitor :) With the major vendors now offering VM-based RR's, I'd discourage using routers as RR's just for pure long-term scale. > As for peer groups, you should have a design that allows > you to herd most of the config snips together. Use the > features that make your life easier and allow you to > simplify your routing policies. Suffice it to say that the Peer Group functionality in IOS and IOS XE has largely been replaced by Update Groups. We use peer and session templates, but really, as with Peer Groups in 2015, it's just to keep things neat and tidy. Junos, of course, has its way forever which still works nicely. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Jan 2 18:24:05 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Jan 2015 20:24:05 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: References: <54A3E6C7.7070406@gmail.com> <54A5BB44.9080208@comcast.net> Message-ID: <201501022024.05478.mark.tinka@seacom.mu> On Thursday, January 01, 2015 11:37:25 PM Baldur Norddahl wrote: > Is there a good reason to use actual router hardware for > the route reflector role? Nope. It used to be code maturity - but major vendors are supporting service-grade code on VM's. > Even a cheap server has more > CPU and memory. If it is not in the forwarding path, > this is a computing task - not a move packets at line > speed task. Agree. > Are anyone using Bird, Quagga etc. for this? Wish I could - to be honest, these don't give me enough comfort for a production network. We use Quagga on FreeBSD for Anycast-this-&-that - from that experience, I'd not use it for backbone routing. YMMV. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Jan 2 18:24:48 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Jan 2015 20:24:48 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <54A5C5A0.3040506@foobar.org> References: <54A3E6C7.7070406@gmail.com> <54A5C5A0.3040506@foobar.org> Message-ID: <201501022024.48681.mark.tinka@seacom.mu> On Friday, January 02, 2015 12:09:36 AM Nick Hilliard wrote: > there are patches for both code-bases and some > preliminary support for vpnv4 in quagga, but other than > that neither currently supports either ldp or the > vpnv4/vpnv6 address families in the main-line code. LDP support would not be necessary for an out-of-path RR, but lack of VPNv4/VPNv6 is hurdle. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Jan 2 18:26:58 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Jan 2015 20:26:58 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> References: <54A3E6C7.7070406@gmail.com> <54A5C5A0.3040506@foobar.org> <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> Message-ID: <201501022026.58370.mark.tinka@seacom.mu> On Friday, January 02, 2015 03:54:32 AM Jeff Tantsura wrote: > You don't need LDP on RR as long as clients support "not > on lsp" flag (different implementation have different > names for it) The hack needed when running a Junos-based RR in an MPLS network to allow route reflection of l3vpn routes on an RR not running MPLS. For IOS and IOS XE (and IOS XR, I think), this wouldn't be needed as unlike Juniper, Cisco don't treat MPLS signaling protocols as (pseudo) routing protocols. > There are more and more reasons to run RR > on a non router HW, there are many reasons to still run > commercial code base, mostly feature set and resilience. +1. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Jan 2 18:27:43 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Jan 2015 20:27:43 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <28791241.19480.1420163823876.JavaMail.mhammett@ThunderFuck> References: <28791241.19480.1420163823876.JavaMail.mhammett@ThunderFuck> Message-ID: <201501022027.43631.mark.tinka@seacom.mu> On Friday, January 02, 2015 03:57:41 AM Mike Hammett wrote: > Running various functions on a couple small VM clusters > makes a lot of sense. We treat our CSR1000v RR's as dedicated islands. No other functions run on them, nor do we cluster them. Don't want what fun could arise :-)... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Jan 2 18:30:37 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Jan 2015 20:30:37 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: References: <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> <28791241.19480.1420163823876.JavaMail.mhammett@ThunderFuck> Message-ID: <201501022030.37944.mark.tinka@seacom.mu> On Friday, January 02, 2015 04:17:37 AM Ca By wrote: > Ymmv. I have feeling that running a bgp rr on cheap / > standard / commidity vm is pretty exotic from a support > perspective. Not really. Since July last year. The worst I've had was the HP server shutting down in a London data centre due to environmental overheating. Beyond that, similar requirements as with a router, if you avoid the VM clustering goodness they all preach. > So running a bgp rr on a vm may make sense in theory, but > my network control planes are not too busy and vm bgp is > a unique/ exotic support model. Amongst very many other things, running an RR on my core router means I need to touch my core router code if I want that exotic routing feature. I'd rather not, if my core router (in-path) is really just forwarding traffic between PoP's. But agree, our networks are probably quite different :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Jan 2 18:31:20 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Jan 2015 20:31:20 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> Message-ID: <201501022031.20927.mark.tinka@seacom.mu> On Friday, January 02, 2015 12:16:26 PM Andriy Bilous wrote: > Given that you assign unique RD per PE, RR out of the > forwarding path provides you with a neat trick for fast > convergence (and debugging purposes) when CE has > redundant paths to different PEs. Routes to those CEs > will be seen as different routes on RR. Not having to dump routes into FIB *really* speeds up convergence. It's not even funny :-)... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bryan at digitalocean.com Fri Jan 2 19:10:32 2015 From: bryan at digitalocean.com (Bryan Socha) Date: Fri, 2 Jan 2015 14:10:32 -0500 Subject: Level3 Contact - Non-customer Message-ID: Does anyone have a contact for Level3 if you are a not a customer or can someone from level3 please contact me off list. We're seeing and issue with blocked subnets. All of their public addresses are being replied to with "log into the portal, open a customer ticket". Thanks, Bryan Socha Network Engineer DigitalOcean From nick at foobar.org Fri Jan 2 19:45:01 2015 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Jan 2015 19:45:01 +0000 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <201501022024.05478.mark.tinka@seacom.mu> References: <54A3E6C7.7070406@gmail.com> <54A5BB44.9080208@comcast.net> <201501022024.05478.mark.tinka@seacom.mu> Message-ID: <54A6F53D.3060201@foobar.org> On 02/01/2015 18:24, Mark Tinka wrote: > Wish I could - to be honest, these don't give me enough > comfort for a production network. It's not even possible for a vpn enabled network right now. Having said that, I use bird in anger for ixp route server functionality (i.e. ebgp route reflector) and have nothing but good to say about it. Quagga can be, uh, more temperamental. Nick From nick at foobar.org Fri Jan 2 19:50:29 2015 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Jan 2015 19:50:29 +0000 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: References: <3741D057-5B39-4817-867B-20A1FBBB5586@ericsson.com> <28791241.19480.1420163823876.JavaMail.mhammett@ThunderFuck> Message-ID: <54A6F685.8020500@foobar.org> On 02/01/2015 02:17, Ca By wrote: > I agree, it makes some sense, especially if you are control plane bound. > But, nearly all my routers run between 1% and 10% cpu. 1% and 10% on what will generally be older, slower cpus. Modern servers have significantly faster CPUs than any RE/RP on the market, so you will see a benefit in terms of convergence speed by using virtualisation. > Ymmv. I have feeling that running a bgp rr on cheap / standard / commidity > vm is pretty exotic from a support perspective. not really, no. Standalone hypervisors are stable, predictable and easy to manage. They're also commercially supported and most companies these days have a good deal of internal experience in dealing with them. As Mark commented separately, you would need your head examined if you plan to enable hypervisor clustering for this sort of thing. Nick > So running a bgp rr on a vm may make sense in theory, but my network > control planes are not too busy and vm bgp is a unique/ exotic support > model. > > Your network is probably different > > >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Jeff Tantsura" > >> To: "Nick Hilliard" > >> Cc: nanog at nanog.org >> Sent: Thursday, January 1, 2015 7:54:32 PM >> Subject: Re: MPLS VPN design - RR in forwarding path? >> >> You don't need LDP on RR as long as clients support "not on lsp" flag >> (different implementation have different names for it) >> There are more and more reasons to run RR on a non router HW, there are >> many reasons to still run commercial code base, mostly feature set and >> resilience. >> >> Regards, >> Jeff >> >>> On Jan 1, 2015, at 2:11 PM, Nick Hilliard > > wrote: >>> >>>> On 01/01/2015 21:37, Baldur Norddahl wrote: >>>> Are anyone using Bird, Quagga etc. for this? >>> >>> there are patches for both code-bases and some preliminary support for >>> vpnv4 in quagga, but other than that neither currently supports either >> ldp >>> or the vpnv4/vpnv6 address families in the main-line code. >>> >>> Nick >>> >>> >> >> From drohan at gmail.com Fri Jan 2 21:03:21 2015 From: drohan at gmail.com (Daniel Rohan) Date: Fri, 2 Jan 2015 13:03:21 -0800 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: <694A65FF-37EC-40F5-921F-377E88AA6BCF@ericsson.com> References: <54A3E6C7.7070406@gmail.com> <54A3E72F.20801@marcinkurek.com> <20141231170539.GL18618@angus.ind.WPI.EDU> <694A65FF-37EC-40F5-921F-377E88AA6BCF@ericsson.com> Message-ID: On Wed, Dec 31, 2014 at 11:14 AM, Jeff Tantsura wrote: > Keep in mind - some architectures, such as seamless MPLS would require a > RR to be in the fast path. > +1 Also think physical topologies like ethernet rings. Where's the RR go in this topology? -Dan From cidr-report at potaroo.net Fri Jan 2 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Jan 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201501022200.t02M00Fq047646@wattle.apnic.net> This report has been generated at Fri Jan 2 21:14:20 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 26-12-14 529668 293468 27-12-14 529797 293731 28-12-14 529713 293924 29-12-14 529791 292319 30-12-14 529929 291995 31-12-14 529985 291981 01-01-15 529871 291855 02-01-15 529540 291901 AS Summary 49250 Number of ASes in routing system 19745 Number of ASes announcing only one prefix 3060 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120376832 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 02Jan15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 529654 291913 237741 44.9% All ASes AS6389 2890 69 2821 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2922 173 2749 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2816 77 2739 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS28573 2308 307 2001 86.7% NET Servi�os de Comunica��o S.A.,BR AS3356 2631 770 1861 70.7% LEVEL3 - Level 3 Communications, Inc.,US AS4755 1927 285 1642 85.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2942 1303 1639 55.7% KIXS-AS-KR Korea Telecom,KR AS6147 1793 170 1623 90.5% Telefonica del Peru S.A.A.,PE AS7303 1772 289 1483 83.7% Telecom Argentina S.A.,AR AS10620 3060 1588 1472 48.1% Telmex Colombia S.A.,CO AS9808 1515 56 1459 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1411 26 1385 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1855 526 1329 71.6% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2502 1272 1230 49.2% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1637 411 1226 74.9% TWTC - tw telecom holdings, inc.,US AS9498 1298 111 1187 91.4% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2041 868 1173 57.5% MEGAPATH5-US - MegaPath Corporation,US AS7552 1131 57 1074 95.0% VIETEL-AS-AP Viettel Corporation,VN AS22561 1340 266 1074 80.1% AS22561 - CenturyTel Internet Holdings, Inc.,US AS34984 1925 868 1057 54.9% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS6983 1624 617 1007 62.0% ITCDELTA - Earthlink, Inc.,US AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1775 907 868 48.9% ERX-CERNET-BKB China Education and Research Network Center,CN AS31148 1045 190 855 81.8% FREENET-AS Freenet Ltd.,UA AS24560 1179 374 805 68.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS8151 1493 697 796 53.3% Uninet S.A. de C.V.,MX AS18881 856 65 791 92.4% Global Village Telecom,BR AS26615 930 142 788 84.7% Tim Celular S.A.,BR AS4780 1066 305 761 71.4% SEEDNET Digital United Inc.,TW Total 53667 12986 40681 75.8% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 43.245.196.0/24 AS36352 AS-COLOCROSSING - ColoCrossing,US 43.245.197.0/24 AS55286 SERVER-MANIA - B2 Net Solutions Inc.,US 45.61.16.0/20 AS53828 NITEL - NETWORK INNOVATIONS, INC.,US 45.61.64.0/18 AS62874 WEB2OBJECTS-LLC - Web2Objects LLC,US 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 64.247.224.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 69.2.64.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 69.172.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 72.12.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.32.0.0/16 AS20150 SKY-CAPITAL Sky Capital Investments Ltd.,DE 102.39.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.108.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.201.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.242.0.0/16 AS20150 SKY-CAPITAL Sky Capital Investments Ltd.,DE 103.1.155.0/24 AS55799 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.124.0/24 AS45355 DIGICELPACIFIC-1-AP Clarendon House,FJ 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.231.251.0/24 AS13316 103.232.28.0/23 AS13316 103.232.28.0/24 AS13316 103.243.72.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.243.73.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.243.74.0/23 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.105.0/24 AS13316 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 154.134.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.211.192.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 186.65.108.0/22 AS22927 Telefonica de Argentina,AR 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS3322 -Reserved AS-,ZZ 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.64.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.18.0/24 AS33790 -Reserved AS-,ZZ 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.61.108.0/24 AS55812 202.61.118.0/24 AS55833 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 208.115.0.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.159.32.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.83.224.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.107.64.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.219.0.0/18 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.231.96.0/19 AS7029 WINDSTREAM - Windstream Communications Inc,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 2 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Jan 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201501022200.t02M02nD047663@wattle.apnic.net> BGP Update Report Interval: 25-Dec-14 -to- 01-Jan-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8888 821079 16.6% 68423.2 -- RUSERVICE-LLC-AS LLC RU-service,RU 2 - AS13105 350358 7.1% 15233.0 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 3 - AS23752 282375 5.7% 2031.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - AS9829 155694 3.1% 93.1 -- BSNL-NIB National Internet Backbone,IN 5 - AS53249 79833 1.6% 39916.5 -- LAWA-AS - Los Angeles World Airport,US 6 - AS36947 44151 0.9% 218.6 -- ALGTEL-AS,DZ 7 - AS3 42234 0.8% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - AS38197 32173 0.7% 27.8 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 9 - AS10620 29823 0.6% 9.7 -- Telmex Colombia S.A.,CO 10 - AS60725 29341 0.6% 1630.1 -- O3B-AS O3b Limited,JE 11 - AS42456 28956 0.6% 2632.4 -- CHMURTZ-AS CHMURTZ SARL,FR 12 - AS51964 28201 0.6% 59.0 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 13 - AS7162 27074 0.6% 338.4 -- Universo Online S.A.,BR 14 - AS17974 26257 0.5% 9.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 15 - AS45899 25780 0.5% 48.2 -- VNPT-AS-VN VNPT Corp,VN 16 - AS2 24821 0.5% 250.0 -- UDEL-DCN - University of Delaware,US 17 - AS36691 23100 0.5% 11550.0 -- CSUP-AS - Colorado State University-Pueblo,US 18 - AS18399 22856 0.5% 1269.8 -- YTCL-AS-AP Yatanarpon Teleport Company Limited,MM 19 - AS11054 22677 0.5% 629.9 -- LIVEPERSON - LivePerson, Inc.,US 20 - AS23342 21090 0.4% 540.8 -- UNITEDLAYER - Unitedlayer, Inc.,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8888 821079 16.6% 68423.2 -- RUSERVICE-LLC-AS LLC RU-service,RU 2 - AS53249 79833 1.6% 39916.5 -- LAWA-AS - Los Angeles World Airport,US 3 - AS61039 16726 0.3% 16726.0 -- ZMZ OAO ZMZ,RU 4 - AS13105 350358 7.1% 15233.0 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 5 - AS3 42234 0.8% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 6 - AS36691 23100 0.5% 11550.0 -- CSUP-AS - Colorado State University-Pueblo,US 7 - AS3 7718 0.2% 246.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - AS58252 7222 0.1% 7222.0 -- ASN-RINGLOUD Netuity Limited,GB 9 - AS62174 5811 0.1% 5811.0 -- INTERPAN-AS INTERPAN LTD.,BG 10 - AS33721 4422 0.1% 4422.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 11 - AS31860 3008 0.1% 3008.0 -- MACKAY-SHIELDS - MacKay Shields LLC,US 12 - AS42456 28956 0.6% 2632.4 -- CHMURTZ-AS CHMURTZ SARL,FR 13 - AS52789 2630 0.1% 2630.0 -- SILVA NET PROVEDOR DE INTERNET LTDA,BR 14 - AS23752 282375 5.7% 2031.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 15 - AS47680 9769 0.2% 1953.8 -- NHCS EOBO Limited,IE 16 - AS3 1935 0.0% 1445.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 17 - AS60737 7511 0.1% 1877.8 -- NEURONESIT NEURONESIT,FR 18 - AS60725 29341 0.6% 1630.1 -- O3B-AS O3b Limited,JE 19 - AS45606 8025 0.2% 1605.0 -- 20 - AS51363 2802 0.1% 1401.0 -- TELEPATIYA-NET Telepatiya Ltd.,KZ TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 212.22.94.0/24 410720 8.1% AS8888 -- RUSERVICE-LLC-AS LLC RU-service,RU 2 - 212.22.80.0/24 410138 8.1% AS8888 -- RUSERVICE-LLC-AS LLC RU-service,RU 3 - 202.70.88.0/21 141463 2.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 202.70.64.0/21 138919 2.7% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 5 - 82.118.158.0/23 71540 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 6 - 82.118.146.0/23 70924 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 7 - 95.171.242.0/23 69812 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 8 - 95.171.236.0/23 69014 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 9 - 95.171.242.0/24 68980 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 10 - 130.0.192.0/21 42230 0.8% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 11 - 198.140.115.0/24 39940 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 12 - 198.140.114.0/24 39893 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 13 - 41.221.20.0/24 38530 0.8% AS36947 -- ALGTEL-AS,DZ 14 - 64.29.130.0/24 20768 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 15 - 192.115.44.0/22 20095 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 16 - 91.235.169.0/24 16726 0.3% AS61039 -- ZMZ OAO ZMZ,RU 17 - 162.249.183.0/24 14926 0.3% AS60725 -- O3B-AS O3b Limited,JE 18 - 185.26.155.0/24 14397 0.3% AS60725 -- O3B-AS O3b Limited,JE 19 - 192.55.229.0/24 11561 0.2% AS36691 -- CSUP-AS - Colorado State University-Pueblo,US 20 - 158.142.0.0/16 11539 0.2% AS36691 -- CSUP-AS - Colorado State University-Pueblo,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mawatari at jpix.ad.jp Sun Jan 4 03:23:08 2015 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Sun, 04 Jan 2015 12:23:08 +0900 Subject: JANOG 35 meeting agenda Message-ID: <20150104122306.6063.8FE1F57E@jpix.ad.jp> Hi all, JANOG 35 meeting will hold in Shizuoka City, Japan on January 14-16, 2015, hosted by Fujinokuni Information Network Organization. JANOG 35 meeting agenda is available at the following site. http://www.janog.gr.jp/en/index.php?JANOG35_Meeting%2FJANOG35_Program_Contents Registration close: (close registration soon!) Conference: January 8, 2015 3:00 [UTC] Banquet: January 5, 2015 3:00 [UTC] https://regist.e-side.co.jp/product_info.php?products_id=500&language=en The survey will remain open until 14:59 Fri 9 Jan [UTC] for the IPv6 session. https://www.janog.gr.jp/meeting/janog35/program/ipv6/ipv6_form_en/ Thank you for your cooperation! -- Japan Internet Exchange MAWATARI Masataka From symack at gmail.com Sun Jan 4 03:50:16 2015 From: symack at gmail.com (symack) Date: Sat, 3 Jan 2015 22:50:16 -0500 Subject: Fibre Channel Network Message-ID: Hello Everyone, Have a few FC cards and a switch that I would like to use for backplane related packets (ie, local network). I am totally new to FC and would like to know will I need a router to be able to communicate between the nodes? What I plan on doing is connecting the network card to the FC switch. Thanks in Advance, Nick. From rs at seastrom.com Sun Jan 4 13:02:31 2015 From: rs at seastrom.com (Rob Seastrom) Date: Sun, 04 Jan 2015 08:02:31 -0500 Subject: Fibre Channel Network In-Reply-To: (symack@gmail.com's message of "Sat, 3 Jan 2015 22:50:16 -0500") References: Message-ID: <868uhiaec8.fsf@valhalla.seastrom.com> symack writes: > Hello Everyone, > > Have a few FC cards and a switch that I would like to use for backplane > related packets (ie, local network). I am totally new to FC and would like > to know will I need a router to be able to communicate between the nodes? > What I plan on doing is connecting the network card to the FC switch. > > Thanks in Advance, > > Nick. Classic FC is not "routed" in the sense that you're used to from IP, although there is a component in the control plane of every FC switch called a "router", which is perhaps where the confusion comes from (the other three, FWIW, are address manager, fabric controller, and path selector). To answer the implied question, yes you can just plug them into the switch (some configuration will almost certainly be required). You can also do a point to point connection between two FC devices ("back to back" as it were). The way we used to do it back in the old days before switches was an arbitrated loop; in fact I still can't think FC without thinking FC-AL. -r From ag4ve.us at gmail.com Mon Jan 5 02:36:09 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 4 Jan 2015 21:36:09 -0500 Subject: Fibre Channel Network In-Reply-To: <868uhiaec8.fsf@valhalla.seastrom.com> References: <868uhiaec8.fsf@valhalla.seastrom.com> Message-ID: On Jan 4, 2015 8:04 AM, "Rob Seastrom" wrote: > > > symack writes: > > > Hello Everyone, > > > > Have a few FC cards and a switch that I would like to use for backplane > > related packets (ie, local network). I am totally new to FC and would like > > to know will I need a router to be able to communicate between the nodes? > > What I plan on doing is connecting the network card to the FC switch. > > > > Thanks in Advance, > > > > Nick. > > Classic FC is not "routed" in the sense that you're used to from IP, > although there is a component in the control plane of every FC switch > called a "router", which is perhaps where the confusion comes from > (the other three, FWIW, are address manager, fabric controller, and > path selector). > > To answer the implied question, yes you can just plug them into the > switch (some configuration will almost certainly be required). You > can also do a point to point connection between two FC devices ("back > to back" as it were). The way we used to do it back in the old days > before switches was an arbitrated loop; in fact I still can't think FC > without thinking FC-AL. > If you have a tcpip FC driver for your OS (I think Linux and BSD do - not sure about OSX or Windows). And I'm pretty sure you can make your switch look essentially like an ethernet hub but idk you're going to be able to get it to separate domains - node 1 sends to 5 as node 4 sends to 3 will not all send at 8gig or w/e fabric speed is - it's degraded because everyone is seeing each other's WWN and data. All nodes will see all traffic unless you configure a static path - 1 to 5 and 3 to 4 - you could also do an ndmp type config of 1 to 3 but idk how many of these you can have and I'm pretty sure 5 still sees 3's data. Also note that just because you have the hardware don't mean you have the license to use it. In most cases the licenses are pretty easy to hack and you can 'pirate' to make this work (and no one will care since you're an individual). But just pointing out another issue you might see Ps - it's been years since I touched one of these things so I might be mis-remembering some points but FWIW. From mcn4 at leicester.ac.uk Mon Jan 5 12:46:59 2015 From: mcn4 at leicester.ac.uk (Matthew Newton) Date: Mon, 5 Jan 2015 12:46:59 +0000 Subject: The state of TACACS+ In-Reply-To: References: <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> <54A08C19.2090307@direcpath.com> Message-ID: <20150105124659.GA11965@rootmail.cc.le.ac.uk> On Mon, Dec 29, 2014 at 04:25:56PM +0900, Randy Bush wrote: > > Rfc6613: TLS or IPsec transport is shown as mandatory for RADIUS over TCP. > > sweet. can you ref conforming implementations? FreeRADIUS and Radiator can do RADSEC, as well as radsecproxy, so it can be used to protect e.g. site-to-site proxying. I don't know whether any switches/NASes can do it at present, though. Matthew -- Matthew Newton, Ph.D. Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, From jtk at cymru.com Mon Jan 5 14:40:52 2015 From: jtk at cymru.com (John Kristoff) Date: Mon, 5 Jan 2015 08:40:52 -0600 Subject: How our young colleagues are being educated.... In-Reply-To: <549CAA0E.5080406@meetinghouse.net> References: <549CAA0E.5080406@meetinghouse.net> Message-ID: <20150105084052.08116134@localhost> On Thu, 25 Dec 2014 19:21:34 -0500 Miles Fidelman wrote: > Cisco as the basis of networking material? Does nobody use Comer, > Stallings, or Tannenbaum as basic texts anymore? I currently use a Comer book. I've also used a Tannenbaum book in the past, but not recently. My favorite book, when I've used it was Radia Perlman's. Increasingly I'm seeing a trend away from actually relying on books if even requiring them to be read anymore. This is both a trend with faculty and students. I frequently get asked if the book is required, even when the course page clearly says it is. Students and often faculty often I find rely too heavily on Wikipedia pages, which I've found myself going to update since they lead to wrong assumptions and answers in questions I've assigned. I like to augment, as many faculty do, classic or timely research papers into assignments so that students are at least forced to look at something other than vendor white papers and blog posts found in search engines. John From jtk at cymru.com Mon Jan 5 17:28:00 2015 From: jtk at cymru.com (John Kristoff) Date: Mon, 5 Jan 2015 11:28:00 -0600 Subject: Charter ARP Leak In-Reply-To: <17490863.756.1419881036436.JavaMail.root@benjamin.baylink.com> References: <54A195D4.4000503@davidcoulson.net> <17490863.756.1419881036436.JavaMail.root@benjamin.baylink.com> Message-ID: <20150105112800.7a934aef@localhost> On Mon, 29 Dec 2014 14:23:56 -0500 (EST) Jay Ashworth wrote: > From an intermediate routing standpoint, though, it would be easier > to add an *adjacent* block, not one halfway across the address space, > no? One never knows how the address space is carved up. Changing what were once deemed reasonable addressing ideas, ultimately becoming grossly suboptimal, often loses out to competing interests. A long time ago, I arrived at a network where there were two major sites with many LANs at each site. Generally speaking each LAN was a department, but a department spanned both sites. Each department/LAN at a site started off with less than a /25 worth of nodes. This was apparently all done at a time when RIPv1 was the norm and multiple subnet sizes were not widely deployed if even available in the gear deployed. The arrangement I inherited was such that a department was assiged a /24, with the lower half (a /25) network at one site, and the upper half at the other. As long as the organization's assigned /16 always used /25's per network and departments split between sites fit into the /25 things might have been fine for awhile. By the time I arrived the address space was impossibly fragmented with some router interfaces having many secondaries as departments arose, grew, split, ceased to exist and new sites came online. This had the now predictable effect of turning a seemingly nice day one addressing plan into a fragmented and secondary mess. That was over 15 years ago and there are still remnants of the originally addressing plan in place. I wouldn't be too surprised or even too concerned about these sorts of configurations that appear poorly designed in hindsight. They are natural for most any complex system as it evolves. It is all part of the fun. John From dmburgess at linktechs.net Mon Jan 5 18:53:45 2015 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 5 Jan 2015 12:53:45 -0600 Subject: Windstream BGP admin Message-ID: <674E0B100B12BC41BEC7873AFD8B690013DEF7@03-exchange.lti.local> Got a change in windtream routing, massively down since the 23rd out of denver, any Windstream admin want to shoot me a e-mail and talk J Thanks, www.linktechs.net - 314-735-0270 - dmburgess at linktechs.net From symack at gmail.com Tue Jan 6 18:56:52 2015 From: symack at gmail.com (symack) Date: Tue, 6 Jan 2015 13:56:52 -0500 Subject: Fibre Channel Network In-Reply-To: References: <868uhiaec8.fsf@valhalla.seastrom.com> Message-ID: Hello Everyone, We are using Myricom 2000: M3F-PCIXF-2 Network Card ( http://www.myricom.com/scs/myrinet/PCIX/m3f-pcixf.html) M3F-SW8 Switch (http://www.myricom.com/scs/myrinet/product_list.html) The driver we are planning to use is coming directly from Myrinet (ie, MX-2G) driver. Plugged a card in and installed a driver just for curiosity, and can ping itself. Waiting on the rest of the hardware and hope I can ping other nodes. The plan is to have this network as 100% internal backbone connected to the NAS. Hope this works...... ​Kind Regards, Nick. From web at typo.org Tue Jan 6 19:20:05 2015 From: web at typo.org (Wayne E Bouchard) Date: Tue, 6 Jan 2015 12:20:05 -0700 Subject: How our young colleagues are being educated.... In-Reply-To: <20150105084052.08116134@localhost> References: <549CAA0E.5080406@meetinghouse.net> <20150105084052.08116134@localhost> Message-ID: <20150106192005.GA39699@wakko.typo.org> On Mon, Jan 05, 2015 at 08:40:52AM -0600, John Kristoff wrote: > On Thu, 25 Dec 2014 19:21:34 -0500 > Miles Fidelman wrote: > > > Cisco as the basis of networking material? Does nobody use Comer, > > Stallings, or Tannenbaum as basic texts anymore? > > I currently use a Comer book. I've also used a Tannenbaum book in the > past, but not recently. My favorite book, when I've used it was Radia > Perlman's. > > Increasingly I'm seeing a trend away from actually relying on books if > even requiring them to be read anymore. This is both a trend with > faculty and students. I frequently get asked if the book is required, > even when the course page clearly says it is. Students and often > faculty often I find rely too heavily on Wikipedia pages, which I've > found myself going to update since they lead to wrong assumptions and > answers in questions I've assigned. > > I like to augment, as many faculty do, classic or timely research papers > into assignments so that students are at least forced to look at > something other than vendor white papers and blog posts found in search > engines. > > John Then again, no course on networking can be complete without a presentation involving ways in which things are not being used as originally designed because someone had an idea of how they could do it differently, for better or worse. (Ala the contradiction in terms that is "HTTP streaming". Routers two continents away crashing as a result of eBGP packets for interprovider VPNs is another good one.) Nor can you call a course complete without a case study of where things do not work as intended and either very large pFail is the result or where a more complicated hack fix is needed as a workaround. Especially relevant with interoperability concerns when multiple vendors are involved. Those sorts of things you likewise do not often find in text books or white papers and probably not on Wikipedia either but they are at the core of what engineering and operations has contend with day by day. (Too often people conflate "engineering" with "architecture" and while they are very much related, they are not one and the same.) -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From bob at FiberInternetCenter.com Tue Jan 6 20:37:15 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 6 Jan 2015 12:37:15 -0800 Subject: Office 365 Expert - I am not. I have a customer that... Message-ID: I have a customer that heavily uses Microsoft Office 365. It's hosted. All the data I see about usage per user appears theoretical. In that the formulas assume people are taking turns using the bandwidth as if there is a patient line of packets at the Internet gas pump. Nobody is clicking at the same time. We all know that is not the real world. Does anyone have any experience with Office 365 hosted that can tell me the practical bandwidth allocation (NOT in KB per month, but in megabits/sec) for 100 users (during normal work hours) needs to be available ? Thank You in advance, Bob Evans CTO Fiber Internet Center From rhirst at xkl.com Tue Jan 6 20:49:59 2015 From: rhirst at xkl.com (Roy Hirst) Date: Tue, 06 Jan 2015 12:49:59 -0800 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: References: Message-ID: <54AC4A77.2080603@xkl.com> I know there is no such thing as a patient line of packets. There was recently some research done on feedback from big early adopters (hosts) that I will try to dig out if you need it. I remember that (1) user-to-data center bandwidth is much less than the resulting in-data-center bandwidth or dc-dc bandwidth (2) there are some useful metrics (ratios) for estimating bandwidth if you know the workload server GHz, installations need balance (3) Many (most?) estimates underestimate fiber bandwidth actual requirements. Roy **Roy Hirst* 425-556-5773 XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA * On 1/6/2015 12:37 PM, Bob Evans wrote: > I have a customer that heavily uses Microsoft Office 365. It's hosted. All > the data I see about usage per user appears theoretical. In that the > formulas assume people are taking turns using the bandwidth as if there is > a patient line of packets at the Internet gas pump. Nobody is clicking at > the same time. We all know that is not the real world. > > Does anyone have any experience with Office 365 hosted that can tell me > the practical bandwidth allocation (NOT in KB per month, but in > megabits/sec) for 100 users (during normal work hours) needs to be > available ? > > Thank You in advance, > Bob Evans > CTO Fiber Internet Center > > > > > From rhirst at xkl.com Tue Jan 6 21:27:43 2015 From: rhirst at xkl.com (Roy Hirst) Date: Tue, 06 Jan 2015 13:27:43 -0800 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: <54AC4A77.2080603@xkl.com> References: <54AC4A77.2080603@xkl.com> Message-ID: <54AC534F.2020403@xkl.com> I found both these useful, all credit to the authors: Application-Driven Bandwidth Guarantees in Data Centers www.hpl.hp.com/people/jklee/Sigcomm14-CloudMirror.pdf Surviving failures in Bandwidth-Constrained Datacenters http://research.microsoft.com/pubs/167565/fp285-bodikPS.pdf Roy **Roy Hirst* 425-556-5773 XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA * On 1/6/2015 12:49 PM, Roy Hirst wrote: > I know there is no such thing as a patient line of packets. > There was recently some research done on feedback from big early > adopters (hosts) that I will try to dig out if you need it. > I remember that (1) user-to-data center bandwidth is much less than > the resulting in-data-center bandwidth or dc-dc bandwidth (2) there > are some useful metrics (ratios) for estimating bandwidth if you know > the workload server GHz, installations need balance (3) Many (most?) > estimates underestimate fiber bandwidth actual requirements. > Roy > > **Roy Hirst* 425-556-5773 > XKL LLC | 12020 113th Ave NE, Suite 100 | Kirkland, WA 98034 | USA > > * > On 1/6/2015 12:37 PM, Bob Evans wrote: >> I have a customer that heavily uses Microsoft Office 365. It's >> hosted. All >> the data I see about usage per user appears theoretical. In that the >> formulas assume people are taking turns using the bandwidth as if >> there is >> a patient line of packets at the Internet gas pump. Nobody is >> clicking at >> the same time. We all know that is not the real world. >> >> Does anyone have any experience with Office 365 hosted that can tell me >> the practical bandwidth allocation (NOT in KB per month, but in >> megabits/sec) for 100 users (during normal work hours) needs to be >> available ? >> >> Thank You in advance, >> Bob Evans >> CTO Fiber Internet Center >> >> >> >> >> From dwessels at verisign.com Wed Jan 7 00:24:20 2015 From: dwessels at verisign.com (Wessels, Duane) Date: Wed, 7 Jan 2015 00:24:20 +0000 Subject: DNS Track at NANOG 63 Message-ID: Dear DNS Community, I will be moderating a DNS Track at the NANOG 63 meeting in San Antonio, TX. If you have interesting and timely DNS-related material to share with operators and researchers please reply to me with a brief abstract or description. I'm expecting we'll have about 90 minutes and plan to allocate 10-15 minutes per presenter. Apologies if you receive multiple copies. Duane W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From refresh.lsong at gmail.com Wed Jan 7 13:35:35 2015 From: refresh.lsong at gmail.com (Song Li) Date: Wed, 07 Jan 2015 21:35:35 +0800 Subject: something strange about bgp community Message-ID: <54AD3627.7020006@gmail.com> Hi everyone, Today when I check one route in Routeviews I find something strange as follows: route-views>sh ip bgp 176.108.0.0 BGP routing table entry for 176.108.0.0/19, version 23405621 Paths: (33 available, best #28, table default) Not advertised to any peer Refresh Epoch 1 202018 35320 35320 57800 5.101.110.2 from 5.101.110.2 (5.101.110.2) Origin IGP, localpref 100, valid, external Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 20485:54050 47541:10001 rx pathid: 0, tx pathid: 0 the AS-Path is "202018 35320 35320 57800" but the community is 702:120 2914:429 20485:52990 .... According to RFC 1997, the community format is AA:NN and AA means the AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and as a result they should not appear in the community. Could anybody tell me what's the reason they do appear in the community of this route? Thanks! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From jared at puck.nether.net Wed Jan 7 14:29:36 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 7 Jan 2015 06:29:36 -0800 Subject: something strange about bgp community In-Reply-To: <54AD3627.7020006@gmail.com> References: <54AD3627.7020006@gmail.com> Message-ID: 2914:429 is a community to signal to NTT to not announce the route to peers which would perhaps be why you don't see NTT doing that. You can see the documented NTT communities here: http://www.us.ntt.net/support/policy/routing.cfm Jared Mauch > On Jan 7, 2015, at 5:35 AM, Song Li wrote: > > Hi everyone, > > Today when I check one route in Routeviews I find something strange as follows: > > route-views>sh ip bgp 176.108.0.0 > BGP routing table entry for 176.108.0.0/19, version 23405621 > Paths: (33 available, best #28, table default) > Not advertised to any peer > Refresh Epoch 1 > 202018 35320 35320 57800 > 5.101.110.2 from 5.101.110.2 (5.101.110.2) > Origin IGP, localpref 100, valid, external > Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 20485:54050 47541:10001 > rx pathid: 0, tx pathid: 0 > > the AS-Path is "202018 35320 35320 57800" but the community is 702:120 2914:429 20485:52990 .... > > According to RFC 1997, the community format is AA:NN and AA means the AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and as a result they should not appear in the community. Could anybody tell me what's the reason they do appear in the community of this route? > > Thanks! > > -- > Song Li > Room 4-204, FIT Building, > Network Security, > Department of Electronic Engineering, > Tsinghua University, Beijing 100084, China > Tel:( +86) 010-62446440 > E-mail: refresh.lsong at gmail.com From morrowc.lists at gmail.com Wed Jan 7 14:58:05 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 7 Jan 2015 09:58:05 -0500 Subject: something strange about bgp community In-Reply-To: References: <54AD3627.7020006@gmail.com> Message-ID: On Wed, Jan 7, 2015 at 9:29 AM, Jared Mauch wrote: > 2914:429 is a community to signal to NTT to not announce the route to peers which would perhaps be why you don't see NTT doing that. > it looks like this is the 'customer' of several networks (701, 2914) and they just blindly add carrier communities to their routes 'everywhere'... Or perhaps they view the RV peer as a special place to signal their intent on certain routes more clearly? "Hey, this route is going to get localpref 120 in 701 and NOT be announced to 2914" either way, unless someone strips them, the communities just stay around until stripping... -chris > You can see the documented NTT communities here: http://www.us.ntt.net/support/policy/routing.cfm > > Jared Mauch > >> On Jan 7, 2015, at 5:35 AM, Song Li wrote: >> >> Hi everyone, >> >> Today when I check one route in Routeviews I find something strange as follows: >> >> route-views>sh ip bgp 176.108.0.0 >> BGP routing table entry for 176.108.0.0/19, version 23405621 >> Paths: (33 available, best #28, table default) >> Not advertised to any peer >> Refresh Epoch 1 >> 202018 35320 35320 57800 >> 5.101.110.2 from 5.101.110.2 (5.101.110.2) >> Origin IGP, localpref 100, valid, external >> Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 20485:54050 47541:10001 >> rx pathid: 0, tx pathid: 0 >> >> the AS-Path is "202018 35320 35320 57800" but the community is 702:120 2914:429 20485:52990 .... >> >> According to RFC 1997, the community format is AA:NN and AA means the AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and as a result they should not appear in the community. Could anybody tell me what's the reason they do appear in the community of this route? >> >> Thanks! >> >> -- >> Song Li >> Room 4-204, FIT Building, >> Network Security, >> Department of Electronic Engineering, >> Tsinghua University, Beijing 100084, China >> Tel:( +86) 010-62446440 >> E-mail: refresh.lsong at gmail.com From ml at kenweb.org Wed Jan 7 15:06:57 2015 From: ml at kenweb.org (ML) Date: Wed, 07 Jan 2015 10:06:57 -0500 Subject: something strange about bgp community In-Reply-To: <54AD3627.7020006@gmail.com> References: <54AD3627.7020006@gmail.com> Message-ID: <54AD4B91.5020102@kenweb.org> Also note there is nothing stopping anyone from adding any community they want. The effect and how long the community stays attached to a route is another matter. On 1/7/2015 8:35 AM, Song Li wrote: > Hi everyone, > > Today when I check one route in Routeviews I find something strange as > follows: > > route-views>sh ip bgp 176.108.0.0 > BGP routing table entry for 176.108.0.0/19, version 23405621 > Paths: (33 available, best #28, table default) > Not advertised to any peer > Refresh Epoch 1 > 202018 35320 35320 57800 > 5.101.110.2 from 5.101.110.2 (5.101.110.2) > Origin IGP, localpref 100, valid, external > Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 > 20485:54050 47541:10001 > rx pathid: 0, tx pathid: 0 > > the AS-Path is "202018 35320 35320 57800" but the community is 702:120 > 2914:429 20485:52990 .... > > According to RFC 1997, the community format is AA:NN and AA means the > AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and > as a result they should not appear in the community. Could anybody > tell me what's the reason they do appear in the community of this route? > > Thanks! > From joelja at bogus.com Wed Jan 7 15:25:59 2015 From: joelja at bogus.com (joel jaeggli) Date: Wed, 07 Jan 2015 07:25:59 -0800 Subject: something strange about bgp community In-Reply-To: <54AD3627.7020006@gmail.com> References: <54AD3627.7020006@gmail.com> Message-ID: <54AD5007.8010506@bogus.com> 2914:429 is ntt's do not advertise to any peer community bgp communities are transitive attributes, e.g. you can just pass them to peers unmolested. so someone that's presumably not ntt ( e.g. the neighbor is digital ocean) is sending that commmunity to route views as part of their export. Their utility in routviews depends on context, when I see communities I tagged on my own routes in routviews for example I can tell what pop the announcement originated from which is rather useful. other's like the one above do tell you something about the policy of somebody on the internet. you can also tell who strips communities... On 1/7/15 5:35 AM, Song Li wrote: > Hi everyone, > > Today when I check one route in Routeviews I find something strange as > follows: > > route-views>sh ip bgp 176.108.0.0 > BGP routing table entry for 176.108.0.0/19, version 23405621 > Paths: (33 available, best #28, table default) > Not advertised to any peer > Refresh Epoch 1 > 202018 35320 35320 57800 > 5.101.110.2 from 5.101.110.2 (5.101.110.2) > Origin IGP, localpref 100, valid, external > Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 > 20485:54050 47541:10001 > rx pathid: 0, tx pathid: 0 > > the AS-Path is "202018 35320 35320 57800" but the community is 702:120 > 2914:429 20485:52990 .... > > According to RFC 1997, the community format is AA:NN and AA means the > AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and > as a result they should not appear in the community. Could anybody > tell me what's the reason they do appear in the community of this route? > > Thanks! > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: OpenPGP digital signature URL: From ag4ve.us at gmail.com Wed Jan 7 18:38:09 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 7 Jan 2015 13:38:09 -0500 Subject: Fwd: whois server features In-Reply-To: References: Message-ID: Is there a list of NIC (and other popular whois server) features (what can be searched on) and what data they provide (and what title they give it)? A quick search yields: http://www.ripe.net/ripe/docs/ripe-358 https://www.arin.net/resources/whoisrws/whois_diff.html https://www.apnic.net/apnic-info/whois_search/using-whois/searching/query-options (In declining order of information - I also couldn't find the info for AFRINIC queries) I also couldn't find information on what fields they have (and obviously how they map to one another). There are also a few other whois servers around that I have no idea about: https://www.opensource.apple.com/source/adv_cmds/adv_cmds-149/whois/whois.c From woody at pch.net Wed Jan 7 18:53:46 2015 From: woody at pch.net (Bill Woodcock) Date: Wed, 7 Jan 2015 10:53:46 -0800 Subject: whois server features In-Reply-To: References: Message-ID: > On Jan 7, 2015, at 10:38 AM, shawn wilson wrote: > > Is there a list of NIC (and other popular whois server) features (what > can be searched on) and what data they provide (and what title they > give it)? Heh, heh, heh. There are just about as many whois output formats as there are back-end data-stores. Note that I say “data-stores” rather than databases. Some of them aren’t. So when you say “title” I assume you’re referring to half of a key-value pair. A concept some large whois sources don’t have. So, you’re not running into a poorly-documented mystery, you’ve run afoul of one of the rotten armpits of the shub-Internet. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ag4ve.us at gmail.com Wed Jan 7 19:47:47 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 7 Jan 2015 14:47:47 -0500 Subject: whois server features In-Reply-To: References: Message-ID: On Wed, Jan 7, 2015 at 1:53 PM, Bill Woodcock wrote: > >> On Jan 7, 2015, at 10:38 AM, shawn wilson wrote: >> >> Is there a list of NIC (and other popular whois server) features (what >> can be searched on) and what data they provide (and what title they >> give it)? > > Heh, heh, heh. There are just about as many whois output formats as there are back-end data-stores. Note that I say “data-stores” rather than databases. Some of them aren’t. So when you say “title” I assume you’re referring to half of a key-value pair. A concept some large whois sources don’t have. > Yes, I'm referring to mapping between key names. > So, you’re not running into a poorly-documented mystery, you’ve run afoul of one of the rotten armpits of the shub-Internet. > So there's no consensus between NICs for the information they should have in whois and what search mechanisms they should provide? I guess what you're saying is that whois is just a protocol definition and nothing else? From rubensk at gmail.com Wed Jan 7 19:55:48 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 7 Jan 2015 17:55:48 -0200 Subject: whois server features In-Reply-To: References: Message-ID: > > > So, you’re not running into a poorly-documented mystery, you’ve run > afoul of one of the rotten armpits of the shub-Internet. > > > > So there's no consensus between NICs for the information they should > have in whois and what search mechanisms they should provide? I guess > what you're saying is that whois is just a protocol definition and > nothing else? > Might not even qualify for "protocol definition", and RFC 3912 ACKs this: https://tools.ietf.org/html/rfc3912 Rubens From woody at pch.net Wed Jan 7 20:07:04 2015 From: woody at pch.net (Bill Woodcock) Date: Wed, 7 Jan 2015 12:07:04 -0800 Subject: whois server features In-Reply-To: References: Message-ID: >> So, you’re not running into a poorly-documented mystery, you’ve run afoul of one of the rotten armpits of the shub-Internet. >> > So there's no consensus between NICs for the information they should > have in whois and what search mechanisms they should provide? I guess > what you're saying is that whois is just a protocol definition and > nothing else? Correct. It gets you a blob of text. Sometimes, a blob is just a blob. Other times, it contains what _appear_ to be key-value pairs, but are instead loosely-formatted text. Other times, it contains textually-represented key-value pairs that are programmatically generated from an actual database, and can thus be re-imported into another database. Depends what’s on the back end. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ag4ve.us at gmail.com Wed Jan 7 20:18:07 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 7 Jan 2015 15:18:07 -0500 Subject: whois server features In-Reply-To: References: Message-ID: On Wed, Jan 7, 2015 at 3:07 PM, Bill Woodcock wrote: >>> So, you’re not running into a poorly-documented mystery, you’ve run afoul of one of the rotten armpits of the shub-Internet. >>> >> So there's no consensus between NICs for the information they should >> have in whois and what search mechanisms they should provide? I guess >> what you're saying is that whois is just a protocol definition and >> nothing else? > > Correct. It gets you a blob of text. Sometimes, a blob is just a blob. Other times, it contains what _appear_ to be key-value pairs, but are instead loosely-formatted text. Other times, it contains textually-represented key-value pairs that are programmatically generated from an actual database, and can thus be re-imported into another database. Depends what’s on the back end. > This is not the response I was looking for (and reading the RFC makes me feel even worse). Is there a better mechanism for querying NICs for host/owner information? From rubensk at gmail.com Wed Jan 7 20:24:10 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 7 Jan 2015 18:24:10 -0200 Subject: whois server features In-Reply-To: References: Message-ID: > This is not the response I was looking for (and reading the RFC makes > me feel even worse). > > Is there a better mechanism for querying NICs for host/owner information? > There will be, one day. And the start (although not the whole journey) will be when this I-D follows the standard path all the way to STD: http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-18.html Rubens From ag4ve.us at gmail.com Wed Jan 7 20:45:30 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 7 Jan 2015 15:45:30 -0500 Subject: whois server features In-Reply-To: References: Message-ID: On Wed, Jan 7, 2015 at 3:32 PM, anthony kasza wrote: > Scripting languages have modules that can parse many registrar whois > formats. However, most are incomplete due to the plurality of output formats > as stated above. I, and i suspect many others, wouls *love* to see a more > concrete key value format drafted and enforced by ICANN. > Yes, that's what I was looking at. And that REST API looks nice... Though from what I read (admittedly not the whole doc yet) I didn't see it defined what type of data is returned, nor what data should be expected, which would leave me in the same place. If I'm only getting a blob back (that would be, I guess, internationalized at this point) I've still got to loop through with a regex expecting some type of key/value thing and concatenate data after a line break to the last value (probably removing spaces since they try to format it pretty). From nick at foobar.org Wed Jan 7 20:48:22 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 07 Jan 2015 20:48:22 +0000 Subject: whois server features In-Reply-To: References: Message-ID: <54AD9B96.4050300@foobar.org> On 07/01/2015 20:07, Bill Woodcock wrote: > Correct. It gets you a blob of text. Sometimes, a blob is just a blob. > Other times, it contains what _appear_ to be key-value pairs, but are > instead loosely-formatted text. Other times, it contains > textually-represented key-value pairs that are programmatically > generated from an actual database, and can thus be re-imported into > another database. Depends what’s on the back end. If only we could create a committee to fix whois... Nick From joelja at bogus.com Wed Jan 7 20:57:41 2015 From: joelja at bogus.com (joel jaeggli) Date: Wed, 07 Jan 2015 12:57:41 -0800 Subject: whois server features In-Reply-To: <54AD9B96.4050300@foobar.org> References: <54AD9B96.4050300@foobar.org> Message-ID: <54AD9DC5.1050908@bogus.com> On 1/7/15 12:48 PM, Nick Hilliard wrote: > On 07/01/2015 20:07, Bill Woodcock wrote: >> Correct. It gets you a blob of text. Sometimes, a blob is just a blob. >> Other times, it contains what _appear_ to be key-value pairs, but are >> instead loosely-formatted text. Other times, it contains >> textually-represented key-value pairs that are programmatically >> generated from an actual database, and can thus be re-imported into >> another database. Depends what’s on the back end. > If only we could create a committee to fix whois... wierd, I've heard that before someplace. > Nick > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 221 bytes Desc: OpenPGP digital signature URL: From bob at FiberInternetCenter.com Wed Jan 7 21:02:59 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 7 Jan 2015 13:02:59 -0800 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: <54AC534F.2020403@xkl.com> References: <54AC4A77.2080603@xkl.com> <54AC534F.2020403@xkl.com> Message-ID: <95d83393f3f60372c62aae9c66f02214.squirrel@66.201.44.180> Thanks to those of you that answered...It is hypothetical....However, I found another customer that uses Office 365 heavily ... said they discovered 1 meg/sec per Microsoft Office 365 user works well in most scenarios. This customer has 80 users and a 100 meg/sec connection with us. Thank You Bob Evans CTO >> On 1/6/2015 12:37 PM, Bob Evans wrote: >>> I have a customer that heavily uses Microsoft Office 365. It's >>> hosted. All >>> the data I see about usage per user appears theoretical. In that the >>> formulas assume people are taking turns using the bandwidth as if >>> there is >>> a patient line of packets at the Internet gas pump. Nobody is >>> clicking at >>> the same time. We all know that is not the real world. >>> >>> Does anyone have any experience with Office 365 hosted that can tell me >>> the practical bandwidth allocation (NOT in KB per month, but in >>> megabits/sec) for 100 users (during normal work hours) needs to be >>> available ? >>> >>> Thank You in advance, >>> Bob Evans >>> CTO Fiber Internet Center >>> >>> >>> >>> >>> > > From mysidia at gmail.com Wed Jan 7 23:17:26 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 7 Jan 2015 17:17:26 -0600 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: References: Message-ID: On Tue, Jan 6, 2015 at 2:37 PM, Bob Evans wrote: [snip] > Does anyone have any experience with Office 365 hosted that can tell me > the practical bandwidth allocation (NOT in KB per month, but in Most likely in the real world where packets don't line up neatly... O365 is most probably not the largest bandwidth user, when there is Pandora and Youtube. It depends on factors that may be specific to the organization which are truly unpredictable for each individual user, but you could gather data for your specific population of users. I believe I would just ignore O365, since the bandwidth usage is not much, and pick a standard rule of thumb for the amount of bandwidth your typical Office user actually needs to get work done, that includes more than sufficient 'slack' for O365. My suggested rule of thumb if you can't actually measure the traffic in advance for your population: count the number of workstation devices that will be your network, figure at least 0.5 Megabit of WAN for each typical business user workstation or laptop. Assuming equal numbers of active users and workstations all operating 8 hours a day ( if there are many more devices than users, or many more users than devices, then adjust in proportion). *Each internal workgroup server or Office manager's workstation counts as 300% of a workstation. (In other words: better figure 1.5 Megabits for each of those, instead of 0.5.) *Each Wireless tablet or phone connected by WiFi = 33% of a workstation. so add 0.17 Megabits for each staff person that may connect a smartphone. *Designer, Engineer workstations are 500% (So figure 2.5 Mbit for each of those). Add an extra safety margin of either 2 Megabits, or 30%, whichever is greater. So for 100 standard workstations, 100 Tablets, 2 Internal servers, 1 Office manager desktop, and 2 Designers. I would say get a 100 Megabit WAN. > megabits/sec) for 100 users (during normal work hours) needs to be > available ? > > Thank You in advance, > Bob Evans > CTO Fiber Internet Center -- -JH From anthony.kasza at gmail.com Wed Jan 7 20:32:49 2015 From: anthony.kasza at gmail.com (anthony kasza) Date: Wed, 7 Jan 2015 12:32:49 -0800 Subject: whois server features In-Reply-To: References: Message-ID: Scripting languages have modules that can parse many registrar whois formats. However, most are incomplete due to the plurality of output formats as stated above. I, and i suspect many others, wouls *love* to see a more concrete key value format drafted and enforced by ICANN. -AK On Jan 7, 2015 12:26 PM, "Rubens Kuhl" wrote: > > This is not the response I was looking for (and reading the RFC makes > > me feel even worse). > > > > Is there a better mechanism for querying NICs for host/owner information? > > > > There will be, one day. And the start (although not the whole journey) will > be when this I-D follows the standard path all the way to STD: > http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-18.html > > > Rubens > From drc at virtualized.org Thu Jan 8 01:38:56 2015 From: drc at virtualized.org (David Conrad) Date: Wed, 7 Jan 2015 17:38:56 -0800 Subject: whois server features In-Reply-To: References: Message-ID: <516C1E31-E0EC-4900-A00E-66A74B32FF34@virtualized.org> Hi, > Scripting languages have modules that can parse many registrar whois > formats. However, most are incomplete due to the plurality of output > formats as stated above. I, and i suspect many others, wouls *love* to see > a more concrete key value format drafted and enforced by ICANN. ICANN can only 'enforce' stuff on the contracted parties, namely the gTLDs. And, in fact, they do so in contractual agreements (if you want the gory details, see Specification 4 of http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm for registries and https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois for registrars). ICANN can't 'enforce' anything on the ccTLDs or RIRs. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jeast at mslogic.net Thu Jan 8 01:39:29 2015 From: jeast at mslogic.net (John East) Date: Wed, 7 Jan 2015 19:39:29 -0600 Subject: RADB Message-ID: Is there anyone from RADB or MerIt on this list that could contact me off the list? John From ggm at algebras.org Thu Jan 8 02:11:24 2015 From: ggm at algebras.org (George Michaelson) Date: Thu, 8 Jan 2015 12:11:24 +1000 Subject: whois server features In-Reply-To: <516C1E31-E0EC-4900-A00E-66A74B32FF34@virtualized.org> References: <516C1E31-E0EC-4900-A00E-66A74B32FF34@virtualized.org> Message-ID: CRISP is dead. RDAP is real. If people need to script, then RDAP is workable JSON and for once, has converged on sensible stuff in both names and numbers. the whois "problem" is a formalism owned by ICANN, but as DRC pointed out the WHOIS solution is dispersed. RPSL lies to one side btw. I wish it was a defined RDAP type. It may be work-in-progress but thats not clear. On Thu, Jan 8, 2015 at 11:38 AM, David Conrad wrote: > Hi, > > > Scripting languages have modules that can parse many registrar whois > > formats. However, most are incomplete due to the plurality of output > > formats as stated above. I, and i suspect many others, wouls *love* to > see > > a more concrete key value format drafted and enforced by ICANN. > > ICANN can only 'enforce' stuff on the contracted parties, namely the > gTLDs. And, in fact, they do so in contractual agreements (if you want the > gory details, see Specification 4 of > http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm > for registries and > https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois > for registrars). > > ICANN can't 'enforce' anything on the ccTLDs or RIRs. > > Regards, > -drc > > From refresh.lsong at gmail.com Thu Jan 8 02:31:38 2015 From: refresh.lsong at gmail.com (Song Li) Date: Thu, 08 Jan 2015 10:31:38 +0800 Subject: something strange about bgp community In-Reply-To: <54AD5007.8010506@bogus.com> References: <54AD3627.7020006@gmail.com> <54AD5007.8010506@bogus.com> Message-ID: <54ADEC0A.8090809@gmail.com> Thanks! Because there is no standard syntax on the description of BGP community, I think the problem is hard to understand. 在 2015/1/7 23:25, joel jaeggli 写道: > 2914:429 is ntt's do not advertise to any peer community > > bgp communities are transitive attributes, e.g. you can just pass them > to peers unmolested. so someone that's presumably not ntt ( e.g. the > neighbor is digital ocean) is sending that commmunity to route views as > part of their export. > > Their utility in routviews depends on context, when I see communities I > tagged on my own routes in routviews for example I can tell what pop the > announcement originated from which is rather useful. other's like the > one above do tell you something about the policy of somebody on the > internet. you can also tell who strips communities... > > On 1/7/15 5:35 AM, Song Li wrote: >> Hi everyone, >> >> Today when I check one route in Routeviews I find something strange as >> follows: >> >> route-views>sh ip bgp 176.108.0.0 >> BGP routing table entry for 176.108.0.0/19, version 23405621 >> Paths: (33 available, best #28, table default) >> Not advertised to any peer >> Refresh Epoch 1 >> 202018 35320 35320 57800 >> 5.101.110.2 from 5.101.110.2 (5.101.110.2) >> Origin IGP, localpref 100, valid, external >> Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 >> 20485:54050 47541:10001 >> rx pathid: 0, tx pathid: 0 >> >> the AS-Path is "202018 35320 35320 57800" but the community is 702:120 >> 2914:429 20485:52990 .... >> >> According to RFC 1997, the community format is AA:NN and AA means the >> AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and >> as a result they should not appear in the community. Could anybody >> tell me what's the reason they do appear in the community of this route? >> >> Thanks! >> > > -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From jtk at cymru.com Thu Jan 8 02:41:29 2015 From: jtk at cymru.com (John Kristoff) Date: Wed, 7 Jan 2015 20:41:29 -0600 Subject: Security Track @ NANOG 63 Call for Participation Message-ID: <20150107204129.78576ce6@localhost> [ Apologies if you saw this elsewhere already - jtk ] Friends, colleagues, fellow operators, The network security track, formerly known as the ISP security BoF, will be on the agenda at NANOG 63 in San Antonio and I will be the track facilitator. We not only seek your participation, but we are also interested you contributing to the track content. If you have an idea or if you know someone who might like to present, discuss or conduct a demonstration of something, we want to hear from you. Here is an incomplete list of relevant topics to stir your thoughts: * Cloud security (whatever that means :-) * Control plane best practices and templates * DDoS mitigation experience and case studies * Embedded device problems and protections * Government regulatory, compliance and privacy issues * IPv6 security concerns or case studies * MPLS and VLAN security issues * NetFlow-based security tools and techniques * OpenFlow/SDN security considerations * Route leak/hijack monitoring and mitigation * Walled garden techniques * X.509 certificate infrastructure concerns * If you want your PGP key signed by me (or anyone else), you should upload your key to the biglumber event keyring page before arriving so we have a record of it before meeting in person. John From johnl at iecc.com Thu Jan 8 03:22:03 2015 From: johnl at iecc.com (John Levine) Date: 8 Jan 2015 03:22:03 -0000 Subject: whois server features In-Reply-To: <54AD9B96.4050300@foobar.org> Message-ID: <20150108032203.37628.qmail@ary.lan> >If only we could create a committee to fix whois... Quite astonishingly, the IETF WEIRDS working group finished successfully, and its documents will be published as RFCs when they get through the editing queue in a month or two. The protocol is called RDAP, the queries are http, the results are json. ARIN, APNIC, and RIPE have prototypes already that are a lot easier to script than the text WHOIS. RDAP is also supposed to work for domain name WHOIS, but the timeline there is less clear. ICANN has hired cnnic to do a freeware version which we hope a lot of smaller registries will use. R's, John From ag4ve.us at gmail.com Thu Jan 8 03:59:22 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 7 Jan 2015 22:59:22 -0500 Subject: whois server features In-Reply-To: <20150108032203.37628.qmail@ary.lan> References: <54AD9B96.4050300@foobar.org> <20150108032203.37628.qmail@ary.lan> Message-ID: On Wed, Jan 7, 2015 at 10:22 PM, John Levine wrote: > ARIN, APNIC, and RIPE have prototypes already that are a lot easier to > script than the text WHOIS. > Meaning the data structure is in place or they have a RDAP service up? If so, is it publicly accessible? From jwhited0917 at gmail.com Thu Jan 8 02:36:01 2015 From: jwhited0917 at gmail.com (Jordan Whited) Date: Wed, 7 Jan 2015 21:36:01 -0500 Subject: HostGator contact Message-ID: Looking for a HostGator contact, off-list From ggm at algebras.org Thu Jan 8 04:22:49 2015 From: ggm at algebras.org (George Michaelson) Date: Thu, 8 Jan 2015 14:22:49 +1000 Subject: whois server features In-Reply-To: References: <54AD9B96.4050300@foobar.org> <20150108032203.37628.qmail@ary.lan> Message-ID: http://rdap.apnic.net/ redirects to a web page documenting service http://rdap.apnic.net/ip shows a json error response http://rdap.apnic.net/ip/203.119.0.0/24 shows the /24 record for 203.119.0.0/24 -G On Thu, Jan 8, 2015 at 1:59 PM, shawn wilson wrote: > On Wed, Jan 7, 2015 at 10:22 PM, John Levine wrote: > > > ARIN, APNIC, and RIPE have prototypes already that are a lot easier to > > script than the text WHOIS. > > > > Meaning the data structure is in place or they have a RDAP service up? > If so, is it publicly accessible? > From johnl at iecc.com Thu Jan 8 04:23:40 2015 From: johnl at iecc.com (John R. Levine) Date: 7 Jan 2015 23:23:40 -0500 Subject: whois server features In-Reply-To: References: <54AD9B96.4050300@foobar.org> <20150108032203.37628.qmail@ary.lan> Message-ID: >> ARIN, APNIC, and RIPE have prototypes already that are a lot easier to >> script than the text WHOIS. > > Meaning the data structure is in place or they have a RDAP service up? Both. ARIN's and RIPE's are based on early versions so the URLs and JSON aren't quite what RDAP says they should be yet. > If so, is it publicly accessible? Google is your friend. R's, John From bob at FiberInternetCenter.com Thu Jan 8 05:00:43 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 7 Jan 2015 21:00:43 -0800 Subject: Microsoft - RE: Office 365 Expert - I am not. I have a customer that... In-Reply-To: <000a01d02af8$431f11b0$c95d3510$@iname.com> References: <54AC4A77.2080603@xkl.com> <54AC534F.2020403@xkl.com> <95d83393f3f60372c62aae9c66f02214.squirrel@66.201.44.180> <000a01d02af8$431f11b0$c95d3510$@iname.com> Message-ID: <19fc7fe8a976f99e42e44f66d4503b3f.squirrel@66.201.44.180> Thanks Frank... I do have a customer with 500 meg/sec service running 350 meg/sec average all day.... just 800 employees - no company driven focused use of MS office 365. Applications used and time of day, etc. So, I don't think one can compare a college's overall app bandwidth usage to a business primarily using office 365. I'm really looking for a "minimum bandwidth recommended requirement for 100 employees all using Office 365 hosted docs that are all outside the LAN. " MS has no such number. MS just leaving it to the individual case-by-case discovery process. I bet Microsoft can't answer that simple question or they wouldn't have these GB per user equations that use X for average document size. Best, I have to go on so far is what one of our customers "thinks" is needed. Thank You Bob Evans CTO > 1 Mbps/user seems very high -- the local college has over 200 employees > using O365 (and over 1400 students) and its broadband connection is just > 250 > Mbps and they're at less than 150 Mbps during the day. > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans > Sent: Wednesday, January 07, 2015 3:03 PM > To: Roy Hirst > Cc: nanog at nanog.org > Subject: Re: Office 365 Expert - I am not. I have a customer that... > > Thanks to those of you that answered...It is hypothetical....However, I > found another customer that uses Office 365 heavily ... said they > discovered 1 meg/sec per Microsoft Office 365 user works well in most > scenarios. This customer has 80 users and a 100 meg/sec connection with > us. > > Thank You > Bob Evans > CTO > > > >>> On 1/6/2015 12:37 PM, Bob Evans wrote: >>>> I have a customer that heavily uses Microsoft Office 365. It's >>>> hosted. All >>>> the data I see about usage per user appears theoretical. In that the >>>> formulas assume people are taking turns using the bandwidth as if >>>> there is >>>> a patient line of packets at the Internet gas pump. Nobody is >>>> clicking at >>>> the same time. We all know that is not the real world. >>>> >>>> Does anyone have any experience with Office 365 hosted that can tell >>>> me >>>> the practical bandwidth allocation (NOT in KB per month, but in >>>> megabits/sec) for 100 users (during normal work hours) needs to be >>>> available ? >>>> >>>> Thank You in advance, >>>> Bob Evans >>>> CTO Fiber Internet Center >>>> >>>> >>>> >>>> >>>> >> >> > > > > > From ag4ve.us at gmail.com Thu Jan 8 05:07:55 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 8 Jan 2015 00:07:55 -0500 Subject: whois server features In-Reply-To: References: <54AD9B96.4050300@foobar.org> <20150108032203.37628.qmail@ary.lan> Message-ID: On Wed, Jan 7, 2015 at 11:23 PM, John R. Levine wrote: > Google is your friend. > Woops, you're right.... From bob at FiberInternetCenter.com Thu Jan 8 05:20:25 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 7 Jan 2015 21:20:25 -0800 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: References: Message-ID: <9ea34653da96846ba58bb1270b69969d.squirrel@66.201.44.180> Thanks Jimmy - I agree - It's pretty much what we do today...it's just this one customer wanted Office 365 specific details. I don't think anyone knows. Including Microsoft, app creator. Wonder when Cloud providers get a clue, step up and help recommend a circuit size based on users and the services their customer buy from them. All that investment in co-lo infrastructure and it's left the middle man. VCs in the cloud sector should be realizing that customer experience in their cloud investment can be hindered as they leave this up to the middle. But, they (and MS) should publish something other than the monthly GB transfer/seats they charge by. Enterprise circuits are not sold by GB transfer. After all we just want to get it right and help make the cloud service provider's apps run well. Thank You Bob Evans CTO > On Tue, Jan 6, 2015 at 2:37 PM, Bob Evans > wrote: > [snip] >> Does anyone have any experience with Office 365 hosted that can tell me >> the practical bandwidth allocation (NOT in KB per month, but in > > Most likely in the real world where packets don't line up neatly... O365 > is most probably not the largest bandwidth user, when there is > Pandora and Youtube. > It depends on factors that may be specific to the organization which > are truly unpredictable > for each individual user, but you could gather data for your specific > population of users. > > I believe I would just ignore O365, since the bandwidth usage is not > much, and pick > a standard rule of thumb for the amount of bandwidth your typical > Office user actually needs > to get work done, that includes more than sufficient 'slack' for O365. > > My suggested rule of thumb if you can't actually measure the traffic > in advance for your > population: count the number of workstation devices that will be your > network, figure > at least 0.5 Megabit of WAN for each typical business user > workstation or laptop. > > Assuming equal numbers of active users and workstations all operating > 8 hours a day ( > if there are many more devices than users, or many more users than > devices, then adjust in proportion). > > *Each internal workgroup server or Office manager's workstation > counts as 300% of a workstation. > (In other words: better figure 1.5 Megabits for each of those, > instead of 0.5.) > > *Each Wireless tablet or phone connected by WiFi = 33% of a > workstation. > so add 0.17 Megabits for each staff person that may connect > a smartphone. > > *Designer, Engineer workstations are 500% (So figure 2.5 Mbit > for each of those). > > Add an extra safety margin of either 2 Megabits, or 30%, > whichever is greater. > > So for 100 standard workstations, 100 Tablets, 2 Internal servers, 1 > Office manager desktop, and 2 Designers. > I would say get a 100 Megabit WAN. > > > >> megabits/sec) for 100 users (during normal work hours) needs to be >> available ? >> >> Thank You in advance, >> Bob Evans >> CTO Fiber Internet Center > > -- > -JH > From fmartin at linkedin.com Thu Jan 8 09:23:25 2015 From: fmartin at linkedin.com (Franck Martin) Date: Thu, 8 Jan 2015 09:23:25 +0000 Subject: whois server features In-Reply-To: References: Message-ID: On Jan 7, 2015, at 10:38 AM, shawn wilson wrote: > Is there a list of NIC (and other popular whois server) features (what > can be searched on) and what data they provide (and what title they > give it)? > Your best bet today is http://sourceforge.net/projects/phpwhois/ and from http://phpwhois.cvs.sourceforge.net/viewvc/phpwhois/phpwhois/ You will see there are nearly as many data mappers as there are TLDs… WEIRDS is supposed to fix the protocol, data presentation and the field names, but not what fields will be present (as I understand it). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nick at foobar.org Thu Jan 8 09:48:09 2015 From: nick at foobar.org (Nick Hilliard) Date: Thu, 08 Jan 2015 09:48:09 +0000 Subject: RADB In-Reply-To: References: Message-ID: <54AE5259.40004@foobar.org> On 08/01/2015 01:39, John East wrote: > Is there anyone from RADB or MerIt on this list that could contact me off > the list? radb-support at merit.edu is responsive when it comes to RADB IRRDB issues. Nick From ag4ve.us at gmail.com Thu Jan 8 14:02:33 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 8 Jan 2015 09:02:33 -0500 Subject: whois server features In-Reply-To: References: Message-ID: On Jan 8, 2015 4:23 AM, "Franck Martin" wrote: > > > On Jan 7, 2015, at 10:38 AM, shawn wilson wrote: > > > Is there a list of NIC (and other popular whois server) features (what > > can be searched on) and what data they provide (and what title they > > give it)? > > > Your best bet today is http://sourceforge.net/projects/phpwhois/ > > and from http://phpwhois.cvs.sourceforge.net/viewvc/phpwhois/phpwhois/ > Awesome thanks. That answers half of my original question (though this route was much more insightful than I thought). I can run with that (php isn't my language but the etl is pretty clear). From edlewis.subscriber at cox.net Thu Jan 8 14:25:13 2015 From: edlewis.subscriber at cox.net (Edward Lewis) Date: Thu, 8 Jan 2015 09:25:13 -0500 Subject: Solicitation for Statements of Interest regarding Root KSK Rollover Message-ID: <1B969B0B-678F-4DC7-B61B-7D7DDDE12F00@cox.net> (I am not sure if this appeared on this list before, so just to be sure, perhaps yet another posting of this announcement:) ICANN, as the IANA functions operator, in cooperation with Verisign as the Root Zone Maintainer and the National Telecommunications Information Administration (NTIA) as the Root Zone Administrator, together known as the Root Zone Management (RZM) partners, seek to develop a plan for rolling the DNS root zone key-signing key (KSK). The KSK is used to sign the root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the Internet’s root zone. The Root Zone Partners are soliciting five to seven volunteers from the community to participate in a Design Team to develop the Root Zone KSK Rollover Plan (“The Plan”). These volunteers along with the RZM partners will form the Design Team to develop The Plan. Individuals interested in volunteering approximately 5 hours per week for the Design Team should consult the announcement: https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf and submit their Statement of Interest to ksk-rollover-soi at icann.org no later than January 16, 2015. From maxtul at netassist.ua Thu Jan 8 14:50:49 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 08 Jan 2015 16:50:49 +0200 Subject: something strange about bgp community In-Reply-To: <54AD3627.7020006@gmail.com> References: <54AD3627.7020006@gmail.com> Message-ID: <54AE9949.6030007@netassist.ua> Hi Song, that's normal. This is a signat to AS702 to do some special with this route when it will see this route. Community is transistive by its design, so you don't need to be directly connected to AS702 to send some signal to it. For example: you->AS101-AS102-AS103-target \->AS104-/\/\/\-AS105-/ where /\/\/\ is disrupted path with packet loss. AS104-AS105 is better as AS-PATH lengh. If "target" accepts community, I can add "target:notaccept" to AS104 and avoid that path. Some brain-dead ;) transit providers clear all community when import announces, but for me it is at least unfair. On 07.01.15 15:35, Song Li wrote: > Hi everyone, > > Today when I check one route in Routeviews I find something strange as > follows: > > route-views>sh ip bgp 176.108.0.0 > BGP routing table entry for 176.108.0.0/19, version 23405621 > Paths: (33 available, best #28, table default) > Not advertised to any peer > Refresh Epoch 1 > 202018 35320 35320 57800 > 5.101.110.2 from 5.101.110.2 (5.101.110.2) > Origin IGP, localpref 100, valid, external > Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 > 20485:54050 47541:10001 > rx pathid: 0, tx pathid: 0 > > the AS-Path is "202018 35320 35320 57800" but the community is 702:120 > 2914:429 20485:52990 .... > > According to RFC 1997, the community format is AA:NN and AA means the > AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and as > a result they should not appear in the community. Could anybody tell me > what's the reason they do appear in the community of this route? > > Thanks! > From mark.tinka at seacom.mu Thu Jan 8 15:09:03 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 8 Jan 2015 17:09:03 +0200 Subject: MPLS VPN design - RR in forwarding path? In-Reply-To: References: <54A3E6C7.7070406@gmail.com> <694A65FF-37EC-40F5-921F-377E88AA6BCF@ericsson.com> Message-ID: <201501081709.06101.mark.tinka@seacom.mu> On Friday, January 02, 2015 11:03:21 PM Daniel Rohan wrote: > Also think physical topologies like ethernet rings. > Where's the RR go in this topology? In these topologies, I've been playing with having the RR's in the core (i.e., on the other end of the PE Aggregation routers terminating the ring) and running the iBGP sessions between the Metro-E Access switches and the RR's. As the RR's are MPLS-free (but the Metro-E Access switches [particularly Cisco] still assign MPLS labels to each IGP route), we cobble together a combination of hop-by-hop IP forwarding + MPLS forwarding fu to get traffic to where it needs to go without involving the PE Aggregation routers in the routing toward the Metro-E Access switches (i.e., 0/0 and ::/0 + a few more specifics come from the RR's). Been working with this routing topology for MPLS rings since 2009. It seems to hold up... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From daryl at introspect.net Thu Jan 8 16:13:13 2015 From: daryl at introspect.net (Daryl G. Jurbala) Date: Thu, 8 Jan 2015 11:13:13 -0500 Subject: 1U or SS7 to SIP services in Sovereign House London Message-ID: I know it’s a long shot on this list, but if you know of anyone who can provide these services or even just a good place like NANOG for that part of the world please contact me off list. From carlos at race.com Thu Jan 8 16:19:02 2015 From: carlos at race.com (Carlos Alcantar) Date: Thu, 8 Jan 2015 16:19:02 +0000 Subject: 1U or SS7 to SIP services in Sovereign House London In-Reply-To: References: Message-ID: Voiceops list might be better suited for this request. 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 On 1/8/15, 8:13 AM, "Daryl G. Jurbala" wrote: >I know it¹s a long shot on this list, but if you know of anyone who can >provide these services or even just a good place like NANOG for that part >of the world please contact me off list. > > > From corbe at corbe.net Thu Jan 8 16:35:11 2015 From: corbe at corbe.net (Daniel Corbe) Date: Thu, 08 Jan 2015 11:35:11 -0500 Subject: 1U or SS7 to SIP services in Sovereign House London In-Reply-To: (Carlos Alcantar's message of "Thu, 8 Jan 2015 16:19:02 +0000") References: Message-ID: <878uhddydc.fsf@corbe.net> Just to save him some googling: https://puck.nether.net/mailman/listinfo/voiceops -Daniel Carlos Alcantar writes: > Voiceops list might be better suited for this request. > > > 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 > > > > > > > > On 1/8/15, 8:13 AM, "Daryl G. Jurbala" wrote: > >>I know it¹s a long shot on this list, but if you know of anyone who can >>provide these services or even just a good place like NANOG for that part >>of the world please contact me off list. >> >> >> From mmg at transtelco.net Thu Jan 8 17:01:47 2015 From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=) Date: Thu, 8 Jan 2015 10:01:47 -0700 Subject: DDOS solution recommendation Message-ID: Nanog group I was wondering what are are using for DDOS protection in your networks. We are currently evaluating different options (Arbor, Radware, NSFocus, RioRey) and I would like to know if someone is using the cloud based solutions/scrubbing centers like Imperva, Prolexic, etc and what are the advantages/disadvantages of using a cloud base vs an on-premise solution. It would be great if you can share your experience on this matter. Thank you From mehmet at akcin.net Thu Jan 8 17:13:55 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 8 Jan 2015 09:13:55 -0800 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: <12D153EA-A717-4A0F-A190-0F104BF204F6@akcin.net> A10 http://www.a10networks.com/products/ddos_protection.php Mehmet > On Jan 8, 2015, at 9:01 AM, Manuel Marín wrote: > > Nanog group > > I was wondering what are are using for DDOS protection in your networks. We > are currently evaluating different options (Arbor, Radware, NSFocus, > RioRey) and I would like to know if someone is using the cloud based > solutions/scrubbing centers like Imperva, Prolexic, etc and what are the > advantages/disadvantages of using a cloud base vs an on-premise solution. > It would be great if you can share your experience on this matter. > > Thank you From Joel.Snyder at opus1.com Thu Jan 8 17:27:55 2015 From: Joel.Snyder at opus1.com (Joel M Snyder) Date: Thu, 08 Jan 2015 10:27:55 -0700 Subject: Office 365 Expert In-Reply-To: References: Message-ID: <54AEBE1B.50203@opus1.com> >My suggested rule of thumb if you can't actually measure the traffic >in advance for your population: count the number of >workstation devices that will be your network, >figure at least 0.5 Megabit of WAN for each typical business >user workstation or laptop. I can't help but laugh (laughing with, not laughing at--all due respect to the NA part of NANOG) at this. I've been spending the last 4 years working on various UN networks where getting 0.5Mb of bandwidth to a site can be a challenge, and 4 Mbit/second for an office of 8 users is an unaffordable luxury. And these are sites where the end users want to move to Office 365. We've done a bit of testing, and one of the issues with O365 is that O365 is a BIG thing and you have to decide which slice of O365 you are calling "O365" at a particular site. For some people, that's just "outsourced Exchange" (in which case we would allocate 30K-50Kbps per office user downstream bandwidth, and drop in a WAN Opt box plus do some shenanigans to break into the HTTPS through proxy). For other people, O365 is the whole "nothing is on my hard disk (but cache)" thing, plus Lync (not just voice, but voice+video). Those folks really are going to require major bandwidth; this is where numbers like 512K/simultaneous user make more sense. You can excuse (or at least explain) Microsoft's lack of benchmarks and guidance because of the complexity of O365 and also because they have the sort of North American viewpoint that makes it hard for them to understand high latency/low bandwidth pipes. They try hard, but often just don't get it because of the amazing resources and richness available to a company of that size. I had a great conversation with them about 3 years ago about Exchange and AD forest design where they were strongly advocating centralizing everything in data centers, rather than pushing anything like a DC or mailbox server out to a branch office. When I asked about the bandwidth required, they said that it was "not much." Pressed for details, they said "we do it ourselves, and it hardly impacts the bandwidth on our most poorly-connected offices." Pressed even further, it turns out that a T3/E3 is the lowest link they would consider acceptable for an office. (My total upstream bandwidth budget at one agency for 100 offices and 9,000 users in 24 timezones is less than a single T3... Thanks Microsoft!) Anyway, not adding much to this conversation since it's clear that Bob is asking in the context of "bandwidth is cheap, fast, and inexpensive," but I couldn't help but giggle at the kinds of numbers you guys are throwing around here for people to read email and work on spreadsheets. 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 RCzumbil at xand.com Thu Jan 8 17:32:33 2015 From: RCzumbil at xand.com (Romeo Czumbil) Date: Thu, 8 Jan 2015 17:32:33 +0000 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: <4B5E2AE2A43CEF4BB004BB9FB485D834081B99@Xand-tek-Mbx01.corp.xand.com> Radware DefensePro x420s is what we use. Works great and extremely fast. Just need to make sure where you install it on your network. For best results you want to make sure you get the return traffic as well into the box otherwise it won't be able to detect all attacks. -Romeo -----Original Message----- From: NANOG [mailto:nanog-bounces+rczumbil=xand.com at nanog.org] On Behalf Of Manuel Marín Sent: Thursday, January 08, 2015 12:02 PM To: nanog at nanog.org Subject: DDOS solution recommendation Nanog group I was wondering what are are using for DDOS protection in your networks. We are currently evaluating different options (Arbor, Radware, NSFocus, RioRey) and I would like to know if someone is using the cloud based solutions/scrubbing centers like Imperva, Prolexic, etc and what are the advantages/disadvantages of using a cloud base vs an on-premise solution. It would be great if you can share your experience on this matter. Thank you From morrowc.lists at gmail.com Thu Jan 8 19:42:31 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 8 Jan 2015 14:42:31 -0500 Subject: something strange about bgp community In-Reply-To: <54AE9949.6030007@netassist.ua> References: <54AD3627.7020006@gmail.com> <54AE9949.6030007@netassist.ua> Message-ID: On Thu, Jan 8, 2015 at 9:50 AM, Max Tulyev wrote: > Some brain-dead ;) transit providers clear all community when import > announces, but for me it is at least unfair. hrm, it's possible that cleaning the communities (after dealing with the local/customer-added ones) means you may not get multiple copies that differ only in community in your network. this may have the effect of you seeing less route 'churn' overall in your network. From gcroft at unitedshore.com Thu Jan 8 16:31:05 2015 From: gcroft at unitedshore.com (gcroft at unitedshore.com) Date: Thu, 8 Jan 2015 16:31:05 +0000 Subject: XO Peering Question.. Message-ID: Hey All, Quick question for those of you who may be pulling a partial or full table from XO.. Can you tell me your MED/Weight on the routes from them? Please and Thank you. [cid:62CA825B-35AD-469A-B224-9BA199DC5662]GREGORY S CROFT Information Security Engineer gcroft at unitedshore.com p 855.888.8737 ext.4999 p 248.833.4999 UNITEDSHORE.COM United to better serve you. Share your experience at mymanager at unitedshore.com The contents of this message may be confidential. If you are not the intended recipient, do not disseminate, disclose, copy or use this message without the permission of the author. Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and nothing contained herein shall constitute a contract or electronic signature. If this message has been received in error, please delete it immediately. From mel at beckman.org Thu Jan 8 17:11:36 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 8 Jan 2015 17:11:36 +0000 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: BlackLotus.com looks very good, with GRE tunneling and sensible provider level pricing. -mel via cell > On Jan 8, 2015, at 9:06 AM, "Manuel Marín" wrote: > > Nanog group > > I was wondering what are are using for DDOS protection in your networks. We > are currently evaluating different options (Arbor, Radware, NSFocus, > RioRey) and I would like to know if someone is using the cloud based > solutions/scrubbing centers like Imperva, Prolexic, etc and what are the > advantages/disadvantages of using a cloud base vs an on-premise solution. > It would be great if you can share your experience on this matter. > > Thank you From josh at 2cold.net Thu Jan 8 20:44:48 2015 From: josh at 2cold.net (Joshua McDonald) Date: Thu, 8 Jan 2015 15:44:48 -0500 Subject: XO Peering Question.. In-Reply-To: References: Message-ID: <634DCD03-7797-4D13-8BA6-9C2943BD7A10@2cold.net> I am seeing a MED of 3 from XO. Josh > On Jan 8, 2015, at 11:31 AM, wrote: > > Hey All, > Quick question for those of you who may be pulling a partial or full table from XO.. > > Can you tell me your MED/Weight on the routes from them? > > Please and Thank you. > > > > > [cid:62CA825B-35AD-469A-B224-9BA199DC5662]GREGORY S CROFT Information Security Engineer > gcroft at unitedshore.com > p 855.888.8737 ext.4999 > p 248.833.4999 > UNITEDSHORE.COM > > > United to better serve you. > Share your experience at mymanager at unitedshore.com > > The contents of this message may be confidential. If you are not the intended recipient, do not disseminate, disclose, copy or use this message without the permission of the author. Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and nothing contained herein shall constitute a contract or electronic signature. If this message has been received in error, please delete it immediately. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From frnkblk at iname.com Thu Jan 8 23:54:33 2015 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 8 Jan 2015 17:54:33 -0600 Subject: Google's Safe Browsing Alerts for Network Administrators Message-ID: <000101d02b9e$736488e0$5a2d9aa0$@iname.com> I want to make this forum aware of Google's "Safe Browsing Alerts for Network Administrators" (https://www.google.com/safebrowsing/alerts/). I've had a link to their diagnostic page for several years (https://www.google.com/safebrowsing/diagnostic?site=AS:####&hl=it-it, where #### is your ASN), but I didn't know that Google actually had a way to alert ASN owners of new incidents. I checked NANOG's archive and haven't ever seen it mentioned, so I thought there might be more like me that weren't aware. And while I'm on the subject, I want to make people aware of somewhat related service by ShadowServer (https://www.shadowserver.org/wiki/pmwiki.php/Involve/GetReportsOnYourNetwor k). Frank From lists at sadiqs.com Fri Jan 9 00:53:54 2015 From: lists at sadiqs.com (Sadiq Saif) Date: Thu, 08 Jan 2015 19:53:54 -0500 Subject: whois server features In-Reply-To: References: Message-ID: <54AF26A2.5090200@sadiqs.com> On 1/8/2015 09:02, shawn wilson wrote: > Awesome thanks. That answers half of my original question (though this > route was much more insightful than I thought). I can run with that (php > isn't my language but the etl is pretty clear). > There is a Python module if that is more your thing: https://pypi.python.org/pypi/pythonwhois -- Sadiq Saif https://staticsafe.ca From mloftis at wgops.com Fri Jan 9 01:37:21 2015 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 8 Jan 2015 17:37:21 -0800 Subject: Google's Safe Browsing Alerts for Network Administrators In-Reply-To: <000101d02b9e$736488e0$5a2d9aa0$@iname.com> References: <000101d02b9e$736488e0$5a2d9aa0$@iname.com> Message-ID: My problem with Google's "Safe Browsing" alerts is that from the admin side they rarely are useful/useable. They make a big loud noisy complaint without ANYTHING to substantiate what the issue is to correct it. You're left searching your own site trying to figure out what in the heck it's complaining about. On Thu, Jan 8, 2015 at 3:54 PM, Frank Bulk wrote: > I want to make this forum aware of Google's "Safe Browsing Alerts for > Network Administrators" (https://www.google.com/safebrowsing/alerts/). I've > had a link to their diagnostic page for several years > (https://www.google.com/safebrowsing/diagnostic?site=AS:####&hl=it-it, where > #### is your ASN), but I didn't know that Google actually had a way to alert > ASN owners of new incidents. I checked NANOG's archive and haven't ever > seen it mentioned, so I thought there might be more like me that weren't > aware. > > And while I'm on the subject, I want to make people aware of somewhat > related service by ShadowServer > (https://www.shadowserver.org/wiki/pmwiki.php/Involve/GetReportsOnYourNetwor > k). > > Frank > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From blakjak at blakjak.net Fri Jan 9 02:05:36 2015 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 09 Jan 2015 15:05:36 +1300 Subject: Google's Safe Browsing Alerts for Network Administrators In-Reply-To: References: <000101d02b9e$736488e0$5a2d9aa0$@iname.com> Message-ID: <54AF3770.8040401@blakjak.net> I've had my team report false-positives with the Safe Browsing reports as well. On 9/01/2015 2:37 p.m., Michael Loftis wrote: > My problem with Google's "Safe Browsing" alerts is that from the admin > side they rarely are useful/useable. They make a big loud noisy > complaint without ANYTHING to substantiate what the issue is to > correct it. You're left searching your own site trying to figure out > what in the heck it's complaining about. > > On Thu, Jan 8, 2015 at 3:54 PM, Frank Bulk wrote: >> I want to make this forum aware of Google's "Safe Browsing Alerts for >> Network Administrators" (https://www.google.com/safebrowsing/alerts/). I've >> had a link to their diagnostic page for several years >> (https://www.google.com/safebrowsing/diagnostic?site=AS:####&hl=it-it, where >> #### is your ASN), but I didn't know that Google actually had a way to alert >> ASN owners of new incidents. I checked NANOG's archive and haven't ever >> seen it mentioned, so I thought there might be more like me that weren't >> aware. >> >> And while I'm on the subject, I want to make people aware of somewhat >> related service by ShadowServer >> (https://www.shadowserver.org/wiki/pmwiki.php/Involve/GetReportsOnYourNetwor >> k). >> >> Frank >> > > From bob at FiberInternetCenter.com Fri Jan 9 03:59:07 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 8 Jan 2015 19:59:07 -0800 Subject: Office 365 Expert In-Reply-To: <54AEBE1B.50203@opus1.com> References: <54AEBE1B.50203@opus1.com> Message-ID: <25b32c1e9a59dea873907d0c08efa4a7.squirrel@66.201.44.180> Thanks for your input Joel...Yes, it's a lot of bandwidth, today. In fact, our smallest customer is 10 meg/sec. Our biggest is 10 Gig/second. Here in Silicon Valley California most companies are outsourcing everything except the circuit they need to access it..it's the new portability initiative! I recall 13 years ago when I said I was going to start a Fiber Only ISP...everyone including my previous VCs, Hedge Funds and business partners in my first ISP laughed at me. It was the Dot Bomb period. Today, everyone here asks for fiber to do all this crazy things they now can't live without. It's all about Bigger, Faster, Cheaper and mostly Store it someplace else that has lead to these big pipes. Thank You Bob Evans CTO > >My suggested rule of thumb if you can't actually measure the traffic > >in advance for your population: count the number of > >workstation devices that will be your network, > >figure at least 0.5 Megabit of WAN for each typical business > >user workstation or laptop. > > I can't help but laugh (laughing with, not laughing at--all due respect > to the NA part of NANOG) at this. > > I've been spending the last 4 years working on various UN networks where > getting 0.5Mb of bandwidth to a site can be a challenge, and 4 > Mbit/second for an office of 8 users is an unaffordable luxury. And > these are sites where the end users want to move to Office 365. > > We've done a bit of testing, and one of the issues with O365 is that > O365 is a BIG thing and you have to decide which slice of O365 you are > calling "O365" at a particular site. > > For some people, that's just "outsourced Exchange" (in which case we > would allocate 30K-50Kbps per office user downstream bandwidth, and drop > in a WAN Opt box plus do some shenanigans to break into the HTTPS > through proxy). > > For other people, O365 is the whole "nothing is on my hard disk (but > cache)" thing, plus Lync (not just voice, but voice+video). Those folks > really are going to require major bandwidth; this is where numbers like > 512K/simultaneous user make more sense. > > You can excuse (or at least explain) Microsoft's lack of benchmarks and > guidance because of the complexity of O365 and also because they have > the sort of North American viewpoint that makes it hard for them to > understand high latency/low bandwidth pipes. > > They try hard, but often just don't get it because of the amazing > resources and richness available to a company of that size. I had a > great conversation with them about 3 years ago about Exchange and AD > forest design where they were strongly advocating centralizing > everything in data centers, rather than pushing anything like a DC or > mailbox server out to a branch office. When I asked about the bandwidth > required, they said that it was "not much." Pressed for details, they > said "we do it ourselves, and it hardly impacts the bandwidth on our > most poorly-connected offices." Pressed even further, it turns out that > a T3/E3 is the lowest link they would consider acceptable for an office. > (My total upstream bandwidth budget at one agency for 100 offices and > 9,000 users in 24 timezones is less than a single T3... Thanks Microsoft!) > > Anyway, not adding much to this conversation since it's clear that Bob > is asking in the context of "bandwidth is cheap, fast, and inexpensive," > but I couldn't help but giggle at the kinds of numbers you guys are > throwing around here for people to read email and work on spreadsheets. > > 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 mawatari at jpix.ad.jp Fri Jan 9 08:58:56 2015 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Fri, 09 Jan 2015 17:58:56 +0900 Subject: IPv6 survey (JANOG 35 IPv6 session) In-Reply-To: <20141225174627.E0C3.8FE1F57E@jpix.ad.jp> References: <20141225174627.E0C3.8FE1F57E@jpix.ad.jp> Message-ID: <20150109175855.1341.8FE1F57E@jpix.ad.jp> Just a reminder. The fill-out deadline of the survey is 14:59 Fri 9 Jan [UTC]. https://www.janog.gr.jp/meeting/janog35/program/ipv6/ipv6_form_en/ Looking forward to hearing from you! Thanks in advance. Masataka, * On Thu, 25 Dec 2014 17:46:27 +0900 * MAWATARI Masataka wrote: > Hi all, > > > JANOG will have a session "Why don't we want to deploy IPv6?" in > JANOG 35 meeting next month. It will focus on IPv6 deployment > of the contents providers in Japan. > > To help us make this session better, we carry out a questionnaire > survey to the service providers. > > It would be great if you could fill out the following questionnaire: > https://www.janog.gr.jp/meeting/janog35/program/ipv6/ipv6_form_en/ > > Your co-operation will be appreciated. > We will make a good use out of the survey information in order to > improve this session. > > > We'll update you with more details about JANOG 35 meeting through > the following page. > http://www.janog.gr.jp/en/index.php?JANOG35_Meeting > > > Happy Holidays! -- Japan Internet Exchange MAWATARI Masataka From pavel.odintsov at gmail.com Fri Jan 9 15:41:04 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Fri, 9 Jan 2015 19:41:04 +0400 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: I could suggest Voxility.com because they have very good network and can defense any protocol. And I can recommend qrator.net as best solution agains http/https attacks. We use they for 2 years and got only positive feedback. And if you need only ability to reroute to antiddos cloud/blackhole specific IP you could try my open source tool FastNetMon: https://github.com/FastVPSEestiOu/fastnetmon Thank you! On Thu, Jan 8, 2015 at 8:11 PM, Mel Beckman wrote: > BlackLotus.com looks very good, with GRE tunneling and sensible provider level pricing. > > -mel via cell > >> On Jan 8, 2015, at 9:06 AM, "Manuel Marín" wrote: >> >> Nanog group >> >> I was wondering what are are using for DDOS protection in your networks. We >> are currently evaluating different options (Arbor, Radware, NSFocus, >> RioRey) and I would like to know if someone is using the cloud based >> solutions/scrubbing centers like Imperva, Prolexic, etc and what are the >> advantages/disadvantages of using a cloud base vs an on-premise solution. >> It would be great if you can share your experience on this matter. >> >> Thank you -- Sincerely yours, Pavel Odintsov From cscora at apnic.net Fri Jan 9 18:12:16 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Jan 2015 04:12:16 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201501091812.t09ICGIQ011895@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 10 Jan, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 525347 Prefixes after maximum aggregation (per Origin AS): 201896 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 256875 Total ASes present in the Internet Routing Table: 49026 Prefixes per ASN: 10.72 Origin-only ASes present in the Internet Routing Table: 36384 Origin ASes announcing only one prefix: 16299 Transit ASes present in the Internet Routing Table: 6209 Transit-only ASes present in the Internet Routing Table: 173 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 107 Max AS path prepend of ASN ( 55644) 100 Prefixes from unregistered ASNs in the Routing Table: 1623 Unregistered ASNs in the Routing Table: 422 Number of 32-bit ASNs allocated by the RIRs: 8322 Number of 32-bit ASNs visible in the Routing Table: 6433 Prefixes from 32-bit ASNs in the Routing Table: 23156 Number of bogon 32-bit ASNs visible in the Routing Table: 11 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 401 Number of addresses announced to Internet: 2719145860 Equivalent to 162 /8s, 18 /16s and 223 /24s Percentage of available address space announced: 73.4 Percentage of allocated address space announced: 73.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.1 Total number of prefixes smaller than registry allocations: 176964 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 130059 Total APNIC prefixes after maximum aggregation: 37934 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 134952 Unique aggregates announced from the APNIC address blocks: 55075 APNIC Region origin ASes present in the Internet Routing Table: 5010 APNIC Prefixes per ASN: 26.94 APNIC Region origin ASes announcing only one prefix: 1218 APNIC Region transit ASes present in the Internet Routing Table: 861 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1241 Number of APNIC addresses announced to Internet: 740849792 Equivalent to 44 /8s, 40 /16s and 120 /24s Percentage of available APNIC address space announced: 86.6 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, 131072-135580 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: 174417 Total ARIN prefixes after maximum aggregation: 86316 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 176340 Unique aggregates announced from the ARIN address blocks: 82430 ARIN Region origin ASes present in the Internet Routing Table: 16418 ARIN Prefixes per ASN: 10.74 ARIN Region origin ASes announcing only one prefix: 6074 ARIN Region transit ASes present in the Internet Routing Table: 1713 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 19 Number of ARIN region 32-bit ASNs visible in the Routing Table: 311 Number of ARIN addresses announced to Internet: 1055687168 Equivalent to 62 /8s, 236 /16s and 130 /24s Percentage of available ARIN address space announced: 55.8 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, 393216-394239 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: 125943 Total RIPE prefixes after maximum aggregation: 63692 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 132016 Unique aggregates announced from the RIPE address blocks: 82815 RIPE Region origin ASes present in the Internet Routing Table: 17833 RIPE Prefixes per ASN: 7.40 RIPE Region origin ASes announcing only one prefix: 8158 RIPE Region transit ASes present in the Internet Routing Table: 2930 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3333 Number of RIPE addresses announced to Internet: 692667524 Equivalent to 41 /8s, 73 /16s and 68 /24s Percentage of available RIPE address space announced: 100.7 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, 196608-202239 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: 59140 Total LACNIC prefixes after maximum aggregation: 10937 LACNIC Deaggregation factor: 5.41 Prefixes being announced from the LACNIC address blocks: 68189 Unique aggregates announced from the LACNIC address blocks: 31219 LACNIC Region origin ASes present in the Internet Routing Table: 2395 LACNIC Prefixes per ASN: 28.47 LACNIC Region origin ASes announcing only one prefix: 645 LACNIC Region transit ASes present in the Internet Routing Table: 471 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1464 Number of LACNIC addresses announced to Internet: 167448448 Equivalent to 9 /8s, 251 /16s and 15 /24s Percentage of available LACNIC address space announced: 99.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12518 Total AfriNIC prefixes after maximum aggregation: 2973 AfriNIC Deaggregation factor: 4.21 Prefixes being announced from the AfriNIC address blocks: 13449 Unique aggregates announced from the AfriNIC address blocks: 4979 AfriNIC Region origin ASes present in the Internet Routing Table: 734 AfriNIC Prefixes per ASN: 18.32 AfriNIC Region origin ASes announcing only one prefix: 204 AfriNIC Region transit ASes present in the Internet Routing Table: 153 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 84 Number of AfriNIC addresses announced to Internet: 60960512 Equivalent to 3 /8s, 162 /16s and 47 /24s Percentage of available AfriNIC address space announced: 60.6 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 4766 2915 11556 911 Korea Telecom 17974 2825 904 77 PT Telekomunikasi Indonesia 7545 2495 336 128 TPG Telecom Limited 4755 1931 418 191 TATA Communications formerly 4538 1757 4190 71 China Education and Research 9829 1675 1323 28 National Internet Backbone 9808 1523 6719 19 Guangdong Mobile Communicatio 4808 1441 2205 433 CNCGROUP IP network China169 9583 1388 115 571 Sify Limited 9498 1300 336 97 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 2931 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2560 10684 473 Level 3 Communications, Inc. 18566 2042 379 183 MegaPath Corporation 20115 1854 1825 450 Charter Communications 6983 1626 867 245 EarthLink, Inc. 4323 1623 1037 408 tw telecom holdings, inc. 30036 1511 312 574 Mediacom Communications Corp 701 1412 11278 696 MCI Communications Services, 22561 1339 411 241 CenturyTel Internet Holdings, 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 34984 1933 300 356 TELLCOM ILETISIM HIZMETLERI A 20940 1540 598 1136 Akamai International B.V. 8402 1445 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 1036 97 54 TOV "Bank-Inform" 8551 905 373 48 Bezeq International-Ltd 9198 859 349 26 JSC Kazakhtelecom 12479 830 794 85 France Telecom Espana SA 6830 824 2340 444 Liberty Global Operations B.V 9121 599 1693 22 Turk Telekomunikasyon Anonim 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 3055 495 247 Telmex Colombia S.A. 28573 2317 2127 114 NET Servi�os de Comunica��o S 6147 1790 374 30 Telefonica del Peru S.A.A. 7303 1768 1172 237 Telecom Argentina S.A. 8151 1486 3054 431 Uninet S.A. de C.V. 6503 1227 417 57 Axtel, S.A.B. de C.V. 7738 1000 1882 42 Telemar Norte Leste S.A. 3816 914 396 148 COLOMBIA TELECOMUNICACIONES S 26615 913 2325 35 Tim Celular S.A. 27947 890 129 50 Telconet S.A 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 8452 1486 958 13 TE-AS 24863 951 284 26 Link Egypt (Link.NET) 36903 482 243 89 Office National des Postes et 36992 369 845 30 ETISALAT MISR 37492 347 145 64 Orange Tunisie 24835 295 144 9 Vodafone Data 3741 248 921 213 Internet Solutions 29571 233 21 12 Cote d'Ivoire Telecom 36947 197 807 13 Telecom Algeria 15706 176 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3055 495 247 Telmex Colombia S.A. 22773 2931 2955 141 Cox Communications Inc. 4766 2915 11556 911 Korea Telecom 6389 2891 3688 51 BellSouth.net Inc. 17974 2825 904 77 PT Telekomunikasi Indonesia 3356 2560 10684 473 Level 3 Communications, Inc. 7545 2495 336 128 TPG Telecom Limited 28573 2317 2127 114 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation 34984 1933 300 356 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2891 2840 BellSouth.net Inc. 22773 2931 2790 Cox Communications Inc. 17974 2825 2748 PT Telekomunikasi Indonesia 7545 2495 2367 TPG Telecom Limited 28573 2317 2203 NET Servi�os de Comunica��o S 3356 2560 2087 Level 3 Communications, Inc. 4766 2915 2004 Korea Telecom 18566 2042 1859 MegaPath Corporation 6147 1790 1760 Telefonica del Peru S.A.A. 4755 1931 1740 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.92.160.0/24 14013 EPSON America (Factory Automa 23.92.161.0/24 14013 EPSON America (Factory Automa 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 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:12 /10:31 /11:92 /12:265 /13:502 /14:997 /15:1726 /16:13047 /17:7178 /18:11969 /19:24822 /20:35620 /21:38222 /22:56653 /23:49225 /24:282014 /25:1143 /26:1083 /27:679 /28:17 /29:15 /30:10 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2145 2931 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1358 1511 Mediacom Communications Corp 6147 1333 1790 Telefonica del Peru S.A.A. 6983 1312 1626 EarthLink, Inc. 34984 1238 1933 TELLCOM ILETISIM HIZMETLERI A 11492 1123 1182 CABLE ONE, INC. 8402 1109 1445 OJSC "Vimpelcom" 10620 1090 3055 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1415 2:672 3:3 4:95 5:1208 6:21 8:1407 11:1 12:1838 13:4 14:1235 15:17 16:2 17:45 18:21 20:51 23:1087 24:1669 27:1816 31:1472 32:39 33:2 34:5 35:1 36:138 37:1871 38:968 39:14 40:228 41:3035 42:288 43:885 44:21 45:86 46:2137 47:32 49:730 50:783 52:12 54:60 55:8 56:8 57:33 58:1119 59:677 60:451 61:1752 62:1283 63:1886 64:4395 65:2262 66:4070 67:2004 68:1037 69:3248 70:908 71:426 72:1962 74:2617 75:314 76:410 77:1366 78:1055 79:784 80:1322 81:1303 82:796 83:670 84:677 85:1307 86:382 87:1199 88:522 89:1770 90:138 91:5878 92:785 93:1678 94:1936 95:1418 96:420 97:338 98:1046 99:48 100:70 101:799 103:6447 104:972 105:110 106:199 107:890 108:610 109:2037 110:1059 111:1462 112:745 113:958 114:802 115:1244 116:1319 117:1037 118:1672 119:1393 120:439 121:1020 122:2196 123:1715 124:1470 125:1523 128:643 129:373 130:384 131:1081 132:446 133:167 134:389 135:88 136:331 137:300 138:387 139:177 140:224 141:421 142:619 143:444 144:511 145:111 146:705 147:569 148:1062 149:406 150:542 151:594 152:473 153:245 154:289 155:667 156:392 157:331 158:260 159:949 160:369 161:631 162:1861 163:371 164:647 165:662 166:322 167:710 168:1159 169:135 170:1427 171:221 172:50 173:1566 174:705 175:598 176:1480 177:3682 178:2098 179:810 180:1849 181:1695 182:1695 183:574 184:728 185:2609 186:2940 187:1688 188:2000 189:1550 190:7898 191:837 192:7977 193:5561 194:4062 195:3631 196:1694 197:867 198:5460 199:5495 200:6544 201:2963 202:9509 203:9025 204:4655 205:2703 206:3003 207:2969 208:3908 209:3853 210:3492 211:1836 212:2528 213:2257 214:839 215:77 216:5526 217:1764 218:663 219:457 220:1316 221:783 222:460 223:680 End of report From cidr-report at potaroo.net Fri Jan 9 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Jan 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201501092200.t09M00m5066759@wattle.apnic.net> This report has been generated at Fri Jan 9 21:14:22 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 02-01-15 529540 291853 03-01-15 529526 292022 04-01-15 529679 292063 05-01-15 531171 291938 06-01-15 529585 292403 07-01-15 530471 292497 08-01-15 530416 292577 09-01-15 530957 293031 AS Summary 49289 Number of ASes in routing system 19772 Number of ASes announcing only one prefix 3055 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120393216 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 09Jan15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 530925 292944 237981 44.8% All ASes AS6389 2890 69 2821 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2933 172 2761 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2825 77 2748 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS28573 2317 309 2008 86.7% NET Servi�os de Comunica��o S.A.,BR AS4755 1930 284 1646 85.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS6147 1790 159 1631 91.1% Telefonica del Peru S.A.A.,PE AS4766 2915 1290 1625 55.7% KIXS-AS-KR Korea Telecom,KR AS7303 1771 288 1483 83.7% Telecom Argentina S.A.,AR AS9808 1522 56 1466 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 3055 1598 1457 47.7% Telmex Colombia S.A.,CO AS8402 1424 26 1398 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1855 531 1324 71.4% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2507 1269 1238 49.4% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1630 410 1220 74.8% TWTC - tw telecom holdings, inc.,US AS9498 1300 111 1189 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2041 868 1173 57.5% MEGAPATH5-US - MegaPath Corporation,US AS22561 1339 269 1070 79.9% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7552 1118 49 1069 95.6% VIETEL-AS-AP Viettel Corporation,VN AS34984 1933 871 1062 54.9% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS3356 2561 1507 1054 41.2% LEVEL3 - Level 3 Communications, Inc.,US AS6983 1627 634 993 61.0% ITCDELTA - Earthlink, Inc.,US AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1775 908 867 48.8% ERX-CERNET-BKB China Education and Research Network Center,CN AS31148 1045 190 855 81.8% FREENET-AS Freenet Ltd.,UA AS24560 1192 375 817 68.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS8151 1491 702 789 52.9% Uninet S.A. de C.V.,MX AS18881 856 82 774 90.4% Global Village Telecom,BR AS26615 913 139 774 84.8% Tim Celular S.A.,BR AS18101 954 193 761 79.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN Total 53492 13633 39859 74.5% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.92.160.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.92.161.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 62.122.72.0/23 AS19979 DEPO40-AS Trusov Ilya Igorevych,RU 62.122.74.0/23 AS5577 ROOT root SA,LU 62.122.76.0/22 AS19979 DEPO40-AS Trusov Ilya Igorevych,RU 64.18.128.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 64.187.208.0/24 AS174 COGENT-174 - Cogent Communications,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.50.0/24 AS9009 M247 M247 Ltd,BE 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.124.0/24 AS45355 DIGICELPACIFIC-1-AP Clarendon House,FJ 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.30.196.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.243.72.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.243.73.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.243.74.0/23 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.243.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.252.116.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.253.128.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM",RU 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 186.65.108.0/22 AS22927 Telefonica de Argentina,AR 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS3322 -Reserved AS-,ZZ 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.227.0/24 AS43993 GRIFIN-AS Grifin Ltd,RU 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.18.0/24 AS33790 -Reserved AS-,ZZ 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.61.108.0/24 AS55812 202.61.118.0/24 AS55833 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.8.216.0/21 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 204.8.217.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 204.8.218.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 204.8.222.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 209.250.224.0/22 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.224.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.225.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.230.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 209.250.253.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 209.250.254.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.24.208.0/24 AS3561 SAVVIS - Savvis,US 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 9 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Jan 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201501092200.t09M02Nc066772@wattle.apnic.net> BGP Update Report Interval: 01-Jan-15 -to- 08-Jan-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 307612 8.3% 4961.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 154142 4.2% 132.7 -- BSNL-NIB National Internet Backbone,IN 3 - AS9198 96119 2.6% 111.4 -- KAZTELECOM-AS JSC Kazakhtelecom,KZ 4 - AS22047 90559 2.5% 22.8 -- VTR BANDA ANCHA S.A.,CL 5 - AS53249 79167 2.1% 39583.5 -- LAWA-AS - Los Angeles World Airport,US 6 - AS45899 56209 1.5% 75.1 -- VNPT-AS-VN VNPT Corp,VN 7 - AS3 47332 1.3% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - AS36925 32106 0.9% 406.4 -- ASMedi,MA 9 - AS3816 28309 0.8% 59.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 10 - AS28024 27536 0.8% 18.0 -- Nuevatel PCS de Bolivia S.A.,BO 11 - AS10620 25849 0.7% 17.2 -- Telmex Colombia S.A.,CO 12 - AS17099 25513 0.7% 2126.1 -- CALLIS-COMMUNICATIONS-AS - Callis Communications,US 13 - AS64512 25478 0.7% 1959.8 -- -Private Use AS-,ZZ 14 - AS60725 23227 0.6% 7742.3 -- O3B-AS O3b Limited,JE 15 - AS23342 21941 0.6% 10970.5 -- UNITEDLAYER - Unitedlayer, Inc.,US 16 - AS9038 21689 0.6% 380.5 -- BAT-AS9038 Batelco Jordan,JO 17 - AS7552 21440 0.6% 19.1 -- VIETEL-AS-AP Viettel Corporation,VN 18 - AS11054 20834 0.6% 672.1 -- LIVEPERSON - LivePerson, Inc.,US 19 - AS12066 20353 0.6% 142.3 -- TRICOM,DO 20 - AS48159 20260 0.6% 70.3 -- TIC-AS Telecommunication Infrastructure Company,IR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3 47332 1.3% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 2 - AS53249 79167 2.1% 39583.5 -- LAWA-AS - Los Angeles World Airport,US 3 - AS61039 13973 0.4% 13973.0 -- ZMZ OAO ZMZ,RU 4 - AS23342 21941 0.6% 10970.5 -- UNITEDLAYER - Unitedlayer, Inc.,US 5 - AS6629 10519 0.3% 10519.0 -- NOAA-AS - NOAA,US 6 - AS18135 8855 0.2% 8855.0 -- BTV BTV Cable television,JP 7 - AS54465 8162 0.2% 8162.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 8 - AS60725 23227 0.6% 7742.3 -- O3B-AS O3b Limited,JE 9 - AS58252 5054 0.1% 5054.0 -- ASN-RINGLOUD Netuity Limited,GB 10 - AS23752 307612 8.3% 4961.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 11 - AS62174 4956 0.1% 4956.0 -- INTERPAN-AS INTERPAN LTD.,BG 12 - AS33721 4444 0.1% 4444.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 13 - AS58844 3193 0.1% 3193.0 -- OFIDC Guangdong Aofei Data Technology Co., Ltd.,CN 14 - AS21934 2754 0.1% 2754.0 -- VITAC - VITAC Corporation,US 15 - AS11728 2428 0.1% 2428.0 -- INTERNETXT - Internet Exchange Technology, Inc.,US 16 - AS27250 4384 0.1% 2192.0 -- FNCINC - FNC INC,US 17 - AS3 2134 0.1% 1445.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 18 - AS17099 25513 0.7% 2126.1 -- CALLIS-COMMUNICATIONS-AS - Callis Communications,US 19 - AS12521 4202 0.1% 2101.0 -- NOVA_INTERNET_AS12521 Nova Internet Network,ES 20 - AS11613 2047 0.1% 2047.0 -- U-SAVE - U-Save Auto Rental of America, Inc.,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 154317 4.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 152907 4.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 130.0.192.0/21 47332 1.2% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 4 - 198.140.114.0/24 39606 1.0% AS53249 -- LAWA-AS - Los Angeles World Airport,US 5 - 198.140.115.0/24 39561 1.0% AS53249 -- LAWA-AS - Los Angeles World Airport,US 6 - 64.29.130.0/24 21938 0.6% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 7 - 192.115.44.0/22 19452 0.5% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 8 - 182.50.246.0/24 17920 0.5% AS45786 -- HTSNET-AS-ID HTSNET - ISP,ID AS65001 -- -Private Use AS-,ZZ AS65534 -- -Private Use AS-,ZZ 9 - 91.235.169.0/24 13973 0.4% AS61039 -- ZMZ OAO ZMZ,RU 10 - 162.249.183.0/24 11811 0.3% AS60725 -- O3B-AS O3b Limited,JE 11 - 185.26.155.0/24 11409 0.3% AS60725 -- O3B-AS O3b Limited,JE 12 - 192.58.232.0/24 10519 0.3% AS6629 -- NOAA-AS - NOAA,US 13 - 88.87.160.0/19 9632 0.2% AS47680 -- NHCS EOBO Limited,IE 14 - 42.83.48.0/20 8855 0.2% AS18135 -- BTV BTV Cable television,JP 15 - 197.230.128.0/17 8314 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 16 - 41.214.192.0/18 8296 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 17 - 197.253.128.0/17 8236 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 18 - 206.152.15.0/24 8162 0.2% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 19 - 105.188.0.0/14 7880 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 20 - 197.153.0.0/16 7872 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cgrundemann at gmail.com Fri Jan 9 23:09:17 2015 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 9 Jan 2015 16:09:17 -0700 Subject: Join us for the NANOG 63 BCOP Track! Message-ID: Hello NANOG, This is a friendly notification of the BCOP Track to be held at NANOG 63 in San Antonio. We’d (the BCOP Committee) like to invite you to come participate at our track. Participation can take (at least) two forms: 1) Come present your idea for a BCOP! Do you have a question that needs answered about the current operational practice for some portion of your network? Or maybe you have some insight to share about how something is best done? Remember that there are no dumb questions here and no BCOP is too basic or too simple. The things that you take for granted as common sense are new information for many other network engineers all around the world. Come tell us the question you’d love to have answered, or the practice you’d love to see spread! 2) Come observe, and provide feedback. There are currently 4 active NANOG-BCOP drafts: Public Peering Exchange Participant - http://bcop.nanog.org/index.php/Public_Peering_Exchange_Participant_BCOP_v0 Ethernet OAM - http://bcop.nanog.org/images/b/b0/BCOP-Ethernet_OAM-1_v_0.1.5.docx DDoS/DoS Attack - http://bcop.nanog.org/images/e/e2/BCOP-DoS-attack-appeal.docx eBGP Configuration - http://bcop.nanog.org/index.php/EBGP_Configuration_BCOP_v0.1 We will be discussing all of these documents, including considering moving some of them forward for last call and ultimately, publication as community vetted BCOPs! So, come vet them. ;-) We will likely also be discussing the Anti-Spoofing BCOP draft that is set to come out of security community stealth mode any day now. I hope to see many of you at the NANOG 63 BCOP Track in just a few short weeks! Cheers, ~Chris PS - to stay up to date on all things NANOG-BCOP, join our mailing list: http://mailman.nanog.org/mailman/listinfo/bcop PPS - you can also reach the entire commity for questions at: bcop-support at nanog.org -- @ChrisGrundemann http://chrisgrundemann.com From amit.rai at netcerts.net Fri Jan 9 21:41:47 2015 From: amit.rai at netcerts.net (Amit Rai) Date: Fri, 9 Jan 2015 16:41:47 -0500 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: another option would be a service offered by https://www.neustar.biz/services/ddos-protection On Fri, Jan 9, 2015 at 10:41 AM, Pavel Odintsov wrote: > I could suggest Voxility.com because they have very good network and > can defense any protocol. > > And I can recommend qrator.net as best solution agains http/https > attacks. We use they for 2 years and got only positive feedback. > > And if you need only ability to reroute to antiddos cloud/blackhole > specific IP you could try my open source tool FastNetMon: > https://github.com/FastVPSEestiOu/fastnetmon > > Thank you! > > On Thu, Jan 8, 2015 at 8:11 PM, Mel Beckman wrote: > > BlackLotus.com looks very good, with GRE tunneling and sensible provider > level pricing. > > > > -mel via cell > > > >> On Jan 8, 2015, at 9:06 AM, "Manuel Marín" wrote: > >> > >> Nanog group > >> > >> I was wondering what are are using for DDOS protection in your > networks. We > >> are currently evaluating different options (Arbor, Radware, NSFocus, > >> RioRey) and I would like to know if someone is using the cloud based > >> solutions/scrubbing centers like Imperva, Prolexic, etc and what are the > >> advantages/disadvantages of using a cloud base vs an on-premise > solution. > >> It would be great if you can share your experience on this matter. > >> > >> Thank you > > > > -- > Sincerely yours, Pavel Odintsov > -- Thanks, Amit. From charles at thefnf.org Sun Jan 11 00:19:22 2015 From: charles at thefnf.org (Charles N Wyble) Date: Sat, 10 Jan 2015 18:19:22 -0600 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: Also how are folks testing ddos protection? What lab gear,tools,methods are you using to determine effectiveness of the mitigation. On January 8, 2015 11:01:47 AM CST, "Manuel Marín" wrote: >Nanog group > >I was wondering what are are using for DDOS protection in your >networks. We >are currently evaluating different options (Arbor, Radware, NSFocus, >RioRey) and I would like to know if someone is using the cloud based >solutions/scrubbing centers like Imperva, Prolexic, etc and what are >the >advantages/disadvantages of using a cloud base vs an on-premise >solution. >It would be great if you can share your experience on this matter. > >Thank you > >!DSPAM:54aeb96d198072115716976! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From damian at google.com Sun Jan 11 03:48:26 2015 From: damian at google.com (Damian Menscher) Date: Sat, 10 Jan 2015 19:48:26 -0800 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín wrote: > I was wondering what are are using for DDOS protection in your networks. We > are currently evaluating different options (Arbor, Radware, NSFocus, > RioRey) and I would like to know if someone is using the cloud based > solutions/scrubbing centers like Imperva, Prolexic, etc and what are the > advantages/disadvantages of using a cloud base vs an on-premise solution. > It would be great if you can share your experience on this matter. > On-premise solutions are limited by your own bandwidth. Attacks have been publicly reported at 400Gbps, and are rumored to be even larger. If you don't have that much network to spare, then packet loss will occur upstream of your mitigation. Having a good relationship with your network provider(s) can help here, of course. If you go with a cloud-based solution, be wary of their SLA. I've seen some claim 100% uptime (not believable) but of course no refund/credits for downtime. Another provider only provides 20Gbps protection, then will null-route the victim. On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble wrote: > Also how are folks testing ddos protection? What lab gear,tools,methods > are you using to determine effectiveness of the mitigation. Live-fire is the cheapest approach (just requires some creative trolling) but if you want to control the "off" button, cloud VMs can be tailored to your needs. There are also legitimate companies that do network stress testing. Keep in mind that you need to test against a variety of attacks, against all components in the critical path. Attackers aren't particularly methodical, but will still randomly discover any weaknesses you've overlooked. Damian From contact at winterei.se Sun Jan 11 04:37:32 2015 From: contact at winterei.se (Paul S.) Date: Sun, 11 Jan 2015 13:37:32 +0900 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: <54B1FE0C.4060405@winterei.se> While it indeed is true that attacks up to 600 gbit/s (If OVH and CloudFlare's data is to be believed) have been known to happen in the wild, it's very unlikely that you need to mitigate anything close. The average attack is usually around the 10g mark (That too barely) -- so even solutions that service up to 20g work alright. Obviously, concerns are different if you're an enterprise that's a DDoS magnet -- but for general service providers selling 'protected services,' food for thought. On 1/11/2015 午後 12:48, Damian Menscher wrote: > On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín wrote: > >> I was wondering what are are using for DDOS protection in your networks. We >> are currently evaluating different options (Arbor, Radware, NSFocus, >> RioRey) and I would like to know if someone is using the cloud based >> solutions/scrubbing centers like Imperva, Prolexic, etc and what are the >> advantages/disadvantages of using a cloud base vs an on-premise solution. >> It would be great if you can share your experience on this matter. >> > On-premise solutions are limited by your own bandwidth. Attacks have been > publicly reported at 400Gbps, and are rumored to be even larger. If you > don't have that much network to spare, then packet loss will occur upstream > of your mitigation. Having a good relationship with your network > provider(s) can help here, of course. > > If you go with a cloud-based solution, be wary of their SLA. I've seen > some claim 100% uptime (not believable) but of course no refund/credits for > downtime. Another provider only provides 20Gbps protection, then will > null-route the victim. > > On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble wrote: > >> Also how are folks testing ddos protection? What lab gear,tools,methods >> are you using to determine effectiveness of the mitigation. > > Live-fire is the cheapest approach (just requires some creative trolling) > but if you want to control the "off" button, cloud VMs can be tailored to > your needs. There are also legitimate companies that do network stress > testing. > > Keep in mind that you need to test against a variety of attacks, against > all components in the critical path. Attackers aren't particularly > methodical, but will still randomly discover any weaknesses you've > overlooked. > > Damian From ammar at fastreturn.net Sun Jan 11 04:50:01 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sun, 11 Jan 2015 08:50:01 +0400 Subject: DDOS solution recommendation In-Reply-To: <54B1FE0C.4060405@winterei.se> References: <54B1FE0C.4060405@winterei.se> Message-ID: <98868920-8D0C-4613-B047-4BA321DEEC18@fastreturn.net> I'd beg to differ on this one. The average attacks we're seeing are double that, around the 30-40g mark. Since NTP and SSDP amplification began, we've been seeing all kinds of large attacks. Obviously, these can easily be blocked upstream to your network. Hibernia Networks blocks them for us. Ammar > On 11 Jan 2015, at 8:37 am, Paul S. wrote: > > While it indeed is true that attacks up to 600 gbit/s (If OVH and CloudFlare's data is to be believed) have been known to happen in the wild, it's very unlikely that you need to mitigate anything close. > > The average attack is usually around the 10g mark (That too barely) -- so even solutions that service up to 20g work alright. > > Obviously, concerns are different if you're an enterprise that's a DDoS magnet -- but for general service providers selling 'protected services,' food for thought. > >> On 1/11/2015 午後 12:48, Damian Menscher wrote: >>> On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín wrote: >>> >>> I was wondering what are are using for DDOS protection in your networks. We >>> are currently evaluating different options (Arbor, Radware, NSFocus, >>> RioRey) and I would like to know if someone is using the cloud based >>> solutions/scrubbing centers like Imperva, Prolexic, etc and what are the >>> advantages/disadvantages of using a cloud base vs an on-premise solution. >>> It would be great if you can share your experience on this matter. >> On-premise solutions are limited by your own bandwidth. Attacks have been >> publicly reported at 400Gbps, and are rumored to be even larger. If you >> don't have that much network to spare, then packet loss will occur upstream >> of your mitigation. Having a good relationship with your network >> provider(s) can help here, of course. >> >> If you go with a cloud-based solution, be wary of their SLA. I've seen >> some claim 100% uptime (not believable) but of course no refund/credits for >> downtime. Another provider only provides 20Gbps protection, then will >> null-route the victim. >> >>> On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble wrote: >>> >>> Also how are folks testing ddos protection? What lab gear,tools,methods >>> are you using to determine effectiveness of the mitigation. >> >> Live-fire is the cheapest approach (just requires some creative trolling) >> but if you want to control the "off" button, cloud VMs can be tailored to >> your needs. There are also legitimate companies that do network stress >> testing. >> >> Keep in mind that you need to test against a variety of attacks, against >> all components in the critical path. Attackers aren't particularly >> methodical, but will still randomly discover any weaknesses you've >> overlooked. >> >> Damian > From rdobbins at arbor.net Sun Jan 11 04:51:05 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 11 Jan 2015 11:51:05 +0700 Subject: DDOS solution recommendation In-Reply-To: <54B1FE0C.4060405@winterei.se> References: <54B1FE0C.4060405@winterei.se> Message-ID: On Jan 11, 2015, at 11:37 AM, Paul S. wrote: > Obviously, concerns are different if you're an enterprise that's a DDoS magnet -- but for general service providers selling 'protected services,' food for thought. Actually, bystander traffic is all-too-often affected by these very large reflection/amplification attacks, because they fill up peering/transit links: [Full disclosure: I work for a provider of IDMS solutions, but there's no vendor propaganda in the above-linked .pdf preso.] ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laocoön From contact at winterei.se Sun Jan 11 05:03:06 2015 From: contact at winterei.se (Paul S.) Date: Sun, 11 Jan 2015 14:03:06 +0900 Subject: DDOS solution recommendation In-Reply-To: <98868920-8D0C-4613-B047-4BA321DEEC18@fastreturn.net> References: <54B1FE0C.4060405@winterei.se> <98868920-8D0C-4613-B047-4BA321DEEC18@fastreturn.net> Message-ID: <54B2040A.40503@winterei.se> Seeing a lot of SSDP too, but attacks on scales that large have been rare (at least for us). Have however seen a few 40+ ones, yeah. I suppose it all comes down to how much you actually /need/ to stand up against. For enterprises that can't afford to go down, yeah... :( On 1/11/2015 午後 01:50, Ammar Zuberi wrote: > I'd beg to differ on this one. The average attacks we're seeing are double that, around the 30-40g mark. Since NTP and SSDP amplification began, we've been seeing all kinds of large attacks. > > Obviously, these can easily be blocked upstream to your network. Hibernia Networks blocks them for us. > > Ammar > >> On 11 Jan 2015, at 8:37 am, Paul S. wrote: >> >> While it indeed is true that attacks up to 600 gbit/s (If OVH and CloudFlare's data is to be believed) have been known to happen in the wild, it's very unlikely that you need to mitigate anything close. >> >> The average attack is usually around the 10g mark (That too barely) -- so even solutions that service up to 20g work alright. >> >> Obviously, concerns are different if you're an enterprise that's a DDoS magnet -- but for general service providers selling 'protected services,' food for thought. >> >>> On 1/11/2015 午後 12:48, Damian Menscher wrote: >>>> On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín wrote: >>>> >>>> I was wondering what are are using for DDOS protection in your networks. We >>>> are currently evaluating different options (Arbor, Radware, NSFocus, >>>> RioRey) and I would like to know if someone is using the cloud based >>>> solutions/scrubbing centers like Imperva, Prolexic, etc and what are the >>>> advantages/disadvantages of using a cloud base vs an on-premise solution. >>>> It would be great if you can share your experience on this matter. >>> On-premise solutions are limited by your own bandwidth. Attacks have been >>> publicly reported at 400Gbps, and are rumored to be even larger. If you >>> don't have that much network to spare, then packet loss will occur upstream >>> of your mitigation. Having a good relationship with your network >>> provider(s) can help here, of course. >>> >>> If you go with a cloud-based solution, be wary of their SLA. I've seen >>> some claim 100% uptime (not believable) but of course no refund/credits for >>> downtime. Another provider only provides 20Gbps protection, then will >>> null-route the victim. >>> >>>> On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble wrote: >>>> >>>> Also how are folks testing ddos protection? What lab gear,tools,methods >>>> are you using to determine effectiveness of the mitigation. >>> Live-fire is the cheapest approach (just requires some creative trolling) >>> but if you want to control the "off" button, cloud VMs can be tailored to >>> your needs. There are also legitimate companies that do network stress >>> testing. >>> >>> Keep in mind that you need to test against a variety of attacks, against >>> all components in the critical path. Attackers aren't particularly >>> methodical, but will still randomly discover any weaknesses you've >>> overlooked. >>> >>> Damian From contact at winterei.se Sun Jan 11 05:05:25 2015 From: contact at winterei.se (Paul S.) Date: Sun, 11 Jan 2015 14:05:25 +0900 Subject: DDOS solution recommendation In-Reply-To: References: <54B1FE0C.4060405@winterei.se> Message-ID: <54B20495.6070009@winterei.se> Very true. Last year's Atrato outages in NY come to mind on this one. On 1/11/2015 午後 01:51, Roland Dobbins wrote: > On Jan 11, 2015, at 11:37 AM, Paul S. wrote: > >> Obviously, concerns are different if you're an enterprise that's a DDoS magnet -- but for general service providers selling 'protected services,' food for thought. > Actually, bystander traffic is all-too-often affected by these very large reflection/amplification attacks, because they fill up peering/transit links: > > > > [Full disclosure: I work for a provider of IDMS solutions, but there's no vendor propaganda in the above-linked .pdf preso.] > > ---------------------------------------------------------------------- > Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laocoön > From sathya.varadharajan at gmail.com Sun Jan 11 04:32:54 2015 From: sathya.varadharajan at gmail.com (Sathya Varadharajan) Date: Sat, 10 Jan 2015 23:32:54 -0500 Subject: DDOS solution recommendation In-Reply-To: References: Message-ID: This gives some comparison of cloud based Ddos mitigation providers. https://www.ombud.com/product/compare/prolexic-ddos-protection On Jan 10, 2015 10:50 PM, "Damian Menscher" wrote: > On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín wrote: > > > I was wondering what are are using for DDOS protection in your networks. > We > > are currently evaluating different options (Arbor, Radware, NSFocus, > > RioRey) and I would like to know if someone is using the cloud based > > solutions/scrubbing centers like Imperva, Prolexic, etc and what are the > > advantages/disadvantages of using a cloud base vs an on-premise solution. > > It would be great if you can share your experience on this matter. > > > > On-premise solutions are limited by your own bandwidth. Attacks have been > publicly reported at 400Gbps, and are rumored to be even larger. If you > don't have that much network to spare, then packet loss will occur upstream > of your mitigation. Having a good relationship with your network > provider(s) can help here, of course. > > If you go with a cloud-based solution, be wary of their SLA. I've seen > some claim 100% uptime (not believable) but of course no refund/credits for > downtime. Another provider only provides 20Gbps protection, then will > null-route the victim. > > On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble > wrote: > > > Also how are folks testing ddos protection? What lab gear,tools,methods > > are you using to determine effectiveness of the mitigation. > > > Live-fire is the cheapest approach (just requires some creative trolling) > but if you want to control the "off" button, cloud VMs can be tailored to > your needs. There are also legitimate companies that do network stress > testing. > > Keep in mind that you need to test against a variety of attacks, against > all components in the critical path. Attackers aren't particularly > methodical, but will still randomly discover any weaknesses you've > overlooked. > > Damian > From damian at google.com Sun Jan 11 05:43:03 2015 From: damian at google.com (Damian Menscher) Date: Sat, 10 Jan 2015 21:43:03 -0800 Subject: DDOS solution recommendation In-Reply-To: <54B1FE0C.4060405@winterei.se> References: <54B1FE0C.4060405@winterei.se> Message-ID: On Sat, Jan 10, 2015 at 8:37 PM, Paul S. wrote: > While it indeed is true that attacks up to 600 gbit/s (If OVH and > CloudFlare's data is to be believed) have been known to happen in the wild, > it's very unlikely that you need to mitigate anything close. > Agree that trusting others' numbers is unwise (there's a bias to inflate sizes), but from personal experience I can say that their claims are plausible. The average attack is usually around the 10g mark (That too barely) -- so > even solutions that service up to 20g work alright. > I'm not sure how to compute an "average" -- I generally just track the maximums. I suspect some reports of 10Gbps attacks are simply that the attack saturated the victim's link, and they were unable to measure the true size. (I agree there are many actual 10Gbps attacks also, of course -- attackers know this size will usually work, so they don't waste resources.) Obviously, concerns are different if you're an enterprise that's a DDoS > magnet -- but for general service providers selling 'protected services,' > food for thought. Even if you're just a hosting provider, your customers may be DDoS magnets. Coincidentally, at the time you pressed "send", we were seeing a 40Gbps attack targeting a customer. Damian On 1/11/2015 午後 12:48, Damian Menscher wrote: > >> On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín wrote: >> >> I was wondering what are are using for DDOS protection in your networks. >>> We >>> are currently evaluating different options (Arbor, Radware, NSFocus, >>> RioRey) and I would like to know if someone is using the cloud based >>> solutions/scrubbing centers like Imperva, Prolexic, etc and what are the >>> advantages/disadvantages of using a cloud base vs an on-premise solution. >>> It would be great if you can share your experience on this matter. >>> >>> On-premise solutions are limited by your own bandwidth. Attacks have >> been >> publicly reported at 400Gbps, and are rumored to be even larger. If you >> don't have that much network to spare, then packet loss will occur >> upstream >> of your mitigation. Having a good relationship with your network >> provider(s) can help here, of course. >> >> If you go with a cloud-based solution, be wary of their SLA. I've seen >> some claim 100% uptime (not believable) but of course no refund/credits >> for >> downtime. Another provider only provides 20Gbps protection, then will >> null-route the victim. >> >> On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble >> wrote: >> >> Also how are folks testing ddos protection? What lab gear,tools,methods >>> are you using to determine effectiveness of the mitigation. >>> >> >> Live-fire is the cheapest approach (just requires some creative trolling) >> but if you want to control the "off" button, cloud VMs can be tailored to >> your needs. There are also legitimate companies that do network stress >> testing. >> >> Keep in mind that you need to test against a variety of attacks, against >> all components in the critical path. Attackers aren't particularly >> methodical, but will still randomly discover any weaknesses you've >> overlooked. >> >> Damian >> > > From ammar at fastreturn.net Sun Jan 11 06:30:22 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sun, 11 Jan 2015 10:30:22 +0400 Subject: DDOS solution recommendation In-Reply-To: References: <54B1FE0C.4060405@winterei.se> Message-ID: You'd notice that most people don't really know how big the attack that they're sending is. I've done a lot of research into how these attacks actually work and most of them are done by kids who don't really know what they're doing. To them an attack is something that will take their target down (usually a home connection or a game server). If this doesn't happen, they fire off complaints to the person that runs the DDoS service. Its a whole industry out there, and they're generally far ahead of us. Ammar > On 11 Jan 2015, at 9:43 am, Damian Menscher wrote: > >> On Sat, Jan 10, 2015 at 8:37 PM, Paul S. wrote: >> >> While it indeed is true that attacks up to 600 gbit/s (If OVH and >> CloudFlare's data is to be believed) have been known to happen in the wild, >> it's very unlikely that you need to mitigate anything close. > > Agree that trusting others' numbers is unwise (there's a bias to inflate > sizes), but from personal experience I can say that their claims are > plausible. > > The average attack is usually around the 10g mark (That too barely) -- so >> even solutions that service up to 20g work alright. > > I'm not sure how to compute an "average" -- I generally just track the > maximums. I suspect some reports of 10Gbps attacks are simply that the > attack saturated the victim's link, and they were unable to measure the > true size. (I agree there are many actual 10Gbps attacks also, of course > -- attackers know this size will usually work, so they don't waste > resources.) > > Obviously, concerns are different if you're an enterprise that's a DDoS >> magnet -- but for general service providers selling 'protected services,' >> food for thought. > > > Even if you're just a hosting provider, your customers may be DDoS > magnets. Coincidentally, at the time you pressed "send", we were seeing a > 40Gbps attack targeting a customer. > > Damian > >> On 1/11/2015 午後 12:48, Damian Menscher wrote: >> >>> On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín wrote: >>> >>> I was wondering what are are using for DDOS protection in your networks. >>>> We >>>> are currently evaluating different options (Arbor, Radware, NSFocus, >>>> RioRey) and I would like to know if someone is using the cloud based >>>> solutions/scrubbing centers like Imperva, Prolexic, etc and what are the >>>> advantages/disadvantages of using a cloud base vs an on-premise solution. >>>> It would be great if you can share your experience on this matter. >>>> >>>> On-premise solutions are limited by your own bandwidth. Attacks have >>> been >>> publicly reported at 400Gbps, and are rumored to be even larger. If you >>> don't have that much network to spare, then packet loss will occur >>> upstream >>> of your mitigation. Having a good relationship with your network >>> provider(s) can help here, of course. >>> >>> If you go with a cloud-based solution, be wary of their SLA. I've seen >>> some claim 100% uptime (not believable) but of course no refund/credits >>> for >>> downtime. Another provider only provides 20Gbps protection, then will >>> null-route the victim. >>> >>> On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble >>> wrote: >>> >>> Also how are folks testing ddos protection? What lab gear,tools,methods >>>> are you using to determine effectiveness of the mitigation. >>> >>> Live-fire is the cheapest approach (just requires some creative trolling) >>> but if you want to control the "off" button, cloud VMs can be tailored to >>> your needs. There are also legitimate companies that do network stress >>> testing. >>> >>> Keep in mind that you need to test against a variety of attacks, against >>> all components in the critical path. Attackers aren't particularly >>> methodical, but will still randomly discover any weaknesses you've >>> overlooked. >>> >>> Damian >> >> From hank at efes.iucc.ac.il Sun Jan 11 08:23:36 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 11 Jan 2015 10:23:36 +0200 Subject: DDOS solution recommendation In-Reply-To: References: <54B1FE0C.4060405@winterei.se> <54B1FE0C.4060405@winterei.se> Message-ID: <5.1.1.6.2.20150111085411.01f9f870@efes.iucc.ac.il> >> If you go with a cloud-based solution, be wary of their SLA. I've seen >> some claim 100% uptime (not believable) but of course no refund/credits >> for >> downtime. I have encountered where they are willing to offer 100% sla for *their* DDOS mitigation equipment in the cloud. Not for your service. -Hank From rdobbins at arbor.net Sun Jan 11 09:24:48 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 11 Jan 2015 16:24:48 +0700 Subject: DDOS solution recommendation In-Reply-To: References: <54B1FE0C.4060405@winterei.se> Message-ID: <65339E2E-BB50-4F58-AFD1-AEE4D228CA13@arbor.net> On 11 Jan 2015, at 13:30, Ammar Zuberi wrote: > I've done a lot of research into how these attacks actually work and > most of them are done by kids who don't really know what they're > doing. The really sad part is that in a huge of the cases we see, the attacks are hugely disproportionate - so many servers/services/applications/networks are so brittle and fragile and non-scalable that only a fraction of the pps/bps/cps/qps generated by the attackers would take them down, anyways. Even worse, the attackers who don't know what they're doing routinely achieve their goals, anyways, due to the above plus the unpreparedness of the defenders. I've only run across a handful of organizations which proactively took appropriate defensive measures; most only do so in the aftermath of a successful attack. It's easy to be an Internet supervillain. ----------------------------------- Roland Dobbins From nanog at ics-il.net Sun Jan 11 13:07:13 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 11 Jan 2015 07:07:13 -0600 (CST) Subject: DDOS solution recommendation In-Reply-To: Message-ID: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> Why does it seem like everyone is trying to "solve" this the wrong way? Do other networks' abuse departments just not give a shit? Blackhole all of the zombie attackers and notify their abuse departments. Sure, most of the owners of the PCs being used in these scenarios have no idea they're being used to attack people, but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified. When the unknowing end-user reached out to support over larger and larger parts of the Internet not working, they'd be told to clean up their system. The way to stop this stuff is for those millions of end users to clean up their infected PCs. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Thursday, January 8, 2015 11:01:47 AM Subject: DDOS solution recommendation Nanog group I was wondering what are are using for DDOS protection in your networks. We are currently evaluating different options (Arbor, Radware, NSFocus, RioRey) and I would like to know if someone is using the cloud based solutions/scrubbing centers like Imperva, Prolexic, etc and what are the advantages/disadvantages of using a cloud base vs an on-premise solution. It would be great if you can share your experience on this matter. Thank you From rdobbins at arbor.net Sun Jan 11 13:24:55 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 11 Jan 2015 20:24:55 +0700 Subject: DDOS solution recommendation In-Reply-To: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> Message-ID: On 11 Jan 2015, at 20:07, Mike Hammett wrote: > but I'd think that if their network's abuse department was notified, > either they'd contact the customer about it issue or at least have on > file that they were notified. Just because we think something, that doesn't make it true. ;> > The way to stop this stuff is for those millions of end users to clean > up their infected PCs. You may want to do some reading on this topic in order to gain a better understanding of the issues involved: Some of us have been dealing with DDoS attacks for a couple of decades, now. If it were a simple problem, we would've solved it long ago. Here's a hint: scale alone makes any problem literally orders of magnitude more difficult than any given instance thereof. ----------------------------------- Roland Dobbins From nanog at ics-il.net Sun Jan 11 13:46:15 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 11 Jan 2015 07:46:15 -0600 (CST) Subject: DDOS solution recommendation In-Reply-To: Message-ID: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> Well there's going to be two sources of the attack... infested clients or machines setup for this purpose (usually in a datacenter somewhere). Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet. They may not care of it's a server in a datacenter being used to attack, but an infested home PC would care once they can't get to Google, FaceBook, Instagram, whatever. If the attacker's abuse contact doesn't care, then just brute force of more and more of the Internet being offline to them, they'll figure it out. You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days. No point in letting troublemakers (manual or scripted) spend more time on the network than necessary. The more people (as a collective or not) that do this, the better. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Roland Dobbins" To: nanog at nanog.org Sent: Sunday, January 11, 2015 7:24:55 AM Subject: Re: DDOS solution recommendation On 11 Jan 2015, at 20:07, Mike Hammett wrote: > but I'd think that if their network's abuse department was notified, > either they'd contact the customer about it issue or at least have on > file that they were notified. Just because we think something, that doesn't make it true. ;> > The way to stop this stuff is for those millions of end users to clean > up their infected PCs. You may want to do some reading on this topic in order to gain a better understanding of the issues involved: Some of us have been dealing with DDoS attacks for a couple of decades, now. If it were a simple problem, we would've solved it long ago. Here's a hint: scale alone makes any problem literally orders of magnitude more difficult than any given instance thereof. ----------------------------------- Roland Dobbins From patrick at ianai.net Sun Jan 11 13:50:22 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 11 Jan 2015 08:50:22 -0500 Subject: DDOS solution recommendation In-Reply-To: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> Message-ID: <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> I agree with lots said here. But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS. No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks. There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source. Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will. -- TTFN, patrick > On Jan 11, 2015, at 08:46 , Mike Hammett wrote: > > Well there's going to be two sources of the attack... infested clients or machines setup for this purpose (usually in a datacenter somewhere). Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet. They may not care of it's a server in a datacenter being used to attack, but an infested home PC would care once they can't get to Google, FaceBook, Instagram, whatever. > > If the attacker's abuse contact doesn't care, then just brute force of more and more of the Internet being offline to them, they'll figure it out. > > You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days. > > No point in letting troublemakers (manual or scripted) spend more time on the network than necessary. The more people (as a collective or not) that do this, the better. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Roland Dobbins" > To: nanog at nanog.org > Sent: Sunday, January 11, 2015 7:24:55 AM > Subject: Re: DDOS solution recommendation > > > On 11 Jan 2015, at 20:07, Mike Hammett wrote: > >> but I'd think that if their network's abuse department was notified, >> either they'd contact the customer about it issue or at least have on >> file that they were notified. > > Just because we think something, that doesn't make it true. > > ;> > >> The way to stop this stuff is for those millions of end users to clean >> up their infected PCs. > > You may want to do some reading on this topic in order to gain a better > understanding of the issues involved: > > > > Some of us have been dealing with DDoS attacks for a couple of decades, > now. If it were a simple problem, we would've solved it long ago. > > Here's a hint: scale alone makes any problem literally orders of > magnitude more difficult than any given instance thereof. > > ----------------------------------- > Roland Dobbins From rdobbins at arbor.net Sun Jan 11 13:51:59 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 11 Jan 2015 20:51:59 +0700 Subject: DDOS solution recommendation In-Reply-To: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> Message-ID: <5A423AE2-F363-41CE-BDB5-9AA19DD15879@arbor.net> On 11 Jan 2015, at 20:46, Mike Hammett wrote: > Enough people blackhole the attacking IPs, those IPs are eventually > going to have a very limited view of the Internet. TCAMs have limits. Not all networks practice anti-spoofing. Not all networks have any visibility whatsoever into their network traffic. Not all networks have security teams. Again, it would probably be advisable to do some reading before you start telling those of us who've been working on this set of problems for the last couple of decades that it's simple, and that we don't know what we're doing. ----------------------------------- Roland Dobbins From cb.list6 at gmail.com Sun Jan 11 13:52:56 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 11 Jan 2015 05:52:56 -0800 Subject: DDOS solution recommendation In-Reply-To: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, Jan 11, 2015 at 5:07 AM, Mike Hammett wrote: > Why does it seem like everyone is trying to "solve" this the wrong way? > > Do other networks' abuse departments just not give a shit? Blackhole all > of the zombie attackers and notify their abuse departments. Sure, most of > the owners of the PCs being used in these scenarios have no idea they're > being used to attack people, but I'd think that if their network's abuse > department was notified, either they'd contact the customer about it issue > or at least have on file that they were notified. When the unknowing > end-user reached out to support over larger and larger parts of the > Internet not working, they'd be told to clean up their system. > > The way to stop this stuff is for those millions of end users to clean up > their infected PCs. > > > 1. BCP38 protects your neighbor, do it. 2. Protect yourself by having your upstream police Police UDP to some baseline you are comfortable with. 3. Have RTBH ready for some special case. 4. Sleep better at night. I do all of the above for the last 18 months. > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Manuel Marín" > To: nanog at nanog.org > Sent: Thursday, January 8, 2015 11:01:47 AM > Subject: DDOS solution recommendation > > Nanog group > > I was wondering what are are using for DDOS protection in your networks. We > are currently evaluating different options (Arbor, Radware, NSFocus, > RioRey) and I would like to know if someone is using the cloud based > solutions/scrubbing centers like Imperva, Prolexic, etc and what are the > advantages/disadvantages of using a cloud base vs an on-premise solution. > It would be great if you can share your experience on this matter. > > Thank you > > From rdobbins at arbor.net Sun Jan 11 13:54:36 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 11 Jan 2015 20:54:36 +0700 Subject: DDOS solution recommendation In-Reply-To: <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> Message-ID: <96D0D2FF-14F8-4E84-BE0E-0C4CA17E0553@arbor.net> On 11 Jan 2015, at 20:50, Patrick W. Gilmore wrote: > Push on your providers. Stop paying for transit from networks that do > not filter ingress, put it in your RFPs, and reward those who do with > contracts. Make it economically advantageous to fix the problem, and > people will. Concur 100%. Unfortunately, it's only a tiny minority who understand enough to even care - and even when individuals in that tiny minority are influential within large organizations with global impact, all too often they can't get those kinds of measures implemented due to factors and priorities which are beyond their control. As you yourself know, through hard-won experience. ;> ----------------------------------- Roland Dobbins From nanog at ics-il.net Sun Jan 11 14:46:40 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 11 Jan 2015 08:46:40 -0600 (CST) Subject: DDOS solution recommendation In-Reply-To: <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> Message-ID: <32356202.1925.1420987613770.JavaMail.mhammett@ThunderFuck> Is anyone maintaining a list of good, bad and ugly providers in terms of how seriously they take things they should like BCP38 and community support and whatever else that's quantifiable? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Sunday, January 11, 2015 7:50:22 AM Subject: Re: DDOS solution recommendation I agree with lots said here. But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS. No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks. There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source. Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will. -- TTFN, patrick > On Jan 11, 2015, at 08:46 , Mike Hammett wrote: > > Well there's going to be two sources of the attack... infested clients or machines setup for this purpose (usually in a datacenter somewhere). Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet. They may not care of it's a server in a datacenter being used to attack, but an infested home PC would care once they can't get to Google, FaceBook, Instagram, whatever. > > If the attacker's abuse contact doesn't care, then just brute force of more and more of the Internet being offline to them, they'll figure it out. > > You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days. > > No point in letting troublemakers (manual or scripted) spend more time on the network than necessary. The more people (as a collective or not) that do this, the better. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Roland Dobbins" > To: nanog at nanog.org > Sent: Sunday, January 11, 2015 7:24:55 AM > Subject: Re: DDOS solution recommendation > > > On 11 Jan 2015, at 20:07, Mike Hammett wrote: > >> but I'd think that if their network's abuse department was notified, >> either they'd contact the customer about it issue or at least have on >> file that they were notified. > > Just because we think something, that doesn't make it true. > > ;> > >> The way to stop this stuff is for those millions of end users to clean >> up their infected PCs. > > You may want to do some reading on this topic in order to gain a better > understanding of the issues involved: > > > > Some of us have been dealing with DDoS attacks for a couple of decades, > now. If it were a simple problem, we would've solved it long ago. > > Here's a hint: scale alone makes any problem literally orders of > magnitude more difficult than any given instance thereof. > > ----------------------------------- > Roland Dobbins From job at instituut.net Sun Jan 11 14:51:14 2015 From: job at instituut.net (Job Snijders) Date: Sun, 11 Jan 2015 15:51:14 +0100 Subject: DDOS solution recommendation In-Reply-To: <32356202.1925.1420987613770.JavaMail.mhammett@ThunderFuck> References: <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> <32356202.1925.1420987613770.JavaMail.mhammett@ThunderFuck> Message-ID: <20150111145114.GK18289@Vurt.local> On Sun, Jan 11, 2015 at 08:46:40AM -0600, Mike Hammett wrote: > Is anyone maintaining a list of good, bad and ugly providers in terms > of how seriously they take things they should like BCP38 and community > support and whatever else that's quantifiable? This list sheds some light on antispoofing commitments made by various providers: https://www.routingmanifesto.org/participants/ Kind regards, Job From rdobbins at arbor.net Sun Jan 11 14:58:12 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 11 Jan 2015 21:58:12 +0700 Subject: DDOS solution recommendation In-Reply-To: References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> Message-ID: <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> On 11 Jan 2015, at 20:52, Ca By wrote: > 1. BCP38 protects your neighbor, do it. It's to protect yourself, as well. You should do it all the way down to the transit customer aggregation edge, all the way down to the IDC access layer, etc. > 2. Protect yourself by having your upstream police Police UDP to some > baseline you are comfortable with. This will come back to haunt you, when the programmatically-generated attack traffic 'crowds out' the legitimate traffic and everything breaks. You can only really do this for ntp. > 3. Have RTBH ready for some special case. S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too). ----------------------------------- Roland Dobbins From ammar at fastreturn.net Sun Jan 11 15:02:50 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sun, 11 Jan 2015 19:02:50 +0400 Subject: DDOS solution recommendation In-Reply-To: <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> Message-ID: <9A37AC87-6AEE-4A06-A413-CFD07E9453FF@fastreturn.net> I’m stuck trying to find a virtual router environment that I can play with flowspec on. We do have some Juniper routers, but they are in production and I don’t think I want to touch flowspec on them just yet. Does anyone have any experience or any ideas here? Even openbgpd? > On Jan 11, 2015, at 6:58 PM, Roland Dobbins wrote: > > > On 11 Jan 2015, at 20:52, Ca By wrote: > >> 1. BCP38 protects your neighbor, do it. > > It's to protect yourself, as well. You should do it all the way down to the transit customer aggregation edge, all the way down to the IDC access layer, etc. > >> 2. Protect yourself by having your upstream police Police UDP to some >> baseline you are comfortable with. > > This will come back to haunt you, when the programmatically-generated attack traffic 'crowds out' the legitimate traffic and everything breaks. > > You can only really do this for ntp. > >> 3. Have RTBH ready for some special case. > > S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too). > > ----------------------------------- > Roland Dobbins From job at instituut.net Sun Jan 11 15:07:18 2015 From: job at instituut.net (Job Snijders) Date: Sun, 11 Jan 2015 16:07:18 +0100 Subject: DDOS solution recommendation In-Reply-To: <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> Message-ID: <20150111150718.GL18289@Vurt.local> On Sun, Jan 11, 2015 at 09:58:12PM +0700, Roland Dobbins wrote: >> 2. Protect yourself by having your upstream police Police UDP to some >> baseline you are comfortable with. > > This will come back to haunt you, when the programmatically-generated > attack traffic 'crowds out' the legitimate traffic and everything > breaks. > > You can only really do this for ntp. You can also consider adding CHARGEN and SSDP. Kind regards, Job From me at geordish.org Sun Jan 11 15:08:25 2015 From: me at geordish.org (Dave Bell) Date: Sun, 11 Jan 2015 15:08:25 +0000 Subject: DDOS solution recommendation In-Reply-To: <9A37AC87-6AEE-4A06-A413-CFD07E9453FF@fastreturn.net> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> <9A37AC87-6AEE-4A06-A413-CFD07E9453FF@fastreturn.net> Message-ID: Maybe try the Cisco CSR1000v. In the trial mode it won't give you a decent throughput, but should have all features enabled. On 11 January 2015 at 15:02, Ammar Zuberi wrote: > I’m stuck trying to find a virtual router environment that I can play with flowspec on. We do have some Juniper routers, but they are in production and I don’t think I want to touch flowspec on them just yet. > > Does anyone have any experience or any ideas here? Even openbgpd? > >> On Jan 11, 2015, at 6:58 PM, Roland Dobbins wrote: >> >> >> On 11 Jan 2015, at 20:52, Ca By wrote: >> >>> 1. BCP38 protects your neighbor, do it. >> >> It's to protect yourself, as well. You should do it all the way down to the transit customer aggregation edge, all the way down to the IDC access layer, etc. >> >>> 2. Protect yourself by having your upstream police Police UDP to some >>> baseline you are comfortable with. >> >> This will come back to haunt you, when the programmatically-generated attack traffic 'crowds out' the legitimate traffic and everything breaks. >> >> You can only really do this for ntp. >> >>> 3. Have RTBH ready for some special case. >> >> S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too). >> >> ----------------------------------- >> Roland Dobbins > From nanog at ics-il.net Sun Jan 11 15:21:13 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 11 Jan 2015 09:21:13 -0600 (CST) Subject: DDOS solution recommendation In-Reply-To: <5A423AE2-F363-41CE-BDB5-9AA19DD15879@arbor.net> Message-ID: <25342930.1994.1420989680127.JavaMail.mhammett@ThunderFuck> To quote a presentation I heard at a conference regarding small routers, "Buy bigger rooters, bitches." (Yes, I know it isn't that simple, but most of the audience at that conference had purchasing authority.) Not all networks are doing what they're supposed to be (I'm on that list), but if no one ever does anything because not everyone else is, then nothing ever gets done. I'm not saying what you're doing is wrong, I'm saying whatever the industry as a whole is doing obviously isn't working and perhaps a different approach is required. Security teams? My network has me, myself and I. If for example ChinaNet's abuse department isn't doing anything about complains, eventually their whole network gets blocked a /32 at a time. *shrugs* Their loss. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Roland Dobbins" To: nanog at nanog.org Sent: Sunday, January 11, 2015 7:51:59 AM Subject: Re: DDOS solution recommendation On 11 Jan 2015, at 20:46, Mike Hammett wrote: > Enough people blackhole the attacking IPs, those IPs are eventually > going to have a very limited view of the Internet. TCAMs have limits. Not all networks practice anti-spoofing. Not all networks have any visibility whatsoever into their network traffic. Not all networks have security teams. Again, it would probably be advisable to do some reading before you start telling those of us who've been working on this set of problems for the last couple of decades that it's simple, and that we don't know what we're doing. ----------------------------------- Roland Dobbins From cb.list6 at gmail.com Sun Jan 11 15:23:47 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 11 Jan 2015 07:23:47 -0800 Subject: DDOS solution recommendation In-Reply-To: <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> Message-ID: On Sun, Jan 11, 2015 at 6:58 AM, Roland Dobbins wrote: > > On 11 Jan 2015, at 20:52, Ca By wrote: > > 1. BCP38 protects your neighbor, do it. >> > > It's to protect yourself, as well. You should do it all the way down to > the transit customer aggregation edge, all the way down to the IDC access > layer, etc. > > 2. Protect yourself by having your upstream police Police UDP to some >> baseline you are comfortable with. >> > > This will come back to haunt you, when the programmatically-generated > attack traffic 'crowds out' the legitimate traffic and everything breaks. > > You can only really do this for ntp. I do it for all UDP. There are bw policers and pps policers. As I said, this is known to work for me. YMMV. It is a managed risk, like anything. There are no silver bullets. I feel bad for people developing things like QUIC and WebRTC on UDP. But. i have already informed them of this risk to using UDP instead of a new L4 protocol. Protip: UDP is a cesspool. Don't build things on a cesspool where the vast majority of traffic is illegitimate. Guilty by association is a real thing. UDP will not have a renaissance CB > > > 3. Have RTBH ready for some special case. >> > > S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too). > > ----------------------------------- > Roland Dobbins > From contact at winterei.se Sun Jan 11 15:28:34 2015 From: contact at winterei.se (Paul S.) Date: Mon, 12 Jan 2015 00:28:34 +0900 Subject: DDOS solution recommendation In-Reply-To: References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> <9A37AC87-6AEE-4A06-A413-CFD07E9453FF@fastreturn.net> Message-ID: <54B296A2.2090602@winterei.se> There's the Cisco xRV too, should be decent for playing around with. On 1/12/2015 午前 12:08, Dave Bell wrote: > Maybe try the Cisco CSR1000v. In the trial mode it won't give you a > decent throughput, but should have all features enabled. > > On 11 January 2015 at 15:02, Ammar Zuberi wrote: >> I’m stuck trying to find a virtual router environment that I can play with flowspec on. We do have some Juniper routers, but they are in production and I don’t think I want to touch flowspec on them just yet. >> >> Does anyone have any experience or any ideas here? Even openbgpd? >> >>> On Jan 11, 2015, at 6:58 PM, Roland Dobbins wrote: >>> >>> >>> On 11 Jan 2015, at 20:52, Ca By wrote: >>> >>>> 1. BCP38 protects your neighbor, do it. >>> It's to protect yourself, as well. You should do it all the way down to the transit customer aggregation edge, all the way down to the IDC access layer, etc. >>> >>>> 2. Protect yourself by having your upstream police Police UDP to some >>>> baseline you are comfortable with. >>> This will come back to haunt you, when the programmatically-generated attack traffic 'crowds out' the legitimate traffic and everything breaks. >>> >>> You can only really do this for ntp. >>> >>>> 3. Have RTBH ready for some special case. >>> S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too). >>> >>> ----------------------------------- >>> Roland Dobbins From rdobbins at arbor.net Sun Jan 11 15:29:33 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 11 Jan 2015 22:29:33 +0700 Subject: DDOS solution recommendation In-Reply-To: <25342930.1994.1420989680127.JavaMail.mhammett@ThunderFuck> References: <25342930.1994.1420989680127.JavaMail.mhammett@ThunderFuck> Message-ID: <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> On 11 Jan 2015, at 22:21, Mike Hammett wrote: > I'm not saying what you're doing is wrong, I'm saying whatever the > industry as a whole is doing obviously isn't working and perhaps a > different approach is required. You haven't recommended anything new, and you really need to do some reading in order to understand why it isn't as simple as you seem to think it is. > Security teams? My network has me, myself and I. And a relatively small network, too. > If for example ChinaNet's abuse department isn't doing anything about > complains, eventually their whole network gets blocked a /32 at a > time. *shrugs* Their loss. Again, it isn't that simple. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sun Jan 11 15:30:35 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 11 Jan 2015 22:30:35 +0700 Subject: DDOS solution recommendation In-Reply-To: <20150111150718.GL18289@Vurt.local> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> <20150111150718.GL18289@Vurt.local> Message-ID: <08695123-002D-4537-A3E3-1E91B8F468CB@arbor.net> On 11 Jan 2015, at 22:07, Job Snijders wrote: > You can also consider adding CHARGEN and SSDP. People run all sorts of strange things on arbitrary ports - like VPNs, for example. It isn't that simple. ----------------------------------- Roland Dobbins From m.hallgren at free.fr Sun Jan 11 15:47:03 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Sun, 11 Jan 2015 16:47:03 +0100 Subject: DDOS solution recommendation In-Reply-To: <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> Message-ID: <54B29AF7.3040102@free.fr> Le 11/01/2015 14:50, Patrick W. Gilmore a écrit : > I agree with lots said here. > > But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS. > > No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks. > > There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source. > > Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will. +1 mh > From m.hallgren at free.fr Sun Jan 11 15:47:04 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Sun, 11 Jan 2015 16:47:04 +0100 Subject: DDOS solution recommendation In-Reply-To: <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> Message-ID: <54B29AF8.5080609@free.fr> Le 11/01/2015 14:50, Patrick W. Gilmore a écrit : > I agree with lots said here. > > But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS. > > No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks. > > There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source. > > Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will. +1 mh > From pavel.odintsov at gmail.com Sun Jan 11 15:52:02 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Sun, 11 Jan 2015 19:52:02 +0400 Subject: DDOS solution recommendation In-Reply-To: <54B29AF7.3040102@free.fr> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> <951F252A-31AF-4726-B015-B8C534A78CF4@ianai.net> <54B29AF7.3040102@free.fr> Message-ID: Hello! If you speaking about ISP "filtering" you should check your subnets and ASN here: https://radar.qrator.net I was really amazed amount of DDoS bots/amplificators in my network. On Sun, Jan 11, 2015 at 6:47 PM, Michael Hallgren wrote: > Le 11/01/2015 14:50, Patrick W. Gilmore a écrit : >> I agree with lots said here. >> >> But I've said for years (despite some people saying I am confused) that BCP38 is the single most important thing we can do to cut DDoS. >> >> No spoofed source means no amplification. It also stops things like Kaminsky DNS attacks. >> >> There is no silver bullet. Security is a series of steps ("layers" as one highly respected security professional has in his .sig). But the most important layer, the biggest bang for the buck we can do today, is eliminated spoofed source. >> >> Push on your providers. Stop paying for transit from networks that do not filter ingress, put it in your RFPs, and reward those who do with contracts. Make it economically advantageous to fix the problem, and people will. > > +1 > mh >> > -- Sincerely yours, Pavel Odintsov From Valdis.Kletnieks at vt.edu Sun Jan 11 16:09:47 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 11 Jan 2015 11:09:47 -0500 Subject: DDOS solution recommendation In-Reply-To: Your message of "Sun, 11 Jan 2015 22:29:33 +0700." <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> References: <25342930.1994.1420989680127.JavaMail.mhammett@ThunderFuck> <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> Message-ID: <77143.1420992587@turing-police.cc.vt.edu> On Sun, 11 Jan 2015 22:29:33 +0700, "Roland Dobbins" said: > > On 11 Jan 2015, at 22:21, Mike Hammett wrote: > > > I'm not saying what you're doing is wrong, I'm saying whatever the > > industry as a whole is doing obviously isn't working and perhaps a > > different approach is required. > > You haven't recommended anything new, and you really need to do some > reading in order to understand why it isn't as simple as you seem to > think it is. Sounds like RFC1925, section 4 should be top of the list? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at ics-il.net Sun Jan 11 16:33:05 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 11 Jan 2015 10:33:05 -0600 (CST) Subject: DDOS solution recommendation In-Reply-To: <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> Message-ID: <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> I didn't necessarily think I was shattering minds with my ideas. I don't have the time to read a dozen presentations. Blackhole them and move on. I don't care whose feelings I hurt. This isn't kindergarten. Maybe "you" should have tried a little harder to not get a virus in the first place. Quit clicking on male enhancement ads or update your OS occasionally. I'm not going to spend a bunch of time and money to make sure someone's bubble of bliss doesn't get popped. Swift, effective, cheap. Besides, you're only cut off for 30 days. If in 30 days you can prove yourself to be responsible, we can try this again. Well, that or a sufficient support request. Besides, if enough people did hat, the list of blackholes wouldn't be huge as someone upstream already blocked them. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Roland Dobbins" To: nanog at nanog.org Sent: Sunday, January 11, 2015 9:29:33 AM Subject: Re: DDOS solution recommendation On 11 Jan 2015, at 22:21, Mike Hammett wrote: > I'm not saying what you're doing is wrong, I'm saying whatever the > industry as a whole is doing obviously isn't working and perhaps a > different approach is required. You haven't recommended anything new, and you really need to do some reading in order to understand why it isn't as simple as you seem to think it is. > Security teams? My network has me, myself and I. And a relatively small network, too. > If for example ChinaNet's abuse department isn't doing anything about > complains, eventually their whole network gets blocked a /32 at a > time. *shrugs* Their loss. Again, it isn't that simple. ----------------------------------- Roland Dobbins From ammar at fastreturn.net Sun Jan 11 18:07:28 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sun, 11 Jan 2015 22:07:28 +0400 Subject: Anyone from EPOCH Internet/MegaPath? Message-ID: Hi, The AS number we were assigned by ARIN (AS14558) was previously owned by DANDY and was in the EPOCH routing registry. We get conflicting route generations from IRR due to this, is there anyone that can contact me off-list and get this done or does anyone have any suggestions on how I can go about getting this removed. I’ve already tried to call and email them, everyone seems clueless unfortunately. Ammar. From jmaslak at antelope.net Sun Jan 11 18:09:20 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Sun, 11 Jan 2015 11:09:20 -0700 Subject: DDOS solution recommendation In-Reply-To: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, Jan 11, 2015 at 6:46 AM, Mike Hammett wrote: > You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to > my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, > etc. You have more than say 5 bad login attempts to my mail server in 5 > minutes, blackholed for 30 days. You're trying to access various web pages > known for home router or Wordpress exploitation, blackholed for 30 days. > I urge caution in building automatic systems to respond to network abuse, lest you have unanticipated consequences. How are you tracing the source for DNS UDP, NTP UDP, etc, requests? Or TCP SYNs? If you say source address in the packet, you might not be doing what you think you're doing. Or for that matter HTTP accesses. Without giving too much discussion, let me point out: 1) You can forge a victim's IP and send packets to a honeypot (or indeed the entire IPv4 internet if you want). You may not want to assume "I see a packet with this claimed source being sent to X, so it must be a bad guy and I should block it." 2) Web crawlers will follow links from Bad Guy's Site to your website, even if these links might match an IDS signature on your end. You may not want to block some search engine crawlers. 3) Legitimate recursive DNS servers can be made to connect to any IP address a bad guy wants them to connect to. You may not want to block some ISP's recursive DNS servers. There are good things to do automatically, but make sure you think them through. I used to do click fraud detection 15 years ago - when that was still a new field and we all were inventing our own ways of doing it. I was amazed at the number of ways a bad guy could do an HTTP request from millions of source IPs (hint: they weren't spoofed). I suspect it hasn't gotten better. The internet isn't able to be broken because the people building and running it are idiots. It's able to be broken because breaking things has always been far easier than building them. It takes much more intelligence, skill, and expertise to build a glass window than to throw a brick through one. From bedard.phil at gmail.com Sun Jan 11 19:34:03 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 11 Jan 2015 14:34:03 -0500 Subject: DDOS solution recommendation In-Reply-To: <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> References: <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> Message-ID: Many attacks can use spoofed source IPs, so who are you really blocking? That's why BCP38 as mentioned many times already is a necessary tool in fighting the attacks overall. Phil On 1/11/15, 4:33 PM, "Mike Hammett" wrote: >I didn't necessarily think I was shattering minds with my ideas. > >I don't have the time to read a dozen presentations. > >Blackhole them and move on. I don't care whose feelings I hurt. This >isn't kindergarten. Maybe "you" should have tried a little harder to not >get a virus in the first place. Quit clicking on male enhancement ads or >update your OS occasionally. I'm not going to spend a bunch of time and >money to make sure someone's bubble of bliss doesn't get popped. Swift, >effective, cheap. Besides, you're only cut off for 30 days. If in 30 days >you can prove yourself to be responsible, we can try this again. Well, >that or a sufficient support request. > >Besides, if enough people did hat, the list of blackholes wouldn't be >huge as someone upstream already blocked them. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > > > >----- Original Message ----- > >From: "Roland Dobbins" >To: nanog at nanog.org >Sent: Sunday, January 11, 2015 9:29:33 AM >Subject: Re: DDOS solution recommendation > > >On 11 Jan 2015, at 22:21, Mike Hammett wrote: > >> I'm not saying what you're doing is wrong, I'm saying whatever the >> industry as a whole is doing obviously isn't working and perhaps a >> different approach is required. > >You haven't recommended anything new, and you really need to do some >reading in order to understand why it isn't as simple as you seem to >think it is. > >> Security teams? My network has me, myself and I. > >And a relatively small network, too. > >> If for example ChinaNet's abuse department isn't doing anything about >> complains, eventually their whole network gets blocked a /32 at a >> time. *shrugs* Their loss. > >Again, it isn't that simple. > >----------------------------------- >Roland Dobbins > From patrick at ianai.net Sun Jan 11 19:42:13 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 11 Jan 2015 14:42:13 -0500 Subject: DDOS solution recommendation In-Reply-To: References: <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> Message-ID: <95FAA7BE-A61D-4F9A-8966-E13076AA93F4@ianai.net> I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease". Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world. Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic. Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner. -- TTFN, patrick On Jan 11, 2015, at 14:34 , Phil Bedard wrote: > > Many attacks can use spoofed source IPs, so who are you really blocking? > > That's why BCP38 as mentioned many times already is a necessary tool in > fighting the attacks overall. > > Phil > > > > > On 1/11/15, 4:33 PM, "Mike Hammett" wrote: > >> I didn't necessarily think I was shattering minds with my ideas. >> >> I don't have the time to read a dozen presentations. >> >> Blackhole them and move on. I don't care whose feelings I hurt. This >> isn't kindergarten. Maybe "you" should have tried a little harder to not >> get a virus in the first place. Quit clicking on male enhancement ads or >> update your OS occasionally. I'm not going to spend a bunch of time and >> money to make sure someone's bubble of bliss doesn't get popped. Swift, >> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days >> you can prove yourself to be responsible, we can try this again. Well, >> that or a sufficient support request. >> >> Besides, if enough people did hat, the list of blackholes wouldn't be >> huge as someone upstream already blocked them. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Roland Dobbins" >> To: nanog at nanog.org >> Sent: Sunday, January 11, 2015 9:29:33 AM >> Subject: Re: DDOS solution recommendation >> >> >> On 11 Jan 2015, at 22:21, Mike Hammett wrote: >> >>> I'm not saying what you're doing is wrong, I'm saying whatever the >>> industry as a whole is doing obviously isn't working and perhaps a >>> different approach is required. >> >> You haven't recommended anything new, and you really need to do some >> reading in order to understand why it isn't as simple as you seem to >> think it is. >> >>> Security teams? My network has me, myself and I. >> >> And a relatively small network, too. >> >>> If for example ChinaNet's abuse department isn't doing anything about >>> complains, eventually their whole network gets blocked a /32 at a >>> time. *shrugs* Their loss. >> >> Again, it isn't that simple. >> >> ----------------------------------- >> Roland Dobbins >> From courtneysmith at comcast.net Sun Jan 11 20:05:49 2015 From: courtneysmith at comcast.net (Courtney Smith) Date: Sun, 11 Jan 2015 15:05:49 -0500 Subject: Anyone from EPOCH Internet/MegaPath? Message-ID: <2FE65451-CE5A-42BA-9F78-42804804F88B@comcast.net> I'm seeing what appear to be old route objects with origin AS14558 on several other registries. I would recommend you review those and reach out to those registries while you are trying to find a Megapath contact. Maybe theres should be a world 'clean up IRR' day. Getting ARIN to wipe the objects under this maintainer should be easy. mntner: MNT-DNDY referral-by: MNT-DNDY descr: Dandy Connections Inc admin-c: SCU23-ARIN tech-c: SCU23-ARIN upd-to: min at dandy.net mnt-nfy: min at dandy.net auth: MAIL-FROM min at dandy.net notify: min at dandy.net mnt-by: MNT-DNDY changed: min at dandy.net 20060428 source: ARIN RADB will clean this up for you. route: 209.128.240.0/20 descr: AS14558 proxy-registered route by Cogent origin: AS14558 remarks: Proxy-registered route object remarks: for Cogent customer notify: neteng at cogentco.com mnt-by: MAINT-AS174 changed: neteng at cogentco.com 20031230 source: RADB route: 209.128.224.0/19 descr: AS14558 proxy-registered route by Cogent origin: AS14558 remarks: Proxy-registered route object remarks: for Cogent customer notify: neteng at cogentco.com mnt-by: MAINT-AS174 changed: neteng at cogentco.com 20040308 source: RADB route: 76.161.33.0/24 descr: Proxy-registered route object origin: AS14558 remarks: This route object is for a BtN customer route remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found, and remarks: since some BtN peers filter based on these objects remarks: this route may be rejected if this object is not created. remarks: remarks: Please contact peering at cais.net if you have any remarks: questions regarding this object. mnt-by: MAINT-AS3491 changed: sajwani at pccwbtn.com 20080620 source: RADB Hopefully you can get a response out of Level3 to clean these out. mntner: DANDY-MNT descr: Dandy.net Maintainer admin-c: MIH1-LEVEL3 tech-c: MIH1-LEVEL3 upd-to: min at dandy.net mnt-nfy: min at dandy.net auth: MAIL-FROM min at dandy.net notify: min at dandy.net mnt-by: DANDY-MNT changed: scott.gentry at level3.com 20040629 source: LEVEL3 route: 66.159.96.0/20 descr: route object for dandy.com origin: AS14558 mnt-by: DANDY-MNT changed: scott.gentry at level3.com 20040709 source: LEVEL3 route: 209.128.224.0/19 descr: route object for Dandy.net origin: AS14558 mnt-by: DANDY-MNT changed: scott.gentry at level3.com 20040709 source: LEVEL3 route: 75.127.0.0/20 descr: cwie bgp req 20071228 origin: AS14558 mnt-by: DANDY-MNT changed: adam.hebert at level3.com 20071228 source: LEVEL3 route: 66.160.225.0/24 descr: cwie bgp req 20071228 origin: AS14558 mnt-by: DANDY-MNT changed: adam.hebert at level3.com 20071228 source: LEVEL3 Courtney Smith courtneysmith at comcast.net From patrick at ianai.net Sun Jan 11 20:47:20 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 11 Jan 2015 15:47:20 -0500 Subject: DDOS solution recommendation In-Reply-To: <3B1A3D80-278A-47D1-87E7-D9E7860186F1@gt86car.org.uk> References: <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> <95FAA7BE-A61D-4F9A-8966-E13076AA93F4@ianai.net> <3B1A3D80-278A-47D1-87E7-D9E7860186F1@gt86car.org.uk> Message-ID: <89F1DC65-2718-4D8E-901E-7A85FB8D0421@ianai.net> On Jan 11, 2015, at 15:28 , Colin Johnston wrote: > > unfortunately chinanet antispam/abuse email box is always full, after a while people block . > always check arin/ripe for known good provider blocks and actively exclude from rules They aren't the only ones who never reply to abuse at . > ddos protection via careful overview ips rules and active web source ip monitoring works well, the hard part is daily rule updates and blocks until you know most traffic is genuine. No one is advocating "never block anything". However, automatic blocking based on a single DNS packet to a non-DNS server is .. let's call it counterproductive. Good hygiene is necessary both on outgoing packets and on blocking. Checking ARIN/RIPE (not APNIC, LACNIC, AFRINIC?) is not even the bare minimum you should be doing. -- TTFN, patrick >> On 11 Jan 2015, at 19:42, "Patrick W. Gilmore" wrote: >> >> I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease". >> >> Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world. >> >> Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic. >> >> Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner. >> >> -- >> TTFN, >> patrick >> >>> On Jan 11, 2015, at 14:34 , Phil Bedard wrote: >>> >>> Many attacks can use spoofed source IPs, so who are you really blocking? >>> >>> That's why BCP38 as mentioned many times already is a necessary tool in >>> fighting the attacks overall. >>> >>> Phil >>> >>> >>> >>> >>>> On 1/11/15, 4:33 PM, "Mike Hammett" wrote: >>>> >>>> I didn't necessarily think I was shattering minds with my ideas. >>>> >>>> I don't have the time to read a dozen presentations. >>>> >>>> Blackhole them and move on. I don't care whose feelings I hurt. This >>>> isn't kindergarten. Maybe "you" should have tried a little harder to not >>>> get a virus in the first place. Quit clicking on male enhancement ads or >>>> update your OS occasionally. I'm not going to spend a bunch of time and >>>> money to make sure someone's bubble of bliss doesn't get popped. Swift, >>>> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days >>>> you can prove yourself to be responsible, we can try this again. Well, >>>> that or a sufficient support request. >>>> >>>> Besides, if enough people did hat, the list of blackholes wouldn't be >>>> huge as someone upstream already blocked them. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Roland Dobbins" >>>> To: nanog at nanog.org >>>> Sent: Sunday, January 11, 2015 9:29:33 AM >>>> Subject: Re: DDOS solution recommendation >>>> >>>> >>>>> On 11 Jan 2015, at 22:21, Mike Hammett wrote: >>>>> >>>>> I'm not saying what you're doing is wrong, I'm saying whatever the >>>>> industry as a whole is doing obviously isn't working and perhaps a >>>>> different approach is required. >>>> >>>> You haven't recommended anything new, and you really need to do some >>>> reading in order to understand why it isn't as simple as you seem to >>>> think it is. >>>> >>>>> Security teams? My network has me, myself and I. >>>> >>>> And a relatively small network, too. >>>> >>>>> If for example ChinaNet's abuse department isn't doing anything about >>>>> complains, eventually their whole network gets blocked a /32 at a >>>>> time. *shrugs* Their loss. >>>> >>>> Again, it isn't that simple. >>>> >>>> ----------------------------------- >>>> Roland Dobbins >> From owen at delong.com Sun Jan 11 20:55:59 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 11 Jan 2015 12:55:59 -0800 Subject: DDOS solution recommendation In-Reply-To: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> Message-ID: > On Jan 11, 2015, at 05:07 , Mike Hammett wrote: > > Why does it seem like everyone is trying to "solve" this the wrong way? Because it’s what we CAN do. > > Do other networks' abuse departments just not give a shit? Blackhole all of the zombie attackers and notify their abuse departments. Sure, most of the owners of the PCs being used in these scenarios have no idea they're being used to attack people, but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified. When the unknowing end-user reached out to support over larger and larger parts of the Internet not working, they'd be told to clean up their system. > > The way to stop this stuff is for those millions of end users to clean up their infected PCs. Agreed… However, let’s look at it from an economics perspective… The average residential service provider doesn’t have the resources and doesn’t charge enough to build the resources to deal with this onslaught. It won’t be the service provider that the attacker blames for the initial few disconnections, it will be the websites in question. So, let’s say XYZ.COM is a really popular site with lots of end-users. Some of those end-users are also unknowingly attacking XYZ.COM . XYZ.COM black holes those customers (along with all the other zombies attacking them). XYZ.COM gets angry calls from those customers and has no ability to contact the rest. The rest don’t call their ISP or XYZ.COM because they don’t know that they are unsuccessfully trying to reach XYZ.COM , so they don’t see the problem. Depending on hold times, etc., XYZ.COM loses some fraction of their customers (who instead of cleaning up their system, move into the second group who don’t care about the problem any more.) The rest may clean up their systems. So, at the cost of some fraction of their customer base and a substantial burden on their call center, XYZ.COM has managed to clean up a relatively small percentage of systems, but accomplished little else. I’m all for finding a way to do a better job of this. Personally, I’d like to see some sort of centralized clearing house where credible reporters of dDOS information could send some form of standardized (automated) report. The clearing house would then take care of contacting the responsible ISPs in a scaleable and useful manner that the ISPs could handle. Because the clearing house would be a known credible source and because they are providing the information in a way that the ISP can more efficiently utilize the information, it MIGHT allow the ISP to take proactive action such as contacting the user and addressing the problem, limiting the user’s ability to send dDOS traffic, etc. However, this would require lots of cooperation and if such a clearing house were to evolve, it would probably have to start as a coalition of residential ISPs. Owen From nanog at ics-il.net Sun Jan 11 21:08:45 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 11 Jan 2015 15:08:45 -0600 (CST) Subject: DDOS solution recommendation In-Reply-To: <95FAA7BE-A61D-4F9A-8966-E13076AA93F4@ianai.net> Message-ID: <5949794.3034.1421010501752.JavaMail.mhammett@ThunderFuck> If that were to happen, it'd be for 30 days and it'd be whatever random residential account or APNIC address that was doing it. Not really a big loss. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Sunday, January 11, 2015 1:42:13 PM Subject: Re: DDOS solution recommendation I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease". Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world. Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic. Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner. -- TTFN, patrick On Jan 11, 2015, at 14:34 , Phil Bedard wrote: > > Many attacks can use spoofed source IPs, so who are you really blocking? > > That's why BCP38 as mentioned many times already is a necessary tool in > fighting the attacks overall. > > Phil > > > > > On 1/11/15, 4:33 PM, "Mike Hammett" wrote: > >> I didn't necessarily think I was shattering minds with my ideas. >> >> I don't have the time to read a dozen presentations. >> >> Blackhole them and move on. I don't care whose feelings I hurt. This >> isn't kindergarten. Maybe "you" should have tried a little harder to not >> get a virus in the first place. Quit clicking on male enhancement ads or >> update your OS occasionally. I'm not going to spend a bunch of time and >> money to make sure someone's bubble of bliss doesn't get popped. Swift, >> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days >> you can prove yourself to be responsible, we can try this again. Well, >> that or a sufficient support request. >> >> Besides, if enough people did hat, the list of blackholes wouldn't be >> huge as someone upstream already blocked them. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Roland Dobbins" >> To: nanog at nanog.org >> Sent: Sunday, January 11, 2015 9:29:33 AM >> Subject: Re: DDOS solution recommendation >> >> >> On 11 Jan 2015, at 22:21, Mike Hammett wrote: >> >>> I'm not saying what you're doing is wrong, I'm saying whatever the >>> industry as a whole is doing obviously isn't working and perhaps a >>> different approach is required. >> >> You haven't recommended anything new, and you really need to do some >> reading in order to understand why it isn't as simple as you seem to >> think it is. >> >>> Security teams? My network has me, myself and I. >> >> And a relatively small network, too. >> >>> If for example ChinaNet's abuse department isn't doing anything about >>> complains, eventually their whole network gets blocked a /32 at a >>> time. *shrugs* Their loss. >> >> Again, it isn't that simple. >> >> ----------------------------------- >> Roland Dobbins >> From pavel.odintsov at gmail.com Sun Jan 11 21:11:39 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 12 Jan 2015 01:11:39 +0400 Subject: DDOS solution recommendation In-Reply-To: References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> Message-ID: Hello! But abuse@ contacts is very-very-very hard way to contacting with ASN administrator in case of attack. Big amount of requests to #Nanog about "please contact ASN XXXX noc with me offlist" confirms this. I'm got multiple attacks from well known ISP and I spend about 10-20 hours to contacting they in average. It's unacceptable time We need FAST and RELIABLE way to contacting with noc of attackers network for effective attack mitigation. We need something like RTBH for knocking network admin of remote network. Maybe somebody can create social network for noc's with API ?:) On Sun, Jan 11, 2015 at 11:55 PM, Owen DeLong wrote: > >> On Jan 11, 2015, at 05:07 , Mike Hammett wrote: >> >> Why does it seem like everyone is trying to "solve" this the wrong way? > > Because it’s what we CAN do. > >> >> Do other networks' abuse departments just not give a shit? Blackhole all of the zombie attackers and notify their abuse departments. Sure, most of the owners of the PCs being used in these scenarios have no idea they're being used to attack people, but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified. When the unknowing end-user reached out to support over larger and larger parts of the Internet not working, they'd be told to clean up their system. >> >> The way to stop this stuff is for those millions of end users to clean up their infected PCs. > > Agreed… However, let’s look at it from an economics perspective… > > The average residential service provider doesn’t have the resources and doesn’t charge enough to build the resources to deal with this onslaught. It won’t be the service provider that the attacker blames for the initial few disconnections, it will be the websites in question. > > So, let’s say XYZ.COM is a really popular site with lots of end-users. Some of those end-users are also unknowingly attacking XYZ.COM . > > XYZ.COM black holes those customers (along with all the other zombies attacking them). > > XYZ.COM gets angry calls from those customers and has no ability to contact the rest. > The rest don’t call their ISP or XYZ.COM because they don’t know that they are unsuccessfully trying to reach XYZ.COM , so they don’t see the problem. > > Depending on hold times, etc., XYZ.COM loses some fraction of their customers (who instead of cleaning up their system, move into the second group who don’t care about the problem any more.) The rest may clean up their systems. > > So, at the cost of some fraction of their customer base and a substantial burden on their call center, XYZ.COM has managed to clean up a relatively small percentage of systems, but accomplished little else. > > I’m all for finding a way to do a better job of this. Personally, I’d like to see some sort of centralized clearing house where credible reporters of dDOS information could send some form of standardized (automated) report. The clearing house would then take care of contacting the responsible ISPs in a scaleable and useful manner that the ISPs could handle. Because the clearing house would be a known credible source and because they are providing the information in a way that the ISP can more efficiently utilize the information, it MIGHT allow the ISP to take proactive action such as contacting the user and addressing the problem, limiting the user’s ability to send dDOS traffic, etc. > > However, this would require lots of cooperation and if such a clearing house were to evolve, it would probably have to start as a coalition of residential ISPs. > > Owen > > -- Sincerely yours, Pavel Odintsov From patrick at ianai.net Sun Jan 11 21:14:27 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 11 Jan 2015 16:14:27 -0500 Subject: DDOS solution recommendation In-Reply-To: <5949794.3034.1421010501752.JavaMail.mhammett@ThunderFuck> References: <5949794.3034.1421010501752.JavaMail.mhammett@ThunderFuck> Message-ID: <28333B30-49A1-476D-AABA-8731E2DBCFB0@ianai.net> You are very confused about how the Internet works. Or did you not understand the words "with source of"? Wait, maybe you have some magic to tell the actual source of a packet than the 32/128 bits in the "source" field? Because if you do, you stand to make a few billion dollars, and I'll be one of the first to pay you for it. (I'm specifically excluding things that give hints like TTL & incoming interface. To get paid, you need to tell me the ACTUAL source of a spoofed packet.) While I will admit I do not know which of the above is true, my money is on #1. -- TTFN, patrick > On Jan 11, 2015, at 16:08 , Mike Hammett wrote: > > If that were to happen, it'd be for 30 days and it'd be whatever random residential account or APNIC address that was doing it. Not really a big loss. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Sunday, January 11, 2015 1:42:13 PM > Subject: Re: DDOS solution recommendation > > I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease". > > Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world. > > Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic. > > Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner. > > -- > TTFN, > patrick > > On Jan 11, 2015, at 14:34 , Phil Bedard wrote: >> >> Many attacks can use spoofed source IPs, so who are you really blocking? >> >> That's why BCP38 as mentioned many times already is a necessary tool in >> fighting the attacks overall. >> >> Phil >> >> >> >> >> On 1/11/15, 4:33 PM, "Mike Hammett" wrote: >> >>> I didn't necessarily think I was shattering minds with my ideas. >>> >>> I don't have the time to read a dozen presentations. >>> >>> Blackhole them and move on. I don't care whose feelings I hurt. This >>> isn't kindergarten. Maybe "you" should have tried a little harder to not >>> get a virus in the first place. Quit clicking on male enhancement ads or >>> update your OS occasionally. I'm not going to spend a bunch of time and >>> money to make sure someone's bubble of bliss doesn't get popped. Swift, >>> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days >>> you can prove yourself to be responsible, we can try this again. Well, >>> that or a sufficient support request. >>> >>> Besides, if enough people did hat, the list of blackholes wouldn't be >>> huge as someone upstream already blocked them. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "Roland Dobbins" >>> To: nanog at nanog.org >>> Sent: Sunday, January 11, 2015 9:29:33 AM >>> Subject: Re: DDOS solution recommendation >>> >>> >>> On 11 Jan 2015, at 22:21, Mike Hammett wrote: >>> >>>> I'm not saying what you're doing is wrong, I'm saying whatever the >>>> industry as a whole is doing obviously isn't working and perhaps a >>>> different approach is required. >>> >>> You haven't recommended anything new, and you really need to do some >>> reading in order to understand why it isn't as simple as you seem to >>> think it is. >>> >>>> Security teams? My network has me, myself and I. >>> >>> And a relatively small network, too. >>> >>>> If for example ChinaNet's abuse department isn't doing anything about >>>> complains, eventually their whole network gets blocked a /32 at a >>>> time. *shrugs* Their loss. >>> >>> Again, it isn't that simple. >>> >>> ----------------------------------- >>> Roland Dobbins >>> > From sf at lists.esoteric.ca Sun Jan 11 21:18:11 2015 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Sun, 11 Jan 2015 16:18:11 -0500 Subject: DDOS solution recommendation In-Reply-To: References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> Message-ID: <54B2E893.8040506@lists.esoteric.ca> peeringdb.com is usually quite accurate. -- Stephen On 2015-01-11 4:11 PM, Pavel Odintsov wrote: > Hello! > > But abuse@ contacts is very-very-very hard way to contacting with ASN > administrator in case of attack. Big amount of requests to #Nanog > about "please contact ASN XXXX noc with me offlist" confirms this. > > I'm got multiple attacks from well known ISP and I spend about 10-20 > hours to contacting they in average. It's unacceptable time > > We need FAST and RELIABLE way to contacting with noc of attackers > network for effective attack mitigation. > > We need something like RTBH for knocking network admin of remote network. > > Maybe somebody can create social network for noc's with API ?:) > > > > > > On Sun, Jan 11, 2015 at 11:55 PM, Owen DeLong wrote: >> >>> On Jan 11, 2015, at 05:07 , Mike Hammett wrote: >>> >>> Why does it seem like everyone is trying to "solve" this the wrong way? >> >> Because it’s what we CAN do. >> >>> >>> Do other networks' abuse departments just not give a shit? Blackhole all of the zombie attackers and notify their abuse departments. Sure, most of the owners of the PCs being used in these scenarios have no idea they're being used to attack people, but I'd think that if their network's abuse department was notified, either they'd contact the customer about it issue or at least have on file that they were notified. When the unknowing end-user reached out to support over larger and larger parts of the Internet not working, they'd be told to clean up their system. >>> >>> The way to stop this stuff is for those millions of end users to clean up their infected PCs. >> >> Agreed… However, let’s look at it from an economics perspective… >> >> The average residential service provider doesn’t have the resources and doesn’t charge enough to build the resources to deal with this onslaught. It won’t be the service provider that the attacker blames for the initial few disconnections, it will be the websites in question. >> >> So, let’s say XYZ.COM is a really popular site with lots of end-users. Some of those end-users are also unknowingly attacking XYZ.COM . >> >> XYZ.COM black holes those customers (along with all the other zombies attacking them). >> >> XYZ.COM gets angry calls from those customers and has no ability to contact the rest. >> The rest don’t call their ISP or XYZ.COM because they don’t know that they are unsuccessfully trying to reach XYZ.COM , so they don’t see the problem. >> >> Depending on hold times, etc., XYZ.COM loses some fraction of their customers (who instead of cleaning up their system, move into the second group who don’t care about the problem any more.) The rest may clean up their systems. >> >> So, at the cost of some fraction of their customer base and a substantial burden on their call center, XYZ.COM has managed to clean up a relatively small percentage of systems, but accomplished little else. >> >> I’m all for finding a way to do a better job of this. Personally, I’d like to see some sort of centralized clearing house where credible reporters of dDOS information could send some form of standardized (automated) report. The clearing house would then take care of contacting the responsible ISPs in a scaleable and useful manner that the ISPs could handle. Because the clearing house would be a known credible source and because they are providing the information in a way that the ISP can more efficiently utilize the information, it MIGHT allow the ISP to take proactive action such as contacting the user and addressing the problem, limiting the user’s ability to send dDOS traffic, etc. >> >> However, this would require lots of cooperation and if such a clearing house were to evolve, it would probably have to start as a coalition of residential ISPs. >> >> Owen >> >> > > > From nanog at ics-il.net Sun Jan 11 21:22:30 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 11 Jan 2015 15:22:30 -0600 (CST) Subject: DDOS solution recommendation In-Reply-To: <28333B30-49A1-476D-AABA-8731E2DBCFB0@ianai.net> Message-ID: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> I know that UDP can be spoofed, but it's not likely that the SSH, mail, etc. login attempts, web page hits, etc. would be spoofed as they'd have to know the response to be of any good. There's more going on than UDP spoofing\amplification. Frankly the most damaging thing to me has been SMTP hijacking. For you to login to my SMTP server and send e-mail out, there's going to be one hell of a conversation going on. However, the thought is that if someone's PC is hijacked and trying to login to my SMTP server, it'll be doing something else later (or even concurrently). Enough deployment (in addition to BCP 38), and most of the threats are mitigated. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Sunday, January 11, 2015 3:14:27 PM Subject: Re: DDOS solution recommendation You are very confused about how the Internet works. Or did you not understand the words "with source of"? Wait, maybe you have some magic to tell the actual source of a packet than the 32/128 bits in the "source" field? Because if you do, you stand to make a few billion dollars, and I'll be one of the first to pay you for it. (I'm specifically excluding things that give hints like TTL & incoming interface. To get paid, you need to tell me the ACTUAL source of a spoofed packet.) While I will admit I do not know which of the above is true, my money is on #1. -- TTFN, patrick > On Jan 11, 2015, at 16:08 , Mike Hammett wrote: > > If that were to happen, it'd be for 30 days and it'd be whatever random residential account or APNIC address that was doing it. Not really a big loss. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Sunday, January 11, 2015 1:42:13 PM > Subject: Re: DDOS solution recommendation > > I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease". > > Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world. > > Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic. > > Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner. > > -- > TTFN, > patrick > > On Jan 11, 2015, at 14:34 , Phil Bedard wrote: >> >> Many attacks can use spoofed source IPs, so who are you really blocking? >> >> That's why BCP38 as mentioned many times already is a necessary tool in >> fighting the attacks overall. >> >> Phil >> >> >> >> >> On 1/11/15, 4:33 PM, "Mike Hammett" wrote: >> >>> I didn't necessarily think I was shattering minds with my ideas. >>> >>> I don't have the time to read a dozen presentations. >>> >>> Blackhole them and move on. I don't care whose feelings I hurt. This >>> isn't kindergarten. Maybe "you" should have tried a little harder to not >>> get a virus in the first place. Quit clicking on male enhancement ads or >>> update your OS occasionally. I'm not going to spend a bunch of time and >>> money to make sure someone's bubble of bliss doesn't get popped. Swift, >>> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days >>> you can prove yourself to be responsible, we can try this again. Well, >>> that or a sufficient support request. >>> >>> Besides, if enough people did hat, the list of blackholes wouldn't be >>> huge as someone upstream already blocked them. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "Roland Dobbins" >>> To: nanog at nanog.org >>> Sent: Sunday, January 11, 2015 9:29:33 AM >>> Subject: Re: DDOS solution recommendation >>> >>> >>> On 11 Jan 2015, at 22:21, Mike Hammett wrote: >>> >>>> I'm not saying what you're doing is wrong, I'm saying whatever the >>>> industry as a whole is doing obviously isn't working and perhaps a >>>> different approach is required. >>> >>> You haven't recommended anything new, and you really need to do some >>> reading in order to understand why it isn't as simple as you seem to >>> think it is. >>> >>>> Security teams? My network has me, myself and I. >>> >>> And a relatively small network, too. >>> >>>> If for example ChinaNet's abuse department isn't doing anything about >>>> complains, eventually their whole network gets blocked a /32 at a >>>> time. *shrugs* Their loss. >>> >>> Again, it isn't that simple. >>> >>> ----------------------------------- >>> Roland Dobbins >>> > From damian at google.com Sun Jan 11 22:22:06 2015 From: damian at google.com (Damian Menscher) Date: Sun, 11 Jan 2015 14:22:06 -0800 Subject: DDOS solution recommendation In-Reply-To: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> References: <28333B30-49A1-476D-AABA-8731E2DBCFB0@ianai.net> <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, Jan 11, 2015 at 5:07 AM, Mike Hammett wrote: > > Blackhole all of the zombie attackers and notify their abuse departments. > Sure, most of the owners of the PCs being used in these scenarios have no > idea they're being used to attack people, but I'd think that if their > network's abuse department was notified, either they'd contact the customer > about it issue or at least have on file that they were notified. When the > unknowing end-user reached out to support over larger and larger parts of > the Internet not working, they'd be told to clean up their system. Notification to abuse departments is largely a waste of time, but I've tried it anyway. My records indicate that over the past year I sent 3139 emails covering 24054 known-infected machines regarding 16 distinct incidents. A few machines were cleaned, but the attacks continue. Part of the problem is that most network providers don't have the resources to chase down abuse issues. In one case I informed an ISP of ~70k infected customers. They said their support team couldn't possibly handle that, and took no action. In another case, a well-known ISP was unable to receive my list because they bounced emails over a certain size. I try to bypass the ISP where possible by sending notices directly to users ( http://googleblog.blogspot.com/2011/07/using-data-to-protect-people-from.html and http://googleonlinesecurity.blogspot.com/2012/05/notifying-users-affected-by-dnschanger.html). That has a provable effect, though not as large as one might hope. Your later comment of blackholing is indeed quite effective (I once blackholed 3 IPs at a hosting provider who had ignored 3 abuse complaints over 3 months, and they had the machines cleaned within days), but is a last resort since there can be significant collateral damage (which is, of course, why they suddenly decided to care). I've also encouraged website owners to care by marking their website as infected in Google search results. On Sun, Jan 11, 2015 at 5:50 AM, Patrick W. Gilmore wrote: > > But I've said for years (despite some people saying I am confused) that > BCP38 is the single most important thing we can do to cut DDoS. > Yes, agreed. I've been working on this, but unfortunately nobody is ready to take action, often citing hardware limitations. And since nobody is compliant, there's no way to push others to upgrade. On Sun, Jan 11, 2015 at 6:51 AM, Job Snijders wrote: > On Sun, Jan 11, 2015 at 08:46:40AM -0600, Mike Hammett wrote: > > Is anyone maintaining a list of good, bad and ugly providers in terms > > of how seriously they take things they should like BCP38 and community > > support and whatever else that's quantifiable? > > This list sheds some light on antispoofing commitments made by various > providers: https://www.routingmanifesto.org/participants/ I have traced spoofed-source attacks to providers on that list. I once considered posting a list-of-shame, but it would be too long (and not win any friends here). On Sun, Jan 11, 2015 at 10:09 AM, Joel Maslak wrote: > I urge caution in building automatic systems to respond to network abuse, > lest you have unanticipated consequences. > I'm always amused at the automation people create. Googlebot is a frequent victim of admins who know perl, but not /robots.txt. Damian From rdobbins at arbor.net Sun Jan 11 23:08:41 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 12 Jan 2015 06:08:41 +0700 Subject: DDOS solution recommendation In-Reply-To: <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> References: <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> Message-ID: <33E1155C-F59C-441E-A4DC-547674DA3C90@arbor.net> On 11 Jan 2015, at 23:33, Mike Hammett wrote: > I don't have the time to read a dozen presentations. Then just read one: Skip the screenshots entirely, if you want, and just read the textual slides at the beginning and the end. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sun Jan 11 23:18:00 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 12 Jan 2015 06:18:00 +0700 Subject: DDOS solution recommendation In-Reply-To: <77143.1420992587@turing-police.cc.vt.edu> References: <25342930.1994.1420989680127.JavaMail.mhammett@ThunderFuck> <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> <77143.1420992587@turing-police.cc.vt.edu> Message-ID: On 11 Jan 2015, at 23:09, Valdis.Kletnieks at vt.edu wrote: > Sounds like RFC1925, section 4 should be top of the list? Indeed - as well as section 8. ;> ----------------------------------- Roland Dobbins From gtaylor at tnetconsulting.net Mon Jan 12 00:56:30 2015 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 11 Jan 2015 18:56:30 -0600 Subject: DDOS solution recommendation In-Reply-To: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> References: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> Message-ID: <54B31BBE.3000502@tnetconsulting.net> On 01/11/2015 03:22 PM, Mike Hammett wrote: > I know that UDP can be spoofed, but it's not likely that the SSH, > mail, etc. login attempts, web page hits, etc. would be spoofed as > they'd have to know the response to be of any good. I encourage you to investigate "Triangular Spamming". (http://www.cs.ucr.edu/~zhiyunq/pub/oakland10_triangular_spamming.pdf) The "Triangular..." technique does specifically that, allow the attacker to "...know the responses...". In short, the bot receives the reply to the spoofed source IP and forwards information on to the attacker so that it can continue the conversation. In effect, three parties are having a one way conversation in a ring. > There's more going on than UDP spoofing\amplification. Frankly the > most damaging thing to me has been SMTP hijacking. For you to login > to my SMTP server and send e-mail out, there's going to be one hell > of a conversation going on. Yes, there is what appears to you to be be a conversation going on. However, the source of what you are hearing is not where you think it's from. -- Grant. . . . unix || die From marka at isc.org Mon Jan 12 01:42:00 2015 From: marka at isc.org (Mark Andrews) Date: Mon, 12 Jan 2015 12:42:00 +1100 Subject: DDOS solution recommendation In-Reply-To: Your message of "Sun, 11 Jan 2015 18:56:30 -0600." <54B31BBE.3000502@tnetconsulting.net> References: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> <54B31BBE.3000502@tnetconsulting.net> Message-ID: <20150112014200.32372274EBBB@rock.dv.isc.org> In message <54B31BBE.3000502 at tnetconsulting.net>, Grant Taylor writes: > On 01/11/2015 03:22 PM, Mike Hammett wrote: > > I know that UDP can be spoofed, but it's not likely that the SSH, > > mail, etc. login attempts, web page hits, etc. would be spoofed as > > they'd have to know the response to be of any good. > > I encourage you to investigate "Triangular Spamming". > (http://www.cs.ucr.edu/~zhiyunq/pub/oakland10_triangular_spamming.pdf) > The "Triangular..." technique does specifically that, allow the attacker > to "...know the responses...". > > In short, the bot receives the reply to the spoofed source IP and > forwards information on to the attacker so that it can continue the > conversation. In effect, three parties are having a one way > conversation in a ring. Just because you can only identify one of the two remotes doesn't mean that you can't report the addresses. It is involved in the communication stream. > > There's more going on than UDP spoofing\amplification. Frankly the > > most damaging thing to me has been SMTP hijacking. For you to login > > to my SMTP server and send e-mail out, there's going to be one hell > > of a conversation going on. > > Yes, there is what appears to you to be be a conversation going on. > However, the source of what you are hearing is not where you think it's > from. Actually it is coming from where you think it is coming from, just not directly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gtaylor at tnetconsulting.net Mon Jan 12 04:14:10 2015 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 11 Jan 2015 22:14:10 -0600 Subject: DDOS solution recommendation In-Reply-To: <20150112014200.32372274EBBB@rock.dv.isc.org> References: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> <54B31BBE.3000502@tnetconsulting.net> <20150112014200.32372274EBBB@rock.dv.isc.org> Message-ID: <54B34A12.4000704@tnetconsulting.net> On 01/11/2015 07:42 PM, Mark Andrews wrote: > Just because you can only identify one of the two remotes doesn't > mean that you can't report the addresses. It is involved in the > communication stream. It is very difficult to make a case that the host with the spoofed IP address is attacking you when it is not even sending any traffic to you. The ISP will very likely not see ANY traffic originating from spoofed IP destined to your server. So what you do know is effectively useless. > Actually it is coming from where you think it is coming from, just > not directly. No, not quite. 1 - Spammer (A) sends packets to server (B) spoofing the source address of the relay (C). (A spoofed as) C -> B 2 - Server (B) replies to relay (C) B -> C 3 - Relay (C) sends packets to spammer (A). C -> A Notice how the relay (C) is never sending packets -to- the server (B). The traffic is NOT coming from the relay (C). This is not a case of the spammer (A) sending to the relay (C) that is then sending the traffic to the server (B). There is no traffic originating from the relay (C) going to the server (B). Thus there is nothing to be caught by the relay's ISP ISP filter. You could even use this technique on ISPs that block outbound traffic to TCP port 25. (Like many cable / DSL providers.) Also notice how the server (B) never knows the spammer's (A) real IP. This is very similar in concept to a Joe Job, but at the TCP layer, not the SMTP application layer. ---- The point of this is that it is possible, and occurring in the wild, to spoof TCP source IP addresses. - So, don't blindly trust the source IP address used for TCP connections. - It is possible (if not practical) to spoof them and have a successfully transmission. -- Grant. . . . unix || die From mmg at transtelco.net Mon Jan 12 06:35:15 2015 From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=) Date: Sun, 11 Jan 2015 23:35:15 -0700 Subject: Recommended L2 switches for a new IXP Message-ID: Dear Nanog community We are trying to build a new IXP in some US Metro areas where we have multiple POPs and I was wondering what do you recommend for L2 switches. I know that some IXPs use Nexus, Brocade, Force10 but I don't personally have experience with these switches. It would be great if you can share your experience and recommendations. There are so many options that I don't know if it makes sense to start with a modular switch (usually expensive because the backplane, dual dc, dual CPU, etc) or start with a 1RU high density switch that support new protocols like Trill and that supposedly allow you to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G ports for exchange participants, 40G/100G for uplinks between switches and flow support for statistics and traffic analysis. Thank you and have a great day. Regards From marka at isc.org Mon Jan 12 07:06:57 2015 From: marka at isc.org (Mark Andrews) Date: Mon, 12 Jan 2015 18:06:57 +1100 Subject: DDOS solution recommendation In-Reply-To: Your message of "Sun, 11 Jan 2015 22:14:10 -0600." <54B34A12.4000704@tnetconsulting.net> References: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> <54B31BBE.3000502@tnetconsulting.net> <20150112014200.32372274EBBB@rock.dv.isc.org> <54B34A12.4000704@tnetconsulting.net> Message-ID: <20150112070657.12E41275504F@rock.dv.isc.org> In message <54B34A12.4000704 at tnetconsulting.net>, Grant Taylor writes: > On 01/11/2015 07:42 PM, Mark Andrews wrote: > > Just because you can only identify one of the two remotes doesn't > > mean that you can't report the addresses. It is involved in the > > communication stream. > > It is very difficult to make a case that the host with the spoofed IP > address is attacking you when it is not even sending any traffic to you. It is accepting the reply traffic and forwarding it to the originator. It is directly involved. > The ISP will very likely not see ANY traffic originating from spoofed > IP destined to your server. They will see the reply traffic and will see the acks increasing etc. > So what you do know is effectively useless. > > > Actually it is coming from where you think it is coming from, just > > not directly. > > No, not quite. > > 1 - Spammer (A) sends packets to server (B) spoofing the source address > of the relay (C). > (A spoofed as) C -> B > 2 - Server (B) replies to relay (C) > B -> C > 3 - Relay (C) sends packets to spammer (A). > C -> A > > Notice how the relay (C) is never sending packets -to- the server (B). > The traffic is NOT coming from the relay (C). > > This is not a case of the spammer (A) sending to the relay (C) that is > then sending the traffic to the server (B). > > There is no traffic originating from the relay (C) going to the server > (B). Thus there is nothing to be caught by the relay's ISP ISP filter. > You could even use this technique on ISPs that block outbound traffic > to TCP port 25. (Like many cable / DSL providers.) > > Also notice how the server (B) never knows the spammer's (A) real IP. > > This is very similar in concept to a Joe Job, but at the TCP layer, not > the SMTP application layer. > > ---- > > The point of this is that it is possible, and occurring in the wild, to > spoof TCP source IP addresses. - So, don't blindly trust the source IP > address used for TCP connections. - It is possible (if not practical) > to spoof them and have a successfully transmission. There is no difference to this than asymetric routing. The address you are presented with is part of the communication path. > -- > Grant. . . . > unix || die -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From david at mailplus.nl Mon Jan 12 08:29:59 2015 From: david at mailplus.nl (David Hofstee) Date: Mon, 12 Jan 2015 09:29:59 +0100 Subject: DDOS solution recommendation In-Reply-To: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> Message-ID: <78C35D6C1A82D243B830523B4193CF5F8D72815381@SBS1.blinker.local> Hi Mike, About trying to hit the mail ports... It is very easy for a domain to set its MX to a random host name. So before you block you might want to check the To-domain in the header of the mail. Otherwise it is too easy to DoS yourself (by planting email addresses in systems, such as mine, and then changing the MX of that domain to your hosts). David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Mike Hammett Verzonden: Sunday, January 11, 2015 2:46 PM Aan: Roland Dobbins CC: nanog at nanog.org Onderwerp: Re: DDOS solution recommendation Well there's going to be two sources of the attack... infested clients or machines setup for this purpose (usually in a datacenter somewhere). Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet. They may not care of it's a server in a datacenter being used to attack, but an infested home PC would care once they can't get to Google, FaceBook, Instagram, whatever. If the attacker's abuse contact doesn't care, then just brute force of more and more of the Internet being offline to them, they'll figure it out. You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days. No point in letting troublemakers (manual or scripted) spend more time on the network than necessary. The more people (as a collective or not) that do this, the better. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Roland Dobbins" To: nanog at nanog.org Sent: Sunday, January 11, 2015 7:24:55 AM Subject: Re: DDOS solution recommendation On 11 Jan 2015, at 20:07, Mike Hammett wrote: > but I'd think that if their network's abuse department was notified, > either they'd contact the customer about it issue or at least have on > file that they were notified. Just because we think something, that doesn't make it true. ;> > The way to stop this stuff is for those millions of end users to clean > up their infected PCs. You may want to do some reading on this topic in order to gain a better understanding of the issues involved: Some of us have been dealing with DDoS attacks for a couple of decades, now. If it were a simple problem, we would've solved it long ago. Here's a hint: scale alone makes any problem literally orders of magnitude more difficult than any given instance thereof. ----------------------------------- Roland Dobbins From colinj at mx5.org.uk Mon Jan 12 08:48:28 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 12 Jan 2015 08:48:28 +0000 Subject: DDOS solution recommendation In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F8D72815381@SBS1.blinker.local> References: <22194530.1736.1420983994911.JavaMail.mhammett@ThunderFuck> <78C35D6C1A82D243B830523B4193CF5F8D72815381@SBS1.blinker.local> Message-ID: <1E87891D-934E-4EFF-A61B-87B10988C418@gt86car.org.uk> > On 12 Jan 2015, at 08:29, David Hofstee wrote: > > Hi Mike, > > About trying to hit the mail ports... It is very easy for a domain to set its MX to a random host name. So before you block you might want to check the To-domain in the header of the mail. Otherwise it is too easy to DoS yourself (by planting email addresses in systems, such as mine, and then changing the MX of that domain to your hosts). > Should be overcome by good dont block range checker and header checks as above Colin From tore at fud.no Mon Jan 12 09:19:00 2015 From: tore at fud.no (Tore Anderson) Date: Mon, 12 Jan 2015 10:19:00 +0100 Subject: DDOS solution recommendation In-Reply-To: <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> Message-ID: <20150112101900.47cfea3d@echo.ms.redpill-linpro.com> * "Roland Dobbins" > On 11 Jan 2015, at 20:52, Ca By wrote: > > > 3. Have RTBH ready for some special case. > > S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too). But are there any transit providers that support flowspec these days? As I understand it, only GTT used to, but they stopped. I'd love to use flowspec over D/RTBH, but to me it seems like vapourware. Tore From rdobbins at arbor.net Mon Jan 12 09:28:35 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 12 Jan 2015 16:28:35 +0700 Subject: DDOS solution recommendation In-Reply-To: <20150112101900.47cfea3d@echo.ms.redpill-linpro.com> References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> <20150112101900.47cfea3d@echo.ms.redpill-linpro.com> Message-ID: On 12 Jan 2015, at 16:19, Tore Anderson wrote: > I'd love to use flowspec over D/RTBH, but to me it seems like > vapourware. I meant on your own infrastructure, apologies for the confusion. Transit providers can't offer S/RTBH to their downstreams for obvious reasons. Transit providers utilizing Juniper aggregation edge routers could do it now - why they don't, I don't know. And now Cisco are now supporting flowspec on some of their platforms, as well. ----------------------------------- Roland Dobbins From tore at fud.no Mon Jan 12 09:51:58 2015 From: tore at fud.no (Tore Anderson) Date: Mon, 12 Jan 2015 10:51:58 +0100 Subject: DDOS solution recommendation In-Reply-To: References: <21151566.1466.1420981585260.JavaMail.mhammett@ThunderFuck> <5A6E09C5-ED1C-4DB5-9E48-74F54D5C5131@arbor.net> <20150112101900.47cfea3d@echo.ms.redpill-linpro.com> Message-ID: <20150112105158.19e3fa1e@echo.ms.redpill-linpro.com> * "Roland Dobbins" > On 12 Jan 2015, at 16:19, Tore Anderson wrote: > > > I'd love to use flowspec over D/RTBH, but to me it seems like > > vapourware. > > I meant on your own infrastructure, apologies for the confusion. Right. So if I first need to accept the traffic onto my infrastructure before I can discard it, I'm dead in the water anyway: My uplinks will sit there at 100% ingress utilisation, dropping legitimate traffic. /32 or /128 D/RTBH announcements towards my transits is my only real option at this point. That helps protect against collateral damage, and if the customer's audience is local, it can also restore full operation for the attacked customer's primary markets (which are usually reached via peers instead of transits). For attacks that are conveniently sized smaller than my upstream capacity, I could see that flowspec could be useful, but not in a unique way, as inside my own network I can easily distribute targeted stateless discard ACLs in many other ways too (I use Netconf currently). > Transit providers utilizing Juniper aggregation edge routers could do it > now - why they don't, I don't know. I'd definitively be willing to pay a premium for such a feature. Tore From refresh.lsong at gmail.com Mon Jan 12 13:05:38 2015 From: refresh.lsong at gmail.com (Song Li) Date: Mon, 12 Jan 2015 21:05:38 +0800 Subject: command that can display routes containing AS loops Message-ID: <54B3C6A2.4030509@gmail.com> Hi everyone, I am curious about the AS loops in the AS-path. I think there should be a very, very few received BGP routes that contain the local AS#. But because such routes will be dropped and not installed in Loc-RIB, I want to know if there is a command that can display the dropped routes containing AS loops (in cisco or juniper router). Does anybody know? Thanks! Best! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From nanog at ics-il.net Mon Jan 12 13:07:48 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 12 Jan 2015 07:07:48 -0600 (CST) Subject: Recommended L2 switches for a new IXP In-Reply-To: Message-ID: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> I look forward to this thread. I think one important thing is who is your addressable market size? I'm working with a startup IXP and there's only 20 carriers in the building. A chassis based switch would be silly as there would never be that many people present. 2x 1U switches would be more than plenty in their environment. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Monday, January 12, 2015 12:35:15 AM Subject: Recommended L2 switches for a new IXP Dear Nanog community We are trying to build a new IXP in some US Metro areas where we have multiple POPs and I was wondering what do you recommend for L2 switches. I know that some IXPs use Nexus, Brocade, Force10 but I don't personally have experience with these switches. It would be great if you can share your experience and recommendations. There are so many options that I don't know if it makes sense to start with a modular switch (usually expensive because the backplane, dual dc, dual CPU, etc) or start with a 1RU high density switch that support new protocols like Trill and that supposedly allow you to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G ports for exchange participants, 40G/100G for uplinks between switches and flow support for statistics and traffic analysis. Thank you and have a great day. Regards From me at geordish.org Mon Jan 12 13:16:40 2015 From: me at geordish.org (Dave Bell) Date: Mon, 12 Jan 2015 13:16:40 +0000 Subject: command that can display routes containing AS loops In-Reply-To: <54B3C6A2.4030509@gmail.com> References: <54B3C6A2.4030509@gmail.com> Message-ID: On a Juniper, you could do something like: show route hidden aspath-regex .*.* Regards, Dave On 12 January 2015 at 13:05, Song Li wrote: > Hi everyone, > > I am curious about the AS loops in the AS-path. I think there should be a > very, very few received BGP routes that contain the local AS#. But because > such routes will be dropped and not installed in Loc-RIB, I want to know if > there is a command that can display the dropped routes containing AS loops > (in cisco or juniper router). Does anybody know? > > Thanks! > > Best! > > -- > Song Li > Room 4-204, FIT Building, > Network Security, > Department of Electronic Engineering, > Tsinghua University, Beijing 100084, China > Tel:( +86) 010-62446440 > E-mail: refresh.lsong at gmail.com From refresh.lsong at gmail.com Mon Jan 12 13:36:11 2015 From: refresh.lsong at gmail.com (Song Li) Date: Mon, 12 Jan 2015 21:36:11 +0800 Subject: command that can display routes containing AS loops In-Reply-To: References: <54B3C6A2.4030509@gmail.com> Message-ID: <54B3CDCB.20904@gmail.com> Hi Dave, thanks! I tried the command and found that it works. Do you know the similar command on cisco? Regards, Song 在 2015/1/12 21:16, Dave Bell 写道: > On a Juniper, you could do something like: > > show route hidden aspath-regex .*.* > > Regards, > Dave > > On 12 January 2015 at 13:05, Song Li wrote: >> Hi everyone, >> >> I am curious about the AS loops in the AS-path. I think there should be a >> very, very few received BGP routes that contain the local AS#. But because >> such routes will be dropped and not installed in Loc-RIB, I want to know if >> there is a command that can display the dropped routes containing AS loops >> (in cisco or juniper router). Does anybody know? >> >> Thanks! >> >> Best! >> >> -- >> Song Li >> Room 4-204, FIT Building, >> Network Security, >> Department of Electronic Engineering, >> Tsinghua University, Beijing 100084, China >> Tel:( +86) 010-62446440 >> E-mail: refresh.lsong at gmail.com -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From colinj at gt86car.org.uk Sun Jan 11 20:28:51 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Sun, 11 Jan 2015 20:28:51 +0000 Subject: DDOS solution recommendation In-Reply-To: <95FAA7BE-A61D-4F9A-8966-E13076AA93F4@ianai.net> References: <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> <95FAA7BE-A61D-4F9A-8966-E13076AA93F4@ianai.net> Message-ID: <3B1A3D80-278A-47D1-87E7-D9E7860186F1@gt86car.org.uk> unfortunately chinanet antispam/abuse email box is always full, after a while people block . always check arin/ripe for known good provider blocks and actively exclude from rules ddos protection via careful overview ips rules and active web source ip monitoring works well, the hard part is daily rule updates and blocks until you know most traffic is genuine. colin Sent from my iPhone > On 11 Jan 2015, at 19:42, "Patrick W. Gilmore" wrote: > > I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease". > > Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world. > > Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic. > > Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner. > > -- > TTFN, > patrick > >> On Jan 11, 2015, at 14:34 , Phil Bedard wrote: >> >> Many attacks can use spoofed source IPs, so who are you really blocking? >> >> That's why BCP38 as mentioned many times already is a necessary tool in >> fighting the attacks overall. >> >> Phil >> >> >> >> >>> On 1/11/15, 4:33 PM, "Mike Hammett" wrote: >>> >>> I didn't necessarily think I was shattering minds with my ideas. >>> >>> I don't have the time to read a dozen presentations. >>> >>> Blackhole them and move on. I don't care whose feelings I hurt. This >>> isn't kindergarten. Maybe "you" should have tried a little harder to not >>> get a virus in the first place. Quit clicking on male enhancement ads or >>> update your OS occasionally. I'm not going to spend a bunch of time and >>> money to make sure someone's bubble of bliss doesn't get popped. Swift, >>> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days >>> you can prove yourself to be responsible, we can try this again. Well, >>> that or a sufficient support request. >>> >>> Besides, if enough people did hat, the list of blackholes wouldn't be >>> huge as someone upstream already blocked them. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "Roland Dobbins" >>> To: nanog at nanog.org >>> Sent: Sunday, January 11, 2015 9:29:33 AM >>> Subject: Re: DDOS solution recommendation >>> >>> >>>> On 11 Jan 2015, at 22:21, Mike Hammett wrote: >>>> >>>> I'm not saying what you're doing is wrong, I'm saying whatever the >>>> industry as a whole is doing obviously isn't working and perhaps a >>>> different approach is required. >>> >>> You haven't recommended anything new, and you really need to do some >>> reading in order to understand why it isn't as simple as you seem to >>> think it is. >>> >>>> Security teams? My network has me, myself and I. >>> >>> And a relatively small network, too. >>> >>>> If for example ChinaNet's abuse department isn't doing anything about >>>> complains, eventually their whole network gets blocked a /32 at a >>>> time. *shrugs* Their loss. >>> >>> Again, it isn't that simple. >>> >>> ----------------------------------- >>> Roland Dobbins > From dave-nanog at pooserville.com Mon Jan 12 04:57:40 2015 From: dave-nanog at pooserville.com (Dave Pooser) Date: Sun, 11 Jan 2015 22:57:40 -0600 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: <9ea34653da96846ba58bb1270b69969d.squirrel@66.201.44.180> References: <9ea34653da96846ba58bb1270b69969d.squirrel@66.201.44.180> Message-ID: >Wonder when Cloud providers get a clue, step up and help recommend a >circuit size based on users and the services their customer buy from them. When they think that poor customer word of mouth will cost them more sales then they are currently gaining from customers who would *not* move away from on-prem if they understood all the costs including increased bandwidth? -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com From chenliu419 at gmail.com Mon Jan 12 06:24:17 2015 From: chenliu419 at gmail.com (Chen Liu) Date: Sun, 11 Jan 2015 22:24:17 -0800 Subject: IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network (MASONS) Message-ID: --------------------------------------------------------------------------------------------------------------------------- Apologies for cross-postings! --------------------------------------------------------------------------------------------------------------------------- Call for Papers IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network (MASONS) With ICCCN 2015 at Las Vegas, Aug 3 – 6, 2015 http://www.icccn.org/icccn15/ MASONS 2015 is Technically Co-Sponsored by the IEEE Communication Society 1. Theme Today, many research organizations in academia, government labs and industry are exploring SDN and NFV technologies to study and materialize their benefits in real world networks. These benefits are enabling automation, reducing time to market in case of new service introductions, optimization and/or improving overall economics of network and system management and operations. However to materialize the benefits of SDN and NFV at larger scale across multiple domains, similar to today’s internet, additional investigations are needed which should focus beyond the core SDN, NFV features and functionalities. This involves: development of multi-domain SDN network to support Internet; large scale deployment of novel applications, identification of technological and operational gaps in research and development over the longer term to increase the capability of SDN and NFV powered networks, and better integrate them with existing public Internet and emerging cloud technologies; Identification of security, manageability gaps, including opportunities to build in additional levels of security, resilience and management capabilities. 2. Topics of interest This workshop aims to show case and disseminate new ideas and high quality research on manageability and security of Software Defined Network and Network Function Virtualization. We solicit original research articles, review papers, theoretical studies, and practical software systems incorporating new paradigms, experimental prototypes, and insightful requirement analysis with the above theme including, but not limited to the topics below: * Design, requirements and prototypes of Software Defined Exchanges (SDX) to enable interoperability and use of new approaches with the current Internet infrastructure. * Security, privacy, authentication, trust, verification for SDN and NFV. * Integration of compute, storage and network under the Software Defined Infrastructure (SDI) paradigm. * Analysis of new management challenges that SDN and NFV has introduced. * Network management practices and business processes for SDN and NFV, in service provider and data center infrastructures. * Tools and operational procedures for managing SDN. * New paradigms in network operations, administration and management (OAM), service orchestration, service engineering, converged network-compute and data center management. * Software Defined Network (SDN), abstraction, programmability, application Interface, south and northbound API. * Network Function Virtualization (NFV), distributed control, virtual switches, routing virtualization. * Network system management, orchestration, resource management and optimization, integration, interoperability. * Network operations management related automation, troubleshooting and management tools. * Cloud based network and system management application paradigms. * Application of artificial intelligence (AI), machine learning (ML), analytics and big data in network and system management. * Insights about Network Management System architectural requirements analysis. * Scalability of SDN, NFV, SDI, NMS systems. * User experience, user interface design issues and challenges in NMS for SDN, NFV, ethnographic studies on network operations centers, usability studies of management applications. 3. Instructions for IEEE MASONS 2015 Workshop Authors: Submitted manuscripts must be formatted in standard IEEE camera ready format (double column, 10 pt font) and must be submitted via EasyChair ( http://www.easychair.org/) as PDF files (formatted for 8.5×11 inch paper). It should be no longer than 6 pages with up to two extra pages given the authors are willing to pay an over-length charge per extra page. The detailed information can be found in the ICCCN 2015 (Las Vegas) website. For any workshop related questions or additional information please contact the General, TPC, or Workshop Chairs. Submitted papers should not be previously published in or be under consideration for publication in another conference or journal. Paper titles and/or author names cannot be changed and/or added to the papers once papers are submitted to ICCCN 2015 for review. Submissions must include a title, abstract, keywords, author(s) and affiliation(s) with postal and email address(es) and phone number(s). A paper abstract must be registered on EasyChair by the deadline indicated below. 4. Important dates: * Abstract Due: Mar 2, 2015 * Paper Due: Mar 10, 2015 * Acceptance Notification: Apr 13, 2015 * Camera Ready Due: May 8, 2015 5. Review and Publication of Manuscripts: Submitted papers will be reviewed by the ICCCN 2015 TPC members and judged on originality, technical correctness, relevance, and quality of presentation. An accepted paper must be presented at the conference venue by one (who registered/paid full author reg. fee) of authors to be included in the conference venue. Each full registration covers up to two ICCCN 2015 conference papers authored by the registered/paid author. Accepted and presented papers will be published in the conference proceedings and submitted to IEEE Xplore as well as other Abstracting and Indexing (A&I) databases. The page limit for papers is 6 pages. Papers should be submitted on EDAS, the link for this workshop will be published here shortly. Papers of special merit will be selected for possible fast track at a journal special issue at IJCNDS (see details at http://www.inderscience.com/info/ingeneral/cfplist.php?jcode=ijcnds and http://www.manageability-at-scale.org/cfp/). 6. Workshop chairs * Inder Monga, ESnet and LBNL, USA, imonga at es.net * Amitava Biswas, Cisco Systems, USA, amitavabiswas at ieee.org * Chen Liu, Microsoft, USA, chenliu419 at gmail.com From chenliu419 at gmail.com Mon Jan 12 06:25:59 2015 From: chenliu419 at gmail.com (Chen Liu) Date: Sun, 11 Jan 2015 22:25:59 -0800 Subject: MISSION 2015 - IEEE Workshop on Management Issues in SDN, SDI and NFV Message-ID: --------------------------------------------------------------------------------------------------------------------------- Apologies for cross-postings! --------------------------------------------------------------------------------------------------------------------------- IEEE Workshop on Management Issues in SDN, SDI and NFV LONDON, UK, APRIL 13-17, 2015 http://sites.ieee.org/netsoft/workshop/MISSION/ CALL FOR PAPERS SCOPE The IEEE International Workshop on Management Issues in Software defined network, Software defined infrastructure and network function virtualizatION (MISSION 2015) will be held between April 13-17, 2015 in London, U.K. at the Cruciform Building of University College London (UCL) along with 1st IEEE International Conference on Network Softwarization (NetSoft 2015). Software is increasing flexibility and programmability of infrastructure in SDN, SDI and NFV. This softwarization trend has materialized new product and services that lead to significant business benefits. To realize these benefits, we also need to rethink the management issues along with making progress in core functionalities for SDN, SDI and NFV. A holistic system-oriented innovation approach is needed to redesign infrastructure management operations, NMS artefacts and functionalities at multiple levels. The MISSION 2015 workshop will address these new and emerging management issues in SDN, SDI and NFV. TOPICS OF INTEREST Authors are invited to submit papers that fall into the area of software-defined and virtualized infrastructures. Topics of interest include, but are not limited to, the following: - System management challenges in SDN, SDI, NFV - Network management practices and business procedures for SDN, NFV, SDI in telco and enterprise data center infrastructures - New paradigms in network operations, administration and management for SDN, SDI and NFV - Management challenges in mobile and wireless SDN and NFV environment - Service orchestration in converged network-compute and data center management - Reliability issues in SDN and NFV Network management & operations related automation, troubleshooting and administration tools for SDN, SDI and NFV - Cloud based network and system management application paradigms for SDN , SDI and NFV - Application of artificial intelligence (AI), machine learning (ML), analytics and big data in network and system management of SDN, SDI and NFV - Insights about Network Management System (NMS) architectural requirements & analysis - User experience, user interface design issues and challenges in NMS for SDN, SDI, NFV ethnographic studies on network operations centers, usability studies of management applications PAPER SUBMISSION Authors are invited to submit only original papers not published or submitted for publication elsewhere. Papers should be within 6 pages, in IEEE 2-column US-Letter style using IEEE Conference ( www.ieee.org/conferences_events/conferences/publishing/templates.html) templates and submitted in PDF format via EDAS at: http://edas.info/19315. Papers exceeding these limits, multiple submissions elsewhere, and self-plagiarized papers will be rejected without further review. All submitted papers will be subject to a peer-review process. Accepted and presented papers will be published in the MISSION 2015 Workshop Proceedings and submitted to IEEE Xplore. IMPORTANT DATES - Paper Submission: January 30, 2015 - Notification of Acceptance: February 28, 2015 - Camera Ready Papers: March 13, 2015 WORKSHOP CO-CHAIRS - Kashinath Basu, Oxford Brookes University, UK - Chen Liu, Microsoft, US NETSOFT WORKSHOP CO-CHAIRS - Amitava Biswas, Cisco Systems, US - Noura Limam, University of Waterloo, Canada NETSOFT GENERAL CO-CHAIRS - Prosper Chemouil, Orange Labs, France - George Pavlou, University College London, UK IEEE SDN Initiative Chair - Antonio Manzalini, Telecom Italia, Italy TECHNICAL SPONSORS - IEEE Communications Society, IEEE Computer Society, IEEE Consumer Electronics Society and IEEE Signal Processing From rdobbins at arbor.net Mon Jan 12 14:55:06 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 12 Jan 2015 21:55:06 +0700 Subject: DDOS solution recommendation In-Reply-To: <3B1A3D80-278A-47D1-87E7-D9E7860186F1@gt86car.org.uk> References: <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> <95FAA7BE-A61D-4F9A-8966-E13076AA93F4@ianai.net> <3B1A3D80-278A-47D1-87E7-D9E7860186F1@gt86car.org.uk> Message-ID: <82FD3166-4F5E-4385-BD47-39F7055C6004@arbor.net> On 12 Jan 2015, at 3:28, Colin Johnston wrote: > ips rules and active web source ip monitoring works well Until it doesn't: ----------------------------------- Roland Dobbins From bob at FiberInternetCenter.com Mon Jan 12 15:07:24 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 12 Jan 2015 07:07:24 -0800 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: References: <9ea34653da96846ba58bb1270b69969d.squirrel@66.201.44.180> Message-ID: >>Wonder when Cloud providers get a clue, step up and help recommend a >>circuit size based on users and the services their customer buy from >> them. > > When they think that poor customer word of mouth will cost them more sales > then they are currently gaining from customers who would *not* move away > from on-prem if they understood all the costs including increased > bandwidth? Agreed - it will be the smart ones that don't wait for that end user experience to go bad. In the meantime, I can tell you sitting here in silicon valley that all these sharp VCs don't see the hole in many of these basic business plans called "Cloud, Rack of servers in multiple locations". Bob Evans CTO From aaron at wholesaleinternet.net Mon Jan 12 15:24:56 2015 From: aaron at wholesaleinternet.net (Aaron) Date: Mon, 12 Jan 2015 09:24:56 -0600 Subject: Recommended L2 switches for a new IXP In-Reply-To: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> Message-ID: <54B3E748.4010304@wholesaleinternet.net> We used to use Brocade FastIrons until we needed more 10G port density. We moved to Brocade SX's. Originally, when it was 2 or 3 peers, we used an old Netgear switch. :) Aaron On 1/12/2015 7:07 AM, Mike Hammett wrote: > I look forward to this thread. > > I think one important thing is who is your addressable market size? I'm working with a startup IXP and there's only 20 carriers in the building. A chassis based switch would be silly as there would never be that many people present. 2x 1U switches would be more than plenty in their environment. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Manuel Marín" > To: nanog at nanog.org > Sent: Monday, January 12, 2015 12:35:15 AM > Subject: Recommended L2 switches for a new IXP > > Dear Nanog community > > We are trying to build a new IXP in some US Metro areas where we have > multiple POPs and I was wondering what do you recommend for L2 switches. I > know that some IXPs use Nexus, Brocade, Force10 but I don't personally have > experience with these switches. It would be great if you can share your > experience and recommendations. There are so many options that I don't know > if it makes sense to start with a modular switch (usually expensive because > the backplane, dual dc, dual CPU, etc) or start with a 1RU high density > switch that support new protocols like Trill and that supposedly allow you > to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G > ports for exchange participants, 40G/100G for uplinks between switches and > flow support for statistics and traffic analysis. > > Thank you and have a great day. > > Regards > > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From lists at mtin.net Mon Jan 12 15:34:21 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Mon, 12 Jan 2015 10:34:21 -0500 Subject: Recommended L2 switches for a new IXP In-Reply-To: <54B3E748.4010304@wholesaleinternet.net> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <54B3E748.4010304@wholesaleinternet.net> Message-ID: <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> Like Mike says, it depends on your market. Are these markets where there are existing exchanges? Cost per port is what we always look at. If we are going into a market where there won’t be much growth we look at Cisco and Force 10. Their cost per port is usually cheaper for smaller 10 Gig switches. You need something that is fairly robust. Reliability in an exchange is a key component. If you go with a non-chassis switch make sure you have redundancy in your design. We like Chassis based switches because they tend to be more robust. But thats just my take on it. Justin --- Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Jan 12, 2015, at 10:24 AM, Aaron wrote: > > We used to use Brocade FastIrons until we needed more 10G port density. We moved to Brocade SX's. > > Originally, when it was 2 or 3 peers, we used an old Netgear switch. :) > > Aaron > > On 1/12/2015 7:07 AM, Mike Hammett wrote: >> I look forward to this thread. >> >> I think one important thing is who is your addressable market size? I'm working with a startup IXP and there's only 20 carriers in the building. A chassis based switch would be silly as there would never be that many people present. 2x 1U switches would be more than plenty in their environment. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Manuel Marín" >> To: nanog at nanog.org >> Sent: Monday, January 12, 2015 12:35:15 AM >> Subject: Recommended L2 switches for a new IXP >> >> Dear Nanog community >> >> We are trying to build a new IXP in some US Metro areas where we have >> multiple POPs and I was wondering what do you recommend for L2 switches. I >> know that some IXPs use Nexus, Brocade, Force10 but I don't personally have >> experience with these switches. It would be great if you can share your >> experience and recommendations. There are so many options that I don't know >> if it makes sense to start with a modular switch (usually expensive because >> the backplane, dual dc, dual CPU, etc) or start with a 1RU high density >> switch that support new protocols like Trill and that supposedly allow you >> to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G >> ports for exchange participants, 40G/100G for uplinks between switches and >> flow support for statistics and traffic analysis. >> >> Thank you and have a great day. >> >> Regards >> >> > > -- > ================================================================ > Aaron Wendel > Chief Technical Officer > Wholesale Internet, Inc. (AS 32097) > (816)550-9030 > http://www.wholesaleinternet.com > ================================================================ > From nick at foobar.org Mon Jan 12 15:43:26 2015 From: nick at foobar.org (Nick Hilliard) Date: Mon, 12 Jan 2015 15:43:26 +0000 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: Message-ID: <54B3EB9E.7070907@foobar.org> On 12/01/2015 06:35, Manuel Marín wrote: > We are trying to build a new IXP in some US Metro areas where we have > multiple POPs and I was wondering what do you recommend for L2 switches. I > know that some IXPs use Nexus, Brocade, Force10 but I don't personally have > experience with these switches. It would be great if you can share your > experience and recommendations. For a startup IXP, it would probably not be sensible to use chassis based kit due to cost / real estate issues. Some personal opinions: - I have a strong preference for using only open bridging protocols. This excludes out vendor proprietary fabrics (VDX, OTV, etc). This is important for when you do fabric upgrades on multi-site IXPs. - You will probably want a product which supports sflow, as peer-to-peer traffic graphs are massively useful. Most vendors support sflow on most of their products with the notable exception of Cisco where only the Nexus 3K team were enlightened enough to shim it in. I haven't yet come across a L2 netflow implementation which works well enough to be an adequate substitute, but ymmv. - VPLS based fabrics may be important if you have an interesting topology. If it is important to you, then you will need a VPLS implementation which will do proper load balancing over multiple links. Most don't and this is a very hard problem to handle on smaller kit. - There is no excuse for vendor transceiver locking or transceiver crippling (e.g. refusing to show DDM values) and vendors who do this need to be made aware that it's not an acceptable business proposition. - you need kit which will support Layer 2 ACLs and Layer 3 ACLs on layer 2 interfaces. - you should get in with the open-ix crowd and chat to people over pizza or peanuts. You will learn a lot from in an afternoon of immersion with peers. Nick From hannigan at gmail.com Mon Jan 12 15:44:04 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 12 Jan 2015 10:44:04 -0500 Subject: Recommended L2 switches for a new IXP In-Reply-To: <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <54B3E748.4010304@wholesaleinternet.net> <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> Message-ID: Substantial amounts of hive mind went into this topic in the formation of Open-IX and particularly around optimizing costs and maximizing traffic. See http://bit.ly/N-OIX1 for a reference. Best, -M< On Mon, Jan 12, 2015 at 10:34 AM, Justin Wilson - MTIN wrote: > Like Mike says, it depends on your market. Are these markets where there > are existing exchanges? > > Cost per port is what we always look at. If we are going into a market > where there won't be much growth we look at Cisco and Force 10. Their cost > per port is usually cheaper for smaller 10 Gig switches. You need something > that is fairly robust. > > Reliability in an exchange is a key component. If you go with a > non-chassis switch make sure you have redundancy in your design. We like > Chassis based switches because they tend to be more robust. But thats just > my take on it. > > Justin > > --- > Justin Wilson j2sw at mtin.net > http://www.mtin.net > Managed Services - xISP Solutions - Data Centers > http://www.thebrotherswisp.com > Podcast about xISP topics > http://www.midwest-ix.com > Peering - Transit - Internet Exchange > > > On Jan 12, 2015, at 10:24 AM, Aaron wrote: > > > > We used to use Brocade FastIrons until we needed more 10G port density. > We moved to Brocade SX's. > > > > Originally, when it was 2 or 3 peers, we used an old Netgear switch. :) > > > > Aaron > > > > On 1/12/2015 7:07 AM, Mike Hammett wrote: > >> I look forward to this thread. > >> > >> I think one important thing is who is your addressable market size? I'm > working with a startup IXP and there's only 20 carriers in the building. A > chassis based switch would be silly as there would never be that many > people present. 2x 1U switches would be more than plenty in their > environment. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> > >> > >> ----- Original Message ----- > >> > >> From: "Manuel Marín" > >> To: nanog at nanog.org > >> Sent: Monday, January 12, 2015 12:35:15 AM > >> Subject: Recommended L2 switches for a new IXP > >> > >> Dear Nanog community > >> > >> We are trying to build a new IXP in some US Metro areas where we have > >> multiple POPs and I was wondering what do you recommend for L2 > switches. I > >> know that some IXPs use Nexus, Brocade, Force10 but I don't personally > have > >> experience with these switches. It would be great if you can share your > >> experience and recommendations. There are so many options that I don't > know > >> if it makes sense to start with a modular switch (usually expensive > because > >> the backplane, dual dc, dual CPU, etc) or start with a 1RU high density > >> switch that support new protocols like Trill and that supposedly allow > you > >> to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G > >> ports for exchange participants, 40G/100G for uplinks between switches > and > >> flow support for statistics and traffic analysis. > >> > >> Thank you and have a great day. > >> > >> Regards > >> > >> > > > > -- > > ================================================================ > > Aaron Wendel > > Chief Technical Officer > > Wholesale Internet, Inc. (AS 32097) > > (816)550-9030 > > http://www.wholesaleinternet.com > > ================================================================ > > > > From woody at pch.net Mon Jan 12 15:54:38 2015 From: woody at pch.net (Bill Woodcock) Date: Mon, 12 Jan 2015 10:54:38 -0500 Subject: Recommended L2 switches for a new IXP In-Reply-To: <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <54B3E748.4010304@wholesaleinternet.net> <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> Message-ID: <26AB1A01-6D34-4C3A-80E8-1186C955DE5B@pch.net> > On Jan 12, 2015, at 10:34 AM, Justin Wilson - MTIN wrote: > Cost per port is what we always look at. If we are going into a market where there won’t be much growth we look at Cisco and Force 10. Their cost per port is usually cheaper for smaller 10 Gig switches. You need something that is fairly robust. We see a lot of IXPs being formed or upgrading with Cisco Nexus 3524 switches, which have 48 1G-10G SFP/SFP+ physical ports, license-limited to 24 active, upgradeable to 48 active. FWIW, 83% of IXPs have 48 or fewer participants, and 70% of IXPs have 24 or fewer participants. And the failure rate of chassis-based switches is _way_ higher than that of stand-alone switches. So we never recommend that an IXP buy a switch larger than necessary to accommodate 18 months reasonably-projectable growth. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hannigan at gmail.com Mon Jan 12 15:55:42 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 12 Jan 2015 10:55:42 -0500 Subject: Recommended L2 switches for a new IXP In-Reply-To: <54B3EB9E.7070907@foobar.org> References: <54B3EB9E.7070907@foobar.org> Message-ID: On Mon, Jan 12, 2015 at 10:43 AM, Nick Hilliard wrote: [ clip, good stuff ] - you should get in with the open-ix crowd and chat to people over pizza or > peanuts. You will learn a lot from in an afternoon of immersion with > peers. > And you can find that crowd here http://mailman.open-ix.org/mailman/listinfo/public if interested. Best, -M< From amekkaoui at mektel.ca Mon Jan 12 16:17:16 2015 From: amekkaoui at mektel.ca (A MEKKAOUI) Date: Mon, 12 Jan 2015 11:17:16 -0500 Subject: 129.250.35.250/251 NTT DNS Instability Message-ID: <004001d02e83$3c0cf520$b426df60$@ca> Hi We've seen some DNS instability and want to know if anyone of you have seen the same thing. Your comments will be appreciated. Thank you Karim From jared at puck.nether.net Mon Jan 12 16:19:43 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 12 Jan 2015 11:19:43 -0500 Subject: 129.250.35.250/251 NTT DNS Instability In-Reply-To: <004001d02e83$3c0cf520$b426df60$@ca> References: <004001d02e83$3c0cf520$b426df60$@ca> Message-ID: <07F1A542-0E9E-489A-86B1-872D9654E9EF@puck.nether.net> Can you give examples? 129.250.35.250/251 are anycasted so a trace route would be helpful as well. - jared > On Jan 12, 2015, at 11:17 AM, A MEKKAOUI wrote: > > Hi > > > > We've seen some DNS instability and want to know if anyone of you have seen > the same thing. Your comments will be appreciated. > > > > Thank you > > > > Karim > > From amekkaoui at mektel.ca Mon Jan 12 16:28:31 2015 From: amekkaoui at mektel.ca (A MEKKAOUI) Date: Mon, 12 Jan 2015 11:28:31 -0500 Subject: 129.250.35.250/251 NTT DNS Instability In-Reply-To: <07F1A542-0E9E-489A-86B1-872D9654E9EF@puck.nether.net> References: <004001d02e83$3c0cf520$b426df60$@ca> <07F1A542-0E9E-489A-86B1-872D9654E9EF@puck.nether.net> Message-ID: <004901d02e84$d2bd3380$78379a80$@ca> What we've seen is that this morning some of our clients cannot connect to internet and when we change the DNS to use Google DNS internet works fine. I'll see if I can get a tracert to 129.250.35.250 and will send it. Thank you A MEKKAOUI MEKTEL INC www.mektel.ca -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: 12 janvier 2015 11:20 To: A MEKKAOUI Cc: nanog at nanog.org Subject: Re: 129.250.35.250/251 NTT DNS Instability Can you give examples? 129.250.35.250/251 are anycasted so a trace route would be helpful as well. - jared > On Jan 12, 2015, at 11:17 AM, A MEKKAOUI wrote: > > Hi > > > > We've seen some DNS instability and want to know if anyone of you have > seen the same thing. Your comments will be appreciated. > > > > Thank you > > > > Karim > > From ammar at fastreturn.net Mon Jan 12 16:30:39 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Mon, 12 Jan 2015 20:30:39 +0400 Subject: 129.250.35.250/251 NTT DNS Instability In-Reply-To: <004901d02e84$d2bd3380$78379a80$@ca> References: <004001d02e83$3c0cf520$b426df60$@ca> <07F1A542-0E9E-489A-86B1-872D9654E9EF@puck.nether.net> <004901d02e84$d2bd3380$78379a80$@ca> Message-ID: Traceroute from my home connection in Dubai, United Arab Emirates: traceroute to 129.250.35.250 (129.250.35.250), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 2.293 ms 1.549 ms 7.657 ms 2 94.203.22.1 (94.203.22.1) 3.281 ms 8.348 ms 8.494 ms 3 10.39.162.65 (10.39.162.65) 5.722 ms 2.753 ms 4.999 ms 4 10.171.0.19 (10.171.0.19) 2.780 ms 3.022 ms 3.278 ms 5 10.100.35.78 (10.100.35.78) 6.344 ms 5.340 ms 5.254 ms 6 10.44.24.162 (10.44.24.162) 90.120 ms 90.141 ms 92.448 ms 7 116.51.26.81 (116.51.26.81) 276.227 ms 265.609 ms 368.385 ms 8 ae-1.r21.sngpsi05.sg.bb.gin.ntt.net (129.250.7.20) 275.509 ms 270.857 ms 274.100 ms 9 ae-4.r23.tokyjp01.jp.bb.gin.ntt.net (129.250.7.37) 258.667 ms 265.824 ms 256.990 ms 10 x.ns.gin.ntt.net (129.250.35.250) 251.302 ms 252.865 ms 255.337 ms > On Jan 12, 2015, at 8:28 PM, A MEKKAOUI wrote: > > What we've seen is that this morning some of our clients cannot connect to > internet and when we change the DNS to use Google DNS internet works fine. > I'll see if I can get a tracert to 129.250.35.250 and will send it. > > Thank you > > A MEKKAOUI > MEKTEL INC > www.mektel.ca > > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: 12 janvier 2015 11:20 > To: A MEKKAOUI > Cc: nanog at nanog.org > Subject: Re: 129.250.35.250/251 NTT DNS Instability > > Can you give examples? 129.250.35.250/251 are anycasted so a trace route > would be helpful as well. > > - jared > >> On Jan 12, 2015, at 11:17 AM, A MEKKAOUI wrote: >> >> Hi >> >> >> >> We've seen some DNS instability and want to know if anyone of you have >> seen the same thing. Your comments will be appreciated. >> >> >> >> Thank you >> >> >> >> Karim >> >> > > From Valdis.Kletnieks at vt.edu Mon Jan 12 16:35:58 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 12 Jan 2015 11:35:58 -0500 Subject: DDOS solution recommendation In-Reply-To: Your message of "Mon, 12 Jan 2015 18:06:57 +1100." <20150112070657.12E41275504F@rock.dv.isc.org> References: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> <54B31BBE.3000502@tnetconsulting.net> <20150112014200.32372274EBBB@rock.dv.isc.org> <54B34A12.4000704@tnetconsulting.net> <20150112070657.12E41275504F@rock.dv.isc.org> Message-ID: <8443.1421080558@turing-police.cc.vt.edu> On Mon, 12 Jan 2015 18:06:57 +1100, Mark Andrews said: > > The ISP will very likely not see ANY traffic originating from spoofed > > IP destined to your server. > > They will see the reply traffic and will see the acks increasing etc. Assuming they think to *look* for it. 99.8% of ISPs will get a complaint "Your IP w.x.y.z is sending me spam", drop a tap on the IP address, see no matching outbound traffic, and hit delete on the complaint. They will almost certainly not think to look in something like the ICMP port unreachable packets the address is sending to some *other* address. (Remember, the compromised relay machine has to send *very* little info back to the actual sending box - TCP sequence numbers, maybe windows, and SMTP reply codes that can be encoded in 1 byte or even less) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon Jan 12 16:36:13 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 12 Jan 2015 11:36:13 -0500 Subject: DDOS solution recommendation In-Reply-To: Your message of "Sun, 11 Jan 2015 15:08:45 -0600." <5949794.3034.1421010501752.JavaMail.mhammett@ThunderFuck> References: <5949794.3034.1421010501752.JavaMail.mhammett@ThunderFuck> Message-ID: <8466.1421080573@turing-police.cc.vt.edu> On Sun, 11 Jan 2015 15:08:45 -0600, Mike Hammett said: > If that were to happen, it'd be for 30 days and it'd be whatever random > residential account or APNIC address that was doing it. Not really a big loss. OK. I'll bite. When you get home today, blackhole www.google.com for your home IP address(es) and call us back in 30 days and let us know how big a loss it is. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jbfixurpc at gmail.com Mon Jan 12 16:39:03 2015 From: jbfixurpc at gmail.com (Joe) Date: Mon, 12 Jan 2015 10:39:03 -0600 Subject: Google's Safe Browsing Alerts for Network Administrators In-Reply-To: <000101d02b9e$736488e0$5a2d9aa0$@iname.com> References: <000101d02b9e$736488e0$5a2d9aa0$@iname.com> Message-ID: I've not found it very usefull. As for Shadowserver.org I really wish folks trying to save the internet from mis-configurations would stop randomly scanning networks to fix. These folks are one of many "do-gooders" that are adding to the traffic being dropped and logged. Its only contibuting to the daily clutter of problem folk already poking and prodding. Regards, -Joe On Thu, Jan 8, 2015 at 5:54 PM, Frank Bulk wrote: From dwessels at verisign.com Mon Jan 12 17:43:12 2015 From: dwessels at verisign.com (Wessels, Duane) Date: Mon, 12 Jan 2015 17:43:12 +0000 Subject: Root and ARPA DNSSEC operational message - signature validity period Message-ID: <51C394F4-F416-4590-93E8-101414BE467A@verisign.com> DNSSEC signatures in the Root and ARPA zones were initially given a validity period of 7 days. The validity period is being increased to 10 days. Both the Root and ARPA zones publish their NS RRsets with a TTL of 6 days. A signature validity period of 7 days means that a root server instance that is not updated within 24 hours may return NS RRset responses whose TTL exceeds the signature validity. This could cause problems for validating recursive name servers that forward queries through non-validators. A longer signature validity provides a longer buffer in the distribution of these zones. Note that we are not aware of any cases where the 7 day signature validity period has caused problems for DNSSEC validators. This is a precautionary measure. As of today, the zones now have the increased validity period. Please feel free to contact us with concerns or questions. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From frnkblk at iname.com Mon Jan 12 18:38:20 2015 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 12 Jan 2015 12:38:20 -0600 Subject: Google's Safe Browsing Alerts for Network Administrators In-Reply-To: References: <000101d02b9e$736488e0$5a2d9aa0$@iname.com> Message-ID: <003301d02e96$f015b170$d0411450$@iname.com> Thanks for that feedback on Google’s Safe Browsing Alerts. We’ll have to see how that works out for us over time. In regards to ShadowServer, I don’t think they’re randomly scanning networks, and neither are folks like OpenResolver – I think it’s pretty systematic, albeit from perhaps only a certain point of view on the Internet. If their scans are being dropped and logged, that’s great – that means someone has measures in place to mitigate attacks that leverage those UDP protocols. But for those who use their output to better secure their own and clients’ endpoint devices, it’s much appreciated. If it’s really just a drop in the ocean, what does it matter to you? Frank From: Joe [mailto:jbfixurpc at gmail.com] Sent: Monday, January 12, 2015 10:39 AM To: Frank Bulk Cc: nanog at nanog.org Subject: Re: Google's Safe Browsing Alerts for Network Administrators I've not found it very usefull. As for Shadowserver.org I really wish folks trying to save the internet from mis-configurations would stop randomly scanning networks to fix. These folks are one of many "do-gooders" that are adding to the traffic being dropped and logged. Its only contibuting to the daily clutter of problem folk already poking and prodding. Regards, -Joe On Thu, Jan 8, 2015 at 5:54 PM, Frank Bulk > wrote: From dave at temk.in Mon Jan 12 19:24:49 2015 From: dave at temk.in (Dave Temkin) Date: Mon, 12 Jan 2015 14:24:49 -0500 Subject: FL-IX in Miami is ready for new members Message-ID: Hi all, FL-IX has started issuing LOAs for both 36 NE 2nd Street and NOTA in Miami. If you have a network that peers at either location, we'd love to have you as a member. We've committed to keeping the IX platform free for 3 years (you bring the cross connect; we have pre-negotiated deals for inexpensive riser in 36 NE 2nd). For more information, please see: http://www.fl-ix.net Here's a list of who's signed up thus far: Akamai Amazon BroadbandONE CloudFlare Coresite Facebook GlobeNet/Oi Google GTT Hurricane Electric Init7 Limelight Netflix Reliable Hosting Quadranet Snappy Internet SoftLayer T-Mobile Telx Vault Networks WebSense Yahoo Regards, -Dave From owen at delong.com Mon Jan 12 19:52:11 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Jan 2015 11:52:11 -0800 Subject: DDOS solution recommendation In-Reply-To: <3B1A3D80-278A-47D1-87E7-D9E7860186F1@gt86car.org.uk> References: <9666BB7E-E2FD-43E3-BEAE-66CD228FC8CC@arbor.net> <18730191.2584.1420993984566.JavaMail.mhammett@ThunderFuck> <95FAA7BE-A61D-4F9A-8966-E13076AA93F4@ianai.net> <3B1A3D80-278A-47D1-87E7-D9E7860186F1@gt86car.org.uk> Message-ID: > On Jan 11, 2015, at 12:28 , Colin Johnston wrote: > > unfortunately chinanet antispam/abuse email box is always full, after a while people block . > always check arin/ripe for known good provider blocks and actively exclude from rules ARIN and RIPE do not provide address reputation information, so I’m not sure what you mean by known good blocks. Anything you can get from ARIN or RIPE, you would also want to check against LACNIC, AfriNIC, and APNIC as each of the 5 RIRs has their own region for which they are responsible. If you merely check ARIN and RIPE, you will permit only North America (exclusive of Mexico), some Caribbean Islands, Antarctica, and Europe. If it is not your intent to completely ignore Asia, Africa, Latin America, and about half of the Caribbean, then your above statement needs adjustment. > ddos protection via careful overview ips rules and active web source ip monitoring works well, the hard part is daily rule updates and blocks until you know most traffic is genuine. This helps with PPS attacks against web servers and certain web exploits. It does not help with volumetric attacks. The simple fact is that the only way to deal with volumetric attacks is to have them blocked or filtered upstream unless you have sufficient ingress capacity to sink the attack traffic volume. Owen > > colin > > Sent from my iPhone > >> On 11 Jan 2015, at 19:42, "Patrick W. Gilmore" wrote: >> >> I do love solutions which open larger attack surfaces than they are supposed to close. In the US, we call that "a cure worse than the disease". >> >> Send packet from random bot with source of Google, Comcast, Akamai, etc. to Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off from the world. >> >> Voilà! Denial of service accomplished without all the hassle of sending 100s of Gbps of traffic. >> >> Best part is he was willing to explain this to 10,000+ of his not-so-closest friends, in a search-engine-indexed manner. >> >> -- >> TTFN, >> patrick >> >>> On Jan 11, 2015, at 14:34 , Phil Bedard wrote: >>> >>> Many attacks can use spoofed source IPs, so who are you really blocking? >>> >>> That's why BCP38 as mentioned many times already is a necessary tool in >>> fighting the attacks overall. >>> >>> Phil >>> >>> >>> >>> >>>> On 1/11/15, 4:33 PM, "Mike Hammett" wrote: >>>> >>>> I didn't necessarily think I was shattering minds with my ideas. >>>> >>>> I don't have the time to read a dozen presentations. >>>> >>>> Blackhole them and move on. I don't care whose feelings I hurt. This >>>> isn't kindergarten. Maybe "you" should have tried a little harder to not >>>> get a virus in the first place. Quit clicking on male enhancement ads or >>>> update your OS occasionally. I'm not going to spend a bunch of time and >>>> money to make sure someone's bubble of bliss doesn't get popped. Swift, >>>> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days >>>> you can prove yourself to be responsible, we can try this again. Well, >>>> that or a sufficient support request. >>>> >>>> Besides, if enough people did hat, the list of blackholes wouldn't be >>>> huge as someone upstream already blocked them. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Roland Dobbins" >>>> To: nanog at nanog.org >>>> Sent: Sunday, January 11, 2015 9:29:33 AM >>>> Subject: Re: DDOS solution recommendation >>>> >>>> >>>>> On 11 Jan 2015, at 22:21, Mike Hammett wrote: >>>>> >>>>> I'm not saying what you're doing is wrong, I'm saying whatever the >>>>> industry as a whole is doing obviously isn't working and perhaps a >>>>> different approach is required. >>>> >>>> You haven't recommended anything new, and you really need to do some >>>> reading in order to understand why it isn't as simple as you seem to >>>> think it is. >>>> >>>>> Security teams? My network has me, myself and I. >>>> >>>> And a relatively small network, too. >>>> >>>>> If for example ChinaNet's abuse department isn't doing anything about >>>>> complains, eventually their whole network gets blocked a /32 at a >>>>> time. *shrugs* Their loss. >>>> >>>> Again, it isn't that simple. >>>> >>>> ----------------------------------- >>>> Roland Dobbins >> From mark.tinka at seacom.mu Mon Jan 12 20:11:10 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 12 Jan 2015 22:11:10 +0200 Subject: Recommended L2 switches for a new IXP In-Reply-To: <26AB1A01-6D34-4C3A-80E8-1186C955DE5B@pch.net> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> <26AB1A01-6D34-4C3A-80E8-1186C955DE5B@pch.net> Message-ID: <201501122211.13678.mark.tinka@seacom.mu> On Monday, January 12, 2015 05:54:38 PM Bill Woodcock wrote: > We see a lot of IXPs being formed or upgrading with Cisco > Nexus 3524 switches, which have 48 1G-10G SFP/SFP+ > physical ports, license-limited to 24 active, > upgradeable to 48 active. > > FWIW, 83% of IXPs have 48 or fewer participants, and 70% > of IXPs have 24 or fewer participants. And the failure > rate of chassis-based switches is _way_ higher than that > of stand-alone switches. So we never recommend that an > IXP buy a switch larger than necessary to accommodate 18 > months reasonably-projectable growth. Would tend to agree with this approach, and the above. Multi-rate (i.e., 1Gbps/10Gbps SFP/SFP+) standalone 1U switches are reasonable these days. The issue you'll probably run into with them is limited support for features you find being implemented by larger exchange points (VPLS, Sflow, e.t.c.), and quirks with the hardware that could impact things like Layer 2 or Layer 3 filtering (especially if they are using off-the-self silicon), e.t.c. Test before you buy, in as far as you can anticipate your (growth) needs. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bross at pobox.com Mon Jan 12 20:17:36 2015 From: bross at pobox.com (Brandon Ross) Date: Mon, 12 Jan 2015 15:17:36 -0500 (EST) Subject: DDOS solution recommendation In-Reply-To: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> References: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, 11 Jan 2015, Mike Hammett wrote: > I know that UDP can be spoofed, but it's not likely that the SSH, mail, > etc. login attempts, web page hits, etc. would be spoofed as they'd have > to know the response to be of any good. Okay, so I'm curious. Are you saying that you do not automatically block attackers until you can confirm a 3-way TCP handshake has been completed, and therefore you aren't blocking sources that were spoofed? If so, how are you protecting yourself against SYN attacks? If not, then you've made it quite easy for attackers to deny any source they want. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From morrowc.lists at gmail.com Mon Jan 12 21:05:14 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 12 Jan 2015 16:05:14 -0500 Subject: DDOS solution recommendation In-Reply-To: References: <24459190.3096.1421011316528.JavaMail.mhammett@ThunderFuck> Message-ID: On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross wrote: > On Sun, 11 Jan 2015, Mike Hammett wrote: > >> I know that UDP can be spoofed, but it's not likely that the SSH, mail, >> etc. login attempts, web page hits, etc. would be spoofed as they'd have to >> know the response to be of any good. > > > Okay, so I'm curious. Are you saying that you do not automatically block > attackers until you can confirm a 3-way TCP handshake has been completed, > and therefore you aren't blocking sources that were spoofed? If so, how are > you protecting yourself against SYN attacks? If not, then you've made it > quite easy for attackers to deny any source they want. this all seems like a fabulous conversation we're watching, but really .. if someone wants to block large swaths of the intertubes on their systems it's totally up to them, right? They can choose to not be functional all they want, as near as I can tell... and arguing with someone with this mentality isn't productive, especially after several (10+? folk) have tried to show and tell some experience that would lead to more cautious approaches. If mike wants less packets, that's all cool... I'm not sure it's actually solving anything, but sure, go right ahead, have fun. -chris From nanog at ics-il.net Mon Jan 12 21:35:21 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 12 Jan 2015 15:35:21 -0600 (CST) Subject: DDOS solution recommendation In-Reply-To: Message-ID: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> So the preferred alternative is to simply do nothing at all? That seems fair. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Christopher Morrow" To: "Brandon Ross" Cc: "Mike Hammett" , "NANOG list" Sent: Monday, January 12, 2015 3:05:14 PM Subject: Re: DDOS solution recommendation On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross wrote: > On Sun, 11 Jan 2015, Mike Hammett wrote: > >> I know that UDP can be spoofed, but it's not likely that the SSH, mail, >> etc. login attempts, web page hits, etc. would be spoofed as they'd have to >> know the response to be of any good. > > > Okay, so I'm curious. Are you saying that you do not automatically block > attackers until you can confirm a 3-way TCP handshake has been completed, > and therefore you aren't blocking sources that were spoofed? If so, how are > you protecting yourself against SYN attacks? If not, then you've made it > quite easy for attackers to deny any source they want. this all seems like a fabulous conversation we're watching, but really .. if someone wants to block large swaths of the intertubes on their systems it's totally up to them, right? They can choose to not be functional all they want, as near as I can tell... and arguing with someone with this mentality isn't productive, especially after several (10+? folk) have tried to show and tell some experience that would lead to more cautious approaches. If mike wants less packets, that's all cool... I'm not sure it's actually solving anything, but sure, go right ahead, have fun. -chris From surfer at mauigateway.com Mon Jan 12 21:41:16 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 12 Jan 2015 13:41:16 -0800 Subject: DDOS solution recommendation Message-ID: <20150112134116.2C2A653D@m0005299.ppops.net> --- nanog at ics-il.net wrote: From: Mike Hammett So the preferred alternative is to simply do nothing at all? That seems fair. --------------------------------------- No, the answer is to find the groups that have already looked into the issues, learn what they've done and see if you can provide quality input to the group. scott From tony at wicks.co.nz Mon Jan 12 21:41:20 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 13 Jan 2015 10:41:20 +1300 Subject: Recommended L2 switches for a new IXP In-Reply-To: <201501122211.13678.mark.tinka@seacom.mu> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> <26AB1A01-6D34-4C3A-80E8-1186C955DE5B@pch.net> <201501122211.13678.mark.tinka@seacom.mu> Message-ID: <010901d02eb0$82157330$86405990$@wicks.co.nz> People seem to be avoiding recommending actual devices, well I would recommend the Juniper EX4600 - http://www.juniper.net/us/en/products-services/switching/ex-series/ex4600/ They are affordable, highly scalable, stackable and run JunOS. cheers From morrowc.lists at gmail.com Mon Jan 12 21:43:07 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 12 Jan 2015 16:43:07 -0500 Subject: DDOS solution recommendation In-Reply-To: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> References: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> Message-ID: On Mon, Jan 12, 2015 at 4:35 PM, Mike Hammett wrote: > So the preferred alternative is to simply do nothing at all? That seems fair. fairly certain I didn't say that, no. I think that lots of smarter-than-me folk have already chimed in with options... All I wanted to do with this was to note I didn't say 'do nothing'. -chris > ----- Original Message ----- > > From: "Christopher Morrow" > To: "Brandon Ross" > Cc: "Mike Hammett" , "NANOG list" > Sent: Monday, January 12, 2015 3:05:14 PM > Subject: Re: DDOS solution recommendation > > On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross wrote: >> On Sun, 11 Jan 2015, Mike Hammett wrote: >> >>> I know that UDP can be spoofed, but it's not likely that the SSH, mail, >>> etc. login attempts, web page hits, etc. would be spoofed as they'd have to >>> know the response to be of any good. >> >> >> Okay, so I'm curious. Are you saying that you do not automatically block >> attackers until you can confirm a 3-way TCP handshake has been completed, >> and therefore you aren't blocking sources that were spoofed? If so, how are >> you protecting yourself against SYN attacks? If not, then you've made it >> quite easy for attackers to deny any source they want. > > this all seems like a fabulous conversation we're watching, but really > .. if someone wants to block large swaths of the intertubes on their > systems it's totally up to them, right? They can choose to not be > functional all they want, as near as I can tell... and arguing with > someone with this mentality isn't productive, especially after several > (10+? folk) have tried to show and tell some experience that would > lead to more cautious approaches. > > If mike wants less packets, that's all cool... I'm not sure it's > actually solving anything, but sure, go right ahead, have fun. > > -chris > From rdobbins at arbor.net Mon Jan 12 21:44:06 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 13 Jan 2015 04:44:06 +0700 Subject: DDOS solution recommendation In-Reply-To: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> References: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> Message-ID: <0DF6C3B7-9A01-4B88-8820-23CC771DE145@arbor.net> On 13 Jan 2015, at 4:35, Mike Hammett wrote: > So the preferred alternative is to simply do nothing at all? Straw man. Nobody's said that. Quite the opposite, in point of fact. As noted previously in this thread, there's a lot of information out there about how operators deal with DDoS attacks. All it takes is the willingness to devote a bit of time to educating oneself. ----------------------------------- Roland Dobbins From mehmet at akcin.net Mon Jan 12 21:47:51 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 12 Jan 2015 13:47:51 -0800 Subject: Recommended L2 switches for a new IXP In-Reply-To: <010901d02eb0$82157330$86405990$@wicks.co.nz> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> <26AB1A01-6D34-4C3A-80E8-1186C955DE5B@pch.net> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> Message-ID: <2F74DB0F-BB91-4F34-A0BA-00F05542B946@akcin.net> That's what I had recommended him directly ;) Mehmet > On Jan 12, 2015, at 1:41 PM, Tony Wicks wrote: > > People seem to be avoiding recommending actual devices, well I would > recommend the Juniper EX4600 - > > http://www.juniper.net/us/en/products-services/switching/ex-series/ex4600/ > > They are affordable, highly scalable, stackable and run JunOS. > > cheers > > > From morrowc.lists at gmail.com Mon Jan 12 21:51:12 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 12 Jan 2015 16:51:12 -0500 Subject: Recommended L2 switches for a new IXP In-Reply-To: <010901d02eb0$82157330$86405990$@wicks.co.nz> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <79F0983B-8F78-4ED6-8925-3B9324AA79C0@mtin.net> <26AB1A01-6D34-4C3A-80E8-1186C955DE5B@pch.net> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> Message-ID: On Mon, Jan 12, 2015 at 4:41 PM, Tony Wicks wrote: > People seem to be avoiding recommending actual devices, well I would > recommend the Juniper EX4600 - > > http://www.juniper.net/us/en/products-services/switching/ex-series/ex4600/ > > They are affordable, highly scalable, stackable and run JunOS. (and you can't do anything worthwhile for acls to protect that device from the world/ix-users) From wmaton at ottix.net Mon Jan 12 22:28:08 2015 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Mon, 12 Jan 2015 17:28:08 -0500 (EST) Subject: DDOS solution recommendation In-Reply-To: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> References: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> Message-ID: On Mon, 12 Jan 2015, Mike Hammett wrote: > So the preferred alternative is to simply do nothing at all? That seems fair. Not at all. But it is your network and only you know what the suggested approaches others have already run through are best for your environment. But if you haven't yet done so, help the rest of us and deploy BCP38 too. :-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Christopher Morrow" > To: "Brandon Ross" > Cc: "Mike Hammett" , "NANOG list" > Sent: Monday, January 12, 2015 3:05:14 PM > Subject: Re: DDOS solution recommendation > > On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross wrote: >> On Sun, 11 Jan 2015, Mike Hammett wrote: >> >>> I know that UDP can be spoofed, but it's not likely that the SSH, mail, >>> etc. login attempts, web page hits, etc. would be spoofed as they'd have to >>> know the response to be of any good. >> >> >> Okay, so I'm curious. Are you saying that you do not automatically block >> attackers until you can confirm a 3-way TCP handshake has been completed, >> and therefore you aren't blocking sources that were spoofed? If so, how are >> you protecting yourself against SYN attacks? If not, then you've made it >> quite easy for attackers to deny any source they want. > > this all seems like a fabulous conversation we're watching, but really > .. if someone wants to block large swaths of the intertubes on their > systems it's totally up to them, right? They can choose to not be > functional all they want, as near as I can tell... and arguing with > someone with this mentality isn't productive, especially after several > (10+? folk) have tried to show and tell some experience that would > lead to more cautious approaches. > > If mike wants less packets, that's all cool... I'm not sure it's > actually solving anything, but sure, go right ahead, have fun. > > -chris > wfms From max.clark at gmail.com Mon Jan 12 23:29:45 2015 From: max.clark at gmail.com (Max Clark) Date: Mon, 12 Jan 2015 15:29:45 -0800 Subject: DDOS solution recommendation In-Reply-To: <98868920-8D0C-4613-B047-4BA321DEEC18@fastreturn.net> References: <54B1FE0C.4060405@winterei.se> <98868920-8D0C-4613-B047-4BA321DEEC18@fastreturn.net> Message-ID: Ditto - we've been seeing average attack size pushing the 40-50 Gbps mark. The "serious" attacks are much, much larger. On Sat, Jan 10, 2015 at 8:50 PM, Ammar Zuberi wrote: > I'd beg to differ on this one. The average attacks we're seeing are double > that, around the 30-40g mark. Since NTP and SSDP amplification began, we've > been seeing all kinds of large attacks. > > Obviously, these can easily be blocked upstream to your network. Hibernia > Networks blocks them for us. > > Ammar > > > On 11 Jan 2015, at 8:37 am, Paul S. wrote: > > > > While it indeed is true that attacks up to 600 gbit/s (If OVH and > CloudFlare's data is to be believed) have been known to happen in the wild, > it's very unlikely that you need to mitigate anything close. > > > > The average attack is usually around the 10g mark (That too barely) -- > so even solutions that service up to 20g work alright. > > > > Obviously, concerns are different if you're an enterprise that's a DDoS > magnet -- but for general service providers selling 'protected services,' > food for thought. > > > >> On 1/11/2015 午後 12:48, Damian Menscher wrote: > >>> On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín > wrote: > >>> > >>> I was wondering what are are using for DDOS protection in your > networks. We > >>> are currently evaluating different options (Arbor, Radware, NSFocus, > >>> RioRey) and I would like to know if someone is using the cloud based > >>> solutions/scrubbing centers like Imperva, Prolexic, etc and what are > the > >>> advantages/disadvantages of using a cloud base vs an on-premise > solution. > >>> It would be great if you can share your experience on this matter. > >> On-premise solutions are limited by your own bandwidth. Attacks have > been > >> publicly reported at 400Gbps, and are rumored to be even larger. If you > >> don't have that much network to spare, then packet loss will occur > upstream > >> of your mitigation. Having a good relationship with your network > >> provider(s) can help here, of course. > >> > >> If you go with a cloud-based solution, be wary of their SLA. I've seen > >> some claim 100% uptime (not believable) but of course no refund/credits > for > >> downtime. Another provider only provides 20Gbps protection, then will > >> null-route the victim. > >> > >>> On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble > wrote: > >>> > >>> Also how are folks testing ddos protection? What lab gear,tools,methods > >>> are you using to determine effectiveness of the mitigation. > >> > >> Live-fire is the cheapest approach (just requires some creative > trolling) > >> but if you want to control the "off" button, cloud VMs can be tailored > to > >> your needs. There are also legitimate companies that do network stress > >> testing. > >> > >> Keep in mind that you need to test against a variety of attacks, against > >> all components in the critical path. Attackers aren't particularly > >> methodical, but will still randomly discover any weaknesses you've > >> overlooked. > >> > >> Damian > > > From littlefishguy at gmail.com Mon Jan 12 21:51:58 2015 From: littlefishguy at gmail.com (Scott Fisher) Date: Mon, 12 Jan 2015 16:51:58 -0500 Subject: DDOS solution recommendation In-Reply-To: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> References: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> Message-ID: In looking at this thread, it's apparent that some are trying to over-simplify a not-so-simple problem. As someone brought out earlier, there is no silver bullet to fix for several reasons. Some reasons that I can come up with at the top of my head are: 1) DDOS types vary. 2) Not every network is the same (shocker I know) 3) Time/Money - not every company has the same budget (again, shocker) 4) Staff/Resources - Not every company have admin/engineers at different technical levels. So someone may decide on blocking an attack at different levels because "that's what they know." EG: wordpress guy blocks attacks at the webserver level, an admin blocks it at the system, network admin at the edge. The questions should be much more narrow. "How should I mitigate an NTP reflection" or "what are common mistakes people make when mitigating attacks" are questions that more specific that all can glean from. Thanks, Scott On Mon, Jan 12, 2015 at 4:35 PM, Mike Hammett wrote: > So the preferred alternative is to simply do nothing at all? That seems fair. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Christopher Morrow" > To: "Brandon Ross" > Cc: "Mike Hammett" , "NANOG list" > Sent: Monday, January 12, 2015 3:05:14 PM > Subject: Re: DDOS solution recommendation > > On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross wrote: >> On Sun, 11 Jan 2015, Mike Hammett wrote: >> >>> I know that UDP can be spoofed, but it's not likely that the SSH, mail, >>> etc. login attempts, web page hits, etc. would be spoofed as they'd have to >>> know the response to be of any good. >> >> >> Okay, so I'm curious. Are you saying that you do not automatically block >> attackers until you can confirm a 3-way TCP handshake has been completed, >> and therefore you aren't blocking sources that were spoofed? If so, how are >> you protecting yourself against SYN attacks? If not, then you've made it >> quite easy for attackers to deny any source they want. > > this all seems like a fabulous conversation we're watching, but really > .. if someone wants to block large swaths of the intertubes on their > systems it's totally up to them, right? They can choose to not be > functional all they want, as near as I can tell... and arguing with > someone with this mentality isn't productive, especially after several > (10+? folk) have tried to show and tell some experience that would > lead to more cautious approaches. > > If mike wants less packets, that's all cool... I'm not sure it's > actually solving anything, but sure, go right ahead, have fun. > > -chris > -- Scott From rdobbins at arbor.net Tue Jan 13 05:33:25 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 13 Jan 2015 12:33:25 +0700 Subject: DDOS solution recommendation In-Reply-To: References: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> Message-ID: <75EA3DB2-F987-4090-BB6B-C59BC2E4E1E8@arbor.net> On 13 Jan 2015, at 4:51, Scott Fisher wrote: > The questions should be much more narrow. "How should I mitigate an > NTP reflection" or "what are common mistakes people make when > mitigating attacks" are questions that more specific that all can > glean from. The answers to a lot of those questions are right here: In fact, they're discussed in this single presentation: There are lots more resources available elsewhere on the Internet, as well. We all just need to invest the time to learn from the experiences of others, so that we can then make our own contributions starting from a firm foundation. ----------------------------------- Roland Dobbins From mark.tinka at seacom.mu Tue Jan 13 06:01:11 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 13 Jan 2015 08:01:11 +0200 Subject: Recommended L2 switches for a new IXP In-Reply-To: <010901d02eb0$82157330$86405990$@wicks.co.nz> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> Message-ID: <201501130801.12056.mark.tinka@seacom.mu> On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: > People seem to be avoiding recommending actual devices, > well I would recommend the Juniper EX4600 - > > http://www.juniper.net/us/en/products-services/switching/ > ex-series/ex4600/ > > They are affordable, highly scalable, stackable and run > JunOS. We've been quite happy with the EX4550, but the EX4600 is good too, particularly if you're coming from its younger brother. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mysidia at gmail.com Tue Jan 13 06:02:50 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 13 Jan 2015 00:02:50 -0600 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: References: <9ea34653da96846ba58bb1270b69969d.squirrel@66.201.44.180> Message-ID: Dave Pooser wrote: > then they are currently gaining from customers who would *not* move away > from on-prem if they understood all the costs including increased > bandwidth? The extra bandwidth needed to utilize most SaaS-based applications is not significant. I would say the larger problems in some cases would be the increase in end-to-end latency. SaaS apps seem most sensible where rapid deployment is desired, where the number of users and amount of data are low. In other cases, there are concerns about the additional vendor lock-in, loss of strong control of the data. Cannot assure that it is encrypted and secure against access by social engineering attacks against SaaS provider. Vendors can increase monthly rates later, after it becomes much harder to switch to an on-prem option. The list of security hazards expands. Cannot mitigate application downtime caused by problems with vendor infrastructure or failure of vendor to backup data like they promised. On Mon, Jan 12, 2015 at 9:07 AM, Bob Evans wrote: > In the meantime, I can tell you sitting here in silicon valley that all > these sharp VCs don't see the hole in many of these basic business plans > called "Cloud, Rack of servers in multiple locations". Well, I cannot fault those folks for trying, or VCs from dabbling in Buzzword-Driven financing and risky ventures. Even if there actually are gaping holes in respective plans that they are accepting: they are playing a high-rewards game, and likely have their odds all calculated. 2 or 3% of those 'cloud,rack of servers' people may very well manage to pull off some tricky in-flight maneuvers to escape whichever perceived hole, or come to realize the "fix" after starting with otherwise inherently flawwed plans.. just having a flawwed enough plan was still good enough in theory to show a starting point. Any plan will essentially have holes of varying sizes, with varying amounts of camouflage. But the results of following a plan with holes are not necessarily disastrous... so long as what is actually done is adapted later in place of the original plan as required, in order to accommodate realities. > Bob Evans > CTO -- -JH From Valdis.Kletnieks at vt.edu Tue Jan 13 08:25:26 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 13 Jan 2015 03:25:26 -0500 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: Your message of "Tue, 13 Jan 2015 00:02:50 -0600." References: <9ea34653da96846ba58bb1270b69969d.squirrel@66.201.44.180> Message-ID: <23140.1421137526@turing-police.cc.vt.edu> On Tue, 13 Jan 2015 00:02:50 -0600, Jimmy Hess said: > In other cases, there are concerns about the additional vendor > lock-in, loss of strong control of the data. Cannot assure that it > is encrypted and secure against access by social engineering attacks > against SaaS provider. The one that bit us on the tookas for a recent 'outsource to SaaS' project was trying to negotiate support for our ITAR users (which summarizes to "servers on US soil, and no 'non US persons' for support staff"). We ended up with several racks of gear iin a separate room onsite instead.... (To be fair - several vendors were able to provide ITAR-compliant SaaS, just not at a price point that worked for us...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From twh at megagroup.ru Tue Jan 13 08:29:40 2015 From: twh at megagroup.ru (Stepan Kucherenko) Date: Tue, 13 Jan 2015 11:29:40 +0300 Subject: Recommended L2 switches for a new IXP In-Reply-To: <201501130801.12056.mark.tinka@seacom.mu> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> Message-ID: <54B4D774.50600@megagroup.ru> Is there any particular reason you prefer EX4600 over QFX5100 ? Not counting obvious differences like ports and upgrade options. It's the same chipset after all, and with all upgrades they have the same 10G density (with breakouts). Is that because you can have more 40G ports with EX4600 ? I'm still trying to find out if there are any noticeable software or feature differences. On 13.01.2015 09:01, Mark Tinka wrote: > On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: > >> People seem to be avoiding recommending actual devices, >> well I would recommend the Juniper EX4600 - >> >> http://www.juniper.net/us/en/products-services/switching/ >> ex-series/ex4600/ >> >> They are affordable, highly scalable, stackable and run >> JunOS. > > We've been quite happy with the EX4550, but the EX4600 is > good too, particularly if you're coming from its younger > brother. > > Mark. > From oscar.vives at gmail.com Tue Jan 13 08:40:45 2015 From: oscar.vives at gmail.com (Tei) Date: Tue, 13 Jan 2015 09:40:45 +0100 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: <23140.1421137526@turing-police.cc.vt.edu> References: <9ea34653da96846ba58bb1270b69969d.squirrel@66.201.44.180> <23140.1421137526@turing-police.cc.vt.edu> Message-ID: Current developing fads include messaging a server POST messages over http, receiving JSON data. Both the request and answer are smallish small. A interface update refresh may depend on this data arriving. So the less latency, the more agile and snappy will feel the application. This is less trafic than webpages. A typical webpage page update may need 400KB / 700KB +. HTML can be wasteful in big pages with a lot of data. The same data coming from in JSON can weight much less, maybe x10 less. I have not tried O365, so I don't know if it follow the typical modern web app. -- -- ℱin del ℳensaje. From listas at esds.com.br Tue Jan 13 11:25:01 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 13 Jan 2015 09:25:01 -0200 Subject: Recommended L2 switches for a new IXP In-Reply-To: <54B4D774.50600@megagroup.ru> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: QFX5100 is SDN ready. -- Eduardo Schoedler 2015-01-13 6:29 GMT-02:00 Stepan Kucherenko : > Is there any particular reason you prefer EX4600 over QFX5100 ? Not > counting obvious differences like ports and upgrade options. > > It's the same chipset after all, and with all upgrades they have the > same 10G density (with breakouts). Is that because you can have more 40G > ports with EX4600 ? > > I'm still trying to find out if there are any noticeable software or > feature differences. > > On 13.01.2015 09:01, Mark Tinka wrote: > > On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: > > > >> People seem to be avoiding recommending actual devices, > >> well I would recommend the Juniper EX4600 - > >> > >> http://www.juniper.net/us/en/products-services/switching/ > >> ex-series/ex4600/ > >> > >> They are affordable, highly scalable, stackable and run > >> JunOS. > > > > We've been quite happy with the EX4550, but the EX4600 is > > good too, particularly if you're coming from its younger > > brother. > > > > Mark. > > > -- Eduardo Schoedler From jared at puck.nether.net Tue Jan 13 11:32:24 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 13 Jan 2015 06:32:24 -0500 Subject: Google's Safe Browsing Alerts for Network Administrators In-Reply-To: <003301d02e96$f015b170$d0411450$@iname.com> References: <000101d02b9e$736488e0$5a2d9aa0$@iname.com> <003301d02e96$f015b170$d0411450$@iname.com> Message-ID: Hat: open.*project person.. With the complaints we get often the people aren't properly secured, they are just seeing the noise in their logs or they just started logging. We often get more complaints after the first six months as someone says "oh hey, we updated our IPS and now see the NTP traffic that we didn't see in 2000-2015, lets complain about it". It's good they have visibility now but most people don't get the true issue or impact, and don't even appreciate it when they are on the receiving end of a 100-250Gb/s attack from these services. Take a moment to read the Christian Rossow paper called "amplification Hell". While amplifiers are only a part of the equation, the trend of fixes is important to track so people understand the state of the fixes. Jared Mauch > On Jan 12, 2015, at 1:38 PM, Frank Bulk wrote: > > In regards to ShadowServer, I don’t think they’re randomly scanning networks, and neither are folks like OpenResolver – I think it’s pretty systematic, albeit from perhaps only a certain point of view on the Internet. If their scans are being dropped and logged, that’s great – that means someone has measures in place to mitigate attacks that leverage those UDP protocols. But for those who use their output to better secure their own and clients’ endpoint devices, it’s much appreciated. If it’s really just a drop in the ocean, what does it matter to you? From benno at NLnetLabs.nl Tue Jan 13 13:57:44 2015 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 13 Jan 2015 14:57:44 +0100 Subject: Call For Presentations RIPE 70, submission deadline 1 March 2015 Message-ID: <54B52458.9070803@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 70 below. The deadline for submissions is 1 March 2015. 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 for the RIPE Programme Committee http://www.ripe.net/ripe/meetings/ripe-meetings/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 70 will take place from 11-15 May 2015 in Amsterdam, The Netherlands. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 70. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange 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. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe70.ripe.net/submit-topic/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for "lightning talks", which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 1 March 2015, using the meeting submission system at https://ripe70.ripe.net/submit-topic/submission-form/. Proposals submitted after this date will be considered on a space-available basis. Important Dates regarding RIPE 70 can be found at: https://ripe70.ripe.net/programme/important-dates/ - Lightning talks should also be submitted using the meeting submission system (https://ripe70.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice – in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe70.ripe.net/submit-topic/presentation-formats/. - Proposals for talks 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, it is expected that most, if not all, presenters/panellists will 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 stephen.carter at gltgc.org Tue Jan 13 15:45:22 2015 From: stephen.carter at gltgc.org (Stephen R. Carter) Date: Tue, 13 Jan 2015 15:45:22 +0000 Subject: Recommended L2 switches for a new IXP In-Reply-To: <54B4D774.50600@megagroup.ru> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: We love our 5100s here. I have 4 48S, and 2 24q¹s. Super fast, TISSU when it works is awesome as well... like, really awesome. Stephen Carter | IT Systems Administrator | Gun Lake Tribal Gaming Commission 1123 129th Avenue, Wayland, MI 49348 Phone 269.792.1773 On 1/13/15, 3:29 AM, "Stepan Kucherenko" wrote: >Is there any particular reason you prefer EX4600 over QFX5100 ? Not >counting obvious differences like ports and upgrade options. > >It's the same chipset after all, and with all upgrades they have the >same 10G density (with breakouts). Is that because you can have more 40G >ports with EX4600 ? > >I'm still trying to find out if there are any noticeable software or >feature differences. > >On 13.01.2015 09:01, Mark Tinka wrote: >> On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: >> >>> People seem to be avoiding recommending actual devices, >>> well I would recommend the Juniper EX4600 - >>> >>> http://www.juniper.net/us/en/products-services/switching/ >>> ex-series/ex4600/ >>> >>> They are affordable, highly scalable, stackable and run >>> JunOS. >> >> We've been quite happy with the EX4550, but the EX4600 is >> good too, particularly if you're coming from its younger >> brother. >> >> Mark. >>
The information contained in this electronic transmission (email) is confidential information and may be subject to attorney/client privilege. It is intended only for the use of the individual or entity named above. ANY DISTRIBUTION OR COPYING OF THIS MESSAGE IS PROHIBITED, except by the intended recipient. Attempts to intercept this message are in violation of 18 U.S.C. 2511(1) of the Electronic Communications Privacy Act (ECPA), which subjects the interceptor to fines, imprisonment and/or civil damages. From bross at pobox.com Tue Jan 13 19:18:26 2015 From: bross at pobox.com (Brandon Ross) Date: Tue, 13 Jan 2015 14:18:26 -0500 (EST) Subject: DDOS solution recommendation In-Reply-To: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> References: <19396037.4539.1421098469167.JavaMail.mhammett@ThunderFuck> Message-ID: Earlier in the thread you seemed extremely confident in your position that long term blocking of addresses that appeared as source addresses of undesirable traffic is a good thing. Why are you now avoiding answering my question with a strawman? On Mon, 12 Jan 2015, Mike Hammett wrote: > So the preferred alternative is to simply do nothing at all? That seems fair. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Christopher Morrow" > To: "Brandon Ross" > Cc: "Mike Hammett" , "NANOG list" > Sent: Monday, January 12, 2015 3:05:14 PM > Subject: Re: DDOS solution recommendation > > On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross wrote: >> On Sun, 11 Jan 2015, Mike Hammett wrote: >> >>> I know that UDP can be spoofed, but it's not likely that the SSH, mail, >>> etc. login attempts, web page hits, etc. would be spoofed as they'd have to >>> know the response to be of any good. >> >> >> Okay, so I'm curious. Are you saying that you do not automatically block >> attackers until you can confirm a 3-way TCP handshake has been completed, >> and therefore you aren't blocking sources that were spoofed? If so, how are >> you protecting yourself against SYN attacks? If not, then you've made it >> quite easy for attackers to deny any source they want. > > this all seems like a fabulous conversation we're watching, but really > .. if someone wants to block large swaths of the intertubes on their > systems it's totally up to them, right? They can choose to not be > functional all they want, as near as I can tell... and arguing with > someone with this mentality isn't productive, especially after several > (10+? folk) have tried to show and tell some experience that would > lead to more cautious approaches. > > If mike wants less packets, that's all cool... I'm not sure it's > actually solving anything, but sure, go right ahead, have fun. > > -chris > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From simon.leinen at switch.ch Tue Jan 13 21:50:03 2015 From: simon.leinen at switch.ch (Simon Leinen) Date: Tue, 13 Jan 2015 22:50:03 +0100 Subject: Recommended L2 switches for a new IXP In-Reply-To: ("Manuel \=\?utf-8\?Q\?Mar\=C3\=ADn\=22's\?\= message of "Sun, 11 Jan 2015 23:35:15 -0700") References: Message-ID: Manuel Marín writes: > Dear Nanog community > [...] There are so many options that I don't know if it makes sense to > start with a modular switch (usually expensive because the backplane, > dual dc, dual CPU, etc) or start with a 1RU high density switch that > support new protocols like Trill and that supposedly allow you to > create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G > ports for exchange participants, 40G/100G for uplinks between switches > and flow support for statistics and traffic analysis. Stupid thought from someone who has never built an IXP, but has been looking at recent trends in data center networks: There are these "white-box" switches mostly designed for top-of-rack or spine (as in leaf-spine/fat-tree datacenter networks) applications. They have all the necessary port speeds - well 100G seems to be a few months off. I'm thinking of brands such as Edge-Core, Quanta etc. You can get them as "bare-metal" versions with no switch OS on them, just a bootloader according to the "ONIE" standard. Equipment cost seems to be on the order of $100 per SFP+ port w/o optics for a second-to-last generation (Trident-based) 48*10GE+4*40GE ToR switch. Now, for the limited and somewhat special L2 needs of an IXP, couldn't "someone" hack together a suitable switch OS based on Open Network Linux (ONL) or something like that? You wouldn't even need MAC address learning or most types of flooding, because at an IXP this often hurts rather than helps. For building larger fabrics you might be using something other (waves hands) than TRILL; maybe you could get away without slightly complex "multi-chassis multi-channel" mechanisms, and so on. "Flow support" sounds somewhat tough, but full netflow support that would get Roland Dobbins' "usable telemetry" seal of approval is probably out of reach anyway - it's a high-end feature with classical gear. With white-box switches, you could try to use the given 5-tuple flow hardware capabilities - which might not scale that well -, or use packet sampling, or try to use the built-in flow and counter mechanisms in an application-specific way. (Except *that's* a lot of work on the software side, and a usably efficient implementation requires slightly sophisticated hardware/software interfaces.) Instead of a Linux-based switch OS, one could also build an IXP "application" using OpenFlow and some kind of central controller. (Not to be confused with "SDX: Software Defined Internet Exchange".) Has anybody looked into the feasibility of this? The software could be done as an open-source community project to make setting up regional IXPs easier/cheaper. Large IXPs could sponsor this so they get better scalability - although I'm not sure how well something like the leaf-spine/fat-tree design maps to these IXPs, which are typically distributed over several locations. Maybe they could use something like Facebook's new design, treating each IXP location as a "pod". -- Simon. [1] https://code.facebook.com/posts/360346274145943 From jeff.tantsura at ericsson.com Tue Jan 13 22:10:56 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Tue, 13 Jan 2015 22:10:56 +0000 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: What does it mean - to be SDN ready? Cheers, Jeff -----Original Message----- From: Eduardo Schoedler Date: Tuesday, January 13, 2015 at 3:25 AM To: "nanog at nanog.org" Subject: Re: Recommended L2 switches for a new IXP >QFX5100 is SDN ready. > >-- >Eduardo Schoedler > > >2015-01-13 6:29 GMT-02:00 Stepan Kucherenko : > >> Is there any particular reason you prefer EX4600 over QFX5100 ? Not >> counting obvious differences like ports and upgrade options. >> >> It's the same chipset after all, and with all upgrades they have the >> same 10G density (with breakouts). Is that because you can have more 40G >> ports with EX4600 ? >> >> I'm still trying to find out if there are any noticeable software or >> feature differences. >> >> On 13.01.2015 09:01, Mark Tinka wrote: >> > On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: >> > >> >> People seem to be avoiding recommending actual devices, >> >> well I would recommend the Juniper EX4600 - >> >> >> >> http://www.juniper.net/us/en/products-services/switching/ >> >> ex-series/ex4600/ >> >> >> >> They are affordable, highly scalable, stackable and run >> >> JunOS. >> > >> > We've been quite happy with the EX4550, but the EX4600 is >> > good too, particularly if you're coming from its younger >> > brother. >> > >> > Mark. >> > >> > > > >-- >Eduardo Schoedler From nick at foobar.org Tue Jan 13 22:23:33 2015 From: nick at foobar.org (Nick Hilliard) Date: Tue, 13 Jan 2015 22:23:33 +0000 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: <54B59AE5.2000309@foobar.org> On 13/01/2015 22:10, Jeff Tantsura wrote: > What does it mean - to be SDN ready? it means "fully buzzword compliant". Nick From jeff.tantsura at ericsson.com Tue Jan 13 22:25:30 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Tue, 13 Jan 2015 22:25:30 +0000 Subject: Recommended L2 switches for a new IXP In-Reply-To: <54B59AE5.2000309@foobar.org> References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> <54B59AE5.2000309@foobar.org> Message-ID: AhhhŠ vertically integrated horizontal API¹s Cheers, Jeff -----Original Message----- From: Nick Hilliard Date: Tuesday, January 13, 2015 at 2:23 PM To: Jeff Tantsura , Eduardo Schoedler , "nanog at nanog.org" Subject: Re: Recommended L2 switches for a new IXP >On 13/01/2015 22:10, Jeff Tantsura wrote: >> What does it mean - to be SDN ready? > >it means "fully buzzword compliant". > >Nick > > From listas at esds.com.br Tue Jan 13 22:28:32 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 13 Jan 2015 20:28:32 -0200 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: My mistake, it's the OCX1100. http://www.networkworld.com/article/2855056/sdn/juniper-unbundles-switch-hardware-software.html 2015-01-13 20:10 GMT-02:00 Jeff Tantsura : > What does it mean - to be SDN ready? > > Cheers, > Jeff > > > > > -----Original Message----- > From: Eduardo Schoedler > Date: Tuesday, January 13, 2015 at 3:25 AM > To: "nanog at nanog.org" > Subject: Re: Recommended L2 switches for a new IXP > > >QFX5100 is SDN ready. > > > >-- > >Eduardo Schoedler > > > > > >2015-01-13 6:29 GMT-02:00 Stepan Kucherenko : > > > >> Is there any particular reason you prefer EX4600 over QFX5100 ? Not > >> counting obvious differences like ports and upgrade options. > >> > >> It's the same chipset after all, and with all upgrades they have the > >> same 10G density (with breakouts). Is that because you can have more 40G > >> ports with EX4600 ? > >> > >> I'm still trying to find out if there are any noticeable software or > >> feature differences. > >> > >> On 13.01.2015 09:01, Mark Tinka wrote: > >> > On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: > >> > > >> >> People seem to be avoiding recommending actual devices, > >> >> well I would recommend the Juniper EX4600 - > >> >> > >> >> http://www.juniper.net/us/en/products-services/switching/ > >> >> ex-series/ex4600/ > >> >> > >> >> They are affordable, highly scalable, stackable and run > >> >> JunOS. > >> > > >> > We've been quite happy with the EX4550, but the EX4600 is > >> > good too, particularly if you're coming from its younger > >> > brother. > >> > > >> > Mark. > >> > > >> > > > > > > > >-- > >Eduardo Schoedler > > -- Eduardo Schoedler From raphael.timothy at gmail.com Tue Jan 13 22:38:02 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Wed, 14 Jan 2015 06:38:02 +0800 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: <2B41A2D3-B4D0-46D6-9BBD-F9F0CB386672@gmail.com> Either way, you can do "SDN" and automation with most Juniper kit. On purchase of JCare you get free access to Junos Space - great for provisioning and management of an IXP. Regards, Tim Raphael > On 14 Jan 2015, at 6:28 am, Eduardo Schoedler wrote: > > My mistake, it's the OCX1100. > http://www.networkworld.com/article/2855056/sdn/juniper-unbundles-switch-hardware-software.html > > 2015-01-13 20:10 GMT-02:00 Jeff Tantsura : > >> What does it mean - to be SDN ready? >> >> Cheers, >> Jeff >> >> >> >> >> -----Original Message----- >> From: Eduardo Schoedler >> Date: Tuesday, January 13, 2015 at 3:25 AM >> To: "nanog at nanog.org" >> Subject: Re: Recommended L2 switches for a new IXP >> >>> QFX5100 is SDN ready. >>> >>> -- >>> Eduardo Schoedler >>> >>> >>> 2015-01-13 6:29 GMT-02:00 Stepan Kucherenko : >>> >>>> Is there any particular reason you prefer EX4600 over QFX5100 ? Not >>>> counting obvious differences like ports and upgrade options. >>>> >>>> It's the same chipset after all, and with all upgrades they have the >>>> same 10G density (with breakouts). Is that because you can have more 40G >>>> ports with EX4600 ? >>>> >>>> I'm still trying to find out if there are any noticeable software or >>>> feature differences. >>>> >>>>> On 13.01.2015 09:01, Mark Tinka wrote: >>>>>> On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: >>>>>> >>>>>> People seem to be avoiding recommending actual devices, >>>>>> well I would recommend the Juniper EX4600 - >>>>>> >>>>>> http://www.juniper.net/us/en/products-services/switching/ >>>>>> ex-series/ex4600/ >>>>>> >>>>>> They are affordable, highly scalable, stackable and run >>>>>> JunOS. >>>>> >>>>> We've been quite happy with the EX4550, but the EX4600 is >>>>> good too, particularly if you're coming from its younger >>>>> brother. >>>>> >>>>> Mark. >>> >>> >>> >>> -- >>> Eduardo Schoedler > > > -- > Eduardo Schoedler From jeff.tantsura at ericsson.com Tue Jan 13 22:47:09 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Tue, 13 Jan 2015 22:47:09 +0000 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: Got you - artificially disabling 90% of the features otherwise supported by the OS and using half baked HAL makes product SDN ready! Sorry for the sarcasm, couldn¹t resist :) Cheers, Jeff -----Original Message----- From: Eduardo Schoedler Date: Tuesday, January 13, 2015 at 2:28 PM To: "nanog at nanog.org" Subject: Re: Recommended L2 switches for a new IXP >My mistake, it's the OCX1100. >http://www.networkworld.com/article/2855056/sdn/juniper-unbundles-switch-h >ardware-software.html > >2015-01-13 20:10 GMT-02:00 Jeff Tantsura : > >> What does it mean - to be SDN ready? >> >> Cheers, >> Jeff >> >> >> >> >> -----Original Message----- >> From: Eduardo Schoedler >> Date: Tuesday, January 13, 2015 at 3:25 AM >> To: "nanog at nanog.org" >> Subject: Re: Recommended L2 switches for a new IXP >> >> >QFX5100 is SDN ready. >> > >> >-- >> >Eduardo Schoedler >> > >> > >> >2015-01-13 6:29 GMT-02:00 Stepan Kucherenko : >> > >> >> Is there any particular reason you prefer EX4600 over QFX5100 ? Not >> >> counting obvious differences like ports and upgrade options. >> >> >> >> It's the same chipset after all, and with all upgrades they have the >> >> same 10G density (with breakouts). Is that because you can have more >>40G >> >> ports with EX4600 ? >> >> >> >> I'm still trying to find out if there are any noticeable software or >> >> feature differences. >> >> >> >> On 13.01.2015 09:01, Mark Tinka wrote: >> >> > On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: >> >> > >> >> >> People seem to be avoiding recommending actual devices, >> >> >> well I would recommend the Juniper EX4600 - >> >> >> >> >> >> http://www.juniper.net/us/en/products-services/switching/ >> >> >> ex-series/ex4600/ >> >> >> >> >> >> They are affordable, highly scalable, stackable and run >> >> >> JunOS. >> >> > >> >> > We've been quite happy with the EX4550, but the EX4600 is >> >> > good too, particularly if you're coming from its younger >> >> > brother. >> >> > >> >> > Mark. >> >> > >> >> >> > >> > >> > >> >-- >> >Eduardo Schoedler >> >> > > >-- >Eduardo Schoedler From blair.trosper at gmail.com Tue Jan 13 22:52:49 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 13 Jan 2015 16:52:49 -0600 Subject: Level 3 issues in Miami/West Palm Beach Message-ID: All packets traveling through customer edges and routers in Miami/Daytona seem to be incurring *extraordinary* latency (4+ seconds) all of a sudden. Can someone contact me off list so I can throw you some traceroutes? From Valdis.Kletnieks at vt.edu Tue Jan 13 23:18:23 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 13 Jan 2015 18:18:23 -0500 Subject: Level 3 issues in Miami/West Palm Beach In-Reply-To: Your message of "Tue, 13 Jan 2015 16:52:49 -0600." References: Message-ID: <26601.1421191103@turing-police.cc.vt.edu> On Tue, 13 Jan 2015 16:52:49 -0600, Blair Trosper said: > All packets traveling through customer edges and routers in Miami/Daytona > seem to be incurring *extraordinary* latency (4+ seconds) all of a sudden. I'm impressed that the routers have sufficient buffer memory to do that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From david at davidcoulson.net Wed Jan 14 01:04:11 2015 From: david at davidcoulson.net (David Coulson) Date: Tue, 13 Jan 2015 20:04:11 -0500 Subject: Akron OH CO outage Message-ID: <54B5C08B.6080809@davidcoulson.net> Anyone else in North East Ohio seeing an outage of AT&T's CO in Akron? Local news is reporting 911 is out across multiple counties, so can't be good. If anyone has any information, feel free to reach out off-list. David From mksmith at mac.com Wed Jan 14 01:45:55 2015 From: mksmith at mac.com (Michael Smith) Date: Wed, 14 Jan 2015 01:45:55 +0000 (GMT) Subject: Recommended L2 switches for a new IXP Message-ID: <94405db5-045c-4dea-babc-c3fc79436fb9@me.com> You can see what we have at the SIX here - http://www.seattleix.net/topology.html Mike -- Michael K. Smith mksmith at mac.com On Jan 11, 2015, at 10:37 PM, Manuel Marín wrote: Dear Nanog community We are trying to build a new IXP in some US Metro areas where we have multiple POPs and I was wondering what do you recommend for L2 switches. I know that some IXPs use Nexus, Brocade, Force10 but I don't personally have experience with these switches. It would be great if you can share your experience and recommendations. There are so many options that I don't know if it makes sense to start with a modular switch (usually expensive because the backplane, dual dc, dual CPU, etc) or start with a 1RU high density switch that support new protocols like Trill and that supposedly allow you to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G ports for exchange participants, 40G/100G for uplinks between switches and flow support for statistics and traffic analysis. Thank you and have a great day. Regards From list at satchell.net Wed Jan 14 01:54:49 2015 From: list at satchell.net (Stephen Satchell) Date: Tue, 13 Jan 2015 17:54:49 -0800 Subject: Level 3 issues in Miami/West Palm Beach In-Reply-To: <26601.1421191103@turing-police.cc.vt.edu> References: <26601.1421191103@turing-police.cc.vt.edu> Message-ID: <54B5CC69.9040108@satchell.net> On 01/13/2015 03:18 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 13 Jan 2015 16:52:49 -0600, Blair Trosper said: >> All packets traveling through customer edges and routers in Miami/Daytona >> seem to be incurring *extraordinary* latency (4+ seconds) all of a sudden. > > I'm impressed that the routers have sufficient buffer memory to do that. > That is what buffer bloat is all about -- too much queue and too little circuit. From blair.trosper at gmail.com Wed Jan 14 02:27:50 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 13 Jan 2015 20:27:50 -0600 Subject: Level 3 issues in Miami/West Palm Beach In-Reply-To: <54B5CC69.9040108@satchell.net> References: <26601.1421191103@turing-police.cc.vt.edu> <54B5CC69.9040108@satchell.net> Message-ID: In this case, it appeared to be a customer's edge router, not a core/backbone router...although those did seem to have rather high latency (400ms and higher in some cases) and high packet loss (about 18-20%). On Tue, Jan 13, 2015 at 7:54 PM, Stephen Satchell wrote: > On 01/13/2015 03:18 PM, Valdis.Kletnieks at vt.edu wrote: > > On Tue, 13 Jan 2015 16:52:49 -0600, Blair Trosper said: > >> All packets traveling through customer edges and routers in > Miami/Daytona > >> seem to be incurring *extraordinary* latency (4+ seconds) all of a > sudden. > > > > I'm impressed that the routers have sufficient buffer memory to do that. > > > > That is what buffer bloat is all about -- too much queue and too little > circuit. > From mark.tinka at seacom.mu Wed Jan 14 04:06:23 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 14 Jan 2015 06:06:23 +0200 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <54B59AE5.2000309@foobar.org> Message-ID: <201501140606.23502.mark.tinka@seacom.mu> On Wednesday, January 14, 2015 12:25:30 AM Jeff Tantsura wrote: > AhhhŠ vertically integrated horizontal API¹s Green, vertically integrated horizontal API's :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Wed Jan 14 04:10:29 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 14 Jan 2015 06:10:29 +0200 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> Message-ID: <201501140610.29666.mark.tinka@seacom.mu> On Wednesday, January 14, 2015 12:47:09 AM Jeff Tantsura wrote: > Got you - artificially disabling 90% of the features > otherwise supported by the OS and using half baked HAL > makes product SDN ready! Sorry for the sarcasm, couldn¹t > resist :) I once tested a Junos release with the X blah blah D blah blah letters in there on an EX4550. Couldn't even get LACP going, until I realized it was some kind of QFX'y release for the non-QFX EX boxes. Promptly got ride of that. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From frnkblk at iname.com Wed Jan 14 04:48:54 2015 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 13 Jan 2015 22:48:54 -0600 Subject: Akron OH CO outage In-Reply-To: <54B5C08B.6080809@davidcoulson.net> References: <54B5C08B.6080809@davidcoulson.net> Message-ID: <002401d02fb5$66b04b00$3410e100$@iname.com> Twitter has lots of news on this topic: http://fox8.com/2015/01/13/police-911-systems-down-throughout-summit-co-due-to-power-outage-at-att-office-in-akron/ http://www.newsnet5.com/news/local-news/oh-summit/summit-county-911-lines-down http://www.wkyc.com/story/news/local/northeast-ohio/2015/01/13/911-outages/21719669/ Frank -----Original Message----- From: NANOG [mailto:nanog-bounces+frnkblk=iname.com at nanog.org] On Behalf Of David Coulson Sent: Tuesday, January 13, 2015 7:04 PM To: nanog at nanog.org Subject: Akron OH CO outage Anyone else in North East Ohio seeing an outage of AT&T's CO in Akron? Local news is reporting 911 is out across multiple counties, so can't be good. If anyone has any information, feel free to reach out off-list. David From johnstong at westmancom.com Wed Jan 14 19:10:03 2015 From: johnstong at westmancom.com (Graham Johnston) Date: Wed, 14 Jan 2015 19:10:03 +0000 Subject: Brocade MLX Feedback Message-ID: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> We are looking at Brocade MLX routers to act as Internet edge routers. They will initially handle two to four full tables, plus peering on an IX. The price is certainly attractive. We are coming from Cisco 7600 series devices. Can anyone comment about their use of them? Are you happy with them? Any gotchas? Particularly we are interested in convergence time to full FIB population. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From jordan-medlen at bisk.com Wed Jan 14 19:25:51 2015 From: jordan-medlen at bisk.com (Jordan Medlen) Date: Wed, 14 Jan 2015 19:25:51 +0000 Subject: Brocade MLX Feedback In-Reply-To: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> Message-ID: <4861E1CF94656C46BBE7DD50DA619F8C2C2B9D@TPA-MBX-001.qwest.corp.bisk.com> These are great routers. I used the MLX16s in the same capacity, before the newer model MLXe with upgraded management card specs. Should work just fine for that. Thank you, Jordan Medlen Network Engineer Bisk Education, Inc. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Graham Johnston Sent: Wednesday, January 14, 2015 2:10 PM To: 'nanog at nanog.org' Subject: Brocade MLX Feedback We are looking at Brocade MLX routers to act as Internet edge routers. They will initially handle two to four full tables, plus peering on an IX. The price is certainly attractive. We are coming from Cisco 7600 series devices. Can anyone comment about their use of them? Are you happy with them? Any gotchas? Particularly we are interested in convergence time to full FIB population. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From wp at null0.nl Wed Jan 14 19:35:38 2015 From: wp at null0.nl (Wouter Prins) Date: Wed, 14 Jan 2015 20:35:38 +0100 Subject: Brocade MLX Feedback In-Reply-To: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> Message-ID: Hi Graham, Do you have any special features you need? MLX-e's are great and fulfill most standard environments fine. Full table convergence time is pretty fast on MLX-e's. Be sure to pick the right modules, switch fabrics and management blades (or contact a partner to do it for you) when you go for a mlx-e. You may want to consider the CER-RT (fixed 1U box) if you dont need a modular chassis. On 14 January 2015 at 20:10, Graham Johnston wrote: > We are looking at Brocade MLX routers to act as Internet edge routers. > They will initially handle two to four full tables, plus peering on an IX. > The price is certainly attractive. We are coming from Cisco 7600 series > devices. Can anyone comment about their use of them? Are you happy with > them? Any gotchas? Particularly we are interested in convergence time to > full FIB population. > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > > -- Wouter Prins wp at null0.nl From karsten.elfenbein at gmail.com Wed Jan 14 20:07:18 2015 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Wed, 14 Jan 2015 21:07:18 +0100 Subject: Brocade MLX Feedback In-Reply-To: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> Message-ID: Hi, the devices are good. Just read up about gen 1, gen1.1 and gen 2 modules in regard to backplane mode. Afaik Gen1 Modules are discontinued now so all modules should work in turbo mode. I don't know which cam profile is the current default so that needs repartitioning and default values adjusted if you run full table IPv4. SNMP for IPv6 BGP neighbors is still missing in software version 5.6 so monitoring these sessions is not possible. Best regards Karsten 2015-01-14 20:10 GMT+01:00 Graham Johnston : > We are looking at Brocade MLX routers to act as Internet edge routers. They will initially handle two to four full tables, plus peering on an IX. The price is certainly attractive. We are coming from Cisco 7600 series devices. Can anyone comment about their use of them? Are you happy with them? Any gotchas? Particularly we are interested in convergence time to full FIB population. > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > From math at sizone.org Wed Jan 14 20:08:48 2015 From: math at sizone.org (Ken Chase) Date: Wed, 14 Jan 2015 15:08:48 -0500 Subject: discussing how to stop hacking is hacking which is now racketeering Message-ID: <20150114200848.GU9708@sizone.org> http://blog.erratasec.com/2015/01/obams-war-on-hackers.html Therefore, immediate end of this thread? Are all subscribers to this list now to be inconvenienced at airports? (Sorry, my bad.) Do we all need a CCNP Security-multipass to log into IRC now? Which channels are now a good idea to avoid? #linux? #bitcoin? #nanog? #obamasucks? #blacklivesmatter? (in Canada #idlenomore is similar and equally targetted by Palantir/Tempests as the latter was). What constitutes racketeering in 'communication'? Membership on a mailing list or just reading a webpage? [ This week I was investigating a colleague's website, so I ran dig(1) in a bash terminal in putty - she saw a text terminal, and exclaimed "Wait, stop, are you hacking my website?!" I blame Sandra Bullock and to a lesser extent Carrie Ann Moss (and the nmap crew, esp. for using actually-plausible toolsets/techniques). ] This is an age old game, but the ante has just been upped. Our industry should respond to this. /kc -- Ken Chase - math at sizone.org Toronto Canada From jlsorrels at kanren.net Wed Jan 14 20:17:42 2015 From: jlsorrels at kanren.net (Jeff Sorrels) Date: Wed, 14 Jan 2015 14:17:42 -0600 Subject: Brocade MLX Feedback In-Reply-To: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> Message-ID: <54B6CEE6.5040505@kanren.net> Graham, We have several Brocades - including XMR, CER, and CES devices. Their convergence is excellent, even with several full v4 and v6 tables, and was much faster than other platforms (I'm looking at you MXs...). In terms of TCAM and convergence, best bang for the buck as they say. One 'gotcha' we discovered: Brocade does not have, as per our last discussion with them, BGP FlowSpec on the road map. That was a problem for us, but YMMV. Cheers, Jeff On 1/14/2015 1:10 PM, Graham Johnston wrote: > We are looking at Brocade MLX routers to act as Internet edge routers. They will initially handle two to four full tables, plus peering on an IX. The price is certainly attractive. We are coming from Cisco 7600 series devices. Can anyone comment about their use of them? Are you happy with them? Any gotchas? Particularly we are interested in convergence time to full FIB population. > > Thanks, > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. > -- Jeff Sorrels Network Administrator KanREN, Inc jlsorrels at kanren.net 785-856-9820, #2 From jimpop at gmail.com Wed Jan 14 20:19:42 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 14 Jan 2015 15:19:42 -0500 Subject: discussing how to stop hacking is hacking which is now racketeering In-Reply-To: <20150114200848.GU9708@sizone.org> References: <20150114200848.GU9708@sizone.org> Message-ID: On Wed, Jan 14, 2015 at 3:08 PM, Ken Chase wrote: > http://blog.erratasec.com/2015/01/obams-war-on-hackers.html > > Therefore, immediate end of this thread? Are all subscribers to this list now > to be inconvenienced at airports? (Sorry, my bad.) > > Do we all need a CCNP Security-multipass to log into IRC now? Which channels > are now a good idea to avoid? #linux? #bitcoin? #nanog? #obamasucks? > #blacklivesmatter? (in Canada #idlenomore is similar and equally targetted by > Palantir/Tempests as the latter was). > > What constitutes racketeering in 'communication'? Membership on a mailing list > or just reading a webpage? > > [ This week I was investigating a colleague's website, so I ran dig(1) in a > bash terminal in putty - she saw a text terminal, and exclaimed "Wait, stop, are > you hacking my website?!" I blame Sandra Bullock and to a lesser extent Carrie > Ann Moss (and the nmap crew, esp. for using actually-plausible toolsets/techniques). ] > > This is an age old game, but the ante has just been upped. Our industry should > respond to this. One has to wonder how any of this applies to the 'countries that hack' accusations that the FBI/CIA/NSA have always laid claim to. -Jim P. From Trelane at trelane.net Wed Jan 14 21:09:41 2015 From: Trelane at trelane.net (Andrew D Kirch) Date: Wed, 14 Jan 2015 13:09:41 -0800 Subject: discussing how to stop hacking is hacking which is now racketeering In-Reply-To: References: <20150114200848.GU9708@sizone.org> Message-ID: <1419AF03-34C5-4753-BAFE-CEC8C58DCA25@trelane.net> > On Jan 14, 2015, at 12:19 PM, Jim Popovitch wrote: > > >> On Wed, Jan 14, 2015 at 3:08 PM, Ken Chase wrote: >> http://blog.erratasec.com/2015/01/obams-war-on-hackers.html >> >> Therefore, immediate end of this thread? Are all subscribers to this list now >> to be inconvenienced at airports? (Sorry, my bad.) >> >> Do we all need a CCNP Security-multipass to log into IRC now? Which channels >> are now a good idea to avoid? #linux? #bitcoin? #nanog? #obamasucks? >> #blacklivesmatter? (in Canada #idlenomore is similar and equally targetted by >> Palantir/Tempests as the latter was). >> >> What constitutes racketeering in 'communication'? Membership on a mailing list >> or just reading a webpage? >> >> [ This week I was investigating a colleague's website, so I ran dig(1) in a >> bash terminal in putty - she saw a text terminal, and exclaimed "Wait, stop, are >> you hacking my website?!" I blame Sandra Bullock and to a lesser extent Carrie >> Ann Moss (and the nmap crew, esp. for using actually-plausible toolsets/techniques). ] >> >> This is an age old game, but the ante has just been upped. Our industry should >> respond to this. > > One has to wonder how any of this applies to the 'countries that hack' > accusations that the FBI/CIA/NSA have always laid claim to. > > -Jim P. Jim- You mean the credits page for Stuxnet? From betty at newnog.org Wed Jan 14 21:14:55 2015 From: betty at newnog.org (Betty Burke ) Date: Wed, 14 Jan 2015 16:14:55 -0500 Subject: [NANOG-announce] NANOG 63 Update Message-ID: NANOGers, We are beginning our final preparations in support of NANOG 63, February 2-4, 2015 in San Antonio, TX. A few highlights and reminders follow: The NANOG 63 Agenda is posted, with updates being provided as warranted. he Conference Registration Fee will increase soon, so be sure to register now. Also, take a moment to join NANOG or renew your existing Membership. - Standard Registration starting January 16, 2015 - (non-member $525, member $500, student $100) - Late Registration starting January 23, 2015 - (non-member $600, member $575, student $100) - On-Site Registration starting January 30, 2015 - (non-member $675, member $650, student $100) The conference hotel (Marriott Rivercenter) room block rate is set to expire on Friday, 5 pm CST, January 16, 2015, be sure to get your reservation made ASAP. We welcome those attendees and conference sponsors already planning to join us for NANOG 63. We encourage those not yet registered to do so, and join us for what will be another great February NANOG meeting! Should you have any questions, contact us at nanog-support at nanog.org Sincerely, Betty Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jimpop at gmail.com Wed Jan 14 21:17:02 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 14 Jan 2015 16:17:02 -0500 Subject: discussing how to stop hacking is hacking which is now racketeering In-Reply-To: <1419AF03-34C5-4753-BAFE-CEC8C58DCA25@trelane.net> References: <20150114200848.GU9708@sizone.org> <1419AF03-34C5-4753-BAFE-CEC8C58DCA25@trelane.net> Message-ID: On Wed, Jan 14, 2015 at 4:09 PM, Andrew D Kirch wrote: > > >> On Jan 14, 2015, at 12:19 PM, Jim Popovitch wrote: >> >> >>> On Wed, Jan 14, 2015 at 3:08 PM, Ken Chase wrote: >>> http://blog.erratasec.com/2015/01/obams-war-on-hackers.html >>> >>> Therefore, immediate end of this thread? Are all subscribers to this list now >>> to be inconvenienced at airports? (Sorry, my bad.) >>> >>> Do we all need a CCNP Security-multipass to log into IRC now? Which channels >>> are now a good idea to avoid? #linux? #bitcoin? #nanog? #obamasucks? >>> #blacklivesmatter? (in Canada #idlenomore is similar and equally targetted by >>> Palantir/Tempests as the latter was). >>> >>> What constitutes racketeering in 'communication'? Membership on a mailing list >>> or just reading a webpage? >>> >>> [ This week I was investigating a colleague's website, so I ran dig(1) in a >>> bash terminal in putty - she saw a text terminal, and exclaimed "Wait, stop, are >>> you hacking my website?!" I blame Sandra Bullock and to a lesser extent Carrie >>> Ann Moss (and the nmap crew, esp. for using actually-plausible toolsets/techniques). ] >>> >>> This is an age old game, but the ante has just been upped. Our industry should >>> respond to this. >> >> One has to wonder how any of this applies to the 'countries that hack' >> accusations that the FBI/CIA/NSA have always laid claim to. >> >> -Jim P. > > Jim- > You mean the credits page for Stuxnet? :-) I do mean any and nearly everything the USG has told us about how evil hackers reside in RU, CN, and DPRK and prey on Mil computers. -Jim P. From Stetson.Blake at datayardworks.com Wed Jan 14 14:29:24 2015 From: Stetson.Blake at datayardworks.com (Stetson Blake) Date: Wed, 14 Jan 2015 14:29:24 +0000 Subject: VDSL CPE Mixed Results Message-ID: <1421245763.3821.2.camel@stets.datayard.local> Hey All, We have been deploying Adtran 838(shdsl) and 868(dsl) units in our metro area with mixed results. The devices themselves are reliable and secure it would seem, but the speeds were are able to get are not. ie. we have deployed 'vdsl' and needed 3 lines to get up to 10x10 speeds. We are using an Adtran TA5000 on the other end to terminate our connections. The distance between the site and CO is not great (under 6k feet). What gives? Are we provisioning wrong, using the wrong equipment, or a combination of both? If we were able to get the speeds others have been reporting from VDSL, life would be great. Anyone feel free to contact me off-list or on, this has had me scratching my head for a while now. Thanks, -- Stetson Blake Network Technician DataYard 130 West Second St. Suite 250 Dayton, OH 45402 http://datayardworks.com From frnkblk at iname.com Wed Jan 14 22:08:04 2015 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 14 Jan 2015 16:08:04 -0600 Subject: VDSL CPE Mixed Results In-Reply-To: <1421245763.3821.2.camel@stets.datayard.local> References: <1421245763.3821.2.camel@stets.datayard.local> Message-ID: <008101d03046$91fbb2e0$b5f318a0$@iname.com> We've used a few Zhone ETHX-344x4 (http://www.zhone.com/products/ETHX-3400/) and been happy with the reliability. Configuration was a bugger, but if you get one of those I can share my template. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stetson Blake Sent: Wednesday, January 14, 2015 8:29 AM To: nanog at nanog.org Subject: VDSL CPE Mixed Results Hey All, We have been deploying Adtran 838(shdsl) and 868(dsl) units in our metro area with mixed results. The devices themselves are reliable and secure it would seem, but the speeds were are able to get are not. ie. we have deployed 'vdsl' and needed 3 lines to get up to 10x10 speeds. We are using an Adtran TA5000 on the other end to terminate our connections. The distance between the site and CO is not great (under 6k feet). What gives? Are we provisioning wrong, using the wrong equipment, or a combination of both? If we were able to get the speeds others have been reporting from VDSL, life would be great. Anyone feel free to contact me off-list or on, this has had me scratching my head for a while now. Thanks, -- Stetson Blake Network Technician DataYard 130 West Second St. Suite 250 Dayton, OH 45402 http://datayardworks.com From RCzumbil at xand.com Wed Jan 14 23:11:22 2015 From: RCzumbil at xand.com (Romeo Czumbil) Date: Wed, 14 Jan 2015 23:11:22 +0000 Subject: Brocade MLX Feedback In-Reply-To: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> Message-ID: <4B5E2AE2A43CEF4BB004BB9FB485D834087E5A@Xand-tek-Mbx01.corp.xand.com> I got a few CERs and 7600's You will not notice the CPU lag anymore like in the 7600's Extremely fast and puts the 7600's to shame -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Graham Johnston Sent: Wednesday, January 14, 2015 2:10 PM To: 'nanog at nanog.org' Subject: Brocade MLX Feedback We are looking at Brocade MLX routers to act as Internet edge routers. They will initially handle two to four full tables, plus peering on an IX. The price is certainly attractive. We are coming from Cisco 7600 series devices. Can anyone comment about their use of them? Are you happy with them? Any gotchas? Particularly we are interested in convergence time to full FIB population. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From youssef at 720.fr Thu Jan 15 08:40:28 2015 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Thu, 15 Jan 2015 09:40:28 +0100 Subject: Brocade MLX Feedback In-Reply-To: <54B6CEE6.5040505@kanren.net> References: <49EE1A35457387418410F97564A3752B013663B7F7@MSG6.westman.int> <54B6CEE6.5040505@kanren.net> Message-ID: Hi, I've been running NetIron (MLXe + CER-RT) for quite some time, mostly happy with the products. Of course, there are always some unforseen / silly / nasty things that still turn one's mind upside down. What we noticed so far : - ISSU / hitless protocols upgrades : we have been pounding them to get it right, an RFE has been submitted for quite some time now but it's not there yet, - Support of route reflection for VPLS auto discovery : same as above, - Adding packet capture (PCAP) capabilities : newly submitted RFE, - Adding BGP flowspec support : same as above, Also, BFD is always a little sensitive when the routers' CPU spike even if it's supported in hardware. All in all, and from a price/performance perspective, I would still recommend them if they match your business case (especially CER-RT for small colo / IP transit / IXP PEs and/or BGP route reflection). HTH. 2015-01-14 21:17 GMT+01:00 Jeff Sorrels : > Graham, > > We have several Brocades - including XMR, CER, and CES devices. Their > convergence is excellent, even with several full v4 and v6 tables, and was > much faster than other platforms (I'm looking at you MXs...). In terms of > TCAM and convergence, best bang for the buck as they say. > > One 'gotcha' we discovered: Brocade does not have, as per our last > discussion with them, BGP FlowSpec on the road map. That was a problem for > us, but YMMV. > > Cheers, > Jeff > > > > > On 1/14/2015 1:10 PM, Graham Johnston wrote: > >> We are looking at Brocade MLX routers to act as Internet edge routers. >> They will initially handle two to four full tables, plus peering on an IX. >> The price is certainly attractive. We are coming from Cisco 7600 series >> devices. Can anyone comment about their use of them? Are you happy with >> them? Any gotchas? Particularly we are interested in convergence time to >> full FIB population. >> >> Thanks, >> Graham Johnston >> Network Planner >> Westman Communications Group >> 204.717.2829 >> johnstong at westmancom.com >> P think green; don't print this email. >> >> > -- > Jeff Sorrels > Network Administrator > KanREN, Inc > jlsorrels at kanren.net > 785-856-9820, #2 > > -- Youssef BENGELLOUN-ZAHR From richih.mailinglist at gmail.com Thu Jan 15 09:17:59 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 15 Jan 2015 10:17:59 +0100 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: On Tue, Jan 13, 2015 at 4:45 PM, Stephen R. Carter wrote: > We love our 5100s here. Out of interest: Are you running 13.2 or 14.1? What features are you using? Our own experiences with a bunch of 48 & 96 port machines running 14.1 is painful to say the least. Richard From khelms at zcorum.com Thu Jan 15 13:15:20 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 15 Jan 2015 08:15:20 -0500 Subject: VDSL CPE Mixed Results In-Reply-To: <1421245763.3821.2.camel@stets.datayard.local> References: <1421245763.3821.2.camel@stets.datayard.local> Message-ID: I'm going to guess you're a CLEC from your website and a common problem I've seen in that scenario is that vectoring doesn't work between DSLAMs because it needs all pairs to be part of the vector group so that the DSLAM can mitigate FEXT. DSLAM vendors have been working on system level, rather than DSLAM/binder level, vectoring for a while but cross vendor support is questionable at best. Read the section on system level vectoring especially: http://www.adtran.com/web/fileDownload/doc/32362 If you are sharing binders with the ILEC and potentially other CLECs then you really need to talk to you ILEC rep and find out what they're doing for system level vectoring to see if there is an option for your DSLAMs to be included. That benefits everyone and will _greatly_ increase performance. VDSL2 speeds will otherwise be unreachable unless the ILEC gives each CLEC their own binder, not very practical. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Wed, Jan 14, 2015 at 9:29 AM, Stetson Blake < Stetson.Blake at datayardworks.com> wrote: > Hey All, > > We have been deploying Adtran 838(shdsl) and 868(dsl) units in our metro > area with mixed results. The devices themselves are reliable and secure > it would seem, but the speeds were are able to get are not. ie. we have > deployed 'vdsl' and needed 3 lines to get up to 10x10 speeds. We are > using an Adtran TA5000 on the other end to terminate our connections. > The distance between the site and CO is not great (under 6k feet). What > gives? Are we provisioning wrong, using the wrong equipment, or a > combination of both? > If we were able to get the speeds others have been reporting from VDSL, > life would be great. > Anyone feel free to contact me off-list or on, this has had me > scratching my head for a while now. > > Thanks, > > -- > Stetson Blake > Network Technician > DataYard > 130 West Second St. > Suite 250 > Dayton, OH 45402 > > http://datayardworks.com > > > > > > From shawnl at up.net Thu Jan 15 13:36:50 2015 From: shawnl at up.net (Shawn L) Date: Thu, 15 Jan 2015 08:36:50 -0500 Subject: VDSL CPE Mixed Results In-Reply-To: References: <1421245763.3821.2.camel@stets.datayard.local> Message-ID: I was going to ask if you've tested the cable pair at all. If the pair is bad, or even a little out of balance, bad scotch loks, etc. VDSL isn't going to work properly. We have customers that are definitely in-range for VDSL but who cannot get it because there is a 26 gauge insert between two cross-connect cabinets in the field On Thu, Jan 15, 2015 at 8:15 AM, Scott Helms wrote: > I'm going to guess you're a CLEC from your website and a common problem > I've seen in that scenario is that vectoring doesn't work between DSLAMs > because it needs all pairs to be part of the vector group so that the DSLAM > can mitigate FEXT. DSLAM vendors have been working on system level, rather > than DSLAM/binder level, vectoring for a while but cross vendor support is > questionable at best. > > Read the section on system level vectoring especially: > http://www.adtran.com/web/fileDownload/doc/32362 > > If you are sharing binders with the ILEC and potentially other CLECs then > you really need to talk to you ILEC rep and find out what they're doing for > system level vectoring to see if there is an option for your DSLAMs to be > included. That benefits everyone and will _greatly_ increase performance. > VDSL2 speeds will otherwise be unreachable unless the ILEC gives each CLEC > their own binder, not very practical. > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Wed, Jan 14, 2015 at 9:29 AM, Stetson Blake < > Stetson.Blake at datayardworks.com> wrote: > > > Hey All, > > > > We have been deploying Adtran 838(shdsl) and 868(dsl) units in our metro > > area with mixed results. The devices themselves are reliable and secure > > it would seem, but the speeds were are able to get are not. ie. we have > > deployed 'vdsl' and needed 3 lines to get up to 10x10 speeds. We are > > using an Adtran TA5000 on the other end to terminate our connections. > > The distance between the site and CO is not great (under 6k feet). What > > gives? Are we provisioning wrong, using the wrong equipment, or a > > combination of both? > > If we were able to get the speeds others have been reporting from VDSL, > > life would be great. > > Anyone feel free to contact me off-list or on, this has had me > > scratching my head for a while now. > > > > Thanks, > > > > -- > > Stetson Blake > > Network Technician > > DataYard > > 130 West Second St. > > Suite 250 > > Dayton, OH 45402 > > > > http://datayardworks.com > > > > > > > > > > > > > From cra at WPI.EDU Thu Jan 15 14:14:23 2015 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 15 Jan 2015 09:14:23 -0500 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: <20150115141422.GY18618@angus.ind.WPI.EDU> Software Defined Networking (SDN) features that QFX5100 supports: Automatic configuration of OVSDB-managed VXLANs with trunk interfaces 14.1X53-D15 OVSDB support 14.1X53-D10 OpenFlow v1.0 14.1X53-D10 OpenFlow v1.3.1 14.1X53-D10 VXLAN Gateway 14.1X53-D10 http://pathfinder.juniper.net/feature-explorer/select-software.html?swName=Junos+OS&typ=1#family=&platform=QFX5100&rel=14.1X53-D15&swName=Junos+OS On Tue, Jan 13, 2015 at 10:10:56PM +0000, Jeff Tantsura wrote: > What does it mean - to be SDN ready? > > Cheers, > Jeff > > > > > -----Original Message----- > From: Eduardo Schoedler > Date: Tuesday, January 13, 2015 at 3:25 AM > To: "nanog at nanog.org" > Subject: Re: Recommended L2 switches for a new IXP > > >QFX5100 is SDN ready. > > > >-- > >Eduardo Schoedler > > > > > >2015-01-13 6:29 GMT-02:00 Stepan Kucherenko : > > > >> Is there any particular reason you prefer EX4600 over QFX5100 ? Not > >> counting obvious differences like ports and upgrade options. > >> > >> It's the same chipset after all, and with all upgrades they have the > >> same 10G density (with breakouts). Is that because you can have more 40G > >> ports with EX4600 ? > >> > >> I'm still trying to find out if there are any noticeable software or > >> feature differences. > >> > >> On 13.01.2015 09:01, Mark Tinka wrote: > >> > On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote: > >> > > >> >> People seem to be avoiding recommending actual devices, > >> >> well I would recommend the Juniper EX4600 - > >> >> > >> >> http://www.juniper.net/us/en/products-services/switching/ > >> >> ex-series/ex4600/ > >> >> > >> >> They are affordable, highly scalable, stackable and run > >> >> JunOS. > >> > > >> > We've been quite happy with the EX4550, but the EX4600 is > >> > good too, particularly if you're coming from its younger > >> > brother. > >> > > >> > Mark. > >> > > >> > > > > > > > >-- > >Eduardo Schoedler From stephen.carter at gltgc.org Thu Jan 15 14:47:51 2015 From: stephen.carter at gltgc.org (Stephen R. Carter) Date: Thu, 15 Jan 2015 14:47:51 +0000 Subject: Recommended L2 switches for a new IXP In-Reply-To: References: <9753610.3783.1421068068110.JavaMail.mhammett@ThunderFuck> <201501122211.13678.mark.tinka@seacom.mu> <010901d02eb0$82157330$86405990$@wicks.co.nz> <201501130801.12056.mark.tinka@seacom.mu> <54B4D774.50600@megagroup.ru> Message-ID: We always adhere to JTAC: http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476&actp=SUBSCRI PTION unless otherwise required by their support to change. Currently it is Junos 13.2X51-D26. My advice to you is to not use 14.1 unless you have a reason, as that is more of a dev branch in terms of stability than anything. We use VRRP, OSPF, MC-LAG, and so forth. Nothing super fancy. Stephen Carter | IT Systems Administrator | Gun Lake Tribal Gaming Commission 1123 129th Avenue, Wayland, MI 49348 Phone 269.792.1773 On 1/15/15, 4:17 AM, "Richard Hartmann" wrote: >On Tue, Jan 13, 2015 at 4:45 PM, Stephen R. Carter > wrote: >> We love our 5100s here. > >Out of interest: Are you running 13.2 or 14.1? > >What features are you using? > > >Our own experiences with a bunch of 48 & 96 port machines running 14.1 >is painful to say the least. > > >Richard
The information contained in this electronic transmission (email) is confidential information and may be subject to attorney/client privilege. It is intended only for the use of the individual or entity named above. ANY DISTRIBUTION OR COPYING OF THIS MESSAGE IS PROHIBITED, except by the intended recipient. Attempts to intercept this message are in violation of 18 U.S.C. 2511(1) of the Electronic Communications Privacy Act (ECPA), which subjects the interceptor to fines, imprisonment and/or civil damages. From carey at ar-ballbat.org Thu Jan 15 15:04:34 2015 From: carey at ar-ballbat.org (Andrew Carey) Date: Thu, 15 Jan 2015 07:04:34 -0800 Subject: VDSL CPE Mixed Results In-Reply-To: References: <1421245763.3821.2.camel@stets.datayard.local> Message-ID: <3B7B8CDD-7E92-45FD-AC3B-0D7C3B8730D6@ar-ballbat.org> Also, what do your stats look like? 6kft is getting beyond the sweet spot for VDSL2, particularly if you're trying to push 10Mbps on the upstream. Sent from my iPhone > On Jan 15, 2015, at 5:36, Shawn L wrote: > > I was going to ask if you've tested the cable pair at all. If the pair is > bad, or even a little out of balance, bad scotch loks, etc. VDSL isn't > going to work properly. > > We have customers that are definitely in-range for VDSL but who cannot get > it because there is a 26 gauge insert between two cross-connect cabinets in > the field > >> On Thu, Jan 15, 2015 at 8:15 AM, Scott Helms wrote: >> >> I'm going to guess you're a CLEC from your website and a common problem >> I've seen in that scenario is that vectoring doesn't work between DSLAMs >> because it needs all pairs to be part of the vector group so that the DSLAM >> can mitigate FEXT. DSLAM vendors have been working on system level, rather >> than DSLAM/binder level, vectoring for a while but cross vendor support is >> questionable at best. >> >> Read the section on system level vectoring especially: >> http://www.adtran.com/web/fileDownload/doc/32362 >> >> If you are sharing binders with the ILEC and potentially other CLECs then >> you really need to talk to you ILEC rep and find out what they're doing for >> system level vectoring to see if there is an option for your DSLAMs to be >> included. That benefits everyone and will _greatly_ increase performance. >> VDSL2 speeds will otherwise be unreachable unless the ILEC gives each CLEC >> their own binder, not very practical. >> >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Wed, Jan 14, 2015 at 9:29 AM, Stetson Blake < >> Stetson.Blake at datayardworks.com> wrote: >> >>> Hey All, >>> >>> We have been deploying Adtran 838(shdsl) and 868(dsl) units in our metro >>> area with mixed results. The devices themselves are reliable and secure >>> it would seem, but the speeds were are able to get are not. ie. we have >>> deployed 'vdsl' and needed 3 lines to get up to 10x10 speeds. We are >>> using an Adtran TA5000 on the other end to terminate our connections. >>> The distance between the site and CO is not great (under 6k feet). What >>> gives? Are we provisioning wrong, using the wrong equipment, or a >>> combination of both? >>> If we were able to get the speeds others have been reporting from VDSL, >>> life would be great. >>> Anyone feel free to contact me off-list or on, this has had me >>> scratching my head for a while now. >>> >>> Thanks, >>> >>> -- >>> Stetson Blake >>> Network Technician >>> DataYard >>> 130 West Second St. >>> Suite 250 >>> Dayton, OH 45402 >>> >>> http://datayardworks.com >> From eksffa at freebsdbrasil.com.br Fri Jan 16 15:07:29 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Fri, 16 Jan 2015 13:07:29 -0200 Subject: FL-IX in Miami is ready for new members In-Reply-To: References: Message-ID: > On 12/01/2015, at 17:24, Dave Temkin wrote: > > Hi all, > > > FL-IX has started issuing LOAs for both 36 NE 2nd Street and NOTA in Miami. > If you have a network that peers at either location, we'd love to have you > as a member. We've committed to keeping the IX platform free for 3 years > (you bring the cross connect; we have pre-negotiated deals for inexpensive > riser in 36 NE 2nd). > > > For more information, please see: http://www.fl-ix.net > Do you have a suggestion for cost-effective cross connect provider from ZIP 33166 to 36 NE 2nd St. or NOTA? -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601 at sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From edtardist at gmail.com Fri Jan 16 15:40:32 2015 From: edtardist at gmail.com (Eddie Tardist) Date: Fri, 16 Jan 2015 13:40:32 -0200 Subject: FL-IX in Miami is ready for new members In-Reply-To: References: Message-ID: On Fri, Jan 16, 2015 at 1:07 PM, Patrick Tracanelli < eksffa at freebsdbrasil.com.br> wrote: > > > On 12/01/2015, at 17:24, Dave Temkin wrote: > > > > Hi all, > > > > > > FL-IX has started issuing LOAs for both 36 NE 2nd Street and NOTA in > Miami. > > If you have a network that peers at either location, we'd love to have > you > > as a member. We've committed to keeping the IX platform free for 3 years > > (you bring the cross connect; we have pre-negotiated deals for > inexpensive > > riser in 36 NE 2nd). > > > > > > For more information, please see: http://www.fl-ix.net > > > > Do you have a suggestion for cost-effective cross connect provider from > ZIP 33166 to 36 NE 2nd St. or NOTA? > LMC Wireless LLC is located in Doral. They will provide microwave connect to Brickell area. Maybe you should contact them about FL-IX site locations. How are you connected today? btw are you the same Patrick Tracanelli from ServerU routing appliances? From vwittkop at nanog.org Fri Jan 16 17:39:20 2015 From: vwittkop at nanog.org (Valerie Wittkop) Date: Fri, 16 Jan 2015 12:39:20 -0500 Subject: [NANOG-announce] ARIN+NANOG On The Road - Orlando Message-ID: <0DF59396-C9FD-4600-9514-1497DDFAB806@nanog.org> We invite you to join us at: ARIN+NANOG On The Road - Orlando Tuesday, 24 February 2015 9:00 AM – 5:00 PM; Reception: 5:00 PM – 6:30 PM Eastern Time Register at: https://www.nanog.org/meetings/road5/registration ARIN + NANOG On The Road is hosted by the American Registry for Internet Numbers (ARIN ) and the North American Network Operators’ Group (NANOG ). If you are, or will be, in the Orlando area, we invite you to attend this meeting . The agenda features an “Open Internet Debate” keynote address; sessions will include an ARIN Overview along with policies under discussion, DNSSEC & RPKI, IPv6 Tutorial, and an introduction to BGP. This free event, held at the Holiday Inn Resort Orlando-Lake Buena Vista, will also feature interactive discussions and networking opportunities. Lunch will be provided and there will be two drawings for $100 Amazon gift cards. Don't wait until it's too late to register ! Space is limited and will fill up fast, so sign up as soon as you know you can attend. Make ARIN+NANOG On The Road your first step toward learning how you can take the wheel and steer the future of the Internet. Please share this invitation with anyone you feel may benefit from attending this meeting. Learn more about On The Road events here . Feel free to contact us at nanog-support at nanog.org if you have any questions. Regards, Valerie Valerie Wittkop NANOG Program Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cscora at apnic.net Fri Jan 16 18:11:25 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Jan 2015 04:11:25 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201501161811.t0GIBPK9030065@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 17 Jan, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 526976 Prefixes after maximum aggregation (per Origin AS): 202232 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 257810 Total ASes present in the Internet Routing Table: 49093 Prefixes per ASN: 10.73 Origin-only ASes present in the Internet Routing Table: 36410 Origin ASes announcing only one prefix: 16310 Transit ASes present in the Internet Routing Table: 6195 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 107 Max AS path prepend of ASN ( 55644) 100 Prefixes from unregistered ASNs in the Routing Table: 1602 Unregistered ASNs in the Routing Table: 417 Number of 32-bit ASNs allocated by the RIRs: 8376 Number of 32-bit ASNs visible in the Routing Table: 6488 Prefixes from 32-bit ASNs in the Routing Table: 23272 Number of bogon 32-bit ASNs visible in the Routing Table: 11 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 392 Number of addresses announced to Internet: 2719739492 Equivalent to 162 /8s, 27 /16s and 238 /24s Percentage of available address space announced: 73.5 Percentage of allocated address space announced: 73.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.1 Total number of prefixes smaller than registry allocations: 177721 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 130455 Total APNIC prefixes after maximum aggregation: 38037 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 135324 Unique aggregates announced from the APNIC address blocks: 55288 APNIC Region origin ASes present in the Internet Routing Table: 5016 APNIC Prefixes per ASN: 26.98 APNIC Region origin ASes announcing only one prefix: 1225 APNIC Region transit ASes present in the Internet Routing Table: 864 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1252 Number of APNIC addresses announced to Internet: 741194624 Equivalent to 44 /8s, 45 /16s and 187 /24s Percentage of available APNIC address space announced: 86.6 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, 131072-135580 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: 174887 Total ARIN prefixes after maximum aggregation: 86451 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 176802 Unique aggregates announced from the ARIN address blocks: 82742 ARIN Region origin ASes present in the Internet Routing Table: 16434 ARIN Prefixes per ASN: 10.76 ARIN Region origin ASes announcing only one prefix: 6086 ARIN Region transit ASes present in the Internet Routing Table: 1715 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 19 Number of ARIN region 32-bit ASNs visible in the Routing Table: 322 Number of ARIN addresses announced to Internet: 1055595232 Equivalent to 62 /8s, 235 /16s and 26 /24s Percentage of available ARIN address space announced: 55.8 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, 393216-394239 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: 127056 Total RIPE prefixes after maximum aggregation: 63838 RIPE Deaggregation factor: 1.99 Prefixes being announced from the RIPE address blocks: 133202 Unique aggregates announced from the RIPE address blocks: 83191 RIPE Region origin ASes present in the Internet Routing Table: 17829 RIPE Prefixes per ASN: 7.47 RIPE Region origin ASes announcing only one prefix: 8150 RIPE Region transit ASes present in the Internet Routing Table: 2924 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3357 Number of RIPE addresses announced to Internet: 692833412 Equivalent to 41 /8s, 75 /16s and 204 /24s Percentage of available RIPE address space announced: 100.7 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, 196608-202239 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: 58714 Total LACNIC prefixes after maximum aggregation: 10894 LACNIC Deaggregation factor: 5.39 Prefixes being announced from the LACNIC address blocks: 67849 Unique aggregates announced from the LACNIC address blocks: 31251 LACNIC Region origin ASes present in the Internet Routing Table: 2391 LACNIC Prefixes per ASN: 28.38 LACNIC Region origin ASes announcing only one prefix: 643 LACNIC Region transit ASes present in the Internet Routing Table: 469 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1472 Number of LACNIC addresses announced to Internet: 167684224 Equivalent to 9 /8s, 254 /16s and 168 /24s Percentage of available LACNIC address space announced: 99.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12479 Total AfriNIC prefixes after maximum aggregation: 2968 AfriNIC Deaggregation factor: 4.20 Prefixes being announced from the AfriNIC address blocks: 13407 Unique aggregates announced from the AfriNIC address blocks: 4990 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 18.19 AfriNIC Region origin ASes announcing only one prefix: 206 AfriNIC Region transit ASes present in the Internet Routing Table: 151 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 85 Number of AfriNIC addresses announced to Internet: 60936448 Equivalent to 3 /8s, 161 /16s and 209 /24s Percentage of available AfriNIC address space announced: 60.5 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 4766 2905 11556 910 Korea Telecom 17974 2830 904 77 PT Telekomunikasi Indonesia 7545 2500 336 128 TPG Telecom Limited 4755 1933 418 191 TATA Communications formerly 4538 1758 4190 71 China Education and Research 9829 1675 1323 30 National Internet Backbone 9808 1523 6719 19 Guangdong Mobile Communicatio 4808 1457 2213 435 CNCGROUP IP network China169 9583 1393 115 572 Sify Limited 9498 1292 336 98 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 2930 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2566 10685 478 Level 3 Communications, Inc. 18566 2042 379 183 MegaPath Corporation 20115 1855 1826 448 Charter Communications 6983 1629 867 245 EarthLink, Inc. 4323 1622 1037 408 tw telecom holdings, inc. 30036 1522 316 541 Mediacom Communications Corp 701 1399 11273 686 MCI Communications Services, 22561 1339 411 241 CenturyTel Internet Holdings, 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 34984 1937 300 359 TELLCOM ILETISIM HIZMETLERI A 20940 1546 603 1147 Akamai International B.V. 8402 1428 544 15 OJSC "Vimpelcom" 6849 1233 356 25 JSC "Ukrtelecom" 13188 1038 97 55 TOV "Bank-Inform" 31148 940 45 41 Freenet Ltd. 8551 904 373 48 Bezeq International-Ltd 9198 853 349 26 JSC Kazakhtelecom 12479 831 793 86 France Telecom Espana SA 6830 825 2340 445 Liberty Global Operations B.V 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 3057 495 248 Telmex Colombia S.A. 28573 2320 2130 116 NET Servi�os de Comunica��o S 6147 1780 374 30 Telefonica del Peru S.A.A. 7303 1768 1172 237 Telecom Argentina S.A. 8151 1489 3080 431 Uninet S.A. de C.V. 6503 1226 417 56 Axtel, S.A.B. de C.V. 7738 1000 1882 42 Telemar Norte Leste S.A. 3816 915 396 148 COLOMBIA TELECOMUNICACIONES S 26615 914 2325 35 Tim Celular S.A. 18881 857 1036 22 Global Village Telecom 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 8452 1497 958 13 TE-AS 24863 951 284 26 Link Egypt (Link.NET) 36903 480 242 90 Office National des Postes et 36992 373 845 30 ETISALAT MISR 37492 347 145 64 Orange Tunisie 24835 295 144 9 Vodafone Data 3741 248 921 213 Internet Solutions 29571 233 21 12 Cote d'Ivoire Telecom 36947 195 807 13 Telecom Algeria 15706 176 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3057 495 248 Telmex Colombia S.A. 22773 2930 2955 141 Cox Communications Inc. 4766 2905 11556 910 Korea Telecom 6389 2891 3688 51 BellSouth.net Inc. 17974 2830 904 77 PT Telekomunikasi Indonesia 3356 2566 10685 478 Level 3 Communications, Inc. 7545 2500 336 128 TPG Telecom Limited 28573 2320 2130 116 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation 34984 1937 300 359 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2891 2840 BellSouth.net Inc. 22773 2930 2789 Cox Communications Inc. 17974 2830 2753 PT Telekomunikasi Indonesia 7545 2500 2372 TPG Telecom Limited 28573 2320 2204 NET Servi�os de Comunica��o S 3356 2566 2088 Level 3 Communications, Inc. 4766 2905 1995 Korea Telecom 18566 2042 1859 MegaPath Corporation 6147 1780 1750 Telefonica del Peru S.A.A. 4755 1933 1742 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.92.160.0/24 14013 EPSON America (Factory Automa 23.92.161.0/24 14013 EPSON America (Factory Automa 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 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:12 /10:31 /11:92 /12:265 /13:502 /14:998 /15:1724 /16:13041 /17:7193 /18:12004 /19:24928 /20:35731 /21:38315 /22:56977 /23:49791 /24:282396 /25:1149 /26:1084 /27:677 /28:15 /29:14 /30:10 /31:0 /32:11 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2143 2930 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1367 1522 Mediacom Communications Corp 6147 1323 1780 Telefonica del Peru S.A.A. 6983 1315 1629 EarthLink, Inc. 34984 1241 1937 TELLCOM ILETISIM HIZMETLERI A 11492 1125 1184 CABLE ONE, INC. 8402 1093 1428 OJSC "Vimpelcom" 10620 1090 3057 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1420 2:672 3:1 4:94 5:1216 6:21 8:1403 11:1 12:1839 13:4 14:1253 15:17 16:2 17:45 18:21 20:50 23:1097 24:1673 27:1823 31:1486 32:39 33:2 34:5 35:1 36:130 37:1884 38:969 39:15 40:230 41:3001 42:267 43:915 44:23 45:90 46:2132 47:34 49:781 50:784 52:12 54:66 55:7 56:8 57:32 58:1121 59:674 60:454 61:1747 62:1287 63:1901 64:4400 65:2268 66:4079 67:2009 68:1035 69:3248 70:907 71:427 72:1969 74:2621 75:314 76:411 77:1414 78:1032 79:788 80:1324 81:1300 82:802 83:669 84:673 85:1314 86:384 87:1193 88:522 89:1761 90:139 91:5882 92:794 93:1694 94:1911 95:1396 96:420 97:334 98:1040 99:46 100:70 101:802 103:6517 104:1080 105:109 106:199 107:886 108:607 109:2019 110:1063 111:1469 112:743 113:978 114:808 115:1249 116:1320 117:1031 118:1681 119:1395 120:438 121:1012 122:2173 123:1718 124:1490 125:1523 128:645 129:374 130:382 131:1080 132:449 133:167 134:389 135:86 136:331 137:299 138:396 139:176 140:220 141:411 142:620 143:444 144:515 145:112 146:725 147:547 148:1062 149:395 150:548 151:748 152:485 153:246 154:296 155:676 156:394 157:330 158:263 159:946 160:370 161:631 162:1872 163:372 164:645 165:659 166:322 167:717 168:994 169:140 170:1430 171:223 172:48 173:1583 174:707 175:611 176:1471 177:3692 178:2102 179:819 180:1856 181:1630 182:1699 183:575 184:731 185:2666 186:2830 187:1723 188:2001 189:1553 190:7889 191:813 192:8027 193:5556 194:4057 195:3630 196:1687 197:850 198:5447 199:5512 200:6512 201:2925 202:9491 203:9042 204:4656 205:2724 206:3006 207:2971 208:3931 209:3876 210:3495 211:1836 212:2544 213:2258 214:838 215:73 216:5530 217:1776 218:664 219:460 220:1319 221:784 222:462 223:677 End of report From cma at cmadams.net Fri Jan 16 21:00:31 2015 From: cma at cmadams.net (Chris Adams) Date: Fri, 16 Jan 2015 15:00:31 -0600 Subject: Verizon.net email admin? Message-ID: <20150116210031.GA13566@cmadams.net> Anybody Verizon.net mail admins around? I have a downstream customer on a newly-deployed IP allocation that can't get to pop.verizon.net (connections just time out). She can surf elsewhere, she can take the same computer to another location (different IP block) and it works, so it appears something on Verizon is filtering out the IP space (from 107.190.192.0/20). Thanks. -- Chris Adams From ammar at fastreturn.net Fri Jan 16 21:13:06 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sat, 17 Jan 2015 01:13:06 +0400 Subject: Verizon.net email admin? In-Reply-To: <20150116210031.GA13566@cmadams.net> References: <20150116210031.GA13566@cmadams.net> Message-ID: Maybe your IP block isn’t being accepted by Verizon? Can you traceroute it etc? > On Jan 17, 2015, at 1:00 AM, Chris Adams wrote: > > Anybody Verizon.net mail admins around? > > I have a downstream customer on a newly-deployed IP allocation that > can't get to pop.verizon.net (connections just time out). She can surf > elsewhere, she can take the same computer to another location (different > IP block) and it works, so it appears something on Verizon is filtering > out the IP space (from 107.190.192.0/20). > > Thanks. > -- > Chris Adams From pete at altadena.net Fri Jan 16 21:51:13 2015 From: pete at altadena.net (Pete Carah) Date: Fri, 16 Jan 2015 16:51:13 -0500 Subject: Verizon.net email admin? In-Reply-To: <20150116210031.GA13566@cmadams.net> References: <20150116210031.GA13566@cmadams.net> Message-ID: <54B987D1.5040907@altadena.net> On 01/16/2015 04:00 PM, Chris Adams wrote: > Anybody Verizon.net mail admins around? > > I have a downstream customer on a newly-deployed IP allocation that > can't get to pop.verizon.net (connections just time out). I can't either ping or telnet to that either but can connect with s_client. I'm *on* verizon (fios)... Maybe they only allow secure, at least from some locations. (Just for reference, I'm seeing pop.verizon.net at a 206.46.x.x address, no v6.) (not saying that they don't filter, but there are no 107 prefixes in the current cymru fullbogon4 list fetched about 5 minutes ago.) -- Pete From cidr-report at potaroo.net Fri Jan 16 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Jan 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201501162200.t0GM00Ou008519@wattle.apnic.net> This report has been generated at Fri Jan 16 21:14:25 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-01-15 530957 292867 10-01-15 530888 293281 11-01-15 530995 293414 12-01-15 531475 292974 13-01-15 531676 293207 14-01-15 531589 292441 15-01-15 532069 293018 16-01-15 533401 293570 AS Summary 49371 Number of ASes in routing system 19817 Number of ASes announcing only one prefix 3057 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120393216 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 16Jan15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 532447 293424 239023 44.9% All ASes AS6389 2890 71 2819 97.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2929 172 2757 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2830 77 2753 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS28573 2320 311 2009 86.6% NET Servi�os de Comunica��o S.A.,BR AS3356 2565 726 1839 71.7% LEVEL3 - Level 3 Communications, Inc.,US AS4755 1933 285 1648 85.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS6147 1780 159 1621 91.1% Telefonica del Peru S.A.A.,PE AS4766 2905 1286 1619 55.7% KIXS-AS-KR Korea Telecom,KR AS7303 1771 288 1483 83.7% Telecom Argentina S.A.,AR AS9808 1522 56 1466 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 3057 1646 1411 46.2% Telmex Colombia S.A.,CO AS8402 1411 25 1386 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1856 529 1327 71.5% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2513 1233 1280 50.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1629 410 1219 74.8% TWTC - tw telecom holdings, inc.,US AS9498 1293 113 1180 91.3% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2041 868 1173 57.5% MEGAPATH5-US - MegaPath Corporation,US AS6849 1230 134 1096 89.1% UKRTELNET JSC UKRTELECOM,UA AS22561 1339 276 1063 79.4% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7552 1101 45 1056 95.9% VIETEL-AS-AP Viettel Corporation,VN AS6983 1629 638 991 60.8% ITCDELTA - Earthlink, Inc.,US AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1776 909 867 48.8% ERX-CERNET-BKB China Education and Research Network Center,CN AS24560 1198 422 776 64.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS26615 914 139 775 84.8% Tim Celular S.A.,BR AS4780 1073 299 774 72.1% SEEDNET Digital United Inc.,TW AS18101 953 192 761 79.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS855 812 57 755 93.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS17908 837 94 743 88.8% TCISL Tata Communications,IN Total 52090 11657 40433 77.6% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.92.160.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.92.161.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 62.122.74.0/23 AS5577 ROOT root SA,LU 64.18.128.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 64.187.208.0/24 AS174 COGENT-174 - Cogent Communications,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.50.0/24 AS9009 M247 M247 Ltd,BE 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.243.72.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.243.73.0/24 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.243.74.0/23 AS36351 SOFTLAYER - SoftLayer Technologies Inc.,US 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.252.116.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 104.255.12.0/22 AS36445 COEXTRO-01 - Coextro,CA 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 186.65.108.0/22 AS22927 Telefonica de Argentina,AR 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.81.70.0/24 AS39363 NPLUSNETWORKS - NPlus Networks,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.106.32.0/22 AS49873 -Reserved AS-,ZZ 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS3322 -Reserved AS-,ZZ 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.18.0/24 AS33790 -Reserved AS-,ZZ 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.61.108.0/24 AS55812 202.61.118.0/24 AS55833 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.8.216.0/21 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 204.8.217.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 204.8.218.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 204.8.222.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 209.250.224.0/22 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.224.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.225.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.230.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 209.250.253.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 209.250.254.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.24.208.0/24 AS3561 SAVVIS - Savvis,US 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 16 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Jan 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201501162200.t0GM02Pb008535@wattle.apnic.net> BGP Update Report Interval: 08-Jan-15 -to- 15-Jan-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 320546 7.0% 2887.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 167235 3.6% 141.4 -- BSNL-NIB National Internet Backbone,IN 3 - AS53249 80639 1.8% 40319.5 -- LAWA-AS - Los Angeles World Airport,US 4 - AS45899 75029 1.6% 121.2 -- VNPT-AS-VN VNPT Corp,VN 5 - AS31148 55744 1.2% 56.4 -- FREENET-AS Freenet Ltd.,UA 6 - AS38197 49650 1.1% 59.1 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 7 - AS53563 43204 0.9% 8640.8 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - AS17099 40055 0.9% 3081.2 -- CALLIS-COMMUNICATIONS-AS - Callis Communications,US 9 - AS11664 39916 0.9% 82.8 -- Techtel LMDS Comunicaciones Interactivas S.A.,AR 10 - AS3 38581 0.8% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 11 - AS10620 35546 0.8% 27.5 -- Telmex Colombia S.A.,CO 12 - AS27738 34469 0.8% 44.1 -- Ecuadortelecom S.A.,EC 13 - AS8402 33335 0.7% 173.6 -- CORBINA-AS OJSC "Vimpelcom",RU 14 - AS36925 31985 0.7% 404.9 -- ASMedi,MA 15 - AS9583 31906 0.7% 25.6 -- SIFY-AS-IN Sify Limited,IN 16 - AS17974 27549 0.6% 28.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 17 - AS28024 26411 0.6% 17.3 -- Nuevatel PCS de Bolivia S.A.,BO 18 - AS64512 25478 0.6% 1819.9 -- -Private Use AS-,ZZ 19 - AS48159 25459 0.6% 88.4 -- TIC-AS Telecommunication Infrastructure Company,IR 20 - AS13489 25115 0.6% 49.0 -- EPM Telecomunicaciones S.A. E.S.P.,CO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS53249 80639 1.8% 40319.5 -- LAWA-AS - Los Angeles World Airport,US 2 - AS3 38581 0.8% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 3 - AS18135 11409 0.2% 11409.0 -- BTV BTV Cable television,JP 4 - AS23342 22176 0.5% 11088.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 5 - AS53563 43204 0.9% 8640.8 -- XPLUSONE - X Plus One Solutions, Inc.,US 6 - AS62174 5622 0.1% 5622.0 -- INTERPAN-AS INTERPAN LTD.,BG 7 - AS49128 5592 0.1% 5592.0 -- IVCSPBORW-AS OAO Russian Railway,RU 8 - AS33721 4399 0.1% 4399.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 9 - AS60725 24972 0.5% 4162.0 -- O3B-AS O3b Limited,JE 10 - AS27250 7084 0.1% 3542.0 -- FNCINC - FNC INC,US 11 - AS11613 3307 0.1% 3307.0 -- U-SAVE - U-Save Auto Rental of America, Inc.,US 12 - AS46214 3233 0.1% 3233.0 -- LEFRED - Lefleur Transportation of Tupelo, Inc.,US 13 - AS17099 40055 0.9% 3081.2 -- CALLIS-COMMUNICATIONS-AS - Callis Communications,US 14 - AS23752 320546 7.0% 2887.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 15 - AS25563 7719 0.2% 2573.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 16 - AS3 2500 0.1% 1445.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 17 - AS29508 2401 0.1% 2401.0 -- TANAT-AS TANAT LLC,UA 18 - AS62695 8922 0.2% 2230.5 -- VERSO-NETWORKS - Verso Networks, Inc.,US 19 - AS47680 10816 0.2% 2163.2 -- NHCS EOBO Limited,IE 20 - AS27934 16917 0.4% 2114.6 -- JSNet S.A.,AR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 159902 3.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 159517 3.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 199.38.164.0/23 43057 0.9% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 4 - 198.140.114.0/24 40326 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 5 - 198.140.115.0/24 40313 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 6 - 130.0.192.0/21 38577 0.8% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 7 - 64.29.130.0/24 22173 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 8 - 192.115.44.0/22 18964 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 9 - 200.24.244.0/24 16739 0.3% AS27934 -- JSNet S.A.,AR 10 - 185.26.155.0/24 12850 0.3% AS60725 -- O3B-AS O3b Limited,JE 11 - 162.249.183.0/24 12102 0.2% AS60725 -- O3B-AS O3b Limited,JE 12 - 42.83.48.0/20 11409 0.2% AS18135 -- BTV BTV Cable television,JP 13 - 192.58.232.0/24 10863 0.2% AS6629 -- NOAA-AS - NOAA,US 14 - 88.87.160.0/19 10812 0.2% AS47680 -- NHCS EOBO Limited,IE 15 - 197.230.128.0/17 8314 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 16 - 41.214.192.0/18 8296 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 17 - 197.253.128.0/17 8236 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 18 - 105.188.0.0/14 7880 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 19 - 197.153.0.0/16 7872 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ 20 - 41.92.0.0/17 7855 0.2% AS36925 -- ASMedi,MA AS64512 -- -Private Use AS-,ZZ Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cma at cmadams.net Fri Jan 16 22:02:51 2015 From: cma at cmadams.net (Chris Adams) Date: Fri, 16 Jan 2015 16:02:51 -0600 Subject: Verizon.net email admin? In-Reply-To: <54B987D1.5040907@altadena.net> References: <20150116210031.GA13566@cmadams.net> <54B987D1.5040907@altadena.net> Message-ID: <20150116220251.GC13566@cmadams.net> Once upon a time, Pete Carah said: > On 01/16/2015 04:00 PM, Chris Adams wrote: > > Anybody Verizon.net mail admins around? > > > > I have a downstream customer on a newly-deployed IP allocation that > > can't get to pop.verizon.net (connections just time out). > I can't either ping or telnet to that either but can connect with > s_client. I'm *on* verizon (fios)... Yeah, apparently they only allow SSL-wrapped connections on 993 and 465, block ping/traceroute, etc. (makes it hard to debug). However, I believe the customer when they say the computer is configured correctly, because it is a notebook and works on another network (both at our downstream, in a different IP block, and a fast-food place with free wifi). > Maybe they only allow secure, at least from some locations. > (Just for reference, I'm seeing pop.verizon.net at a 206.46.x.x address, > no v6.) Me too (didn't think if they might have different IPs in different locations). I see pop.verizon.net is 206.46.232.132. > (not saying that they don't filter, but there are no 107 prefixes in the > current cymru fullbogon4 list fetched about 5 minutes ago.) I don't know; that's just a guess on my part that it may be the problem (seems to fit). -- Chris Adams From hugo at slabnet.com Fri Jan 16 22:09:02 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 16 Jan 2015 14:09:02 -0800 Subject: Verizon.net email admin? In-Reply-To: <54B987D1.5040907@altadena.net> References: <20150116210031.GA13566@cmadams.net> <54B987D1.5040907@altadena.net> Message-ID: <20150116220902.GC31474@bamboo.slabnet.com> >Maybe they only allow secure, at least from some locations. That seems to be the likely case... http://mailman.nanog.org/pipermail/nanog/2014-October/070532.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From frnkblk at iname.com Fri Jan 16 22:17:09 2015 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 16 Jan 2015 16:17:09 -0600 Subject: Verizon.net email admin? In-Reply-To: <20150116220251.GC13566@cmadams.net> References: <20150116210031.GA13566@cmadams.net> <54B987D1.5040907@altadena.net> <20150116220251.GC13566@cmadams.net> Message-ID: <000e01d031da$2b62ef40$8228cdc0$@iname.com> FYI, this topic was discussed on this listserv in mid-October (http://mailman.nanog.org/pipermail/nanog/2014-October/070532.html) and mailops (archives restricted to listserv members) in mid-November. In the NANOG thread reference was made that Verizon was filtering out the 107/8 network. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Adams Sent: Friday, January 16, 2015 4:03 PM To: nanog at nanog.org Subject: Re: Verizon.net email admin? Once upon a time, Pete Carah said: > On 01/16/2015 04:00 PM, Chris Adams wrote: > > Anybody Verizon.net mail admins around? > > > > I have a downstream customer on a newly-deployed IP allocation that > > can't get to pop.verizon.net (connections just time out). > I can't either ping or telnet to that either but can connect with > s_client. I'm *on* verizon (fios)... Yeah, apparently they only allow SSL-wrapped connections on 993 and 465, block ping/traceroute, etc. (makes it hard to debug). However, I believe the customer when they say the computer is configured correctly, because it is a notebook and works on another network (both at our downstream, in a different IP block, and a fast-food place with free wifi). > Maybe they only allow secure, at least from some locations. > (Just for reference, I'm seeing pop.verizon.net at a 206.46.x.x address, > no v6.) Me too (didn't think if they might have different IPs in different locations). I see pop.verizon.net is 206.46.232.132. > (not saying that they don't filter, but there are no 107 prefixes in the > current cymru fullbogon4 list fetched about 5 minutes ago.) I don't know; that's just a guess on my part that it may be the problem (seems to fit). -- Chris Adams From pete at altadena.net Fri Jan 16 23:49:47 2015 From: pete at altadena.net (Pete Carah) Date: Fri, 16 Jan 2015 18:49:47 -0500 Subject: Verizon.net email admin? In-Reply-To: <000e01d031da$2b62ef40$8228cdc0$@iname.com> References: <20150116210031.GA13566@cmadams.net> <54B987D1.5040907@altadena.net> <20150116220251.GC13566@cmadams.net> <000e01d031da$2b62ef40$8228cdc0$@iname.com> Message-ID: <54B9A39B.9070305@altadena.net> On 01/16/2015 05:17 PM, Frank Bulk wrote: > FYI, this topic was discussed on this listserv in mid-October > (http://mailman.nanog.org/pipermail/nanog/2014-October/070532.html) and > mailops (archives restricted to listserv members) in mid-November. In the > NANOG thread reference was made that Verizon was filtering out the 107/8 > network. > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Adams > Sent: Friday, January 16, 2015 4:03 PM > To: nanog at nanog.org > Subject: Re: Verizon.net email admin? > > Once upon a time, Pete Carah said: .....snip..... >> (not saying that they don't filter, but there are no 107 prefixes in the >> current cymru fullbogon4 list fetched about 5 minutes ago.) Pardon following up on my own post, but from my (business) fios, I can ping the .1 address of the mentioned 107 block OK; of course vz might still filter it for service networks like mail. > I don't know; that's just a guess on my part that it may be the problem > (seems to fit). From agember at cs.wisc.edu Fri Jan 16 20:30:53 2015 From: agember at cs.wisc.edu (Gember-Jacobson, Aaron) Date: Fri, 16 Jan 2015 14:30:53 -0600 Subject: Network Management Survey Message-ID: We are a team of researchers in the Computer Sciences department at the University of Wisconsin studying network management practices. Our goal is to better understand what practices are employed by network operators, and to what extent certain practices impact the frequency/severity of network problems. We would appreciate if you could take two minutes to complete our brief 12 question survey: https://docs.google.com/forms/d/1CfO07p7tIm7w1P10NNYQrKeDJMFn0O0Ld3kdn9ZBP6c/viewform To learn more about our research, visit http://cs.wisc.edu/~agember/go/mpa Thanks, Aaron Gember-Jacobson Fellow, University of Wisconsin-Madison From md at bts.sk Sat Jan 17 11:02:33 2015 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Sat, 17 Jan 2015 12:02:33 +0100 Subject: Recommended L2 switches for a new IXP Message-ID: <20150117110233.GA88590@bts.sk> Last year we installed four 1RU TRILL switches in SIX - see http://www.six.sk/images/trill_ring.png Our experience after 100 days of production is only the best - TRILL setup is pretty straightforward and thanks to IS-IS it provides shortest-path IP-like "routing" for L2 ethernet packets over any reasonable topology out of the box (without the burden and cost implications of VPLS). Trident ASICs perform deep packet inspection so ECMP loadbalancing based on L3 and L4 headers inside TRILL-encapsulated packets works for both IPv4 and IPv6. Port-security is supported on physical ports as well as on LAGs - and L4 access-lists could be applied at the same time. As most 1RU switches are based on Trident ASICs, you just need to pick a vendor which implements TRILL properly and of course thoroughly test before deployment. We selected Huawei Cloud Engine 6850 boxes. Regards, M. > Dear Nanog community > > We are trying to build a new IXP in some US Metro areas where we have > multiple POPs and I was wondering what do you recommend for L2 switches. I > know that some IXPs use Nexus, Brocade, Force10 but I don't personally have > experience with these switches. It would be great if you can share your > experience and recommendations. There are so many options that I don't know > if it makes sense to start with a modular switch (usually expensive because > the backplane, dual dc, dual CPU, etc) or start with a 1RU high density > switch that support new protocols like Trill and that supposedly allow you > to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G > ports for exchange participants, 40G/100G for uplinks between switches and > flow support for statistics and traffic analysis. > > Thank you and have a great day. > > Regards From saku at ytti.fi Sat Jan 17 19:15:04 2015 From: saku at ytti.fi (Saku Ytti) Date: Sat, 17 Jan 2015 21:15:04 +0200 Subject: Recommended L2 switches for a new IXP In-Reply-To: <20150117110233.GA88590@bts.sk> References: <20150117110233.GA88590@bts.sk> Message-ID: <20150117191504.GA17079@pob.ytti.fi> On (2015-01-17 12:02 +0100), Marian Ďurkovič wrote: > Our experience after 100 days of production is only the best - TRILL setup > is pretty straightforward and thanks to IS-IS it provides shortest-path > IP-like "routing" for L2 ethernet packets over any reasonable topology > out of the box (without the burden and cost implications of VPLS). I'm not sure what the burden refers to, but cost implications to me seem same, trident HW can do VPLS. >From complexity POV, I don't expect much different development time to write functioning control-plane to either. I'm not against Trill, I think Trill, and especially SPB-M are great, now they just feel too little and 20 years too late. There was no particular reason why SPB-M couldn't have existed 20 years ago in HW. But perhaps it's good it didn't, it might have made ethernet 'good enough', that selling MPLS might have been much more difficult. -- ++ytti From mastorakis at cs.ucla.edu Sat Jan 17 21:34:38 2015 From: mastorakis at cs.ucla.edu (Spyridon Mastorakis) Date: Sat, 17 Jan 2015 13:34:38 -0800 Subject: Recommended readings on Network Monitoring and Anomaly Detection. Message-ID: <828655BA-268B-4152-B0EF-D0FC598FDEA4@cs.ucla.edu> Dear all, I am interested in conducting a survey on Network Monitoring and Anomaly Detection. I would really appreciate any recommendations for papers/readings that would help me on my survey. I am not really familiar with these areas, so I would appreciate to receive recommendations about papers/readings that elaborate on the basics as well. Thank you in advance for your time and your recommendations! Kind regards. -- Spyridon Mastorakis Personal Website: http://cs.ucla.edu/~mastorakis/ Internet Research Laboratory PhD Computer Science UCLA From rdobbins at arbor.net Sun Jan 18 01:57:09 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 18 Jan 2015 08:57:09 +0700 Subject: Recommended readings on Network Monitoring and Anomaly Detection. In-Reply-To: <828655BA-268B-4152-B0EF-D0FC598FDEA4@cs.ucla.edu> References: <828655BA-268B-4152-B0EF-D0FC598FDEA4@cs.ucla.edu> Message-ID: <7E204039-6244-461D-81AD-D2070ADB371F@arbor.net> On 18 Jan 2015, at 4:34, Spyridon Mastorakis wrote: > so I would appreciate to receive recommendations about papers/readings > that elaborate on the basics as well. ----------------------------------- Roland Dobbins From shortdudey123 at gmail.com Sun Jan 18 12:29:56 2015 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 18 Jan 2015 04:29:56 -0800 Subject: HTTPS redirects to HTTP for monitoring Message-ID: Hi Everyone, I wanted to see what opinions and thoughts were out there. What software, appliances, or services are being used to monitor web traffic for "inappropriate" content on the SSL side of things? personal use? enterprise enterprise? It looks like Websense might do decryption ( http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does some sort of session hijack to redirect to non-ssl (atleast for Google) ( https://twitter.com/CovenantEyes/status/451382865914105856). Thoughts on having a product that decrypts SSL traffic internally vs one that doesn't allow SSL to start with? -Grant From keastes at gmail.com Sun Jan 18 12:41:49 2015 From: keastes at gmail.com (kendrick eastes) Date: Sun, 18 Jan 2015 05:41:49 -0700 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: On Sun, Jan 18, 2015 at 5:29 AM, Grant Ridder wrote: > Hi Everyone, > > I wanted to see what opinions and thoughts were out there. What software, > appliances, or services are being used to monitor web traffic for > "inappropriate" content on the SSL side of things? personal use? > enterprise enterprise? > > It looks like Websense might do decryption ( > http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does > some sort of session hijack to redirect to non-ssl (atleast for Google) ( > https://twitter.com/CovenantEyes/status/451382865914105856). > > Thoughts on having a product that decrypts SSL traffic internally vs one > that doesn't allow SSL to start with? > > -Grant > Admittedly I've only been on the user side of things for this, but IMO for cases like this MITM > striping. if your users need to access anything outside your intranet (google apps comes to mind right away, any kind of outsourced web-based training, etc) that requires SSL to function would be broken by stripping, but with MITMing the connection and having your internal certs set up properly, it won't even blip. that being said, squid can be configured to transparently decrypt and reencrypt the session. (http://wiki.squid-cache.org/Features/SslBump) From andy at mbrez.com Sun Jan 18 14:18:48 2015 From: andy at mbrez.com (Andy Brezinsky) Date: Sun, 18 Jan 2015 08:18:48 -0600 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: <54BBC0C8.4010803@mbrez.com> We use Fortinet firewalls and SSL (HTTPS, FTPS, IMAPS, POP3S, SMTPS, SSH) inspection is a standard feature. It works by rolling out a custom CA certificate from the device to all of the desktops and whenever you hit a SSL site, a cert signed with the CA is generated and presented to the user. If you look at the cert your browser has, you can tell the CA is different but most users aren't looking at that. Our user base uses a lot of services that can't be forced to downgrade to HTTP so it's the only option. Fortinet has some configurations that allow you to exclude certain sites from the MiTM 'attack'. For example we don't scan banking, health care and personal privacy categories. On 01/18/2015 06:29 AM, Grant Ridder wrote: > Hi Everyone, > > I wanted to see what opinions and thoughts were out there. What software, > appliances, or services are being used to monitor web traffic for > "inappropriate" content on the SSL side of things? personal use? > enterprise enterprise? > > It looks like Websense might do decryption ( > http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does > some sort of session hijack to redirect to non-ssl (atleast for Google) ( > https://twitter.com/CovenantEyes/status/451382865914105856). > > Thoughts on having a product that decrypts SSL traffic internally vs one > that doesn't allow SSL to start with? > > -Grant From cb.list6 at gmail.com Sun Jan 18 14:48:49 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 18 Jan 2015 06:48:49 -0800 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: On Sunday, January 18, 2015, Grant Ridder wrote: > Hi Everyone, > > I wanted to see what opinions and thoughts were out there. What software, > appliances, or services are being used to monitor web traffic for > "inappropriate" content on the SSL side of things? personal use? > enterprise enterprise? > > It looks like Websense might do decryption ( > http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does > some sort of session hijack to redirect to non-ssl (atleast for Google) ( > https://twitter.com/CovenantEyes/status/451382865914105856). > > Thoughts on having a product that decrypts SSL traffic internally vs one > that doesn't allow SSL to start with? > > -Grant > IMHO, it would be better to just block the service and say the encrypted traffic is inconsistent with your policy instead of snooping it and exposing sensitive data to your middle box. These boxes that violate end to end encryption are a great place for hackers to steal the bank and identity info of everyone in your company. That sounds like a lot liablity to put on your shoulders. CB From ammar at fastreturn.net Sun Jan 18 14:53:41 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sun, 18 Jan 2015 18:53:41 +0400 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: <63418E02-F95D-4331-B56C-E64A52FC36E1@fastreturn.net> So your idea is to block every HTTPS website? > On 18 Jan 2015, at 6:48 pm, Ca By wrote: > >> On Sunday, January 18, 2015, Grant Ridder wrote: >> >> Hi Everyone, >> >> I wanted to see what opinions and thoughts were out there. What software, >> appliances, or services are being used to monitor web traffic for >> "inappropriate" content on the SSL side of things? personal use? >> enterprise enterprise? >> >> It looks like Websense might do decryption ( >> http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does >> some sort of session hijack to redirect to non-ssl (atleast for Google) ( >> https://twitter.com/CovenantEyes/status/451382865914105856). >> >> Thoughts on having a product that decrypts SSL traffic internally vs one >> that doesn't allow SSL to start with? >> >> -Grant > > IMHO, it would be better to just block the service and say the encrypted > traffic is inconsistent with your policy instead of snooping it and > exposing sensitive data to your middle box. > > These boxes that violate end to end encryption are a great place for > hackers to steal the bank and identity info of everyone in your company. > > That sounds like a lot liablity to put on your shoulders. > > CB From nanog at jack.fr.eu.org Sun Jan 18 15:24:05 2015 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Sun, 18 Jan 2015 16:24:05 +0100 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <63418E02-F95D-4331-B56C-E64A52FC36E1@fastreturn.net> References: <63418E02-F95D-4331-B56C-E64A52FC36E1@fastreturn.net> Message-ID: <54BBD015.3070001@jack.fr.eu.org> >From my point of view, it is better than violate user privacy & safety. Sneaky is evil. On 18/01/2015 15:53, Ammar Zuberi wrote: > So your idea is to block every HTTPS website? > > >> On 18 Jan 2015, at 6:48 pm, Ca By wrote: >> >>> On Sunday, January 18, 2015, Grant Ridder wrote: >>> >>> Hi Everyone, >>> >>> I wanted to see what opinions and thoughts were out there. What software, >>> appliances, or services are being used to monitor web traffic for >>> "inappropriate" content on the SSL side of things? personal use? >>> enterprise enterprise? >>> >>> It looks like Websense might do decryption ( >>> http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does >>> some sort of session hijack to redirect to non-ssl (atleast for Google) ( >>> https://twitter.com/CovenantEyes/status/451382865914105856). >>> >>> Thoughts on having a product that decrypts SSL traffic internally vs one >>> that doesn't allow SSL to start with? >>> >>> -Grant >> >> IMHO, it would be better to just block the service and say the encrypted >> traffic is inconsistent with your policy instead of snooping it and >> exposing sensitive data to your middle box. >> >> These boxes that violate end to end encryption are a great place for >> hackers to steal the bank and identity info of everyone in your company. >> >> That sounds like a lot liablity to put on your shoulders. >> >> CB From tknchris at gmail.com Sun Jan 18 15:25:54 2015 From: tknchris at gmail.com (chris) Date: Sun, 18 Jan 2015 10:25:54 -0500 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: Hello, I have been going through something very interesting recently that relates to this. We have a customer who google is flagging for "abusive" search behavior. Because google now forces all search traffic to be SSL, it has made attempting to track down the supposed "bad traffic" extremely difficult. We have contacted google through several channels and no one at google who we've worked with is able to provide us any factual examples of what they are seeing and because of the traffic being encrypted all our usual capture and analysis tools have been fairly useless. I'm sure this this will be more and more prevalent but its really frustrating when the vendor who forces SSL cannot or will not provide actual documentation that can help us investigate. So far the only ideas we've come up with are to play some tricks with DNS overrides and force the users to non SSL search so we can inspect http traffic or we were also looking into doing something like using SQUID mitm SSL and allow us to at least inspect the traffic there. Overall we're not thrilled about the other side effects / implications that can be caused by these workarounds, and in this situation our customer who happens to be a customer of several google apps is very disappointed that they cannot be more cooperative. I am very interested to hear if others have run into similar situations and how it was handled etc. I am sure we will see this type of issue again with the number of hosted and SaaS solutions growing exponentially, so we are looking into various options so that in the future we have better accomodations to handle this situation with or without cooperation on the hosted side. chris On Sun, Jan 18, 2015 at 7:29 AM, Grant Ridder wrote: > Hi Everyone, > > I wanted to see what opinions and thoughts were out there. What software, > appliances, or services are being used to monitor web traffic for > "inappropriate" content on the SSL side of things? personal use? > enterprise enterprise? > > It looks like Websense might do decryption ( > http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does > some sort of session hijack to redirect to non-ssl (atleast for Google) ( > https://twitter.com/CovenantEyes/status/451382865914105856). > > Thoughts on having a product that decrypts SSL traffic internally vs one > that doesn't allow SSL to start with? > > -Grant > From bill at herrin.us Sun Jan 18 17:35:02 2015 From: bill at herrin.us (William Herrin) Date: Sun, 18 Jan 2015 12:35:02 -0500 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: On Sun, Jan 18, 2015 at 7:29 AM, Grant Ridder wrote: > I wanted to see what opinions and thoughts were out there. What software, > appliances, or services are being used to monitor web traffic for > "inappropriate" content on the SSL side of things? personal use? > enterprise enterprise? Hi Grant, Fidelis Security (part of GD) does this for USG customers. Good guys with a strong, scalable product. http://www.fidelissecurity.com/ Basically, all internal web browsers get a custom CA which authenticates a re-signing cert. HTTPS traffic is decrypted by an IDS agent, examined and then re-encrypted with the resigning cert. You have to decide for yourself whether you really want to examine your users' HTTPS traffic. It does create a rather hostile work environment for the folks you're playing big brother to. Not quite camera-in-the-men's-room hostile but hostile enough to deter quality staff from seeking and maintaining employment. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From cb.list6 at gmail.com Sun Jan 18 17:41:13 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 18 Jan 2015 09:41:13 -0800 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <63418E02-F95D-4331-B56C-E64A52FC36E1@fastreturn.net> References: <63418E02-F95D-4331-B56C-E64A52FC36E1@fastreturn.net> Message-ID: On Sunday, January 18, 2015, Ammar Zuberi wrote: > So your idea is to block every HTTPS website? > > My idea is to provide secure internet and tell the truth about it. Proxying And mitm SSL/TLS is telling a lie to the end user and exposing them and the proxying organization to a great deal of liability. If you cannot provide proper transport of TLS/SSL, then tell your users that. Dont fake it and undermine the ecosystem. Proxying secure traffic is extremely dangerous, you are pretty much creating trap door in the bank vault. It is going to hurt when the hackers find it and you are going to Be liable for undermining all the secure communications for all your users. Your call. Ymmv. May be you are especially lucky and the hackers wont find this weak spot in your network where all the most important encrypted info (Perosal and corporate) suddenly becomes clear text. My advice, dont do mitm, you cant afford it. It is only a matter of Time when the hackers get this info and steal the identity And drain the bank accounts of all your users. > > > On 18 Jan 2015, at 6:48 pm, Ca By > > wrote: > > > >> On Sunday, January 18, 2015, Grant Ridder > wrote: > >> > >> Hi Everyone, > >> > >> I wanted to see what opinions and thoughts were out there. What > software, > >> appliances, or services are being used to monitor web traffic for > >> "inappropriate" content on the SSL side of things? personal use? > >> enterprise enterprise? > >> > >> It looks like Websense might do decryption ( > >> http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes > does > >> some sort of session hijack to redirect to non-ssl (atleast for Google) > ( > >> https://twitter.com/CovenantEyes/status/451382865914105856). > >> > >> Thoughts on having a product that decrypts SSL traffic internally vs one > >> that doesn't allow SSL to start with? > >> > >> -Grant > > > > IMHO, it would be better to just block the service and say the encrypted > > traffic is inconsistent with your policy instead of snooping it and > > exposing sensitive data to your middle box. > > > > These boxes that violate end to end encryption are a great place for > > hackers to steal the bank and identity info of everyone in your company. > > > > That sounds like a lot liablity to put on your shoulders. > > > > CB > From johnl at iecc.com Sun Jan 18 18:15:09 2015 From: johnl at iecc.com (John Levine) Date: 18 Jan 2015 18:15:09 -0000 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <54BBD015.3070001@jack.fr.eu.org> Message-ID: <20150118181509.24102.qmail@ary.lan> >> So your idea is to block every HTTPS website? >From my point of view, it is better than violate user privacy & safety. > >Sneaky is evil. I expect your users would fire you when they found you'd blocked access to Google. >>> These boxes that violate end to end encryption are a great place for >>> hackers to steal the bank and identity info of everyone in your company. Since the end user machines are generally running Windows, why would bad guys waste time on a much harder and more obscure target? From cb.list6 at gmail.com Sun Jan 18 18:29:05 2015 From: cb.list6 at gmail.com (Ca By) Date: Sun, 18 Jan 2015 10:29:05 -0800 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <20150118181509.24102.qmail@ary.lan> References: <54BBD015.3070001@jack.fr.eu.org> <20150118181509.24102.qmail@ary.lan> Message-ID: On Sunday, January 18, 2015, John Levine wrote: > >> So your idea is to block every HTTPS website? > >From my point of view, it is better than violate user privacy & safety. > > > >Sneaky is evil. > > I expect your users would fire you when they found you'd blocked access to > Google. > > And they would sue you for gross negligence for decrypting their ssn when access company payroll and cpni data >>> These boxes that violate end to end encryption are a great place for > >>> hackers to steal the bank and identity info of everyone in your > company. > > Since the end user machines are generally running Windows, why would bad > guys > waste time on a much harder and more obscure target? > > Who said the mitm box was not running windows ? That said, a properly admin'd win7 box is about as secure as any other end station in my opinion. Yea, win2k and xp were a pain, msft has come a long long way. The same cannot be said for Adobe or Java. CB From wwaites at tardis.ed.ac.uk Sun Jan 18 18:31:19 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sun, 18 Jan 2015 18:31:19 +0000 (GMT) Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <20150118181509.24102.qmail@ary.lan> References: <54BBD015.3070001@jack.fr.eu.org> <20150118181509.24102.qmail@ary.lan> Message-ID: <20150118.183119.1694097476080201717.wwaites@tardis.ed.ac.uk> On 18 Jan 2015 18:15:09 -0000, "John Levine" said: > I expect your users would fire you when they found you'd blocked > access to Google. Doesn't goog do certificate pinning anyways, at least in their web browser? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From teleric-lists at outlook.com Sun Jan 18 18:41:22 2015 From: teleric-lists at outlook.com (Teleric Team) Date: Sun, 18 Jan 2015 13:41:22 -0500 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: Honestly, don't do this. Neither option.You can still have some control over SSL access with ordinary domain based filtering getting proxied, via CONNECT method or sorta. You don't need filtering capabilities over full POST/DELETE/UPDATE HTTP methods, and if you believe you need it, you just have a bigger problem that MITMing won't solve at all. It's just like believing a data leak prevention system will really prevent data leaking. Or believing a Palo Alto NGFW policy that allows gmail but won't allow gmail attachments of mime-type XYZ will be effective. If someone is really interested, there are clever ways to bypass it, more clever than your options to filter it. Forcing http fallback for https communication is not only wrong, it's a general regression regarding security policy and best practices. You are risking privacy, or "confidentiality" and "integrity" if you prefer 27002 buzzwords. Not to mention the "availability" breakage since many applications won't just work (aka, you will break 'em). On the other hand, adding a MITM strategy, be using Squid, Fortinet, pfSense, Palo Alto, Sonicwall, EndianFW, is just worse. You are adding you own an attack vector on your company. You are doing the difficult part of the attack for the attacker, installing a custom root cert in your client stations. So you will have much more to worry about, from "who has access", "how vulnerable" and "how to deploy" until "what is deployed", "what is revogated", "how's renegotiation, CRIME, etc like". You will have more problem root and vectors to care about. Not only how safe is the remote destination SSL server, but how save is the client to local proxy doing MITM and local proxy doing MITM to remote SSL server. You are attacking, cracking and breaking your own network. If someone raise your squid log levels, you will have to respond for that, and respond for what was copied before you noticed it. Same goes for Fortinet, Websense, Sonicwall, or whatever open source or proprietary solution you pick. You are still breaking "confidentiality" and "integrity" but now without allowing for ordinary users or applications to notice it. Back to the beginning: you can still do some level of HTTPS filtering and per domain controlling without having to fully MITM and inspect the payload. Don't add OWASP Top 10 / SANS Top 25 facilitation vectors to your company. Do the usual limited but still "safe" (oh no, not counting that unknown openssl zero-day NSA and people on IRC know about but industry stills ignore, or any other conspirator theory/fact), filtering... do just whatever can be filtered without MITMing https and HTTP redirection. And don't be seduced by the possibility of filtering more than that. It's a trap, for both your users and your responsibilities as organization regarding users' privacy not to mention possible ACTs and other laws on your state/contry. > Date: Sun, 18 Jan 2015 04:29:56 -0800 > Subject: HTTPS redirects to HTTP for monitoring > From: shortdudey123 at gmail.com > To: nanog at nanog.org > > Hi Everyone, > > I wanted to see what opinions and thoughts were out there. What software, > appliances, or services are being used to monitor web traffic for > "inappropriate" content on the SSL side of things? personal use? > enterprise enterprise? > > It looks like Websense might do decryption ( > http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does > some sort of session hijack to redirect to non-ssl (atleast for Google) ( > https://twitter.com/CovenantEyes/status/451382865914105856). > > Thoughts on having a product that decrypts SSL traffic internally vs one > that doesn't allow SSL to start with? > > -Grant From johnl at iecc.com Sun Jan 18 18:55:02 2015 From: johnl at iecc.com (John R. Levine) Date: 18 Jan 2015 13:55:02 -0500 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: <54BBD015.3070001@jack.fr.eu.org> <20150118181509.24102.qmail@ary.lan> Message-ID: >> I expect your users would fire you when they found you'd blocked access to >> Google. >> > And they would sue you for gross negligence for decrypting their ssn when > access company payroll and cpni data May I suggest that playing Junior Lawyer on nanog rarely turns out well. These filter boxes are typically used on private enterprise networks. Companies have broad latitude in what facilities they provide to their users, and the rationales for filtering run from keeping out malware to keeping dimwit guys from porn sites that are fodder for hostile work environment claims. Your employer alrady knows your SSN and payroll data. Unless, I suppose, you're using your computer at one job to moonlight at another, but you're not going to get a lot of sympathy for that. There are also ISPs that provide intrusive filtering as a feature. I wouldn't use one, but I know people who do, typically members of conservative religious groups. R's, John From Kelly.Setzer at wnco.com Sun Jan 18 20:05:18 2015 From: Kelly.Setzer at wnco.com (Kelly Setzer) Date: Sun, 18 Jan 2015 20:05:18 +0000 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <20150118.183119.1694097476080201717.wwaites@tardis.ed.ac.uk> References: <54BBD015.3070001@jack.fr.eu.org> <20150118181509.24102.qmail@ary.lan> <20150118.183119.1694097476080201717.wwaites@tardis.ed.ac.uk> Message-ID: I don't know if you're referring to HSTS. If not, it's worth noting in this thread. As I understand HSTS, session decryption is still possible on sites that send the 'Strict-Transport-Security' header. See: https://tools.ietf.org/html/rfc6797 I suspect it's only a matter of time before browsers become suspicious by default, requiring that HTTPS responses be signed and requiring that SSL certificates come from trusted sources. In other words, HSTS is the next step in a long-running arms race. It will not be the last. See this 1997 article for a taste: http://www.apacheweek.com/features/ssl Money quote: "The US Government imposes export restrictions on arms, in a set of rules called ITAR" All of this points to the deficiency of the existing commercial certificate authority system. The fact that organizations can easily purchase software specifically designed to subvert encrypted communication channels is proof that HTTPS security is an illusion. Kelly On 1/18/15, 12:31 PM, "William Waites" wrote: >On 18 Jan 2015 18:15:09 -0000, "John Levine" said: > > > I expect your users would fire you when they found you'd blocked > > access to Google. > >Doesn't goog do certificate pinning anyways, at least in their web >browser? ******* CONFIDENTIALITY NOTICE ******* This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. From geoffk at geoffk.org Sun Jan 18 20:49:10 2015 From: geoffk at geoffk.org (Geoffrey Keating) Date: 18 Jan 2015 12:49:10 -0800 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: chris writes: > I have been going through something very interesting recently that relates > to this. We have a customer who google is flagging for "abusive" search > behavior. Because google now forces all search traffic to be SSL, it has > made attempting to track down the supposed "bad traffic" extremely > difficult. We have contacted google through several channels and no one at > google who we've worked with is able to provide us any factual examples of > what they are seeing and because of the traffic being encrypted all our > usual capture and analysis tools have been fairly useless. I presume the problem is that Google has flagged the outgoing address on your NAT, because that's all they can see. Have you considered deploying IPv6 and giving each customer their own address? Then only that customer will be flagged and it'll be between them and Google. From mpalmer at hezmatt.org Sun Jan 18 23:02:48 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 19 Jan 2015 10:02:48 +1100 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: <54BBD015.3070001@jack.fr.eu.org> <20150118181509.24102.qmail@ary.lan> <20150118.183119.1694097476080201717.wwaites@tardis.ed.ac.uk> Message-ID: <20150118230248.GO3352@hezmatt.org> On Sun, Jan 18, 2015 at 08:05:18PM +0000, Kelly Setzer wrote: > I don't know if you're referring to HSTS. No, HSTS is separate to certificate pinning. Certificate pinning would, in fact, cause Chrome to freak out in the presence of an HTTPS-intercepting proxy, but that's what it's supposed to do. I doubt that organisations regressive enough to do HTTPS-MitM would be enlightened enough to allow Chrome to be installed, though. > If not, it's worth noting in > this thread. As I understand HSTS, session decryption is still possible > on sites that send the 'Strict-Transport-Security' header. See: > https://tools.ietf.org/html/rfc6797 Yes, HSTS allows interception; it would, on the other hand, prevent the downgrade attack which the OP was suggesting as one option to allow organisational monitoring of web requests and responses. > I suspect it's only a matter of time before browsers become suspicious by > default, requiring that HTTPS responses be signed and requiring that SSL > certificates come from trusted sources. That sounds like what has been the case since... forever. > All of this points to the deficiency of the existing commercial > certificate authority system. The fact that organizations can easily > purchase software specifically designed to subvert encrypted communication > channels is proof that HTTPS security is an illusion. What does the existence of a HTTPS proxy have to do with the deficiency of existing CAs? Yes, CAs have issued intermediate CA certificates to MitM boxes (Trustwave has been caught doing it; I'm sure others have done it, too). However, the standard mechanism for doing this sort of thing is a locally-issued root CA certificate, which is installed in the corporate SOE as a trusted root. That is, actually, *exactly* how the TLS certificate system is supposed to work -- root CA certificate is marked as trusted, thus everything issued therefrom is considered OK. That this is possible is not "proof that HTTPS security is an illusion"; it's simply another demonstration that if the bad guy has control over your machine, it isn't your machine any more. If TLS wasn't vulnerable to this particular mode of subversion, I'm sure there'd be products out there that would hook into the core of the browser and grab the requests before they got into the encrypted channel and re-route them to the proxy, and it would be that software, rather than the local root CA certificate, which would be installed in the corporate SOE. - Matt From patrick at ianai.net Mon Jan 19 05:09:33 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 19 Jan 2015 00:09:33 -0500 Subject: Peering Track for NANOG 63 Message-ID: Everyone: I have been asked to moderate the Peering Track for NANOG 63. Time is short, and I need to fill a couple hours. If you have interesting ideas on how to do it, or better yet, would like to present something yourself, please ping me off-list. See you San Antonio! -- TTFN, patrick From larrysheldon at cox.net Mon Jan 19 09:01:14 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 19 Jan 2015 03:01:14 -0600 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: Message-ID: <54BCC7DA.7050508@cox.net> On 1/18/2015 12:41, Teleric Team wrote: > Honestly, don't do this. Neither option.You can still have some > control over SSL access with ordinary domain based filtering getting > proxied, via CONNECT method or sorta. You don't need filtering > capabilities over full POST/DELETE/UPDATE HTTP methods, and if you > believe you need it, you just have a bigger problem that MITMing > won't solve at all. It's just like believing a data leak prevention > system will really prevent data leaking. Or believing a Palo Alto > NGFW policy that allows gmail but won't allow gmail attachments of > mime-type XYZ will be effective. If someone is really interested, > there are clever ways to bypass it, more clever than your options to > filter it. Forcing http fallback for https communication is not only > wrong, it's a general regression regarding security policy and best > practices. You are risking privacy, or "confidentiality" and > "integrity" if you prefer 27002 buzzwords. Not to mention the > "availability" breakage since many applications won't just work (aka, > you will break 'em). On the other hand, adding a MITM strategy, be > using Squid, Fortinet, pfSense, Palo Alto, Sonicwall, EndianFW, is > just worse. You are adding you own an attack vector on your company. > You are doing the difficult part of the attack for the attacker, > installing a custom root cert in your client stations. So you will > have much more to worry about, from "who has access", "how > vulnerable" and "how to deploy" until "what is deployed", "what is > revogated", "how's renegotiation, CRIME, etc like". You will have > more problem root and vectors to care about. Not only how safe is the > remote destination SSL server, but how save is the client to local > proxy doing MITM and local proxy doing MITM to remote SSL server. You > are attacking, cracking and breaking your own network. If someone > raise your squid log levels, you will have to respond for that, and > respond for what was copied before you noticed it. Same goes for > Fortinet, Websense, Sonicwall, or whatever open source or proprietary > solution you pick. You are still breaking "confidentiality" and > "integrity" but now without allowing for ordinary users or > applications to notice it. Back to the beginning: you can still do > some level of HTTPS filtering and per domain controlling without > having to fully MITM and inspect the payload. Don't add OWASP Top 10 > / SANS Top 25 facilitation vectors to your company. Do the usual > limited but still "safe" (oh no, not counting that unknown openssl > zero-day NSA and people on IRC know about but industry stills ignore, > or any other conspirator theory/fact), filtering... do just whatever > can be filtered without MITMing https and HTTP redirection. And don't > be seduced by the possibility of filtering more than that. It's a > trap, for both your users and your responsibilities as organization > regarding users' privacy not to mention possible ACTs and other laws > on your state/contry. > > >> Date: Sun, 18 Jan 2015 04:29:56 -0800 Subject: HTTPS redirects to >> HTTP for monitoring From: shortdudey123 at gmail.com To: >> nanog at nanog.org >> >> Hi Everyone, >> >> I wanted to see what opinions and thoughts were out there. What >> software, appliances, or services are being used to monitor web >> traffic for "inappropriate" content on the SSL side of things? >> personal use? enterprise enterprise? >> >> It looks like Websense might do decryption ( >> http://community.websense.com/forums/t/3146.aspx) while Covenant >> Eyes does some sort of session hijack to redirect to non-ssl >> (atleast for Google) ( >> https://twitter.com/CovenantEyes/status/451382865914105856). >> >> Thoughts on having a product that decrypts SSL traffic internally >> vs one that doesn't allow SSL to start with? >> >> -Grant I have been "off-line" for several days and I have to say that this is one of the most depressing thread I have seen _anywhere_ in a while and reading it on NANOG multiplies the depression. But I am heartened to see this response (and one or two others so far)--there is still hope. For what it is worth (and this reflects at most two people's thinking here), I go to some considerable effort to identify handlers-of-my-data that betray my trust and on the merest hint I take considerable effort the avoid the betrayer and anybody who relies on the betrayer. Yes, I know that there is no way that I can stop everybody, but I try very hard. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Mon Jan 19 09:06:44 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 19 Jan 2015 03:06:44 -0600 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: References: <54BBD015.3070001@jack.fr.eu.org> <20150118181509.24102.qmail@ary.lan> Message-ID: <54BCC924.1000104@cox.net> On 1/18/2015 12:55, John R. Levine wrote: > There are also ISPs that provide intrusive filtering as a feature. I > wouldn't use one, but I know people who do, typically members of > conservative religious groups. Can you provide credible evidence to support "typically members of > conservative religious groups."? Please explain how that contributes to the question at hand. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From md at bts.sk Mon Jan 19 10:12:28 2015 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Mon, 19 Jan 2015 11:12:28 +0100 Subject: Recommended L2 switches for a new IXP In-Reply-To: <20150117191504.GA17079@pob.ytti.fi> References: <20150117110233.GA88590@bts.sk> <20150117191504.GA17079@pob.ytti.fi> Message-ID: <20150119101228.GA19486@bts.sk> On Sat, Jan 17, 2015 at 09:15:04PM +0200, Saku Ytti wrote: > On (2015-01-17 12:02 +0100), Marian Ďurkovič wrote: > > > Our experience after 100 days of production is only the best - TRILL setup > > is pretty straightforward and thanks to IS-IS it provides shortest-path > > IP-like "routing" for L2 ethernet packets over any reasonable topology > > out of the box (without the burden and cost implications of VPLS). > > I'm not sure what the burden refers to, but cost implications to me seem same, > trident HW can do VPLS. Well, it can, but as usual the devil is in the detail. For example, loadbalancing on outgoing LAGs depends on *inbound* packet encapsulation as follows: - native ethernet, TRILL, L3 MPLS : hash based on L3 and L4 headers - L2 MPLS, MACinMAC : hash based on L2 headers only. Thus if you use VPLS or SPB-M on Trident HW, the egress PE doesn't support per-flow loadbalancing on IXP participants' LAGs. In any case, we preferred TRILL over SPB-M not just because of that, but mainly due to a fact that TRILL provides real routing using IS-IS as we know it from IP world, while SPB still builds on top of MST and just cleverly uses multiple trees. Yes, compatibility with existing ASICs was one of the main design goals of SPB, but that's irrelevant once you have Trident HW. Regards, M. From nick at foobar.org Mon Jan 19 11:29:45 2015 From: nick at foobar.org (Nick Hilliard) Date: Mon, 19 Jan 2015 11:29:45 +0000 Subject: Recommended L2 switches for a new IXP In-Reply-To: <20150119101228.GA19486@bts.sk> References: <20150117110233.GA88590@bts.sk> <20150117191504.GA17079@pob.ytti.fi> <20150119101228.GA19486@bts.sk> Message-ID: <54BCEAA9.5000302@foobar.org> On 19/01/2015 10:12, Marian Ďurkovič wrote: > Thus if you use VPLS or SPB-M on Trident HW, the egress PE doesn't support > per-flow loadbalancing on IXP participants' LAGs. not completely true. Extreme XOS has an interesting hack to work around this. Nick From colton.conor at gmail.com Mon Jan 19 19:09:00 2015 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 19 Jan 2015 13:09:00 -0600 Subject: VDSL CPE Mixed Results In-Reply-To: <1421245763.3821.2.camel@stets.datayard.local> References: <1421245763.3821.2.camel@stets.datayard.local> Message-ID: So with this 3 line connection, what speeds up and down are you getting? You say 10X10 which I find odd for a 3 line bonded VDSL2 connection. Most always your downstream will be much higher than your upstream on a 868 unit. On Wed, Jan 14, 2015 at 8:29 AM, Stetson Blake < Stetson.Blake at datayardworks.com> wrote: > Hey All, > > We have been deploying Adtran 838(shdsl) and 868(dsl) units in our metro > area with mixed results. The devices themselves are reliable and secure > it would seem, but the speeds were are able to get are not. ie. we have > deployed 'vdsl' and needed 3 lines to get up to 10x10 speeds. We are > using an Adtran TA5000 on the other end to terminate our connections. > The distance between the site and CO is not great (under 6k feet). What > gives? Are we provisioning wrong, using the wrong equipment, or a > combination of both? > If we were able to get the speeds others have been reporting from VDSL, > life would be great. > Anyone feel free to contact me off-list or on, this has had me > scratching my head for a while now. > > Thanks, > > -- > Stetson Blake > Network Technician > DataYard > 130 West Second St. > Suite 250 > Dayton, OH 45402 > > http://datayardworks.com > > > > > > From lyle at lcrcomputer.net Mon Jan 19 20:28:22 2015 From: lyle at lcrcomputer.net (Lyle Giese) Date: Mon, 19 Jan 2015 14:28:22 -0600 Subject: Gmail admin help requested In-Reply-To: <54BD6878.3070801@lcrcomputer.net> References: <54BD6878.3070801@lcrcomputer.net> Message-ID: <54BD68E6.70200@lcrcomputer.net> I have discovered that some emails are disappearing inside gmail. I have logs of one such email that disappeared. It shows the 250 reply from google, but email doesn't get to inbox or spam filter. Looking for assistance from Gmail. Thanks, Lyle Giese LCR Computer Services, Inc. From johnl at iecc.com Mon Jan 19 21:51:16 2015 From: johnl at iecc.com (John Levine) Date: 19 Jan 2015 21:51:16 -0000 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <54BCC924.1000104@cox.net> Message-ID: <20150119215116.2362.qmail@ary.lan> In article <54BCC924.1000104 at cox.net> you write: >On 1/18/2015 12:55, John R. Levine wrote: >> There are also ISPs that provide intrusive filtering as a feature. I >> wouldn't use one, but I know people who do, typically members of >> conservative religious groups. > >Can you provide credible evidence to support "typically members of > > conservative religious groups."? I personally have known people who use them. If you're familar with some of the books that I've written, it should be evident why I'd need to know about them and who they'd appeal to. In any event, as should be totally obvious, the point was that there are people who for their own reasons welcome intrusive filtering that most of us would find unacceptable. R's, John From johnl at iecc.com Mon Jan 19 21:56:04 2015 From: johnl at iecc.com (John Levine) Date: 19 Jan 2015 21:56:04 -0000 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <54BBC0C8.4010803@mbrez.com> Message-ID: <20150119215604.2397.qmail@ary.lan> >We use Fortinet firewalls and SSL (HTTPS, FTPS, IMAPS, POP3S, SMTPS, >SSH) inspection is a standard feature. It works by rolling out a custom >CA certificate from the device to all of the desktops and whenever you >hit a SSL site, a cert signed with the CA is generated and presented to >the user. If you look at the cert your browser has, you can tell the CA >is different but most users aren't looking at that. By the way, I hope that all of the people who have been ranting about this have read this note. The only way this filtering works is if the client computers have a special CA cert installed into their browsers. That means it's a private organizational network that manages all its client computers, or it's a service where the users specifically do something on their own computers to enable it. It may not be a very good idea, but it's definitely not evil people secretly spying on traffic of innocent victims. R's, John From glen.kent at gmail.com Mon Jan 19 22:01:40 2015 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 20 Jan 2015 03:31:40 +0530 Subject: link monitoring and BFD in SDN networks Message-ID: Hi, Routers connected back to back often rely on BFD for link failures. Its certainly possible that there is a switch between two routers and hence a link down event on one side is not visible to the other side. So, you run some sort of an OAM protocol on the two routers so that they can detect link flaps/failures. How will this happen in SDN networks where there is no control plane on the routers. Will the routers be sending a state of all their links to a central controller who will then detect that a link has gone down. This just doesnt sound good. I am presuming that some sort of "control plane" will always be required. Any pointers here? Is there any other reason other than link events for which we would need a control plane on the routers in SDN? Thanks, Glen From michael.holstein at csuohio.edu Mon Jan 19 22:10:53 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Mon, 19 Jan 2015 22:10:53 +0000 Subject: gamer "lag" dashboard Message-ID: <1421705578413.91196@csuohio.edu> ?Can someone point me in the right direction for something that allows creation of a "dashboard" with current and statistical latency to the various game servers (PC, Xbox, PS4, etc) ? .. I'm in the education space and we get lots of questions/complains about this and would like a way to make the stats public. I could roll something with RRD and Smokeping but with all the packet-shaping crapola (including that which we use here) I need something that emulates the actual game traffic as would be classified by all the network crap that endeavors to mess with it. (not intended to be an argument about QoS and prioritization, responses addressing either --or the politics thereof-- really aren't helpful). TIA, Michael Holstein Network & Data Security Cleveland State University From me at geordish.org Mon Jan 19 22:55:04 2015 From: me at geordish.org (Dave Bell) Date: Mon, 19 Jan 2015 22:55:04 +0000 Subject: link monitoring and BFD in SDN networks In-Reply-To: References: Message-ID: BFD etc aim to prove there is end-to-end connectivity between two points, not just that all links are up along the path. All ports could be up, but end-to-end connectivity broken, for example a misconfigured VLAN across a L2 network. Sending some kind of packet across the network is pretty much the only way to guarantee reachability. The OpenFlow protocol in particular has a way to instruct a switch to send a frame out of an interface. By default, the OpenFlow switches will forward all frames it has received and doesn't know what to do with back to the controller. This means someone could write an OAM protocol that will work via OpenFlow. A quick google for 'OpenFlow OAM' brought me this link which has someone who has done just that: "http://www.rvdp.org/presentations/SC11-SRS-8021ag.pdf" Of course if you want fast failover, you need to send packets very rapidly. Every 250ms is not unreasonable. This is going to cause the control plane to get very chatty. Typically on high end routers, processes such as BFD are actually ran on line cards as opposed to on the routing engine. When a failure is detected this reports up into the control plane to trigger a reconvergence event. I see no reason why this couldn't occur using SDN. Regards, Dave On 19 January 2015 at 22:01, Glen Kent wrote: > Hi, > > Routers connected back to back often rely on BFD for link failures. Its > certainly possible that there is a switch between two routers and hence a > link down event on one side is not visible to the other side. So, you run > some sort of an OAM protocol on the two routers so that they can detect > link flaps/failures. > > How will this happen in SDN networks where there is no control plane on the > routers. Will the routers be sending a state of all their links to a > central controller who will then detect that a link has gone down. This > just doesnt sound good. I am presuming that some sort of "control plane" > will always be required. > > Any pointers here? > > Is there any other reason other than link events for which we would need a > control plane on the routers in SDN? > > Thanks, > Glen From tfarrell at riotgames.com Mon Jan 19 23:07:21 2015 From: tfarrell at riotgames.com (Trent Farrell) Date: Mon, 19 Jan 2015 15:07:21 -0800 Subject: gamer "lag" dashboard In-Reply-To: <1421705578413.91196@csuohio.edu> References: <1421705578413.91196@csuohio.edu> Message-ID: Hi Michael, I don't have a direct answer to your question, nor can I speak for other gaming companies, but I can certainly work with you off-list on ways to monitor connectivity and performance to our game, "League of Legends". Hopefully also find some ways to optimise routing between our networks. Happy to assist any other network also - it's great to see gaming appearing on more and more radars. On Mon, Jan 19, 2015 at 2:10 PM, Michael O Holstein < michael.holstein at csuohio.edu> wrote: > ?Can someone point me in the right direction for something that allows > creation of a "dashboard" with current and statistical latency to the > various game servers (PC, Xbox, PS4, etc) ? .. I'm in the education space > and we get lots of questions/complains about this and would like a way to > make the stats public. > > > I could roll something with RRD and Smokeping but with all the > packet-shaping crapola (including that which we use here) I need something > that emulates the actual game traffic as would be classified by all the > network crap that endeavors to mess with it. > > > (not intended to be an argument about QoS and prioritization, responses > addressing either --or the politics thereof-- really aren't helpful). > > > TIA, > > > Michael Holstein > > Network & Data Security > > Cleveland State University > -- *tf* From george.herbert at gmail.com Mon Jan 19 23:16:43 2015 From: george.herbert at gmail.com (George Herbert) Date: Mon, 19 Jan 2015 15:16:43 -0800 Subject: gamer "lag" dashboard In-Reply-To: <1421705578413.91196@csuohio.edu> References: <1421705578413.91196@csuohio.edu> Message-ID: <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> Emulating game traffic... Good luck with that. You'll probably have to figure it out and build your own models per service, though a lot is encapsulated in https. In terms of showing it to the public, look at Zabbix and Zenoss; both do dashboards and managing multiple realtime monitoring / performance info feeds well. George William Herbert Sent from my iPhone > On Jan 19, 2015, at 2:10 PM, Michael O Holstein wrote: > > ?Can someone point me in the right direction for something that allows creation of a "dashboard" with current and statistical latency to the various game servers (PC, Xbox, PS4, etc) ? .. I'm in the education space and we get lots of questions/complains about this and would like a way to make the stats public. > > > I could roll something with RRD and Smokeping but with all the packet-shaping crapola (including that which we use here) I need something that emulates the actual game traffic as would be classified by all the network crap that endeavors to mess with it. > > > (not intended to be an argument about QoS and prioritization, responses addressing either --or the politics thereof-- really aren't helpful). > > > TIA, > > > Michael Holstein > > Network & Data Security > > Cleveland State University From josh at imaginenetworksllc.com Mon Jan 19 23:18:38 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 19 Jan 2015 18:18:38 -0500 Subject: gamer "lag" dashboard In-Reply-To: <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> References: <1421705578413.91196@csuohio.edu> <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> Message-ID: IXIA would be the first product to look at as far as emulating traffic. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Jan 19, 2015 at 6:16 PM, George Herbert wrote: > Emulating game traffic... Good luck with that. You'll probably have to > figure it out and build your own models per service, though a lot is > encapsulated in https. > > In terms of showing it to the public, look at Zabbix and Zenoss; both do > dashboards and managing multiple realtime monitoring / performance info > feeds well. > > George William Herbert > Sent from my iPhone > > > On Jan 19, 2015, at 2:10 PM, Michael O Holstein < > michael.holstein at csuohio.edu> wrote: > > > > ?Can someone point me in the right direction for something that allows > creation of a "dashboard" with current and statistical latency to the > various game servers (PC, Xbox, PS4, etc) ? .. I'm in the education space > and we get lots of questions/complains about this and would like a way to > make the stats public. > > > > > > I could roll something with RRD and Smokeping but with all the > packet-shaping crapola (including that which we use here) I need something > that emulates the actual game traffic as would be classified by all the > network crap that endeavors to mess with it. > > > > > > (not intended to be an argument about QoS and prioritization, responses > addressing either --or the politics thereof-- really aren't helpful). > > > > > > TIA, > > > > > > Michael Holstein > > > > Network & Data Security > > > > Cleveland State University > From damian at google.com Mon Jan 19 23:47:40 2015 From: damian at google.com (Damian Menscher) Date: Mon, 19 Jan 2015 15:47:40 -0800 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <20150118.183119.1694097476080201717.wwaites@tardis.ed.ac.uk> References: <54BBD015.3070001@jack.fr.eu.org> <20150118181509.24102.qmail@ary.lan> <20150118.183119.1694097476080201717.wwaites@tardis.ed.ac.uk> Message-ID: On Sun, Jan 18, 2015 at 4:29 AM, Grant Ridder wrote: > It looks like Websense might do decryption ( > http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes > does some sort of session hijack to redirect to non-ssl (atleast for > Google) (https://twitter.com/CovenantEyes/status/451382865914105856). > The ssl opt-out has been deprecated (not sure if it's fully disabled yet): http://googleonlinesecurity.blogspot.com/2014/10/an-update-to-safesearch-options-for.html If you need to disallow adult content, another option is described here: https://support.google.com/websearch/answer/186669 On Sun, Jan 18, 2015 at 10:31 AM, William Waites wrote: > On 18 Jan 2015 18:15:09 -0000, "John Levine" said: > > > I expect your users would fire you when they found you'd blocked > > access to Google. > > Doesn't goog do certificate pinning anyways, at least in their web > browser? > User-installed root CAs are allowed to override certificate pins in Chrome. I think a lot of the problem is people have a false expectation of privacy when using their work computers. The legal documents they have you sign on day 1 probably explain that it's their network, their computer, and they will monitor it. If you want privacy, bring your own computer to work (which they probably won't allow on their network...). On Sun, Jan 18, 2015 at 12:49 PM, Geoffrey Keating wrote: > chris writes: > > > I have been going through something very interesting recently that > relates > > to this. We have a customer who google is flagging for "abusive" search > > behavior. Because google now forces all search traffic to be SSL, it has > > made attempting to track down the supposed "bad traffic" extremely > > difficult. We have contacted google through several channels and no one > at > > google who we've worked with is able to provide us any factual examples > of > > what they are seeing and because of the traffic being encrypted all our > > usual capture and analysis tools have been fairly useless. > > I presume the problem is that Google has flagged the outgoing address > on your NAT, because that's all they can see. > Yup, exactly. Additionally, Google's privacy policies don't allow us to provide the evidence of abuse. Not that the evidence would help anyway, since the searches are encrypted.... Have you considered deploying IPv6 and giving each customer their own > address? Then only that customer will be flagged and it'll be between > them and Google. This is probably the best option. I realize it's not a trivial change so we try to help where we can, but in most cases there's not much information we can provide that would be helpful in tracing the abuse. Damian From rdobbins at arbor.net Tue Jan 20 01:22:36 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 20 Jan 2015 08:22:36 +0700 Subject: gamer "lag" dashboard In-Reply-To: <1421705578413.91196@csuohio.edu> References: <1421705578413.91196@csuohio.edu> Message-ID: On 20 Jan 2015, at 5:10, Michael O Holstein wrote: > I need something that emulates the actual game traffic as would be > classified by all the network crap that endeavors to mess with it. That sounds like a great open-source project - let us know when you're done! ;> ----------------------------------- Roland Dobbins From bedard.phil at gmail.com Tue Jan 20 02:37:35 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Mon, 19 Jan 2015 21:37:35 -0500 Subject: Recommended L2 switches for a new IXP In-Reply-To: <20150117191504.GA17079@pob.ytti.fi> References: <20150117110233.GA88590@bts.sk> <20150117191504.GA17079@pob.ytti.fi> Message-ID: <6DB700CF-CFEB-4623-92B8-3C4BCB1CA6A7@gmail.com> On 1/17/15, 7:15 PM, "Saku Ytti" wrote: >On (2015-01-17 12:02 +0100), Marian Ďurkovič wrote: > >> Our experience after 100 days of production is only the best - TRILL >>setup >> is pretty straightforward and thanks to IS-IS it provides shortest-path >> IP-like "routing" for L2 ethernet packets over any reasonable topology >> out of the box (without the burden and cost implications of VPLS). > >I'm not sure what the burden refers to, but cost implications to me seem >same, >trident HW can do VPLS. >From complexity POV, I don't expect much different development time to >write >functioning control-plane to either. > >I'm not against Trill, I think Trill, and especially SPB-M are great, now >they >just feel too little and 20 years too late. There was no particular >reason why >SPB-M couldn't have existed 20 years ago in HW. But perhaps it's good it >didn't, it might have made ethernet 'good enough', that selling MPLS might >have been much more difficult. > >-- > ++ytti I think in fairly short order both TRILL and 802.1AQ will be depercated in place of VXLAN and using BGP EVPN as the control plane ala Juniper QFX5100/Nexus 9300. Phil From charles at thefnf.org Tue Jan 20 02:56:00 2015 From: charles at thefnf.org (Charles N Wyble) Date: Mon, 19 Jan 2015 20:56:00 -0600 Subject: gamer "lag" dashboard In-Reply-To: <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> References: <1421705578413.91196@csuohio.edu> <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> Message-ID: <4b02227c-e5fa-4f12-bf48-c66bf5736976@email.android.com> SSL is no problem. We just had a whole thread about breaking it. :-) On January 19, 2015 5:16:43 PM CST, George Herbert wrote: >Emulating game traffic... Good luck with that. You'll probably have >to figure it out and build your own models per service, though a lot is >encapsulated in https. > >In terms of showing it to the public, look at Zabbix and Zenoss; both >do dashboards and managing multiple realtime monitoring / performance >info feeds well. > >George William Herbert >Sent from my iPhone > >> On Jan 19, 2015, at 2:10 PM, Michael O Holstein > wrote: >> >> ?Can someone point me in the right direction for something that >allows creation of a "dashboard" with current and statistical latency >to the various game servers (PC, Xbox, PS4, etc) ? .. I'm in the >education space and we get lots of questions/complains about this and >would like a way to make the stats public. >> >> >> I could roll something with RRD and Smokeping but with all the >packet-shaping crapola (including that which we use here) I need >something that emulates the actual game traffic as would be classified >by all the network crap that endeavors to mess with it. >> >> >> (not intended to be an argument about QoS and prioritization, >responses addressing either --or the politics thereof-- really aren't >helpful). >> >> >> TIA, >> >> >> Michael Holstein >> >> Network & Data Security >> >> Cleveland State University > >!DSPAM:54bd909e175152519182214! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From charles at thefnf.org Tue Jan 20 02:54:56 2015 From: charles at thefnf.org (Charles N Wyble) Date: Mon, 19 Jan 2015 20:54:56 -0600 Subject: gamer "lag" dashboard In-Reply-To: References: <1421705578413.91196@csuohio.edu> Message-ID: As a zenoss plugin, I agree. On January 19, 2015 7:22:36 PM CST, Roland Dobbins wrote: > >On 20 Jan 2015, at 5:10, Michael O Holstein wrote: > >> I need something that emulates the actual game traffic as would be >> classified by all the network crap that endeavors to mess with it. > >That sounds like a great open-source project - let us know when you're >done! > >;> > >----------------------------------- >Roland Dobbins > >!DSPAM:54bdae36220661660451680! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From charles at thefnf.org Tue Jan 20 02:54:27 2015 From: charles at thefnf.org (Charles N Wyble) Date: Mon, 19 Jan 2015 20:54:27 -0600 Subject: gamer "lag" dashboard In-Reply-To: References: <1421705578413.91196@csuohio.edu> <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> Message-ID: Ixia is very very expensive and has its own sets of "fun", though it is a nice appliance for playing with packets. Though its more for protocol compliance testing and load generation. You'll find that protocol exploration and... hmmmm... exploitation is an incredibly mature field in floss. https://code.google.com/p/ostinato/ would probably do what you need ( since you'll basically be spending lots of time with pcap capture and replay ). Once you get tired of spending expensive labor time on this project, you can throw some grad students, xboxes and scapy in a room and have them automate the process for you. :-) Also checkout http://www.pcapr.net/home ( specifically pcapr on premise) to manage and analyze captured pcaps. Of course security onion must be considered if you want a more robust capture and management toolkit. Aol wrote something called moloch, that's on my list of tools to play with this year. Wireshark wiki has many other things linked for pcap related play. My $dayjob involves supporting people who do horrible horrible things to packets and tcp stacks for fun and profit. So I've become very proficient with an extensive floss toolkit around this stuff. With a bit of critical thinking and research, you'll be able to devise a strategy that works. Also +1 for Zenoss. That is a fantastic NMS. Written in python, so hooking up scapy to do periodic game latency checks would be slick and a natural fit. On January 19, 2015 5:18:38 PM CST, Josh Luthman wrote: >IXIA would be the first product to look at as far as emulating traffic. > > >Josh Luthman >Office: 937-552-2340 >Direct: 937-552-2343 >1100 Wayne St >Suite 1337 >Troy, OH 45373 > >On Mon, Jan 19, 2015 at 6:16 PM, George Herbert > >wrote: > >> Emulating game traffic... Good luck with that. You'll probably have >to >> figure it out and build your own models per service, though a lot is >> encapsulated in https. >> >> In terms of showing it to the public, look at Zabbix and Zenoss; both >do >> dashboards and managing multiple realtime monitoring / performance >info >> feeds well. >> >> George William Herbert >> Sent from my iPhone >> >> > On Jan 19, 2015, at 2:10 PM, Michael O Holstein < >> michael.holstein at csuohio.edu> wrote: >> > >> > ?Can someone point me in the right direction for something that >allows >> creation of a "dashboard" with current and statistical latency to the >> various game servers (PC, Xbox, PS4, etc) ? .. I'm in the education >space >> and we get lots of questions/complains about this and would like a >way to >> make the stats public. >> > >> > >> > I could roll something with RRD and Smokeping but with all the >> packet-shaping crapola (including that which we use here) I need >something >> that emulates the actual game traffic as would be classified by all >the >> network crap that endeavors to mess with it. >> > >> > >> > (not intended to be an argument about QoS and prioritization, >responses >> addressing either --or the politics thereof-- really aren't helpful). >> > >> > >> > TIA, >> > >> > >> > Michael Holstein >> > >> > Network & Data Security >> > >> > Cleveland State University >> > >!DSPAM:54bd9147175514905077569! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From george.herbert at gmail.com Tue Jan 20 05:04:08 2015 From: george.herbert at gmail.com (George Herbert) Date: Mon, 19 Jan 2015 21:04:08 -0800 Subject: gamer "lag" dashboard In-Reply-To: <4b02227c-e5fa-4f12-bf48-c66bf5736976@email.android.com> References: <1421705578413.91196@csuohio.edu> <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> <4b02227c-e5fa-4f12-bf48-c66bf5736976@email.android.com> Message-ID: Cruel, cruel man. George William Herbert Sent from my iPhone > On Jan 19, 2015, at 6:56 PM, Charles N Wyble wrote: > > SSL is no problem. We just had a whole thread about breaking it. :-) > > >> On January 19, 2015 5:16:43 PM CST, George Herbert wrote: >> Emulating game traffic... Good luck with that. You'll probably have to figure it out and build your own models per service, though a lot is encapsulated in https. >> >> In terms of showing it to the public, look at Zabbix and Zenoss; both do dashboards and managing multiple realtime monitoring / performance info feeds well. >> >> George William Herbert >> Sent from my iPhone >> >>> On Jan 19, 2015, at 2:10 PM, Michael O Holstein wrote: >>> >>> ?Can someone point me in the right direction for something that allows creation of a "dashboard" with current and statistical latency to the various game servers (PC, Xbox, PS4, etc) ? .. I'm in the education space and we get lots of questions/complains about this and would like a way to make the stats public. >>> >>> >>> I could roll >>> something with RRD and Smokeping but with all the packet-shaping crapola (including that which we use here) I need something that emulates the actual game traffic as would be classified by all the network crap that endeavors to mess with it. >>> >>> >>> (not intended to be an argument about QoS and prioritization, responses addressing either --or the politics thereof-- really aren't helpful). >>> >>> >>> TIA, >>> >>> >>> Michael Holstein >>> >>> Network & Data Security >>> >>> Cleveland State University >> >> !DSPAM:54bd909e175152519182214! > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From v.bajpai at jacobs-university.de Mon Jan 19 13:33:57 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Mon, 19 Jan 2015 13:33:57 +0000 Subject: [request]: host a probe for v6 measurements Message-ID: <8B0BCD73-0EC1-462A-A303-6FA710A237DC@jacobs-university.de> Dear NANOG, We are currently looking for volunteers in US with native IPv6 lines to help us in our v6 measurement research. <——------ Background We are interested in measuring IPv6 performance from home. As part of the LEONE project [1], we have developed measurement tests that compare performance over IPv4 and IPv6 to: a) Dual-stacked websites and b) YouTube content delivery network (in collaboration with Aalto University). The tests comes bundled with a LEONE SamKnows probe. [1] http://www.leone-project.eu We currently have ~25 Vantage points (VP). Each VP runs a Leone SamKnows probe. The google map [2] shows where these probes are deployed. As you can see the VP sample is too small (nothing in North America) [2] http://goo.gl/TL4woP <——------ Request: If you receive native IPv6 at home (or know someone who does), it would be great if you can host a LEONE SamKnows probe for us. The probe will run standard SamKnows tests [3] and our IPv6 tests. [3] https://www.samknows.com/tests-and-metrics We prefer measuring from home networks, but are also open to deploying probes within research/academic networks, business lines, or operators labs. <-------- Action: Let me know if you’re interested, and I can share details on how to get the probe to you. We only have limited number of LEONE SamKnows probes. We will process the requests on first come first serve basis. <-------- Research Impact. a) Measuring YouTube from Dual-Stacked Hosts Saba Ahsan, Vaibhav Bajpai, Jörg Ott, Jürgen Schönwälder Passive and Active Measurement Conference (PAM 2015), New York, March 2015. b) Measuring TCP Connection Establishment Times of Dual-Stacked Web Services Vaibhav Bajpai, Jürgen Schönwälder 9th International Conference on Network and Service Management, (CNSM 2013) Zürich, October 2013. 8<——-- Thanks. Thank you so much for helping us in our research activity. Best, Vaibhav ===================================================== Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From michael.holstein at csuohio.edu Tue Jan 20 07:15:19 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Tue, 20 Jan 2015 07:15:19 +0000 Subject: gamer "lag" dashboard In-Reply-To: References: <1421705578413.91196@csuohio.edu> <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> , Message-ID: <1421738118933.62038@csuohio.edu> >Once you get tired of spending expensive labor time on this project, you can throw some >grad students, xboxes and scapy in a room and have them automate the process for Actually, this is exactly what we do now .. we host LAN parties (usually right after Christmas when new games come out) and have everyone plug their toys into monitoring switches and get their frag on while the engineers in the back of the room watch the packets and tweak stuff in realtime. This not only fixes the problem (sometimes) but it garners an incredible amount of good will because ... when was the last time YOUR helpdesk invited you down to game at their office so they could help you reduce your lag? If you are in a position to do so, consider it. You already have a bunch of HDTVs and projectors in the conference room .. order some Subway/Pizza and make an afternoon of it. It's also a non-creepy way to do "network analysis" .. when they can walk back and see what you're doing and why. Of course we can do it the other way too but we've found it works way better to fiddle with it in realtime versus examine a pcap, tweak, update ticket, wait, repeat ... I do appreciate all the responses on/off list and those of you that reached out to help in some way I will contact privately in return. Thanks NANOG, and goodnight. The red button at the right will unlock the door. -Michael Holstein -Network & Data Security -Cleveland State University From wcci2016 at gmail.com Tue Jan 20 04:08:08 2015 From: wcci2016 at gmail.com (2016 IEEE WCCI) Date: Tue, 20 Jan 2015 04:08:08 +0000 Subject: 2016 IEEE World Congress on Computational Intelligence - Call for Papers Message-ID: <4tu3wq7xmglc.mpkx5c-48g9zjif9g1q01@api.elasticemail.com> From md at bts.sk Tue Jan 20 08:04:29 2015 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Tue, 20 Jan 2015 09:04:29 +0100 Subject: Recommended L2 switches for a new IXP In-Reply-To: <6DB700CF-CFEB-4623-92B8-3C4BCB1CA6A7@gmail.com> References: <20150117110233.GA88590@bts.sk> <20150117191504.GA17079@pob.ytti.fi> <6DB700CF-CFEB-4623-92B8-3C4BCB1CA6A7@gmail.com> Message-ID: <20150120080429.GA95997@bts.sk> On Mon, Jan 19, 2015 at 09:37:35PM -0500, Phil Bedard wrote: > I think in fairly short order both TRILL and 802.1AQ will be depercated in > place of VXLAN and using BGP EVPN as the control plane ala Juniper > QFX5100/Nexus 9300. We also evaluated VXLAN for IXP deployment, since Trident-2 introduced HW support for it. But VXLAN does *not* create a network for you, it relies on some existing underlying IP network, on top of which VXLAN creates stateless tunnels. By using TRILL, we could connect 4 switches into a ring (or any other reasonable topology) and have a fully functional network with shortest-path "routing" of L2 packets. With VXLAN, we'd need at least two additional IP routers with bunch of 40GE interfaces to perform the functions TRILL supports out of the box. Regards, M. From tim at pelican.org Tue Jan 20 10:23:53 2015 From: tim at pelican.org (Tim Franklin) Date: Tue, 20 Jan 2015 10:23:53 +0000 (GMT) Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <20150119215604.2397.qmail@ary.lan> References: <20150119215604.2397.qmail@ary.lan> Message-ID: <595911751.5837.1421749433480.JavaMail.zimbra@pelican.org> > By the way, I hope that all of the people who have been ranting about > this have read this note. The only way this filtering works is if the > client computers have a special CA cert installed into their browsers. > That means it's a private organizational network that manages all its > client computers, or it's a service where the users specifically do > something on their own computers to enable it. In the first instance, I'd still very much *want* the organisation to tell the users that the internal IT people are breaking their SSL, so please not to have any expectation that security is doing what you think it is. While it's not an organisation I'd particularly enjoy working for, at least I then know not to do online banking in my lunch break, or similar. Pushing out internal MITM CAs silently *is* still evil, in my view, although sadly closer to what I'd *expect* to happen. Regards, Tim. From oscar.vives at gmail.com Tue Jan 20 13:34:27 2015 From: oscar.vives at gmail.com (Tei) Date: Tue, 20 Jan 2015 14:34:27 +0100 Subject: gamer "lag" dashboard In-Reply-To: <1421738118933.62038@csuohio.edu> References: <1421705578413.91196@csuohio.edu> <3676F58A-557C-482A-B9C6-AE8F6B97E02D@gmail.com> <1421738118933.62038@csuohio.edu> Message-ID: If anyone is interested, the Quake engine and variants have created a lot of documentation and tools. Since Quake represent early phases of the development of modern gaming systems, they are simple. As simple they can be. Many open source games can be studied, I suggest OpenArena because is easy available and fun. Modern games don't work standalone. They connect to a master server to find other gamers/active games. Heres a simple one: https://github.com/kphillisjr/dpmaster Example of use: http://dpmaster.deathmask.net/?game=openarena Another game that is interesting for networking, is SubSpace. The history with subspace is that was a commercial game that turned open source. It had already billing server, game server, master server. So is probably very similar to how many commercial games work. http://en.wikipedia.org/wiki/SubSpace_%28video_game%29 http://wiki.minegoboom.com/index.php/Main_Page http://wiki.minegoboom.com/index.php/Category:Protocol It looks to me like somebody can learn stuff by reading this ones. From bill at herrin.us Tue Jan 20 15:07:01 2015 From: bill at herrin.us (William Herrin) Date: Tue, 20 Jan 2015 10:07:01 -0500 Subject: HTTPS redirects to HTTP for monitoring In-Reply-To: <595911751.5837.1421749433480.JavaMail.zimbra@pelican.org> References: <20150119215604.2397.qmail@ary.lan> <595911751.5837.1421749433480.JavaMail.zimbra@pelican.org> Message-ID: On Tue, Jan 20, 2015 at 5:23 AM, Tim Franklin wrote: > I'd still very much *want* the organization to tell the users > that the internal IT people are breaking their SSL, so > please not to have any expectation that security is doing > what you think it is. Blame it on the browser devs. They tell users the -wrong- things about security. Silent about totally unencrypted traffic. Silent about Sysadmin-installed certs. Noisy with dire warnings about anyone who wants better than unencrypted without whole-hog signed certs. And God help you if you train your users to just click "confirm exception." Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From bedard.phil at gmail.com Tue Jan 20 15:17:20 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 20 Jan 2015 10:17:20 -0500 Subject: Recommended L2 switches for a new IXP In-Reply-To: <20150120080429.GA95997@bts.sk> References: <20150117110233.GA88590@bts.sk> <20150117191504.GA17079@pob.ytti.fi> <6DB700CF-CFEB-4623-92B8-3C4BCB1CA6A7@gmail.com> <20150120080429.GA95997@bts.sk> Message-ID: <61EBADCD-86B2-4CC6-BA48-1CF2B01DE03E@gmail.com> For many people eliminating L2 switching and building on top of a L3 network is a good thing, especially if you are using BGP as the control plane. I'm not sure I follow the two routers with 40GE interfaces if you are just building L2 domains to interconnect people. Phil On 1/20/15, 8:04 AM, "Marian Ďurkovič" wrote: >On Mon, Jan 19, 2015 at 09:37:35PM -0500, Phil Bedard wrote: >> I think in fairly short order both TRILL and 802.1AQ will be depercated >>in >> place of VXLAN and using BGP EVPN as the control plane ala Juniper >> QFX5100/Nexus 9300. > >We also evaluated VXLAN for IXP deployment, since Trident-2 introduced HW >support for it. But VXLAN does *not* create a network for you, it relies >on >some existing underlying IP network, on top of which VXLAN creates >stateless >tunnels. > >By using TRILL, we could connect 4 switches into a ring (or any other >reasonable topology) and have a fully functional network with >shortest-path >"routing" of L2 packets. > >With VXLAN, we'd need at least two additional IP routers with bunch of >40GE interfaces to perform the functions TRILL supports out of the box. > >Regards, > > M. > > From tdurack at gmail.com Tue Jan 20 15:47:23 2015 From: tdurack at gmail.com (Tim Durack) Date: Tue, 20 Jan 2015 10:47:23 -0500 Subject: RAD MiNID Message-ID: Anyone got experience with RAD MiNID? I need to do some L2 protocol tunneling (L2PT), and this looks like it might scratch that itch. -- Tim:> From bob at FiberInternetCenter.com Tue Jan 20 18:12:29 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 20 Jan 2015 10:12:29 -0800 Subject: Could someone from Charter that is knowledgable on SV1 and LOA processes please contact me. Message-ID: <6f8dc815d6c2b97d2dc990f2ea2f9036.squirrel@66.201.44.180> Hello, I am having a heck of a time with this Charter order. Today's issue - I was sent an incomplete LOA from the project manager (PM). Basically, asking me for charter's information on port numbers and data for the cross connect at SV1 (11 Great Oaks, San Jose)? Obviously, I can't provided that as I can't read minds. ( If I could, Bill Gates would be working for me. ) At the start...PM sent the field tech out to customer prem to verify the fiber. A month later, did it again. The Charter field tech called "me" asking why he had to go twice. Who's on first? (old Abbot and Costello reference). It's been like this at almost every step on this order which is now many many months behind. I think this is stuck in some sort of order twilight zone. My sales team and my customer is getting upset. Thank You Bob Evans CTO bob at FiberInternetCenter.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: untitled-[1.1.2].html URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Blank Charter LOA-CFA.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 51204 bytes Desc: not available URL: From chkuhtz at microsoft.com Tue Jan 20 23:19:55 2015 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Tue, 20 Jan 2015 23:19:55 +0000 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: References: Message-ID: I don't belong to the O365 product group, but did you look at this? https://technet.microsoft.com/en-us/library/hh852542.aspx and a blog article to go along with that: http://blogs.technet.com/b/educloud/archive/2013/08/20/do-you-have-any-bandwidth-calculators-for-office-365.aspx There's a bunch more than comes up under "office 365 bandwidth calculator" in your friendly neighborhood search engine. The Exchange client model, for example, looks like it can give you basics for a model based projection if you can characterize your base. Thanks, Christian -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans Sent: Tuesday, January 6, 2015 12:37 PM To: NANOG list Subject: Office 365 Expert - I am not. I have a customer that... I have a customer that heavily uses Microsoft Office 365. It's hosted. All the data I see about usage per user appears theoretical. In that the formulas assume people are taking turns using the bandwidth as if there is a patient line of packets at the Internet gas pump. Nobody is clicking at the same time. We all know that is not the real world. Does anyone have any experience with Office 365 hosted that can tell me the practical bandwidth allocation (NOT in KB per month, but in megabits/sec) for 100 users (during normal work hours) needs to be available ? Thank You in advance, Bob Evans CTO Fiber Internet Center From ryan at finnesey.com Wed Jan 21 06:40:46 2015 From: ryan at finnesey.com (Ryan Finnesey) Date: Wed, 21 Jan 2015 06:40:46 +0000 Subject: Registrar Accreditation Message-ID: <766F269A-4DB9-4E1D-97BD-705041DFCF64@finnesey.com> Has anyone gone through the ICANN Registrar Accreditation process and would have any tips or insight they can share? Cheers Ryan Sent from my iPad From colinj at gt86car.org.uk Wed Jan 21 09:10:47 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 21 Jan 2015 09:10:47 +0000 Subject: Office 365 Expert - I am not. I have a customer that... In-Reply-To: References: Message-ID: <361B1E60-9372-493F-80EF-BF616BEF14F5@gt86car.org.uk> > On 20 Jan 2015, at 23:19, Christian Kuhtz wrote: > > I don't belong to the O365 product group, but did you look at this? > > https://technet.microsoft.com/en-us/library/hh852542.aspx > > and a blog article to go along with that: > > http://blogs.technet.com/b/educloud/archive/2013/08/20/do-you-have-any-bandwidth-calculators-for-office-365.aspx > > There's a bunch more than comes up under "office 365 bandwidth calculator" in your friendly neighborhood search engine. > > The Exchange client model, for example, looks like it can give you basics for a model based projection if you can characterize your base. > biggest issue to deal with is migration traffic analysis, you need to identify biggest pst users, biggest non techie users who dont delete emails so hence have large email sets. you need to identify work times so that migration efforts can start overnight ideally. Colin From Ronald.vanderPol at rvdp.org Wed Jan 21 17:22:56 2015 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 21 Jan 2015 18:22:56 +0100 Subject: link monitoring and BFD in SDN networks In-Reply-To: References: Message-ID: <20150121172255.GK496@rvdp.org> On Mon, Jan 19, 2015 at 22:55:04 +0000, Dave Bell wrote: > "http://www.rvdp.org/presentations/SC11-SRS-8021ag.pdf" The 802.1ag code used is open source and available on: https://svn.surfnet.nl/trac/dot1ag-utils/ > Of course if you want fast failover, you need to send packets very > rapidly. Every 250ms is not unreasonable. This is going to cause the > control plane to get very chatty. Typically on high end routers, > processes such as BFD are actually ran on line cards as opposed to on > the routing engine. When a failure is detected this reports up into > the control plane to trigger a reconvergence event. I see no reason > why this couldn't occur using SDN. Exactly. This is something you want to do in hardware, especially if you want to do fast reroute with the OpenFlow group table. Problem is that many 1U OpenFlow switches do not support 802.1ag. We made the propotype mentioned above to show and investigate the benefits of OAM. The closed "open" networking foundation is supposed to be working on this, but I don't know the status because their mailing lists are closed. In SDN/OpenFlow I think a couple of things are needed: - configure 802.1ag on the interfaces (via ofconfig?) - configure OpenFlow paths (e.g. primary and backup) and also create forwarding entries for 802.1ag datagrams along those paths - configure fast reroute with the group table (ofconfig?) By doing this detection and failover are handled in hardware. rvdp From swannie at swannie.net Wed Jan 21 17:31:17 2015 From: swannie at swannie.net (Brian R. Swan) Date: Wed, 21 Jan 2015 11:31:17 -0600 Subject: Netflix contact Message-ID: <03B4700E-26E1-408F-964E-A6C155939431@swannie.net> Is there anyone out there from NetFlix? If so, can you please contact me off list, I'd like to discuss a campus network/proxy situation that my customer has with your service. From michael.holstein at csuohio.edu Wed Jan 21 18:23:07 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Wed, 21 Jan 2015 18:23:07 +0000 Subject: Netflix contact In-Reply-To: <03B4700E-26E1-408F-964E-A6C155939431@swannie.net> References: <03B4700E-26E1-408F-964E-A6C155939431@swannie.net> Message-ID: <1421864714653.87224@csuohio.edu> Fill out the form, they will get back to you in a couple hours (they did for me, anyway) https://openconnect.itp.netflix.com/request/index.html You do need a certain amount of ingest from them before they will consider it. Regards, Michael Holstein Cleveland State University ________________________________________ From: NANOG on behalf of Brian R. Swan Sent: Wednesday, January 21, 2015 12:31 PM To: nanog at nanog.org Subject: Netflix contact Is there anyone out there from NetFlix? If so, can you please contact me off list, I'd like to discuss a campus network/proxy situation that my customer has with your service. From nitinics at gmail.com Wed Jan 21 23:14:33 2015 From: nitinics at gmail.com (Nitin Sharma) Date: Wed, 21 Jan 2015 18:14:33 -0500 Subject: link monitoring and BFD in SDN networks In-Reply-To: <20150121172255.GK496@rvdp.org> References: <20150121172255.GK496@rvdp.org> Message-ID: On Wed, Jan 21, 2015 at 12:22 PM, Ronald van der Pol < Ronald.vanderPol at rvdp.org> wrote: > On Mon, Jan 19, 2015 at 22:55:04 +0000, Dave Bell wrote: > > > "http://www.rvdp.org/presentations/SC11-SRS-8021ag.pdf" > > The 802.1ag code used is open source and available on: > https://svn.surfnet.nl/trac/dot1ag-utils/ > > > Of course if you want fast failover, you need to send packets very > > rapidly. Every 250ms is not unreasonable. This is going to cause the > > control plane to get very chatty. Typically on high end routers, > > processes such as BFD are actually ran on line cards as opposed to on > > the routing engine. When a failure is detected this reports up into > > the control plane to trigger a reconvergence event. I see no reason > > why this couldn't occur using SDN. > > Exactly. This is something you want to do in hardware, especially > if you want to do fast reroute with the OpenFlow group table. > Problem is that many 1U OpenFlow switches do not support 802.1ag. > We made the propotype mentioned above to show and investigate the > benefits of OAM. The closed "open" networking foundation is supposed > to be working on this, but I don't know the status because their > mailing lists are closed. > > In SDN/OpenFlow I think a couple of things are needed: > - configure 802.1ag on the interfaces (via ofconfig?) > - configure OpenFlow paths (e.g. primary and backup) and also create > forwarding entries for 802.1ag datagrams along those paths > - configure fast reroute with the group table (ofconfig?) > Fast reroute (in the form of fast failover) is supported in the OF spec (1.3+), using Group Tables. > By doing this detection and failover are handled in hardware. > > rvdp > Data plane reachability could be performed in SDN/OpenFlow networks using BFD/ Ethernet CFM (802.1ag), Y.1731, preferably on silicon if there is support (which i believe every silicon vendor should work on). It would not be ideal if these OAM frames are forwarded to a central controller. Today - I think it is done on some form of software layer (ovs, sdks) that reside on these OF switches. From amps at djlab.com Wed Jan 21 23:15:12 2015 From: amps at djlab.com (Randy) Date: Wed, 21 Jan 2015 15:15:12 -0800 Subject: Comcast contact regarding /32 nullroute Message-ID: Someone/something is announcing a /32 from our IP space into comcast from a private ASN. Could someone from comcast help at least provide me some more information off-list? Normal support channels are not helping. route-server.newyork.ny.ibone>show ip bgp 74.115.212.130 BGP routing table entry for 74.115.212.130/32, version 2713438548 Paths: (13 available, best #10, table Default-IP-Routing-Table, not advertised to EBGP peer) Advertised to update-groups: 2 64650, (received & used) 68.86.80.4 (metric 69635) from 68.86.80.4 (68.86.1.4) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export It should instead look like this. route-server.newyork.ny.ibone>show ip bgp 74.115.212.129 BGP routing table entry for 74.115.212.0/22, version 2674585749 Paths: (13 available, best #12, table Default-IP-Routing-Table) Advertised to update-groups: 2 29944 29889, (received & used) 68.86.1.89 (metric 66845) from 68.86.80.4 (68.86.1.4) Origin IGP, metric 0, localpref 300, valid, internal Community: 7922:89 7922:2900 Originator: 68.86.1.89, Cluster list: 68.86.1.4, 68.86.1.0 -- ~Randy From wesley.george at twcable.com Thu Jan 22 14:27:55 2015 From: wesley.george at twcable.com (George, Wes) Date: Thu, 22 Jan 2015 09:27:55 -0500 Subject: [request]: host a probe for v6 measurements In-Reply-To: <8B0BCD73-0EC1-462A-A303-6FA710A237DC@jacobs-university.de> References: <8B0BCD73-0EC1-462A-A303-6FA710A237DC@jacobs-university.de> Message-ID: We've seen 3 or 4 recent presentations of some new measurement project that requires deploying yet another set of dedicated probes. While I'm generally supportive of measurement attempts, I'll ask the same question that was asked then: Why not use RIPE Atlas? https://atlas.ripe.net/docs/udm/ Wes George On 1/19/15, 8:33 AM, "Bajpai, Vaibhav" wrote: >Dear NANOG, > >We are currently looking for volunteers in US with native IPv6 lines >to help us in our v6 measurement research. > ><——------ Background >We are interested in measuring IPv6 performance from home. As part >of the LEONE project [1], we have developed measurement tests that >compare performance over IPv4 and IPv6 to: a) Dual-stacked websites >and b) YouTube content delivery network (in collaboration with Aalto >University). The tests comes bundled with a LEONE SamKnows probe. > >[1] http://www.leone-project.eu > >We currently have ~25 Vantage points (VP). Each VP runs a Leone >SamKnows probe. The google map [2] shows where these probes are >deployed. As you can see the VP sample is too small (nothing in >North America) > >[2] http://goo.gl/TL4woP > > ><——------ Request: >If you receive native IPv6 at home (or know someone who does), it >would be great if you can host a LEONE SamKnows probe for us. The >probe will run standard SamKnows tests [3] and our IPv6 tests. > >[3] https://www.samknows.com/tests-and-metrics > >We prefer measuring from home networks, but are also open to >deploying probes within research/academic networks, business >lines, or operators labs. > > ><-------- Action: >Let me know if you’re interested, and I can share details on how to >get the probe to you. We only have limited number of LEONE SamKnows >probes. We will process the requests on first come first serve basis. > > > ><-------- Research Impact. >a) Measuring YouTube from Dual-Stacked Hosts > Saba Ahsan, Vaibhav Bajpai, Jörg Ott, Jürgen Schönwälder > Passive and Active Measurement Conference (PAM 2015), > New York, March 2015. > >b) Measuring TCP Connection Establishment Times of Dual-Stacked Web >Services > Vaibhav Bajpai, Jürgen Schönwälder > 9th International Conference on Network and Service Management, (CNSM >2013) > Zürich, October 2013. > > >8<——-- Thanks. >Thank you so much for helping us in our research activity. > > >Best, Vaibhav > >===================================================== >Vaibhav Bajpai > >Research I, Room 91 >Computer Networks and Distributed Systems (CNDS) Lab >School of Engineering and Sciences >Jacobs University Bremen, Germany > >www.vaibhavbajpai.com >===================================================== This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From randy at psg.com Thu Jan 22 14:33:38 2015 From: randy at psg.com (Randy Bush) Date: Thu, 22 Jan 2015 23:33:38 +0900 Subject: [request]: host a probe for v6 measurements In-Reply-To: References: <8B0BCD73-0EC1-462A-A303-6FA710A237DC@jacobs-university.de> Message-ID: > Why not use RIPE Atlas? > https://atlas.ripe.net/docs/udm/ usually it is because you can not put your own code in it for the measures you want to make. randy From skhuraijam at liveops.com Thu Jan 22 19:32:10 2015 From: skhuraijam at liveops.com (Sudeep Khuraijam) Date: Thu, 22 Jan 2015 11:32:10 -0800 Subject: link monitoring and BFD in SDN networks In-Reply-To: References: <20150121172255.GK496@rvdp.org> Message-ID: Gents, We need to separate the context of fast reroute via control plane topology map vs local link protection with OAM at mac/phy sub-layer and time frames at which they are relevant. There are efforts going on at the media level but then there are current solutions that are media and encapsulation independent which need to be juxtaposed to the SDN paradigm. Going back to the original question that Glen posed, it is more a question on implementation complexity. The more state machines that are pushed down to the Nodes in SDN network away from the control plane, the more cost and barriers to entry for OEM products, inter-op issues etc. Now looking squarely at BFD, the popular application is bootstrapping BFD link state to routing topology and peer pathway which may traverse multiple nodes/switches/media and encapsulations. BFD is a next hop communication failure detection mechanism which may itself rely (bootstrap) on routing topology to find alternate paths and is therefore a larger time frame event than a phy/mac sub layer protection, and is media/encapsulation independent. And the fact that such a state change will have a high probability to trigger a topology/network wide event (if not less need to run BFD) makes it a controller centric state which it needs to bootstrap its routing services on. Link layer OAM on the other hand may be a mechanism that protects the BFD event from triggering. Further, BFD will enable faster end to end connectivity communication/reachability detection than hold down timers allow on hardware that do not support OAM features. Finally the scale at which BFD is used is far less than the number of links. I.e if you have a 10K port network, you are likely using BFD on a few tens maybe (for Datacenters) and the timescale is typically in the 100s ms which any control plane software module can handle at large scale and should be run just like any hello protocols for routing services. Link layer state machines on the nodes on the other hand operate in the sub 1ms timeframe. It is an overhead, but an insignificantly small tax. Cheers, Sudeep Khuraijam On 1/21/15, 3:14 PM, "Nitin Sharma" wrote: >On Wed, Jan 21, 2015 at 12:22 PM, Ronald van der Pol < >Ronald.vanderPol at rvdp.org> wrote: > >> On Mon, Jan 19, 2015 at 22:55:04 +0000, Dave Bell wrote: >> >> > "http://www.rvdp.org/presentations/SC11-SRS-8021ag.pdf" >> >> The 802.1ag code used is open source and available on: >> https://svn.surfnet.nl/trac/dot1ag-utils/ >> >> > Of course if you want fast failover, you need to send packets very >> > rapidly. Every 250ms is not unreasonable. This is going to cause the >> > control plane to get very chatty. Typically on high end routers, >> > processes such as BFD are actually ran on line cards as opposed to on >> > the routing engine. When a failure is detected this reports up into >> > the control plane to trigger a reconvergence event. I see no reason >> > why this couldn't occur using SDN. >> >> Exactly. This is something you want to do in hardware, especially >> if you want to do fast reroute with the OpenFlow group table. >> Problem is that many 1U OpenFlow switches do not support 802.1ag. >> We made the propotype mentioned above to show and investigate the >> benefits of OAM. The closed "open" networking foundation is supposed >> to be working on this, but I don't know the status because their >> mailing lists are closed. >> >> In SDN/OpenFlow I think a couple of things are needed: >> - configure 802.1ag on the interfaces (via ofconfig?) >> - configure OpenFlow paths (e.g. primary and backup) and also create >> forwarding entries for 802.1ag datagrams along those paths >> - configure fast reroute with the group table (ofconfig?) >> > >Fast reroute (in the form of fast failover) is supported in the OF spec >(1.3+), using Group Tables. > > >> By doing this detection and failover are handled in hardware. >> >> rvdp >> > >Data plane reachability could be performed in SDN/OpenFlow networks using >BFD/ Ethernet CFM (802.1ag), Y.1731, preferably on silicon if there is >support (which i believe every silicon vendor should work on). It would >not >be ideal if these OAM frames are forwarded to a central controller. Today >- >I think it is done on some form of software layer (ovs, sdks) that reside >on these OF switches. From jared at puck.nether.net Thu Jan 22 20:50:05 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 Jan 2015 15:50:05 -0500 Subject: NETGEAR Contacts? Message-ID: <2FC2C3DF-520C-4709-B6FE-329728CA810B@puck.nether.net> I’m wondering if someone has any contacts at Netgear they would be willing to forward some information to. While working with their devices one of my colleagues discovered some poor behavior of their embedded DNSMASQ, such as returning REFUSED to DNS queries. eg: $ dig +tcp puck.nether.net. ; <<>> DiG 9.8.3-P1 <<>> +tcp puck.nether.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33649 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;puck.nether.net. IN A ;; Query time: 136 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Jan 22 13:28:59 2015 ;; MSG SIZE rcvd: 33 where a UDP query passes just fine. This is one of a few issues we’ve uncovered, so hoping for someone who can work on building some fixed firmware. Device in question: Netgear wnr2000v3 v1.1.2.10 (latest on website) Is there a mailing list that exists for the purposes of discussing these types of CPE device issues? - Jared From khelms at zcorum.com Thu Jan 22 20:57:08 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 22 Jan 2015 15:57:08 -0500 Subject: NETGEAR Contacts? In-Reply-To: <2FC2C3DF-520C-4709-B6FE-329728CA810B@puck.nether.net> References: <2FC2C3DF-520C-4709-B6FE-329728CA810B@puck.nether.net> Message-ID: Jared, Netgear is divided into a few divisions and they don't overlap, is this direct to consumer gear or gear they sold through an ISP? Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jan 22, 2015 at 3:50 PM, Jared Mauch wrote: > I’m wondering if someone has any contacts at Netgear they would be willing > to forward some information to. While working with their devices one of my > colleagues discovered some poor behavior of their embedded DNSMASQ, such as > returning REFUSED to DNS queries. > > eg: > > $ dig +tcp puck.nether.net. > > ; <<>> DiG 9.8.3-P1 <<>> +tcp puck.nether.net. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33649 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;puck.nether.net. IN A > > ;; Query time: 136 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) > ;; WHEN: Thu Jan 22 13:28:59 2015 > ;; MSG SIZE rcvd: 33 > > > where a UDP query passes just fine. > > This is one of a few issues we’ve uncovered, so hoping for someone who can > work on building some fixed firmware. > > Device in question: > > Netgear wnr2000v3 > v1.1.2.10 (latest on website) > > Is there a mailing list that exists for the purposes of discussing these > types of CPE device issues? > > - Jared From jared at puck.nether.net Thu Jan 22 21:02:35 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 Jan 2015 16:02:35 -0500 Subject: NETGEAR Contacts? In-Reply-To: References: <2FC2C3DF-520C-4709-B6FE-329728CA810B@puck.nether.net> Message-ID: <827CC9CA-2100-41C8-B543-5168B28ADF80@puck.nether.net> Direct consumer, eg: http://www.amazon.com/NETGEAR-Wireless-Router-N300-WNR2000/dp/B001AZP8EW - Jared > On Jan 22, 2015, at 3:57 PM, Scott Helms wrote: > > Jared, > > Netgear is divided into a few divisions and they don't overlap, is this direct to consumer gear or gear they sold through an ISP? > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Jan 22, 2015 at 3:50 PM, Jared Mauch wrote: > I’m wondering if someone has any contacts at Netgear they would be willing to forward some information to. While working with their devices one of my colleagues discovered some poor behavior of their embedded DNSMASQ, such as returning REFUSED to DNS queries. > > eg: > > $ dig +tcp puck.nether.net. > > ; <<>> DiG 9.8.3-P1 <<>> +tcp puck.nether.net. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33649 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;puck.nether.net. IN A > > ;; Query time: 136 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) > ;; WHEN: Thu Jan 22 13:28:59 2015 > ;; MSG SIZE rcvd: 33 > > > where a UDP query passes just fine. > > This is one of a few issues we’ve uncovered, so hoping for someone who can work on building some fixed firmware. > > Device in question: > > Netgear wnr2000v3 > v1.1.2.10 (latest on website) > > Is there a mailing list that exists for the purposes of discussing these types of CPE device issues? > > - Jared > From khelms at zcorum.com Thu Jan 22 21:05:32 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 22 Jan 2015 16:05:32 -0500 Subject: NETGEAR Contacts? In-Reply-To: <827CC9CA-2100-41C8-B543-5168B28ADF80@puck.nether.net> References: <2FC2C3DF-520C-4709-B6FE-329728CA810B@puck.nether.net> <827CC9CA-2100-41C8-B543-5168B28ADF80@puck.nether.net> Message-ID: Sorry, the guys I know are on the ISP side :( I'll ask if there is anyone they can point us to on the direct side. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jan 22, 2015 at 4:02 PM, Jared Mauch wrote: > Direct consumer, eg: > http://www.amazon.com/NETGEAR-Wireless-Router-N300-WNR2000/dp/B001AZP8EW > > - Jared > > > On Jan 22, 2015, at 3:57 PM, Scott Helms wrote: > > > > Jared, > > > > Netgear is divided into a few divisions and they don't overlap, is this > direct to consumer gear or gear they sold through an ISP? > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > On Thu, Jan 22, 2015 at 3:50 PM, Jared Mauch > wrote: > > I’m wondering if someone has any contacts at Netgear they would be > willing to forward some information to. While working with their devices > one of my colleagues discovered some poor behavior of their embedded > DNSMASQ, such as returning REFUSED to DNS queries. > > > > eg: > > > > $ dig +tcp puck.nether.net. > > > > ; <<>> DiG 9.8.3-P1 <<>> +tcp puck.nether.net. > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33649 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;puck.nether.net. IN A > > > > ;; Query time: 136 msec > > ;; SERVER: 192.168.1.1#53(192.168.1.1) > > ;; WHEN: Thu Jan 22 13:28:59 2015 > > ;; MSG SIZE rcvd: 33 > > > > > > where a UDP query passes just fine. > > > > This is one of a few issues we’ve uncovered, so hoping for someone who > can work on building some fixed firmware. > > > > Device in question: > > > > Netgear wnr2000v3 > > v1.1.2.10 (latest on website) > > > > Is there a mailing list that exists for the purposes of discussing these > types of CPE device issues? > > > > - Jared > > > > From janets at nairial.net Thu Jan 22 22:42:17 2015 From: janets at nairial.net (Janet Sullivan) Date: Thu, 22 Jan 2015 22:42:17 +0000 Subject: Comcast Support Message-ID: I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset my router 4 times while working with Comcast, and I've been told to do things like switch to a static IPv4 address, which shows a level of clue that is scary. And before that they were convinced it was a wireless problem even though I have a wired connection, and told them that multiple times. I've wasted two hours with Comcast today, and even when I asked for escalation I got nothing. Just hung up on. It's honestly the worst customer support I've ever received. I don't think I ever got them to understand the difference between IPv4 and IPv6. From William.Murphy at uth.tmc.edu Thu Jan 22 23:26:35 2015 From: William.Murphy at uth.tmc.edu (Murphy, William) Date: Thu, 22 Jan 2015 23:26:35 +0000 Subject: Comcast Support In-Reply-To: References: Message-ID: <60A6112378A00B4BBC674E5B8DC65B4017AC96FE@UTHMAIL1.uthouston.edu> I experienced a loss of Comcast IPv6 service at my home I think it was last Monday... My pfSense reported loss of reachability to the IPv6 gateway, IPv4 still worked but I had a period of intermittent high latency... Does anyone know if Comcast is monkeying around with their IPv6 network? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Janet Sullivan Sent: Thursday, January 22, 2015 4:42 PM To: 'nanog at nanog.org' Subject: Comcast Support I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset my router 4 times while working with Comcast, and I've been told to do things like switch to a static IPv4 address, which shows a level of clue that is scary. And before that they were convinced it was a wireless problem even though I have a wired connection, and told them that multiple times. I've wasted two hours with Comcast today, and even when I asked for escalation I got nothing. Just hung up on. It's honestly the worst customer support I've ever received. I don't think I ever got them to understand the difference between IPv4 and IPv6. From aaron at heyaaron.com Thu Jan 22 23:28:59 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 22 Jan 2015 15:28:59 -0800 Subject: Comcast Support In-Reply-To: References: Message-ID: It's starting to become more typical. I finally resolved an issue after two weeks of fighting with them. A remote office could send traffic out, but couldn't receive traffic. I ran tcpdumps on the firewall, and did everything to convince them it wasn't my problem. They still insisted on sending out a 'tech' to check the issue. When the tech hooked up his Windows XP laptop to the modem and was able to pull up Bing, he said everything was working fine. We were told we would be billed for the tech coming out. The last time I called in, I *finally* got someone who was studying for their CCNA, described everything, and he spent about an hour on the phone troubleshooting. Finally he re-flashed the modem, reloaded the config, and manually configured the static IPs on the modem. Everything immediately came up. http://xkcd.com/806/ Maybe Comcast train the level 1 techs that if someone says "NANOG" you get transferred to someone who knows routing... ;) -A On Thu, Jan 22, 2015 at 2:42 PM, Janet Sullivan wrote: > I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. > > I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset my router 4 times while working with Comcast, and I've been told to do things like switch to a static IPv4 address, which shows a level of clue that is scary. And before that they were convinced it was a wireless problem even though I have a wired connection, and told them that multiple times. I've wasted two hours with Comcast today, and even when I asked for escalation I got nothing. Just hung up on. It's honestly the worst customer support I've ever received. I don't think I ever got them to understand the difference between IPv4 and IPv6. From pete at altadena.net Fri Jan 23 00:07:34 2015 From: pete at altadena.net (Pete Carah) Date: Thu, 22 Jan 2015 19:07:34 -0500 Subject: Comcast Support In-Reply-To: References: Message-ID: <54C190C6.6020301@altadena.net> On 01/22/2015 06:28 PM, Aaron C. de Bruyn wrote: > It's starting to become more typical. > > I finally resolved an issue after two weeks of fighting with them. > A remote office could send traffic out, but couldn't receive traffic. > > ..... > http://xkcd.com/806/ Cute. > > Maybe Comcast train the level 1 techs that if someone says "NANOG" you > get transferred to someone who knows routing... ;) And Charter gets you the business NOC if you call level1 tech between 2 and 6AM eastern. Unfortunately this is the fiber-service noc so they can't do much with cable nodes. At least they know what a router is, and ping and traceroute. > > Reminds me of a call I made to the local power company some years back; the transformer for my end of the block was rather undersized for the more-recently installed customer air conditioners, and my line voltage was around 85 in the afternoon. Computers don't like that :-( Called the trouble line, said my voltage was low. She asked how I was measuring it, I said the magic word "Fluke". She then said it would get reported right away. Of course, fixing it was a major undertaking (had to replace the 2400 pole-top lines with 16kv, and add a transformer), so it still took a year for them to actually fix it (and a day without power while running the new lines)... At least that magic word was in the script... -- Pete From gwardell at gwsystems.co.il Fri Jan 23 00:20:17 2015 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Thu, 22 Jan 2015 19:20:17 -0500 Subject: Comcast Support In-Reply-To: <54C190C6.6020301@altadena.net> References: <54C190C6.6020301@altadena.net> Message-ID: <013701d036a2$5d86edb0$1894c910$@gwsystems.co.il> I had a similar thing with Shentel. When I finally started sending them screenshots of Wireshark ARP traffic I got to talk to someone that knew something. Turned out another customer was advertising they owned part of my IP addresses. Gary -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Pete Carah Sent: Thursday, January 22, 2015 7:08 PM To: nanog at nanog.org Subject: Re: Comcast Support On 01/22/2015 06:28 PM, Aaron C. de Bruyn wrote: > It's starting to become more typical. > > I finally resolved an issue after two weeks of fighting with them. > A remote office could send traffic out, but couldn't receive traffic. > > ..... > http://xkcd.com/806/ Cute. > > Maybe Comcast train the level 1 techs that if someone says "NANOG" you > get transferred to someone who knows routing... ;) And Charter gets you the business NOC if you call level1 tech between 2 and 6AM eastern. Unfortunately this is the fiber-service noc so they can't do much with cable nodes. At least they know what a router is, and ping and traceroute. > > Reminds me of a call I made to the local power company some years back; the transformer for my end of the block was rather undersized for the more-recently installed customer air conditioners, and my line voltage was around 85 in the afternoon. Computers don't like that :-( Called the trouble line, said my voltage was low. She asked how I was measuring it, I said the magic word "Fluke". She then said it would get reported right away. Of course, fixing it was a major undertaking (had to replace the 2400 pole-top lines with 16kv, and add a transformer), so it still took a year for them to actually fix it (and a day without power while running the new lines)... At least that magic word was in the script... -- Pete From surfer at mauigateway.com Fri Jan 23 00:26:17 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 22 Jan 2015 16:26:17 -0800 Subject: Comcast Support Message-ID: <20150122162617.F0DDC101@m0005298.ppops.net> --- aaron at heyaaron.com wrote: From: "Aaron C. de Bruyn" http://xkcd.com/806/ Maybe Comcast train the level 1 techs that if someone says "NANOG" you get transferred to someone who knows routing... ;) -------------------------------------------- Then, like the last cell in the comic, you wake up and the real world smacks you right between the eyes before you've waken up all the way. ;-) scott From v.bajpai at jacobs-university.de Fri Jan 23 15:24:33 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Fri, 23 Jan 2015 15:24:33 +0000 Subject: [request]: host a probe for v6 measurements In-Reply-To: References: <8B0BCD73-0EC1-462A-A303-6FA710A237DC@jacobs-university.de> Message-ID: <87B72B70-871A-4C17-A175-F66080F2836A@jacobs-university.de> > On 22 Jan 2015, at 15:27, George, Wes wrote: > > We've seen 3 or 4 recent presentations of some new measurement project > that requires deploying yet another set of dedicated probes. While I'm > generally supportive of measurement attempts, I'll ask the same question > that was asked then: The probes we are shipping are ‘SamKnows' probes. We are not forking a new measurement platform. These probes will be part of SamKnows. I called them LEONE SamKnows probes because in addition to standard SamKnows tests they are also going to run our v6 tests. > Why not use RIPE Atlas? > https://atlas.ripe.net/docs/udm As Randy pointed out, the current built-in set of RIPE Atlas measurement tools do not allow us to make measurements we want to make. We want to measure connect times and achievable throughput over an established TCP connection to live dual-stacked websites and YouTube CDNs. This requires additional tests to be baked in the platform. In efforts to get this accepted, I presented one of ours tests at the RIPE66 meeting in 2013 and received positive feedback [1]. We are working with them to get things accepted. [2] Measuring the Effectiveness of Happy Eyeballs IPv6 Working Group, RIPE66 Dublin, May 2013. https://ripe66.ripe.net/archives/video/1208 > Wes George Best, Vaibhav ===================================================== Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From John_Brzozowski at Cable.Comcast.com Fri Jan 23 17:14:11 2015 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Fri, 23 Jan 2015 17:14:11 +0000 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) Message-ID: Folks, The thread below was sent to me a few times, apologies for not catching it sooner. Janet, I sent you mail unicast with a request for some information. I am happy to help you out. For the larger NANOG audience, Comcast has recently launched IPv6 support for our BCI products, these are our DOCSIS based commercial offerings. This means that if you gateway device is in fact in RG mode you will be delegated a dynamic IPv6 prefix, by default customers are delegated a /56 prefix along with a single IPv6 address that is assigned to the WAN of the gateway device. IPv6 support applies to the following makes and models: SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347) For customers where you bring your own cable modem or have one of the above in bridge mode we have enabled IPv6 support for you as well. However, your router behind the modem must be running software and configured with IPv6 support. Specifically, your router needs to be support stateful DHCPv6 for IPv6 address and prefix acquisition. We have received a number of reports from customers that the Juniper SRX does not appear to properly support IPv6. We are working with Juniper and also recommend that you reach out to Juniper as well. Please keep checking http://www.comcast6.net for updates, we will post some additional information here in the next week or so. In the mean time if you have questions feel free to send me mail or post them here on the NANOG list. HTH, John ========================================= John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozowski at cable.comcast.com ========================================= -----Original Message----- From: "nanog-request at nanog.org" > Reply-To: NANOG > Date: Friday, January 23, 2015 at 07:00 To: NANOG > Subject: NANOG Digest, Vol 84, Issue 23 Date: Thu, 22 Jan 2015 22:42:17 +0000 From: Janet Sullivan > To: "'nanog at nanog.org'" > Subject: Comcast Support Message-ID: > Content-Type: text/plain; charset="us-ascii" I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset my router 4 times while working with Comcast, and I've been told to do things like switch to a static IPv4 address, which shows a level of clue that is scary. And before that they were convinced it was a wireless problem even though I have a wired connection, and told them that multiple times. I've wasted two hours with Comcast today, and even when I asked for escalation I got nothing. Just hung up on. It's honestly the worst customer support I've ever received. I don't think I ever got them to understand the difference between IPv4 and IPv6. From mark.tinka at seacom.mu Fri Jan 23 17:50:50 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 23 Jan 2015 19:50:50 +0200 Subject: Private ASNs in the wild In-Reply-To: <548A20DE.5070901@kenweb.org> References: <548A20DE.5070901@kenweb.org> Message-ID: <4283080.TdjaPLnvj7@the-host.seacom.mu> On Thursday, December 11, 2014 05:55:26 PM ML wrote: > There are sloppy networks out there. If it was a big > enough problem all you'd need is a few key networks drop > those prefixes and we'd have a...slightly less sloppy > Internet? Router software (speaking of Cisco and Juniper in this case) has developed reasonably well that one can now strip private ASN's from the AS_PATH even though they now appear in between public ASN's. This was not possible before, as private AS filtering was only possible if they appeared contiguously in the AS_PATH. Of course, this means running later code - but chances are that if you're running code that supports 4-byte ASN's, you might have this feature. Not sure about other vendors out there. We, for example, remove private ASN's by default on all eBGP sessions. I know several other providers that do the same - but it takes a village to raise the Internet... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From john at op-sec.us Fri Jan 23 18:12:43 2015 From: john at op-sec.us (John Fraizer) Date: Fri, 23 Jan 2015 10:12:43 -0800 Subject: Private ASNs in the wild In-Reply-To: <4283080.TdjaPLnvj7@the-host.seacom.mu> References: <548A20DE.5070901@kenweb.org> <4283080.TdjaPLnvj7@the-host.seacom.mu> Message-ID: Sadly, you don't have to pass any sort of "clue" test to peer in the default-free zone and there are plenty of organizations who simply don't filter properly. Worse yet, it's still illegal to use the bright platinum baseball bat of clue on the perpetrators. ;-) -- John Fraizer LinkedIn profile: http://www.linkedin.com/in/johnfraizer/ From cscora at apnic.net Fri Jan 23 18:12:37 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Jan 2015 04:12:37 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201501231812.t0NICb7W027199@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 24 Jan, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 528233 Prefixes after maximum aggregation (per Origin AS): 202606 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 257973 Total ASes present in the Internet Routing Table: 49174 Prefixes per ASN: 10.74 Origin-only ASes present in the Internet Routing Table: 36416 Origin ASes announcing only one prefix: 16306 Transit ASes present in the Internet Routing Table: 6219 Transit-only ASes present in the Internet Routing Table: 172 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 107 Max AS path prepend of ASN ( 55644) 100 Prefixes from unregistered ASNs in the Routing Table: 1596 Unregistered ASNs in the Routing Table: 414 Number of 32-bit ASNs allocated by the RIRs: 8418 Number of 32-bit ASNs visible in the Routing Table: 6539 Prefixes from 32-bit ASNs in the Routing Table: 23497 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 380 Number of addresses announced to Internet: 2724441252 Equivalent to 162 /8s, 99 /16s and 172 /24s Percentage of available address space announced: 73.6 Percentage of allocated address space announced: 73.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.1 Total number of prefixes smaller than registry allocations: 178139 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 130644 Total APNIC prefixes after maximum aggregation: 38088 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 135622 Unique aggregates announced from the APNIC address blocks: 55421 APNIC Region origin ASes present in the Internet Routing Table: 5014 APNIC Prefixes per ASN: 27.05 APNIC Region origin ASes announcing only one prefix: 1225 APNIC Region transit ASes present in the Internet Routing Table: 871 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1259 Number of APNIC addresses announced to Internet: 741911680 Equivalent to 44 /8s, 56 /16s and 172 /24s Percentage of available APNIC address space announced: 86.7 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, 131072-135580 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: 175163 Total ARIN prefixes after maximum aggregation: 86557 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 177092 Unique aggregates announced from the ARIN address blocks: 82879 ARIN Region origin ASes present in the Internet Routing Table: 16450 ARIN Prefixes per ASN: 10.77 ARIN Region origin ASes announcing only one prefix: 6088 ARIN Region transit ASes present in the Internet Routing Table: 1718 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 19 Number of ARIN region 32-bit ASNs visible in the Routing Table: 328 Number of ARIN addresses announced to Internet: 1060431136 Equivalent to 63 /8s, 52 /16s and 229 /24s Percentage of available ARIN address space announced: 56.1 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, 393216-394239 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: 127767 Total RIPE prefixes after maximum aggregation: 64061 RIPE Deaggregation factor: 1.99 Prefixes being announced from the RIPE address blocks: 133881 Unique aggregates announced from the RIPE address blocks: 82988 RIPE Region origin ASes present in the Internet Routing Table: 17836 RIPE Prefixes per ASN: 7.51 RIPE Region origin ASes announcing only one prefix: 8140 RIPE Region transit ASes present in the Internet Routing Table: 2930 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3377 Number of RIPE addresses announced to Internet: 692903044 Equivalent to 41 /8s, 76 /16s and 220 /24s Percentage of available RIPE address space announced: 100.7 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, 196608-202239 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: 58578 Total LACNIC prefixes after maximum aggregation: 10891 LACNIC Deaggregation factor: 5.38 Prefixes being announced from the LACNIC address blocks: 67832 Unique aggregates announced from the LACNIC address blocks: 31310 LACNIC Region origin ASes present in the Internet Routing Table: 2394 LACNIC Prefixes per ASN: 28.33 LACNIC Region origin ASes announcing only one prefix: 645 LACNIC Region transit ASes present in the Internet Routing Table: 471 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1488 Number of LACNIC addresses announced to Internet: 167735168 Equivalent to 9 /8s, 255 /16s and 111 /24s Percentage of available LACNIC address space announced: 100.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12471 Total AfriNIC prefixes after maximum aggregation: 2965 AfriNIC Deaggregation factor: 4.21 Prefixes being announced from the AfriNIC address blocks: 13426 Unique aggregates announced from the AfriNIC address blocks: 5037 AfriNIC Region origin ASes present in the Internet Routing Table: 739 AfriNIC Prefixes per ASN: 18.17 AfriNIC Region origin ASes announcing only one prefix: 208 AfriNIC Region transit ASes present in the Internet Routing Table: 154 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 87 Number of AfriNIC addresses announced to Internet: 61018368 Equivalent to 3 /8s, 163 /16s and 17 /24s Percentage of available AfriNIC address space announced: 60.6 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 4766 2887 11556 915 Korea Telecom 17974 2846 905 78 PT Telekomunikasi Indonesia 7545 2506 336 128 TPG Telecom Limited 4755 1938 418 194 TATA Communications formerly 4538 1758 4190 71 China Education and Research 9829 1682 1324 32 National Internet Backbone 9808 1524 6719 19 Guangdong Mobile Communicatio 4808 1458 2214 436 CNCGROUP IP network China169 9583 1393 115 572 Sify Limited 9498 1298 336 97 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 2927 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2580 10688 484 Level 3 Communications, Inc. 18566 2043 379 183 MegaPath Corporation 20115 1855 1826 453 Charter Communications 6983 1627 867 245 EarthLink, Inc. 4323 1626 1037 408 tw telecom holdings, inc. 30036 1528 317 532 Mediacom Communications Corp 701 1403 11274 687 MCI Communications Services, 22561 1339 411 241 CenturyTel Internet Holdings, 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 34984 1944 300 358 TELLCOM ILETISIM HIZMETLERI A 20940 1551 605 1152 Akamai International B.V. 8402 1429 544 15 OJSC "Vimpelcom" 6849 1234 356 25 JSC "Ukrtelecom" 31148 1045 45 21 Freenet Ltd. 13188 1038 97 55 TOV "Bank-Inform" 8551 941 373 48 Bezeq International-Ltd 9198 856 349 25 JSC Kazakhtelecom 12479 838 793 84 France Telecom Espana SA 6830 825 2340 445 Liberty Global Operations B.V 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 3068 497 225 Telmex Colombia S.A. 28573 2331 2134 114 NET Servi�os de Comunica��o S 6147 1822 374 30 Telefonica del Peru S.A.A. 7303 1774 1172 237 Telecom Argentina S.A. 8151 1491 3084 431 Uninet S.A. de C.V. 6503 1221 417 56 Axtel, S.A.B. de C.V. 7738 1000 1882 42 Telemar Norte Leste S.A. 26615 912 2325 35 Tim Celular S.A. 3816 902 395 150 COLOMBIA TELECOMUNICACIONES S 18881 857 1036 22 Global Village Telecom 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 8452 1507 958 13 TE-AS 24863 955 284 26 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 373 845 30 ETISALAT MISR 37492 327 144 65 Orange Tunisie 24835 295 144 9 Vodafone Data 3741 249 921 213 Internet Solutions 29571 233 21 12 Cote d'Ivoire Telecom 36947 194 807 13 Telecom Algeria 15706 176 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3068 497 225 Telmex Colombia S.A. 22773 2927 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 4766 2887 11556 915 Korea Telecom 17974 2846 905 78 PT Telekomunikasi Indonesia 3356 2580 10688 484 Level 3 Communications, Inc. 7545 2506 336 128 TPG Telecom Limited 28573 2331 2134 114 NET Servi�os de Comunica��o S 18566 2043 379 183 MegaPath Corporation 34984 1944 300 358 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2891 2840 BellSouth.net Inc. 22773 2927 2786 Cox Communications Inc. 17974 2846 2768 PT Telekomunikasi Indonesia 7545 2506 2378 TPG Telecom Limited 28573 2331 2217 NET Servi�os de Comunica��o S 3356 2580 2096 Level 3 Communications, Inc. 4766 2887 1972 Korea Telecom 18566 2043 1860 MegaPath Corporation 6147 1822 1792 Telefonica del Peru S.A.A. 4755 1938 1744 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.92.160.0/24 14013 EPSON America (Factory Automa 23.92.161.0/24 14013 EPSON America (Factory Automa 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 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:12 /10:32 /11:92 /12:265 /13:502 /14:996 /15:1721 /16:13048 /17:7192 /18:12051 /19:24915 /20:35833 /21:38375 /22:57203 /23:50117 /24:282961 /25:1139 /26:1055 /27:656 /28:17 /29:14 /30:10 /31:0 /32:11 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2141 2927 Cox Communications Inc. 18566 1998 2043 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1373 1528 Mediacom Communications Corp 6147 1366 1822 Telefonica del Peru S.A.A. 6983 1314 1627 EarthLink, Inc. 34984 1248 1944 TELLCOM ILETISIM HIZMETLERI A 11492 1128 1187 CABLE ONE, INC. 8402 1097 1429 OJSC "Vimpelcom" 10620 1094 3068 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1462 2:672 3:1 4:95 5:1216 6:21 8:1401 11:1 12:1845 13:4 14:1255 15:17 16:2 17:43 18:21 20:50 23:1094 24:1682 27:1844 31:1473 32:39 33:2 34:5 35:2 36:133 37:1892 38:970 39:13 40:230 41:3027 42:261 43:934 44:23 45:95 46:2118 47:34 49:783 50:789 52:12 54:66 55:6 56:8 57:32 58:1193 59:681 60:454 61:1759 62:1303 63:1905 64:4407 65:2268 66:4085 67:2018 68:1040 69:3269 70:904 71:431 72:1971 74:2619 75:314 76:414 77:1453 78:1281 79:790 80:1311 81:1300 82:786 83:668 84:673 85:1303 86:389 87:1164 88:517 89:1781 90:139 91:5903 92:799 93:1707 94:1931 95:1329 96:413 97:335 98:1038 99:46 100:75 101:800 103:6565 104:1123 105:56 106:200 107:888 108:608 109:2018 110:1066 111:1463 112:746 113:980 114:819 115:1251 116:1310 117:1015 118:1698 119:1396 120:447 121:1013 122:2179 123:1714 124:1492 125:1518 128:642 129:376 130:382 131:1077 132:453 133:167 134:389 135:88 136:333 137:297 138:408 139:173 140:221 141:412 142:621 143:450 144:521 145:112 146:712 147:572 148:1063 149:414 150:555 151:742 152:482 153:246 154:302 155:708 156:397 157:328 158:264 159:956 160:367 161:630 162:1873 163:382 164:651 165:665 166:320 167:701 168:1001 169:140 170:1431 171:223 172:47 173:1587 174:706 175:612 176:1469 177:3613 178:2092 179:848 180:1860 181:1622 182:1696 183:575 184:734 185:2701 186:2678 187:1739 188:2020 189:1543 190:7907 191:835 192:8052 193:5555 194:4053 195:3631 196:1700 197:874 198:5450 199:5508 200:6480 201:2911 202:9506 203:9085 204:4656 205:2714 206:3006 207:2969 208:3939 209:3865 210:3494 211:1836 212:2484 213:2267 214:838 215:69 216:5528 217:1800 218:668 219:463 220:1322 221:795 222:464 223:644 End of report From John_Brzozowski at Cable.Comcast.com Fri Jan 23 18:27:38 2015 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Fri, 23 Jan 2015 18:27:38 +0000 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: References: Message-ID: Correct link for Cisco is updated below. John From: , John Brzozowski > Date: Friday, January 23, 2015 at 12:14 To: NANOG > Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) Folks, The thread below was sent to me a few times, apologies for not catching it sooner. Janet, I sent you mail unicast with a request for some information. I am happy to help you out. For the larger NANOG audience, Comcast has recently launched IPv6 support for our BCI products, these are our DOCSIS based commercial offerings. This means that if you gateway device is in fact in RG mode you will be delegated a dynamic IPv6 prefix, by default customers are delegated a /56 prefix along with a single IPv6 address that is assigned to the WAN of the gateway device. IPv6 support applies to the following makes and models: SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347) Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=407) For customers where you bring your own cable modem or have one of the above in bridge mode we have enabled IPv6 support for you as well. However, your router behind the modem must be running software and configured with IPv6 support. Specifically, your router needs to be support stateful DHCPv6 for IPv6 address and prefix acquisition. We have received a number of reports from customers that the Juniper SRX does not appear to properly support IPv6. We are working with Juniper and also recommend that you reach out to Juniper as well. Please keep checking http://www.comcast6.net for updates, we will post some additional information here in the next week or so. In the mean time if you have questions feel free to send me mail or post them here on the NANOG list. HTH, John ========================================= John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozowski at cable.comcast.com ========================================= -----Original Message----- From: "nanog-request at nanog.org" > Reply-To: NANOG > Date: Friday, January 23, 2015 at 07:00 To: NANOG > Subject: NANOG Digest, Vol 84, Issue 23 Date: Thu, 22 Jan 2015 22:42:17 +0000 From: Janet Sullivan > To: "'nanog at nanog.org'" > Subject: Comcast Support Message-ID: > Content-Type: text/plain; charset="us-ascii" I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset my router 4 times while working with Comcast, and I've been told to do things like switch to a static IPv4 address, which shows a level of clue that is scary. And before that they were convinced it was a wireless problem even though I have a wired connection, and told them that multiple times. I've wasted two hours with Comcast today, and even when I asked for escalation I got nothing. Just hung up on. It's honestly the worst customer support I've ever received. I don't think I ever got them to understand the difference between IPv4 and IPv6. From dmburgess at linktechs.net Fri Jan 23 18:36:27 2015 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 23 Jan 2015 12:36:27 -0600 Subject: Verizion FiOS Message-ID: <674E0B100B12BC41BEC7873AFD8B6900200D93@03-exchange.lti.local> Got a customer that needs a /25 block routed to him, was approved for "125" IPs, but they refuse to route a block to the customer. Any assistance, please hit me off-list, dmburgess at linktechs.net Thanks, www.linktechs.net - 314-735-0270 - dmburgess at linktechs.net From morrowc.lists at gmail.com Fri Jan 23 20:45:44 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 23 Jan 2015 15:45:44 -0500 Subject: Verizion FiOS In-Reply-To: <674E0B100B12BC41BEC7873AFD8B6900200D93@03-exchange.lti.local> References: <674E0B100B12BC41BEC7873AFD8B6900200D93@03-exchange.lti.local> Message-ID: Don't they just say: "125 ips" and route (they used to) each /32 to the VC that represnets the customer in question... They don't actually route a /25, they route the individual /32's to the LAN that is presented on the end of the fiber. good luck! On Fri, Jan 23, 2015 at 1:36 PM, Dennis Burgess wrote: > Got a customer that needs a /25 block routed to him, was approved for > "125" IPs, but they refuse to route a block to the customer. Any > assistance, please hit me off-list, dmburgess at linktechs.net > > > > > > Thanks, > > > > > > www.linktechs.net - 314-735-0270 - dmburgess at linktechs.net > > > From bill at herrin.us Fri Jan 23 21:54:25 2015 From: bill at herrin.us (William Herrin) Date: Fri, 23 Jan 2015 16:54:25 -0500 Subject: Verizion FiOS In-Reply-To: <674E0B100B12BC41BEC7873AFD8B6900200D93@03-exchange.lti.local> References: <674E0B100B12BC41BEC7873AFD8B6900200D93@03-exchange.lti.local> Message-ID: On Fri, Jan 23, 2015 at 1:36 PM, Dennis Burgess wrote: > Got a customer that needs a /25 block routed to him, was approved for > "125" IPs, but they refuse to route a block to the customer. Any > assistance, please hit me off-list, dmburgess at linktechs.net That's just how Verizon does things. Often linear addresses on no particular CIDR boundary. Just use proxy arp to bring the addresses in to the border router and then route as normal. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From cidr-report at potaroo.net Fri Jan 23 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Jan 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201501232200.t0NM00dB076121@wattle.apnic.net> This report has been generated at Fri Jan 23 21:14:26 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 16-01-15 533401 293377 17-01-15 532425 293220 18-01-15 533071 292994 19-01-15 533028 293344 20-01-15 533524 293232 21-01-15 533599 293543 22-01-15 534062 293703 23-01-15 534248 293834 AS Summary 49418 Number of ASes in routing system 19834 Number of ASes announcing only one prefix 3068 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120442368 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 23Jan15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 534049 293876 240173 45.0% All ASes AS6389 2890 71 2819 97.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2931 172 2759 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2847 90 2757 96.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS28573 2332 309 2023 86.7% NET Servi�os de Comunica��o S.A.,BR AS3356 2583 721 1862 72.1% LEVEL3 - Level 3 Communications, Inc.,US AS6147 1822 162 1660 91.1% Telefonica del Peru S.A.A.,PE AS4755 1937 287 1650 85.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2889 1288 1601 55.4% KIXS-AS-KR Korea Telecom,KR AS7303 1777 295 1482 83.4% Telecom Argentina S.A.,AR AS9808 1523 55 1468 96.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 3068 1652 1416 46.2% Telmex Colombia S.A.,CO AS8402 1417 25 1392 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1856 526 1330 71.7% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2519 1231 1288 51.1% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1633 410 1223 74.9% TWTC - tw telecom holdings, inc.,US AS9498 1299 116 1183 91.1% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2042 869 1173 57.4% MEGAPATH5-US - MegaPath Corporation,US AS6849 1231 134 1097 89.1% UKRTELNET JSC UKRTELECOM,UA AS7552 1111 51 1060 95.4% VIETEL-AS-AP Viettel Corporation,VN AS22561 1339 281 1058 79.0% AS22561 - CenturyTel Internet Holdings, Inc.,US AS34984 1944 886 1058 54.4% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS6983 1627 637 990 60.8% ITCDELTA - Earthlink, Inc.,US AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1776 957 819 46.1% ERX-CERNET-BKB China Education and Research Network Center,CN AS8551 1110 314 796 71.7% BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone,IL AS24560 1200 421 779 64.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS26615 912 138 774 84.9% Tim Celular S.A.,BR AS4780 1072 301 771 71.9% SEEDNET Digital United Inc.,TW AS855 815 57 758 93.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA Total 53485 12653 40832 76.3% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.92.160.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.92.161.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.59.64.0/20 AS40440 CENTARRA - Centarra Networks Inc.,US 62.122.74.0/23 AS5577 ROOT root SA,LU 64.18.128.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 64.187.208.0/24 AS174 COGENT-174 - Cogent Communications,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.48.168.0/24 AS13242 TELECOM-HK Hong Kong Telecom Global Data Centre,HK 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.252.116.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.85.84.0/22 AS39458 REALHOSTS-AS Real Hosts Limited,GB 185.85.108.0/22 AS51395 AS-SOFTPLUS SOFTplus Entwicklungen GmbH,CH 185.85.112.0/22 AS41887 PROLOCATION Prolocation AS,NL 185.85.112.0/23 AS41887 PROLOCATION Prolocation AS,NL 185.85.114.0/23 AS41887 PROLOCATION Prolocation AS,NL 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.106.32.0/22 AS49873 -Reserved AS-,ZZ 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.18.0/24 AS33790 FINANT-MEXCOM,ZZ 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.61.108.0/24 AS55812 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.8.216.0/21 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 204.8.217.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 204.8.218.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 204.8.222.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 209.250.224.0/22 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.224.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.225.0/24 AS14037 AS-DZ-14037 - Dedicated Zone Inc,US 209.250.230.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 209.250.253.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 209.250.254.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,US 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 23 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Jan 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201501232200.t0NM02ru076136@wattle.apnic.net> BGP Update Report Interval: 15-Jan-15 -to- 22-Jan-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS38623 2053233 30.3% 8927.1 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 2 - AS23752 337342 5.0% 2426.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS9829 251094 3.7% 216.8 -- BSNL-NIB National Internet Backbone,IN 4 - AS53249 91826 1.4% 45913.0 -- LAWA-AS - Los Angeles World Airport,US 5 - AS45786 89535 1.3% 1209.9 -- HTSNET-AS-ID HTSNET - ISP,ID 6 - AS45899 73870 1.1% 114.7 -- VNPT-AS-VN VNPT Corp,VN 7 - AS35908 69229 1.0% 104.6 -- VPLSNET - Krypt Technologies,US 8 - AS53563 58186 0.9% 14546.5 -- XPLUSONE - X Plus One Solutions, Inc.,US 9 - AS17974 39370 0.6% 15.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 10 - AS28642 35295 0.5% 1008.4 -- Contato Internet Ltda EPP,BR 11 - AS27738 32694 0.5% 41.9 -- Ecuadortelecom S.A.,EC 12 - AS8402 31426 0.5% 97.3 -- CORBINA-AS OJSC "Vimpelcom",RU 13 - AS14840 30872 0.5% 882.1 -- COMMCORP COMUNICACOES LTDA,BR 14 - AS28573 29314 0.4% 12.3 -- NET Servi�os de Comunica��o S.A.,BR 15 - AS60725 26669 0.4% 5333.8 -- O3B-AS O3b Limited,JE 16 - AS48159 23597 0.3% 79.7 -- TIC-AS Telecommunication Infrastructure Company,IR 17 - AS1756 23395 0.3% 359.9 -- HAMYAR-AS Shiraz Hamyar Co.,IR 18 - AS10620 22650 0.3% 11.4 -- Telmex Colombia S.A.,CO 19 - AS23342 22089 0.3% 22089.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 20 - AS262617 21681 0.3% 1548.6 -- UWBR Telecomunica��es Ltda,BR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS53249 91826 1.4% 45913.0 -- LAWA-AS - Los Angeles World Airport,US 2 - AS23342 22089 0.3% 22089.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 3 - AS49128 20577 0.3% 20577.0 -- IVCSPBORW-AS OAO Russian Railway,RU 4 - AS53563 58186 0.9% 14546.5 -- XPLUSONE - X Plus One Solutions, Inc.,US 5 - AS25003 19209 0.3% 9604.5 -- INTERNET_BINAT Internet Binat Ltd,IL 6 - AS54465 9339 0.1% 9339.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 7 - AS38623 2053233 30.3% 8927.1 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 8 - AS197914 20872 0.3% 6957.3 -- STOCKHO-AS Stockho Hosting SARL,FR 9 - AS18135 11708 0.2% 5854.0 -- BTV BTV Cable television,JP 10 - AS60725 26669 0.4% 5333.8 -- O3B-AS O3b Limited,JE 11 - AS33721 4390 0.1% 4390.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 12 - AS18680 19699 0.3% 3283.2 -- AKAMAI-AS - Akamai Technologies, Inc.,US 13 - AS62174 2648 0.0% 2648.0 -- INTERPAN-AS INTERPAN LTD.,BG 14 - AS25563 7571 0.1% 2523.7 -- WEBLAND-AS Webland AG, Autonomous System,CH 15 - AS23752 337342 5.0% 2426.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 16 - AS47680 11962 0.2% 2392.4 -- NHCS EOBO Limited,IE 17 - AS29508 2138 0.0% 2138.0 -- TANAT-AS TANAT LLC,UA 18 - AS45606 10441 0.1% 2088.2 -- 19 - AS198053 2038 0.0% 2038.0 -- AMTEL VECTRA S.A.,PL 20 - AS32097 2005 0.0% 2005.0 -- WII-KC - WholeSale Internet, Inc.,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 171988 2.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 163041 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.61.101.0/24 88535 1.3% AS45786 -- HTSNET-AS-ID HTSNET - ISP,ID 4 - 199.38.164.0/23 58175 0.8% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 5 - 198.140.115.0/24 45917 0.7% AS53249 -- LAWA-AS - Los Angeles World Airport,US 6 - 198.140.114.0/24 45909 0.7% AS53249 -- LAWA-AS - Los Angeles World Airport,US 7 - 64.29.130.0/24 22089 0.3% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 8 - 130.0.192.0/21 20868 0.3% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 9 - 91.212.146.0/24 20577 0.3% AS49128 -- IVCSPBORW-AS OAO Russian Railway,RU 10 - 192.115.44.0/22 19207 0.3% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 11 - 36.37.136.0/24 19088 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 12 - 36.37.128.0/23 19072 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 13 - 36.37.135.0/24 19059 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 14 - 36.37.176.0/24 19044 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 15 - 36.37.232.0/24 19035 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 16 - 36.37.144.0/22 19029 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 17 - 36.37.152.0/24 19025 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 18 - 36.37.192.0/21 19016 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 19 - 36.37.137.0/24 19016 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH 20 - 36.37.130.0/23 19005 0.3% AS38623 -- VIETTELCAMBODIA-AS-AP ISP/IXP IN CAMBODIA WITH THE BEST VERVICE IN THERE.,KH Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From ordinarybluethread at gmail.com Fri Jan 23 00:15:11 2015 From: ordinarybluethread at gmail.com (Matoi T.) Date: Thu, 22 Jan 2015 16:15:11 -0800 Subject: Actiontec contact for vulnerability disclosure Message-ID: During testing I found a security issue with an ISP-provided Actiontec DSL CPE device (model PK5000) and was wondering if anyone had a contact at Actiontec that I could properly disclose this vulnerability to. -- M. From dave at temk.in Sat Jan 24 23:02:24 2015 From: dave at temk.in (Dave Temkin) Date: Sat, 24 Jan 2015 18:02:24 -0500 Subject: Verizion FiOS In-Reply-To: <674E0B100B12BC41BEC7873AFD8B6900200D93@03-exchange.lti.local> References: <674E0B100B12BC41BEC7873AFD8B6900200D93@03-exchange.lti.local> Message-ID: Quite simple - Verizon doesn't offer BGP or any other type of custom service over FIOS. No Layer 2, no non-VZ Layer 3, etc... You get the IP space you pay for from them (per IP). -Dave On Fri, Jan 23, 2015 at 1:36 PM, Dennis Burgess wrote: > Got a customer that needs a /25 block routed to him, was approved for > "125" IPs, but they refuse to route a block to the customer. Any > assistance, please hit me off-list, dmburgess at linktechs.net > > > > > > Thanks, > > > > > > www.linktechs.net - 314-735-0270 - dmburgess at linktechs.net > > > > From dmburgess at linktechs.net Sat Jan 24 23:09:01 2015 From: dmburgess at linktechs.net (Dennis Burgess) Date: Sat, 24 Jan 2015 17:09:01 -0600 Subject: Verizion FiOS References: <674E0B100B12BC41BEC7873AFD8B6900200D93@03-exchange.lti.local> Message-ID: <674E0B100B12BC41BEC7873AFD8B6900200DD3@03-exchange.lti.local> Yep, what we found. The customer is going to have to look elsewhere for their 500meg L Just won’t work for what they are doing.. TWC even will route them block L Dennis Burgess, Link Technologies, Inc. 314-735-0270 From: Dave Temkin [mailto:dave at temk.in] Sent: Saturday, January 24, 2015 5:02 PM To: Dennis Burgess Cc: North American Network Operators' Group Subject: Re: Verizion FiOS Quite simple - Verizon doesn't offer BGP or any other type of custom service over FIOS. No Layer 2, no non-VZ Layer 3, etc... You get the IP space you pay for from them (per IP). -Dave On Fri, Jan 23, 2015 at 1:36 PM, Dennis Burgess wrote: Got a customer that needs a /25 block routed to him, was approved for "125" IPs, but they refuse to route a block to the customer. Any assistance, please hit me off-list, dmburgess at linktechs.net Thanks, www.linktechs.net - 314-735-0270 - dmburgess at linktechs.net From jra at baylink.com Sun Jan 25 14:37:57 2015 From: jra at baylink.com (Jay Ashworth) Date: Sun, 25 Jan 2015 09:37:57 -0500 Subject: REMINDER: Leap Second Message-ID: <194715CB-3779-428C-A6C1-5444A5902E69@baylink.com> This June 30th, 235959UTC will be followed immediately by 235960UTC. What will /your/ devices do? http://www.marketplace.org/topics/world/leap-second-deep-space-and-how-we-keep-time Cheers, -- jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From the.lists at mgm51.com Sun Jan 25 15:19:29 2015 From: the.lists at mgm51.com (Mike.) Date: Sun, 25 Jan 2015 10:19:29 -0500 Subject: REMINDER: Leap Second In-Reply-To: <194715CB-3779-428C-A6C1-5444A5902E69@baylink.com> References: <194715CB-3779-428C-A6C1-5444A5902E69@baylink.com> Message-ID: <201501251019290550.005C05BC@smtp.24cl.home> On 1/25/2015 at 9:37 AM Jay Ashworth wrote: |This June 30th, 235959UTC will be followed immediately by 235960UTC. | |What will /your/ devices do? ============= I've always wondered why this is such a big issue, and why it's done as it is. In UNIX, for instance, time is measured as the number of seconds since the UNIX epoch. imo, the counting of the number of seconds should not be "adjusted", unless there's a time warp of some sort. The leap second adjustment should be in the display of the time, i.e., similar to how time zones are handled. fwiw From karsten.elfenbein at gmail.com Sun Jan 25 17:01:40 2015 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Sun, 25 Jan 2015 18:01:40 +0100 Subject: REMINDER: Leap Second In-Reply-To: <201501251019290550.005C05BC@smtp.24cl.home> References: <194715CB-3779-428C-A6C1-5444A5902E69@baylink.com> <201501251019290550.005C05BC@smtp.24cl.home> Message-ID: Hi, Java had some issues with 100% CPU usage when NTP was running during the additional second in 2012. http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix/ Google did something different to get the extra second in: http://googleblog.blogspot.de/2011/09/time-technology-and-leaping-seconds.html Most devices probably don't even know about the leap second coming as that would require a firmware upgrade. Karsten 2015-01-25 16:19 GMT+01:00 Mike. : > On 1/25/2015 at 9:37 AM Jay Ashworth wrote: > > |This June 30th, 235959UTC will be followed immediately by 235960UTC. > | > |What will /your/ devices do? > ============= > > > I've always wondered why this is such a big issue, and why it's done > as it is. > > In UNIX, for instance, time is measured as the number of seconds > since the UNIX epoch. imo, the counting of the number of seconds > should not be "adjusted", unless there's a time warp of some sort. > The leap second adjustment should be in the display of the time, > i.e., similar to how time zones are handled. > > > fwiw > > > From math at sizone.org Sun Jan 25 17:26:27 2015 From: math at sizone.org (Ken Chase) Date: Sun, 25 Jan 2015 12:26:27 -0500 Subject: REMINDER: Leap Second In-Reply-To: References: <194715CB-3779-428C-A6C1-5444A5902E69@baylink.com> <201501251019290550.005C05BC@smtp.24cl.home> Message-ID: <20150125172627.GM24849@sizone.org> I think devices would likely be fine, unless they're concerned with reconciling a leap-second updated ntp source and one that's not. Who wins? For most NTPs I would guess they're slaves to whatever feed and just 'believe' whatever they're told. (Sounds like a security hole waiting for high frequency trader types, q.v. http://www.theverge.com/2013/10/3/4798542/whats-faster-than-a-light-speed-trade-inside-the-sketchy-world-of ) Can't we just subscribe to a leapsmeary NTP feed if we care to have no big leap (I dont mind)? Isnt NIST offering this? /kc On Sun, Jan 25, 2015 at 06:01:40PM +0100, Karsten Elfenbein said: >Hi, > >Java had some issues with 100% CPU usage when NTP was running during >the additional second in 2012. >http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix/ > >Google did something different to get the extra second in: >http://googleblog.blogspot.de/2011/09/time-technology-and-leaping-seconds.html > >Most devices probably don't even know about the leap second coming as >that would require a firmware upgrade. > > >Karsten > >2015-01-25 16:19 GMT+01:00 Mike. : >> On 1/25/2015 at 9:37 AM Jay Ashworth wrote: >> >> |This June 30th, 235959UTC will be followed immediately by 235960UTC. >> | >> |What will /your/ devices do? >> ============= >> >> >> I've always wondered why this is such a big issue, and why it's done >> as it is. >> >> In UNIX, for instance, time is measured as the number of seconds >> since the UNIX epoch. imo, the counting of the number of seconds >> should not be "adjusted", unless there's a time warp of some sort. >> The leap second adjustment should be in the display of the time, >> i.e., similar to how time zones are handled. >> >> >> fwiw >> >> >> -- Ken Chase - math at sizone.org Toronto From johnl at iecc.com Sun Jan 25 17:29:25 2015 From: johnl at iecc.com (John Levine) Date: 25 Jan 2015 17:29:25 -0000 Subject: REMINDER: Leap Second In-Reply-To: <201501251019290550.005C05BC@smtp.24cl.home> Message-ID: <20150125172925.9654.qmail@ary.lan> In article <201501251019290550.005C05BC at smtp.24cl.home> you write: >I've always wondered why this is such a big issue, and why it's done >as it is. A lot of people don't think the current approach is so great. >In UNIX, for instance, time is measured as the number of seconds >since the UNIX epoch. imo, the counting of the number of seconds >should not be "adjusted", unless there's a time warp of some sort. >The leap second adjustment should be in the display of the time, >i.e., similar to how time zones are handled. It shares with time zones the problem that you cannot tell what the UNIX timestamp will be for a particular future time. If you want to have something happen at, say, July 2 2025 at 12:00 UTC you can guess what the timstamp for that will be, but if there's another leapsecond or two, you'll be wrong. Life would be a lot easier for everyone except a handful of astronomers if we forgot about leap seconds and adjusted by a full minute every couple of centuries. From Valdis.Kletnieks at vt.edu Sun Jan 25 18:15:27 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 25 Jan 2015 13:15:27 -0500 Subject: REMINDER: Leap Second In-Reply-To: Your message of "25 Jan 2015 17:29:25 +0000." <20150125172925.9654.qmail@ary.lan> References: <20150125172925.9654.qmail@ary.lan> Message-ID: <98940.1422209727@turing-police.cc.vt.edu> On 25 Jan 2015 17:29:25 +0000, "John Levine" said: > It shares with time zones the problem that you cannot tell what > the UNIX timestamp will be for a particular future time. If > you want to have something happen at, say, July 2 2025 at 12:00 UTC > you can guess what the timstamp for that will be, but if there's > another leapsecond or two, you'll be wrong. It shares another problem - that doing calculations across a boundary is difficult. If you have a recurring timer that pops at 23:58:30 on June 30, and you want another one in 2 minutes. do you want a timer that the next pop is at 00:00:30 - or 00:00:29? The operating system can't tell whether the desired semantic is "as close to every 120 elapsed seconds as possible" or "as close to the half-minute tick as possible". And of course doing interval math across several years where you cross multiple leap seconds is even more problematic - for some corner cases that have an endppoint nearmidnight, doing a naive "timestamp in seconds +/- 86400 * number of days" can land you on the wrong *day*, with possibly serious consequences... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From math at sizone.org Sun Jan 25 18:31:36 2015 From: math at sizone.org (Ken Chase) Date: Sun, 25 Jan 2015 13:31:36 -0500 Subject: REMINDER: Leap Second In-Reply-To: <98940.1422209727@turing-police.cc.vt.edu> References: <20150125172925.9654.qmail@ary.lan> <98940.1422209727@turing-police.cc.vt.edu> Message-ID: <20150125183135.GO24849@sizone.org> the quote from the GNU coreutils manpages on Date Input Formats: "Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible. Indeed, had some tyrannical god contrived to enslave our minds to time, to make it all but impossible for us to escape subjection to sodden routines and unpleasant surprises, he could hardly have done better than handing down our present system. It is like a set of trapezoidal building blocks, with no vertical or horizontal surfaces, like a language in which the simplest thought demands ornate constructions, useless particles and lengthy circumlocutions. Unlike the more successful patterns of language and science, which enable us to face experience boldly or at least level-headedly, our system of temporal calculation silently and persistently encourages our terror of time. ... It is as though architects had to measure length in feet, width in meters and height in ells; as though basic instruction manuals demanded a knowledge of five different languages. It is no wonder then that we often look into our own immediate past or future, last Tuesday or a week from Sunday, with feelings of helpless confusion." -Robert Grudin, Time and the Art of Living. http://www.gnu.org/software/coreutils/manual/coreutils.html#Date-input-formats /kc On Sun, Jan 25, 2015 at 01:15:27PM -0500, Valdis.Kletnieks at vt.edu said: > >And of course doing interval math across several years where you cross multiple >leap seconds is even more problematic - for some corner cases that have an >endppoint nearmidnight, doing a naive "timestamp in seconds +/- 86400 * number >of days" can land you on the wrong *day*, with possibly serious consequences... > /kc -- Ken Chase - math at sizone.org Toronto From jsklein at gmail.com Sun Jan 25 21:17:33 2015 From: jsklein at gmail.com (Joe Klein) Date: Sun, 25 Jan 2015 16:17:33 -0500 Subject: REMINDER: Leap Second In-Reply-To: <20150125172627.GM24849@sizone.org> References: <194715CB-3779-428C-A6C1-5444A5902E69@baylink.com> <201501251019290550.005C05BC@smtp.24cl.home> <20150125172627.GM24849@sizone.org> Message-ID: I spoke on time hacking and ntp 3 years ago at shmoocon. On Jan 25, 2015 12:28 PM, "Ken Chase" wrote: > I think devices would likely be fine, unless they're concerned with > reconciling > a leap-second updated ntp source and one that's not. Who wins? > > For most NTPs I would guess they're slaves to whatever feed and just > 'believe' > whatever they're told. (Sounds like a security hole waiting for high > frequency > trader types, q.v. > > http://www.theverge.com/2013/10/3/4798542/whats-faster-than-a-light-speed-trade-inside-the-sketchy-world-of > ) > > Can't we just subscribe to a leapsmeary NTP feed if we care to have no > big leap (I dont mind)? Isnt NIST offering this? > > /kc > > > On Sun, Jan 25, 2015 at 06:01:40PM +0100, Karsten Elfenbein said: > >Hi, > > > >Java had some issues with 100% CPU usage when NTP was running during > >the additional second in 2012. > > > http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix/ > > > >Google did something different to get the extra second in: > > > http://googleblog.blogspot.de/2011/09/time-technology-and-leaping-seconds.html > > > >Most devices probably don't even know about the leap second coming as > >that would require a firmware upgrade. > > > > > >Karsten > > > >2015-01-25 16:19 GMT+01:00 Mike. : > >> On 1/25/2015 at 9:37 AM Jay Ashworth wrote: > >> > >> |This June 30th, 235959UTC will be followed immediately by 235960UTC. > >> | > >> |What will /your/ devices do? > >> ============= > >> > >> > >> I've always wondered why this is such a big issue, and why it's done > >> as it is. > >> > >> In UNIX, for instance, time is measured as the number of seconds > >> since the UNIX epoch. imo, the counting of the number of seconds > >> should not be "adjusted", unless there's a time warp of some sort. > >> The leap second adjustment should be in the display of the time, > >> i.e., similar to how time zones are handled. > >> > >> > >> fwiw > >> > >> > >> > > -- > Ken Chase - math at sizone.org Toronto > From list at satchell.net Sun Jan 25 22:24:52 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 25 Jan 2015 14:24:52 -0800 Subject: REMINDER: Leap Second In-Reply-To: <98940.1422209727@turing-police.cc.vt.edu> References: <20150125172925.9654.qmail@ary.lan> <98940.1422209727@turing-police.cc.vt.edu> Message-ID: <54C56D34.9050403@satchell.net> On 01/25/2015 10:15 AM, Valdis.Kletnieks at vt.edu wrote: > It shares another problem - that doing calculations across a boundary is > difficult. If you have a recurring timer that pops at 23:58:30 on June 30, > and you want another one in 2 minutes. do you want a timer that the next pop > is at 00:00:30 - or 00:00:29? The operating system can't tell whether the > desired semantic is "as close to every 120 elapsed seconds as possible" or > "as close to the half-minute tick as possible". I have automation code for a "classroom" full of Cisco routers, and the way I deal with that sort of issue is to say that anything that has to be synchronized to the wall clock uses cron(8), but for actions tied to a fixed interval I use sleep(3) and let the operating system sort out the issues, if any. I did this to sidestep the issues with Daylight Savings Time (DST) cusps; it also works for leapseconds, as the OS interval timing is not tied to the real-time clock. Funny you should mention ticks versus elapsed time. In every specification I've written since 1970, I've differentiated between the two. I got started doing that because in the computers of that era the real-time clock was tied to power-line frequency, while the interval timers were based on counts on a crystal oscillator. The crystal was using good for 1000 parts per million, good enough for short intervals. The power-line clock was pulled back and forth by the power company as said company would fine-tune the time so electric clocks would stay at the right time long-term as the expense of short-term jitter. Today's computers don't use clocks derived from 50- or 60-hertz power-line frequency. The last computer I remember seeing with such a clock was the IBM System/360. The System/370 used a motor-generator set for the power supply, so it had to get its real-time clock time source another way. From barney at databus.com Sun Jan 25 23:06:49 2015 From: barney at databus.com (Barney Wolff) Date: Sun, 25 Jan 2015 18:06:49 -0500 Subject: REMINDER: Leap Second In-Reply-To: <54C56D34.9050403@satchell.net> References: <20150125172925.9654.qmail@ary.lan> <98940.1422209727@turing-police.cc.vt.edu> <54C56D34.9050403@satchell.net> Message-ID: <20150125230649.GA90136@pit.databus.com> On Sun, Jan 25, 2015 at 02:24:52PM -0800, Stephen Satchell wrote: > > Today's computers don't use clocks derived from 50- or 60-hertz > power-line frequency. The last computer I remember seeing with such a > clock was the IBM System/360. The System/370 used a motor-generator set > for the power supply, so it had to get its real-time clock time source > another way. The 360/95 and /91 also used 400 Hz from a motor/gen. Water cooled, too. One of my fondest war stories is when the power was turned off for July 4th weekend but the water was left on. From tshaw at oitc.com Sun Jan 25 23:42:51 2015 From: tshaw at oitc.com (TR Shaw) Date: Sun, 25 Jan 2015 18:42:51 -0500 Subject: REMINDER: Leap Second In-Reply-To: <20150125230649.GA90136@pit.databus.com> References: <20150125172925.9654.qmail@ary.lan> <98940.1422209727@turing-police.cc.vt.edu> <54C56D34.9050403@satchell.net> <20150125230649.GA90136@pit.databus.com> Message-ID: On Jan 25, 2015, at 6:06 PM, Barney Wolff wrote: > On Sun, Jan 25, 2015 at 02:24:52PM -0800, Stephen Satchell wrote: >> >> Today's computers don't use clocks derived from 50- or 60-hertz >> power-line frequency. The last computer I remember seeing with such a >> clock was the IBM System/360. The System/370 used a motor-generator set >> for the power supply, so it had to get its real-time clock time source >> another way. > > The 360/95 and /91 also used 400 Hz from a motor/gen. Water cooled, too. > One of my fondest war stories is when the power was turned off for July 4th > weekend but the water was left on. That made the transformers smaller/cooler and more efficient. I seem to remember a 195 as well but maybe it is just CRS. From barney at databus.com Mon Jan 26 08:36:41 2015 From: barney at databus.com (Barney Wolff) Date: Mon, 26 Jan 2015 03:36:41 -0500 Subject: REMINDER: Leap Second In-Reply-To: References: <20150125172925.9654.qmail@ary.lan> <98940.1422209727@turing-police.cc.vt.edu> <54C56D34.9050403@satchell.net> <20150125230649.GA90136@pit.databus.com> Message-ID: <20150126083641.GA47009@pit.databus.com> On Sun, Jan 25, 2015 at 06:42:51PM -0500, TR Shaw wrote: > > That made the transformers smaller/cooler and more efficient. I seem to remember a 195 as well but maybe it is just CRS. Google says the 360/195 did exist. But my baby was the 360/95, where the first megabyte of memory was flat-film at 60ns, which made it faster than the 195 for some things. It was incredibly expensive to build - we heard rumors of $30 million in 1967 dollars, and sold to NASA at a huge loss, which is why there were only two built. I used to amuse myself by climbing into the flats memory cabinet, and was amused again some years later when I could have ingested a megabyte without harm. Ours sat directly above Tom's Restaurant, of Seinfeld fame. Very early climate modeling was done on that machine, along with a lot of astrophysics. From patrick at ianai.net Mon Jan 26 11:10:51 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 26 Jan 2015 06:10:51 -0500 Subject: Peering Track: Peering Personals - any new peers out there? Message-ID: Everyone: As the NANOG 63 Peering Track moderator, I would like to make a call for "Peering Personals". This time around, I would like to limit the Personals to "new" - networks new to peering, existing networks with new locations, changes to peering policies, turning up v6 peering, etc. If you or your network would like to announce something "new" at the N63 Peering Track, please ping me off-list and I'll ensure there is time for your presentation. Thank you! -- TTFN, patrick From rafael.ribeiro at rnp.br Mon Jan 26 16:00:28 2015 From: rafael.ribeiro at rnp.br (Rafael de Oliveira Ribeiro) Date: Mon, 26 Jan 2015 14:00:28 -0200 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 24) In-Reply-To: References: Message-ID: <54C6649C.7030201@rnp.br> Dear John, On 24/01/2015 10:00, nanog-request at nanog.org wrote: (...) > Date: Fri, 23 Jan 2015 17:14:11 +0000 > From: "Brzozowski, John" > To: "nanog at nanog.org" > Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) > Message-ID: > Content-Type: text/plain; charset="utf-8" (...) > For customers where you bring your own cable modem or have one of the above in bridge mode we have enabled IPv6 support for you as well. However, your router behind the modem must be running software and configured with IPv6 support. Specifically, your router needs to be support stateful DHCPv6 for IPv6 address and prefix acquisition. We have received a number of reports from customers that the Juniper SRX does not appear to properly support IPv6. We are working with Juniper and also recommend that you reach out to Juniper as well. (...) Care to share scenarios where the SRXs do not perform well with DHCPv6? Any specific model? Thanks in advance, -- Rafael de Oliveira Ribeiro DAERO - Gerencia de Operacoes RNP - Rede Nacional de Ensino e Pesquisa Tel.: +55 21 2102 9659 - iNOC: 1916*767 From John_Brzozowski at Cable.Comcast.com Mon Jan 26 18:19:03 2015 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 26 Jan 2015 18:19:03 +0000 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 24) In-Reply-To: <54C6649C.7030201@rnp.br> References: <54C6649C.7030201@rnp.br> Message-ID: From the looks of it, there is no IPv6 PD support per RFC3633. ========================================= John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozowski at cable.comcast.com ========================================= -----Original Message----- From: Rafael de Oliveira Ribeiro Organization: Rede Nacional de ensino e Pesquisa Date: Monday, January 26, 2015 at 11:00 To: John Brzozowski , NANOG Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 24) >Dear John, > >On 24/01/2015 10:00, nanog-request at nanog.org wrote: >(...) >> Date: Fri, 23 Jan 2015 17:14:11 +0000 >> From: "Brzozowski, John" >> To: "nanog at nanog.org" >> Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) >> Message-ID: >> Content-Type: text/plain; charset="utf-8" >(...) >> For customers where you bring your own cable modem or have one of the >>above in bridge mode we have enabled IPv6 support for you as well. >>However, your router behind the modem must be running software and >>configured with IPv6 support. Specifically, your router needs to be >>support stateful DHCPv6 for IPv6 address and prefix acquisition. We >>have received a number of reports from customers that the Juniper SRX >>does not appear to properly support IPv6. We are working with Juniper >>and also recommend that you reach out to Juniper as well. >(...) > >Care to share scenarios where the SRXs do not perform well with DHCPv6? >Any specific model? > >Thanks in advance, >-- >Rafael de Oliveira Ribeiro >DAERO - Gerencia de Operacoes >RNP - Rede Nacional de Ensino e Pesquisa >Tel.: +55 21 2102 9659 - iNOC: 1916*767 From John_Brzozowski at Cable.Comcast.com Mon Jan 26 18:19:39 2015 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 26 Jan 2015 18:19:39 +0000 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 24) In-Reply-To: <0C5F4601-AA6B-45A2-B127-3E56D64B444E@dren.mil> References: <54C6649C.7030201@rnp.br> <0C5F4601-AA6B-45A2-B127-3E56D64B444E@dren.mil> Message-ID: Sorry Ron, just replied with the same information. ========================================= John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozowski at cable.comcast.com ========================================= -----Original Message----- From: Ron Broersma Date: Monday, January 26, 2015 at 13:15 To: Rafael de Oliveira Ribeiro Cc: John Brzozowski , NANOG Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 24) > >> On Jan 26, 2015, at 8:00 AM, Rafael de Oliveira Ribeiro >> wrote: >> >> Care to share scenarios where the SRXs do not perform well with DHCPv6? >>Any specific model? > >As one example, there is no support for DHCPv6-relay in the SRX, so we >never use them for edge routers (in our enterprise networks). >—Ron > From johnl at iecc.com Mon Jan 26 18:20:20 2015 From: johnl at iecc.com (John Levine) Date: 26 Jan 2015 18:20:20 -0000 Subject: REMINDER: Leap Second In-Reply-To: <20150126083641.GA47009@pit.databus.com> Message-ID: <20150126182020.11552.qmail@ary.lan> Barney Wolff wrote: >On Sun, Jan 25, 2015 at 06:42:51PM -0500, TR Shaw wrote: >> >> That made the transformers smaller/cooler and more efficient. I seem to remember a 195 as well but maybe it >is just CRS. > >Google says the 360/195 did exist. But my baby was the 360/95, >where the first megabyte of memory was flat-film at 60ns, which >made it faster than the 195 for some things. ... The /95 was a /91 with a megabyte of thin film memory, which was both much faster than core (120 vs 780 ns cycle time) and much more expensive (7c rather than 1.6c per bit.) The /195 was a /91 reimplemented in slightly faster logic with a 54ns rather than 60ns cycle time, and a cache adapted from the /85. I can easily believe that for programs that didn't cache well, the /95 with the fast memory would be faster. IBM lost money on all of them and eventually stopped trying to compete with CDC in that niche. See alt.folklore.computers (yes, usenet, reports of its death are premature) for endless discussion of topics like this. R's, John From rafael.ribeiro at rnp.br Mon Jan 26 19:36:47 2015 From: rafael.ribeiro at rnp.br (Rafael de Oliveira Ribeiro) Date: Mon, 26 Jan 2015 17:36:47 -0200 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 24) In-Reply-To: References: <54C6649C.7030201@rnp.br> <0C5F4601-AA6B-45A2-B127-3E56D64B444E@dren.mil> Message-ID: <54C6974F.9030702@rnp.br> Thanks John and Ron, We'll definitely reach out to Juniper. Best regards, -- Rafael de Oliveira Ribeiro DAERO - Gerencia de Operacoes RNP - Rede Nacional de Ensino e Pesquisa Tel.: +55 21 2102 9659 - iNOC: 1916*767 From bzs at world.std.com Mon Jan 26 19:49:01 2015 From: bzs at world.std.com (Barry Shein) Date: Mon, 26 Jan 2015 14:49:01 -0500 Subject: REMINDER: Leap Second In-Reply-To: <20150126083641.GA47009@pit.databus.com> References: <20150125172925.9654.qmail@ary.lan> <98940.1422209727@turing-police.cc.vt.edu> <54C56D34.9050403@satchell.net> <20150125230649.GA90136@pit.databus.com> <20150126083641.GA47009@pit.databus.com> Message-ID: <21702.39469.334831.212792@world.std.com> I'm pretty sure University College, London (UCL) had a 360/195 on the net in the late 1970s. I remember it had open login to I guess it was TSO? I'd play with it but couldn't really figure out anything interesting to do lacking all documentation and by and large motivation other than it was kind of cool in like 1978 to be typing at a computer in London even if it was just saying "do something or go away!" I guess you had to be there. -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* On January 26, 2015 at 03:36 barney at databus.com (Barney Wolff) wrote: > On Sun, Jan 25, 2015 at 06:42:51PM -0500, TR Shaw wrote: > > > > That made the transformers smaller/cooler and more efficient. I seem to remember a 195 as well but maybe it is just CRS. > > Google says the 360/195 did exist. But my baby was the 360/95, > where the first megabyte of memory was flat-film at 60ns, which > made it faster than the 195 for some things. It was incredibly > expensive to build - we heard rumors of $30 million in 1967 dollars, > and sold to NASA at a huge loss, which is why there were only two > built. I used to amuse myself by climbing into the flats memory > cabinet, and was amused again some years later when I could have > ingested a megabyte without harm. Ours sat directly above Tom's > Restaurant, of Seinfeld fame. Very early climate modeling was done > on that machine, along with a lot of astrophysics. From micah at riseup.net Mon Jan 26 22:53:54 2015 From: micah at riseup.net (micah anderson) Date: Mon, 26 Jan 2015 17:53:54 -0500 Subject: scaling linux-based router hardware recommendations Message-ID: <87vbjt6tml.fsf@muck.riseup.net> Hi, I know that specially programmed ASICs on dedicated hardware like Cisco, Juniper, etc. are going to always outperform a general purpose server running gnu/linux, *bsd... but I find the idea of trying to use proprietary, NSA-backdoored devices difficult to accept, especially when I don't have the budget for it. I've noticed that even with a relatively modern system (supermicro with a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server adapters, and 16gig of ram, you still tend to get high percentage of time working on softirqs on all the CPUs when pps reaches somewhere around 60-70k, and the traffic approaching 600-900mbit/sec (during a DDoS, such hardware cannot typically cope). It seems like finding hardware more optimized for very high packet per second counts would be a good thing to do. I just have no idea what is out there that could meet these goals. I'm unsure if faster CPUs, or more CPUs is really the problem, or networking cards, or just plain old fashioned tuning. Any ideas or suggestions would be welcome! micah From faisal at snappytelecom.net Mon Jan 26 23:27:55 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 26 Jan 2015 23:27:55 +0000 (GMT) Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: <1722876115.771987.1422314875496.JavaMail.zimbra@snappytelecom.net> Hi Micah, There is a segment in the Hardware Side of the industry that produces "Network Appliances". (Folks such as Axiomtek, Lanner Electronics, Caswell Networks, Portwell etc etc) These appliances are commonly used as a commercial (OEM) platform for a variety of uses.. Routers, Firewalls, Specialized network applications etc. Our internal testing ( informal), matches up with the commonly quoted PPS handling by the different product vendors who incorporate these appliances in their network product offerings. i3/i5/i7 (x86) based network appliances will forward traffic as long as pps does not exceed 1.4million (In our testing we found the pps to be limiting factor and not the amount of traffic being moved) (will easily handle 6G to 10G of traffic Core2duo (x86) based network appliances will forward traffic as long as pps does not exceed 600,0000 pps (will easily handle 1.5G to 2G of traffic) Atom based (x86) network appliances will forward traffic as long as pps does not exceed 250,000 pps. ---------------------------------------- Of course, if you start to bog down the router with lots of NAT/ACL/ Bridge Rules (i.e. the CPU has to get involved in traffic management) then your actual performance will be degraded. 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: "micah anderson" > To: nanog at nanog.org > Sent: Monday, January 26, 2015 5:53:54 PM > Subject: scaling linux-based router hardware recommendations > > > Hi, > > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > > From nanog at ics-il.net Mon Jan 26 23:44:37 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 26 Jan 2015 17:44:37 -0600 (CST) Subject: scaling linux-based router hardware recommendations In-Reply-To: <1722876115.771987.1422314875496.JavaMail.zimbra@snappytelecom.net> Message-ID: <23401113.10997.1422315847984.JavaMail.mhammett@ThunderFuck> Has anyone tested these setups with something more beefy like dual Xeons of Sandybridge or later vintage? Waiting to hear back from one NIC vendor (HotLava) what they think can be done on larger hardware setups. Put in two big Xeons and you're looking at 24 cores to work with as opposed to the <8 on the desktop versions. The newer ones would also have PCIe 3, which would overcome bus speed limitations in PCIe 2. Realistic to put 6x - 12x 10GigEs into a server with that much beef and expect it to perform well? What vintage of core ix do you run, Faisal? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Faisal Imtiaz" To: "micah anderson" Cc: nanog at nanog.org Sent: Monday, January 26, 2015 5:27:55 PM Subject: Re: scaling linux-based router hardware recommendations Hi Micah, There is a segment in the Hardware Side of the industry that produces "Network Appliances". (Folks such as Axiomtek, Lanner Electronics, Caswell Networks, Portwell etc etc) These appliances are commonly used as a commercial (OEM) platform for a variety of uses.. Routers, Firewalls, Specialized network applications etc. Our internal testing ( informal), matches up with the commonly quoted PPS handling by the different product vendors who incorporate these appliances in their network product offerings. i3/i5/i7 (x86) based network appliances will forward traffic as long as pps does not exceed 1.4million (In our testing we found the pps to be limiting factor and not the amount of traffic being moved) (will easily handle 6G to 10G of traffic Core2duo (x86) based network appliances will forward traffic as long as pps does not exceed 600,0000 pps (will easily handle 1.5G to 2G of traffic) Atom based (x86) network appliances will forward traffic as long as pps does not exceed 250,000 pps. ---------------------------------------- Of course, if you start to bog down the router with lots of NAT/ACL/ Bridge Rules (i.e. the CPU has to get involved in traffic management) then your actual performance will be degraded. 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: "micah anderson" > To: nanog at nanog.org > Sent: Monday, January 26, 2015 5:53:54 PM > Subject: scaling linux-based router hardware recommendations > > > Hi, > > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > > From swhyte at gmail.com Mon Jan 26 23:52:49 2015 From: swhyte at gmail.com (Scott Whyte) Date: Mon, 26 Jan 2015 15:52:49 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: <54C6D351.9080608@gmail.com> On 1/26/15 14:53, micah anderson wrote: > Hi, > > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. > > Any ideas or suggestions would be welcome! DPDK is your friend here. -Scott > micah > From jgreco at ns.sol.net Tue Jan 27 00:18:01 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 26 Jan 2015 18:18:01 -0600 (CST) Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: <201501270018.t0R0I1tP020510@aurora.sol.net> > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. 10-15 years ago, we were seeing early Pentium 4 boxes capable of moving 100Kpps+ on FreeBSD. See for example http://info.iet.unipi.it/~luigi/polling/ Luigi moved on to Netmap, which looks promising for this sort of thing. https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf I was under the impression that some people have been using this for 10G routing. Also I'll note that Ubiquiti has some remarkable low-power gear capable of 1Mpps+. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mehmet at akcin.net Tue Jan 27 00:06:53 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 26 Jan 2015 22:06:53 -0200 Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> Cumulus Networks has some stuff, http://www.bigswitch.com/sites/default/files/presentations/onug-baremetal-2014-final.pdf Pretty decent presentation with more details you like. Mehmet > On Jan 26, 2015, at 8:53 PM, micah anderson wrote: > > > Hi, > > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > From oliver at g.garraux.net Tue Jan 27 00:07:28 2015 From: oliver at g.garraux.net (Oliver Garraux) Date: Mon, 26 Jan 2015 16:07:28 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: <201501270018.t0R0I1tP020510@aurora.sol.net> References: <87vbjt6tml.fsf@muck.riseup.net> <201501270018.t0R0I1tP020510@aurora.sol.net> Message-ID: One thing to note about Ubiquiti's EdgeMax products is that they are not Intel based. They use Cavium Octeon's (at least that's what my EdgeRouter Lite has in it). Oliver ------------------------------------- Oliver Garraux Check out my blog: blog.garraux.net Follow me on Twitter: twitter.com/olivergarraux On Mon, Jan 26, 2015 at 4:18 PM, Joe Greco wrote: > > I know that specially programmed ASICs on dedicated hardware like Cisco, > > Juniper, etc. are going to always outperform a general purpose server > > running gnu/linux, *bsd... but I find the idea of trying to use > > proprietary, NSA-backdoored devices difficult to accept, especially when > > I don't have the budget for it. > > > > I've noticed that even with a relatively modern system (supermicro with > > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > > adapters, and 16gig of ram, you still tend to get high percentage of > > time working on softirqs on all the CPUs when pps reaches somewhere > > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > > DDoS, such hardware cannot typically cope). > > > > It seems like finding hardware more optimized for very high packet per > > second counts would be a good thing to do. I just have no idea what is > > out there that could meet these goals. I'm unsure if faster CPUs, or > > more CPUs is really the problem, or networking cards, or just plain old > > fashioned tuning. > > 10-15 years ago, we were seeing early Pentium 4 boxes capable of moving > 100Kpps+ on FreeBSD. See for example > http://info.iet.unipi.it/~luigi/polling/ > > Luigi moved on to Netmap, which looks promising for this sort of > thing. > https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf > I was under the impression that some people have been using this for > 10G routing. > > Also I'll note that Ubiquiti has some remarkable low-power gear capable > of 1Mpps+. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > From bedard.phil at gmail.com Tue Jan 27 00:45:52 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Mon, 26 Jan 2015 19:45:52 -0500 Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: <10EE5175-77DF-4A97-BA1C-BCD89BA6483E@gmail.com> Kind of unsurprisingly, the traditional network vendors are somewhat at the forefront of pushing what an x86 server can do as well. Brocade (Vyatta), Juniper, and Alcatel-Lucent all have virtualized routers using Intel's DPDK pushing 5M+ PPS at this point. They are all also tweaking what Intel is providing, and they are the ones with lots of software developers with a lot of hardware and network programming experience. ALU claims to be able to get 160Gbps full duplex through a 2RU server with 16x10G interfaces and two 10-core latest-gen Xeon processors. Of course that's probably at 9000 byte packet sizes, but at Imix type traffic it's probably still pushing 60-70Gbps. They have a demo of lots of them in a single rack managed as a single router pushing Tbps. A commerical offering you are going to pay for that kind of performance and the control plane software. Over time though you'll see the DPDK type enhancements make it into standard OS stacks. Other options include servers with integrated network processors or NPs on a PCI card, there is a whole rash of those type of devices out there now and coming out. Phil On 1/26/15, 22:53, "micah anderson" wrote: > >Hi, > >I know that specially programmed ASICs on dedicated hardware like Cisco, >Juniper, etc. are going to always outperform a general purpose server >running gnu/linux, *bsd... but I find the idea of trying to use >proprietary, NSA-backdoored devices difficult to accept, especially when >I don't have the budget for it. > >I've noticed that even with a relatively modern system (supermicro with >a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >adapters, and 16gig of ram, you still tend to get high percentage of >time working on softirqs on all the CPUs when pps reaches somewhere >around 60-70k, and the traffic approaching 600-900mbit/sec (during a >DDoS, such hardware cannot typically cope). > >It seems like finding hardware more optimized for very high packet per >second counts would be a good thing to do. I just have no idea what is >out there that could meet these goals. I'm unsure if faster CPUs, or >more CPUs is really the problem, or networking cards, or just plain old >fashioned tuning. > >Any ideas or suggestions would be welcome! >micah > From skhuraijam at liveops.com Tue Jan 27 01:05:29 2015 From: skhuraijam at liveops.com (Sudeep Khuraijam) Date: Mon, 26 Jan 2015 17:05:29 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: It really depends on the application that you are interested in beyond forwarding, but not knowing that and to scale forwarding ³at a reasonable price", things have to come off cpu and become more customized for forwarding, especially for low latency forwarding. The optimization comes in minimizing packet tuple copies, off load to co-processors and network coprocessors (some of which can be in NICs) and parallel processing with some semblance of shared memory across, all of which takes customization beyond CPU and Kernel which in itself needs to be stripped down bare and embedded. Ultimately that¹s what appliance vendors do with different levels of hardware/firmware customization depending on ROI of features, speeds and price. A generic OpenSource compatible OEM product with multi-gig ports will generally be at least half to 5th the price of a high end latest server architecture server product with ability to support 10 gig interfaces in the same forwarding performance range (which are in the market for a different scale problem in compute and net I/O but exist at a price point that make them exorbitant to solve forwarding speed). Cheers, Sudeep Khuraijam On 1/26/15, 2:53 PM, "micah anderson" wrote: > >Hi, > >I know that specially programmed ASICs on dedicated hardware like Cisco, >Juniper, etc. are going to always outperform a general purpose server >running gnu/linux, *bsd... but I find the idea of trying to use >proprietary, NSA-backdoored devices difficult to accept, especially when >I don't have the budget for it. > >I've noticed that even with a relatively modern system (supermicro with >a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >adapters, and 16gig of ram, you still tend to get high percentage of >time working on softirqs on all the CPUs when pps reaches somewhere >around 60-70k, and the traffic approaching 600-900mbit/sec (during a >DDoS, such hardware cannot typically cope). > >It seems like finding hardware more optimized for very high packet per >second counts would be a good thing to do. I just have no idea what is >out there that could meet these goals. I'm unsure if faster CPUs, or >more CPUs is really the problem, or networking cards, or just plain old >fashioned tuning. > >Any ideas or suggestions would be welcome! >micah > From nanog at ics-il.net Tue Jan 27 01:43:59 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 26 Jan 2015 19:43:59 -0600 (CST) Subject: scaling linux-based router hardware recommendations In-Reply-To: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> Message-ID: <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> Aren't most of the new whitebox\open source platforms based on switching and not routing? I'd assume that the "cloud-scale" data centers deploying this stuff still have more traditional big iron at their cores. The small\medium sized ISP usually is left behind. They're not big enough to afford the big new hardware, but all of their user's NetFlix and porn and whatever else they do is chewing up bandwidth. For example, the small\medium ISPs are at the Nx10GigE stage now. The new hardware is expensive, the old hardware (besides being old) is likely in a huge chassis if you can get any sort of port density at all. 48 port GigE switches with a couple 10GigE can be had for $100. A minimum of 24 port 10GigE switches (except for the occasional IBM switch ) is 30x to 40x times that. Routers (BGP, MPLS, etc.) with that more than just a couple 10GigEs are even more money, I'd assume. I thought vMX was going to save the day, but it's pricing for 10 gigs of traffic (licensed by throughput and standard\advanced licenses) is really about 5x - 10x what I'd be willing to pay for it. Haven't gotten a quote from AlcaLu yet. Vyatta (last I checked, which was admittedly some time ago) doesn't have MPLS. The FreeBSD world can bring zero software cost and a stable platform, but no MPLS. Mikrotik brings most (though not all) of the features one would want... a good enough feature set, let's say... but is a non-stop flow of bugs. I don't think a week or two goes by where one of my friends doesn't submit some sort of reproducible bug to Mikrotik. They've also been "looking into" DPDK for 2.5 years now. hasn't shown up yet. I've used MT for 10 years and I'm always left wanting just a little more, but it may be the best balance between the features and performance I want and the ability to pay for it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mehmet Akcin" To: "micah anderson" Cc: nanog at nanog.org Sent: Monday, January 26, 2015 6:06:53 PM Subject: Re: scaling linux-based router hardware recommendations Cumulus Networks has some stuff, http://www.bigswitch.com/sites/default/files/presentations/onug-baremetal-2014-final.pdf Pretty decent presentation with more details you like. Mehmet > On Jan 26, 2015, at 8:53 PM, micah anderson wrote: > > > Hi, > > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > From tony at wicks.co.nz Tue Jan 27 01:57:44 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 27 Jan 2015 14:57:44 +1300 Subject: scaling linux-based router hardware recommendations In-Reply-To: <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> References: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> Message-ID: <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> And the solution to this issue is - http://routerboard.com/ or http://www.mikrotik.com/software# on x86 hardware, plus any basic layer2 switch. Don't scoff until you have tried it, the price/performance is pretty staggering if you are in the sub 20gig space. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Tuesday, 27 January 2015 2:44 p.m. To: nanog at nanog.org Subject: Re: scaling linux-based router hardware recommendations Aren't most of the new whitebox\open source platforms based on switching and not routing? I'd assume that the "cloud-scale" data centers deploying this stuff still have more traditional big iron at their cores. The small\medium sized ISP usually is left behind. They're not big enough to afford the big new hardware, but all of their user's NetFlix and porn and whatever else they do is chewing up bandwidth. For example, the small\medium ISPs are at the Nx10GigE stage now. The new hardware is expensive, the old hardware (besides being old) is likely in a huge chassis if you can get any sort of port density at all. 48 port GigE switches with a couple 10GigE can be had for $100. A minimum of 24 port 10GigE switches (except for the occasional IBM switch ) is 30x to 40x times that. Routers (BGP, MPLS, etc.) with that more than just a couple 10GigEs are even more money, I'd assume. I thought vMX was going to save the day, but it's pricing for 10 gigs of traffic (licensed by throughput and standard\advanced licenses) is really about 5x - 10x what I'd be willing to pay for it. Haven't gotten a quote from AlcaLu yet. Vyatta (last I checked, which was admittedly some time ago) doesn't have MPLS. The FreeBSD world can bring zero software cost and a stable platform, but no MPLS. Mikrotik brings most (though not all) of the features one would want... a good enough feature set, let's say... but is a non-stop flow of bugs. I don't think a week or two goes by where one of my friends doesn't submit some sort of reproducible bug to Mikrotik. They've also been "looking into" DPDK for 2.5 years now. hasn't shown up yet. I've used MT for 10 years and I'm always left wanting just a little more, but it may be the best balance between the features and performance I want and the ability to pay for it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mehmet Akcin" To: "micah anderson" Cc: nanog at nanog.org Sent: Monday, January 26, 2015 6:06:53 PM Subject: Re: scaling linux-based router hardware recommendations Cumulus Networks has some stuff, http://www.bigswitch.com/sites/default/files/presentations/onug-baremetal-2014-final.pdf Pretty decent presentation with more details you like. Mehmet > On Jan 26, 2015, at 8:53 PM, micah anderson wrote: > > > Hi, > > I know that specially programmed ASICs on dedicated hardware like > Cisco, Juniper, etc. are going to always outperform a general purpose > server running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially > when I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro > with a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain > old fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > From nanog at ics-il.net Tue Jan 27 02:01:05 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 26 Jan 2015 20:01:05 -0600 (CST) Subject: scaling linux-based router hardware recommendations In-Reply-To: <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> Message-ID: <32607674.11261.1422324024411.JavaMail.mhammett@ThunderFuck> Must not have read my whole e-mail. ;-) There aren't very many people outside of my group that know more about Mikrotik. Trainers, MUM presenters, direct-line-to-Janis guys, etc. Still can't make those Latvians produce what we want. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Tony Wicks" To: "Mike Hammett" , nanog at nanog.org Sent: Monday, January 26, 2015 7:57:44 PM Subject: RE: scaling linux-based router hardware recommendations And the solution to this issue is - http://routerboard.com/ or http://www.mikrotik.com/software# on x86 hardware, plus any basic layer2 switch. Don't scoff until you have tried it, the price/performance is pretty staggering if you are in the sub 20gig space. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Tuesday, 27 January 2015 2:44 p.m. To: nanog at nanog.org Subject: Re: scaling linux-based router hardware recommendations Aren't most of the new whitebox\open source platforms based on switching and not routing? I'd assume that the "cloud-scale" data centers deploying this stuff still have more traditional big iron at their cores. The small\medium sized ISP usually is left behind. They're not big enough to afford the big new hardware, but all of their user's NetFlix and porn and whatever else they do is chewing up bandwidth. For example, the small\medium ISPs are at the Nx10GigE stage now. The new hardware is expensive, the old hardware (besides being old) is likely in a huge chassis if you can get any sort of port density at all. 48 port GigE switches with a couple 10GigE can be had for $100. A minimum of 24 port 10GigE switches (except for the occasional IBM switch ) is 30x to 40x times that. Routers (BGP, MPLS, etc.) with that more than just a couple 10GigEs are even more money, I'd assume. I thought vMX was going to save the day, but it's pricing for 10 gigs of traffic (licensed by throughput and standard\advanced licenses) is really about 5x - 10x what I'd be willing to pay for it. Haven't gotten a quote from AlcaLu yet. Vyatta (last I checked, which was admittedly some time ago) doesn't have MPLS. The FreeBSD world can bring zero software cost and a stable platform, but no MPLS. Mikrotik brings most (though not all) of the features one would want... a good enough feature set, let's say... but is a non-stop flow of bugs. I don't think a week or two goes by where one of my friends doesn't submit some sort of reproducible bug to Mikrotik. They've also been "looking into" DPDK for 2.5 years now. hasn't shown up yet. I've used MT for 10 years and I'm always left wanting just a little more, but it may be the best balance between the features and performance I want and the ability to pay for it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mehmet Akcin" To: "micah anderson" Cc: nanog at nanog.org Sent: Monday, January 26, 2015 6:06:53 PM Subject: Re: scaling linux-based router hardware recommendations Cumulus Networks has some stuff, http://www.bigswitch.com/sites/default/files/presentations/onug-baremetal-2014-final.pdf Pretty decent presentation with more details you like. Mehmet > On Jan 26, 2015, at 8:53 PM, micah anderson wrote: > > > Hi, > > I know that specially programmed ASICs on dedicated hardware like > Cisco, Juniper, etc. are going to always outperform a general purpose > server running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially > when I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro > with a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain > old fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > From contact at winterei.se Tue Jan 27 02:10:54 2015 From: contact at winterei.se (Paul S.) Date: Tue, 27 Jan 2015 11:10:54 +0900 Subject: scaling linux-based router hardware recommendations In-Reply-To: <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> References: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> Message-ID: <54C6F3AE.5040703@winterei.se> Like Mike mentioned, the feature list in RouterOS is nothing short of impressive -- problem is that pretty much everything in there is inherently buggy. That and one hell of a painful syntax-schema to work with too. On 1/27/2015 午前 10:57, Tony Wicks wrote: > And the solution to this issue is - http://routerboard.com/ or http://www.mikrotik.com/software# on x86 hardware, plus any basic layer2 switch. Don't scoff until you have tried it, the price/performance is pretty staggering if you are in the sub 20gig space. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Tuesday, 27 January 2015 2:44 p.m. > To: nanog at nanog.org > Subject: Re: scaling linux-based router hardware recommendations > > Aren't most of the new whitebox\open source platforms based on switching and not routing? I'd assume that the "cloud-scale" data centers deploying this stuff still have more traditional big iron at their cores. > > The small\medium sized ISP usually is left behind. They're not big enough to afford the big new hardware, but all of their user's NetFlix and porn and whatever else they do is chewing up bandwidth. For example, the small\medium ISPs are at the Nx10GigE stage now. The new hardware is expensive, the old hardware (besides being old) is likely in a huge chassis if you can get any sort of port density at all. > > 48 port GigE switches with a couple 10GigE can be had for $100. A minimum of 24 port 10GigE switches (except for the occasional IBM switch ) is 30x to 40x times that. Routers (BGP, MPLS, etc.) with that more than just a couple 10GigEs are even more money, I'd assume. > > I thought vMX was going to save the day, but it's pricing for 10 gigs of traffic (licensed by throughput and standard\advanced licenses) is really about 5x - 10x what I'd be willing to pay for it. > > Haven't gotten a quote from AlcaLu yet. > > Vyatta (last I checked, which was admittedly some time ago) doesn't have MPLS. > > The FreeBSD world can bring zero software cost and a stable platform, but no MPLS. > > Mikrotik brings most (though not all) of the features one would want... a good enough feature set, let's say... but is a non-stop flow of bugs. I don't think a week or two goes by where one of my friends doesn't submit some sort of reproducible bug to Mikrotik. They've also been "looking into" DPDK for 2.5 years now. hasn't shown up yet. I've used MT for 10 years and I'm always left wanting just a little more, but it may be the best balance between the features and performance I want and the ability to pay for it. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Mehmet Akcin" > To: "micah anderson" > Cc: nanog at nanog.org > Sent: Monday, January 26, 2015 6:06:53 PM > Subject: Re: scaling linux-based router hardware recommendations > > Cumulus Networks has some stuff, > > http://www.bigswitch.com/sites/default/files/presentations/onug-baremetal-2014-final.pdf > > Pretty decent presentation with more details you like. > > Mehmet > >> On Jan 26, 2015, at 8:53 PM, micah anderson wrote: >> >> >> Hi, >> >> I know that specially programmed ASICs on dedicated hardware like >> Cisco, Juniper, etc. are going to always outperform a general purpose >> server running gnu/linux, *bsd... but I find the idea of trying to use >> proprietary, NSA-backdoored devices difficult to accept, especially >> when I don't have the budget for it. >> >> I've noticed that even with a relatively modern system (supermicro >> with a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >> adapters, and 16gig of ram, you still tend to get high percentage of >> time working on softirqs on all the CPUs when pps reaches somewhere >> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >> DDoS, such hardware cannot typically cope). >> >> It seems like finding hardware more optimized for very high packet per >> second counts would be a good thing to do. I just have no idea what is >> out there that could meet these goals. I'm unsure if faster CPUs, or >> more CPUs is really the problem, or networking cards, or just plain >> old fashioned tuning. >> >> Any ideas or suggestions would be welcome! >> micah >> From nanog at ics-il.net Tue Jan 27 02:20:07 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 26 Jan 2015 20:20:07 -0600 (CST) Subject: scaling linux-based router hardware recommendations In-Reply-To: <54C6F3AE.5040703@winterei.se> Message-ID: <28670313.11299.1422325227247.JavaMail.mhammett@ThunderFuck> Different (configuration) strokes for different folks. I look at a Cisco interface now and say, "Who the hell would use this?" despite my decade old Cisco training. I was corrected offlist that Vyatta does do MPLS now... but I can't find anything on it doing VPLS, so I guess that's still out. The 5600's license (according to their SDNCentral performance report) appears to be near $7k whereas MT you can get a license for $80. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul S." To: nanog at nanog.org Sent: Monday, January 26, 2015 8:10:54 PM Subject: Re: scaling linux-based router hardware recommendations Like Mike mentioned, the feature list in RouterOS is nothing short of impressive -- problem is that pretty much everything in there is inherently buggy. That and one hell of a painful syntax-schema to work with too. On 1/27/2015 午前 10:57, Tony Wicks wrote: > And the solution to this issue is - http://routerboard.com/ or http://www.mikrotik.com/software# on x86 hardware, plus any basic layer2 switch. Don't scoff until you have tried it, the price/performance is pretty staggering if you are in the sub 20gig space. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Tuesday, 27 January 2015 2:44 p.m. > To: nanog at nanog.org > Subject: Re: scaling linux-based router hardware recommendations > > Aren't most of the new whitebox\open source platforms based on switching and not routing? I'd assume that the "cloud-scale" data centers deploying this stuff still have more traditional big iron at their cores. > > The small\medium sized ISP usually is left behind. They're not big enough to afford the big new hardware, but all of their user's NetFlix and porn and whatever else they do is chewing up bandwidth. For example, the small\medium ISPs are at the Nx10GigE stage now. The new hardware is expensive, the old hardware (besides being old) is likely in a huge chassis if you can get any sort of port density at all. > > 48 port GigE switches with a couple 10GigE can be had for $100. A minimum of 24 port 10GigE switches (except for the occasional IBM switch ) is 30x to 40x times that. Routers (BGP, MPLS, etc.) with that more than just a couple 10GigEs are even more money, I'd assume. > > I thought vMX was going to save the day, but it's pricing for 10 gigs of traffic (licensed by throughput and standard\advanced licenses) is really about 5x - 10x what I'd be willing to pay for it. > > Haven't gotten a quote from AlcaLu yet. > > Vyatta (last I checked, which was admittedly some time ago) doesn't have MPLS. > > The FreeBSD world can bring zero software cost and a stable platform, but no MPLS. > > Mikrotik brings most (though not all) of the features one would want... a good enough feature set, let's say... but is a non-stop flow of bugs. I don't think a week or two goes by where one of my friends doesn't submit some sort of reproducible bug to Mikrotik. They've also been "looking into" DPDK for 2.5 years now. hasn't shown up yet. I've used MT for 10 years and I'm always left wanting just a little more, but it may be the best balance between the features and performance I want and the ability to pay for it. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Mehmet Akcin" > To: "micah anderson" > Cc: nanog at nanog.org > Sent: Monday, January 26, 2015 6:06:53 PM > Subject: Re: scaling linux-based router hardware recommendations > > Cumulus Networks has some stuff, > > http://www.bigswitch.com/sites/default/files/presentations/onug-baremetal-2014-final.pdf > > Pretty decent presentation with more details you like. > > Mehmet > >> On Jan 26, 2015, at 8:53 PM, micah anderson wrote: >> >> >> Hi, >> >> I know that specially programmed ASICs on dedicated hardware like >> Cisco, Juniper, etc. are going to always outperform a general purpose >> server running gnu/linux, *bsd... but I find the idea of trying to use >> proprietary, NSA-backdoored devices difficult to accept, especially >> when I don't have the budget for it. >> >> I've noticed that even with a relatively modern system (supermicro >> with a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >> adapters, and 16gig of ram, you still tend to get high percentage of >> time working on softirqs on all the CPUs when pps reaches somewhere >> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >> DDoS, such hardware cannot typically cope). >> >> It seems like finding hardware more optimized for very high packet per >> second counts would be a good thing to do. I just have no idea what is >> out there that could meet these goals. I'm unsure if faster CPUs, or >> more CPUs is really the problem, or networking cards, or just plain >> old fashioned tuning. >> >> Any ideas or suggestions would be welcome! >> micah >> From ccosta at gaikai.com Mon Jan 26 19:57:40 2015 From: ccosta at gaikai.com (Christopher Costa) Date: Mon, 26 Jan 2015 11:57:40 -0800 Subject: Requesting Consolidated Communications (AS5742) contact Message-ID: Requesting to speak with Consolidated Communications (AS5742) regarding routing in Illinois region towards Gaikai (AS33353). Please contact me offline. Thank you, Chris Costa Gaikai ccosta at gaikai.com From bb at 1stclasshosting.com Mon Jan 26 21:26:46 2015 From: bb at 1stclasshosting.com (Brad Bendy) Date: Mon, 26 Jan 2015 14:26:46 -0700 Subject: AT&T uVerse blocking SIP? Message-ID: Has anyone seen issues where a end user on uVerse trying to connect to either another provider or AT&T non uVerse (in this case DIA) is having SIP blocked? SIP leaving the uVerse network going to another uVerse DSL account is fine, but it appears soon as it leave the uVerse network all SIP traffic is blocked? It appears others have seen this problem, some say it's a modem issue, some say they are truly blocking it. Ive yet to call uVerse support yet as im guessing ill get no where. Thanks for any insight on this. -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender 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. The sender 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. If verification is required please request a hard-copy version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, Cheyenne, WY 82001 From davidbass570 at gmail.com Tue Jan 27 01:07:11 2015 From: davidbass570 at gmail.com (David bass) Date: Mon, 26 Jan 2015 19:07:11 -0600 Subject: scaling linux-based router hardware recommendations In-Reply-To: <10EE5175-77DF-4A97-BA1C-BCD89BA6483E@gmail.com> References: <87vbjt6tml.fsf@muck.riseup.net> <10EE5175-77DF-4A97-BA1C-BCD89BA6483E@gmail.com> Message-ID: I'm also in the research stage of building our own router. I'm interested in reading more if you can post links to some of this research and/or testing. David Sent from my iPad > On Jan 26, 2015, at 6:45 PM, Phil Bedard wrote: > > Kind of unsurprisingly, the traditional network vendors are somewhat at > the forefront of pushing what an x86 server can do as well. Brocade > (Vyatta), Juniper, and Alcatel-Lucent all have virtualized routers using > Intel's DPDK pushing 5M+ PPS at this point. They are all also tweaking > what Intel is providing, and they are the ones with lots of software > developers with a lot of hardware and network programming experience. > > ALU claims to be able to get 160Gbps full duplex through a 2RU server with > 16x10G interfaces and two 10-core latest-gen Xeon processors. Of course > that's probably at 9000 byte packet sizes, but at Imix type traffic it's > probably still pushing 60-70Gbps. They have a demo of lots of them in a > single rack managed as a single router pushing Tbps. > > A commerical offering you are going to pay for that kind of performance > and the control plane software. Over time though you'll see the DPDK type > enhancements make it into standard OS stacks. Other options include > servers with integrated network processors or NPs on a PCI card, there is > a whole rash of those type of devices out there now and coming out. > > Phil > > > >> On 1/26/15, 22:53, "micah anderson" wrote: >> >> >> Hi, >> >> I know that specially programmed ASICs on dedicated hardware like Cisco, >> Juniper, etc. are going to always outperform a general purpose server >> running gnu/linux, *bsd... but I find the idea of trying to use >> proprietary, NSA-backdoored devices difficult to accept, especially when >> I don't have the budget for it. >> >> I've noticed that even with a relatively modern system (supermicro with >> a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >> adapters, and 16gig of ram, you still tend to get high percentage of >> time working on softirqs on all the CPUs when pps reaches somewhere >> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >> DDoS, such hardware cannot typically cope). >> >> It seems like finding hardware more optimized for very high packet per >> second counts would be a good thing to do. I just have no idea what is >> out there that could meet these goals. I'm unsure if faster CPUs, or >> more CPUs is really the problem, or networking cards, or just plain old >> fashioned tuning. >> >> Any ideas or suggestions would be welcome! >> micah > From jared at puck.nether.net Tue Jan 27 03:22:56 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 26 Jan 2015 22:22:56 -0500 Subject: AT&T uVerse blocking SIP? In-Reply-To: References: Message-ID: <3291F28A-7010-46B5-955E-F2AFFDCD688F@puck.nether.net> Yes. If you move to another port, e.g.: 5061 it works fine. If you’re running on a Linux based system, you can do this: /sbin/iptables -A PREROUTING -t nat -i eth1 -p udp --dport 5061 -j REDIRECT --to-port 5060 on the host to remap 5061 -> 5060 with no application change. - Jared > On Jan 26, 2015, at 4:26 PM, Brad Bendy wrote: > > Has anyone seen issues where a end user on uVerse trying to connect to > either another provider or AT&T non uVerse (in this case DIA) is having SIP > blocked? SIP leaving the uVerse network going to another uVerse DSL account > is fine, but it appears soon as it leave the uVerse network all SIP traffic > is blocked? > > It appears others have seen this problem, some say it's a modem issue, some > say they are truly blocking it. Ive yet to call uVerse support yet as im > guessing ill get no where. > > Thanks for any insight on this. > > -- > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > 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. > The sender 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. If verification is required please request a hard-copy > version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, Cheyenne, WY > 82001 From joelja at bogus.com Tue Jan 27 03:23:47 2015 From: joelja at bogus.com (joel jaeggli) Date: Mon, 26 Jan 2015 19:23:47 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> References: <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> Message-ID: <54C704C3.3040801@bogus.com> On 1/26/15 5:43 PM, Mike Hammett wrote: > Aren't most of the new whitebox\open source platforms based on > switching and not routing? I'd assume that the "cloud-scale" data > centers deploying this stuff still have more traditional big iron at > their cores. A L3 ethernet switch and a "router" are effectively indistinguishable. the actual feature set you need drives what platforms are appropiate. A signficant push for DCs particularly those with CLOS archectures is away from modular chassis based switches towards dense but fixed configuration switches. This drives the complexity and a signficant chunk of the cost out of these switches. > The small\medium sized ISP usually is left behind. They're not big > enough to afford the big new hardware, but all of their user's > NetFlix and porn and whatever else they do is chewing up bandwidth. Everyone in the industry is under margin pressure. Done well every subsequent generation of your infrastrucuture is less costly per bit delivered while also being faster. > For example, the small\medium ISPs are at the Nx10GigE stage now. The > new hardware is expensive, the old hardware (besides being old) is > likely in a huge chassis if you can get any sort of port density at > all. If you're a small consumer based ISP how many routers do you actually need the have a full table (the customer access network doesn't need it). > 48 port GigE switches with a couple 10GigE can be had for $100. I'm not aware of that being the case. With respect to merchant silicon there a limited number of comon l3 switch asic building blocks which all switch/router vendors can avail themselves of. broadcom trident+ trident 2 and arad, intel fm6000, marvell prestera etc. > A > minimum of 24 port 10GigE switches (except for the occasional IBM > switch ) is 30x to 40x times that. Routers (BGP, MPLS, etc.) with > that more than just a couple 10GigEs are even more money, I'd assume. a 64 port 10 or mixed 10/40Gb/s switch can forward more half a Tb/s worth of 64byte packets, do so with cut-through forwarding and in a thermal enevelope of 150 watts. device like that retail for ~20k, in reality you need more than one. the equivalent gigabit product is 15 or 20% of the price. you mention mpls support so that dictates appropriate support which is available in some platforms and asics. > > I thought vMX was going to save the day, but it's pricing for 10 gigs > of traffic (licensed by throughput and standard\advanced licenses) is > really about 5x - 10x what I'd be willing to pay for it. The servers capable of relatively high-end forwarding feats aren't free either nor are the equivalent. > Haven't gotten a quote from AlcaLu yet. > > Vyatta (last I checked, which was admittedly some time ago) doesn't > have MPLS. > > The FreeBSD world can bring zero software cost and a stable platform, > but no MPLS. mpls implementions have abundant ipr, which among other things prevents practical merging with the linux kernel. > Mikrotik brings most (though not all) of the features one would > want... a good enough feature set, let's say... but is a non-stop > flow of bugs. I don't think a week or two goes by where one of my > friends doesn't submit some sort of reproducible bug to Mikrotik. > They've also been "looking into" DPDK for 2.5 years now. hasn't shown > up yet. I've used MT for 10 years and I'm always left wanting just a > little more, but it may be the best balance between the features and > performance I want and the ability to pay for it. > > > > > ----- Mike Hammett Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Mehmet Akcin" To: "micah anderson" > Cc: nanog at nanog.org Sent: Monday, January 26, 2015 > 6:06:53 PM Subject: Re: scaling linux-based router hardware > recommendations > > Cumulus Networks has some stuff, > > http://www.bigswitch.com/sites/default/files/presentations/onug-baremetal-2014-final.pdf > > > Pretty decent presentation with more details you like. > > Mehmet > >> On Jan 26, 2015, at 8:53 PM, micah anderson >> wrote: >> >> >> Hi, >> >> I know that specially programmed ASICs on dedicated hardware like >> Cisco, Juniper, etc. are going to always outperform a general >> purpose server running gnu/linux, *bsd... but I find the idea of >> trying to use proprietary, NSA-backdoored devices difficult to >> accept, especially when I don't have the budget for it. >> >> I've noticed that even with a relatively modern system (supermicro >> with a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK >> Server adapters, and 16gig of ram, you still tend to get high >> percentage of time working on softirqs on all the CPUs when pps >> reaches somewhere around 60-70k, and the traffic approaching >> 600-900mbit/sec (during a DDoS, such hardware cannot typically >> cope). >> >> It seems like finding hardware more optimized for very high packet >> per second counts would be a good thing to do. I just have no idea >> what is out there that could meet these goals. I'm unsure if faster >> CPUs, or more CPUs is really the problem, or networking cards, or >> just plain old fashioned tuning. >> >> Any ideas or suggestions would be welcome! micah >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Tue Jan 27 03:44:33 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 26 Jan 2015 22:44:33 -0500 Subject: AT&T uVerse blocking SIP? In-Reply-To: <3291F28A-7010-46B5-955E-F2AFFDCD688F@puck.nether.net> References: <3291F28A-7010-46B5-955E-F2AFFDCD688F@puck.nether.net> Message-ID: I think this is due to the CPE using a particular ALG ... (from recollection having never been a UVerse customer, but having sat through a long, long, long set of discussions about the merits/demerits of sip blocking) On Mon, Jan 26, 2015 at 10:22 PM, Jared Mauch wrote: > Yes. If you move to another port, e.g.: 5061 it works fine. > > If you’re running on a Linux based system, you can do this: > > /sbin/iptables -A PREROUTING -t nat -i eth1 -p udp --dport 5061 -j REDIRECT --to-port 5060 > > on the host to remap 5061 -> 5060 with no application change. > > - Jared > >> On Jan 26, 2015, at 4:26 PM, Brad Bendy wrote: >> >> Has anyone seen issues where a end user on uVerse trying to connect to >> either another provider or AT&T non uVerse (in this case DIA) is having SIP >> blocked? SIP leaving the uVerse network going to another uVerse DSL account >> is fine, but it appears soon as it leave the uVerse network all SIP traffic >> is blocked? >> >> It appears others have seen this problem, some say it's a modem issue, some >> say they are truly blocking it. Ive yet to call uVerse support yet as im >> guessing ill get no where. >> >> Thanks for any insight on this. >> >> -- >> This message contains confidential information and is intended only for the >> individual named. If you are not the named addressee you should not >> disseminate, distribute or copy this e-mail. Please notify the sender >> 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. >> The sender 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. If verification is required please request a hard-copy >> version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, Cheyenne, WY >> 82001 > From math at sizone.org Tue Jan 27 03:29:28 2015 From: math at sizone.org (Ken Chase) Date: Mon, 26 Jan 2015 22:29:28 -0500 Subject: scaling linux-based router hardware recommendations In-Reply-To: <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> References: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> Message-ID: <20150127032928.GI24849@sizone.org> Hows convergence time on these mikrotik/ubiquity/etc units for a full table? /kc -- Ken Chase - math at sizone.org Toronto From nanog at ics-il.net Tue Jan 27 03:51:47 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 26 Jan 2015 21:51:47 -0600 (CST) Subject: scaling linux-based router hardware recommendations In-Reply-To: <20150127032928.GI24849@sizone.org> Message-ID: <20018125.11558.1422330721500.JavaMail.mhammett@ThunderFuck> Depends on the hardware. 30 - 45 seconds for the higher end stuff? I'm not sure how long it is on an RB750 (list price of like $40). ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Ken Chase" To: nanog at nanog.org Sent: Monday, January 26, 2015 9:29:28 PM Subject: Re: scaling linux-based router hardware recommendations Hows convergence time on these mikrotik/ubiquity/etc units for a full table? /kc -- Ken Chase - math at sizone.org Toronto From Valdis.Kletnieks at vt.edu Tue Jan 27 03:58:32 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 26 Jan 2015 22:58:32 -0500 Subject: scaling linux-based router hardware recommendations In-Reply-To: Your message of "Tue, 27 Jan 2015 11:10:54 +0900." <54C6F3AE.5040703@winterei.se> References: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> <54C6F3AE.5040703@winterei.se> Message-ID: <10768.1422331112@turing-police.cc.vt.edu> On Tue, 27 Jan 2015 11:10:54 +0900, "Paul S." said: > Like Mike mentioned, the feature list in RouterOS is nothing short of > impressive -- problem is that pretty much everything in there is > inherently buggy. > > That and one hell of a painful syntax-schema to work with too. Latvian grammar is.. somewhat unusual. Just be glad the development team wasn't Finnish. :) (Sorry, I couldn't resist. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From alexander at neilson.net.nz Tue Jan 27 03:59:12 2015 From: alexander at neilson.net.nz (Alexander Neilson) Date: Tue, 27 Jan 2015 16:59:12 +1300 Subject: scaling linux-based router hardware recommendations In-Reply-To: <20150127032928.GI24849@sizone.org> References: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> <20150127032928.GI24849@sizone.org> Message-ID: > On 27/01/2015, at 4:29 pm, Ken Chase wrote: > > Hows convergence time on these mikrotik/ubiquity/etc units for a full table? For the CCR1036-12G-4S with one full table, one domestic table (NZ - ~26k entries) some peering and iBGP full convergence took about three minutes forty seconds last time I timed it from cold. I may do some new timing as they have been working hard to improve the multi core support (currently BGP still only single core however they been doing some work on efficient allocation of other tasks to cores. > > /kc > -- > Ken Chase - math at sizone.org Toronto > From faisal at snappytelecom.net Tue Jan 27 04:37:59 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 27 Jan 2015 04:37:59 +0000 (GMT) Subject: scaling linux-based router hardware recommendations In-Reply-To: <20150127032928.GI24849@sizone.org> References: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> <20150127032928.GI24849@sizone.org> Message-ID: <181088146.776471.1422333479308.JavaMail.zimbra@snappytelecom.net> Under 30sec (more like 15 to 20) on an i7 based Mikrotik for full BGP Tables. Faisal Imtiaz ----- Original Message ----- > From: "Ken Chase" > To: nanog at nanog.org > Sent: Monday, January 26, 2015 10:29:28 PM > Subject: Re: scaling linux-based router hardware recommendations > > Hows convergence time on these mikrotik/ubiquity/etc units for a full table? > > /kc > -- > Ken Chase - math at sizone.org Toronto > > From math at sizone.org Tue Jan 27 04:52:05 2015 From: math at sizone.org (Ken Chase) Date: Mon, 26 Jan 2015 23:52:05 -0500 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <3DA7BA52-9C4F-4FBE-BAA6-AD7F08D9C002@akcin.net> <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> <008001d039d4$a4c135c0$ee43a140$@wicks.co.nz> <20150127032928.GI24849@sizone.org> Message-ID: <20150127045205.GJ24849@sizone.org> On Tue, Jan 27, 2015 at 04:59:12PM +1300, Alexander Neilson said: >For the CCR1036-12G-4S with one full table, one domestic table (NZ - ~26k entries) some peering and iBGP full convergence took about three minutes forty seconds last time I timed it from cold. That's terrible. I dont know what model that is or appropriate deploys but I think a couple of my peers use these and report similar times for their models for 500k+ routes. Still too slow. I think the single threaded nature of the routing table manip is at fault with the 36-but-slow cores (mikrotic). Im not sure how you get around this without drastically rewriting the kernel, which puts you out on your own developing new fundamental tech. I'd be more comfortable with full-cpu models (like xeon based for eg.) > From: Faisal Imtiaz > Under 30sec (more like 15 to 20) on an i7 based Mikrotik for full BGP Tables. Ya, that. /kc -- Ken Chase - math at sizone.org Toronto From damien at supremebytes.com Tue Jan 27 06:47:03 2015 From: damien at supremebytes.com (Damien Burke) Date: Tue, 27 Jan 2015 06:47:03 +0000 Subject: Facebook outage? Message-ID: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> Facebook outage? Everyone panic! https://twitter.com/search?q=facebook&src=typd -Damien From jvanoppen at spectrumnet.us Tue Jan 27 06:48:31 2015 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Tue, 27 Jan 2015 06:48:31 +0000 Subject: Facebook outage? In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> Message-ID: Dead here at AS11404 from all locations where we PNI or public peer... must be bad over there, v4 dies at their edge, v6 makes it in but no page loads. John From damien at supremebytes.com Tue Jan 27 06:50:07 2015 From: damien at supremebytes.com (Damien Burke) Date: Tue, 27 Jan 2015 06:50:07 +0000 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> Message-ID: <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> I hear that AIM and hipchat is also having issues. Any other major company down too? -----Original Message----- From: John van Oppen [mailto:jvanoppen at spectrumnet.us] Sent: Monday, January 26, 2015 10:49 PM To: Damien Burke; nanog at nanog.org Subject: RE: Facebook outage? Dead here at AS11404 from all locations where we PNI or public peer... must be bad over there, v4 dies at their edge, v6 makes it in but no page loads. John From jason at unlimitednet.us Tue Jan 27 06:56:26 2015 From: jason at unlimitednet.us (Jason Canady) Date: Tue, 27 Jan 2015 01:56:26 -0500 Subject: Facebook outage? In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: Instagram appears to be down as well, but that would make sense since they are part of Facebook. On Jan 27, 2015, at 1:50, Damien Burke wrote: > I hear that AIM and hipchat is also having issues. > > Any other major company down too? > > -----Original Message----- > From: John van Oppen [mailto:jvanoppen at spectrumnet.us] > Sent: Monday, January 26, 2015 10:49 PM > To: Damien Burke; nanog at nanog.org > Subject: RE: Facebook outage? > > Dead here at AS11404 from all locations where we PNI or public peer... > > must be bad over there, v4 dies at their edge, v6 makes it in but no page loads. > > John From tfarrell at riotgames.com Tue Jan 27 06:56:28 2015 From: tfarrell at riotgames.com (Trent Farrell) Date: Mon, 26 Jan 2015 22:56:28 -0800 Subject: Facebook outage? In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: https://twitter.com/LizardMafia/status/559963134006292481 On Mon, Jan 26, 2015 at 10:50 PM, Damien Burke wrote: > I hear that AIM and hipchat is also having issues. > > Any other major company down too? > > -----Original Message----- > From: John van Oppen [mailto:jvanoppen at spectrumnet.us] > Sent: Monday, January 26, 2015 10:49 PM > To: Damien Burke; nanog at nanog.org > Subject: RE: Facebook outage? > > Dead here at AS11404 from all locations where we PNI or public peer... > > must be bad over there, v4 dies at their edge, v6 makes it in but no page > loads. > > John > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro From morrowc.lists at gmail.com Tue Jan 27 06:57:01 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 27 Jan 2015 01:57:01 -0500 Subject: Facebook outage? In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: snow, it's a terrible thing. On Tue, Jan 27, 2015 at 1:50 AM, Damien Burke wrote: > I hear that AIM and hipchat is also having issues. > > Any other major company down too? > > -----Original Message----- > From: John van Oppen [mailto:jvanoppen at spectrumnet.us] > Sent: Monday, January 26, 2015 10:49 PM > To: Damien Burke; nanog at nanog.org > Subject: RE: Facebook outage? > > Dead here at AS11404 from all locations where we PNI or public peer... > > must be bad over there, v4 dies at their edge, v6 makes it in but no page loads. > > John From morrowc.lists at gmail.com Tue Jan 27 06:58:22 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 27 Jan 2015 01:58:22 -0500 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: On Tue, Jan 27, 2015 at 1:56 AM, Jason Canady wrote: > Instagram appears to be down as well, but that would make sense since they are part of Facebook. > $ dig +short facebook.com 173.252.120.6 NetRange: 173.252.64.0 - 173.252.127.255 CIDR: 173.252.64.0/18 NetName: FACEBOOK-INC but $ dig +short instagram.com 54.209.14.128 107.23.173.176 54.175.77.206 54.208.246.103 107.23.166.70 54.236.148.28 54.209.197.196 54.236.177.12 those are amazon addresses... err, not sure the connection makes sense though? -chris From chaim.rieger at gmail.com Tue Jan 27 06:58:21 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 26 Jan 2015 22:58:21 -0800 Subject: Facebook outage? In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: <54C7370D.1080509@gmail.com> Hacking group Lizard Sqaud claims to have taken down @facebook @instagram @Tinder @aim @Myspace From larrysheldon at cox.net Tue Jan 27 06:58:21 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 27 Jan 2015 00:58:21 -0600 Subject: Facebook outage? In-Reply-To: References: Message-ID: <54C7370D.8020705@cox.net> On 1/27/2015 00:47, Damien Burke wrote: > Facebook outage? Everyone panic! > > https://twitter.com/search?q=facebook&src=typd Let the record show that I noticed it quite a while ago, but did NOT go for first NANOG mention. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From contact at nullivex.com Tue Jan 27 07:04:42 2015 From: contact at nullivex.com (Bryan Tong) Date: Tue, 27 Jan 2015 00:04:42 -0700 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: Dead here from a close peering link. 1 10ge11-3.core1.lax1.he.net (65.49.27.149) [AS 6939] 4 msec 12 msec 0 msec 2 10ge1-3.core1.lax2.he.net (72.52.92.122) [AS 6939] 0 msec 8 msec 4 msec 3 any2ix.coresite.com (206.72.210.161) 0 msec 4 msec 0 msec 4 be2.bb01.lax1.tfbnw.net (31.13.30.24) [AS 32934] [MPLS: Label 20180 Exp 2] 64 msec 68 msec be2.bb02.lax1.tfbnw.net (31.13.30.26) [AS 32934] [MPLS: Label 18881 Exp 2] 56 msec 5 ae31.bb01.atl1.tfbnw.net (204.15.20.76) [AS 32934] [MPLS: Label 688077 Exp 2] 100 msec ae12.bb01.atl1.tfbnw.net (31.13.28.109) [AS 32934] [MPLS: Label 706669 Exp 2] 56 msec ae31.bb01.atl1.tfbnw.net (204.15.20.76) [AS 32934] [MPLS: Label 687613 Exp 2] 76 msec 6 be25.bb01.frc3.tfbnw.net (204.15.23.53) [AS 32934] [MPLS: Label 16526 Exp 2] 60 msec 64 msec 72 msec 7 ae60.dr03.frc3.tfbnw.net (74.119.79.11) [AS 32934] 96 msec ae60.dr01.frc3.tfbnw.net (204.15.23.247) [AS 32934] 56 msec ae60.dr03.frc3.tfbnw.net (74.119.79.11) [AS 32934] 64 msec 8 * * * 9 * * * On Mon, Jan 26, 2015 at 11:57 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > snow, it's a terrible thing. > > On Tue, Jan 27, 2015 at 1:50 AM, Damien Burke > wrote: > > I hear that AIM and hipchat is also having issues. > > > > Any other major company down too? > > > > -----Original Message----- > > From: John van Oppen [mailto:jvanoppen at spectrumnet.us] > > Sent: Monday, January 26, 2015 10:49 PM > > To: Damien Burke; nanog at nanog.org > > Subject: RE: Facebook outage? > > > > Dead here at AS11404 from all locations where we PNI or public peer... > > > > must be bad over there, v4 dies at their edge, v6 makes it in but no > page loads. > > > > John > -- eSited LLC (701) 390-9638 From zacharyw09264 at gmail.com Tue Jan 27 07:04:58 2015 From: zacharyw09264 at gmail.com (Zachary) Date: Tue, 27 Jan 2015 02:04:58 -0500 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: Seems unlikely, probably taking credit for someone tripping over a cable. On Jan 27, 2015 2:01 AM, "Trent Farrell" wrote: > https://twitter.com/LizardMafia/status/559963134006292481 > > On Mon, Jan 26, 2015 at 10:50 PM, Damien Burke > wrote: > > > I hear that AIM and hipchat is also having issues. > > > > Any other major company down too? > > > > -----Original Message----- > > From: John van Oppen [mailto:jvanoppen at spectrumnet.us] > > Sent: Monday, January 26, 2015 10:49 PM > > To: Damien Burke; nanog at nanog.org > > Subject: RE: Facebook outage? > > > > Dead here at AS11404 from all locations where we PNI or public peer... > > > > must be bad over there, v4 dies at their edge, v6 makes it in but no page > > loads. > > > > John > > > > > > -- > > *Trent Farrell* > > *Riot Games* > > *IP Network Engineer* > > E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 > > Summoner name: Foro > From raphael.timothy at gmail.com Tue Jan 27 07:08:53 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Tue, 27 Jan 2015 15:08:53 +0800 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: <658E1236-F6DE-46C3-B59C-4C87D8C848FC@gmail.com> Instagram used to use Amazon AWS before being purchased by Facebook. There has been a slow migration onto FB infrastructure, so yes, a mixture of addresses like that makes sense. - Tim > On 27 Jan 2015, at 2:58 pm, Christopher Morrow wrote: > > On Tue, Jan 27, 2015 at 1:56 AM, Jason Canady wrote: >> Instagram appears to be down as well, but that would make sense since they are part of Facebook. >> > > $ dig +short facebook.com > 173.252.120.6 > > NetRange: 173.252.64.0 - 173.252.127.255 > CIDR: 173.252.64.0/18 > NetName: FACEBOOK-INC > > > but > $ dig +short instagram.com > 54.209.14.128 > 107.23.173.176 > 54.175.77.206 > 54.208.246.103 > 107.23.166.70 > 54.236.148.28 > 54.209.197.196 > 54.236.177.12 > > > those are amazon addresses... err, not sure the connection makes sense though? > > -chris From raphael.timothy at gmail.com Tue Jan 27 07:12:08 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Tue, 27 Jan 2015 15:12:08 +0800 Subject: Facebook outage? In-Reply-To: <658E1236-F6DE-46C3-B59C-4C87D8C848FC@gmail.com> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> <658E1236-F6DE-46C3-B59C-4C87D8C848FC@gmail.com> Message-ID: And it appears to be back for me. - Tim > On 27 Jan 2015, at 3:08 pm, Tim Raphael wrote: > > Instagram used to use Amazon AWS before being purchased by Facebook. > There has been a slow migration onto FB infrastructure, so yes, a mixture of addresses like that makes sense. > > - Tim > > >> On 27 Jan 2015, at 2:58 pm, Christopher Morrow wrote: >> >> On Tue, Jan 27, 2015 at 1:56 AM, Jason Canady wrote: >>> Instagram appears to be down as well, but that would make sense since they are part of Facebook. >>> >> >> $ dig +short facebook.com >> 173.252.120.6 >> >> NetRange: 173.252.64.0 - 173.252.127.255 >> CIDR: 173.252.64.0/18 >> NetName: FACEBOOK-INC >> >> >> but >> $ dig +short instagram.com >> 54.209.14.128 >> 107.23.173.176 >> 54.175.77.206 >> 54.208.246.103 >> 107.23.166.70 >> 54.236.148.28 >> 54.209.197.196 >> 54.236.177.12 >> >> >> those are amazon addresses... err, not sure the connection makes sense though? >> >> -chris > From larrysheldon at cox.net Tue Jan 27 07:13:36 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 27 Jan 2015 01:13:36 -0600 Subject: Facebook outage? In-Reply-To: <54C7370D.8020705@cox.net> References: <54C7370D.8020705@cox.net> Message-ID: <54C73AA0.6010606@cox.net> On 1/27/2015 00:58, Larry Sheldon wrote: > On 1/27/2015 00:47, Damien Burke wrote: >> Facebook outage? Everyone panic! >> >> https://twitter.com/search?q=facebook&src=typd > > Let the record show that I noticed it quite a while ago, but did NOT go > for first NANOG mention. > It is back up in Omaha. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From adairw at amarillowireless.net Tue Jan 27 03:59:00 2015 From: adairw at amarillowireless.net (Adair Winter) Date: Mon, 26 Jan 2015 21:59:00 -0600 Subject: scaling linux-based router hardware recommendations In-Reply-To: <20018125.11558.1422330721500.JavaMail.mhammett@ThunderFuck> References: <20150127032928.GI24849@sizone.org> <20018125.11558.1422330721500.JavaMail.mhammett@ThunderFuck> Message-ID: A Maxxwave Routermxx MW-RM1300-i7 (x86 mikrotik router) pulls full tables from two peers and converges in about 40 seconds. On Mon, Jan 26, 2015 at 9:51 PM, Mike Hammett wrote: > Depends on the hardware. 30 - 45 seconds for the higher end stuff? I'm not > sure how long it is on an RB750 (list price of like $40). ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Ken Chase" > To: nanog at nanog.org > Sent: Monday, January 26, 2015 9:29:28 PM > Subject: Re: scaling linux-based router hardware recommendations > > Hows convergence time on these mikrotik/ubiquity/etc units for a full > table? > > /kc > -- > Ken Chase - math at sizone.org Toronto > > > -- Adair Winter VP, Network Operations / Owner Amarillo Wireless | 806.316.5071 C: 806.231.7180 http://www.amarillowireless.net From gary at byoteki.com Tue Jan 27 07:12:04 2015 From: gary at byoteki.com (Gary Josack) Date: Mon, 26 Jan 2015 23:12:04 -0800 Subject: Facebook outage? In-Reply-To: <54C7370D.1080509@gmail.com> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> <54C7370D.1080509@gmail.com> Message-ID: The js console for hipchat shows tons of connection errors and 503s to facebook.com. It's like just a facebook outage and breaking sites that have facebook login options. On Mon, Jan 26, 2015 at 10:58 PM, Chaim Rieger wrote: > Hacking group Lizard Sqaud claims to have taken down @facebook > @instagram > @Tinder > @aim @Myspace > > From math at sizone.org Tue Jan 27 07:00:46 2015 From: math at sizone.org (Ken Chase) Date: Tue, 27 Jan 2015 02:00:46 -0500 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: <20150127070046.GL24849@sizone.org> down from toronto. instagram too, of course. /kc -- Ken Chase - math at sizone.org Toronto From ops.lists at gmail.com Tue Jan 27 07:22:55 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 27 Jan 2015 12:52:55 +0530 Subject: Facebook outage? In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> Message-ID: It is back now fwiw On Jan 27, 2015 12:18 PM, "Damien Burke" wrote: > Facebook outage? Everyone panic! > > https://twitter.com/search?q=facebook&src=typd > > -Damien > From math at sizone.org Tue Jan 27 07:12:07 2015 From: math at sizone.org (Ken Chase) Date: Tue, 27 Jan 2015 02:12:07 -0500 Subject: Facebook outage? In-Reply-To: <54C7370D.1080509@gmail.com> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> <54C7370D.1080509@gmail.com> Message-ID: <20150127071207.GM24849@sizone.org> Some busted links there, but http://www.bbc.co.uk/newsbeat/30306319 /kc On Mon, Jan 26, 2015 at 10:58:21PM -0800, Chaim Rieger said: >Hacking group Lizard Sqaud claims to have taken down @facebook >@instagram >@Tinder >@aim @Myspace > -- Ken Chase - math at sizone.org Toronto From pavel.odintsov at gmail.com Tue Jan 27 07:33:16 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 27 Jan 2015 11:33:16 +0400 Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: Hello! Looks like somebody want to build Linux soft router!) Nice idea for routing 10-30 GBps. I route about 5+ Gbps in Xeon E5-2620v2 with 4 10GE cards Intel 82599 and Debian Wheezy 3.2 (but it's really terrible kernel, everyone should use modern kernels since 3.16 because "buggy linux route cache"). My current processor load on server is about: 15%, thus I can route about 15 GE on my Linux server. Surely, you should deploy backup server too if master server fails. On Tue, Jan 27, 2015 at 1:53 AM, micah anderson wrote: > > Hi, > > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > -- Sincerely yours, Pavel Odintsov From math at sizone.org Tue Jan 27 07:23:42 2015 From: math at sizone.org (Ken Chase) Date: Tue, 27 Jan 2015 02:23:42 -0500 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> Message-ID: <20150127072342.GN24849@sizone.org> cable was replugged, insta/fb back up here. /kc On Tue, Jan 27, 2015 at 02:04:58AM -0500, Zachary said: >Seems unlikely, probably taking credit for someone tripping over a cable. -- Ken Chase - math at sizone.org Toronto From colinj at gt86car.org.uk Tue Jan 27 08:13:28 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 27 Jan 2015 08:13:28 +0000 Subject: Facebook outage? In-Reply-To: <20150127072342.GN24849@sizone.org> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <2FD50E6D13594B4C93B743BFCF9F528422CE3FAE@sbla1-exchange.sb.local> <20150127072342.GN24849@sizone.org> Message-ID: <4ECC252D-B895-4B30-8E5E-B2E117382377@gt86car.org.uk> implement service routers for pop machines using cbac checking and acl for private address range spoofing. block china ranges since never respond to abuse reports. move on Colin > On 27 Jan 2015, at 07:23, Ken Chase wrote: > > cable was replugged, insta/fb back up here. > > /kc > > On Tue, Jan 27, 2015 at 02:04:58AM -0500, Zachary said: >> Seems unlikely, probably taking credit for someone tripping over a cable. > > -- > Ken Chase - math at sizone.org Toronto From contact at winterei.se Tue Jan 27 10:54:49 2015 From: contact at winterei.se (Paul S.) Date: Tue, 27 Jan 2015 19:54:49 +0900 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: <54C76E79.7030900@winterei.se> Anyone aware of any dpdk enabled solutions in the software routing space that doesn't cost an arm and a leg? vMX certainly does. On 1/27/2015 午後 04:33, Pavel Odintsov wrote: > Hello! > > Looks like somebody want to build Linux soft router!) Nice idea for > routing 10-30 GBps. I route about 5+ Gbps in Xeon E5-2620v2 with 4 > 10GE cards Intel 82599 and Debian Wheezy 3.2 (but it's really terrible > kernel, everyone should use modern kernels since 3.16 because "buggy > linux route cache"). My current processor load on server is about: > 15%, thus I can route about 15 GE on my Linux server. > > Surely, you should deploy backup server too if master server fails. > > On Tue, Jan 27, 2015 at 1:53 AM, micah anderson wrote: >> Hi, >> >> I know that specially programmed ASICs on dedicated hardware like Cisco, >> Juniper, etc. are going to always outperform a general purpose server >> running gnu/linux, *bsd... but I find the idea of trying to use >> proprietary, NSA-backdoored devices difficult to accept, especially when >> I don't have the budget for it. >> >> I've noticed that even with a relatively modern system (supermicro with >> a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >> adapters, and 16gig of ram, you still tend to get high percentage of >> time working on softirqs on all the CPUs when pps reaches somewhere >> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >> DDoS, such hardware cannot typically cope). >> >> It seems like finding hardware more optimized for very high packet per >> second counts would be a good thing to do. I just have no idea what is >> out there that could meet these goals. I'm unsure if faster CPUs, or >> more CPUs is really the problem, or networking cards, or just plain old >> fashioned tuning. >> >> Any ideas or suggestions would be welcome! >> micah >> > > From pavel.odintsov at gmail.com Tue Jan 27 11:14:47 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 27 Jan 2015 15:14:47 +0400 Subject: scaling linux-based router hardware recommendations In-Reply-To: <54C76E79.7030900@winterei.se> References: <87vbjt6tml.fsf@muck.riseup.net> <54C76E79.7030900@winterei.se> Message-ID: Hello! You could try to build simple router with DPDK yourself. It's very straightforward and have good examples for simple routing. I have done some tests with PF_RING ZC (it's very similar technology to DPDK without specialization on building of network devices) while test my DDoS monitoring solution and it work perfectly. I can achieve 8 million of packets per second (10GE with 120byte packets) on very slow Intel Xeon E5 2420. You could look at this tests from PF_RING developers: http://www.ntop.org/pf_ring/pf_ring-dna-rfc-2544-benchmark/ But building router on top of PF_RING or DPDK is very challenging task because everyone want very different things (BGP, OSPF, RIP... etc.). On Tue, Jan 27, 2015 at 1:54 PM, Paul S. wrote: > Anyone aware of any dpdk enabled solutions in the software routing space > that doesn't cost an arm and a leg? > > vMX certainly does. > > > On 1/27/2015 午後 04:33, Pavel Odintsov wrote: >> >> Hello! >> >> Looks like somebody want to build Linux soft router!) Nice idea for >> routing 10-30 GBps. I route about 5+ Gbps in Xeon E5-2620v2 with 4 >> 10GE cards Intel 82599 and Debian Wheezy 3.2 (but it's really terrible >> kernel, everyone should use modern kernels since 3.16 because "buggy >> linux route cache"). My current processor load on server is about: >> 15%, thus I can route about 15 GE on my Linux server. >> >> Surely, you should deploy backup server too if master server fails. >> >> On Tue, Jan 27, 2015 at 1:53 AM, micah anderson wrote: >>> >>> Hi, >>> >>> I know that specially programmed ASICs on dedicated hardware like Cisco, >>> Juniper, etc. are going to always outperform a general purpose server >>> running gnu/linux, *bsd... but I find the idea of trying to use >>> proprietary, NSA-backdoored devices difficult to accept, especially when >>> I don't have the budget for it. >>> >>> I've noticed that even with a relatively modern system (supermicro with >>> a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >>> adapters, and 16gig of ram, you still tend to get high percentage of >>> time working on softirqs on all the CPUs when pps reaches somewhere >>> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >>> DDoS, such hardware cannot typically cope). >>> >>> It seems like finding hardware more optimized for very high packet per >>> second counts would be a good thing to do. I just have no idea what is >>> out there that could meet these goals. I'm unsure if faster CPUs, or >>> more CPUs is really the problem, or networking cards, or just plain old >>> fashioned tuning. >>> >>> Any ideas or suggestions would be welcome! >>> micah >>> >> >> > -- Sincerely yours, Pavel Odintsov From baldur.norddahl at gmail.com Tue Jan 27 11:56:29 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 27 Jan 2015 12:56:29 +0100 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> <54C76E79.7030900@winterei.se> Message-ID: I propose the hybrid solution: A device such as the ZTE 5960e with 24x 10G and 2x 40G will set you about USD 6000 back. This thing can do MPLS and L3 equal cost multiple path routing. With that you can load balance across as many software routers as you need. It also speaks BGP and can accept about 10k routes. So maybe you could consider if the full table is really worth it. It would be possible to have your software router speak BGP with the neighbors and use next hop to direct the traffic directly to the switch. Or use proxy arp if the peer does not want to allow you to specify a different next hop than the BGP speaker. This way your software router is only moving outgoing packets. Inbound packets will never go through the computer, but will instead be delivered directly to the correct destination by hardware switching. If you are an ISP, you will often have more inbound traffic so this very useful. Also the weak point of the software router is denial of service attacks with small packets. The attacks are likely from outside your network so your software router will not need to route it. We need someone to code a BGP daemon, that will export the 5k most used routes to the switch. This way you can have the switch deliver the majority of the traffic directly to your peers. If you are a service provider, much of your traffic is outbound. Put your servers or multiple routers/firewalls on the same vlan as your transit. Then add static host routes for next hop on all servers. This way you can have as many servers as you need to deliver traffic directly. You can run iBGP on all the servers, so every server knows how to route outbound by itself. MPLS would also be useful for this instead of vlan, but there is no good MPLS implementation for Linux. Regards, Baldur From refresh.lsong at gmail.com Tue Jan 27 13:45:38 2015 From: refresh.lsong at gmail.com (Song Li) Date: Tue, 27 Jan 2015 21:45:38 +0800 Subject: look for BGP routes containing local AS# Message-ID: <54C79682.9020802@gmail.com> Hi everyone, Recently I studied the BGP AS path looping problem, and found that in most cases, the received BGP routes containing local AS# are suspicious. However, we checked our BGP routing table (AS23910,CERNET2) on juniper router(show route hidden terse aspath-regex .*23910.* ), and have not found such routes in Adj-RIB-In. We believe that the received BGP routes containing local AS# are related to BGP security problem. Hence, we want to look for some real cases in the wild. Could anybody give us some examples of such routes? Thanks! Best Regards! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From bb at 1stclasshosting.com Tue Jan 27 14:47:29 2015 From: bb at 1stclasshosting.com (Brad Bendy) Date: Tue, 27 Jan 2015 07:47:29 -0700 Subject: AT&T uVerse blocking SIP? In-Reply-To: References: <3291F28A-7010-46B5-955E-F2AFFDCD688F@puck.nether.net> Message-ID: They are saying this CPE has no ALG in it, but they can enable DMZ, which acourse made zero difference. What I do find funny is they escalated the problem to Tier-2 and wanted to enroll the customer in premium tech support for $15 a month, because the Internet signal is strong and is not causing the problem, sigh. Back to trying port 5061 it appears! On Mon, Jan 26, 2015 at 8:44 PM, Christopher Morrow wrote: > I think this is due to the CPE using a particular ALG ... (from > recollection having never been a UVerse customer, but having sat > through a long, long, long set of discussions about the > merits/demerits of sip blocking) > > On Mon, Jan 26, 2015 at 10:22 PM, Jared Mauch > wrote: > > Yes. If you move to another port, e.g.: 5061 it works fine. > > > > If you’re running on a Linux based system, you can do this: > > > > /sbin/iptables -A PREROUTING -t nat -i eth1 -p udp --dport 5061 -j > REDIRECT --to-port 5060 > > > > on the host to remap 5061 -> 5060 with no application change. > > > > - Jared > > > >> On Jan 26, 2015, at 4:26 PM, Brad Bendy wrote: > >> > >> Has anyone seen issues where a end user on uVerse trying to connect to > >> either another provider or AT&T non uVerse (in this case DIA) is having > SIP > >> blocked? SIP leaving the uVerse network going to another uVerse DSL > account > >> is fine, but it appears soon as it leave the uVerse network all SIP > traffic > >> is blocked? > >> > >> It appears others have seen this problem, some say it's a modem issue, > some > >> say they are truly blocking it. Ive yet to call uVerse support yet as im > >> guessing ill get no where. > >> > >> Thanks for any insight on this. > >> > >> -- > >> This message contains confidential information and is intended only for > the > >> individual named. If you are not the named addressee you should not > >> disseminate, distribute or copy this e-mail. Please notify the sender > >> 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. > >> The sender 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. If verification is required please request a hard-copy > >> version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, > Cheyenne, WY > >> 82001 > > > -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender 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. The sender 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. If verification is required please request a hard-copy version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, Cheyenne, WY 82001 From jared at puck.nether.net Tue Jan 27 14:50:34 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 Jan 2015 09:50:34 -0500 Subject: AT&T uVerse blocking SIP? In-Reply-To: References: <3291F28A-7010-46B5-955E-F2AFFDCD688F@puck.nether.net> Message-ID: I’ve never gotten AT&T to respond to issues, including the fact the device eats the SIP packets, and some types of SIP packets can actually cause their device to reboot as well. It’s been a few years now since I really chased this down, but beware all of these ‘helpers’, including the Cisco SIP-ALG are broken. It’s more damage introduced by these CPE devices (like broken DNS proxies, etc). - Jared > On Jan 27, 2015, at 9:47 AM, Brad Bendy wrote: > > They are saying this CPE has no ALG in it, but they can enable DMZ, which acourse made zero difference. > > What I do find funny is they escalated the problem to Tier-2 and wanted to enroll the customer in premium tech support for $15 a month, because the Internet signal is strong and is not causing the problem, sigh. > > Back to trying port 5061 it appears! > > On Mon, Jan 26, 2015 at 8:44 PM, Christopher Morrow wrote: > I think this is due to the CPE using a particular ALG ... (from > recollection having never been a UVerse customer, but having sat > through a long, long, long set of discussions about the > merits/demerits of sip blocking) > > On Mon, Jan 26, 2015 at 10:22 PM, Jared Mauch wrote: > > Yes. If you move to another port, e.g.: 5061 it works fine. > > > > If you’re running on a Linux based system, you can do this: > > > > /sbin/iptables -A PREROUTING -t nat -i eth1 -p udp --dport 5061 -j REDIRECT --to-port 5060 > > > > on the host to remap 5061 -> 5060 with no application change. > > > > - Jared > > > >> On Jan 26, 2015, at 4:26 PM, Brad Bendy wrote: > >> > >> Has anyone seen issues where a end user on uVerse trying to connect to > >> either another provider or AT&T non uVerse (in this case DIA) is having SIP > >> blocked? SIP leaving the uVerse network going to another uVerse DSL account > >> is fine, but it appears soon as it leave the uVerse network all SIP traffic > >> is blocked? > >> > >> It appears others have seen this problem, some say it's a modem issue, some > >> say they are truly blocking it. Ive yet to call uVerse support yet as im > >> guessing ill get no where. > >> > >> Thanks for any insight on this. > >> > >> -- > >> This message contains confidential information and is intended only for the > >> individual named. If you are not the named addressee you should not > >> disseminate, distribute or copy this e-mail. Please notify the sender > >> 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. > >> The sender 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. If verification is required please request a hard-copy > >> version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, Cheyenne, WY > >> 82001 > > > > > > > > > > This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender 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. The sender 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. If verification is required please request a hard-copy version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, Cheyenne, WY 82001 From bb at 1stclasshosting.com Tue Jan 27 14:58:35 2015 From: bb at 1stclasshosting.com (Brad Bendy) Date: Tue, 27 Jan 2015 07:58:35 -0700 Subject: AT&T uVerse blocking SIP? In-Reply-To: References: <3291F28A-7010-46B5-955E-F2AFFDCD688F@puck.nether.net> Message-ID: I agree. I always leave ALGs off, its just 10x harder when the support asked what SIP was and then told me it's not a common protocol since it's not in his magic book :) On Tue, Jan 27, 2015 at 7:50 AM, Jared Mauch wrote: > I’ve never gotten AT&T to respond to issues, including the fact the device > eats the SIP packets, and some types of SIP packets can actually cause > their device to reboot as well. > > It’s been a few years now since I really chased this down, but beware all > of these ‘helpers’, including the Cisco SIP-ALG are broken. It’s more > damage introduced by these CPE devices (like broken DNS proxies, etc). > > - Jared > > > On Jan 27, 2015, at 9:47 AM, Brad Bendy wrote: > > > > They are saying this CPE has no ALG in it, but they can enable DMZ, > which acourse made zero difference. > > > > What I do find funny is they escalated the problem to Tier-2 and wanted > to enroll the customer in premium tech support for $15 a month, because the > Internet signal is strong and is not causing the problem, sigh. > > > > Back to trying port 5061 it appears! > > > > On Mon, Jan 26, 2015 at 8:44 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > > I think this is due to the CPE using a particular ALG ... (from > > recollection having never been a UVerse customer, but having sat > > through a long, long, long set of discussions about the > > merits/demerits of sip blocking) > > > > On Mon, Jan 26, 2015 at 10:22 PM, Jared Mauch > wrote: > > > Yes. If you move to another port, e.g.: 5061 it works fine. > > > > > > If you’re running on a Linux based system, you can do this: > > > > > > /sbin/iptables -A PREROUTING -t nat -i eth1 -p udp --dport 5061 -j > REDIRECT --to-port 5060 > > > > > > on the host to remap 5061 -> 5060 with no application change. > > > > > > - Jared > > > > > >> On Jan 26, 2015, at 4:26 PM, Brad Bendy > wrote: > > >> > > >> Has anyone seen issues where a end user on uVerse trying to connect to > > >> either another provider or AT&T non uVerse (in this case DIA) is > having SIP > > >> blocked? SIP leaving the uVerse network going to another uVerse DSL > account > > >> is fine, but it appears soon as it leave the uVerse network all SIP > traffic > > >> is blocked? > > >> > > >> It appears others have seen this problem, some say it's a modem > issue, some > > >> say they are truly blocking it. Ive yet to call uVerse support yet as > im > > >> guessing ill get no where. > > >> > > >> Thanks for any insight on this. > > >> > > >> -- > > >> This message contains confidential information and is intended only > for the > > >> individual named. If you are not the named addressee you should not > > >> disseminate, distribute or copy this e-mail. Please notify the sender > > >> 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. > > >> The sender 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. If verification is required please request a hard-copy > > >> version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, > Cheyenne, WY > > >> 82001 > > > > > > > > > > > > > > > > > > > This message contains confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > 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. > The sender 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. If verification is required please request a hard-copy > version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, Cheyenne, WY > 82001 > > -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender 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. The sender 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. If verification is required please request a hard-copy version. 1st Class Hosting, LLC. 1712 Pioneer Ave, Suite 1854, Cheyenne, WY 82001 From r.engehausen at gmail.com Tue Jan 27 15:02:47 2015 From: r.engehausen at gmail.com (Roy) Date: Tue, 27 Jan 2015 07:02:47 -0800 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> Message-ID: <54C7A897.5020504@gmail.com> According to one joker, the crash was caused by too many pictures of the Northeast blizzard :-) From hugo at slabnet.com Tue Jan 27 16:22:52 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 27 Jan 2015 08:22:52 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: <20150127162252.GE21113@bamboo.slabnet.com> There is also some work in progress to improve network performance in the Linux kernel: https://lwn.net/Articles/629155/ Preliminary, but encouraging that work is under way. -- Hugo On Tue 2015-Jan-27 11:33:16 +0400, Pavel Odintsov wrote: >Hello! > >Looks like somebody want to build Linux soft router!) Nice idea for >routing 10-30 GBps. I route about 5+ Gbps in Xeon E5-2620v2 with 4 >10GE cards Intel 82599 and Debian Wheezy 3.2 (but it's really terrible >kernel, everyone should use modern kernels since 3.16 because "buggy >linux route cache"). My current processor load on server is about: >15%, thus I can route about 15 GE on my Linux server. > >Surely, you should deploy backup server too if master server fails. > >On Tue, Jan 27, 2015 at 1:53 AM, micah anderson wrote: >> >> Hi, >> >> I know that specially programmed ASICs on dedicated hardware like Cisco, >> Juniper, etc. are going to always outperform a general purpose server >> running gnu/linux, *bsd... but I find the idea of trying to use >> proprietary, NSA-backdoored devices difficult to accept, especially when >> I don't have the budget for it. >> >> I've noticed that even with a relatively modern system (supermicro with >> a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >> adapters, and 16gig of ram, you still tend to get high percentage of >> time working on softirqs on all the CPUs when pps reaches somewhere >> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >> DDoS, such hardware cannot typically cope). >> >> It seems like finding hardware more optimized for very high packet per >> second counts would be a good thing to do. I just have no idea what is >> out there that could meet these goals. I'm unsure if faster CPUs, or >> more CPUs is really the problem, or networking cards, or just plain old >> fashioned tuning. >> >> Any ideas or suggestions would be welcome! >> micah >> > > > >-- >Sincerely yours, Pavel Odintsov -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From listas at esds.com.br Tue Jan 27 16:27:28 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 27 Jan 2015 14:27:28 -0200 Subject: scaling linux-based router hardware recommendations In-Reply-To: <20150127162252.GE21113@bamboo.slabnet.com> References: <87vbjt6tml.fsf@muck.riseup.net> <20150127162252.GE21113@bamboo.slabnet.com> Message-ID: Can be Freebsd-based? http://info.iet.unipi.it/~luigi/netmap/ 2015-01-27 14:22 GMT-02:00 Hugo Slabbert : > There is also some work in progress to improve network performance in the > Linux kernel: > > https://lwn.net/Articles/629155/ > > Preliminary, but encouraging that work is under way. > > -- > Hugo > > > On Tue 2015-Jan-27 11:33:16 +0400, Pavel Odintsov < > pavel.odintsov at gmail.com> wrote: > > Hello! >> >> Looks like somebody want to build Linux soft router!) Nice idea for >> routing 10-30 GBps. I route about 5+ Gbps in Xeon E5-2620v2 with 4 >> 10GE cards Intel 82599 and Debian Wheezy 3.2 (but it's really terrible >> kernel, everyone should use modern kernels since 3.16 because "buggy >> linux route cache"). My current processor load on server is about: >> 15%, thus I can route about 15 GE on my Linux server. >> >> Surely, you should deploy backup server too if master server fails. >> >> On Tue, Jan 27, 2015 at 1:53 AM, micah anderson wrote: >> >>> >>> Hi, >>> >>> I know that specially programmed ASICs on dedicated hardware like Cisco, >>> Juniper, etc. are going to always outperform a general purpose server >>> running gnu/linux, *bsd... but I find the idea of trying to use >>> proprietary, NSA-backdoored devices difficult to accept, especially when >>> I don't have the budget for it. >>> >>> I've noticed that even with a relatively modern system (supermicro with >>> a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >>> adapters, and 16gig of ram, you still tend to get high percentage of >>> time working on softirqs on all the CPUs when pps reaches somewhere >>> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >>> DDoS, such hardware cannot typically cope). >>> >>> It seems like finding hardware more optimized for very high packet per >>> second counts would be a good thing to do. I just have no idea what is >>> out there that could meet these goals. I'm unsure if faster CPUs, or >>> more CPUs is really the problem, or networking cards, or just plain old >>> fashioned tuning. >>> >>> Any ideas or suggestions would be welcome! >>> micah >>> >>> >> >> >> -- >> Sincerely yours, Pavel Odintsov >> > > -- > Hugo > -- Eduardo Schoedler From nanog at shankland.org Tue Jan 27 16:31:09 2015 From: nanog at shankland.org (Jim Shankland) Date: Tue, 27 Jan 2015 08:31:09 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: <54C7BD4D.1000101@shankland.org> On 1/26/15 11:33 PM, Pavel Odintsov wrote: > Hello! > > Looks like somebody want to build Linux soft router!) Nice idea for > routing 10-30 GBps. I route about 5+ Gbps in Xeon E5-2620v2 with 4 > 10GE cards Intel 82599 and Debian Wheezy 3.2 (but it's really terrible > kernel, everyone should use modern kernels since 3.16 because "buggy > linux route cache"). My current processor load on server is about: > 15%, thus I can route about 15 GE on my Linux server. > > I looked into the promise and limits of this approach pretty intensively a few years back before abandoning the effort abruptly due to other constraints. Underscoring what others have said: it's all about pps, not aggregate throughput. Modern NICs can inject packets at line rate into the kernel, and distribute them across per-processor queues, etc. Payloads end up getting DMA-ed from NIC to RAM to NIC. There's really no reason you shouldn't be able to push 80 Gb/s of traffic, or more, through these boxes. As for routing protocol performance (BGP convergence time, ability to handle multiple full tables, etc.): that's just CPU and RAM. The part that's hard (as in "can't be fixed without rethinking this approach") is the per-packet routing overhead: the cost of reading the packet header, looking up the destination in the routing table, decrementing the TTL, and enqueueing the packet on the correct outbound interface. At the time, I was able to convince myself that being able to do this in 4 us, average, in the Linux kernel, was within reach. That's not really very much time: you start asking things like "will the entire routing table fit into the L2 cache?" 4 us to "think about" each packet comes out to 250Kpps per processor; with 24 processors, it's 6Mpps (assuming zero concurrency/locking overhead, which might be a little bit of an ... assumption). With 1500-byte packets, 6Mpps is 72 Gb/s of throughput -- not too shabby. But with 40-byte packets, it's less than 2 Gb/s. Which means that your Xeon ES-2620v2 will not cope well with a DDoS of 40-byte packets. That's not necessarily a reason not to use this approach, depending on your situation; but it's something to be aware of. I ended up convincing myself that OpenFlow was the right general idea: marry fast, dumb, and cheap switching hardware with fast, smart, and cheap generic CPU for the complicated stuff. My expertise, such as it ever was, is a bit stale at this point, and my figures might be a little off. But I think the general principle applies: think about the minimum number of x86 instructions, and the minimum number of main memory accesses, to inspect a packet header, do a routing table lookup, and enqueue the packet on an outbound interface. I can't see that ever getting reduced to the point where a generic server can handle 40-byte packets at line rate (for that matter, "line rate" is increasing a lot faster than "speed of generic server" these days). Jim From larrysheldon at cox.net Tue Jan 27 18:15:18 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 27 Jan 2015 12:15:18 -0600 Subject: Facebook outage? In-Reply-To: References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> Message-ID: <54C7D5B6.80704@cox.net> On 1/27/2015 09:02, Roy wrote: > > According to one joker, the crash was caused by too many pictures of the > Northeast blizzard :-) Cat-picture server went down. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From bedard.phil at gmail.com Tue Jan 27 18:16:11 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 27 Jan 2015 13:16:11 -0500 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> <54C76E79.7030900@winterei.se> Message-ID: There are some interesting ideas. There are tricks to getting 128K LPM routes into a Trident2 device like you mentioned. You can get the same type of devices from Cisco/Juniper for not a whole lot more, what you are really paying for is the mature control plane. https://github.com/dbarrosop/sir is a project from David Barasso at Spotify. The BGP daemon on your Internet-connected device may store all the routes in its RIB but usually doesn't need everything in the FIB. A downstream BGP controller running on a x86 server would analyze the routes more closely and use something like Netflow/Sflow (or really any criteria) to identify the routes you really care about and install those into the FIB on the device and just use the default for everything else. Metaswitch, a commercial control-plane company, had a similar idea using Openflow where the actual Internet connected device just proxied BGP connections to a controller which then went back and programmed the upstream Openflow switches. They call them "lean transit switches." The major network vendors all have the ability to run their control planes in software on x86 these days just fine. On many newer platforms they them run the software as a VM anyways. Pricing for bringing your own server is going to be cheaper, but not free. As for open source type stuff, Contrail from Juniper was made open source and has a BGP implementation, MPLS (MPLSoUDP) implementation, and a Linux kernel module to do fairly high speed packet forwarding, what they call the vRouter in Contrail. Wind River is another vendor who has incorporated the Intel DPDK stuff into a Linux distribution, but it is commercial as well. Phil On 1/27/15, 11:56, "Baldur Norddahl" wrote: >I propose the hybrid solution: > >A device such as the ZTE 5960e with 24x 10G and 2x 40G will set you about >USD 6000 back. > >This thing can do MPLS and L3 equal cost multiple path routing. With that >you can load balance across as many software routers as you need. > >It also speaks BGP and can accept about 10k routes. So maybe you could >consider if the full table is really worth it. > >It would be possible to have your software router speak BGP with the >neighbors and use next hop to direct the traffic directly to the switch. >Or >use proxy arp if the peer does not want to allow you to specify a >different >next hop than the BGP speaker. This way your software router is only >moving >outgoing packets. Inbound packets will never go through the computer, but >will instead be delivered directly to the correct destination by hardware >switching. > >If you are an ISP, you will often have more inbound traffic so this very >useful. Also the weak point of the software router is denial of service >attacks with small packets. The attacks are likely from outside your >network so your software router will not need to route it. > >We need someone to code a BGP daemon, that will export the 5k most used >routes to the switch. This way you can have the switch deliver the >majority >of the traffic directly to your peers. > >If you are a service provider, much of your traffic is outbound. Put your >servers or multiple routers/firewalls on the same vlan as your transit. >Then add static host routes for next hop on all servers. This way you can >have as many servers as you need to deliver traffic directly. You can run >iBGP on all the servers, so every server knows how to route outbound by >itself. MPLS would also be useful for this instead of vlan, but there is >no >good MPLS implementation for Linux. > >Regards, > >Baldur From owen at delong.com Tue Jan 27 18:19:44 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Jan 2015 10:19:44 -0800 Subject: Facebook outage? In-Reply-To: <54C7D5B6.80704@cox.net> References: <2FD50E6D13594B4C93B743BFCF9F528422CE3F42@sbla1-exchange.sb.local> <54C7D5B6.80704@cox.net> Message-ID: > On Jan 27, 2015, at 10:15 , Larry Sheldon wrote: > > On 1/27/2015 09:02, Roy wrote: >> >> According to one joker, the crash was caused by too many pictures of the >> Northeast blizzard :-) > > Cat-picture server went down. Putting those two things together, I think it was because really, nobody wants to see a bunch of frozen pussy. Get your minds out of the gutter. Owen From jra at baylink.com Tue Jan 27 18:24:42 2015 From: jra at baylink.com (Jay Ashworth) Date: Tue, 27 Jan 2015 13:24:42 -0500 (EST) Subject: Facebook outage? In-Reply-To: <54C7370D.8020705@cox.net> Message-ID: <29933241.1441.1422383082013.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Larry Sheldon" > On 1/27/2015 00:47, Damien Burke wrote: > > Facebook outage? Everyone panic! > > > > https://twitter.com/search?q=facebook&src=typd > > Let the record show that I noticed it quite a while ago, but did NOT > go for first NANOG mention. Proud of you, Larry. Let the record show that *I* haven't seen any outages all day, from Sprint LTE. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mureninc at gmail.com Tue Jan 27 20:37:45 2015 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 27 Jan 2015 12:37:45 -0800 Subject: AT&T uVerse blocking SIP? In-Reply-To: References: Message-ID: On 26 January 2015 at 13:26, Brad Bendy wrote: > Has anyone seen issues where a end user on uVerse trying to connect to > either another provider or AT&T non uVerse (in this case DIA) is having SIP > blocked? SIP leaving the uVerse network going to another uVerse DSL account > is fine, but it appears soon as it leave the uVerse network all SIP traffic > is blocked? I used to have AT&T U-verse a couple of years back. Never had any issues with SIP. Although I've stopped using their modem prior to starting to use SIP, directly connecting my own router to their ONT, so, I cannot comment on whether their 2Wire PoS is the cause of the issues you experience (but it's indeed quite likely so). It's worth checking with your customer whether they can throw away their modem, too. The modem has two ports -- green-coloured PHONE LINE and red-coloured BROADBAND. If they get their connection through the green PHONE LINE port, it means it's DSL. If it's through the red BROADBAND port, it means no modem is required (other than every couple of months or years for some weird port authentication that they require), and can swap their at&t PoS with any other router. C. From ryan at finnesey.com Tue Jan 27 21:20:48 2015 From: ryan at finnesey.com (Ryan Finnesey) Date: Tue, 27 Jan 2015 21:20:48 +0000 Subject: Network ops lists. Message-ID: <97D1EEAD-7A7F-423B-A111-AD157595C0B7@finnesey.com> At one point I stumbled across a site that listed all of the network ops lists for the corresponding regions but now I can't seem to find it would anyone happen to have a similar list? Sent from my iPad From corbe at corbe.net Tue Jan 27 21:33:18 2015 From: corbe at corbe.net (Daniel Corbe) Date: Tue, 27 Jan 2015 16:33:18 -0500 Subject: Network ops lists. In-Reply-To: <97D1EEAD-7A7F-423B-A111-AD157595C0B7@finnesey.com> (Ryan Finnesey's message of "Tue, 27 Jan 2015 21:20:48 +0000") References: <97D1EEAD-7A7F-423B-A111-AD157595C0B7@finnesey.com> Message-ID: <87egqfsych.fsf@corbe.net> Ryan Finnesey writes: > At one point I stumbled across a site that listed all of the network > ops lists for the corresponding regions but now I can't seem to find > it would anyone happen to have a similar list? > Are you referring to a list regional NOGs? Because there's other interesting content out there too, like dns-operations and voice-ops, v6-operations, etc. -Daniel From ajeffri at angrywithunicorns.org Tue Jan 27 07:35:16 2015 From: ajeffri at angrywithunicorns.org (Anthony Jeffries) Date: Mon, 26 Jan 2015 23:35:16 -0800 Subject: Facebook outage? In-Reply-To: <54C73AA0.6010606@cox.net> References: <54C7370D.8020705@cox.net> <54C73AA0.6010606@cox.net> Message-ID: <1422344116.2675.4.camel@peacenik.breitnet.net> It is working here in rural Oregon as well. Kudos to the Facebook team for such a quick recovery. On Tue, 2015-01-27 at 01:13 -0600, Larry Sheldon wrote: > On 1/27/2015 00:58, Larry Sheldon wrote: > > On 1/27/2015 00:47, Damien Burke wrote: > >> Facebook outage? Everyone panic! > >> > >> https://twitter.com/search?q=facebook&src=typd > > > > Let the record show that I noticed it quite a while ago, but did NOT go > > for first NANOG mention. > > > It is back up in Omaha. > From nellermann at broadaspect.com Tue Jan 27 14:27:00 2015 From: nellermann at broadaspect.com (Nick Ellermann) Date: Tue, 27 Jan 2015 14:27:00 +0000 Subject: Cisco IOS stable/production safe versions? Message-ID: <3551369d5e2b4a9796964e4f335aa827@exchange.broadaspect.local> I have a Cisco IOS specific question for the group and also specifically related to the 6500 platform. We have always been very conservative with our IOS version that we run in production, we are still running a pretty old safe harbor build of 12.2.x on SUP 720 3BXLs with BGP and OSFP routing. Any advice from fellow network operators that are running the 6500 platform in the core still for versions that are considered safe for production? We are stable, but I am really wanting access to features such as Netflow v9, etc. Thanks for any advice! Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. From lists at rewt.org.uk Tue Jan 27 22:32:13 2015 From: lists at rewt.org.uk (Joe Holden) Date: Tue, 27 Jan 2015 22:32:13 +0000 Subject: scaling linux-based router hardware recommendations In-Reply-To: <1722876115.771987.1422314875496.JavaMail.zimbra@snappytelecom.net> References: <87vbjt6tml.fsf@muck.riseup.net> <1722876115.771987.1422314875496.JavaMail.zimbra@snappytelecom.net> Message-ID: <54C811ED.5060301@rewt.org.uk> I get more than that with realtek nics on x86, problem is high interrupt rates even with msix, intel fixes some of those and chelsio makes it all go away... Just saying :) On 26/01/2015 23:27, Faisal Imtiaz wrote: > Hi Micah, > > There is a segment in the Hardware Side of the industry that produces "Network Appliances". > (Folks such as Axiomtek, Lanner Electronics, Caswell Networks, Portwell etc etc) > > These appliances are commonly used as a commercial (OEM) platform for a variety of uses.. > Routers, Firewalls, Specialized network applications etc. > > Our internal testing ( informal), matches up with the commonly quoted PPS handling by the different product vendors who incorporate these appliances in their network product offerings. > > i3/i5/i7 (x86) based network appliances will forward traffic as long as pps does not exceed 1.4million > (In our testing we found the pps to be limiting factor and not the amount of traffic being moved) > (will easily handle 6G to 10G of traffic > > Core2duo (x86) based network appliances will forward traffic as long as pps does not exceed 600,0000 pps > (will easily handle 1.5G to 2G of traffic) > > Atom based (x86) network appliances will forward traffic as long as pps does not exceed 250,000 pps. > > ---------------------------------------- > > Of course, if you start to bog down the router with lots of NAT/ACL/ Bridge Rules (i.e. the CPU has to get involved in traffic management) then your actual performance will be degraded. > > 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: "micah anderson" >> To: nanog at nanog.org >> Sent: Monday, January 26, 2015 5:53:54 PM >> Subject: scaling linux-based router hardware recommendations >> >> >> Hi, >> >> I know that specially programmed ASICs on dedicated hardware like Cisco, >> Juniper, etc. are going to always outperform a general purpose server >> running gnu/linux, *bsd... but I find the idea of trying to use >> proprietary, NSA-backdoored devices difficult to accept, especially when >> I don't have the budget for it. >> >> I've noticed that even with a relatively modern system (supermicro with >> a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >> adapters, and 16gig of ram, you still tend to get high percentage of >> time working on softirqs on all the CPUs when pps reaches somewhere >> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >> DDoS, such hardware cannot typically cope). >> >> It seems like finding hardware more optimized for very high packet per >> second counts would be a good thing to do. I just have no idea what is >> out there that could meet these goals. I'm unsure if faster CPUs, or >> more CPUs is really the problem, or networking cards, or just plain old >> fashioned tuning. >> >> Any ideas or suggestions would be welcome! >> micah >> >> From lists at rewt.org.uk Tue Jan 27 22:34:45 2015 From: lists at rewt.org.uk (Joe Holden) Date: Tue, 27 Jan 2015 22:34:45 +0000 Subject: scaling linux-based router hardware recommendations In-Reply-To: <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> References: <21180758.11197.1422322999684.JavaMail.mhammett@ThunderFuck> Message-ID: <54C81285.5050906@rewt.org.uk> Easy to make a switch when the only thing you're actually doing is teling the asic what to do (Cumulus, Ubiquiti, ... every other broadcom vendor out there...) Better yet - Atheros have finally come out with a 24*1GE + 2*10GE switch asic - only a matter of time before they challenge broadcom et al. On 27/01/2015 01:43, Mike Hammett wrote: > Aren't most of the new whitebox\open source platforms based on switching and not routing? I'd assume that the "cloud-scale" data centers deploying this stuff still have more traditional big iron at their cores. > > The small\medium sized ISP usually is left behind. They're not big enough to afford the big new hardware, but all of their user's NetFlix and porn and whatever else they do is chewing up bandwidth. For example, the small\medium ISPs are at the Nx10GigE stage now. The new hardware is expensive, the old hardware (besides being old) is likely in a huge chassis if you can get any sort of port density at all. > > 48 port GigE switches with a couple 10GigE can be had for $100. A minimum of 24 port 10GigE switches (except for the occasional IBM switch ) is 30x to 40x times that. Routers (BGP, MPLS, etc.) with that more than just a couple 10GigEs are even more money, I'd assume. > > I thought vMX was going to save the day, but it's pricing for 10 gigs of traffic (licensed by throughput and standard\advanced licenses) is really about 5x - 10x what I'd be willing to pay for it. > > Haven't gotten a quote from AlcaLu yet. > > Vyatta (last I checked, which was admittedly some time ago) doesn't have MPLS. > > The FreeBSD world can bring zero software cost and a stable platform, but no MPLS. > > Mikrotik brings most (though not all) of the features one would want... a good enough feature set, let's say... but is a non-stop flow of bugs. I don't think a week or two goes by where one of my friends doesn't submit some sort of reproducible bug to Mikrotik. They've also been "looking into" DPDK for 2.5 years now. hasn't shown up yet. I've used MT for 10 years and I'm always left wanting just a little more, but it may be the best balance between the features and performance I want and the ability to pay for it. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Mehmet Akcin" > To: "micah anderson" > Cc: nanog at nanog.org > Sent: Monday, January 26, 2015 6:06:53 PM > Subject: Re: scaling linux-based router hardware recommendations > > Cumulus Networks has some stuff, > > http://www.bigswitch.com/sites/default/files/presentations/onug-baremetal-2014-final.pdf > > Pretty decent presentation with more details you like. > > Mehmet > >> On Jan 26, 2015, at 8:53 PM, micah anderson wrote: >> >> >> Hi, >> >> I know that specially programmed ASICs on dedicated hardware like Cisco, >> Juniper, etc. are going to always outperform a general purpose server >> running gnu/linux, *bsd... but I find the idea of trying to use >> proprietary, NSA-backdoored devices difficult to accept, especially when >> I don't have the budget for it. >> >> I've noticed that even with a relatively modern system (supermicro with >> a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server >> adapters, and 16gig of ram, you still tend to get high percentage of >> time working on softirqs on all the CPUs when pps reaches somewhere >> around 60-70k, and the traffic approaching 600-900mbit/sec (during a >> DDoS, such hardware cannot typically cope). >> >> It seems like finding hardware more optimized for very high packet per >> second counts would be a good thing to do. I just have no idea what is >> out there that could meet these goals. I'm unsure if faster CPUs, or >> more CPUs is really the problem, or networking cards, or just plain old >> fashioned tuning. >> >> Any ideas or suggestions would be welcome! >> micah >> > From edtardist at gmail.com Wed Jan 28 00:05:58 2015 From: edtardist at gmail.com (Eddie Tardist) Date: Tue, 27 Jan 2015 22:05:58 -0200 Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: On Mon, Jan 26, 2015 at 8:53 PM, micah anderson wrote: > > Hi, > > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > Hello! This is a very interesting yet obscure and not widely discussed subject. And industry generally does not like the discussion to come up in public lists like this one. If you happen to reach line rate PPS throughput on x86, for filtering or forwarding, how will they keep that high profit rate on their products and keep investors happy? With that said, I am a very happy user for two hardware vendors not widely known, and a technology very well known but still barely discussed. I run FreeBSD, the so called "silent workhorse" as a BGP router and also FreeBSD (or pfSense) as a border firewall. For hardware vendors, I am a very happy customer of: - iXSystems (www.ixsystems.com) - ServerU Inc. (www.serveru.us) They are both BSD/Linux driven hardware specialists, and they are both very good consultants and technology engineers. I run a number of BGP and firewall boxes on GA, NY, FL and some other locations on east coast, as well as Belize, BVI and Bahamas and LATAM. pfSense is my number one system of choice, but sometimes I run FreeBSD vanilla, specially in my core locations. In one central location I have the following setup: - 1x ServerU Netmap L800 box in Bridge Mode for Core Firewall protection - 2x ServerU Netmap L800 boxes as BGP router (redundant) - Several Netmap L800, L100 and iXSystems servers (iXS for everything else since ServerU are only networking-centric, not high storage high processing Xeon servers) In this setup I am running yet another not well known but very promising technology, called Netmap. A Netmap firewall (called netmap-ipfw) was supplied from ServerU vendor, it's a slightly modified version from what you can download from Luigi Rizzo's (netmap author) public repository with multithread capabilities based on the number of queues available in the ServerU igb(4) networking card. What it does is, IMHO, amazing for a x86 hardware: line rate firewall on 1GbE port (1.3-1.4Mpps) and line rate firewall for 10GbE port (12-14Mpps) in a system with 8 @2.4Ghz Intel Rangeley CPU. It's not Linux DNA. It's not PF_RING. It's not Intel DPDK. It's netmap, it's there, available, on FreeBSD base system with a number of utilities and code for reference on Rizzos' repositories. It's there, it's available and it's amazing. This firewall has saved my sleep several times since November, dropping up to 9Mpps amplified UDP/NTP traffic on peak DDoS attack rates. For the BGP box, I needed trunking, Q-in-Q and vlan. And sadly right now this is not available in a netmap implementation. It means I had to keep my BGP router in the kernel path. It's funny to say this, but Netmap usually skips kernel path completely and does its job direct on the NIC, reaching backplane and bus limits directly. ServerU people recommended me to use Chelsio Terminator 5 40G ports. OK I only needed 10G but they convinced me not to look at the bits per second numbers but the packets per seconds number. Honestly, I don't know how Chelsio T5 did it, even though ServerU 1GbE ports perform very good on interruption CPU usage (probably this is an Intel igb(4) / ix(4) credit) but everything I route from one 40GbE port to the other port on the same L-800 expansion card, I have very, very, very LOW interrupt rates. Sometimes I have no interrupt at all!! I peaked routing 6Mpps on ServerU L-800 and still had CPU there, available. I am not sure where proper credits is due to ServerU hardware, to FreeBSD OS, to Netmap or to Chelsio. But I am sure on what it matters for my VP or my CFO: $$$ While a T5 card will cost around USD 1,000 and a ServerU L-800 router will cost another USD 1,200, I have a 2,2k USD overall cost of ownership for a box that will give me PPS rates that otherwise would cost from 9,000 USD to 12,000 USD on an industry product. I have followed a good discussion on a Linkedin Group (anyone googling for it will find it) comparing Netmap to DPDK from the developer perspective. Netmap developer pointed some good considerations while an Intel engineer pointed some other perspectives. Overall, DPDK and Netmap sounds, from my end-user/non-developer/non-software-engineer point of view, very similar in matter of results, while different in the inner gore details with some flexibility/generalist advantages for Netmap and some hardware specifics advantages for DPDK when running Intel hardware (of course), since its like CUDA is for Nvidia... vendor specific. I honestly hope a fraction of this million dollar donated to FreeBSD Foundation from WhatsApp founder goes on research and enhancements for Netmap technology. It's the most promising networking technology I have seen in the last years, and it goes straight to what FreeBSD does best: networking performance. It's not a coincidence that since the beginning of Internet, top Internet traffic servers, from Yahoo! to WhatsApp and Netflix, run FreeBSD. I don't know how important decisions can be addressed concerning adding to a Netmap stack a superset of full forwarding capability along with lagg(4), vlan(4), Q-in-Q, maybe carp(4) and other lightweight but still very kernel-path choppy features. But I hope FreeBSD engineers take good decisions on assigning those issues. And address time, funds and goals to Netmap. For now, however, if you really want a relatively new and innovative technology with actual code to use and run, ready and available, this is my suggestion: FreeBSD+Netmap. And for hardware vendors, iXSystems + ServerU. It gets out from the speculation field, since Netmap reference code for serious stuff, including a whole firewall, is available and ready to test, compare results, enhance and use. Suricata IDP has Netmap support, so yes, you can inspect close to line rate packets on IDS (not IPS) mode with Suricata. For everything else, DPDK, DNA, PF_RING, you have a framework in place. Some are experimental, some are more mature, but you will have to code and prove it by yourself. While FreeBSD/Netmap is a flavor ready to be tasted. This is my 5 cents opinion for such a great topic! Concerning BGP convergence time. Come on, are you serious? You deal with platforms that take 1 minute, up to 3 minutes for full convergence of a couple of bgp FULL sessions? What hardware is that? A Nintendo 8bits? LOL! ;-) Seriously and literally, a Sega Dreamcast videogame running NetBSD + BIRD will have better convergence time!! Now, serious again and no ironic statements further. While Cisco and Juniper have great ASICS chips and stuff, it's amazing to see that nowadays, Juniper MX Series still run weak Cavium-Octeon CPU for stuff their Trio 3D chip won't run. The same goes to Cisco with amazing ASICS but with weak CPU power that need, indeed, to be protected from DDoS attacks for things won't run on ASICS. Convergence time frames above 30 seconds nowadays, IMHO, should not be accepted on any new BGP environment. Only legacy hardware should take that long. For OpenBGP I have <30s convergence time for several full sessions on x86 hardware as the ones mentioned above. With BIRD, convergence time frames are even lower. If convergence time takes longer on OpenBGP or BIRD its mostly related to how long the UPDATE messages take to arrive, not to be processed. -- Eddie From kawamucho at mesh.ad.jp Wed Jan 28 02:27:04 2015 From: kawamucho at mesh.ad.jp (Seiichi Kawamura) Date: Wed, 28 Jan 2015 11:27:04 +0900 Subject: Network ops lists. In-Reply-To: <97D1EEAD-7A7F-423B-A111-AD157595C0B7@finnesey.com> References: <97D1EEAD-7A7F-423B-A111-AD157595C0B7@finnesey.com> Message-ID: <54C848F8.5090009@mesh.ad.jp> Not my list, but here's one. http://www.bugest.net/nogs.html I'm sure there's more though. BDNOG, BTNOG, HKNOG ... -Seiichi (2015/01/28 6:20), Ryan Finnesey wrote: > At one point I stumbled across a site that listed all of the network ops lists for the corresponding regions but now I can't seem to find it would anyone happen to have a similar list? > > Sent from my iPad > From dan at tangledhelix.com Wed Jan 28 02:29:34 2015 From: dan at tangledhelix.com (Dan Lowe) Date: Tue, 27 Jan 2015 21:29:34 -0500 Subject: AT&T uVerse blocking SIP? In-Reply-To: <3291F28A-7010-46B5-955E-F2AFFDCD688F@puck.nether.net> References: <3291F28A-7010-46B5-955E-F2AFFDCD688F@puck.nether.net> Message-ID: <1422412174.20189.219794705.31D580B1@webmail.messagingengine.com> On Mon, Jan 26, 2015, at 10:22 PM, Jared Mauch wrote: > Yes. If you move to another port, e.g.: 5061 it works fine. > > If you’re running on a Linux based system, you can do this: > > /sbin/iptables -A PREROUTING -t nat -i eth1 -p udp --dport 5061 -j > REDIRECT --to-port 5060 > > on the host to remap 5061 -> 5060 with no application change. > > - Jared In most cases the above has worked fine (we also use a 15060 -> 5060 remap), but I have one user for whom nothing seems to work. The problem has persisted with different models of CPE, different phones, different server-side ports (5060, 5061, 15060). They even moved and the problem followed them to a new house (albeit in the same area). I was never able to work out the issue and have been assuming it's a regional problem in Uverse (in this case it was near Austin, TX). IIRC, the user ended up switching to cable. Dan From joelja at bogus.com Wed Jan 28 08:23:38 2015 From: joelja at bogus.com (joel jaeggli) Date: Wed, 28 Jan 2015 00:23:38 -0800 Subject: look for BGP routes containing local AS# In-Reply-To: <54C79682.9020802@gmail.com> References: <54C79682.9020802@gmail.com> Message-ID: <54C89C8A.2030800@bogus.com> On 1/27/15 5:45 AM, Song Li wrote: > Hi everyone, > > Recently I studied the BGP AS path looping problem, and found that in > most cases, the received BGP routes containing local AS# are suspicious. > However, we checked our BGP routing table (AS23910,CERNET2) on juniper > router(show route hidden terse aspath-regex .*23910.* ), and have not > found such routes in Adj-RIB-In. Updates with your AS in the path are discarded as part of loop detection, e.g. they do not become candidate routes. https://tools.ietf.org/html/rfc4271 page 77 If the AS_PATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. Operations of a BGP speaker that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document. in junos neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number where number is the number of instances of your AS in the path you're willing to accept will correct that. > We believe that the received BGP routes containing local AS# are related > to BGP security problem. You'll have to elaborate, since their existence is a basic principle in the operation of bgp and they are ubiquitous. Island instances of a distributed ASN communicate with each other by allowing such routes in so that they can be evaluated one the basis of prefix, specificity, AS path length and so forth. > Hence, we want to look for some real cases in > the wild. Could anybody give us some examples of such routes? > > Thanks! > > Best Regards! > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From refresh.lsong at gmail.com Wed Jan 28 09:32:34 2015 From: refresh.lsong at gmail.com (Song Li) Date: Wed, 28 Jan 2015 17:32:34 +0800 Subject: look for BGP routes containing local AS# In-Reply-To: <54C89C8A.2030800@bogus.com> References: <54C79682.9020802@gmail.com> <54C89C8A.2030800@bogus.com> Message-ID: <54C8ACB2.9080505@gmail.com> Hi Joel, It is right that the BGP route containing the local ASN will be droped. However, such routes can still be displayed on router. For example, you can run "show route hidden terse aspath-regex .*.*" on Juniper to check them. We are looking for those routes. If you can run the command on your Juniper and find such routes, could you please provider them for us? Thanks! Regards! Song 在 2015/1/28 16:23, joel jaeggli 写道: > On 1/27/15 5:45 AM, Song Li wrote: >> Hi everyone, >> >> Recently I studied the BGP AS path looping problem, and found that in >> most cases, the received BGP routes containing local AS# are suspicious. >> However, we checked our BGP routing table (AS23910,CERNET2) on juniper >> router(show route hidden terse aspath-regex .*23910.* ), and have not >> found such routes in Adj-RIB-In. > > Updates with your AS in the path are discarded as part of loop > detection, e.g. they do not become candidate routes. > > https://tools.ietf.org/html/rfc4271 page 77 > > If the AS_PATH attribute of a BGP route contains an AS loop, the BGP > route should be excluded from the Phase 2 decision function. AS loop > detection is done by scanning the full AS path (as specified in the > AS_PATH attribute), and checking that the autonomous system number of > the local system does not appear in the AS path. Operations of a BGP > speaker that is configured to accept routes with its own autonomous > system number in the AS path are outside the scope of this document. > > in junos > > neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number > > where number is the number of instances of your AS in the path you're > willing to accept will correct that. > >> We believe that the received BGP routes containing local AS# are related >> to BGP security problem. > > You'll have to elaborate, since their existence is a basic principle in > the operation of bgp and they are ubiquitous. > > Island instances of a distributed ASN communicate with each other by > allowing such routes in so that they can be evaluated one the basis of > prefix, specificity, AS path length and so forth. > >> Hence, we want to look for some real cases in >> the wild. Could anybody give us some examples of such routes? >> >> Thanks! >> >> Best Regards! >> > > -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From robert at gdk.org Wed Jan 28 11:02:38 2015 From: robert at gdk.org (Robert Bays) Date: Wed, 28 Jan 2015 03:02:38 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: <54C7BD4D.1000101@shankland.org> References: <87vbjt6tml.fsf@muck.riseup.net> <54C7BD4D.1000101@shankland.org> Message-ID: > On Jan 27, 2015, at 8:31 AM, Jim Shankland wrote: > > My expertise, such as it ever was, is a bit stale at this point, and my > figures might be a little off. But I think the general principle > applies: think about the minimum number of x86 instructions, and the > minimum number of main memory accesses, to inspect a packet header, do a > routing table lookup, and enqueue the packet on an outbound interface. I > can't see that ever getting reduced to the point where a generic server > can handle 40-byte packets at line rate (for that matter, "line rate" is > increasing a lot faster than "speed of generic server" these days). Using DPDK it’s possible to do everything stated and achieve 10Gbps line rate at 64byte packets on multiple interfaces simultaneously. Add ACLs to the test setup and you can reach significant portions of 10Gbps at 64byte packets and full line rate at 128bytes. Check out Venky Venkatesan’s presentation at the last DPDK Summit for interesting information on pps/CPU cycles and some of the things that can be done to optimize forwarding in a generic processor environment. http://www.slideshare.net/jstleger/6-dpdk-summit-2014-intel-presentation-venky-venkatesan From askoorb+nanog at gmail.com Wed Jan 28 12:32:27 2015 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Wed, 28 Jan 2015 12:32:27 +0000 Subject: Network ops lists. In-Reply-To: <54C848F8.5090009@mesh.ad.jp> References: <97D1EEAD-7A7F-423B-A111-AD157595C0B7@finnesey.com> <54C848F8.5090009@mesh.ad.jp> Message-ID: On Wed, Jan 28, 2015 at 2:27 AM, Seiichi Kawamura wrote: > Not my list, but here's one. > http://www.bugest.net/nogs.html > > I'm sure there's more though. BDNOG, BTNOG, HKNOG ... > As has been mentioned, there are also a few special purpose non-geographic lists around. Voiceops for VoIP (http://www.voiceops.org/), DC-Ops for Data Centre operation discussion (https://puck.nether.net/mailman/listinfo/dc-ops), IPv6 Ops for IPv6 specific stuff (http://lists.cluenet.de/pipermail/ipv6-ops/) come to mind. Be aware that other regional ops mailing lists can be a little quieter than NANOG. UKNOF (http://www.uknof.org.uk/) is a great example of this, there are lots of great people from loads of ISPs and network operators on that list, with lots of experience of the UK and Western Europe, they also host two meetings a year, a bit like the NANOG meetings, but if you subscribed to the list you might think it a little dead until someone posts something on topic. Their meeting last week had nearly 300 attendees, including BT, the BBC, Cisco, Akamai and Amazon along with a heck of a lot of very interesting talks, most of which are on Youtube. You will find that other regional groups do similar things as well. HTH, Alex From contact at winterei.se Wed Jan 28 13:02:34 2015 From: contact at winterei.se (Paul S.) Date: Wed, 28 Jan 2015 22:02:34 +0900 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> <54C7BD4D.1000101@shankland.org> Message-ID: <54C8DDEA.6060507@winterei.se> That's the problem though. Everyone has presentations for the most part, very few actual tools that end users can just use exist. On 1/28/2015 午後 08:02, Robert Bays wrote: >> On Jan 27, 2015, at 8:31 AM, Jim Shankland wrote: >> >> My expertise, such as it ever was, is a bit stale at this point, and my >> figures might be a little off. But I think the general principle >> applies: think about the minimum number of x86 instructions, and the >> minimum number of main memory accesses, to inspect a packet header, do a >> routing table lookup, and enqueue the packet on an outbound interface. I >> can't see that ever getting reduced to the point where a generic server >> can handle 40-byte packets at line rate (for that matter, "line rate" is >> increasing a lot faster than "speed of generic server" these days). > Using DPDK it’s possible to do everything stated and achieve 10Gbps line rate at 64byte packets on multiple interfaces simultaneously. Add ACLs to the test setup and you can reach significant portions of 10Gbps at 64byte packets and full line rate at 128bytes. > > Check out Venky Venkatesan’s presentation at the last DPDK Summit for interesting information on pps/CPU cycles and some of the things that can be done to optimize forwarding in a generic processor environment. > > http://www.slideshare.net/jstleger/6-dpdk-summit-2014-intel-presentation-venky-venkatesan > > From robert at gdk.org Wed Jan 28 13:23:23 2015 From: robert at gdk.org (Robert Bays) Date: Wed, 28 Jan 2015 05:23:23 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: <54C8DDEA.6060507@winterei.se> References: <87vbjt6tml.fsf@muck.riseup.net> <54C7BD4D.1000101@shankland.org> <54C8DDEA.6060507@winterei.se> Message-ID: <59E8FB66-C85E-465B-A6C8-F080898666BF@gdk.org> I was trying not to pitch my company on list, but the performance numbers I quoted are on the Vyatta/Brocade vRouter which is commercially available. Other vendors also also have publicly available performance numbers that are interesting. > On Jan 28, 2015, at 5:02 AM, Paul S. wrote: > > That's the problem though. > > Everyone has presentations for the most part, very few actual tools that > end users can just use exist. > > On 1/28/2015 午後 08:02, Robert Bays wrote: >>> On Jan 27, 2015, at 8:31 AM, Jim Shankland wrote: >>> >>> My expertise, such as it ever was, is a bit stale at this point, and my >>> figures might be a little off. But I think the general principle >>> applies: think about the minimum number of x86 instructions, and the >>> minimum number of main memory accesses, to inspect a packet header, do a >>> routing table lookup, and enqueue the packet on an outbound interface. I >>> can't see that ever getting reduced to the point where a generic server >>> can handle 40-byte packets at line rate (for that matter, "line rate" is >>> increasing a lot faster than "speed of generic server" these days). >> Using DPDK it’s possible to do everything stated and achieve 10Gbps line rate at 64byte packets on multiple interfaces simultaneously. Add ACLs to the test setup and you can reach significant portions of 10Gbps at 64byte packets and full line rate at 128bytes. >> >> Check out Venky Venkatesan’s presentation at the last DPDK Summit for interesting information on pps/CPU cycles and some of the things that can be done to optimize forwarding in a generic processor environment. >> >> http://www.slideshare.net/jstleger/6-dpdk-summit-2014-intel-presentation-venky-venkatesan >> >> > From pmsac.nanog at gmail.com Wed Jan 28 13:23:39 2015 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Wed, 28 Jan 2015 13:23:39 +0000 Subject: look for BGP routes containing local AS# In-Reply-To: <54C8ACB2.9080505@gmail.com> References: <54C79682.9020802@gmail.com> <54C89C8A.2030800@bogus.com> <54C8ACB2.9080505@gmail.com> Message-ID: If your ISP utilizes Juniper platforms, you might have to ask them to allow the advertisement of these routes, see http://www.firstdigest.com/2012/09/cisco-vs-juniper-different-ebgp-behavior/ On 28 January 2015 at 09:32, Song Li wrote: > Hi Joel, > > It is right that the BGP route containing the local ASN will be droped. > However, such routes can still be displayed on router. For example, you can > run "show route hidden terse aspath-regex .*.*" on Juniper to > check them. We are looking for those routes. If you can run the command on > your Juniper and find such routes, could you please provider them for us? > > Thanks! > > Regards! > > Song > > 在 2015/1/28 16:23, joel jaeggli 写道: > > On 1/27/15 5:45 AM, Song Li wrote: >> >>> Hi everyone, >>> >>> Recently I studied the BGP AS path looping problem, and found that in >>> most cases, the received BGP routes containing local AS# are suspicious. >>> However, we checked our BGP routing table (AS23910,CERNET2) on juniper >>> router(show route hidden terse aspath-regex .*23910.* ), and have not >>> found such routes in Adj-RIB-In. >>> >> >> Updates with your AS in the path are discarded as part of loop >> detection, e.g. they do not become candidate routes. >> >> https://tools.ietf.org/html/rfc4271 page 77 >> >> If the AS_PATH attribute of a BGP route contains an AS loop, the BGP >> route should be excluded from the Phase 2 decision function. AS loop >> detection is done by scanning the full AS path (as specified in the >> AS_PATH attribute), and checking that the autonomous system number of >> the local system does not appear in the AS path. Operations of a BGP >> speaker that is configured to accept routes with its own autonomous >> system number in the AS path are outside the scope of this document. >> >> in junos >> >> neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number >> >> where number is the number of instances of your AS in the path you're >> willing to accept will correct that. >> >> We believe that the received BGP routes containing local AS# are related >>> to BGP security problem. >>> >> >> You'll have to elaborate, since their existence is a basic principle in >> the operation of bgp and they are ubiquitous. >> >> Island instances of a distributed ASN communicate with each other by >> allowing such routes in so that they can be evaluated one the basis of >> prefix, specificity, AS path length and so forth. >> >> Hence, we want to look for some real cases in >>> the wild. Could anybody give us some examples of such routes? >>> >>> Thanks! >>> >>> Best Regards! >>> >>> >> >> > > -- > Song Li > Room 4-204, FIT Building, > Network Security, > Department of Electronic Engineering, > Tsinghua University, Beijing 100084, China > Tel:( +86) 010-62446440 > E-mail: refresh.lsong at gmail.com > From cra at WPI.EDU Wed Jan 28 13:27:40 2015 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 28 Jan 2015 08:27:40 -0500 Subject: look for BGP routes containing local AS# In-Reply-To: <54C8ACB2.9080505@gmail.com> References: <54C79682.9020802@gmail.com> <54C89C8A.2030800@bogus.com> <54C8ACB2.9080505@gmail.com> Message-ID: <20150128132739.GH15777@angus.ind.WPI.EDU> It used to be the case that looped routes didn't even show up as hidden routes, because Junos discarded them even from Adj-RIB-In, although this may have changed at some Junos version. Also, Junos won't even advertise such looped routes to a neighbor with the same AS by default, so in many cases you won't see it at all if you are peering with a Juniper unless it is specifically configured to send these looped routes with advertise-peer-as, or change the AS number with as-override. On Wed, Jan 28, 2015 at 05:32:34PM +0800, Song Li wrote: > Hi Joel, > > It is right that the BGP route containing the local ASN will be > droped. However, such routes can still be displayed on router. For > example, you can run "show route hidden terse aspath-regex .* ASN>.*" on Juniper to check them. We are looking for those routes. > If you can run the command on your Juniper and find such routes, > could you please provider them for us? > > Thanks! > > Regards! > > Song > > 在 2015/1/28 16:23, joel jaeggli 写道: > >On 1/27/15 5:45 AM, Song Li wrote: > >>Hi everyone, > >> > >>Recently I studied the BGP AS path looping problem, and found that in > >>most cases, the received BGP routes containing local AS# are suspicious. > >>However, we checked our BGP routing table (AS23910,CERNET2) on juniper > >>router(show route hidden terse aspath-regex .*23910.* ), and have not > >>found such routes in Adj-RIB-In. > > > >Updates with your AS in the path are discarded as part of loop > >detection, e.g. they do not become candidate routes. > > > >https://tools.ietf.org/html/rfc4271 page 77 > > > > If the AS_PATH attribute of a BGP route contains an AS loop, the BGP > > route should be excluded from the Phase 2 decision function. AS loop > > detection is done by scanning the full AS path (as specified in the > > AS_PATH attribute), and checking that the autonomous system number of > > the local system does not appear in the AS path. Operations of a BGP > > speaker that is configured to accept routes with its own autonomous > > system number in the AS path are outside the scope of this document. > > > >in junos > > > >neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number > > > >where number is the number of instances of your AS in the path you're > >willing to accept will correct that. > > > >>We believe that the received BGP routes containing local AS# are related > >>to BGP security problem. > > > >You'll have to elaborate, since their existence is a basic principle in > >the operation of bgp and they are ubiquitous. > > > >Island instances of a distributed ASN communicate with each other by > >allowing such routes in so that they can be evaluated one the basis of > >prefix, specificity, AS path length and so forth. > > > >>Hence, we want to look for some real cases in > >>the wild. Could anybody give us some examples of such routes? From refresh.lsong at gmail.com Wed Jan 28 14:00:26 2015 From: refresh.lsong at gmail.com (Song Li) Date: Wed, 28 Jan 2015 22:00:26 +0800 Subject: look for BGP routes containing local AS# In-Reply-To: <20150128132739.GH15777@angus.ind.WPI.EDU> References: <54C79682.9020802@gmail.com> <54C89C8A.2030800@bogus.com> <54C8ACB2.9080505@gmail.com> <20150128132739.GH15777@angus.ind.WPI.EDU> Message-ID: <54C8EB7A.6090306@gmail.com> Thanks! It seems hard to see such routes on the edge router. Nonetheless, we do believe there must exist such routes in the wild. We still hope to find some real cases of them. If anybody see them in your routers, please let us know. Regards! Song 在 2015/1/28 21:27, Chuck Anderson 写道: > It used to be the case that looped routes didn't even show up as > hidden routes, because Junos discarded them even from Adj-RIB-In, > although this may have changed at some Junos version. > > Also, Junos won't even advertise such looped routes to a neighbor with > the same AS by default, so in many cases you won't see it at all if > you are peering with a Juniper unless it is specifically configured to > send these looped routes with advertise-peer-as, or change the AS > number with as-override. > > On Wed, Jan 28, 2015 at 05:32:34PM +0800, Song Li wrote: >> Hi Joel, >> >> It is right that the BGP route containing the local ASN will be >> droped. However, such routes can still be displayed on router. For >> example, you can run "show route hidden terse aspath-regex .*> ASN>.*" on Juniper to check them. We are looking for those routes. >> If you can run the command on your Juniper and find such routes, >> could you please provider them for us? >> >> Thanks! >> >> Regards! >> >> Song >> >> 在 2015/1/28 16:23, joel jaeggli 写道: >>> On 1/27/15 5:45 AM, Song Li wrote: >>>> Hi everyone, >>>> >>>> Recently I studied the BGP AS path looping problem, and found that in >>>> most cases, the received BGP routes containing local AS# are suspicious. >>>> However, we checked our BGP routing table (AS23910,CERNET2) on juniper >>>> router(show route hidden terse aspath-regex .*23910.* ), and have not >>>> found such routes in Adj-RIB-In. >>> >>> Updates with your AS in the path are discarded as part of loop >>> detection, e.g. they do not become candidate routes. >>> >>> https://tools.ietf.org/html/rfc4271 page 77 >>> >>> If the AS_PATH attribute of a BGP route contains an AS loop, the BGP >>> route should be excluded from the Phase 2 decision function. AS loop >>> detection is done by scanning the full AS path (as specified in the >>> AS_PATH attribute), and checking that the autonomous system number of >>> the local system does not appear in the AS path. Operations of a BGP >>> speaker that is configured to accept routes with its own autonomous >>> system number in the AS path are outside the scope of this document. >>> >>> in junos >>> >>> neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number >>> >>> where number is the number of instances of your AS in the path you're >>> willing to accept will correct that. >>> >>>> We believe that the received BGP routes containing local AS# are related >>>> to BGP security problem. >>> >>> You'll have to elaborate, since their existence is a basic principle in >>> the operation of bgp and they are ubiquitous. >>> >>> Island instances of a distributed ASN communicate with each other by >>> allowing such routes in so that they can be evaluated one the basis of >>> prefix, specificity, AS path length and so forth. >>> >>>> Hence, we want to look for some real cases in >>>> the wild. Could anybody give us some examples of such routes? -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From corbe at corbe.net Wed Jan 28 14:15:58 2015 From: corbe at corbe.net (Daniel Corbe) Date: Wed, 28 Jan 2015 09:15:58 -0500 Subject: Cisco IOS stable/production safe versions? In-Reply-To: <3551369d5e2b4a9796964e4f335aa827@exchange.broadaspect.local> (Nick Ellermann's message of "Tue, 27 Jan 2015 14:27:00 +0000") References: <3551369d5e2b4a9796964e4f335aa827@exchange.broadaspect.local> Message-ID: <87r3ufq9cx.fsf@corbe.net> Nick Ellermann writes: > I have a Cisco IOS specific question for the group and also > specifically related to the 6500 platform. We have always been very > conservative with our IOS version that we run in production, we are > still running a pretty old safe harbor build of 12.2.x on SUP 720 > 3BXLs with BGP and OSFP routing. Any advice from fellow network > operators that are running the 6500 platform in the core still for > versions that are considered safe for production? We are stable, but I > am really wanting access to features such as Netflow v9, etc. > > Thanks for any advice! > You're pretty spot on with your thinking here. Don't upgrade unless there's a known vulnerability, a bug fix or a feature that you need on a particular device; and don't expose your management to the Internet. tl;dr: don't fix what isn't broken. Having said that; make use of the software download tools on your CCO account. Cisco has a list of recommended builds for your particular platform and code train. When in doubt you can always fall back to S-train stuff on a Sup720. -S images were made for service providers and are generally very stable. -Daniel From charles at thefnf.org Wed Jan 28 14:35:07 2015 From: charles at thefnf.org (Charles N Wyble) Date: Wed, 28 Jan 2015 08:35:07 -0600 Subject: scaling linux-based router hardware recommendations In-Reply-To: <54C8DDEA.6060507@winterei.se> References: <87vbjt6tml.fsf@muck.riseup.net> <54C7BD4D.1000101@shankland.org> <54C8DDEA.6060507@winterei.se> Message-ID: <106549A1-0CF3-4FE9-B517-CD0FB27C7861@thefnf.org> There is no free lunch. If you want " tools that end users can just use" then buy Cisco. Otherwise you need to roll up your sleeves and take the pieces and put them together. Or hire people like me to do it for you. It isn't overly complicated in my opinion. Also you'll find plenty of reasonably priced Linux or BSD integration engineers out there across the globe who are used to doing this sort of thing. Now once you move beyond basic forwarding / high PPS processing (which seems mostly commodity now) and get into say 80gbps (40gbps full duplex) IPS , ip reputation, data loss prevention, SSL MITM, AV... well that requires some very beefy hardware. Can that be done on x86? I doubt it. Tilera seems the way to go here. Newer FPGA boards can implement various CPU architectures on the fly. You also have CUDA. I hadn't seen chelsio, I'm very excited about that. Ill have one in my grubby little hands soon enough. transceivers are still horribly expensive. This is a major portion of the bom cost on any build, no matter what software stack is putting packets onto them. It isn't so simple once you move beyond the 1gbps range and want full feature set. And not in one box I think. Look at https://www.bro.org/ for interesting multi box scaling. On January 28, 2015 7:02:34 AM CST, "Paul S." wrote: >That's the problem though. > >Everyone has presentations for the most part, very few actual tools >that >end users can just use exist. > >On 1/28/2015 午後 08:02, Robert Bays wrote: >>> On Jan 27, 2015, at 8:31 AM, Jim Shankland >wrote: >>> >>> My expertise, such as it ever was, is a bit stale at this point, and >my >>> figures might be a little off. But I think the general principle >>> applies: think about the minimum number of x86 instructions, and the >>> minimum number of main memory accesses, to inspect a packet header, >do a >>> routing table lookup, and enqueue the packet on an outbound >interface. I >>> can't see that ever getting reduced to the point where a generic >server >>> can handle 40-byte packets at line rate (for that matter, "line >rate" is >>> increasing a lot faster than "speed of generic server" these days). >> Using DPDK it’s possible to do everything stated and achieve 10Gbps >line rate at 64byte packets on multiple interfaces simultaneously. Add >ACLs to the test setup and you can reach significant portions of 10Gbps >at 64byte packets and full line rate at 128bytes. >> >> Check out Venky Venkatesan’s presentation at the last DPDK Summit for >interesting information on pps/CPU cycles and some of the things that >can be done to optimize forwarding in a generic processor environment. >> >> >http://www.slideshare.net/jstleger/6-dpdk-summit-2014-intel-presentation-venky-venkatesan >> >> > > >!DSPAM:54c8de34274511264773590! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From colinj at gt86car.org.uk Wed Jan 28 14:45:50 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 28 Jan 2015 14:45:50 +0000 Subject: scaling linux-based router hardware recommendations In-Reply-To: <106549A1-0CF3-4FE9-B517-CD0FB27C7861@thefnf.org> References: <87vbjt6tml.fsf@muck.riseup.net> <54C7BD4D.1000101@shankland.org> <54C8DDEA.6060507@winterei.se> <106549A1-0CF3-4FE9-B517-CD0FB27C7861@thefnf.org> Message-ID: <86B7CF2F-ED10-4941-A4E7-B36B0873363F@gt86car.org.uk> qnx os based router works well with powerpc, could be pushed far higher load than intel based chips Colin >> That's the problem though. >> >> Everyone has presentations for the most part, very few actual tools >> that >> end users can just use exist. >> >> On 1/28/2015 午後 08:02, Robert Bays wrote: >>>> On Jan 27, 2015, at 8:31 AM, Jim Shankland >> wrote: >>>> >>>> My expertise, such as it ever was, is a bit stale at this point, and >> my >>>> figures might be a little off. But I think the general principle >>>> applies: think about the minimum number of x86 instructions, and the >>>> minimum number of main memory accesses, to inspect a packet header, >> do a >>>> routing table lookup, and enqueue the packet on an outbound >> interface. I >>>> can't see that ever getting reduced to the point where a generic >> server >>>> can handle 40-byte packets at line rate (for that matter, "line >> rate" is >>>> increasing a lot faster than "speed of generic server" these days). >>> Using DPDK it’s possible to do everything stated and achieve 10Gbps >> line rate at 64byte packets on multiple interfaces simultaneously. Add >> ACLs to the test setup and you can reach significant portions of 10Gbps >> at 64byte packets and full line rate at 128bytes. >>> >>> Check out Venky Venkatesan’s presentation at the last DPDK Summit for >> interesting information on pps/CPU cycles and some of the things that >> can be done to optimize forwarding in a generic processor environment. >>> >>> >> http://www.slideshare.net/jstleger/6-dpdk-summit-2014-intel-presentation-venky-venkatesan >>> >>> >> >> >> !DSPAM:54c8de34274511264773590! > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From mark.tinka at seacom.mu Wed Jan 28 14:55:23 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 28 Jan 2015 16:55:23 +0200 Subject: scaling linux-based router hardware recommendations In-Reply-To: <86B7CF2F-ED10-4941-A4E7-B36B0873363F@gt86car.org.uk> References: <87vbjt6tml.fsf@muck.riseup.net> <54C7BD4D.1000101@shankland.org> <54C8DDEA.6060507@winterei.se> <106549A1-0CF3-4FE9-B517-CD0FB27C7861@thefnf.org> <86B7CF2F-ED10-4941-A4E7-B36B0873363F@gt86car.org.uk> Message-ID: <54C8F85B.8050807@seacom.mu> On 28/1/15 16:45, Colin Johnston wrote: > qnx os based router works well with powerpc, could be pushed far higher load than intel based chips The problem being that QNX is a 32-bit kernel. Mark. From dudu.meyer at gmail.com Wed Jan 28 15:07:27 2015 From: dudu.meyer at gmail.com (Eduardo Meyer) Date: Wed, 28 Jan 2015 13:07:27 -0200 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: > - 1x ServerU Netmap L800 box in Bridge Mode for Core Firewall protection > - 2x ServerU Netmap L800 boxes as BGP router (redundant) > - Several Netmap L800, L100 and iXSystems servers (iXS for everything else > since ServerU are only networking-centric, not high storage high processing > Xeon servers) > > In this setup I am running yet another not well known but very promising > technology, called Netmap. > > A Netmap firewall (called netmap-ipfw) was supplied from ServerU vendor, > it's a slightly modified version from what you can download from Luigi > Rizzo's (netmap author) public repository with multithread capabilities > based on the number of queues available in the ServerU igb(4) networking > card. > > What it does is, IMHO, amazing for a x86 hardware: line rate firewall on > 1GbE port (1.3-1.4Mpps) and line rate firewall for 10GbE port (12-14Mpps) > in a system with 8 @2.4Ghz Intel Rangeley CPU. > > It's not Linux DNA. It's not PF_RING. It's not Intel DPDK. > > It's netmap, it's there, available, on FreeBSD base system with a number of > utilities and code for reference on Rizzos' repositories. It's there, it's > available and it's amazing. > > This firewall has saved my sleep several times since November, dropping up > to 9Mpps amplified UDP/NTP traffic on peak DDoS attack rates. > > For the BGP box, I needed trunking, Q-in-Q and vlan. And sadly right now > this is not available in a netmap implementation. > > It means I had to keep my BGP router in the kernel path. It's funny to say > this, but Netmap usually skips kernel path completely and does its job > direct on the NIC, reaching backplane and bus limits directly. > > ServerU people recommended me to use Chelsio Terminator 5 40G ports. OK I > only needed 10G but they convinced me not to look at the bits per second > numbers but the packets per seconds number. > > Honestly, I don't know how Chelsio T5 did it, even though ServerU 1GbE > ports perform very good on interruption CPU usage (probably this is an > Intel igb(4) / ix(4) credit) but everything I route from one 40GbE port to > the other port on the same L-800 expansion card, I have very, very, very > LOW interrupt rates. Sometimes I have no interrupt at all!! > > I peaked routing 6Mpps on ServerU L-800 and still had CPU there, > > I am also a user for FreeBSD netmap-ipfw, running kipfw fwd to, say, "fwd" http traffic to a peerapp appliance. My numbers are not line rate, I peak on 900Kpps, but still have CPU idle. I had a hard time figuring out how to use netmap-ipfw, due to lack of updated documentation, but once I got it running and set up, ecerything was very straightforward with default code, no modifications, just as available. I agree FreeBSD-netmap seems more ready, with tools, toolchains and code available wheh compared to DPDK or Linux DNA. Also in the hope for further evolvings of Netmap in the base system. Numbers are impressive indeed. -- =========== Eduardo Meyer pessoal: dudu.meyer at gmail.com profissional: ddm.farmaciap at saude.gov.br From baldur.norddahl at gmail.com Wed Jan 28 15:35:52 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 28 Jan 2015 16:35:52 +0100 Subject: scaling linux-based router hardware recommendations In-Reply-To: <106549A1-0CF3-4FE9-B517-CD0FB27C7861@thefnf.org> References: <87vbjt6tml.fsf@muck.riseup.net> <54C7BD4D.1000101@shankland.org> <54C8DDEA.6060507@winterei.se> <106549A1-0CF3-4FE9-B517-CD0FB27C7861@thefnf.org> Message-ID: 10g transceivers are not overly expensive if you buy compatible modules. SFP+ Direct attach cable is $16. SFP+ multimode module is $18. SFP+ singlemode LR module is $48. That is nothing compared to what vendors are asking for a "real" router. I believe there are many startups that are going for 2x 10G transit with full tables. We are one of them for sure. And then you need a cheap way to handle up to 20G bidirectional traffic, because as a startup it is not a good idea to fork over what equals to a whole year of salary to Cisco or Juniper. Even if you have that kind of money, you would want to spent it on something that will get you revenue. The obvious solution is a server (or two for redundancy) running Linux or BSD. You will be getting the Intel NIC with two SFP+ slots, so you can connect a transit connection directly to each server. This works well enough. We used a setup just like that for a year, before we upgraded to a hardware router. The weak point is that it will likely have trouble if you get hit by a real big DDoS with small packets. But back to cost of things. If I use my own company as an example, we are a FTTH provider. We use PON switches with 2x 10G ports on each switch. You can get many PON switches for the price of one router with at least 4x 10G ports (equivalent to the Linux routers). The PON switches will earn you revenue, it is what you connect your customers to. Better to get a bigger network, than spend the money on a router. The cost of SFP+/XFP and GPON C+ modules on the PON switch is only about 10% of the cost of the switch itself (again using compatible modules). A switch with 24x1G and 4x 10G can be bought for $3000. You can fill it completely with optics for $300 - again about 10%. My point is that if you are in an environment where every dollar counts, you do not need to spent a majority of your funds on optics. And neither do you need that expensive router until later in the game. Regards, Baldur On 28 January 2015 at 15:35, Charles N Wyble wrote: > There is no free lunch. If you want " tools that end users can just use" > then buy Cisco. > > Otherwise you need to roll up your sleeves and take the pieces and put > them together. Or hire people like me to do it for you. > > It isn't overly complicated in my opinion. Also you'll find plenty of > reasonably priced Linux or BSD integration engineers out there across the > globe who are used to doing this sort of thing. > > Now once you move beyond basic forwarding / high PPS processing (which > seems mostly commodity now) and get into say 80gbps (40gbps full duplex) > IPS , ip reputation, data loss prevention, SSL MITM, AV... well that > requires some very beefy hardware. Can that be done on x86? I doubt it. > > Tilera seems the way to go here. Newer FPGA boards can implement various > CPU architectures on the fly. You also have CUDA. I hadn't seen chelsio, > I'm very excited about that. Ill have one in my grubby little hands soon > enough. > > transceivers are still horribly expensive. This is a major portion of the > bom cost on any build, no matter what software stack is putting packets > onto them. > > It isn't so simple once you move beyond the 1gbps range and want full > feature set. And not in one box I think. Look at https://www.bro.org/ for > interesting multi box scaling. > > On January 28, 2015 7:02:34 AM CST, "Paul S." wrote: > >That's the problem though. > > > >Everyone has presentations for the most part, very few actual tools > >that > >end users can just use exist. > > > >On 1/28/2015 午後 08:02, Robert Bays wrote: > >>> On Jan 27, 2015, at 8:31 AM, Jim Shankland > >wrote: > >>> > >>> My expertise, such as it ever was, is a bit stale at this point, and > >my > >>> figures might be a little off. But I think the general principle > >>> applies: think about the minimum number of x86 instructions, and the > >>> minimum number of main memory accesses, to inspect a packet header, > >do a > >>> routing table lookup, and enqueue the packet on an outbound > >interface. I > >>> can't see that ever getting reduced to the point where a generic > >server > >>> can handle 40-byte packets at line rate (for that matter, "line > >rate" is > >>> increasing a lot faster than "speed of generic server" these days). > >> Using DPDK it’s possible to do everything stated and achieve 10Gbps > >line rate at 64byte packets on multiple interfaces simultaneously. Add > >ACLs to the test setup and you can reach significant portions of 10Gbps > >at 64byte packets and full line rate at 128bytes. > >> > >> Check out Venky Venkatesan’s presentation at the last DPDK Summit for > >interesting information on pps/CPU cycles and some of the things that > >can be done to optimize forwarding in a generic processor environment. > >> > >> > > > http://www.slideshare.net/jstleger/6-dpdk-summit-2014-intel-presentation-venky-venkatesan > >> > >> > > > > > >!DSPAM:54c8de34274511264773590! > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > From nick at foobar.org Wed Jan 28 15:51:22 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 28 Jan 2015 15:51:22 +0000 Subject: scaling linux-based router hardware recommendations In-Reply-To: <86B7CF2F-ED10-4941-A4E7-B36B0873363F@gt86car.org.uk> References: <87vbjt6tml.fsf@muck.riseup.net> <54C7BD4D.1000101@shankland.org> <54C8DDEA.6060507@winterei.se> <106549A1-0CF3-4FE9-B517-CD0FB27C7861@thefnf.org> <86B7CF2F-ED10-4941-A4E7-B36B0873363F@gt86car.org.uk> Message-ID: <54C9057A.1040504@foobar.org> On 28/01/2015 14:45, Colin Johnston wrote: > qnx os based router works well with powerpc, could be pushed far higher > load than intel based chips that may be so, but how many people out there know how to push qnx that hard compared freebsd/linux on amd64 compatible hardware, and how many people know how to configure up a juniper mx or cisco asr9k, compared to the number that can tune a freely available unix. As someone pointed out elsewhere, there's no such thing as a free lunch. If you want to economise on hardware, you should expect to pay for the expertise to do it. Nick From jay at west.net Wed Jan 28 18:06:26 2015 From: jay at west.net (Jay Hennigan) Date: Wed, 28 Jan 2015 10:06:26 -0800 Subject: Alerting systems, Logicmonitor and/or alternatives Message-ID: <54C92522.7060301@west.net> I know that this topic has been kicking around for at least a decade, but wanted to get current opinions of other network operators. Most of us have explored Nagios, MRTG, and several front-ends for MRTG. We are looking into a new player in the space called Logicmonitor. They have a very functional and easy to navigate front end and configuration tool, and I very much like the look-and-feel of their product. What I don't like is that they only offer it as a cloud-based service. Internal probes tie in to a "collector" which we maintain. The collector then phones home over the Internet to their hosted service periodically and they remotely analyze the data and generate alerts, plot graphs, etc. >From a technical standpoint this adds more points of failure in series, will cause missed alerts if their cloud-based service goes down (who is guarding the guards?) will cause false alarms if their service is still up but can't reach the collector, and doesn't give us a full view under the hood. Of course their sales guys are giving us "Our time and energy is dedicated to reliability" and "professionally managed multi-carrier highly secure data centers" language to encourage the warm fuzzies. >From a scalability standpoint we incur ever-increasing recurring costs as we grow and add monitored devices and services. What's the collective opinion here? Is anyone using them or a similar service? Are there non-cloud-based alternatives that are relatively easy to set up and manage? We've explored Zabbix, Nagios, MRTG and its various wrappers, and Intermapper. Anything else new on the horizon that has a GUI front-end that is configurable without a lot of scripting experience, etc.? We would love to buy something that works for us and pay a reasonable price for it, but I'm not particularly interested in the equivalent of renting a time-share in order to monitor our networks. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From eksffa at freebsdbrasil.com.br Wed Jan 28 17:50:10 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Wed, 28 Jan 2015 15:50:10 -0200 Subject: look for BGP routes containing local AS# In-Reply-To: <54C8ACB2.9080505@gmail.com> References: <54C79682.9020802@gmail.com> <54C89C8A.2030800@bogus.com> <54C8ACB2.9080505@gmail.com> Message-ID: > On 28/01/2015, at 07:32, Song Li wrote: > > Hi Joel, > > It is right that the BGP route containing the local ASN will be droped. However, such routes can still be displayed on router. For example, you can run "show route hidden terse aspath-regex .*.*" on Juniper to check them. We are looking for those routes. If you can run the command on your Juniper and find such routes, could you please provider them for us? > Sorry, what do you need exactly? A sample? For education purposes are you looking for something specific? You need it to be on Juniper router or other BGP software will do? I have this scenario from Brazil-US, with specifics getting received both ways but it’s not Juniper. > Thanks! > > Regards! > > Song > > 在 2015/1/28 16:23, joel jaeggli 写道: >> On 1/27/15 5:45 AM, Song Li wrote: >>> Hi everyone, >>> >>> Recently I studied the BGP AS path looping problem, and found that in >>> most cases, the received BGP routes containing local AS# are suspicious. >>> However, we checked our BGP routing table (AS23910,CERNET2) on juniper >>> router(show route hidden terse aspath-regex .*23910.* ), and have not >>> found such routes in Adj-RIB-In. >> >> Updates with your AS in the path are discarded as part of loop >> detection, e.g. they do not become candidate routes. >> >> https://tools.ietf.org/html/rfc4271 page 77 >> >> If the AS_PATH attribute of a BGP route contains an AS loop, the BGP >> route should be excluded from the Phase 2 decision function. AS loop >> detection is done by scanning the full AS path (as specified in the >> AS_PATH attribute), and checking that the autonomous system number of >> the local system does not appear in the AS path. Operations of a BGP >> speaker that is configured to accept routes with its own autonomous >> system number in the AS path are outside the scope of this document. >> >> in junos >> >> neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number >> >> where number is the number of instances of your AS in the path you're >> willing to accept will correct that. >> >>> We believe that the received BGP routes containing local AS# are related >>> to BGP security problem. >> >> You'll have to elaborate, since their existence is a basic principle in >> the operation of bgp and they are ubiquitous. >> >> Island instances of a distributed ASN communicate with each other by >> allowing such routes in so that they can be evaluated one the basis of >> prefix, specificity, AS path length and so forth. >> >>> Hence, we want to look for some real cases in >>> the wild. Could anybody give us some examples of such routes? >>> >>> Thanks! >>> >>> Best Regards! >>> >> >> > > > -- > Song Li > Room 4-204, FIT Building, > Network Security, > Department of Electronic Engineering, > Tsinghua University, Beijing 100084, China > Tel:( +86) 010-62446440 > E-mail: refresh.lsong at gmail.com -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601 at sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From jeff at briworks.com Wed Jan 28 18:17:32 2015 From: jeff at briworks.com (Jeff Cornejo) Date: Wed, 28 Jan 2015 18:17:32 +0000 Subject: Alerting systems, Logicmonitor and/or alternatives In-Reply-To: <54C92522.7060301@west.net> References: <54C92522.7060301@west.net> Message-ID: We have used LogicMonitor for a few years to monitor hundreds of network devices with no reliability issues, at all. The agents have proven to be lightweight and rather unobtrusive. I can’t recall a time where we have ever had to intervene during regular operations or one of their upgrades. We do not use the alerting service at this time so no history to report there. We have only a few dislikes. One of them is the new skin and use the prior one still available to us so its a relatively minor issue. The pricing is something I’m also not crazy about though they have been willing to work with us on some pricing tiers. Jeff jeff cornejo blue ridge internetworks 321 east main st • suite 200 charlottesville va 22902 434.817.0707 x 2001 www.briworks.com Central Virginia’s technology authority since 2000. > On Jan 28, 2015, at 1:06 PM, Jay Hennigan wrote: > > I know that this topic has been kicking around for at least a decade, > but wanted to get current opinions of other network operators. Most of > us have explored Nagios, MRTG, and several front-ends for MRTG. > > We are looking into a new player in the space called Logicmonitor. They > have a very functional and easy to navigate front end and configuration > tool, and I very much like the look-and-feel of their product. > > What I don't like is that they only offer it as a cloud-based service. > Internal probes tie in to a "collector" which we maintain. The collector > then phones home over the Internet to their hosted service periodically > and they remotely analyze the data and generate alerts, plot graphs, etc. > > From a technical standpoint this adds more points of failure in series, > will cause missed alerts if their cloud-based service goes down (who is > guarding the guards?) will cause false alarms if their service is still > up but can't reach the collector, and doesn't give us a full view under > the hood. > > Of course their sales guys are giving us "Our time and energy is > dedicated to reliability" and "professionally managed multi-carrier > highly secure data centers" language to encourage the warm fuzzies. > > From a scalability standpoint we incur ever-increasing recurring costs > as we grow and add monitored devices and services. > > What's the collective opinion here? Is anyone using them or a similar > service? Are there non-cloud-based alternatives that are relatively easy > to set up and manage? We've explored Zabbix, Nagios, MRTG and its > various wrappers, and Intermapper. Anything else new on the horizon that > has a GUI front-end that is configurable without a lot of scripting > experience, etc.? > > We would love to buy something that works for us and pay a reasonable > price for it, but I'm not particularly interested in the equivalent of > renting a time-share in order to monitor our networks. > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mel at beckman.org Wed Jan 28 18:40:19 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 28 Jan 2015 18:40:19 +0000 Subject: Alerting systems, Logicmonitor and/or alternatives In-Reply-To: <54C92522.7060301@west.net> References: <54C92522.7060301@west.net> Message-ID: <14A3DAFA-4F9F-43BA-9C29-5FAB9A4D5C51@beckman.org> The value proposition of all cloud services is that you get instant technical capability without building your own infrastructure. I see cloud NMS services like LogicMonitor and Spiceworks as a good deal for small organizations without their own IT people. But for all the reasons you give, the model doesn't scale very well. For network professionals, the value of self-managed internal monitoring infrastructure far outweighs the temporary ease and low cost of cloud monitoring. In particular, commercial monitoring offerings, such as Intermapper, PRTG, and SolarWinds, are extremely cost effective for business network operations. Their cost is easily justifiable, especially if you have a busy staff. Yes, you can get many of the commercial tool capabilities in open source projects such as OpenNMS and Cacti. But as you note, they can be a pain to configure, and if your labor is worth anything, the commercial options are usually a better deal. One exception I've found recently is Mikrotik's The Dude, which is free, but not FOSS. It's fully graphical, is straightforward to install and configure. It has a client/server architecture like Intermapper, but doesn't run natively on as many platforms (Windows only; other OSes must use emulation). Although it works with any SNMP device, it has special support for Mikrotik, since Mikrotik devised it. To recap, I think cloud monitoring is pointless for managing inside networks for any organization having a reasonably capable IT staff. On Jan 28, 2015, at 10:06 AM, Jay Hennigan wrote: > I know that this topic has been kicking around for at least a decade, > but wanted to get current opinions of other network operators. Most of > us have explored Nagios, MRTG, and several front-ends for MRTG. > > We are looking into a new player in the space called Logicmonitor. They > have a very functional and easy to navigate front end and configuration > tool, and I very much like the look-and-feel of their product. > > What I don't like is that they only offer it as a cloud-based service. > Internal probes tie in to a "collector" which we maintain. The collector > then phones home over the Internet to their hosted service periodically > and they remotely analyze the data and generate alerts, plot graphs, etc. > > From a technical standpoint this adds more points of failure in series, > will cause missed alerts if their cloud-based service goes down (who is > guarding the guards?) will cause false alarms if their service is still > up but can't reach the collector, and doesn't give us a full view under > the hood. > > Of course their sales guys are giving us "Our time and energy is > dedicated to reliability" and "professionally managed multi-carrier > highly secure data centers" language to encourage the warm fuzzies. > > From a scalability standpoint we incur ever-increasing recurring costs > as we grow and add monitored devices and services. > > What's the collective opinion here? Is anyone using them or a similar > service? Are there non-cloud-based alternatives that are relatively easy > to set up and manage? We've explored Zabbix, Nagios, MRTG and its > various wrappers, and Intermapper. Anything else new on the horizon that > has a GUI front-end that is configurable without a lot of scripting > experience, etc.? > > We would love to buy something that works for us and pay a reasonable > price for it, but I'm not particularly interested in the equivalent of > renting a time-share in order to monitor our networks. > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV From charles at thefnf.org Wed Jan 28 19:08:49 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Wed, 28 Jan 2015 13:08:49 -0600 Subject: Alerting systems, Logicmonitor and/or alternatives In-Reply-To: <54C92522.7060301@west.net> References: <54C92522.7060301@west.net> Message-ID: > What's the collective opinion here? Is anyone using them or a similar > service? Are there non-cloud-based alternatives that are relatively > easy > to set up and manage? We've explored Zabbix, Nagios, MRTG and its > various wrappers, and Intermapper. Anything else new on the horizon > that > has a GUI front-end that is configurable without a lot of scripting > experience, etc.? Zenoss. I have it monitoring about 4k end points. The documentation is phenomnal. I've not had to touch the command line at all for any operations. I have two cron jobs on the server (one to do a weekly backup to a tar file that gets grabbed by my backup systems, one to run zendisc on only subnets I care about (and not everything in zenoss which is the default). The learning curve was pretty much non existent (you install it (which is apt-get or yum or scripted [i think appliances exist, i dunno]) , connect with default creds, change your creds, scan your network, classify devices, setup alerting rules and contacts). This all presumes you have SNMP already setup of course (which is trivial to do on just about everything). (Oh I did use the CLI to load in mibs, but that's a one time operation (unless you are constantly adding new vendors to your network i guess). > > We would love to buy something that works for us and pay a reasonable > price for it, but I'm not particularly interested in the equivalent of > renting a time-share in order to monitor our networks. Indeed. You should be able to find plenty of Linux engineers that could easily set this up. I would probably charge about $250.00 to $500.00 flat rate for a zenoss deployment, and could deliver it in 8 to 30 hours fully ready to go (range depends on size of deployment, HA, multi site etc). I expect most other engineers could do about the same (or maybe a bit longer if they've never worked with Zenoss before). (I'm that weird Linux/Windows/VM/storage/security/app admin type who is now getting his CCIE cause networking looks fun). > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > !DSPAM:54c925874441589320983! From joelja at bogus.com Wed Jan 28 20:02:35 2015 From: joelja at bogus.com (joel jaeggli) Date: Wed, 28 Jan 2015 12:02:35 -0800 Subject: look for BGP routes containing local AS# In-Reply-To: <54C8ACB2.9080505@gmail.com> References: <54C79682.9020802@gmail.com> <54C89C8A.2030800@bogus.com> <54C8ACB2.9080505@gmail.com> Message-ID: <54C9405B.9040508@bogus.com> On 1/28/15 1:32 AM, Song Li wrote: > Hi Joel, > > It is right that the BGP route containing the local ASN will be droped. > However, such routes can still be displayed on router. There is also the non-zero probability that they don't arrive. If this is and edge router if your neighbor is a juniper and the only instance of prefix advertisement with this case is your advertisement from your router your're not going to get it. From: --- https://www.juniper.net/documentation/en_US/junos14.2/topics/topic-map/bgp-route-advertisement.html Disabling Suppression of Route Advertisements Junos OS does not advertise the routes learned from one EBGP peer back to the same external BGP (EBGP) peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same AS as the originating peer, regardless of the routing instance. You can modify this behavior by including the advertise-peer-as statement in the configuration. To disable the default advertisement suppression, include the advertise-peer-as statement: Note: The route suppression default behavior is disabled if the as-override statement is included in the configuration. If you include the advertise-peer-as statement in the configuration, BGP advertises the route regardless of this check. To restore the default behavior, include the no-advertise-peer-as statement in the configuration: no-advertise-peer-as; If you include both the as-override and no-advertise-peer-as statements in the configuration, the no-advertise-peer-as statement is ignored. You can include these statements at multiple hierarchy levels. For a list of hierarchy levels at which you can include these statements, see the statement summary section for these statements. --- If this is an edge router and your provider is filtering those either from above or other reasons then you won't recieve them. If this in an ibgp session and they're not being accepted on the edge router you will never see them. > For example, you > can run "show route hidden terse aspath-regex .*.*" on > Juniper to check them. We are looking for those routes. If you can run > the command on your Juniper and find such routes, could you please > provider them for us? > > Thanks! > > Regards! > > Song > > 在 2015/1/28 16:23, joel jaeggli 写道: >> On 1/27/15 5:45 AM, Song Li wrote: >>> Hi everyone, >>> >>> Recently I studied the BGP AS path looping problem, and found that in >>> most cases, the received BGP routes containing local AS# are suspicious. >>> However, we checked our BGP routing table (AS23910,CERNET2) on juniper >>> router(show route hidden terse aspath-regex .*23910.* ), and have not >>> found such routes in Adj-RIB-In. >> >> Updates with your AS in the path are discarded as part of loop >> detection, e.g. they do not become candidate routes. >> >> https://tools.ietf.org/html/rfc4271 page 77 >> >> If the AS_PATH attribute of a BGP route contains an AS loop, the BGP >> route should be excluded from the Phase 2 decision function. AS loop >> detection is done by scanning the full AS path (as specified in the >> AS_PATH attribute), and checking that the autonomous system number of >> the local system does not appear in the AS path. Operations of a BGP >> speaker that is configured to accept routes with its own autonomous >> system number in the AS path are outside the scope of this document. >> >> in junos >> >> neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number >> >> where number is the number of instances of your AS in the path you're >> willing to accept will correct that. >> >>> We believe that the received BGP routes containing local AS# are related >>> to BGP security problem. >> >> You'll have to elaborate, since their existence is a basic principle in >> the operation of bgp and they are ubiquitous. >> >> Island instances of a distributed ASN communicate with each other by >> allowing such routes in so that they can be evaluated one the basis of >> prefix, specificity, AS path length and so forth. >> >>> Hence, we want to look for some real cases in >>> the wild. Could anybody give us some examples of such routes? >>> >>> Thanks! >>> >>> Best Regards! >>> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From pavel.odintsov at gmail.com Wed Jan 28 20:36:54 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 29 Jan 2015 00:36:54 +0400 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <5921D86D-0312-414B-A894-59D79A1EFBE0@arbor.net> References: <20141122160052.4EB8855000087@freedman.net> <547121E5.4050401@gameservers.com> <5921D86D-0312-414B-A894-59D79A1EFBE0@arbor.net> Message-ID: Hello, folks! NetFlow v5 and v9 support have just added to FastNetMon: https://github.com/FastVPSEestiOu/fastnetmon Now you can catch DDoS attacks and collect data from sFLOW v5, NetFlow v5/v9 and even from mirror port with PF_RING in one tool simultaneously! Will be very glad for feedback and testing! On Wed, Dec 3, 2014 at 7:57 AM, Roland Dobbins wrote: > > On 2 Dec 2014, at 17:18, Pavel Odintsov wrote: > >> In near future I will add netflow v5 support. > > > Good job - you should really go for NetFlow v9 when you can, as it supports > IPv6 and MPLS labels. > > Next would be IPFIX. > > ----------------------------------- > Roland Dobbins -- Sincerely yours, Pavel Odintsov From dorancemc at gmail.com Wed Jan 28 21:21:56 2015 From: dorancemc at gmail.com (Dorance Martinez Cortes) Date: Wed, 28 Jan 2015 16:21:56 -0500 Subject: Alerting systems, Logicmonitor and/or alternatives In-Reply-To: <54C92522.7060301@west.net> References: <54C92522.7060301@west.net> Message-ID: Hi Jay, I have experience with nagios and cacti, now I'm experimenting with logic monitor and observium. The observium is a great tool to discover your network devices but don't have great graphics and don't have any alarm system, but you can get a lot of information about your network devices, connections, ip address, protocols and configurations. Logic Monitor is a new tool for me, but without comparison with nagios, they have well support, but some times you need time to create personal data-points because they don't have recognising for all devices. Nagios could require time for implementation and experience with command line and snmp. not is a expensive tool only if you don't want pay for it. But the nagios XI is a great tool with lot of functions, automatización process, graphics, and capacity planning. You can try with nagios xi with network analyzer. If you don't have budget maybe nagios core and observium can offer a great solution. For comercial solution, I recommend you nagios xi and nagios network analyzer. 2015-01-28 13:06 GMT-05:00 Jay Hennigan : > I know that this topic has been kicking around for at least a decade, > but wanted to get current opinions of other network operators. Most of > us have explored Nagios, MRTG, and several front-ends for MRTG. > > We are looking into a new player in the space called Logicmonitor. They > have a very functional and easy to navigate front end and configuration > tool, and I very much like the look-and-feel of their product. > > What I don't like is that they only offer it as a cloud-based service. > Internal probes tie in to a "collector" which we maintain. The collector > then phones home over the Internet to their hosted service periodically > and they remotely analyze the data and generate alerts, plot graphs, etc. > > From a technical standpoint this adds more points of failure in series, > will cause missed alerts if their cloud-based service goes down (who is > guarding the guards?) will cause false alarms if their service is still > up but can't reach the collector, and doesn't give us a full view under > the hood. > > Of course their sales guys are giving us "Our time and energy is > dedicated to reliability" and "professionally managed multi-carrier > highly secure data centers" language to encourage the warm fuzzies. > > From a scalability standpoint we incur ever-increasing recurring costs > as we grow and add monitored devices and services. > > What's the collective opinion here? Is anyone using them or a similar > service? Are there non-cloud-based alternatives that are relatively easy > to set up and manage? We've explored Zabbix, Nagios, MRTG and its > various wrappers, and Intermapper. Anything else new on the horizon that > has a GUI front-end that is configurable without a lot of scripting > experience, etc.? > > We would love to buy something that works for us and pay a reasonable > price for it, but I'm not particularly interested in the equivalent of > renting a time-share in order to monitor our networks. > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > -- Cordialmente, Dorancé Martínez Cortés +57 320 6968121 Linux User Number 112632 Nagios Certified Administrator Certificación ITIL Fundation 2011 ed. Cali - Colombia dorancemc at gmail.com http://dmcingenieria.net http://dmci.co "Si piensas que la tecnología puede solucionar tus problemas de seguridad, está claro que ni entiendes los problemas ni entiendes la tecnología" Bruce Schneier From disordr at gmail.com Wed Jan 28 22:58:05 2015 From: disordr at gmail.com (Philip) Date: Wed, 28 Jan 2015 14:58:05 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: <87vbjt6tml.fsf@muck.riseup.net> References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: I recently built a pair of Linux based "routers" to handle full BGP tables from 3 upstream providers (10gig links) I had penguincomputing.com build me two reasonably powerful (dual xeon hex core processor) servers with SolarFlare NICs. (I didn't get a chance to play with open-onload before moving on to a new opportunity) Rudimentary testing with iperf showed I could saturate a 10gig link with minimal system load. With real world traffic, the limits came when we started pushing packets in the several hundred thousand range. However, this was due to the fact that these "routers" were also doing firewall / NAT duty (iptables), load-balancing (haproxy), VPN endpoints (openvpn), plus the routing eBGP (quagga), and internally propagating OSPF routes as well (quagga). Interrupt handling / system load became a problem only when our hadoop cluster (200+ nodes) started crazy aws s3 communications, otherwise things ran pretty well. The systems, configurations and software were pretty much just hacked together by me. Ideally we would have bought Juniper / Cisco gear, but my budget of $50K wouldn't even buy half a router after my vendors were done quoting me the real stuff. I ended up spending ~$15K to build this solution. I'm a not a networking person though, just a Linux hack, but was able to get this solution working reliably. -Philip On Mon, Jan 26, 2015 at 2:53 PM, micah anderson wrote: > > Hi, > > I know that specially programmed ASICs on dedicated hardware like Cisco, > Juniper, etc. are going to always outperform a general purpose server > running gnu/linux, *bsd... but I find the idea of trying to use > proprietary, NSA-backdoored devices difficult to accept, especially when > I don't have the budget for it. > > I've noticed that even with a relatively modern system (supermicro with > a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server > adapters, and 16gig of ram, you still tend to get high percentage of > time working on softirqs on all the CPUs when pps reaches somewhere > around 60-70k, and the traffic approaching 600-900mbit/sec (during a > DDoS, such hardware cannot typically cope). > > It seems like finding hardware more optimized for very high packet per > second counts would be a good thing to do. I just have no idea what is > out there that could meet these goals. I'm unsure if faster CPUs, or > more CPUs is really the problem, or networking cards, or just plain old > fashioned tuning. > > Any ideas or suggestions would be welcome! > micah > > From ray at oneunified.net Wed Jan 28 23:15:30 2015 From: ray at oneunified.net (Raymond Burkholder) Date: Wed, 28 Jan 2015 19:15:30 -0400 Subject: Alerting systems, Logicmonitor and/or alternatives In-Reply-To: <54C92522.7060301@west.net> References: <54C92522.7060301@west.net> Message-ID: <511f01d03b50$4fa2dbc0$eee89340$@oneunified.net> > What's the collective opinion here? Is anyone using them or a similar service? > Are there non-cloud-based alternatives that are relatively easy to set up and > manage? We've explored Zabbix, Nagios, MRTG and its various wrappers, > and Intermapper. Anything else new on the horizon that has a GUI front-end > that is configurable without a lot of scripting experience, etc.? Try OMD. It packages a python wrapper called check_mk around Nagios and adds on charts via an already integrated pnp4nagios. The guys doing check_mk have done an amazing job of harnessing the power of Nagios through the use of configuration files which nicely minimizes the amount of work necessary for getting things monitored, while maximizing how things are grouped and structured. Since I like it so much, I'm in the process of migrating our monitoring from a combination of NagiosXI, Observium, and Cacti over to the OMD package. It has fast agents for monitoring vsphere. Has native agents for Linux and Windows. And can do SNMP. And has good customization for those who want more done that what is supplied out of the box. > > We would love to buy something that works for us and pay a reasonable > price for it, but I'm not particularly interested in the equivalent of renting a > time-share in order to monitor our networks. Check_mk has support and professional services available. It is open source for those who wish to go the DIY route. Raymond blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From adrian at creative.net.au Wed Jan 28 23:18:30 2015 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 28 Jan 2015 15:18:30 -0800 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: [snip] To inject science into the discussion: http://bsdrp.net/documentation/examples/forwarding_performance_lab_of_an_ibm_system_x3550_m3_with_10-gigabit_intel_x540-at2 And he maintains a test setup to check for performance regressions: http://bsdrp.net/documentation/examples/freebsd_performance_regression_lab Now, this is using the in-kernel stack, not netmap/pfring/etc that uses all the batching-y, stack-shallow-y implementations that the kernel currently doesn't have. But, there are people out there doing science on it and trying very hard to kick things along. The nice thing about what has come out of the DPDK related stuff is, well, the bar is set very high now. Now it's up to the open source groups to stop messing around and do something about it. If you're interested in more of this stuff, go poke Jim at pfsense/netgate. -adrian (This and RSS work is plainly in my "stuff I do for fun" category, btw.) From refresh.lsong at gmail.com Thu Jan 29 01:38:23 2015 From: refresh.lsong at gmail.com (Song Li) Date: Thu, 29 Jan 2015 09:38:23 +0800 Subject: look for BGP routes containing local AS# In-Reply-To: References: <54C79682.9020802@gmail.com> <54C89C8A.2030800@bogus.com> <54C8ACB2.9080505@gmail.com> Message-ID: <54C98F0F.9000002@gmail.com> Hi Patrick, We want to know what's the reason for the received routes containing local ASN. Hence we need real cases of those routes in the Internet. And any routes like that are welcome, whether they are on Juniper router or other BGP software. Thank you! Regards! Song 在 2015/1/29 1:50, Patrick Tracanelli 写道: > > Sorry, what do you need exactly? A sample? For education purposes are you looking for something specific? > You need it to be on Juniper router or other BGP software will do? > > I have this scenario from Brazil-US, with specifics getting received both ways but it’s not Juniper. > > > >> Thanks! >> >> Regards! >> >> Song >> >> 在 2015/1/28 16:23, joel jaeggli 写道: >>> On 1/27/15 5:45 AM, Song Li wrote: >>>> Hi everyone, >>>> >>>> Recently I studied the BGP AS path looping problem, and found that in >>>> most cases, the received BGP routes containing local AS# are suspicious. >>>> However, we checked our BGP routing table (AS23910,CERNET2) on juniper >>>> router(show route hidden terse aspath-regex .*23910.* ), and have not >>>> found such routes in Adj-RIB-In. >>> >>> Updates with your AS in the path are discarded as part of loop >>> detection, e.g. they do not become candidate routes. >>> >>> https://tools.ietf.org/html/rfc4271 page 77 >>> >>> If the AS_PATH attribute of a BGP route contains an AS loop, the BGP >>> route should be excluded from the Phase 2 decision function. AS loop >>> detection is done by scanning the full AS path (as specified in the >>> AS_PATH attribute), and checking that the autonomous system number of >>> the local system does not appear in the AS path. Operations of a BGP >>> speaker that is configured to accept routes with its own autonomous >>> system number in the AS path are outside the scope of this document. >>> >>> in junos >>> >>> neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number >>> >>> where number is the number of instances of your AS in the path you're >>> willing to accept will correct that. >>> >>>> We believe that the received BGP routes containing local AS# are related >>>> to BGP security problem. >>> >>> You'll have to elaborate, since their existence is a basic principle in >>> the operation of bgp and they are ubiquitous. >>> >>> Island instances of a distributed ASN communicate with each other by >>> allowing such routes in so that they can be evaluated one the basis of >>> prefix, specificity, AS path length and so forth. >>> >>>> Hence, we want to look for some real cases in >>>> the wild. Could anybody give us some examples of such routes? >>>> >>>> Thanks! >>>> >>>> Best Regards! >>>> >>> >>> >> >> >> -- >> Song Li >> Room 4-204, FIT Building, >> Network Security, >> Department of Electronic Engineering, >> Tsinghua University, Beijing 100084, China >> Tel:( +86) 010-62446440 >> E-mail: refresh.lsong at gmail.com > > -- > Patrick Tracanelli > > FreeBSD Brasil LTDA. > Tel.: (31) 3516-0800 > 316601 at sip.freebsdbrasil.com.br > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From rsk at gsp.org Thu Jan 29 02:33:39 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 28 Jan 2015 21:33:39 -0500 Subject: Alerting systems, Logicmonitor and/or alternatives In-Reply-To: <54C92522.7060301@west.net> References: <54C92522.7060301@west.net> Message-ID: <20150129023339.GB26219@gsp.org> On Wed, Jan 28, 2015 at 10:06:26AM -0800, Jay Hennigan wrote: > What I don't like is that they only offer it as a cloud-based service. One of the downsides of all such services is that the more successful they are, the bigger a target they are. And they're a tempting target, since successful penetration would yield a wealth of data about every client they have (if that penetration was limited to read-only access) and possibly more, e.g., silencing alarms that would otherwise be triggered (if that penetration allowed write access). ---rsk From rdrake at direcpath.com Thu Jan 29 02:38:16 2015 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 28 Jan 2015 21:38:16 -0500 Subject: PDU for high amp 48Vdc Message-ID: <54C99D18.5070907@direcpath.com> For larger DC devices with ~50amps per side, does anyone have a software accessible way to turn off power? I've looked into PDU's but the ones I find have a max of 10amps. I've considered building something with solenoids or a rotary actuator that would turn the switches on or off, but that's a complete one-off and would need to be done for each device we manage (not to mention it involves janky wiring all over the place I've got to explain to the colo) My use case is pretty infrequent so it needs to be remote-hands cheap.. it's for emergencies when you need to completely power cycle a redundantly powered DC device. The last time I needed this it was because a router was stuck in a boot loop due to a bad IOS upgrade and wouldn't break to rommon since it had been >60 seconds. It came up again tonight because we wanted to disable one power supply to troubleshoot something. FWIW, I believe I've seen newer Cisco gear with high-end power supplies that have a console or ethernet port which would possibly let you shut them down remotely. That solves the problem nicely if you're dealing with only one bit of hardware, but I'd like a general solution that worked with any vendor. Possibly a fuse panel with solenoids that could add/remove fuses when needed.. or would that be considered dangerous in code-ways or in telco fire regulation ways? From andy at mbrez.com Thu Jan 29 02:49:27 2015 From: andy at mbrez.com (Andy Brezinsky) Date: Wed, 28 Jan 2015 20:49:27 -0600 Subject: PDU for high amp 48Vdc In-Reply-To: <54C99D18.5070907@direcpath.com> References: <54C99D18.5070907@direcpath.com> Message-ID: <54C99FB7.8000002@mbrez.com> We use ServerTech for -48Vdc switching, http://www.servertech.com/products/-48vdcpowermanagement/ Not quite remote-hands cheap, but worth every penny in a pinch. On 01/28/2015 08:38 PM, Robert Drake wrote: > For larger DC devices with ~50amps per side, does anyone have a > software accessible way to turn off power? > > I've looked into PDU's but the ones I find have a max of 10amps. > > I've considered building something with solenoids or a rotary actuator > that would turn the switches on or off, but that's a complete one-off > and would need to be done for each device we manage (not to mention it > involves janky wiring all over the place I've got to explain to the colo) > > My use case is pretty infrequent so it needs to be remote-hands > cheap.. it's for emergencies when you need to completely power cycle a > redundantly powered DC device. The last time I needed this it was > because a router was stuck in a boot loop due to a bad IOS upgrade and > wouldn't break to rommon since it had been >60 seconds. It came up > again tonight because we wanted to disable one power supply to > troubleshoot something. > > FWIW, I believe I've seen newer Cisco gear with high-end power > supplies that have a console or ethernet port which would possibly let > you shut them down remotely. That solves the problem nicely if you're > dealing with only one bit of hardware, but I'd like a general solution > that worked with any vendor. Possibly a fuse panel with solenoids > that could add/remove fuses when needed.. or would that be considered > dangerous in code-ways or in telco fire regulation ways? > > > > From woody at pch.net Thu Jan 29 03:21:25 2015 From: woody at pch.net (Bill Woodcock) Date: Wed, 28 Jan 2015 19:21:25 -0800 Subject: PDU for high amp 48Vdc In-Reply-To: <54C99D18.5070907@direcpath.com> References: <54C99D18.5070907@direcpath.com> Message-ID: <9FA96721-C9DF-4823-ACFC-799272D40624@pch.net> The rotary actuators are an off-the-shelf item for transfer switches. No problem to get them paired with high-amperage switches. But a contactor, which is a solenoid-driven switch, is also an off-the-shelf item. The ones I use in EV applications are rated for 1000A, and cost about $300. You need to be careful to look at the trade-off between voltage, amperage, and the per-cycle probability of a weld, though. An over-rated contactor helps a lot if you're going to be cycling it a lot, whereas if it's for emergency use only, you can hew a lot closer to the max rating. -Bill > On Jan 28, 2015, at 18:40, Robert Drake wrote: > > For larger DC devices with ~50amps per side, does anyone have a software accessible way to turn off power? > > I've looked into PDU's but the ones I find have a max of 10amps. > > I've considered building something with solenoids or a rotary actuator that would turn the switches on or off, but that's a complete one-off and would need to be done for each device we manage (not to mention it involves janky wiring all over the place I've got to explain to the colo) > > My use case is pretty infrequent so it needs to be remote-hands cheap.. it's for emergencies when you need to completely power cycle a redundantly powered DC device. The last time I needed this it was because a router was stuck in a boot loop due to a bad IOS upgrade and wouldn't break to rommon since it had been >60 seconds. It came up again tonight because we wanted to disable one power supply to troubleshoot something. > > FWIW, I believe I've seen newer Cisco gear with high-end power supplies that have a console or ethernet port which would possibly let you shut them down remotely. That solves the problem nicely if you're dealing with only one bit of hardware, but I'd like a general solution that worked with any vendor. Possibly a fuse panel with solenoids that could add/remove fuses when needed.. or would that be considered dangerous in code-ways or in telco fire regulation ways? > > > > From amekkaoui at mektel.ca Thu Jan 29 04:10:54 2015 From: amekkaoui at mektel.ca (A MEKKAOUI) Date: Wed, 28 Jan 2015 23:10:54 -0500 Subject: cable modem firmware upgrade Message-ID: <000501d03b79$942070e0$bc6152a0$@ca> Hi, Anyone knows how to upgrade Motorola SB6120 cable modem firmware other than going through the internet provider? Your help will be appreciated. Thank you A MEKKAOUI MEKTEL INC www.mektel.ca From nathana at fsr.com Thu Jan 29 04:19:48 2015 From: nathana at fsr.com (Nathan Anderson) Date: Wed, 28 Jan 2015 20:19:48 -0800 Subject: cable modem firmware upgrade In-Reply-To: <000501d03b79$942070e0$bc6152a0$@ca> References: <000501d03b79$942070e0$bc6152a0$@ca> Message-ID: On Wednesday, January 28, 2015 8:11 PM, A MEKKAOUI wrote: > Anyone knows how to upgrade Motorola SB6120 cable modem firmware other > than going through the internet provider? Your help will be appreciated. My employer managed a handful of small DOCSIS networks for a while where 99% of the modems were Motorola, and as far as I know, there is no way to push a firmware update to the modem from the ethernet side...only from the RF side. And trust me: I looked. If I ever had to update the firmware on some batch of modems that weren't already deployed on a network, I would hook them up to a test CMTS that we had on the bench in order to do so. I would strongly suspect that this is going to hold true for just about any DOCSIS modem. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From frnkblk at iname.com Thu Jan 29 04:45:27 2015 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 28 Jan 2015 22:45:27 -0600 Subject: cable modem firmware upgrade In-Reply-To: References: <000501d03b79$942070e0$bc6152a0$@ca> Message-ID: <001201d03b7e$6ac8b180$405a1480$@iname.com> And even if you updated it yourself, it's possible that your service provider's config file would automatically downgrade it. Best bet is to ask your internet provider to upgrade your modem. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nathan Anderson Sent: Wednesday, January 28, 2015 10:20 PM To: 'A MEKKAOUI'; 'nanog at nanog.org' Subject: RE: cable modem firmware upgrade On Wednesday, January 28, 2015 8:11 PM, A MEKKAOUI wrote: > Anyone knows how to upgrade Motorola SB6120 cable modem firmware other > than going through the internet provider? Your help will be appreciated. My employer managed a handful of small DOCSIS networks for a while where 99% of the modems were Motorola, and as far as I know, there is no way to push a firmware update to the modem from the ethernet side...only from the RF side. And trust me: I looked. If I ever had to update the firmware on some batch of modems that weren't already deployed on a network, I would hook them up to a test CMTS that we had on the bench in order to do so. I would strongly suspect that this is going to hold true for just about any DOCSIS modem. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From mmg at transtelco.net Thu Jan 29 05:06:39 2015 From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=) Date: Wed, 28 Jan 2015 22:06:39 -0700 Subject: Recommended wireless AP for 400 users office Message-ID: Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From mike.lyon at gmail.com Thu Jan 29 05:17:26 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 28 Jan 2015 21:17:26 -0800 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: Check out Xirrus On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: > Dear nanog community > > I was wondering if you can recommend or share your experience with APs that > you can use in locations that have 300-500 users. I friend recommended me > Ruckus Wireless, it would be great if you can share your experience with > Ruckus or with a similar vendor. My experience with ubiquity for this type > of requirement was not that good. > > Thank you and have a great day > From tylermills at gmail.com Thu Jan 29 06:19:00 2015 From: tylermills at gmail.com (Tyler Mills) Date: Thu, 29 Jan 2015 06:19:00 +0000 Subject: Recommended wireless AP for 400 users office References: Message-ID: Have had a lot of experience with Ruckus(and Unifi unfortunately). The Ruckus platform is one of the best. If you will be responsible for supporting the deployment, it will save you a lot of frustration when compared with UBNT. On Thu Jan 29 2015 at 12:18:54 AM Mike Lyon wrote: > Check out Xirrus > On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: > > > Dear nanog community > > > > I was wondering if you can recommend or share your experience with APs > that > > you can use in locations that have 300-500 users. I friend recommended me > > Ruckus Wireless, it would be great if you can share your experience with > > Ruckus or with a similar vendor. My experience with ubiquity for this > type > > of requirement was not that good. > > > > Thank you and have a great day > > > From listas at esds.com.br Thu Jan 29 09:46:06 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Thu, 29 Jan 2015 07:46:06 -0200 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: +1 Ruckus+ZoneDirector -- Eduardo Em quinta-feira, 29 de janeiro de 2015, Tyler Mills escreveu: > Have had a lot of experience with Ruckus(and Unifi unfortunately). The > Ruckus platform is one of the best. If you will be responsible for > supporting the deployment, it will save you a lot of frustration when > compared with UBNT. > > On Thu Jan 29 2015 at 12:18:54 AM Mike Lyon > wrote: > > > Check out Xirrus > > On Jan 28, 2015 9:08 PM, "Manuel Marín" > wrote: > > > > > Dear nanog community > > > > > > I was wondering if you can recommend or share your experience with APs > > that > > > you can use in locations that have 300-500 users. I friend recommended > me > > > Ruckus Wireless, it would be great if you can share your experience > with > > > Ruckus or with a similar vendor. My experience with ubiquity for this > > type > > > of requirement was not that good. > > > > > > Thank you and have a great day > > > > > > -- Eduardo Schoedler From savage at savage.za.org Thu Jan 29 09:50:45 2015 From: savage at savage.za.org (Chris Knipe) Date: Thu, 29 Jan 2015 11:50:45 +0200 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: Mikrotik's also a rather good choice for the Wireless AP side... On Thu, Jan 29, 2015 at 11:46 AM, Eduardo Schoedler wrote: > +1 Ruckus+ZoneDirector > > -- > Eduardo > > Em quinta-feira, 29 de janeiro de 2015, Tyler Mills > escreveu: > > > Have had a lot of experience with Ruckus(and Unifi unfortunately). The > > Ruckus platform is one of the best. If you will be responsible for > > supporting the deployment, it will save you a lot of frustration when > > compared with UBNT. > > > > On Thu Jan 29 2015 at 12:18:54 AM Mike Lyon > > wrote: > > > > > Check out Xirrus > > > On Jan 28, 2015 9:08 PM, "Manuel Marín" > > wrote: > > > > > > > Dear nanog community > > > > > > > > I was wondering if you can recommend or share your experience with > APs > > > that > > > > you can use in locations that have 300-500 users. I friend > recommended > > me > > > > Ruckus Wireless, it would be great if you can share your experience > > with > > > > Ruckus or with a similar vendor. My experience with ubiquity for > this > > > type > > > > of requirement was not that good. > > > > > > > > Thank you and have a great day > > > > > > > > > > > > -- > Eduardo Schoedler > -- Regards, Chris Knipe From paul at nashnetworks.ca Thu Jan 29 10:17:32 2015 From: paul at nashnetworks.ca (Paul Nash) Date: Thu, 29 Jan 2015 05:17:32 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: Make that +2. I am halfway through an install for about 800 users spread through a multi-story building with around 100 R700 access points and ZD 3000. Once you understand the basics, it is trivial to set up, easy to manage, performance is superb. Using RADIUS auth you can assign different groups of users to different VLANs (all on a single SSID), just different username/password to connect. Signal penetration is the best that I have ever seen, and makes the Cisco Aironet enterprise stuff look really really silly. paul > On Jan 29, 2015, at 4:46 AM, Eduardo Schoedler wrote: > > +1 Ruckus+ZoneDirector > > -- > Eduardo > > Em quinta-feira, 29 de janeiro de 2015, Tyler Mills > escreveu: > >> Have had a lot of experience with Ruckus(and Unifi unfortunately). The >> Ruckus platform is one of the best. If you will be responsible for >> supporting the deployment, it will save you a lot of frustration when >> compared with UBNT. >> >> On Thu Jan 29 2015 at 12:18:54 AM Mike Lyon > > wrote: >> >>> Check out Xirrus >>> On Jan 28, 2015 9:08 PM, "Manuel Marín" > > wrote: >>> >>>> Dear nanog community >>>> >>>> I was wondering if you can recommend or share your experience with APs >>> that >>>> you can use in locations that have 300-500 users. I friend recommended >> me >>>> Ruckus Wireless, it would be great if you can share your experience >> with >>>> Ruckus or with a similar vendor. My experience with ubiquity for this >>> type >>>> of requirement was not that good. >>>> >>>> Thank you and have a great day >>>> >>> >> > > > -- > Eduardo Schoedler From paul at paulstewart.org Thu Jan 29 10:22:44 2015 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 29 Jan 2015 05:22:44 -0500 Subject: cable modem firmware upgrade In-Reply-To: References: <000501d03b79$942070e0$bc6152a0$@ca> Message-ID: <011701d03bad$86476030$92d62090$@paulstewart.org> That has been my experience as well (only from the RF side) and I would believe this was a design choice. The ISP usually wants to keep control over the firmware versions of the CM for various technical/support reasons versus having consumers mess with the firmware. Paul On Wednesday, January 28, 2015 8:11 PM, A MEKKAOUI wrote: > Anyone knows how to upgrade Motorola SB6120 cable modem firmware other > than going through the internet provider? Your help will be appreciated. My employer managed a handful of small DOCSIS networks for a while where 99% of the modems were Motorola, and as far as I know, there is no way to push a firmware update to the modem from the ethernet side...only from the RF side. From csmith6 at swarthmore.edu Thu Jan 29 12:13:20 2015 From: csmith6 at swarthmore.edu (Aaron Smith) Date: Thu, 29 Jan 2015 07:13:20 -0500 (EST) Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: <890162357.5254496.1422533600936.JavaMail.zimbra@swarthmore.edu> Aruba Networks is also good for wireless. I support ~2000 users spread out over 50+ buildings on a small college campus. Lots of add on options like Clearpass for NAC and guest provisioning and Airwave for historical data and RF planning. Good Luck! Aaron Smith ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Thursday, January 29, 2015 12:06:39 AM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From rps at maine.edu Thu Jan 29 13:11:54 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Jan 2015 08:11:54 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: Just curious. What kind of problems have you seen with the Ubiquiti solution? I've had a few units in for testing a potential managed wireless for rural libraries and so far they've been pretty rock solid for the price. My biggest critique is that they don't support many features and are fairly static, so you really need to map out your deployment and handle power level and channel selection manually. That said the test deployments I have going are very, very small. On Thu, Jan 29, 2015 at 1:19 AM, Tyler Mills wrote: > Have had a lot of experience with Ruckus(and Unifi unfortunately). The > Ruckus platform is one of the best. If you will be responsible for > supporting the deployment, it will save you a lot of frustration when > compared with UBNT. > > On Thu Jan 29 2015 at 12:18:54 AM Mike Lyon wrote: > >> Check out Xirrus >> On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: >> >> > Dear nanog community >> > >> > I was wondering if you can recommend or share your experience with APs >> that >> > you can use in locations that have 300-500 users. I friend recommended me >> > Ruckus Wireless, it would be great if you can share your experience with >> > Ruckus or with a similar vendor. My experience with ubiquity for this >> type >> > of requirement was not that good. >> > >> > Thank you and have a great day >> > >> -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From nanog at ics-il.net Thu Jan 29 13:22:48 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 29 Jan 2015 07:22:48 -0600 (CST) Subject: Recommended wireless AP for 400 users office In-Reply-To: Message-ID: <9095977.636.1422537766884.JavaMail.mhammett@ThunderFuck> What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From rps at maine.edu Thu Jan 29 13:52:51 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Jan 2015 08:52:51 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: <9095977.636.1422537766884.JavaMail.mhammett@ThunderFuck> References: <9095977.636.1422537766884.JavaMail.mhammett@ThunderFuck> Message-ID: Yeah, most people ignore ZH. UBNT marketing hyped it up quite a bit, and for a residential deployment it can work OK, but if you have any kind of background in wireless you'll understand that it goes out the window for a non-trivial deployment due to the requirement of all APs sharing a channel. It's too bad they don't support 802.11r (fast roaming) and 802.11k (radio resource management). On Thu, Jan 29, 2015 at 8:22 AM, Mike Hammett wrote: > What problems have you had with UBNT? > > It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Manuel Marín" > To: nanog at nanog.org > Sent: Wednesday, January 28, 2015 11:06:39 PM > Subject: Recommended wireless AP for 400 users office > > Dear nanog community > > I was wondering if you can recommend or share your experience with APs that > you can use in locations that have 300-500 users. I friend recommended me > Ruckus Wireless, it would be great if you can share your experience with > Ruckus or with a similar vendor. My experience with ubiquity for this type > of requirement was not that good. > > Thank you and have a great day > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From paul at paulstewart.org Thu Jan 29 14:34:46 2015 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 29 Jan 2015 09:34:46 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: <9095977.636.1422537766884.JavaMail.mhammett@ThunderFuck> References: <9095977.636.1422537766884.JavaMail.mhammett@ThunderFuck> Message-ID: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 8:23 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From IAN.SLADE at saic.com Thu Jan 29 14:42:49 2015 From: IAN.SLADE at saic.com (Slade, Ian) Date: Thu, 29 Jan 2015 14:42:49 +0000 Subject: Recommended wireless AP for 400 users office In-Reply-To: <890162357.5254496.1422533600936.JavaMail.zimbra@swarthmore.edu> References: <890162357.5254496.1422533600936.JavaMail.zimbra@swarthmore.edu> Message-ID: I've setup at several hotel conference event/trade-shows and office networks with Aruba Networks and it has worked well with multiple access-points getting great coverage and having their adaptive strength features. Ian Slade Sr. Network Engineer | SAIC ITO - Network & Security Solutions ian.slade at saic.com  | 703.676.5234 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Smith Sent: Thursday, January 29, 2015 7:13 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office Aruba Networks is also good for wireless. I support ~2000 users spread out over 50+ buildings on a small college campus. Lots of add on options like Clearpass for NAC and guest provisioning and Airwave for historical data and RF planning. Good Luck! Aaron Smith ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Thursday, January 29, 2015 12:06:39 AM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From Matthew.Black at csulb.edu Thu Jan 29 15:45:15 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Thu, 29 Jan 2015 15:45:15 +0000 Subject: Need abuse/postmaster contact for AT&T Message-ID: Our university just received notice from AT&T that our e-mail is being blocked without much explanation. As all universities send e-mail to the students and employees, it is impossible to tell what triggered AT&T's actions. Does anyone have an AT&T contact? If you are from AT&T, please contact me off-line. Thanks. matthew black e-mail postmaster california state university, long beach -----Original Message----- From: test_reply at att.net [mailto:test_reply at att.net] Sent: Wednesday, January 28, 2015 4:58 PM Subject: Blocked Email Notification Dear Postmaster: We are writing to let you know that we are blocking messages addressed to one of our customers at the domain att.net by one of your customers at domain csulb.edu. The stream of messages coming from your system appears to consist mostly of unwanted commercial e-mail (UCE, or "spam"). To protect our system and to ensure that it operates well for all of our customers, we have decided to block all messages originating from your system. Please consult your logs to see what might be causing this situation and how it can be fixed. Then visit http://rbl.att.net/block_inquiry.html to request a removal of the block. Most requests for removal are honored within two days. The specific error message received by your customer was: 550 Error - Blocked for abuse. See http://att.net/blocks Thank you for your assistance in helping our respective customers communicate. Best regards, The AT&T Mail Team. From nanog at ics-il.net Thu Jan 29 15:53:08 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 29 Jan 2015 09:53:08 -0600 (CST) Subject: Recommended wireless AP for 400 users office In-Reply-To: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> Message-ID: <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Stewart" To: "Mike Hammett" , nanog at nanog.org Sent: Thursday, January 29, 2015 8:34:46 AM Subject: RE: Recommended wireless AP for 400 users office I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 8:23 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From lists at connectionlost.com.br Thu Jan 29 10:24:03 2015 From: lists at connectionlost.com.br (Tiago Felipe) Date: Thu, 29 Jan 2015 08:24:03 -0200 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: <54CA0A43.7090106@connectionlost.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 +1 Xirrus On 01/29/2015 08:17 AM, Paul Nash wrote: > Make that +2. I am halfway through an install for about 800 users > spread through a multi-story building with around 100 R700 access > points and ZD 3000. Once you understand the basics, it is trivial > to set up, easy to manage, performance is superb. > > Using RADIUS auth you can assign different groups of users to > different VLANs (all on a single SSID), just different > username/password to connect. > > Signal penetration is the best that I have ever seen, and makes the > Cisco Aironet enterprise stuff look really really silly. > > paul > >> On Jan 29, 2015, at 4:46 AM, Eduardo Schoedler >> wrote: >> >> +1 Ruckus+ZoneDirector >> >> -- Eduardo >> >> Em quinta-feira, 29 de janeiro de 2015, Tyler Mills >> escreveu: >> >>> Have had a lot of experience with Ruckus(and Unifi >>> unfortunately). The Ruckus platform is one of the best. If you >>> will be responsible for supporting the deployment, it will save >>> you a lot of frustration when compared with UBNT. >>> >>> On Thu Jan 29 2015 at 12:18:54 AM Mike Lyon >>> > wrote: >>> >>>> Check out Xirrus On Jan 28, 2015 9:08 PM, "Manuel Marín" >>>> >> > wrote: >>>> >>>>> Dear nanog community >>>>> >>>>> I was wondering if you can recommend or share your >>>>> experience with APs >>>> that >>>>> you can use in locations that have 300-500 users. I friend >>>>> recommended >>> me >>>>> Ruckus Wireless, it would be great if you can share your >>>>> experience >>> with >>>>> Ruckus or with a similar vendor. My experience with >>>>> ubiquity for this >>>> type >>>>> of requirement was not that good. >>>>> >>>>> Thank you and have a great day >>>>> >>>> >>> >> >> >> -- Eduardo Schoedler > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUygo/AAoJEMR7HC7H8wTJJwIQAJLj0fo7zSItMGmlj+v5oo8S VS/ePSV6YG31SLvADHy9Ge7yaazLzrh9tUdGKqBz5KCHMghUqJLnMf1DDiDvYzuW cmv3Y4P/Knu3q3eYeBlcYMhoh+qSRJ+/lTwaPCyHE3BlSr1E/VQjGygHGREQkjDk ubjcXnAbPTJRj6EwKq/MTdqO/nAQROtCxB/69c7i3m3kSvS5XY0jrZiBlhJNgJuH JghSx5wihsbmuMKVkgTta+BhJ0k4+8+Eyp4wnLi1bPNxaRuygF0lkOfnAagZC/ab OkfBabUc4O8p575XRmm+RJStoB1QlbaLaKJfqu1VKbWO6fOpsntU5nyK12lPceKs 7Nq8jbVUzRlkNIQS0kAfwMPOMV9oEWP9zBt4ZAi2gsuHP52YbwKcqn5vzadiJQog 1CC95cfWiYpfT26ThzOzCu6PcLYZzokM4izYi57uPPLRgz4fOmVu89rMSNI/QC00 habLpZV1FVMFRBjEs3HDhKTgedE55WJYelAg5Gw9o5X5qazN0d5UaGSDGb/TKaf+ SwngXboBlfM1a07dM3rK3RTjXPFp6/mrrrPTsoXp0LRdXqJhYQzDtsD/l8r/QQpr hjapvY79HVF8Km8FaZwynSzrY0qS0jESH60LLJzm+IHgEoXNY5bDzDV79x4e+4Xy CjPDZ7IYJ3FvroTsPtoY =yNtF -----END PGP SIGNATURE----- From tylermills at gmail.com Thu Jan 29 16:18:31 2015 From: tylermills at gmail.com (Tyler Mills) Date: Thu, 29 Jan 2015 16:18:31 +0000 Subject: Recommended wireless AP for 400 users office References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> Message-ID: Most of the issues are related to firmware. Most of my UBNT experience was with the UAP-Pro and the UAP-AC, and it wasn't a good experience. Production firmwares seem to be of beta quality. For features, they can't compete with Ruckus. One thing I can think of off the top of my head is support for tagging management on its own VLAN and tagging wired traffic onto another. If you were to implement this on the UBNT products you would have to SSH into every single one and implement the features as you would on a linux box, and it might work. Ruckus, you configure the VLAN's how you would want through the Zonedirector or the AP's GUI and it will just work. They cost more, but you get what you pay for. On Thu Jan 29 2015 at 10:54:44 AM Mike Hammett wrote: > Did you figure out why it was dropping out? All of it dropping out? Just > some APs dropping? Just some users dropping? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Paul Stewart" > To: "Mike Hammett" , nanog at nanog.org > Sent: Thursday, January 29, 2015 8:34:46 AM > Subject: RE: Recommended wireless AP for 400 users office > > I had a bad experience with it one time at a tradeshow environment. 6 > access points setup for public wifi. The radio levels were quite good in > various areas of the tradeshow however traffic would keep dropping out at > random intervals as soon as about 300 users were online. It wasn't my idea > to use UBNT but it definitely turned me off of their product after digging > into their gear... > > Again as someone pointed out, for residential and perhaps SOHO > applications it can probably work well - and in my opinion it's priced for > that market. > > Paul > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Thursday, January 29, 2015 8:23 AM > To: nanog at nanog.org > Subject: Re: Recommended wireless AP for 400 users office > > What problems have you had with UBNT? > > It's zero hand-off doesn't work on unsecured networks, but that's about > the extent of the issues I've heard of other than stadium density > environments. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Manuel Marín" > To: nanog at nanog.org > Sent: Wednesday, January 28, 2015 11:06:39 PM > Subject: Recommended wireless AP for 400 users office > > Dear nanog community > > I was wondering if you can recommend or share your experience with APs > that you can use in locations that have 300-500 users. I friend recommended > me Ruckus Wireless, it would be great if you can share your experience with > Ruckus or with a similar vendor. My experience with ubiquity for this type > of requirement was not that good. > > Thank you and have a great day > > > > From nanog at ics-il.net Thu Jan 29 16:19:41 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 29 Jan 2015 10:19:41 -0600 (CST) Subject: Recommended wireless AP for 400 users office In-Reply-To: Message-ID: <1697930.1434.1422548365278.JavaMail.mhammett@ThunderFuck> That would be a nice feature to have and I have been on them about that. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Tyler Mills" To: "Mike Hammett" , nanog at nanog.org Sent: Thursday, January 29, 2015 10:18:31 AM Subject: Re: Recommended wireless AP for 400 users office Most of the issues are related to firmware. Most of my UBNT experience was with the UAP-Pro and the UAP-AC, and it wasn't a good experience. Production firmwares seem to be of beta quality. For features, they can't compete with Ruckus. One thing I can think of off the top of my head is support for tagging management on its own VLAN and tagging wired traffic onto another. If you were to implement this on the UBNT products you would have to SSH into every single one and implement the features as you would on a linux box, and it might work. Ruckus, you configure the VLAN's how you would want through the Zonedirector or the AP's GUI and it will just work. They cost more, but you get what you pay for. On Thu Jan 29 2015 at 10:54:44 AM Mike Hammett < nanog at ics-il.net > wrote: Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Stewart" < paul at paulstewart.org > To: "Mike Hammett" < nanog at ics-il.net >, nanog at nanog.org Sent: Thursday, January 29, 2015 8:34:46 AM Subject: RE: Recommended wireless AP for 400 users office I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. Paul -----Original Message----- From: NANOG [mailto: nanog-bounces at nanog. org ] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 8:23 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" < mmg at transtelco.net > To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From paul at nashnetworks.ca Thu Jan 29 16:22:50 2015 From: paul at nashnetworks.ca (Paul Nash) Date: Thu, 29 Jan 2015 11:22:50 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> Message-ID: <6D94E2F2-AB8E-4F7E-909D-99EF544D761C@nashnetworks.ca> You can also VLAN allocation through RADIUS. Our setup has a single SSID, 250-odd user accounts. User connects to the SSID & authenticates with their userid/password and is assigned to their VLAN, which connects them to the appropriate DHCP server, gateway, etc. Makes management and segregation fairly trivial (for non-trivial values of trivial :-)). paul > On Jan 29, 2015, at 11:18 AM, Tyler Mills wrote: > > Most of the issues are related to firmware. Most of my UBNT experience was > with the UAP-Pro and the UAP-AC, and it wasn't a good experience. > Production firmwares seem to be of beta quality. > > For features, they can't compete with Ruckus. One thing I can think of off > the top of my head is support for tagging management on its own VLAN and > tagging wired traffic onto another. If you were to implement this on the > UBNT products you would have to SSH into every single one and implement the > features as you would on a linux box, and it might work. Ruckus, you > configure the VLAN's how you would want through the Zonedirector or the > AP's GUI and it will just work. > > They cost more, but you get what you pay for. > > On Thu Jan 29 2015 at 10:54:44 AM Mike Hammett wrote: > >> Did you figure out why it was dropping out? All of it dropping out? Just >> some APs dropping? Just some users dropping? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Paul Stewart" >> To: "Mike Hammett" , nanog at nanog.org >> Sent: Thursday, January 29, 2015 8:34:46 AM >> Subject: RE: Recommended wireless AP for 400 users office >> >> I had a bad experience with it one time at a tradeshow environment. 6 >> access points setup for public wifi. The radio levels were quite good in >> various areas of the tradeshow however traffic would keep dropping out at >> random intervals as soon as about 300 users were online. It wasn't my idea >> to use UBNT but it definitely turned me off of their product after digging >> into their gear... >> >> Again as someone pointed out, for residential and perhaps SOHO >> applications it can probably work well - and in my opinion it's priced for >> that market. >> >> Paul >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >> Sent: Thursday, January 29, 2015 8:23 AM >> To: nanog at nanog.org >> Subject: Re: Recommended wireless AP for 400 users office >> >> What problems have you had with UBNT? >> >> It's zero hand-off doesn't work on unsecured networks, but that's about >> the extent of the issues I've heard of other than stadium density >> environments. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Manuel Marín" >> To: nanog at nanog.org >> Sent: Wednesday, January 28, 2015 11:06:39 PM >> Subject: Recommended wireless AP for 400 users office >> >> Dear nanog community >> >> I was wondering if you can recommend or share your experience with APs >> that you can use in locations that have 300-500 users. I friend recommended >> me Ruckus Wireless, it would be great if you can share your experience with >> Ruckus or with a similar vendor. My experience with ubiquity for this type >> of requirement was not that good. >> >> Thank you and have a great day >> >> >> >> From mianosm at gmail.com Thu Jan 29 16:34:30 2015 From: mianosm at gmail.com (Steven Miano) Date: Thu, 29 Jan 2015 11:34:30 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: <6D94E2F2-AB8E-4F7E-909D-99EF544D761C@nashnetworks.ca> References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <6D94E2F2-AB8E-4F7E-909D-99EF544D761C@nashnetworks.ca> Message-ID: Another hat that I haven't seen thrown in the ring yet is Aerohive. They're great to work with - and the product is decent in terms of scalability across geographically locations with management being hosted by them, or you - as/when needed. Huge list of features and capabilities (from having silly fun with the LEDs on the units, to 802.1x and WIPS/etc). On Thu, Jan 29, 2015 at 11:22 AM, Paul Nash wrote: > You can also VLAN allocation through RADIUS. Our setup has a single SSID, > 250-odd user accounts. User connects to the SSID & authenticates with > their userid/password and is assigned to their VLAN, which connects them to > the appropriate DHCP server, gateway, etc. > > Makes management and segregation fairly trivial (for non-trivial values of > trivial :-)). > > paul > > > > On Jan 29, 2015, at 11:18 AM, Tyler Mills wrote: > > > > Most of the issues are related to firmware. Most of my UBNT experience > was > > with the UAP-Pro and the UAP-AC, and it wasn't a good experience. > > Production firmwares seem to be of beta quality. > > > > For features, they can't compete with Ruckus. One thing I can think of > off > > the top of my head is support for tagging management on its own VLAN and > > tagging wired traffic onto another. If you were to implement this on the > > UBNT products you would have to SSH into every single one and implement > the > > features as you would on a linux box, and it might work. Ruckus, you > > configure the VLAN's how you would want through the Zonedirector or the > > AP's GUI and it will just work. > > > > They cost more, but you get what you pay for. > > > > On Thu Jan 29 2015 at 10:54:44 AM Mike Hammett wrote: > > > >> Did you figure out why it was dropping out? All of it dropping out? Just > >> some APs dropping? Just some users dropping? > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> > >> > >> ----- Original Message ----- > >> > >> From: "Paul Stewart" > >> To: "Mike Hammett" , nanog at nanog.org > >> Sent: Thursday, January 29, 2015 8:34:46 AM > >> Subject: RE: Recommended wireless AP for 400 users office > >> > >> I had a bad experience with it one time at a tradeshow environment. 6 > >> access points setup for public wifi. The radio levels were quite good in > >> various areas of the tradeshow however traffic would keep dropping out > at > >> random intervals as soon as about 300 users were online. It wasn't my > idea > >> to use UBNT but it definitely turned me off of their product after > digging > >> into their gear... > >> > >> Again as someone pointed out, for residential and perhaps SOHO > >> applications it can probably work well - and in my opinion it's priced > for > >> that market. > >> > >> Paul > >> > >> > >> -----Original Message----- > >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > >> Sent: Thursday, January 29, 2015 8:23 AM > >> To: nanog at nanog.org > >> Subject: Re: Recommended wireless AP for 400 users office > >> > >> What problems have you had with UBNT? > >> > >> It's zero hand-off doesn't work on unsecured networks, but that's about > >> the extent of the issues I've heard of other than stadium density > >> environments. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> > >> > >> ----- Original Message ----- > >> > >> From: "Manuel Marín" > >> To: nanog at nanog.org > >> Sent: Wednesday, January 28, 2015 11:06:39 PM > >> Subject: Recommended wireless AP for 400 users office > >> > >> Dear nanog community > >> > >> I was wondering if you can recommend or share your experience with APs > >> that you can use in locations that have 300-500 users. I friend > recommended > >> me Ruckus Wireless, it would be great if you can share your experience > with > >> Ruckus or with a similar vendor. My experience with ubiquity for this > type > >> of requirement was not that good. > >> > >> Thank you and have a great day > >> > >> > >> > >> > > From eksffa at freebsdbrasil.com.br Thu Jan 29 16:38:05 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Thu, 29 Jan 2015 14:38:05 -0200 Subject: look for BGP routes containing local AS# In-Reply-To: <54C98F0F.9000002@gmail.com> References: <54C79682.9020802@gmail.com> <54C89C8A.2030800@bogus.com> <54C8ACB2.9080505@gmail.com> <54C98F0F.9000002@gmail.com> Message-ID: <728A6171-0AD9-4389-B11A-B92C0E5E2761@freebsdbrasil.com.br> > On 28/01/2015, at 23:38, Song Li wrote: > > Hi Patrick, > > We want to know what's the reason for the received routes containing local ASN. Hence we need real cases of those routes in the Internet. And any routes like that are welcome, whether they are on Juniper router or other BGP software. > > Thank you! > > Regards! OK here you go. 1) Brazil import: Local ASN here: 61894 BGP routing table entry for 177.10.159.0/24 28250 3549 7018 28640 61894 Nexthop 187.1.94.17 (via 187.1.94.17) from Telbrax (187.1.95.241) Origin IGP, metric 0, localpref 100, weight 0, external, best Last update: 20:39:17 ago Communities: 3549:2473 3549:30840 Note that the above route is on my BGP RIB table but will never go into FIB, it’s not marked valid as you can see on a short summary: flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incompleteflags destination gateway lpref med aspath origin 177.10.159.0/24 187.1.94.17 100 0 28250 3549 7018 28640 61894 i It’s lacking * flag (valid). And how the same route when I enable allowas-in: BGP routing table entry for 177.10.159.0/24 28250 3549 7018 28640 61894 Nexthop 187.1.94.17 (via 187.1.94.17) from Telbrax (187.1.95.241) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 20:44:42 ago Communities: 3549:2473 3549:30840 Now you can see “valid, best” and on summary you have *> flags: flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 177.10.159.0/24 187.1.94.17 100 0 28250 3549 7018 28640 61894 i 2) USA import: Local ASN here: 28640 Source ASN here: 61894 (same as local above) BGP routing table entry for 177.10.157.0/24 7018 3549 12989 28640 61894 Nexthop 12.122.120.7 (via 12.222.230.129) from 7018-ATT (12.122.120.7) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 20:59:52 ago As you can guess, due to “valid, best” this routing entry also has allowas-in. 3) USA import: Local ASN here: 28640 Source ASN here: 4.1392 Another sample is for a transit customer in Latin America from the USA perspective: BGP routing table entry for 191.5.130.0/23 7018 3549 12989 28640 4.1392 4.1392 4.1392 4.1392 Nexthop 12.122.120.7 (via 12.222.230.129) from 7018-ATT (12.122.120.7) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 21:21:24 ago I have more samples and scenarios which I can share on private anytime. Here I am using OpenBGP, and first scenario where route is on RIB but never goes on FIB is due to OpenBGP default loop control on route decision engine (RDE.) This is something you can not disable on OpenBGP, so, I had to add this feature to OpenBGP, my patch for it is available here: http://177.10.156.226/~eksffa/l/local-patch-openbgpd-allowas-in.c In the patch header I mention my understanding on how wrong are symptoms where you need to use it, so I will reproduce my understanding: This is a feature that should rarely be needed. Usually the need for this feature suggests something wrong on the current BGP setup. However in some particular setups it's just needed, and can be used without breaking BGP or adding loops. Cisco, Juniper and other BGP routing daemons do offer the same feature, sometimes with explicit control of how many times the AS number is accepted in the as-path. It does not help, the wrong setup will loop anyway Why this is a symptom for something wrong? First, one should not advertise a CIDR prefix on a different location using the same AS number. I know I am doing it wrong and I will fix it, I have a LACNIC assigned ASN, and started a process to get an ARIN assigned ASN. In a couple days I will have my ARIN assigned ASN and I will use it on ARIN locations, so, this scenario will be fixed and I will not see my own ASN in as-path anymore. Other scenarios I have faced, it’s not myself but some customers of mine, on different cities or different neighbors, and they contract independent upstream to the Internet. Say: City1 -> ATT -> Internet City2 -> Level3 -> Internet But city1 and city2 is the same company, and they need to be reached by each other (City1 -> Internet -> City2). What is wrong here is that this setup should have been done on iBGP as a primary option since it’s the same company. But sometimes this is just not possible immediately. Maybe you don’t have that cross connection, and maybe you are doing it right, you DO have an iBGP session but your fiber circuit or wireless circuit comes DOWN for any reason. If you don’t have another backup circuit, City1 will reach City2 via eBGP and therefore the “wrong / unusual” scenario will raise. Maybe a multihop iBGP using eBGP session ("qualify via bgp” on OpenBGP) might be more “correct” from the BGP perspective, but… it’s just the same original problem. The thing is, workarounds like using allowas-in should always be treated as temporary and is a symptom that something is strange, and a good setup should be aimed to stop having your own ASN on a RIB as-path. It’s also very important to notice that this loop prevention mechanism is also a security mechanism. This security mechanism is sometimes used for a good reason by network engineers. Say, if someone start to DDoS you w/ a good DDoS, with forged/spoofed IP addresses etc. I am not able to block by IP, source-as or anything like since I have no reliable information what's the DDoS real source. But with a little help from upstream providers and a few telemetry (flows) we can map the usual as-path for attacking packets to reach me. Therefore you may decide to manipulate your CIDR advertisements and include the AS number that is common path from the attacking vector to me. I confidently rely that when I add someone else’s AS path in my advertisement, this “someone else” will drop the route as a loop prevention when the announcement reaches their router. So, say, if you are attacked from an unknown spoofed source but you can check it is a certain East Europe or Asia or South America or Russian carrier as a common as-path, you can have the effect of blackholing your advertisement on those ASN hops without dealing with BGP communities or other mechanisms that have to be previously agreed and set among peers. So, on the other hand if you, somehow, disable this mechanism, like I just did with allowas-in, you have a potential security problem where someone announcing your CIDR with your ASN or just your ASN somewhere, and this advertisement happens to reach you, You can be victim of attack of different types, ranging from hijacking to other forms of denial of service. So it makes much more urgent the sense that if by any reason you see your own as on prefixes you receive, and you “just need it on FIB”, you must treat it as a temporary configuration and try to get rid of such workaround, getting yourself another ASN or full meshing iBGP among your locations, as the usual first moves to be taken. Regards, -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601 at sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From paul at paulstewart.org Thu Jan 29 16:54:55 2015 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 29 Jan 2015 11:54:55 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> Message-ID: <044601d03be4$4eef9210$ecceb630$@paulstewart.org> It was all users getting randomly disconnected ... the AP's stayed online but the traffic would completely halt for 15-30 seconds at a time. Their association with the AP would stay in tact .... Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 10:53 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Stewart" To: "Mike Hammett" , nanog at nanog.org Sent: Thursday, January 29, 2015 8:34:46 AM Subject: RE: Recommended wireless AP for 400 users office I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 8:23 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From nanog at ics-il.net Thu Jan 29 17:06:11 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 29 Jan 2015 11:06:11 -0600 (CST) Subject: Recommended wireless AP for 400 users office In-Reply-To: <0AA634BD14529B41BB3816DC3D8FD768016F78CD3C@SFCOEX06.lodgenet.com> Message-ID: <19224167.1631.1422551146098.JavaMail.mhammett@ThunderFuck> UniFi, Xirrus, Ruckus. Only WiFi I would deploy anywhere (well, aside from residential). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Jermaine Edwards" To: "Paul Stewart" , "Mike Hammett" , nanog at nanog.org Sent: Thursday, January 29, 2015 11:02:20 AM Subject: RE: Recommended wireless AP for 400 users office Ruckus should work fine for you. You need to have a controller and need a good RF plan but as far as capacity, throughput, roaming etc they are really solid. Of course the best is Cisco but if you can't afford them Ruckus is the way to go. I use them in small and very large convention centers and hotels with no reservation. jle -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart Sent: Thursday, January 29, 2015 11:55 To: 'Mike Hammett'; nanog at nanog.org Subject: RE: Recommended wireless AP for 400 users office It was all users getting randomly disconnected ... the AP's stayed online but the traffic would completely halt for 15-30 seconds at a time. Their association with the AP would stay in tact .... Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 10:53 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Stewart" To: "Mike Hammett" , nanog at nanog.org Sent: Thursday, January 29, 2015 8:34:46 AM Subject: RE: Recommended wireless AP for 400 users office I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 8:23 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From mike.lyon at gmail.com Thu Jan 29 17:07:06 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 29 Jan 2015 09:07:06 -0800 Subject: Recommended wireless AP for 400 users office In-Reply-To: <044601d03be4$4eef9210$ecceb630$@paulstewart.org> References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <044601d03be4$4eef9210$ecceb630$@paulstewart.org> Message-ID: Just curious, were you using WPA2 or were the networks open? Thanks, Mike On Jan 29, 2015 8:56 AM, "Paul Stewart" wrote: > It was all users getting randomly disconnected ... the AP's stayed online > but the traffic would completely halt for 15-30 seconds at a time. Their > association with the AP would stay in tact .... > > Paul > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Thursday, January 29, 2015 10:53 AM > To: nanog at nanog.org > Subject: Re: Recommended wireless AP for 400 users office > > Did you figure out why it was dropping out? All of it dropping out? Just > some APs dropping? Just some users dropping? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Paul Stewart" > To: "Mike Hammett" , nanog at nanog.org > Sent: Thursday, January 29, 2015 8:34:46 AM > Subject: RE: Recommended wireless AP for 400 users office > > I had a bad experience with it one time at a tradeshow environment. 6 > access points setup for public wifi. The radio levels were quite good in > various areas of the tradeshow however traffic would keep dropping out at > random intervals as soon as about 300 users were online. It wasn't my idea > to use UBNT but it definitely turned me off of their product after digging > into their gear... > > Again as someone pointed out, for residential and perhaps SOHO > applications it can probably work well - and in my opinion it's priced for > that market. > > Paul > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Thursday, January 29, 2015 8:23 AM > To: nanog at nanog.org > Subject: Re: Recommended wireless AP for 400 users office > > What problems have you had with UBNT? > > It's zero hand-off doesn't work on unsecured networks, but that's about > the extent of the issues I've heard of other than stadium density > environments. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Manuel Marín" > To: nanog at nanog.org > Sent: Wednesday, January 28, 2015 11:06:39 PM > Subject: Recommended wireless AP for 400 users office > > Dear nanog community > > I was wondering if you can recommend or share your experience with APs > that you can use in locations that have 300-500 users. I friend recommended > me Ruckus Wireless, it would be great if you can share your experience with > Ruckus or with a similar vendor. My experience with ubiquity for this type > of requirement was not that good. > > Thank you and have a great day > > > > > From jared at puck.nether.net Thu Jan 29 17:15:22 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 29 Jan 2015 12:15:22 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <044601d03be4$4eef9210$ecceb630$@paulstewart.org> Message-ID: <3540E225-188C-47A3-AF00-92259A4050E9@puck.nether.net> UBNT just fixed some of this in their latest firmware: http://community.ubnt.com/t5/UniFi-Beta-Blog/UniFi-3-2-10-GA-is-Released-for-Soaking/ba-p/1157252 I’m not saying the UniFi stuff doesn’t leave something to be desired, but in a small deployments i’ve had good luck with them. - Jared > On Jan 29, 2015, at 12:07 PM, Mike Lyon wrote: > > Just curious, were you using WPA2 or were the networks open? > > Thanks, > Mike > On Jan 29, 2015 8:56 AM, "Paul Stewart" wrote: > >> It was all users getting randomly disconnected ... the AP's stayed online >> but the traffic would completely halt for 15-30 seconds at a time. Their >> association with the AP would stay in tact .... >> >> Paul >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >> Sent: Thursday, January 29, 2015 10:53 AM >> To: nanog at nanog.org >> Subject: Re: Recommended wireless AP for 400 users office >> >> Did you figure out why it was dropping out? All of it dropping out? Just >> some APs dropping? Just some users dropping? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Paul Stewart" >> To: "Mike Hammett" , nanog at nanog.org >> Sent: Thursday, January 29, 2015 8:34:46 AM >> Subject: RE: Recommended wireless AP for 400 users office >> >> I had a bad experience with it one time at a tradeshow environment. 6 >> access points setup for public wifi. The radio levels were quite good in >> various areas of the tradeshow however traffic would keep dropping out at >> random intervals as soon as about 300 users were online. It wasn't my idea >> to use UBNT but it definitely turned me off of their product after digging >> into their gear... >> >> Again as someone pointed out, for residential and perhaps SOHO >> applications it can probably work well - and in my opinion it's priced for >> that market. >> >> Paul >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >> Sent: Thursday, January 29, 2015 8:23 AM >> To: nanog at nanog.org >> Subject: Re: Recommended wireless AP for 400 users office >> >> What problems have you had with UBNT? >> >> It's zero hand-off doesn't work on unsecured networks, but that's about >> the extent of the issues I've heard of other than stadium density >> environments. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Manuel Marín" >> To: nanog at nanog.org >> Sent: Wednesday, January 28, 2015 11:06:39 PM >> Subject: Recommended wireless AP for 400 users office >> >> Dear nanog community >> >> I was wondering if you can recommend or share your experience with APs >> that you can use in locations that have 300-500 users. I friend recommended >> me Ruckus Wireless, it would be great if you can share your experience with >> Ruckus or with a similar vendor. My experience with ubiquity for this type >> of requirement was not that good. >> >> Thank you and have a great day >> >> >> >> >> From paul at paulstewart.org Thu Jan 29 17:21:55 2015 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 29 Jan 2015 12:21:55 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <044601d03be4$4eef9210$ecceb630$@paulstewart.org> Message-ID: <002701d03be8$146e9fb0$3d4bdf10$@paulstewart.org> Open – it was just for a trade show setting .. few years ago …. Thanks, Paul From: Mike Lyon [mailto:mike.lyon at gmail.com] Sent: Thursday, January 29, 2015 12:07 PM To: Paul Stewart Cc: Mike Hammett; NANOG Subject: RE: Recommended wireless AP for 400 users office Just curious, were you using WPA2 or were the networks open? Thanks, Mike On Jan 29, 2015 8:56 AM, "Paul Stewart" > wrote: It was all users getting randomly disconnected ... the AP's stayed online but the traffic would completely halt for 15-30 seconds at a time. Their association with the AP would stay in tact .... Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 10:53 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Stewart" > To: "Mike Hammett" >, nanog at nanog.org Sent: Thursday, January 29, 2015 8:34:46 AM Subject: RE: Recommended wireless AP for 400 users office I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 8:23 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" > To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From seth.mos at dds.nl Thu Jan 29 17:45:27 2015 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 29 Jan 2015 18:45:27 +0100 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> Message-ID: <99BE8E2D-C811-4CDF-9C72-09B333867D13@dds.nl> Op 29 jan. 2015, om 17:18 heeft Tyler Mills het volgende geschreven: > Most of the issues are related to firmware. Most of my UBNT experience was > with the UAP-Pro and the UAP-AC, and it wasn't a good experience. > Production firmwares seem to be of beta quality. It’s meh, but it’s good enough. Getting wifi „right” is really hard considering the sheer amount of different hardware, network stacks etc. > For features, they can't compete with Ruckus. One thing I can think of off > the top of my head is support for tagging management on its own VLAN and > tagging wired traffic onto another. If you were to implement this on the > UBNT products you would have to SSH into every single one and implement the > features as you would on a linux box, and it might work. Ruckus, you > configure the VLAN's how you would want through the Zonedirector or the > AP's GUI and it will just work. That’s not true in my experience. Fyi, I just setup a new site here using the Unifi Pro AP’s and I’ve been doing the reverse. Management is untagged, and tag all the traffic VLANs. That works just fine, have been doing that since 2013. The networks are all plain WPA2, but most devices on our wifi seem fine roaming throughout the building without dropping much traffic. The management tool is quite allright, more so when considering the prices and the lack of a subscription model. Really, the subscription models offered for some of the other gear is off the wall. The Unifi gear is by no means bad, but it’s still way better then manually configuring wireless APs without any management. It’s still far better then the 3Com/H3C gear I had before that was 3 times as expensive and still lacks proper english for the management. We have a site with 26 APs, and a new one with 8. You can now manage multiple sites from the same server too. > > They cost more, but you get what you pay for. Yup! Cheers, Seth From clay at bloomcounty.org Thu Jan 29 18:12:23 2015 From: clay at bloomcounty.org (Clay Fiske) Date: Thu, 29 Jan 2015 10:12:23 -0800 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <6D94E2F2-AB8E-4F7E-909D-99EF544D761C@nashnetworks.ca> Message-ID: <3399A5C3-B88A-4A6E-AF04-64DEC4016C7E@bloomcounty.org> Anyone played with/deployed any Mimosa gear? I’m not a “real” wireless guy so I’ll spare folks any armchair speculation. Just looks interesting to me. -c On Jan 29, 2015, at 8:34 AM, Steven Miano wrote: > Another hat that I haven't seen thrown in the ring yet is Aerohive. > > They're great to work with - and the product is decent in terms of > scalability across geographically locations with management being hosted by > them, or you - as/when needed. > > Huge list of features and capabilities (from having silly fun with the LEDs > on the units, to 802.1x and WIPS/etc). > > On Thu, Jan 29, 2015 at 11:22 AM, Paul Nash wrote: > >> You can also VLAN allocation through RADIUS. Our setup has a single SSID, >> 250-odd user accounts. User connects to the SSID & authenticates with >> their userid/password and is assigned to their VLAN, which connects them to >> the appropriate DHCP server, gateway, etc. >> >> Makes management and segregation fairly trivial (for non-trivial values of >> trivial :-)). >> >> paul >> >> >>> On Jan 29, 2015, at 11:18 AM, Tyler Mills wrote: >>> >>> Most of the issues are related to firmware. Most of my UBNT experience >> was >>> with the UAP-Pro and the UAP-AC, and it wasn't a good experience. >>> Production firmwares seem to be of beta quality. >>> >>> For features, they can't compete with Ruckus. One thing I can think of >> off >>> the top of my head is support for tagging management on its own VLAN and >>> tagging wired traffic onto another. If you were to implement this on the >>> UBNT products you would have to SSH into every single one and implement >> the >>> features as you would on a linux box, and it might work. Ruckus, you >>> configure the VLAN's how you would want through the Zonedirector or the >>> AP's GUI and it will just work. >>> >>> They cost more, but you get what you pay for. >>> >>> On Thu Jan 29 2015 at 10:54:44 AM Mike Hammett wrote: >>> >>>> Did you figure out why it was dropping out? All of it dropping out? Just >>>> some APs dropping? Just some users dropping? >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Paul Stewart" >>>> To: "Mike Hammett" , nanog at nanog.org >>>> Sent: Thursday, January 29, 2015 8:34:46 AM >>>> Subject: RE: Recommended wireless AP for 400 users office >>>> >>>> I had a bad experience with it one time at a tradeshow environment. 6 >>>> access points setup for public wifi. The radio levels were quite good in >>>> various areas of the tradeshow however traffic would keep dropping out >> at >>>> random intervals as soon as about 300 users were online. It wasn't my >> idea >>>> to use UBNT but it definitely turned me off of their product after >> digging >>>> into their gear... >>>> >>>> Again as someone pointed out, for residential and perhaps SOHO >>>> applications it can probably work well - and in my opinion it's priced >> for >>>> that market. >>>> >>>> Paul >>>> >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >>>> Sent: Thursday, January 29, 2015 8:23 AM >>>> To: nanog at nanog.org >>>> Subject: Re: Recommended wireless AP for 400 users office >>>> >>>> What problems have you had with UBNT? >>>> >>>> It's zero hand-off doesn't work on unsecured networks, but that's about >>>> the extent of the issues I've heard of other than stadium density >>>> environments. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Manuel Marín" >>>> To: nanog at nanog.org >>>> Sent: Wednesday, January 28, 2015 11:06:39 PM >>>> Subject: Recommended wireless AP for 400 users office >>>> >>>> Dear nanog community >>>> >>>> I was wondering if you can recommend or share your experience with APs >>>> that you can use in locations that have 300-500 users. I friend >> recommended >>>> me Ruckus Wireless, it would be great if you can share your experience >> with >>>> Ruckus or with a similar vendor. My experience with ubiquity for this >> type >>>> of requirement was not that good. >>>> >>>> Thank you and have a great day >>>> >>>> >>>> >>>> >> >> > > From nanog at ics-il.net Thu Jan 29 18:15:33 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 29 Jan 2015 12:15:33 -0600 (CST) Subject: Recommended wireless AP for 400 users office In-Reply-To: <3399A5C3-B88A-4A6E-AF04-64DEC4016C7E@bloomcounty.org> Message-ID: <32487496.1925.1422555302120.JavaMail.mhammett@ThunderFuck> Thus far only available for backhaul, but they're looking pretty good from the reports I've read. There will be a webinar in about an hour. http://mimosa.co/webinar ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Clay Fiske" To: "NANOG" Sent: Thursday, January 29, 2015 12:12:23 PM Subject: Re: Recommended wireless AP for 400 users office Anyone played with/deployed any Mimosa gear? I’m not a “real” wireless guy so I’ll spare folks any armchair speculation. Just looks interesting to me. -c On Jan 29, 2015, at 8:34 AM, Steven Miano wrote: > Another hat that I haven't seen thrown in the ring yet is Aerohive. > > They're great to work with - and the product is decent in terms of > scalability across geographically locations with management being hosted by > them, or you - as/when needed. > > Huge list of features and capabilities (from having silly fun with the LEDs > on the units, to 802.1x and WIPS/etc). > > On Thu, Jan 29, 2015 at 11:22 AM, Paul Nash wrote: > >> You can also VLAN allocation through RADIUS. Our setup has a single SSID, >> 250-odd user accounts. User connects to the SSID & authenticates with >> their userid/password and is assigned to their VLAN, which connects them to >> the appropriate DHCP server, gateway, etc. >> >> Makes management and segregation fairly trivial (for non-trivial values of >> trivial :-)). >> >> paul >> >> >>> On Jan 29, 2015, at 11:18 AM, Tyler Mills wrote: >>> >>> Most of the issues are related to firmware. Most of my UBNT experience >> was >>> with the UAP-Pro and the UAP-AC, and it wasn't a good experience. >>> Production firmwares seem to be of beta quality. >>> >>> For features, they can't compete with Ruckus. One thing I can think of >> off >>> the top of my head is support for tagging management on its own VLAN and >>> tagging wired traffic onto another. If you were to implement this on the >>> UBNT products you would have to SSH into every single one and implement >> the >>> features as you would on a linux box, and it might work. Ruckus, you >>> configure the VLAN's how you would want through the Zonedirector or the >>> AP's GUI and it will just work. >>> >>> They cost more, but you get what you pay for. >>> >>> On Thu Jan 29 2015 at 10:54:44 AM Mike Hammett wrote: >>> >>>> Did you figure out why it was dropping out? All of it dropping out? Just >>>> some APs dropping? Just some users dropping? >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Paul Stewart" >>>> To: "Mike Hammett" , nanog at nanog.org >>>> Sent: Thursday, January 29, 2015 8:34:46 AM >>>> Subject: RE: Recommended wireless AP for 400 users office >>>> >>>> I had a bad experience with it one time at a tradeshow environment. 6 >>>> access points setup for public wifi. The radio levels were quite good in >>>> various areas of the tradeshow however traffic would keep dropping out >> at >>>> random intervals as soon as about 300 users were online. It wasn't my >> idea >>>> to use UBNT but it definitely turned me off of their product after >> digging >>>> into their gear... >>>> >>>> Again as someone pointed out, for residential and perhaps SOHO >>>> applications it can probably work well - and in my opinion it's priced >> for >>>> that market. >>>> >>>> Paul >>>> >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett >>>> Sent: Thursday, January 29, 2015 8:23 AM >>>> To: nanog at nanog.org >>>> Subject: Re: Recommended wireless AP for 400 users office >>>> >>>> What problems have you had with UBNT? >>>> >>>> It's zero hand-off doesn't work on unsecured networks, but that's about >>>> the extent of the issues I've heard of other than stadium density >>>> environments. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Manuel Marín" >>>> To: nanog at nanog.org >>>> Sent: Wednesday, January 28, 2015 11:06:39 PM >>>> Subject: Recommended wireless AP for 400 users office >>>> >>>> Dear nanog community >>>> >>>> I was wondering if you can recommend or share your experience with APs >>>> that you can use in locations that have 300-500 users. I friend >> recommended >>>> me Ruckus Wireless, it would be great if you can share your experience >> with >>>> Ruckus or with a similar vendor. My experience with ubiquity for this >> type >>>> of requirement was not that good. >>>> >>>> Thank you and have a great day >>>> >>>> >>>> >>>> >> >> > > From mike.lyon at gmail.com Thu Jan 29 18:17:23 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 29 Jan 2015 10:17:23 -0800 Subject: Recommended wireless AP for 400 users office In-Reply-To: <3399A5C3-B88A-4A6E-AF04-64DEC4016C7E@bloomcounty.org> References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <6D94E2F2-AB8E-4F7E-909D-99EF544D761C@nashnetworks.ca> <3399A5C3-B88A-4A6E-AF04-64DEC4016C7E@bloomcounty.org> Message-ID: If all goes well, my Mimosa gear should be arriving this week :) -Mike On Thu, Jan 29, 2015 at 10:12 AM, Clay Fiske wrote: > Anyone played with/deployed any Mimosa gear? I’m not a “real” wireless guy > so I’ll spare folks any armchair speculation. Just looks interesting to me. > > -c > > > On Jan 29, 2015, at 8:34 AM, Steven Miano wrote: > > > Another hat that I haven't seen thrown in the ring yet is Aerohive. > > > > They're great to work with - and the product is decent in terms of > > scalability across geographically locations with management being hosted > by > > them, or you - as/when needed. > > > > Huge list of features and capabilities (from having silly fun with the > LEDs > > on the units, to 802.1x and WIPS/etc). > > > > On Thu, Jan 29, 2015 at 11:22 AM, Paul Nash > wrote: > > > >> You can also VLAN allocation through RADIUS. Our setup has a single > SSID, > >> 250-odd user accounts. User connects to the SSID & authenticates with > >> their userid/password and is assigned to their VLAN, which connects > them to > >> the appropriate DHCP server, gateway, etc. > >> > >> Makes management and segregation fairly trivial (for non-trivial values > of > >> trivial :-)). > >> > >> paul > >> > >> > >>> On Jan 29, 2015, at 11:18 AM, Tyler Mills > wrote: > >>> > >>> Most of the issues are related to firmware. Most of my UBNT experience > >> was > >>> with the UAP-Pro and the UAP-AC, and it wasn't a good experience. > >>> Production firmwares seem to be of beta quality. > >>> > >>> For features, they can't compete with Ruckus. One thing I can think of > >> off > >>> the top of my head is support for tagging management on its own VLAN > and > >>> tagging wired traffic onto another. If you were to implement this on > the > >>> UBNT products you would have to SSH into every single one and implement > >> the > >>> features as you would on a linux box, and it might work. Ruckus, you > >>> configure the VLAN's how you would want through the Zonedirector or the > >>> AP's GUI and it will just work. > >>> > >>> They cost more, but you get what you pay for. > >>> > >>> On Thu Jan 29 2015 at 10:54:44 AM Mike Hammett > wrote: > >>> > >>>> Did you figure out why it was dropping out? All of it dropping out? > Just > >>>> some APs dropping? Just some users dropping? > >>>> > >>>> > >>>> > >>>> > >>>> ----- > >>>> Mike Hammett > >>>> Intelligent Computing Solutions > >>>> http://www.ics-il.com > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> > >>>> From: "Paul Stewart" > >>>> To: "Mike Hammett" , nanog at nanog.org > >>>> Sent: Thursday, January 29, 2015 8:34:46 AM > >>>> Subject: RE: Recommended wireless AP for 400 users office > >>>> > >>>> I had a bad experience with it one time at a tradeshow environment. 6 > >>>> access points setup for public wifi. The radio levels were quite good > in > >>>> various areas of the tradeshow however traffic would keep dropping out > >> at > >>>> random intervals as soon as about 300 users were online. It wasn't my > >> idea > >>>> to use UBNT but it definitely turned me off of their product after > >> digging > >>>> into their gear... > >>>> > >>>> Again as someone pointed out, for residential and perhaps SOHO > >>>> applications it can probably work well - and in my opinion it's priced > >> for > >>>> that market. > >>>> > >>>> Paul > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike > Hammett > >>>> Sent: Thursday, January 29, 2015 8:23 AM > >>>> To: nanog at nanog.org > >>>> Subject: Re: Recommended wireless AP for 400 users office > >>>> > >>>> What problems have you had with UBNT? > >>>> > >>>> It's zero hand-off doesn't work on unsecured networks, but that's > about > >>>> the extent of the issues I've heard of other than stadium density > >>>> environments. > >>>> > >>>> > >>>> > >>>> > >>>> ----- > >>>> Mike Hammett > >>>> Intelligent Computing Solutions > >>>> http://www.ics-il.com > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> > >>>> From: "Manuel Marín" > >>>> To: nanog at nanog.org > >>>> Sent: Wednesday, January 28, 2015 11:06:39 PM > >>>> Subject: Recommended wireless AP for 400 users office > >>>> > >>>> Dear nanog community > >>>> > >>>> I was wondering if you can recommend or share your experience with APs > >>>> that you can use in locations that have 300-500 users. I friend > >> recommended > >>>> me Ruckus Wireless, it would be great if you can share your experience > >> with > >>>> Ruckus or with a similar vendor. My experience with ubiquity for this > >> type > >>>> of requirement was not that good. > >>>> > >>>> Thank you and have a great day > >>>> > >>>> > >>>> > >>>> > >> > >> > > > > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From ccosta at gaikai.com Thu Jan 29 19:03:56 2015 From: ccosta at gaikai.com (Christopher Costa) Date: Thu, 29 Jan 2015 11:03:56 -0800 Subject: Requesting Consolidated Communications (AS5742) contact Message-ID: Requesting a Consolidated Communications (AS5742) engineer contact me regarding routing in Illinois region towards Gaikai (AS33353). Thank you, Chris Costa Gaikai ccosta at gaikai.com From sean at seanharlow.info Thu Jan 29 19:50:20 2015 From: sean at seanharlow.info (Sean Harlow) Date: Thu, 29 Jan 2015 14:50:20 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> Message-ID: I have had this same behavior at my UniFi pilot site. What I discovered in my case was a combination of bad behaviors in both the UniFi unit and Android. Long story short Android really wants to hang on to a WiFi signal as long as it can and does not seemingly scan for other signals when connected. If it sees even the slightest bit of a signal from the access point it's connected to it doesn't give it up. I can replicate this behavior on every Android device I have where I can walk across a building and pass through 2-3 other "cells", even others on the same channel, and still see my device connected to the AP I started on in the UniFi control panel until it completely loses signal. This behavior then interacts poorly with UniFi in that it seems to be very willing to keep trying to get the data through to the distant client and queues up everything else until it either succeeds or possibly times out. Presumably if ZHR worked this would effectively work around the issue, but as already noted it has its own issues that reduce its utility in a crowded environment. Our solution has been to stop using the "Long Range" units and install more small cells to minimize the impacted area if this does occur, plus ensure that any Android devices are set to sleep their WiFi when the display is off (this is often set by default). The customer we were testing with had a few tablets that needed to be on most of the time, but they switched to Windows devices for unrelated reasons and basically eliminated the problem. There is apparently some way to have the APs drop clients that are below a certain signal threshold now, but I haven't looked in to it in a while as it hasn't really been an issue. --- Overall my experience with UniFi is positive, if you have relatively simple needs they'll usually get the job done. You'll probably need a few more access points than you would with another solution, but they're generally a fraction of the price so it still often works out. If you need your wireless to get fancy or handle a high number of clients on a single AP look elsewhere. Needing to work on 5GHz also changes the value equation as those units are significantly more expensive than the plain 2.4GHz 802.11n units. On Thu, Jan 29, 2015 at 10:53 AM, Mike Hammett wrote: > Did you figure out why it was dropping out? All of it dropping out? Just > some APs dropping? Just some users dropping? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Paul Stewart" > To: "Mike Hammett" , nanog at nanog.org > Sent: Thursday, January 29, 2015 8:34:46 AM > Subject: RE: Recommended wireless AP for 400 users office > > I had a bad experience with it one time at a tradeshow environment. 6 > access points setup for public wifi. The radio levels were quite good in > various areas of the tradeshow however traffic would keep dropping out at > random intervals as soon as about 300 users were online. It wasn't my idea > to use UBNT but it definitely turned me off of their product after digging > into their gear... > > Again as someone pointed out, for residential and perhaps SOHO > applications it can probably work well - and in my opinion it's priced for > that market. > > Paul > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Thursday, January 29, 2015 8:23 AM > To: nanog at nanog.org > Subject: Re: Recommended wireless AP for 400 users office > > What problems have you had with UBNT? > > It's zero hand-off doesn't work on unsecured networks, but that's about > the extent of the issues I've heard of other than stadium density > environments. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Manuel Marín" > To: nanog at nanog.org > Sent: Wednesday, January 28, 2015 11:06:39 PM > Subject: Recommended wireless AP for 400 users office > > Dear nanog community > > I was wondering if you can recommend or share your experience with APs > that you can use in locations that have 300-500 users. I friend recommended > me Ruckus Wireless, it would be great if you can share your experience with > Ruckus or with a similar vendor. My experience with ubiquity for this type > of requirement was not that good. > > Thank you and have a great day > > > > From nanog at ics-il.net Thu Jan 29 19:57:08 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 29 Jan 2015 13:57:08 -0600 (CST) Subject: Recommended wireless AP for 400 users office In-Reply-To: Message-ID: <13255767.2314.1422561386919.JavaMail.mhammett@ThunderFuck> They should have never made the LR models. Louder radios don't work with today's mobile clients. It's antenna or nothing. The pricing is old as well. It hasn't changed since it debuted. A platform that manages handoffs would mitigate that issue. Mobile devices really suck in that regard. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Sean Harlow" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, January 29, 2015 1:50:20 PM Subject: Re: Recommended wireless AP for 400 users office I have had this same behavior at my UniFi pilot site. What I discovered in my case was a combination of bad behaviors in both the UniFi unit and Android. Long story short Android really wants to hang on to a WiFi signal as long as it can and does not seemingly scan for other signals when connected. If it sees even the slightest bit of a signal from the access point it's connected to it doesn't give it up. I can replicate this behavior on every Android device I have where I can walk across a building and pass through 2-3 other "cells", even others on the same channel, and still see my device connected to the AP I started on in the UniFi control panel until it completely loses signal. This behavior then interacts poorly with UniFi in that it seems to be very willing to keep trying to get the data through to the distant client and queues up everything else until it either succeeds or possibly times out. Presumably if ZHR worked this would effectively work around the issue, but as already noted it has its own issues that reduce its utility in a crowded environment. Our solution has been to stop using the "Long Range" units and install more small cells to minimize the impacted area if this does occur, plus ensure that any Android devices are set to sleep their WiFi when the display is off (this is often set by default). The customer we were testing with had a few tablets that needed to be on most of the time, but they switched to Windows devices for unrelated reasons and basically eliminated the problem. There is apparently some way to have the APs drop clients that are below a certain signal threshold now, but I haven't looked in to it in a while as it hasn't really been an issue. --- Overall my experience with UniFi is positive, if you have relatively simple needs they'll usually get the job done. You'll probably need a few more access points than you would with another solution, but they're generally a fraction of the price so it still often works out. If you need your wireless to get fancy or handle a high number of clients on a single AP look elsewhere. Needing to work on 5GHz also changes the value equation as those units are significantly more expensive than the plain 2.4GHz 802.11n units. On Thu, Jan 29, 2015 at 10:53 AM, Mike Hammett < nanog at ics-il.net > wrote: Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Stewart" < paul at paulstewart.org > To: "Mike Hammett" < nanog at ics-il.net >, nanog at nanog.org Sent: Thursday, January 29, 2015 8:34:46 AM Subject: RE: Recommended wireless AP for 400 users office I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. Paul -----Original Message----- From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 8:23 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" < mmg at transtelco.net > To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From jared at puck.nether.net Thu Jan 29 20:08:18 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 29 Jan 2015 15:08:18 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: <13255767.2314.1422561386919.JavaMail.mhammett@ThunderFuck> References: <13255767.2314.1422561386919.JavaMail.mhammett@ThunderFuck> Message-ID: <95B2B4FA-C4A6-4F08-ABC0-9880EDB374C0@puck.nether.net> You can manually adjust the UAP radios to reject clients, but things like the LR are really only useful in an outdoor setting, or environments that have sparse clients. https://community.ubnt.com/t5/UniFi-Configuration-Examples/UniFi-Set-minimum-RSSI-for-clients/ta-p/522637 It’s really an ugly hack and I wish they would allow it to be set under the site or AP. For my home environment, my iPhone thinks it can see the AP up to 1/4 of a mile away with a normal UAP-PRO, which is not really the case as the client doesn’t notice the signal fade as quickly as one would expect. - Jared > On Jan 29, 2015, at 2:57 PM, Mike Hammett wrote: > > They should have never made the LR models. Louder radios don't work with today's mobile clients. It's antenna or nothing. > > The pricing is old as well. It hasn't changed since it debuted. > > A platform that manages handoffs would mitigate that issue. Mobile devices really suck in that regard. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Sean Harlow" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Thursday, January 29, 2015 1:50:20 PM > Subject: Re: Recommended wireless AP for 400 users office > > > I have had this same behavior at my UniFi pilot site. What I discovered in my case was a combination of bad behaviors in both the UniFi unit and Android. > > > > Long story short Android really wants to hang on to a WiFi signal as long as it can and does not seemingly scan for other signals when connected. If it sees even the slightest bit of a signal from the access point it's connected to it doesn't give it up. I can replicate this behavior on every Android device I have where I can walk across a building and pass through 2-3 other "cells", even others on the same channel, and still see my device connected to the AP I started on in the UniFi control panel until it completely loses signal. > > > This behavior then interacts poorly with UniFi in that it seems to be very willing to keep trying to get the data through to the distant client and queues up everything else until it either succeeds or possibly times out. > > > Presumably if ZHR worked this would effectively work around the issue, but as already noted it has its own issues that reduce its utility in a crowded environment. Our solution has been to stop using the "Long Range" units and install more small cells to minimize the impacted area if this does occur, plus ensure that any Android devices are set to sleep their WiFi when the display is off (this is often set by default). The customer we were testing with had a few tablets that needed to be on most of the time, but they switched to Windows devices for unrelated reasons and basically eliminated the problem. > > > There is apparently some way to have the APs drop clients that are below a certain signal threshold now, but I haven't looked in to it in a while as it hasn't really been an issue. > > > --- > > > Overall my experience with UniFi is positive, if you have relatively simple needs they'll usually get the job done. You'll probably need a few more access points than you would with another solution, but they're generally a fraction of the price so it still often works out. If you need your wireless to get fancy or handle a high number of clients on a single AP look elsewhere. Needing to work on 5GHz also changes the value equation as those units are significantly more expensive than the plain 2.4GHz 802.11n units. > > > On Thu, Jan 29, 2015 at 10:53 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Paul Stewart" < paul at paulstewart.org > > To: "Mike Hammett" < nanog at ics-il.net >, nanog at nanog.org > Sent: Thursday, January 29, 2015 8:34:46 AM > Subject: RE: Recommended wireless AP for 400 users office > > > > I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... > > Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. > > Paul > > > -----Original Message----- > From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Mike Hammett > Sent: Thursday, January 29, 2015 8:23 AM > To: nanog at nanog.org > Subject: Re: Recommended wireless AP for 400 users office > > What problems have you had with UBNT? > > It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Manuel Marín" < mmg at transtelco.net > > To: nanog at nanog.org > Sent: Wednesday, January 28, 2015 11:06:39 PM > Subject: Recommended wireless AP for 400 users office > > Dear nanog community > > I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. > > Thank you and have a great day > > > > > > > From rps at maine.edu Thu Jan 29 21:56:27 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 29 Jan 2015 16:56:27 -0500 Subject: scaling linux-based router hardware recommendations In-Reply-To: References: <87vbjt6tml.fsf@muck.riseup.net> Message-ID: "For us, open source isn't just a business model; it's smart engineering practice." -- Bruce Schneier I hope I'm not the only one, but I think the NSA (and other state actors) intentionally introducing systemic weaknesses or backdoors into critical infrastructure is pretty ... reckless. I really can't figure out if it's arrogance or just plain naivety on their part, but they seem pretty confident that the information won't ever fall into the wrong hands and keep pushing forward. So for me, this is an area I've very interested in seeing some progress. I think most people don't realize that if you only care about 1G performance levels, commodity hardware can be more than fine. Linux netfilter makes a really great firewall, and it's the most peer-reviewed in the world. On Wed, Jan 28, 2015 at 6:18 PM, Adrian Chadd wrote: > [snip] > > To inject science into the discussion: > > http://bsdrp.net/documentation/examples/forwarding_performance_lab_of_an_ibm_system_x3550_m3_with_10-gigabit_intel_x540-at2 > > And he maintains a test setup to check for performance regressions: > > http://bsdrp.net/documentation/examples/freebsd_performance_regression_lab > > Now, this is using the in-kernel stack, not netmap/pfring/etc that > uses all the batching-y, stack-shallow-y implementations that the > kernel currently doesn't have. But, there are people out there doing > science on it and trying very hard to kick things along. The nice > thing about what has come out of the DPDK related stuff is, well, the > bar is set very high now. Now it's up to the open source groups to > stop messing around and do something about it. > > > If you're interested in more of this stuff, go poke Jim at pfsense/netgate. > > > -adrian > (This and RSS work is plainly in my "stuff I do for fun" category, btw.) -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From grizz at dipd.com Thu Jan 29 23:15:55 2015 From: grizz at dipd.com (Matt Griswold) Date: Thu, 29 Jan 2015 23:15:55 +0000 Subject: Call For Presentations Open-IX AIS-1, deadline 2015-03-01 Message-ID: <20150129231555.01777957@x0r> Call For Presentations Open-IX Association Americas Interconnection Summit The Americas Interconnection Summit is an annual, open, event where Internet Service Providers, network operators, Internet Exchange Points, Data Center Operators and other interested parties get together to plan interconnection of networks and discuss issues affecting interconnection overall. AIS-1 will take place at the Westin Gaslamp Quarter Hotel from April 7, 2015 through April 9, 2015 in San Diego, CA. The AIS Program Committee “PC” is seeking presentation proposals on relevant topics primarily related to Interconnection strategy, including but not limited to: - Physical layer Interconnection - WDM management - IP or Ethernet Interconnection - Interconnection Automation - Mobile Data Exchange - Interconnection and Peering Internet Governance and Regulatory Topics - Economic and Product Trends; Infrastructure Procurement - Cloud Interconnection - Peering/Interconnection Strategy # Submissions AIS requires presentations to be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged.   Submissions of  presentations should be made to the PC , please include: - Author's name(s) - Presentation title - Abstract - Slides (if available) - Time requested # Deadlines Presentation Abstract Deadline March 1st, 2015 Presentation Slides Submission Deadline March 15th, 2015 Final Selection of Speakers March 16th, 2015 From oregon.wolfy at gmail.com Fri Jan 30 01:50:20 2015 From: oregon.wolfy at gmail.com (Pete Hanson) Date: Fri, 30 Jan 2015 01:50:20 +0000 (UTC) Subject: Need abuse/postmaster contact for AT&T References: Message-ID: Matthew Black csulb.edu> writes: > > Our university just received notice from AT&T that our e-mail is being blocked without much explanation. > As all universities send e-mail to the students and employees, it is impossible to tell what triggered > AT&T's actions. > > Does anyone have an AT&T contact? If you are from AT&T, please contact me off-line. > > Thanks. > > matthew black > e-mail postmaster > california state university, long beach > > > -----Original Message----- > From: test_reply att.net [mailto:test_reply att.net] > Sent: Wednesday, January 28, 2015 4:58 PM > Subject: Blocked Email Notification > > Dear Postmaster: > > We are writing to let you know that we are blocking messages addressed to one of our customers at the domain > att.net by one of your customers at domain csulb.edu. The stream of messages coming from your system > appears to consist mostly of unwanted commercial e-mail (UCE, or "spam"). To protect our system and to > ensure that it operates well for all of our customers, we have decided to block all messages originating > from your system. > > Please consult your logs to see what might be causing this situation and how it can be fixed. Then visit > http://rbl.att.net/block_inquiry.html to request a removal of the block. Most requests for removal > are honored within two days. > > The specific error message received by your customer was: > 550 Error - Blocked for abuse. See http://att.net/blocks > > Thank you for your assistance in helping our respective customers communicate. > > Best regards, > > The AT&T Mail Team. > I'm seeing the same blockage on the site that I run, including those servers that never send email. I suspect that are using the AHBL DNSBL which recently shutdown and started responding with positives to all lookups. From sam at themerritts.org Fri Jan 30 02:56:50 2015 From: sam at themerritts.org (Sam Hayes Merritt, III) Date: Thu, 29 Jan 2015 20:56:50 -0600 (CST) Subject: cable modem firmware upgrade In-Reply-To: <011701d03bad$86476030$92d62090$@paulstewart.org> References: <000501d03b79$942070e0$bc6152a0$@ca> <011701d03bad$86476030$92d62090$@paulstewart.org> Message-ID: > That has been my experience as well (only from the RF side) and I would > believe this was a design choice. The ISP usually wants to keep control > over the firmware versions of the CM for various technical/support reasons > versus having consumers mess with the firmware. Its a design choice but not one that always works out well. Customers that bring their own modems that aren't on a "certified" list, end up with a device that the provider may not have ever seen. Then, if you run into an issue with the modem that can be fixed with a firmware issue (some vendors have issues that they cannot fix - rhymes with netgear) then the MSO has to work with the maker of that modem, even though they may have never had any interactions with them, get the certificate and firmware for that modem and upgrade customer owned devices - possibly turning them into bricks. I'd rather allow customers to turn their own modems into bricks. sam From rs at seastrom.com Fri Jan 30 11:44:55 2015 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 30 Jan 2015 06:44:55 -0500 Subject: PDU for high amp 48Vdc In-Reply-To: <9FA96721-C9DF-4823-ACFC-799272D40624@pch.net> (Bill Woodcock's message of "Wed, 28 Jan 2015 19:21:25 -0800") References: <54C99D18.5070907@direcpath.com> <9FA96721-C9DF-4823-ACFC-799272D40624@pch.net> Message-ID: <86oapgjxvs.fsf@valhalla.seastrom.com> None of the stuff you'll make has UL or NEBS approval unless you pay for that. I'd be inclined to suck it up and pay for remote hands to turn a switch unless you own the colo or they're casual enough that they don't care (your insurance company might though). Should you decide to go ahead and build, be sure to check the DC rating vs. AC rating for break under load - AC arcs are a lot more self-extinguishing than DC arcs are. Consider a snubber (resistor and capacitor in series across the contacts) in your design to minimize arcing. More on AC vs DC here: http://www.temcoindustrialpower.com/product_selection.html?p=ac_vs_dc_contactor For context, my Lincoln IM206 arc welder can be dialed down as low as 30 amps, and will have an open circuit voltage of way under 48 volts when it's set that low (no, I don't feel motivated enough this early in the morning to go fire it up and stick a voltmeter on it). -r "Bill Woodcock" writes: > The rotary actuators are an off-the-shelf item for transfer switches. No problem to get them paired with high-amperage switches. But a contactor, which is a solenoid-driven switch, is also an off-the-shelf item. The ones I use in EV applications are rated for 1000A, and cost about $300. You need to be careful to look at the trade-off between voltage, amperage, and the per-cycle probability of a weld, though. An over-rated contactor helps a lot if you're going to be cycling it a lot, whereas if it's for emergency use only, you can hew a lot closer to the max rating. > > > -Bill > > >> On Jan 28, 2015, at 18:40, Robert Drake wrote: >> >> For larger DC devices with ~50amps per side, does anyone have a software accessible way to turn off power? >> >> I've looked into PDU's but the ones I find have a max of 10amps. >> >> I've considered building something with solenoids or a rotary actuator that would turn the switches on or off, but that's a complete one-off and would need to be done for each device we manage (not to mention it involves janky wiring all over the place I've got to explain to the colo) >> >> My use case is pretty infrequent so it needs to be remote-hands cheap.. it's for emergencies when you need to completely power cycle a redundantly powered DC device. The last time I needed this it was because a router was stuck in a boot loop due to a bad IOS upgrade and wouldn't break to rommon since it had been >60 seconds. It came up again tonight because we wanted to disable one power supply to troubleshoot something. >> >> FWIW, I believe I've seen newer Cisco gear with high-end power supplies that have a console or ethernet port which would possibly let you shut them down remotely. That solves the problem nicely if you're dealing with only one bit of hardware, but I'd like a general solution that worked with any vendor. Possibly a fuse panel with solenoids that could add/remove fuses when needed.. or would that be considered dangerous in code-ways or in telco fire regulation ways? >> >> >> >> From rs at seastrom.com Fri Jan 30 11:48:38 2015 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 30 Jan 2015 06:48:38 -0500 Subject: cable modem firmware upgrade In-Reply-To: <011701d03bad$86476030$92d62090$@paulstewart.org> (Paul Stewart's message of "Thu, 29 Jan 2015 05:22:44 -0500") References: <000501d03b79$942070e0$bc6152a0$@ca> <011701d03bad$86476030$92d62090$@paulstewart.org> Message-ID: <86k304jxpl.fsf@valhalla.seastrom.com> "Paul Stewart" writes: > That has been my experience as well (only from the RF side) and I would > believe this was a design choice. The ISP usually wants to keep control > over the firmware versions of the CM for various technical/support reasons > versus having consumers mess with the firmware. 15 years ago, in certain circles it was well-understood how to load one's own (possibly patched) software from the Ethernet side on the old LanCity (pre-DOCSIS) cablemodems. You can imagine what kind of hilarity ensued. -r From rs at seastrom.com Fri Jan 30 12:07:10 2015 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 30 Jan 2015 07:07:10 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: (Manuel =?iso-8859-1?Q?Mar=C3=ADn's?= message of "Wed, 28 Jan 2015 22:06:39 -0700") References: Message-ID: <86fvasjwup.fsf@valhalla.seastrom.com> Manuel Marín writes: > I was wondering if you can recommend or share your experience with APs that > you can use in locations that have 300-500 users. I friend recommended me > Ruckus Wireless, it would be great if you can share your experience with > Ruckus or with a similar vendor. My experience with ubiquity for this type > of requirement was not that good. I have had a pair of Ruckus R700s at the house for a short while now (hey, they haven't been out that long). They work fine without a controller, at least in WPA2-PSK mode with a few VLANs. Haven't seen if Enterprise works without the controller or not, so if you care you might want to check. For an annual fee, Ruckus offers a "cloud controller" too as opposed to their physical box controllers; this is worthy of consideration depending upon your situation. Software upgrades were pretty straightforward. The R700 has a CLI, but I haven't tried doing anything particular with it so I can't offer any thoughts there. Those running with a controller (the "expected" mode of operation) will never touch the individual APs anyway, so I'd expect the CLI might be a little disappointing. The web UI is thoughtfully laid out and was easy to use. Management VLAN can be separate from the customer traffic VLANs and they work fine with my slightly demented mix of tagged/untagged traffic. The caveat here is that if you were thinking of just tossing everything in one VLAN without any separation whatsoever, there doesn't seem to be a good way to filter access to the management interface. Then again, it's https/ssh (http and telnet are available but off by default, hooray!) so you may not care. The sshd and web server are dropbear and GoAhead-Webs respectively. Overall I've found the R700s very stable and been pleased with them. They're a bit spendy, but you absolutely get what you pay for. At the other end of the spectrum is the Ubiquiti and Mikrotik kit, which I also love, but for a completely different use case and budget. I would recommend Ruckus without hesitation. My $0.02. -r From khelms at zcorum.com Fri Jan 30 13:18:39 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 30 Jan 2015 08:18:39 -0500 Subject: cable modem firmware upgrade In-Reply-To: References: <000501d03b79$942070e0$bc6152a0$@ca> <011701d03bad$86476030$92d62090$@paulstewart.org> Message-ID: Sam, The most common approach from the MSOs is to take one of two paths. Either simply not allow non-approved devices to come online, this is common from the larger MSOs, or to simply not try and update the firmware for unfamiliar devices, this is common for smaller operators. It's very unusual for a MSO to work with an unapproved vendor simply because they almost never have enough of their own customers using those devices to make the effort worthwhile *and *most of the direct to consumer vendors stop producing firmware updates on a much quicker pace than service provider gear vendors do. A direct to consumer device will often get <3 firmware updates total, while the devices sold to/through service providers are supported for much longer and I can commonly get firmware updates for devices that are 8+ years old. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jan 29, 2015 at 9:56 PM, Sam Hayes Merritt, III wrote: > > That has been my experience as well (only from the RF side) and I would >> believe this was a design choice. The ISP usually wants to keep control >> over the firmware versions of the CM for various technical/support reasons >> versus having consumers mess with the firmware. >> > > Its a design choice but not one that always works out well. > > Customers that bring their own modems that aren't on a "certified" list, > end up with a device that the provider may not have ever seen. Then, if you > run into an issue with the modem that can be fixed with a firmware issue > (some vendors have issues that they cannot fix - rhymes with netgear) then > the MSO has to work with the maker of that modem, even though they may have > never had any interactions with them, get the certificate and firmware for > that modem and upgrade customer owned devices - possibly turning them into > bricks. I'd rather allow customers to turn their own modems into bricks. > > > sam > From Valdis.Kletnieks at vt.edu Fri Jan 30 13:36:25 2015 From: Valdis.Kletnieks at vt.edu (Valdis Kletnieks) Date: Fri, 30 Jan 2015 08:36:25 -0500 Subject: Now that's an odd failure mode... Message-ID: <33795.1422624985@turing-police.cc.vt.edu> Lauren Weinstein shared a pointer to this video of one of the stranger failure modes I've ever seen..... https://www.youtube.com/watch?v=cZkAP-CQlhA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From elouie at techintegrity.com Thu Jan 29 23:28:58 2015 From: elouie at techintegrity.com (Eric Louie) Date: Thu, 29 Jan 2015 15:28:58 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion Message-ID: I'm putting together my first IPv6 allocation plan. The general layout: /48 for customers universally and uniformly /38 for larger regions on an even (/37) boundary /39 for smaller regions on an even (/38) boundary A few /48's for "internal use" to allow us to monitor and maintain systems. For security sake, do I need (am I better off) to "reserve" a "management block" (/39, /40, /41 or something of that nature) that does NOT get advertised into BGP to my upstreams, and use that for my device management and monitoring address space? In other words, make a small "private" address space for management? What are folks doing around that? If I have to do 6-to-4 conversion, is there any way to do that with multiple diverse ISP connections, or am I "restricted" to using one entry/exit point? (If that's true, do I need to allocate a separate block of addresses that would be designated "6 to 4" so they'd always be routed out that one entry/exit point?) From JEdwards at sonifi.com Thu Jan 29 17:02:20 2015 From: JEdwards at sonifi.com (Edwards, Jermaine) Date: Thu, 29 Jan 2015 17:02:20 +0000 Subject: Recommended wireless AP for 400 users office In-Reply-To: <044601d03be4$4eef9210$ecceb630$@paulstewart.org> References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <044601d03be4$4eef9210$ecceb630$@paulstewart.org> Message-ID: <0AA634BD14529B41BB3816DC3D8FD768016F78CD3C@SFCOEX06.lodgenet.com> Ruckus should work fine for you. You need to have a controller and need a good RF plan but as far as capacity, throughput, roaming etc they are really solid. Of course the best is Cisco but if you can't afford them Ruckus is the way to go. I use them in small and very large convention centers and hotels with no reservation. jle -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart Sent: Thursday, January 29, 2015 11:55 To: 'Mike Hammett'; nanog at nanog.org Subject: RE: Recommended wireless AP for 400 users office It was all users getting randomly disconnected ... the AP's stayed online but the traffic would completely halt for 15-30 seconds at a time. Their association with the AP would stay in tact .... Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 10:53 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Stewart" To: "Mike Hammett" , nanog at nanog.org Sent: Thursday, January 29, 2015 8:34:46 AM Subject: RE: Recommended wireless AP for 400 users office I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, January 29, 2015 8:23 AM To: nanog at nanog.org Subject: Re: Recommended wireless AP for 400 users office What problems have you had with UBNT? It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Manuel Marín" To: nanog at nanog.org Sent: Wednesday, January 28, 2015 11:06:39 PM Subject: Recommended wireless AP for 400 users office Dear nanog community I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. Thank you and have a great day From paul at paulstewart.org Fri Jan 30 14:00:03 2015 From: paul at paulstewart.org (Paul Stewart) Date: Fri, 30 Jan 2015 09:00:03 -0500 Subject: cable modem firmware upgrade In-Reply-To: <86k304jxpl.fsf@valhalla.seastrom.com> References: <000501d03b79$942070e0$bc6152a0$@ca> <011701d03bad$86476030$92d62090$@paulstewart.org> <86k304jxpl.fsf@valhalla.seastrom.com> Message-ID: <009701d03c95$0e94c990$2bbe5cb0$@paulstewart.org> That brings back memories of some unidentified folks getting much higher speeds and other features they may errr umm not been paying for ;) I miss my LanCity cablemodem - it made a great spaceheater in the winters..... -----Original Message----- From: Rob Seastrom [mailto:rs at seastrom.com] Sent: Friday, January 30, 2015 6:49 AM To: Paul Stewart Cc: 'Nathan Anderson'; 'A MEKKAOUI'; nanog at nanog.org Subject: Re: cable modem firmware upgrade "Paul Stewart" writes: > That has been my experience as well (only from the RF side) and I would > believe this was a design choice. The ISP usually wants to keep control > over the firmware versions of the CM for various technical/support > reasons versus having consumers mess with the firmware. 15 years ago, in certain circles it was well-understood how to load one's own (possibly patched) software from the Ethernet side on the old LanCity (pre-DOCSIS) cablemodems. You can imagine what kind of hilarity ensued. -r From paul at nashnetworks.ca Fri Jan 30 14:06:59 2015 From: paul at nashnetworks.ca (Paul Nash) Date: Fri, 30 Jan 2015 09:06:59 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: <0AA634BD14529B41BB3816DC3D8FD768016F78CD3C@SFCOEX06.lodgenet.com> References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <044601d03be4$4eef9210$ecceb630$@paulstewart.org> <0AA634BD14529B41BB3816DC3D8FD768016F78CD3C@SFCOEX06.lodgenet.com> Message-ID: <252417D4-9A19-4734-B931-1A23015404CF@nashnetworks.ca> My personal experience is that the Ruckus kit outperforms the Cisco Air-O-Net stuff. This was looking at penetration through concrete walls, co-existence with other devices, throughput. YMMV, I’m not a Cisco expert but *did* have a local certified-up-to-his-eyeballs Cisco dude check what I had done, and he could not squeeze any better performance out of the Cisco gear either. Maybe they just want to sell more APs and controllers? Oh, and for this application, the Ruckus kit came in an order of magnitude cheaper than Cisco would have. Ruckus is also *way* easier to configure than Cisco. Some of the Cisco folk that I know think that that is a point in favour of Cisco, as it adds to job security :-) paul > On Jan 29, 2015, at 12:02 PM, Edwards, Jermaine wrote: > > Ruckus should work fine for you. You need to have a controller and need a good RF plan but as far as capacity, throughput, roaming etc they are really solid. Of course the best is Cisco but if you can't afford them Ruckus is the way to go. I use them in small and very large convention centers and hotels with no reservation. > > jle > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Stewart > Sent: Thursday, January 29, 2015 11:55 > To: 'Mike Hammett'; nanog at nanog.org > Subject: RE: Recommended wireless AP for 400 users office > > It was all users getting randomly disconnected ... the AP's stayed online but the traffic would completely halt for 15-30 seconds at a time. Their association with the AP would stay in tact .... > > Paul > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Thursday, January 29, 2015 10:53 AM > To: nanog at nanog.org > Subject: Re: Recommended wireless AP for 400 users office > > Did you figure out why it was dropping out? All of it dropping out? Just some APs dropping? Just some users dropping? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Paul Stewart" > To: "Mike Hammett" , nanog at nanog.org > Sent: Thursday, January 29, 2015 8:34:46 AM > Subject: RE: Recommended wireless AP for 400 users office > > I had a bad experience with it one time at a tradeshow environment. 6 access points setup for public wifi. The radio levels were quite good in various areas of the tradeshow however traffic would keep dropping out at random intervals as soon as about 300 users were online. It wasn't my idea to use UBNT but it definitely turned me off of their product after digging into their gear... > > Again as someone pointed out, for residential and perhaps SOHO applications it can probably work well - and in my opinion it's priced for that market. > > Paul > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Thursday, January 29, 2015 8:23 AM > To: nanog at nanog.org > Subject: Re: Recommended wireless AP for 400 users office > > What problems have you had with UBNT? > > It's zero hand-off doesn't work on unsecured networks, but that's about the extent of the issues I've heard of other than stadium density environments. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Manuel Marín" > To: nanog at nanog.org > Sent: Wednesday, January 28, 2015 11:06:39 PM > Subject: Recommended wireless AP for 400 users office > > Dear nanog community > > I was wondering if you can recommend or share your experience with APs that you can use in locations that have 300-500 users. I friend recommended me Ruckus Wireless, it would be great if you can share your experience with Ruckus or with a similar vendor. My experience with ubiquity for this type of requirement was not that good. > > Thank you and have a great day > > > > From karsten.elfenbein at gmail.com Fri Jan 30 15:12:47 2015 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Fri, 30 Jan 2015 16:12:47 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: Hi, 2015-01-30 0:28 GMT+01:00 Eric Louie : > I'm putting together my first IPv6 allocation plan. The general layout: > /48 for customers universally and uniformly > /38 for larger regions on an even (/37) boundary > /39 for smaller regions on an even (/38) boundary > A few /48's for "internal use" to allow us to monitor and maintain systems. Depending on how many regions you have I would just go for /40 as it is the byte boundary or request a bigger block and use the /32. > For security sake, do I need (am I better off) to "reserve" a "management > block" (/39, /40, /41 or something of that nature) that does NOT get > advertised into BGP to my upstreams, and use that for my device management > and monitoring address space? In other words, make a small "private" > address space for management? What are folks doing around that? Do not spam the BGP table for that. Use firewalls or ACLs to prevent unwanted access. You could use Unique Local addresses (ULA) for this if you have some VPN infrastructure in your network. Not announcing these blocks does not prevent people on your network to access these areas. > If I have to do 6-to-4 conversion, is there any way to do that with > multiple diverse ISP connections, or am I "restricted" to using one > entry/exit point? (If that's true, do I need to allocate a separate block > of addresses that would be designated "6 to 4" so they'd always be routed > out that one entry/exit point?) I would not use 6to4 as it tunnels the IPv6 traffic over IPv4 which is a pain to control. Best regards Karsten From the.lists at mgm51.com Fri Jan 30 15:32:45 2015 From: the.lists at mgm51.com (Mike.) Date: Fri, 30 Jan 2015 10:32:45 -0500 Subject: Anyone from google? - possible routing loop Message-ID: <201501301032450164.005055AF@smtp.24cl.home> The shaperprobe test program from M-Lab is not working. The problem appears to be a routing loop in google's realm. Emails to m-lab over the past month were not effective in resolving the issue. shaperprobe: http://www.measurementlab.net/tools/shaperprobe 64.9.225.153 is server shaperprobe uses. Traceroute showing routing loop: $ traceroute 64.9.225.153 traceroute to 64.9.225.153 (64.9.225.153), 64 hops max, 40 byte packets 1 cat6509-vlan5.edm.tera-byte.com (216.234.161.129) 0.428 ms 0.658 ms 0.399 ms 2 * * * 3 core3-edmonton_1-0-0.net.bell.ca (64.230.119.244) 18.289 ms core4-edmonton_1-0-0.net.bell.ca (64.230.119.246) 18.305 ms core3-edmonton_1-0-0.net.bell.ca (64.230.119.244) 18.308 ms 4 core4-edmonton_pos10-1-0.net.bell.ca (64.230.77.201) 19.619 ms 18.325 ms core3-vancouver_pos15-1-0.net.bell.ca (64.230.77.203) 20.342 ms 5 tcore3-seattle_hundredgige0-5-0-0.net.bell.ca (64.230.79.92) 22.857 ms tcore4-seattle_hundredgige0-9-0-0.net.bell.ca (64.230.79.98) 21.344 ms 18.256 ms 6 bx4-seattle_xe1-0-0.net.bell.ca (64.230.125.245) 18.923 ms 18.950 ms bx4-seattle_xe8-0-0.net.bell.ca (64.230.125.247) 18.099 ms 7 Global_Crossing_bx3-seattle.net.bell.ca (67.69.246.206) 17.221 ms ge-9-29-1G.ar5.sea1.gblx.net (64.212.107.53) 33.570 ms Global_Crossing_bx3-seattle.net.bell.ca (67.69.246.206) 171.896 ms 8 204.245.39.194 (204.245.39.194) 74.329 ms 73.353 ms 74.364 ms 9 64.9.224.130 (64.9.224.130) 75.516 ms 75.441 ms 75.421 ms 10 64.9.224.142 (64.9.224.142) 74.722 ms 73.774 ms 73.741 ms 11 64.9.224.230 (64.9.224.230) 74.525 ms 75.333 ms 75.360 ms 12 64.9.224.229 (64.9.224.229) 73.637 ms 74.666 ms 74.619 ms 13 64.9.224.230 (64.9.224.230) 74.812 ms 75.119 ms 75.467 ms 14 64.9.224.229 (64.9.224.229) 73.819 ms 74.694 ms 74.734 ms 15 64.9.224.230 (64.9.224.230) 75.553 ms 74.605 ms 75.588 ms 16 64.9.224.229 (64.9.224.229) 73.833 ms 74.745 ms 73.794 ms 17 64.9.224.230 (64.9.224.230) 74.689 ms 74.691 ms 75.701 ms 18 64.9.224.229 (64.9.224.229) 73.837 ms 74.786 ms 74.986 ms 19 64.9.224.230 (64.9.224.230) 74.722 ms 75.720 ms 75.212 ms 20 64.9.224.229 (64.9.224.229) 74.868 ms 74.881 ms 73.911 ms 21 64.9.224.230 (64.9.224.230) 74.857 ms 74.846 ms 74.788 ms 22 64.9.224.229 (64.9.224.229) 74.909 ms 74.952 ms 73.975 ms 23 64.9.224.230 (64.9.224.230) 75.860 ms 74.898 ms 79.610 ms 24 64.9.224.229 (64.9.224.229) 75.046 ms 74.098 ms 74.112 ms 25 64.9.224.230 (64.9.224.230) 74.928 ms 74.968 ms 75.976 ms 26 64.9.224.229 (64.9.224.229) 74.093 ms 75.088 ms 75.015 ms 27 64.9.224.230 (64.9.224.230) 76.031 ms 75.050 ms 75.989 ms 28 64.9.224.229 (64.9.224.229) 107.876 ms 74.216 ms 75.263 ms 29 64.9.224.230 (64.9.224.230) 75.253 ms 81.958 ms 76.030 ms 30 64.9.224.229 (64.9.224.229) 75.196 ms 75.149 ms 74.183 ms 31 64.9.224.230 (64.9.224.230) 76.127 ms 76.370 ms 75.149 ms 32 64.9.224.229 (64.9.224.229) 75.199 ms 74.242 ms 75.240 ms 33 64.9.224.230 (64.9.224.230) 76.514 ms 75.286 ms 76.278 ms 34 64.9.224.229 (64.9.224.229) 75.308 ms 75.253 ms 75.270 ms 35 64.9.224.230 (64.9.224.230) 75.493 ms 76.337 ms 75.282 ms 36 64.9.224.229 (64.9.224.229) 75.312 ms 75.359 ms 75.344 ms 37 64.9.224.230 (64.9.224.230) 75.449 ms 75.395 ms 75.745 ms 38 64.9.224.229 (64.9.224.229) 74.486 ms 75.419 ms 74.524 ms 39 64.9.224.230 (64.9.224.230) 75.444 ms 76.412 ms 75.474 ms 40 64.9.224.229 (64.9.224.229) 74.467 ms 75.434 ms 75.477 ms 41 64.9.224.230 (64.9.224.230) 77.191 ms 75.567 ms 75.553 ms From morrowc.lists at gmail.com Fri Jan 30 15:44:37 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 30 Jan 2015 10:44:37 -0500 Subject: Anyone from google? - possible routing loop In-Reply-To: <201501301032450164.005055AF@smtp.24cl.home> References: <201501301032450164.005055AF@smtp.24cl.home> Message-ID: On Fri, Jan 30, 2015 at 10:32 AM, Mike. wrote: > > The shaperprobe test program from M-Lab is not working. The problem > appears to be a routing loop in google's realm. Emails to m-lab over > the past month were not effective in resolving the issue. > > shaperprobe: http://www.measurementlab.net/tools/shaperprobe > > > 64.9.225.153 is server shaperprobe uses. looking, thnx From bill at herrin.us Fri Jan 30 15:51:47 2015 From: bill at herrin.us (William Herrin) Date: Fri, 30 Jan 2015 10:51:47 -0500 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: On Thu, Jan 29, 2015 at 6:28 PM, Eric Louie wrote: > I'm putting together my first IPv6 allocation plan. The general layout: > /48 for customers universally and uniformly Hi Eric, Good luck with that. Personally, I'd be inclined to think that some customers will (reasonably) want more than a /48 and I'd be in less of a rush to burn through my /32 for the sake of customers who would have been perfectly happy with a /56. The only deliberately static sizes I'd endorse is /64 for an ethernet LAN and the 4-bit nibble boundary for any delegations. > /38 for larger regions on an even (/37) boundary > /39 for smaller regions on an even (/38) boundary > A few /48's for "internal use" to allow us to monitor and maintain systems. Suggest you delegate to regions, purposes and customers on the 4-bit nibble boundary. This makes it easier to read your IPv6 addresses and it simplifies DNS operations. > For security sake, do I need (am I better off) to "reserve" a "management > block" (/39, /40, /41 or something of that nature) that does NOT get > advertised into BGP to my upstreams, and use that for my device management > and monitoring address space? In other words, make a small "private" > address space for management? What are folks doing around that? If it is strictly internal (not used for router interfaces that have to transmit destination unreachables) select and use a ULA block. That way when you find you really need to advertise a covering route for your /32 to get full IPv6 connectivity, your management network still won't be exposed to the Internet at large. Otherwise, address with firewalls and access lists. If you try to micromanage your /32's advertisement you'll both earn yourself grief and engender the annoyance of other IPv6 participants trying to keep the routing table small. > If I have to do 6-to-4 conversion, is there any way to do that with > multiple diverse ISP connections, or am I "restricted" to using one > entry/exit point? (If that's true, do I need to allocate a separate block > of addresses that would be designated "6 to 4" so they'd always be routed > out that one entry/exit point?) Let's clarify some terminology: 6to4 - a system for facilitating IPv4-only end sites creating a configuration-free local IPv6 network that reaches out to the native IPv6 Internet. Run by unaffiliated volunteers. Algorithmically matched an IPv6 /48 to every possible IPv4 address. It did good service in IPv6's experimental days but is not production grade and basically should never be used again. Replace with free tunnels from Hurricane Electric or similar. 6rd - allows ISPs to deploy IPv6 to their customers without dual-stacking the ISP's network. Get your feet wet at minimal cost and then wait to see what happens before undertaking the substantial risk and expense of dual-stacking your entire network. Uses the network protocols developed for 6to4 but is implemented entirely within your organization and is production grade. 6rd uses *your* IPv6 addresses, so you route those IPv6 addresses with your peers as normal -- no special considerations needed. nat64/nat46 - allows an IPv6-only host to interact in limited ways with IPv4-only hosts. Don't go down this rabbit hole. This will probably be useful in the waning days of IPv4 when folks are dismantling their IPv4 networks but for now the corner cases will drive you nuts. Plan on dual-stacking any network which requires access to IPv4 resources such as the public Internet. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Fri Jan 30 16:19:31 2015 From: bill at herrin.us (William Herrin) Date: Fri, 30 Jan 2015 11:19:31 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: On Thu, Jan 29, 2015 at 12:06 AM, Manuel Marín wrote: > I was wondering if you can recommend or share your experience with APs that > you can use in locations that have 300-500 users. I friend recommended me > Ruckus Wireless, it would be great if you can share your experience with > Ruckus or with a similar vendor. My experience with ubiquity for this type > of requirement was not that good. Hi Manuel, At 300-500 users you may still be in dd-wrt territory with the lack of smart roaming and self-healing features mitigated by a price that makes it practical to simply deploy more access points. Dumb roaming can be good enough when the user count per AP is low. Aruba it is not, but I had a 150 user deployment on 5 dd-wrt APs that was largely trouble-free. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From tore at fud.no Fri Jan 30 16:44:53 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 30 Jan 2015 17:44:53 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: <20150130174453.485e9105@envy.fud.no> * William Herrin > nat64/nat46 - allows an IPv6-only host to interact in limited ways > with IPv4-only hosts. Don't go down this rabbit hole. This will > probably be useful in the waning days of IPv4 when folks are > dismantling their IPv4 networks but for now the corner cases will > drive you nuts. Plan on dual-stacking any network which requires > access to IPv4 resources such as the public Internet. For many folks, that's easier said than done. Think about it: If everyone could just dual-stack their networks, they might as well single-stack them on IPv4 instead; there would be no point whatsoever in transitioning to IPv6 for anyone. Tore From streiner at cluebyfour.org Fri Jan 30 13:03:50 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 30 Jan 2015 08:03:50 -0500 (EST) Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <20150130174453.485e9105@envy.fud.no> References: <20150130174453.485e9105@envy.fud.no> Message-ID: On Fri, 30 Jan 2015, Tore Anderson wrote: > For many folks, that's easier said than done. > > Think about it: If everyone could just dual-stack their networks, they > might as well single-stack them on IPv4 instead; there would be no > point whatsoever in transitioning to IPv6 for anyone. I re-read this 3 or 4 times, and it still doesn't make any sense. I dual-stacked our backbone here at $dayjob 3+ years ago, and it really wasn't painful at all. Sure, there were were some transition pains, but they've been more at the edge (firewalls, wireless, managing users, etc), but getting the backbone to handle both v4 and v6 was the easy part. Granted, this process can be more or less painful in different environments, but definitely no reason to stick your head in the sand and pretend that IPv6 doesn't exist, especially in 2015. jms From carlos at race.com Fri Jan 30 17:04:38 2015 From: carlos at race.com (Carlos Alcantar) Date: Fri, 30 Jan 2015 17:04:38 +0000 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: +1 on Xirrus or Ruckus if you care to sleep at night. Just my 2cents 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 On 1/30/15, 8:19 AM, "William Herrin" wrote: >On Thu, Jan 29, 2015 at 12:06 AM, Manuel Marín wrote: >> I was wondering if you can recommend or share your experience with APs >>that >> you can use in locations that have 300-500 users. I friend recommended >>me >> Ruckus Wireless, it would be great if you can share your experience with >> Ruckus or with a similar vendor. My experience with ubiquity for this >>type >> of requirement was not that good. > >Hi Manuel, > >At 300-500 users you may still be in dd-wrt territory with the lack of >smart roaming and self-healing features mitigated by a price that >makes it practical to simply deploy more access points. Dumb roaming >can be good enough when the user count per AP is low. > >Aruba it is not, but I had a 150 user deployment on 5 dd-wrt APs that >was largely trouble-free. > >Regards, >Bill Herrin > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Owner, Dirtside Systems ......... Web: > From mel at beckman.org Fri Jan 30 17:14:29 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 30 Jan 2015 17:14:29 +0000 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> Message-ID: Tore, Um, haven't you heard that we are out of IPv4 addresses? The point of IPv6 is to expand address space so that the Internet can keep growing. Maybe you don't want to grow with it, but most people do. Eventually IPv4 will be dropped and the Internet will be IPv6-only. Dual-stack is just a convenient transition mechanism. -mel On Jan 30, 2015, at 5:03 AM, "Justin M. Streiner" wrote: > On Fri, 30 Jan 2015, Tore Anderson wrote: > >> For many folks, that's easier said than done. >> >> Think about it: If everyone could just dual-stack their networks, they >> might as well single-stack them on IPv4 instead; there would be no >> point whatsoever in transitioning to IPv6 for anyone. > > I re-read this 3 or 4 times, and it still doesn't make any sense. > > I dual-stacked our backbone here at $dayjob 3+ years ago, and it really wasn't painful at all. Sure, there were were some transition pains, but they've been more at the edge (firewalls, wireless, managing users, etc), but getting the backbone to handle both v4 and v6 was the easy part. > > Granted, this process can be more or less painful in different environments, but definitely no reason to stick your head in the sand and pretend that IPv6 doesn't exist, especially in 2015. > > jms From bill at herrin.us Fri Jan 30 17:39:33 2015 From: bill at herrin.us (William Herrin) Date: Fri, 30 Jan 2015 12:39:33 -0500 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <20150130174453.485e9105@envy.fud.no> References: <20150130174453.485e9105@envy.fud.no> Message-ID: On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson wrote: > * William Herrin > >> Plan on dual-stacking any network which requires >> access to IPv4 resources such as the public Internet. > > For many folks, that's easier said than done. > > Think about it: If everyone could just dual-stack their networks, they > might as well single-stack them on IPv4 instead; there would be no > point whatsoever in transitioning to IPv6 for anyone. Hi Tore, That's what NAT is for. Use RFC 1918 space for end users, RFC 6598 space for ISPs. Plan on dual-stacking until IPv6 deployment is ubiquitous. Which won't be this year. Or next. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rs at seastrom.com Fri Jan 30 17:45:29 2015 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 30 Jan 2015 12:45:29 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: <252417D4-9A19-4734-B931-1A23015404CF@nashnetworks.ca> (Paul Nash's message of "Fri, 30 Jan 2015 09:06:59 -0500") References: <00f201d03bd0$bb269a50$3173cef0$@paulstewart.org> <28724771.1090.1422546772976.JavaMail.mhammett@ThunderFuck> <044601d03be4$4eef9210$ecceb630$@paulstewart.org> <0AA634BD14529B41BB3816DC3D8FD768016F78CD3C@SFCOEX06.lodgenet.com> <252417D4-9A19-4734-B931-1A23015404CF@nashnetworks.ca> Message-ID: <86wq44b1s6.fsf@valhalla.seastrom.com> Paul Nash writes: > Ruckus is also *way* easier to configure than Cisco. Some of the > Cisco folk that I know think that that is a point in favour of > Cisco, as it adds to job security :-) That matches my experience with Cisco 802.11 kit. Way too many knobs exposed, and guidance on how to set them is thin on the ground. Sensible defaults and quick to configure on the Ruckus kit. -r From stuart at tech.org Fri Jan 30 17:59:18 2015 From: stuart at tech.org (Stephen Stuart) Date: Fri, 30 Jan 2015 17:59:18 +0000 Subject: Anyone from google? - possible routing loop In-Reply-To: References: <201501301032450164.005055AF@smtp.24cl.home> Message-ID: <201501301759.t0UHxIq4010090@nb.tech.org> > On Fri, Jan 30, 2015 at 10:32 AM, Mike. wrote: > > > > The shaperprobe test program from M-Lab is not working. The problem > > appears to be a routing loop in google's realm. Emails to m-lab over > > the past month were not effective in resolving the issue. > > > > shaperprobe: http://www.measurementlab.net/tools/shaperprobe > > > > > > 64.9.225.153 is server shaperprobe uses. > > looking, thnx The M-Lab folks are looking at it. The loop is getting resolved as I type (thanks, Chris). Unfortunately. the Shaperprobe researchers hard-coded IP addresses in their experiment for a site that is in the process of being decommissioned, the M-Lab ops team is working on getting that bit resolved ASAP. Thanks, Stephen From cscora at apnic.net Fri Jan 30 18:11:54 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Jan 2015 04:11:54 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201501301811.t0UIBsH8029733@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 31 Jan, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 529971 Prefixes after maximum aggregation (per Origin AS): 202983 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 258157 Total ASes present in the Internet Routing Table: 49242 Prefixes per ASN: 10.76 Origin-only ASes present in the Internet Routing Table: 36405 Origin ASes announcing only one prefix: 16292 Transit ASes present in the Internet Routing Table: 6246 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 107 Max AS path prepend of ASN ( 55644) 100 Prefixes from unregistered ASNs in the Routing Table: 1714 Unregistered ASNs in the Routing Table: 422 Number of 32-bit ASNs allocated by the RIRs: 8474 Number of 32-bit ASNs visible in the Routing Table: 6591 Prefixes from 32-bit ASNs in the Routing Table: 23699 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 356 Number of addresses announced to Internet: 2723625508 Equivalent to 162 /8s, 87 /16s and 58 /24s Percentage of available address space announced: 73.6 Percentage of allocated address space announced: 73.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 179682 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 130804 Total APNIC prefixes after maximum aggregation: 38186 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 135954 Unique aggregates announced from the APNIC address blocks: 55417 APNIC Region origin ASes present in the Internet Routing Table: 5021 APNIC Prefixes per ASN: 27.08 APNIC Region origin ASes announcing only one prefix: 1227 APNIC Region transit ASes present in the Internet Routing Table: 872 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1275 Number of APNIC addresses announced to Internet: 741480576 Equivalent to 44 /8s, 50 /16s and 24 /24s Percentage of available APNIC address space announced: 86.7 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, 131072-135580 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: 175130 Total ARIN prefixes after maximum aggregation: 86650 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 177109 Unique aggregates announced from the ARIN address blocks: 82854 ARIN Region origin ASes present in the Internet Routing Table: 16458 ARIN Prefixes per ASN: 10.76 ARIN Region origin ASes announcing only one prefix: 6081 ARIN Region transit ASes present in the Internet Routing Table: 1722 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 19 Number of ARIN region 32-bit ASNs visible in the Routing Table: 331 Number of ARIN addresses announced to Internet: 1059902240 Equivalent to 63 /8s, 44 /16s and 211 /24s Percentage of available ARIN address space announced: 56.1 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, 393216-394239 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: 129159 Total RIPE prefixes after maximum aggregation: 64185 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 135279 Unique aggregates announced from the RIPE address blocks: 83134 RIPE Region origin ASes present in the Internet Routing Table: 17839 RIPE Prefixes per ASN: 7.58 RIPE Region origin ASes announcing only one prefix: 8133 RIPE Region transit ASes present in the Internet Routing Table: 2942 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3398 Number of RIPE addresses announced to Internet: 692818564 Equivalent to 41 /8s, 75 /16s and 146 /24s Percentage of available RIPE address space announced: 100.7 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, 196608-202239 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: 58588 Total LACNIC prefixes after maximum aggregation: 10951 LACNIC Deaggregation factor: 5.35 Prefixes being announced from the LACNIC address blocks: 67869 Unique aggregates announced from the LACNIC address blocks: 31417 LACNIC Region origin ASes present in the Internet Routing Table: 2397 LACNIC Prefixes per ASN: 28.31 LACNIC Region origin ASes announcing only one prefix: 644 LACNIC Region transit ASes present in the Internet Routing Table: 481 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 34 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1499 Number of LACNIC addresses announced to Internet: 167768576 Equivalent to 9 /8s, 255 /16s and 242 /24s Percentage of available LACNIC address space announced: 100.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12418 Total AfriNIC prefixes after maximum aggregation: 2967 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 13404 Unique aggregates announced from the AfriNIC address blocks: 5016 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 18.19 AfriNIC Region origin ASes announcing only one prefix: 207 AfriNIC Region transit ASes present in the Internet Routing Table: 157 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 88 Number of AfriNIC addresses announced to Internet: 61094400 Equivalent to 3 /8s, 164 /16s and 58 /24s Percentage of available AfriNIC address space announced: 60.7 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 4766 2877 11553 909 Korea Telecom 17974 2842 905 78 PT Telekomunikasi Indonesia 7545 2488 336 128 TPG Telecom Limited 4755 1943 418 196 TATA Communications formerly 4538 1757 4190 71 China Education and Research 9829 1685 1324 34 National Internet Backbone 9808 1525 6719 19 Guangdong Mobile Communicatio 4808 1460 2218 436 CNCGROUP IP network China169 9583 1391 115 572 Sify Limited 9498 1296 336 97 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 2930 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2569 10688 477 Level 3 Communications, Inc. 18566 2043 379 183 MegaPath Corporation 20115 1850 1826 450 Charter Communications 4323 1623 1037 407 tw telecom holdings, inc. 6983 1622 866 244 EarthLink, Inc. 30036 1520 315 521 Mediacom Communications Corp 701 1398 11271 684 MCI Communications Services, 22561 1331 411 240 CenturyTel Internet Holdings, 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 2069 139 10 SaudiNet, Saudi Telecom Compa 34984 1956 300 357 TELLCOM ILETISIM HIZMETLERI A 20940 1567 613 1162 Akamai International B.V. 8402 1437 544 15 OJSC "Vimpelcom" 6849 1234 358 26 JSC "Ukrtelecom" 31148 1045 45 21 Freenet Ltd. 13188 1037 97 58 TOV "Bank-Inform" 8551 904 373 48 Bezeq International-Ltd 12479 847 793 85 France Telecom Espana SA 9198 843 349 25 JSC Kazakhtelecom 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 3073 498 223 Telmex Colombia S.A. 28573 2346 2139 112 NET Servi�os de Comunica��o S 7303 1770 1173 238 Telecom Argentina S.A. 6147 1695 374 30 Telefonica del Peru S.A.A. 8151 1495 3094 427 Uninet S.A. de C.V. 6503 1227 421 57 Axtel, S.A.B. de C.V. 7738 1000 1882 42 Telemar Norte Leste S.A. 3816 920 396 149 COLOMBIA TELECOMUNICACIONES S 26615 913 2325 35 Tim Celular S.A. 18881 857 1036 22 Global Village Telecom 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 8452 1520 958 13 TE-AS 24863 953 284 26 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 373 845 30 ETISALAT MISR 37492 327 144 65 Orange Tunisie 24835 295 144 9 Vodafone Data 3741 249 921 213 Internet Solutions 29571 234 21 12 Cote d'Ivoire Telecom 36947 191 807 13 Telecom Algeria 15706 176 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3073 498 223 Telmex Colombia S.A. 22773 2930 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 4766 2877 11553 909 Korea Telecom 17974 2842 905 78 PT Telekomunikasi Indonesia 3356 2569 10688 477 Level 3 Communications, Inc. 7545 2488 336 128 TPG Telecom Limited 28573 2346 2139 112 NET Servi�os de Comunica��o S 39891 2069 139 10 SaudiNet, Saudi Telecom Compa 18566 2043 379 183 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2891 2840 BellSouth.net Inc. 22773 2930 2789 Cox Communications Inc. 17974 2842 2764 PT Telekomunikasi Indonesia 7545 2488 2360 TPG Telecom Limited 28573 2346 2234 NET Servi�os de Comunica��o S 3356 2569 2092 Level 3 Communications, Inc. 39891 2069 2059 SaudiNet, Saudi Telecom Compa 4766 2877 1968 Korea Telecom 18566 2043 1860 MegaPath Corporation 4755 1943 1747 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.92.160.0/24 14013 EPSON America (Factory Automa 23.92.161.0/24 14013 EPSON America (Factory Automa 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 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:12 /10:32 /11:92 /12:264 /13:502 /14:997 /15:1718 /16:12975 /17:7131 /18:12135 /19:24997 /20:35644 /21:38397 /22:57495 /23:50361 /24:284231 /25:1151 /26:1091 /27:680 /28:17 /29:14 /30:8 /31:0 /32:11 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2143 2930 Cox Communications Inc. 39891 2012 2069 SaudiNet, Saudi Telecom Compa 18566 1998 2043 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1366 1520 Mediacom Communications Corp 6983 1313 1622 EarthLink, Inc. 34984 1260 1956 TELLCOM ILETISIM HIZMETLERI A 6147 1241 1695 Telefonica del Peru S.A.A. 11492 1131 1189 CABLE ONE, INC. 8402 1103 1437 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1468 2:673 3:1 4:97 5:1204 6:21 8:1404 12:1843 13:4 14:1240 15:17 16:2 17:42 18:21 20:50 23:1095 24:1677 27:1825 31:1468 32:39 33:2 34:5 35:2 36:129 37:1900 38:978 39:11 40:232 41:2976 42:262 43:980 44:23 45:105 46:2093 47:34 49:786 50:790 52:12 54:66 55:5 56:8 57:32 58:1198 59:681 60:455 61:1760 62:1311 63:1903 64:4442 65:2257 66:4083 67:2019 68:1040 69:3276 70:907 71:431 72:1969 74:2616 75:314 76:413 77:1465 78:1298 79:783 80:1324 81:1305 82:796 83:628 84:674 85:1322 86:376 87:1162 88:514 89:1740 90:139 91:5856 92:802 93:2206 94:1866 95:2071 96:418 97:335 98:1039 99:47 100:75 101:790 103:6585 104:1163 105:54 106:202 107:887 108:608 109:2008 110:1067 111:1477 112:745 113:930 114:841 115:1253 116:1320 117:1022 118:1688 119:1409 120:452 121:1038 122:2176 123:1714 124:1496 125:1540 128:643 129:386 130:380 131:1075 132:470 133:167 134:389 135:87 136:311 137:296 138:417 139:173 140:223 141:414 142:625 143:442 144:519 145:111 146:708 147:564 148:1067 149:418 150:559 151:586 152:482 153:247 154:309 155:712 156:398 157:332 158:265 159:957 160:368 161:634 162:1881 163:388 164:651 165:669 166:321 167:705 168:1002 169:141 170:1430 171:223 172:42 173:1596 174:702 175:612 176:1460 177:3635 178:2092 179:862 180:1876 181:1594 182:1700 183:604 184:738 185:2754 186:2717 187:1794 188:2017 189:1539 190:7808 191:851 192:8077 193:5553 194:4040 195:3634 196:1693 197:887 198:5444 199:5500 200:6464 201:2909 202:9521 203:9081 204:4658 205:2730 206:3015 207:2978 208:3950 209:3871 210:3486 211:1827 212:2436 213:2301 214:832 215:69 216:5536 217:1808 218:665 219:466 220:1342 221:796 222:464 223:657 End of report From rs at seastrom.com Fri Jan 30 18:42:14 2015 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 30 Jan 2015 13:42:14 -0500 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: (Eric Louie's message of "Thu, 29 Jan 2015 15:28:58 -0800") References: Message-ID: <86siesaz5l.fsf@valhalla.seastrom.com> Eric Louie writes: > I'm putting together my first IPv6 allocation plan. The general layout: > /48 for customers universally and uniformly > /38 for larger regions on an even (/37) boundary > /39 for smaller regions on an even (/38) boundary You really really really don't want to subnet on non-nybble boundaries. "Technically feasible" does not equate to "good idea". Optimize for technician brain cells and 2am maintenance windows. Oh, and rDNS. If you can't make your regional aggregation scheme fit within a /32 when rounding up on nybble boundaries... get more from ARIN. Seriously. IPv6 is not scarce. A /32 is the *minimum* initial allocation for an ISP. See ARIN NRPM 6.5.2.1. "justification" is viewed in an entirely different light in the IPv6 land-of-plenty that is IPv6. If you already have a /32 but haven't rolled it out yet, ask for a do-over. "Our subnetting scheme [insert description here] requires a /28" is, at least on paper, an entirely good reason to get a /28 out of ARIN. If you need it and you are having trouble getting it, it's a sign that policy needs further evolution; please reach out to folks involved tightly with the policy process (that would include me) to let us know. As for giving a /48 to every customer... that's a fine way to go and eminently defensible. If every human being on the face of the earth (let's round up and say 2^33 or 8 billion to make it easy) had an end site, and we assume only 10% efficiency in our allocation scheme due to the subnetting scheme I outlined above and getting unlucky... that still uses less than a tenth of a percent of available IPv6 space. This is one of those things that are easiest to get right the first time. If "conservation of address space" is in your IPv6 numbering plan, you're doing it wrong. My $0.02, FWIW. -r From tore at fud.no Fri Jan 30 18:46:28 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 30 Jan 2015 19:46:28 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> Message-ID: <20150130194628.08ba77a2@envy.fud.no> * Mel Beckman > Um, haven't you heard that we are out of IPv4 addresses? The point > of IPv6 is to expand address space so that the Internet can keep > growing. Maybe you don't want to grow with it, but most people do. > Eventually IPv4 will be dropped and the Internet will be IPv6-only. > Dual-stack is just a convenient transition mechanism. Mel, Dual-stack was positioned to be a convenient transition mechanism 15 years ago (to take the year when RFC 2893 was published). However, that train left the platform mostly empty years ago, when the first RIRs started to run out of IPv4 addresses. After all, we were supposed to have dual-stack everywhere *before* we ran out of IPv4. That didn't happen. The key point is: In order to run dual-stack, you need as many IPv4 addresses as you do to run IPv4-only. Or to put it another way: If you don't have enough IPv4 addresses to run IPv4-only, then you don't have enough IPv4 addresses to run dual-stack either. Sure, you can squeeze some more life-time out of IPv4 by adding more NAT (something which is completely orthogonal to deploying IPv6 simultaneously). However, if you're already out of IPv4, and you already see no way forward except adding NAT, then you should seriously consider doing the NAT (or whatever backwards compat mechanism you prefer) between the residual IPv4 internet and your IPv6 infrastructure, instead of doing it between IPv4 and IPv4. Running single-stack is simply much easier and less complex than dual-stack, and once your infrastructure is based on an IPv6-only foundation, you don't have to bother with any IPv4->IPv6 transition project ever again. Tore From baldur.norddahl at gmail.com Fri Jan 30 19:46:57 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 30 Jan 2015 20:46:57 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <20150130194628.08ba77a2@envy.fud.no> References: <20150130174453.485e9105@envy.fud.no> <20150130194628.08ba77a2@envy.fud.no> Message-ID: Single stacking on IPv6 is nice in theory. In practice it just doesn't work yet. If you as an ISP tried to force all your customers to be IPv6 single stack, you would go bust. Therefore the only option is dual stack. The IPv4 can be private address space with carrier NAT - but you will need to give the users an IPv4 on their internal network. Otherwise there is simply too much that breaks. But you also want to give them IPv6, so they can escape your carrier NAT. Since carrier NAT sucks, we are buying extra IPv4 addresses instead. We still need to dual stack - our customers want both IPv4 and IPv6. Currently it might even be cheaper to buy extra addresses compared to implement carrier NAT. The equipment to do high speed NAT is not free and neither is the extra support and operating complications. Regards, Baldur On 30 January 2015 at 19:46, Tore Anderson wrote: > * Mel Beckman > > > Um, haven't you heard that we are out of IPv4 addresses? The point > > of IPv6 is to expand address space so that the Internet can keep > > growing. Maybe you don't want to grow with it, but most people do. > > Eventually IPv4 will be dropped and the Internet will be IPv6-only. > > Dual-stack is just a convenient transition mechanism. > > Mel, > > Dual-stack was positioned to be a convenient transition mechanism 15 > years ago (to take the year when RFC 2893 was published). However, that > train left the platform mostly empty years ago, when the first RIRs > started to run out of IPv4 addresses. After all, we were supposed to > have dual-stack everywhere *before* we ran out of IPv4. That didn't > happen. > > The key point is: In order to run dual-stack, you need as many IPv4 > addresses as you do to run IPv4-only. Or to put it another way: If you > don't have enough IPv4 addresses to run IPv4-only, then you don't have > enough IPv4 addresses to run dual-stack either. > > Sure, you can squeeze some more life-time out of IPv4 by adding more > NAT (something which is completely orthogonal to deploying IPv6 > simultaneously). However, if you're already out of IPv4, and you > already see no way forward except adding NAT, then you should seriously > consider doing the NAT (or whatever backwards compat mechanism > you prefer) between the residual IPv4 internet and your IPv6 > infrastructure, instead of doing it between IPv4 and IPv4. > > Running single-stack is simply much easier and less complex than > dual-stack, and once your infrastructure is based on an IPv6-only > foundation, you don't have to bother with any IPv4->IPv6 transition > project ever again. > > Tore > From elouie at techintegrity.com Fri Jan 30 20:20:16 2015 From: elouie at techintegrity.com (Eric Louie) Date: Fri, 30 Jan 2015 12:20:16 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: I'm just beginning to grasp the concepts of IPv6 operations here, so please pardon my seeming ignorance. If I'm reading properly, the best common practice (at least the original) was allocating a minimum /48 to customers, though I did see one that referenced a /56. If I do everything on nibble boundaries, then that would mean the natural breaks are /44, /40 and /36. It makes the regions pretty large in terms of customer count - just plain arithmetic, a /44 allocation for a region with /56 for customers is a capability of 2**12 customers or 4096 where a /36 allocation for a region with /48 customers would be 4096. It also sounds like the Internet (aka the upstream/Tier 1 carriers) don't want me to advertise anything longer than my /32 into BGPv6. Is that true? (I'm getting that from the spamming comments made by others) Am I supposed to be asking ARIN for a /32 for each region that I want to address? (They turned down my request for an increase to a /28 last year) As far as the v6 to v4 translation is concerned, I'm looking at that for the future - for the time being, we will be dual-stacked. However, if we move into a new area, based on our current IPv4 inventory, I don't really have enough to assign to each new customer, so I was looking for ways to allow those customers access to properties that are still IPv4 only. Is there yet another way to do that? Thanks Eric eric at techintegrity dot com 619-335-8148 voice & text www.techintegrity.com ericlouie on Twitter On Fri, Jan 30, 2015 at 7:51 AM, William Herrin wrote: > On Thu, Jan 29, 2015 at 6:28 PM, Eric Louie > wrote: > > I'm putting together my first IPv6 allocation plan. The general layout: > > /48 for customers universally and uniformly > > Hi Eric, > > Good luck with that. Personally, I'd be inclined to think that some > customers will (reasonably) want more than a /48 and I'd be in less of > a rush to burn through my /32 for the sake of customers who would have > been perfectly happy with a /56. The only deliberately static sizes > I'd endorse is /64 for an ethernet LAN and the 4-bit nibble boundary > for any delegations. > > > /38 for larger regions on an even (/37) boundary > > /39 for smaller regions on an even (/38) boundary > > A few /48's for "internal use" to allow us to monitor and maintain > systems. > > Suggest you delegate to regions, purposes and customers on the 4-bit > nibble boundary. This makes it easier to read your IPv6 addresses and > it simplifies DNS operations. > > > > For security sake, do I need (am I better off) to "reserve" a "management > > block" (/39, /40, /41 or something of that nature) that does NOT get > > advertised into BGP to my upstreams, and use that for my device > management > > and monitoring address space? In other words, make a small "private" > > address space for management? What are folks doing around that? > > If it is strictly internal (not used for router interfaces that have > to transmit destination unreachables) select and use a ULA block. That > way when you find you really need to advertise a covering route for > your /32 to get full IPv6 connectivity, your management network still > won't be exposed to the Internet at large. > > Otherwise, address with firewalls and access lists. If you try to > micromanage your /32's advertisement you'll both earn yourself grief > and engender the annoyance of other IPv6 participants trying to keep > the routing table small. > > > > If I have to do 6-to-4 conversion, is there any way to do that with > > multiple diverse ISP connections, or am I "restricted" to using one > > entry/exit point? (If that's true, do I need to allocate a separate > block > > of addresses that would be designated "6 to 4" so they'd always be routed > > out that one entry/exit point?) > > Let's clarify some terminology: > > 6to4 - a system for facilitating IPv4-only end sites creating a > configuration-free local IPv6 network that reaches out to the native > IPv6 Internet. Run by unaffiliated volunteers. Algorithmically matched > an IPv6 /48 to every possible IPv4 address. It did good service in > IPv6's experimental days but is not production grade and basically > should never be used again. Replace with free tunnels from Hurricane > Electric or similar. > > 6rd - allows ISPs to deploy IPv6 to their customers without > dual-stacking the ISP's network. Get your feet wet at minimal cost and > then wait to see what happens before undertaking the substantial risk > and expense of dual-stacking your entire network. Uses the network > protocols developed for 6to4 but is implemented entirely within your > organization and is production grade. 6rd uses *your* IPv6 addresses, > so you route those IPv6 addresses with your peers as normal -- no > special considerations needed. > > nat64/nat46 - allows an IPv6-only host to interact in limited ways > with IPv4-only hosts. Don't go down this rabbit hole. This will > probably be useful in the waning days of IPv4 when folks are > dismantling their IPv4 networks but for now the corner cases will > drive you nuts. Plan on dual-stacking any network which requires > access to IPv4 resources such as the public Internet. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From tore at fud.no Fri Jan 30 20:23:35 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 30 Jan 2015 21:23:35 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> <20150130194628.08ba77a2@envy.fud.no> Message-ID: <20150130212335.568df5a0@envy.fud.no> * Baldur Norddahl > Single stacking on IPv6 is nice in theory. In practice it just doesn't work > yet. If you as an ISP tried to force all your customers to be IPv6 single > stack, you would go bust. Kabel Deutschland, T-Mobile USA, and Facebook are examples of companies who have already or are in the process of moving their network infrastructure to IPv6-only. Without going bust. What you *do* need, is some form of connectivity to the IPv4 internet. But there are smarter ways to do that than dual stack. Seriously, if you're building a network today, consider making IPv4 a legacy "app" or service running on top of an otherwise IPv6-only infrastructure. Five years down the road you'll thank me for the tip. :-) Tore From streiner at cluebyfour.org Fri Jan 30 16:29:01 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 30 Jan 2015 11:29:01 -0500 (EST) Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: On Fri, 30 Jan 2015, Eric Louie wrote: > It also sounds like the Internet (aka the upstream/Tier 1 carriers) don't > want me to advertise anything longer than my /32 into BGPv6. Is that true? > (I'm getting that from the spamming comments made by others) Am I > supposed to be asking ARIN for a /32 for each region that I want to > address? (They turned down my request for an increase to a /28 last year) Not true. A peek at the global IPv6 routing table shows lots of prefixes that are smaller than /32. One of the hopes with larger allocations and assignments was that there would be less bloat in the global IPv6 routing table because networks would need to announce fewer prefixes. How well that will hold up in practice remains to be seen :) > As far as the v6 to v4 translation is concerned, I'm looking at that for > the future - for the time being, we will be dual-stacked. However, if we > move into a new area, based on our current IPv4 inventory, I don't really > have enough to assign to each new customer, so I was looking for ways to > allow those customers access to properties that are still IPv4 only. Is > there yet another way to do that? If you assign a customer IPv6 space only, a translation mechanism is needed to allow that customer to reach Internet destinations that only speak IPv4 today. There's no way around that. jms From elouie at techintegrity.com Fri Jan 30 20:32:43 2015 From: elouie at techintegrity.com (Eric Louie) Date: Fri, 30 Jan 2015 12:32:43 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: On Fri, Jan 30, 2015 at 8:29 AM, Justin M. Streiner wrote: > On Fri, 30 Jan 2015, Eric Louie wrote: > > It also sounds like the Internet (aka the upstream/Tier 1 carriers) don't >> want me to advertise anything longer than my /32 into BGPv6. Is that >> true? >> (I'm getting that from the spamming comments made by others) Am I >> supposed to be asking ARIN for a /32 for each region that I want to >> address? (They turned down my request for an increase to a /28 last year) >> > > Not true. A peek at the global IPv6 routing table shows lots of prefixes > that are smaller than /32. One of the hopes with larger allocations and > assignments was that there would be less bloat in the global IPv6 routing > table because networks would need to announce fewer prefixes. How well > that will hold up in practice remains to be seen :) > > As far as the v6 to v4 translation is concerned, I'm looking at that for >> the future - for the time being, we will be dual-stacked. However, if we >> move into a new area, based on our current IPv4 inventory, I don't really >> have enough to assign to each new customer, so I was looking for ways to >> allow those customers access to properties that are still IPv4 only. Is >> there yet another way to do that? >> > > If you assign a customer IPv6 space only, a translation mechanism is > needed to allow that customer to reach Internet destinations that only > speak IPv4 today. There's no way around that. > > jms > What IPv6 to IPv4 translation mechanisms are available for networks with multiple ingress/egress points? From karsten.elfenbein at gmail.com Fri Jan 30 21:16:52 2015 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Fri, 30 Jan 2015 22:16:52 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: Hi, I would not recommend to run any nat over protocol versions for clients as you would need to break DNSsec. The clients creating connections should run dual-stack or dual-stack lite. The only useful thing for service providers would be to proxy/nat lets say an incoming IPv6 connection to still only IPv4 servers/services. 2015-01-30 21:32 GMT+01:00 Eric Louie : > On Fri, Jan 30, 2015 at 8:29 AM, Justin M. Streiner > wrote: > >> On Fri, 30 Jan 2015, Eric Louie wrote: >> >> It also sounds like the Internet (aka the upstream/Tier 1 carriers) don't >>> want me to advertise anything longer than my /32 into BGPv6. Is that >>> true? >>> (I'm getting that from the spamming comments made by others) Am I >>> supposed to be asking ARIN for a /32 for each region that I want to >>> address? (They turned down my request for an increase to a /28 last year) >>> >> >> Not true. A peek at the global IPv6 routing table shows lots of prefixes >> that are smaller than /32. One of the hopes with larger allocations and >> assignments was that there would be less bloat in the global IPv6 routing >> table because networks would need to announce fewer prefixes. How well >> that will hold up in practice remains to be seen :) >> >> As far as the v6 to v4 translation is concerned, I'm looking at that for >>> the future - for the time being, we will be dual-stacked. However, if we >>> move into a new area, based on our current IPv4 inventory, I don't really >>> have enough to assign to each new customer, so I was looking for ways to >>> allow those customers access to properties that are still IPv4 only. Is >>> there yet another way to do that? >>> >> >> If you assign a customer IPv6 space only, a translation mechanism is >> needed to allow that customer to reach Internet destinations that only >> speak IPv4 today. There's no way around that. >> >> jms >> > > What IPv6 to IPv4 translation mechanisms are available for networks with > multiple ingress/egress points? From fred at cisco.com Fri Jan 30 21:33:21 2015 From: fred at cisco.com (Fred Baker (fred)) Date: Fri, 30 Jan 2015 21:33:21 +0000 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: <6E13EE07-4ECC-4FF8-A520-41E66F00B6E3@cisco.com> > On Jan 29, 2015, at 3:28 PM, Eric Louie wrote: > > If I have to do 6-to-4 conversion, is there any way to do that with > multiple diverse ISP connections, or am I "restricted" to using one > entry/exit point? (If that's true, do I need to allocate a separate block > of addresses that would be designated "6 to 4" so they'd always be routed > out that one entry/exit point?) On this point, you may find https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic "Deprecating Anycast Prefix for 6to4 Relay Routers", Ole Troan, Brian Carpenter, 2015-01-28 of interest. t is coming from the IETF IPv6 Operations Working Group, and in essence suggests that operators not support anycast 6to4. Don’t prevent it, please understand, but don’t deploy it, and if it’s causing you problems, turn it off. One of the authors, Brian carpenter, is the original designer of 6to4... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: Message signed with OpenPGP using GPGMail URL: From streiner at cluebyfour.org Fri Jan 30 17:40:45 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 30 Jan 2015 12:40:45 -0500 (EST) Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: On Fri, 30 Jan 2015, Eric Louie wrote: >> If you assign a customer IPv6 space only, a translation mechanism is >> needed to allow that customer to reach Internet destinations that only >> speak IPv4 today. There's no way around that. >> > What IPv6 to IPv4 translation mechanisms are available for networks with > multiple ingress/egress points? A bunch were listed in an earlier post. Translation is generally best done either as close to the customer edge as possible. jms From cidr-report at potaroo.net Fri Jan 30 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Jan 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201501302200.t0UM00qm054120@wattle.apnic.net> This report has been generated at Fri Jan 30 21:14:23 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 23-01-15 534248 293832 24-01-15 533976 293841 25-01-15 534031 293632 26-01-15 533957 293791 27-01-15 534178 293992 28-01-15 534226 294290 29-01-15 535181 294664 30-01-15 535593 294944 AS Summary 49505 Number of ASes in routing system 19841 Number of ASes announcing only one prefix 3073 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120442368 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 30Jan15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 535794 295017 240777 44.9% All ASes AS22773 2933 172 2761 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2843 85 2758 97.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS6389 2891 376 2515 87.0% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS39891 2069 30 2039 98.6% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2346 313 2033 86.7% NET Servi�os de Comunica��o S.A.,BR AS3356 2572 808 1764 68.6% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2877 1283 1594 55.4% KIXS-AS-KR Korea Telecom,KR AS6147 1695 159 1536 90.6% Telefonica del Peru S.A.A.,PE AS4755 1942 458 1484 76.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7303 1774 292 1482 83.5% Telecom Argentina S.A.,AR AS9808 1524 55 1469 96.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 3073 1653 1420 46.2% Telmex Colombia S.A.,CO AS8402 1423 25 1398 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1851 523 1328 71.7% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2531 1224 1307 51.6% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1630 409 1221 74.9% TWTC - tw telecom holdings, inc.,US AS18566 2042 869 1173 57.4% MEGAPATH5-US - MegaPath Corporation,US AS9498 1297 188 1109 85.5% BBIL-AP BHARTI Airtel Ltd.,IN AS6983 1622 544 1078 66.5% ITCDELTA - Earthlink, Inc.,US AS22561 1332 265 1067 80.1% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7552 1115 53 1062 95.2% VIETEL-AS-AP Viettel Corporation,VN AS34984 1956 894 1062 54.3% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS6849 1230 169 1061 86.3% UKRTELNET JSC UKRTELECOM,UA AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 136 847 86.2% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1775 932 843 47.5% ERX-CERNET-BKB China Education and Research Network Center,CN AS8551 1094 318 776 70.9% BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone,IL AS24560 1201 426 775 64.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS26615 913 140 773 84.7% Tim Celular S.A.,BR AS4780 1075 309 766 71.3% SEEDNET Digital United Inc.,TW Total 54609 13192 41417 75.8% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.92.160.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.92.161.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.52.0.0/15 AS5650 FRONTIER-FRTR - Frontier Communications of America, Inc.,US 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 64.187.208.0/24 AS174 COGENT-174 - Cogent Communications,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.252.116.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.253.240.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 163.53.212.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.86.68.0/22 AS19672 LYNERO-AS Lynero ApS,DK 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.106.32.0/22 AS49873 -Reserved AS-,ZZ 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 30 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Jan 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201501302200.t0UM018p054135@wattle.apnic.net> BGP Update Report Interval: 22-Jan-15 -to- 29-Jan-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 291255 4.9% 1967.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS38197 275218 4.7% 228.0 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 3 - AS9829 179278 3.0% 106.3 -- BSNL-NIB National Internet Backbone,IN 4 - AS262617 96401 1.6% 5073.7 -- UWBR Telecomunica��es Ltda,BR 5 - AS53249 80442 1.4% 40221.0 -- LAWA-AS - Los Angeles World Airport,US 6 - AS53563 59128 1.0% 5912.8 -- XPLUSONE - X Plus One Solutions, Inc.,US 7 - AS23693 53806 0.9% 349.4 -- TELKOMSEL-ASN-ID PT. Telekomunikasi Selular,ID 8 - AS35908 39596 0.7% 51.8 -- VPLSNET - Krypt Technologies,US 9 - AS8402 34795 0.6% 23.7 -- CORBINA-AS OJSC "Vimpelcom",RU 10 - AS8452 32582 0.6% 20.7 -- TE-AS TE-AS,EG 11 - AS36997 29316 0.5% 888.4 -- INFOCOM-UG,UG 12 - AS10620 28018 0.5% 9.1 -- Telmex Colombia S.A.,CO 13 - AS28573 27429 0.5% 11.2 -- NET Servi�os de Comunica��o S.A.,BR 14 - AS60725 26344 0.5% 1386.5 -- O3B-AS O3b Limited,JE 15 - AS4755 23524 0.4% 12.1 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 16 - AS45899 22530 0.4% 33.0 -- VNPT-AS-VN VNPT Corp,VN 17 - AS23342 22262 0.4% 570.8 -- UNITEDLAYER - Unitedlayer, Inc.,US 18 - AS197914 21462 0.4% 7154.0 -- STOCKHO-AS Stockho Hosting SARL,FR 19 - AS48159 21303 0.4% 73.0 -- TIC-AS Telecommunication Infrastructure Company,IR 20 - AS17974 20835 0.3% 7.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS53249 80442 1.4% 40221.0 -- LAWA-AS - Los Angeles World Airport,US 2 - AS61039 15237 0.3% 15237.0 -- ZMZ OAO ZMZ,RU 3 - AS49128 13605 0.2% 13605.0 -- IVCSPBORW-AS OAO Russian Railway,RU 4 - AS197914 21462 0.4% 7154.0 -- STOCKHO-AS Stockho Hosting SARL,FR 5 - AS53563 59128 1.0% 5912.8 -- XPLUSONE - X Plus One Solutions, Inc.,US 6 - AS262617 96401 1.6% 5073.7 -- UWBR Telecomunica��es Ltda,BR 7 - AS33721 4580 0.1% 4580.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 8 - AS197368 4128 0.1% 4128.0 -- FOODCARE-AS FoodCare Sp. z o.o.,PL 9 - AS62174 3151 0.1% 3151.0 -- INTERPAN-AS INTERPAN LTD.,BG 10 - AS47680 13399 0.2% 2679.8 -- NHCS EOBO Limited,IE 11 - AS15319 2150 0.0% 2150.0 -- ENLINX-LLC - Enlinx, LLC,US 12 - AS45606 10695 0.2% 2139.0 -- 13 - AS37263 1979 0.0% 1979.0 -- UNIVEDU,GH 14 - AS23752 291255 4.9% 1967.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 15 - AS197957 1591 0.0% 1591.0 -- KERBB Ker Broadband Communications Ltd,IE 16 - AS56269 3079 0.1% 1539.5 -- ARCUSIT-PH 1007 Antel Global Corporate Center,PH 17 - AS198053 1531 0.0% 1531.0 -- AMTEL VECTRA S.A.,PL 18 - AS60725 26344 0.5% 1386.5 -- O3B-AS O3b Limited,JE 19 - AS9581 1308 0.0% 1308.0 -- TELSTRAGLOBAL-ID-AS-AP TTPL,HK 20 - AS263611 3840 0.1% 1280.0 -- BNCOM - SERVI�OS DE TELECOMUNICA��ES LTDA ME,BR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 148566 2.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 141252 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 199.38.164.0/23 59101 1.0% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 4 - 198.140.115.0/24 40240 0.7% AS53249 -- LAWA-AS - Los Angeles World Airport,US 5 - 198.140.114.0/24 40202 0.7% AS53249 -- LAWA-AS - Los Angeles World Airport,US 6 - 187.62.207.0/24 29399 0.5% AS262617 -- UWBR Telecomunica��es Ltda,BR 7 - 187.62.205.0/24 29376 0.5% AS262617 -- UWBR Telecomunica��es Ltda,BR 8 - 187.62.202.0/24 26979 0.4% AS262617 -- UWBR Telecomunica��es Ltda,BR 9 - 64.29.130.0/24 22186 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 10 - 130.0.192.0/21 21458 0.3% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 11 - 91.235.169.0/24 15237 0.2% AS61039 -- ZMZ OAO ZMZ,RU 12 - 185.26.155.0/24 13803 0.2% AS60725 -- O3B-AS O3b Limited,JE 13 - 91.212.146.0/24 13605 0.2% AS49128 -- IVCSPBORW-AS OAO Russian Railway,RU 14 - 88.87.160.0/19 13371 0.2% AS47680 -- NHCS EOBO Limited,IE 15 - 162.249.183.0/24 12379 0.2% AS60725 -- O3B-AS O3b Limited,JE 16 - 192.115.44.0/22 12117 0.2% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 17 - 192.58.232.0/24 10590 0.2% AS6629 -- NOAA-AS - NOAA,US 18 - 42.83.48.0/20 9447 0.2% AS18135 -- BTV BTV Cable television,JP 19 - 187.62.204.0/24 8293 0.1% AS262617 -- UWBR Telecomunica��es Ltda,BR 20 - 162.249.210.0/24 7970 0.1% AS27435 -- OPSOURCE-INC - Dimension Data Cloud Solutions, Inc.,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From larrysheldon at cox.net Fri Jan 30 22:13:05 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 30 Jan 2015 16:13:05 -0600 Subject: Now that's an odd failure mode... In-Reply-To: References: Message-ID: <54CC01F1.2010201@cox.net> On 1/30/2015 07:36, Valdis Kletnieks wrote: > Lauren Weinstein shared a pointer to this video of one of the stranger > failure modes I've ever seen..... > > https://www.youtube.com/watch?v=cZkAP-CQlhA It is actually an excreable add for something--runs forever, finally followd by a very old video of repairs to a microwave site occasioned by a woodpecker (or woodpeckers--not squirrels, in any case) using the enclosure to store acorns. I might have still had a valid radio license when I first saw that. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Fri Jan 30 22:23:11 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 30 Jan 2015 16:23:11 -0600 Subject: Now that's an odd failure mode... In-Reply-To: References: Message-ID: <54CC044F.4030400@cox.net> On 1/30/2015 16:13, Larry Sheldon wrote: > On 1/30/2015 07:36, Valdis Kletnieks wrote: >> Lauren Weinstein shared a pointer to this video of one of the stranger >> failure modes I've ever seen..... >> >> https://www.youtube.com/watch?v=cZkAP-CQlhA > > It is actually an execrable add for something--runs forever, finally > followed by a very old video of repairs to a microwave site occasioned by > a woodpecker (or woodpeckers--not squirrels, in any case) using the > enclosure to store acorns. > > I might have still had a valid radio license when I first saw that. Here is the clip (still maligning squirrels) without the ad: http://youtu.be/cZkAP-CQlhA -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Fri Jan 30 22:31:55 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 30 Jan 2015 16:31:55 -0600 Subject: Now that's an odd failure mode... In-Reply-To: References: Message-ID: <54CC065B.1030507@cox.net> On 1/30/2015 16:23, Larry Sheldon wrote: > On 1/30/2015 16:13, Larry Sheldon wrote: >> On 1/30/2015 07:36, Valdis Kletnieks wrote: >>> Lauren Weinstein shared a pointer to this video of one of the stranger >>> failure modes I've ever seen..... >>> >>> https://www.youtube.com/watch?v=cZkAP-CQlhA >> >> It is actually an execrable add for something--runs forever, finally >> followed by a very old video of repairs to a microwave site occasioned by >> a woodpecker (or woodpeckers--not squirrels, in any case) using the >> enclosure to store acorns. >> >> I might have still had a valid radio license when I first saw that. > > Here is the clip (still maligning squirrels) without the ad: > > http://youtu.be/cZkAP-CQlhA The questions that have always intrigued me about the clip: Who made the hole and how long did it take (assumption is "woodpeckers made it" but I have no idea how long it took to make the hole).) HOW did they make it--seems like it would have been like making a hole in a bass drum with a finger (lot of bounce, not much cut)? How long did it take to put that many in, and how many worked on the project? Why didn't some alarm or path measurement disclose the deterioration before the cavity was packed so full? Were the acorns cooked? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From tagno25 at gmail.com Fri Jan 30 22:47:50 2015 From: tagno25 at gmail.com (Philip Dorr) Date: Fri, 30 Jan 2015 16:47:50 -0600 Subject: Now that's an odd failure mode... In-Reply-To: <54CC065B.1030507@cox.net> References: <54CC065B.1030507@cox.net> Message-ID: In this case the cover is a thin, but ridged peice of plastic. It is possible that the link stayed up until it rained and the acorns absorbed water coming in through the hole. On Jan 30, 2015 4:33 PM, "Larry Sheldon" wrote: > On 1/30/2015 16:23, Larry Sheldon wrote: > >> On 1/30/2015 16:13, Larry Sheldon wrote: >> >>> On 1/30/2015 07:36, Valdis Kletnieks wrote: >>> >>>> Lauren Weinstein shared a pointer to this video of one of the stranger >>>> failure modes I've ever seen..... >>>> >>>> https://www.youtube.com/watch?v=cZkAP-CQlhA >>>> >>> >>> It is actually an execrable add for something--runs forever, finally >>> followed by a very old video of repairs to a microwave site occasioned by >>> a woodpecker (or woodpeckers--not squirrels, in any case) using the >>> enclosure to store acorns. >>> >>> I might have still had a valid radio license when I first saw that. >>> >> >> Here is the clip (still maligning squirrels) without the ad: >> >> http://youtu.be/cZkAP-CQlhA >> > > The questions that have always intrigued me about the clip: > > Who made the hole and how long did it take (assumption is "woodpeckers > made it" but I have no idea how long it took to make the hole).) > > HOW did they make it--seems like it would have been like making a hole in > a bass drum with a finger (lot of bounce, not much cut)? > > How long did it take to put that many in, and how many worked on the > project? > > Why didn't some alarm or path measurement disclose the deterioration > before the cavity was packed so full? > > Were the acorns cooked? > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes > From gary.buhrmaster at gmail.com Fri Jan 30 23:12:56 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 30 Jan 2015 23:12:56 +0000 Subject: Now that's an odd failure mode... In-Reply-To: <54CC065B.1030507@cox.net> References: <54CC065B.1030507@cox.net> Message-ID: On Fri, Jan 30, 2015 at 10:31 PM, Larry Sheldon wrote: ..... > HOW did they make it.... Maybe the woodpecker had a little help... Obligatory Friday xkcd ref: http://xkcd.com/614/ From math at sizone.org Fri Jan 30 23:18:06 2015 From: math at sizone.org (Ken Chase) Date: Fri, 30 Jan 2015 18:18:06 -0500 Subject: Now that's an odd failure mode... In-Reply-To: References: <54CC065B.1030507@cox.net> Message-ID: <20150130231806.GV24849@sizone.org> This one time, at band camp, a guy had pigeons get into his pop and sit on the warm ciscos til they gummed up the fans with coredumps til failure was achieved. But that might just be a Dalph rumour. /kc On Fri, Jan 30, 2015 at 11:12:56PM +0000, Gary Buhrmaster said: >On Fri, Jan 30, 2015 at 10:31 PM, Larry Sheldon wrote: >..... >> HOW did they make it.... > >Maybe the woodpecker had a little help... >Obligatory Friday xkcd ref: http://xkcd.com/614/ -- Ken Chase - math at sizone.org Toronto From jay at west.net Fri Jan 30 23:20:17 2015 From: jay at west.net (Jay Hennigan) Date: Fri, 30 Jan 2015 15:20:17 -0800 Subject: Now that's an odd failure mode... In-Reply-To: <54CC065B.1030507@cox.net> References: <54CC065B.1030507@cox.net> Message-ID: <54CC11B1.2070500@west.net> On 1/30/15 14:31, Larry Sheldon wrote: > The questions that have always intrigued me about the clip: > > Who made the hole and how long did it take (assumption is "woodpeckers > made it" but I have no idea how long it took to make the hole).) Most likely the woodpeckers, maybe helped by natural deterioration of the radome material or a defect in manufacture or installation or both. > HOW did they make it--seems like it would have been like making a hole > in a bass drum with a finger (lot of bounce, not much cut)? They pecked it. They can go pretty deeply into trees, and at the edge of the cover there wouldn't be much bounce. > How long did it take to put that many in, and how many worked on the > project? Unknown, but probably a long time, that's a lot of acorns! > Why didn't some alarm or path measurement disclose the deterioration > before the cavity was packed so full? I'm sure it did, over a period of months or years the signal strength would gradually go down as the dish filled up. No immediately obvious cause, this would be a real puzzler. There's typically a pretty good fade margin built in to such links, so it would be a very slowly decreasing RSSI coupled with likely a hockey-stick graph increase in BER as the dish got fuller. Depending on the RF frequency, could get worse with rain as the fade margin decreased. It may have been discovered accidentally if a tech happened to observe a bird while troubleshooting. Filling half the dish would be only a 3dB decrease, but once the acorns started to cover the feedhorn it probably got worse in a relative hurry. I have no idea of the dielectric properties of an acorn, it would probably vary depending on the moisture content and the RF wavelength relative to the size of the acorn. ;-) > Were the acorns cooked? Probably not. RF output likely a watt or two, spread out over a large area and several tens of thousands of acorns. -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From eric at ericheather.com Fri Jan 30 23:28:42 2015 From: eric at ericheather.com (Eric C. Miller) Date: Fri, 30 Jan 2015 23:28:42 +0000 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: +1 Xirrus, especially for the multi radio arrays. Crowded common areas benefit from sector antennas attached to individual radios. Also, there XMS server is really useful for managing a large cluster. Ubiquiti UniFi is good for smaller installations, but I wouldn't trust them for enterprise level reliability. Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Lyon Sent: Thursday, January 29, 2015 12:17 AM To: Manuel Marín Cc: NANOG Subject: Re: Recommended wireless AP for 400 users office Check out Xirrus On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: > Dear nanog community > > I was wondering if you can recommend or share your experience with APs > that you can use in locations that have 300-500 users. I friend > recommended me Ruckus Wireless, it would be great if you can share > your experience with Ruckus or with a similar vendor. My experience > with ubiquity for this type of requirement was not that good. > > Thank you and have a great day > From baldur.norddahl at gmail.com Sat Jan 31 00:54:53 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 31 Jan 2015 01:54:53 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <20150130212335.568df5a0@envy.fud.no> References: <20150130174453.485e9105@envy.fud.no> <20150130194628.08ba77a2@envy.fud.no> <20150130212335.568df5a0@envy.fud.no> Message-ID: We are talking about different things. If your business is servers, do whatever you want. If you are in the business of selling internet, which quite a few are on this mailinglist, you need to be dual stack. We are dual stack towards our customers. On our internal network we are single stack - ipv4 only. This is a new build. Why? Because half of our equipment does not support ipv6 management and even some of the network protocols will not function without ipv4 (MPLS). Adding ipv6 to the internal network seems to have no purpose. It is all private address space with not even NAT. The internal network is not directly connected to the internet, so there is no need. Regards, Baldur Den 30/01/2015 21.23 skrev "Tore Anderson" : > * Baldur Norddahl > > > Single stacking on IPv6 is nice in theory. In practice it just doesn't > work > > yet. If you as an ISP tried to force all your customers to be IPv6 single > > stack, you would go bust. > > Kabel Deutschland, T-Mobile USA, and Facebook are examples of companies > who have already or are in the process of moving their network > infrastructure to IPv6-only. Without going bust. > > What you *do* need, is some form of connectivity to the IPv4 internet. > But there are smarter ways to do that than dual stack. Seriously, if > you're building a network today, consider making IPv4 a legacy "app" or > service running on top of an otherwise IPv6-only infrastructure. Five > years down the road you'll thank me for the tip. :-) > > Tore > From elouie at techintegrity.com Sat Jan 31 01:05:37 2015 From: elouie at techintegrity.com (Eric Louie) Date: Fri, 30 Jan 2015 17:05:37 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> <20150130194628.08ba77a2@envy.fud.no> <20150130212335.568df5a0@envy.fud.no> Message-ID: And, we're in sort of the same predicament - I have no choice on the current infrastructure but to run IPv4. IPv6 is a service we would like to start to offer to new customers in this current infrastructure. And to existing customers who believe that they have the need for IPv6 and have the equipment in their network to support it. We may end up as IPv6-only on the customer side in new markets because we don't have enough PUBLIC IPv4 address space to support a new market, but that will STILL require private IPv4 for management and monitoring of the equipment that does not support IPv6 yet. (and yes, there's a lot of equipment that is greater than 2 years old that still works and that does not support IPv6) eric at techintegrity dot com 619-335-8148 voice & text www.techintegrity.com ericlouie on Twitter On Fri, Jan 30, 2015 at 4:54 PM, Baldur Norddahl wrote: > We are talking about different things. If your business is servers, do > whatever you want. If you are in the business of selling internet, which > quite a few are on this mailinglist, you need to be dual stack. > > We are dual stack towards our customers. On our internal network we are > single stack - ipv4 only. This is a new build. Why? Because half of our > equipment does not support ipv6 management and even some of the network > protocols will not function without ipv4 (MPLS). Adding ipv6 to the > internal network seems to have no purpose. It is all private address space > with not even NAT. The internal network is not directly connected to the > internet, so there is no need. > > Regards, > > Baldur > Den 30/01/2015 21.23 skrev "Tore Anderson" : > > > * Baldur Norddahl > > > > > Single stacking on IPv6 is nice in theory. In practice it just doesn't > > work > > > yet. If you as an ISP tried to force all your customers to be IPv6 > single > > > stack, you would go bust. > > > > Kabel Deutschland, T-Mobile USA, and Facebook are examples of companies > > who have already or are in the process of moving their network > > infrastructure to IPv6-only. Without going bust. > > > > What you *do* need, is some form of connectivity to the IPv4 internet. > > But there are smarter ways to do that than dual stack. Seriously, if > > you're building a network today, consider making IPv4 a legacy "app" or > > service running on top of an otherwise IPv6-only infrastructure. Five > > years down the road you'll thank me for the tip. :-) > > > > Tore > > > From owen at delong.com Sat Jan 31 01:32:27 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Jan 2015 17:32:27 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: > On Jan 30, 2015, at 07:12 , Karsten Elfenbein wrote: > > Hi, > > 2015-01-30 0:28 GMT+01:00 Eric Louie : >> I'm putting together my first IPv6 allocation plan. The general layout: >> /48 for customers universally and uniformly >> /38 for larger regions on an even (/37) boundary >> /39 for smaller regions on an even (/38) boundary >> A few /48's for "internal use" to allow us to monitor and maintain systems. > > Depending on how many regions you have I would just go for /40 as it > is the byte boundary or request a bigger block and use the /32. Given that ARIN policy allows you two levels of nibble-round-up, I’d suggest putting your regions all at /36, actually, assuming you have enough customers in your largest region to justify more than 75% of a /40 (which I assume to be the case given the limited information provided). Don’t make your network fit inside a /32 if it doesn’t fit conveniently. Get a /28 instead. > >> For security sake, do I need (am I better off) to "reserve" a "management >> block" (/39, /40, /41 or something of that nature) that does NOT get >> advertised into BGP to my upstreams, and use that for my device management >> and monitoring address space? In other words, make a small "private" >> address space for management? What are folks doing around that? > > Do not spam the BGP table for that. Use firewalls or ACLs to prevent > unwanted access. Exactly! > You could use Unique Local addresses (ULA) for this if you have some > VPN infrastructure in your network. But only if you are truly a masochist. It’s so much easier to do this with GUA and filters. > Not announcing these blocks does not prevent people on your network to > access these areas. Among other various issues with using announcement control in lieu of actual security policy. >> If I have to do 6-to-4 conversion, is there any way to do that with >> multiple diverse ISP connections, or am I "restricted" to using one >> entry/exit point? (If that's true, do I need to allocate a separate block >> of addresses that would be designated "6 to 4" so they'd always be routed >> out that one entry/exit point?) > > I would not use 6to4 as it tunnels the IPv6 traffic over IPv4 which is > a pain to control. 6to4 is in the process of being moved to historic status in the IETF for good reason. If you’re deploying real IPv6, there’s no need to add any 6to4 headaches into your environment. At its best, 6to4 was for people who couldn’t get real IPv6 transport. Today, it’s mostly an anachronism. Owen From owen at delong.com Sat Jan 31 01:37:24 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Jan 2015 17:37:24 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: <6D484C0A-8BB8-4145-AC95-2F9C9D8961CD@delong.com> > On Jan 30, 2015, at 07:51 , William Herrin wrote: > > On Thu, Jan 29, 2015 at 6:28 PM, Eric Louie wrote: >> I'm putting together my first IPv6 allocation plan. The general layout: >> /48 for customers universally and uniformly > > Hi Eric, > > Good luck with that. Personally, I'd be inclined to think that some > customers will (reasonably) want more than a /48 and I'd be in less of > a rush to burn through my /32 for the sake of customers who would have > been perfectly happy with a /56. The only deliberately static sizes > I'd endorse is /64 for an ethernet LAN and the 4-bit nibble boundary > for any delegations. > Yes and no. First, assuming you are limited to a /32 is absurd. I’ve personally helped multiple organizations obtain various size allocations ranging from /32 to /24 with little or no difficulty so long as the size of the network warranted it. (The biggest challenge was a large organization that I had to work at showing ARIN was, in fact, an ISP and not merely an end-user. They got a /24. In fairness to ARIN, it took me a while to realize myself that they were an ISP before I approached ARIN. It was an odd situation.) /48 for all customer sites is not at all unreasonable and is fully supported by ARIN policy. Where Bill is correct is that some customers may have more than one site. The official policy definition of a site is a single building or structure, or, in the case of a multi-tenant building or structure, a single tenant within that building. Yes, this could technically mean that a college dorm contains thousands of sites and could justify thousands of /48s. Owen From hartleyc at gmail.com Sat Jan 31 01:00:08 2015 From: hartleyc at gmail.com (Chris Hartley) Date: Fri, 30 Jan 2015 20:00:08 -0500 Subject: Now that's an odd failure mode... In-Reply-To: <54CC11B1.2070500@west.net> References: <54CC065B.1030507@cox.net> <54CC11B1.2070500@west.net> Message-ID: At OARNet, the leading cause of aerial fiber outages was squirrels, followed closely by weather, distantly by angry farmers and once in Akron, random gunfire... At OSU, the leading cause of fiber outages is squirrels, followed distantly by fire. Somewhere I have a great picture of a squirrel gnawing on a fiber that's illuminated with a red visible laser. Don't squirrels go back to their stash? Could a squirrel get through that hole, or were those just a lost stash? On Fri, Jan 30, 2015 at 6:20 PM, Jay Hennigan wrote: > On 1/30/15 14:31, Larry Sheldon wrote: > > > The questions that have always intrigued me about the clip: > > > > Who made the hole and how long did it take (assumption is "woodpeckers > > made it" but I have no idea how long it took to make the hole).) > > Most likely the woodpeckers, maybe helped by natural deterioration of > the radome material or a defect in manufacture or installation or both. > > > HOW did they make it--seems like it would have been like making a hole > > in a bass drum with a finger (lot of bounce, not much cut)? > > They pecked it. They can go pretty deeply into trees, and at the edge of > the cover there wouldn't be much bounce. > > > How long did it take to put that many in, and how many worked on the > > project? > > Unknown, but probably a long time, that's a lot of acorns! > > > Why didn't some alarm or path measurement disclose the deterioration > > before the cavity was packed so full? > > I'm sure it did, over a period of months or years the signal strength > would gradually go down as the dish filled up. No immediately obvious > cause, this would be a real puzzler. There's typically a pretty good > fade margin built in to such links, so it would be a very slowly > decreasing RSSI coupled with likely a hockey-stick graph increase in BER > as the dish got fuller. Depending on the RF frequency, could get worse > with rain as the fade margin decreased. It may have been discovered > accidentally if a tech happened to observe a bird while troubleshooting. > > Filling half the dish would be only a 3dB decrease, but once the acorns > started to cover the feedhorn it probably got worse in a relative hurry. > I have no idea of the dielectric properties of an acorn, it would > probably vary depending on the moisture content and the RF wavelength > relative to the size of the acorn. ;-) > > > Were the acorns cooked? > > Probably not. RF output likely a watt or two, spread out over a large > area and several tens of thousands of acorns. > > -- > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From owen at delong.com Sat Jan 31 01:44:30 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Jan 2015 17:44:30 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> Message-ID: > On Jan 30, 2015, at 09:39 , William Herrin wrote: > > On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson wrote: >> * William Herrin >> >>> Plan on dual-stacking any network which requires >>> access to IPv4 resources such as the public Internet. >> >> For many folks, that's easier said than done. >> >> Think about it: If everyone could just dual-stack their networks, they >> might as well single-stack them on IPv4 instead; there would be no >> point whatsoever in transitioning to IPv6 for anyone. > > Hi Tore, > > That's what NAT is for. Use RFC 1918 space for end users, RFC 6598 > space for ISPs. And here I thought NAT was merely a tool used by sadists to satisfy masochists. Oh, wait… We’re saying the same thing. > Plan on dual-stacking until IPv6 deployment is ubiquitous. Which won't > be this year. Or next. I think you’re right about this year, Not completely sure about next year. Current growth rates in the two protocols suggest at least that there will be more devices with unique IPv6 addresses than IPv4 addresses somewhere in the latter half of next year. I guess it depends on your definition of ubiquitous, but to me, when a protocol has the majority of the deployed addresses, I think it counts for this purpose. Owen From bill at herrin.us Sat Jan 31 02:07:25 2015 From: bill at herrin.us (William Herrin) Date: Fri, 30 Jan 2015 21:07:25 -0500 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> Message-ID: On Fri, Jan 30, 2015 at 8:44 PM, Owen DeLong wrote: > I guess it depends on your definition of ubiquitous, but to me, when a protocol > has the majority of the deployed addresses, I think it counts for this purpose. LOL, Owen, IPv6 had that with the first /64 ethernet LAN it was used on. How about this: when Verizon starts decommissioning its IPv4 infrastructure on the basis that IPv6 is widespread enough to no longer require the expense of dual-stack, IPv6 will have achieved ubiquity. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From Valdis.Kletnieks at vt.edu Sat Jan 31 02:48:32 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 30 Jan 2015 21:48:32 -0500 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: Your message of "Fri, 30 Jan 2015 21:07:25 -0500." References: <20150130174453.485e9105@envy.fud.no> Message-ID: <3850.1422672512@turing-police.cc.vt.edu> On Fri, 30 Jan 2015 21:07:25 -0500, William Herrin said: > How about this: when Verizon starts decommissioning its IPv4 > infrastructure on the basis that IPv6 is widespread enough to no > longer require the expense of dual-stack, IPv6 will have achieved > ubiquity. Using that logic, what does Verizon FIOS tell us about US broadband? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From owen at delong.com Sat Jan 31 02:49:45 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Jan 2015 18:49:45 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> Message-ID: > On Jan 30, 2015, at 18:07 , William Herrin wrote: > > On Fri, Jan 30, 2015 at 8:44 PM, Owen DeLong wrote: >> I guess it depends on your definition of ubiquitous, but to me, when a protocol >> has the majority of the deployed addresses, I think it counts for this purpose. > > LOL, Owen, IPv6 had that with the first /64 ethernet LAN it was used on. If you want to nit-pick, by “deployed addresses”, I mean addresses actually deployed on hosts and being used for cummunications. This was a really stupid nit, even for you. > How about this: when Verizon starts decommissioning its IPv4 > infrastructure on the basis that IPv6 is widespread enough to no > longer require the expense of dual-stack, IPv6 will have achieved > ubiquity. Um, no. The judgment of one traditional telephone company is hardly where I would look to contemplate the future of the internet. Heck, to a large degree, Verizon hasn’t even figured out how to do IPv6 for FIOS customers yet, let alone their DSL subscribers. Really not the shining example I would turn to. No. Certainly not the worst, but definitely not the leader, either. Owen From bill at herrin.us Sat Jan 31 03:29:39 2015 From: bill at herrin.us (William Herrin) Date: Fri, 30 Jan 2015 22:29:39 -0500 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <3850.1422672512@turing-police.cc.vt.edu> References: <20150130174453.485e9105@envy.fud.no> <3850.1422672512@turing-police.cc.vt.edu> Message-ID: On Fri, Jan 30, 2015 at 9:48 PM, wrote: > On Fri, 30 Jan 2015 21:07:25 -0500, William Herrin said: > >> How about this: when Verizon starts decommissioning its IPv4 >> infrastructure on the basis that IPv6 is widespread enough to no >> longer require the expense of dual-stack, IPv6 will have achieved >> ubiquity. > > Using that logic, what does Verizon FIOS tell us about US broadband? I don't know but tonight the 100 ms lag is really pissing me off. 3 T1-3-0-4.WASHDC-LCR-22.verizon-gni.net (130.81.221.218) 5.268 ms 5.316 ms 5.556 ms 4 * * * 5 0.ae2.BR1.IAD8.ALTER.NET (140.222.229.165) 6.985 ms 10.824 ms 11.039 ms 6 xe-2-1-0.er2.iad10.us.zip.zayo.com (64.125.13.173) 92.949 ms 91.437 ms 91.660 ms 5 xe-4-0-0.cr2.dca2.us.zip.zayo.com (64.125.31.118) 2.008 ms 2.038 ms 1.841 ms 6 ae1.er2.iad10.us.zip.zayo.com (64.125.20.122) 2.484 ms 2.411 ms 2.685 ms 7 zayo-vzb.iad10.us.zip.zayo.com (64.125.13.174) 94.578 ms 94.839 ms 94.589 ms 8 xe-0-3-0-0.WASHDC-VFTTP-312.verizon-gni.net (130.81.221.217) 101.677 ms 101.670 ms 101.593 ms -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From cma at cmadams.net Sat Jan 31 05:37:28 2015 From: cma at cmadams.net (Chris Adams) Date: Fri, 30 Jan 2015 23:37:28 -0600 Subject: Now that's an odd failure mode... In-Reply-To: References: <54CC065B.1030507@cox.net> <54CC11B1.2070500@west.net> Message-ID: <20150131053728.GB23922@cmadams.net> Once upon a time, Chris Hartley said: > At OARNet, the leading cause of aerial fiber outages was squirrels, > followed closely by weather, distantly by angry farmers and once in Akron, > random gunfire... At OSU, the leading cause of fiber outages is squirrels, > followed distantly by fire. What about the random moron trying to steal copper wire from the pole (and getting glass instead)? > Don't squirrels go back to their stash? Could a squirrel get through that > hole, or were those just a lost stash? Eh, if the number of small oak trees I find sprouting in my flower beds is any indication, the squirrels' brains are smaller than the acorns and they forget where they left them. -- Chris Adams From randy.fischer at gmail.com Sat Jan 31 07:36:43 2015 From: randy.fischer at gmail.com (Randy Fischer) Date: Sat, 31 Jan 2015 02:36:43 -0500 Subject: Now that's an odd failure mode... In-Reply-To: <33795.1422624985@turing-police.cc.vt.edu> References: <33795.1422624985@turing-police.cc.vt.edu> Message-ID: Well, y'all probably too young to have read http://www.csmonitor.com/1990/0302/utwain.html - and then it's a bluejay yarn - the woodpeckers hereabout aren't so industrious, I've noticed. -Rand Fischer On Fri, Jan 30, 2015 at 8:36 AM, Valdis Kletnieks wrote: > Lauren Weinstein shared a pointer to this video of one of the stranger > failure modes I've ever seen..... > > https://www.youtube.com/watch?v=cZkAP-CQlhA > From joelja at bogus.com Sat Jan 31 07:39:49 2015 From: joelja at bogus.com (joel jaeggli) Date: Fri, 30 Jan 2015 23:39:49 -0800 Subject: Now that's an odd failure mode... In-Reply-To: <20150131053728.GB23922@cmadams.net> References: <54CC065B.1030507@cox.net> <54CC11B1.2070500@west.net> <20150131053728.GB23922@cmadams.net> Message-ID: <54CC86C5.2060708@bogus.com> On 1/30/15 9:37 PM, Chris Adams wrote: >> Don't squirrels go back to their stash? Could a squirrel get through that >> hole, or were those just a lost stash? > > Eh, if the number of small oak trees I find sprouting in my flower beds > is any indication, the squirrels' brains are smaller than the acorns and > they forget where they left them. The oak tree has successfully resisted domestication for the last 20,000 years because it doesn't need us, the thing with the squirrel has worked out pretty well. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From nanog at ics-il.net Sat Jan 31 16:25:00 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 31 Jan 2015 10:25:00 -0600 (CST) Subject: Indiana Dark Fiber In-Reply-To: <28396930.6942.1422720983076.JavaMail.mhammett@ThunderFuck> Message-ID: <11088525.6972.1422721460950.JavaMail.mhammett@ThunderFuck> Any recommendations for dark fiber between Indianapolis and Fort Wayne? I see a few routes, but that doesn't mean they actually sell dark fiber. The company that we've partnered with asked a couple companies (Zayo, IFN and one of the Time Warners) and came up short. Seems odd because Zayo lists dark fiber routes to within 1.5 miles of the Fort Wayne location, but figured I'd look to see what companies I was missing that actually did dark fiber. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From jra at baylink.com Sat Jan 31 16:31:16 2015 From: jra at baylink.com (Jay Ashworth) Date: Sat, 31 Jan 2015 11:31:16 -0500 (EST) Subject: Network ops lists. In-Reply-To: Message-ID: <28046148.1567.1422721876435.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Alex Brooks" > As has been mentioned, there are also a few special purpose > non-geographic lists around. Voiceops for VoIP > (http://www.voiceops.org/), DC-Ops for Data Centre operation > discussion (https://puck.nether.net/mailman/listinfo/dc-ops), Wouldn't it be pretty to think so. DC-ops, while a wonderful idea, has had no live traffic in the last 2 years... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jason at unlimitednet.us Sat Jan 31 21:37:05 2015 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 31 Jan 2015 16:37:05 -0500 Subject: Indiana Dark Fiber In-Reply-To: <11088525.6972.1422721460950.JavaMail.mhammett@ThunderFuck> References: <11088525.6972.1422721460950.JavaMail.mhammett@ThunderFuck> Message-ID: Hi Mike, Have you checked with Axia Technology Partners? www.axiatp.com They have fiber throughout Indiana. Doubtful they have their own dark fiber from Indy to Ft Wayne, but worth checking into! -- Jason Canady Unlimited Net, LLC www.unlimitednet.us twitter: @unlimitednet On Jan 31, 2015, at 11:25, Mike Hammett wrote: > Any recommendations for dark fiber between Indianapolis and Fort Wayne? I see a few routes, but that doesn't mean they actually sell dark fiber. The company that we've partnered with asked a couple companies (Zayo, IFN and one of the Time Warners) and came up short. Seems odd because Zayo lists dark fiber routes to within 1.5 miles of the Fort Wayne location, but figured I'd look to see what companies I was missing that actually did dark fiber. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > From joelja at bogus.com Sat Jan 31 20:21:43 2015 From: joelja at bogus.com (joel jaeggli) Date: Sat, 31 Jan 2015 12:21:43 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: <54CD3957.1000706@bogus.com> On 1/30/15 8:29 AM, Justin M. Streiner wrote: > On Fri, 30 Jan 2015, Eric Louie wrote: > >> It also sounds like the Internet (aka the upstream/Tier 1 carriers) don't >> want me to advertise anything longer than my /32 into BGPv6. Is that >> true? >> (I'm getting that from the spamming comments made by others) Am I >> supposed to be asking ARIN for a /32 for each region that I want to >> address? (They turned down my request for an increase to a /28 last >> year) > > Not true. A peek at the global IPv6 routing table shows lots of > prefixes that are smaller than /32. One of the hopes with larger > allocations and assignments was that there would be less bloat in the > global IPv6 routing table because networks would need to announce fewer > prefixes. How well that will hold up in practice remains to be seen :) Direct assignments exist down to /48s so you can expect to have to accept announcements down to that size given that they can't concievably be covered by an aggregate. >> As far as the v6 to v4 translation is concerned, I'm looking at that for >> the future - for the time being, we will be dual-stacked. However, if we >> move into a new area, based on our current IPv4 inventory, I don't really >> have enough to assign to each new customer, so I was looking for ways to >> allow those customers access to properties that are still IPv4 only. Is >> there yet another way to do that? > > If you assign a customer IPv6 space only, a translation mechanism is > needed to allow that customer to reach Internet destinations that only > speak IPv4 today. There's no way around that. > > jms > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: