From wilhelm at ripe.net Sun Dec 1 00:19:14 2013 From: wilhelm at ripe.net (Rene Wilhelm) Date: Sun, 01 Dec 2013 01:19:14 +0100 Subject: bgp traceroute tool? In-Reply-To: References: Message-ID: <529A8082.8040908@ripe.net> On 11/30/13 1:18 AM, Lee Clark wrote: > The traceroute variant included with CentOS 6.4 & Mint 13 has an -A > flag which does ASN lookups. ntraceroute on FreeBSD supports it as > well. I believe the Linux port is traceroute-nanog. > > Lee traceroute -A consults the internet routing registry which is know to beincomplete and at times incorrect when it comes to IP to BGP origin AS mapping. For this reason we developed riswhois.ripe.net, a whois style interface to the BGP data collected by RIPE NCC's Routing information service (http://www.ripe.net/data-tools/stats/ris) Reporting in the same format as the IRR, riswhois is plugin compatible with whois.radb.net. If your linux traceroutederives from http://traceroute.sourceforge.net/ all it takes to switch to using true BGP info in traceroute is setting the environment variable RA_SERVER to "riswhois.ripe.net" -- Rene P.S. the LFT tool metioned earlier in this thread can also use RISwhois to lookup ASNs; just pass it the -r option on the command line. > > > [user at box ~]# traceroute -V Modern traceroute for Linux, version > 2.0.14, Nov 11 2010 Copyright (c) 2008 Dmitry Butskoy, License: > GPL v2 or any later > > [user at box ~]# traceroute -A www.google.ca traceroute to www.google.ca > (74.125.226.127), 30 hops max, 60 byte packets 6 72.14.197.33 > (72.14.197.33) [AS15169] 73.927 ms 69.254 ms69.305 ms 7 > 209.85.254.130 (209.85.254.130) [AS15169] 69.436 ms 209.85.254.122 > (209.85.254.122) [AS15169] 79.554 ms 64.269 ms 872.14.237.130 > (72.14.237.130) [AS15169] 64.979 ms 65.975 ms 209.85.254.238 > (209.85.254.238) [AS15169] 66.700 ms 9216.239.46.161 > (216.239.46.161) [AS15169] 71.293 ms 72.251 ms73.521 ms 10 > 209.85.250.207 (209.85.250.207) [AS15169] 74.454 ms 74.920 ms > 75.889 ms 11 yyz08s13-in-f31.1e100.net (74.125.226.127) [AS15169] > 76.628 ms 77.105 ms 70.928 ms > > > -----Original Message----- From: John Conner > [mailto:bs7799 at gmail.com] Sent: Friday, November 29, 2013 5:04 PM To: > nanog at nanog.org Subject: bgp traceroute tool? > > Hi there, is there any tools available under linux which can do bgp > traceroute? (print bgp AS numbers for each traceroute hop ) , i > googled and found nothing. > > thanks > > John > > From jason at lixfeld.ca Sun Dec 1 00:58:54 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Sat, 30 Nov 2013 19:58:54 -0500 Subject: bgp traceroute tool? In-Reply-To: <529A8082.8040908@ripe.net> References: <529A8082.8040908@ripe.net> Message-ID: It would be slick if someone could patch mtr to do this too. Sent from my iPhone > On Nov 30, 2013, at 7:19 PM, Rene Wilhelm wrote: > > >> On 11/30/13 1:18 AM, Lee Clark wrote: >> The traceroute variant included with CentOS 6.4 & Mint 13 has an -A > > flag which does ASN lookups. ntraceroute on FreeBSD supports it as > > well. I believe the Linux port is traceroute-nanog. > > > > Lee > > traceroute -A consults the internet routing registry which is know > to beincomplete and at times incorrect when it comes to IP to > BGP origin AS mapping. For this reason we developed riswhois.ripe.net, > a whois style interface to the BGP data collected by RIPE NCC's Routing > information service (http://www.ripe.net/data-tools/stats/ris) > > Reporting in the same format as the IRR, riswhois is plugin > compatible with whois.radb.net. If your linux traceroutederives > from http://traceroute.sourceforge.net/ all it takes to switch to > using true BGP info in traceroute is setting the environment variable > RA_SERVER to "riswhois.ripe.net" > > > -- Rene > > P.S. the LFT tool metioned earlier in this thread can also use RISwhois > to lookup ASNs; just pass it the -r option on the command line. > > >> >> >> [user at box ~]# traceroute -V Modern traceroute for Linux, version >> 2.0.14, Nov 11 2010 Copyright (c) 2008 Dmitry Butskoy, License: >> GPL v2 or any later >> >> [user at box ~]# traceroute -A www.google.ca traceroute to www.google.ca >> (74.125.226.127), 30 hops max, 60 byte packets 6 72.14.197.33 >> (72.14.197.33) [AS15169] 73.927 ms 69.254 ms69.305 ms 7 >> 209.85.254.130 (209.85.254.130) [AS15169] 69.436 ms 209.85.254.122 >> (209.85.254.122) [AS15169] 79.554 ms 64.269 ms 872.14.237.130 >> (72.14.237.130) [AS15169] 64.979 ms 65.975 ms 209.85.254.238 >> (209.85.254.238) [AS15169] 66.700 ms 9216.239.46.161 >> (216.239.46.161) [AS15169] 71.293 ms 72.251 ms73.521 ms 10 >> 209.85.250.207 (209.85.250.207) [AS15169] 74.454 ms 74.920 ms >> 75.889 ms 11 yyz08s13-in-f31.1e100.net (74.125.226.127) [AS15169] >> 76.628 ms 77.105 ms 70.928 ms > > > > > > -----Original Message----- From: John Conner > > [mailto:bs7799 at gmail.com] Sent: Friday, November 29, 2013 5:04 PM To: > > nanog at nanog.org Subject: bgp traceroute tool? > > > > Hi there, is there any tools available under linux which can do bgp > > traceroute? (print bgp AS numbers for each traceroute hop ) , i > > googled and found nothing. > > > > thanks > > > > John > > > > > > > From jason at unlimitednet.us Sun Dec 1 02:04:40 2013 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 30 Nov 2013 21:04:40 -0500 Subject: bgp traceroute tool? In-Reply-To: References: <529A8082.8040908@ripe.net> Message-ID: I agree, ASN lookup in mtr would be awesome! I'll have to look into that sometime. Jason On Nov 30, 2013, at 19:58, Jason Lixfeld wrote: > It would be slick if someone could patch mtr to do this too. > > Sent from my iPhone > >> On Nov 30, 2013, at 7:19 PM, Rene Wilhelm wrote: >> >> >>> On 11/30/13 1:18 AM, Lee Clark wrote: >>> The traceroute variant included with CentOS 6.4 & Mint 13 has an -A >>> flag which does ASN lookups. ntraceroute on FreeBSD supports it as >>> well. I believe the Linux port is traceroute-nanog. >>> >>> Lee >> >> traceroute -A consults the internet routing registry which is know >> to beincomplete and at times incorrect when it comes to IP to >> BGP origin AS mapping. For this reason we developed riswhois.ripe.net, >> a whois style interface to the BGP data collected by RIPE NCC's Routing >> information service (http://www.ripe.net/data-tools/stats/ris) >> >> Reporting in the same format as the IRR, riswhois is plugin >> compatible with whois.radb.net. If your linux traceroutederives >> from http://traceroute.sourceforge.net/ all it takes to switch to >> using true BGP info in traceroute is setting the environment variable >> RA_SERVER to "riswhois.ripe.net" >> >> >> -- Rene >> >> P.S. the LFT tool metioned earlier in this thread can also use RISwhois >> to lookup ASNs; just pass it the -r option on the command line. >> >> >>> >>> >>> [user at box ~]# traceroute -V Modern traceroute for Linux, version >>> 2.0.14, Nov 11 2010 Copyright (c) 2008 Dmitry Butskoy, License: >>> GPL v2 or any later >>> >>> [user at box ~]# traceroute -A www.google.ca traceroute to www.google.ca >>> (74.125.226.127), 30 hops max, 60 byte packets 6 72.14.197.33 >>> (72.14.197.33) [AS15169] 73.927 ms 69.254 ms69.305 ms 7 >>> 209.85.254.130 (209.85.254.130) [AS15169] 69.436 ms 209.85.254.122 >>> (209.85.254.122) [AS15169] 79.554 ms 64.269 ms 872.14.237.130 >>> (72.14.237.130) [AS15169] 64.979 ms 65.975 ms 209.85.254.238 >>> (209.85.254.238) [AS15169] 66.700 ms 9216.239.46.161 >>> (216.239.46.161) [AS15169] 71.293 ms 72.251 ms73.521 ms 10 >>> 209.85.250.207 (209.85.250.207) [AS15169] 74.454 ms 74.920 ms >>> 75.889 ms 11 yyz08s13-in-f31.1e100.net (74.125.226.127) [AS15169] >>> 76.628 ms 77.105 ms 70.928 ms >>> >>> >>> -----Original Message----- From: John Conner >>> [mailto:bs7799 at gmail.com] Sent: Friday, November 29, 2013 5:04 PM To: >>> nanog at nanog.org Subject: bgp traceroute tool? >>> >>> Hi there, is there any tools available under linux which can do bgp >>> traceroute? (print bgp AS numbers for each traceroute hop ) , i >>> googled and found nothing. >>> >>> thanks >>> >>> John > From tony at lavanauts.org Sun Dec 1 03:07:07 2013 From: tony at lavanauts.org (Antonio Querubin) Date: Sat, 30 Nov 2013 17:07:07 -1000 (HST) Subject: bgp traceroute tool? In-Reply-To: References: <529A8082.8040908@ripe.net> Message-ID: On Sat, 30 Nov 2013, Jason Lixfeld wrote: > It would be slick if someone could patch mtr to do this too. It's in mtr as of v0.83. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From mpetach at netflight.com Sun Dec 1 07:19:49 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 30 Nov 2013 23:19:49 -0800 Subject: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond In-Reply-To: <5299941F.7050507@gmail.com> References: <5299941F.7050507@gmail.com> Message-ID: On Fri, Nov 29, 2013 at 11:30 PM, Constantine A. Murenin wrote: > Dear NANOG@, > ... > From hetzner.de through he.net: > > > Cns# date ; mtr --report{,-wide,-cycles=600} --interval 0.1 --order "SRL > BGAWV" -4 ????c????????.indiana.edu ; date > Using a 1/10th of a second interval is rather anti-social. I know we rate-limit ICMP traffic down, and such a short interval would be detected as attack traffic, and treated as such. I would take any results you get from such probes with a grain of salt. What results do you get with a more sane interval, one of at least 1 second or more? Matt From mureninc at gmail.com Sun Dec 1 09:11:54 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sun, 1 Dec 2013 01:11:54 -0800 Subject: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond In-Reply-To: References: <5299941F.7050507@gmail.com> Message-ID: <20131201091154.GA4999@Cns.Cns.SU> On 2013-W48-6 23:19 -0800, Matthew Petach wrote: > On Fri, Nov 29, 2013 at 11:30 PM, Constantine A. Murenin > wrote: > > > Dear NANOG@, > > > > ... > > > > From hetzner.de through he.net: > > > > > > Cns# date ; mtr --report{,-wide,-cycles=600} --interval 0.1 --order "SRL > > BGAWV" -4 ????c????????.indiana.edu ; date > > > > > Using a 1/10th of a second interval is rather anti-social. > I know we rate-limit ICMP traffic down, and such a > short interval would be detected as attack traffic, > and treated as such. > > I would take any results you get from such probes > with a grain of salt. What results do you get with > a more sane interval, one of at least 1 second or > more? > > Matt For what it is worth, I used to think the same, until I saw several providers themselves suggest that 1000 packets should be sent, with the 0.1 s interval. So, this is considered normal and appropriate nowadays. Anyhow, is this better? I now saw a 2% traffic loss this night at a random test time, and the 151ms avg rtt on this 114ms rtt route. Cns# date ; mtr --report{,-wide,-cycles=600} --interval 0.5 --order "SRL BGAWV" -4 ????c????????.indiana.edu ; date Sat Nov 30 23:17:13 PST 2013 HOST: Cns??????? Snt Rcv Loss% Best Gmean Avg Wrst StDev 1.|-- static.??.???.4.46.clients.your-server.de 600 600 0.0% 0.5 1.0 1.3 4.6 1.1 2.|-- hos-tr1.juniper1.rz13.hetzner.de 600 600 0.0% 0.1 0.2 2.0 58.5 7.9 3.|-- core21.hetzner.de 600 600 0.0% 0.2 0.2 0.2 10.2 0.7 4.|-- core22.hetzner.de 600 600 0.0% 0.2 0.2 0.2 11.2 0.8 5.|-- core1.hetzner.de 600 600 0.0% 4.8 4.8 4.8 25.1 1.3 6.|-- juniper1.ffm.hetzner.de 600 600 0.0% 4.8 4.8 4.8 13.9 0.6 7.|-- 30gigabitethernet1-3.core1.ams1.he.net 600 595 0.8% 11.2 14.3 15.2 121.4 7.4 8.|-- 10gigabitethernet1-4.core1.lon1.he.net 600 600 0.0% 18.2 21.0 21.3 51.2 4.0 9.|-- 10gigabitethernet10-4.core1.nyc4.he.net 600 592 1.3% 86.9 125.9 126.4 160.7 10.6 10.|-- 100gigabitethernet7-2.core1.chi1.he.net 600 591 1.5% 106.6 145.1 145.4 190.9 10.5 11.|-- ??? 600 0 100.0 0.0 0.0 0.0 0.0 0.0 12.|-- et-11-0-0.945.rtr.ictc.indiana.gigapop.net 600 589 1.8% 114.3 148.9 149.2 167.9 9.1 13.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu 600 589 1.8% 113.4 149.2 149.5 173.4 9.3 14.|-- ae-0.0.br2.bldc.net.uits.iu.edu 600 590 1.7% 114.5 150.2 150.5 175.6 9.3 15.|-- ae-10.0.cr3.bldc.net.uits.iu.edu 600 589 1.8% 114.3 150.5 150.8 181.0 9.1 16.|-- ????c????????.indiana.edu 600 589 1.8% 114.8 150.7 151.0 170.7 9.0 Sat Nov 30 23:24:06 PST 2013 The ICMP timestamp request/reply test still indicates that only one path is affected: the one from Europe to US over he.net. Cns# date ; unbuffer hping --icmp-ts --count 30 ????c????????.indiana.edu | \ perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \ if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, $3);} \ if (/tsrtt=(\d+)/) { \ print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\n"; }' Sun Dec 1 00:55:46 PST 2013 0 151.3 151 = 91 + 60 1 154.2 154 = 93 + 61 2 127.8 127 = 67 + 60 3 123.6 123 = 63 + 60 4 136.9 137 = 76 + 61 5 149.6 149 = 89 + 60 6 147.4 147 = 87 + 60 7 133.5 133 = 73 + 60 8 152.2 152 = 92 + 60 9 137.3 137 = 77 + 60 10 143.7 144 = 84 + 60 11 124.5 124 = 64 + 60 12 141.4 141 = 81 + 60 13 118.0 118 = 58 + 60 14 153.6 154 = 94 + 60 15 137.7 138 = 78 + 60 16 119.9 120 = 60 + 60 17 130.6 131 = 71 + 60 18 144.6 145 = 85 + 60 19 138.8 139 = 79 + 60 20 155.7 156 = 96 + 60 21 128.8 129 = 69 + 60 22 153.0 153 = 93 + 60 23 146.5 147 = 87 + 60 24 137.2 138 = 77 + 61 25 153.3 154 = 94 + 60 26 146.3 147 = 87 + 60 27 150.1 151 = 91 + 60 28 150.5 150 = 90 + 60 29 143.5 143 = 83 + 60 Cheers, Constantine. From sthaug at nethelp.no Sun Dec 1 10:37:08 2013 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 01 Dec 2013 11:37:08 +0100 (CET) Subject: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond In-Reply-To: <20131201091154.GA4999@Cns.Cns.SU> References: <5299941F.7050507@gmail.com> <20131201091154.GA4999@Cns.Cns.SU> Message-ID: <20131201.113708.74695831.sthaug@nethelp.no> >> Using a 1/10th of a second interval is rather anti-social. >> I know we rate-limit ICMP traffic down, and such a >> short interval would be detected as attack traffic, >> and treated as such. ... > For what it is worth, I used to think the same, until I saw several > providers themselves suggest that 1000 packets should be sent, with > the 0.1 s interval. So, this is considered normal and appropriate > nowadays. Disagree. You are of course free to use whatever rate you want between your own end points. If you want a response from routers on the public Internet, you should *expect* this to be rate limited. I certainly don't think that a 0.1s interval is appropriate - and configure control plane policing on "my" routers accordingly. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From randy at psg.com Sun Dec 1 10:49:03 2013 From: randy at psg.com (Randy Bush) Date: Sun, 01 Dec 2013 19:49:03 +0900 Subject: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond In-Reply-To: <20131201091154.GA4999@Cns.Cns.SU> References: <5299941F.7050507@gmail.com> <20131201091154.GA4999@Cns.Cns.SU> Message-ID: >> Using a 1/10th of a second interval is rather anti-social. >> I know we rate-limit ICMP traffic down, and such a >> short interval would be detected as attack traffic, >> and treated as such. > For what it is worth, I used to think the same, until I saw several > providers themselves suggest that 1000 packets should be sent, with > the 0.1 s interval. So, this is considered normal and appropriate > nowadays. matthew is correct go back to your old way of thinking. while some providers may tolerate fast pings, few if any grown-ups do. and even thouse who think they do have routing engines which consider all pings as low priority rubbish to be dropped when there is any real work to do. randy From danny at danysek.cz Sun Dec 1 11:16:20 2013 From: danny at danysek.cz (Daniel Suchy) Date: Sun, 01 Dec 2013 12:16:20 +0100 Subject: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond In-Reply-To: References: <5299941F.7050507@gmail.com> <20131201091154.GA4999@Cns.Cns.SU> Message-ID: <529B1A84.9090101@danysek.cz> On 1.12.2013 11:49, Randy Bush wrote: >>> Using a 1/10th of a second interval is rather anti-social. >>> I know we rate-limit ICMP traffic down, and such a >>> short interval would be detected as attack traffic, >>> and treated as such. >> For what it is worth, I used to think the same, until I saw several >> providers themselves suggest that 1000 packets should be sent, with >> the 0.1 s interval. So, this is considered normal and appropriate >> nowadays. > > matthew is correct > > go back to your old way of thinking. while some providers may tolerate > fast pings, few if any grown-ups do. and even thouse who think they do > have routing engines which consider all pings as low priority rubbish to > be dropped when there is any real work to do. > From router control-plane perspective, rate-limiting should be always expected and result evaluation should take that in account. From router perspective, packet with TTL=1 is handled typically in software, in CPU with limited power (compared to modern hardware) and it's not a primary job of router to answer to each TTL=1 packet - that's correct view. But, provided reports shows ALSO end-to-end packet loss, which never will be caused by control-plane policers on transit routers, these packets will never hit router CPU. And there we talk about basic network neutrality - everyone should treat all data equally, independently of protocol used for data transport. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4240 bytes Desc: S/MIME Cryptographic Signature URL: From rs at seastrom.com Sun Dec 1 12:27:42 2013 From: rs at seastrom.com (Rob Seastrom) Date: Sun, 01 Dec 2013 07:27:42 -0500 Subject: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond In-Reply-To: (Matthew Petach's message of "Sat, 30 Nov 2013 23:19:49 -0800") References: <5299941F.7050507@gmail.com> Message-ID: <86haaszrgh.fsf@valhalla.seastrom.com> Matthew Petach writes: > Using a 1/10th of a second interval is rather anti-social. > I know we rate-limit ICMP traffic down, and such a > short interval would be detected as attack traffic, > and treated as such. This should be obvious to everyone here but just in case, there's also a huge difference between hammering the control plane of every router along the path due to TTL expiration (mtr) and trying to smoke out intermittent performance problems between end points with a few hundred packets/second of various sizes of icmp or udp *between those end points*. Folks should expect the former to be rate limited - a reasonable control plane policing policy is not optional these days. -r From hank at efes.iucc.ac.il Sun Dec 1 13:53:50 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 01 Dec 2013 15:53:50 +0200 Subject: bgp traceroute tool? In-Reply-To: References: <529A8082.8040908@ripe.net> Message-ID: <5.1.1.6.2.20131201155326.0036fb00@efes.iucc.ac.il> At 17:07 30/11/2013 -1000, Antonio Querubin wrote: >On Sat, 30 Nov 2013, Jason Lixfeld wrote: > >>It would be slick if someone could patch mtr to do this too. > >It's in mtr as of v0.83. Unfortunately not in winmtr. -Hank >Antonio Querubin >e-mail: tony at lavanauts.org >xmpp: antonioquerubin at gmail.com From notify.sina at gmail.com Sun Dec 1 16:56:51 2013 From: notify.sina at gmail.com (Notify Me) Date: Sun, 1 Dec 2013 17:56:51 +0100 Subject: Is there a method or tool(s) to prove network outages? Message-ID: Hi Everyone Please I have a very problematic radio link which goes out and back on again every few hours. The only way I know this is happening is from my gateway device: a Sophos UTM that sends email anytime there's been an outage. The ISP refuses to accept this as outage/instability proof, and I'm wondering if there's something I can run behind the gateway UTM that can provide output information over time. They seem to be a primarily Windows+Cisco shop (as is common here in the 4th world). We are primarily Linux. Is there some set of command incantations I can run who's output I can collect and send to them (besides some sort of sustained ping)? Thanks in advance! Sina From joelja at bogus.com Sun Dec 1 17:19:51 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 01 Dec 2013 09:19:51 -0800 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: Message-ID: <529B6FB7.1090507@bogus.com> On 12/1/13, 8:56 AM, Notify Me wrote: > Hi Everyone > > Please I have a very problematic radio link which goes out and back on > again every few hours. > The only way I know this is happening is from my gateway device: a Sophos > UTM that sends email anytime there's been an outage. > > The ISP refuses to accept this as outage/instability proof, and I'm > wondering if there's something I can run behind the gateway UTM that can > provide output information over time. > They seem to be a primarily Windows+Cisco shop (as is common here in the > 4th world). We are primarily Linux. > Is there some set of command incantations I can run who's output I can > collect and send to them (besides some sort of sustained ping)? Given a measurement target on the customer side and smokeping instance on your side you can actively measure the availability/latency/loss rates between them. > Thanks in advance! > > Sina > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From don at sandvine.com Sun Dec 1 17:20:51 2013 From: don at sandvine.com (Don Bowman) Date: Sun, 1 Dec 2013 17:20:51 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: Message-ID: >Hi Everyone >Please I have a very problematic radio link which goes > out and back on again every few hours. >The only way I know this is happening is from my gateway >device: a Sophos UTM that sends email anytime there's been an outage. >The ISP refuses to accept this as outage/instability > proof, and I'm wondering if there's something I can run > behind the gateway UTM that can provide output information > over time. They seem to be a primarily Windows+Cisco shop > (as is common here in the 4th world). We are primarily Linux. > Is there some set of command incantations I can run who's output I can > collect and send to them (besides some sort of sustained ping)? I'm a big fan of smokeping personally. (http://oss.oetiker.ch/smokeping/) it will install on practically any linux device, and i've even installed it on ~$50 consumer NAS or router type devices (e.g. a pgoplug nas) if it has enough ram (128MB is dicey but works). shows you loss + latency. you set it up to ping e.g. the near and far end of the radio link, and then maybe a few sentinel sites. it can do ICMP and also TCP. From rdobbins at arbor.net Sun Dec 1 17:20:51 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 1 Dec 2013 17:20:51 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: Message-ID: <52A6AEA8-4B8B-4E9F-B84F-BA648520ED8B@arbor.net> On Dec 1, 2013, at 11:56 PM, Notify Me wrote: > Is there some set of command incantations I can run who's output I can collect and send to them (besides some sort of sustained ping)? Do you have wireless CPE within your span of administrative control? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Sun Dec 1 17:23:17 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 1 Dec 2013 17:23:17 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <529B6FB7.1090507@bogus.com> References: <529B6FB7.1090507@bogus.com> Message-ID: On Dec 2, 2013, at 12:19 AM, joel jaeggli wrote: > Given a measurement target on the customer side and smokeping instance on your side you can actively measure the availability/latency/loss > rates between them. I think he's actually the end-customer, and he's saying that his upstream transit ISP won't accept non-RF-specific diags . . . ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From joelja at bogus.com Sun Dec 1 17:38:39 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 01 Dec 2013 09:38:39 -0800 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: <529B6FB7.1090507@bogus.com> Message-ID: <529B741F.8070709@bogus.com> On 12/1/13, 9:23 AM, Dobbins, Roland wrote: > > On Dec 2, 2013, at 12:19 AM, joel jaeggli wrote: > >> Given a measurement target on the customer side and smokeping instance on your side you can actively measure the availability/latency/loss >> rates between them. > > I think he's actually the end-customer, and he's saying that his upstream transit ISP won't accept non-RF-specific diags . . . and if you don't control any of the air interfaces you don't get that. > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From notify.sina at gmail.com Sun Dec 1 17:39:50 2013 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 1 Dec 2013 17:39:50 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <52A6AEA8-4B8B-4E9F-B84F-BA648520ED8B@arbor.net> References: <52A6AEA8-4B8B-4E9F-B84F-BA648520ED8B@arbor.net> Message-ID: <1338702596-1385919590-cardhu_decombobulator_blackberry.rim.net-139122111-@b2.c4.bise7.blackberry> No, I don't. Sent from my BlackBerry wireless device from MTN -----Original Message----- From: "Dobbins, Roland" Date: Sun, 1 Dec 2013 17:20:51 To: nanog at nanog.org list Subject: Re: Is there a method or tool(s) to prove network outages? On Dec 1, 2013, at 11:56 PM, Notify Me wrote: > Is there some set of command incantations I can run who's output I can collect and send to them (besides some sort of sustained ping)? Do you have wireless CPE within your span of administrative control? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From notify.sina at gmail.com Sun Dec 1 17:42:18 2013 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 1 Dec 2013 17:42:18 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <529B741F.8070709@bogus.com> References: <529B6FB7.1090507@bogus.com> <529B741F.8070709@bogus.com> Message-ID: <212200154-1385919738-cardhu_decombobulator_blackberry.rim.net-372404223-@b2.c4.bise7.blackberry> I'm actually halfway through trying to setup a smokeping appliance. Sent from my BlackBerry wireless device from MTN -----Original Message----- From: joel jaeggli Date: Sun, 01 Dec 2013 09:38:39 To: Dobbins, Roland; nanog at nanog.org list Subject: Re: Is there a method or tool(s) to prove network outages? On 12/1/13, 9:23 AM, Dobbins, Roland wrote: > > On Dec 2, 2013, at 12:19 AM, joel jaeggli wrote: > >> Given a measurement target on the customer side and smokeping instance on your side you can actively measure the availability/latency/loss >> rates between them. > > I think he's actually the end-customer, and he's saying that his upstream transit ISP won't accept non-RF-specific diags . . . and if you don't control any of the air interfaces you don't get that. > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > From trelane at trelane.net Sun Dec 1 18:40:44 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 01 Dec 2013 13:40:44 -0500 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: Message-ID: <529B82AC.9090803@trelane.net> Sina, I'd recommend using Zenoss to monitor the remote end of the link at least with /Status/Ping. You'll get alerts when Zenoss can't ping across the link, and may be able to set up SNMP traps on your router for the link itself going down. DISCLOSURE: I work for Zenoss, however I used Zenoss core long before they decided to pay me money. Good luck with dealing with your ISP, it's _ALWAYS_ a pain in situations like this. Andrew On 12/1/2013 11:56 AM, Notify Me wrote: > Hi Everyone > > Please I have a very problematic radio link which goes out and back on > again every few hours. > The only way I know this is happening is from my gateway device: a Sophos > UTM that sends email anytime there's been an outage. > > The ISP refuses to accept this as outage/instability proof, and I'm > wondering if there's something I can run behind the gateway UTM that can > provide output information over time. > They seem to be a primarily Windows+Cisco shop (as is common here in the > 4th world). We are primarily Linux. > Is there some set of command incantations I can run who's output I can > collect and send to them (besides some sort of sustained ping)? > > Thanks in advance! > > Sina From notify.sina at gmail.com Sun Dec 1 18:57:24 2013 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 1 Dec 2013 18:57:24 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <529B82AC.9090803@trelane.net> References: <529B82AC.9090803@trelane.net> Message-ID: <2104374026-1385924244-cardhu_decombobulator_blackberry.rim.net-359288298-@b2.c4.bise7.blackberry> Thanks a lot, ill definitely consider it. Sent from my BlackBerry wireless device from MTN -----Original Message----- From: Andrew D Kirch Date: Sun, 01 Dec 2013 13:40:44 To: Subject: Re: Is there a method or tool(s) to prove network outages? Sina, I'd recommend using Zenoss to monitor the remote end of the link at least with /Status/Ping. You'll get alerts when Zenoss can't ping across the link, and may be able to set up SNMP traps on your router for the link itself going down. DISCLOSURE: I work for Zenoss, however I used Zenoss core long before they decided to pay me money. Good luck with dealing with your ISP, it's _ALWAYS_ a pain in situations like this. Andrew On 12/1/2013 11:56 AM, Notify Me wrote: > Hi Everyone > > Please I have a very problematic radio link which goes out and back on > again every few hours. > The only way I know this is happening is from my gateway device: a Sophos > UTM that sends email anytime there's been an outage. > > The ISP refuses to accept this as outage/instability proof, and I'm > wondering if there's something I can run behind the gateway UTM that can > provide output information over time. > They seem to be a primarily Windows+Cisco shop (as is common here in the > 4th world). We are primarily Linux. > Is there some set of command incantations I can run who's output I can > collect and send to them (besides some sort of sustained ping)? > > Thanks in advance! > > Sina From wbailey at satelliteintelligencegroup.com Sun Dec 1 19:44:46 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 1 Dec 2013 19:44:46 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: Message-ID: Ask them for a plot of your snr (signal to noise ratio) and your rsl (receive signal level). In the RF realm, it's pretty difficult to fabricate receive power. :) Sent from my Mobile Device. -------- Original message -------- From: Notify Me Date: 12/01/2013 7:58 AM (GMT-09:00) To: nanog at nanog.org Subject: Is there a method or tool(s) to prove network outages? Hi Everyone Please I have a very problematic radio link which goes out and back on again every few hours. The only way I know this is happening is from my gateway device: a Sophos UTM that sends email anytime there's been an outage. The ISP refuses to accept this as outage/instability proof, and I'm wondering if there's something I can run behind the gateway UTM that can provide output information over time. They seem to be a primarily Windows+Cisco shop (as is common here in the 4th world). We are primarily Linux. Is there some set of command incantations I can run who's output I can collect and send to them (besides some sort of sustained ping)? Thanks in advance! Sina From mpalmer at hezmatt.org Sun Dec 1 19:50:31 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 2 Dec 2013 06:50:31 +1100 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: Message-ID: <20131201195031.GG14268@hezmatt.org> On Sun, Dec 01, 2013 at 05:56:51PM +0100, Notify Me wrote: > Please I have a very problematic radio link which goes out and back on > again every few hours. > The only way I know this is happening is from my gateway device: a Sophos > UTM that sends email anytime there's been an outage. > > The ISP refuses to accept this as outage/instability proof, and I'm > wondering if there's something I can run behind the gateway UTM that can > provide output information over time. I'm surprised nobody's mentioned the root question to answer before you go off spending time setting up anything in particular: what *will* the ISP accept (or be forced to accept) as outage/instability proof? Contracts are your first line of defence, but it's nigh-on universal that they don't cover these sorts of situations well enough. So you probably need to have a discussion, as a follow-on from being told that your UTM's e-mails *aren't* sufficient, to determine what *is* sufficient. Once you've got that, only then can you evaluate appropriate methods of gathering the necessary data to support a claim of an outage. I like the *idea* of smokeping, but when gathering data on complete service loss (which was my use case for it as well) I found its methods of collecting and displaying that data to be very suboptimal and counter-intuitive. For something small and once-off like this, I'd probably just break out my text editor and script up something that would collect the relevant data and process it into the acceptable form. - Matt From notify.sina at gmail.com Sun Dec 1 20:02:50 2013 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 1 Dec 2013 20:02:50 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <20131201195031.GG14268@hezmatt.org> References: <20131201195031.GG14268@hezmatt.org> Message-ID: <560701198-1385928170-cardhu_decombobulator_blackberry.rim.net-808126701-@b2.c4.bise7.blackberry> Hmm. Great points. Didn't think of that. Sent from my BlackBerry wireless device from MTN -----Original Message----- From: Matt Palmer Date: Mon, 2 Dec 2013 06:50:31 To: Subject: Re: Is there a method or tool(s) to prove network outages? On Sun, Dec 01, 2013 at 05:56:51PM +0100, Notify Me wrote: > Please I have a very problematic radio link which goes out and back on > again every few hours. > The only way I know this is happening is from my gateway device: a Sophos > UTM that sends email anytime there's been an outage. > > The ISP refuses to accept this as outage/instability proof, and I'm > wondering if there's something I can run behind the gateway UTM that can > provide output information over time. I'm surprised nobody's mentioned the root question to answer before you go off spending time setting up anything in particular: what *will* the ISP accept (or be forced to accept) as outage/instability proof? Contracts are your first line of defence, but it's nigh-on universal that they don't cover these sorts of situations well enough. So you probably need to have a discussion, as a follow-on from being told that your UTM's e-mails *aren't* sufficient, to determine what *is* sufficient. Once you've got that, only then can you evaluate appropriate methods of gathering the necessary data to support a claim of an outage. I like the *idea* of smokeping, but when gathering data on complete service loss (which was my use case for it as well) I found its methods of collecting and displaying that data to be very suboptimal and counter-intuitive. For something small and once-off like this, I'd probably just break out my text editor and script up something that would collect the relevant data and process it into the acceptable form. - Matt From george.herbert at gmail.com Sun Dec 1 20:10:33 2013 From: george.herbert at gmail.com (George William Herbert) Date: Sun, 1 Dec 2013 12:10:33 -0800 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <20131201195031.GG14268@hezmatt.org> References: <20131201195031.GG14268@hezmatt.org> Message-ID: <08659D5F-A944-4B3B-9C84-909FACC8F9BD@gmail.com> On Dec 1, 2013, at 11:50 AM, Matt Palmer wrote: > I'm surprised nobody's mentioned the root question to answer before you go > off spending time setting up anything in particular: what *will* the ISP > accept (or be forced to accept) as outage/instability proof? Contracts are > your first line of defence, but it's nigh-on universal that they don't cover > these sorts of situations well enough. So you probably need to have a > discussion, as a follow-on from being told that your UTM's e-mails *aren't* > sufficient, to determine what *is* sufficient. This. They may not cooperate, in which case, you have to force proof down their throats. I would go with the Zenoss (or Zabbix, or...) option - a free to use, professionally supported, professional grade commonly used monitoring package that would meet anyone's basic "credible tool" definition plus neat GUI to send a snapshot of the results. Use it to perform various tests of the net - pings, http gets of some small target, starting pings with the next hop outside your premise and working outwards to the outside world. Don't overwhelm your net with tests, but test as often as needed to demonstrate an issue. -george william herbert george.herbert at gmail.com Sent from Kangphone From wwaites at tardis.ed.ac.uk Sun Dec 1 20:14:46 2013 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sun, 01 Dec 2013 20:14:46 +0000 (GMT) Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: Message-ID: <20131201.201446.138907851.wwaites@tardis.ed.ac.uk> On Sun, 1 Dec 2013 17:56:51 +0100, Notify Me said: > I have a very problematic radio link which goes out and back on > again every few hours. Is "every few hours" regular/cyclical? Does the radio link cross a tidal body of water? -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From randy at psg.com Sun Dec 1 20:20:23 2013 From: randy at psg.com (Randy Bush) Date: Mon, 02 Dec 2013 05:20:23 +0900 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <560701198-1385928170-cardhu_decombobulator_blackberry.rim.net-808126701-@b2.c4.bise7.blackberry> References: <20131201195031.GG14268@hezmatt.org> <560701198-1385928170-cardhu_decombobulator_blackberry.rim.net-808126701-@b2.c4.bise7.blackberry> Message-ID: if you do not control the rf end [0], then i assume the upstream supplies it and is really selling you connectivity to behind the rf cpe. so you should show you do not have that connectivity, the rf is a red herring. use smokeping or any other tool from immediately behind the rf cpe with a target of the first layer three hop beyond your network. but, if the upstream is in solid denial and is not actually accepting that they have a contractual obligation, measurement and technology are not going to help you. randy -- [0] - literally NO control, e.g. not antenna placement, power supplied, ... From notify.sina at gmail.com Sun Dec 1 20:25:36 2013 From: notify.sina at gmail.com (Sina Owolabi) Date: Sun, 1 Dec 2013 20:25:36 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <20131201.201446.138907851.wwaites@tardis.ed.ac.uk> References: <20131201.201446.138907851.wwaites@tardis.ed.ac.uk> Message-ID: <1655857833-1385929536-cardhu_decombobulator_blackberry.rim.net-149235933-@b2.c4.bise7.blackberry> Its cyclical, but I have not tried to graph/measure its repetition before now (when I noticed the emails filling up my inbox). Body of tidal water..could be, but I wasn't involved in the installation so I can't actually tell where the antennas are pointing. Sent from my BlackBerry wireless device from MTN -----Original Message----- From: William Waites Date: Sun, 01 Dec 2013 20:14:46 To: Cc: Subject: Re: Is there a method or tool(s) to prove network outages? On Sun, 1 Dec 2013 17:56:51 +0100, Notify Me said: > I have a very problematic radio link which goes out and back on > again every few hours. Is "every few hours" regular/cyclical? Does the radio link cross a tidal body of water? -w From wwaites at tardis.ed.ac.uk Sun Dec 1 22:02:45 2013 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sun, 01 Dec 2013 22:02:45 +0000 (GMT) Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <1655857833-1385929536-cardhu_decombobulator_blackberry.rim.net-149235933-@b2.c4.bise7.blackberry> References: <20131201.201446.138907851.wwaites@tardis.ed.ac.uk> <1655857833-1385929536-cardhu_decombobulator_blackberry.rim.net-149235933-@b2.c4.bise7.blackberry> Message-ID: <20131201.220245.502098305.wwaites@tardis.ed.ac.uk> On Sun, 1 Dec 2013 20:25:36 +0000, Sina Owolabi said: > Its cyclical, but I have not tried to graph/measure its > repetition before now... Body of tidal water..could be This is speculation until you have measurements, but if this is the case I'd wager you are having reflected signal interference off of the water. The water acts like a mirror and as it moves up and down the reflected signal will move in and out of phase with the main signal. At certain points you'll get near complete cancellation and the link will fail. See section 4 here for some explanations, fig 5 and 6 for what you could expect the graphs of signal strength, time, link capactity to look like: http://homepages.inf.ed.ac.uk/mmarina/papers/mobicom_winsdr08.pdf But not having access to the RF part you can't measure this directly. If you can get tide tables for a nearby location, what you could do is say that signal strength is 1 if the link is working and 0 if it is not. Measure for a while then scatterplot that against the level of the tide. If the measurements of 0 group tightly together in a few spots then you know definitely what is happening. Perhaps that plot together with a pointer to a nice academic paper would be enough to convince the provider of what is happening. What could you do about this? If you are lucky and the interference does not complete a full cycle from destructive to constructive and back with the largest amplitude of the tides that you experience in that place, you could try moving the antenna up or down. How much depends on the frequency and distances involved but I'd try 25cm increments up to a couple of meters if you can. You'll still get degradation but can hopefully avoid the deep nulls that take the link out completely. If you are able and willing to replace the end-site radios or antennas with your own, and the link uses some sort of 2xN MIMO, you could arrange vertical spacing between the antennas so that you have a good signal at one antenna when the other one is experiencing a null. This should get you on average half the best-case throughput the equipment is capable of but it should get you that consistently. The actual spacing depends on the distances and heights involved. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Sun Dec 1 23:26:30 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 1 Dec 2013 23:26:30 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <20131201.220245.502098305.wwaites@tardis.ed.ac.uk> References: <20131201.201446.138907851.wwaites@tardis.ed.ac.uk> <1655857833-1385929536-cardhu_decombobulator_blackberry.rim.net-149235933-@b2.c4.bise7.blackberry> <20131201.220245.502098305.wwaites@tardis.ed.ac.uk> Message-ID: I would hold off on considering Multipath as a problem until you see the RSL. There is no reason to go to the worst case scenario. In addition to that, there are some mitigation techniques we use (OFDM, XPIC, etc.) that will help null out some multi path should that be the case. With that being said, you should probably hire an RF Engineer rather than try to attempt this yourself. If you guys are having path problems, talk to the guy who designed the path. If there ?wasn?t? a ?guy? who ?designed? the path - this is what you get. //warren On 12/1/13, 1:02 PM, "William Waites" wrote: >On Sun, 1 Dec 2013 20:25:36 +0000, Sina Owolabi >said: > > > Its cyclical, but I have not tried to graph/measure its > > repetition before now... Body of tidal water..could be > >This is speculation until you have measurements, but if this is the >case I'd wager you are having reflected signal interference off of the >water. The water acts like a mirror and as it moves up and down the >reflected signal will move in and out of phase with the main >signal. At certain points you'll get near complete cancellation and >the link will fail. > >See section 4 here for some explanations, fig 5 and 6 for what you >could expect the graphs of signal strength, time, link capactity to >look like: > > http://homepages.inf.ed.ac.uk/mmarina/papers/mobicom_winsdr08.pdf > >But not having access to the RF part you can't measure this >directly. If you can get tide tables for a nearby location, what you >could do is say that signal strength is 1 if the link is working and 0 >if it is not. Measure for a while then scatterplot that against the >level of the tide. If the measurements of 0 group tightly together >in a few spots then you know definitely what is happening. Perhaps >that plot together with a pointer to a nice academic paper would be >enough to convince the provider of what is happening. > >What could you do about this? > >If you are lucky and the interference does not complete a full cycle >from destructive to constructive and back with the largest amplitude >of the tides that you experience in that place, you could try moving >the antenna up or down. How much depends on the frequency and >distances involved but I'd try 25cm increments up to a couple of >meters if you can. You'll still get degradation but can hopefully >avoid the deep nulls that take the link out completely. > >If you are able and willing to replace the end-site radios or antennas >with your own, and the link uses some sort of 2xN MIMO, you could >arrange vertical spacing between the antennas so that you have a good >signal at one antenna when the other one is experiencing a null. This >should get you on average half the best-case throughput the equipment >is capable of but it should get you that consistently. The actual >spacing depends on the distances and heights involved. > >-w From rdobbins at arbor.net Mon Dec 2 02:15:29 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 2 Dec 2013 02:15:29 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: <20131201195031.GG14268@hezmatt.org> References: <20131201195031.GG14268@hezmatt.org> Message-ID: <27E31D1D-B97E-4A40-82C3-CFFA670E4DD2@arbor.net> On Dec 2, 2013, at 2:50 AM, Matt Palmer wrote: > I'm surprised nobody's mentioned the root question to answer before you go off spending time setting up anything in particular: what *will* the ISP > accept (or be forced to accept) as outage/instability proof? That was my point - if the upstream won't accept ICMP pings, what's the likelihood he'll accept anything else, either? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Dec 2 02:40:59 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 2 Dec 2013 02:40:59 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: <20131201.201446.138907851.wwaites@tardis.ed.ac.uk> <1655857833-1385929536-cardhu_decombobulator_blackberry.rim.net-149235933-@b2.c4.bise7.blackberry> <20131201.220245.502098305.wwaites@tardis.ed.ac.uk> Message-ID: On Dec 2, 2013, at 6:26 AM, Warren Bailey wrote: > I would hold off on considering Multipath as a problem until you see the RSL. Concur. It could also be related to precipitation or other adverse conditions. Or, in fact, it could be related to the 'UTM' box and/or something else on the endpoint network. It could be a periodic DDoS attack, or traffic causing an availability hit as an unintended consequence. It's difficult to say without data. Since the OP has the ability to gather IP-level data on his own network, he should utilize whatever instrumentation and telemetry he can set up in order to diagnose the issue as accurately as possible. And the OP should dig out his SLA and see what it says about the obligations of his upstream. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From wbailey at satelliteintelligencegroup.com Mon Dec 2 03:09:13 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 2 Dec 2013 03:09:13 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: <20131201.201446.138907851.wwaites@tardis.ed.ac.uk> <1655857833-1385929536-cardhu_decombobulator_blackberry.rim.net-149235933-@b2.c4.bise7.blackberry> <20131201.220245.502098305.wwaites@tardis.ed.ac.uk> Message-ID: Keep in mind that inter web traffic has nothing to do with the overall health of the radio link. In RF land, we really don?t care what is going over that link - just that we have enough RSL hitting the receiver to be above threshold thus allowing the box to demodulate that signal. If your radio is sitting at a threshold RSL of -108 and you?re coming in at -105, big trouble in little China (3dB fade murdered your link). Stop thinking like a network engineer.. If your DS-1 was taking hits, an ICMP request (or lack thereof) would mean little (read: zero) to me as an RF Engineer. I want to see the BER/PER of the circuit over time so I can correlate possible trouble with real world issues. With that being said.. the tidal issue comes up a lot, and more times than not I see someone who said ?Point that dish over there? and when it magically works they have earned the title of ?Best RF Engineer in History? until the tide rolls in and their link suddenly has ?issues?. The invention of cheap wireless has caused many people to believe they have in depth wireless experience, and that is usually not the case. Not trying to preach, but I?ve spent a *TON* of time and other people?s money in multi path land.. If someone was responsible for the proper design of the link multi path would not be a factor as it would be addressed early on in the link. You are not going to gain much traction with a wireless company when you call and tell them your pings aren?t working.. They are kind of like parents.. They just don?t understand. ;) //warren Ps - I welcome any replies on or off list.. I know how frustrating it can be to have a link that seems to work well until you look at it, so I probably have a bit more compassion than others when talking about broken Microwave/Satellite hops. On 12/1/13, 5:40 PM, "Dobbins, Roland" wrote: > >On Dec 2, 2013, at 6:26 AM, Warren Bailey > wrote: > >> I would hold off on considering Multipath as a problem until you see >>the RSL. > >Concur. It could also be related to precipitation or other adverse >conditions. > >Or, in fact, it could be related to the 'UTM' box and/or something else >on the endpoint network. It could be a periodic DDoS attack, or traffic >causing an availability hit as an unintended consequence. > >It's difficult to say without data. Since the OP has the ability to >gather IP-level data on his own network, he should utilize whatever >instrumentation and telemetry he can set up in order to diagnose the >issue as accurately as possible. > >And the OP should dig out his SLA and see what it says about the >obligations of his upstream. > >----------------------------------------------------------------------- >Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From notify.sina at gmail.com Mon Dec 2 05:40:59 2013 From: notify.sina at gmail.com (Sina Owolabi) Date: Mon, 2 Dec 2013 05:40:59 +0000 Subject: Is there a method or tool(s) to prove network outages? In-Reply-To: References: <20131201.201446.138907851.wwaites@tardis.ed.ac.uk> <1655857833-1385929536-cardhu_decombobulator_blackberry.rim.net-149235933-@b2.c4.bise7.blackberry> <20131201.220245.502098305.wwaites@tardis.ed.ac.uk> Message-ID: <1488691992-1385962860-cardhu_decombobulator_blackberry.rim.net-214314978-@b2.c4.bise7.blackberry> Thanks a lot for the in-depth insights, all. Ill be doing a lot of "sleuthing" in the next few days based on all this information. Sent from my BlackBerry wireless device from MTN -----Original Message----- From: Warren Bailey Date: Mon, 2 Dec 2013 03:09:13 To: Dobbins, Roland; nanog at nanog.org Subject: Re: Is there a method or tool(s) to prove network outages? Keep in mind that inter web traffic has nothing to do with the overall health of the radio link. In RF land, we really don?t care what is going over that link - just that we have enough RSL hitting the receiver to be above threshold thus allowing the box to demodulate that signal. If your radio is sitting at a threshold RSL of -108 and you?re coming in at -105, big trouble in little China (3dB fade murdered your link). Stop thinking like a network engineer.. If your DS-1 was taking hits, an ICMP request (or lack thereof) would mean little (read: zero) to me as an RF Engineer. I want to see the BER/PER of the circuit over time so I can correlate possible trouble with real world issues. With that being said.. the tidal issue comes up a lot, and more times than not I see someone who said ?Point that dish over there? and when it magically works they have earned the title of ?Best RF Engineer in History? until the tide rolls in and their link suddenly has ?issues?. The invention of cheap wireless has caused many people to believe they have in depth wireless experience, and that is usually not the case. Not trying to preach, but I?ve spent a *TON* of time and other people?s money in multi path land.. If someone was responsible for the proper design of the link multi path would not be a factor as it would be addressed early on in the link. You are not going to gain much traction with a wireless company when you call and tell them your pings aren?t working.. They are kind of like parents.. They just don?t understand. ;) //warren Ps - I welcome any replies on or off list.. I know how frustrating it can be to have a link that seems to work well until you look at it, so I probably have a bit more compassion than others when talking about broken Microwave/Satellite hops. On 12/1/13, 5:40 PM, "Dobbins, Roland" wrote: > >On Dec 2, 2013, at 6:26 AM, Warren Bailey > wrote: > >> I would hold off on considering Multipath as a problem until you see >>the RSL. > >Concur. It could also be related to precipitation or other adverse >conditions. > >Or, in fact, it could be related to the 'UTM' box and/or something else >on the endpoint network. It could be a periodic DDoS attack, or traffic >causing an availability hit as an unintended consequence. > >It's difficult to say without data. Since the OP has the ability to >gather IP-level data on his own network, he should utilize whatever >instrumentation and telemetry he can set up in order to diagnose the >issue as accurately as possible. > >And the OP should dig out his SLA and see what it says about the >obligations of his upstream. > >----------------------------------------------------------------------- >Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From leo.vegoda at icann.org Mon Dec 2 13:57:53 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 2 Dec 2013 05:57:53 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <52990466.90206@bitfreak.org> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <52990466.90206@bitfreak.org> Message-ID: <5648A8908CCB564EBF46E2BC904A75B19681060E7B@EXVPMBX100-1.exc.icann.org> Hi, Darren Pilgrim wrote: > On 11/28/2013 1:07 PM, Leo Vegoda wrote: > > Is a /60 what is considered generous these days? > > Comcast only gives you a /64. That could be awkward for anyone who wants to run a separate LAN for wired and wireless. I hope it's only temporary. Cheers, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From mjkelly at gmail.com Mon Dec 2 14:23:49 2013 From: mjkelly at gmail.com (Matt Kelly) Date: Mon, 2 Dec 2013 09:23:49 -0500 Subject: Hardware resale question... Message-ID: I recently had a project end and have some pretty powerful hardware left over. Without spamming the list, I'm trying to get feedback as to where might be a good place to list this hardware and or resellers to contact who may be interested. The hardware is Juniper MX960 routers purchased new and used for about 45 days. Any input would be appreciated. Thanks. -- Matt From ilissa at imillerpr.com Mon Dec 2 14:27:26 2013 From: ilissa at imillerpr.com (Ilissa Miller) Date: Mon, 2 Dec 2013 09:27:26 -0500 Subject: Hardware resale question... In-Reply-To: References: Message-ID: <024A89C1-B2B2-42B6-B3F2-9F164E78140B@imillerpr.com> there's a global site called HWTrek you may want to check out. On Dec 2, 2013, at 9:23 AM, Matt Kelly wrote: > I recently had a project end and have some pretty powerful hardware left over. Without spamming the list, I'm trying to get feedback as to where might be a good place to list this hardware and or resellers to contact who may be interested. The hardware is Juniper MX960 routers purchased new and used for about 45 days. Any input would be appreciated. > > > Thanks. > > -- > Matt > > > Ilissa Miller CEO, iMiller Public Relations President, Northeast DAS + Small Cell Association Tel: 914.315.6424 Cel: 917.743.0931 eMail: ilissa at imillerpr.com www.imillerpr.com www.northeastdas.com From Jason_Livingood at cable.comcast.com Mon Dec 2 14:45:21 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 2 Dec 2013 14:45:21 +0000 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org>, Message-ID: <10229F86C86EB444898E629583FD4171EDE63125@PACDCEXMB06.cable.comcast.com> Wait, ISPs rolling out native dual stack are "victimizing" their customers? ________________________________________ From: Owen DeLong [owen at delong.com] Sent: Friday, November 29, 2013 4:41 AM To: Leo Vegoda Cc: nanog at nanog.org Subject: Re: AT&T UVERSE Native IPv6, a HOWTO Agreed? Unforutnately, the big guys (Comcast, AT&T) in America seem to like victimizing their customers with undersized assignments, limiting choice of proper prefix sizes to only their business class customers. I?m not sure why they are doing this. I know when I?ve had conversations with them, they haven?t exactly given a reason so much as just said that they thought a /48 was ridiculous. Of course, if AT&T is blocking protocol 41, that?s even worse, because at least so long as that isn?t blocked, you can still get an HE tunnel and get a /48 if you need it anyway. Owen From Jean-Francois.TremblayING at videotron.com Mon Dec 2 15:26:43 2013 From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com) Date: Mon, 2 Dec 2013 10:26:43 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <86li07ukk3.fsf@valhalla.seastrom.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129072801.E26D2AF62CE@rock.dv.isc.org> <86li07ukk3.fsf@valhalla.seastrom.com> Message-ID: > De : Rob Seastrom > > This space wouldn't be used much anyway, > > given that most 6RD routers use only one /64, sometimes two. > > I argue that a /60 is actually the best compromise here, from > > a space and usage point of view. > > IPv4-thinking. In the fullness of time this line of reasoning [...] Hopefully, the fullness of time won't apply to 6RD (this is what was being discussed here, not dual-stack). Most MSOs are planning /56s for native. ARIN 2011-3 is great, but it came a bit late (January 2012) for those who already had planned their network. /JF From rs at seastrom.com Mon Dec 2 15:46:30 2013 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 02 Dec 2013 10:46:30 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: (Jean-Francois TremblayING's message of "Mon, 2 Dec 2013 10:26:43 -0500") References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129072801.E26D2AF62CE@rock.dv.isc.org> <86li07ukk3.fsf@valhalla.seastrom.com> Message-ID: <86iov7qmqx.fsf@valhalla.seastrom.com> Jean-Francois.TremblayING at videotron.com writes: >> IPv4-thinking. ?In the fullness of time this line of reasoning [...] > > Hopefully, the fullness of time won't apply to 6RD (this is what > was being discussed here, not dual-stack). I agree but there's a subtlety here - we don't want to get people used to parsimony in IPv6-land via chintzing out on deployments with a transition technology. There are dinosaurs in every organization who cling to the "monetizing addresses/subnets" model and will want to charge more for a /48 or a /56 and point to the market being used to a /60 or a /64, and it becomes the unfortunate task for folks like us to argue against that line of thinking. We've got a little over two decades worth of IPv4 penny-pinching to undo here, and the interim deployments ought to help that to the degree possible. > Most MSOs are planning /56s for native. ARIN 2011-3 is great, but > it came a bit late (January 2012) for those who already had planned > their network. Yep, we're planning /56es for native at $DAYJOB too. Worse than /48s, not as bad as /64s or /60s. Not that ARIN policies constrain this at all; it was certainly possible before 2011-3 to get more than a /32 of space, it just wasn't as easy (certainly there was more than one org that managed to do it). As for the 6rd part, there was no 2010-12 6rd policy before December 2010... then again, before August 2010 there was no 6rd. :) I'm unfortunately quite familiar with the internal costs of a do-over in a large organization. -r From gary.buhrmaster at gmail.com Mon Dec 2 16:39:39 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 2 Dec 2013 16:39:39 +0000 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B19681060E7B@EXVPMBX100-1.exc.icann.org> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <52990466.90206@bitfreak.org> <5648A8908CCB564EBF46E2BC904A75B19681060E7B@EXVPMBX100-1.exc.icann.org> Message-ID: On Mon, Dec 2, 2013 at 1:57 PM, Leo Vegoda wrote: > Hi, > > Darren Pilgrim wrote: > >> On 11/28/2013 1:07 PM, Leo Vegoda wrote: >> > Is a /60 what is considered generous these days? >> >> Comcast only gives you a /64. > > That could be awkward for anyone who wants to run a separate LAN for > wired and wireless. I hope it's only temporary. Comcast (at least in my area) gives out up to a /60 to residential customers (if requested by the IA-PD option), although the default is /64. As I understand it, there was an issue earlier in the year (in one of their vendors software) that forced them to only offer a /64 for a time. I seem to recall that they stated two/three months ago that "most" areas now support /60 requests. I still think a /60 is too small for future home networking, and I hope to see at least a /56 at some point. From jim.rampley at charter.com Mon Dec 2 17:55:21 2013 From: jim.rampley at charter.com (Rampley Jr, Jim F) Date: Mon, 2 Dec 2013 11:55:21 -0600 Subject: RSVP Cisco ASR-9k to ALU 7750 Message-ID: <5D717D6976F4D8498089CBEE22C2EBCD014606C887@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM> Wondering if anybody on the list has any working configurations for RSVP tunnels between a Cisco ASR9k to Alcatel-Lucent 7750? I've been able to get LSP's up and talking between the two boxes, but I'm having an issue getting the RSVP tunnels to come up on the Cisco side. Jim From aj at sneep.net Mon Dec 2 19:41:50 2013 From: aj at sneep.net (Alastair Johnson) Date: Mon, 02 Dec 2013 11:41:50 -0800 Subject: RSVP Cisco ASR-9k to ALU 7750 In-Reply-To: <5D717D6976F4D8498089CBEE22C2EBCD014606C887@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM> References: <5D717D6976F4D8498089CBEE22C2EBCD014606C887@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM> Message-ID: <529CE27E.4000604@sneep.net> On 12/2/2013 9:55 AM, Rampley Jr, Jim F wrote: > > Wondering if anybody on the list has any working configurations for > RSVP tunnels between a Cisco ASR9k to Alcatel-Lucent 7750? I've been > able to get LSP's up and talking between the two boxes, but I'm > having an issue getting the RSVP tunnels to come up on the Cisco > side. You may need to enable adspec on the 7750 side, otherwise the ASR will always advertise a 500 byte MTU on the LSP, which will usually cause problems (service MTU checks, etc). config router mpls lsp adspec HTH, AJ From jfbeam at gmail.com Mon Dec 2 21:25:27 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 16:25:27 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <86haav72ds.fsf@valhalla.seastrom.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom wrote: > So there really is no excuse on AT&T's part for the /60s on uverse 6rd... Except for a) greed ("we can *sell* larger slices") and b) demonstrable user want/need. How many residential, "home networks", have you seen with more than one subnet? The typical household (esp Uverse) doesn't even customize the provided router. Even a CCIE friend of mine has made ZERO changes to his RG -- AT&T turned off WiFi and added the static block at install. (I know NANOG is bad sample as we're all professionals and setup all kinds of weird configurations at "home". I have 3 nets in continuous use... a legacy public subnet from eons ago (I never renumbered), an RFC1918 subnet overlapping that network (because it's too small), and a second RFC1918 net from a second ISP) I wouldn't use the word "generous", but a /60 (16 "LAN"s) is way more than what 99% of residential deployments will need for many years. We've gotten by with a single, randomly changing, dynamic IP for decades. Until routers come out-of-the-box setup for a dozen networks, non-networking pros aren't going to need it, or even know that it's possible. (and the default firewalling policy in Windows is going to confuse a lot of people when machines start landing in different subnets can "see" each other.) Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks when they're only ever likely to use one or two (or maybe four), is intentionally wasting space you could've assigned to someone else. (or **sold** to someone else :-)) IPv6 may be huge to the power of huge, but it's still finite. People like you are repeating the same mistakes from the early days of IPv4... the difference is, we won't be around when people are cursing us for the way we mismanaged early allocations. Indeed, a /64 is too little (aka "bare minimum") and far too restrictive, but it works for most simple (default) setups today. Which leads to DHCPv6 PD... a /60 is adequate -- it's the minimal space for the rare cases where multiple nets are desirable or necessary. The option for /56 or even /48 should exist (esp. for "business"), but the need for such large address spaces are an EXCEPTION in residential settings. (and those are probably non-residential users anyway.) [FWIW, HE.net does what they do as marketing. And it works, btw.] From jfbeam at gmail.com Mon Dec 2 21:40:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 16:40:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <86li07ukk3.fsf@valhalla.seastrom.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129072801.E26D2AF62CE@rock.dv.isc.org> <86li07ukk3.fsf@valhalla.seastrom.com> Message-ID: On Fri, 29 Nov 2013 13:31:08 -0500, Rob Seastrom wrote: > IPv4-thinking. In the fullness of time... I suspect it'll fall the other way. In a few decades, people will be wondering what we were smoking to have carved up this /8 (and maybe a few of them by then) in such an insanely sparse ("wasteful") manner. (By then let's hope routers have improved enough to handle million route tables.) From owen at delong.com Mon Dec 2 21:42:02 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 13:42:02 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: On Dec 2, 2013, at 13:25 , Ricky Beam wrote: > On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom wrote: >> So there really is no excuse on AT&T's part for the /60s on uverse 6rd... > > Except for a) greed ("we can *sell* larger slices") and b) demonstrable user want/need. > > How many residential, "home networks", have you seen with more than one subnet? The typical household (esp Uverse) doesn't even customize the provided router. Even a CCIE friend of mine has made ZERO changes to his RG -- AT&T turned off WiFi and added the static block at install. (I know NANOG is bad sample as we're all professionals and setup all kinds of weird configurations at "home". I have 3 nets in continuous use... a legacy public subnet from eons ago (I never renumbered), an RFC1918 subnet overlapping that network (because it's too small), and a second RFC1918 net from a second ISP) Quite a few with at least three out there these days. Many home gateways now come with separate networks for Wired, WiFi, and Guest WiFi. However, as I have repeatedly said... IPv6 is not about just what we need today. What we need today is limited to what we could do with the scarcity inherent in IPv4 addressing. Restricting IPv6 based on those limitations is absurd. IPv6 should be about what we want to be able to do in 5, 10, 20, and 50 years. It shouldn't be about what we need today. > > I wouldn't use the word "generous", but a /60 (16 "LAN"s) is way more than what 99% of residential deployments will need for many years. I'm not so sure about that, depending on how you define "many". Worse, if it becomes the widespread lowest common denominator, then it will become somewhat of a self-fulfilling prophecy in that engineers will design to what users have instead of to what users should be able to get. > We've gotten by with a single, randomly changing, dynamic IP for decades. Until routers come out-of-the-box setup for a dozen networks, non-networking pros aren't going to need it, or even know that it's possible. (and the default firewalling policy in Windows is going to confuse a lot of people when machines start landing in different subnets can "see" each other.) Yes, we've suffered with a severely degraded internet for decades. Is that really a reason not to make things better going forward? I don't think so. Routers are already starting to come out of the box with the ability to do prefix delegation and being able to connect multiple routers together into automatically generated hierarchies is a technology that is just beginning to be explored. Given that Cell Phones and Tablets are already widely used as routers, I don't think that increasing router ubiquity is all that unlikely in the home market in just a few years. > > Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks when they're only ever likely to use one or two (or maybe four), is intentionally wasting space you could've assigned to someone else. (or **sold** to someone else :-)) IPv6 may be huge to the power of huge, but it's still finite. People like you are repeating the same mistakes from the early days of IPv4... the difference is, we won't be around when people are cursing us for the way we mismanaged early allocations. Indeed, a /64 is too little (aka "bare minimum") and far too restrictive, but it works for most simple (default) setups today. Which leads to DHCPv6 PD... a /60 is adequate -- it's the minimal space for the rare cases where multiple nets are desirable or necessary. The option for /56 or even /48 should exist (esp. for "business"), but the need for such large address spaces are an EXCEPTION in residential settings. (and those are probably non-residential users anyway.) [FWIW, HE.net does what they do as marketing. And it works, btw.] I hate to break it to you, but, no, nobody is really paying for that space. There is no inherent cost to address space relative to the size of the address space. The cost is related to administering the registrations of that space. Once you get above a certain size, your ARIN fees do not go up. If you have fewer than 60,000 customers, you can give all of them a /48 for $2000/year. That works out to less than $0.04 per customer per year. If you have fewer than 1,000,000 customers, you can give all of them a /48 for $4,000/year which works out to less than $0.005 per customer per year. By the way, those numbers leave GENEROUS room for ISP internal infrastructure, overhead, etc. (536 /48s in the first case and 48,576 /48s in the second case). Arguing that "someone is paying for those addresses" just doesn't work out when you look at the actual costs. There are enough /48s available in 2000::/3 to give every person alive from now until 2050 16 /48s and still have many left over. For all of you who keep wanting to repeat the scarcity problems of IPv4 in IPv6 and waste the space by leaving it sitting on the shelf instead of wasting it by handing it out to users, I offer this compromise... Let's try giving out /48s liberally in 2000::/3. If we exhaust 2000::/3 before I am dead, I will be the first one to help you champion more restrictive policies for the remaining 7/8ths of IPv6. (I expect to live something close to another 50 years and there's not much I can to do help with more restrictive policies beyond my death anyway). Owen From alh-ietf at tndh.net Mon Dec 2 22:14:38 2013 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 2 Dec 2013 14:14:38 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: <015701ceefab$e45513b0$acff3b10$@tndh.net> Ricky Beam wrote: > On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > wrote: > > So there really is no excuse on AT&T's part for the /60s on uverse 6rd... > > Except for a) greed ("we can *sell* larger slices") and b) demonstrable user > want/need. > > How many residential, "home networks", have you seen with more than one > subnet? The typical household (esp Uverse) doesn't even customize the > provided router. Even a CCIE friend of mine has made ZERO changes to his > RG -- AT&T turned off WiFi and added the static block at install. (I know > NANOG is bad sample as we're all professionals and setup all kinds of weird > configurations at "home". I have 3 nets in continuous use... a legacy public > subnet from eons ago (I never renumbered), an RFC1918 subnet overlapping > that network (because it's too small), and a second RFC1918 net from a > second ISP) > > I wouldn't use the word "generous", but a /60 (16 "LAN"s) is way more than > what 99% of residential deployments will need for many years. We've > gotten by with a single, randomly changing, dynamic IP for decades. Until > routers come out-of-the-box setup for a dozen networks, non-networking > pros aren't going to need it, or even know that it's possible. (and the default > firewalling policy in Windows is going to confuse a lot of people when > machines start landing in different subnets can "see" each other.) > > Handing out /56's like Pez is just wasting address space -- someone *is* > paying for that space. Yes, it's waste; giving everyone 256 networks when > they're only ever likely to use one or two (or maybe four), is intentionally > wasting space you could've assigned to someone else. (or > **sold** to someone else :-)) IPv6 may be huge to the power of huge, but > it's still finite. People like you are repeating the same mistakes from the early > days of IPv4... the difference is, we won't be around when > people are cursing us for the way we mismanaged early allocations. > Indeed, a /64 is too little (aka "bare minimum") and far too restrictive, but it > works for most simple (default) setups today. Which leads to DHCPv6 PD... a > /60 is adequate -- it's the minimal space for the rare cases where multiple > nets are desirable or necessary. The option for /56 or even /48 should exist > (esp. for "business"), but the need for such large address spaces are an > EXCEPTION in residential settings. (and those are probably non-residential > users anyway.) [FWIW, HE.net does what they do as marketing. And it works, > btw.] The rant above represents a braindead short-sighted thought process. If you focus on the past as justification for current actions, you guarantee that the future will always look exactly like the past. If you even hint at a /64 as the standard for residential deployment, you will find that all the CPE vendors will hard code that, and you will never get it undone when you change your mind. All because you stated up front that they will only ever need what they have been using in the past. You don't see multi-subnet residential today from the consumer viewpoint, but they do widely exist supporting deployment of "watch your dvr from any set-top", where a premise subnet handles that traffic off of the consumer lan. That one example is why there should NEVER be a /64, because you are already at 2 subnets that should be using the same shorter prefix. Trying to develop the automation necessary for consumer plug-n-play subnets shows that even a /56 is virtually unusable. A /55 makes more sense for a topology with moderate constraints, but if you are already shorter than a 56, it doesn't make sense to stop there. This is a hard concept for "professional network engineers", because their market place value is based on the ability to efficiently manage topologies to fit within address resource constraints. Consumers have no desire to understand the technology, they just want to plug stuff together and have it sort out what it needs to do. That unconstrained topology coupled with unmanaged device automation requires excess address resource. YES THAT IS A WASTE. But having the address space sitting on the shelf at IANA when someone comes along with a better idea in the next few hundred years is also a waste. Get over it, the address space excessively larger than we will ever deploy so it is wasted ... The only open issue is how we utilize the resource until the next thing comes along. If it sits on the shelf, you constrain innovation. If you 'waste it' by deploying it before people can really use it, you piss-off the existing engineering staff. From my perspective, the latter will die off, but stifling innovation robs future generations of capabilities they could/should have had to make the world a better place. Tony From jfbeam at gmail.com Mon Dec 2 22:35:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 17:35:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: On Mon, 02 Dec 2013 16:42:02 -0500, Owen DeLong wrote: > Quite a few with at least three out there these days. Many home gateways > now come with separate networks for Wired, WiFi, and Guest WiFi. Interesting... I've not looked at the current "high end" (i.e. things that cost more than $17 at Tiger Direct.) > However, as I have repeatedly said... IPv6 is not about just what we > need today. What we need today is limited to what we could do with the > scarcity inherent in IPv4 addressing. Restricting IPv6 based on those > limitations is absurd. DHCPv6-PD isn't a "restriction", it's simply what gets handed out today. A "simple" reconfiguration on the DHCP server and it's handing out /56's instead. (or *allowing* /56's if requested -- it's better to let the customer ask for what they need/want; assuming they just default to asking for the largest block they're allowed and using only 3 networks.) > IPv6 should be about what we want to be able to do in 5, 10, 20, and 50 > years. It shouldn't be about what we need today. We don't know what we'll need in the future. We only know what we need right now. Using the current dynamic mechanisms we can provide for now and "later", as "later" becomes apparent. > Yes, we've suffered with a severely degraded internet for decades. Is > that really a reason not to make things better going forward? I don't > think so. More complex is not always "better". This is doubly true here as very few people ("the public") have any measurable clue when it comes to networks. The Internet is just something that works. When you start mixing in multiple networks, that's going to create problems for them. Recall my Windows warning... the default firewall setup blocks inbound access from outside the local subnet. So with the above 3-way router, a PC on the wired network and a laptop on WiFi would not be able to talk to each other without MANUAL adjustment -- or Microsoft will have to start making (even more) dangerous assumptions about one's network [assume every "LAN" is /60? /56?, on top of the already Bad Idea(tm) that "ALL LANS ARE SLASH SIXTY-FOUR, SO SAYETH THE RFC!"] > I hate to break it to you, but, no, nobody is really paying for that > space. Go talk to your bean counters. There's a line-item charge for your address space; they'll want it as small as possible. (they'll also want to make as much money off that space as possible. Even if *you* aren't charging for IPv{4,6} space, almost everyone else does, and wants to continue. Because it's a major source of revenue.) From james.cutler at consultant.com Mon Dec 2 22:44:17 2013 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 2 Dec 2013 17:44:17 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <015701ceefab$e45513b0$acff3b10$@tndh.net> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> Message-ID: On Dec 2, 2013, at 5:14 PM, Tony Hain wrote: > Ricky Beam wrote: >> On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom >> wrote: >>> So there really is no excuse on AT&T's part for the /60s on uverse > 6rd... >> >> Except for a) greed ("we can *sell* larger slices") and b) demonstrable > user >> want/need. >> >> How many residential, "home networks", have you seen with more than one >> subnet? The typical household (esp Uverse) doesn't even customize the >> provided router. Even a CCIE friend of mine has made ZERO changes to his >> RG -- AT&T turned off WiFi and added the static block at install. (I know >> NANOG is bad sample as we're all professionals and setup all kinds of > weird >> configurations at "home". I have 3 nets in continuous use... a legacy > public >> subnet from eons ago (I never renumbered), an RFC1918 subnet overlapping >> that network (because it's too small), and a second RFC1918 net from a >> second ISP) >> >> I wouldn't use the word "generous", but a /60 (16 "LAN"s) is way more than >> what 99% of residential deployments will need for many years. We've >> gotten by with a single, randomly changing, dynamic IP for decades. Until >> routers come out-of-the-box setup for a dozen networks, non-networking >> pros aren't going to need it, or even know that it's possible. (and the > default >> firewalling policy in Windows is going to confuse a lot of people when >> machines start landing in different subnets can "see" each other.) >> >> Handing out /56's like Pez is just wasting address space -- someone *is* >> paying for that space. Yes, it's waste; giving everyone 256 networks when >> they're only ever likely to use one or two (or maybe four), is > intentionally >> wasting space you could've assigned to someone else. (or >> **sold** to someone else :-)) IPv6 may be huge to the power of huge, but >> it's still finite. People like you are repeating the same mistakes from > the early >> days of IPv4... the difference is, we won't be around when >> people are cursing us for the way we mismanaged early allocations. >> Indeed, a /64 is too little (aka "bare minimum") and far too restrictive, > but it >> works for most simple (default) setups today. Which leads to DHCPv6 PD... > a >> /60 is adequate -- it's the minimal space for the rare cases where > multiple >> nets are desirable or necessary. The option for /56 or even /48 should > exist >> (esp. for "business"), but the need for such large address spaces are an >> EXCEPTION in residential settings. (and those are probably non-residential >> users anyway.) [FWIW, HE.net does what they do as marketing. And it works, >> btw.] > > The rant above represents a braindead short-sighted thought process. If you > focus on the past as justification for current actions, you guarantee that > the future will always look exactly like the past. If you even hint at a /64 > as the standard for residential deployment, you will find that all the CPE > vendors will hard code that, and you will never get it undone when you > change your mind. All because you stated up front that they will only ever > need what they have been using in the past. > > You don't see multi-subnet residential today from the consumer viewpoint, > but they do widely exist supporting deployment of "watch your dvr from any > set-top", where a premise subnet handles that traffic off of the consumer > lan. That one example is why there should NEVER be a /64, because you are > already at 2 subnets that should be using the same shorter prefix. Trying to > develop the automation necessary for consumer plug-n-play subnets shows that > even a /56 is virtually unusable. A /55 makes more sense for a topology with > moderate constraints, but if you are already shorter than a 56, it doesn't > make sense to stop there. This is a hard concept for "professional network > engineers", because their market place value is based on the ability to > efficiently manage topologies to fit within address resource constraints. > Consumers have no desire to understand the technology, they just want to > plug stuff together and have it sort out what it needs to do. That > unconstrained topology coupled with unmanaged device automation requires > excess address resource. > > YES THAT IS A WASTE. But having the address space sitting on the shelf at > IANA when someone comes along with a better idea in the next few hundred > years is also a waste. Get over it, the address space excessively larger > than we will ever deploy so it is wasted ... The only open issue is how we > utilize the resource until the next thing comes along. If it sits on the > shelf, you constrain innovation. If you 'waste it' by deploying it before > people can really use it, you piss-off the existing engineering staff. From > my perspective, the latter will die off, but stifling innovation robs future > generations of capabilities they could/should have had to make the world a > better place. > > Tony > My kudos to Tony for an excellent summary. The only thing he missed is the tremendous waste of people resources involved in micro-managing address assignments. Those who cannot learn from history are condemned to repeat it. The available IPv6 address space, even constrained to /64 as a maximum prefix, is far beyond concern for decades. In addition, really intelligent network service providers calculate the budget for personnel to micro-manage address space. For example, a provider that by default uses a /64 for the CPE WAN link and a separate DHCP-PD assignment for customer networks will almost never have to revisit the issue, but has the flexibility to do so as needed. And, the lazy user, as cited above, will receive a working network without special effort. So just do the cost-benefit analysis including business office, deployment, and operations personnel and systems versus a purported ?waste? of some integers which potentially will not affect us until 2090 if at all. James R. Cutler james.cutler at consultant.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Mon Dec 2 22:54:50 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 14:54:50 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: On Dec 2, 2013, at 14:35 , Ricky Beam wrote: > On Mon, 02 Dec 2013 16:42:02 -0500, Owen DeLong wrote: >> Quite a few with at least three out there these days. Many home gateways now come with separate networks for Wired, WiFi, and Guest WiFi. > > Interesting... I've not looked at the current "high end" (i.e. things that cost more than $17 at Tiger Direct.) > Maybe you should expand your consideration to include $30-$50 at Best Buy. >> However, as I have repeatedly said... IPv6 is not about just what we need today. What we need today is limited to what we could do with the scarcity inherent in IPv4 addressing. Restricting IPv6 based on those limitations is absurd. > > DHCPv6-PD isn't a "restriction", it's simply what gets handed out today. A "simple" reconfiguration on the DHCP server and it's handing out /56's instead. (or *allowing* /56's if requested -- it's better to let the customer ask for what they need/want; assuming they just default to asking for the largest block they're allowed and using only 3 networks.) > No, DHCPv6-PD isn't a restriction. Only handing out a /60 _IS_ a restriction. As to a "simple" reconfiguration, not really. That depends very much on how the infrastructure that DHCP server supports is architected. >> IPv6 should be about what we want to be able to do in 5, 10, 20, and 50 years. It shouldn't be about what we need today. > > We don't know what we'll need in the future. We only know what we need right now. Using the current dynamic mechanisms we can provide for now and "later", as "later" becomes apparent. Circular and short-sighted argument. There's already clear evidence that having a wider bit field will enable greater flexibility and better application development, so we should be deploying that wider bitfield. You're arguing the network equivalant of "we shouldn't deploy charging stations until there are tons of electric cars on the road." I'm arguing that we'll never see tons of electric cars on the road until there is a widespread infrastructure of charging stations. So far, in the electric car world, it seems that charging stations are starting to pop up all over the place and as they become more widespread, indeed, more electric cars are hitting the road. > >> Yes, we've suffered with a severely degraded internet for decades. Is that really a reason not to make things better going forward? I don't think so. > > More complex is not always "better". This is doubly true here as very few people ("the public") have any measurable clue when it comes to networks. The Internet is just something that works. When you start mixing in multiple networks, that's going to create problems for them. Recall my Windows warning... the default firewall setup blocks inbound access from outside the local subnet. So with the above 3-way router, a PC on the wired network and a laptop on WiFi would not be able to talk to each other without MANUAL adjustment -- or Microsoft will have to start making (even more) dangerous assumptions about one's network [assume every "LAN" is /60? /56?, on top of the already Bad Idea(tm) that "ALL LANS ARE SLASH SIXTY-FOUR, SO SAYETH THE RFC!"] I agree... The unnecessary complexity inherent in NAT and even moreso with CGN is horrible. Multiple networks will be plug and play. Heck, they already are in some circumstances... Look at the number of people that have no trouble converting their cell phones and tablets from simple nodes to internet routers. I don't know why you think that the PC and Laptop can't talk to each other. It actually seems to work just fine. They both default to the upstream router and the router has more specifics to each of the two LAN segments. Micr0$0ft doesn't have to make any assumptions at all. In the IPv6 world, they can use site-scoped multicast (ffx5::). All that is required in that case is for the home gateway to know that it is the home gateway and not a lower-level router within the site. (More accurately, it needs to be able to distinguish between the provider link and it's intra-site links. I believe that is generally something that the gateway should be able to do automatically... (The DSL or Cable interface is obviously not intra-site, for example). > >> I hate to break it to you, but, no, nobody is really paying for that space. > > Go talk to your bean counters. There's a line-item charge for your address space; they'll want it as small as possible. (they'll also want to make as much money off that space as possible. Even if *you* aren't charging for IPv{4,6} space, almost everyone else does, and wants to continue. Because it's a major source of revenue.) I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 address space. Frankly, if you're paying for IPv6 space, you're not too bright. You can go get a direct assignment from an RIR so easily for $100/year that it just doesn't make sense to pay more than that. Owen From marka at isc.org Mon Dec 2 22:59:51 2013 From: marka at isc.org (Mark Andrews) Date: Tue, 03 Dec 2013 09:59:51 +1100 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: Your message of "Mon, 02 Dec 2013 17:35:28 -0500." References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: <20131202225952.1C8F2B052B6@rock.dv.isc.org> In message , "Ricky Beam" writes: > On Mon, 02 Dec 2013 16:42:02 -0500, Owen DeLong wrote: > > Quite a few with at least three out there these days. Many home gateways > > now come with separate networks for Wired, WiFi, and Guest WiFi. > > Interesting... I've not looked at the current "high end" (i.e. things that > cost more than $17 at Tiger Direct.) > > > However, as I have repeatedly said... IPv6 is not about just what we > > need today. What we need today is limited to what we could do with the > > scarcity inherent in IPv4 addressing. Restricting IPv6 based on those > > limitations is absurd. > > DHCPv6-PD isn't a "restriction", it's simply what gets handed out today. A > "simple" reconfiguration on the DHCP server and it's handing out /56's > instead. (or *allowing* /56's if requested -- it's better to let the > customer ask for what they need/want; assuming they just default to asking > for the largest block they're allowed and using only 3 networks.) > > > IPv6 should be about what we want to be able to do in 5, 10, 20, and 50 > > years. It shouldn't be about what we need today. > > We don't know what we'll need in the future. We only know what we need > right now. Using the current dynamic mechanisms we can provide for now and > "later", as "later" becomes apparent. > > > Yes, we've suffered with a severely degraded internet for decades. Is > > that really a reason not to make things better going forward? I don't > > think so. > > More complex is not always "better". This is doubly true here as very few > people ("the public") have any measurable clue when it comes to networks. > The Internet is just something that works. When you start mixing in > multiple networks, that's going to create problems for them. Recall my > Windows warning... the default firewall setup blocks inbound access from > outside the local subnet. So with the above 3-way router, a PC on the > wired network and a laptop on WiFi would not be able to talk to each other > without MANUAL adjustment And there are moves in homenet to change that because we know it is a bad idea that has had its place and time. Machines are quite capable of protecting themselves these days. > -- or Microsoft will have to start making (even > more) dangerous assumptions about one's network [assume every "LAN" is > /60? /56?, on top of the already Bad Idea(tm) that "ALL LANS ARE SLASH > SIXTY-FOUR, SO SAYETH THE RFC!"] You don't make assumptions. You get the network tell you what size the local scope is. A simple RA/DHCP option could do this. The information is known by the border CPE. You just need to advertise this to the devices on the local network. > > I hate to break it to you, but, no, nobody is really paying for that > > space. > > Go talk to your bean counters. There's a line-item charge for your > address space; they'll want it as small as possible. (they'll also want to > make as much money off that space as possible. Even if *you* aren't > charging for IPv{4,6} space, almost everyone else does, and wants to > continue. Because it's a major source of revenue.) For the few residential ISP's that do this what is it? $5 / month per IP and how many ask for a second address? 1 in 10000, 1 in recover the setup costs. Go ask the bean counters about the cost of having different sized customers. Those costs will dwarf the income from charging for bigger address space. For IPv4 there wasn't a choice. For IPv6 there is the choice of one size for all vs the additional cost of managing different sized customers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dougb at dougbarton.us Mon Dec 2 23:02:07 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 02 Dec 2013 15:02:07 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: <529D116F.9000009@dougbarton.us> On 12/02/2013 02:35 PM, Ricky Beam wrote: > We don't know what we'll need in the future. We only know what we need > right now. Using the current dynamic mechanisms we can provide for now > and "later", as "later" becomes apparent. I hate to keep repeating this, but each time the argument comes up the 2 camps split into their factions and ignore my suggestion, so here goes. :) I have been proposing for years now that ISPs reserve a /48 per customer end site, which aligns with both the protocol design and the policies of most if not all RIRs. Then as rollout actually occurs make the first /56 (1/2 way between /48 and /64) available to the customer (in whatever form 'make available' occurs, such as DHCPv6-PD). That way you have protected your customer from having to renumber in the future should they need the full /48. Then down the road IF you run out of space, and IF you can't get more, you can then go back and start assigning the second /56 out of the /48s you had previously reserved. Of course this same logic could be applied to /60s instead of /56s, but even I (sympathetic to the argument of not repeating the wasteful mistakes of the past as I am) think that's too small. hth, Doug From jfbeam at gmail.com Mon Dec 2 23:10:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 18:10:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <015701ceefab$e45513b0$acff3b10$@tndh.net> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> Message-ID: On Mon, 02 Dec 2013 17:14:38 -0500, Tony Hain wrote: > If you even hint at a /64 as the standard for residential deployment, I never said that should be the standard. The way most systems do it today, you get a /64 without doing anything. If that's all you need, then you're done. If you want more networks, you ask for them via DHCPv6, and you can ask for prefix size you need (you may not get it, 'tho.) Currently, ISPs are defaulting to /60 as that's fair compromise for current networking. It's an easy limit to change, if they're willing to do it. > Trying to develop the automation necessary for consumer plug-n-play > subnets shows that even a /56 is virtually unusable... I'm the insane one for saying a single /64 and a /60 are perfectly workable today, but every damned device in the home getting it's very own /64 is *NECESSARY*??? If that's your only answer to home automation, then you should quit now, and leave the solar system. Multiple networks REQUIRE a working understanding of networking; we have yet to escape that. I get how people want to make networking as dumb and simple as possible. However, giving an entire /64 LAN to a single device for a single purpose is certifiably insane. If a 2^64 address LAN cannot hold all of the devices in your house, there's something very wrong here. :-) I do understand the desire, and even need, for system isolation, but a LAN-per-device is beyond insane. Also, until 20$ switches become infinitely more intelligent, the typical home network is a flat network. (with a "maybe" on isolation between wired and wireless) The only logical reason for multiple /64 LANs is multiple, isolated networks... wifi, guest wifi, lan-1, lan-2, lan-3, lan-4 (for 4 port router), beyond physical ports are VLANs and thus switches that can handle VLANs, and something has to configure all that. From jfbeam at gmail.com Mon Dec 2 23:45:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 18:45:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: On Mon, 02 Dec 2013 17:54:50 -0500, Owen DeLong wrote: > I don't know why you think that the PC and Laptop can't talk to each > other. It actually seems to work just fine. They both default to the > upstream router and the router has more specifics to each of the two LAN > segments. You are confusing ROUTING with the WINDOWS FIREWALL (on by default) Wired pinging Wireless will be dropped by the OS as foreign, unsolicited traffic. (I see it often enough: A cannot talk to B because they're in different networks.) > Micr0$0ft doesn't have to make any assumptions at all. In the IPv6 > world, they can use site-scoped multicast (ffx5::). People don't even know what link-local addresses are (and they don't cross links.) Site-local (ULA) requires administrative configuration; no machine, by default, will have a ULA address until manually configured (i.e. they see an RA.) > Frankly, if you're paying for IPv6 space, you're not too bright. You can > go get a direct assignment from an RIR so easily for $100/year that it > just doesn't make sense to pay more than that. If you can justify it. A home user... good luck with that (a: getting the space, and then b: getting Uverse, etc. to use it.) For a business, I always say get your own space, unless you like re-numbering every time you change providers. (we've done it 5 times in 10 years. 'tho none of them have ever supported IPv6; shame on them.) [while "renumbering" the network may be simple, changing the prefix(es) that have been recorded in various systems is still a pain.] From owen at delong.com Mon Dec 2 23:47:38 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 15:47:38 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> Message-ID: On Dec 2, 2013, at 15:10 , Ricky Beam wrote: > On Mon, 02 Dec 2013 17:14:38 -0500, Tony Hain wrote: >> If you even hint at a /64 as the standard for residential deployment, > > I never said that should be the standard. The way most systems do it today, you get a /64 without doing anything. If that's all you need, then you're done. If you want more networks, you ask for them via DHCPv6, and you can ask for prefix size you need (you may not get it, 'tho.) Currently, ISPs are defaulting to /60 as that's fair compromise for current networking. It's an easy limit to change, if they're willing to do it. > >> Trying to develop the automation necessary for consumer plug-n-play >> subnets shows that even a /56 is virtually unusable... > > I'm the insane one for saying a single /64 and a /60 are perfectly workable today, but every damned device in the home getting it's very own /64 is *NECESSARY*??? If that's your only answer to home automation, then you should quit now, and leave the solar system. > > Multiple networks REQUIRE a working understanding of networking; we have yet to escape that. I get how people want to make networking as dumb and simple as possible. However, giving an entire /64 LAN to a single device for a single purpose is certifiably insane. If a 2^64 address LAN cannot hold all of the devices in your house, there's something very wrong here. :-) I do understand the desire, and even need, for system isolation, but a LAN-per-device is beyond insane. Again, the real world has already proven you wrong about this. Multiple home gateways are being sold to people who know nothing about networking and yet are able to work with these gateways that divide their network up into multiple networks. People are able to use mobile hotspot capability on their cell phones and tablets without a working understanding of networking. More automation and improved software are being developed. > Also, until 20$ switches become infinitely more intelligent, the typical home network is a flat network. (with a "maybe" on isolation between wired and wireless) The only logical reason for multiple /64 LANs is multiple, isolated networks... wifi, guest wifi, lan-1, lan-2, lan-3, lan-4 (for 4 port router), beyond physical ports are VLANs and thus switches that can handle VLANs, and something has to configure all that. $40 routers (switches won't cut it here because switches don't cross network boundaries, as anyone with a working knowledge of networking would tell you) are already intelligent enough. What you will find in the future (and are already starting to see today) is things like receivers acting as a router and front-ending an ether-over-HDMI network that interconnects certain capabilities on all of the attached AV components. These capabilities are only beginning to emerge, but they are being built into consumer goods already with IPv4 and will definitely see more complex more capable configurations in IPv6. You will also see things like intelligent refrigerators acting as a router to front end the array of sensors and other connected devices in Pantries and small appliances. You'll start seeing more and more things like smoke detectors and light bulbs that are IPv6 connected and/or 6LOWPAN attached. (Hint, NEST has already released an IPv4 smoke detector). Do you really want your smoke detectors on the same network as your teenager's pr0n surfing? Owen From owen at delong.com Mon Dec 2 23:54:24 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 15:54:24 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: <1FC3F61D-9854-4DA4-AC3B-97C5B4C3AEC0@delong.com> On Dec 2, 2013, at 15:45 , Ricky Beam wrote: > On Mon, 02 Dec 2013 17:54:50 -0500, Owen DeLong wrote: >> I don't know why you think that the PC and Laptop can't talk to each other. It actually seems to work just fine. They both default to the upstream router and the router has more specifics to each of the two LAN segments. > > You are confusing ROUTING with the WINDOWS FIREWALL (on by default) > > Wired pinging Wireless will be dropped by the OS as foreign, unsolicited traffic. (I see it often enough: A cannot talk to B because they're in different networks.) Meh... The firewall will get updated and will have to become more intelligent. Given that Micr0$0ft also turns on automatic updates by default, I'm not too worried about the people who haven't configured their windows box. Besides, Windows is actually losing market share these days anyway. > >> Micr0$0ft doesn't have to make any assumptions at all. In the IPv6 world, they can use site-scoped multicast (ffx5::). > > People don't even know what link-local addresses are (and they don't cross links.) Site-local (ULA) requires administrative configuration; no machine, by default, will have a ULA address until manually configured (i.e. they see an RA.) I didn't say ULA or Site-Local. I said Site-Scoped multicast (ffx5::) specifically. (Site Local is deprecated, ULA is fd00::/8). Further, according to Homenet work going on in the IETF, like it or not, most homenet gateways will be choosing and advertising a ULA prefix for the home in addition to the GUA prefix assigned by the service provider. However, coming back to what I was actually talking about, mDNS/SAP/Network Browser/Network Neighborhood/whatever you want to call the discovery mechanism du jour can find the hosts on the other networks within the site using site-scoped multicast groups (which start with ffx5::/16) and could even do some of their communication (e.g. negotiating for changes in the default firewall posture) via that mechanism. >> Frankly, if you're paying for IPv6 space, you're not too bright. You can go get a direct assignment from an RIR so easily for $100/year that it just doesn't make sense to pay more than that. > > If you can justify it. A home user... good luck with that (a: getting the space, and then b: getting Uverse, etc. to use it.) For a business, I always say get your own space, unless you like re-numbering every time you change providers. (we've done it 5 times in 10 years. 'tho none of them have ever supported IPv6; shame on them.) [while "renumbering" the network may be simple, changing the prefix(es) that have been recorded in various systems is still a pain.] I'm a home user. I run my own /48 ARIN assignment here. I use tunnels to routers in colo and only use Comcast et. al to provide transit for the tunnels themselves. My point is that home users by and large don't pay for any address space and there's not much to be gained from trying to charge them for it. Beyond home users, there's not much point in paying any significant amount of money for it. There's no meaningful cost in providing home users with /48s... So much so, in fact, that the cost of taking even a single phone call complaining about an undersized IPv6 assignment probably more than pays for assigning /48s to 1,000 customers. Owen From jfbeam at gmail.com Tue Dec 3 00:15:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 19:15:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <20131202225952.1C8F2B052B6@rock.dv.isc.org> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <20131202225952.1C8F2B052B6@rock.dv.isc.org> Message-ID: On Mon, 02 Dec 2013 17:59:51 -0500, Mark Andrews wrote: > ... A simple RA/DHCP option could do this. Great. Now I have to go upgrade every g** d*** device in the network to support yet another alteration to the standards. > For the few residential ISP's that do this what is it? $5 / month > per IP and how many ask for a second address? 1 in 10000, 1 in > recover the setup costs. It varies. Bellsouth DSL, it was $15(?) for /32 (it was included in mine) Uverse is $15 for /29. TWC-BC $29(?) for /29. (twc-res doesn't offer it) It turns out to be a mark-up of over 200x their annual cost (and they charge that per month) -- so it's a significant income stream. (how many people are buying, they aren't saying.) > Go ask the bean counters about the cost of having different sized > customers. Those costs will dwarf the income from charging for > bigger address space. For IPv4 there wasn't a choice. For IPv6 > there is the choice of one size for all vs the additional cost of > managing different sized customers. As one who has dealt with such accounting and billing systems, it's actually not that much work. (unless the system pre-dates the internet.) And even more so if the system was designed from the beginning to support it. (as this was already there for IPv4, it should've been included in any additions for IPv6 support.) I doubt we're going to see anyone from the big boys popping up to admit having setup their systems to support micro-allocation billing, but it's a safe bet they have, or they're working on it. From marka at isc.org Tue Dec 3 00:16:27 2013 From: marka at isc.org (Mark Andrews) Date: Tue, 03 Dec 2013 11:16:27 +1100 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: Your message of "Mon, 02 Dec 2013 18:10:28 -0500." References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> Message-ID: <20131203001627.5223EB05758@rock.dv.isc.org> In message , "Ricky Beam" writes: > On Mon, 02 Dec 2013 17:14:38 -0500, Tony Hain wrote: > > If you even hint at a /64 as the standard for residential deployment, > > I never said that should be the standard. The way most systems do it > today, you get a /64 without doing anything. If that's all you need, then > you're done. If you want more networks, you ask for them via DHCPv6, and > you can ask for prefix size you need (you may not get it, 'tho.) > Currently, ISPs are defaulting to /60 as that's fair compromise for > current networking. It's an easy limit to change, if they're willing to do > it. No, it is not a fair limit. > > Trying to develop the automation necessary for consumer plug-n-play > > subnets shows that even a /56 is virtually unusable... > > I'm the insane one for saying a single /64 and a /60 are perfectly > workable today, but every damned device in the home getting it's very own > /64 is *NECESSARY*??? If that's your only answer to home automation, then > you should quit now, and leave the solar system. > > Multiple networks REQUIRE a working understanding of networking; we have > yet to escape that. I get how people want to make networking as dumb and > simple as possible. However, giving an entire /64 LAN to a single device > for a single purpose is certifiably insane. If a 2^64 address LAN cannot > hold all of the devices in your house, there's something very wrong here. > :-) I do understand the desire, and even need, for system isolation, but a > LAN-per-device is beyond insane. So you go from one extreme to another. One lan to one lan-per-device. > Also, until 20$ switches become infinitely more intelligent, the typical > home network is a flat network. (with a "maybe" on isolation between wired > and wireless) The only logical reason for multiple /64 LANs is multiple, > isolated networks... wifi, guest wifi, lan-1, lan-2, lan-3, lan-4 (for 4 > port router), beyond physical ports are VLANs and thus switches that can > handle VLANs, and something has to configure all that. Each of which needs a /64. 16 subnets is incredibly small. It is stifling for developers. PD can do on demand assignment as long as the ISP provides enough space for it. This doesn't have to be heirachically assigned. 65000 x (2 or 3) routes in a home CPE is managable without user intervention. These all get aggregated at the border router. You just build in the assignment algorithms ISP's use today to break up address blocks when you are assigning space customers to allow for customers (down stream devices) to grow the space they need on demand into the CPE devices. This works well enough in reducing internal routes. The only thing stifling this is ISP's being measly with how they hand out address blocks. If ISPs all hand out /60's this sort of development just won't happen and it will be entirely the ISP's fault for being so short sighted. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfbeam at gmail.com Tue Dec 3 00:45:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 19:45:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <1FC3F61D-9854-4DA4-AC3B-97C5B4C3AEC0@delong.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <1FC3F61D-9854-4DA4-AC3B-97C5B4C3AEC0@delong.com> Message-ID: On Mon, 02 Dec 2013 18:54:24 -0500, Owen DeLong wrote: > I said Site-Scoped multicast (ffx5::) And just how does one telnet/ssh/smb/http/whatever to another machine via MULTICAST? You don't. Locating the machine isn't the issue; having an address that can be trivially determined as "local" is. ULA would work, but you'd have to know to use that address instead of any global address. > I'm a home user. I run my own /48 ARIN assignment here. I use tunnels to > routers in colo and only use Comcast et. al to provide transit for the > tunnels themselves. Right. So every "home user" (read: grandmother) should request their own PI space, that they'll then have to tunnel to a far more expensive COLO... PI space is useless to residential customers because no residential ISP will ever bother with the headache. (I never liked dealing with business customers here, and they were paying a lot more for the privilege, and presumably had a clue.) > My point is that home users by and large don't pay for any address space > and there's not much to be gained from trying to charge them for it. ISPs do it right now for IPv4; and it makes them real money. They're not going to want to give that up. You don't, and that's fine. But I can assure you the suits what to keep cashing those checks. From marka at isc.org Tue Dec 3 00:55:56 2013 From: marka at isc.org (Mark Andrews) Date: Tue, 03 Dec 2013 11:55:56 +1100 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: Your message of "Mon, 02 Dec 2013 19:15:28 -0500." References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <20131202225952.1C8F2B052B6@rock.dv.isc.org> Message-ID: <20131203005557.3DF40B059B4@rock.dv.isc.org> In message , "Ricky Beam" writes: > On Mon, 02 Dec 2013 17:59:51 -0500, Mark Andrews wrote: > > ... A simple RA/DHCP option could do this. > > Great. Now I have to go upgrade every g** d*** device in the network to > support yet another alteration to the standards. Guess what, networks evolve and have been evolving for as long as I've been involved which is around 30 years now. There is no reason to expect that they won't stop evolving for the forseeable future. > > For the few residential ISP's that do this what is it? $5 / month > > per IP and how many ask for a second address? 1 in 10000, 1 in > > recover the setup costs. > > It varies. Bellsouth DSL, it was $15(?) for /32 (it was included in mine) > Uverse is $15 for /29. TWC-BC $29(?) for /29. (twc-res doesn't offer it) > > It turns out to be a mark-up of over 200x their annual cost (and they > charge that per month) -- so it's a significant income stream. (how many > people are buying, they aren't saying.) So you have no idea if it is a significant income stream or not. > > Go ask the bean counters about the cost of having different sized > > customers. Those costs will dwarf the income from charging for > > bigger address space. For IPv4 there wasn't a choice. For IPv6 > > there is the choice of one size for all vs the additional cost of > > managing different sized customers. > > As one who has dealt with such accounting and billing systems, it's > actually not that much work. (unless the system pre-dates the internet.) > And even more so if the system was designed from the beginning to support > it. (as this was already there for IPv4, it should've been included in any > additions for IPv6 support.) I doubt we're going to see anyone from the > big boys popping up to admit having setup their systems to support > micro-allocation billing, but it's a safe bet they have, or they're > working on it. Except it is not just the accounting and billing systems. Additionally when you factor in everyone is getting multiple GUA by default the number of customers that need to pay for additional addresses drops by orders of magnitude it doesn't remain cost effective to charge for address space. If you are being charged anything to get a /48 over a /56 or a /60 you are being ripped off. If you can't get a /48 you are being ripped off. The public will learn this as will the regulators that protect customers. There actually is a IPv4 address shortage. There isn't a IPv6 address shortage. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gary.buhrmaster at gmail.com Tue Dec 3 00:57:14 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Tue, 3 Dec 2013 00:57:14 +0000 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> Message-ID: On Mon, Dec 2, 2013 at 11:47 PM, Owen DeLong wrote: .... > (Hint, NEST has already released an IPv4 smoke detector). And they really should have enabled IPv6 on it :-( But the processor should be able to handle it, if they update the firmware. I hear Tado does IPv6. From owen at delong.com Tue Dec 3 01:07:40 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 17:07:40 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <20131202225952.1C8F2B052B6@rock.dv.isc.org> Message-ID: <1B1D549D-F9A6-4928-874C-2718AD6E929A@delong.com> On Dec 2, 2013, at 16:15 , Ricky Beam wrote: > On Mon, 02 Dec 2013 17:59:51 -0500, Mark Andrews wrote: >> ... A simple RA/DHCP option could do this. > > Great. Now I have to go upgrade every g** d*** device in the network to support yet another alteration to the standards. > >> For the few residential ISP's that do this what is it? $5 / month >> per IP and how many ask for a second address? 1 in 10000, 1 in >> recover the setup costs. > > It varies. Bellsouth DSL, it was $15(?) for /32 (it was included in mine) Uverse is $15 for /29. TWC-BC $29(?) for /29. (twc-res doesn't offer it) > > It turns out to be a mark-up of over 200x their annual cost (and they charge that per month) -- so it's a significant income stream. (how many people are buying, they aren't saying.) Actually, on DSL, it's ridiculous, but for Cable operators, most of the cost is that static addresses are a major pain due to the way cable works. Whenever they split or combine a CMTS or head-end (which is apparently a frequent operation for capacity management according to people I know at MSOs), the static addresses require all kinds of additional configuration effort. Likely, they aren't making much money on it, but that's not address quantity, that's static address management. Admittedly, they do charge by the address, but I think that's only in IPv4. > >> Go ask the bean counters about the cost of having different sized >> customers. Those costs will dwarf the income from charging for >> bigger address space. For IPv4 there wasn't a choice. For IPv6 >> there is the choice of one size for all vs the additional cost of >> managing different sized customers. > > As one who has dealt with such accounting and billing systems, it's actually not that much work. (unless the system pre-dates the internet.) And even more so if the system was designed from the beginning to support it. (as this was already there for IPv4, it should've been included in any additions for IPv6 support.) I doubt we're going to see anyone from the big boys popping up to admit having setup their systems to support micro-allocation billing, but it's a safe bet they have, or they're working on it. I actually tend to doubt it. All of the people I've talked to from the major operators have said that the charges in IPv4 were not a revenue source, they were an effort to discourage the consumption of the addresses and/or the use of static addresses and to try and recover the costs of dealing with them in cases where customers were willing to pay. There's a reason we don't (generally) pay for metered long distance within the US any more. IPv6 addresses should be pretty much the same. Owen From jfbeam at gmail.com Tue Dec 3 01:20:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 20:20:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <20131203001627.5223EB05758@rock.dv.isc.org> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> <20131203001627.5223EB05758@rock.dv.isc.org> Message-ID: On Mon, 02 Dec 2013 19:16:27 -0500, Mark Andrews wrote: > So you go from one extreme to another. One lan to one lan-per-device. No. I'm complaning about how the automatic solution to segmenting the home ("homenet") doesn't put any thought into it at all, and puts everything in it's own network. I cannot believe anyone would ever put that on paper, but they did. Anyway. If you want your home segmented, then a human being needs to take a few minutes to think about it and then configure the network (physical and logical) and devices accordingly. That's a very complex problem to solve via AutoMagic Technology(TM) (hence the homenet approach.) >> isolated networks... wifi, guest wifi, lan-1, lan-2, lan-3, lan-4 (for 4 > > Each of which needs a /64. 16 subnets is incredibly small. In this example, it takes 6. Six. 16 is almost 3x that, and thus, plenty big enough. As we're getting our prefex via DHCPv6-PD, it's not hard to ask for a larger prefix when needed. (of course, every idiot is going to ask for the largest prefix possible, and then only use 3 /64's) > The only thing stifling this is ISP's being measly with how they > hand out address blocks. If ISPs all hand out /60's this sort of > development just won't happen and it will be entirely the ISP's > fault for being so short sighted. They could be do much worse... if you throw out SLAAC, your network(s) can be smaller than /64. I don't want to give them any ideas, but Uverse could use their monopoly on routers to make your lan a DHCP only /120. From owen at delong.com Tue Dec 3 01:18:08 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 17:18:08 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <1FC3F61D-9854-4DA4-AC3B-97C5B4C3AEC0@delong.com> Message-ID: On Dec 2, 2013, at 16:45 , Ricky Beam wrote: > On Mon, 02 Dec 2013 18:54:24 -0500, Owen DeLong wrote: >> I said Site-Scoped multicast (ffx5::) > > And just how does one telnet/ssh/smb/http/whatever to another machine via MULTICAST? You don't. Locating the machine isn't the issue; having an address that can be trivially determined as "local" is. ULA would work, but you'd have to know to use that address instead of any global address. > You don't, but it's easy enough for Windows to do discovery and/or negotiation for firewall holes with multicast and avoid making assumptions about where the site boundary is. You made the claim that additional assumptions were required. I countered that argument. Mark countered with another alternative solution which would require updating the software. My solution has the advantage that only windows firewalls need to be updated and that could be handled by a windows auto-update (which is on by default in current versions of windows unless you have already performed manual intervention, in which case I don't see manual intervention on the firewall as a huge additional hurdle). >> I'm a home user. I run my own /48 ARIN assignment here. I use tunnels to routers in colo and only use Comcast et. al to provide transit for the tunnels themselves. > > Right. So every "home user" (read: grandmother) should request their own PI space, that they'll then have to tunnel to a far more expensive COLO... I didn't say that it was the right solution for everyone. I said that it was an effective solution for some. > > PI space is useless to residential customers because no residential ISP will ever bother with the headache. (I never liked dealing with business customers here, and they were paying a lot more for the privilege, and presumably had a clue.) To each their own. FWIW, you can run a BGP tunnel with HE at no cost, so IPv6 PI for free is a viable option. Again, not saying it's the solution for everyone, just saying that it can be done. > >> My point is that home users by and large don't pay for any address space and there's not much to be gained from trying to charge them for it. > > ISPs do it right now for IPv4; and it makes them real money. They're not going to want to give that up. You don't, and that's fine. But I can assure you the suits what to keep cashing those checks. No, it doesn't. It keeps users from using more space more than it brings in revenue. Mostly it's a "headache charge". They can't get away with flat out saying no, so they price it into the "only if you're really serious about wanting it" category and that limits the number of customers asking for it. In IPv4, where address scarcity is an issue, this makes sense. In IPv6, they should be laughed out of existence if they engage in such silliness. You are assuming that I don't talk to the people that deal with this stuff at the major providers. You are mistaken in that assumption. Owen From owen at delong.com Tue Dec 3 01:21:03 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 17:21:03 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> Message-ID: On Dec 2, 2013, at 16:57 , Gary Buhrmaster wrote: > On Mon, Dec 2, 2013 at 11:47 PM, Owen DeLong wrote: > .... >> (Hint, NEST has already released an IPv4 smoke detector). > > And they really should have enabled IPv6 on it :-( > But the processor should be able to handle it, if > they update the firmware. I hear Tado does IPv6. The problem with Tado is that it doesn't do AC, only heat. I am not so sure about Nest being able to do that with a firmware upgrade. I haven't looked inside of one, but someone told me that they were using Wiznet chips. If they are, then that's IPv4 baked into the hardware of the chip and it won't do IPv6. This has been a huge problem with trying to do anything IPv6-oriented in the Arduino and other Microcontroller world. The Raspberry PI and the UDOO are the first semi-promising solutions that I am aware of in this arean, though the Cubie board and Beagle bone have some capabilities here as well... They're just a bit on the pricey side. Owen From owen at delong.com Tue Dec 3 01:27:36 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 17:27:36 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> <20131203001627.5223EB05758@rock.dv.isc.org> Message-ID: On Dec 2, 2013, at 17:20 , Ricky Beam wrote: > On Mon, 02 Dec 2013 19:16:27 -0500, Mark Andrews wrote: >> So you go from one extreme to another. One lan to one lan-per-device. > > No. I'm complaning about how the automatic solution to segmenting the home ("homenet") doesn't put any thought into it at all, and puts everything in it's own network. I cannot believe anyone would ever put that on paper, but they did. That isn't how I read any of the drafts that I've seen, so I'm not sure where you get this. > > Anyway. If you want your home segmented, then a human being needs to take a few minutes to think about it and then configure the network (physical and logical) and devices accordingly. That's a very complex problem to solve via AutoMagic Technology(TM) (hence the homenet approach.) Nope... You plug in the top level router, then start plugging stuff into it. Switches, other nodes, other routers. In the case of other routers, then you plug stuff into them. Lather, rinse, repeat. Wherever you have a router, you have a boundary between links. Simple as that. It's actually not complex for technology to figure out a hierarchy of routers and allocate prefixes to them, but it doesn't work out very well if you only have a few bits to play with and have to dense-pack the allocations. It basically boils down to spanning tree on steroids if you have a wide enough bit field to handle the breadth and depth of the hierarchy. > >>> isolated networks... wifi, guest wifi, lan-1, lan-2, lan-3, lan-4 (for 4 >> >> Each of which needs a /64. 16 subnets is incredibly small. > > In this example, it takes 6. Six. 16 is almost 3x that, and thus, plenty big enough. Depends on how they are connected and how you want the automation to work. Do you want room to grow at the various levels of the hierarchy? What happens when someone plugs a new router in between LAN2 and LAN3 that also connects LANS 5, 6, 7, and 8? > As we're getting our prefex via DHCPv6-PD, it's not hard to ask for a larger prefix when needed. (of course, every idiot is going to ask for the largest prefix possible, and then only use 3 /64's) So what? If the largest prefix possible is a /48, then every idiot has more than enough space to do what they need and there's no harm to the ISP or anyone else. Sounds like an ideal solution to me. >> The only thing stifling this is ISP's being measly with how they >> hand out address blocks. If ISPs all hand out /60's this sort of >> development just won't happen and it will be entirely the ISP's >> fault for being so short sighted. > > They could be do much worse... if you throw out SLAAC, your network(s) can be smaller than /64. I don't want to give them any ideas, but Uverse could use their monopoly on routers to make your lan a DHCP only /120. I think if they did that, they'd do more to evaporate Uverse customers than to change the world of IPv6 routing at this point. Owen From surfer at mauigateway.com Tue Dec 3 01:41:55 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 2 Dec 2013 17:41:55 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO Message-ID: <20131202174155.B5BE600D@m0005299.ppops.net> --- owen at delong.com wrote: From: Owen DeLong I actually tend to doubt it. All of the people I've talked to from the major operators have said that the charges in IPv4 were not a revenue source, they were an effort to discourage the consumption of the addresses and/or the use of static addresses and to try and recover the costs of dealing with them in cases where customers were willing to pay. ------------------------------------------ Not jumping into the turd chunkin' contest, but this is not my experience. The suits definitely want the money for income stream; small as it may be. I'd like to hear from others if their experiences are different. scott From jfbeam at gmail.com Tue Dec 3 01:50:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 20:50:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <1B1D549D-F9A6-4928-874C-2718AD6E929A@delong.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <20131202225952.1C8F2B052B6@rock.dv.isc.org> <1B1D549D-F9A6-4928-874C-2718AD6E929A@delong.com> Message-ID: On Mon, 02 Dec 2013 20:07:40 -0500, Owen DeLong wrote: > Whenever they split or combine a CMTS or head-end... Shouldn't matter unless they're moving things across DHCP servers. (which is likely from what I've heard about TWC, and seen from my own modems. In fact, the addresses in my office changed last week; we aren't paying for statics.) > I actually tend to doubt it. All of the people I've talked to from the > major operators have said that the charges in IPv4 were not a revenue > source, they were an effort to discourage the consumption of the > addresses and/or the use of static addresses and to try and recover the > costs of dealing with them in cases where customers were willing to pay. Yeah, we all say that. *grin* But I went and looked at the numbers... it was several times my yearly salary, per month @ a business ISP. I would assume with residential, people are more cost sensitive and won't pay for address space they won't use. (but I know first hand that's not entirely true.) From bicknell at ufp.org Tue Dec 3 01:56:13 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 2 Dec 2013 19:56:13 -0600 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: On Dec 2, 2013, at 4:35 PM, Ricky Beam wrote: > DHCPv6-PD isn't a "restriction", it's simply what gets handed out today. A "simple" reconfiguration on the DHCP server and it's handing out /56's instead. (or *allowing* /56's if requested -- it's better to let the customer ask for what they need/want; assuming they just default to asking for the largest block they're allowed and using only 3 networks.) I find it amusing that people want to argue both that: - A /56 is horribly wrong and the world will end if we don't fix it NOW. - Providers could give out more by simply changing a setting on the DHCP server. I would love to know what number of home users need 256 subnets. The good news is that folks doing DHCP-PD will be able to report on how many people request all 256 networks available, and are thus "out". In fact they can make a histogram from 1 to 256 networks per household, and show us how many request each number of subnets. I challenge Comcast, AT&T, and others to do just that, and publish it on a regular basis, if only to make people stop talking about this "issue". -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From jfbeam at gmail.com Tue Dec 3 02:05:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 21:05:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <1FC3F61D-9854-4DA4-AC3B-97C5B4C3AEC0@delong.com> Message-ID: On Mon, 02 Dec 2013 20:18:08 -0500, Owen DeLong wrote: > You don't, but it's easy enough for Windows to do discovery and/or > negotiation for firewall holes with multicast and avoid making ... Actually, your process still makes a very dangerous assumption... you have to assume the address passed via multicast is, in fact, a local address. Since it is necessarily outside your prefix, you have to either make assumptions about what is "close" to your prefix -- assumes the site is contiguous, or trust any address passed to you. Hackers will have fun screwing up your firewall rules and potentially breaking into your servers. (if you're foolish enough to not have any other layers in your network, which is likely with home networks.) > ... They can't get away with flat out saying no... Says who? TWC has been saying "no" for years. (unless I'm mistaken, "always".) From jfbeam at gmail.com Tue Dec 3 02:20:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 21:20:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> <20131203001627.5223EB05758@rock.dv.isc.org> Message-ID: On Mon, 02 Dec 2013 20:27:36 -0500, Owen DeLong wrote: >> They could be do much worse... if you throw out SLAAC, your network(s) >> can be smaller than /64. I don't want to give them any ideas, but >> Uverse could use their monopoly on routers to make your lan a DHCP only >> /120. > > I think if they did that, they'd do more to evaporate Uverse customers > than to change the world of IPv6 routing at this point. I'd like to see the results of such an experiment. I suspect 90% of their users wouldn't even notice. (given how many don't even realize IPv6 is on, until some site(s) run dog slow until they're told (how) to turn IPv6 off.) Not counting MAC users, because they cannot do DHCPv6 without 3rd party software. Nobody really cared with they limited what RFC1918 space you could use. (not sure they're still doing that.) From randy at psg.com Tue Dec 3 02:27:23 2013 From: randy at psg.com (Randy Bush) Date: Tue, 03 Dec 2013 11:27:23 +0900 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <20131202174155.B5BE600D@m0005299.ppops.net> References: <20131202174155.B5BE600D@m0005299.ppops.net> Message-ID: > From: Owen DeLong > > I actually tend to doubt it. All of the people I've talked to from the major > operators have said that the charges in IPv4 were not a revenue source, they > were an effort to discourage the consumption of the addresses and/or the use > of static addresses and to try and recover the costs of dealing with them in > cases where customers were willing to pay. > ------------------------------------------ > Not jumping into the turd chunkin' contest, but this is not my experience. > The suits definitely want the money for income stream; small as it may be. > I'd like to hear from others if their experiences are different. oss ops cost reduction randy From jfbeam at gmail.com Tue Dec 3 02:35:28 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 21:35:28 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: On Mon, 02 Dec 2013 20:56:13 -0500, Leo Bicknell wrote: > - A /56 is horribly wrong and the world will end if we don't fix it NOW. I'm reminded of the Comcast trial deployments. Wasn't their conclusion (with a collective thumbs up from the networking world) to go with /56? Yet, even they are handing out little old /60's. > I would love to know what number of home users need 256 subnets. The > good news is that folks doing DHCP-PD will be able to report on how many > people request all 256 networks available, and are thus "out". In fact > they can make a histogram from 1 to 256 networks per household, and show > us how many request each number of subnets. It doesn't work that way. Routers aren't asking for individual prefixes ('tho I suppose it's possible.) They ask for a /60 or /56, and then assign the space as necessary. Thus, the ISP has no idea how many /64's are actually being used. From streiner at cluebyfour.org Mon Dec 2 23:06:43 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 2 Dec 2013 18:06:43 -0500 (EST) Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <20131202225952.1C8F2B052B6@rock.dv.isc.org> Message-ID: On Mon, 2 Dec 2013, Ricky Beam wrote: > On Mon, 02 Dec 2013 17:59:51 -0500, Mark Andrews wrote: >> ... A simple RA/DHCP option could do this. > > Great. Now I have to go upgrade every g** d*** device in the network to > support yet another alteration to the standards. The standards orgs shot us all in the foot by not including an RA option in DHCPv6 from day one. > It turns out to be a mark-up of over 200x their annual cost (and they charge > that per month) -- so it's a significant income stream. (how many people are > buying, they aren't saying.) Verizon hits me up for something like an extra $20/month to get a static IPv4 address for my Fios service, plus I had to buy a business service to get it. Worse than the mark-up on wine at a nice restaurant ;) jms From owen at delong.com Tue Dec 3 03:03:59 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 19:03:59 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> <20131203001627.5223EB05758@rock.dv.isc.org> Message-ID: <6A1CBDEF-E19C-4AAC-91DD-A344D281EE89@delong.com> On Dec 2, 2013, at 18:20 , Ricky Beam wrote: > On Mon, 02 Dec 2013 20:27:36 -0500, Owen DeLong wrote: >>> They could be do much worse... if you throw out SLAAC, your network(s) can be smaller than /64. I don't want to give them any ideas, but Uverse could use their monopoly on routers to make your lan a DHCP only /120. >> >> I think if they did that, they'd do more to evaporate Uverse customers than to change the world of IPv6 routing at this point. > > I'd like to see the results of such an experiment. I suspect 90% of their users wouldn't even notice. (given how many don't even realize IPv6 is on, until some site(s) run dog slow until they're told (how) to turn IPv6 off.) > > Not counting MAC users, because they cannot do DHCPv6 without 3rd party software. My Macs seem to do DHCPv6 just fine here without third party software, so I'm not sure what you are talking about. > > Nobody really cared with they limited what RFC1918 space you could use. (not sure they're still doing that.) Not sure what you mean here since RFC-1918 is IPv4 only. Owen From owen at delong.com Tue Dec 3 03:02:39 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 19:02:39 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <1FC3F61D-9854-4DA4-AC3B-97C5B4C3AEC0@delong.com> Message-ID: <3F783C20-B412-47BC-B951-C3863E807CB4@delong.com> On Dec 2, 2013, at 18:05 , Ricky Beam wrote: > On Mon, 02 Dec 2013 20:18:08 -0500, Owen DeLong wrote: >> You don't, but it's easy enough for Windows to do discovery and/or negotiation for firewall holes with multicast and avoid making > ... > > Actually, your process still makes a very dangerous assumption... you have to assume the address passed via multicast is, in fact, a local address. Since it is necessarily outside your prefix, you have to either make assumptions about what is "close" to your prefix -- assumes the site is contiguous, or trust any address passed to you. Hackers will have fun screwing up your firewall rules and potentially breaking into your servers. (if you're foolish enough to not have any other layers in your network, which is likely with home networks.) > Not really... First of all, domain or other windows authentication could be used to validate the request. Second, if it's site-scope multicast, unless both your ISP _AND_ your own router are doing something wrong, it shouldn't get forwarded into your site from outside. >> ... They can't get away with flat out saying no... > > Says who? TWC has been saying "no" for years. (unless I'm mistaken, "always".) No, they've said "get a business connection." Close to "no", but not identical. Owen From jfbeam at gmail.com Tue Dec 3 03:24:27 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 22:24:27 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <3F783C20-B412-47BC-B951-C3863E807CB4@delong.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <1FC3F61D-9854-4DA4-AC3B-97C5B4C3AEC0@delong.com> <3F783C20-B412-47BC-B951-C3863E807CB4@delong.com> Message-ID: On Mon, 02 Dec 2013 22:02:39 -0500, Owen DeLong wrote: > Not really... First of all, domain or other windows authentication could > be used to validate the request. Most home networks aren't part of a domain. (unless they're using versions beyond "home", they can't) > Second, if it's site-scope multicast, unless both your ISP _AND_ your > own router are doing something wrong, it shouldn't get forwarded into > your site from outside. All they have to do is get a single computer inside your network to run their little program. Drive-by download, any number of browser exploits, one idiot user... Go talk to the security crowd about UPnP if you really want one computer to be able to ask another computer to alter it's firewall rules. (domain policies do actually address this.) From jfbeam at gmail.com Tue Dec 3 03:34:27 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 02 Dec 2013 22:34:27 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <6A1CBDEF-E19C-4AAC-91DD-A344D281EE89@delong.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> <20131203001627.5223EB05758@rock.dv.isc.org> <6A1CBDEF-E19C-4AAC-91DD-A344D281EE89@delong.com> Message-ID: On Mon, 02 Dec 2013 22:03:59 -0500, Owen DeLong wrote: >> Not counting MAC users, because they cannot do DHCPv6 without 3rd party >> software. > > My Macs seem to do DHCPv6 just fine here without third party software, > so I'm not sure what you are talking about. I've heard many reports of apple not supporting DHCPv6 up to 10.7. After much digging, I have found a single report of it working in 10.8. So, if you're up-to-date, you wouldn't notice it either. :-) >> Nobody really cared with they limited what RFC1918 space you could use. >> (not sure they're still doing that.) > > Not sure what you mean here since RFC-1918 is IPv4 only. Just providing an example of AT&T Uverse lunacy that hasn't resulted in millions of customers leaving. If you want an IPv6 example, their recent 2wire firmware update that broke proto-41 tunnels has met with an equally fervent "gee-whiz, att" response. From owen at delong.com Tue Dec 3 03:46:04 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 19:46:04 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> <20131203001627.5223EB05758@rock.dv.isc.org> <6A1CBDEF-E19C-4AAC-91DD-A344D281EE89@delong.com> Message-ID: <3DFC777A-1CBB-44C2-8D57-15A5A5DE88EC@delong.com> On Dec 2, 2013, at 19:34 , Ricky Beam wrote: > On Mon, 02 Dec 2013 22:03:59 -0500, Owen DeLong wrote: >>> Not counting MAC users, because they cannot do DHCPv6 without 3rd party software. >> >> My Macs seem to do DHCPv6 just fine here without third party software, so I'm not sure what you are talking about. > > I've heard many reports of apple not supporting DHCPv6 up to 10.7. After much digging, I have found a single report of it working in 10.8. So, if you're up-to-date, you wouldn't notice it either. :-) It worked in some later versions of 10.7, all versions of 10.8 and still works in 10.9. Given that 10.7 is fairly ancient at this point, I really don't think you have to be all that up to date to have it work. Given that 10.9 is a 100% free upgrade for anyone with a Mac and that nobody has reported any major problems with it that I know of, I would think that the number of people holding back from upgrading, especially if the need IPv6, would be relatively low. > >>> Nobody really cared with they limited what RFC1918 space you could use. (not sure they're still doing that.) >> >> Not sure what you mean here since RFC-1918 is IPv4 only. > > Just providing an example of AT&T Uverse lunacy that hasn't resulted in millions of customers leaving. If you want an IPv6 example, their recent 2wire firmware update that broke proto-41 tunnels has met with an equally fervent "gee-whiz, att" response. Actually I know several people that cancelled their UVerse subscriptions when ATT broke protocol 41. There are also some FCC complaints that have been lodged if what people are telling me is true. Owen From drais at icantclick.org Tue Dec 3 03:58:02 2013 From: drais at icantclick.org (david raistrick) Date: Mon, 2 Dec 2013 22:58:02 -0500 (EST) Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <3DFC777A-1CBB-44C2-8D57-15A5A5DE88EC@delong.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> <20131203001627.5223EB05758@rock.dv.isc.org> <6A1CBDEF-E19C-4AAC-91DD-A344D281EE89@delong.com> <3DFC777A-1CBB-44C2-8D57-15A5A5DE88EC@delong.com> Message-ID: On Mon, 2 Dec 2013, Owen DeLong wrote: > Given that 10.7 is fairly ancient at this point I know, right? 2.5 years old is -ancient- . o O ( sigh ) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From rs at seastrom.com Tue Dec 3 04:11:00 2013 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 02 Dec 2013 23:11:00 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: (Ricky Beam's message of "Mon, 02 Dec 2013 16:25:27 -0500") References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: <86haaq60bv.fsf@valhalla.seastrom.com> "Ricky Beam" writes: > On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom wrote: >> So there really is no excuse on AT&T's part for the /60s on uverse 6rd... > ... > Handing out /56's like Pez is just wasting address space -- someone > *is* paying for that space. Yes, it's waste; giving everyone 256 > networks when they're only ever likely to use one or two (or maybe > four), is intentionally wasting space you could've assigned to > someone else. (or **sold** to someone else :-)) IPv6 may be huge to > the power of huge, but it's still finite. People like you are > repeating the same mistakes from the early days of IPv4... There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. Suppose that every mobile phone on the face of the planet was an "end site" in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Now give such a phone to every human on the face of the earth. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. -r From LarrySheldon at cox.net Tue Dec 3 04:19:06 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 02 Dec 2013 22:19:06 -0600 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <20131202225952.1C8F2B052B6@rock.dv.isc.org> Message-ID: <529D5BBA.4040503@cox.net> On 12/2/2013 6:15 PM, Ricky Beam wrote: > On Mon, 02 Dec 2013 17:59:51 -0500, Mark Andrews wrote: >> ... A simple RA/DHCP option could do this. > > Great. Now I have to go upgrade every g** d*** device in the network to > support yet another alteration to the standards. I have some good news for you. It is not longer necessary to have somebody walking in front of your car (if it is motion) with a lantern and a bell. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Tue Dec 3 04:21:45 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 02 Dec 2013 22:21:45 -0600 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: Message-ID: <529D5C59.3060008@cox.net> On 12/2/2013 7:41 PM, Scott Weeks wrote: > > > --- owen at delong.com wrote: > From: Owen DeLong > > I actually tend to doubt it. All of the people I've talked to from the major > operators have said that the charges in IPv4 were not a revenue source, they > were an effort to discourage the consumption of the addresses and/or the use > of static addresses and to try and recover the costs of dealing with them in > cases where customers were willing to pay. Do you know to what charity they donate everything in excess of their costs? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From owen at delong.com Tue Dec 3 04:51:44 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 20:51:44 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <015701ceefab$e45513b0$acff3b10$@tndh.net> <20131203001627.5223EB05758@rock.dv.isc.org> <6A1CBDEF-E19C-4AAC-91DD-A344D281EE89@delong.com> <3DFC777A-1CBB-44C2-8D57-15A5A5DE88EC@delong.com> Message-ID: <11428269-1649-454F-8CE9-AFE8BAD8E03F@delong.com> Two major versions back, is fairly ancient in internet years, yes. Owen On Dec 2, 2013, at 19:58 , david raistrick wrote: > On Mon, 2 Dec 2013, Owen DeLong wrote: > >> Given that 10.7 is fairly ancient at this point > > I know, right? 2.5 years old is -ancient- > > . o O ( sigh ) > > > > -- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org ascii ribbon campaign - stop html mail > http://www.asciiribbon.org/ > > From owen at delong.com Tue Dec 3 04:50:27 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Dec 2013 20:50:27 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <86haaq60bv.fsf@valhalla.seastrom.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <86haaq60bv.fsf@valhalla.seastrom.com> Message-ID: <7777F1D5-F830-4AC6-B84F-90A228A606E3@delong.com> On Dec 2, 2013, at 20:11 , Rob Seastrom wrote: > > "Ricky Beam" writes: > >> On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom wrote: >>> So there really is no excuse on AT&T's part for the /60s on uverse 6rd... >> ... >> Handing out /56's like Pez is just wasting address space -- someone >> *is* paying for that space. Yes, it's waste; giving everyone 256 >> networks when they're only ever likely to use one or two (or maybe >> four), is intentionally wasting space you could've assigned to >> someone else. (or **sold** to someone else :-)) IPv6 may be huge to >> the power of huge, but it's still finite. People like you are >> repeating the same mistakes from the early days of IPv4... > > There's finite, and then there's finite. Please complete the > following math assignment so as to calibrate your perceptions before > leveling further allegations of profligate waste. > > Suppose that every mobile phone on the face of the planet was an "end > site" in the classic sense and got a /48 (because miraculously, > the mobile providers aren't being stingy). > > Now give such a phone to every human on the face of the earth. > > Unfortunately for our conservation efforts, every person with a > cell phone is actually the cousin of either Avi Freedman or Vijay > Gill, and consequently actually has FIVE cell phones on active > plans at any given time. > > Assume 2:1 overprovisioning of address space because per Cameron > Byrne's comments on ARIN 2013-2, the cellular equipment providers > can't seem to figure out how to have N+1 or N+2 redundancy rather > than 2N redundancy on Home Agent hardware. > > What percentage of the total available IPv6 space have we burned > through in this scenario? Show your work. > > -r > Quick napkin version: 6.8 Billion people * 10 = 68Billion /48s. 32 bits = 4 billion (we all know that from IPv4, right?) A /16 is 4 Billion /48s. A /15 is 8 Billion A /14 is 16 Billion A /13 is 32 Billion A /12 is 64 Billion A /11 leaves room to spare at more than 128 Billion /48s. So, we need 2 /12s. We have already issued RIRs 6 /12s (as of 3Q2013), leaving 506 /13s in 2000::/3 We could easily issue the global total need of 2 /12s (a /11) to each RIR (there are 5), so total of 10 in addition to what has already been issued, and we'd have issued a total of 16 /12s leaving 494 /12s in inventory in 2000::/3. For convenience, I will remind everyone that 2000::/2 represents 1/8th of the total address space. Further, for those that are worried about population explosions causing this not to scale, even if the population on the planet expanded by an order of magnitude so that we had to issue 100 /12s, w would still have 406 /12s remaining in 2000::/3. Owen From eric.oosting at gmail.com Tue Dec 3 05:04:29 2013 From: eric.oosting at gmail.com (Eric Oosting) Date: Tue, 3 Dec 2013 00:04:29 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <86haaq60bv.fsf@valhalla.seastrom.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <86haaq60bv.fsf@valhalla.seastrom.com> Message-ID: On Mon, Dec 2, 2013 at 11:11 PM, Rob Seastrom wrote: > > "Ricky Beam" writes: > > > On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > wrote: > >> So there really is no excuse on AT&T's part for the /60s on uverse > 6rd... > > ... > > Handing out /56's like Pez is just wasting address space -- someone > > *is* paying for that space. Yes, it's waste; giving everyone 256 > > networks when they're only ever likely to use one or two (or maybe > > four), is intentionally wasting space you could've assigned to > > someone else. (or **sold** to someone else :-)) IPv6 may be huge to > > the power of huge, but it's still finite. People like you are > > repeating the same mistakes from the early days of IPv4... > > There's finite, and then there's finite. Please complete the > following math assignment so as to calibrate your perceptions before > leveling further allegations of profligate waste. > I know this is rhetorical, but my hobby is answering peoples rhetorical questions. > > Suppose that every mobile phone on the face of the planet was an "end > site" in the classic sense and got a /48 (because miraculously, > the mobile providers aren't being stingy). > Very well, I'll play your silly game. 48 bits remaining. > > Now give such a phone to every human on the face of the earth. > 33 bits should do it. That gets us to nearly 9 billion people. 15 bits remaining. > Unfortunately for our conservation efforts, every person with a > cell phone is actually the cousin of either Avi Freedman or Vijay > Gill, and consequently actually has FIVE cell phones on active > plans at any given time. > 5 is inconvenient. Lets give everyone 8 mobil phones, using 3 bits. 12 bits remaining. > > Assume 2:1 overprovisioning of address space because per Cameron > Byrne's comments on ARIN 2013-2, the cellular equipment providers > can't seem to figure out how to have N+1 or N+2 redundancy rather > than 2N redundancy on Home Agent hardware. > 1 bit for that. 11 bits remaining. Now we're assigning space out of 2000::/3 for now ... lets keep the other 7/8ths of the ipv6 address block in reserve, using another 3 bits ... leaving ... carry the one ... 8 bits. > > What percentage of the total available IPv6 space have we burned > through in this scenario? Show your work. > If we give every man, woman, and child on the face of the earth the equivalent to (16) /48s each, we'll will have used 1/256th of the first 1/8th of the IPv6 address space. Wolfram says there have been 110 billion homo sapiens that have ever lived. We need to give every person who has literally ever lived on planet earth their own /40 before we've used up 2000::/3, and need to move on to the remaining 87.5% of the address space. (this is where someone will ding me for the misuse of "literally" somehow with a pointer to theoatmeal comic, right) -e > > -r > > > From james.cutler at consultant.com Tue Dec 3 05:56:40 2013 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 3 Dec 2013 00:56:40 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <86haaq60bv.fsf@valhalla.seastrom.com> Message-ID: <3FFD03CC-CE6A-4486-8921-FC8CD2EA4AD5@consultant.com> On Dec 3, 2013, at 12:04 AM, Eric Oosting wrote: > On Mon, Dec 2, 2013 at 11:11 PM, Rob Seastrom wrote: > >> >> "Ricky Beam" writes: >> >>> On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom >> wrote: >>>> So there really is no excuse on AT&T's part for the /60s on uverse >> 6rd... >>> ... >>> Handing out /56's like Pez is just wasting address space -- someone >>> *is* paying for that space. Yes, it's waste; giving everyone 256 >>> networks when they're only ever likely to use one or two (or maybe >>> four), is intentionally wasting space you could've assigned to >>> someone else. (or **sold** to someone else :-)) IPv6 may be huge to >>> the power of huge, but it's still finite. People like you are >>> repeating the same mistakes from the early days of IPv4... >> >> There's finite, and then there's finite. Please complete the >> following math assignment so as to calibrate your perceptions before >> leveling further allegations of profligate waste. >> > > I know this is rhetorical, but my hobby is answering peoples rhetorical > questions. > > >> >> Suppose that every mobile phone on the face of the planet was an "end >> site" in the classic sense and got a /48 (because miraculously, >> the mobile providers aren't being stingy). >> > > Very well, I'll play your silly game. > > 48 bits remaining. > > >> >> Now give such a phone to every human on the face of the earth. >> > > 33 bits should do it. That gets us to nearly 9 billion people. > > 15 bits remaining. > > >> Unfortunately for our conservation efforts, every person with a >> cell phone is actually the cousin of either Avi Freedman or Vijay >> Gill, and consequently actually has FIVE cell phones on active >> plans at any given time. >> > > 5 is inconvenient. Lets give everyone 8 mobil phones, using 3 bits. > > 12 bits remaining. > > >> >> Assume 2:1 overprovisioning of address space because per Cameron >> Byrne's comments on ARIN 2013-2, the cellular equipment providers >> can't seem to figure out how to have N+1 or N+2 redundancy rather >> than 2N redundancy on Home Agent hardware. >> > > 1 bit for that. > > 11 bits remaining. > > Now we're assigning space out of 2000::/3 for now ... lets keep the other > 7/8ths of the ipv6 address block in reserve, using another 3 bits ... > leaving ... carry the one ... 8 bits. > > >> >> What percentage of the total available IPv6 space have we burned >> through in this scenario? Show your work. >> > > If we give every man, woman, and child on the face of the earth the > equivalent to (16) /48s each, we'll will have used 1/256th of the first > 1/8th of the IPv6 address space. > > Wolfram says there have been 110 billion homo sapiens that have ever lived. > We need to give every person who has literally ever lived on planet earth > their own /40 before we've used up 2000::/3, and need to move on to the > remaining 87.5% of the address space. (this is where someone will ding me > for the misuse of "literally" somehow with a pointer to theoatmeal comic, > right) > > -e > > >> >> -r >> Does this mean we can all get back to solving real IPv6 deployment and operations problems? I certainly hope you all can finally see which is the better business choice between: 1. Using up to around 10% of IPv6 space to make our network operations simpler for the next twenty years or more. 2. Continuing to spend time and money on micromanagement of addressing rather than real customer needs. One who cannot properly understand the business decision here perhaps should not be debating network policies. ? ?Strongly worded letter to follow." James R. Cutler james.cutler at consultant.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From shopik at inblock.ru Tue Dec 3 08:21:38 2013 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 03 Dec 2013 12:21:38 +0400 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: <529D9492.8020205@inblock.ru> On 03/12/13 02:54, Owen DeLong wrote: > I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 address space. There is some ISP who afraid their users will be reselling their connectivity to other users around. While I didin't see that in years (probably last time in 2005) but still this exist in poor regions. Other than that, completely agree on /56y default and /48 on request, but most ISPs here are give-out just single /64. From seth.mos at dds.nl Tue Dec 3 08:44:00 2013 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 03 Dec 2013 09:44:00 +0100 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> Message-ID: <529D99D0.5020507@dds.nl> On 2-12-2013 22:25, Ricky Beam wrote: > On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom wrote: > Handing out /56's like Pez is just wasting address space -- someone *is* > paying for that space. Yes, it's waste; giving everyone 256 networks You clearly have no understanding of route aggregation which just made it's entry into the soho. The router will set up it's own DHCP-PD prefix delegation for downstream routers. Without a /56 or larger it is very hard to do automatically. It is not "wasting" it is "required" for proper operation of a routing internet. You can't just NAT a downstream router and still have IPv6. People buy extra wifi routers at their favorite shop and *will* plug the cable into the "Internet" port. With IPv6 and DHCP-PD they will still get working IPv6 internet. Great! Cheers, Seth From rs at seastrom.com Tue Dec 3 11:39:04 2013 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 03 Dec 2013 06:39:04 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <3FFD03CC-CE6A-4486-8921-FC8CD2EA4AD5@consultant.com> (Cutler James R.'s message of "Tue, 3 Dec 2013 00:56:40 -0500") References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <86haaq60bv.fsf@valhalla.seastrom.com> <3FFD03CC-CE6A-4486-8921-FC8CD2EA4AD5@consultant.com> Message-ID: <86li02rwo7.fsf@valhalla.seastrom.com> Cutler James R writes: > Does this mean we can all get back to solving real IPv6 deployment and operations problems? I sure hope so. :) > I certainly hope you all can finally see which is the better business choice between: > > 1. Using up to around 10% of IPv6 space to make our network operations simpler for the next twenty years or more. You're high by more than an order of magnitude. Inasmuch as I don't hail from Chicago, I'm not suggesting actually issuing addresses to people who are dead (Eric's final datapoint). > 2. Continuing to spend time and money on micromanagement of addressing rather than real customer needs. > > One who cannot properly understand the business decision here perhaps should not be debating network policies. > > "Strongly worded letter to follow." Indeed. -r From phillipa at cs.stonybrook.edu Tue Dec 3 14:54:32 2013 From: phillipa at cs.stonybrook.edu (Phillipa Gill) Date: Tue, 3 Dec 2013 09:54:32 -0500 Subject: Routing Policy Survey Results Message-ID: Hi NANOG! We?d like to thank everyone who answered our survey on routing policies and everyone who gave feedback on our presentation of preliminary survey results at NANOG56 (https://www.nanog.org/meetings/abstract?id=1996 ). A more complete exposition of the survey results will be appearing in the January 2014 issue of ACM Computer Communications Review and can be found online at this URL: http://www.cs.stonybrook.edu/~phillipa/papers/CCR2014.pdf Thanks again to everyone who helped out with our efforts. - Phillipa Gill, Sharon Goldberg, Michael Schapira From peering at phlix.net Tue Dec 3 17:41:23 2013 From: peering at phlix.net (Chris Rogers) Date: Tue, 3 Dec 2013 12:41:23 -0500 Subject: Philadelphia Internet Exchange Message-ID: Hello NANOG, We're in the process of starting up an IXP in Philadelphia, and I wanted to see if there were any networks that would be interested in connecting. Currently, we have just over 10 networks that have expressed interest. (Listed on http://phlix.net/) If you would like to be added, please email me off list with your company name, peering ASN, and any preferred colo(s) where you would like to see PHLIX present. Initially, we're expecting to have switches in 401 N Broad and 3701 Market, with a link between the two buildings. If there's enough demand, we'd also look at 2401 Locust and 833 Chestnut. We are looking to run this as "revenue neutral", so to properly price out ports, we need to get a rough idea who's interested in connecting. Thanks! -Chris Rogers The Philadelphia Internet Exchange http://phlix.net/ From owen at delong.com Tue Dec 3 21:41:01 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 3 Dec 2013 13:41:01 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <529D9492.8020205@inblock.ru> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> Message-ID: On Dec 3, 2013, at 00:21 , Nikolay Shopik wrote: > On 03/12/13 02:54, Owen DeLong wrote: >> I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 address space. > > There is some ISP who afraid their users will be reselling their > connectivity to other users around. While I didin't see that in years > (probably last time in 2005) but still this exist in poor regions. I gotta say that, personally, I think worrying about this is kind of silly. First, end-user connections don't have enough bandwidth to make sharing particularly appealing, especially in poor regions. Second, where it does happen, the ISP isn't really losing anything and it's not like they have some entitlement to the user not doing so. Third, addressing really isn't the hurdle that will stop this. > > Other than that, completely agree on /56y default and /48 on request, > but most ISPs here are give-out just single /64. Ugh. Owen From Andy.Litzinger at theplatform.com Tue Dec 3 22:05:41 2013 From: Andy.Litzinger at theplatform.com (Andy Litzinger) Date: Tue, 3 Dec 2013 22:05:41 +0000 Subject: Advice on v4 NAT for farm of file transfer clients Message-ID: <9F4D4FC766780045A8E7ECEA533A1A8D03924A2F@CORPTPMAIL03.corp.theplatform.com> Hi all, We have a pool of around 100 file transfer clients. They reach out to publicly addressed servers on the net to get and put files. Rather than burn 100 public v4 addresses for the clients, we've traditionally had these guys behind a firewall performing source NAT/PAT overloading about 10 IPs. Recently we've been seeing increases in the amount of throughput to/from the servers through the FW. Within the next 12 mos I expect we'll want to support 10Gbps. Since buying a firewall that supports 10Gbps is fairly expensive I thought i'd seek out alternative ideas before we blindly purchase a bigger firewall. Also, a stateful firewall seems like a bit of overkill for what is actually required. I'm confident we can limit our FTP support to passive connections which should remove the requirement of using a device that supports active FTP (i.e. application inspection). currently we're using a Juniper SRX550 to do this (which replaced an overwhelmed ASA 5520). Avg packet size we see according to the SRX is 1000 bytes. thanks! -andy From morrowc.lists at gmail.com Tue Dec 3 22:15:18 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 3 Dec 2013 17:15:18 -0500 Subject: Advice on v4 NAT for farm of file transfer clients In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D03924A2F@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D03924A2F@CORPTPMAIL03.corp.theplatform.com> Message-ID: 1) why not just use public ips? 2) why not (if not 1) have more than 1 outbound path/nat-device? On Tue, Dec 3, 2013 at 5:05 PM, Andy Litzinger wrote: > Hi all, > We have a pool of around 100 file transfer clients. They reach out to publicly addressed servers on the net to get and put files. Rather than burn 100 public v4 addresses for the clients, we've traditionally had these guys behind a firewall performing source NAT/PAT overloading about 10 IPs. > > Recently we've been seeing increases in the amount of throughput to/from the servers through the FW. Within the next 12 mos I expect we'll want to support 10Gbps. Since buying a firewall that supports 10Gbps is fairly expensive I thought i'd seek out alternative ideas before we blindly purchase a bigger firewall. Also, a stateful firewall seems like a bit of overkill for what is actually required. I'm confident we can limit our FTP support to passive connections which should remove the requirement of using a device that supports active FTP (i.e. application inspection). > > currently we're using a Juniper SRX550 to do this (which replaced an overwhelmed ASA 5520). Avg packet size we see according to the SRX is 1000 bytes. > > thanks! > -andy From marka at isc.org Wed Dec 4 00:14:56 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 04 Dec 2013 11:14:56 +1100 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: Your message of "Tue, 03 Dec 2013 12:21:38 +0400." <529D9492.8020205@inblock.ru> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> Message-ID: <20131204001456.9ABEEB13118@rock.dv.isc.org> In message <529D9492.8020205 at inblock.ru>, Nikolay Shopik writes: > On 03/12/13 02:54, Owen DeLong wrote: > > I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 add > ress space. > > There is some ISP who afraid their users will be reselling their > connectivity to other users around. While I didin't see that in years > (probably last time in 2005) but still this exist in poor regions. And if they didn't resell it they probably wouldn't have a customer in the first place. Unless you offer "unlimited" plans the ISP isn't losing anything here. The bandwidth being used is being paid for. If it isn't the ISP needs to adjust the price points to cover their costs rather than hoping that people won't use all of the bandwidth they have purchased. It's two maybe sales vs one confirmed sale. This is like the whole tethered debate. Why should the ISP care about which device the packets are source from. The customer is buying so many gigabytes of traffic a month. They should be able to use them anyway they see fit without actually breaking the laws of the land. I let my daughter's friends use the net at home here. If they burn through my monthly allotment well then I need to pony up more money or take a reduced service level until the month ends. It's none of my ISP's concern how the bandwidth I have purchased from them is being used. Note there really isn't unlimited. There is pipe width * 29-30 days of traffic. If you have purchased a "unlimited" service then you should be able to pull that amount of traffic without the ISP complaining. > Other than that, completely agree on /56y default and /48 on request, > but most ISPs here are give-out just single /64. Which is just plain stupid. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From karn at philkarn.net Wed Dec 4 03:04:52 2013 From: karn at philkarn.net (Phil Karn) Date: Tue, 03 Dec 2013 19:04:52 -0800 Subject: Anyone competent within AT&T Uverse? Message-ID: <529E9BD4.80502@philkarn.net> Does anyone know anyone within AT&T Uverse who actually knows what TCP/IP is? Maybe even how to read a packet trace? I've been trying to get my static IP block working again since Saturday when they broke it while fixing an unrelated problem. I can't believe how incompetent their tech support has been on this. An hour into a chat with them and I finally realize they don't have a clue what I'm talking about...this is very frustrating... Their premise techs try very hard, but I get the strong impression that the network support people randomly perturb provisioning until it works again, and that's why they keep breaking unrelated things. I'm still wondering if this Internet stuff is ready for prime time... Thanks, Phil From elouie at yahoo.com Wed Dec 4 03:21:26 2013 From: elouie at yahoo.com (Eric A Louie) Date: Tue, 3 Dec 2013 19:21:26 -0800 (PST) Subject: Anyone competent within AT&T Uverse? In-Reply-To: <529E9BD4.80502@philkarn.net> References: <529E9BD4.80502@philkarn.net> Message-ID: <1386127286.35646.YahooMailNeo@web181601.mail.ne1.yahoo.com> Ask to be escalated to Tier 2.? If they can't help, ask for another escalation.? Show them traceroutes if you can (maybe from your phone or from one of us) from other networks so they can see where it's dying. >________________________________ > From: Phil Karn >To: NANOG >Sent: Tuesday, December 3, 2013 7:04 PM >Subject: Anyone competent within AT&T Uverse? > > >Does anyone know anyone within AT&T Uverse who actually knows what >TCP/IP is? Maybe even how to read a packet trace? > >I've been trying to get my static IP block working again since Saturday >when they broke it while fixing an unrelated problem. I can't believe >how incompetent their tech support has been on this. An hour into a chat >with them and I finally realize they don't have a clue what I'm talking >about...this is very frustrating... > >Their premise techs try very hard, but I get the strong impression that >the network support people randomly perturb provisioning until it works >again, and that's why they keep breaking unrelated things. > >I'm still wondering if this Internet stuff is ready for prime time... > >Thanks, > >Phil > > > > From gravestl at swbell.net Wed Dec 4 03:38:59 2013 From: gravestl at swbell.net (Thomas) Date: Tue, 3 Dec 2013 21:38:59 -0600 Subject: Anyone competent within AT&T Uverse? In-Reply-To: <1386127286.35646.YahooMailNeo@web181601.mail.ne1.yahoo.com> References: <529E9BD4.80502@philkarn.net> <1386127286.35646.YahooMailNeo@web181601.mail.ne1.yahoo.com> Message-ID: <50F83DC3-5B62-4D45-BC82-67E2E6EBBC08@swbell.net> You need to talk to Alcatel Tac team. They will be able to help you. Prem tech don't have the knowledge or resources. Tier one is useless and can only do basic diagnostics., tier two won't be able to help but they can open an AOTS ticket that can engage Alcatel Tac. Good luck. May need to insist on executive escalation. Just saying. Thomas L Graves Sent from my IPhone > On Dec 3, 2013, at 9:21 PM, Eric A Louie wrote: > > Ask to be escalated to Tier 2. If they can't help, ask for another escalation. Show them traceroutes if you can (maybe from your phone or from one of us) from other networks so they can see where it's dying. > > > > > >> ________________________________ >> From: Phil Karn >> To: NANOG >> Sent: Tuesday, December 3, 2013 7:04 PM >> Subject: Anyone competent within AT&T Uverse? >> >> >> Does anyone know anyone within AT&T Uverse who actually knows what >> TCP/IP is? Maybe even how to read a packet trace? >> >> I've been trying to get my static IP block working again since Saturday >> when they broke it while fixing an unrelated problem. I can't believe >> how incompetent their tech support has been on this. An hour into a chat >> with them and I finally realize they don't have a clue what I'm talking >> about...this is very frustrating... >> >> Their premise techs try very hard, but I get the strong impression that >> the network support people randomly perturb provisioning until it works >> again, and that's why they keep breaking unrelated things. >> >> I'm still wondering if this Internet stuff is ready for prime time... >> >> Thanks, >> >> Phil >> >> >> >> From gdendy at equinix.com Wed Dec 4 05:54:43 2013 From: gdendy at equinix.com (Greg Dendy) Date: Tue, 3 Dec 2013 21:54:43 -0800 Subject: NANOG 60 - Atlanta - Call For Presentations is open! In-Reply-To: <18336F94-2430-4F60-B060-51C81719DF5A@equinix.com> References: <18336F94-2430-4F60-B060-51C81719DF5A@equinix.com> Message-ID: Reminder the submission period for NANOG 60 is still open, although the deadline is approaching fast! Thanks, Greg On Oct 30, 2013, at 2:12 PM, Greg Dendy wrote: NANOG Community, I hope everyone enjoyed NANOG 59 in Phoenix, NANOG?s largest attended meeting. Fresh off a great meeting, and our NANOG annual elections, we are already starting to get ready for NANOG 60 in Atlanta. If you have a topic you'd like to speak about, the program committee would love to consider it. Please read http://www.nanog.org/meetings/nanog60/callforpresentations for more information. We will continue with the Monday-Wednesday format, with Tracks on Monday afternoon and Tutorials to be scheduled on Tuesday morning. The program will begin on Monday morning at 10:00AM followed by our popular Newcomers Lunch. The exact schedule layout can be found at http://www.nanog.org/meetings/nanog60/preagenda, please take this into account as you plan travel. If you wish to submit a presentation, please keep these important dates in mind: * Presentation Abstracts and Draft Slides Due: December 9, 2013 * Final Slides Due: January 6, 2014 * Topic List Posted: December 20, 2013 * Agenda Published: January 13, 2014 Please submit your materials to http://pc.nanog.org. Looking forward to seeing everyone in Atlanta! Thanks, Greg Dendy Chair, NANOG Program Committee From mureninc at gmail.com Wed Dec 4 08:34:07 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 4 Dec 2013 00:34:07 -0800 Subject: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond In-Reply-To: <20131201091154.GA4999@Cns.Cns.SU> References: <5299941F.7050507@gmail.com> <20131201091154.GA4999@Cns.Cns.SU> Message-ID: <20131204083407.GA16570@Cns.Cns.SU> For anyone's following the story: the weeks-long congestion on he.net remains, however, hetzner has switched my original route to an alternative uplink. I'm no longer experiencing the he.net evening jitter that would bring my avg rtt from the non-congested 114ms to an average of 140ms and more during the busy times. Other sites that have an uplink from he.net are still affected, with a noticeable jitter, delay and some packet loss (which seems to increase with the increase in the avg rtt). Was: Tue Dec 3 22:25:38 PST 2013 Wed Dec 4 07:25:38 CET 2013 HOST: Cns??????? Snt Rcv Loss% Best Gmean Avg Wrst StDev 1.|-- static.??.???.4.46.clients.your-server.de 900 900 0.0% 0.5 0.9 1.3 7.3 1.2 2.|-- hos-tr1.juniper1.rz13.hetzner.de 900 900 0.0% 0.2 0.2 2.1 101.2 9.0 3.|-- core21.hetzner.de 900 900 0.0% 0.2 0.2 0.2 19.7 1.1 4.|-- core22.hetzner.de 900 897 0.3% 0.2 0.2 0.2 19.6 1.1 5.|-- core1.hetzner.de 900 900 0.0% 4.8 4.8 4.8 16.4 1.1 6.|-- juniper1.ffm.hetzner.de 900 893 0.8% 4.8 4.8 4.8 19.1 0.7 7.|-- 30gigabitethernet1-3.core1.ams1.he.net 900 900 0.0% 11.2 14.0 14.8 123.4 6.5 8.|-- 10ge1-4.core1.lon1.he.net 900 900 0.0% 18.2 19.9 20.2 59.7 3.9 9.|-- 10ge10-4.core1.nyc4.he.net 900 896 0.4% 86.9 113.6 114.2 148.4 11.4 10.|-- 100ge7-2.core1.chi1.he.net 900 898 0.2% 106.6 133.0 133.6 184.6 12.4 11.|-- ??? 900 0 100.0 0.0 0.0 0.0 0.0 0.0 12.|-- et-11-0-0.945.rtr.ictc.indiana.gigapop.net 900 899 0.1% 113.3 136.7 137.1 162.3 10.8 13.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu 900 895 0.6% 113.3 137.2 137.7 183.3 11.1 14.|-- ae-0.0.br2.bldc.net.uits.iu.edu 900 900 0.0% 114.3 137.8 138.2 162.8 10.7 15.|-- ae-10.0.cr3.bldc.net.uits.iu.edu 900 899 0.1% 114.4 137.9 138.4 167.5 10.7 16.|-- m???c????????.indiana.edu 900 898 0.2% 114.5 138.1 138.5 159.0 10.4 Tue Dec 3 22:43:16 PST 2013 Wed Dec 4 07:43:16 CET 2013 0 154.8 155 = 94 + 61 1 127.9 128 = 67 + 61 2 125.0 125 = 64 + 61 3 131.5 132 = 71 + 61 4 131.2 132 = 71 + 61 5 117.4 118 = 57 + 61 6 132.9 133 = 72 + 61 7 143.4 144 = 83 + 61 8 138.7 139 = 78 + 61 9 131.5 131 = 70 + 61 10 142.2 142 = 81 + 61 11 152.2 152 = 91 + 61 12 125.2 125 = 64 + 61 13 125.6 125 = 64 + 61 14 140.8 141 = 80 + 61 15 150.9 151 = 89 + 62 Tue Dec 3 22:43:31 PST 2013 Wed Dec 4 07:43:31 CET 2013 Now: Tue Dec 3 23:01:20 PST 2013 Wed Dec 4 08:01:20 CET 2013 HOST: Cns??????? Snt Rcv Loss% Best Gmean Avg Wrst StDev 1.|-- static.??.???.4.46.clients.your-server.de 900 900 0.0% 0.5 0.9 1.3 7.0 1.1 2.|-- hos-tr1.juniper1.rz13.hetzner.de 900 900 0.0% 0.1 0.2 4.3 245.4 18.9 3.|-- core21.hetzner.de 900 900 0.0% 0.2 0.2 0.3 99.4 3.5 4.|-- core12.hetzner.de 900 900 0.0% 2.7 2.8 2.8 23.1 1.9 5.|-- juniper4.rz2.hetzner.de 900 899 0.1% 2.8 2.8 2.8 29.0 1.1 6.|-- te0-0-2-1.nr21.b040138-0.nue01.atlas.cogentco.com 900 900 0.0% 3.1 3.3 3.4 7.1 0.6 7.|-- te2-4.ccr01.nue01.atlas.cogentco.com 900 900 0.0% 3.1 6.6 25.9 244.4 51.0 | `|-- 154.25.0.13 8.|-- te0-2-0-3.ccr22.muc01.atlas.cogentco.com 900 900 0.0% 5.7 5.8 5.9 11.1 0.5 9.|-- be2229.ccr22.fra03.atlas.cogentco.com 900 900 0.0% 11.1 11.4 11.4 14.4 0.5 | `|-- 154.54.38.189 10.|-- te0-3-0-2.mpd22.ams03.atlas.cogentco.com 900 900 0.0% 17.7 17.9 17.9 49.1 1.1 | `|-- 154.54.39.193 11.|-- be2276.ccr22.lon13.atlas.cogentco.com 900 900 0.0% 25.3 27.4 27.4 33.2 1.3 | `|-- 154.54.37.106 | |-- 154.54.58.69 12.|-- te0-7-0-33.ccr22.bos01.atlas.cogentco.com 900 900 0.0% 93.1 93.9 93.9 98.8 1.2 | `|-- 154.54.44.189 | |-- 130.117.0.185 13.|-- te7-8.ccr02.alb02.atlas.cogentco.com 900 900 0.0% 96.8 119.9 128.8 364.2 56.9 | `|-- 154.54.27.153 14.|-- te7-8.ccr01.buf02.atlas.cogentco.com 900 900 0.0% 103.3 126.8 135.8 444.9 59.0 15.|-- te0-5-0-2.ccr21.cle04.atlas.cogentco.com 900 900 0.0% 108.6 109.5 109.5 113.5 1.3 16.|-- te3-2.ccr01.cmh02.atlas.cogentco.com 900 900 0.0% 111.1 134.8 143.5 467.0 59.4 17.|-- te4-7.ccr01.cvg02.atlas.cogentco.com 900 900 0.0% 113.8 122.5 126.2 467.9 39.6 18.|-- te3-3.ccr01.ind01.atlas.cogentco.com 900 899 0.1% 116.1 137.8 145.4 457.7 56.0 19.|-- 38.104.214.6 900 900 0.0% 115.8 118.3 118.5 206.0 8.1 20.|-- xe-0-1-0.11.rtr.ictc.indiana.gigapop.net 900 900 0.0% 115.9 116.7 116.7 128.4 1.5 21.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu 900 900 0.0% 115.9 117.0 117.1 168.6 3.6 22.|-- ae-0.0.br2.bldc.net.uits.iu.edu 900 900 0.0% 116.8 117.7 117.7 130.8 1.8 23.|-- ae-10.0.cr3.bldc.net.uits.iu.edu 900 899 0.1% 116.8 117.8 117.8 135.1 1.9 24.|-- m???c????????.indiana.edu 900 899 0.1% 117.1 117.9 117.9 122.0 1.2 Tue Dec 3 23:19:56 PST 2013 Wed Dec 4 08:19:56 CET 2013 0 120.1 120 = 57 + 63 1 117.3 117 = 54 + 63 2 120.3 120 = 57 + 63 3 117.3 117 = 54 + 63 4 117.4 118 = 54 + 64 5 117.3 118 = 54 + 64 6 120.0 120 = 57 + 63 7 117.3 118 = 54 + 64 8 117.3 118 = 54 + 64 9 117.6 118 = 54 + 64 10 117.3 118 = 54 + 64 11 117.4 118 = 54 + 64 12 117.4 117 = 53 + 64 13 118.6 118 = 55 + 63 14 117.5 117 = 53 + 64 15 117.3 117 = 53 + 64 Tue Dec 3 23:20:11 PST 2013 Wed Dec 4 08:20:11 CET 2013 Yet: Cns# sh -c 'while (true); do date; env TZ=Europe/Berlin date; mtr --report{,-wide,-cycles=900} --interval 1 --order "SRL BGAWV" -4 ntp1.yycix.ca; date; env TZ=Europe/Berlin date; unbuffer hping --icmp-ts --count 16 ntp1.yycix.ca | perl -ne "if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {(\$s,\$p)=(\$1,\$2);} if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {(\$o,\$r,\$t)=(\$1,\$2,\$3);} if (/tsrtt=(\d+)/) {print \$s,qq/\t/,\$p,qq/\t/,\$1,qq/ = /,\$r-\$o,qq/ + /,\$o+\$1-\$t,qq/\n/;}"; done' Tue Dec 3 23:32:37 PST 2013 Wed Dec 4 08:32:37 CET 2013 HOST: Cns??????? Snt Rcv Loss% Best Gmean Avg Wrst StDev 1.|-- static.??.???.4.46.clients.your-server.de 900 900 0.0% 0.5 0.9 1.2 9.7 1.2 2.|-- hos-tr4.juniper2.rz13.hetzner.de 900 900 0.0% 0.2 0.2 2.0 138.3 8.9 3.|-- core22.hetzner.de 900 900 0.0% 0.2 0.2 0.2 8.5 0.4 4.|-- core1.hetzner.de 900 900 0.0% 4.8 4.8 4.8 16.0 0.7 5.|-- juniper1.ffm.hetzner.de 900 900 0.0% 4.8 4.8 4.8 13.8 0.7 6.|-- 30gigabitethernet1-3.core1.ams1.he.net 900 900 0.0% 11.2 14.2 14.9 106.2 6.2 7.|-- 10ge1-4.core1.lon1.he.net 900 900 0.0% 18.0 20.5 20.8 55.6 4.1 8.|-- 10ge10-4.core1.nyc4.he.net 900 895 0.6% 86.4 119.3 120.0 158.6 13.1 9.|-- 10ge1-2.core1.tor1.he.net 900 896 0.4% 96.4 128.4 129.1 159.6 12.9 10.|-- 10ge3-1.core1.ywg1.he.net 900 895 0.6% 121.8 152.2 152.7 181.5 12.6 11.|-- 10ge1-1.core1.yyc1.he.net 900 888 1.3% 135.7 168.0 168.5 197.4 13.0 12.|-- sebo-systems-inc.gigabitethernet2-23.core1.yyc1.he.net 900 890 1.1% 138.4 168.2 168.6 190.9 12.5 13.|-- ??? 900 0 100.0 0.0 0.0 0.0 0.0 0.0 14.|-- ntp1.yycix.ca 900 893 0.8% 138.7 168.8 169.2 191.9 12.2 Tue Dec 3 23:49:07 PST 2013 Wed Dec 4 08:49:07 CET 2013 0 180.0 180 = 109 + 71 1 155.9 156 = 84 + 72 2 143.6 144 = 72 + 72 3 179.8 180 = 108 + 72 4 161.0 161 = 89 + 72 5 155.9 156 = 84 + 72 6 168.0 168 = 97 + 71 7 164.5 165 = 93 + 72 8 177.9 178 = 107 + 71 9 159.6 160 = 88 + 72 10 179.1 180 = 108 + 72 11 178.6 178 = 106 + 72 12 149.8 149 = 78 + 71 13 166.2 166 = 94 + 72 14 146.8 147 = 75 + 72 15 153.7 154 = 82 + 72 Tue Dec 3 23:49:22 PST 2013 Wed Dec 4 08:49:22 CET 2013 Cheers, Constantine. On 2013-W48-7 01:11 -0800, Constantine A. Murenin wrote: > Anyhow, is this better? > > I now saw a 2% traffic loss this night at a random test time, and > the 151ms avg rtt on this 114ms rtt route. > > > Cns# date ; mtr --report{,-wide,-cycles=600} --interval 0.5 --order "SRL BGAWV" -4 ????c????????.indiana.edu ; date > Sat Nov 30 23:17:13 PST 2013 > HOST: Cns??????? Snt Rcv Loss% Best Gmean Avg Wrst StDev > 1.|-- static.??.???.4.46.clients.your-server.de 600 600 0.0% 0.5 1.0 1.3 4.6 1.1 > 2.|-- hos-tr1.juniper1.rz13.hetzner.de 600 600 0.0% 0.1 0.2 2.0 58.5 7.9 > 3.|-- core21.hetzner.de 600 600 0.0% 0.2 0.2 0.2 10.2 0.7 > 4.|-- core22.hetzner.de 600 600 0.0% 0.2 0.2 0.2 11.2 0.8 > 5.|-- core1.hetzner.de 600 600 0.0% 4.8 4.8 4.8 25.1 1.3 > 6.|-- juniper1.ffm.hetzner.de 600 600 0.0% 4.8 4.8 4.8 13.9 0.6 > 7.|-- 30gigabitethernet1-3.core1.ams1.he.net 600 595 0.8% 11.2 14.3 15.2 121.4 7.4 > 8.|-- 10gigabitethernet1-4.core1.lon1.he.net 600 600 0.0% 18.2 21.0 21.3 51.2 4.0 > 9.|-- 10gigabitethernet10-4.core1.nyc4.he.net 600 592 1.3% 86.9 125.9 126.4 160.7 10.6 > 10.|-- 100gigabitethernet7-2.core1.chi1.he.net 600 591 1.5% 106.6 145.1 145.4 190.9 10.5 > 11.|-- ??? 600 0 100.0 0.0 0.0 0.0 0.0 0.0 > 12.|-- et-11-0-0.945.rtr.ictc.indiana.gigapop.net 600 589 1.8% 114.3 148.9 149.2 167.9 9.1 > 13.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu 600 589 1.8% 113.4 149.2 149.5 173.4 9.3 > 14.|-- ae-0.0.br2.bldc.net.uits.iu.edu 600 590 1.7% 114.5 150.2 150.5 175.6 9.3 > 15.|-- ae-10.0.cr3.bldc.net.uits.iu.edu 600 589 1.8% 114.3 150.5 150.8 181.0 9.1 > 16.|-- ????c????????.indiana.edu 600 589 1.8% 114.8 150.7 151.0 170.7 9.0 > Sat Nov 30 23:24:06 PST 2013 > > > > The ICMP timestamp request/reply test still indicates that only > one path is affected: the one from Europe to US over he.net. > > > Cns# date ; unbuffer hping --icmp-ts --count 30 ????c????????.indiana.edu | \ > perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \ > if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, $3);} \ > if (/tsrtt=(\d+)/) { \ > print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\n"; }' > Sun Dec 1 00:55:46 PST 2013 > 0 151.3 151 = 91 + 60 > 1 154.2 154 = 93 + 61 > 2 127.8 127 = 67 + 60 > 3 123.6 123 = 63 + 60 > 4 136.9 137 = 76 + 61 > 5 149.6 149 = 89 + 60 > 6 147.4 147 = 87 + 60 > 7 133.5 133 = 73 + 60 > 8 152.2 152 = 92 + 60 > 9 137.3 137 = 77 + 60 > 10 143.7 144 = 84 + 60 > 11 124.5 124 = 64 + 60 > 12 141.4 141 = 81 + 60 > 13 118.0 118 = 58 + 60 > 14 153.6 154 = 94 + 60 > 15 137.7 138 = 78 + 60 > 16 119.9 120 = 60 + 60 > 17 130.6 131 = 71 + 60 > 18 144.6 145 = 85 + 60 > 19 138.8 139 = 79 + 60 > 20 155.7 156 = 96 + 60 > 21 128.8 129 = 69 + 60 > 22 153.0 153 = 93 + 60 > 23 146.5 147 = 87 + 60 > 24 137.2 138 = 77 + 61 > 25 153.3 154 = 94 + 60 > 26 146.3 147 = 87 + 60 > 27 150.1 151 = 91 + 60 > 28 150.5 150 = 90 + 60 > 29 143.5 143 = 83 + 60 > > > > Cheers, > Constantine. From h.wahl at ifw-dresden.de Wed Dec 4 13:37:03 2013 From: h.wahl at ifw-dresden.de (Henri Wahl) Date: Wed, 04 Dec 2013 14:37:03 +0100 Subject: blogs.cisco.com not available via IPv6 Message-ID: <529F2FFF.8070504@ifw-dresden.de> Hi, can anybody from Cisco confirm that blogs.cisco.com (2001:4800:13c1:10::178) is not available via IPv6? Regards -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: (03 51) 46 59 - 797 email: h.wahl at ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor Nagstamon: http://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x1FBA0942.asc Type: application/pgp-keys Size: 1780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Wed Dec 4 14:22:35 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 4 Dec 2013 09:22:35 -0500 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: <529F2FFF.8070504@ifw-dresden.de> References: <529F2FFF.8070504@ifw-dresden.de> Message-ID: I'm seeing it down via IPv6: * Trying 2600:1407:9:295::90... * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.30.0 > Host: www.cisco.com > Accept: */* > < HTTP/1.1 200 OK * Server Apache is not blacklisted * About to connect() to blogs.cisco.com port 80 (#0) * Trying 2001:4800:13c1:10::178... ^C - Jared On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: > Hi, > can anybody from Cisco confirm that blogs.cisco.com > (2001:4800:13c1:10::178) is not available via IPv6? > Regards > > -- > Henri Wahl > > IT Department > Leibniz-Institut fuer Festkoerper- u. > Werkstoffforschung Dresden > > tel: (03 51) 46 59 - 797 > email: h.wahl at ifw-dresden.de > http://www.ifw-dresden.de > > Nagios status monitor Nagstamon: > http://nagstamon.ifw-dresden.de > > DHCPv6 server dhcpy6d: > http://dhcpy6d.ifw-dresden.de > > IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden > VR Dresden Nr. 1369 > Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle > <0x1FBA0942.asc> From herro91 at gmail.com Wed Dec 4 15:53:12 2013 From: herro91 at gmail.com (Herro91) Date: Wed, 4 Dec 2013 10:53:12 -0500 Subject: Cisco ScanSafe, aka Cisco Cloud Web Security Message-ID: Hi, I'm doing some research on the Cisco Cloud Web Security offering, also known as ScanSafe. Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now called Cisco Cloud Web Security - as a means of providing protection in the cloud that would potentially negate the requirement to have a full tunnel (i.e. allow split tunneling) for teleworkers? Thanks! From Valdis.Kletnieks at vt.edu Wed Dec 4 16:30:26 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 04 Dec 2013 11:30:26 -0500 Subject: bgp traceroute tool? In-Reply-To: Your message of "Sun, 01 Dec 2013 01:19:14 +0100." <529A8082.8040908@ripe.net> References: <529A8082.8040908@ripe.net> Message-ID: <10153.1386174626@turing-police.cc.vt.edu> On Sun, 01 Dec 2013 01:19:14 +0100, Rene Wilhelm said: (Getting caught up after a few weeks elsewhere) > Reporting in the same format as the IRR, riswhois is plugin > compatible with whois.radb.net. If your linux traceroutederives > from http://traceroute.sourceforge.net/ all it takes to switch to > using true BGP info in traceroute is setting the environment variable > RA_SERVER to "riswhois.ripe.net" Is there likely to be a scaling issue if everybody on NANOG does that? Or what if a large(ish) Linux distro does that by default? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From eugen at imacandi.net Wed Dec 4 17:18:06 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 4 Dec 2013 19:18:06 +0200 Subject: Cisco ScanSafe, aka Cisco Cloud Web Security In-Reply-To: References: Message-ID: On Wed, Dec 4, 2013 at 5:53 PM, Herro91 wrote: > Hi, > > I'm doing some research on the Cisco Cloud Web Security offering, also > known as ScanSafe. > > Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now called > Cisco Cloud Web Security - as a means of providing protection in the cloud > that would potentially negate the requirement to have a full tunnel (i.e. > allow split tunneling) for teleworkers? > First of all, why are you allowing or disallowing split tunnel networks ? The only case I see when you want to route all traffic through the gateway is when you have a big network that changes constantly and you don't want to update ACLs all day to make sure a teleworker can reach certain equipment no matter what. Other than that, when the laptop is not connected to the VPN and the user can browse whatever site on the internet and from a security standpoint there is no benefit. There is always the risk that he/she may get infected with some malware that your antivirus does not recognize and it spreads through the internet network when the user VPNs to the corporate network. Even with a malware cloud service, you still have security gaps and opportunity windows for attackers to get to you. One thing is that it not always feasible to have a proxy set up in your browser all the time as for example it would be impossible to connect to the internet when you are at a hotel that has a captive portal. And in order to get access you will have to disable the proxy, log into the captive portal, pay (optionally), accept the terms and reactive the proxy settings in the browser. And fi you forget to do this... well, you're on your own and hope for the best and that the locally installed AV and anti-malware solution is "good enough". What I would suggest is that you only allow access to some jump hosts (linux/windows/etc) that are being protected by adequate security measures such an IPS. This also assumes that the same level of protection exists between your user network and server network, otherwise it's pretty much game over once the user is back in the office with full network access. Regards, Eugeniu From john.kreno at gmail.com Wed Dec 4 17:57:48 2013 From: john.kreno at gmail.com (John Kreno) Date: Wed, 4 Dec 2013 12:57:48 -0500 Subject: Anyone competent within AT&T Uverse? In-Reply-To: <50F83DC3-5B62-4D45-BC82-67E2E6EBBC08@swbell.net> References: <529E9BD4.80502@philkarn.net> <1386127286.35646.YahooMailNeo@web181601.mail.ne1.yahoo.com> <50F83DC3-5B62-4D45-BC82-67E2E6EBBC08@swbell.net> Message-ID: One wonders if this is an industry trend. On Tue, Dec 3, 2013 at 10:38 PM, Thomas wrote: > You need to talk to Alcatel Tac team. They will be able to help you. > Prem tech don't have the knowledge or resources. Tier one is useless and > can only do basic diagnostics., tier two won't be able to help but they can > open an AOTS ticket that can engage Alcatel Tac. Good luck. May need to > insist on executive escalation. Just saying. > > Thomas L Graves > Sent from my IPhone > > > > On Dec 3, 2013, at 9:21 PM, Eric A Louie wrote: > > > > Ask to be escalated to Tier 2. If they can't help, ask for another > escalation. Show them traceroutes if you can (maybe from your phone or > from one of us) from other networks so they can see where it's dying. > > > > > > > > > > > >> ________________________________ > >> From: Phil Karn > >> To: NANOG > >> Sent: Tuesday, December 3, 2013 7:04 PM > >> Subject: Anyone competent within AT&T Uverse? > >> > >> > >> Does anyone know anyone within AT&T Uverse who actually knows what > >> TCP/IP is? Maybe even how to read a packet trace? > >> > >> I've been trying to get my static IP block working again since Saturday > >> when they broke it while fixing an unrelated problem. I can't believe > >> how incompetent their tech support has been on this. An hour into a chat > >> with them and I finally realize they don't have a clue what I'm talking > >> about...this is very frustrating... > >> > >> Their premise techs try very hard, but I get the strong impression that > >> the network support people randomly perturb provisioning until it works > >> again, and that's why they keep breaking unrelated things. > >> > >> I'm still wondering if this Internet stuff is ready for prime time... > >> > >> Thanks, > >> > >> Phil > >> > >> > >> > >> > > -- John Kreno "Those who would sacrifice essential liberties for a little temporary safety deserve neither liberty nor safety." - Ben Franklin From eugen at imacandi.net Wed Dec 4 18:10:49 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 4 Dec 2013 20:10:49 +0200 Subject: Anyone competent within AT&T Uverse? In-Reply-To: References: <529E9BD4.80502@philkarn.net> <1386127286.35646.YahooMailNeo@web181601.mail.ne1.yahoo.com> <50F83DC3-5B62-4D45-BC82-67E2E6EBBC08@swbell.net> Message-ID: On Wed, Dec 4, 2013 at 7:57 PM, John Kreno wrote: > One wonders if this is an industry trend. > > Outsourcing the outsourcers to other outsourcers... and at the end of the day everyone is congratulating everyone that the SLAs have been met :)) From brian.peter.dickson at gmail.com Wed Dec 4 18:21:32 2013 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Wed, 4 Dec 2013 13:21:32 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) Message-ID: Rob Seastrom wrote: > "Ricky Beam" > > writes: > > > * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > wrote: *>> > * So there really is no excuse on AT&T's part for the /60s on uverse > 6rd... *> > * ... *> > * Handing out /56's like Pez is just wasting address space -- someone *> > * *is* paying for that space. Yes, it's waste; giving everyone 256 *> > * networks when they're only ever likely to use one or two (or maybe *> > * four), is intentionally wasting space you could've assigned to *> > * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> > * the power of huge, but it's still finite. People like you are *> > * repeating the same mistakes from the early days of IPv4... * There's > finite, and then there's finite. Please complete the > following math assignment so as to calibrate your perceptions before > leveling further allegations of profligate waste. > Suppose that every mobile phone on the face of the planet was an "end > site" in the classic sense and got a /48 (because miraculously, > the mobile providers aren't being stingy). > Now give such a phone to every human on the face of the earth. > Unfortunately for our conservation efforts, every person with a > cell phone is actually the cousin of either Avi Freedman or Vijay > Gill, and consequently actually has FIVE cell phones on active > plans at any given time. > Assume 2:1 overprovisioning of address space because per Cameron > Byrne's comments on ARIN 2013-2, the cellular equipment providers > can't seem to figure out how to have N+1 or N+2 redundancy rather > than 2N redundancy on Home Agent hardware. > What percentage of the total available IPv6 space have we burned > through in this scenario? Show your work. > -r Here's the problem with the math, presuming everyone gets roughly the same answer: The efficiency (number of prefixes vs total space) is only achieved if there is a "flat" network, which carries every IPv6 prefix (i.e. that there is no aggregation being done). This means 1:1 router slots (for routes) vs prefixes, globally, or even internally on ISP networks. If any ISP has > 1M customers, oops. So, we need to aggregate. Basically, the problem space (waste) boils down to the question, "How many levels of aggregation are needed"? If you have variable POP sizes, region sizes, and assign/aggregate towards customers topologically, the result is: - the need to maintain power-of-2 address block sizes (for aggregation), plus - the need to aggregate at each level (to keep #prefixes sane) plus - asymmetric sizes which don't often end up being just short of the next power-of-2 - equals (necessarily) low utilization rates - i.e. much larger prefixes than would be suggested by "flat" allocation from a single pool. Here's a worked example, for a hypothetical big consumer ISP: - 22 POPs with "core" devices - each POP has anywhere from 2 to 20 "border" devices (feeding access devices) - each "border" has 5 to 100 "access" devices - each access device has up to 5000 customers Rounding up each, using max(count-per-level) as the basis, we get: 5000->8192 (2^13) 100->128 (2^7) 20->32 (2^5) 22->32 (2^5) 5+5+7+13=30 bits of aggregation 2^30 of /48 = /18 This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. A thousand ISPs seems like a lot, but consider this: the ISP we did this for, might only have 3M customers. Scale this up (horizontally or vertically or both), and it is dangerously close to capacity already. The answer above (worked math) will be unique per ISP. It will also drive consumption at the apex, i.e. the size of allocations to ISPs. And root of the problem was brought into existence by the insistence that every network (LAN) must be a /64. That's my 2 cents/observation. Brian From rs at seastrom.com Wed Dec 4 18:32:33 2013 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 04 Dec 2013 13:32:33 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: (Brian Dickson's message of "Wed, 4 Dec 2013 13:21:32 -0500") References: Message-ID: <86mwkgxy9q.fsf@valhalla.seastrom.com> Brian Dickson writes: > Rob Seastrom wrote: > >> "Ricky Beam" > >> writes: >> > >> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > > wrote: *>> >> * So there really is no excuse on AT&T's part for the /60s on uverse >> 6rd... *> >> * ... *> >> * Handing out /56's like Pez is just wasting address space -- someone *> >> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> >> * networks when they're only ever likely to use one or two (or maybe *> >> * four), is intentionally wasting space you could've assigned to *> >> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> >> * the power of huge, but it's still finite. People like you are *> >> * repeating the same mistakes from the early days of IPv4... * There's >> finite, and then there's finite. Please complete the >> following math assignment so as to calibrate your perceptions before >> leveling further allegations of profligate waste. >> Suppose that every mobile phone on the face of the planet was an "end >> site" in the classic sense and got a /48 (because miraculously, >> the mobile providers aren't being stingy). >> Now give such a phone to every human on the face of the earth. >> Unfortunately for our conservation efforts, every person with a >> cell phone is actually the cousin of either Avi Freedman or Vijay >> Gill, and consequently actually has FIVE cell phones on active >> plans at any given time. >> Assume 2:1 overprovisioning of address space because per Cameron >> Byrne's comments on ARIN 2013-2, the cellular equipment providers >> can't seem to figure out how to have N+1 or N+2 redundancy rather >> than 2N redundancy on Home Agent hardware. >> What percentage of the total available IPv6 space have we burned >> through in this scenario? Show your work. >> -r > > > Here's the problem with the math, presuming everyone gets roughly the same > answer: > The efficiency (number of prefixes vs total space) is only achieved if > there is a "flat" network, > which carries every IPv6 prefix (i.e. that there is no aggregation being > done). > > This means 1:1 router slots (for routes) vs prefixes, globally, or even > internally on ISP networks. > > If any ISP has > 1M customers, oops. So, we need to aggregate. > > Basically, the problem space (waste) boils down to the question, "How many > levels of aggregation are needed"? > > If you have variable POP sizes, region sizes, and assign/aggregate towards > customers topologically, the result is: > - the need to maintain power-of-2 address block sizes (for aggregation), > plus > - the need to aggregate at each level (to keep #prefixes sane) plus > - asymmetric sizes which don't often end up being just short of the next > power-of-2 > - equals (necessarily) low utilization rates > - i.e. much larger prefixes than would be suggested by "flat" allocation > from a single pool. > > Here's a worked example, for a hypothetical big consumer ISP: > - 22 POPs with "core" devices > - each POP has anywhere from 2 to 20 "border" devices (feeding access > devices) > - each "border" has 5 to 100 "access" devices > - each access device has up to 5000 customers > > Rounding up each, using max(count-per-level) as the basis, we get: > 5000->8192 (2^13) > 100->128 (2^7) > 20->32 (2^5) > 22->32 (2^5) > 5+5+7+13=30 bits of aggregation > 2^30 of /48 = /18 > This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. > A thousand ISPs seems like a lot, but consider this: the ISP we did this > for, might only have 3M customers. > Scale this up (horizontally or vertically or both), and it is dangerously > close to capacity already. > > The answer above (worked math) will be unique per ISP. It will also drive > consumption at the apex, i.e. the size of allocations to ISPs. > > And root of the problem was brought into existence by the insistence that > every network (LAN) must be a /64. > > That's my 2 cents/observation. > > Brian At a glance, I think there's an implicit assumption in your calculation that each ISP has to be able to hold the whole world (unlikely) and/or there is no such thing as mobile IP or any other kind of tunneling technology going on within the mobile network (also wrong from everything I understand). Also, I'm not sure where "from the current /8" comes from, as there's a /3 in play (1/8 of the total space, maybe that was it?) and each RIR is getting space in chunks of /12... Re-working your conclusion statement without redoing the math, "This leaves room for 2^15 such ISPs (a mere 16384), from the current /3." Oddly enough, I'm OK with that. :) -r From shopik at inblock.ru Wed Dec 4 18:32:55 2013 From: shopik at inblock.ru (Nikolay Shopik) Date: Wed, 04 Dec 2013 22:32:55 +0400 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <20131204001456.9ABEEB13118@rock.dv.isc.org> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> Message-ID: <529F7557.3020607@inblock.ru> On 04.12.2013 4:14, Mark Andrews wrote: > In message <529D9492.8020205 at inblock.ru>, Nikolay Shopik writes: >> On 03/12/13 02:54, Owen DeLong wrote: >>> I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 add >> ress space. >> >> There is some ISP who afraid their users will be reselling their >> connectivity to other users around. While I didin't see that in years >> (probably last time in 2005) but still this exist in poor regions. > > And if they didn't resell it they probably wouldn't have a customer > in the first place. Unless you offer "unlimited" plans the ISP > isn't losing anything here. The bandwidth being used is being paid > for. If it isn't the ISP needs to adjust the price points to cover > their costs rather than hoping that people won't use all of the > bandwidth they have purchased. If we talk about end-user not business user, ISP assume 95th% load will be minimal so therefore it allow them to sell 100mbit for like 20-30$, while real price of it much higher. If its big ISP they usually don't care, as there always be downloaders who saturate their link to 90% most time, but compare to most of other users in their net, this will be not noticeable. If its just smallish ISP things get harder for it. > > This is like the whole tethered debate. Why should the ISP care > about which device the packets are source from. The customer is > buying so many gigabytes of traffic a month. They should be able > to use them anyway they see fit without actually breaking the laws > of the land. If you actually pay per bit, true or have some kind "fair usage" unlimited plan. > > I let my daughter's friends use the net at home here. If they burn > through my monthly allotment well then I need to pony up more money > or take a reduced service level until the month ends. It's none > of my ISP's concern how the bandwidth I have purchased from them > is being used. If you talk about wired connection, this thing almost non-existing here. Only apply to wireless 3G/4G ISPs with limited bits and then reduced service. > > Note there really isn't unlimited. There is pipe width * 29-30 > days of traffic. If you have purchased a "unlimited" service then > you should be able to pull that amount of traffic without the ISP > complaining. > >> Other than that, completely agree on /56y default and /48 on request, >> but most ISPs here are give-out just single /64. > > Which is just plain stupid. > > Some even come up with idea two separate /64 make things easier :-D, instead just put at least round /60 From morrowc.lists at gmail.com Wed Dec 4 18:35:26 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Dec 2013 13:35:26 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <86mwkgxy9q.fsf@valhalla.seastrom.com> References: <86mwkgxy9q.fsf@valhalla.seastrom.com> Message-ID: On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom wrote: > > Brian Dickson writes: > >> Rob Seastrom wrote: >> >>> "Ricky Beam" > >>> writes: >>> > >>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom >> > wrote: *>> >>> * So there really is no excuse on AT&T's part for the /60s on uverse >>> 6rd... *> >>> * ... *> >>> * Handing out /56's like Pez is just wasting address space -- someone *> >>> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> >>> * networks when they're only ever likely to use one or two (or maybe *> >>> * four), is intentionally wasting space you could've assigned to *> >>> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> >>> * the power of huge, but it's still finite. People like you are *> >>> * repeating the same mistakes from the early days of IPv4... * There's >>> finite, and then there's finite. Please complete the >>> following math assignment so as to calibrate your perceptions before >>> leveling further allegations of profligate waste. >>> Suppose that every mobile phone on the face of the planet was an "end >>> site" in the classic sense and got a /48 (because miraculously, >>> the mobile providers aren't being stingy). >>> Now give such a phone to every human on the face of the earth. >>> Unfortunately for our conservation efforts, every person with a >>> cell phone is actually the cousin of either Avi Freedman or Vijay >>> Gill, and consequently actually has FIVE cell phones on active >>> plans at any given time. >>> Assume 2:1 overprovisioning of address space because per Cameron >>> Byrne's comments on ARIN 2013-2, the cellular equipment providers >>> can't seem to figure out how to have N+1 or N+2 redundancy rather >>> than 2N redundancy on Home Agent hardware. >>> What percentage of the total available IPv6 space have we burned >>> through in this scenario? Show your work. >>> -r >> >> >> Here's the problem with the math, presuming everyone gets roughly the same >> answer: >> The efficiency (number of prefixes vs total space) is only achieved if >> there is a "flat" network, >> which carries every IPv6 prefix (i.e. that there is no aggregation being >> done). >> >> This means 1:1 router slots (for routes) vs prefixes, globally, or even >> internally on ISP networks. >> >> If any ISP has > 1M customers, oops. So, we need to aggregate. >> >> Basically, the problem space (waste) boils down to the question, "How many >> levels of aggregation are needed"? >> >> If you have variable POP sizes, region sizes, and assign/aggregate towards >> customers topologically, the result is: >> - the need to maintain power-of-2 address block sizes (for aggregation), >> plus >> - the need to aggregate at each level (to keep #prefixes sane) plus >> - asymmetric sizes which don't often end up being just short of the next >> power-of-2 >> - equals (necessarily) low utilization rates >> - i.e. much larger prefixes than would be suggested by "flat" allocation >> from a single pool. >> >> Here's a worked example, for a hypothetical big consumer ISP: >> - 22 POPs with "core" devices >> - each POP has anywhere from 2 to 20 "border" devices (feeding access >> devices) >> - each "border" has 5 to 100 "access" devices >> - each access device has up to 5000 customers >> >> Rounding up each, using max(count-per-level) as the basis, we get: >> 5000->8192 (2^13) >> 100->128 (2^7) >> 20->32 (2^5) >> 22->32 (2^5) >> 5+5+7+13=30 bits of aggregation >> 2^30 of /48 = /18 >> This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. >> A thousand ISPs seems like a lot, but consider this: the ISP we did this >> for, might only have 3M customers. >> Scale this up (horizontally or vertically or both), and it is dangerously >> close to capacity already. >> >> The answer above (worked math) will be unique per ISP. It will also drive >> consumption at the apex, i.e. the size of allocations to ISPs. >> >> And root of the problem was brought into existence by the insistence that >> every network (LAN) must be a /64. >> >> That's my 2 cents/observation. >> >> Brian > > At a glance, I think there's an implicit assumption in your > calculation that each ISP has to be able to hold the whole world > (unlikely) and/or there is no such thing as mobile IP or any other > kind of tunneling technology going on within the mobile network (also > wrong from everything I understand). > > Also, I'm not sure where "from the current /8" comes from, as there's > a /3 in play (1/8 of the total space, maybe that was it?) and each > RIR is getting space in chunks of /12... > > Re-working your conclusion statement without redoing the math, "This > leaves room for 2^15 such ISPs (a mere 16384), from the current /3." > > Oddly enough, I'm OK with that. :) 16384 'isp' which is really 'transit asn' right? From streiner at cluebyfour.org Wed Dec 4 15:33:31 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 4 Dec 2013 10:33:31 -0500 (EST) Subject: Cisco ScanSafe, aka Cisco Cloud Web Security In-Reply-To: References: Message-ID: > First of all, why are you allowing or disallowing split tunnel networks ? > > There is always the risk that he/she may get infected with some malware > that your antivirus does not recognize and it spreads through the internet > network when the user VPNs to the corporate network. >From what I've seen, many government agencies - particularly those that work with sensitive data - take a very risk-averse position when dealing with remote access - if it is allowed at all. Such networks also tend to be fairly compartmentalized out of necessity. Still the possibility of a breach that originated from a user that was VPN'd in and happened to open "not-infected-srsly.zip" gives IT admins in such environments more than a bit of heartburn. jms From brian.peter.dickson at gmail.com Wed Dec 4 19:23:56 2013 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Wed, 4 Dec 2013 14:23:56 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <86mwkgxy9q.fsf@valhalla.seastrom.com> References: <86mwkgxy9q.fsf@valhalla.seastrom.com> Message-ID: On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom wrote: > > Brian Dickson writes: > > > Rob Seastrom wrote: > > > >> "Ricky Beam" http://mailman.nanog.org/mailman/listinfo/nanog>> > >> writes: > >> > > >> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom >> > wrote: *>> > >> * So there really is no excuse on AT&T's part for the /60s on uverse > >> 6rd... *> > >> * ... *> > >> * Handing out /56's like Pez is just wasting address space -- someone *> > >> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> > >> * networks when they're only ever likely to use one or two (or maybe *> > >> * four), is intentionally wasting space you could've assigned to *> > >> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> > >> * the power of huge, but it's still finite. People like you are *> > >> * repeating the same mistakes from the early days of IPv4... * There's > >> finite, and then there's finite. Please complete the > >> following math assignment so as to calibrate your perceptions before > >> leveling further allegations of profligate waste. > >> Suppose that every mobile phone on the face of the planet was an "end > >> site" in the classic sense and got a /48 (because miraculously, > >> the mobile providers aren't being stingy). > >> Now give such a phone to every human on the face of the earth. > >> Unfortunately for our conservation efforts, every person with a > >> cell phone is actually the cousin of either Avi Freedman or Vijay > >> Gill, and consequently actually has FIVE cell phones on active > >> plans at any given time. > >> Assume 2:1 overprovisioning of address space because per Cameron > >> Byrne's comments on ARIN 2013-2, the cellular equipment providers > >> can't seem to figure out how to have N+1 or N+2 redundancy rather > >> than 2N redundancy on Home Agent hardware. > >> What percentage of the total available IPv6 space have we burned > >> through in this scenario? Show your work. > >> -r > > > > > > Here's the problem with the math, presuming everyone gets roughly the > same > > answer: > > The efficiency (number of prefixes vs total space) is only achieved if > > there is a "flat" network, > > which carries every IPv6 prefix (i.e. that there is no aggregation being > > done). > > > > This means 1:1 router slots (for routes) vs prefixes, globally, or even > > internally on ISP networks. > > > > If any ISP has > 1M customers, oops. So, we need to aggregate. > > > > Basically, the problem space (waste) boils down to the question, "How > many > > levels of aggregation are needed"? > > > > If you have variable POP sizes, region sizes, and assign/aggregate > towards > > customers topologically, the result is: > > - the need to maintain power-of-2 address block sizes (for aggregation), > > plus > > - the need to aggregate at each level (to keep #prefixes sane) plus > > - asymmetric sizes which don't often end up being just short of the next > > power-of-2 > > - equals (necessarily) low utilization rates > > - i.e. much larger prefixes than would be suggested by "flat" allocation > > from a single pool. > > > > Here's a worked example, for a hypothetical big consumer ISP: > > - 22 POPs with "core" devices > > - each POP has anywhere from 2 to 20 "border" devices (feeding access > > devices) > > - each "border" has 5 to 100 "access" devices > > - each access device has up to 5000 customers > > > > Rounding up each, using max(count-per-level) as the basis, we get: > > 5000->8192 (2^13) > > 100->128 (2^7) > > 20->32 (2^5) > > 22->32 (2^5) > > 5+5+7+13=30 bits of aggregation > > 2^30 of /48 = /18 > > This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. > > A thousand ISPs seems like a lot, but consider this: the ISP we did this > > for, might only have 3M customers. > > Scale this up (horizontally or vertically or both), and it is dangerously > > close to capacity already. > > > > The answer above (worked math) will be unique per ISP. It will also drive > > consumption at the apex, i.e. the size of allocations to ISPs. > > > > And root of the problem was brought into existence by the insistence that > > every network (LAN) must be a /64. > > > > That's my 2 cents/observation. > > > > Brian > > At a glance, I think there's an implicit assumption in your > calculation that each ISP has to be able to hold the whole world > (unlikely) and/or there is no such thing as mobile IP or any other > kind of tunneling technology going on within the mobile network (also > wrong from everything I understand). > > No, not the whole world, just that the combo of internal+external has to fit. If internal breaks the table, external is irrelevant, and flat/unaggregated would do that. As for tunneling - not sure that will hold forever, especially depending on the degree of stretch (contributes to latency and bandwidth doubling). > Also, I'm not sure where "from the current /8" comes from, as there's > a /3 in play (1/8 of the total space, maybe that was it?) and each > RIR is getting space in chunks of /12... > > Doh! (I knew there was an "8" involved - need more caffeine). You're right, of course. > Re-working your conclusion statement without redoing the math, "This > leaves room for 2^15 such ISPs (a mere 16384), from the current /3." > > Oddly enough, I'm OK with that. :) > > It's not dire, but I'd be more comfortable with a few more zeros in there (even one more zero). But my point was that every 10* multiplier is 2^3-ish, and in order to get to the numbers you were pointing to, there are several of those involved. E.g. In order to provide 68B instead of 3M, which my math worked out to, that is 23000-ish bigger. That is any combination of more and/or bigger ISPs. Flatter networks (mobile) helps, but to what degree will fixed non-tunnel ISPs contribute, is the real question? What percentage of 68B will have non-wireless service(s)? Brian From brian.peter.dickson at gmail.com Wed Dec 4 19:25:51 2013 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Wed, 4 Dec 2013 14:25:51 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <86mwkgxy9q.fsf@valhalla.seastrom.com> Message-ID: Not necessarily transit - leaf ASN ISP networks (which do IP transit for consumers, but do not have BGP customers) would also be counted in. They do still exist, right? Brian On Wed, Dec 4, 2013 at 1:35 PM, Christopher Morrow wrote: > On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom wrote: > > > > Brian Dickson writes: > > > >> Rob Seastrom wrote: > >> > >>> "Ricky Beam" http://mailman.nanog.org/mailman/listinfo/nanog>> > >>> writes: > >>> > > >>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom >>> > wrote: *>> > >>> * So there really is no excuse on AT&T's part for the /60s on uverse > >>> 6rd... *> > >>> * ... *> > >>> * Handing out /56's like Pez is just wasting address space -- someone > *> > >>> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> > >>> * networks when they're only ever likely to use one or two (or maybe *> > >>> * four), is intentionally wasting space you could've assigned to *> > >>> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to > *> > >>> * the power of huge, but it's still finite. People like you are *> > >>> * repeating the same mistakes from the early days of IPv4... * There's > >>> finite, and then there's finite. Please complete the > >>> following math assignment so as to calibrate your perceptions before > >>> leveling further allegations of profligate waste. > >>> Suppose that every mobile phone on the face of the planet was an "end > >>> site" in the classic sense and got a /48 (because miraculously, > >>> the mobile providers aren't being stingy). > >>> Now give such a phone to every human on the face of the earth. > >>> Unfortunately for our conservation efforts, every person with a > >>> cell phone is actually the cousin of either Avi Freedman or Vijay > >>> Gill, and consequently actually has FIVE cell phones on active > >>> plans at any given time. > >>> Assume 2:1 overprovisioning of address space because per Cameron > >>> Byrne's comments on ARIN 2013-2, the cellular equipment providers > >>> can't seem to figure out how to have N+1 or N+2 redundancy rather > >>> than 2N redundancy on Home Agent hardware. > >>> What percentage of the total available IPv6 space have we burned > >>> through in this scenario? Show your work. > >>> -r > >> > >> > >> Here's the problem with the math, presuming everyone gets roughly the > same > >> answer: > >> The efficiency (number of prefixes vs total space) is only achieved if > >> there is a "flat" network, > >> which carries every IPv6 prefix (i.e. that there is no aggregation being > >> done). > >> > >> This means 1:1 router slots (for routes) vs prefixes, globally, or even > >> internally on ISP networks. > >> > >> If any ISP has > 1M customers, oops. So, we need to aggregate. > >> > >> Basically, the problem space (waste) boils down to the question, "How > many > >> levels of aggregation are needed"? > >> > >> If you have variable POP sizes, region sizes, and assign/aggregate > towards > >> customers topologically, the result is: > >> - the need to maintain power-of-2 address block sizes (for aggregation), > >> plus > >> - the need to aggregate at each level (to keep #prefixes sane) plus > >> - asymmetric sizes which don't often end up being just short of the next > >> power-of-2 > >> - equals (necessarily) low utilization rates > >> - i.e. much larger prefixes than would be suggested by "flat" allocation > >> from a single pool. > >> > >> Here's a worked example, for a hypothetical big consumer ISP: > >> - 22 POPs with "core" devices > >> - each POP has anywhere from 2 to 20 "border" devices (feeding access > >> devices) > >> - each "border" has 5 to 100 "access" devices > >> - each access device has up to 5000 customers > >> > >> Rounding up each, using max(count-per-level) as the basis, we get: > >> 5000->8192 (2^13) > >> 100->128 (2^7) > >> 20->32 (2^5) > >> 22->32 (2^5) > >> 5+5+7+13=30 bits of aggregation > >> 2^30 of /48 = /18 > >> This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. > >> A thousand ISPs seems like a lot, but consider this: the ISP we did this > >> for, might only have 3M customers. > >> Scale this up (horizontally or vertically or both), and it is > dangerously > >> close to capacity already. > >> > >> The answer above (worked math) will be unique per ISP. It will also > drive > >> consumption at the apex, i.e. the size of allocations to ISPs. > >> > >> And root of the problem was brought into existence by the insistence > that > >> every network (LAN) must be a /64. > >> > >> That's my 2 cents/observation. > >> > >> Brian > > > > At a glance, I think there's an implicit assumption in your > > calculation that each ISP has to be able to hold the whole world > > (unlikely) and/or there is no such thing as mobile IP or any other > > kind of tunneling technology going on within the mobile network (also > > wrong from everything I understand). > > > > Also, I'm not sure where "from the current /8" comes from, as there's > > a /3 in play (1/8 of the total space, maybe that was it?) and each > > RIR is getting space in chunks of /12... > > > > Re-working your conclusion statement without redoing the math, "This > > leaves room for 2^15 such ISPs (a mere 16384), from the current /3." > > > > Oddly enough, I'm OK with that. :) > > 16384 'isp' which is really 'transit asn' right? > From alh-ietf at tndh.net Wed Dec 4 19:34:28 2013 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 4 Dec 2013 11:34:28 -0800 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <86mwkgxy9q.fsf@valhalla.seastrom.com> References: <86mwkgxy9q.fsf@valhalla.seastrom.com> Message-ID: <025b01cef127$d93bda40$8bb38ec0$@tndh.net> Brian Dickson wrote: > > And root of the problem was brought into existence by the insistence > > that every network (LAN) must be a /64. Get your history straight. The /64 was an outcome of operators deciding there was not enough room for hierarchy in the original proposal for the IPv6 address as 64 bits (including hosts), despite its ability to deliver 3 orders of magnitude more than the IAB goal statement. Given that position, the entire 64 bits was given to *ROUTING* and we argued for another year about how many bits to add for hosts on the lan. The fact it came out to 64 was an artifact of emerging 64 bit processors and the desire to avoid any more bit shifting than necessary. Yes, autoconfig using the mac was a consideration, but that was a convenient outcome, not the driving factor. Yet here we are 15 years later and the greedy, or math challenged, still insist on needing even more bits. Stop worrying about how many bits there are in the lan space. That abundance allows for technical innovation that will never be possible in the stingy world of centralized control. Consider a world where the 'central control' crowd only allows one application on the network (voice), and innovation is defined as 'only deploy something with an immediate income stream' (caller id). In an environment like that, were do new things come from? You can't prove a demand exists without deployment, yet you can't get deployment without a proven demand. Enter the ott Internet which leveraged the only allowed app via an audio modulation hack and built something entirely different, where innovation was allowed to flourish. Now go back to the concept of miserly central control of lan bits and figure out how one might come up with something like RFC3971 (SEND) that would work in any network. Rob Seastrom wrote: > > Re-working your conclusion statement without redoing the math, "This > leaves room for 2^15 such ISPs (a mere 16384), from the current /3." Interesting; that was the IAB design goal for total end system count. >>> 2^12 networks supporting 2^15 end systems. > > Oddly enough, I'm OK with that. :) So am I, and if we do burn through that before a replacement network technology comes along, there are still 6 more buckets that large to do it differently. Tony From morrowc.lists at gmail.com Wed Dec 4 19:46:49 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Dec 2013 14:46:49 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <86mwkgxy9q.fsf@valhalla.seastrom.com> Message-ID: On Wed, Dec 4, 2013 at 2:25 PM, Brian Dickson wrote: > Not necessarily transit - leaf ASN ISP networks (which do IP transit for > consumers, but do not have BGP customers) would also be counted in. They do > still exist, right? that's still a transit as, right? I think your math means that there would only ever be 16k networks.. which seems small. > On Wed, Dec 4, 2013 at 1:35 PM, Christopher Morrow > wrote: >> >> On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom wrote: >> > >> > Brian Dickson writes: >> > >> >> Rob Seastrom wrote: >> >> >> >>> "Ricky Beam" > >>> gmail.com> >> >>> writes: >> >>> > >> >>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > >>> > wrote: *>> >> >>> * So there really is no excuse on AT&T's part for the /60s on uverse >> >>> 6rd... *> >> >>> * ... *> >> >>> * Handing out /56's like Pez is just wasting address space -- someone >> >>> *> >> >>> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> >> >>> * networks when they're only ever likely to use one or two (or maybe >> >>> *> >> >>> * four), is intentionally wasting space you could've assigned to *> >> >>> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to >> >>> *> >> >>> * the power of huge, but it's still finite. People like you are *> >> >>> * repeating the same mistakes from the early days of IPv4... * There's >> >>> finite, and then there's finite. Please complete the >> >>> following math assignment so as to calibrate your perceptions before >> >>> leveling further allegations of profligate waste. >> >>> Suppose that every mobile phone on the face of the planet was an "end >> >>> site" in the classic sense and got a /48 (because miraculously, >> >>> the mobile providers aren't being stingy). >> >>> Now give such a phone to every human on the face of the earth. >> >>> Unfortunately for our conservation efforts, every person with a >> >>> cell phone is actually the cousin of either Avi Freedman or Vijay >> >>> Gill, and consequently actually has FIVE cell phones on active >> >>> plans at any given time. >> >>> Assume 2:1 overprovisioning of address space because per Cameron >> >>> Byrne's comments on ARIN 2013-2, the cellular equipment providers >> >>> can't seem to figure out how to have N+1 or N+2 redundancy rather >> >>> than 2N redundancy on Home Agent hardware. >> >>> What percentage of the total available IPv6 space have we burned >> >>> through in this scenario? Show your work. >> >>> -r >> >> >> >> >> >> Here's the problem with the math, presuming everyone gets roughly the >> >> same >> >> answer: >> >> The efficiency (number of prefixes vs total space) is only achieved if >> >> there is a "flat" network, >> >> which carries every IPv6 prefix (i.e. that there is no aggregation >> >> being >> >> done). >> >> >> >> This means 1:1 router slots (for routes) vs prefixes, globally, or even >> >> internally on ISP networks. >> >> >> >> If any ISP has > 1M customers, oops. So, we need to aggregate. >> >> >> >> Basically, the problem space (waste) boils down to the question, "How >> >> many >> >> levels of aggregation are needed"? >> >> >> >> If you have variable POP sizes, region sizes, and assign/aggregate >> >> towards >> >> customers topologically, the result is: >> >> - the need to maintain power-of-2 address block sizes (for >> >> aggregation), >> >> plus >> >> - the need to aggregate at each level (to keep #prefixes sane) plus >> >> - asymmetric sizes which don't often end up being just short of the >> >> next >> >> power-of-2 >> >> - equals (necessarily) low utilization rates >> >> - i.e. much larger prefixes than would be suggested by "flat" >> >> allocation >> >> from a single pool. >> >> >> >> Here's a worked example, for a hypothetical big consumer ISP: >> >> - 22 POPs with "core" devices >> >> - each POP has anywhere from 2 to 20 "border" devices (feeding access >> >> devices) >> >> - each "border" has 5 to 100 "access" devices >> >> - each access device has up to 5000 customers >> >> >> >> Rounding up each, using max(count-per-level) as the basis, we get: >> >> 5000->8192 (2^13) >> >> 100->128 (2^7) >> >> 20->32 (2^5) >> >> 22->32 (2^5) >> >> 5+5+7+13=30 bits of aggregation >> >> 2^30 of /48 = /18 >> >> This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. >> >> A thousand ISPs seems like a lot, but consider this: the ISP we did >> >> this >> >> for, might only have 3M customers. >> >> Scale this up (horizontally or vertically or both), and it is >> >> dangerously >> >> close to capacity already. >> >> >> >> The answer above (worked math) will be unique per ISP. It will also >> >> drive >> >> consumption at the apex, i.e. the size of allocations to ISPs. >> >> >> >> And root of the problem was brought into existence by the insistence >> >> that >> >> every network (LAN) must be a /64. >> >> >> >> That's my 2 cents/observation. >> >> >> >> Brian >> > >> > At a glance, I think there's an implicit assumption in your >> > calculation that each ISP has to be able to hold the whole world >> > (unlikely) and/or there is no such thing as mobile IP or any other >> > kind of tunneling technology going on within the mobile network (also >> > wrong from everything I understand). >> > >> > Also, I'm not sure where "from the current /8" comes from, as there's >> > a /3 in play (1/8 of the total space, maybe that was it?) and each >> > RIR is getting space in chunks of /12... >> > >> > Re-working your conclusion statement without redoing the math, "This >> > leaves room for 2^15 such ISPs (a mere 16384), from the current /3." >> > >> > Oddly enough, I'm OK with that. :) >> >> 16384 'isp' which is really 'transit asn' right? > > From owen at delong.com Wed Dec 4 19:48:33 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Dec 2013 11:48:33 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <529F7557.3020607@inblock.ru> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> Message-ID: <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> On Dec 4, 2013, at 10:32 , Nikolay Shopik wrote: > On 04.12.2013 4:14, Mark Andrews wrote: >> In message <529D9492.8020205 at inblock.ru>, Nikolay Shopik writes: >>> On 03/12/13 02:54, Owen DeLong wrote: >>>> I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 add >>> ress space. >>> >>> There is some ISP who afraid their users will be reselling their >>> connectivity to other users around. While I didin't see that in years >>> (probably last time in 2005) but still this exist in poor regions. >> >> And if they didn't resell it they probably wouldn't have a customer >> in the first place. Unless you offer "unlimited" plans the ISP >> isn't losing anything here. The bandwidth being used is being paid >> for. If it isn't the ISP needs to adjust the price points to cover >> their costs rather than hoping that people won't use all of the >> bandwidth they have purchased. > > If we talk about end-user not business user, ISP assume 95th% load will > be minimal so therefore it allow them to sell 100mbit for like 20-30$, > while real price of it much higher. Please tell me what provider is selling 100Mbit for $20-30 in the 408-532-xxxx area of San Jose, California. Currently, the only provider capable of delivering more than 768k wired here is charging me $100+/month for 30-50Mbps maximum. I could get 100Mbps from them, but they want $250+/month for that. If I can get 100Mbps for $20-30, I'd jump at it. > If its big ISP they usually don't care, as there always be downloaders > who saturate their link to 90% most time, but compare to most of other > users in their net, this will be not noticeable. If its just smallish > ISP things get harder for it. For $100+/month, frankly, it's none of their business whether I'm pooling my resources with my neighbors to pay for the connectivity or not. >> This is like the whole tethered debate. Why should the ISP care >> about which device the packets are source from. The customer is >> buying so many gigabytes of traffic a month. They should be able >> to use them anyway they see fit without actually breaking the laws >> of the land. > > If you actually pay per bit, true or have some kind "fair usage" > unlimited plan. Which is pretty much all that is available any more. >> I let my daughter's friends use the net at home here. If they burn >> through my monthly allotment well then I need to pony up more money >> or take a reduced service level until the month ends. It's none >> of my ISP's concern how the bandwidth I have purchased from them >> is being used. > > If you talk about wired connection, this thing almost non-existing here. > Only apply to wireless 3G/4G ISPs with limited bits and then reduced > service. Not entirely sure what you are saying here. In this day and age, I don't see any reason that wireless providers should get a free pass or be able to sustain significantly worse policies than wireline providers. Wireless bandwidth is rapidly approaching parity with wired bandwidth pricing at consumer levels. > Some even come up with idea two separate /64 make things easier :-D, > instead just put at least round /60 Actually, providing a separate /64 for the provider link makes a lot of sense. It really is best to pull that out of a separate provider aggregate across all the subscribers in the same aggregation group than to carve individual link prefixes out of each subscribers internal-use prefix. For example, if you get a tunnel from HE, then, by default, you get a /64 from our link block for the tunnel broker to which you connect and an additional /64 for your internal use by default. If you click the "please give me a /48" checkbox, then you'll also get an additional /48. We do this because it makes our provisioning easier and allows us to support users that want prefixes as well as users whose equipment (or brains) can't handle more than a single /64 for their LAN. There's really NOTHING to be gained from providing anything in between a /64 and a /48, so we don't do it. Owen From brian.peter.dickson at gmail.com Wed Dec 4 20:04:35 2013 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Wed, 4 Dec 2013 15:04:35 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <025b01cef127$d93bda40$8bb38ec0$@tndh.net> References: <86mwkgxy9q.fsf@valhalla.seastrom.com> <025b01cef127$d93bda40$8bb38ec0$@tndh.net> Message-ID: On Wed, Dec 4, 2013 at 2:34 PM, Tony Hain wrote: > Brian Dickson wrote: > > > And root of the problem was brought into existence by the insistence > > > that every network (LAN) must be a /64. > [snip] > about how many bits to add for hosts on the lan. The fact it came out to 64 > > The point I'm making (and have made before), is not how many bits, but that it is a fixed number (64). And again, the concern isn't about bits, it is about slots in routing tables. Routing table hardware is generally: (a) non-upgradeable in currently deployed systems, and (b) very very expensive (at least for TCAMs). (c) for lots of routers, is per-linecard (not per-router) cost If you look back at the need for CIDR (where we went from class A, B, and C to variable-length subnet masks), it might be a bit more obvious. CIDR fixed the total number of available routes problem, but fundamentally cannot do anything about # route slots. Fixed sizes do not have the scalability that variable sizes do, when it comes to networks, even within a fixed total size (network + host). Variable sizes are needed for aggregation, which is the only solution to router slot issues. IF deployed by operators correctly, the global routing table should be 1 IPv6 route per ASN. However, that is only feasible if each ASN can efficiently aggregate forever (or 50 years at least). The math shows that 61 bits, given out in 16-bit chunks to end users, when aggregation is used hierarchically, runs the risk of not lasting 50 years. [snip] > Now > go back to the concept of miserly central control of lan bits and figure > out > how one might come up with something like RFC3971 (SEND) that would work in > any network. > > There are two really easy ways, just off the top of my head: (1) prefix delegation. Host wanting SEND asks its upstream router to delegate a prefix of adequate size. The prefix is routed to the host, with only the immediate upstream router knowing the host's non-SEND address. The host picks SEND addresses from the prefix, rotates whenever it wants, problem solved. QED. (2) pass the prefix size to the host. Have the SEND math use whatever scheme it wants, modulo that size. E.g. rand(2**64-1) -> rand(2**prefix_size-1). Host redoes this whenever it changes addresses, problem solved. QED. (The question of how much space is adequate for the protection offered by SEND. I suggest that 32 bits as a minimum, would still be adequate.) As far as I have been able to determine, there are very few places where fixed /64 (as a requirement) actually makes sense. For example, the code for IPv6 on Linux, basically does "check that we're /64 and if not fail", but otherwise has no /64 dependencies. We can always do an IPv6-bis in future, to first fix SEND, then fix autoconf, and finally remove /64 from IPv6 -- if we think the usage rate justifies doing so. Brian From owen at delong.com Wed Dec 4 20:09:10 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Dec 2013 12:09:10 -0800 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: Message-ID: <55AAEAC4-38A6-4A81-BA3B-EEC84646EA45@delong.com> On Dec 4, 2013, at 10:21 , Brian Dickson wrote: > Rob Seastrom wrote: > >> "Ricky Beam" > >> writes: >>> >> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > > wrote: *>> >> * So there really is no excuse on AT&T's part for the /60s on uverse >> 6rd... *> >> * ... *> >> * Handing out /56's like Pez is just wasting address space -- someone *> >> * *is* paying for that space. Yes, it's waste; giving everyone 256 *> >> * networks when they're only ever likely to use one or two (or maybe *> >> * four), is intentionally wasting space you could've assigned to *> >> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *> >> * the power of huge, but it's still finite. People like you are *> >> * repeating the same mistakes from the early days of IPv4... * There's >> finite, and then there's finite. Please complete the >> following math assignment so as to calibrate your perceptions before >> leveling further allegations of profligate waste. >> Suppose that every mobile phone on the face of the planet was an "end >> site" in the classic sense and got a /48 (because miraculously, >> the mobile providers aren't being stingy). >> Now give such a phone to every human on the face of the earth. >> Unfortunately for our conservation efforts, every person with a >> cell phone is actually the cousin of either Avi Freedman or Vijay >> Gill, and consequently actually has FIVE cell phones on active >> plans at any given time. >> Assume 2:1 overprovisioning of address space because per Cameron >> Byrne's comments on ARIN 2013-2, the cellular equipment providers >> can't seem to figure out how to have N+1 or N+2 redundancy rather >> than 2N redundancy on Home Agent hardware. >> What percentage of the total available IPv6 space have we burned >> through in this scenario? Show your work. >> -r > > > Here's the problem with the math, presuming everyone gets roughly the same > answer: > The efficiency (number of prefixes vs total space) is only achieved if > there is a "flat" network, > which carries every IPv6 prefix (i.e. that there is no aggregation being > done). Yes, but since our most exaggerated estimates only got to a /11, you can do up to 256x in waste in order to support aggregation and still fit within 2000::/3 (1/8th of the total address space). > > This means 1:1 router slots (for routes) vs prefixes, globally, or even > internally on ISP networks. > > If any ISP has > 1M customers, oops. So, we need to aggregate. > > Basically, the problem space (waste) boils down to the question, "How many > levels of aggregation are needed"? I argue that much of the waste needed for aggregation is available in the amount by which the model for the number of required is included in the pre-existing exaggeration of the model. However, there's still a 256x factor within 2000::/3 that can also absorb aggregation costs. > > If you have variable POP sizes, region sizes, and assign/aggregate towards > customers topologically, the result is: > - the need to maintain power-of-2 address block sizes (for aggregation), > plus > - the need to aggregate at each level (to keep #prefixes sane) plus > - asymmetric sizes which don't often end up being just short of the next > power-of-2 > - equals (necessarily) low utilization rates > - i.e. much larger prefixes than would be suggested by "flat" allocation > from a single pool. > > Here's a worked example, for a hypothetical big consumer ISP: > - 22 POPs with "core" devices > - each POP has anywhere from 2 to 20 "border" devices (feeding access > devices) > - each "border" has 5 to 100 "access" devices > - each access device has up to 5000 customers > But you don't have to (or even usually want to) aggregate at all of those levels. > Rounding up each, using max(count-per-level) as the basis, we get: > 5000->8192 (2^13) > 100->128 (2^7) > 20->32 (2^5) > 22->32 (2^5) > 5+5+7+13=30 bits of aggregation > 2^30 of /48 = /18 > This leaves room for 2^10 such ISPs (a mere 1024), from the current /8. > A thousand ISPs seems like a lot, but consider this: the ISP we did this > for, might only have 3M customers. > Scale this up (horizontally or vertically or both), and it is dangerously > close to capacity already. First of all, you are mistaken. There is no current /8, it's a /3, so there's room for 32 times that (32,768 such ISPs). Second of all, what would make much more sense in your scenario is to aggregate at one or two of those levels. I'd expect probably the POP and the Border device levels most likely, so what you're really looking at is 5000*100 = 500,000 /48s per border. To make this even, we'll round that up to 524,288 (2^19) and actually to make life easy, let's take that to a nibble boundary (2^20) 1,048,576, which gives us a /28 per Border Device. Now aggregating POPs, we have 22*20 border devices which fits in 8 bits, so we can build this ISP in a /20 quite easily. That leaves us 17 bits in the current /3 for assigning ISPs of this size (note, this is quite the sizeable ISP since we're supporting 220,000,000 customers in your count. Even so, since they only need a /20, I think that's OK. We've got room to support enough of those ISPs that even if they only have 3 million customers, since we can support 131,072 such ISPs in the current /3, that gives us the ability to address a total of 393,216,000,000 total customers. There are approximately 6,800,000,000 People on the planet, so we have almost 60x as many ISPs as we would possibly need. > The answer above (worked math) will be unique per ISP. It will also drive > consumption at the apex, i.e. the size of allocations to ISPs. Sure, but doing aggregation in the least efficient possible way against inflated numbers and you were still barely able to make it be a problem by dividing the currently available address space by 256 and ignoring the fact that the currently available address space is only 1/8th of the total address space. > And root of the problem was brought into existence by the insistence that > every network (LAN) must be a /64. Not really. The original plan was for everything to be 64 bits, so by adding another 64 bits and making every network a /64, we're actually better off than we would have been if we'd just gone to 64 bit addresses in toto. Thanks for playing. Owen From morrowc.lists at gmail.com Wed Dec 4 20:33:54 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Dec 2013 15:33:54 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <86mwkgxy9q.fsf@valhalla.seastrom.com> <025b01cef127$d93bda40$8bb38ec0$@tndh.net> Message-ID: On Wed, Dec 4, 2013 at 3:04 PM, Brian Dickson wrote: > IF deployed by operators correctly, the global routing table should be 1 > IPv6 route per ASN. > However, that is only feasible if each ASN can efficiently aggregate > forever (or 50 years at least). and if your capacity between 2 asn endpoints is always able to handle the traffic load offered, right? else you start having to traffic-engineer... which today means deaggregate (or announce some more specifics along with the aggregate). I'm not sure I'd make a bet that I can always have enough capacity between any two asn endpoints that I wouldn't need to TE. From swmike at swm.pp.se Wed Dec 4 20:35:36 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 4 Dec 2013 21:35:36 +0100 (CET) Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> Message-ID: On Wed, 4 Dec 2013, Owen DeLong wrote: > significantly worse policies than wireline providers. Wireless bandwidth > is rapidly approaching parity with wired bandwidth pricing at consumer > levels. Have you seen the cost of an LTE base station including install and monthly fees? If you did, you wouldn't make that claim. If you want to deliver not even close to speed parity to fiber, you need multiple base stations per city block. This is extremely cost prohivitive, especially since you need fiber to the base stations anyway. Btw, if I could convince everybody in my building to pay 400 USD install for fiber, I could get 100/100 Internet conenctivity for USD10 per month. There just isn't any way in the world this is doable with wireless. Don't make the mistake of comparing the dysfunctional US market pricing levels with what is actually doable in a working market. -- Mikael Abrahamsson email: swmike at swm.pp.se From brian.peter.dickson at gmail.com Wed Dec 4 20:43:33 2013 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Wed, 4 Dec 2013 15:43:33 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <55AAEAC4-38A6-4A81-BA3B-EEC84646EA45@delong.com> References: <55AAEAC4-38A6-4A81-BA3B-EEC84646EA45@delong.com> Message-ID: On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong wrote: > > On Dec 4, 2013, at 10:21 , Brian Dickson > wrote: > > Second of all, what would make much more sense in your scenario is > to aggregate at one or two of those levels. I'd expect probably the POP > and the Border device levels most likely, so what you're really looking > at is 5000*100 = 500,000 /48s per border. To make this even, we'll > round that up to 524,288 (2^19) and actually to make life easy, let's > take that to a nibble boundary (2^20) 1,048,576, which gives us a > /28 per Border Device. > > > Except that we have a hard limit of 1M total, which after a few 100K from the global routing tables (IPv4+IPv6), this 500,000 looks pretty dicey. > > > And root of the problem was brought into existence by the insistence that > > every network (LAN) must be a /64. > > Not really. The original plan was for everything to be 64 bits, so by > adding > another 64 bits and making every network a /64, we're actually better off > than we would have been if we'd just gone to 64 bit addresses in toto. > > Thanks for playing. > > Owen > > Understand, I am not saying anyone got it wrong, but rather, that there is a risk associated with continuing forever to use a /64 fixed LAN size. Yes, we are better than we were, but the point I'm making is, if push comes to shove, that the /64 is a small thing to sacrifice (at very small incremental cost, SEND + AUTOCONF modifications). I can't believe I just called 2**64 small. Brian From morrowc.lists at gmail.com Wed Dec 4 20:48:06 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Dec 2013 15:48:06 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <55AAEAC4-38A6-4A81-BA3B-EEC84646EA45@delong.com> Message-ID: On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson wrote: > Except that we have a hard limit of 1M total, which after a few 100K from where does the 1M come from? From owen at delong.com Wed Dec 4 20:50:42 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Dec 2013 12:50:42 -0800 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <55AAEAC4-38A6-4A81-BA3B-EEC84646EA45@delong.com> Message-ID: <9727EC86-D7D6-4BF7-B3ED-4FED79CABF44@delong.com> On Dec 4, 2013, at 12:43 , Brian Dickson wrote: > > > > On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong wrote: > > On Dec 4, 2013, at 10:21 , Brian Dickson wrote: > > Second of all, what would make much more sense in your scenario is > to aggregate at one or two of those levels. I'd expect probably the POP > and the Border device levels most likely, so what you're really looking > at is 5000*100 = 500,000 /48s per border. To make this even, we'll > round that up to 524,288 (2^19) and actually to make life easy, let's > take that to a nibble boundary (2^20) 1,048,576, which gives us a > /28 per Border Device. > > > > Except that we have a hard limit of 1M total, which after a few 100K from the > global routing tables (IPv4+IPv6), this 500,000 looks pretty dicey. > Only if you feel the need to carry those global routes all the way down to your border devices (which is unlikely in the kind of residential scenario proposed). > > > And root of the problem was brought into existence by the insistence that > > every network (LAN) must be a /64. > > Not really. The original plan was for everything to be 64 bits, so by adding > another 64 bits and making every network a /64, we're actually better off > than we would have been if we'd just gone to 64 bit addresses in toto. > > Thanks for playing. > > Owen > > Understand, I am not saying anyone got it wrong, but rather, that there is a risk associated > with continuing forever to use a /64 fixed LAN size. Yes, we are better than we > were, but the point I'm making is, if push comes to shove, that the /64 is a small thing > to sacrifice (at very small incremental cost, SEND + AUTOCONF modifications). > I think it is already too entrenched to change, but I guess time will tell. Since we are only talking about how we use the first 1/8th of the address space and we didn't even exhaust that in your particularly overblown example, I am unconcerned. > I can't believe I just called 2**64 small. Well, it's smaller than 2^128. ;-) Owen From owen at delong.com Wed Dec 4 20:56:22 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Dec 2013 12:56:22 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> Message-ID: On Dec 4, 2013, at 12:35 , Mikael Abrahamsson wrote: > On Wed, 4 Dec 2013, Owen DeLong wrote: > >> significantly worse policies than wireline providers. Wireless bandwidth is rapidly approaching parity with wired bandwidth pricing at consumer levels. > > Have you seen the cost of an LTE base station including install and monthly fees? If you did, you wouldn't make that claim. > Nope... I look at the consumer side pricing and the fact that cellular providers by and large are NOT losing money. I assume that means that the rest of the math behind the scenes must work somehow. > If you want to deliver not even close to speed parity to fiber, you need multiple base stations per city block. This is extremely cost prohivitive, especially since you need fiber to the base stations anyway. I'd love fiber, but I can't even get fiber in my neighborhood (or most of the civilized portions of the US) because fiber deployments are concentrated where rural subsidies are available due to USF market manipulations. > Btw, if I could convince everybody in my building to pay 400 USD install for fiber, I could get 100/100 Internet conenctivity for USD10 per month. There just isn't any way in the world this is doable with wireless. Yeah, I'm sure there are all kinds of ways that wireline could be made cheaper, etc. However, I'm talking about comparing consumer pricing, not behind the scenes costs as the former is relatively easy to compare on even footing while the later is far to obfuscated by far too many parties to ever have a rational debate. > Don't make the mistake of comparing the dysfunctional US market pricing levels with what is actually doable in a working market. I said nothing about what was possible... I only comment on what is actually happening. If you know how to achieve a functioning market in the US, I'm all ears. In the mean time, dysfunction is all I have available to work with. Owen From brian.peter.dickson at gmail.com Wed Dec 4 20:58:30 2013 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Wed, 4 Dec 2013 15:58:30 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <55AAEAC4-38A6-4A81-BA3B-EEC84646EA45@delong.com> Message-ID: On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow wrote: > On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson > wrote: > > Except that we have a hard limit of 1M total, which after a few 100K from > > where does the 1M come from? > FIB table sizes, usually dictated by TCAM size. Think deployed hardware, lots of it. (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6 taking two slots of TCAM, IIRC. And a few other things also consume TCAM, maybe not as significantly.) (Newer boxes may handle more on some network's cores, but I don't believe it is ubiquitously the case across the DFZ.) Brian From joelja at bogus.com Wed Dec 4 21:26:16 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 04 Dec 2013 13:26:16 -0800 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <55AAEAC4-38A6-4A81-BA3B-EEC84646EA45@delong.com> Message-ID: <529F9DF8.9090306@bogus.com> On 12/4/13, 12:58 PM, Brian Dickson wrote: > On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow > wrote: > >> On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson >> wrote: >>> Except that we have a hard limit of 1M total, which after a few 100K from >> >> where does the 1M come from? >> > > FIB table sizes, usually dictated by TCAM size. Think deployed hardware, > lots of it. > (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6 > taking two slots of TCAM, IIRC. And a few other things also consume TCAM, > maybe not as significantly.) > > (Newer boxes may handle more on some network's cores, but I don't believe > it is ubiquitously the case across the DFZ.) Table size growth has conveniently not outstripped the growth of available fib sizes in a quite a long time. There doesn't appear to be much reason to believe that won't continue baring us coming up with novel ways to blow up the size of the DFZ. Managing to aggregate in some way that respects your internal topology and addressing plan without blowing up your route count is an exercise for the reader. It's somewhat facile to relate fib size to the bounds of what ternary cam chips you can currently buy since not all routers use cams for longest match lookups. > Brian > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Wed Dec 4 21:30:04 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 4 Dec 2013 16:30:04 -0500 Subject: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <55AAEAC4-38A6-4A81-BA3B-EEC84646EA45@delong.com> Message-ID: On Wed, Dec 4, 2013 at 3:58 PM, Brian Dickson wrote: > > > > On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow > wrote: >> >> On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson >> wrote: >> > Except that we have a hard limit of 1M total, which after a few 100K >> > from >> >> where does the 1M come from? > > > FIB table sizes, usually dictated by TCAM size. Think deployed hardware, > lots of it. > (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6 > taking two slots of TCAM, IIRC. And a few other things also consume TCAM, > maybe not as significantly.) > > (Newer boxes may handle more on some network's cores, but I don't believe it > is ubiquitously the case across the DFZ.) > ok, that's fair... but in ~5yrs time we'll work ourslves out of the 1M mark, right? to 5M or 10M? (or something more than 1M) From swmike at swm.pp.se Wed Dec 4 21:43:10 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 4 Dec 2013 22:43:10 +0100 (CET) Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> Message-ID: On Wed, 4 Dec 2013, Owen DeLong wrote: > Nope... I look at the consumer side pricing and the fact that cellular > providers by and large are NOT losing money. I assume that means that > the rest of the math behind the scenes must work somehow. Cost != price. Also, wireless providers are not delivering the same service as wireline providers. How many gigabytes per month do you usually get for the same money on wireline compared to wireless? > Yeah, I'm sure there are all kinds of ways that wireline could be made > cheaper, etc. However, I'm talking about comparing consumer pricing, not > behind the scenes costs as the former is relatively easy to compare on > even footing while the later is far to obfuscated by far too many > parties to ever have a rational debate. Consumer pricing often have nothing to do with cost in a dysfunctional market. It a functional market, cost and price are more closely related. > I said nothing about what was possible... I only comment on what is > actually happening. If you know how to achieve a functioning market in > the US, I'm all ears. In the mean time, dysfunction is all I have > available to work with. Well, there would have to be a huge amount of changes, and most likely only a portion of them would be implemented and then the changes would be deemed a failure. Make it administratively fairly easy to put fiber in the ground. Make municipalities/utilities put in fiber along other infrastructure and make them rent it out at pricepoints that are related to cost. If it's possible to rent dark fiber, then you can all of a sudden get competition instead of having a few huge companies dominate the market. Access to possibility of renting or installing L1 infrastructure to the block/cabinet is the key. -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Wed Dec 4 21:53:06 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 05 Dec 2013 08:53:06 +1100 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: Your message of "Wed, 04 Dec 2013 11:38:54 -0500." References: Message-ID: <20131204215307.767B3B280B7@rock.dv.isc.org> In message , Lee Howard writes: > > > On 12/3/13 7:14 PM, "Mark Andrews" wrote: > > > > >In message <529D9492.8020205 at inblock.ru>, Nikolay Shopik writes: > >> On 03/12/13 02:54, Owen DeLong wrote: > >> > I have talked to my bean counters. We give out /48s to anyone who > >>wants them and we don't charge for IPv6 add > >> ress space. > >> > >> There is some ISP who afraid their users will be reselling their > >> connectivity to other users around. While I didin't see that in years > >> (probably last time in 2005) but still this exist in poor regions. > > > >And if they didn't resell it they probably wouldn't have a customer > >in the first place. Unless you offer "unlimited" plans the ISP > >isn't losing anything here. The bandwidth being used is being paid > >for. If it isn't the ISP needs to adjust the price points to cover > >their costs rather than hoping that people won't use all of the > >bandwidth they have purchased. > > It seems that, especially in the U.S., consumers don't like paying per-bit. > That was true with per-minute for voice, too. > > You are free to be unhappy about consumer behavior. Customers like to know what there bill will be at the end of each month and not suffer from bill shock. There are lots of ways to provide that. For instance I pay $85 for 120G per month + telephone with a rate limited connection if I go over that. I can pay more or less and change the amount of traffic I get before it becomes rate limited. I get warnings at various tigger points. I can see my total and daily usage of the month. In the US you still pay $XX for YYYG and then get rate limited. You call this unlimited and you don't know what YYY is and it changes from month to month. > >> Other than that, completely agree on /56y default and /48 on request, > >> but most ISPs here are give-out just single /64. > > > >Which is just plain stupid. > > You are also free to run your network as you choose. Getting upset about > how other people run their networks is not going to improve the world. Actually it is. Developers need to design for their products to work in the real world. Getting realistic minimums provided everywhere is useful. People need to be told when they are doing something that is bad for the general community and only supplying a single /64 is bad for the general community as it is outside the design choices that were made when developing IPv6. > Lee > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wbailey at satelliteintelligencegroup.com Wed Dec 4 22:05:23 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 4 Dec 2013 22:05:23 +0000 Subject: Question related to Cellular Data and restrictions.. Message-ID: All, I realize this is not exactly relevant to the usual topics on NANOG, but I thought this list was a decent place to ask a question related to cellular data usage limits. Have any of you experienced or been subjected to a "domestic data roaming policy"? I am a customer of a carrier who advertises "Unlimited Nationwide 4G data", but limits their customers to 50MB per month while traveling in an area they do not have coverage (Alaska, for example). I've never heard of such a policy in regards to a "Nationwide" plan.. I thought the entire idea of saying nationwide was to represent you were covering the ENTIRE NATION. Happy to receive replies on or off-list. Thanks! //warren From j at 2600hz.com Wed Dec 4 22:18:12 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Wed, 4 Dec 2013 22:18:12 +0000 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: Message-ID: TL;DR: peering is not free in wireless. Hi, So as you may or may not be aware, most operators do not, in fact have nationwide networks, just as you, as I assume you're an operator, do not run last mile connectivity to all your customers (or every intervening interconnect for that matter). The same is true in wireless. Sprint (arbitrary example) has coverage in most of the top 100 metros but supplements this coverage with domestic roaming agreements (usually with Verizon or a group of independent tower aggregators). Sprint pays Verizon for the traffic they send to their network. The pricing you receive as a consumer is based upon the majority of your traffic hitting sprints towers (and not being ferried over a more expensive channel, like a roaming agreement). When you send your data over a partners network it raises your wireless company's cost of delivering service, in some cases so much so that you become unprofitable. Sprint isn't a charity and therefore cuts you loose. Cheers, Joshua Sent from my iPhone On Dec 4, 2013, at 2:06 PM, "Warren Bailey" wrote: > All, > > I realize this is not exactly relevant to the usual topics on NANOG, but I thought this list was a decent place to ask a question related to cellular data usage limits. > > Have any of you experienced or been subjected to a "domestic data roaming policy"? I am a customer of a carrier who advertises "Unlimited Nationwide 4G data", but limits their customers to 50MB per month while traveling in an area they do not have coverage (Alaska, for example). I've never heard of such a policy in regards to a "Nationwide" plan.. I thought the entire idea of saying nationwide was to represent you were covering the ENTIRE NATION. > > Happy to receive replies on or off-list. > > Thanks! > //warren > From jra at baylink.com Wed Dec 4 22:20:33 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 4 Dec 2013 17:20:33 -0500 (EST) Subject: Question related to Cellular Data and restrictions.. In-Reply-To: Message-ID: <13720621.4060.1386195633357.JavaMail.root@benjamin.baylink.com> > Have any of you experienced or been subjected to a "domestic data > roaming policy"? I am a customer of a carrier who advertises > "Unlimited Nationwide 4G data", but limits their customers to 50MB per > month while traveling in an area they do not have coverage (Alaska, > for example). I've never heard of such a policy in regards to a > "Nationwide" plan.. I thought the entire idea of saying nationwide was > to represent you were covering the ENTIRE NATION. I believe you will find that any carrier says "Nationwide means where we have coverage, and unlimited means 'if you're on our towers'." Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jack at mail.rockefeller.edu Wed Dec 4 22:45:35 2013 From: jack at mail.rockefeller.edu (Jack Vizelter) Date: Wed, 4 Dec 2013 22:45:35 +0000 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: <13720621.4060.1386195633357.JavaMail.root@benjamin.baylink.com> References: , <13720621.4060.1386195633357.JavaMail.root@benjamin.baylink.com> Message-ID: In my experience, nationwide, typically just means the continental 48 states, for the most part. ________________________________________ From: Jay Ashworth [jra at baylink.com] Sent: Wednesday, December 04, 2013 5:20 PM To: NANOG Subject: Re: Question related to Cellular Data and restrictions.. > Have any of you experienced or been subjected to a "domestic data > roaming policy"? I am a customer of a carrier who advertises > "Unlimited Nationwide 4G data", but limits their customers to 50MB per > month while traveling in an area they do not have coverage (Alaska, > for example). I've never heard of such a policy in regards to a > "Nationwide" plan.. I thought the entire idea of saying nationwide was > to represent you were covering the ENTIRE NATION. I believe you will find that any carrier says "Nationwide means where we have coverage, and unlimited means 'if you're on our towers'." Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From ryan at deadfrog.net Wed Dec 4 22:49:39 2013 From: ryan at deadfrog.net (Ryan Wilkins) Date: Wed, 4 Dec 2013 17:49:39 -0500 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: Message-ID: <76350ED2-8261-4D26-B07C-C1537E67911E@deadfrog.net> Since we're on the subject of T-Mobile USA, who was kind enough to send me a notification via SMS that my 10 megabytes of roaming data allotment was all used up yesterday while driving a long stretch of I-77 between somewhere in mid-Ohio all the way to somewhere about Wytheville, VA, I'm pretty sure the fine print says the unlimited data is only useful while on their network which we all know to be anything but nationwide. Heck, right now I'd just be happy to get some sort of data at all riding the rural stretches of major highways. The upside is my bill dropped considerably by switching from AT&T so it goes both ways. Ryan > On Dec 4, 2013, at 5:05 PM, Warren Bailey wrote: > > All, > > I realize this is not exactly relevant to the usual topics on NANOG, but I thought this list was a decent place to ask a question related to cellular data usage limits. > > Have any of you experienced or been subjected to a "domestic data roaming policy"? I am a customer of a carrier who advertises "Unlimited Nationwide 4G data", but limits their customers to 50MB per month while traveling in an area they do not have coverage (Alaska, for example). I've never heard of such a policy in regards to a "Nationwide" plan.. I thought the entire idea of saying nationwide was to represent you were covering the ENTIRE NATION. > > Happy to receive replies on or off-list. > > Thanks! > //warren > From jared at puck.nether.net Wed Dec 4 22:52:58 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 4 Dec 2013 17:52:58 -0500 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: , <13720621.4060.1386195633357.JavaMail.root@benjamin.baylink.com> Message-ID: Traveling, I usually see better data performance natively on a network vs roaming. In "outlying" areas, such as Maine, Alaska, Hawaii, you're better off using a local telco. More likely to have better coverage. - Jared On Dec 4, 2013, at 5:45 PM, Jack Vizelter wrote: > In my experience, nationwide, typically just means the continental 48 states, for the most part. > > > > ________________________________________ > From: Jay Ashworth [jra at baylink.com] > Sent: Wednesday, December 04, 2013 5:20 PM > To: NANOG > Subject: Re: Question related to Cellular Data and restrictions.. > >> Have any of you experienced or been subjected to a "domestic data >> roaming policy"? I am a customer of a carrier who advertises >> "Unlimited Nationwide 4G data", but limits their customers to 50MB per >> month while traveling in an area they do not have coverage (Alaska, >> for example). I've never heard of such a policy in regards to a >> "Nationwide" plan.. I thought the entire idea of saying nationwide was >> to represent you were covering the ENTIRE NATION. > > I believe you will find that any carrier says "Nationwide means where we > have coverage, and unlimited means 'if you're on our towers'." > > Cheers, > -- jra > -- > Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 > > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > > From henry at AegisInfoSys.com Wed Dec 4 22:58:30 2013 From: henry at AegisInfoSys.com (Henry Yen) Date: Wed, 4 Dec 2013 17:58:30 -0500 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: Message-ID: <20131204225830.GT9526@nntp.AegisInfoSys.com> On Wed, Dec 04, 2013 at 22:18:12PM +0000, Joshua Goldbard wrote: > ... When you send your data > over a partners network it raises your wireless company's cost of > delivering service, in some cases so much so that you become > unprofitable. Some folks over at Ting(.com) suggest that the cost for data roaming is as high as ten times that for voice/SMS roaming, which is why they don't charge extra for the latter, and do not at all provide the former. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) From owen at delong.com Wed Dec 4 23:12:12 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Dec 2013 15:12:12 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> Message-ID: <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> On Dec 4, 2013, at 13:43 , Mikael Abrahamsson wrote: > On Wed, 4 Dec 2013, Owen DeLong wrote: > >> Nope... I look at the consumer side pricing and the fact that cellular providers by and large are NOT losing money. I assume that means that the rest of the math behind the scenes must work somehow. > > Cost != price. > Price from the suppliers perspective absolutely = cost from the consumers perspective. > Also, wireless providers are not delivering the same service as wireline providers. How many gigabytes per month do you usually get for the same money on wireline compared to wireless? Depends on your carrier. From AT&T, I have $29 unlimited and I have definitely cranked down more over that (faster) LTE connection in some months than through my $100+ cable connection. From VZW, I'm paying $100+/month and only getting 10GB over LTE, but I rarely exceed 10GB per month from my (again slower) cable connection. T-Mo is offering unlimited LTE for something like $100/mo IIRC. (Their plans change so often and so quickly right now that it's hard to keep up). Several of the MVNOs offer unlimited for $40/month. >> Yeah, I'm sure there are all kinds of ways that wireline could be made cheaper, etc. However, I'm talking about comparing consumer pricing, not behind the scenes costs as the former is relatively easy to compare on even footing while the later is far to obfuscated by far too many parties to ever have a rational debate. > > Consumer pricing often have nothing to do with cost in a dysfunctional market. It a functional market, cost and price are more closely related. Who cares? I'm talking about cost to the consumer which is absolutely equivalent to price from the supplier since they are one and the same. >> I said nothing about what was possible... I only comment on what is actually happening. If you know how to achieve a functioning market in the US, I'm all ears. In the mean time, dysfunction is all I have available to work with. > > Well, there would have to be a huge amount of changes, and most likely only a portion of them would be implemented and then the changes would be deemed a failure. > > Make it administratively fairly easy to put fiber in the ground. Make municipalities/utilities put in fiber along other infrastructure and make them rent it out at pricepoints that are related to cost. > > If it's possible to rent dark fiber, then you can all of a sudden get competition instead of having a few huge companies dominate the market. > > Access to possibility of renting or installing L1 infrastructure to the block/cabinet is the key. Sure, I'd love to see all of that. I'd also love to see L1 providers prohibited from engaging in L2 and higher level service provision and require L1 providers to accept all comers on an equal price and service basis (fiber from the MMR to any given subscriber costs the same per strand no matter who you are, no matter how many you buy, etc.). However, just like the mythical isotropic radiator, I don't expect any of that to happen any time soon. So, in the meantime, wireless bandwidth cost (from an end-user perspective) is rapidly approaching wireline bandwidth cost as I said before. This is the reality that we currently live in, regardless of how dysfunctional it may be. Owen From surfer at mauigateway.com Thu Dec 5 00:35:04 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 4 Dec 2013 16:35:04 -0800 Subject: Question related to Cellular Data and restrictions.. Message-ID: <20131204163504.7DE49ED4@resin03.mta.everyone.net> --- jared at puck.nether.net wrote: From: Jared Mauch In "outlying" areas, such as Maine, Alaska, Hawaii, you're better off using a local telco. More likely to have better coverage. ---------------------------------------- Not in Hawaii. Hawaiian Telcom used to (still do?) use Sprint's cell network. scott From j at 2600hz.com Thu Dec 5 01:07:46 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Thu, 5 Dec 2013 01:07:46 +0000 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: <20131204225830.GT9526@nntp.AegisInfoSys.com> References: , <20131204225830.GT9526@nntp.AegisInfoSys.com> Message-ID: Ting is an MVNO (just like my company 2600hz) and while it would violate the terms of my NDA to confirm the 10x number I can say that we found it to be prohibitively expensive. One should be aware that, just like in the IP transit world, the small players have different rules than the big kids. It might be prohibitively expensive for us, but it's a different order of magnitude for a carrier like Sprint proper. Hope that helps. Cheers, Joshua P.S. shameless plug: we provide white-label cellular service to operators including full provisioning and call control plus it can be tied back into corporate phone systems (and it's open source!!). Sent from my iPhone On Dec 4, 2013, at 2:59 PM, "Henry Yen" wrote: > On Wed, Dec 04, 2013 at 22:18:12PM +0000, Joshua Goldbard wrote: >> ... When you send your data >> over a partners network it raises your wireless company's cost of >> delivering service, in some cases so much so that you become >> unprofitable. > > Some folks over at Ting(.com) suggest that the cost for data roaming is as > high as ten times that for voice/SMS roaming, which is why they don't charge > extra for the latter, and do not at all provide the former. > > -- > Henry Yen Aegis Information Systems, Inc. > Senior Systems Programmer Hicksville, New York > (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) > > From frnkblk at iname.com Thu Dec 5 05:06:17 2013 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 4 Dec 2013 23:06:17 -0600 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: , <13720621.4060.1386195633357.JavaMail.root@benjamin.baylink.com> Message-ID: <009101cef177$baf7d750$30e785f0$@iname.com> For example, the regional wireless carrier my $DAYJOB has partnered with has rate-limiting in place with its two major roaming partners, to help control roaming costs. And when it uses the word "unlimited" in its marketing materials it means you can access data anywhere where there is access, not "unlimited quantity" or "unlimited speed". Frank -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Wednesday, December 04, 2013 4:53 PM To: Jack Vizelter Cc: NANOG Subject: Re: Question related to Cellular Data and restrictions.. Traveling, I usually see better data performance natively on a network vs roaming. In "outlying" areas, such as Maine, Alaska, Hawaii, you're better off using a local telco. More likely to have better coverage. - Jared On Dec 4, 2013, at 5:45 PM, Jack Vizelter wrote: > In my experience, nationwide, typically just means the continental 48 states, for the most part. > > > > ________________________________________ > From: Jay Ashworth [jra at baylink.com] > Sent: Wednesday, December 04, 2013 5:20 PM > To: NANOG > Subject: Re: Question related to Cellular Data and restrictions.. > >> Have any of you experienced or been subjected to a "domestic data >> roaming policy"? I am a customer of a carrier who advertises >> "Unlimited Nationwide 4G data", but limits their customers to 50MB per >> month while traveling in an area they do not have coverage (Alaska, >> for example). I've never heard of such a policy in regards to a >> "Nationwide" plan.. I thought the entire idea of saying nationwide was >> to represent you were covering the ENTIRE NATION. > > I believe you will find that any carrier says "Nationwide means where we > have coverage, and unlimited means 'if you're on our towers'." > > Cheers, > -- jra > -- > Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 > > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > > From aaron at westfield.ma.edu Tue Dec 3 19:46:58 2013 From: aaron at westfield.ma.edu (Childs, Aaron) Date: Tue, 3 Dec 2013 19:46:58 +0000 Subject: Comcast DNS Issue? Message-ID: <10B60E2061BA5D42B4B91A06763E2C4202B0423A@ex-mbx-1.ads.wsc.ma.edu> Good Afternoon, If there is a Comcast DNS Engineer on the list could you contact me off-list? We are experiencing an odd issue with 75.75.75.75. Thanks, Aaron [Description: Description: Description: logo-email] Aaron Childs, CCNA Associate Director, Networking Information Technology www.westfield.ma.edu/it Please Note: new e-mail address - aaron at westfield.ma.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 8578 bytes Desc: image001.jpg URL: From ss4414 at att.com Wed Dec 4 14:14:07 2013 From: ss4414 at att.com (SMITH, STEVEN B) Date: Wed, 4 Dec 2013 14:14:07 +0000 Subject: Anyone competent within AT&T Uverse? In-Reply-To: <529E9BD4.80502@philkarn.net> References: <529E9BD4.80502@philkarn.net> Message-ID: <8A3BB5AFD8D2104EACEBF48AE96A14F30AAE1B2B@MISOUT7MSGUSR9K.ITServices.sbc.com> Phil if you can send me your full name, address, billing telephone number, contact number, U-Verse BAN if you know it, and what is wrong and for how long, I can escalate this to get immediate attention. Steve -----Original Message----- From: Phil Karn [mailto:karn at philkarn.net] Sent: Tuesday, December 03, 2013 9:05 PM To: NANOG Subject: Anyone competent within AT&T Uverse? Does anyone know anyone within AT&T Uverse who actually knows what TCP/IP is? Maybe even how to read a packet trace? I've been trying to get my static IP block working again since Saturday when they broke it while fixing an unrelated problem. I can't believe how incompetent their tech support has been on this. An hour into a chat with them and I finally realize they don't have a clue what I'm talking about...this is very frustrating... Their premise techs try very hard, but I get the strong impression that the network support people randomly perturb provisioning until it works again, and that's why they keep breaking unrelated things. I'm still wondering if this Internet stuff is ready for prime time... Thanks, Phil From frnkblk at iname.com Thu Dec 5 05:40:16 2013 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 4 Dec 2013 23:40:16 -0600 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: References: <529F2FFF.8070504@ifw-dresden.de> Message-ID: <000701cef17c$7a5a73b0$6f0f5b10$@iname.com> My Cisco IPv6 contacts confirmed that they were made aware of this 12 hours ago and it's being worked on. Frank -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Wednesday, December 04, 2013 8:23 AM To: Henri Wahl Cc: NANOG list Subject: Re: blogs.cisco.com not available via IPv6 I'm seeing it down via IPv6: * Trying 2600:1407:9:295::90... * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.30.0 > Host: www.cisco.com > Accept: */* > < HTTP/1.1 200 OK * Server Apache is not blacklisted * About to connect() to blogs.cisco.com port 80 (#0) * Trying 2001:4800:13c1:10::178... ^C - Jared On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: > Hi, > can anybody from Cisco confirm that blogs.cisco.com > (2001:4800:13c1:10::178) is not available via IPv6? > Regards > > -- > Henri Wahl > > IT Department > Leibniz-Institut fuer Festkoerper- u. > Werkstoffforschung Dresden > > tel: (03 51) 46 59 - 797 > email: h.wahl at ifw-dresden.de > http://www.ifw-dresden.de > > Nagios status monitor Nagstamon: > http://nagstamon.ifw-dresden.de > > DHCPv6 server dhcpy6d: > http://dhcpy6d.ifw-dresden.de > > IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden > VR Dresden Nr. 1369 > Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle > <0x1FBA0942.asc> From swmike at swm.pp.se Thu Dec 5 06:54:48 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 5 Dec 2013 07:54:48 +0100 (CET) Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> Message-ID: On Wed, 4 Dec 2013, Owen DeLong wrote: > Depends on your carrier. From AT&T, I have $29 unlimited and I have definitely cranked down more over that (faster) LTE connection in some months than through my $100+ cable connection. > > From VZW, I'm paying $100+/month and only getting 10GB over LTE, but I rarely exceed 10GB per month from my (again slower) cable connection. > > T-Mo is offering unlimited LTE for something like $100/mo IIRC. (Their plans change so often and so quickly right now that it's hard to keep up). > > Several of the MVNOs offer unlimited for $40/month. Have you tried downloading 500 gigabytes in a month on any of these? I highly doubt any of the LTE solutions are "unlimited" then. > Who cares? I'm talking about cost to the consumer which is absolutely > equivalent to price from the supplier since they are one and the same. Your usage pattern makes wireless feasable. Watching two hours per day of Netflix 1080p on the above connections changes the equation completely. > However, just like the mythical isotropic radiator, I don't expect any > of that to happen any time soon. So, in the meantime, wireless bandwidth > cost (from an end-user perspective) is rapidly approaching wireline > bandwidth cost as I said before. This is the reality that we currently > live in, regardless of how dysfunctional it may be. For your usage pattern, I agree. We have the same deal here, for the same price per month you can have access to ~80 megabit/s LTE, or you can have 100/10 cable. The problem is that with LTE you get 80 gigabytes/month in cap. The cable connection doesn't have a cap. Also, the cable connection actually delivers 100 megabit/s at peak to you, which the LTE connection definitely doesn't (because you share the cell with hundreds of others). What's been happening here is that the price for fixed access has remained approximately the same (10-50 USD per month for 100/10 or 100/100 depending on if you have coax or fiber/CAT6), LTE is in the 20-50 USD range as well for 80 megabit/s, but you get capped and have to pay to increase your monthly cap. Thus, for light consumers this is fine, but for people who actually use their connection for video or bulk data, wireless is very much more expensive (which reflects actual cost of producing the service, wireline has a low marginal cost for bandwidth, there it's establishing the infrastructure that costs, whereas for wireless you have medium-high cost for establishing the infrastructure, but also a medium-high cost to increase the bandwidth in the cell). -- Mikael Abrahamsson email: swmike at swm.pp.se From wbailey at satelliteintelligencegroup.com Thu Dec 5 07:30:06 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 5 Dec 2013 07:30:06 +0000 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: , <20131204225830.GT9526@nntp.AegisInfoSys.com>, Message-ID: Blanket reply.. :) So at what point does unlimited mean unlimited? Roaming agreements have always been two sided. In my case.. I roam on to AT&T's network, the same as AT&T folk roam into tmo when they do not have coverage. At the end of the month the two are reconciled and someone gets paid. If you are selling a service that is making generalized assurances in connectivity (nationwide 4g let netwokr) , you should make a best effort to honor that. It wasn't even a fair amount of bandwidth.. I could deal with a 2gb a month cap or something.. But I am now able to use my unlimited data in 100 countries without incurring additional charges.. Are we going to start saying that international roaming costs are lower than domestic on a regularly used network? I literally feel like I'm taking crazy pills here. Tmo and Att are far from small fish.. And a 50mb per month cap is absolute bullshit. Figure it into your business line.. Or do the honest thing and don't offer the service. How you guys are justifying this is BEYOND me. You can buy a ds1 for several hundred dollars per month.. And unlimited customers get 50 megs a month for data.. You can't even check email over the month on that. I'm not an abusive user.. I don't download or use my cellular data connection for hacked hotspot use.. Not to mention the hotspot I do have with them has 10gb a month nationwide.. So I can use my puck for 10gb..but my phone (on the SAME TOWER) is different? That is like saying sms costs network providers money.. (don't bring up ran gear or smsc costs.. It's not related) Sent from my Mobile Device. -------- Original message -------- From: Joshua Goldbard Date: 12/04/2013 4:10 PM (GMT-09:00) To: Henry Yen Cc: nanog at nanog.org Subject: Re: Question related to Cellular Data and restrictions.. Ting is an MVNO (just like my company 2600hz) and while it would violate the terms of my NDA to confirm the 10x number I can say that we found it to be prohibitively expensive. One should be aware that, just like in the IP transit world, the small players have different rules than the big kids. It might be prohibitively expensive for us, but it's a different order of magnitude for a carrier like Sprint proper. Hope that helps. Cheers, Joshua P.S. shameless plug: we provide white-label cellular service to operators including full provisioning and call control plus it can be tied back into corporate phone systems (and it's open source!!). Sent from my iPhone On Dec 4, 2013, at 2:59 PM, "Henry Yen" wrote: > On Wed, Dec 04, 2013 at 22:18:12PM +0000, Joshua Goldbard wrote: >> ... When you send your data >> over a partners network it raises your wireless company's cost of >> delivering service, in some cases so much so that you become >> unprofitable. > > Some folks over at Ting(.com) suggest that the cost for data roaming is as > high as ten times that for voice/SMS roaming, which is why they don't charge > extra for the latter, and do not at all provide the former. > > -- > Henry Yen Aegis Information Systems, Inc. > Senior Systems Programmer Hicksville, New York > (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) > > From j at 2600hz.com Thu Dec 5 07:59:29 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Thu, 5 Dec 2013 07:59:29 +0000 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: , <20131204225830.GT9526@nntp.AegisInfoSys.com>, , Message-ID: Tier 1 ISPs engage in settlement-free peering. Everyone else pays for transit. I had a giant reply about politics but figured I'd save everyone the reading time. Suffice it to say, the regulatory environment in Wireless is different. It costs more money than their model allows for you to use their service. They are not making the profits they need to and cut the service, it's that simple. Roaming costs money, you're not crazy, this is 2013. A DS1 and a cellular link are completely different. Cheers, Joshua P.S. A puck with 10GB is a ton of data; I'd also wager you couldn't use the full 10GB on a roaming tower without a warning, but I could be wrong. Sent from my iPad On Dec 4, 2013, at 11:30 PM, "Warren Bailey" > wrote: Blanket reply.. :) So at what point does unlimited mean unlimited? Roaming agreements have always been two sided. In my case.. I roam on to AT&T's network, the same as AT&T folk roam into tmo when they do not have coverage. At the end of the month the two are reconciled and someone gets paid. If you are selling a service that is making generalized assurances in connectivity (nationwide 4g let netwokr) , you should make a best effort to honor that. It wasn't even a fair amount of bandwidth.. I could deal with a 2gb a month cap or something.. But I am now able to use my unlimited data in 100 countries without incurring additional charges.. Are we going to start saying that international roaming costs are lower than domestic on a regularly used network? I literally feel like I'm taking crazy pills here. Tmo and Att are far from small fish.. And a 50mb per month cap is absolute bullshit. Figure it into your business line.. Or do the honest thing and don't offer the service. How you guys are justifying this is BEYOND me. You can buy a ds1 for several hundred dollars per month.. And unlimited customers get 50 megs a month for data.. You can't even check email over the month on that. I'm not an abusive user.. I don't download or use my cellular data connection for hacked hotspot use.. Not to mention the hotspot I do have with them has 10gb a month nationwide.. So I can use my puck for 10gb..but my phone (on the SAME TOWER) is different? That is like saying sms costs network providers money.. (don't bring up ran gear or smsc costs.. It's not related) Sent from my Mobile Device. -------- Original message -------- From: Joshua Goldbard > Date: 12/04/2013 4:10 PM (GMT-09:00) To: Henry Yen > Cc: nanog at nanog.org Subject: Re: Question related to Cellular Data and restrictions.. Ting is an MVNO (just like my company 2600hz) and while it would violate the terms of my NDA to confirm the 10x number I can say that we found it to be prohibitively expensive. One should be aware that, just like in the IP transit world, the small players have different rules than the big kids. It might be prohibitively expensive for us, but it's a different order of magnitude for a carrier like Sprint proper. Hope that helps. Cheers, Joshua P.S. shameless plug: we provide white-label cellular service to operators including full provisioning and call control plus it can be tied back into corporate phone systems (and it's open source!!). Sent from my iPhone On Dec 4, 2013, at 2:59 PM, "Henry Yen" > wrote: > On Wed, Dec 04, 2013 at 22:18:12PM +0000, Joshua Goldbard wrote: >> ... When you send your data >> over a partners network it raises your wireless company's cost of >> delivering service, in some cases so much so that you become >> unprofitable. > > Some folks over at Ting(.com) suggest that the cost for data roaming is as > high as ten times that for voice/SMS roaming, which is why they don't charge > extra for the latter, and do not at all provide the former. > > -- > Henry Yen > Aegis Information Systems, Inc. > Senior Systems Programmer Hicksville, New York > (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) > > From ulf at alameda.net Thu Dec 5 12:28:26 2013 From: ulf at alameda.net (Ulf Zimmermann) Date: Thu, 5 Dec 2013 04:28:26 -0800 Subject: Comcast DNS Issue? In-Reply-To: <10B60E2061BA5D42B4B91A06763E2C4202B0423A@ex-mbx-1.ads.wsc.ma.edu> References: <10B60E2061BA5D42B4B91A06763E2C4202B0423A@ex-mbx-1.ads.wsc.ma.edu> Message-ID: Is your issue that it gives out old DNS records? Because I am trying to track something down for an user on Comcast who is still getting the old IP of a VPN concentrator. The DNS records has a TTL of 30 minutes, yet a week later the end user is still getting the old IP. Haven't been able to get him to query 75.75.75.75 and 75.75.75.76 directly to see if he gets the IP from there. On Tue, Dec 3, 2013 at 11:46 AM, Childs, Aaron wrote: > Good Afternoon, > > If there is a Comcast DNS Engineer on the list could you contact me > off-list? We are experiencing an odd issue with 75.75.75.75. > > Thanks, > Aaron > > > [Description: Description: Description: logo-email] > > Aaron Childs, CCNA > Associate Director, Networking > Information Technology > www.westfield.ma.edu/it > Please Note: new e-mail address - aaron at westfield.ma.edu aaron at westfield.ma.edu> > > > > -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From Jason_Livingood at cable.comcast.com Thu Dec 5 13:46:42 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 5 Dec 2013 13:46:42 +0000 Subject: Comcast DNS Issue? In-Reply-To: <10B60E2061BA5D42B4B91A06763E2C4202B0423A@ex-mbx-1.ads.wsc.ma.edu> Message-ID: <10229F86C86EB444898E629583FD4171EDE789B6@PACDCEXMB06.cable.comcast.com> http://dns.comcast.net/index.php/contactus On 12/3/13, 2:46 PM, "Childs, Aaron" wrote: >Good Afternoon, > >If there is a Comcast DNS Engineer on the list could you contact me >off-list? We are experiencing an odd issue with 75.75.75.75. > >Thanks, >Aaron > > >[Description: Description: Description: logo-email] > >Aaron Childs, CCNA >Associate Director, Networking >Information Technology >www.westfield.ma.edu/it >Please Note: new e-mail address - >aaron at westfield.ma.edu > > > From Jason_Livingood at cable.comcast.com Thu Dec 5 13:47:23 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 5 Dec 2013 13:47:23 +0000 Subject: Comcast DNS Issue? In-Reply-To: Message-ID: <10229F86C86EB444898E629583FD4171EDE78A16@PACDCEXMB06.cable.comcast.com> You can check all our caches @ http://dns.comcast.net/index.php/tools/cachecheck On 12/5/13, 7:28 AM, "Ulf Zimmermann" wrote: >Is your issue that it gives out old DNS records? Because I am trying to >track something down for an user on Comcast who is still getting the old >IP >of a VPN concentrator. The DNS records has a TTL of 30 minutes, yet a week >later the end user is still getting the old IP. Haven't been able to get >him to query 75.75.75.75 and 75.75.75.76 directly to see if he gets the IP >from there. > > > >On Tue, Dec 3, 2013 at 11:46 AM, Childs, Aaron >wrote: > >> Good Afternoon, >> >> If there is a Comcast DNS Engineer on the list could you contact me >> off-list? We are experiencing an odd issue with 75.75.75.75. >> >> Thanks, >> Aaron >> >> >> [Description: Description: Description: logo-email] >> >> Aaron Childs, CCNA >> Associate Director, Networking >> Information Technology >> www.westfield.ma.edu/it >> Please Note: new e-mail address - aaron at westfield.ma.edu> aaron at westfield.ma.edu> >> >> >> >> > > >-- > >Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 >You can find my resume at: http://www.Alameda.net/~ulf/resume.html From mark at townsley.net Thu Dec 5 13:55:17 2013 From: mark at townsley.net (Mark Townsley) Date: Thu, 5 Dec 2013 14:55:17 +0100 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: <000701cef17c$7a5a73b0$6f0f5b10$@iname.com> References: <529F2FFF.8070504@ifw-dresden.de> <000701cef17c$7a5a73b0$6f0f5b10$@iname.com> Message-ID: <1C5D32F9-43F1-44ED-87C0-9B81A31A9D81@townsley.net> And if anyone from rackspace is on this list, please feel free to help out as that is where blogs.cisco.com is hosted (it's a wordpress site, not directly under Cisco's control operationally). Thanks, - Mark On Dec 5, 2013, at 6:40 AM, Frank Bulk wrote: > My Cisco IPv6 contacts confirmed that they were made aware of this 12 hours > ago and it's being worked on. > > Frank > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Wednesday, December 04, 2013 8:23 AM > To: Henri Wahl > Cc: NANOG list > Subject: Re: blogs.cisco.com not available via IPv6 > > I'm seeing it down via IPv6: > > * Trying 2600:1407:9:295::90... > * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) >> GET / HTTP/1.1 >> User-Agent: curl/7.30.0 >> Host: www.cisco.com >> Accept: */* >> > < HTTP/1.1 200 OK > * Server Apache is not blacklisted > > > * About to connect() to blogs.cisco.com port 80 (#0) > * Trying 2001:4800:13c1:10::178... > ^C > > - Jared > > On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: > >> Hi, >> can anybody from Cisco confirm that blogs.cisco.com >> (2001:4800:13c1:10::178) is not available via IPv6? >> Regards >> >> -- >> Henri Wahl >> >> IT Department >> Leibniz-Institut fuer Festkoerper- u. >> Werkstoffforschung Dresden >> >> tel: (03 51) 46 59 - 797 >> email: h.wahl at ifw-dresden.de >> http://www.ifw-dresden.de >> >> Nagios status monitor Nagstamon: >> http://nagstamon.ifw-dresden.de >> >> DHCPv6 server dhcpy6d: >> http://dhcpy6d.ifw-dresden.de >> >> IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden >> VR Dresden Nr. 1369 >> Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle >> <0x1FBA0942.asc> > > > > > From cb.list6 at gmail.com Thu Dec 5 14:32:52 2013 From: cb.list6 at gmail.com (cb.list6) Date: Thu, 5 Dec 2013 06:32:52 -0800 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: <20131204225830.GT9526@nntp.AegisInfoSys.com> Message-ID: On Dec 4, 2013 11:31 PM, "Warren Bailey" < wbailey at satelliteintelligencegroup.com> wrote: > > Blanket reply.. :) > > So at what point does unlimited mean unlimited? Roaming agreements have always been two sided. In my case.. I roam on to AT&T's network, the same as AT&T folk roam into tmo when they do not have coverage. At the end of the month the two are reconciled and someone gets paid. If you are selling a service that is making generalized assurances in connectivity (nationwide 4g let netwokr) , you should make a best effort to honor that. It wasn't even a fair amount of bandwidth.. I could deal with a 2gb a month cap or something.. But I am now able to use my unlimited data in 100 countries without incurring additional charges.. Are we going to start saying that international roaming costs are lower than domestic on a regularly used network? > > I literally feel like I'm taking crazy pills here. Tmo and Att are far from small fish.. And a 50mb per month cap is absolute bullshit. Figure it into your business line.. Or do the honest thing and don't offer the service. How you guys are justifying this is BEYOND me. You can buy a ds1 for several hundred dollars per month.. And unlimited customers get 50 megs a month for data.. You can't even check email over the month on that. I'm not an abusive user.. I don't download or use my cellular data connection for hacked hotspot use.. Not to mention the hotspot I do have with them has 10gb a month nationwide.. So I can use my puck for 10gb..but my phone (on the SAME TOWER) is different? > > That is like saying sms costs network providers money.. (don't bring up ran gear or smsc costs.. It's not related) > If you have a beef with tmo, here is the complaint department https://mobile.twitter.com/JohnLegere or you can email him at john.legere at t-mobile.com You can probably just forward this thread Given that tmo now has free (rate limited) intl data roaming, it is a bummer to see domestic roaming is now less well served. I think in belt tightening years limiting domestic roaming saved substantial cost ... since it can be expensive having some users living on roamed networks CB > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Joshua Goldbard > Date: 12/04/2013 4:10 PM (GMT-09:00) > To: Henry Yen > Cc: nanog at nanog.org > Subject: Re: Question related to Cellular Data and restrictions.. > > > Ting is an MVNO (just like my company 2600hz) and while it would violate the terms of my NDA to confirm the 10x number I can say that we found it to be prohibitively expensive. > > One should be aware that, just like in the IP transit world, the small players have different rules than the big kids. It might be prohibitively expensive for us, but it's a different order of magnitude for a carrier like Sprint proper. > > Hope that helps. > > Cheers, > Joshua > > P.S. shameless plug: we provide white-label cellular service to operators including full provisioning and call control plus it can be tied back into corporate phone systems (and it's open source!!). > > Sent from my iPhone > > On Dec 4, 2013, at 2:59 PM, "Henry Yen" wrote: > > > On Wed, Dec 04, 2013 at 22:18:12PM +0000, Joshua Goldbard wrote: > >> ... When you send your data > >> over a partners network it raises your wireless company's cost of > >> delivering service, in some cases so much so that you become > >> unprofitable. > > > > Some folks over at Ting(.com) suggest that the cost for data roaming is as > > high as ten times that for voice/SMS roaming, which is why they don't charge > > extra for the latter, and do not at all provide the former. > > > > -- > > Henry Yen Aegis Information Systems, Inc. > > Senior Systems Programmer Hicksville, New York > > (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) > > > > > From aaron at westfield.ma.edu Thu Dec 5 16:02:29 2013 From: aaron at westfield.ma.edu (Childs, Aaron) Date: Thu, 5 Dec 2013 16:02:29 +0000 Subject: Comcast DNS Issue? In-Reply-To: References: <10B60E2061BA5D42B4B91A06763E2C4202B0423A@ex-mbx-1.ads.wsc.ma.edu> Message-ID: <10B60E2061BA5D42B4B91A06763E2C4202B081EA@ex-mbx-1.ads.wsc.ma.edu> Hi Ulf, Our issue was that 75.75.75.75 was not responding to queries at all and for some reason clients weren't getting redirected to 75.75.76.76. For us all is well now, my email was stuck in Nanog Approval land for a couple of days so I couldn't give an update to the list until today. Have a good day, Aaron [Description: Description: Description: logo-email] Aaron Childs, CCNA Associate Director, Networking Information Technology www.westfield.ma.edu/it Please Note: new e-mail address - aaron at westfield.ma.edu From: Ulf Zimmermann [mailto:ulf at alameda.net] Sent: Thursday, December 05, 2013 7:28 AM To: Childs, Aaron Cc: nanog at nanog.org Subject: Re: Comcast DNS Issue? Is your issue that it gives out old DNS records? Because I am trying to track something down for an user on Comcast who is still getting the old IP of a VPN concentrator. The DNS records has a TTL of 30 minutes, yet a week later the end user is still getting the old IP. Haven't been able to get him to query 75.75.75.75 and 75.75.75.76 directly to see if he gets the IP from there. On Tue, Dec 3, 2013 at 11:46 AM, Childs, Aaron > wrote: Good Afternoon, If there is a Comcast DNS Engineer on the list could you contact me off-list? We are experiencing an odd issue with 75.75.75.75. Thanks, Aaron [Description: Description: Description: logo-email] Aaron Childs, CCNA Associate Director, Networking Information Technology www.westfield.ma.edu/it Please Note: new e-mail address - aaron at westfield.ma.edu> -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 8578 bytes Desc: image001.jpg URL: From morrowc.lists at gmail.com Thu Dec 5 16:08:59 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 Dec 2013 11:08:59 -0500 Subject: Comcast DNS Issue? In-Reply-To: <10B60E2061BA5D42B4B91A06763E2C4202B081EA@ex-mbx-1.ads.wsc.ma.edu> References: <10B60E2061BA5D42B4B91A06763E2C4202B0423A@ex-mbx-1.ads.wsc.ma.edu> <10B60E2061BA5D42B4B91A06763E2C4202B081EA@ex-mbx-1.ads.wsc.ma.edu> Message-ID: On Thu, Dec 5, 2013 at 11:02 AM, Childs, Aaron wrote: > Our issue was that 75.75.75.75 was not responding to queries at all and for some reason clients weren't getting redirected to 75.75.76.76. did the clients not have 75.75.76.76 in their resolv.conf (or equivalent) as the second nameserver entry? that 'redirect' is the host-os knowing it has more than one 'nameserver' to ask questions of, right? so without the config... you are SOL. From aaron at westfield.ma.edu Thu Dec 5 16:09:57 2013 From: aaron at westfield.ma.edu (Childs, Aaron) Date: Thu, 5 Dec 2013 16:09:57 +0000 Subject: Comcast DNS Issue? In-Reply-To: References: <10B60E2061BA5D42B4B91A06763E2C4202B0423A@ex-mbx-1.ads.wsc.ma.edu> <10B60E2061BA5D42B4B91A06763E2C4202B081EA@ex-mbx-1.ads.wsc.ma.edu> Message-ID: <10B60E2061BA5D42B4B91A06763E2C4202B0826D@ex-mbx-1.ads.wsc.ma.edu> Yes clients had both IPs in their relative DNS configuration settings. Aaron Childs, CCNA Associate Director, Networking Information Technology www.westfield.ma.edu/it Please Note: new e-mail address - aaron at westfield.ma.edu -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Thursday, December 05, 2013 11:09 AM To: Childs, Aaron Cc: Ulf Zimmermann; nanog at nanog.org Subject: Re: Comcast DNS Issue? On Thu, Dec 5, 2013 at 11:02 AM, Childs, Aaron wrote: > Our issue was that 75.75.75.75 was not responding to queries at all and for some reason clients weren't getting redirected to 75.75.76.76. did the clients not have 75.75.76.76 in their resolv.conf (or equivalent) as the second nameserver entry? that 'redirect' is the host-os knowing it has more than one 'nameserver' to ask questions of, right? so without the config... you are SOL. From wbailey at satelliteintelligencegroup.com Thu Dec 5 17:36:42 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 5 Dec 2013 17:36:42 +0000 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: <20131204225830.GT9526@nntp.AegisInfoSys.com> , Message-ID: I've been talking to their executive officer after doing that exact thing. 15 years ago roaming was very expensive.. But when you are selling something using terminology like "free" or "unlimited", I believe you should be extremely careful. I don't know how or who implemented this policy.. But they have been claiming to rock AT&T with this "actual nationwide" and this "uncarrier" talk. If you claim to be unlike your competitors.. At least make an attempt to be.. NOT like your competition. I was floored seeing the Nanog tribe reply with "it was a business decision over cost".. It's 2013 and nearly 14...get your lives together. Make these people who give you a paycheck accountable. Sent from my Mobile Device. -------- Original message -------- From: "cb.list6" Date: 12/05/2013 5:33 AM (GMT-09:00) To: Warren Bailey Cc: Henry Yen ,Joshua Goldbard ,nanog at nanog.org Subject: Re: Question related to Cellular Data and restrictions.. On Dec 4, 2013 11:31 PM, "Warren Bailey" > wrote: > > Blanket reply.. :) > > So at what point does unlimited mean unlimited? Roaming agreements have always been two sided. In my case.. I roam on to AT&T's network, the same as AT&T folk roam into tmo when they do not have coverage. At the end of the month the two are reconciled and someone gets paid. If you are selling a service that is making generalized assurances in connectivity (nationwide 4g let netwokr) , you should make a best effort to honor that. It wasn't even a fair amount of bandwidth.. I could deal with a 2gb a month cap or something.. But I am now able to use my unlimited data in 100 countries without incurring additional charges.. Are we going to start saying that international roaming costs are lower than domestic on a regularly used network? > > I literally feel like I'm taking crazy pills here. Tmo and Att are far from small fish.. And a 50mb per month cap is absolute bullshit. Figure it into your business line.. Or do the honest thing and don't offer the service. How you guys are justifying this is BEYOND me. You can buy a ds1 for several hundred dollars per month.. And unlimited customers get 50 megs a month for data.. You can't even check email over the month on that. I'm not an abusive user.. I don't download or use my cellular data connection for hacked hotspot use.. Not to mention the hotspot I do have with them has 10gb a month nationwide.. So I can use my puck for 10gb..but my phone (on the SAME TOWER) is different? > > That is like saying sms costs network providers money.. (don't bring up ran gear or smsc costs.. It's not related) > If you have a beef with tmo, here is the complaint department https://mobile.twitter.com/JohnLegere or you can email him at john.legere at t-mobile.com You can probably just forward this thread Given that tmo now has free (rate limited) intl data roaming, it is a bummer to see domestic roaming is now less well served. I think in belt tightening years limiting domestic roaming saved substantial cost ... since it can be expensive having some users living on roamed networks CB > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Joshua Goldbard > > Date: 12/04/2013 4:10 PM (GMT-09:00) > To: Henry Yen > Cc: nanog at nanog.org > Subject: Re: Question related to Cellular Data and restrictions.. > > > Ting is an MVNO (just like my company 2600hz) and while it would violate the terms of my NDA to confirm the 10x number I can say that we found it to be prohibitively expensive. > > One should be aware that, just like in the IP transit world, the small players have different rules than the big kids. It might be prohibitively expensive for us, but it's a different order of magnitude for a carrier like Sprint proper. > > Hope that helps. > > Cheers, > Joshua > > P.S. shameless plug: we provide white-label cellular service to operators including full provisioning and call control plus it can be tied back into corporate phone systems (and it's open source!!). > > Sent from my iPhone > > On Dec 4, 2013, at 2:59 PM, "Henry Yen" wrote: > > > On Wed, Dec 04, 2013 at 22:18:12PM +0000, Joshua Goldbard wrote: > >> ... When you send your data > >> over a partners network it raises your wireless company's cost of > >> delivering service, in some cases so much so that you become > >> unprofitable. > > > > Some folks over at Ting(.com) suggest that the cost for data roaming is as > > high as ten times that for voice/SMS roaming, which is why they don't charge > > extra for the latter, and do not at all provide the former. > > > > -- > > Henry Yen Aegis Information Systems, Inc. > > Senior Systems Programmer Hicksville, New York > > (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) > > > > > From j at 2600hz.com Thu Dec 5 18:23:07 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Thu, 5 Dec 2013 18:23:07 +0000 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: <20131204225830.GT9526@nntp.AegisInfoSys.com> , , Message-ID: <58AFA133-ECEF-49D1-AB27-681314DF758F@2600hz.com> You are misunderstanding the political reality and are instead making impermissible technical inferences. Is moving bits between networks hard or expensive? No. Is moving bits between asymmetric power relationships trivial? No. When you think about how much roaming costs, you're thinking of the settlement free model which is not how cellular roaming works. Cellular roaming is a fiefdom. There is no common carriage. No one is obligated to carry anyone else's traffic. Therefore roaming is artificially more expensive. It is political not technical. Bear in mind, you are preaching to the converted. You don't get much more hippie-status in the telecom world than writing open-source infrastructure (which is what my company does). I know where you're coming from and I'm trying to explain why the networks are not behaving in an optimally efficient manner: because it isn't profitable. We can sit here and rail about how bad TMobile is on a mailing list but the behavior they are displaying is entirely rational given the rules of the game. You asked how someone could claim nationwide network without owning all of the assets, I answered you and you don't like the answer. Sorry. If you don't like it, write Tom Wheeler or put in a false advertising claim, but you should understand that TMobile's behavior is politically rational. Cheers, Joshua Sent from my iPhone On Dec 5, 2013, at 9:36 AM, "Warren Bailey" > wrote: I've been talking to their executive officer after doing that exact thing. 15 years ago roaming was very expensive.. But when you are selling something using terminology like "free" or "unlimited", I believe you should be extremely careful. I don't know how or who implemented this policy.. But they have been claiming to rock AT&T with this "actual nationwide" and this "uncarrier" talk. If you claim to be unlike your competitors.. At least make an attempt to be.. NOT like your competition. I was floored seeing the Nanog tribe reply with "it was a business decision over cost".. It's 2013 and nearly 14...get your lives together. Make these people who give you a paycheck accountable. Sent from my Mobile Device. -------- Original message -------- From: "cb.list6" > Date: 12/05/2013 5:33 AM (GMT-09:00) To: Warren Bailey > Cc: Henry Yen >,Joshua Goldbard >,nanog at nanog.org Subject: Re: Question related to Cellular Data and restrictions.. On Dec 4, 2013 11:31 PM, "Warren Bailey" > wrote: > > Blanket reply.. :) > > So at what point does unlimited mean unlimited? Roaming agreements have always been two sided. In my case.. I roam on to AT&T's network, the same as AT&T folk roam into tmo when they do not have coverage. At the end of the month the two are reconciled and someone gets paid. If you are selling a service that is making generalized assurances in connectivity (nationwide 4g let netwokr) , you should make a best effort to honor that. It wasn't even a fair amount of bandwidth.. I could deal with a 2gb a month cap or something.. But I am now able to use my unlimited data in 100 countries without incurring additional charges.. Are we going to start saying that international roaming costs are lower than domestic on a regularly used network? > > I literally feel like I'm taking crazy pills here. Tmo and Att are far from small fish.. And a 50mb per month cap is absolute bullshit. Figure it into your business line.. Or do the honest thing and don't offer the service. How you guys are justifying this is BEYOND me. You can buy a ds1 for several hundred dollars per month.. And unlimited customers get 50 megs a month for data.. You can't even check email over the month on that. I'm not an abusive user.. I don't download or use my cellular data connection for hacked hotspot use.. Not to mention the hotspot I do have with them has 10gb a month nationwide.. So I can use my puck for 10gb..but my phone (on the SAME TOWER) is different? > > That is like saying sms costs network providers money.. (don't bring up ran gear or smsc costs.. It's not related) > If you have a beef with tmo, here is the complaint department https://mobile.twitter.com/JohnLegere or you can email him at john.legere at t-mobile.com You can probably just forward this thread Given that tmo now has free (rate limited) intl data roaming, it is a bummer to see domestic roaming is now less well served. I think in belt tightening years limiting domestic roaming saved substantial cost ... since it can be expensive having some users living on roamed networks CB > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Joshua Goldbard > > Date: 12/04/2013 4:10 PM (GMT-09:00) > To: Henry Yen > > Cc: nanog at nanog.org > Subject: Re: Question related to Cellular Data and restrictions.. > > > Ting is an MVNO (just like my company 2600hz) and while it would violate the terms of my NDA to confirm the 10x number I can say that we found it to be prohibitively expensive. > > One should be aware that, just like in the IP transit world, the small players have different rules than the big kids. It might be prohibitively expensive for us, but it's a different order of magnitude for a carrier like Sprint proper. > > Hope that helps. > > Cheers, > Joshua > > P.S. shameless plug: we provide white-label cellular service to operators including full provisioning and call control plus it can be tied back into corporate phone systems (and it's open source!!). > > Sent from my iPhone > > On Dec 4, 2013, at 2:59 PM, "Henry Yen" > wrote: > > > On Wed, Dec 04, 2013 at 22:18:12PM +0000, Joshua Goldbard wrote: > >> ... When you send your data > >> over a partners network it raises your wireless company's cost of > >> delivering service, in some cases so much so that you become > >> unprofitable. > > > > Some folks over at Ting(.com) suggest that the cost for data roaming is as > > high as ten times that for voice/SMS roaming, which is why they don't charge > > extra for the latter, and do not at all provide the former. > > > > -- > > Henry Yen > Aegis Information Systems, Inc. > > Senior Systems Programmer Hicksville, New York > > (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) > > > > > From surfer at mauigateway.com Thu Dec 5 19:52:54 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 5 Dec 2013 11:52:54 -0800 Subject: list scraping by QualiSystems Message-ID: <20131205115254.7DE4DF1A@resin03.mta.everyone.net> :: QualiSystems team met you during the 2011 Nanog :: Conference in Denver. No you didn't. This is completely false. In the 15+ years I have been on the NANOG mailing list I have *never* been able to afford to attend a NANOG conference because it's really expensive from Hawaii. So, in addition to spamming, you're not telling the truth. Warning to others reading. Don't scrape the list for email addresses and if you get caught DON'T TELL FALSE THINGS to folks! :-( scott --- zohar.k at qualisystems.com wrote: From: Zohar Karni To: "surfer at mauigateway.com" CC: Revital Rabany-Levi Subject: RE: Live Webinar: The Mandate for a Highly Automated IT Function Date: Thu, 5 Dec 2013 09:42:32 +0000 Dear Mr. Weeks, QualiSystems team met you during the 2011 Nanog Conference in Denver. If you no longer wish to get updates from QualiSystems please let me know. Sorry if we disturbed you, Zohar -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Thursday, December 05, 2013 2:29 AM To: Zohar Karni Subject: Re: Live Webinar: The Mandate for a Highly Automated IT Function Where did you get my email address from? --- Zohar.k at qualisystems.com wrote: From: "Zohar karni" To: "Scott Weeks" Subject: Live Webinar: The Mandate for a Highly Automated IT Function Date: Wed, 04 Dec 2013 23:07:24 +0000 LIVE WEBINAR The Mandate for a Highly Automated IT Function Dear Scott Weeks, QualiSystems invites you to attend a Web seminar: The Mandate for a Highly Automated IT Function Distinguished industry analyst Jim Metzler will deliver the first in a five part webinar series that describes the journey that IT organizations must take in order to go from the traditional highly manual, hardware centric IT operational model to an operational model that is highly automated and software centric. This webinar will kick off the series by delving into the limitations of the current IT operational model and will discuss some of the factors that are forcing IT organizations to adopt a new operational model. Presenter: Dr. Jim Metzler Ashton, Metzler & Associates JOIN US Tuesday, December 17, 2013 9:00 am Pacific Daylight Time (San Francisco) 11:00 pm Central Daylight Time (Chicago) 12:00 pm Eastern Daylight Time (New York) ( https://webex.rsvp1.com/s18c7fdYV8p5 ) Looking forward to meeting you online, The QualiSystems Team ( http://www.qualisystems.rsvp1.com/s1897fdYV8p9 ) ( https://twitter.rsvp1.com/s1b07fdYV8pe ) ( http://www.facebook.rsvp1.com/s174fedYV8pk ) ( http://www.linkedin.rsvp1.com/s1b6bfdYV8pl ) ( https://google.rsvp1.com/s17fbedYV8pp ) ( http://www.youtube.rsvp1.com/s1be3fdYV8pr ) www.qualisystems.com ( http://www.qualisystems.rsvp1.com/s17efedYV8ps ) | Contact Us ( http://www.qualisystems.rsvp1.com/s17c7edYV8pu ) This e-mail was sent to surfer at mauigateway.com by Zohar.k at qualisystems.com. Qualisystems, Inc, 20 Ha’Carmel St., Ganey-Tikva, 55900 If you no longer wish to receive commercial e-mail messages from Zohar.k at qualisystems.com, please select the following link: Remove ( https://salesgenius.rsvp1.com/s16d7edYV8pI ). From jstuppi at cisco.com Thu Dec 5 21:54:59 2013 From: jstuppi at cisco.com (John Stuppi (jstuppi)) Date: Thu, 5 Dec 2013 21:54:59 +0000 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: References: <529F2FFF.8070504@ifw-dresden.de> Message-ID: <3FA32E339980EB4BBB4935C00A6A8F29218C3D9A@xmb-aln-x09.cisco.com> Thanks folks. Blogs.cisco.com should be back up now for both IPv4 and v6. Thanks, John "We can't help everyone, but everyone can help someone." John Stuppi, CISSP Technical Leader Strategic Security Research jstuppi at cisco.com Phone: +1 732 516 5994 Mobile: 732 319 3886 CCIE, Security - 11154 Cisco Systems Mail Stop INJ01/2/ 111 Wood Avenue South Iselin, New Jersey 08830 United States Cisco.com Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Wednesday, December 04, 2013 9:23 AM To: Henri Wahl Cc: NANOG list Subject: Re: blogs.cisco.com not available via IPv6 I'm seeing it down via IPv6: * Trying 2600:1407:9:295::90... * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.30.0 > Host: www.cisco.com > Accept: */* > < HTTP/1.1 200 OK * Server Apache is not blacklisted * About to connect() to blogs.cisco.com port 80 (#0) * Trying 2001:4800:13c1:10::178... ^C - Jared On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: > Hi, > can anybody from Cisco confirm that blogs.cisco.com > (2001:4800:13c1:10::178) is not available via IPv6? > Regards > > -- > Henri Wahl > > IT Department > Leibniz-Institut fuer Festkoerper- u. > Werkstoffforschung Dresden > > tel: (03 51) 46 59 - 797 > email: h.wahl at ifw-dresden.de > http://www.ifw-dresden.de > > Nagios status monitor Nagstamon: > http://nagstamon.ifw-dresden.de > > DHCPv6 server dhcpy6d: > http://dhcpy6d.ifw-dresden.de > > IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. > 1369 > Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle > <0x1FBA0942.asc> From owen at delong.com Thu Dec 5 22:00:28 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Dec 2013 14:00:28 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> Message-ID: <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> On Dec 4, 2013, at 10:54 PM, Mikael Abrahamsson wrote: > On Wed, 4 Dec 2013, Owen DeLong wrote: > >> Depends on your carrier. From AT&T, I have $29 unlimited and I have definitely cranked down more over that (faster) LTE connection in some months than through my $100+ cable connection. >> >> From VZW, I'm paying $100+/month and only getting 10GB over LTE, but I rarely exceed 10GB per month from my (again slower) cable connection. >> >> T-Mo is offering unlimited LTE for something like $100/mo IIRC. (Their plans change so often and so quickly right now that it's hard to keep up). >> >> Several of the MVNOs offer unlimited for $40/month. > > Have you tried downloading 500 gigabytes in a month on any of these? I highly doubt any of the LTE solutions are ?unlimited" then. > Nothing is completely unlimited because you hit the bandwidth limitations if you try hard enough. I generally get around 40-50 Mbps over LTE. Downloading 500Gig at that rate would be roughly 1/2 of the maximum possible throughput for the entire month. Of course, I haven?t tried to do that because I can?t really think what I would do with the data. However, there have been months where I have done over 200GB on the AT&T connection. For my purposes, that?s close enough to unlimited. YMMV. Choose the plan that works best for you. >> Who cares? I'm talking about cost to the consumer which is absolutely equivalent to price from the supplier since they are one and the same. > > Your usage pattern makes wireless feasable. Watching two hours per day of Netflix 1080p on the above connections changes the equation completely. > I regularly watch 2 hours of netflix per day on my iPad, so in addition to some other bandwidth-intense things that I do (like downloading a complete set of aviation charts for the entire (not just continental) US, IFR and VFR) every 14-28 days, miscellaneous video surfing, and various other usage which is lower bandwidth (most of the time) plus an average of about 5GB per month of App updates most of which are downloaded via the LTE network, I would say my usage pattern falls exactly into the ?changes the equation completely? category you just mentioned. >> However, just like the mythical isotropic radiator, I don't expect any of that to happen any time soon. So, in the meantime, wireless bandwidth cost (from an end-user perspective) is rapidly approaching wireline bandwidth cost as I said before. This is the reality that we currently live in, regardless of how dysfunctional it may be. > > For your usage pattern, I agree. > Except you just cited something that falls a little short of my usage pattern as an example of what doesn?t work, so, color me confused. > We have the same deal here, for the same price per month you can have access to ~80 megabit/s LTE, or you can have 100/10 cable. The problem is that with LTE you get 80 gigabytes/month in cap. The cable connection doesn't have a cap. Also, the cable connection actually delivers 100 megabit/s at peak to you, which the LTE connection definitely doesn?t (because you share the cell with hundreds of others). If AT&T has capped me, then, I haven?t managed to hit the cap as yet. Admittedly, the connection isn?t always as reliable as $CABLECO, but when it works, it tends to work at full speed and it does work the vast majority of the time. OTOH, I have routinely run into circumstances where $CABLECO is not delivering what they promised in terms of throughput. > What's been happening here is that the price for fixed access has remained approximately the same (10-50 USD per month for 100/10 or 100/100 depending on if you have coax or fiber/CAT6), LTE is in the 20-50 USD range as well for 80 megabit/s, but you get capped and have to pay to increase your monthly cap. Thus, for light consumers this is fine, but for people who actually use their connection for video or bulk data, wireless is very much more expensive (which reflects actual cost of producing the service, wireline has a low marginal cost for bandwidth, there it?s establishing the infrastructure that costs, whereas for wireless you have medium-high cost for establishing the infrastructure, but also a medium-high cost to increase the bandwidth in the cell). Even if you double the price of LTE today, that?s still less than 1/10th of the cost of equivalent bandwidth in 3G wireless. My argument wasn?t that they are equal today, but, that the price ramp on wireless is APPROACHING parity. The fact that you are arguing not that the price won?t reach parity, but, that the extent to which it has done so is limited kind of makes my point in that regard. Owen From gjshep at gmail.com Thu Dec 5 22:14:28 2013 From: gjshep at gmail.com (Greg Shepherd) Date: Thu, 5 Dec 2013 14:14:28 -0800 Subject: CenturyLink Engineering contact? Message-ID: Is there someone on the list in CenturyLink Engineering involved in the pacific north west? Please contact me off list. Thanks, Greg From swmike at swm.pp.se Thu Dec 5 23:05:51 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 6 Dec 2013 00:05:51 +0100 (CET) Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> Message-ID: On Thu, 5 Dec 2013, Owen DeLong wrote: > I generally get around 40-50 Mbps over LTE. > > Downloading 500Gig at that rate would be roughly 1/2 of the maximum possible throughput for the entire month. Nope. 350 gigabyte in a month is an average of 1 megabit/s over the entire month. > won?t reach parity, but, that the extent to which it has done so is > limited kind of makes my point in that regard. How many 10 megabit/s (actual traffic) users can there be per cell at the same time? 5? 10? How many people in your area share the cell? This just won't work in the long run considering the cost of the base stations. In order for this to scale, the bases much become much smaller and cheaper and serve fewer people, and then we're down to Wifi APs that we already have, but they still need fiber/CAT6 to them. -- Mikael Abrahamsson email: swmike at swm.pp.se From karn at philkarn.net Fri Dec 6 00:35:40 2013 From: karn at philkarn.net (Phil Karn) Date: Thu, 05 Dec 2013 16:35:40 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> Message-ID: <52A11BDC.1010307@philkarn.net> On 12/05/2013 02:00 PM, Owen DeLong wrote: > If AT&T has capped me, then, I haven?t managed to hit the cap as yet. > Admittedly, the connection isn?t always as reliable as $CABLECO, but > when it works, it tends to work at full speed and it does work the > vast majority of the time. AT&T threatened to cap U-verse at 250 GB/mo several years ago, but they never seem to have followed through. It's probably about the only way that their incompetence is actually in the public interest. Monthly caps -- and even peak speed limits -- are a very poor idea in general because they don't take system conditions into account. A torrent that runs at night penalizes you just as much as one run at prime time. Actually more, since you probably get greater throughput at off-peak times and therefore hit your cap faster. If one *must* charge for usage on a shared network, the right thing is to base the monthly fee on *guaranteed* bandwidth because that's what actually drives costs. If more is available because others aren't using their guarantees, fine, you can have it for free. But it's not guaranteed. And you don't get a refund for not using your guarantee because the equipment still had to be allocated for you. Of course the real solution to nearly every problem with local broadband access is the same: meaningful competition. About the only way this could happen is for the municipality to install, own and maintain the fiber plant and lease it to any and all commercial service providers on a non-discriminatory and non-exclusive basis. Naturally this will never happen in the United States because the incumbents will scream "socialism!" at the top of their lungs and race to the state houses to outlaw it. Never mind that this is exactly how we've handled roads for centuries. --Phil From roganschlassa at gmail.com Fri Dec 6 01:39:44 2013 From: roganschlassa at gmail.com (Rogan Schlassa) Date: Thu, 5 Dec 2013 19:39:44 -0600 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: <3FA32E339980EB4BBB4935C00A6A8F29218C3D9A@xmb-aln-x09.cisco.com> References: <529F2FFF.8070504@ifw-dresden.de> <3FA32E339980EB4BBB4935C00A6A8F29218C3D9A@xmb-aln-x09.cisco.com> Message-ID: Please dont reply back with such legal disclaimers. It is basically SPAM and of course nonsense. The thought that you can send a email and force your companies terms on us is rediculous. If CISCO forces that in your sig then for one tell them to fuck off and two use a different email. On Dec 5, 2013 3:56 PM, "John Stuppi (jstuppi)" wrote: > Thanks folks. Blogs.cisco.com should be back up now for both IPv4 and v6. > > Thanks, > John > > "We can't help everyone, but everyone can help someone." > > > > > John Stuppi, CISSP > Technical Leader > Strategic Security Research > jstuppi at cisco.com > Phone: +1 732 516 5994 > Mobile: 732 319 3886 > > CCIE, Security - 11154 > Cisco Systems > Mail Stop INJ01/2/ > 111 Wood Avenue South > Iselin, New Jersey 08830 > United States > Cisco.com > > > > Think before you print. > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender by > reply email and delete all copies of this message. > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Wednesday, December 04, 2013 9:23 AM > To: Henri Wahl > Cc: NANOG list > Subject: Re: blogs.cisco.com not available via IPv6 > > I'm seeing it down via IPv6: > > * Trying 2600:1407:9:295::90... > * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) > > GET / HTTP/1.1 > > User-Agent: curl/7.30.0 > > Host: www.cisco.com > > Accept: */* > > > < HTTP/1.1 200 OK > * Server Apache is not blacklisted > > > * About to connect() to blogs.cisco.com port 80 (#0) > * Trying 2001:4800:13c1:10::178... > ^C > > - Jared > > On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: > > > Hi, > > can anybody from Cisco confirm that blogs.cisco.com > > (2001:4800:13c1:10::178) is not available via IPv6? > > Regards > > > > -- > > Henri Wahl > > > > IT Department > > Leibniz-Institut fuer Festkoerper- u. > > Werkstoffforschung Dresden > > > > tel: (03 51) 46 59 - 797 > > email: h.wahl at ifw-dresden.de > > http://www.ifw-dresden.de > > > > Nagios status monitor Nagstamon: > > http://nagstamon.ifw-dresden.de > > > > DHCPv6 server dhcpy6d: > > http://dhcpy6d.ifw-dresden.de > > > > IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. > > 1369 > > Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle > > <0x1FBA0942.asc> > > > > From richard at pedantictheory.com Fri Dec 6 01:52:02 2013 From: richard at pedantictheory.com (Richard Porter) Date: Thu, 5 Dec 2013 18:52:02 -0700 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: References: <529F2FFF.8070504@ifw-dresden.de> <3FA32E339980EB4BBB4935C00A6A8F29218C3D9A@xmb-aln-x09.cisco.com> Message-ID: *Sarcasm* but lawyers seem to think it is REALLY important to add that load to email servers, backup servers and storage :). I wonder how much extra storage those simple extra bits/bytes have taken over the years? ~Richard On Dec 5, 2013, at 6:39 PM, Rogan Schlassa wrote: > Please dont reply back with such legal disclaimers. It is basically SPAM > and of course nonsense. > > The thought that you can send a email and force your companies terms on us > is rediculous. > > If CISCO forces that in your sig then for one tell them to fuck off and two > use a different email. > On Dec 5, 2013 3:56 PM, "John Stuppi (jstuppi)" wrote: > >> Thanks folks. Blogs.cisco.com should be back up now for both IPv4 and v6. >> >> Thanks, >> John >> >> "We can't help everyone, but everyone can help someone." >> >> >> >> >> John Stuppi, CISSP >> Technical Leader >> Strategic Security Research >> jstuppi at cisco.com >> Phone: +1 732 516 5994 >> Mobile: 732 319 3886 >> >> CCIE, Security - 11154 >> Cisco Systems >> Mail Stop INJ01/2/ >> 111 Wood Avenue South >> Iselin, New Jersey 08830 >> United States >> Cisco.com >> >> >> >> Think before you print. >> This email may contain confidential and privileged material for the sole >> use of the intended recipient. Any review, use, distribution or disclosure >> by others is strictly prohibited. If you are not the intended recipient (or >> authorized to receive for the recipient), please contact the sender by >> reply email and delete all copies of this message. >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> >> >> -----Original Message----- >> From: Jared Mauch [mailto:jared at puck.nether.net] >> Sent: Wednesday, December 04, 2013 9:23 AM >> To: Henri Wahl >> Cc: NANOG list >> Subject: Re: blogs.cisco.com not available via IPv6 >> >> I'm seeing it down via IPv6: >> >> * Trying 2600:1407:9:295::90... >> * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) >>> GET / HTTP/1.1 >>> User-Agent: curl/7.30.0 >>> Host: www.cisco.com >>> Accept: */* >>> >> < HTTP/1.1 200 OK >> * Server Apache is not blacklisted >> >> >> * About to connect() to blogs.cisco.com port 80 (#0) >> * Trying 2001:4800:13c1:10::178... >> ^C >> >> - Jared >> >> On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: >> >>> Hi, >>> can anybody from Cisco confirm that blogs.cisco.com >>> (2001:4800:13c1:10::178) is not available via IPv6? >>> Regards >>> >>> -- >>> Henri Wahl >>> >>> IT Department >>> Leibniz-Institut fuer Festkoerper- u. >>> Werkstoffforschung Dresden >>> >>> tel: (03 51) 46 59 - 797 >>> email: h.wahl at ifw-dresden.de >>> http://www.ifw-dresden.de >>> >>> Nagios status monitor Nagstamon: >>> http://nagstamon.ifw-dresden.de >>> >>> DHCPv6 server dhcpy6d: >>> http://dhcpy6d.ifw-dresden.de >>> >>> IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. >>> 1369 >>> Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle >>> <0x1FBA0942.asc> >> >> >> >> -------------- 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 randy at psg.com Fri Dec 6 05:33:01 2013 From: randy at psg.com (Randy Bush) Date: Fri, 06 Dec 2013 06:33:01 +0100 Subject: UCS + MegaRAID 9261 + ESXI clue Message-ID: i am having scary logging from ESXI off a UCS-210-M2 with a MagaRAID 9261. if you have clue in this space, please contact me off list. thanks. [ esxi's lack of transparency to the hardware makes me crazy. i plan to migrate to kvm when i have spare time, ha ha, and a spare box to hold the vms while switching. ] randy From iam at kjro.se Thu Dec 5 19:59:39 2013 From: iam at kjro.se (Kelly John Rose) Date: Thu, 05 Dec 2013 14:59:39 -0500 Subject: list scraping by QualiSystems In-Reply-To: <20131205115254.7DE4DF1A@resin03.mta.everyone.net> References: <20131205115254.7DE4DF1A@resin03.mta.everyone.net> Message-ID: <52A0DB2B.1090802@kjro.se> You didn't quite play this one right. You need to see if you can use them to get a ticket to the next conference to meet them in person and discuss their proposals. Free ticket to the next Nanog conference. On 12/5/2013 2:52 PM, Scott Weeks wrote: > > :: QualiSystems team met you during the 2011 Nanog > :: Conference in Denver. > > No you didn't. This is completely false. In the > 15+ years I have been on the NANOG mailing list I > have *never* been able to afford to attend a NANOG > conference because it's really expensive from Hawaii. > > So, in addition to spamming, you're not telling the > truth. > > Warning to others reading. Don't scrape the list > for email addresses and if you get caught DON'T TELL > FALSE THINGS to folks! :-( > > scott > > > --- zohar.k at qualisystems.com wrote: > > From: Zohar Karni > To: "surfer at mauigateway.com" > CC: Revital Rabany-Levi > Subject: RE: Live Webinar: The Mandate for a Highly Automated IT Function > Date: Thu, 5 Dec 2013 09:42:32 +0000 > > Dear Mr. Weeks, > > QualiSystems team met you during the 2011 Nanog Conference in Denver. > > If you no longer wish to get updates from QualiSystems please let me know. > > Sorry if we disturbed you, > Zohar > > > -----Original Message----- > From: Scott Weeks [mailto:surfer at mauigateway.com] > Sent: Thursday, December 05, 2013 2:29 AM > To: Zohar Karni > Subject: Re: Live Webinar: The Mandate for a Highly Automated IT Function > > > > Where did you get my email address from? > > > --- Zohar.k at qualisystems.com wrote: > > From: "Zohar karni" > To: "Scott Weeks" > Subject: Live Webinar: The Mandate for a Highly Automated IT Function > Date: Wed, 04 Dec 2013 23:07:24 +0000 > > LIVE WEBINAR > > The Mandate for a Highly Automated IT Function > > Dear Scott Weeks, > > QualiSystems invites you to attend a Web seminar: > > The Mandate for a Highly Automated IT Function > > Distinguished industry analyst Jim Metzler will deliver the first in a five part webinar series that describes the journey that IT organizations must take in order to go from the traditional highly manual, hardware centric IT operational model to an operational model that is highly automated and software centric. > This webinar will kick off the series by delving into the limitations of the current IT operational model and will discuss some of the factors that are forcing IT organizations to adopt a new operational model. > > Presenter: > Dr. Jim Metzler > Ashton, Metzler & Associates > > JOIN US > > Tuesday, > December 17, 2013 > > 9:00 am > Pacific Daylight Time > (San Francisco) > > 11:00 pm > Central Daylight Time (Chicago) > > 12:00 pm > Eastern Daylight Time > (New York) > > ( https://webex.rsvp1.com/s18c7fdYV8p5 ) > > Looking forward to meeting you online, > The QualiSystems Team > > ( http://www.qualisystems.rsvp1.com/s1897fdYV8p9 ) > > ( https://twitter.rsvp1.com/s1b07fdYV8pe ) > > ( http://www.facebook.rsvp1.com/s174fedYV8pk ) > > ( http://www.linkedin.rsvp1.com/s1b6bfdYV8pl ) > > ( https://google.rsvp1.com/s17fbedYV8pp ) > > ( http://www.youtube.rsvp1.com/s1be3fdYV8pr ) www.qualisystems.com ( http://www.qualisystems.rsvp1.com/s17efedYV8ps ) > | > > Contact Us ( http://www.qualisystems.rsvp1.com/s17c7edYV8pu ) > > This e-mail was sent to surfer at mauigateway.com by Zohar.k at qualisystems.com. > Qualisystems, Inc, 20 Ha’Carmel St., Ganey-Tikva, 55900 If you no longer wish to receive commercial e-mail messages from Zohar.k at qualisystems.com, please select the following link: Remove ( https://salesgenius.rsvp1.com/s16d7edYV8pI ). > > > > From svoll.voip at gmail.com Thu Dec 5 20:05:05 2013 From: svoll.voip at gmail.com (Scott Voll) Date: Thu, 5 Dec 2013 12:05:05 -0800 Subject: Cisco ScanSafe, aka Cisco Cloud Web Security In-Reply-To: References: Message-ID: We currently use CCWS (previously ScanSafe) with the Anyconnect client. Nice solution. Whether your in the office or remoting from a Starbucks, the traffic is always proxied. We went with the solution because of a couple reasons: 1. with multiple egress points on the corporate network, we didn't want to be down if we lost a proxy server. 2. corporate laptops whether in the office or at Starbucks would still be proxied. This helps limit our virus and malware infections. and provides HR reports. 3 split tunneling would be an option because the traffic doesn't have to come back to your internal proxy. 4. our remote home office bandwidth is very limited, so using the cloud it provided for better use of that bandwidth. all and all it's a good solution. I'm not going to tell you that we have not had any issues, but with any new solution, there will be a couple bruises along the way. YMMV Scott On Wed, Dec 4, 2013 at 7:53 AM, Herro91 wrote: > Hi, > > I'm doing some research on the Cisco Cloud Web Security offering, also > known as ScanSafe. > > Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now called > Cisco Cloud Web Security - as a means of providing protection in the cloud > that would potentially negate the requirement to have a full tunnel (i.e. > allow split tunneling) for teleworkers? > > > Thanks! > From geraint at koding.com Fri Dec 6 02:16:30 2013 From: geraint at koding.com (Geraint Jones) Date: Fri, 06 Dec 2013 15:16:30 +1300 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: Message-ID: Its the reason deduplication makes the storage savings it does :) -- Geraint Jones On 6/12/13 2:52 pm, "Richard Porter" wrote: >*Sarcasm* but lawyers seem to think it is REALLY important to add that >load to email servers, backup servers and storage :). I wonder how much >extra storage those simple extra bits/bytes have taken over the years? > >~Richard > >On Dec 5, 2013, at 6:39 PM, Rogan Schlassa >wrote: > >> Please dont reply back with such legal disclaimers. It is basically >>SPAM >> and of course nonsense. >> >> The thought that you can send a email and force your companies terms on >>us >> is rediculous. >> >> If CISCO forces that in your sig then for one tell them to fuck off and >>two >> use a different email. >> On Dec 5, 2013 3:56 PM, "John Stuppi (jstuppi)" >>wrote: >> >>> Thanks folks. Blogs.cisco.com should be back up now for both IPv4 and >>>v6. >>> >>> Thanks, >>> John >>> >>> "We can't help everyone, but everyone can help someone." >>> >>> >>> >>> >>> John Stuppi, CISSP >>> Technical Leader >>> Strategic Security Research >>> jstuppi at cisco.com >>> Phone: +1 732 516 5994 >>> Mobile: 732 319 3886 >>> >>> CCIE, Security - 11154 >>> Cisco Systems >>> Mail Stop INJ01/2/ >>> 111 Wood Avenue South >>> Iselin, New Jersey 08830 >>> United States >>> Cisco.com >>> >>> >>> >>> Think before you print. >>> This email may contain confidential and privileged material for the >>>sole >>> use of the intended recipient. Any review, use, distribution or >>>disclosure >>> by others is strictly prohibited. If you are not the intended >>>recipient (or >>> authorized to receive for the recipient), please contact the sender by >>> reply email and delete all copies of this message. >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Jared Mauch [mailto:jared at puck.nether.net] >>> Sent: Wednesday, December 04, 2013 9:23 AM >>> To: Henri Wahl >>> Cc: NANOG list >>> Subject: Re: blogs.cisco.com not available via IPv6 >>> >>> I'm seeing it down via IPv6: >>> >>> * Trying 2600:1407:9:295::90... >>> * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) >>>> GET / HTTP/1.1 >>>> User-Agent: curl/7.30.0 >>>> Host: www.cisco.com >>>> Accept: */* >>>> >>> < HTTP/1.1 200 OK >>> * Server Apache is not blacklisted >>> >>> >>> * About to connect() to blogs.cisco.com port 80 (#0) >>> * Trying 2001:4800:13c1:10::178... >>> ^C >>> >>> - Jared >>> >>> On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: >>> >>>> Hi, >>>> can anybody from Cisco confirm that blogs.cisco.com >>>> (2001:4800:13c1:10::178) is not available via IPv6? >>>> Regards >>>> >>>> -- >>>> Henri Wahl >>>> >>>> IT Department >>>> Leibniz-Institut fuer Festkoerper- u. >>>> Werkstoffforschung Dresden >>>> >>>> tel: (03 51) 46 59 - 797 >>>> email: h.wahl at ifw-dresden.de >>>> http://www.ifw-dresden.de >>>> >>>> Nagios status monitor Nagstamon: >>>> http://nagstamon.ifw-dresden.de >>>> >>>> DHCPv6 server dhcpy6d: >>>> http://dhcpy6d.ifw-dresden.de >>>> >>>> IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. >>>> 1369 >>>> Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle >>>> <0x1FBA0942.asc> >>> >>> >>> >>> > From Bryan at bryanfields.net Fri Dec 6 07:04:17 2013 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 06 Dec 2013 02:04:17 -0500 Subject: Question related to Cellular Data and restrictions.. In-Reply-To: References: <13720621.4060.1386195633357.JavaMail.root@benjamin.baylink.com> Message-ID: <52A176F1.1050806@bryanfields.net> On 12/4/13 5:20 PM, Jay Ashworth wrote: > I believe you will find that any carrier says "Nationwide means where we > have coverage, and unlimited means 'if you're on our towers'." TSRH. When I was at Alltel we discovered one client that was using his 3g card on a roaming partners network 24/7. As we could not bill based on this we only discovered it via a roaming settlement audit. I think at the time we were paying .35 cents per kb or something like that (might have been MOU based). Basically this customer was costing us $10-$20k per month and we had no way to track it back to them. I believe they fired the customers using the clause that nationwide is included, but you your home majority use location must be on our network. the lawyers had nicer way of saying it :) Wireless data interconnect (GRX/CRX) is like the most arcane and backwards peering there is. every single bit of use must be tracked and metered back to the user, and it makes the whole thing more expensive than it needs to be. It's like going to your users and demanding different payments based on the amount of data they receive from different ASN's. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From eugen at imacandi.net Fri Dec 6 07:14:36 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Fri, 6 Dec 2013 09:14:36 +0200 Subject: [c-nsp] Cisco ScanSafe, aka Cisco Cloud Web Security In-Reply-To: References: Message-ID: Hi, How do you handle captive portals in hotels and other venues where you first have to login into the portal and then have Internet access ? This is my biggest woe right now in this regards with any kind of proxy settings I can push to users. Thanks, Eugeniu On Thu, Dec 5, 2013 at 10:05 PM, Scott Voll wrote: > We currently use CCWS (previously ScanSafe) with the Anyconnect client. > Nice solution. Whether your in the office or remoting from a Starbucks, > the traffic is always proxied. We went with the solution because of a > couple reasons: > > 1. with multiple egress points on the corporate network, we didn't want to > be down if we lost a proxy server. > > 2. corporate laptops whether in the office or at Starbucks would still be > proxied. This helps limit our virus and malware infections. and provides > HR reports. > > 3 split tunneling would be an option because the traffic doesn't have to > come back to your internal proxy. > > 4. our remote home office bandwidth is very limited, so using the cloud it > provided for better use of that bandwidth. > > all and all it's a good solution. I'm not going to tell you that we have > not had any issues, but with any new solution, there will be a couple > bruises along the way. > > YMMV > > Scott > > > > On Wed, Dec 4, 2013 at 7:53 AM, Herro91 wrote: > > > Hi, > > > > I'm doing some research on the Cisco Cloud Web Security offering, also > > known as ScanSafe. > > > > Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now > called > > Cisco Cloud Web Security - as a means of providing protection in the > cloud > > that would potentially negate the requirement to have a full tunnel (i.e. > > allow split tunneling) for teleworkers? > > > > > > Thanks! > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From email at edylie.net Fri Dec 6 07:47:32 2013 From: email at edylie.net (Pui Edylie) Date: Fri, 06 Dec 2013 15:47:32 +0800 Subject: [c-nsp] Cisco ScanSafe, aka Cisco Cloud Web Security In-Reply-To: References: Message-ID: <52A18114.1040703@edylie.net> Hi Eugeniu, You could use the inexpensive Mikrotik User Manager http://wiki.mikrotik.com/wiki/User_Manager/Introduction http://wiki.mikrotik.com/wiki/Manual:User_Manager http://wiki.mikrotik.com/wiki/User_Manager/Getting_started http://www.youtube.com/watch?v=blEGv5i-aO4 Good Luck :) Edy On 12/6/2013 3:14 PM, Eugeniu Patrascu wrote: > Hi, > > How do you handle captive portals in hotels and other venues where you > first have to login into the portal and then have Internet access ? > > This is my biggest woe right now in this regards with any kind of proxy > settings I can push to users. > > Thanks, > Eugeniu > > > On Thu, Dec 5, 2013 at 10:05 PM, Scott Voll wrote: > >> We currently use CCWS (previously ScanSafe) with the Anyconnect client. >> Nice solution. Whether your in the office or remoting from a Starbucks, >> the traffic is always proxied. We went with the solution because of a >> couple reasons: >> >> 1. with multiple egress points on the corporate network, we didn't want to >> be down if we lost a proxy server. >> >> 2. corporate laptops whether in the office or at Starbucks would still be >> proxied. This helps limit our virus and malware infections. and provides >> HR reports. >> >> 3 split tunneling would be an option because the traffic doesn't have to >> come back to your internal proxy. >> >> 4. our remote home office bandwidth is very limited, so using the cloud it >> provided for better use of that bandwidth. >> >> all and all it's a good solution. I'm not going to tell you that we have >> not had any issues, but with any new solution, there will be a couple >> bruises along the way. >> >> YMMV >> >> Scott >> >> >> >> On Wed, Dec 4, 2013 at 7:53 AM, Herro91 wrote: >> >>> Hi, >>> >>> I'm doing some research on the Cisco Cloud Web Security offering, also >>> known as ScanSafe. >>> >>> Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now >> called >>> Cisco Cloud Web Security - as a means of providing protection in the >> cloud >>> that would potentially negate the requirement to have a full tunnel (i.e. >>> allow split tunneling) for teleworkers? >>> >>> >>> Thanks! >>> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> From eugen at imacandi.net Fri Dec 6 08:17:53 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Fri, 6 Dec 2013 10:17:53 +0200 Subject: [c-nsp] Cisco ScanSafe, aka Cisco Cloud Web Security In-Reply-To: <52A18114.1040703@edylie.net> References: <52A18114.1040703@edylie.net> Message-ID: Helllo Pui, Thanks for the pointers but I think you misunderstood my question. I know how to set up a captive portal for WiFi access. What I wanted to know is how are users logging into captive portals when the browser has a proxy set and it tries to send all requests to the proxy server which until they authenticate to the captive portal they cannot reach ? Eugeniu On Fri, Dec 6, 2013 at 9:47 AM, Pui Edylie wrote: > Hi Eugeniu, > > You could use the inexpensive Mikrotik User Manager > > http://wiki.mikrotik.com/wiki/User_Manager/Introduction > > http://wiki.mikrotik.com/wiki/Manual:User_Manager > > http://wiki.mikrotik.com/wiki/User_Manager/Getting_started > > http://www.youtube.com/watch?v=blEGv5i-aO4 > > Good Luck :) > > Edy > > On 12/6/2013 3:14 PM, Eugeniu Patrascu wrote: > >> Hi, >> >> How do you handle captive portals in hotels and other venues where you >> first have to login into the portal and then have Internet access ? >> >> This is my biggest woe right now in this regards with any kind of proxy >> settings I can push to users. >> >> Thanks, >> Eugeniu >> >> >> On Thu, Dec 5, 2013 at 10:05 PM, Scott Voll wrote: >> >> We currently use CCWS (previously ScanSafe) with the Anyconnect client. >>> Nice solution. Whether your in the office or remoting from a >>> Starbucks, >>> the traffic is always proxied. We went with the solution because of a >>> couple reasons: >>> >>> 1. with multiple egress points on the corporate network, we didn't want >>> to >>> be down if we lost a proxy server. >>> >>> 2. corporate laptops whether in the office or at Starbucks would still be >>> proxied. This helps limit our virus and malware infections. and >>> provides >>> HR reports. >>> >>> 3 split tunneling would be an option because the traffic doesn't have to >>> come back to your internal proxy. >>> >>> 4. our remote home office bandwidth is very limited, so using the cloud >>> it >>> provided for better use of that bandwidth. >>> >>> all and all it's a good solution. I'm not going to tell you that we have >>> not had any issues, but with any new solution, there will be a couple >>> bruises along the way. >>> >>> YMMV >>> >>> Scott >>> >>> >>> >>> On Wed, Dec 4, 2013 at 7:53 AM, Herro91 wrote: >>> >>> Hi, >>>> >>>> I'm doing some research on the Cisco Cloud Web Security offering, also >>>> known as ScanSafe. >>>> >>>> Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now >>>> >>> called >>> >>>> Cisco Cloud Web Security - as a means of providing protection in the >>>> >>> cloud >>> >>>> that would potentially negate the requirement to have a full tunnel >>>> (i.e. >>>> allow split tunneling) for teleworkers? >>>> >>>> >>>> Thanks! >>>> >>>> _______________________________________________ >>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >>> > > From surfer at mauigateway.com Fri Dec 6 08:30:32 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 6 Dec 2013 00:30:32 -0800 Subject: list scraping by QualiSystems Message-ID: <20131206003032.7DEB9024@resin13.mta.everyone.net> On 12/5/2013 2:52 PM, Scott Weeks wrote: > :: QualiSystems team met you during the 2011 Nanog > :: Conference in Denver. > > No you didn't. --- iam at kjro.se wrote: From: Kelly John Rose You didn't quite play this one right. You need to see if you can use them to get a ticket to the next conference to meet them in person and discuss their proposals. Free ticket to the next Nanog conference. -------------------------------------------- I know you're just messing around, but the thing I/we get from NANOG is freely shared information; without worrying about hassle from anyone but our peers. And there's a LOT of that. :-) That's valuable. I want nothing more and I seek to keep it that way. I hate schwag. scott On 12/5/2013 2:52 PM, Scott Weeks wrote: > > :: QualiSystems team met you during the 2011 Nanog > :: Conference in Denver. > > No you didn't. This is completely false. In the > 15+ years I have been on the NANOG mailing list I > have *never* been able to afford to attend a NANOG > conference because it's really expensive from Hawaii. > > So, in addition to spamming, you're not telling the > truth. > > Warning to others reading. Don't scrape the list > for email addresses and if you get caught DON'T TELL > FALSE THINGS to folks! :-( > > scott > > > --- zohar.k at qualisystems.com wrote: > > From: Zohar Karni > To: "surfer at mauigateway.com" > CC: Revital Rabany-Levi > Subject: RE: Live Webinar: The Mandate for a Highly Automated IT Function > Date: Thu, 5 Dec 2013 09:42:32 +0000 > > Dear Mr. Weeks, > > QualiSystems team met you during the 2011 Nanog Conference in Denver. > > If you no longer wish to get updates from QualiSystems please let me know. > > Sorry if we disturbed you, > Zohar > > > -----Original Message----- > From: Scott Weeks [mailto:surfer at mauigateway.com] > Sent: Thursday, December 05, 2013 2:29 AM > To: Zohar Karni > Subject: Re: Live Webinar: The Mandate for a Highly Automated IT Function > > > > Where did you get my email address from? > > > --- Zohar.k at qualisystems.com wrote: > > From: "Zohar karni" > To: "Scott Weeks" > Subject: Live Webinar: The Mandate for a Highly Automated IT Function > Date: Wed, 04 Dec 2013 23:07:24 +0000 > > LIVE WEBINAR > > The Mandate for a Highly Automated IT Function > > Dear Scott Weeks, > > QualiSystems invites you to attend a Web seminar: > > The Mandate for a Highly Automated IT Function > > Distinguished industry analyst Jim Metzler will deliver the first in a five part webinar series that describes the journey that IT organizations must take in order to go from the traditional highly manual, hardware centric IT operational model to an operational model that is highly automated and software centric. > This webinar will kick off the series by delving into the limitations of the current IT operational model and will discuss some of the factors that are forcing IT organizations to adopt a new operational model. > > Presenter: > Dr. Jim Metzler > Ashton, Metzler & Associates > > JOIN US > > Tuesday, > December 17, 2013 > > 9:00 am > Pacific Daylight Time > (San Francisco) > > 11:00 pm > Central Daylight Time (Chicago) > > 12:00 pm > Eastern Daylight Time > (New York) > > ( https://webex.rsvp1.com/s18c7fdYV8p5 ) > > Looking forward to meeting you online, > The QualiSystems Team > > ( http://www.qualisystems.rsvp1.com/s1897fdYV8p9 ) > > ( https://twitter.rsvp1.com/s1b07fdYV8pe ) > > ( http://www.facebook.rsvp1.com/s174fedYV8pk ) > > ( http://www.linkedin.rsvp1.com/s1b6bfdYV8pl ) > > ( https://google.rsvp1.com/s17fbedYV8pp ) > > ( http://www.youtube.rsvp1.com/s1be3fdYV8pr ) www.qualisystems.com ( http://www.qualisystems.rsvp1.com/s17efedYV8ps ) > | > > Contact Us ( http://www.qualisystems.rsvp1.com/s17c7edYV8pu ) > > This e-mail was sent to surfer at mauigateway.com by Zohar.k at qualisystems.com. > Qualisystems, Inc, 20 Ha’Carmel St., Ganey-Tikva, 55900 If you no longer wish to receive commercial e-mail messages from Zohar.k at qualisystems.com, please select the following link: Remove ( https://salesgenius.rsvp1.com/s16d7edYV8pI ). > > > > From mark at amplex.net Fri Dec 6 13:54:34 2013 From: mark at amplex.net (Mark Radabaugh) Date: Fri, 06 Dec 2013 08:54:34 -0500 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A11BDC.1010307@philkarn.net> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> <52A11BDC.1010307@philkarn.ne! t> Message-ID: <52A1D71A.4040801@amplex.net> On 12/5/13 7:35 PM, Phil Karn wrote: > On 12/05/2013 02:00 PM, Owen DeLong wrote: > >> If AT&T has capped me, then, I haven?t managed to hit the cap as yet. >> Admittedly, the connection isn?t always as reliable as $CABLECO, but >> when it works, it tends to work at full speed and it does work the >> vast majority of the time. > AT&T threatened to cap U-verse at 250 GB/mo several years ago, but they > never seem to have followed through. It's probably about the only way > that their incompetence is actually in the public interest. > > Monthly caps -- and even peak speed limits -- are a very poor idea in > general because they don't take system conditions into account. A > torrent that runs at night penalizes you just as much as one run at > prime time. Actually more, since you probably get greater throughput at > off-peak times and therefore hit your cap faster. > > If one *must* charge for usage on a shared network, the right thing is > to base the monthly fee on *guaranteed* bandwidth because that's what > actually drives costs. If more is available because others aren't using > their guarantees, fine, you can have it for free. But it's not > guaranteed. And you don't get a refund for not using your guarantee > because the equipment still had to be allocated for you. > > Of course the real solution to nearly every problem with local broadband > access is the same: meaningful competition. About the only way this > could happen is for the municipality to install, own and maintain the > fiber plant and lease it to any and all commercial service providers on > a non-discriminatory and non-exclusive basis. > > Naturally this will never happen in the United States because the > incumbents will scream "socialism!" at the top of their lungs and race > to the state houses to outlaw it. Never mind that this is exactly how > we've handled roads for centuries. > > --Phil > Phil - we sort of do what you suggest, making the fee based on the sustained rate without a cap. The problem becomes one of being and staying competitive in the market. This method penalizes the light users in favor of the heavy ones. Amplex is a WISP so we are somewhere between wired and mobile wireless, though closer to wireline in many ways. Our limiting factors are sector capacity, spectrum availability, and physical tower space. By staying with relatively low speed plans (1, 3.5, 5, and 9Mpbs) we can reasonably guarantee that a user running full rate 24x7 will not significantly affect the other users on the sector. Keeping the speeds to low rates becomes a marketing/sales problem. It also keeps us from offering higher speeds to light consumption users. Currently, without a limit, there is nothing to convince a end user to make any attempt at conserving bandwidth and no revenue to cover the cost of additional equipment to serve high bandwidth customers. By adding a cap or overage charge we can offer higher speed plans. I realize most of the NANOG operators are not running end user networks anymore. Real consumption data: Monthly_GB Count Percent <100GB 3658 90% 100-149 368 10% 150-199 173 4.7% 200-249 97 2.6% 250-299 50 1.4% 300-399 27 0.7% 400-499 9 0.25% 500-599 4 0.1% 600-699 4 0.1% 700-799 3 0.1% >800 1 0.03% Overall average: 36GB/mo The user at 836MB per month is on a 3.5Mbps plan paying $49.95/mo. Do we do anything about it? No - because our current AUP and policies say he can do that. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 x 1021 From eugen at leitl.org Fri Dec 6 17:38:31 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 6 Dec 2013 18:38:31 +0100 Subject: =?utf-8?B?U29tZW9uZeKAmXMgQmVl?= =?utf-8?Q?n?= Siphoning Data Through a Huge Security Hole in the Internet Message-ID: <20131206173830.GL10793@leitl.org> http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ Someone?s Been Siphoning Data Through a Huge Security Hole in the Internet BY KIM ZETTER12.05.136:30 AM Hijacked traffic went all the way to Iceland, where it may have been copied before being released to its intended destination. The green arrows show the path the traffic should have traveled; the red arrows show the path it took. Map courtesy of Renesys In 2008, two security researchers at the DefCon hacker conference demonstrated a massive security vulnerability in the worldwide internet traffic-routing system ? a vulnerability so severe that it could allow intelligence agencies, corporate spies or criminals to intercept massive amounts of data, or even tamper with it on the fly. The traffic hijack, they showed, could be done in such a way that no one would notice because the attackers could simply re-route the traffic to a router they controlled, then forward it to its intended destination once they were done with it, leaving no one the wiser about what had occurred. Now, five years later, this is exactly what has happened. Earlier this year, researchers say, someone mysteriously hijacked internet traffic headed to government agencies, corporate offices and other recipients in the U.S. and elsewhere and redirected it to Belarus and Iceland, before sending it on its way to its legitimate destinations. They did so repeatedly over several months. But luckily someone did notice. And this may not be the first time it has occurred ? just the first time it got caught. Analysts at Renesys, a network monitoring firm, said that over several months earlier this year someone diverted the traffic using the same vulnerability in the so-called Border Gateway Protocol, or BGP, that the two security researchers demonstrated in 2008. The BGP attack, a version of the classic man-in-the-middle exploit, allows hijackers to fool other routers into re-directing data to a system they control. When they finally send it to its correct destination, neither the sender nor recipient is aware that their data has made an unscheduled stop. The stakes are potentially enormous, since once data is hijacked, the perpetrator can copy and then comb through any unencrypted data freely ? reading email and spreadsheets, extracting credit card numbers, and capturing vast amounts of sensitive information. The attackers initiated the hijacks at least 38 times, grabbing traffic from about 1,500 individual IP blocks ? sometimes for minutes, other times for days ? and they did it in such a way that, researchers say, it couldn?t have been a mistake. Renesys Senior Analyst Doug Madory says initially he thought the motive was financial, since traffic destined for a large bank got sucked up in the diversion. But then the hijackers began diverting traffic intended for the foreign ministries of several countries he declined to name, as well as a large VoIP provider in the U.S., and ISPs that process the internet communications of thousands of customers. Although the intercepts originated from a number of different systems in Belarus and Iceland, Renesys believes the hijacks are all related, and that the hijackers may have altered the locations to obfuscate their activity. ?What makes a man-in-the-middle routing attack different from a simple route hijack? Simply put, the traffic keeps flowing and everything looks fine to the recipient,?? Renesys wrote in a blog post about the hijacks. ?It?s possible to drag specific internet traffic halfway around the world, inspect it, modify it if desired, and send it on its way. Who needs fiberoptic taps?? Earlier this year someone mysteriously hijacked internet traffic headed to government agencies, corporate offices and other recipients and redirected it to Belarus and Iceland (above). Photo: Image Source/Getty Renesys cautions that it doesn?t know who is behind the hijacks. Although systems in Belarus and Iceland initiated the hijacks, it?s possible that those systems were hijacked by a third party that simply used them as a proxy for the attacks. Either way, one thing is certain, Madory says: the characteristics of the hijacks indicate they were intentional. Some of the targets whose traffic was hijacked seemed hand-picked by the attackers, he says, especially the foreign ministry domains. ?It?s a list [of targets] that you just wouldn?t come by mistake,? Madory told WIRED. The hijackers also appeared to tweak their attack over time to modify and refine it. ?In the Belarus example, we saw an evolution of the technique of someone manipulating the attributes of the BGP messages to try to achieve this man-in-the-middle thing,? he said. ?To us, that communicated some intention versus a mistake.? BGP eavesdropping has long been a known weakness, but no one is known to have intentionally exploited it like this until now. The technique doesn?t attack a bug or flaw in BGP, but simply takes advantage of the fact that BGP?s architecture is based on trust. To make it easy for e-mail traffic from an ISP in California to reach customers of an ISP in Spain, networks for these providers and others communicate through BGP routers. Each router distributes so-called announcements indicating which IP addresses they?re in the best position to deliver traffic to, for the quickest, most efficient route. But BGP routers assume that when another router says it?s the best path to a specific block of IP addresses, it?s telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic they shouldn?t get. When a user types a website name into his browser or clicks ?send? to launch an e-mail, a router belonging to the sender?s ISP consults a BGP table for the best route to the destination. That table is built from the announcements issued by ISPs and other networks declaring the range of IP addresses, or IP prefixes, to which they?ll deliver traffic. The routing table searches for the destination IP address among those prefixes, and if two systems deliver traffic for the address, the one with the narrower, more specific range of prefixes ?wins? the traffic. For example, one ISP announces that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both of these, the e-mail will get sent to the narrower, more specific one. To intercept data, anyone with a BGP router or control of a BGP router could send out an announcement for a range of IP addresses he wished to target that was narrower than the chunk advertised by other network routers. The announcement would take just minutes to propagate worldwide and, just like that, data that should have headed to those networks would begin arriving to the eavesdropper?s router instead. Ordinarily, when an attacker tried to then forward the stolen traffic to its rightful destination, it would boomerang back to him, since other routers would still believe that his was the best destination for the traffic. But the technique demonstrated at DefCon, and now spotted in the wild, allows an attacker to send his announcement in such a way that it is delivered only to select routers. So, once the traffic passes through his router, it gets directed to its rightful destination through routers that never got the bogus announcement. The attack intercepts only traffic headed to target addresses, not from them. BGP hijacking happens in some form or fashion every day, but it?s usually unintentional ? the result of a typo in a routing announcement or some other mistake. And when it does occur, it generally results in an outage, as the traffic being routed never reaches its destination. This was the case in 2008 when Pakistan Telecom inadvertently hijacked all of the world?s YouTube traffic when it attempted to prevent just Pakistan citizens from reaching video content the government deemed objectionable. The telecom and its upstream provider mistakenly advertised to routers around the world that it was the best route through which to send all YouTube traffic, and for nearly two hours browsers attempting to reach YouTube fell into a black hole in Pakistan until the problem was corrected. In April 2010, another outage occurred when China Telecom distributed an erroneous announcement for more than 50,000 blocks of IP addresses, and within minutes some of the traffic destined for these domains got sucked into China Telecom?s network for 20 minutes. After analyzing the details, Renesys concluded that this incident, too, was likely a mistake. But the incidents this year have all the characteristics of an intentional intercept, Renesys says. There are legitimate reasons to send out bogus BGP announcements intentionally. Some security firms do this as part of a DDoS protection service. If a victim is being hit with a lot of trash traffic in an effort to knock its servers offline, the security firms will send out bogus announcements to divert traffic away from the client, filter out the trash, and forward the legitimate traffic to the client. But Renesys ruled this out as an explanation for the suspected hijacks after speaking with victims whose IP traffic was hijacked. The first hijacks occurred last February, when an internet service provider called GlobalOneBel based in the Belarusian capital, Minsk, sent out a bogus BGP announcement. The intercepts occurred 21 times throughout the month, with different IP addresses re-routed each day. Some of the intercepts lasted a few minutes, others continued for hours. Countries whose traffic was intercepted included the U.S., Germany, South Korea and Iran. GlobalOneBel?s traffic gets routed through the state-run Bel Telecom, which is where Renesys saw the hijacked traffic go. In one case, traffic headed from New York to Los Angeles took a detour to Moscow and Belarus before being sent back through New York to its destination on the West Coast. In another case, traffic headed from Chicago to Iran, which normally passed through Germany, took a roundabout journey through Canada, London, Amsterdam, Moscow and Belarus before being sent to Iran via Poland, Germany, the UK and New York. The intercepts suddenly halted in March, but then resumed on May 21. This time the hijack appeared to be initiated by a system belonging to Elsat, another ISP in Belarus, whose traffic also gets routed through Belarus?s state-run telecom. The intercepts didn?t last long, though, before the hijackers appeared to change their tactics. The diversion to Belarus stopped, and instead Renesys saw traffic being diverted to a different location, this time in Iceland. The hijack now appeared to be initiated by Nyherji hf, a small internet provider in that country. That intercept lasted just five minutes before the hijack went silent. Nothing occurred again until July 31 when the intercepts resumed with a vengeance, this time appearing to come from Opin Kerfi, another ISP in Iceland. The hijack intercepted 597 IP blocks belonging to a large company in the U.S. that provides VoIP and other services, as well as other IP blocks, most of them in the U.S. Renesys counted 17 intercepts between July 31 and August 19, with nine different ISPs or companies in Iceland initiating the intercepts ? all of them downstream customers of S?minn, an internet backbone provider in Iceland. In one case, traffic headed from one location in Denver, Colorado, to another location in Denver flew off to Illinois, Virginia and New York before traveling overseas to London and Iceland. From there it was redirected back to Denver through Canada, Illinois, New York, Texas and Missouri before finally reaching its destination. The bogus BGP announcements that hijacked the traffic went to so-called peering partners of S?minn in London but not to its peering partners elsewhere. Peers are separate networks that have an established connection in order to easily pass traffic back and forth. Map showing the long and winding path taken by traffic headed from Chicago to Iran. The green route represents the normal route the traffic takes; the red route is the hijacked route it took through Belarus. Renesys contacted S?minn to inquire about the redirects and was told the cause was a bug that had since been patched. ?A software malfunction in S?minn?s internet gateway in Montreal this summer resulted in the corruption of routing data,? a S?minn security manager wrote Renesys in an email. ?The effect of the malfunction was that traffic which was not intended for S?minn or its customers passed through S?minn?s network en route to its intended destination. ? The malfunction had the effect that the corrupt routing data appeared to originate from certain customers of S?minn, including Opin Kerfi and N?herji.? The company said the malfunction was resolved with the assistance of the equipment vendor on August 22nd. Renesys, skeptical of the response, asked for details about the bug and the vendor so that others using the same system could fix it as well, but S?minn didn?t respond. The S?minn manager also did not respond to questions from WIRED. Madory says that if the hijacks to Iceland occurred in isolation, Siminn?s explanation might be plausible, though he still wouldn?t understand how a problem with a system in Montreal resulted in traffic being misrouted through London but then correctly routed through Montreal on its way back from Iceland. But the hijacks to Iceland weren?t isolated; they occurred around the same time as the Belarus attacks. He says he has no doubt that the Belarus hijacks were intentional, and the fact that the last Belarus hijack and the first hijack to Iceland occurred on the same day ? May 21 ? within minutes of one another appear to link them. ?This is a one-in-a-million thing that this would just also happen [on the same day] with some similarities to it,? he says. Renesys discovered the hijacks because it uses an automated system to read global BGP tables daily and tag any that match suspicious parameters. But BGP tables don?t tell the whole story. So Renesys also sends about a quarter of a billion traceroutes a day around the world to measure the health of digital traffic ? like a coronary angiography for the internet. This helps verify that the data in routing tables matches what is really happening to data in the stream, and helps them spot outages when undersea cables are cut or when countries like Iran or Syria block users from the internet. Judging by the BGP tables alone, the traffic that got hijacked to Belarus, for example, should have dead-ended there. But when Renesys sent traceroutes along the same path, it got sucked into the stream going to Belarus and then got spit out the other end to continue to its destination. ?Which is alarming,? Madory says. BGP hijacking is an ?exceedingly blunt instrument? to capture traffic, and is ?about as subtle as a firecracker in a funeral home,? Renesys has noted in the past. In all the years Renesys has been monitoring internet traffic, analysts had never seen anything that looked intentional before. Generally, Madory says, mistakes look clumsy and show obvious signs of being mistakes. They also generally last minutes, not days as these did, and they also generally do not result in traffic being re-routed to its legitimate destination, as occurred in these cases. ?To achieve this thing where you can get [hijacked] traffic back to its destination, . . . you have to craft your [BGP] messages in a way that you control how far it propagates or where it propagates,? he says. ?And we can see these guys experiment over time, modifying different attributes to change the propagation until they?ve achieved the one that they want. We?ve never seen anything like that, that looks very deliberate where someone is tweaking the approach.? But Tony Kapela, VP of data center and network technology at 5Nines in Wisconsin and one of the researchers who exposed the BGP vulnerability in 2008, is shocked that no other signs of intentional hijacking have occurred since their talk five years ago and questions whether this is really the first case, or just the first one seen. Kapela says there are a number of ways that an attacker could hijack traffic so that even Renesys wouldn?t notice ? specifically, if attackers wanted to grab a narrow slice of traffic going to a specific destination and did so in a way that prevented a bogus route announcement from being distributed to the entire internet. He gives the example of three networks that are traffic peers. One of the networks could siphon traffic passing between the other two by sending a route announcement that doesn?t get broadcast to the wider internet. The attacker would send an announcement to one of the others with a tag attached, indicating that the announcement should not be broadcast to any other systems. ?If you have the ability to give a network route to another provider and say ?don?t export this,? and if that provider doesn?t give it to Renesys or the world, it will not be visible,? Kapela says. Renesys has monitoring systems set up throughout the internet in more than 400 networks, but doesn?t see all traffic movement. ?Renesys sees whatever lands in the fly trap,? Kapela says. ?But if you pick one that doesn?t give a route view to Renesys, you have a good chance of not having this get noticed.? Kapela notes that the first time he and his colleague demonstrated a BGP attack at a conference in Germany, the bogus announcements they sent out did not reach the internet at large, just the specific networks they wanted to affect. Kapela says the culprit doesn?t have to be one of the three entities in the attack scenario, but could actually be an outsider who simply seizes control of one of the systems and sends out the bogus announcement without the owner of the system knowing it. He imagines a scenario where an attacker gains physical access to a router belonging to one of the companies and installs a monitoring device to record data, then gains control of the router console to send out a bogus BGP announcement to redirect traffic through the router. If anyone discovers the redirect, the culprit would appear to be the company that owned the router. Kapela says this kind of attack could become a real risk as data centers and ISPs begin installing centralized router controls. Until now, many ISPs have used proprietary systems and decentralized models of control whereby routers were managed individually. But many are switching to new systems, where control for numerous routers is centralized. If someone can hijack the master control, he can distribute bogus announcements. There may also be ways to feed operators false data to blind them to this manipulation. Renesys and Kapela say that ISPs, credit-card processing companies, government agencies and others should all be monitoring the global routing of their advertised IP prefixes to make sure that someone isn?t hijacking their traffic or using their system to hijack someone else?s traffic. In other words, the future may hold more of these security breaches. As Renesys warned on its blog: ?We believe that people are still attempting this because they believe (correctly, in most cases) that nobody is looking.? Kim Zetter is a senior reporter at Wired covering cybercrime, privacy, security and civil liberties. Read more by Kim Zetter Follow @KimZetter and @ThreatLevel on Twitter. From jared at puck.nether.net Fri Dec 6 18:05:54 2013 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 6 Dec 2013 13:05:54 -0500 Subject: =?windows-1252?Q?Re=3A_Someone=92s_Been_Siphoning_Data_Through_a?= =?windows-1252?Q?_Huge_Security_Hole_in_the_Internet?= In-Reply-To: <20131206173830.GL10793@leitl.org> References: <20131206173830.GL10793@leitl.org> Message-ID: <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> On Dec 6, 2013, at 12:38 PM, Eugen Leitl wrote: > > http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ > > Someone?s Been Siphoning Data Through a Huge Security Hole in the Internet > ... > In 2008, two security researchers at the DefCon hacker conference > demonstrated a massive security vulnerability in the worldwide internet > traffic-routing system ? a vulnerability so severe that it could allow > intelligence agencies, corporate spies or criminals to intercept massive > amounts of data, or even tamper with it on the fly. ... Yes, nothing new to see here, networks don't do BGP filtering well, no Film at 11? I've detected 11.6 million of these events since 2008 just looking at the route-views data. Most recently the past two days 701 has done a large MITM of traffic. In other news, you can go read the other thread on this that happened already. http://mailman.nanog.org/pipermail/nanog/2013-November/062257.html - Jared From wbailey at satelliteintelligencegroup.com Fri Dec 6 18:08:06 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 6 Dec 2013 18:08:06 +0000 Subject: list scraping by QualiSystems In-Reply-To: <20131206003032.7DEB9024@resin13.mta.everyone.net> References: <20131206003032.7DEB9024@resin13.mta.everyone.net> Message-ID: I will accept all Schwag that does not involve consuming food (cups etc) or clothing. I still randomly get amazon gift cards, but I suspect they are catching on to the fact that their money is being spent on toys for a 4 year old "engineer" (my daughter). I'm happy to accept free money.. I just won't wear their shirts or use their mugs. ;) Sent from my Mobile Device. -------- Original message -------- From: Scott Weeks Date: 12/05/2013 11:33 PM (GMT-09:00) To: nanog at nanog.org Subject: Re: list scraping by QualiSystems On 12/5/2013 2:52 PM, Scott Weeks wrote: > :: QualiSystems team met you during the 2011 Nanog > :: Conference in Denver. > > No you didn't. --- iam at kjro.se wrote: From: Kelly John Rose You didn't quite play this one right. You need to see if you can use them to get a ticket to the next conference to meet them in person and discuss their proposals. Free ticket to the next Nanog conference. -------------------------------------------- I know you're just messing around, but the thing I/we get from NANOG is freely shared information; without worrying about hassle from anyone but our peers. And there's a LOT of that. :-) That's valuable. I want nothing more and I seek to keep it that way. I hate schwag. scott On 12/5/2013 2:52 PM, Scott Weeks wrote: > > :: QualiSystems team met you during the 2011 Nanog > :: Conference in Denver. > > No you didn't. This is completely false. In the > 15+ years I have been on the NANOG mailing list I > have *never* been able to afford to attend a NANOG > conference because it's really expensive from Hawaii. > > So, in addition to spamming, you're not telling the > truth. > > Warning to others reading. Don't scrape the list > for email addresses and if you get caught DON'T TELL > FALSE THINGS to folks! :-( > > scott > > > --- zohar.k at qualisystems.com wrote: > > From: Zohar Karni > To: "surfer at mauigateway.com" > CC: Revital Rabany-Levi > Subject: RE: Live Webinar: The Mandate for a Highly Automated IT Function > Date: Thu, 5 Dec 2013 09:42:32 +0000 > > Dear Mr. Weeks, > > QualiSystems team met you during the 2011 Nanog Conference in Denver. > > If you no longer wish to get updates from QualiSystems please let me know. > > Sorry if we disturbed you, > Zohar > > > -----Original Message----- > From: Scott Weeks [mailto:surfer at mauigateway.com] > Sent: Thursday, December 05, 2013 2:29 AM > To: Zohar Karni > Subject: Re: Live Webinar: The Mandate for a Highly Automated IT Function > > > > Where did you get my email address from? > > > --- Zohar.k at qualisystems.com wrote: > > From: "Zohar karni" > To: "Scott Weeks" > Subject: Live Webinar: The Mandate for a Highly Automated IT Function > Date: Wed, 04 Dec 2013 23:07:24 +0000 > > LIVE WEBINAR > > The Mandate for a Highly Automated IT Function > > Dear Scott Weeks, > > QualiSystems invites you to attend a Web seminar: > > The Mandate for a Highly Automated IT Function > > Distinguished industry analyst Jim Metzler will deliver the first in a five part webinar series that describes the journey that IT organizations must take in order to go from the traditional highly manual, hardware centric IT operational model to an operational model that is highly automated and software centric. > This webinar will kick off the series by delving into the limitations of the current IT operational model and will discuss some of the factors that are forcing IT organizations to adopt a new operational model. > > Presenter: > Dr. Jim Metzler > Ashton, Metzler & Associates > > JOIN US > > Tuesday, > December 17, 2013 > > 9:00 am > Pacific Daylight Time > (San Francisco) > > 11:00 pm > Central Daylight Time (Chicago) > > 12:00 pm > Eastern Daylight Time > (New York) > > ( https://webex.rsvp1.com/s18c7fdYV8p5 ) > > Looking forward to meeting you online, > The QualiSystems Team > > ( http://www.qualisystems.rsvp1.com/s1897fdYV8p9 ) > > ( https://twitter.rsvp1.com/s1b07fdYV8pe ) > > ( http://www.facebook.rsvp1.com/s174fedYV8pk ) > > ( http://www.linkedin.rsvp1.com/s1b6bfdYV8pl ) > > ( https://google.rsvp1.com/s17fbedYV8pp ) > > ( http://www.youtube.rsvp1.com/s1be3fdYV8pr ) www.qualisystems.com ( http://www.qualisystems.rsvp1.com/s17efedYV8ps ) > | > > Contact Us ( http://www.qualisystems.rsvp1.com/s17c7edYV8pu ) > > This e-mail was sent to surfer at mauigateway.com by Zohar.k at qualisystems.com. > Qualisystems, Inc, 20 Ha’Carmel St., Ganey-Tikva, 55900 If you no longer wish to receive commercial e-mail messages from Zohar.k at qualisystems.com, please select the following link: Remove ( https://salesgenius.rsvp1.com/s16d7edYV8pI ). > > > > From cscora at apnic.net Fri Dec 6 18:08:07 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Dec 2013 04:08:07 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201312061808.rB6I874X003935@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, LacNOG, TRNOG, 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 07 Dec, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 473989 Prefixes after maximum aggregation: 189922 Deaggregation factor: 2.50 Unique aggregates announced to Internet: 235181 Total ASes present in the Internet Routing Table: 45624 Prefixes per ASN: 10.39 Origin-only ASes present in the Internet Routing Table: 35427 Origin ASes announcing only one prefix: 16261 Transit ASes present in the Internet Routing Table: 5952 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 103 Max AS path prepend of ASN ( 50404) 101 Prefixes from unregistered ASNs in the Routing Table: 1033 Unregistered ASNs in the Routing Table: 289 Number of 32-bit ASNs allocated by the RIRs: 5465 Number of 32-bit ASNs visible in the Routing Table: 4245 Prefixes from 32-bit ASNs in the Routing Table: 13223 Number of bogon 32-bit ASNs visible in the Routing Table: 1 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 1331 Number of addresses announced to Internet: 2657192828 Equivalent to 158 /8s, 97 /16s and 139 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.3 Total number of prefixes smaller than registry allocations: 165389 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 112564 Total APNIC prefixes after maximum aggregation: 34192 APNIC Deaggregation factor: 3.29 Prefixes being announced from the APNIC address blocks: 114799 Unique aggregates announced from the APNIC address blocks: 47947 APNIC Region origin ASes present in the Internet Routing Table: 4875 APNIC Prefixes per ASN: 23.55 APNIC Region origin ASes announcing only one prefix: 1210 APNIC Region transit ASes present in the Internet Routing Table: 835 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 775 Number of APNIC addresses announced to Internet: 728720576 Equivalent to 43 /8s, 111 /16s and 100 /24s Percentage of available APNIC address space announced: 85.2 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-63999, 131072-133631 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: 163081 Total ARIN prefixes after maximum aggregation: 81731 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 163820 Unique aggregates announced from the ARIN address blocks: 75763 ARIN Region origin ASes present in the Internet Routing Table: 15926 ARIN Prefixes per ASN: 10.29 ARIN Region origin ASes announcing only one prefix: 6000 ARIN Region transit ASes present in the Internet Routing Table: 1666 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 41 Number of ARIN addresses announced to Internet: 1073321856 Equivalent to 63 /8s, 249 /16s and 151 /24s Percentage of available ARIN address space announced: 56.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: 119610 Total RIPE prefixes after maximum aggregation: 61148 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 123359 Unique aggregates announced from the RIPE address blocks: 78944 RIPE Region origin ASes present in the Internet Routing Table: 17538 RIPE Prefixes per ASN: 7.03 RIPE Region origin ASes announcing only one prefix: 8285 RIPE Region transit ASes present in the Internet Routing Table: 2830 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 103 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2506 Number of RIPE addresses announced to Internet: 656022500 Equivalent to 39 /8s, 26 /16s and 27 /24s Percentage of available RIPE address space announced: 95.4 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-200191 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: 53068 Total LACNIC prefixes after maximum aggregation: 10006 LACNIC Deaggregation factor: 5.30 Prefixes being announced from the LACNIC address blocks: 58322 Unique aggregates announced from the LACNIC address blocks: 27386 LACNIC Region origin ASes present in the Internet Routing Table: 2046 LACNIC Prefixes per ASN: 28.51 LACNIC Region origin ASes announcing only one prefix: 553 LACNIC Region transit ASes present in the Internet Routing Table: 393 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 915 Number of LACNIC addresses announced to Internet: 146170648 Equivalent to 8 /8s, 182 /16s and 99 /24s Percentage of available LACNIC address space announced: 87.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11711 Total AfriNIC prefixes after maximum aggregation: 2612 AfriNIC Deaggregation factor: 4.48 Prefixes being announced from the AfriNIC address blocks: 12358 Unique aggregates announced from the AfriNIC address blocks: 4091 AfriNIC Region origin ASes present in the Internet Routing Table: 694 AfriNIC Prefixes per ASN: 17.81 AfriNIC Region origin ASes announcing only one prefix: 213 AfriNIC Region transit ASes present in the Internet Routing Table: 144 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 8 Number of AfriNIC addresses announced to Internet: 48528448 Equivalent to 2 /8s, 228 /16s and 124 /24s Percentage of available AfriNIC address space announced: 48.2 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 2955 11559 952 Korea Telecom (KIX) 17974 2721 902 88 PT TELEKOMUNIKASI INDONESIA 7545 2112 319 110 TPG Internet Pty Ltd 4755 1794 392 190 TATA Communications formerly 9829 1538 1244 47 BSNL National Internet Backbo 9583 1321 102 543 Sify Limited 9498 1218 309 72 BHARTI Airtel Ltd. 7552 1169 1080 13 Vietel Corporation 4808 1143 2119 337 CNCGROUP IP network: China169 24560 1098 382 166 Bharti Airtel Ltd., Telemedia 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 6389 3038 3688 53 BellSouth.net Inc. 22773 2296 2939 137 Cox Communications, Inc. 18566 2052 379 178 MegaPath Corporation 1785 2048 686 131 PaeTec Communications, Inc. 20115 1684 1657 600 Charter Communications 4323 1638 1098 418 Time Warner Telecom 701 1511 11144 782 MCI Communications Services, 30036 1381 311 581 Mediacom Communications Corp 7018 1326 17779 865 AT&T WorldNet Services 6983 1292 755 578 ITC^Deltacom 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 8402 1926 544 16 OJSC "Vimpelcom" 34984 1368 244 224 TELLCOM ILETISIM HIZMETLERI A 20940 1189 450 893 Akamai Technologies European 31148 1010 45 20 FreeNet ISP 13188 897 99 42 TOV "Bank-Inform" 6849 855 363 39 JSC UKRTELECOM, 8551 786 370 41 Bezeq International 6830 755 2326 409 UPC Distribution Services 12479 679 798 53 Uni2 Autonomous System 35228 549 246 16 Avatar Broadband Limited 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 28573 3422 1829 94 NET Servicos de Comunicao S.A 10620 2687 435 198 Telmex Colombia S.A. 7303 1735 1161 230 Telecom Argentina Stet-France 18881 1708 908 20 Global Village Telecom 8151 1367 2855 422 UniNet S.A. de C.V. 11830 868 364 15 Instituto Costarricense de El 27947 851 93 89 Telconet S.A 6147 793 373 27 Telefonica Del Peru 7738 780 1498 36 Telecomunicacoes da Bahia S.A 6503 776 434 60 AVANTEL, 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 36998 1854 112 5 Sudanese Mobile Telephone (ZA 24863 872 338 26 LINKdotNET AS number 6713 554 633 26 Itissalat Al-MAGHRIB 8452 414 956 9 TEDATA 24835 297 144 9 RAYA Telecom - Egypt 3741 247 921 209 The Internet Solution 29571 228 21 13 Ci Telecom Autonomous system 36992 222 501 29 Etisalat MISR 15706 219 32 6 Sudatel Internet Exchange Aut 29975 192 668 21 Vodacom 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 28573 3422 1829 94 NET Servicos de Comunicao S.A 6389 3038 3688 53 BellSouth.net Inc. 4766 2955 11559 952 Korea Telecom (KIX) 17974 2721 902 88 PT TELEKOMUNIKASI INDONESIA 10620 2687 435 198 Telmex Colombia S.A. 22773 2296 2939 137 Cox Communications, Inc. 7545 2112 319 110 TPG Internet Pty Ltd 18566 2052 379 178 MegaPath Corporation 1785 2048 686 131 PaeTec Communications, Inc. 8402 1926 544 16 OJSC "Vimpelcom" 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 3038 2985 BellSouth.net Inc. 17974 2721 2633 PT TELEKOMUNIKASI INDONESIA 10620 2687 2489 Telmex Colombia S.A. 22773 2296 2159 Cox Communications, Inc. 4766 2955 2003 Korea Telecom (KIX) 7545 2112 2002 TPG Internet Pty Ltd 1785 2048 1917 PaeTec Communications, Inc. 8402 1926 1910 OJSC "Vimpelcom" 18566 2052 1874 MegaPath Corporation 36998 1854 1849 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 62828 UNALLOCATED 8.21.130.0/24 4323 Time Warner Telecom 62850 UNALLOCATED 8.25.147.0/24 46887 Lightower Fiber Netw 62734 UNALLOCATED 8.31.128.0/24 6939 Hurricane Electric 62773 UNALLOCATED 8.35.180.0/22 3356 Level 3 Communicatio 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 62719 UNALLOCATED 12.27.130.0/24 4323 Time Warner Telecom 62861 UNALLOCATED 12.37.197.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest Communications Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.100.0.0/24 4847 China Networks Inter-Exchange Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.91.0.0/19 40676 Psychz Networks 23.91.4.0/24 40676 Psychz Networks 23.91.14.0/24 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.80.0/20 21560 Capital Technology Services G 23.91.96.0/20 37958 ChinaCache Networks ASN 23.91.112.0/21 32475 MidPhase Inc. 23.91.120.0/21 36351 SoftLayer Technologies Inc. 23.91.160.0/19 36493 3757277 Canada Inc. (oa 295.c 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:11 /10:31 /11:92 /12:253 /13:476 /14:932 /15:1635 /16:12838 /17:6785 /18:11330 /19:23161 /20:32947 /21:35652 /22:50197 /23:43974 /24:251235 /25:830 /26:986 /27:452 /28:49 /29:73 /30:20 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2007 2052 MegaPath Corporation 36998 1819 1854 Sudanese Mobile Telephone (ZA 6389 1700 3038 BellSouth.net Inc. 8402 1632 1926 OJSC "Vimpelcom" 22773 1548 2296 Cox Communications, Inc. 30036 1221 1381 Mediacom Communications Corp 11492 1183 1224 Cable One 1785 1088 2048 PaeTec Communications, Inc. 6983 1034 1292 ITC^Deltacom 22561 964 1239 Digital Teleport, Inc Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:923 2:869 3:3 4:16 5:812 6:21 8:613 12:1878 13:3 14:899 15:11 16:3 17:19 18:19 20:25 23:616 24:1755 27:1700 31:1521 32:45 33:2 34:5 36:96 37:1945 38:918 39:5 40:181 41:3220 42:231 44:14 46:2073 47:10 49:700 50:864 52:12 54:44 55:5 56:4 57:26 58:1147 59:584 60:367 61:1495 62:1249 63:1973 64:4399 65:2333 66:4145 67:2109 68:1096 69:3297 70:909 71:504 72:2018 74:2580 75:324 76:304 77:1216 78:1016 79:670 80:1277 81:1055 82:630 83:753 84:590 85:1253 86:380 87:1039 88:548 89:1564 90:154 91:5716 92:620 93:1612 94:2118 95:1510 96:515 97:349 98:1130 99:41 100:33 101:686 103:3782 105:530 106:143 107:229 108:538 109:2008 110:976 111:1123 112:594 113:804 114:752 115:1045 116:1009 117:831 118:1221 119:1296 120:338 121:763 122:1871 123:1267 124:1386 125:1439 128:636 129:233 130:355 131:663 132:350 133:158 134:307 135:72 136:275 137:269 138:352 139:171 140:198 141:343 142:549 143:406 144:501 145:90 146:553 147:417 148:773 149:367 150:153 151:485 152:415 153:207 154:45 155:516 156:306 157:419 158:285 159:783 160:361 161:457 162:901 163:225 164:628 165:582 166:276 167:637 168:1039 169:124 170:1125 171:185 172:11 173:1626 174:667 175:540 176:1320 177:2480 178:1867 179:315 180:1600 181:886 182:1406 183:479 184:621 185:1102 186:2641 187:1453 188:1958 189:1253 190:7298 192:7085 193:5425 194:4032 195:3358 196:1343 197:1057 198:4758 199:5511 200:6069 201:2525 202:8976 203:8894 204:4537 205:2647 206:2892 207:2793 208:3957 209:3662 210:3080 211:1629 212:2177 213:1983 214:887 215:84 216:5427 217:1711 218:637 219:318 220:1267 221:587 222:332 223:521 End of report From brandon.galbraith at gmail.com Fri Dec 6 18:39:16 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 6 Dec 2013 12:39:16 -0600 Subject: =?UTF-8?Q?Re=3A_Someone=E2=80=99s_Been_Siphoning_Data_Through_a_Huge_S?= =?UTF-8?Q?ecurity_Hole_in_the_Internet?= In-Reply-To: <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: If your flows are a target, or your data is of an extremely sensitive nature (diplomatic, etc), why aren't you moving those bits over something more private than IP (point to point L2, MPLS)? This doesn't work for the VoIP target mentioned, but foreign ministries should most definitely not be trusting encryption alone. brandon On Fri, Dec 6, 2013 at 12:05 PM, Jared Mauch wrote: > > On Dec 6, 2013, at 12:38 PM, Eugen Leitl wrote: > >> >> http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ >> >> Someone?s Been Siphoning Data Through a Huge Security Hole in the Internet >> ... > >> In 2008, two security researchers at the DefCon hacker conference >> demonstrated a massive security vulnerability in the worldwide internet >> traffic-routing system ? a vulnerability so severe that it could allow >> intelligence agencies, corporate spies or criminals to intercept massive >> amounts of data, or even tamper with it on the fly. > ... > > Yes, nothing new to see here, networks don't do BGP filtering well, no Film at 11? > > I've detected 11.6 million of these events since 2008 just looking at the > route-views data. Most recently the past two days 701 has done a large MITM of > traffic. > > In other news, you can go read the other thread on this that happened already. > > http://mailman.nanog.org/pipermail/nanog/2013-November/062257.html > > - Jared > > From wbailey at satelliteintelligencegroup.com Fri Dec 6 18:44:00 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 6 Dec 2013 18:44:00 +0000 Subject: =?Windows-1252?Q?Re:_Someone=B9s_Been_Siphoning_Data_Through_a_Huge_Secur?= =?Windows-1252?Q?ity_Hole_in_the_Internet?= In-Reply-To: References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: That didn?t seem to work for google.. ;) On 12/6/13, 9:39 AM, "Brandon Galbraith" wrote: >If your flows are a target, or your data is of an extremely sensitive >nature (diplomatic, etc), why aren't you moving those bits over >something more private than IP (point to point L2, MPLS)? This doesn't >work for the VoIP target mentioned, but foreign ministries should most >definitely not be trusting encryption alone. > >brandon > >On Fri, Dec 6, 2013 at 12:05 PM, Jared Mauch >wrote: >> >> On Dec 6, 2013, at 12:38 PM, Eugen Leitl wrote: >> >>> >>> http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ >>> >>> Someone?s Been Siphoning Data Through a Huge Security Hole in the >>>Internet >>> ... >> >>> In 2008, two security researchers at the DefCon hacker conference >>> demonstrated a massive security vulnerability in the worldwide internet >>> traffic-routing system ? a vulnerability so severe that it could allow >>> intelligence agencies, corporate spies or criminals to intercept >>>massive >>> amounts of data, or even tamper with it on the fly. >> ... >> >> Yes, nothing new to see here, networks don't do BGP filtering well, no >>Film at 11? >> >> I've detected 11.6 million of these events since 2008 just looking at >>the >> route-views data. Most recently the past two days 701 has done a large >>MITM of >> traffic. >> >> In other news, you can go read the other thread on this that happened >>already. >> >> http://mailman.nanog.org/pipermail/nanog/2013-November/062257.html >> >> - Jared >> >> > From brandon.galbraith at gmail.com Fri Dec 6 19:01:14 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 6 Dec 2013 13:01:14 -0600 Subject: =?UTF-8?Q?Re=3A_Someone=C2=B9s_Been_Siphoning_Data_Through_a_Huge_Se?= =?UTF-8?Q?curity_Hole_in_the_Internet?= In-Reply-To: References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: An attacker who can "only" attack BGP is different than someone who can splice into your undersea cables undetected. Prepare for the worst appears to be the best SOP now. On Fri, Dec 6, 2013 at 12:44 PM, Warren Bailey wrote: > That didn?t seem to work for google.. ;) > > On 12/6/13, 9:39 AM, "Brandon Galbraith" > wrote: > >>If your flows are a target, or your data is of an extremely sensitive >>nature (diplomatic, etc), why aren't you moving those bits over >>something more private than IP (point to point L2, MPLS)? This doesn't >>work for the VoIP target mentioned, but foreign ministries should most >>definitely not be trusting encryption alone. >> >>brandon >> >>On Fri, Dec 6, 2013 at 12:05 PM, Jared Mauch >>wrote: >>> >>> On Dec 6, 2013, at 12:38 PM, Eugen Leitl wrote: >>> >>>> >>>> http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ >>>> >>>> Someone?s Been Siphoning Data Through a Huge Security Hole in the >>>>Internet >>>> ... >>> >>>> In 2008, two security researchers at the DefCon hacker conference >>>> demonstrated a massive security vulnerability in the worldwide internet >>>> traffic-routing system ? a vulnerability so severe that it could allow >>>> intelligence agencies, corporate spies or criminals to intercept >>>>massive >>>> amounts of data, or even tamper with it on the fly. >>> ... >>> >>> Yes, nothing new to see here, networks don't do BGP filtering well, no >>>Film at 11? >>> >>> I've detected 11.6 million of these events since 2008 just looking at >>>the >>> route-views data. Most recently the past two days 701 has done a large >>>MITM of >>> traffic. >>> >>> In other news, you can go read the other thread on this that happened >>>already. >>> >>> http://mailman.nanog.org/pipermail/nanog/2013-November/062257.html >>> >>> - Jared >>> >>> >> > From owen at delong.com Fri Dec 6 18:59:31 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Dec 2013 10:59:31 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <52A11BDC.1010307@philkarn.net> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> <52A11BDC.1010307@philkarn.ne! t> Message-ID: On Dec 5, 2013, at 16:35 , Phil Karn wrote: > On 12/05/2013 02:00 PM, Owen DeLong wrote: > >> If AT&T has capped me, then, I haven?t managed to hit the cap as yet. >> Admittedly, the connection isn?t always as reliable as $CABLECO, but >> when it works, it tends to work at full speed and it does work the >> vast majority of the time. > > AT&T threatened to cap U-verse at 250 GB/mo several years ago, but they > never seem to have followed through. It's probably about the only way > that their incompetence is actually in the public interest. Meh... U-verse isn't available here anyway. AT&T here is capped at 768kbps on wired. Wireless, I'm getting LTE 30-50Mbps from them. > > Monthly caps -- and even peak speed limits -- are a very poor idea in > general because they don't take system conditions into account. A > torrent that runs at night penalizes you just as much as one run at > prime time. Actually more, since you probably get greater throughput at > off-peak times and therefore hit your cap faster. > On this, we agree. > If one *must* charge for usage on a shared network, the right thing is > to base the monthly fee on *guaranteed* bandwidth because that's what > actually drives costs. If more is available because others aren't using > their guarantees, fine, you can have it for free. But it's not > guaranteed. And you don't get a refund for not using your guarantee > because the equipment still had to be allocated for you. Unfortunately, most of the DSLAMs/GPON Concentrators/CMTS systems don't do a very good job of enabling CIR based provisioning and even if they did, for some reason, consumers seem to have a very hard time wrapping their heads around the CIR/Burst concept when money is involved. > Of course the real solution to nearly every problem with local broadband > access is the same: meaningful competition. About the only way this > could happen is for the municipality to install, own and maintain the > fiber plant and lease it to any and all commercial service providers on > a non-discriminatory and non-exclusive basis. I couldn't agree more... I've been saying this for years. It's starting to actually happen in some places with reasonable success. However, the municipality doesn't necessarily have to install, own, and maintain it. All that really has to happen is regulations that prohibit those that own/provide Layer 1 infrastructure from playing in higher layers of the stack and requiring them to provide service to ALL comers on equal footing. > Naturally this will never happen in the United States because the > incumbents will scream "socialism!" at the top of their lungs and race > to the state houses to outlaw it. Never mind that this is exactly how > we've handled roads for centuries. Yes, our roads are a great example of workable socialism, though what you have proposed is not. What you have proposed is not socialism, since it would be more like a toll road (toll roads which are 100% self-funding don't qualify because there is no tax involved, it is a business. The fact that the business happens to be run by a government agency (in some cases) doesn't really matter.) Nonetheless, you are right that the incumbents will do everything in their considerable power to hang on tightly to their existing monopolies. Unfortunately, so long as we preserve problems like the citizens united ruling, it will be difficult for the people to overcome these problems. Owen From fergdawgster at mykolab.com Fri Dec 6 19:14:32 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 06 Dec 2013 11:14:32 -0800 Subject: =?windows-1252?Q?Someone=92s_Been_Siphoning_Data_Thr?= =?windows-1252?Q?ough_a_Huge_Security_Hole_in_the_Internet?= In-Reply-To: <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: <52A22218.4080001@mykolab.com> ...but you've got to love the headlines it creates. :-) http://news.techeye.net/business/black-hole-found-in-the-internet - ferg On 12/6/2013 10:05 AM, Jared Mauch wrote: > > On Dec 6, 2013, at 12:38 PM, Eugen Leitl wrote: > >> >> http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ >> >> Someone?s Been Siphoning Data Through a Huge Security Hole in the Internet >> ... > >> In 2008, two security researchers at the DefCon hacker conference >> demonstrated a massive security vulnerability in the worldwide internet >> traffic-routing system ? a vulnerability so severe that it could allow >> intelligence agencies, corporate spies or criminals to intercept massive >> amounts of data, or even tamper with it on the fly. > ... > > Yes, nothing new to see here, networks don't do BGP filtering well, no Film at 11? > > I've detected 11.6 million of these events since 2008 just looking at the > route-views data. Most recently the past two days 701 has done a large MITM of > traffic. > > In other news, you can go read the other thread on this that happened already. > > http://mailman.nanog.org/pipermail/nanog/2013-November/062257.html > > - Jared > > > -- Paul Ferguson PGP Public Key ID: 0x63546533 From jared at puck.nether.net Fri Dec 6 19:48:23 2013 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 6 Dec 2013 14:48:23 -0500 Subject: =?windows-1252?Q?Re=3A_Someone=92s_Been_Siphoning_Data_Through_a?= =?windows-1252?Q?_Huge_Security_Hole_in_the_Internet?= In-Reply-To: References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: On Dec 6, 2013, at 1:39 PM, Brandon Galbraith wrote: > If your flows are a target, or your data is of an extremely sensitive > nature (diplomatic, etc), why aren't you moving those bits over > something more private than IP (point to point L2, MPLS)? This doesn't > work for the VoIP target mentioned, but foreign ministries should most > definitely not be trusting encryption alone. I will ruin someones weekend here, but: MPLS != Encryption. MPLS VPN = "Stick a label before the still unencrypted IP packet". MPLS doesn't secure your data, you are responsible for keeping it secure on the wire. - Jared From morrowc.lists at gmail.com Fri Dec 6 19:49:12 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Dec 2013 14:49:12 -0500 Subject: =?windows-1252?Q?Re=3A_Someone=92s_Been_Siphoning_Data_Through_a_Huge_S?= =?windows-1252?Q?ecurity_Hole_in_the_Internet?= In-Reply-To: References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: On Fri, Dec 6, 2013 at 2:48 PM, Jared Mauch wrote: > > On Dec 6, 2013, at 1:39 PM, Brandon Galbraith wrote: > >> If your flows are a target, or your data is of an extremely sensitive >> nature (diplomatic, etc), why aren't you moving those bits over >> something more private than IP (point to point L2, MPLS)? This doesn't >> work for the VoIP target mentioned, but foreign ministries should most >> definitely not be trusting encryption alone. > > I will ruin someones weekend here, but: > > MPLS != Encryption. MPLS VPN = "Stick a label before the still unencrypted IP packet". great, now how do I get a private link? > MPLS doesn't secure your data, you are responsible for keeping it secure on the wire. but, but,but! they told me it was private! From deleskie at gmail.com Fri Dec 6 19:55:49 2013 From: deleskie at gmail.com (deleskie at gmail.com) Date: Fri, 06 Dec 2013 11:55:49 -0800 Subject: =?utf-8?q?Re=3A_Someone=E2=80=99s_Been_Siphoning_Data_Through_a_Huge_Securit?= =?utf-8?q?y_Hole_in_the_Internet?= In-Reply-To: References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: <20131206195549.5558418.95684.2661@gmail.com> From eugen at imacandi.net Fri Dec 6 19:55:52 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Fri, 6 Dec 2013 21:55:52 +0200 Subject: =?windows-1252?Q?Re=3A_Someone=92s_Been_Siphoning_Data_Through_a_Huge_S?= =?windows-1252?Q?ecurity_Hole_in_the_Internet?= In-Reply-To: References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: On Fri, Dec 6, 2013 at 9:48 PM, Jared Mauch wrote: > > On Dec 6, 2013, at 1:39 PM, Brandon Galbraith > wrote: > > > If your flows are a target, or your data is of an extremely sensitive > > nature (diplomatic, etc), why aren't you moving those bits over > > something more private than IP (point to point L2, MPLS)? This doesn't > > work for the VoIP target mentioned, but foreign ministries should most > > definitely not be trusting encryption alone. > > I will ruin someones weekend here, but: > > MPLS != Encryption. MPLS VPN = "Stick a label before the still > unencrypted IP packet". > MPLS doesn't secure your data, you are responsible for keeping it secure > on the wire. > > It's always interesting to watch someone's expression when they hear that MPLS VPN, even if it says VPN in the name is not encrypted. Priceless every time :) From bortzmeyer at nic.fr Fri Dec 6 19:54:35 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 6 Dec 2013 20:54:35 +0100 Subject: =?utf-8?B?U29tZW9uZeKAmXMgQmVl?= =?utf-8?Q?n?= Siphoning Data Through a Huge Security Hole in the Internet In-Reply-To: <20131206173830.GL10793@leitl.org> References: <20131206173830.GL10793@leitl.org> Message-ID: <20131206195435.GA2811@sources.org> On Fri, Dec 06, 2013 at 06:38:31PM +0100, Eugen Leitl wrote a message of 357 lines which said: > http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ Except the remarks from Kapela, it has very little content above what was in the Renesys paper, discussed here two weeks ago. I suggest that Nanog readers read the Renesys blog rather than Wired. From bortzmeyer at nic.fr Fri Dec 6 19:57:39 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 6 Dec 2013 20:57:39 +0100 Subject: =?utf-8?B?U29tZW9uZeKAmXMgQmVl?= =?utf-8?Q?n?= Siphoning Data Through a Huge Security Hole in the Internet In-Reply-To: <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: <20131206195739.GB2811@sources.org> On Fri, Dec 06, 2013 at 01:05:54PM -0500, Jared Mauch wrote a message of 36 lines which said: > I've detected 11.6 million of these events since 2008 just looking at the > route-views data. Most recently the past two days 701 has done a large MITM of > traffic. The big novelty in the Renesys paper is the proof (with traceroute) that there was a return path, something which did not exist in the famous Pakistan Telecom case, or in most (all?) other BGP hijackings. This return path allows to attacker to really get access to the data with little chance of the victim noticing. That's something new. From surfer at mauigateway.com Fri Dec 6 20:07:22 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 6 Dec 2013 12:07:22 -0800 Subject: =?utf-8?B?UmU6IFNvbWVvbmXCuXMgQmVlbiBTaXBob25pbmcgRGF0YSBUaHJvdWdoIGEgSHVn?= =?utf-8?B?ZSBTZWN1cml0eSBIb2xlIGluIHRoZSBJbnRlcm5ldA==?= Message-ID: <20131206120722.7DEBC42F@resin13.mta.everyone.net> --- brandon.galbraith at gmail.com wrote: From: Brandon Galbraith someone who can splice into your undersea cables undetected. ----------------------------------------------------- Or detected and others framed? SE-WE-ME-4, FLAG, EASSy, SEACOM, etc... {;-) The above is a tin foil hat smiley :-) scott From bortzmeyer at nic.fr Fri Dec 6 20:10:36 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 6 Dec 2013 21:10:36 +0100 Subject: =?utf-8?B?U29tZW9uZeKAmXMgQmVl?= =?utf-8?Q?n?= Siphoning Data Through a Huge Security Hole in the Internet In-Reply-To: References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: <20131206201036.GA4442@sources.org> On Fri, Dec 06, 2013 at 12:39:16PM -0600, Brandon Galbraith wrote a message of 43 lines which said: > If your flows are a target, or your data is of an extremely > sensitive nature (diplomatic, etc), why aren't you moving those bits > over something more private than IP (point to point L2, And how can you be sure that the P2P L2 has not been provisioned as just an unencrypted virtual link over the regular Internet? A dedicated low-layers circuit is expensive... No, end-to-end encryption is the only serious solution. From eric-list at truenet.com Fri Dec 6 20:58:52 2013 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 6 Dec 2013 15:58:52 -0500 Subject: ICANN related question... Message-ID: <047301cef2c5$f84602e0$e8d208a0$@truenet.com> We have a customer that purchased a domain through a reseller of register.com. The Whois records only point to the actual company and the originating accredited registrar: register.com. Does anyone know of any hints to find out who the reseller is? Apparently Register.com can't supply us with that information. Just in case anyone is wondering: Domain ID:D96747839-LROR Domain Name:GIRLSINCDE.ORG Created On:21-Apr-2003 18:39:46 UTC Last Updated On:20-Nov-2013 22:11:57 UTC Expiration Date:21-Apr-2014 18:39:46 UTC Sponsoring Registrar:Register.com, Inc. (R71-LROR) Status:CLIENT TRANSFER PROHIBITED Registrant ID:F50A8CB8E137E659 Registrant Name:Lori Cooney Registrant Organization:Girls Incorporated of Delaware Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 From ebw at abenaki.wabanaki.net Fri Dec 6 21:14:37 2013 From: ebw at abenaki.wabanaki.net (ebw at abenaki.wabanaki.net) Date: Fri, 06 Dec 2013 13:14:37 -0800 Subject: ICANN related question... In-Reply-To: <047301cef2c5$f84602e0$e8d208a0$@truenet.com> References: <047301cef2c5$f84602e0$e8d208a0$@truenet.com> Message-ID: <201312062114.rB6LEbNC078646@nike.wampumpeag.net> why bother getting rcom to grovel through the records they should have kept (it happens to reseller model registrars, occasionally i'm asked if i can help a core registrant find their member (reseller)), just do a transfer request to another registrar (i'm not volunteering) and get the registrar-of-record changed. now you know the (gaining) r-of-r, and the (gaining) reseller (if any), and you're free to do whatever else you want. the hammer to use if rcom hangs due to enoresellerrecord is icann complaince, which in time is effective. -e From cidr-report at potaroo.net Fri Dec 6 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Dec 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201312062200.rB6M00Im090900@wattle.apnic.net> This report has been generated at Fri Dec 6 21:13:57 2013 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 29-11-13 485190 274098 30-11-13 485543 274016 01-12-13 485557 274109 02-12-13 484805 274254 03-12-13 485255 273951 04-12-13 484901 274262 05-12-13 484986 274625 06-12-13 485100 274200 AS Summary 45786 Number of ASes in routing system 18791 Number of ASes announcing only one prefix 4208 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118909696 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 06Dec13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 485084 274137 210947 43.5% All ASes AS28573 3421 96 3325 97.2% NET Servi?os de Comunica??o S.A. AS6389 3038 56 2982 98.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2720 178 2542 93.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4208 1727 2481 59.0% WINDSTREAM - Windstream Communications Inc AS4766 2955 961 1994 67.5% KIXS-AS-KR Korea Telecom AS22773 2299 440 1859 80.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18881 1708 31 1677 98.2% Global Village Telecom AS10620 2693 1070 1623 60.3% Telmex Colombia S.A. AS18566 2051 566 1485 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2956 1521 1435 48.5% TWTC - tw telecom holdings, inc. AS36998 1854 457 1397 75.4% SDN-MOBITEL AS1785 2048 669 1379 67.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS7303 1736 472 1264 72.8% Telecom Argentina S.A. AS4755 1793 582 1211 67.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1202 142 1060 88.2% VIETEL-AS-AP Vietel Corporation AS22561 1239 254 985 79.5% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1538 636 902 58.6% BSNL-NIB National Internet Backbone AS35908 922 93 829 89.9% VPLSNET - Krypt Technologies AS7545 2113 1301 812 38.4% TPG-INTERNET-AP TPG Telecom Limited AS18101 985 182 803 81.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1144 380 764 66.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 1098 369 729 66.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS701 1511 784 727 48.1% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS8151 1376 649 727 52.8% Uninet S.A. de C.V. AS6983 1292 578 714 55.3% ITCDELTA - ITC^Deltacom AS13977 855 143 712 83.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS6147 793 108 685 86.4% Telefonica del Peru S.A.A. AS855 732 58 674 92.1% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 1020 354 666 65.3% SEEDNET Digital United Inc. AS4788 873 228 645 73.9% TMNET-AS-AP TM Net, Internet Service Provider Total 54173 15085 39088 72.2% Top 30 total Possible Bogus Routes 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 27.100.7.0/24 AS56096 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS35916 MULTA-ASN1 - MULTACOM CORPORATION 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.114.140.0/22 AS32757 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 94.158.16.0/22 AS3257 TINET-BACKBONE Tinet SpA 94.158.20.0/22 AS3257 TINET-BACKBONE Tinet SpA 94.158.24.0/22 AS3257 TINET-BACKBONE Tinet SpA 94.158.28.0/22 AS3257 TINET-BACKBONE Tinet SpA 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.21.72.0/22 AS13244 103.21.75.0/24 AS13244 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 164.40.184.0/24 AS19821 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 185.42.96.0/22 AS47139 INDIGO-TADZHIKISTAN-AS CJSC INDIGO TAJIKISTAN 185.42.96.0/23 AS47139 INDIGO-TADZHIKISTAN-AS CJSC INDIGO TAJIKISTAN 185.42.98.0/23 AS47139 INDIGO-TADZHIKISTAN-AS CJSC INDIGO TAJIKISTAN 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.22.224.0/20 AS3322 193.22.238.0/23 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.202.8.0/21 AS3322 193.254.218.0/23 AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC 194.34.56.0/24 AS3549 GBLX Global Crossing Ltd. 194.34.56.0/25 AS3549 GBLX Global Crossing Ltd. 194.34.56.128/26 AS3549 GBLX Global Crossing Ltd. 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.79.48.0/22 AS39117 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 195.28.168.0/23 AS8655 195.114.4.0/23 AS41158 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.12.123.0/24 AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich 202.49.33.0/24 AS7657 VODAFONE-NZ-NGN-AS Vodafone NZ Ltd. 202.58.113.0/24 AS19161 202.59.240.0/24 AS17477 MCT-SYDNEY Macquarie Telecom 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.129.208.0/24 AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.32.0/24 AS25617 204.9.33.0/24 AS25617 204.9.34.0/24 AS25617 204.9.35.0/24 AS25617 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.13.12.0/22 AS32952 204.14.208.0/21 AS32952 204.14.213.0/24 AS40067 NEWEGG - Newegg Inc. 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.115.110.0/23 AS53709 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.120.0/22 AS32757 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.74.16.0/21 AS32952 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 208.92.224.0/22 AS32757 208.92.226.0/24 AS32757 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Dec 6 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Dec 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201312062200.rB6M01rT090916@wattle.apnic.net> BGP Update Report Interval: 28-Nov-13 -to- 05-Dec-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7545 61106 2.5% 112.1 -- TPG-INTERNET-AP TPG Telecom Limited 2 - AS8402 54975 2.3% 26.2 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 48061 2.0% 51.2 -- BSNL-NIB National Internet Backbone 4 - AS14287 31004 1.3% 5167.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 5 - AS10620 23186 1.0% 11.9 -- Telmex Colombia S.A. 6 - AS13118 22847 0.9% 11423.5 -- ASN-YARTELECOM OJSC Rostelecom 7 - AS29990 22060 0.9% 22060.0 -- ASN-APPNEXUS - AppNexus, Inc 8 - AS36753 21592 0.9% 10796.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 9 - AS24964 20919 0.9% 445.1 -- EVO-LTD MOBILTEL EAD 10 - AS4766 20619 0.9% 7.3 -- KIXS-AS-KR Korea Telecom 11 - AS7029 19366 0.8% 9.3 -- WINDSTREAM - Windstream Communications Inc 12 - AS4775 18892 0.8% 2698.9 -- GLOBE-TELECOM-AS Globe Telecoms 13 - AS4538 18347 0.8% 32.8 -- ERX-CERNET-BKB China Education and Research Network Center 14 - AS24085 17912 0.7% 471.4 -- QTSC-AS-VN Quang Trung Software City Development Company 15 - AS28021 17501 0.7% 2187.6 -- ASEGLOB S.A. 16 - AS37004 16453 0.7% 658.1 -- SUBURBAN-AS 17 - AS17488 15662 0.7% 28.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 18 - AS13999 15417 0.6% 98.2 -- Mega Cable, S.A. de C.V. 19 - AS45544 14250 0.6% 619.6 -- PAVIETNAM-AS-VN PAVIETNAM Co.,Ltd 20 - AS27738 14104 0.6% 24.5 -- Ecuadortelecom S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29990 22060 0.9% 22060.0 -- ASN-APPNEXUS - AppNexus, Inc 2 - AS13118 22847 0.9% 11423.5 -- ASN-YARTELECOM OJSC Rostelecom 3 - AS36753 21592 0.9% 10796.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 4 - AS54465 7287 0.3% 7287.0 -- QPM-AS-1 - QuickPlay Media Inc. 5 - AS59217 6173 0.3% 6173.0 -- AZONNELIMITED-AS-AP Azonne Limited 6 - AS14287 31004 1.3% 5167.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 7 - AS22592 4294 0.2% 4294.0 -- HBP - HBP, Inc. 8 - AS60345 8026 0.3% 4013.0 -- NBITI-AS Nahjol Balagheh International Research Institution 9 - AS52640 3053 0.1% 3053.0 -- ULTRANET SCM - COMUNICACAO MULTIMIDIA LTDA. 10 - AS4775 18892 0.8% 2698.9 -- GLOBE-TELECOM-AS Globe Telecoms 11 - AS32244 6719 0.3% 2239.7 -- LIQUID-WEB-INC - Liquid Web, Inc. 12 - AS37367 2208 0.1% 2208.0 -- CALLKEY 13 - AS28021 17501 0.7% 2187.6 -- ASEGLOB S.A. 14 - AS62431 1975 0.1% 1975.0 -- NCSC-IE-AS National Cyber Security Centre 15 - AS21271 5661 0.2% 1887.0 -- SOTELMABGP 16 - AS7202 8633 0.4% 1726.6 -- FAMU - Florida A & M University 17 - AS45556 1087 0.1% 1087.0 -- SCANCOM-AS-VN Scancom Vietnam Ltd 18 - AS31245 969 0.0% 969.0 -- ATI-ISP 19 - AS37453 9415 0.4% 941.5 -- VODACOM-CONGO 20 - AS37504 1802 0.1% 901.0 -- Meninx TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22846 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.220.0/22 22060 0.9% AS29990 -- ASN-APPNEXUS - AppNexus, Inc 3 - 12.68.46.0/24 11241 0.4% AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 4 - 64.240.174.0/24 10351 0.4% AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 6 - 222.127.0.0/24 9371 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 38.87.227.0/24 9027 0.3% AS37453 -- VODACOM-CONGO 8 - 192.58.232.0/24 7807 0.3% AS6629 -- NOAA-AS - NOAA 9 - 206.152.15.0/24 7287 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 10 - 220.244.72.0/21 6770 0.3% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 11 - 67.210.190.0/23 6709 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 12 - 14.202.160.0/22 6545 0.3% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 13 - 216.162.0.0/20 6204 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 14 - 208.73.244.0/22 6202 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 15 - 208.78.116.0/22 6198 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 16 - 208.88.232.0/22 6196 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 17 - 208.70.20.0/22 6180 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 18 - 103.243.164.0/22 6173 0.2% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 19 - 67.210.188.0/23 6153 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 20 - 217.64.96.0/20 5655 0.2% AS21271 -- SOTELMABGP 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 lists at tigertech.com Fri Dec 6 22:34:07 2013 From: lists at tigertech.com (Robert L Mathews) Date: Fri, 06 Dec 2013 14:34:07 -0800 Subject: ICANN related question... In-Reply-To: <201312062114.rB6LEbNC078646@nike.wampumpeag.net> References: <047301cef2c5$f84602e0$e8d208a0$@truenet.com> <201312062114.rB6LEbNC078646@nike.wampumpeag.net> Message-ID: <52A250DF.6080404@tigertech.com> On 12/6/13, 1:14 PM, ebw at abenaki.wabanaki.net wrote: > why bother getting rcom to grovel through the records they should have > kept (it happens to reseller model registrars, occasionally i'm asked > if i can help a core registrant find their member (reseller)), just do > a transfer request to another registrar (i'm not volunteering) and get > the registrar-of-record changed. > > now you know the (gaining) r-of-r, and the (gaining) reseller (if any), > and you're free to do whatever else you want. Unfortunately, that won't work, because: >Status:CLIENT TRANSFER PROHIBITED ... means that the domain name is locked against transfers, and someone will first need to login at the existing reseller to unlock it (and probably to get the transfer authorization code, too). To the original poster: Why won't Register.com give you the reseller name? Is it because you're not one of the people listed in their account records? If so, I can't fully blame them; my company (also a registrar, although we don't have resellers) also gives out as little information as possible to "strangers" to discourage social engineering hijacking attempts. Many companies will confirm information but not volunteer it, leading to boring conversations along the lines of "Well, I can't tell you, but can you think of the name of anyone at your company that might have registered the domain name? No... no... no...". Have the person listed in the Register.com records call them and you may get further. > the hammer to use if rcom hangs due to enoresellerrecord is icann complaince, > which in time is effective. Sadly, ICANN compliance will not do a thing for any individual domain name incident. Their mechanism for such things is to pass complaints on to the registrar, even when the registrar IS the problem, as if they're the Better Business Bureau. I've never seen them intervene in an individual domain name case. I once spent a great deal of my time trying to get ICANN compliance to do something in a few egregious cases before realizing that they explicitly do not see that as their role. I'd initially assumed their unhelpfulness was gross incompetence, but it turned out to be a sort of reverse Hanlon's razor. -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ From mike at mtcc.com Sat Dec 7 01:14:57 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 06 Dec 2013 17:14:57 -0800 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A1D71A.4040801@amplex.net> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> <52A11BDC.1010307@philkarn.ne! t> <52A1D71A.4040801@amplex.net> Message-ID: <52A27691.3000005@mtcc.com> On 12/06/2013 05:54 AM, Mark Radabaugh wrote: > > I realize most of the NANOG operators are not running end user > networks anymore. Real consumption data: > > Monthly_GB Count Percent > <100GB 3658 90% > 100-149 368 10% > 150-199 173 4.7% > 200-249 97 2.6% > 250-299 50 1.4% > 300-399 27 0.7% > 400-499 9 0.25% > 500-599 4 0.1% > 600-699 4 0.1% > 700-799 3 0.1% > >800 1 0.03% > > Overall average: 36GB/mo > > > The user at 836MB per month is on a 3.5Mbps plan paying $49.95/mo. > Do we do anything about it? No - because our current AUP and policies > say he can do that. > Thanks for the stats, real life is always refreshing :) It seems to me -- all things being equal -- that the real question is whether Mr. Hog is impacting your other users. If he's not, then what difference does it make if he consumes the bits, or if the bits over the air are not consumed at all? Is it because of transit costs? That seems unlikely because Mr. Hog's 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude). If he is impacting other users, doesn't this devolve into a shaping problem which is there regardless of whether it's him or 4 people at 200GB? Mike From cb.list6 at gmail.com Sat Dec 7 01:34:32 2013 From: cb.list6 at gmail.com (cb.list6) Date: Fri, 6 Dec 2013 17:34:32 -0800 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A27691.3000005@mtcc.com> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> <52A1D71A.4040801@amplex.net> <52A27691.3000005@mtcc.com> Message-ID: On Dec 6, 2013 5:16 PM, "Michael Thomas" wrote: > > On 12/06/2013 05:54 AM, Mark Radabaugh wrote: >> >> >> I realize most of the NANOG operators are not running end user networks anymore. Real consumption data: >> >> Monthly_GB Count Percent >> <100GB 3658 90% >> 100-149 368 10% >> 150-199 173 4.7% >> 200-249 97 2.6% >> 250-299 50 1.4% >> 300-399 27 0.7% >> 400-499 9 0.25% >> 500-599 4 0.1% >> 600-699 4 0.1% >> 700-799 3 0.1% >> >800 1 0.03% >> >> Overall average: 36GB/mo >> >> >> The user at 836MB per month is on a 3.5Mbps plan paying $49.95/mo. Do we do anything about it? No - because our current AUP and policies say he can do that. >> > > Thanks for the stats, real life is always refreshing :) > > It seems to me -- all things being equal -- that the real question is whether Mr. Hog is impacting your > other users. If he's not, then what difference does it make if he consumes the bits, or if the bits over > the air are not consumed at all? Is it because of transit costs? That seems unlikely because Mr. Hog's > 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude). > > If he is impacting other users, doesn't this devolve into a shaping problem which is there regardless > of whether it's him or 4 people at 200GB? > > Mike > In a cell network, mr. Hog is most definately negatively impacting users on the same radio sector and backhaul, both of which are dimensioned and operated (like the internet as a whole) on statistical multiplexing. If mr hog is blasting 50mbs on a 100meg link 24/7, nobody will perceive 100mbs since 50mbs is always consumed by mr hog. Statistical multiplexing works great 99% of the time, and i personally would rather not engineer the whole system to fight the 1% extreme users CB From mark at amplex.net Sat Dec 7 01:58:03 2013 From: mark at amplex.net (Mark Radabaugh) Date: Fri, 06 Dec 2013 20:58:03 -0500 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A27691.3000005@mtcc.com> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> <52A11BDC.1010307@philkarn.ne! t> <52A1D71A.4040801@amplex.net> <52A27691.3000005@mtcc.com> Message-ID: <52A280AB.20001@amplex.net> On 12/6/13 8:14 PM, Michael Thomas wrote: > > Thanks for the stats, real life is always refreshing :) > > It seems to me -- all things being equal -- that the real question is > whether Mr. Hog is impacting your > other users. If he's not, then what difference does it make if he > consumes the bits, or if the bits over > the air are not consumed at all? Is it because of transit costs? That > seems unlikely because Mr. Hog's > 800gb is dwarfed by your 3658*36gb (almost three orders of magnitude). > > If he is impacting other users, doesn't this devolve into a shaping > problem which is there regardless > of whether it's him or 4 people at 200GB? > > Mike > Thank you for the response! Mr. Hog impacts other customers in that he blows the over subscription model for that particular tower site (and specifically the sector) well out of the norm. This specific sector has a capacity of ~10.5Mbps download so his continuous 3.5Mbps is noticed by other customers. It's a last mile capacity issue, not a transit cost. Heck - transit is cheap these days and we have more than 50% spare transit capacity. Last mile is expensive. Most sites have sector capacities of 35 or 70Mbps (and Mr. Hogs will be updated fairly soon). What I'm really trying to figure out is how to offer higher speed packages (15Mbps or higher) without having a 24x7 user kill the over-subscription ratio or forcing a early upgrade to the tower site. I understand the argument that you should have full capacity available for the peak hour - but that peak hour doesn't really exist anymore with home users. The only real usage dropoff is from 12:30am to about 7am. Do the top 10% cause any problems? Not currently since we kept the available speeds low. What I am trying to figure out is how to offer higher speeds for the average user without having to resort to lots of weaseling in the marketing / AUP, etc. Putting some sane limits on the upper few percent seems to make the most sense. I'm not set on billing for overages. A rate limit at the cutoff would also be workable. I'm not willing to do the hidden cap / fire the top user method. Mark -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 x 1021 From mysidia at gmail.com Sat Dec 7 03:40:21 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 6 Dec 2013 21:40:21 -0600 Subject: ICANN related question... In-Reply-To: <52A250DF.6080404@tigertech.com> References: <047301cef2c5$f84602e0$e8d208a0$@truenet.com> <201312062114.rB6LEbNC078646@nike.wampumpeag.net> <52A250DF.6080404@tigertech.com> Message-ID: On Fri, Dec 6, 2013 at 4:34 PM, Robert L Mathews wrote: > > now you know the (gaining) r-of-r, and the (gaining) reseller (if any), > > and you're free to do whatever else you want. > ICANN is one potential recourse against the registrar, if non-cooperative with the registrant; another one is the courts, and finally: there is the court of public opinion. > Unfortunately, that won't work, because: > >Status:CLIENT TRANSFER PROHIBITED > > ... means that the domain name is locked against transfers, and someone > will first need to login at the existing reseller to unlock it (and > probably to get the transfer authorization code, too). > This is a technical block against transfer, that the losing registrar must not refuse to allow the registrant to remove. http://archive.icann.org/en/transfers/policy-12jul04.htm "Instances when the requested change of Registrar may not be denied include, but are not limited to: ... * Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request. " Sadly, ICANN compliance will not do a thing for any individual domain > name incident. Their mechanism for such things is to pass complaints on > to the registrar, even when the registrar IS the problem, as if they're > the Better Business Bureau. I've never seen them intervene in an > individual domain name case Perhaps, there need to be some complaints to ICANN about ICANN then. Or to other community entities about an apparent lack of competent authority by ICANN, to even successfully implement their own policies. > Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ > -- -JH From j at arpa.com Sat Dec 7 16:26:12 2013 From: j at arpa.com (jamie rishaw) Date: Sat, 7 Dec 2013 10:26:12 -0600 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: References: Message-ID: (A little late but) it's reachable for me -- Funny tho that something at cisco is IPv6 via a v4<->v6 (2001::) :-) jamie On Thu, Dec 5, 2013 at 8:16 PM, Geraint Jones wrote: > Its the reason deduplication makes the storage savings it does :) > -- > Geraint Jones > > > > > On 6/12/13 2:52 pm, "Richard Porter" wrote: > > >*Sarcasm* but lawyers seem to think it is REALLY important to add that > >load to email servers, backup servers and storage :). I wonder how much > >extra storage those simple extra bits/bytes have taken over the years? > > > >~Richard > > > >On Dec 5, 2013, at 6:39 PM, Rogan Schlassa > >wrote: > > > >> Please dont reply back with such legal disclaimers. It is basically > >>SPAM > >> and of course nonsense. > >> > >> The thought that you can send a email and force your companies terms on > >>us > >> is rediculous. > >> > >> If CISCO forces that in your sig then for one tell them to fuck off and > >>two > >> use a different email. > >> On Dec 5, 2013 3:56 PM, "John Stuppi (jstuppi)" > >>wrote: > >> > >>> Thanks folks. Blogs.cisco.com should be back up now for both IPv4 and > >>>v6. > >>> > >>> Thanks, > >>> John > >>> > >>> "We can't help everyone, but everyone can help someone." > >>> > >>> > >>> > >>> > >>> John Stuppi, CISSP > >>> Technical Leader > >>> Strategic Security Research > >>> jstuppi at cisco.com > >>> Phone: +1 732 516 5994 > >>> Mobile: 732 319 3886 > >>> > >>> CCIE, Security - 11154 > >>> Cisco Systems > >>> Mail Stop INJ01/2/ > >>> 111 Wood Avenue South > >>> Iselin, New Jersey 08830 > >>> United States > >>> Cisco.com > >>> > >>> > >>> > >>> Think before you print. > >>> This email may contain confidential and privileged material for the > >>>sole > >>> use of the intended recipient. Any review, use, distribution or > >>>disclosure > >>> by others is strictly prohibited. If you are not the intended > >>>recipient (or > >>> authorized to receive for the recipient), please contact the sender by > >>> reply email and delete all copies of this message. > >>> For corporate legal information go to: > >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Jared Mauch [mailto:jared at puck.nether.net] > >>> Sent: Wednesday, December 04, 2013 9:23 AM > >>> To: Henri Wahl > >>> Cc: NANOG list > >>> Subject: Re: blogs.cisco.com not available via IPv6 > >>> > >>> I'm seeing it down via IPv6: > >>> > >>> * Trying 2600:1407:9:295::90... > >>> * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) > >>>> GET / HTTP/1.1 > >>>> User-Agent: curl/7.30.0 > >>>> Host: www.cisco.com > >>>> Accept: */* > >>>> > >>> < HTTP/1.1 200 OK > >>> * Server Apache is not blacklisted > >>> > >>> > >>> * About to connect() to blogs.cisco.com port 80 (#0) > >>> * Trying 2001:4800:13c1:10::178... > >>> ^C > >>> > >>> - Jared > >>> > >>> On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: > >>> > >>>> Hi, > >>>> can anybody from Cisco confirm that blogs.cisco.com > >>>> (2001:4800:13c1:10::178) is not available via IPv6? > >>>> Regards > >>>> > >>>> -- > >>>> Henri Wahl > >>>> > >>>> IT Department > >>>> Leibniz-Institut fuer Festkoerper- u. > >>>> Werkstoffforschung Dresden > >>>> > >>>> tel: (03 51) 46 59 - 797 > >>>> email: h.wahl at ifw-dresden.de > >>>> http://www.ifw-dresden.de > >>>> > >>>> Nagios status monitor Nagstamon: > >>>> http://nagstamon.ifw-dresden.de > >>>> > >>>> DHCPv6 server dhcpy6d: > >>>> http://dhcpy6d.ifw-dresden.de > >>>> > >>>> IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. > >>>> 1369 > >>>> Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle > >>>> <0x1FBA0942.asc> > >>> > >>> > >>> > >>> > > > > > > -- "sharp, dry wit and brash in his dealings with contestants." - Forbes If voting didn't matter, the GOP wouldn't make it more difficult than buying a gun. /* - teh jamie. ; uri -> http://about.me/jgr */ From mksmith at mac.com Sat Dec 7 17:30:42 2013 From: mksmith at mac.com (Michael Smith) Date: Sat, 07 Dec 2013 09:30:42 -0800 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: References: Message-ID: <50DE5C4F-2C11-4529-B241-93D37E47C3A0@mac.com> On Dec 7, 2013, at 8:26 AM, jamie rishaw wrote: > (A little late but) it's reachable for me -- Funny tho that something at > cisco is IPv6 via a v4<->v6 (2001::) :-) > > jamie Huh? 2001:4800::/29 is owned by Rackspace. It's native all the way from "here" anyway. Mike From jared at puck.nether.net Sat Dec 7 17:35:44 2013 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 7 Dec 2013 12:35:44 -0500 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: References: Message-ID: Jamie, methinks you are confusing 2002 with 2001.... Jared Mauch > On Dec 7, 2013, at 11:26 AM, jamie rishaw wrote: > > (A little late but) it's reachable for me -- Funny tho that something at > cisco is IPv6 via a v4<->v6 (2001::) :-) > > jamie > > >> On Thu, Dec 5, 2013 at 8:16 PM, Geraint Jones wrote: >> >> Its the reason deduplication makes the storage savings it does :) >> -- >> Geraint Jones >> >> >> >> >>> On 6/12/13 2:52 pm, "Richard Porter" wrote: >>> >>> *Sarcasm* but lawyers seem to think it is REALLY important to add that >>> load to email servers, backup servers and storage :). I wonder how much >>> extra storage those simple extra bits/bytes have taken over the years? >>> >>> ~Richard >>> >>> On Dec 5, 2013, at 6:39 PM, Rogan Schlassa >>> wrote: >>> >>>> Please dont reply back with such legal disclaimers. It is basically >>>> SPAM >>>> and of course nonsense. >>>> >>>> The thought that you can send a email and force your companies terms on >>>> us >>>> is rediculous. >>>> >>>> If CISCO forces that in your sig then for one tell them to fuck off and >>>> two >>>> use a different email. >>>> On Dec 5, 2013 3:56 PM, "John Stuppi (jstuppi)" >>>> wrote: >>>> >>>>> Thanks folks. Blogs.cisco.com should be back up now for both IPv4 and >>>>> v6. >>>>> >>>>> Thanks, >>>>> John >>>>> >>>>> "We can't help everyone, but everyone can help someone." >>>>> >>>>> >>>>> >>>>> >>>>> John Stuppi, CISSP >>>>> Technical Leader >>>>> Strategic Security Research >>>>> jstuppi at cisco.com >>>>> Phone: +1 732 516 5994 >>>>> Mobile: 732 319 3886 >>>>> >>>>> CCIE, Security - 11154 >>>>> Cisco Systems >>>>> Mail Stop INJ01/2/ >>>>> 111 Wood Avenue South >>>>> Iselin, New Jersey 08830 >>>>> United States >>>>> Cisco.com >>>>> >>>>> >>>>> >>>>> Think before you print. >>>>> This email may contain confidential and privileged material for the >>>>> sole >>>>> use of the intended recipient. Any review, use, distribution or >>>>> disclosure >>>>> by others is strictly prohibited. If you are not the intended >>>>> recipient (or >>>>> authorized to receive for the recipient), please contact the sender by >>>>> reply email and delete all copies of this message. >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Jared Mauch [mailto:jared at puck.nether.net] >>>>> Sent: Wednesday, December 04, 2013 9:23 AM >>>>> To: Henri Wahl >>>>> Cc: NANOG list >>>>> Subject: Re: blogs.cisco.com not available via IPv6 >>>>> >>>>> I'm seeing it down via IPv6: >>>>> >>>>> * Trying 2600:1407:9:295::90... >>>>> * Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0) >>>>>> GET / HTTP/1.1 >>>>>> User-Agent: curl/7.30.0 >>>>>> Host: www.cisco.com >>>>>> Accept: */* >>>>> < HTTP/1.1 200 OK >>>>> * Server Apache is not blacklisted >>>>> >>>>> >>>>> * About to connect() to blogs.cisco.com port 80 (#0) >>>>> * Trying 2001:4800:13c1:10::178... >>>>> ^C >>>>> >>>>> - Jared >>>>> >>>>>> On Dec 4, 2013, at 8:37 AM, Henri Wahl wrote: >>>>>> >>>>>> Hi, >>>>>> can anybody from Cisco confirm that blogs.cisco.com >>>>>> (2001:4800:13c1:10::178) is not available via IPv6? >>>>>> Regards >>>>>> >>>>>> -- >>>>>> Henri Wahl >>>>>> >>>>>> IT Department >>>>>> Leibniz-Institut fuer Festkoerper- u. >>>>>> Werkstoffforschung Dresden >>>>>> >>>>>> tel: (03 51) 46 59 - 797 >>>>>> email: h.wahl at ifw-dresden.de >>>>>> http://www.ifw-dresden.de >>>>>> >>>>>> Nagios status monitor Nagstamon: >>>>>> http://nagstamon.ifw-dresden.de >>>>>> >>>>>> DHCPv6 server dhcpy6d: >>>>>> http://dhcpy6d.ifw-dresden.de >>>>>> >>>>>> IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. >>>>>> 1369 >>>>>> Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle >>>>>> <0x1FBA0942.asc> > > > -- > "sharp, dry wit and brash in his dealings with contestants." - Forbes > If voting didn't matter, the GOP wouldn't make it more difficult than > buying a gun. > /* - teh jamie. ; uri -> http://about.me/jgr */ From jra at baylink.com Sat Dec 7 18:18:52 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 7 Dec 2013 13:18:52 -0500 (EST) Subject: =?utf-8?Q?Re:_Someone=E2=80=99s_Been_Siphoning_Data_Throu?= =?utf-8?Q?gh_a_Huge_Security_Hole_in_the_Internet?= In-Reply-To: Message-ID: <11294966.72.1386440332965.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Christopher Morrow" > > MPLS != Encryption. MPLS VPN = "Stick a label before the still > > unencrypted IP packet". > > great, now how do I get a private link? > > > MPLS doesn't secure your data, you are responsible for keeping it > > secure on the wire. > > but, but,but! they told me it was private! As someone -- I think it might have been you, Chris :-) -- pointed out to me about 6 months ago when I scoffed at SCADA networks that weren't properly air-gapped, you can't even trust a "private T-1" -- how do you know that an attacker hasn't put a mid-span DACS in monitor mode? Unless you have copper conductivity from end to end, and pressurized conduit with monitors, you can't bet on anything. Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From j at arpa.com Sat Dec 7 19:41:39 2013 From: j at arpa.com (jamie rishaw) Date: Sat, 7 Dec 2013 13:41:39 -0600 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: References: Message-ID: *Has a Rick Perry "Oops." moment*. Thanks, Jared. ..Again. :) -j From jared at puck.nether.net Sat Dec 7 20:05:09 2013 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 7 Dec 2013 15:05:09 -0500 Subject: =?windows-1252?Q?Re=3A_Someone=92s_Been_Siphoning_Data_Through_a?= =?windows-1252?Q?_Huge_Security_Hole_in_the_Internet?= In-Reply-To: <20131206195739.GB2811@sources.org> References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> <20131206195739.GB2811@sources.org> Message-ID: <2BDDB9A8-F674-4815-A7F8-53B9B355EB0E@puck.nether.net> On Dec 6, 2013, at 2:57 PM, Stephane Bortzmeyer wrote: > On Fri, Dec 06, 2013 at 01:05:54PM -0500, > Jared Mauch wrote > a message of 36 lines which said: > >> I've detected 11.6 million of these events since 2008 just looking at the >> route-views data. Most recently the past two days 701 has done a large MITM of >> traffic. > > The big novelty in the Renesys paper is the proof (with traceroute) > that there was a return path, something which did not exist in the > famous Pakistan Telecom case, or in most (all?) other BGP > hijackings. This return path allows to attacker to really get access > to the data with little chance of the victim noticing. That's > something new. I've been sending the traceroutes to networks for years to get them to clean up their acts. I guess the lesson is publish often? Folks can see the prefixes involved here: http://puck.nether.net/bgp/leakinfo.cgi The ASN search works best. I'll work on optimizing the prefix stuff as it's not returning "promptly". - Jared From matthew at corp.crocker.com Sat Dec 7 20:14:17 2013 From: matthew at corp.crocker.com (Matthew Crocker) Date: Sat, 7 Dec 2013 15:14:17 -0500 Subject: Cogent & Level 3 routing issue? Message-ID: Anyone seeing issues between Cogent & Level3 in NYC? I have Sprint & Cogent for bandwidth. Everything has been humming along for a couple years just fine. Yesterday around 8:00AM my BGP session with Cogent flapped. Now, when my Cogent BGP is up I get 100% packet loss in level3 land. When Cogent BGP is down (i.e. I?m running solely on Sprint) Everything is fine. I have an open ticket with Cogent. They say they have a ?capacity issue? with level3 that has been escalated to executive levels. With Sprint & Cogent BGP UP I see traceroutes showing traffic leaving me on Sprint but returning on Cogent (and failing at level3). I?m guessing it is the level3/cogent border With Sprint UP & Cogent Down I see trace routes showing traffic on to/from on Sprint just fine. Anyone else having issues? -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com From jason at unlimitednet.us Sat Dec 7 20:40:51 2013 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 07 Dec 2013 15:40:51 -0500 Subject: Cogent & Level 3 routing issue? In-Reply-To: References: Message-ID: <52A387D3.6000907@unlimitednet.us> Unfortunately Cogent has a lot of peering issues. We use them in our network blend and we have been having lots of problems with traffic outbound to Comcast. It looks like from South Bend, Indiana on Cogent to Chicago / Level 3 we are getting a very tiny amount of packet loss and a higher than 'normal' latency of 35ms+. Where are you connected to Cogent at? And what destination are you going to on Level 3? Best Regards, -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure www.unlimitednet.us jason at unlimitednet.us twitter: @unlimitednet On 12/7/13 3:14 PM, Matthew Crocker wrote: > Anyone seeing issues between Cogent & Level3 in NYC? > > I have Sprint & Cogent for bandwidth. Everything has been humming along for a couple years just fine. Yesterday around 8:00AM my BGP session with Cogent flapped. Now, when my Cogent BGP is up I get 100% packet loss in level3 land. When Cogent BGP is down (i.e. I?m running solely on Sprint) Everything is fine. > > I have an open ticket with Cogent. They say they have a ?capacity issue? with level3 that has been escalated to executive levels. > > With Sprint & Cogent BGP UP > I see traceroutes showing traffic leaving me on Sprint but returning on Cogent (and failing at level3). I?m guessing it is the level3/cogent border > > With Sprint UP & Cogent Down > I see trace routes showing traffic on to/from on Sprint just fine. > > > Anyone else having issues? > > -Matt > > -- > Matthew S. Crocker > President > Crocker Communications, Inc. > PO BOX 710 > Greenfield, MA 01302-0710 > > E: matthew at crocker.com > P: (413) 746-2760 > F: (413) 746-3704 > W: http://www.crocker.com > > > > From eric-list at truenet.com Sat Dec 7 22:33:13 2013 From: eric-list at truenet.com (Eric Tykwinski) Date: Sat, 7 Dec 2013 17:33:13 -0500 Subject: Cogent & Level 3 routing issue? In-Reply-To: <52A387D3.6000907@unlimitednet.us> References: <52A387D3.6000907@unlimitednet.us> Message-ID: Honestly from the Internet Health Report, I've noticed connections between Level3 and Cogent are red quite a bit. http://www.internethealthreport.com/ Bad samples or peering issues could be the cause either way, but it's been ongoing for awhile. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 On Dec 7, 2013, at 3:40 PM, Jason Canady wrote: > Unfortunately Cogent has a lot of peering issues. We use them in our network blend and we have been having lots of problems with traffic outbound to Comcast. It looks like from South Bend, Indiana on Cogent to Chicago / Level 3 we are getting a very tiny amount of packet loss and a higher than 'normal' latency of 35ms+. > > Where are you connected to Cogent at? And what destination are you going to on Level 3? > > Best Regards, > > -- > > Jason Canady > Unlimited Net, LLC > Responsive, Reliable, Secure > > www.unlimitednet.us > jason at unlimitednet.us > twitter: @unlimitednet > > On 12/7/13 3:14 PM, Matthew Crocker wrote: >> Anyone seeing issues between Cogent & Level3 in NYC? >> >> I have Sprint & Cogent for bandwidth. Everything has been humming along for a couple years just fine. Yesterday around 8:00AM my BGP session with Cogent flapped. Now, when my Cogent BGP is up I get 100% packet loss in level3 land. When Cogent BGP is down (i.e. I?m running solely on Sprint) Everything is fine. >> >> I have an open ticket with Cogent. They say they have a ?capacity issue? with level3 that has been escalated to executive levels. >> >> With Sprint & Cogent BGP UP >> I see traceroutes showing traffic leaving me on Sprint but returning on Cogent (and failing at level3). I?m guessing it is the level3/cogent border >> >> With Sprint UP & Cogent Down >> I see trace routes showing traffic on to/from on Sprint just fine. >> >> >> Anyone else having issues? >> >> -Matt >> >> -- >> Matthew S. Crocker >> President >> Crocker Communications, Inc. >> PO BOX 710 >> Greenfield, MA 01302-0710 >> >> E: matthew at crocker.com >> P: (413) 746-2760 >> F: (413) 746-3704 >> W: http://www.crocker.com >> >> >> >> > > From matthew at corp.crocker.com Sun Dec 8 00:58:41 2013 From: matthew at corp.crocker.com (Matthew Crocker) Date: Sat, 7 Dec 2013 19:58:41 -0500 Subject: Cogent & Level 3 routing issue? In-Reply-To: <52A387D3.6000907@unlimitednet.us> References: <52A387D3.6000907@unlimitednet.us> Message-ID: <4CC28F49-FB40-4945-8B30-9C7CBB9F0EA6@corp.crocker.com> On Dec 7, 2013, at 3:40 PM, Jason Canady wrote: > Unfortunately Cogent has a lot of peering issues. We use them in our network blend and we have been having lots of problems with traffic outbound to Comcast. It looks like from South Bend, Indiana on Cogent to Chicago / Level 3 we are getting a very tiny amount of packet loss and a higher than 'normal' latency of 35ms+. Yeah, I know they are always my secondary, never my primary > > Where are you connected to Cogent at? And what destination are you going to on Level 3? > Boston (300 Bent) but I think they haul it to 1 Summer St A bunch of sites fail but www.cnn.com is one that comes to mind. > Best Regards, > > -- > > Jason Canady > Unlimited Net, LLC > Responsive, Reliable, Secure > > www.unlimitednet.us > jason at unlimitednet.us > twitter: @unlimitednet > > On 12/7/13 3:14 PM, Matthew Crocker wrote: >> Anyone seeing issues between Cogent & Level3 in NYC? >> >> I have Sprint & Cogent for bandwidth. Everything has been humming along for a couple years just fine. Yesterday around 8:00AM my BGP session with Cogent flapped. Now, when my Cogent BGP is up I get 100% packet loss in level3 land. When Cogent BGP is down (i.e. I?m running solely on Sprint) Everything is fine. >> >> I have an open ticket with Cogent. They say they have a ?capacity issue? with level3 that has been escalated to executive levels. >> >> With Sprint & Cogent BGP UP >> I see traceroutes showing traffic leaving me on Sprint but returning on Cogent (and failing at level3). I?m guessing it is the level3/cogent border >> >> With Sprint UP & Cogent Down >> I see trace routes showing traffic on to/from on Sprint just fine. >> >> >> Anyone else having issues? >> >> -Matt >> >> -- >> Matthew S. Crocker >> President >> Crocker Communications, Inc. >> PO BOX 710 >> Greenfield, MA 01302-0710 >> >> E: matthew at crocker.com >> P: (413) 746-2760 >> F: (413) 746-3704 >> W: http://www.crocker.com >> >> >> >> > > > From brandon.galbraith at gmail.com Sun Dec 8 01:17:07 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sat, 7 Dec 2013 19:17:07 -0600 Subject: Cogent & Level 3 routing issue? In-Reply-To: <4CC28F49-FB40-4945-8B30-9C7CBB9F0EA6@corp.crocker.com> References: <52A387D3.6000907@unlimitednet.us> <4CC28F49-FB40-4945-8B30-9C7CBB9F0EA6@corp.crocker.com> Message-ID: Possibly related to their mass outage last night around 5:12am CST (ticket number HD0000005596458). We're connected at their 427 S La Salle POP in Chicago. brandon On Sat, Dec 7, 2013 at 6:58 PM, Matthew Crocker wrote: > > On Dec 7, 2013, at 3:40 PM, Jason Canady wrote: > >> Unfortunately Cogent has a lot of peering issues. We use them in our network blend and we have been having lots of problems with traffic outbound to Comcast. It looks like from South Bend, Indiana on Cogent to Chicago / Level 3 we are getting a very tiny amount of packet loss and a higher than 'normal' latency of 35ms+. > > Yeah, I know they are always my secondary, never my primary >> >> Where are you connected to Cogent at? And what destination are you going to on Level 3? >> > > Boston (300 Bent) but I think they haul it to 1 Summer St > > A bunch of sites fail but www.cnn.com is one that comes to mind. > >> Best Regards, >> >> -- >> >> Jason Canady >> Unlimited Net, LLC >> Responsive, Reliable, Secure >> >> www.unlimitednet.us >> jason at unlimitednet.us >> twitter: @unlimitednet >> >> On 12/7/13 3:14 PM, Matthew Crocker wrote: >>> Anyone seeing issues between Cogent & Level3 in NYC? >>> >>> I have Sprint & Cogent for bandwidth. Everything has been humming along for a couple years just fine. Yesterday around 8:00AM my BGP session with Cogent flapped. Now, when my Cogent BGP is up I get 100% packet loss in level3 land. When Cogent BGP is down (i.e. I?m running solely on Sprint) Everything is fine. >>> >>> I have an open ticket with Cogent. They say they have a ?capacity issue? with level3 that has been escalated to executive levels. >>> >>> With Sprint & Cogent BGP UP >>> I see traceroutes showing traffic leaving me on Sprint but returning on Cogent (and failing at level3). I?m guessing it is the level3/cogent border >>> >>> With Sprint UP & Cogent Down >>> I see trace routes showing traffic on to/from on Sprint just fine. >>> >>> >>> Anyone else having issues? >>> >>> -Matt >>> >>> -- >>> Matthew S. Crocker >>> President >>> Crocker Communications, Inc. >>> PO BOX 710 >>> Greenfield, MA 01302-0710 >>> >>> E: matthew at crocker.com >>> P: (413) 746-2760 >>> F: (413) 746-3704 >>> W: http://www.crocker.com >>> >>> >>> >>> >> >> >> > > From jra at baylink.com Sun Dec 8 06:57:43 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 8 Dec 2013 01:57:43 -0500 (EST) Subject: 844 INWATS prefix activated Message-ID: <25398898.128.1386485863234.JavaMail.root@benjamin.baylink.com> Note, if you're the PBX guy somewhere, too, that the +1 844 toll free prefix was activated at 1200EST today. Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From wbailey at satelliteintelligencegroup.com Sun Dec 8 08:24:37 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 8 Dec 2013 08:24:37 +0000 Subject: Any computer, anywhere? Message-ID: http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11e3-9e2c-e1d01116fd98_story.html Noticed this tonight.. Not saying the WP is always on target, but what software could be installed via a browser on any computer to gather all of that data? And how would it be done without the OS speaking up about it? Far fetched.. Or do the Firefox / chrome guys have some 'splainin to do? Sent from my Mobile Device. From tammy-lists at wiztech.biz Sun Dec 8 08:42:51 2013 From: tammy-lists at wiztech.biz (Tammy Firefly) Date: Sun, 8 Dec 2013 01:42:51 -0700 Subject: Any computer, anywhere? In-Reply-To: References: Message-ID: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> The wording sounds like it was tied to his yahoo account Tammy Sent from my iPhone On Dec 8, 2013, at 1:24, Warren Bailey wrote: > http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11e3-9e2c-e1d01116fd98_story.html > > Noticed this tonight.. Not saying the WP is always on target, but what software could be installed via a browser on any computer to gather all of that data? And how would it be done without the OS speaking up about it? Far fetched.. Or do the Firefox / chrome guys have some 'splainin to do? > > > Sent from my Mobile Device. From michael at supermathie.net Sun Dec 8 14:13:21 2013 From: michael at supermathie.net (Michael Brown) Date: Sun, 08 Dec 2013 09:13:21 -0500 Subject: Any computer, anywhere? In-Reply-To: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> References: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> Message-ID: <20131208141321.6054036.34796.1068@supermathie.net> From ler762 at gmail.com Sun Dec 8 14:23:37 2013 From: ler762 at gmail.com (Lee) Date: Sun, 8 Dec 2013 09:23:37 -0500 Subject: Any computer, anywhere? In-Reply-To: References: Message-ID: On 12/8/13, Warren Bailey wrote: > > http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11e3-9e2c-e1d01116fd98_story.html > > Noticed this tonight.. Not saying the WP is always on target, but what > software could be installed via a browser on any computer to gather all of > that data? And how would it be done without the OS speaking up about it? Far > fetched.. Or do the Firefox / chrome guys have some 'splainin to do? "The goal of the software was to gather a range of information ? Web sites he had visited and indicators of the location of the computer..." That's available from just the browser - don't need to install any software on the computer. Altho if the browser is exploitable http://www.wired.com/threatlevel/2013/08/freedom-hosting/ The malware showed up Sunday morning on multiple websites hosted by the anonymous hosting company Freedom Hosting. That would normally be considered a blatantly criminal ?drive-by? hack attack, but nobody?s calling in the FBI this time. The FBI is the prime suspect. https://lists.torproject.org/pipermail/tor-announce/2013-August/000089.html To be clear, while the Firefox vulnerability is cross-platform, the attack code is Windows-specific. Regards, Lee From bedard.phil at gmail.com Sun Dec 8 14:50:03 2013 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 8 Dec 2013 06:50:03 -0800 Subject: Any computer, anywhere? Message-ID: <-7878741055083095887@unknownmsgid> Have you ever heard of Java and Flash? There is a reason why browsers explicitly disable Java, heck OSX removed it from the OS completely. Flash will run sandboxed in newer browsers but Java afaik cannot. Almost all malware is delivered using them, one research company I read about has lists of non-public Java exploits they sell to governments... Phil From: Warren Bailey Sent: 12/8/2013 3:26 To: nanog at nanog.org Subject: Any computer, anywhere? http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11e3-9e2c-e1d01116fd98_story.html Noticed this tonight.. Not saying the WP is always on target, but what software could be installed via a browser on any computer to gather all of that data? And how would it be done without the OS speaking up about it? Far fetched.. Or do the Firefox / chrome guys have some 'splainin to do? Sent from my Mobile Device. From hiersd at gmail.com Sun Dec 8 18:05:01 2013 From: hiersd at gmail.com (David Hiers) Date: Sun, 8 Dec 2013 10:05:01 -0800 Subject: Any computer, anywhere? In-Reply-To: <-7878741055083095887@unknownmsgid> References: <-7878741055083095887@unknownmsgid> Message-ID: So what? Just another day in the cyber battlespace, friends. David On Sun, Dec 8, 2013 at 6:50 AM, Phil Bedard wrote: > Have you ever heard of Java and Flash? There is a reason why browsers > explicitly disable Java, heck OSX removed it from the OS completely. > Flash will run sandboxed in newer browsers but Java afaik cannot. > Almost all malware is delivered using them, one research company I read > about has lists of non-public Java exploits they sell to governments... > > Phil From: Warren Bailey > Sent: 12/8/2013 3:26 > To: nanog at nanog.org > Subject: Any computer, anywhere? > > http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11e3-9e2c-e1d01116fd98_story.html > > Noticed this tonight.. Not saying the WP is always on target, but what > software could be installed via a browser on any computer to gather > all of that data? And how would it be done without the OS speaking up > about it? Far fetched.. Or do the Firefox / chrome guys have some > 'splainin to do? > > > Sent from my Mobile Device. > > From eric.oosting at gmail.com Sun Dec 8 20:12:57 2013 From: eric.oosting at gmail.com (Eric Oosting) Date: Sun, 8 Dec 2013 15:12:57 -0500 Subject: 844 INWATS prefix activated In-Reply-To: <25398898.128.1386485863234.JavaMail.root@benjamin.baylink.com> References: <25398898.128.1386485863234.JavaMail.root@benjamin.baylink.com> Message-ID: How does team-cymru.org not have a bgp feed of these? On Sun, Dec 8, 2013 at 1:57 AM, Jay Ashworth wrote: > Note, if you're the PBX guy somewhere, too, that the +1 844 toll free > prefix > was activated at 1200EST today. > > Cheers, > -- jra > > -- > Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by > 12/14 > > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From merike at doubleshotsecurity.com Sun Dec 8 21:46:22 2013 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Sun, 8 Dec 2013 13:46:22 -0800 Subject: =?windows-1252?Q?Re=3A_Someone=92s_Been_Siphoning_Data_Through_a?= =?windows-1252?Q?_Huge_Security_Hole_in_the_Internet?= In-Reply-To: References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> Message-ID: <2D1130BB-4534-440C-8C8C-C59B21A36DE3@doubleshotsecurity.com> On Dec 6, 2013, at 11:55 AM, Eugeniu Patrascu wrote: > On Fri, Dec 6, 2013 at 9:48 PM, Jared Mauch wrote: > >> >> On Dec 6, 2013, at 1:39 PM, Brandon Galbraith >> wrote: >> >>> If your flows are a target, or your data is of an extremely sensitive >>> nature (diplomatic, etc), why aren't you moving those bits over >>> something more private than IP (point to point L2, MPLS)? This doesn't >>> work for the VoIP target mentioned, but foreign ministries should most >>> definitely not be trusting encryption alone. >> >> I will ruin someones weekend here, but: >> >> MPLS != Encryption. MPLS VPN = "Stick a label before the still >> unencrypted IP packet". >> MPLS doesn't secure your data, you are responsible for keeping it secure >> on the wire. >> >> > It's always interesting to watch someone's expression when they hear that > MPLS VPN, even if it says VPN in the name is not encrypted. Priceless every > time :) So, just to raise the bar?I had someone once tell me they encrypted everything since they were using IPsec. Since I only trust configurations, lo and behold the configuration was IPsec AH. As exercise to reader?.determine why using IPsec does not automagically equate to encrypted traffic. This was only 2 years ago while doing a security assessment for someone. I greatly dislike the term 'VPN'?..always have and always will. Marketechture is awesome! - merike -------------- 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 LarrySheldon at cox.net Sun Dec 8 21:59:45 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 08 Dec 2013 15:59:45 -0600 Subject: Empty messages (was Re: Any computer, anywhere?) In-Reply-To: References: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> Message-ID: <52A4EBD1.7010601@cox.net> On 12/8/2013 8:13 AM, Michael Brown wrote: > I've been getting several of these (empty messages) from different people and on different subjects but always on the NANOG list. Secret messages? Or is NSA sucking too hard? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From ml at kenweb.org Sun Dec 8 22:24:57 2013 From: ml at kenweb.org (ML) Date: Sun, 08 Dec 2013 17:24:57 -0500 Subject: Empty messages (was Re: Any computer, anywhere?) In-Reply-To: <52A4EBD1.7010601@cox.net> References: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> <52A4EBD1.7010601@cox.net> Message-ID: <52A4F1B9.9000008@kenweb.org> On 12/8/2013 4:59 PM, Larry Sheldon wrote: > On 12/8/2013 8:13 AM, Michael Brown wrote: >> > > I've been getting several of these (empty messages) from different > people and on different subjects but always on the NANOG list. > > Secret messages? Or is NSA sucking too hard? > I confirm I've been seeing the same thing. I've also been seeing more duplicate messages than I would attribute to someone sending twice. From jra at baylink.com Sun Dec 8 22:37:23 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 8 Dec 2013 17:37:23 -0500 (EST) Subject: =?utf-8?Q?Re:_Someone=E2=80=99s_Been_Siphoning_Data_Throu?= =?utf-8?Q?gh_a_Huge_Security_Hole_in_the_Internet?= In-Reply-To: <2D1130BB-4534-440C-8C8C-C59B21A36DE3@doubleshotsecurity.com> Message-ID: <7433863.188.1386542243704.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Merike Kaeo" > I greatly dislike the term 'VPN'?..always have and always will. > Marketechture is awesome! As long as you correctly expand it as Virtual Private Nightmare, I don't see that it's troublesome at all... Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fohdeesha at gmail.com Sun Dec 8 22:44:24 2013 From: fohdeesha at gmail.com (Jon Sands) Date: Sun, 08 Dec 2013 17:44:24 -0500 Subject: Empty messages (was Re: Any computer, anywhere?) In-Reply-To: <52A4F1B9.9000008@kenweb.org> References: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> <52A4EBD1.7010601@cox.net> <52A4F1B9.9000008@kenweb.org> Message-ID: <52A4F648.3010602@gmail.com> Confirming I've also been receiving blank messages. Most recently Michael Browns email sent at 9:13am 12/8/13 -- Jon Sands From michael at supermathie.net Mon Dec 9 00:07:57 2013 From: michael at supermathie.net (Michael Brown) Date: Sun, 08 Dec 2013 19:07:57 -0500 Subject: Any computer, anywhere? In-Reply-To: References: Message-ID: <52A509DD.6020105@supermathie.net> On 13-12-08 03:24 AM, Warren Bailey wrote: > http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11e3-9e2c-e1d01116fd98_story.html > > Noticed this tonight.. Not saying the WP is always on target, but what software could be installed via a browser on any computer to gather all of that data? And how would it be done without the OS speaking up about it? Far fetched.. Or do the Firefox / chrome guys have some 'splainin to do? Let's remember that the information in the article was filtered through no less than two people who don't fully speak tech. I think I can translate it back: ?The FBI crafted a custom piece of malware targeting Mo, designed to snoop his activities . A link was emailed to Mo in a spear phishing attack in an attempt to get hin to download and install the malware from the FBI's monitored servers. The attempt failed; the software was downloaded but never executed in a manner enabling the software to send back information to the FBI.? Nothing too special. I wonder if Mo had the balls to submit the software to Sophos etc. for malware analysis. :) M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From michael at supermathie.net Mon Dec 9 00:14:47 2013 From: michael at supermathie.net (Michael Brown) Date: Sun, 08 Dec 2013 19:14:47 -0500 Subject: Empty messages (was Re: Any computer, anywhere?) In-Reply-To: <52A4EBD1.7010601@cox.net> References: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> <52A4EBD1.7010601@cox.net> Message-ID: <52A50B77.10100@supermathie.net> On 13-12-08 04:59 PM, Larry Sheldon wrote: > On 12/8/2013 8:13 AM, Michael Brown wrote: >> > > I've been getting several of these (empty messages) from different > people and on different subjects but always on the NANOG list. > > Secret messages? Or is NSA sucking too hard? > This I can solidly attribute (at least in my case) to the fact that BlackBerry 10 devices only send emails with a text/html part and no text/plain part. I've seen this cause problems in a few places - notably in services that automatically parse emails for replying to forums/chat/etc. (Discourse & kato.im and now the nanog list which strips text/html). Somewhere I have a nice little python snippet I wrote for extracting text out of the html. It's convenient when you're *expecting* it (you can use the html div information to separate out the actual reply vs. the signature vs. the quoted text) but when you're expecting to be able to use text/plain, it's just not there. (arguments over who is being a worse Internetizen - BB for not having text/plain or Mailman/Mimedel for stripping out text/html when there's no text/plain are not included in this :D ) M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From phobos at panopticism.net Sun Dec 8 11:11:18 2013 From: phobos at panopticism.net (/dev/ph0b0s) Date: Sun, 8 Dec 2013 06:11:18 -0500 Subject: Any computer, anywhere? In-Reply-To: References: Message-ID: <20131208111118.GB5522@phobos.panopticism.net> On 12/08, Warren Bailey wrote: > http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11e3-9e2c-e1d01116fd98_story.html > > Noticed this tonight.. Not saying the WP is always on target, but what > software could be installed via a browser on any computer to gather > all of that data? And how would it be done without the OS speaking up > about it? Far fetched.. Or do the Firefox / chrome guys have some > 'splainin to do? My first thought as I read the article Friday evening was that they were attempting to exploit a vulnerability in a popular application (first guess: Adobe Flash) in order to execute arbitrary code -- at which point they have full control of the victim's PC and can do (or install) whatever they want. "A software update to a program the surveillance software was planning to target, meanwhile, raised fears of a malfunction, forcing the FBI to refashion its malicious software before sending it to Mo?s computer." However, the article also states that: "Federal magistrate Judge Kathleen M. Tafoya approved the FBI?s search warrant request on Dec. 11, 2012, ..." "The surveillance software was sent across the Internet on Dec. 14, 2012 ..." December 11, 2012 fell on a Tuesday. More specifically, it fell on the second Tuesday of the month, a.k.a. "Patch Tuesday". Perhaps it was a vulnerability in Microsoft Windows itself, then, that they were attempting to exploit? Six of the seven vulnerabilities fixed that month "could allow remote code execution". Internet Explorer and Microsoft Office were among the affected software, according to http://technet.microsoft.com/en-us/security/bulletin/ms12-dec. "... but the FBI?s program didn?t function properly, ..." Oops. /p From mysidia at gmail.com Mon Dec 9 02:08:35 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 8 Dec 2013 20:08:35 -0600 Subject: Any computer, anywhere? In-Reply-To: References: Message-ID: On Sun, Dec 8, 2013 at 2:24 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Noticed this tonight.. Not saying the WP is always on target, but what > software could be installed via a browser on any computer to gather all of > that data? And how would it be done without the OS speaking up about it? > Far fetched.. Or do the Firefox / chrome guys have Not really; it's well within the realm of possibility, and not even unlikely. The answer about what software could be installed that way, would be taylor-made covert software; plenty of that is known to exist. Law enforcement would have it well within their ability to potentially intercept and modify traffic on web pages accessed by the user, and inject targetted exploits into the user's in-flight data connections. Software can be installed via the browser through a variety of vectors; mostly vulnerabilities leveraging Javascript, browser-specific flaws, viewer flaws, API flaws such as fonts, or plugins such as Java, Silverlight, Flash, Quicktime, or Adobe reader. Then a sandbox defeat, and privilege escalation using a variety of unpublished exploit techniques. Once that has occured; software may be deployed undetectably and persistently in a variety of ways. A payload specific to the target may be downloaded and configured in the background. It is also possible, that the malware may simply modify existing programs such as the operating system running in RAM --- diskless malware that doesn't save a copy of itself, but reinfects the system after a reboot, when the user browses the web again, and the exploit kit is launched again. -- -JH From jmamodio at gmail.com Mon Dec 9 03:02:40 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 8 Dec 2013 21:02:40 -0600 Subject: Empty messages (was Re: Any computer, anywhere?) In-Reply-To: <52A4F1B9.9000008@kenweb.org> References: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> <52A4EBD1.7010601@cox.net> <52A4F1B9.9000008@kenweb.org> Message-ID: <29C5D2D1-AAC0-42A5-9AD1-E94A0E81B49F@gmail.com> Same here, they are written with invisible bits, like invisible ink. You have to drop some special lemon juice on your email client to be able to see it. -Jorge > On Dec 8, 2013, at 4:24 PM, ML wrote: > >> On 12/8/2013 4:59 PM, Larry Sheldon wrote: >>> On 12/8/2013 8:13 AM, Michael Brown wrote: >> >> I've been getting several of these (empty messages) from different >> people and on different subjects but always on the NANOG list. >> >> Secret messages? Or is NSA sucking too hard? > > I confirm I've been seeing the same thing. > I've also been seeing more duplicate messages than I would attribute to > someone sending twice. > From karn at philkarn.net Mon Dec 9 03:55:41 2013 From: karn at philkarn.net (Phil Karn) Date: Sun, 08 Dec 2013 19:55:41 -0800 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A1D71A.4040801@amplex.net> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> <52A11BDC.1010307@philkarn.ne! t> <52A1D71A.4040801@amplex.net> Message-ID: <52A53F3D.6040007@philkarn.net> On 12/06/2013 05:54 AM, Mark Radabaugh wrote: > Currently, without a limit, there is nothing to convince a end user to > make any attempt at conserving bandwidth and no revenue to cover the > cost of additional equipment to serve high bandwidth customers. By > adding a cap or overage charge we can offer higher speed plans. Why is that? Just guarantee each user a data rate that depends on how much he pays. Charge him by what it costs you to build and maintain that much capacity. Lots of mechanisms exist to do this: token bucket, etc. He gets more than his guaranteed capacity only when others don't use theirs. Otherwise he won't. If that's unacceptable to him, then he has the choice of paying you more to upgrade your network or waiting for others to stop using their guarantees. It costs you nothing to let people use capacity that would otherwise go to waste, and it increases the perceived value of your service. Your customers will eventually find themselves depending on that excess capacity often enough that at least some will be willing to pay you more to guarantee that it'll be there when they really want it. Nothing says you have to carry a customer for less than your incremental cost of servicing his account, or that you can't add a reasonable profit margin. But if you can make your customers realize that they're paying you for a guarantee that most ISP users don't get now they may find it entirely worthwhile, especially given the very large economies of scale that often exist in data communications. --Phil From michael at supermathie.net Mon Dec 9 04:07:08 2013 From: michael at supermathie.net (Michael Brown) Date: Sun, 08 Dec 2013 23:07:08 -0500 Subject: Empty messages (was Re: Any computer, anywhere?) In-Reply-To: <29C5D2D1-AAC0-42A5-9AD1-E94A0E81B49F@gmail.com> References: <4AF9FA95-76A4-41C3-83D2-4AE2A11A2A20@wiztech.biz> <52A4EBD1.7010601@cox.net> <52A4F1B9.9000008@kenweb.org> <29C5D2D1-AAC0-42A5-9AD1-E94A0E81B49F@gmail.com> Message-ID: <52A541EC.5070600@supermathie.net> On 13-12-08 10:02 PM, Jorge Amodio wrote: > Same here, they are written with invisible bits, like invisible ink. You have to drop some special lemon juice on your email client to be able to see it. Lemon juice as promised, to be applied prior to de-HTML-izing email: http://stackoverflow.com/q/20462965/93180 M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From eugen at imacandi.net Mon Dec 9 05:07:57 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Mon, 9 Dec 2013 07:07:57 +0200 Subject: =?windows-1252?Q?Re=3A_Someone=92s_Been_Siphoning_Data_Through_a_Huge_S?= =?windows-1252?Q?ecurity_Hole_in_the_Internet?= In-Reply-To: <2D1130BB-4534-440C-8C8C-C59B21A36DE3@doubleshotsecurity.com> References: <20131206173830.GL10793@leitl.org> <9609A22F-5397-4084-8162-146321E7465E@puck.nether.net> <2D1130BB-4534-440C-8C8C-C59B21A36DE3@doubleshotsecurity.com> Message-ID: On Sun, Dec 8, 2013 at 11:46 PM, Merike Kaeo wrote: > > On Dec 6, 2013, at 11:55 AM, Eugeniu Patrascu wrote: > > > On Fri, Dec 6, 2013 at 9:48 PM, Jared Mauch > wrote: > > > >> > >> On Dec 6, 2013, at 1:39 PM, Brandon Galbraith < > brandon.galbraith at gmail.com> > >> wrote: > >> > >>> If your flows are a target, or your data is of an extremely sensitive > >>> nature (diplomatic, etc), why aren't you moving those bits over > >>> something more private than IP (point to point L2, MPLS)? This doesn't > >>> work for the VoIP target mentioned, but foreign ministries should most > >>> definitely not be trusting encryption alone. > >> > >> I will ruin someones weekend here, but: > >> > >> MPLS != Encryption. MPLS VPN = "Stick a label before the still > >> unencrypted IP packet". > >> MPLS doesn't secure your data, you are responsible for keeping it secure > >> on the wire. > >> > >> > > It's always interesting to watch someone's expression when they hear that > > MPLS VPN, even if it says VPN in the name is not encrypted. Priceless > every > > time :) > > So, just to raise the bar?I had someone once tell me they encrypted > everything since they > were using IPsec. Since I only trust configurations, lo and behold the > configuration was > IPsec AH. As exercise to reader?.determine why using IPsec does not > automagically equate to > encrypted traffic. > > Interesting, as it's particularly hard to enable only AH instead of ESP. > This was only 2 years ago while doing a security assessment for someone. > > I greatly dislike the term 'VPN'?..always have and always will. > Marketechture is awesome! > > I think you probably dislike all the people that grossly misunderstand what a VPN is and what are its use cases :) From dhc2 at dcrocker.net Mon Dec 9 05:34:19 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sun, 08 Dec 2013 21:34:19 -0800 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A53F3D.6040007@philkarn.net> References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> <7287C4E7-F3C9-47D8-88E7-244DFBC5D806@delong.com> <52A11BDC.1010307@philkarn.ne! t> <52A1D71A.4040801@amplex.net> <52A53F3D.6040007@philkarn.net> Message-ID: <52A5565B.2060409@dcrocker.net> On 12/8/2013 7:55 PM, Phil Karn wrote: > It costs you nothing to let people use capacity that would otherwise go > to waste, and it increases the perceived value of your service. Sometimes, yes. Othertimes, perhaps not. I seem to recall an early bit of research on interactive computing (maybe by Sackman) that showed user preference for a /worse/ average response time that was more predictable (narrower range of variance) than a better average time that was more erratic. So, stability over throughput, sort of. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jra at baylink.com Mon Dec 9 05:48:06 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 9 Dec 2013 00:48:06 -0500 (EST) Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A5565B.2060409@dcrocker.net> Message-ID: <26161654.212.1386568086177.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dave Crocker" > I seem to recall an early bit of research on interactive computing > (maybe by Sackman) that showed user preference for a /worse/ average > response time that was more predictable (narrower range of variance) > than a better average time that was more erratic. Very specifically: A 3270 that took 5 seconds of delay and then *snapped* the entire screen up at once was perceived as "faster" than a 9600 tty that painted the same entire screen in about a second and a half or so. Don't remember who it was either, but likely Bell Labs. Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bross at pobox.com Mon Dec 9 06:01:06 2013 From: bross at pobox.com (Brandon Ross) Date: Mon, 9 Dec 2013 01:01:06 -0500 (EST) Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <280111E3-A81E-4489-B5C8-C0CAB6B446D2@delong.com> Message-ID: On Thu, 5 Dec 2013, Mikael Abrahamsson wrote: > We have the same deal here, for the same price per month you can have access > to ~80 megabit/s LTE, or you can have 100/10 cable. The problem is that with > LTE you get 80 gigabytes/month in cap. The cable connection doesn't have a > cap. It does now, at least, if you are a Comcast customer: Starting December 1, 2013, Comcast will trial a new monthly data plan in this area, which will increase the amount of data included in your XFINITY Internet Service to 300 GB and provide more choice and flexibility. Good job, Comcast, considering what I pay you, it might actually be a better deal for me to dump my wired connectivity and just use tethering on my phone when I'm at home. By capping me, you've created a new competitor. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross From jeff-kell at utc.edu Mon Dec 9 06:02:54 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 9 Dec 2013 01:02:54 -0500 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <26161654.212.1386568086177.JavaMail.root@benjamin.baylink.com> References: <26161654.212.1386568086177.JavaMail.root@benjamin.baylink.com> Message-ID: <52A55D0E.5040204@utc.edu> On 12/9/2013 12:48 AM, Jay Ashworth wrote: > A 3270 that took 5 seconds of delay and then *snapped* the entire screen > up at once was perceived as "faster" than a 9600 tty that painted the same > entire screen in about a second and a half or so. Don't remember who it > was either, but likely Bell Labs. This is a "screen/block" mode I/O issue versus a character-mode one. And the "screen/block" I/O won't start until the whole screen data is there, so there is an initial delay. The character-mode variant will paint portions of the screen as the data arrives. Similar anomalies exist on input... the screen/block mode is buffered locally and proceeds normally; while the character mode version has to transit the WAN link, whatever it may be. I won't argue that one is better than the other, depending on your link speed (transmitting a whole screen will incur longer delays than transmitting individual fields, though admittedly it happens "less" often). But the user perception goes a long way... I have seen advantages to both, having done serial termainal applications from back to the 1970s, and won't argue one way or the other. You choose your poison. With 3270 you have little choice other than "full screen" transactions. For other ASCII terminal interfaces, you could optimize the individual fields (while paying the "full screen" price). There are "user perceived" throughput values, "transaction perceived" throughput values, and "application perceived" throughput values. And very rarely did the three equal out for every application :( Jeff From LarrySheldon at cox.net Mon Dec 9 06:12:27 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 09 Dec 2013 00:12:27 -0600 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: Message-ID: <52A55F4B.2060107@cox.net> On 12/8/2013 11:48 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Dave Crocker" > >> I seem to recall an early bit of research on interactive computing >> (maybe by Sackman) that showed user preference for a /worse/ average >> response time that was more predictable (narrower range of variance) >> than a better average time that was more erratic. > > Very specifically: > > A 3270 that took 5 seconds of delay and then *snapped* the entire screen > up at once was perceived as "faster" than a 9600 tty that painted the same > entire screen in about a second and a half or so. Don't remember who it > was either, but likely Bell Labs. Back in the day we were building a system to run on UNIVAC equipment but some brainiac decided that because we were a Bell System company, we had to use DataSpeed 40's (which buffered the screen and snap it up when the last character is received) instead of the UTS terminals on which the system was developed (which painted each character as it came in. Users weeped and wailed to no effect that the change hurt them badly (which they could prove) because that while the two had the same time from first character to last, the operators could not start composing a reply when the first several lines had painted. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From gary.buhrmaster at gmail.com Mon Dec 9 06:37:05 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 9 Dec 2013 06:37:05 +0000 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A55D0E.5040204@utc.edu> References: <26161654.212.1386568086177.JavaMail.root@benjamin.baylink.com> <52A55D0E.5040204@utc.edu> Message-ID: On Mon, Dec 9, 2013 at 6:02 AM, Jeff Kell wrote: > ... With 3270 you have little choice other > than "full screen" transactions. It has been a long long time, but for the truly crazy, I thought it was possible to write single characters at a time (using a Set Buffer Address and then the character) as long as you had set up the field attributes previously. Lots of transactions, but one could appear to write out individual characters as slowly as the KSR 33 it replaced. Or perhaps my 3270 memory has finally faded away. Gary From shopik at inblock.ru Mon Dec 9 08:20:37 2013 From: shopik at inblock.ru (Nikolay Shopik) Date: Mon, 09 Dec 2013 12:20:37 +0400 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> Message-ID: <52A57D55.9000202@inblock.ru> On 04/12/13 23:48, Owen DeLong wrote: > Please tell me what provider is selling 100Mbit for $20-30 in the 408-532-xxxx > area of San Jose, California. > > Currently, the only provider capable of delivering more than 768k wired > here is charging me $100+/month for 30-50Mbps maximum. > > I could get 100Mbps from them, but they want $250+/month for that. > > If I can get 100Mbps for $20-30, I'd jump at it. I know this is nanog, but i was talking about Russia, sorry for confusion. You can get 350Mbps for 70$ via GPON here. but plain ethernet dominates mostly here > > Not entirely sure what you are saying here. In this day and age, I don't see > any reason that wireless providers should get a free pass or be able to sustain > significantly worse policies than wireline providers. Wireless bandwidth is > rapidly approaching parity with wired bandwidth pricing at consumer levels. Sure but most cases you hit tower limit or frequency to crowded, since its shared medium and you can't do anything about that. In wired you can just drop another cable to your new client. > >> Some even come up with idea two separate /64 make things easier :-D, >> instead just put at least round /60 > > Actually, providing a separate /64 for the provider link makes a lot of sense. > It really is best to pull that out of a separate provider aggregate across all > the subscribers in the same aggregation group than to carve individual > link prefixes out of each subscribers internal-use prefix. > > For example, if you get a tunnel from HE, then, by default, you get a /64 > from our link block for the tunnel broker to which you connect and an additional > /64 for your internal use by default. If you click the "please give me a /48" checkbox, > then you'll also get an additional /48. I was talking about /64 + /64 to client LANs and not counting another /64 for WAN interface. I find this hard to manage at least on Cisco, actually didn't find way to separate them at all, unless its make them static > > We do this because it makes our provisioning easier and allows us to support > users that want prefixes as well as users whose equipment (or brains) can't > handle more than a single /64 for their LAN. > > There's really NOTHING to be gained from providing anything in between a /64 > and a /48, so we don't do it. > > Owen > From jmamodio at gmail.com Mon Dec 9 11:21:46 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 9 Dec 2013 05:21:46 -0600 Subject: Skype suspicious download activity ... Message-ID: I just caught an alert on my desktop about high disk activity by Skype, looking at the details it shows a 472MB of disk write activity, no notification of upgrade or any other messages. Trying to see if I can find what was recently written. This the first time I see a report about such high disk activity related to Skype. Anybody seeing anything similar ? Thanks & Regards Jorge PS. Platform is Windoze Vista 64bits From mysidia at gmail.com Mon Dec 9 12:11:56 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 9 Dec 2013 06:11:56 -0600 Subject: Skype suspicious download activity ... In-Reply-To: References: Message-ID: Skype previously showed a warning message showing that the Skype API / Third party applications would stop working as of December 2013. I would bet there was a silent forceful update to the software... -- -JH On Mon, Dec 9, 2013 at 5:21 AM, Jorge Amodio wrote: > I just caught an alert on my desktop about high disk activity by Skype, > looking at the details it shows a 472MB of disk write activity, no > notification of upgrade or any other messages. > > Trying to see if I can find what was recently written. > > This the first time I see a report about such high disk activity related to > Skype. > > Anybody seeing anything similar ? > > Thanks & Regards > Jorge > > PS. Platform is Windoze Vista 64bits > -- -Mysid From randy at psg.com Mon Dec 9 14:49:48 2013 From: randy at psg.com (Randy Bush) Date: Mon, 09 Dec 2013 06:49:48 -0800 Subject: turning on comcast v6 Message-ID: http://comcast6.net/ tells me that the local cmts is v6 enabled. my modem, a cisco dpc3008, is in the supported products list. so how do i turn the sucker on? randy From Valdis.Kletnieks at vt.edu Mon Dec 9 15:50:08 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Dec 2013 10:50:08 -0500 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: Your message of "Mon, 09 Dec 2013 06:37:05 +0000." References: <26161654.212.1386568086177.JavaMail.root@benjamin.baylink.com> <52A55D0E.5040204@utc.edu> Message-ID: <215577.1386604208@turing-police.cc.vt.edu> On Mon, 09 Dec 2013 06:37:05 +0000, Gary Buhrmaster said: > It has been a long long time, but for the truly crazy, I > thought it was possible to write single characters at a > time (using a Set Buffer Address and then the character) > as long as you had set up the field attributes previously. > Lots of transactions, but one could appear to write out > individual characters as slowly as the KSR 33 it replaced. > Or perhaps my 3270 memory has finally faded away. AIX/370 supported vi on a 3278-2 console. Phear. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From asullivan at dyn.com Mon Dec 9 15:54:10 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Mon, 9 Dec 2013 10:54:10 -0500 Subject: ICANN related question... In-Reply-To: <52A250DF.6080404@tigertech.com> References: <047301cef2c5$f84602e0$e8d208a0$@truenet.com> <201312062114.rB6LEbNC078646@nike.wampumpeag.net> <52A250DF.6080404@tigertech.com> Message-ID: <20131209155409.GH32716@dyn.com> On Fri, Dec 06, 2013 at 02:34:07PM -0800, Robert L Mathews wrote: > Sadly, ICANN compliance will not do a thing for any individual domain > name incident. Their mechanism for such things is to pass complaints on > to the registrar, even when the registrar IS the problem, as if they're > the Better Business Bureau. I've never seen them intervene in an > individual domain name case. I have, but usually you can contact the registry before going to ICANN if you're having this problem. Registries will lean on the registrars to behave if there's a problem of this sort. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From dhc2 at dcrocker.net Mon Dec 9 15:59:22 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Mon, 09 Dec 2013 07:59:22 -0800 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <26161654.212.1386568086177.JavaMail.root@benjamin.baylink.com> References: <26161654.212.1386568086177.JavaMail.root@benjamin.baylink.com> Message-ID: <52A5E8DA.8010701@dcrocker.net> On 12/8/2013 9:48 PM, Jay Ashworth wrote: > Very specifically: > > A 3270 that took 5 seconds of delay and then *snapped* the entire screen > up at once was perceived as "faster" than a 9600 tty that painted the same > entire screen in about a second and a half or so. Don't remember who it > was either, but likely Bell Labs. Interesting, but it doesn't feel like the one I'm vaguely remembering. (How's that for waffling?) But then, when interactive computing started getting real, by the late 60s and early 70s, a number of places started studying human-computer interaction issues. IBM and Bell Labs were the two places best positioned with researchers for this. Anyhow, my main point was that economic charging models that are entirely rational, with respect to consumption and cost, don't always work for user preference. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From morrowc.lists at gmail.com Mon Dec 9 16:04:52 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Dec 2013 11:04:52 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Mon, Dec 9, 2013 at 9:49 AM, Randy Bush wrote: > http://comcast6.net/ tells me that the local cmts is v6 enabled. my > modem, a cisco dpc3008, is in the supported products list. so how do > i turn the sucker on? do you see PD from your modem? or RA's? (guessing probably not, or you'd not be asking)... for my arris, it was just automatically working. My dlink, another story :( From randy at psg.com Mon Dec 9 16:08:31 2013 From: randy at psg.com (Randy Bush) Date: Mon, 09 Dec 2013 08:08:31 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: > do you see PD from your modem? or RA's? still trying to educate the opwnwrt (attitude adjustment on netgear 3800). root at wrt-biwa:~# opkg update Downloading http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages//Packages.gz. Inflating http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages//Packages.gz. Updated list of available packages in /var/opkg-lists/attitude_adjustment. root at wrt-biwa:~# opkg install luci-proto-ipv6 Unknown package 'luci-proto-ipv6'. Collected errors: * opkg_install_cmd: Cannot install package luci-proto-ipv6. root at wrt-biwa:~# opkg install ipv6-support Unknown package 'ipv6-support'. Collected errors: * opkg_install_cmd: Cannot install package ipv6-support. sigh randy From morrowc.lists at gmail.com Mon Dec 9 16:19:18 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Dec 2013 11:19:18 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Mon, Dec 9, 2013 at 11:08 AM, Randy Bush wrote: >> do you see PD from your modem? or RA's? > > still trying to educate the opwnwrt (attitude adjustment on netgear > 3800). > > root at wrt-biwa:~# opkg update > Downloading http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages//Packages.gz. > Inflating http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages//Packages.gz. > Updated list of available packages in /var/opkg-lists/attitude_adjustment. > root at wrt-biwa:~# opkg install luci-proto-ipv6 > Unknown package 'luci-proto-ipv6'. > Collected errors: > * opkg_install_cmd: Cannot install package luci-proto-ipv6. > root at wrt-biwa:~# opkg install ipv6-support > Unknown package 'ipv6-support'. > Collected errors: > * opkg_install_cmd: Cannot install package ipv6-support. > > sigh yea, so my 'saga' started with: 1) "dlink 615 doesn't like dhcp-pd ... and is flat broken for v6" a) gets v6 addr on WAN from arris-RA b) gets PD alloction from arris, does RA's to LAN c) sets default-gw for v6 on the LAN side to something unreachable d) manually resetting default-gw ... gets me zippy... can't ping either side of the dlink, nor the arris :( e) dlink's v6 code (for that platform) is just boarked, badly. 2) oh! dd-wrt does this platform too, and v6 a) install dd-wrrt b) fiddle-fart around with v6 configs c) oh.. dhcp-pd is one of the things dd-wrt didn't implement :( d) oh, their 'v6 support' is really only 'v6 tunnel support' e) boned. basically ... this is much harder to do than it shoudl be :( and yes, I can probably do something like plug in my raspberry-pi and make that a 'router' but come on... in 2013 I have to home-brew something to get a protocol developed and engineered in 2000 to work? :( (this raised itself above my level of 'fixed in a weekend' project, so my comcast v6 lays fallow... NOTE: this is NOT comcast's fault, in my eyes.) -chris From randy at psg.com Mon Dec 9 16:29:19 2013 From: randy at psg.com (Randy Bush) Date: Mon, 09 Dec 2013 08:29:19 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: > (this raised itself above my level of 'fixed in a weekend' project, so > my comcast v6 lays fallow... NOTE: this is NOT comcast's fault, in my > eyes.) i could take a picture, but i think you would recognize the boat. sigh. randy From cra at WPI.EDU Mon Dec 9 16:32:16 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 9 Dec 2013 11:32:16 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <20131209163215.GE26059@angus.ind.WPI.EDU> On Mon, Dec 09, 2013 at 11:19:18AM -0500, Christopher Morrow wrote: > On Mon, Dec 9, 2013 at 11:08 AM, Randy Bush wrote: > >> do you see PD from your modem? or RA's? > > > > still trying to educate the opwnwrt (attitude adjustment on netgear > > 3800). ... > yea, so my 'saga' started with: > 1) "dlink 615 doesn't like dhcp-pd ... and is flat broken for v6" ... > 2) oh! dd-wrt does this platform too, and v6 ... > basically ... this is much harder to do than it shoudl be :( and yes, > I can probably do something like plug in my raspberry-pi and make that > a 'router' but come on... in 2013 I have to home-brew something to get > a protocol developed and engineered in 2000 to work? :( > > (this raised itself above my level of 'fixed in a weekend' project, so > my comcast v6 lays fallow... NOTE: this is NOT comcast's fault, in my > eyes.) Another option to try out is CeroWRT. Its based on OpenWRT development releases and focuses on good IPv6 support in addition to its raison d'?tre, debloating buffers. http://www.bufferbloat.net/projects/cerowrt/wiki/Wiki Still waiting for my CMTS to be upgraded... From rwebb at ropeguru.com Mon Dec 9 16:32:23 2013 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Mon, 09 Dec 2013 11:32:23 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Mon, 9 Dec 2013 11:19:18 -0500 Christopher Morrow wrote: > On Mon, Dec 9, 2013 at 11:08 AM, Randy Bush wrote: >>> do you see PD from your modem? or RA's? >> >> still trying to educate the opwnwrt (attitude adjustment on netgear >> 3800). >> >> root at wrt-biwa:~# opkg update >> Downloading >>http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages//Packages.gz. >> Inflating >>http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages//Packages.gz. >> Updated list of available packages in >>/var/opkg-lists/attitude_adjustment. >> root at wrt-biwa:~# opkg install luci-proto-ipv6 >> Unknown package 'luci-proto-ipv6'. >> Collected errors: >> * opkg_install_cmd: Cannot install package luci-proto-ipv6. >> root at wrt-biwa:~# opkg install ipv6-support >> Unknown package 'ipv6-support'. >> Collected errors: >> * opkg_install_cmd: Cannot install package ipv6-support. >> >> sigh > > yea, so my 'saga' started with: > 1) "dlink 615 doesn't like dhcp-pd ... and is flat broken for v6" > a) gets v6 addr on WAN from arris-RA > b) gets PD alloction from arris, does RA's to LAN > c) sets default-gw for v6 on the LAN side to something >unreachable > d) manually resetting default-gw ... gets me zippy... can't ping > either side of the dlink, nor the arris :( > e) dlink's v6 code (for that platform) is just boarked, badly. > > 2) oh! dd-wrt does this platform too, and v6 > a) install dd-wrrt > b) fiddle-fart around with v6 configs > c) oh.. dhcp-pd is one of the things dd-wrt didn't implement :( > d) oh, their 'v6 support' is really only 'v6 tunnel support' > e) boned. > > basically ... this is much harder to do than it shoudl be :( and >yes, > I can probably do something like plug in my raspberry-pi and make >that > a 'router' but come on... in 2013 I have to home-brew something to >get > a protocol developed and engineered in 2000 to work? :( > > (this raised itself above my level of 'fixed in a weekend' project, >so > my comcast v6 lays fallow... NOTE: this is NOT comcast's fault, in >my > eyes.) > > -chris > I feel your pain. I am on the Comcast Business trial and have tried pfsense and now trying monowall. I followed all the different instructions I could find for pfsense 2.1 and while I could pull the WAN IP, I never could get a LAN ip nor could I get an ip on any of my computers. I am now in the process of trying m0n0wall and have gotten IP's on the WAN, LAN, and on my workstation. Can ping from my workstation to my m0n0wall LAN and WAN IP's but nothing will route out to the net. It should really be easier than this. Robert From jra at baylink.com Mon Dec 9 16:38:04 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 9 Dec 2013 11:38:04 -0500 (EST) Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <52A53F3D.6040007@philkarn.net> Message-ID: <18497386.252.1386607084110.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Phil Karn" > On 12/06/2013 05:54 AM, Mark Radabaugh wrote: > > Currently, without a limit, there is nothing to convince a end user to > > make any attempt at conserving bandwidth and no revenue to cover the > > cost of additional equipment to serve high bandwidth customers. By > > adding a cap or overage charge we can offer higher speed plans. > > Why is that? > > Just guarantee each user a data rate that depends on how much he pays. > Charge him by what it costs you to build and maintain that much > capacity. Lots of mechanisms exist to do this: token bucket, etc. > > He gets more than his guaranteed capacity only when others don't use > theirs. Otherwise he won't. If that's unacceptable to him, then he has > the choice of paying you more to upgrade your network or waiting for > others to stop using their guarantees. > > It costs you nothing to let people use capacity that would otherwise go > to waste, and it increases the perceived value of your service. Your > customers will eventually find themselves depending on that excess > capacity often enough that at least some will be willing to pay you > more to guarantee that it'll be there when they really want it. +10 We've forgotten the Committed Information Rate already? Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jared at puck.nether.net Mon Dec 9 16:44:14 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 9 Dec 2013 11:44:14 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: I have no issues with the comcast business netgear box and normal ra+dhcpv6. Not trying anything fancy as when I do, I spend too much time doing tech support for my family. Flat lan makes it work. Jared Mauch > On Dec 9, 2013, at 11:32 AM, wrote: > > I feel your pain. I am on the Comcast Business trial and have tried pfsense and now trying monowall. I followed all the different instructions I could find for pfsense 2.1 and while I could pull the WAN IP, I never could get a LAN ip nor could I get an ip on any of my computers. From james.cutler at consultant.com Mon Dec 9 16:51:46 2013 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 9 Dec 2013 11:51:46 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Mon, Dec 9, 2013 at 9:49 AM, Randy Bush wrote: > http://comcast6.net/ tells me that the local cmts is v6 enabled. my > modem, a cisco dpc3008, is in the supported products list. so how do > i turn the sucker on? According to Comcast?s DOCSIS Devices page, http://mydeviceinfo.comcast.net/?s=i&so=1&e=0&d3=1&tier=-1&sc=84, the Cisco DPC3008 is not supported for IPv6. You could always try enabling IPv6 on a system directly connected to the Cisco and see what happens. I?m not optimistic. I opted for my minimal-effort solution. I installed a Motorola SB6121 and a 5th gen Airport Extreme and turned them on. Of course I configured the Airport Extreme with a name, management password, and confirmed IPv6 was set to to configure Automatically and Native. When the Comcast drop was plugged in and Comcast authorized the modem, I had a multistacked LAN. Going on 11 months of IPv4/IPv6 service. I?ve had about 1 hour of downtime. James R. Cutler james.cutler at consultant.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From michael at supermathie.net Mon Dec 9 16:57:20 2013 From: michael at supermathie.net (Michael Brown) Date: Mon, 09 Dec 2013 11:57:20 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <52A5F670.4060709@supermathie.net> On 13-12-09 11:19 AM, Christopher Morrow wrote: > yea, so my 'saga' started with: > 1) "dlink 615 doesn't like dhcp-pd ... and is flat broken for v6" I had very borken things happen at home on my dlink-615 with their busted-ass IPv6 code. Specifics are here: http://serverfault.com/q/252083/2101 Although in that case, I wasn't trying to use it to route anywhere. It really was written as thought it Would Be the gateway. The dlink stock firmwares even have support for he.net and other tunnel brokers now. But the stack isn't nearly as mature and there's too few users. pfSense is the way to go here. I'll try re-deploying the dir-615 it as an IPv6-only gateway device and see how it behaves. M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From rwebb at ropeguru.com Mon Dec 9 17:05:29 2013 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Mon, 09 Dec 2013 12:05:29 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: Oh, I agree. If I plug the Netgear box directly into my network, everything works great. I really believe it is a pFsene/m0n0wall issue. Robert On Mon, 9 Dec 2013 11:44:14 -0500 Jared Mauch wrote: > I have no issues with the comcast business netgear box and normal >ra+dhcpv6. Not trying anything fancy as when I do, I spend too much >time doing tech support for my family. Flat lan makes it work. > > Jared Mauch > >> On Dec 9, 2013, at 11:32 AM, wrote: >> >> I feel your pain. I am on the Comcast Business trial and have tried >>pfsense and now trying monowall. I followed all the different >>instructions I could find for pfsense 2.1 and while I could pull the >>WAN IP, I never could get a LAN ip nor could I get an ip on any of my >>computers. From izumi at nic.ad.jp Mon Dec 9 17:15:24 2013 From: izumi at nic.ad.jp (Izumi Okutani) Date: Tue, 10 Dec 2013 02:15:24 +0900 Subject: JANOG 33 Program Published Message-ID: <52A5FAAC.3020101@nic.ad.jp> Dear Colleagues, We have published the program for JANOG 33 and welcome you to join us in Beppu City, Japan, from 23rd-24th Jan 2014. Most sessions are in Japanese only but there are a few sessions in English. You are also welcome to connect with us through facebook and twitter for updates in English. The JANOG SNS accounts are open to everyone, including those who are not able to attend the meeting. See you in Beppu. Cheers, Shinichi Yamamoto, Chin Sze Yih, Izumi Okutani JANOG Internationalization team for JANOG 33 ----- JANOG 33 Program : ------------------------ The Program is available in English at: http://www.janog.gr.jp/en/index.php?JANOG33%20Programs%2FJANOG33%20Program%20Contents Translations of the program titles and abstracts were supported by volunteers on the best efforts basis. Note: During the meeting, there will be no official interpretations in English, except for the sessions marked as (English session). Registration : ------------------------ You can register online at: https://regist.e-side.co.jp/product_info.php?products_id=427&language=en ?Deadline: 10th Jan 2014 JST 15:00 SNS Accounts : ------------------------ Facebook : https://www.facebook.com/janogmeetingi18n Twitter : https://twitter.com/janog_i18n From morrowc.lists at gmail.com Mon Dec 9 17:33:37 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Dec 2013 12:33:37 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Mon, Dec 9, 2013 at 11:29 AM, Randy Bush wrote: >> (this raised itself above my level of 'fixed in a weekend' project, so >> my comcast v6 lays fallow... NOTE: this is NOT comcast's fault, in my >> eyes.) > > i could take a picture, but i think you would recognize the boat. sigh. I should be fair to the problem (and my lack of patience with it) and: 1) document with some pictures and packet-captures and interface configs 2) take a better stab at making the stock deployment work 3) write all this up somewhere searchable by askjeeves. if work doesn't eat my evening I'll make an attempt at that tonight/tomorrow. -chris From streiner at cluebyfour.org Mon Dec 9 14:14:20 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 9 Dec 2013 09:14:20 -0500 (EST) Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Mon, 9 Dec 2013, Christopher Morrow wrote: > if work doesn't eat my evening I'll make an attempt at that tonight/tomorrow. Thanks for reminding me that I need to get back on Verizon's case about getting IPv6 on Fios... :| jms From morrowc.lists at gmail.com Mon Dec 9 17:51:44 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Dec 2013 12:51:44 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Mon, Dec 9, 2013 at 9:14 AM, Justin M. Streiner wrote: > On Mon, 9 Dec 2013, Christopher Morrow wrote: > >> if work doesn't eat my evening I'll make an attempt at that >> tonight/tomorrow. > > > Thanks for reminding me that I need to get back on Verizon's case about > getting IPv6 on Fios... :| good luck! and I think their plans currently are to provide you CGN first :( (happy if i"m wrong about that) From jlightfoot at gmail.com Mon Dec 9 18:19:46 2013 From: jlightfoot at gmail.com (John Lightfoot) Date: Mon, 09 Dec 2013 13:19:46 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: Since my Fios router has a way to configure IPv6 on it, I turned it on to see but I couldn't get it to work. I called their technical to ask for help/information about IPv6 support and was told "We don't even support IPv5 yet, so it will be a while before we support v6." John Lightfoot On 12/9/13 9:14 AM, "Justin M. Streiner" wrote: On Mon, 9 Dec 2013, Christopher Morrow wrote: > if work doesn't eat my evening I'll make an attempt at that >tonight/tomorrow. Thanks for reminding me that I need to get back on Verizon's case about getting IPv6 on Fios... :| jms From jay at west.net Mon Dec 9 18:22:53 2013 From: jay at west.net (Jay Hennigan) Date: Mon, 09 Dec 2013 10:22:53 -0800 Subject: blogs.cisco.com not available via IPv6 In-Reply-To: References: <529F2FFF.8070504@ifw-dresden.de> <3FA32E339980EB4BBB4935C00A6A8F29218C3D9A@xmb-aln-x09.cisco.com> Message-ID: <52A60A7D.3080201@west.net> On 12/5/13 5:39 PM, Rogan Schlassa wrote: > Please dont reply back with such legal disclaimers. It is basically SPAM > and of course nonsense. > > The thought that you can send a email and force your companies terms on us > is ridiculous. > > If CISCO forces that in your sig then for one tell them to fuck off and two > use a different email. These typically get one of the following from me: NOTICE: This communication may contain confidential and/or privileged information. If you are not the intended recipient or believe that you have received this communication in error you are obligated to kill yourself and anyone else who may have read it, not necessarily in that order. So there. My disclaimer is scarier than yours. Nyaah. You started this silly nonsense. Knock it off and I will too, ok? It's worthless from a legal standpoint and is responsible for the needless suffering of billions of innocent electrons. Nobody reads it anyway. You're not actually reading this, are you? I didn't think so. NOTICE: By sending email to any of my addresses you are agreeing that: 1. I am by definition, "the intended recipient". 2. All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it on newsgroups, forums, and mailing lists. 3. I may take the contents as representing the views of your company. 4. This overrides any disclaimer or statement of confidentiality that may be included on your message. -- 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 michael at supermathie.net Mon Dec 9 18:28:45 2013 From: michael at supermathie.net (Michael Brown) Date: Mon, 09 Dec 2013 13:28:45 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <52A60BDD.1040801@supermathie.net> On 13-12-09 01:19 PM, John Lightfoot wrote: > We don't even support IPv5 yet, so it will be a while before we support v6. Naturally, as the odd-numbered releases of IP are experimental. They should be focusing on the even-numbered releases for production use. M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From jared at puck.nether.net Mon Dec 9 19:03:45 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 9 Dec 2013 14:03:45 -0500 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: <18497386.252.1386607084110.JavaMail.root@benjamin.baylink.com> References: <18497386.252.1386607084110.JavaMail.root@benjamin.baylink.com> Message-ID: On Dec 9, 2013, at 11:38 AM, Jay Ashworth wrote: >> It costs you nothing to let people use capacity that would otherwise go >> to waste, and it increases the perceived value of your service. Your >> customers will eventually find themselves depending on that excess >> capacity often enough that at least some will be willing to pay you >> more to guarantee that it'll be there when they really want it. > > +10 > > We've forgotten the Committed Information Rate already? ATM/FRAME ftw? I think the challenge here is that RF doesn't scale similarly to other mediums. Cost per bit-mile on fiber is really low compared to RF. If you assume 10G-LR optics (10km) @ $299 *2 (pair) + Cvt-5002sfp ($500*2) is around $0.16/Mbit RF (cheap) NB-5G25 = $95*2 (pair) is around $3.16/Mbit (assuming 60Mb/s unidirectional) or almost 20x the cost, assuming 40Mhz channel and spectrum available. While fiber installation can be expensive, one needs to ask the local municipalities to install extra conduit every time the earth is broken for a local project. - Jared From morrowc.lists at gmail.com Mon Dec 9 19:08:11 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Dec 2013 14:08:11 -0500 Subject: turning on comcast v6 In-Reply-To: <52A60BDD.1040801@supermathie.net> References: <52A60BDD.1040801@supermathie.net> Message-ID: On Mon, Dec 9, 2013 at 1:28 PM, Michael Brown wrote: > On 13-12-09 01:19 PM, John Lightfoot wrote: >> >> We don't even support IPv5 yet, so it will be a while before we support >> v6. > > Naturally, as the odd-numbered releases of IP are experimental. They should > be focusing on the even-numbered releases for production use. is this a StarTrek reference? :) From jra at baylink.com Mon Dec 9 19:25:27 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 9 Dec 2013 14:25:27 -0500 (EST) Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: Message-ID: <9884254.266.1386617127330.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > While fiber installation can be expensive, one needs to ask the local > municipalities to install extra conduit every time the earth is broken > for a local project. You will perhaps recall that I put NANOG through teaching me that exact thing last Summer. :-) But Phil was talking about Wireline caps, unless I misunderstood him. Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From james.cutler at consultant.com Mon Dec 9 19:47:00 2013 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 9 Dec 2013 14:47:00 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <3155E00A-16C5-4556-BBBB-D2A9D2FACB24@consultant.com> On Dec 9, 2013, at 12:32 PM, Gary Buhrmaster wrote: > On Mon, Dec 9, 2013 at 4:51 PM, Cutler James R > wrote: > .... >> According to Comcast?s DOCSIS Devices page, http://mydeviceinfo.comcast.net/?s=i&so=1&e=0&d3=1&tier=-1&sc=84, the Cisco DPC3008 is not supported for IPv6. You could always try enabling IPv6 on a system directly connected to the Cisco and see what happens. I?m not optimistic. > > Are you sure you are looking at the correct page? The DPC3008 shows > are supported with IPv6 to me, and since I am using it, it does seem to > work.... The DPC3000, on the other hand is not supported. Oops, I slipped up or down a line scanning across the page. I am now more optimistic. Cutler -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From james.cutler at consultant.com Mon Dec 9 20:10:52 2013 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 9 Dec 2013 15:10:52 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <5C9B8C92-D053-40E0-BE47-DC63EED7A13C@consultant.com> On Dec 9, 2013, at 12:32 PM, Gary Buhrmaster wrote: > On Mon, Dec 9, 2013 at 4:51 PM, Cutler James R > wrote: > .... >> >> I opted for my minimal-effort solution. I installed a Motorola SB6121 and a 5th gen Airport Extreme and turned them on. Of course I configured the Airport Extreme with a name, management password, and confirmed IPv6 was set to to configure Automatically and Native. When the Comcast drop was plugged in and Comcast authorized the modem, I had a multistacked LAN. >> >> Going on 11 months of IPv4/IPv6 service. I?ve had about 1 hour of downtime. > > Not having the device, but a friend does (who has asked about > IPv6 support), does the Airport Extreme support prefix delegation > with a separate guest IPv6 delegation from the non-guest address? > When I looked at the Apple forums, I only saw questions, no > answers regarding that support. > > Gary My testing on OS X Mavericks shows that an Airport5,117 with firmware 7.6.4 creates the guest wireless network: 1. With an IPv4 address from an automatically assigned RFC1918 LAN connected through NAT to WAN. 2. With NO IPv6 addressing of any kind. My conclusion is that Apple does not yet support IPv6 in any fashion for Wireless Guest networks. James R. Cutler james.cutler at consultant.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jean at unistra.fr Mon Dec 9 20:19:20 2013 From: jean at unistra.fr (Jean Benoit) Date: Mon, 9 Dec 2013 21:19:20 +0100 Subject: Routing asymetry and RPF check Message-ID: <20131209201920.GC21229@seti.u-strasbg.fr> Hello, It's probably an old problem which was already debated here. We (130.79/16, AS2259) can't reach 143.104/16 (AS20252). Actually, all packets are dropped on their way back to our network. The probable cause is a conjunction of routing asymetry and uRPF check : - 143.104/16 is behind a US university network. Packets sent *from 143.104/16* to the rest of the Internet are going through National Lambda Rail (NLR), a US. research and education network, - but, as 143.104/16 does not belong to the university but to a hospital (the network has only a couple of hosts related to public research), this prefix is not announced to NLR. So packets from the Internet *to 143.104/16* go through the university commodity Internet link (a mix of different providers). Thus, there is a routing asymetry. - on the other side of the Atlantic, 130.79/16 is behind another research network, RENATER (AS2200). Renater is connected to GEANT, which federates mots of the European research and education networks. GEANT peers with NLR. So the path from 143.104/16 is : Hospital,University(20252),NLR(19401),GEANT(20965),RENATER(2200),Our site(2259) - when a packet arrives from 143.104/16 on a specific RENATER router in Geneva, geneve-rtr-021.noc.renater.fr, it is dropped. - On this router, geneve-rtr-021.noc.renater.fr, RENATER peers with GEANT. - RENATER lookings glass (https://portail.noc.renater.fr/lookingglass/v2/) tells me that the prefix 143.104/16 is not present in this router's routing table (this prefix is not learnt by NLR, and not learnt by GEANT). Moreover, this router seems not to have a full routing table. - On this router, unicast Reverse Path Forwarding check (unsure if it's strict or loose) is enabled on the interface between RENATER and GEANT (PortChannel4.160 to ae14.160 of rt1.gen.ch.geant.net or mx1.gen.ch.geant.net, see https://tools.geant.net/portal/links/lg/) The packets with source IP address 143.104/16 are dropped because the uRPF check fails. So, what do you think should be done ? Thanks for your advice, -- Jean Benoit University of Strasbourg -------------- next part -------------- ---------------------------------------------------------------------- Traceroute from 143.103 to 130.79 : 1 143.104.11.49 0 msec 0 msec 0 msec 2 143.104.11.34 0 msec 0 msec 0 msec 3 10.174.255.146 0 msec 0 msec 0 msec 4 10.174.1.138 0 msec 0 msec 0 msec 5 te-7-1-nydc1-1300-d-core02.med.cornell.edu (10.10.100.6) 0 msec 0 msec 0 msec 6 gi-3-2-nydc1-1300-fw01.med.cornell.edu (157.139.0.129) 0 msec 0 msec 0 msec 7 vl-10-nydc1-1300-ingw01.med.cornell.edu (157.139.0.65) 0 msec 0 msec 4 msec 8 157.139.255.9 0 msec 0 msec 4 msec 9 * * * 10 216.24.184.86 84 msec 84 msec 84 msec 11 ae3.mx1.ams.nl.geant.net (62.40.98.115) 92 msec 84 msec 84 msec 12 ae0.mx1.fra.de.geant.net (62.40.98.128) 84 msec 84 msec 88 msec 13 ae1.mx1.gen.ch.geant.net (62.40.98.108) 108 msec 104 msec 96 msec 14 ae2.rt1.gen.ch.geant.net (62.40.112.13) 92 msec 92 msec 92 msec 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * ---------------------------------------------------------------------- From rubensk at gmail.com Mon Dec 9 20:22:11 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 9 Dec 2013 18:22:11 -0200 Subject: turning on comcast v6 In-Reply-To: References: <52A60BDD.1040801@supermathie.net> Message-ID: On Mon, Dec 9, 2013 at 5:08 PM, Christopher Morrow wrote: > > On Mon, Dec 9, 2013 at 1:28 PM, Michael Brown wrote: > > On 13-12-09 01:19 PM, John Lightfoot wrote: > >> > >> We don't even support IPv5 yet, so it will be a while before we support > >> v6. > > > > Naturally, as the odd-numbered releases of IP are experimental. They should > > be focusing on the even-numbered releases for production use. > > is this a StarTrek reference? :) > Or a Linux kernel reference, which in turn could be a Star Trek reference... Rubens From swmike at swm.pp.se Mon Dec 9 20:37:19 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 9 Dec 2013 21:37:19 +0100 (CET) Subject: turning on comcast v6 In-Reply-To: <5C9B8C92-D053-40E0-BE47-DC63EED7A13C@consultant.com> References: <5C9B8C92-D053-40E0-BE47-DC63EED7A13C@consultant.com> Message-ID: On Mon, 9 Dec 2013, Cutler James R wrote: > My conclusion is that Apple does not yet support IPv6 in any fashion for > Wireless Guest networks. Works for me on 7.7.2 on the latest hardware (802.1ac version with time capsule hdd). PD and everything. -- Mikael Abrahamsson email: swmike at swm.pp.se From mark at amplex.net Mon Dec 9 20:39:01 2013 From: mark at amplex.net (Mark Radabaugh) Date: Mon, 09 Dec 2013 15:39:01 -0500 Subject: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO) In-Reply-To: References: <18497386.252.1386607084110.JavaMail.root@benjamin.baylink.com> Message-ID: <52A62A65.5060208@amplex.net> On 12/9/13 2:03 PM, Jared Mauch wrote: > On Dec 9, 2013, at 11:38 AM, Jay Ashworth wrote: > >>> It costs you nothing to let people use capacity that would otherwise go >>> to waste, and it increases the perceived value of your service. Your >>> customers will eventually find themselves depending on that excess >>> capacity often enough that at least some will be willing to pay you >>> more to guarantee that it'll be there when they really want it. >> +10 >> >> We've forgotten the Committed Information Rate already? > ATM/FRAME ftw? > > I think the challenge here is that RF doesn't scale similarly to other mediums. > > Cost per bit-mile on fiber is really low compared to RF. > > If you assume 10G-LR optics (10km) @ $299 *2 (pair) + Cvt-5002sfp ($500*2) > > is around $0.16/Mbit > > RF (cheap) NB-5G25 = $95*2 (pair) is around $3.16/Mbit (assuming 60Mb/s unidirectional) or almost 20x the cost, assuming 40Mhz channel and spectrum available. > > While fiber installation can be expensive, one needs to ask the local municipalities to install extra conduit every time the earth is broken for a local project. > > - Jared > Jared, It's a lot worse on RF if you want to be able to scale to >100 customers per tower site. Ubiquiti gear (NB-5G25) is dirt cheap but doesn't scale. To make it work with any kind of customer density you need Cambium, Radwin, Redline, or a manufacturer who has GPS sync working properly. 70Mb = $3000 (AP + Sector antenna) + 400 (client equipment) for about $48.50/Mbit. LTE is significantly higher given base station cost and spectrum licensing. Letting customers use 'idle' bandwidth is great in theory but in practice it has a few problems. We have experience with this as we have allowed our users to burst to maximum available speed for many years. a) Customers become acclimated to burst speed. Customers complain bitterly if the speed test that used to say 20Mb now says 6Mb even though they are paying for 3.5Mb. The provider is obviously an evil bastard and gouging them while overloading the towers. b) Streaming video doesn't always deal well with changing speeds. Netflix essentially runs a speed test at the start of the stream to decide on a resolution. If it picks HD and then reaches the sustained limit (or in this model other users start requesting CIR bandwidth) Netflix does not always gracefully back down and results in a buffering or 'your connection has slowed' message. c) Trying to explain 'burst' to customers is difficult at best. Leaky bucket policers / CIR / etc. confuse engineers. Good luck getting Grandma to understand it. We regularly get customers who are confused between 5Mbps (our plans) and 5GB (cell phone plans). It's not unusual to lose a customer to a 'faster 5GB LTE connection for $40/mo' from a uncapped 5Mbps $54.95 service plan. It's really not surprising when you hear back from them 2 months later when they get a $400 bill from VerizaTT. I really like the new cell company game - no overage fees for the first 60 days, and you have 30 days to cancel your 2 year service plan if you don't like it. Mark -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 x 1021 From james.cutler at consultant.com Mon Dec 9 20:51:56 2013 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 9 Dec 2013 15:51:56 -0500 Subject: turning on comcast v6 In-Reply-To: References: <5C9B8C92-D053-40E0-BE47-DC63EED7A13C@consultant.com> Message-ID: <6890EAE2-3EB0-4BD5-8AD4-5A9402C47B54@consultant.com> On Dec 9, 2013, at 3:37 PM, Mikael Abrahamsson wrote: > On Mon, 9 Dec 2013, Cutler James R wrote: > >> My conclusion is that Apple does not yet support IPv6 in any fashion for Wireless Guest networks. > > Works for me on 7.7.2 on the latest hardware (802.1ac version with time capsule hdd). PD and everything. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se This is not unusual for Apple. Apple often does not support what seem to be firmware improvements on earlier hardware. For example, the first generation GB Ethernet Airport Extreme does not support native IPv6 from the WAN provider. Connection to Comcast IPv6 drove upgrading to the latest and greatest Airport Extreme available at that time. This is disappointing to me as a user but good for me as an Apple stockholder - James R. Cutler james.cutler at consultant.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jared at puck.nether.net Mon Dec 9 21:06:28 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 9 Dec 2013 16:06:28 -0500 Subject: turning on comcast v6 In-Reply-To: <6890EAE2-3EB0-4BD5-8AD4-5A9402C47B54@consultant.com> References: <5C9B8C92-D053-40E0-BE47-DC63EED7A13C@consultant.com> <6890EAE2-3EB0-4BD5-8AD4-5A9402C47B54@consultant.com> Message-ID: On Dec 9, 2013, at 3:51 PM, Cutler James R wrote: > This is disappointing to me as a user but good for me as an Apple stockholder I stopped using their [network] hardware and shifted to using real Access-Points do perform that function. They provide too little intelligence when there is trouble, so rebooting becomes standard operating procedure. I went to unifi hardware for my house and have been very happy since. A bit "overkill", but I can ssh in and poke, as well as use the admin webpage to futz with settings and see when the kids wake up and are on the internet at 5am when they should be sleeping. I can setup a 802.1q trunk/vlan and do guestnet with varying levels of access/speed. I do need to install an outdoor unit in the back of the yard to improve coverage there :) - Jared From james.cutler at consultant.com Mon Dec 9 21:32:42 2013 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 9 Dec 2013 16:32:42 -0500 Subject: turning on comcast v6 In-Reply-To: References: <5C9B8C92-D053-40E0-BE47-DC63EED7A13C@consultant.com> <6890EAE2-3EB0-4BD5-8AD4-5A9402C47B54@consultant.com> Message-ID: <676DBC93-43BB-41AC-84A7-BBA97F39BF5E@consultant.com> On Dec 9, 2013, at 4:06 PM, Jared Mauch wrote: > > On Dec 9, 2013, at 3:51 PM, Cutler James R wrote: > >> This is disappointing to me as a user but good for me as an Apple stockholder > > I stopped using their [network] hardware and shifted to using real Access-Points do perform that function. I support too many people using the Apple Ecosystem to not maintain my own instance. My only third-party tool is a configuration file analysis shell script. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Valdis.Kletnieks at vt.edu Mon Dec 9 17:34:49 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Dec 2013 12:34:49 -0500 Subject: turning on comcast v6 In-Reply-To: Your message of "Mon, 09 Dec 2013 11:51:46 -0500." References: Message-ID: <228039.1386610489@turing-police.cc.vt.edu> On Mon, 09 Dec 2013 11:51:46 -0500, Cutler James R said: > According to Comcast's DOCSIS Devices page, > http://mydeviceinfo.comcast.net/?s=3Di&so=1&e=0&d3=1&tier=-1&sc=84 > the Cisco DPC3008 is not supported for IPv6. You could always try > enabling IPv6 on a system directly connected to the Cisco and see what > happens. I'm not optimistic. That page also says the Zoom 5341 cable modem doesn't do IPv6, although the device in my living room says it does indeed do so but its upstream refuses to provision it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From efinley.lists at gmail.com Mon Dec 9 22:29:13 2013 From: efinley.lists at gmail.com (Elliot Finley) Date: Mon, 9 Dec 2013 15:29:13 -0700 Subject: What routers do folks use these days? In-Reply-To: <52984E15.3070307@init7.net> References: <529827FC.8040603@forethought.net> <52984E15.3070307@init7.net> Message-ID: +1 for Brocade MLXe. Good Price. Good stuff. Good TAC. On Fri, Nov 29, 2013 at 1:19 AM, Fredy Kuenzler wrote: > Am 29.11.2013 06:37, schrieb Jawaid Desktop: > > We're a service provider, and we have a network full of Cat6509's. > > We are finding that we are outgrowing them from the standpoint of > > their ability to handle lots of large routing tables. Obviously > > their switching capability is still superb but one of them with 20 > > peers is starting to groan a bit and RAM is going to be an issue > > soon. > > > > What do people use these days? Our backbone needs in the next 2-3 > > years are going to be sub-100Gbps. > > Check the Brocade MLXe series. We (Init7 / AS13030) are using them and > the previous XMR series for years and are happy with it. CLI is > Cisco-look-and-feel, the software tree has a clear structure (unlike > Cisco with hundreds of versions) and the TAC is willing to ssh into your > gear to assist. > > -- > Fredy Kuenzler > > Init7 (Switzerland) Ltd. > AS13030 > St. Georgen-Strasse 70 > CH-8400 Winterthur > Twitter: @init7 / @kuenzler > http://www.init7.net/ > > From Petter.Bruland at allegiantair.com Mon Dec 9 23:04:10 2013 From: Petter.Bruland at allegiantair.com (Petter Bruland) Date: Mon, 9 Dec 2013 23:04:10 +0000 Subject: What routers do folks use these days? In-Reply-To: References: <529827FC.8040603@forethought.net> <52984E15.3070307@init7.net> Message-ID: +1 for Brocade MLXe. Used on our edge and *knock on wood* have not had any issues with it ever. Full BGP routing table, multiple VRFs, QoS / bandwidth management. We also have a few Brocade CER series routers, which are awesome as well for metro edge. And for political reasons a bunch of Cisco Nexus/Cat4500 gear in the core... -P -----Original Message----- From: Elliot Finley [mailto:efinley.lists at gmail.com] Sent: Monday, December 09, 2013 2:29 PM Cc: nanog list Subject: Re: What routers do folks use these days? +1 for Brocade MLXe. Good Price. Good stuff. Good TAC. On Fri, Nov 29, 2013 at 1:19 AM, Fredy Kuenzler wrote: > Am 29.11.2013 06:37, schrieb Jawaid Desktop: > > We're a service provider, and we have a network full of Cat6509's. > > We are finding that we are outgrowing them from the standpoint of > > their ability to handle lots of large routing tables. Obviously > > their switching capability is still superb but one of them with 20 > > peers is starting to groan a bit and RAM is going to be an issue > > soon. > > > > What do people use these days? Our backbone needs in the next 2-3 > > years are going to be sub-100Gbps. > > Check the Brocade MLXe series. We (Init7 / AS13030) are using them and > the previous XMR series for years and are happy with it. CLI is > Cisco-look-and-feel, the software tree has a clear structure (unlike > Cisco with hundreds of versions) and the TAC is willing to ssh into > your gear to assist. > > -- > Fredy Kuenzler > > Init7 (Switzerland) Ltd. > AS13030 > St. Georgen-Strasse 70 > CH-8400 Winterthur > Twitter: @init7 / @kuenzler > http://www.init7.net/ > > From netfortius at gmail.com Tue Dec 10 01:44:59 2013 From: netfortius at gmail.com (Stefan) Date: Mon, 9 Dec 2013 19:44:59 -0600 Subject: Network Lifecycle Management - anybody??? Message-ID: As $subj may infer, do you guys follow any type of network lifecycle in your environment? If so - what would be some criteria you would consider critical: - consistent rate of cash flow, year after year, while replacing aging gear (allowing for consistent budgetary planning) - risk reduction while replacing unsupported equipment - security issues associated with OS or appliances not supported - business / apps demand for capacity or features (e.g. virtualization, SDN, etc.), laid out well in advance to allow for a 3-4-5 yrs plan with a consistent replacement rate of aging equipment - increased costs of support for aging equipment, or recertification for vendor support - anything else ... ??? Care to share some [other] aspects, as they may relate to $subj? Thanks, ***Stefan From streiner at cluebyfour.org Mon Dec 9 23:52:15 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 9 Dec 2013 18:52:15 -0500 (EST) Subject: Network Lifecycle Management - anybody??? In-Reply-To: References: Message-ID: On Mon, 9 Dec 2013, Stefan wrote: > As $subj may infer, do you guys follow any type of network lifecycle in > your environment? If so - what would be some criteria you would consider > critical: You'll probably get lots of different answers to this question depending on where people are working. The lifecycle criteria for an enterprise can be very different from a service provider, .edu, K-12, etc. > - risk reduction while replacing unsupported equipment > - security issues associated with OS or appliances not supported In my $dayjob environment, we generally try to have gear out of produciton before it goes EOS/EOL. For things like closet switches, the main driver is more about keeping current on security issues, since we often have spare hardware to take care of things like chassis failures, etc. For core gear, maintaining a vendor-supported setup is the main driver. Other organizations might also have separate lifecycle plans for core vs. non-core gear. Financially, the amount of capex/opex per device can make a difference. A smaller number of core routers/switches might be expected to have a longer service life (preferably extendable through module upgrades before a forklift replacement is needed) and depreciation schedule than a larger number of smaller access/edge switches, regardless of the expenditure. I generally don't want to forklift core gear more often than about 5-7 years, though business and technical realities might dictate otherwise. > - business / apps demand for capacity or features (e.g. virtualization, > SDN, etc.), laid out well in advance to allow for a 3-4-5 yrs plan with a > consistent replacement rate of aging equipment We've been doing this with things like wireless APs - replacing older ones over time in addition to installing new ones to keep up with the demand for coverage. > - increased costs of support for aging equipment, or recertification for > vendor support > - anything else ... ??? As much as I hate to say it - politics does play a factor in many environments. In the academic world, 'keeping up with the Joneses' has certainly factored into some technology purchasing decisions. In other words: "xyz.edu is deploying $blah. We need to deploy $blah, too." From mysidia at gmail.com Tue Dec 10 03:34:32 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 9 Dec 2013 21:34:32 -0600 Subject: What routers do folks use these days? In-Reply-To: References: <529827FC.8040603@forethought.net> Message-ID: On Fri, Nov 29, 2013 at 12:02 AM, Mikael Abrahamsson wrote: > [snip] > +1 for MX or ASR 9000. > Cisco ASR 9000, Juniper MX, Huawei NE40E, Alcatel-Lucent 7750, those kinds > of routers are the ones I hear people using. Some go for the new Sup2T for > the 6500, but I don't know how much more CPU it has compared to your > SUP/RSP720, perhaps someone else knows? Cat6500 Sup720 was a platform that used two separate processors; 1 Switch Processor CPU at 600mhz managing Layer 2 services, and 1 Route processor CPU at 600MHz on the MSFC to run the Layer 3 services. these were MIPS CPUs --- sr71000. Cat650 Sup2T is shown as a single Dual core, 1.5GHz per Core cpu. There is one processor stack on the 2T, instead of two separate CPUs; since route processor and switch processor are now combined into one shared processing unit under the new "merged" architecture that runs only one IOS image, that controls both RP and SP features ---- Layer 2, Layer 3, and management services do not run on separate processors, with their own separate hw anymore. So the CPU is beefier --- but it is also now shared by multiple functions that previously had separate, isolated processing from one another. I believe the Sup2T are using a E500 PowerPC chip. In any event, neither old nor new are based on x86 architecture --- keep in mind, that comparison of MHz or GHz CPU frequency rates is only meaningful within the same CPU architecture. There are not significant increases in FIB TCAM, or other important memory capacities from RSP720, that you would expect to need for scalability to larger tables. Even with 2T I would still describe the 65xx as largely a great switching platform, for 10/100/1000 aggregation -- due to limited chassis bandwidth: its days would seem to be numbered once desktops are sporting 10 gigabit links: definitely not (IMO) the best hardware router platform for carrying large routing tables at the ISP edge, anyways. > Mikael Abrahamsson email: swmike at swm.pp.se > -- -JH From james.braunegg at micron21.com Tue Dec 10 10:15:10 2013 From: james.braunegg at micron21.com (James Braunegg) Date: Tue, 10 Dec 2013 10:15:10 +0000 Subject: What routers do folks use these days? In-Reply-To: References: <529827FC.8040603@forethought.net> <52984E15.3070307@init7.net> Message-ID: +2 for Brocade MLXe we use them globally now for almost 3 years and are very happy with them !! Brocade Rocks !! period !! Kindest Regards James Braunegg P:? 1300 769 972? |? M:? 0488 997 207 |? D:? (03) 9751 7616 E:?? james.braunegg at micron21.com? |? ABN:? 12 109 977 666?? W:??www.micron21.com/ip-transit T:?@micron21 This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: Elliot Finley [mailto:efinley.lists at gmail.com] Sent: Tuesday, December 10, 2013 9:29 AM Cc: nanog list Subject: Re: What routers do folks use these days? +1 for Brocade MLXe. Good Price. Good stuff. Good TAC. On Fri, Nov 29, 2013 at 1:19 AM, Fredy Kuenzler wrote: > Am 29.11.2013 06:37, schrieb Jawaid Desktop: > > We're a service provider, and we have a network full of Cat6509's. > > We are finding that we are outgrowing them from the standpoint of > > their ability to handle lots of large routing tables. Obviously > > their switching capability is still superb but one of them with 20 > > peers is starting to groan a bit and RAM is going to be an issue > > soon. > > > > What do people use these days? Our backbone needs in the next 2-3 > > years are going to be sub-100Gbps. > > Check the Brocade MLXe series. We (Init7 / AS13030) are using them and > the previous XMR series for years and are happy with it. CLI is > Cisco-look-and-feel, the software tree has a clear structure (unlike > Cisco with hundreds of versions) and the TAC is willing to ssh into > your gear to assist. > > -- > Fredy Kuenzler > > Init7 (Switzerland) Ltd. > AS13030 > St. Georgen-Strasse 70 > CH-8400 Winterthur > Twitter: @init7 / @kuenzler > http://www.init7.net/ > > From andreas.larsen at ip-only.se Tue Dec 10 10:19:27 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Tue, 10 Dec 2013 11:19:27 +0100 Subject: SV: What routers do folks use these days? In-Reply-To: References: <529827FC.8040603@forethought.net> Message-ID: Same here using MX routers and Brocade +1 for MX due to the "unix" shell =) Med v?nlig h?lsning Andreas Larsen ? IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se -----Ursprungligt meddelande----- Fr?n: Jimmy Hess [mailto:mysidia at gmail.com] Skickat: den 10 december 2013 04:35 Till: Mikael Abrahamsson Kopia: NANOG list; Jawaid Desktop ?mne: Re: What routers do folks use these days? On Fri, Nov 29, 2013 at 12:02 AM, Mikael Abrahamsson wrote: > [snip] > +1 for MX or ASR 9000. > Cisco ASR 9000, Juniper MX, Huawei NE40E, Alcatel-Lucent 7750, those > kinds of routers are the ones I hear people using. Some go for the new > Sup2T for the 6500, but I don't know how much more CPU it has compared > to your SUP/RSP720, perhaps someone else knows? Cat6500 Sup720 was a platform that used two separate processors; 1 Switch Processor CPU at 600mhz managing Layer 2 services, and 1 Route processor CPU at 600MHz on the MSFC to run the Layer 3 services. these were MIPS CPUs --- sr71000. Cat650 Sup2T is shown as a single Dual core, 1.5GHz per Core cpu. There is one processor stack on the 2T, instead of two separate CPUs; since route processor and switch processor are now combined into one shared processing unit under the new "merged" architecture that runs only one IOS image, that controls both RP and SP features ---- Layer 2, Layer 3, and management services do not run on separate processors, with their own separate hw anymore. So the CPU is beefier --- but it is also now shared by multiple functions that previously had separate, isolated processing from one another. I believe the Sup2T are using a E500 PowerPC chip. In any event, neither old nor new are based on x86 architecture --- keep in mind, that comparison of MHz or GHz CPU frequency rates is only meaningful within the same CPU architecture. There are not significant increases in FIB TCAM, or other important memory capacities from RSP720, that you would expect to need for scalability to larger tables. Even with 2T I would still describe the 65xx as largely a great switching platform, for 10/100/1000 aggregation -- due to limited chassis bandwidth: its days would seem to be numbered once desktops are sporting 10 gigabit links: definitely not (IMO) the best hardware router platform for carrying large routing tables at the ISP edge, anyways. > Mikael Abrahamsson email: swmike at swm.pp.se > -- -JH From Jason_Livingood at cable.comcast.com Tue Dec 10 12:41:48 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Tue, 10 Dec 2013 12:41:48 +0000 Subject: turning on comcast v6 In-Reply-To: <228039.1386610489@turing-police.cc.vt.edu> References: <228039.1386610489@turing-police.cc.vt.edu> Message-ID: <10229F86C86EB444898E629583FD4171EDE9EDBF@PACDCEXMB06.cable.comcast.com> On 12/9/13, 12:34 PM, "Valdis.Kletnieks at vt.edu" wrote: >On Mon, 09 Dec 2013 11:51:46 -0500, Cutler James R said: > >> According to Comcast's DOCSIS Devices page, >> http://mydeviceinfo.comcast.net/?s=3Di&so=1&e=0&d3=1&tier=-1&sc=84 >> the Cisco DPC3008 is not supported for IPv6. You could always try >> enabling IPv6 on a system directly connected to the Cisco and see what >> happens. I'm not optimistic. > >That page also says the Zoom 5341 cable modem doesn't do IPv6, although >the device in my living room says it does indeed do so but its upstream >refuses to provision it. While I won't speak to specific device makes/models, we at Comcast add a device to the v6 list after we have tested and shown that it works. In my experience, hearing "our device/router/software/whatever supports IPv6? isn?t generally specific enough and often doesn?t mean much until it has been tested. ;-) Jason From alexwr at gmail.com Tue Dec 10 21:13:12 2013 From: alexwr at gmail.com (Alex White-Robinson) Date: Wed, 11 Dec 2013 10:13:12 +1300 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? Message-ID: Wotcha, >Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) >since you have to treat each boxes as if it was public. I see this kind of statement surprisingly often. Having a public address doesn't make a device public. I don't really see a drive to have devices exposed to the internet without a stateful device in front of them in IPv6 world. People shouldn't allow unsolicited connections to hit your internal workstation on any address scheme. Cheers, Alex. Date: Tue, 10 Dec 2013 05:56:41 +1300 From: Pieter De Wit To: nznog at list.waikato.ac.nz Subject: Re: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? Message-ID: <52A5F649.7070904 at insync.za.net> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Hi, I normally use a combination of "1" and "2". I prefer 1 for weird and "not nat friendly" protocols, like SIP or some other application. The general rule of thumb is to use number 2 in other cases. In both setups, remember to deploy local firewalls as well. This will help for the case when a box on the subnet is hacked. My other twist is to deploy "1" without the private NIC, along with local firewalls (and as you said, dedicated FW). Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) since you have to treat each boxes as if it was public. Cheers, Pieter From web at typo.org Tue Dec 10 21:18:13 2013 From: web at typo.org (Wayne E Bouchard) Date: Tue, 10 Dec 2013 14:18:13 -0700 Subject: What routers do folks use these days? In-Reply-To: References: <529827FC.8040603@forethought.net> <52984E15.3070307@init7.net> Message-ID: <20131210211813.GA57972@wakko.typo.org> Brocade MLXe with the XMR cards is a good choice, yes, but -1 for "What do you mean that this feature isn't fully implemented yet?? It's been in common use among other vendors for better than 10 years!" They're a lot better than they were but still a bit lagging. -Wayne On Tue, Dec 10, 2013 at 10:15:10AM +0000, James Braunegg wrote: > +2 for Brocade MLXe we use them globally now for almost 3 years and are very happy with them !! > > Brocade Rocks !! period !! > > Kindest Regards > > James Braunegg > P:? 1300 769 972? |? M:? 0488 997 207 |? D:? (03) 9751 7616 > E:?? james.braunegg at micron21.com? |? ABN:? 12 109 977 666?? > W:??www.micron21.com/ip-transit T:?@micron21 > > > > This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. > > > -----Original Message----- > From: Elliot Finley [mailto:efinley.lists at gmail.com] > Sent: Tuesday, December 10, 2013 9:29 AM > Cc: nanog list > Subject: Re: What routers do folks use these days? > > +1 for Brocade MLXe. Good Price. Good stuff. Good TAC. > > > On Fri, Nov 29, 2013 at 1:19 AM, Fredy Kuenzler wrote: > > > Am 29.11.2013 06:37, schrieb Jawaid Desktop: > > > We're a service provider, and we have a network full of Cat6509's. > > > We are finding that we are outgrowing them from the standpoint of > > > their ability to handle lots of large routing tables. Obviously > > > their switching capability is still superb but one of them with 20 > > > peers is starting to groan a bit and RAM is going to be an issue > > > soon. > > > > > > What do people use these days? Our backbone needs in the next 2-3 > > > years are going to be sub-100Gbps. > > > > Check the Brocade MLXe series. We (Init7 / AS13030) are using them and > > the previous XMR series for years and are happy with it. CLI is > > Cisco-look-and-feel, the software tree has a clear structure (unlike > > Cisco with hundreds of versions) and the TAC is willing to ssh into > > your gear to assist. > > > > -- > > Fredy Kuenzler > > > > Init7 (Switzerland) Ltd. > > AS13030 > > St. Georgen-Strasse 70 > > CH-8400 Winterthur > > Twitter: @init7 / @kuenzler > > http://www.init7.net/ > > > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From geraint at koding.com Tue Dec 10 22:30:14 2013 From: geraint at koding.com (Geraint Jones) Date: Wed, 11 Dec 2013 11:30:14 +1300 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: Message-ID: On 11/12/13 10:13 am, "Alex White-Robinson" wrote: >Wotcha, > >>Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) >>since you have to treat each boxes as if it was public. > >I see this kind of statement surprisingly often. Having a public address >doesn't make a device public. Yes it does, it makes end to end connectivity work again. NAT broke that (and its one of the best things about v6). People have been relying on the fact that you need rules to get through a NAT to reach a box - thereby having NAT work as an inbound firewall. NAT != Security. But yes having a public address means your box is public, you have to do something to STOP traffic getting to it. With NAT you have to do something to ENABLE traffic to get to it. >I don't really see a drive to have devices exposed to the internet without >a stateful device in front of them in IPv6 world. People shouldn't allow >unsolicited connections to hit your internal workstation on any address >scheme. > >Cheers, >Alex. > > >Date: Tue, 10 Dec 2013 05:56:41 +1300 >From: Pieter De Wit >To: nznog at list.waikato.ac.nz >Subject: Re: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? >Message-ID: <52A5F649.7070904 at insync.za.net> >Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > >Hi, > >I normally use a combination of "1" and "2". I prefer 1 for weird and >"not nat friendly" protocols, like SIP or some other application. The >general rule of thumb is to use number 2 in other cases. In both setups, >remember to deploy local firewalls as well. This will help for the case >when a box on the subnet is hacked. > >My other twist is to deploy "1" without the private NIC, along with >local firewalls (and as you said, dedicated FW). > >Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) >since you have to treat each boxes as if it was public. > >Cheers, > >Pieter From matthew at corp.crocker.com Tue Dec 10 23:50:53 2013 From: matthew at corp.crocker.com (Matthew Crocker) Date: Tue, 10 Dec 2013 18:50:53 -0500 Subject: Cogent & Level 3 routing issue? In-Reply-To: <4CC28F49-FB40-4945-8B30-9C7CBB9F0EA6@corp.crocker.com> References: <52A387D3.6000907@unlimitednet.us> <4CC28F49-FB40-4945-8B30-9C7CBB9F0EA6@corp.crocker.com> Message-ID: Cogent found the problem today. It took them 4 days to do a ?show conf? and see that an outbound access-list was applied to my interface by mistake during a ?normal maintenance window at 8AM EST on Friday? 4 days of jumping through hoops to prove that the problem wasn?t on my network. grumble. -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Dec 7, 2013, at 7:58 PM, Matthew Crocker wrote: > > On Dec 7, 2013, at 3:40 PM, Jason Canady wrote: > >> Unfortunately Cogent has a lot of peering issues. We use them in our network blend and we have been having lots of problems with traffic outbound to Comcast. It looks like from South Bend, Indiana on Cogent to Chicago / Level 3 we are getting a very tiny amount of packet loss and a higher than 'normal' latency of 35ms+. > > Yeah, I know they are always my secondary, never my primary >> >> Where are you connected to Cogent at? And what destination are you going to on Level 3? >> > > Boston (300 Bent) but I think they haul it to 1 Summer St > > A bunch of sites fail but www.cnn.com is one that comes to mind. > >> Best Regards, >> >> -- >> >> Jason Canady >> Unlimited Net, LLC >> Responsive, Reliable, Secure >> >> www.unlimitednet.us >> jason at unlimitednet.us >> twitter: @unlimitednet >> >> On 12/7/13 3:14 PM, Matthew Crocker wrote: >>> Anyone seeing issues between Cogent & Level3 in NYC? >>> >>> I have Sprint & Cogent for bandwidth. Everything has been humming along for a couple years just fine. Yesterday around 8:00AM my BGP session with Cogent flapped. Now, when my Cogent BGP is up I get 100% packet loss in level3 land. When Cogent BGP is down (i.e. I?m running solely on Sprint) Everything is fine. >>> >>> I have an open ticket with Cogent. They say they have a ?capacity issue? with level3 that has been escalated to executive levels. >>> >>> With Sprint & Cogent BGP UP >>> I see traceroutes showing traffic leaving me on Sprint but returning on Cogent (and failing at level3). I?m guessing it is the level3/cogent border >>> >>> With Sprint UP & Cogent Down >>> I see trace routes showing traffic on to/from on Sprint just fine. >>> >>> >>> Anyone else having issues? >>> >>> -Matt >>> >>> -- >>> Matthew S. Crocker >>> President >>> Crocker Communications, Inc. >>> PO BOX 710 >>> Greenfield, MA 01302-0710 >>> >>> E: matthew at crocker.com >>> P: (413) 746-2760 >>> F: (413) 746-3704 >>> W: http://www.crocker.com >>> >>> >>> >>> >> >> >> > From sshafi at gmail.com Tue Dec 10 23:57:20 2013 From: sshafi at gmail.com (Shahid Shafi) Date: Tue, 10 Dec 2013 15:57:20 -0800 Subject: Equinix type colo/Data Center in South Korea Message-ID: I am wondering if anyone has experience hosting services in South Korea, who did you choose for colocation services and in what city? thanks, shahid From tom at cloudflare.com Wed Dec 11 00:21:37 2013 From: tom at cloudflare.com (Tom Paseka) Date: Tue, 10 Dec 2013 16:21:37 -0800 Subject: Equinix type colo/Data Center in South Korea In-Reply-To: References: Message-ID: KINX is the best bet. http://idc.kinx.net/eng/ On Tue, Dec 10, 2013 at 3:57 PM, Shahid Shafi wrote: > I am wondering if anyone has experience hosting services in South Korea, > who did you choose for colocation services and in what city? > > thanks, > shahid > From LarrySheldon at cox.net Wed Dec 11 00:47:07 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 10 Dec 2013 18:47:07 -0600 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: References: Message-ID: <52A7B60B.7070809@cox.net> On 12/10/2013 4:30 PM, Geraint Jones wrote: >>> Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) >>> since you have to treat each boxes as if it was public. >> >> I see this kind of statement surprisingly often. Having a public address >> doesn't make a device public. > > Yes it does, Glad to hear that. We (the family, 8 of us, and the 4 dogs will be arriving at your house, with its public address, in time for your Christmas dinner and we will be staying at least through your New Years eve party--maybe longer depending on the weather here. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From geraint at koding.com Wed Dec 11 01:05:30 2013 From: geraint at koding.com (Geraint Jones) Date: Wed, 11 Dec 2013 14:05:30 +1300 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: <52A7B60B.7070809@cox.net> Message-ID: On 11/12/13 1:47 pm, "Larry Sheldon" wrote: >On 12/10/2013 4:30 PM, Geraint Jones wrote: > >>>> Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) >>>> since you have to treat each boxes as if it was public. >>> >>> I see this kind of statement surprisingly often. Having a public >>>address >>> doesn't make a device public. >> >> Yes it does, > >Glad to hear that. We (the family, 8 of us, and the 4 dogs will be >arriving at your house, with its public address, in time for your >Christmas dinner and we will be staying at least through your New Years >eve party--maybe longer depending on the weather here. I think your dogs may struggle with NZ customs. > >-- >Requiescas in pace o email Two identifying characteristics > of System Administrators: >Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From cb.list6 at gmail.com Wed Dec 11 01:27:23 2013 From: cb.list6 at gmail.com (cb.list6) Date: Tue, 10 Dec 2013 17:27:23 -0800 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: References: Message-ID: On Dec 10, 2013 2:32 PM, "Geraint Jones" wrote: > > On 11/12/13 10:13 am, "Alex White-Robinson" wrote: > > > >Wotcha, > > > >>Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) > >>since you have to treat each boxes as if it was public. > > > >I see this kind of statement surprisingly often. Having a public address > >doesn't make a device public. > > Yes it does, it makes end to end connectivity work again. NAT broke that > (and its one of the best things about v6). People have been relying on the > fact that you need rules to get through a NAT to reach a box - thereby > having NAT work as an inbound firewall. NAT != Security. > > But yes having a public address means your box is public, you have to do > something to STOP traffic getting to it. With NAT you have to do something > to ENABLE traffic to get to it. > Correct. IPv6 correctly supports the end to end model. Firewalls can be scalably implemented on host, not middle boxes. The firewall mindset is locked in from the win2k days, NAT reinforced that, and it is worth re-evaluated removing firewalls with ipv6 Question: are nanog meeting networks stateful firewalled? Follow up question -- if there is no firewall, do folks experience a higher degree of malware infection after the meeting ? CB > >I don't really see a drive to have devices exposed to the internet without > >a stateful device in front of them in IPv6 world. People shouldn't allow > >unsolicited connections to hit your internal workstation on any address > >scheme. > > > >Cheers, > >Alex. > > > > > >Date: Tue, 10 Dec 2013 05:56:41 +1300 > >From: Pieter De Wit > >To: nznog at list.waikato.ac.nz > >Subject: Re: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? > >Message-ID: <52A5F649.7070904 at insync.za.net> > >Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > > >Hi, > > > >I normally use a combination of "1" and "2". I prefer 1 for weird and > >"not nat friendly" protocols, like SIP or some other application. The > >general rule of thumb is to use number 2 in other cases. In both setups, > >remember to deploy local firewalls as well. This will help for the case > >when a box on the subnet is hacked. > > > >My other twist is to deploy "1" without the private NIC, along with > >local firewalls (and as you said, dedicated FW). > > > >Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) > >since you have to treat each boxes as if it was public. > > > >Cheers, > > > >Pieter > > > From jared at puck.nether.net Wed Dec 11 01:32:49 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 10 Dec 2013 20:32:49 -0500 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: References: Message-ID: <7ECD3FCE-724D-46CF-8244-FBC2C5A33C67@puck.nether.net> On Dec 10, 2013, at 8:27 PM, cb.list6 wrote: > Correct. IPv6 correctly supports the end to end model. Yes, if you know the IP address of my printer you can use up my toner (it?s already low) and paper. Then again, It?s IPv6 so good luck finding it. The first nibble is 2. Let me know when you?ve found it. :) I?ve actually had to deal with too many networks that perform MITM or other activities that I actually find it useful to VPN to get a public, unfiltered IP address. The days of a machine that are hit with malware in minutes/seconds are done. The background radiation is still there, but it?s far more effective to use other methods (spam, social networks, ad networks, etc)? Doesn?t mean that?s the only way, but many of the ?easily exploitable? methods from a decade ago are no longer there. - Jared From christopher.morrell.nanog at gmail.com Wed Dec 11 01:36:06 2013 From: christopher.morrell.nanog at gmail.com (Christopher Morrell) Date: Tue, 10 Dec 2013 20:36:06 -0500 Subject: Contact for www.army.mil (AS1503 ) Message-ID: Hi, We are currently having routing issues between one of our customers and www.army.mil which is originated from AS1503. Does anyone have a contact for AS1503? We've tried the ARIN contacts for AS1503 but have not received any response. Thanks, Chris Fibrenoire AS22652 From wbailey at satelliteintelligencegroup.com Wed Dec 11 01:51:21 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 11 Dec 2013 01:51:21 +0000 Subject: Contact for www.army.mil (AS1503 ) In-Reply-To: References: Message-ID: If memory serves me correctly army.mil is run by DISA. May get more traction with them. Sent from my Mobile Device. -------- Original message -------- From: Christopher Morrell Date: 12/10/2013 4:38 PM (GMT-09:00) To: nanog at nanog.org Subject: Contact for www.army.mil (AS1503 ) Hi, We are currently having routing issues between one of our customers and www.army.mil which is originated from AS1503. Does anyone have a contact for AS1503? We've tried the ARIN contacts for AS1503 but have not received any response. Thanks, Chris Fibrenoire AS22652 From ops.lists at gmail.com Wed Dec 11 03:02:24 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 11 Dec 2013 08:32:24 +0530 Subject: Contact for www.army.mil (AS1503 ) In-Reply-To: References: Message-ID: Your best bet is to have your customer find whoever in the army he needs to get in touch with, or does business with, and have them raise this through internal army IT channels --srs (htc one x) On 11-Dec-2013 7:23 AM, "Warren Bailey" < wbailey at satelliteintelligencegroup.com> wrote: > If memory serves me correctly army.mil is run by DISA. May get more > traction with them. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Christopher Morrell > Date: 12/10/2013 4:38 PM (GMT-09:00) > To: nanog at nanog.org > Subject: Contact for www.army.mil (AS1503 ) > > > Hi, > > We are currently having routing issues between one of our customers and > www.army.mil which is originated from AS1503. > > Does anyone have a contact for AS1503? We've tried the ARIN contacts for > AS1503 but have not received any response. > > Thanks, > > Chris > Fibrenoire AS22652 > From surfer at mauigateway.com Wed Dec 11 04:06:02 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 10 Dec 2013 20:06:02 -0800 Subject: Contact for www.army.mil (AS1503 ) Message-ID: <20131210200602.7DEA00BF@resin13.mta.everyone.net> -------- Original message -------- From: Christopher Morrell We are currently having routing issues between one of our customers and www.army.mil which is originated from AS1503. Does anyone have a contact for AS1503? We've tried the ARIN contacts for AS1503 but have not received any response. --------------------------------------- --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey If memory serves me correctly army.mil is run by DISA. May get more traction with them. ------------------------------------------------------- That's like saying "call the federal government". :-) Poking around a bit I found: http://www.disa.mil/Services/Network-Services/Service-Support but I doubt you'll get very far there, either. nic.mil requires a CAC (www.cac.mil) and is only allowed access from certain IP address ranges AFAIK. scott From wbailey at satelliteintelligencegroup.com Wed Dec 11 04:14:02 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 11 Dec 2013 04:14:02 +0000 Subject: Contact for www.army.mil (AS1503 ) In-Reply-To: <20131210200602.7DEA00BF@resin13.mta.everyone.net> References: <20131210200602.7DEA00BF@resin13.mta.everyone.net> Message-ID: I fully said to call DISA, not CALL THE GUB! ;) DISN GLOBAL SUPPORT CENTER DSN: (510) 376-3222 or (312) 850-4790 CML: (800) 554-3476 or (614) 692-4790 DISA.DGSC at mail.mil DGSC at COLS.CSD.DISA.SMIL.MIL You probably aren?t on the DSN, and I don?t think they accept incoming calls from the PSTN. May want to try the CML first (probably a civilian sitting at a DISA desk, so they?ll be useful). Hope this helps. (I only know about this because of the satellite part of my life, and the fact that DISA has threatened to slap my peepee several times ;) <3) On 12/10/13, 7:06 PM, "Scott Weeks" wrote: > >-------- Original message -------- >From: Christopher Morrell > >We are currently having routing issues between one of our customers and >www.army.mil which is originated from AS1503. > >Does anyone have a contact for AS1503? We've tried the ARIN contacts for >AS1503 but have not received any response. >--------------------------------------- > > >--- wbailey at satelliteintelligencegroup.com wrote: >From: Warren Bailey > >If memory serves me correctly army.mil is run by DISA. May get more >traction with them. >------------------------------------------------------- > > >That's like saying "call the federal government". :-) > >Poking around a bit I found: >http://www.disa.mil/Services/Network-Services/Service-Support >but I doubt you'll get very far there, either. > >nic.mil requires a CAC (www.cac.mil) and is only allowed access from >certain IP address ranges AFAIK. > >scott > From nilesh.kahar at outlook.com Tue Dec 10 14:21:24 2013 From: nilesh.kahar at outlook.com (Nilesh Kahar) Date: Tue, 10 Dec 2013 19:51:24 +0530 Subject: BRAS Message-ID: Which is a good BRAS product, to handle 15000 subscribers sessions with full QoS & other features? From len at lenpowell.com Wed Dec 11 04:11:41 2013 From: len at lenpowell.com (Len Powell) Date: Tue, 10 Dec 2013 23:11:41 -0500 Subject: Contact for www.army.mil (AS1503 ) In-Reply-To: References: Message-ID: Suresh is spot on. I can forward your message to a couple of my internal Army POC's as well who may or may not be able to help, my best POC left sadly. It's a long shot, but the AKO help desk may be able to route you to the right group of folks too. Their number is 1-866-335-2769 (A.R.M.Y.). Hope that helps! Len On Dec 10, 2013 10:03 PM, "Suresh Ramasubramanian" wrote: > Your best bet is to have your customer find whoever in the army he needs to > get in touch with, or does business with, and have them raise this through > internal army IT channels > > --srs (htc one x) > On 11-Dec-2013 7:23 AM, "Warren Bailey" < > wbailey at satelliteintelligencegroup.com> wrote: > > > If memory serves me correctly army.mil is run by DISA. May get more > > traction with them. > > > > > > Sent from my Mobile Device. > > > > > > -------- Original message -------- > > From: Christopher Morrell > > Date: 12/10/2013 4:38 PM (GMT-09:00) > > To: nanog at nanog.org > > Subject: Contact for www.army.mil (AS1503 ) > > > > > > Hi, > > > > We are currently having routing issues between one of our customers and > > www.army.mil which is originated from AS1503. > > > > Does anyone have a contact for AS1503? We've tried the ARIN contacts for > > AS1503 but have not received any response. > > > > Thanks, > > > > Chris > > Fibrenoire AS22652 > > > From LarrySheldon at cox.net Wed Dec 11 05:10:50 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 10 Dec 2013 23:10:50 -0600 Subject: BRAS In-Reply-To: <057T1n0161Una3W0157UlL> References: <057T1n0161Una3W0157UlL> Message-ID: <52A7F3DA.709@cox.net> On 12/10/2013 8:21 AM, Nilesh Kahar wrote: > Which is a good BRAS product, to handle 15000 subscribers sessions with full QoS & other features? Victoria's Secret has some nice ones. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jjn at nuge.com Wed Dec 11 05:32:44 2013 From: jjn at nuge.com (Jay Nugent) Date: Wed, 11 Dec 2013 00:32:44 -0500 (EST) Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: <7ECD3FCE-724D-46CF-8244-FBC2C5A33C67@puck.nether.net> References: <7ECD3FCE-724D-46CF-8244-FBC2C5A33C67@puck.nether.net> Message-ID: Greetings, On Tue, 10 Dec 2013, Jared Mauch wrote: > > On Dec 10, 2013, at 8:27 PM, cb.list6 wrote: > >> Correct. IPv6 correctly supports the end to end model. > > Yes, if you know the IP address of my printer you can use up my toner > (it?s already low) and paper. Then again, It?s IPv6 so good luck > finding it. The first nibble is 2. Let me know when you?ve found it. > > :) I think I have narrowed it down a wee bit (based on your email header). [2001:418:3f4::5] plus or minus a few on the last digit... --- Jay Nugent () ascii ribbon campaign in /\ support of plain text e-mail Averaging at least 3 days of MTBWTF!?!?!? The solution for long term Internet growth is IPv6. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | +------------------------------------------------------------------------+ 00:01:02 up 19 days, 6:18, 1 user, load average: 0.07, 0.20, 0.22 From symack at gmail.com Wed Dec 11 06:11:44 2013 From: symack at gmail.com (Nick Cameo) Date: Wed, 11 Dec 2013 01:11:44 -0500 Subject: BRAS In-Reply-To: <52A7F3DA.709@cox.net> References: <52A7F3DA.709@cox.net> Message-ID: Sir whatever that is an acronym for, you have my undivided. This is going to make for an interesting thread in about 6 hours..... From jason at lixfeld.ca Wed Dec 11 06:16:42 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 11 Dec 2013 01:16:42 -0500 Subject: BRAS In-Reply-To: References: <52A7F3DA.709@cox.net> Message-ID: What's so interesting about a guy asking for info on a Broadband Remote Access Server for DSL aggregation? On Dec 11, 2013, at 1:11 AM, Nick Cameo wrote: > Sir whatever that is an acronym for, you have my undivided. > > This is going to make for an interesting thread in about 6 hours..... > From aj at jonesy.com.au Wed Dec 11 06:16:59 2013 From: aj at jonesy.com.au (Andrew Jones) Date: Wed, 11 Dec 2013 17:16:59 +1100 Subject: BRAS In-Reply-To: References: <52A7F3DA.709@cox.net> Message-ID: <961f76bb6f90316580d971244dd79cfb@jonesy.com.au> On 11.12.2013 17:11, Nick Cameo wrote: > Sir whatever that is an acronym for, you have my undivided. > > This is going to make for an interesting thread in about 6 hours..... http://en.wikipedia.org/wiki/Broadband_Remote_Access_Server From LarrySheldon at cox.net Wed Dec 11 06:27:02 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 11 Dec 2013 00:27:02 -0600 Subject: BRAS In-Reply-To: <06Lm1n01v1Una3W016Lnf8> References: <52A7F3DA.709@cox.net> <06Lm1n01v1Una3W016Lnf8> Message-ID: <52A805B6.1000005@cox.net> On 12/11/2013 12:16 AM, Andrew Jones wrote: > On 11.12.2013 17:11, Nick Cameo wrote: >> Sir whatever that is an acronym for, you have my undivided. >> >> This is going to make for an interesting thread in about 6 hours..... > > http://en.wikipedia.org/wiki/Broadband_Remote_Access_Server May not be believed, but I DID search using "BRAS" and qualifiers like "network" and "communication" and got nothing but lingerie-related stuff, before I posted MY wise a remark. I have led a sheltered life. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From christopher.morrell.nanog at gmail.com Wed Dec 11 09:23:29 2013 From: christopher.morrell.nanog at gmail.com (Christopher Morrell) Date: Wed, 11 Dec 2013 04:23:29 -0500 Subject: Contact for www.army.mil (AS1503 ) In-Reply-To: <20131211041828.GA16990@vacation.karoshi.com> References: <20131211041828.GA16990@vacation.karoshi.com> Message-ID: Tried that. No response by email. I haven't tried that phone number yet. > On Dec 10, 2013, at 23:18, bmanning at vacation.karoshi.com wrote: > > > have you tried: > > DoD NIC Registry Services > DoD Network Information Center > 3990 East Broad Street > Columbus Ohio 43213 > United States > Email: disa.columbus.ns.mbx.nic-networks at mail.mil > Voice: (800)365-3642 > Fax: (614)692-3452 > > (always worked for me) > /bill > > >> On Tue, Dec 10, 2013 at 08:36:06PM -0500, Christopher Morrell wrote: >> Hi, >> >> We are currently having routing issues between one of our customers and >> www.army.mil which is originated from AS1503. >> >> Does anyone have a contact for AS1503? We've tried the ARIN contacts for >> AS1503 but have not received any response. >> >> Thanks, >> >> Chris >> Fibrenoire AS22652 From mfidelman at meetinghouse.net Wed Dec 11 11:24:46 2013 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 11 Dec 2013 06:24:46 -0500 Subject: Contact for www.army.mil (AS1503 ) In-Reply-To: References: <20131210200602.7DEA00BF@resin13.mta.everyone.net> Message-ID: <52A84B7E.6070701@meetinghouse.net> Lots of luck there. I'll bet this is all handled by a sub-contractor who's completely unresponsive. (Brings back memories of the days the Army cut all their email over to a DISA contractor, and stuff started bouncing all over the place. Reaching one of our sponsors became a nightmare - and there was nobody to reach. I expect that's only gotten worse.) Warren Bailey wrote: > I fully said to call DISA, not CALL THE GUB! ;) > > DISN GLOBAL SUPPORT CENTER > DSN: (510) 376-3222 or (312) 850-4790 > CML: (800) 554-3476 or (614) 692-4790 > DISA.DGSC at mail.mil > DGSC at COLS.CSD.DISA.SMIL.MIL > > > You probably aren?t on the DSN, and I don?t think they accept incoming > calls from the PSTN. May want to try the CML first (probably a civilian > sitting at a DISA desk, so they?ll be useful). > > Hope this helps. > > (I only know about this because of the satellite part of my life, and the > fact that DISA has threatened to slap my peepee several times ;) <3) > > On 12/10/13, 7:06 PM, "Scott Weeks" wrote: > >> -------- Original message -------- >> From: Christopher Morrell >> >> We are currently having routing issues between one of our customers and >> www.army.mil which is originated from AS1503. >> >> Does anyone have a contact for AS1503? We've tried the ARIN contacts for >> AS1503 but have not received any response. >> --------------------------------------- >> >> >> --- wbailey at satelliteintelligencegroup.com wrote: >> From: Warren Bailey >> >> If memory serves me correctly army.mil is run by DISA. May get more >> traction with them. >> ------------------------------------------------------- >> >> >> That's like saying "call the federal government". :-) >> >> Poking around a bit I found: >> http://www.disa.mil/Services/Network-Services/Service-Support >> but I doubt you'll get very far there, either. >> >> nic.mil requires a CAC (www.cac.mil) and is only allowed access from >> certain IP address ranges AFAIK. >> >> scott >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From randy at psg.com Wed Dec 11 13:17:25 2013 From: randy at psg.com (Randy Bush) Date: Wed, 11 Dec 2013 05:17:25 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: Randy Bush wrote: > http://comcast6.net/ tells me that the local cmts is v6 enabled. my > modem, a cisco dpc3008, is in the supported products list. so how do > i turn the sucker on? > > randy after a lot of messing about with the massive help of Chris Adams and John Brzozowski, problem solved. see http://rtechblog.psg.com/ randy From alumbis at gmail.com Wed Dec 11 14:21:27 2013 From: alumbis at gmail.com (Pete Lumbis) Date: Wed, 11 Dec 2013 09:21:27 -0500 Subject: What routers do folks use these days? In-Reply-To: References: <529827FC.8040603@forethought.net> Message-ID: Even with a single chip architecture the overall scale performance is WAY better than Sup720. Hell, even RSP720 was a huge improvement in scale I know the question was specifically about CPU but Sup2T is also a different forwarding ASIC allowing it to do natively things Sup720 couldn't, like VPLS and EVC I would agree that Sup2t wouldn't be my first choice in ISP Edge. From Cisco, ASR9k or ASR1k depending on bandwidth needs. -Pete disclaimer: I work for Cisco. On Mon, Dec 9, 2013 at 10:34 PM, Jimmy Hess wrote: > On Fri, Nov 29, 2013 at 12:02 AM, Mikael Abrahamsson >wrote: > > > [snip] > > > +1 for MX or ASR 9000. > > > > Cisco ASR 9000, Juniper MX, Huawei NE40E, Alcatel-Lucent 7750, those > kinds > > of routers are the ones I hear people using. Some go for the new Sup2T > for > > the 6500, but I don't know how much more CPU it has compared to your > > SUP/RSP720, perhaps someone else knows? > > > Cat6500 Sup720 was a platform that used two separate processors; 1 Switch > Processor CPU at 600mhz managing Layer 2 services, and 1 Route processor > CPU at 600MHz on the MSFC to run the Layer 3 services. these were MIPS > CPUs --- sr71000. > > Cat650 Sup2T is shown as a single Dual core, 1.5GHz per Core cpu. There > is one processor stack on the 2T, instead of two separate CPUs; since > route processor and switch processor are now combined into one shared > processing unit under the new "merged" architecture that runs only one IOS > image, that controls both RP and SP features ---- Layer 2, Layer 3, and > management services do not run on separate processors, with their own > separate hw anymore. > > > So the CPU is beefier --- but it is also now shared by multiple functions > that previously had separate, isolated processing from one another. > > I believe the Sup2T are using a E500 PowerPC chip. > In any event, neither old nor new are based on x86 architecture --- keep > in mind, that comparison of MHz or GHz CPU frequency rates is only > meaningful within the same CPU architecture. > > There are not significant increases in FIB TCAM, or other important memory > capacities from RSP720, that you would expect to need for scalability to > larger tables. > > > Even with 2T I would still describe the 65xx as largely a great switching > platform, for 10/100/1000 aggregation -- due to limited chassis > bandwidth: its days would seem to be numbered once desktops are sporting 10 > gigabit links: definitely not (IMO) the best hardware router platform > for carrying large routing tables at the ISP edge, anyways. > > > > > Mikael Abrahamsson email: swmike at swm.pp.se > > > -- > -JH > From dwhite at olp.net Wed Dec 11 14:30:40 2013 From: dwhite at olp.net (Dan White) Date: Wed, 11 Dec 2013 08:30:40 -0600 Subject: BRAS In-Reply-To: References: Message-ID: <20131211143040.GB6016@dan.olp.net> On 12/10/13?19:51?+0530, Nilesh Kahar wrote: >Which is a good BRAS product, to handle 15000 subscribers sessions with >full QoS & other features? Juniper MX (480). -- Dan White From Joshua_Sholes at cable.comcast.com Wed Dec 11 14:49:04 2013 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Wed, 11 Dec 2013 14:49:04 +0000 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: <52A7B60B.7070809@cox.net> References: <52A7B60B.7070809@cox.net> Message-ID: Public ipv6 address : firewall :: public street address : locked door/fence/guard dog Just because something is public doesn?t mean you have to accept ALL traffic, it just means you have to anticipate any potential problems based on Larry knowing your address rather than imagining him standing at the front gate of your gated community. ;) (let?s torture that analogy!) -- Josh Sholes On 12/10/13, 7:47 PM, "Larry Sheldon" wrote: >On 12/10/2013 4:30 PM, Geraint Jones wrote: > >>>> Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) >>>> since you have to treat each boxes as if it was public. >>> >>> I see this kind of statement surprisingly often. Having a public >>>address >>> doesn't make a device public. >> >> Yes it does, > >Glad to hear that. We (the family, 8 of us, and the 4 dogs will be >arriving at your house, with its public address, in time for your >Christmas dinner and we will be staying at least through your New Years >eve party--maybe longer depending on the weather here. > >-- >Requiescas in pace o email Two identifying characteristics > of System Administrators: >Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From clayton at MNSi.Net Wed Dec 11 15:10:31 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 11 Dec 2013 10:10:31 -0500 Subject: BRAS In-Reply-To: <20131211143040.GB6016@dan.olp.net> References: <20131211143040.GB6016@dan.olp.net> Message-ID: <1386774632_331846@duplo.mnsi.net> At 09:30 AM 11/12/2013, Dan White wrote: >On 12/10/13 19:51 +0530, Nilesh Kahar wrote: >>Which is a good BRAS product, to handle 15000 subscribers sessions with >>full QoS & other features? > >Juniper MX (480). > >-- >Dan White I heard there were some issues with the LAC/LNS functionality on the MX series vs. JUNOSe on the E series. Is that still the case? --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From eric.oosting at gmail.com Wed Dec 11 15:11:09 2013 From: eric.oosting at gmail.com (Eric Oosting) Date: Wed, 11 Dec 2013 10:11:09 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Wed, Dec 11, 2013 at 8:17 AM, Randy Bush wrote: > Randy Bush wrote: > > http://comcast6.net/ tells me that the local cmts is v6 enabled. my > > modem, a cisco dpc3008, is in the supported products list. so how do > > i turn the sucker on? > > > > randy > > after a lot of messing about with the massive help of Chris Adams and > John Brzozowski, problem solved. see http://rtechblog.psg.com/ It brings a tear to my eye that it takes: 0) A long standing and well informed internet technologist; 1) specific, and potentially high end, CPE for the res; 2) specific and custom firmware, unsupported by CPE manufacturer ... or anyone; 3) hand installing several additional packages; 4) hand editing config files; 5) sysctl kernel flags; 6) several shout outs to friends and coworkers for assistance (resources many don't have access to); 7) oh, and probably hours and hours twiddling with it. just to get IPv6 to work correctly. Yea, that's TOTALLY reasonable. -e > > > randy > > From gabe at teksavvy.ca Wed Dec 11 15:12:51 2013 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Wed, 11 Dec 2013 10:12:51 -0500 Subject: BRAS In-Reply-To: <1386774632_331846@duplo.mnsi.net> References: <20131211143040.GB6016@dan.olp.net> <1386774632_331846@duplo.mnsi.net> Message-ID: <52A880F3.1020805@teksavvy.ca> On 13-12-11 10:10 AM, Clayton Zekelman wrote: > > > > At 09:30 AM 11/12/2013, Dan White wrote: >> On 12/10/13 19:51 +0530, Nilesh Kahar wrote: >>> Which is a good BRAS product, to handle 15000 subscribers sessions with >>> full QoS & other features? >> >> Juniper MX (480). >> >> -- >> Dan White > > > I heard there were some issues with the LAC/LNS functionality on the > MX series vs. JUNOSe on the E series. Is that still the case? Well I'm being told by my Juniper sales reps to stay away from LAC/LNS on the MX for now...so I have. Still rocking E320s -Gabe From dwhite at olp.net Wed Dec 11 15:15:31 2013 From: dwhite at olp.net (Dan White) Date: Wed, 11 Dec 2013 09:15:31 -0600 Subject: BRAS In-Reply-To: <1386774632_331846@duplo.mnsi.net> References: <20131211143040.GB6016@dan.olp.net> <1386774632_331846@duplo.mnsi.net> Message-ID: <20131211151530.GA6872@dan.olp.net> On 12/11/13?10:10?-0500, Clayton Zekelman wrote: > > > >At 09:30 AM 11/12/2013, Dan White wrote: >>On 12/10/13 19:51 +0530, Nilesh Kahar wrote: >>>Which is a good BRAS product, to handle 15000 subscribers sessions with >>>full QoS & other features? >> >>Juniper MX (480). > >I heard there were some issues with the LAC/LNS functionality on the >MX series vs. JUNOSe on the E series. Is that still the case? I have not used those features with the platform, so I can't confirm. The box has been very solid for us as a subscriber management platform for q-in-q termination. -- Dan White From tim at pelican.org Wed Dec 11 15:21:49 2013 From: tim at pelican.org (Tim Franklin) Date: Wed, 11 Dec 2013 15:21:49 +0000 (GMT) Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: References: <52A7B60B.7070809@cox.net> Message-ID: <811188626.8512.1386775309677.JavaMail.zimbra@pelican.org> > Just because something is public doesn?t mean you have to accept ALL > traffic, it just means you have to anticipate any potential problems based > on Larry knowing your address rather than imagining him standing at the > front gate of your gated community. ;) (let?s torture that analogy!) There's still a gated community? I thought that particular piece of routing joy was long gone... Sorry, I'll get my coat. Tim. From nick at foobar.org Wed Dec 11 15:22:11 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 11 Dec 2013 15:22:11 +0000 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <52A88323.7080404@foobar.org> On 11/12/2013 15:11, Eric Oosting wrote: > just to get IPv6 to work correctly. > > Yea, that's TOTALLY reasonable. Sounds a bit like configuring access layer ipv4 in the early 1990s. It took years of early production pain to turn it into a commodity product. Nick From trelane at trelane.net Wed Dec 11 15:25:32 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 11 Dec 2013 10:25:32 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <52A883EC.7000709@trelane.net> On 12/11/2013 10:11 AM, Eric Oosting wrote: > > It brings a tear to my eye that it takes: > > 0) A long standing and well informed internet technologist; > 1) specific, and potentially high end, CPE for the res; > 2) specific and custom firmware, unsupported by CPE manufacturer ... or > anyone; > 3) hand installing several additional packages; > 4) hand editing config files; > 5) sysctl kernel flags; > 6) several shout outs to friends and coworkers for assistance (resources > many don't have access to); > 7) oh, and probably hours and hours twiddling with it. > > just to get IPv6 to work correctly. > > Yea, that's TOTALLY reasonable. > > -e > > >> >> randy >> >> I wonder if he got any better than a /60 for his troubles... Andrew From randy at psg.com Wed Dec 11 15:40:05 2013 From: randy at psg.com (Randy Bush) Date: Wed, 11 Dec 2013 07:40:05 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: > just to get IPv6 to work correctly. i would not have had this problem if i had not done the openwrt thing. the stock netgear would have been fine. i brought this on myself because i wanted to also run things such as an openvpn server. i was documenting for the next to follow, not to whine. randy From eric.oosting at gmail.com Wed Dec 11 15:43:13 2013 From: eric.oosting at gmail.com (Eric Oosting) Date: Wed, 11 Dec 2013 10:43:13 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Wed, Dec 11, 2013 at 10:40 AM, Randy Bush wrote: > > just to get IPv6 to work correctly. > > i would not have had this problem if i had not done the openwrt thing. > the stock netgear would have been fine. i brought this on myself > because i wanted to also run things such as an openvpn server. > > i was documenting for the next to follow, not to whine. > To be clear, I wasn't accusing you of whining. And thanks for documenting it for the next guy. Stock netgear does PD and works out of the box? Didn't realize that. -e > > randy > From bicknell at ufp.org Wed Dec 11 15:43:56 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 Dec 2013 09:43:56 -0600 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Dec 11, 2013, at 9:11 AM, Eric Oosting wrote: > It brings a tear to my eye that it takes: > > 1) specific, and potentially high end, CPE for the res; > 2) specific and custom firmware, unsupported by CPE manufacturer ... or > anyone; I think this says more about Randy's specific choice/luck in hardware than the general state of play. Unfortunately in low end CPE land hardware ships with a specific set of software features, and generally there is no (economic) model for the vendors to ever offer new features. People don't buy "support" for low end CPE. The way to get new software is to buy new hardware, which is really only a good solution when the feature set required is stable over long periods of time. There are plenty of low end residential style boxes that "just work" with Comcast's setup out of the box with vendor images. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Wed Dec 11 15:45:39 2013 From: randy at psg.com (Randy Bush) Date: Wed, 11 Dec 2013 07:45:39 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: > To be clear, I wasn't accusing you of whining. And thanks for documenting > it for the next guy. it just works for gals, they have all the luck and the brains > Stock netgear does PD and works out of the box? Didn't realize that. so says my authority, joelja randy From joelja at bogus.com Wed Dec 11 15:51:46 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 11 Dec 2013 07:51:46 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <52A88A12.2070700@bogus.com> On 12/11/13, 7:11 AM, Eric Oosting wrote: > On Wed, Dec 11, 2013 at 8:17 AM, Randy Bush wrote: > >> Randy Bush wrote: >>> http://comcast6.net/ tells me that the local cmts is v6 enabled. my >>> modem, a cisco dpc3008, is in the supported products list. so how do >>> i turn the sucker on? >>> >>> randy >> >> after a lot of messing about with the massive help of Chris Adams and >> John Brzozowski, problem solved. see http://rtechblog.psg.com/ > > > It brings a tear to my eye that it takes: > > 0) A long standing and well informed internet technologist; > 1) specific, and potentially high end, CPE for the res; > 2) specific and custom firmware, unsupported by CPE manufacturer ... or > anyone; it's worth noting that, that cpe works just fine for this purpose with the manufacturer supplied firmware. so the motivation for doing it this way lies elsewhere. If you approach this as consumer rather than futzing with it you'll probably have a different experience. At my appartment I have a mot sb6121 and a netgear wndr3700 and comcast v6 works without apparent effort. > 3) hand installing several additional packages; > 4) hand editing config files; > 5) sysctl kernel flags; > 6) several shout outs to friends and coworkers for assistance (resources > many don't have access to); > 7) oh, and probably hours and hours twiddling with it. > > just to get IPv6 to work correctly. > > Yea, that's TOTALLY reasonable. > > -e > > >> >> >> randy >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From aditya at grot.org Wed Dec 11 16:10:36 2013 From: aditya at grot.org (R.P. Aditya) Date: Wed, 11 Dec 2013 16:10:36 +0000 (UTC) Subject: Routing asymetry and RPF check References: <20131209201920.GC21229@seti.u-strasbg.fr> Message-ID: Some problems never go away, just reappear periodically -- strict uRPF (and even loose uRPF) on transit provider peering interfaces are going to have unintended consequences as long as their is routing asymmetry on the Internet (pretty much guaranteed to be forever): http://www.nanog.org/mailinglist/mailarchives/old_archive/1999-03/msg00125.html Adi On 2013-12-09, Jean Benoit wrote: > > --KdquIMZPjGJQvRdI > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > > Hello, > > It's probably an old problem which was already debated here. > We (130.79/16, AS2259) can't reach 143.104/16 (AS20252). > Actually, all packets are dropped on their way back to our network. > The probable cause is a conjunction of routing asymetry and uRPF check : > > - 143.104/16 is behind a US university network. Packets sent > *from 143.104/16* to the rest of the Internet are going through National > Lambda Rail (NLR), a US. research and education network, > > - but, as 143.104/16 does not belong to the university but to a hospital > (the network has only a couple of hosts related to public research), > this prefix is not announced to NLR. So packets from the Internet > *to 143.104/16* go through the university commodity Internet link > (a mix of different providers). Thus, there is a routing asymetry. > > - on the other side of the Atlantic, 130.79/16 is behind another research > network, RENATER (AS2200). Renater is connected to GEANT, which > federates mots of the European research and education networks. > GEANT peers with NLR. > So the path from 143.104/16 is : > Hospital,University(20252),NLR(19401),GEANT(20965),RENATER(2200),Our site(2259) > > - when a packet arrives from 143.104/16 on a specific RENATER router in > Geneva, geneve-rtr-021.noc.renater.fr, it is dropped. > > - On this router, geneve-rtr-021.noc.renater.fr, RENATER peers with GEANT. > > - RENATER lookings glass (https://portail.noc.renater.fr/lookingglass/v2/) > tells me that the prefix 143.104/16 is not present in this router's > routing table (this prefix is not learnt by NLR, and not learnt by GEANT). > Moreover, this router seems not to have a full routing table. > > - On this router, unicast Reverse Path Forwarding check (unsure if it's > strict or loose) is enabled on the interface between RENATER > and GEANT (PortChannel4.160 to ae14.160 of rt1.gen.ch.geant.net or > mx1.gen.ch.geant.net, see https://tools.geant.net/portal/links/lg/) > The packets with source IP address 143.104/16 are dropped because the > uRPF check fails. > > So, what do you think should be done ? > > Thanks for your advice, > > -- > Jean Benoit > University of Strasbourg > > --KdquIMZPjGJQvRdI > Content-Type: text/plain; charset=utf-8 > Content-Disposition: attachment; filename="traceroute_from_143.104_to_130.79.txt" > > > ---------------------------------------------------------------------- > > Traceroute from 143.103 to 130.79 : > > 1 143.104.11.49 0 msec 0 msec 0 msec > 2 143.104.11.34 0 msec 0 msec 0 msec > 3 10.174.255.146 0 msec 0 msec 0 msec > 4 10.174.1.138 0 msec 0 msec 0 msec > 5 te-7-1-nydc1-1300-d-core02.med.cornell.edu (10.10.100.6) 0 msec 0 msec 0 msec > 6 gi-3-2-nydc1-1300-fw01.med.cornell.edu (157.139.0.129) 0 msec 0 msec 0 msec > 7 vl-10-nydc1-1300-ingw01.med.cornell.edu (157.139.0.65) 0 msec 0 msec 4 msec > 8 157.139.255.9 0 msec 0 msec 4 msec > 9 * * * > 10 216.24.184.86 84 msec 84 msec 84 msec > 11 ae3.mx1.ams.nl.geant.net (62.40.98.115) 92 msec 84 msec 84 msec > 12 ae0.mx1.fra.de.geant.net (62.40.98.128) 84 msec 84 msec 88 msec > 13 ae1.mx1.gen.ch.geant.net (62.40.98.108) 108 msec 104 msec 96 msec > 14 ae2.rt1.gen.ch.geant.net (62.40.112.13) 92 msec 92 msec 92 msec > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > > ---------------------------------------------------------------------- > > > --KdquIMZPjGJQvRdI-- > > -- From nilesh.kahar at outlook.com Wed Dec 11 16:14:47 2013 From: nilesh.kahar at outlook.com (Nilesh Kahar) Date: Wed, 11 Dec 2013 21:44:47 +0530 Subject: BRAS Message-ID: Basically I am facing issues with MX80 LNS scenario. So just to make sure with community whether anyone is having similar problem. Also wanted to know about any other good BRAS product which can act fine for LNS - LAC setup. Thanks for all the responses. Nil. From olivier.benghozi at wifirst.fr Wed Dec 11 16:27:06 2013 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Wed, 11 Dec 2013 17:27:06 +0100 Subject: BRAS In-Reply-To: References: Message-ID: Hi, Le 11 d?c. 2013 ? 17:14, Nilesh Kahar a ?crit : > Also wanted to know about any other good BRAS product which can act fine for LNS - LAC setup. Ericsson SmartEdge Cisco ASR1000 From saku at ytti.fi Wed Dec 11 17:03:46 2013 From: saku at ytti.fi (Saku Ytti) Date: Wed, 11 Dec 2013 19:03:46 +0200 Subject: Routing asymetry and RPF check In-Reply-To: References: <20131209201920.GC21229@seti.u-strasbg.fr> Message-ID: <20131211170346.GA24339@pob.ytti.fi> On (2013-12-11 16:10 +0000), R.P. Aditya wrote: > Some problems never go away, just reappear periodically -- strict uRPF > (and even loose uRPF) on transit provider peering interfaces are going > to have unintended consequences as long as their is routing asymmetry I can't imagine why uRPF/loose would be problematic. If you're originating traffic from prefix which you're not advertising to DFZ and you still expect it to work, your expectation are at fault, not uRPF/loose. However uRPF/strict feasible won't work, while occasionally some people seem to think it does. -- ++ytti From me at anuragbhatia.com Wed Dec 11 18:06:36 2013 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 11 Dec 2013 23:36:36 +0530 Subject: Best practice on TCP replies for ANY queries Message-ID: Hello everyone I noticed some issues on one of DNS server I am managing. It was getting queries for couple of attacking domains and server was replying in TCP with 3700 bytes releasing very heavy packets. Now I see presence of some (legitimate) DNS forwarders and hence I don't wish to limit queries. As I understand there are two ways here for fix: 1. I can put a DNS rate limit in reply to ANY packets like say 5 replies in every one min. (but again I have some forwarders with quite a few machines behind them). 2. Other way is limiting TCP port 53 outbound size ...limiting to say 600-700 bytes or so. I am sure I am not first person experiencing this issue. Curious to hear how you are managing it. Also under what circumstances I can get a legitimate TCP query on port 53 whose reply exceeds a basic limit of less then 1000 bytes? Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com From ml at kenweb.org Wed Dec 11 18:19:35 2013 From: ml at kenweb.org (ML) Date: Wed, 11 Dec 2013 13:19:35 -0500 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: Message-ID: <52A8ACB7.8000005@kenweb.org> On 12/11/2013 1:06 PM, Anurag Bhatia wrote: > > I am sure I am not first person experiencing this issue. Curious to hear > how you are managing it. Also under what circumstances I can get a > legitimate TCP query on port 53 whose reply exceeds a basic limit of less > then 1000 bytes? > > > I'm not a DNS guru so I don't have an exact answer. However my gut feeling is that putting in a place a rule to drop or rate limit DNS replies greater than X bytes is probably going to come back to bite you in the future. No one can predict the future of what will constitute legitimate DNS traffic. From me at anuragbhatia.com Wed Dec 11 18:25:14 2013 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 11 Dec 2013 23:55:14 +0530 Subject: Best practice on TCP replies for ANY queries In-Reply-To: <52A8ACB7.8000005@kenweb.org> References: <52A8ACB7.8000005@kenweb.org> Message-ID: Hi ML Yeah I can understand. Even DNSSEC will have issues with it which makes me worry about rule even today. On Wed, Dec 11, 2013 at 11:49 PM, ML wrote: > On 12/11/2013 1:06 PM, Anurag Bhatia wrote: > > > > I am sure I am not first person experiencing this issue. Curious to hear > > how you are managing it. Also under what circumstances I can get a > > legitimate TCP query on port 53 whose reply exceeds a basic limit of less > > then 1000 bytes? > > > > > > > > I'm not a DNS guru so I don't have an exact answer. However my gut > feeling is that putting in a place a rule to drop or rate limit DNS > replies greater than X bytes is probably going to come back to bite you > in the future. > > No one can predict the future of what will constitute legitimate DNS > traffic. > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com From nitzan.tzelniker at gmail.com Wed Dec 11 18:44:18 2013 From: nitzan.tzelniker at gmail.com (Nitzan Tzelniker) Date: Wed, 11 Dec 2013 20:44:18 +0200 Subject: BRAS In-Reply-To: <20131211151530.GA6872@dan.olp.net> References: <20131211143040.GB6016@dan.olp.net> <1386774632_331846@duplo.mnsi.net> <20131211151530.GA6872@dan.olp.net> Message-ID: MX480 works for me as LNS with Ericson Smartedge as LAC with more then 10K users it is very stable with 11.4x27 version The biggest limitations is that it is not possible to configure MTU for the subscriber interface ( lower the MTU to1492 for PPPOE subscribers ) Nitzan On Wed, Dec 11, 2013 at 5:15 PM, Dan White wrote: > On 12/11/13 10:10 -0500, Clayton Zekelman wrote: > >> >> >> >> At 09:30 AM 11/12/2013, Dan White wrote: >> >>> On 12/10/13 19:51 +0530, Nilesh Kahar wrote: >>> >>>> Which is a good BRAS product, to handle 15000 subscribers sessions with >>>> full QoS & other features? >>>> >>> >>> Juniper MX (480). >>> >> >> I heard there were some issues with the LAC/LNS functionality on the MX >> series vs. JUNOSe on the E series. Is that still the case? >> > > I have not used those features with the platform, so I can't confirm. The > box has been very solid for us as a subscriber management platform for > q-in-q termination. > > -- > Dan White > > From markwgallagher at gmail.com Wed Dec 11 18:50:36 2013 From: markwgallagher at gmail.com (Mark Gallagher) Date: Wed, 11 Dec 2013 21:50:36 +0300 Subject: Contact for www.army.mil (AS1503 ) In-Reply-To: <52A84B7E.6070701@meetinghouse.net> References: <20131210200602.7DEA00BF@resin13.mta.everyone.net> <52A84B7E.6070701@meetinghouse.net> Message-ID: Probably looking for the DISA CONUS IPNOC. Here's a good place to start: http://www.disa.mil/About/Our-Organization-Structure/OD-Field-Office/CONUS ?T ?hanks, Mark? On Wed, Dec 11, 2013 at 2:24 PM, Miles Fidelman wrote: > Lots of luck there. I'll bet this is all handled by a sub-contractor > who's completely unresponsive. (Brings back memories of the days the Army > cut all their email over to a DISA contractor, and stuff started bouncing > all over the place. Reaching one of our sponsors became a nightmare - and > there was nobody to reach. I expect that's only gotten worse.) > > Warren Bailey wrote: > >> I fully said to call DISA, not CALL THE GUB! ;) >> >> DISN GLOBAL SUPPORT CENTER >> DSN: (510) 376-3222 or (312) 850-4790 >> CML: (800) 554-3476 or (614) 692-4790 >> DISA.DGSC at mail.mil >> DGSC at COLS.CSD.DISA.SMIL.MIL >> >> >> You probably aren?t on the DSN, and I don?t think they accept incoming >> >> calls from the PSTN. May want to try the CML first (probably a civilian >> sitting at a DISA desk, so they?ll be useful). >> >> >> Hope this helps. >> >> (I only know about this because of the satellite part of my life, and the >> fact that DISA has threatened to slap my peepee several times ;) <3) >> >> On 12/10/13, 7:06 PM, "Scott Weeks" wrote: >> >> -------- Original message -------- >>> From: Christopher Morrell >>> >>> We are currently having routing issues between one of our customers and >>> www.army.mil which is originated from AS1503. >>> >>> Does anyone have a contact for AS1503? We've tried the ARIN contacts for >>> AS1503 but have not received any response. >>> --------------------------------------- >>> >>> >>> --- wbailey at satelliteintelligencegroup.com wrote: >>> From: Warren Bailey >>> >>> If memory serves me correctly army.mil is run by DISA. May get more >>> traction with them. >>> ------------------------------------------------------- >>> >>> >>> That's like saying "call the federal government". :-) >>> >>> Poking around a bit I found: >>> http://www.disa.mil/Services/Network-Services/Service-Support >>> but I doubt you'll get very far there, either. >>> >>> nic.mil requires a CAC (www.cac.mil) and is only allowed access from >>> certain IP address ranges AFAIK. >>> >>> scott >>> >>> > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > From arturo.servin at gmail.com Wed Dec 11 19:17:33 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 11 Dec 2013 17:17:33 -0200 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: <52A8ACB7.8000005@kenweb.org> Message-ID: I think is better idea to rate-limit your responses rather than limiting the size of them. AFAIK, bind has a way to do it. .as On Wed, Dec 11, 2013 at 4:25 PM, Anurag Bhatia wrote: > Hi ML > > > > Yeah I can understand. Even DNSSEC will have issues with it which makes me > worry about rule even today. > > > On Wed, Dec 11, 2013 at 11:49 PM, ML wrote: > >> On 12/11/2013 1:06 PM, Anurag Bhatia wrote: >> > >> > I am sure I am not first person experiencing this issue. Curious to hear >> > how you are managing it. Also under what circumstances I can get a >> > legitimate TCP query on port 53 whose reply exceeds a basic limit of less >> > then 1000 bytes? >> > >> > >> > >> >> I'm not a DNS guru so I don't have an exact answer. However my gut >> feeling is that putting in a place a rule to drop or rate limit DNS >> replies greater than X bytes is probably going to come back to bite you >> in the future. >> >> No one can predict the future of what will constitute legitimate DNS >> traffic. >> >> > > > -- > > > Anurag Bhatia > anuragbhatia.com > > Linkedin | > Twitter > Skype: anuragbhatia.com From dougb at dougbarton.us Wed Dec 11 19:21:37 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 11 Dec 2013 11:21:37 -0800 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: Message-ID: <52A8BB41.1020801@dougbarton.us> You don't mention what software you're using. If you're using BIND, ask this question on bind-users at isc.org. There is indeed a solution. Doug On 12/11/2013 10:06 AM, Anurag Bhatia wrote: > Hello everyone > > > I noticed some issues on one of DNS server I am managing. From owen at delong.com Wed Dec 11 19:18:00 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Dec 2013 11:18:00 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: It doesn?t. You can get IPv6 working with off-the-shelf equipment if you choose to. Randy chose to use that particular hardware and software combination. Owen On Dec 11, 2013, at 7:11 AM, Eric Oosting wrote: > On Wed, Dec 11, 2013 at 8:17 AM, Randy Bush wrote: > >> Randy Bush wrote: >>> http://comcast6.net/ tells me that the local cmts is v6 enabled. my >>> modem, a cisco dpc3008, is in the supported products list. so how do >>> i turn the sucker on? >>> >>> randy >> >> after a lot of messing about with the massive help of Chris Adams and >> John Brzozowski, problem solved. see http://rtechblog.psg.com/ > > > It brings a tear to my eye that it takes: > > 0) A long standing and well informed internet technologist; > 1) specific, and potentially high end, CPE for the res; > 2) specific and custom firmware, unsupported by CPE manufacturer ... or > anyone; > 3) hand installing several additional packages; > 4) hand editing config files; > 5) sysctl kernel flags; > 6) several shout outs to friends and coworkers for assistance (resources > many don't have access to); > 7) oh, and probably hours and hours twiddling with it. > > just to get IPv6 to work correctly. > > Yea, that's TOTALLY reasonable. > > -e > > >> >> >> randy >> >> From me at anuragbhatia.com Wed Dec 11 19:22:02 2013 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 12 Dec 2013 00:52:02 +0530 Subject: Best practice on TCP replies for ANY queries In-Reply-To: <52A8BB41.1020801@dougbarton.us> References: <52A8BB41.1020801@dougbarton.us> Message-ID: Hi Doug I am using PowerDNS recursor. On Thu, Dec 12, 2013 at 12:51 AM, Doug Barton wrote: > You don't mention what software you're using. If you're using BIND, ask > this question on bind-users at isc.org. There is indeed a solution. > > Doug > > > > On 12/11/2013 10:06 AM, Anurag Bhatia wrote: > >> Hello everyone >> >> >> I noticed some issues on one of DNS server I am managing. >> > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com From cvicente.lists at gmail.com Wed Dec 11 19:26:05 2013 From: cvicente.lists at gmail.com (Carlos Vicente) Date: Wed, 11 Dec 2013 14:26:05 -0500 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: Message-ID: If you are using BIND, take a look at: https://kb.isc.org/article/AA-01000 cv On Wed, Dec 11, 2013 at 1:06 PM, Anurag Bhatia wrote: > Hello everyone > > > I noticed some issues on one of DNS server I am managing. It was getting > queries for couple of attacking domains and server was replying in TCP with > 3700 bytes releasing very heavy packets. Now I see presence of some > (legitimate) DNS forwarders and hence I don't wish to limit queries. > > > As I understand there are two ways here for fix: > > > 1. I can put a DNS rate limit in reply to ANY packets like say 5 replies > in every one min. (but again I have some forwarders with quite a few > machines behind them). > > 2. Other way is limiting TCP port 53 outbound size ...limiting to say > 600-700 bytes or so. > > > > I am sure I am not first person experiencing this issue. Curious to hear > how you are managing it. Also under what circumstances I can get a > legitimate TCP query on port 53 whose reply exceeds a basic limit of less > then 1000 bytes? > > > > > Thanks. > > -- > > > Anurag Bhatia > anuragbhatia.com > > Linkedin | > Twitter > Skype: anuragbhatia.com > From jared at puck.nether.net Wed Dec 11 19:26:22 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Dec 2013 14:26:22 -0500 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: <52A8ACB7.8000005@kenweb.org> Message-ID: dns-operations list is likely best suited for this question, but... If using BIND 9.9.4 you can set the system to use TCP for repeated queries to prevent spoofed ones from being replied to (ie: use yourself as an amplifier). There's lists of domains published that are used in abuse, eg: https://twitter.com/DnsSmurf http://dnsamplificationattacks.blogspot.nl/ https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist.txt You should restrict your DNS server (as much as possible) to only respond to your customer base. If you are using microsoft dns, STOP. It has no way to restrict the clients it replies to queries for. Set up real software to forward to it which does the filtering and scoping for your space. NSD and others also have the ability to configure rate-limiting, knowing what software you are using is an important key here for proper recommendations and guide pointers. Good luck, - jared On Dec 11, 2013, at 2:17 PM, Arturo Servin wrote: > I think is better idea to rate-limit your responses rather than > limiting the size of them. > > AFAIK, bind has a way to do it. > > .as > > > On Wed, Dec 11, 2013 at 4:25 PM, Anurag Bhatia wrote: >> Hi ML >> >> >> >> Yeah I can understand. Even DNSSEC will have issues with it which makes me >> worry about rule even today. >> >> >> On Wed, Dec 11, 2013 at 11:49 PM, ML wrote: >> >>> On 12/11/2013 1:06 PM, Anurag Bhatia wrote: >>>> >>>> I am sure I am not first person experiencing this issue. Curious to hear >>>> how you are managing it. Also under what circumstances I can get a >>>> legitimate TCP query on port 53 whose reply exceeds a basic limit of less >>>> then 1000 bytes? >>>> >>>> >>>> >>> >>> I'm not a DNS guru so I don't have an exact answer. However my gut >>> feeling is that putting in a place a rule to drop or rate limit DNS >>> replies greater than X bytes is probably going to come back to bite you >>> in the future. >>> >>> No one can predict the future of what will constitute legitimate DNS >>> traffic. >>> >>> >> >> >> -- >> >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | >> Twitter >> Skype: anuragbhatia.com From jared at puck.nether.net Wed Dec 11 19:32:38 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Dec 2013 14:32:38 -0500 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <91CEA684-5EFA-46CC-93F8-818EB3AF20FE@puck.nether.net> On Dec 11, 2013, at 2:18 PM, Owen DeLong wrote: > It doesn?t. You can get IPv6 working with off-the-shelf equipment if you choose to. > > Randy chose to use that particular hardware and software combination. I'll chime in with a link to data: http://www.google.com/ipv6/statistics.html#tab=per-country-ipv6-adoption Looking at things, USA is at 5%+ adoption, which is due to the hard work of folks at Comcast (and other ISPs). Overall google is seeing 2.5%+ of traffic over native IPv6. in several cases IPv6 is actually faster than IPv4: 16 bytes from 2001:418:3f4::5, icmp_seq=0 hlim=57 time=18.649 ms 16 bytes from 2001:418:3f4::5, icmp_seq=1 hlim=57 time=19.008 ms 16 bytes from 2001:418:3f4::5, icmp_seq=2 hlim=57 time=18.959 ms ^C --- puck.nether.net ping6 statistics --- 4 packets transmitted, 3 packets received, 25.0% packet loss round-trip min/avg/max/std-dev = 18.649/18.872/19.008/0.159 ms PING puck.nether.net (204.42.254.5): 56 data bytes 64 bytes from 204.42.254.5: icmp_seq=0 ttl=55 time=32.920 ms 64 bytes from 204.42.254.5: icmp_seq=1 ttl=55 time=18.467 ms 64 bytes from 204.42.254.5: icmp_seq=2 ttl=55 time=22.014 ms 64 bytes from 204.42.254.5: icmp_seq=3 ttl=55 time=20.807 ms 64 bytes from 204.42.254.5: icmp_seq=4 ttl=55 time=19.096 ms ^C --- puck.nether.net ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 18.467/22.661/32.920/5.280 ms - jared From kkinkaid at usgs.gov Wed Dec 11 19:46:56 2013 From: kkinkaid at usgs.gov (Kinkaid, Kyle) Date: Wed, 11 Dec 2013 11:46:56 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: On Wed, Dec 11, 2013 at 11:18 AM, Owen DeLong wrote: > It doesn?t. You can get IPv6 working with off-the-shelf equipment if you > choose to. > > Randy chose to use that particular hardware and software combination. I'm curious, do you know of a consumer-grade router which supports DHCPv6-PD? I have been making plans to put OpenWRT on my home router to get IPv6 and have found v6 support quite lacking. Most of the routers seem to like to focus on various transition technologies like 6to4 tunnels. I would love to go to NewEgg and get a home router for $50 (or even $100) that is ready to go. What's more surprising is even Cisco and Juniper have been lagging. The SRX only got DHCPv6-PD support in the last 6 months or so and I don't think the ASA has it yet. However, ISR routers like the 88x and 86x support it. -Kyle From bicknell at ufp.org Wed Dec 11 19:57:27 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 11 Dec 2013 13:57:27 -0600 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <4377ECE1-DAB2-4878-A086-025D245FF00F@ufp.org> On Dec 11, 2013, at 1:46 PM, "Kinkaid, Kyle" wrote: > I > would love to go to NewEgg and get a home router for $50 (or even $100) > that is ready to go. http://mydeviceinfo.comcast.net/?homegateway contains devices Comcast has actually tested in their lab, and so they are safer than most. There are devices not on this list that meet your criteria as well. I believe the absolute cheapest at NewEgg is the D-Link DIR 655, which is $63.99 with "Extra savings .. promo code" right now: http://www.newegg.com/Product/Product.aspx?Item=N82E16833127215 -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ikiris at gmail.com Wed Dec 11 20:01:47 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 11 Dec 2013 14:01:47 -0600 Subject: turning on comcast v6 In-Reply-To: <4377ECE1-DAB2-4878-A086-025D245FF00F@ufp.org> References: <4377ECE1-DAB2-4878-A086-025D245FF00F@ufp.org> Message-ID: The problem isn't the consumer devices. The problem is most of the open source router software developers don't see ipv6 as a priority, or something even worth "wasting time" on. On Wed, Dec 11, 2013 at 1:57 PM, Leo Bicknell wrote: > > On Dec 11, 2013, at 1:46 PM, "Kinkaid, Kyle" wrote: > > > I > > would love to go to NewEgg and get a home router for $50 (or even $100) > > that is ready to go. > > http://mydeviceinfo.comcast.net/?homegateway contains devices Comcast > has actually tested in their lab, and so they are safer than most. > There are devices not on this list that meet your criteria as well. > > I believe the absolute cheapest at NewEgg is the D-Link DIR 655, > which is $63.99 with "Extra savings .. promo code" right now: > http://www.newegg.com/Product/Product.aspx?Item=N82E16833127215 > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From joelja at bogus.com Wed Dec 11 20:14:55 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 11 Dec 2013 12:14:55 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <52A8C7BF.5000305@bogus.com> On 12/11/13, 11:46 AM, Kinkaid, Kyle wrote: > On Wed, Dec 11, 2013 at 11:18 AM, Owen DeLong wrote: > >> It doesn?t. You can get IPv6 working with off-the-shelf equipment if you >> choose to. >> >> Randy chose to use that particular hardware and software combination. > > > I'm curious, do you know of a consumer-grade router which supports > DHCPv6-PD? http://i.imgur.com/E7bsMsH.png 1. go to frys / newegg 2. buy netgear 3. ? 4. profit I have been making plans to put OpenWRT on my home router to get > IPv6 and have found v6 support quite lacking. Most of the routers seem to > like to focus on various transition technologies like 6to4 tunnels. I > would love to go to NewEgg and get a home router for $50 (or even $100) > that is ready to go. > > What's more surprising is even Cisco and Juniper have been lagging. The > SRX only got DHCPv6-PD support in the last 6 months or so and I don't think > the ASA has it yet. However, ISR routers like the 88x and 86x support it. > > -Kyle > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From sander at steffann.nl Wed Dec 11 20:15:24 2013 From: sander at steffann.nl (Sander Steffann) Date: Wed, 11 Dec 2013 21:15:24 +0100 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: Hi, Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle het volgende geschreven: > I'm curious, do you know of a consumer-grade router which supports > DHCPv6-PD? I have tested a whole bunch of them more than a year ago. I can remember seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Link, Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be forgetting a few as well. Most of them weren't very advanced, but they worked to get IPv6 connectivity in the house. What I am missing these days is DHCPv6-PD server support to re-delegate parts of the prefix it got from the ISP downstream to other home routers. As far as I know AVM Fritz!box is the only one that does that today. Cheers, Sander From marka at isc.org Wed Dec 11 22:01:32 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 12 Dec 2013 09:01:32 +1100 Subject: turning on comcast v6 In-Reply-To: Your message of "Wed, 11 Dec 2013 21:15:24 +0100." References: Message-ID: <20131211220133.23480B8AF8F@rock.dv.isc.org> In message , Sander Steffann writes: > Hi, > > Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle het > volgende geschreven: > > I'm curious, do you know of a consumer-grade router which supports > > DHCPv6-PD? > > I have tested a whole bunch of them more than a year ago. I can remember > seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Link, > Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be > forgetting a few as well. Most of them weren't very advanced, but they > worked to get IPv6 connectivity in the house. What I am missing these > days is DHCPv6-PD server support to re-delegate parts of the prefix it > got from the ISP downstream to other home routers. As far as I know AVM > Fritz!box is the only one that does that today. And the need for it was obvious when all the other boxes were being developed. Daisy chaining routers has been part of home setups for many, many years if only to get configuration control because the ISP router is not configurable enough. There was no reason to think that this would change with IPv6. > Cheers, > Sander -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cvicente.lists at gmail.com Wed Dec 11 22:04:40 2013 From: cvicente.lists at gmail.com (Carlos Vicente) Date: Wed, 11 Dec 2013 17:04:40 -0500 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: <52A8ACB7.8000005@kenweb.org> Message-ID: https://kb.isc.org/article/AA-01000 On Wed, Dec 11, 2013 at 2:17 PM, Arturo Servin wrote: > I think is better idea to rate-limit your responses rather than > limiting the size of them. > > AFAIK, bind has a way to do it. > > .as > > > On Wed, Dec 11, 2013 at 4:25 PM, Anurag Bhatia > wrote: > > Hi ML > > > > > > > > Yeah I can understand. Even DNSSEC will have issues with it which makes > me > > worry about rule even today. > > > > > > On Wed, Dec 11, 2013 at 11:49 PM, ML wrote: > > > >> On 12/11/2013 1:06 PM, Anurag Bhatia wrote: > >> > > >> > I am sure I am not first person experiencing this issue. Curious to > hear > >> > how you are managing it. Also under what circumstances I can get a > >> > legitimate TCP query on port 53 whose reply exceeds a basic limit of > less > >> > then 1000 bytes? > >> > > >> > > >> > > >> > >> I'm not a DNS guru so I don't have an exact answer. However my gut > >> feeling is that putting in a place a rule to drop or rate limit DNS > >> replies greater than X bytes is probably going to come back to bite you > >> in the future. > >> > >> No one can predict the future of what will constitute legitimate DNS > >> traffic. > >> > >> > > > > > > -- > > > > > > Anurag Bhatia > > anuragbhatia.com > > > > Linkedin | > > Twitter > > Skype: anuragbhatia.com > > From jimb at jsbc.cc Wed Dec 11 22:44:32 2013 From: jimb at jsbc.cc (jimb at jsbc.cc) Date: Wed, 11 Dec 2013 14:44:32 -0800 Subject: turning on comcast v6 In-Reply-To: <20131211220133.23480B8AF8F@rock.dv.isc.org> References: <20131211220133.23480B8AF8F@rock.dv.isc.org> Message-ID: <368027b3-1a74-47ce-b091-62773533b5df@email.android.com> Hear hear. Mark Andrews wrote: > >In message , Sander >Steffann >writes: >> Hi, >> >> Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle het >> volgende geschreven: >> > I'm curious, do you know of a consumer-grade router which supports >> > DHCPv6-PD? >> >> I have tested a whole bunch of them more than a year ago. I can >remember >> seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, >D-Link, >> Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be >> forgetting a few as well. Most of them weren't very advanced, but >they >> worked to get IPv6 connectivity in the house. What I am missing these >> days is DHCPv6-PD server support to re-delegate parts of the prefix >it >> got from the ISP downstream to other home routers. As far as I know >AVM >> Fritz!box is the only one that does that today. > >And the need for it was obvious when all the other boxes were being >developed. Daisy chaining routers has been part of home setups for >many, many years if only to get configuration control because the >ISP router is not configurable enough. There was no reason to think >that this would change with IPv6. > >> Cheers, >> Sander >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From ggm at algebras.org Wed Dec 11 22:47:18 2013 From: ggm at algebras.org (George Michaelson) Date: Thu, 12 Dec 2013 08:47:18 +1000 Subject: turning on comcast v6 In-Reply-To: <20131211220133.23480B8AF8F@rock.dv.isc.org> References: <20131211220133.23480B8AF8F@rock.dv.isc.org> Message-ID: I am probably closer to consumer behaviour at home than most of you. I don't regard my home router as a vehicle for hackery beyond clue I can find on the end user public lists and rarely if ever even apply that, and I run stock factory billion code on my billion ADSL2+ home gateway. I just enabled the ADSL2+ profile which had IPv6 and restarted. It came up immediately with a /56 and I haven't touched it since. I have been using it to SSH back home quite comfortably with an almost unmodified ACLset to permit port 22 inbound. This is on Internode, in Australia. So, while I fully acknowledge the reality is that for a lot of people, cable and other complex head-end systems needed change and the experience of going dual-stack can be painful, I want to assert IT DOESNT HAVE TO BE and I am proof by example It just worked. On Thu, Dec 12, 2013 at 8:01 AM, Mark Andrews wrote: > > In message , Sander > Steffann > writes: > > Hi, > > > > Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle het > > volgende geschreven: > > > I'm curious, do you know of a consumer-grade router which supports > > > DHCPv6-PD? > > > > I have tested a whole bunch of them more than a year ago. I can remember > > seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Link, > > Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be > > forgetting a few as well. Most of them weren't very advanced, but they > > worked to get IPv6 connectivity in the house. What I am missing these > > days is DHCPv6-PD server support to re-delegate parts of the prefix it > > got from the ISP downstream to other home routers. As far as I know AVM > > Fritz!box is the only one that does that today. > > And the need for it was obvious when all the other boxes were being > developed. Daisy chaining routers has been part of home setups for > many, many years if only to get configuration control because the > ISP router is not configurable enough. There was no reason to think > that this would change with IPv6. > > > Cheers, > > Sander > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From joelja at bogus.com Wed Dec 11 23:54:30 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 11 Dec 2013 15:54:30 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <52A8FB36.4040505@bogus.com> On 12/11/13, 7:45 AM, Randy Bush wrote: >> To be clear, I wasn't accusing you of whining. And thanks for documenting >> it for the next guy. > > it just works for gals, they have all the luck and the brains > >> Stock netgear does PD and works out of the box? Didn't realize that. > > so says my authority, joelja I have been trying with some success to be a consumer rather than a hacker with respect to my connectivity, and the results haven't been that bad. t-mobile cell vzw wireless dongle comcast broadband All have nominally working v6. Now if I could get the office vpn... > randy > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From paul at paulstewart.org Thu Dec 12 00:00:20 2013 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 11 Dec 2013 19:00:20 -0500 Subject: BRAS In-Reply-To: References: <20131211143040.GB6016@dan.olp.net> <1386774632_331846@duplo.mnsi.net> <20131211151530.GA6872@dan.olp.net> Message-ID: We have deployed several MX480 for BRAS and had good success - definitely within the 11.4X27 release but also we have one box on 13.2 (nothing like living on the edge haha). I believe Juniper is starting to also recommend 12.3 for BRAS but would have to confirm that for sure. On MX80 we also have them running at smaller sites - historically had quite a few issues but lately been quite stable minus one bug we just encountered with PPPOE subscriber sessions not getting torn down correctly (PR is supposed to be resolved in new 11.4X release coming out Mon/Tues). None of these deployments at this point have l2tp tunnels coming in (such as wholesale from ILEC provider) but in early January we will have one in production (wholesale AGAS service via Bell Canada). Paul On 12/11/2013, 1:44 PM, "Nitzan Tzelniker" wrote: >MX480 works for me as LNS with Ericson Smartedge as LAC with more then 10K >users >it is very stable with 11.4x27 version >The biggest limitations is that it is not possible to configure MTU for >the >subscriber interface ( lower the MTU to1492 for PPPOE subscribers ) > >Nitzan > > >On Wed, Dec 11, 2013 at 5:15 PM, Dan White wrote: > >> On 12/11/13 10:10 -0500, Clayton Zekelman wrote: >> >>> >>> >>> >>> At 09:30 AM 11/12/2013, Dan White wrote: >>> >>>> On 12/10/13 19:51 +0530, Nilesh Kahar wrote: >>>> >>>>> Which is a good BRAS product, to handle 15000 subscribers sessions >>>>>with >>>>> full QoS & other features? >>>>> >>>> >>>> Juniper MX (480). >>>> >>> >>> I heard there were some issues with the LAC/LNS functionality on the MX >>> series vs. JUNOSe on the E series. Is that still the case? >>> >> >> I have not used those features with the platform, so I can't confirm. >>The >> box has been very solid for us as a subscriber management platform for >> q-in-q termination. >> >> -- >> Dan White >> >> From paul at paulstewart.org Thu Dec 12 00:02:52 2013 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 11 Dec 2013 19:02:52 -0500 Subject: BRAS In-Reply-To: References: Message-ID: What kind of issues? How many subs and what code? Paul On 12/11/2013, 11:14 AM, "Nilesh Kahar" wrote: >Basically I am facing issues with MX80 LNS scenario. So just to make sure >with community whether anyone is having similar problem. >Also wanted to know about any other good BRAS product which can act fine >for LNS - LAC setup. >Thanks for all the responses. >Nil. From j at arpa.com Thu Dec 12 00:03:37 2013 From: j at arpa.com (jamie rishaw) Date: Wed, 11 Dec 2013 18:03:37 -0600 Subject: BRAS In-Reply-To: <52A7F3DA.709@cox.net> References: <52A7F3DA.709@cox.net> Message-ID: +1 That was my first thought as well. "Well, I don't swing that way but I have an ex coworker or two at Playboy that might be able to give you a pointer, no pun intended" On Tue, Dec 10, 2013 at 11:10 PM, Larry Sheldon wrote: > On 12/10/2013 8:21 AM, Nilesh Kahar wrote: > >> Which is a good BRAS product, to handle 15000 subscribers sessions with >> full QoS & other features? >> > > Victoria's Secret has some nice ones. > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > -- "sharp, dry wit and brash in his dealings with contestants." - Forbes If voting didn't matter, the GOP wouldn't make it more difficult than buying a gun. /* - teh jamie. ; uri -> http://about.me/jgr */ From wbailey at satelliteintelligencegroup.com Thu Dec 12 00:15:59 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 12 Dec 2013 00:15:59 +0000 Subject: BRAS In-Reply-To: References: <52A7F3DA.709@cox.net> Message-ID: I sincerely hope those former coworkers can hook up some invitations to the Mansion. If you can make that work, have I got a deal for you.. ;) On 12/11/13, 3:03 PM, "jamie rishaw" wrote: >+1 > >That was my first thought as well. > >"Well, I don't swing that way but I have an ex coworker or two at Playboy >that might be able to give you a pointer, no pun intended" > > > > >On Tue, Dec 10, 2013 at 11:10 PM, Larry Sheldon >wrote: > >> On 12/10/2013 8:21 AM, Nilesh Kahar wrote: >> >>> Which is a good BRAS product, to handle 15000 subscribers sessions with >>> full QoS & other features? >>> >> >> Victoria's Secret has some nice ones. >> >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) >> >> > > >-- >"sharp, dry wit and brash in his dealings with contestants." - Forbes >If voting didn't matter, the GOP wouldn't make it more difficult than >buying a gun. >/* - teh jamie. ; uri -> http://about.me/jgr */ From Jason_Livingood at cable.comcast.com Thu Dec 12 00:42:04 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 12 Dec 2013 00:42:04 +0000 Subject: turning on comcast v6 In-Reply-To: <91CEA684-5EFA-46CC-93F8-818EB3AF20FE@puck.nether.net> Message-ID: <10229F86C86EB444898E629583FD4171EDEAD533@PACDCEXMB06.cable.comcast.com> On 12/11/13, 2:32 PM, "Jared Mauch" wrote: > >I'll chime in with a link to data: > >http://www.google.com/ipv6/statistics.html#tab=per-country-ipv6-adoption > >Looking at things, USA is at 5%+ adoption, which is due to the hard work >of folks at Comcast (and other ISPs). > >Overall google is seeing 2.5%+ of traffic over native IPv6. in several >cases IPv6 is actually faster than IPv4: Anyone else have a good base of comparative performance data with large data sets / lots of end points? - Jason > >16 bytes from 2001:418:3f4::5, icmp_seq=0 hlim=57 time=18.649 ms >16 bytes from 2001:418:3f4::5, icmp_seq=1 hlim=57 time=19.008 ms >16 bytes from 2001:418:3f4::5, icmp_seq=2 hlim=57 time=18.959 ms >^C >--- puck.nether.net ping6 statistics --- >4 packets transmitted, 3 packets received, 25.0% packet loss >round-trip min/avg/max/std-dev = 18.649/18.872/19.008/0.159 ms > >PING puck.nether.net (204.42.254.5): 56 data bytes >64 bytes from 204.42.254.5: icmp_seq=0 ttl=55 time=32.920 ms >64 bytes from 204.42.254.5: icmp_seq=1 ttl=55 time=18.467 ms >64 bytes from 204.42.254.5: icmp_seq=2 ttl=55 time=22.014 ms >64 bytes from 204.42.254.5: icmp_seq=3 ttl=55 time=20.807 ms >64 bytes from 204.42.254.5: icmp_seq=4 ttl=55 time=19.096 ms >^C >--- puck.nether.net ping statistics --- >5 packets transmitted, 5 packets received, 0.0% packet loss >round-trip min/avg/max/stddev = 18.467/22.661/32.920/5.280 ms > >- jared From pauldotwall at gmail.com Thu Dec 12 00:57:37 2013 From: pauldotwall at gmail.com (Paul WALL) Date: Wed, 11 Dec 2013 16:57:37 -0800 Subject: What routers do folks use these days? In-Reply-To: References: <529827FC.8040603@forethought.net> Message-ID: Based on what? On Thu, Nov 28, 2013 at 9:59 PM, Mehmet Akcin wrote: > Look at Juniper, MX Series. > > mehmet > > On Nov 28, 2013, at 9:37 PM, Jawaid Desktop wrote: > > > We're a service provider, and we have a network full of Cat6509's. We > are finding that we are outgrowing them from the standpoint of their > ability to handle lots of large routing tables. Obviously their switching > capability is still superb but one of them with 20 peers is starting to > groan a bit and RAM is going to be an issue soon. > > > > What do people use these days? Our backbone needs in the next 2-3 years > are going to be sub-100Gbps. > > > > > > Jawaid > > > > > > > From marka at isc.org Thu Dec 12 01:11:35 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 12 Dec 2013 12:11:35 +1100 Subject: turning on comcast v6 In-Reply-To: Your message of "Thu, 12 Dec 2013 08:47:18 +1000." References: <20131211220133.23480B8AF8F@rock.dv.isc.org> Message-ID: <20131212011135.D22B6B9650C@rock.dv.isc.org> In message , George Michaelson writes: > > I am probably closer to consumer behaviour at home than most of you. I > don't regard my home router as a vehicle for hackery beyond clue I can find > on the end user public lists and rarely if ever even apply that, and I run > stock factory billion code on my billion ADSL2+ home gateway. > > I just enabled the ADSL2+ profile which had IPv6 and restarted. It came up > immediately with a /56 and I haven't touched it since. I have been using it > to SSH back home quite comfortably with an almost unmodified ACLset to > permit port 22 inbound. > > This is on Internode, in Australia. > > So, while I fully acknowledge the reality is that for a lot of people, > cable and other complex head-end systems needed change and the experience > of going dual-stack can be painful, I want to assert IT DOESNT HAVE TO BE > and I am proof by example > > It just worked. And it should "just work" if you have two router daisy chained. PD was designed to allow this to work. The home router vendors had all the protocols required to make it work. They choose not to implement a working solution. It isn't that hard to supply a take a PD request on one interface and make a upstream request if you don't have unassigned space to hand out then return the response add routing table entries to keep it all working. One can do more complicated stuff than that like running a routing protocol but static routes also work. It may not be optimal but there was nothing stopping those other vendors from coding the support. Most home routers already do stuff like that in IPv4 for DNS servers and other protocol elements. They take what they have learnt from upstream as supply it downstream. Mark > On Thu, Dec 12, 2013 at 8:01 AM, Mark Andrews wrote: > > > > > In message , Sander > > Steffann > > writes: > > > Hi, > > > > > > Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle het > > > volgende geschreven: > > > > I'm curious, do you know of a consumer-grade router which supports > > > > DHCPv6-PD? > > > > > > I have tested a whole bunch of them more than a year ago. I can remember > > > seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Link, > > > Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be > > > forgetting a few as well. Most of them weren't very advanced, but they > > > worked to get IPv6 connectivity in the house. What I am missing these > > > days is DHCPv6-PD server support to re-delegate parts of the prefix it > > > got from the ISP downstream to other home routers. As far as I know AVM > > > Fritz!box is the only one that does that today. > > > > And the need for it was obvious when all the other boxes were being > > developed. Daisy chaining routers has been part of home setups for > > many, many years if only to get configuration control because the > > ISP router is not configurable enough. There was no reason to think > > that this would change with IPv6. > > > > > Cheers, > > > Sander > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > --047d7b10ccc3ea2d0c04ed4a023d > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > >
I am probably closer to consumer behaviour at home than mo= > st of you. I don't regard my home router as a vehicle for hackery beyon= > d clue I can find on the end user public lists and rarely if ever even appl= > y that, and I run stock factory billion code on my billion ADSL2+ home gate= > way.
>
I just enabled the ADSL2+ profile which had IPv6 and restart= > ed. It came up immediately with a /56 and I haven't touched it since. I= > have been using it to SSH back home quite comfortably with an almost unmod= > ified ACLset to permit port 22 inbound.
>

This is on Internode, in Australia.

>
So, while I fully acknowledge the reality is that for a lot of people= > , cable and other complex head-end systems needed change and the experience= > of going dual-stack can be painful, I want to assert IT DOESNT HAVE TO BE = > and I am proof by example
>

It just worked.
<= > br>
On Thu, Dec 12, 2013 at 8:01 AM, Mark And= > rews < k">marka at isc.org> wrote:
>
x #ccc solid;padding-left:1ex">
> In message < ann.nl">A026246E-F884-47F0-9225-AFAA87CD35B1 at steffann.nl>, Sander St= > effann
> writes:
>
> Hi,
> >
> > Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle < inkaid at usgs.gov">kkinkaid at usgs.gov> het
> > volgende geschreven:
> > > I'm curious, do you know of a consumer-grade router which sup= > ports
> > > DHCPv6-PD?
> >
> > I have tested a whole bunch of them more than a year ago. I can rememb= > er
> > seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Lin= > k,
> > Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be
> > forgetting a few as well. Most of them weren't very advanced, but = > they
> > worked to get IPv6 connectivity in the house. What I am missing these<= > br> > > days is DHCPv6-PD server support to re-delegate parts of the prefix it= >
> > got from the ISP downstream to other home routers. As far as I know AV= > M
> > Fritz!box is the only one that does that today.
>
>
And the need for it was obvious when all the other boxes were b= > eing
> developed. =A0Daisy chaining routers has been part of home setups for
> many, many years if only to get configuration control because the
> ISP router is not configurable enough. =A0There was no reason to think
> that this would change with IPv6.
>
> > Cheers,
> > Sander
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka at isc.org">marka at isc.org
>
>

> > --047d7b10ccc3ea2d0c04ed4a023d-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From LarrySheldon at cox.net Thu Dec 12 01:42:16 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 11 Dec 2013 19:42:16 -0600 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: <0FRM1n01B1Una3W01FRPZE> References: <52A7B60B.7070809@cox.net> <0FRM1n01B1Una3W01FRPZE> Message-ID: <52A91478.4010100@cox.net> On 12/11/2013 9:21 AM, Tim Franklin wrote: >> Just because something is public doesn??t mean you have to accept >> ALL traffic, it just means you have to anticipate any potential >> problems based on Larry knowing your address rather than imagining >> him standing at the front gate of your gated community. ;) (let??s >> torture that analogy!) > > There's still a gated community? I thought that particular piece of > routing joy was long gone... > > Sorry, I'll get my coat. Tim. I'm not sure that was an analogy--it was exploring the exact meanings of two words. In any case, I submit that an address behind a gate is not a "public address". But my point is, my address is in fact public, not behind any gates--displayed once on the post that supports the mail box, again inside the mailbox door for the mail person, and on a sign on the house next to the door. Which public display grants to no one any right of access to the interior of my house (indeed to no part of the property save the path from the street to the front door). Similarly, my IP address could be publicly visible but that does not grant any right of access to the equipment it attaches to. (I might leave my front door wide open--that STILL does not grant any RIGHT of access. It does depend on archaic notions of honest and regard for rights to keep people out.) I'm done. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From cb.list6 at gmail.com Thu Dec 12 02:19:18 2013 From: cb.list6 at gmail.com (cb.list6) Date: Wed, 11 Dec 2013 18:19:18 -0800 Subject: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? In-Reply-To: <52A91478.4010100@cox.net> References: <52A7B60B.7070809@cox.net> <52A91478.4010100@cox.net> Message-ID: On Dec 11, 2013 5:45 PM, "Larry Sheldon" wrote: > > On 12/11/2013 9:21 AM, Tim Franklin wrote: >>> >>> Just because something is public doesn?t mean you have to accept >>> ALL traffic, it just means you have to anticipate any potential >>> problems based on Larry knowing your address rather than imagining >>> him standing at the front gate of your gated community. ;) (let?s >>> torture that analogy!) >> >> >> There's still a gated community? I thought that particular piece of >> routing joy was long gone... >> >> Sorry, I'll get my coat. Tim. > > > I'm not sure that was an analogy--it was exploring the exact meanings of two words. > > In any case, I submit that an address behind a gate is not a "public address". > > But my point is, my address is in fact public, not behind any gates--displayed once on the post that supports the mail box, again inside the mailbox door for the mail person, and on a sign on the house next to the door. > > Which public display grants to no one any right of access to the interior of my house (indeed to no part of the property save the path from the street to the front door). > > Similarly, my IP address could be publicly visible but that does not grant any right of access to the equipment it attaches to. > > (I might leave my front door wide open--that STILL does not grant any RIGHT of access. It does depend on archaic notions of honest and regard for rights to keep people out.) > > > I'm done. > It's maybe better to think of an ip address as a phone number. Most people get a better experience if they can make and receive calls. Your line of thinking is that you would only like to make outbound phone calls. That's cool, for you. The rest of us will be playing xbox online, which explicitly recommends unsolicited inbound connections, meaning your result will be better if you do not statefully firewall and allow xbox to form arbitrary meshes of ipsec http://tools.ietf.org/agenda/88/slides/slides-88-v6ops-0.pdf CB > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From nccariaga at stluke.com.ph Thu Dec 12 02:32:08 2013 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Thu, 12 Dec 2013 10:32:08 +0800 Subject: Facebook contact Message-ID: <52A92028.6050107@stluke.com.ph> Hi, Aside from the 'Help' menu inside the application, anyone here have an idea on how to contact Facebook (via email) regarding getting the information on a FB Page admin / creator? Would appreciate if you could send it off the list. Regards, -- -nathan From rs at seastrom.com Thu Dec 12 03:23:00 2013 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 11 Dec 2013 22:23:00 -0500 Subject: turning on comcast v6 In-Reply-To: (Eric Oosting's message of "Wed, 11 Dec 2013 10:11:09 -0500") References: Message-ID: <86a9g64usr.fsf@valhalla.seastrom.com> Eric Oosting writes: > It brings a tear to my eye that it takes: > > 0) A long standing and well informed internet technologist; > 1) specific, and potentially high end, CPE for the res; > 2) specific and custom firmware, unsupported by CPE manufacturer ... or > anyone; > 3) hand installing several additional packages; > 4) hand editing config files; > 5) sysctl kernel flags; > 6) several shout outs to friends and coworkers for assistance (resources > many don't have access to); > 7) oh, and probably hours and hours twiddling with it. > > just to get IPv6 to work correctly. > > Yea, that's TOTALLY reasonable. Pretty much works out of the box on Mikrotik RouterOS if you are secure enough in your geek cred to admit to running such stuff here in this august forum. -r From ops.lists at gmail.com Thu Dec 12 03:52:08 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 12 Dec 2013 09:22:08 +0530 Subject: Facebook contact In-Reply-To: <52A92028.6050107@stluke.com.ph> References: <52A92028.6050107@stluke.com.ph> Message-ID: How to contact fb for this = contact law enforcement and they will subpoena it from fb Without that, you're SOL --srs On Thursday, December 12, 2013, Nathanael C. Cariaga wrote: > Hi, > > Aside from the 'Help' menu inside the application, anyone here have an > idea on how to contact Facebook (via email) regarding getting the > information on a FB Page admin / creator? Would appreciate if you could > send it off the list. > > > Regards, > > -- > -nathan > > > -- --srs (iPad) From kamtha at ak-labs.net Thu Dec 12 03:59:35 2013 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Wed, 11 Dec 2013 22:59:35 -0500 Subject: do ISPs keep track of end-user IP changes within thier network? Message-ID: <20131212035935.GG54793@ak-labs.net> Hi, just a general curiousity question. it's been a long time since ive worked at an ISP. back then it was non-expiring DHCP leases and in some cases static IP for all.. (yes it was long ago..) Any feedback would be greatly appreciated.. Carlos. From ops.lists at gmail.com Thu Dec 12 04:18:24 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 12 Dec 2013 09:48:24 +0530 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <20131212035935.GG54793@ak-labs.net> References: <20131212035935.GG54793@ak-labs.net> Message-ID: Back then it was also short lease dialup and radius / tacacs to keep track. Things have got rather better On Thursday, December 12, 2013, Carlos Kamtha wrote: > Hi, > > just a general curiousity question. it's been a long time since ive worked > at an ISP. > > back then it was non-expiring DHCP leases and in some cases static IP for > all.. (yes it was long ago..) > > Any feedback would be greatly appreciated.. > > Carlos. > > -- --srs (iPad) From swmike at swm.pp.se Thu Dec 12 05:36:16 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 12 Dec 2013 06:36:16 +0100 (CET) Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <20131212035935.GG54793@ak-labs.net> References: <20131212035935.GG54793@ak-labs.net> Message-ID: On Wed, 11 Dec 2013, Carlos Kamtha wrote: > just a general curiousity question. it's been a long time since ive worked at an ISP. > > back then it was non-expiring DHCP leases and in some cases static IP for all.. (yes it was long ago..) > > Any feedback would be greatly appreciated.. Yes, it's very common to keep track of what user account/line had what IP at what time. -- Mikael Abrahamsson email: swmike at swm.pp.se From rayw at rayw.net Thu Dec 12 08:49:45 2013 From: rayw at rayw.net (Ray Wong) Date: Thu, 12 Dec 2013 00:49:45 -0800 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> Message-ID: been a while, but seems like lately it's more a question of how long. ISPs can be in position where they need to, but as things have consolidated, seems like they'd really like to forget it as soon as they can. If you've got a specific case in mind, likely best to find a direct contact and get a response about policy, even if it has to be off-record. The big ones (like one I likely shouldn't mention by name unless they do as I don't work for them) definitely do, at least long enough to handle DMCA requests and other legal obligations. -R> On Wed, Dec 11, 2013 at 9:36 PM, Mikael Abrahamsson wrote: > On Wed, 11 Dec 2013, Carlos Kamtha wrote: > > just a general curiousity question. it's been a long time since ive >> worked at an ISP. >> >> back then it was non-expiring DHCP leases and in some cases static IP for >> all.. (yes it was long ago..) >> >> Any feedback would be greatly appreciated.. >> > > Yes, it's very common to keep track of what user account/line had what IP > at what time. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > From sam at circlenet.us Thu Dec 12 11:34:26 2013 From: sam at circlenet.us (Sam Moats) Date: Thu, 12 Dec 2013 06:34:26 -0500 Subject: do ISPs keep track of end-user IP changes within thier =?UTF-8?Q?network=3F?= In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> Message-ID: I'm not sure about the current state of the industry it's been a while since I was responsible for an access network. In the past we would keep radius logs for about 4 months, these would include the username,IP address and yes (to date myself) the caller id of the customer at the time. Sam Moats On 2013-12-12 03:49, Ray Wong wrote: > been a while, but seems like lately it's more a question of how long. > ISPs > can be in position where they need to, but as things have > consolidated, > seems like they'd really like to forget it as soon as they can. If > you've > got a specific case in mind, likely best to find a direct contact and > get a > response about policy, even if it has to be off-record. The big ones > (like > one I likely shouldn't mention by name unless they do as I don't work > for > them) definitely do, at least long enough to handle DMCA requests and > other > legal obligations. > > -R> > > > On Wed, Dec 11, 2013 at 9:36 PM, Mikael Abrahamsson > wrote: > >> On Wed, 11 Dec 2013, Carlos Kamtha wrote: >> >> just a general curiousity question. it's been a long time since ive >>> worked at an ISP. >>> >>> back then it was non-expiring DHCP leases and in some cases static >>> IP for >>> all.. (yes it was long ago..) >>> >>> Any feedback would be greatly appreciated.. >>> >> >> Yes, it's very common to keep track of what user account/line had >> what IP >> at what time. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se >> >> From ryan at deadfrog.net Thu Dec 12 12:55:02 2013 From: ryan at deadfrog.net (Ryan Wilkins) Date: Thu, 12 Dec 2013 07:55:02 -0500 Subject: turning on comcast v6 In-Reply-To: <86a9g64usr.fsf@valhalla.seastrom.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> Message-ID: <757553BB-5AD9-4EC5-B9D5-75B8EE1853F3@deadfrog.net> > On Dec 11, 2013, at 10:23 PM, Rob Seastrom wrote: > > Pretty much works out of the box on Mikrotik RouterOS if you are > secure enough in your geek cred to admit to running such stuff here in > this august forum. > > -r > I run a few at home and even in an access role at an ISP I work for. They are a bit quirky but generally they work fairly well when configured and left alone. Ryan Wilkins From smeuse at mara.org Thu Dec 12 13:23:56 2013 From: smeuse at mara.org (Steve Meuse) Date: Thu, 12 Dec 2013 08:23:56 -0500 Subject: turning on comcast v6 In-Reply-To: <757553BB-5AD9-4EC5-B9D5-75B8EE1853F3@deadfrog.net> References: <86a9g64usr.fsf@valhalla.seastrom.com> <757553BB-5AD9-4EC5-B9D5-75B8EE1853F3@deadfrog.net> Message-ID: On Thu, Dec 12, 2013 at 7:55 AM, Ryan Wilkins wrote: > > "They are a bit quirky but generally they work fairly well when configured > and left alone." > That describes most every router ever made :) -Steve From dot at dotat.at Thu Dec 12 13:29:45 2013 From: dot at dotat.at (Tony Finch) Date: Thu, 12 Dec 2013 13:29:45 +0000 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: Message-ID: Anurag Bhatia wrote: > > Now I see presence of some (legitimate) DNS forwarders and hence I don't > wish to limit queries. You are going to have to change your mind about this one. Open recursive resolvers are a really bad idea, unless you can afford a lot of time and cleverness to manage the abuse. Get your users to choose a more appropriate name server, and restrict your name server to your local networks. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From nilesh.kahar at outlook.com Thu Dec 12 13:36:57 2013 From: nilesh.kahar at outlook.com (Nilesh Kahar) Date: Thu, 12 Dec 2013 19:06:57 +0530 Subject: BRAS Message-ID: There is a significant delay for user termination via L2TP; more than 40 seconds. --- Original Message --- From: "Paul Stewart" Sent: December 12, 2013 5:33 AM To: "Nilesh Kahar" , nanog at nanog.org Subject: Re: BRAS What kind of issues? How many subs and what code? Paul On 12/11/2013, 11:14 AM, "Nilesh Kahar" wrote: >Basically I am facing issues with MX80 LNS scenario. So just to make sure >with community whether anyone is having similar problem. >Also wanted to know about any other good BRAS product which can act fine >for LNS - LAC setup. >Thanks for all the responses. >Nil. From paul at paulstewart.org Thu Dec 12 14:04:49 2013 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 12 Dec 2013 09:04:49 -0500 Subject: BRAS In-Reply-To: References: Message-ID: I thought that was resolved? Don?t have an L2TP scenario at the moment but will in early January so will have to follow up with engineering to confirm? Many thanks, Paul On 12/12/2013, 8:36 AM, "Nilesh Kahar" wrote: >There is a significant delay for user termination via L2TP; more than 40 >seconds. > >--- Original Message --- > >From: "Paul Stewart" >Sent: December 12, 2013 5:33 AM >To: "Nilesh Kahar" , nanog at nanog.org >Subject: Re: BRAS > >What kind of issues? How many subs and what code? > >Paul > > > >On 12/11/2013, 11:14 AM, "Nilesh Kahar" wrote: > >>Basically I am facing issues with MX80 LNS scenario. So just to make sure >>with community whether anyone is having similar problem. >>Also wanted to know about any other good BRAS product which can act fine >>for LNS - LAC setup. >>Thanks for all the responses. >>Nil. > > > From mmethw2003 at gmail.com Wed Dec 11 10:45:58 2013 From: mmethw2003 at gmail.com (Methsri Wickramarathna) Date: Wed, 11 Dec 2013 16:15:58 +0530 Subject: CNAME issue Message-ID: Hi All, One of our customer having the following requirement. There is a domain abcd.com ( zone file created , A records are pointed ). He has another domain xyz.com. He want us to create a separate zone file for " xyz.com " & abcd.com should be the CNAME of it. ( No "A" records mentioned ) I'm bit confuse about adding this in zone file. Can any one help ? :( -- ~~( ??? )~~ From jason_jenero at yahoo.com Thu Dec 12 13:59:56 2013 From: jason_jenero at yahoo.com (Jason Jenero) Date: Thu, 12 Dec 2013 05:59:56 -0800 (PST) Subject: 100 Mb/s private link SF to NY price PRIVATELY needed Message-ID: <1386856796.59821.YahooMailNeo@web160606.mail.bf1.yahoo.com> Hi, Looking to see if people can PRIVATELY EMAIL ME about an opportunity for a client of mine for a private 100Mb/s circuit between: A location of Suite 102F in SF (200 Paul) TelX Z location of 4th Fl (Atlantic Metro) 325 Hudson in NYC, NY. They are planning to pick the provider on the best mix of SLA and price. We can't handle it but will do it as a passthrough. They're looking to order no later than 12/20/13 JJ JJ+T Consulting (Yahoo used to cut down on spam) From a.slastenov at gmail.com Thu Dec 12 15:05:54 2013 From: a.slastenov at gmail.com (Andrey Slastenov) Date: Thu, 12 Dec 2013 19:05:54 +0400 Subject: BRAS In-Reply-To: References: Message-ID: <1563513E-9E27-4312-A095-52E5AD57AF9F@gmail.com> Huawei ME60E ?????????? ? iPhone > 10 ???. 2013 ?., ? 18:21, Nilesh Kahar ???????(?): > > Which is a good BRAS product, to handle 15000 subscribers sessions with full QoS & other features? From nanog at rsle.net Thu Dec 12 16:07:28 2013 From: nanog at rsle.net (R. Scott Evans) Date: Thu, 12 Dec 2013 11:07:28 -0500 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> Message-ID: <52A9DF40.2000607@rsle.net> I'm no lawyer but in the U.S., 18 USC 2703 appears to indicate this data must be kept for at least 180 days. -Scott On 12/12/13 06:34, Sam Moats wrote: > I'm not sure about the current state of the industry it's been a while > since I was responsible for an access network. In the past we would keep > radius logs for about 4 months, these would include the username,IP > address and yes (to date myself) the caller id of the customer at the time. > > Sam Moats > > On 2013-12-12 03:49, Ray Wong wrote: >> been a while, but seems like lately it's more a question of how long. >> ISPs >> can be in position where they need to, but as things have consolidated, >> seems like they'd really like to forget it as soon as they can. If you've >> got a specific case in mind, likely best to find a direct contact and >> get a >> response about policy, even if it has to be off-record. The big ones >> (like >> one I likely shouldn't mention by name unless they do as I don't work for >> them) definitely do, at least long enough to handle DMCA requests and >> other >> legal obligations. >> >> -R> >> >> >> On Wed, Dec 11, 2013 at 9:36 PM, Mikael Abrahamsson >> wrote: >> >>> On Wed, 11 Dec 2013, Carlos Kamtha wrote: >>> >>> just a general curiousity question. it's been a long time since ive >>>> worked at an ISP. >>>> >>>> back then it was non-expiring DHCP leases and in some cases static >>>> IP for >>>> all.. (yes it was long ago..) >>>> >>>> Any feedback would be greatly appreciated.. >>>> >>> >>> Yes, it's very common to keep track of what user account/line had >>> what IP >>> at what time. >>> >>> -- >>> Mikael Abrahamsson email: swmike at swm.pp.se >>> >>> > > From jake at nobistech.net Thu Dec 12 16:14:01 2013 From: jake at nobistech.net (Jake Mertel) Date: Thu, 12 Dec 2013 09:14:01 -0700 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <52A9DF40.2000607@rsle.net> References: <20131212035935.GG54793@ak-labs.net> <52A9DF40.2000607@rsle.net> Message-ID: While I'm also not an attorney, my reading of 18 USC 2703 leads me to believe that records need only to be preserved for 180 days if a governmental entity (i.e. law enforcement agency, regulatory body, prosecutors office, etc) makes a request that such records be preserved. To the best of my knowledge, there's no statue on the books (at least at a federal level) which would mandate that a provider keep any records relating to dynamic IP allocations. -- Regards, Jake Mertel Nobis Technology Group, LLC *Web: *http://www.nobistech.net *Phone: *1-480-212-1710 *Mail:* 6930 East Chauncey Lane, Suite 150, Phoenix, AZ 85054 On Thu, Dec 12, 2013 at 9:07 AM, R. Scott Evans wrote: > I'm no lawyer but in the U.S., 18 USC 2703 appears to indicate this data > must be kept for at least 180 days. > > -Scott > > > On 12/12/13 06:34, Sam Moats wrote: > >> I'm not sure about the current state of the industry it's been a while >> since I was responsible for an access network. In the past we would keep >> radius logs for about 4 months, these would include the username,IP >> address and yes (to date myself) the caller id of the customer at the >> time. >> >> Sam Moats >> >> On 2013-12-12 03:49, Ray Wong wrote: >> >>> been a while, but seems like lately it's more a question of how long. >>> ISPs >>> can be in position where they need to, but as things have consolidated, >>> seems like they'd really like to forget it as soon as they can. If you've >>> got a specific case in mind, likely best to find a direct contact and >>> get a >>> response about policy, even if it has to be off-record. The big ones >>> (like >>> one I likely shouldn't mention by name unless they do as I don't work for >>> them) definitely do, at least long enough to handle DMCA requests and >>> other >>> legal obligations. >>> >>> -R> >>> >>> >>> On Wed, Dec 11, 2013 at 9:36 PM, Mikael Abrahamsson >>> wrote: >>> >>> On Wed, 11 Dec 2013, Carlos Kamtha wrote: >>>> >>>> just a general curiousity question. it's been a long time since ive >>>> >>>>> worked at an ISP. >>>>> >>>>> back then it was non-expiring DHCP leases and in some cases static >>>>> IP for >>>>> all.. (yes it was long ago..) >>>>> >>>>> Any feedback would be greatly appreciated.. >>>>> >>>>> >>>> Yes, it's very common to keep track of what user account/line had >>>> what IP >>>> at what time. >>>> >>>> -- >>>> Mikael Abrahamsson email: swmike at swm.pp.se >>>> >>>> >>>> >> >> > > From jlewis at lewis.org Thu Dec 12 16:35:29 2013 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 12 Dec 2013 11:35:29 -0500 (EST) Subject: CNAME issue In-Reply-To: References: Message-ID: On Wed, 11 Dec 2013, Methsri Wickramarathna wrote: > Hi All, > One of our customer having the following requirement. > > There is a domain abcd.com ( zone file created , A records are pointed ). > He has another domain xyz.com. He want us to create a separate zone file > for " xyz.com " & abcd.com should be the CNAME of it. ( No "A" records > mentioned ) > > I'm bit confuse about adding this in zone file. Can any one help ? :( This is really the wrong list to be asking for help with basic DNS. What you've described as what your customer wants is not possible. Google: cname and other data to learn why. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From randy at psg.com Thu Dec 12 16:44:10 2013 From: randy at psg.com (Randy Bush) Date: Thu, 12 Dec 2013 08:44:10 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <757553BB-5AD9-4EC5-B9D5-75B8EE1853F3@deadfrog.net> Message-ID: >> "They are a bit quirky but generally they work fairly well when configured >> and left alone." > That describes most every router ever made :) except those which burst into flame except those which ... From phobos at panopticism.net Thu Dec 12 17:34:36 2013 From: phobos at panopticism.net (/dev/ph0b0s) Date: Thu, 12 Dec 2013 12:34:36 -0500 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <52A9DF40.2000607@rsle.net> References: <20131212035935.GG54793@ak-labs.net> <52A9DF40.2000607@rsle.net> Message-ID: <20131212173436.GA11300@phobos.panopticism.net> On 12/12, R. Scott Evans wrote: > I'm no lawyer but in the U.S., 18 USC 2703 appears to indicate this > data must be kept for at least 180 days. You are very mistaken. There is no requirement to retain *any* logs (notwithstanding any orders issued by a court). From ddowdle at leopard.net Thu Dec 12 18:54:15 2013 From: ddowdle at leopard.net (David Dowdle) Date: Thu, 12 Dec 2013 10:54:15 -0800 (PST) Subject: CNAME issue In-Reply-To: References: Message-ID: short answer: can't be done You cannot have a cname and 'other' information for same entry. As a zone requires an SOA record, you cannot have a CNAME for the entire domain (theoretically a registrar could do it in .com, but afaik nobody does his). Depending on customer's requirements, can put in a wildcard *.abcd.com in cname xyz.com Or can load the same zone file for both abcd.com and xyz.com, so in both, mail goes to the same place On Wed, 11 Dec 2013, Methsri Wickramarathna wrote: > Hi All, > One of our customer having the following requirement. > > There is a domain abcd.com ( zone file created , A records are pointed ). > He has another domain xyz.com. He want us to create a separate zone file > for " xyz.com " & abcd.com should be the CNAME of it. ( No "A" records > mentioned ) > > I'm bit confuse about adding this in zone file. Can any one help ? :( > > -- > > > ~~( ??? )~~ > From frnkblk at iname.com Thu Dec 12 20:11:37 2013 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 12 Dec 2013 14:11:37 -0600 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <20131212035935.GG54793@ak-labs.net> References: <20131212035935.GG54793@ak-labs.net> Message-ID: <003f01cef776$5d0edda0$172c98e0$@iname.com> Option 82 info and logging. Frank -----Original Message----- From: Carlos Kamtha [mailto:kamtha at ak-labs.net] Sent: Wednesday, December 11, 2013 10:00 PM To: nanog at nanog.org Subject: do ISPs keep track of end-user IP changes within thier network? Hi, just a general curiousity question. it's been a long time since ive worked at an ISP. back then it was non-expiring DHCP leases and in some cases static IP for all.. (yes it was long ago..) Any feedback would be greatly appreciated.. Carlos. From ahebert at pubnix.net Thu Dec 12 20:12:31 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 12 Dec 2013 15:12:31 -0500 Subject: CNAME issue In-Reply-To: References: Message-ID: <52AA18AF.9020103@pubnix.net> Confused :( Do your customer want: www.xyz.com pointing to the same IP as www.abcd.com without having to manage xyz.com? ------ With bind: zonefile xyz.com $ORIGIN xyz.com. $INCLUDE domains/abcd.com.all zonefile abcd.com $ORIGIN abcd.com. $INCLUDE domains/abcd.com.all Just make sure nothing is the .all has the .abcd.com. (dots are important). Without bind: Good luck. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 12/12/13 13:54, David Dowdle wrote: > short answer: can't be done > > You cannot have a cname and 'other' information for same entry. As a > zone requires an SOA record, you cannot have a CNAME for the entire > domain (theoretically a registrar could do it in .com, but afaik > nobody does his). > > Depending on customer's requirements, can put in a wildcard > *.abcd.com in cname xyz.com > > Or can load the same zone file for both abcd.com and xyz.com, so in > both, mail goes to the same place > > > On Wed, 11 Dec 2013, Methsri Wickramarathna wrote: > >> Hi All, >> One of our customer having the following requirement. >> >> There is a domain abcd.com ( zone file created , A records are >> pointed ). >> He has another domain xyz.com. He want us to create a separate zone file >> for " xyz.com " & abcd.com should be the CNAME of it. ( No "A" records >> mentioned ) >> >> I'm bit confuse about adding this in zone file. Can any one help ? :( >> >> -- >> >> >> ~~( ??? )~~ >> > > > From sina at redteam.io Thu Dec 12 16:23:10 2013 From: sina at redteam.io (SiNA Rabbani) Date: Thu, 12 Dec 2013 08:23:10 -0800 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: Message-ID: http://www.team-cymru.org/Services/Resolvers/ The Internet will be a better place with less open resolvers around. --SiNA On Dec 12, 2013 5:32 AM, "Tony Finch" wrote: > Anurag Bhatia wrote: > > > > Now I see presence of some (legitimate) DNS forwarders and hence I don't > > wish to limit queries. > > You are going to have to change your mind about this one. Open recursive > resolvers are a really bad idea, unless you can afford a lot of time and > cleverness to manage the abuse. Get your users to choose a more > appropriate name server, and restrict your name server to your local > networks. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at > first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or > good, > occasionally poor at first. > > From fergdawgster at mykolab.com Thu Dec 12 20:26:35 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 12 Dec 2013 12:26:35 -0800 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: Message-ID: <52AA1BFB.70806@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Also: http://openresolverproject.org/ Also, open resolvers are harmful to the Internet, so it would not surprise me to see organizations to begin blocking any communication with them by published lists open recursive resolvers. - - ferg. On 12/12/2013 8:23 AM, SiNA Rabbani wrote: > http://www.team-cymru.org/Services/Resolvers/ > > The Internet will be a better place with less open resolvers around. > > --SiNA > On Dec 12, 2013 5:32 AM, "Tony Finch" wrote: > >> Anurag Bhatia wrote: >>> >>> Now I see presence of some (legitimate) DNS forwarders and hence I >>> don't wish to limit queries. >> >> You are going to have to change your mind about this one. Open recursive >> resolvers are a really bad idea, unless you can afford a lot of time and >> cleverness to manage the abuse. Get your users to choose a more >> appropriate name server, and restrict your name server to your local >> networks. >> >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ >> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at >> first. >> Rough, becoming slight or moderate. Showers, rain at first. Moderate or >> good, >> occasionally poor at first. >> >> > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSqhvyq1pz9mNUZTMRAiXgAKCDaQ1KmlVCjXKffz0bVmHRGpbwxgCfXEk7 tHQx8SXtY/xNFLm2L3Uu8x8= =tTIW -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From ahebert at pubnix.net Thu Dec 12 20:27:19 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 12 Dec 2013 15:27:19 -0500 Subject: Best practice on TCP replies for ANY queries In-Reply-To: References: Message-ID: <52AA1C27.2060809@pubnix.net> The internet will be better without ISP refusing to apply BCP38. This is a pointless argument since the majority of the industry prefer going after the UDP flood instead of curbing the problem at its source once and for all. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 12/12/13 11:23, SiNA Rabbani wrote: > http://www.team-cymru.org/Services/Resolvers/ > > The Internet will be a better place with less open resolvers around. > > --SiNA > On Dec 12, 2013 5:32 AM, "Tony Finch" wrote: > >> Anurag Bhatia wrote: >>> Now I see presence of some (legitimate) DNS forwarders and hence I don't >>> wish to limit queries. >> You are going to have to change your mind about this one. Open recursive >> resolvers are a really bad idea, unless you can afford a lot of time and >> cleverness to manage the abuse. Get your users to choose a more >> appropriate name server, and restrict your name server to your local >> networks. >> >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ >> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at >> first. >> Rough, becoming slight or moderate. Showers, rain at first. Moderate or >> good, >> occasionally poor at first. >> >> > From jared at puck.nether.net Thu Dec 12 20:33:55 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 12 Dec 2013 15:33:55 -0500 Subject: Best practice on TCP replies for ANY queries In-Reply-To: <52AA1C27.2060809@pubnix.net> References: <52AA1C27.2060809@pubnix.net> Message-ID: On Dec 12, 2013, at 3:27 PM, Alain Hebert wrote: > The internet will be better without ISP refusing to apply BCP38. > > > > This is a pointless argument since the majority of the industry > prefer going after the UDP flood instead of > curbing the problem at its source once and for all. I would restate this as "Network Operators" vs "ISPs". If you operate a network and it allows spoofing internally, or facing your ISP, you are also at fault. - Jared From jason at unlimitednet.us Thu Dec 12 21:55:14 2013 From: jason at unlimitednet.us (Jason Canady) Date: Thu, 12 Dec 2013 16:55:14 -0500 Subject: McAfee SiteAdvisor Removal Message-ID: <52AA30C2.2090909@unlimitednet.us> Our web site has been incorrectly listed on McAfee's SiteAdvisor service as "SPAM URLs". We offer dedicated servers to clients and I suspect that one of them was in the same /24 block of IPs. I have tried numerous times to get removed and have been unsuccessful. Does anyone have a contact at SiteAdvisor or can someone contact me off-list to get this taken care of? Thanks in advance! Best Regards, -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure www.unlimitednet.us jason at unlimitednet.us twitter: @unlimitednet From kwoody at citywest.ca Fri Dec 13 01:11:33 2013 From: kwoody at citywest.ca (Keith) Date: Thu, 12 Dec 2013 17:11:33 -0800 Subject: CWDM question Message-ID: <52AA5EC5.9090109@citywest.ca> Hi. We are doing a fiber link between us and another SP using CWDM. There is traffic flowing just fine at the 1310 wave, and have recently added a 1471 wave. On the 1471 wave there are some problems with it. From our perspective, and we have packet captured this, we are transmitting data to them, but they say they are not seeing anything. We are receiving from them, and while we show that packets are leaving our interface to them, they are getting nothing at all. There are good light levels between the two locations and do not understand why they are not seeing traffic from us even though we are sending it. Our packet counters show we are transmitting to them and receiving from them. Is it possible to have RX and TX light and things appear to be ok, but have the RX on their side fubar in some way that it is not operating correctly in that our traffic is not reaching them? Thanks. From jared at puck.nether.net Fri Dec 13 01:15:40 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 12 Dec 2013 20:15:40 -0500 Subject: CWDM question In-Reply-To: <52AA5EC5.9090109@citywest.ca> References: <52AA5EC5.9090109@citywest.ca> Message-ID: On Dec 12, 2013, at 8:11 PM, Keith wrote: > Hi. > > We are doing a fiber link between us and another SP using CWDM. > > There is traffic flowing just fine at the 1310 wave, and have recently added a > 1471 wave. > > On the 1471 wave there are some problems with it. From our perspective, and we > have packet captured this, we are transmitting data to them, but they say they > are not seeing anything. We are receiving from them, and while we show that > packets are leaving our interface to them, they are getting nothing at all. > > There are good light levels between the two locations and do not understand > why they are not seeing traffic from us even though we are sending it. Our packet > counters show we are transmitting to them and receiving from them. > > Is it possible to have RX and TX light and things appear to be ok, but have the > RX on their side fubar in some way that it is not operating correctly in that our > traffic is not reaching them? Are you using fixed optics or tunables? Are transponders involved for the CWDM side then you have ?client optics? at 850nm or 1310? Is there a filter involved? Do you have a light meter? What do the optics show for the various light levels and frequencies involved? - Jared From sroche at lakelandnetworks.com Fri Dec 13 02:40:51 2013 From: sroche at lakelandnetworks.com (Sam Roche) Date: Thu, 12 Dec 2013 21:40:51 -0500 Subject: CWDM question In-Reply-To: <52AA5EC5.9090109@citywest.ca> Message-ID: <20131213024051.18051218.93740.18135@lakelandnetworks.com> From kwoody at citywest.ca Fri Dec 13 03:17:28 2013 From: kwoody at citywest.ca (Keith) Date: Thu, 12 Dec 2013 19:17:28 -0800 Subject: CWDM question In-Reply-To: References: <52AA5EC5.9090109@citywest.ca> Message-ID: <52AA7C48.5050402@citywest.ca> On 12/12/2013 5:15 PM, Jared Mauch wrote: > On Dec 12, 2013, at 8:11 PM, Keith wrote: > >> Hi. >> >> We are doing a fiber link between us and another SP using CWDM. >> >> There is traffic flowing just fine at the 1310 wave, and have recently added a >> 1471 wave. >> >> On the 1471 wave there are some problems with it. From our perspective, and we >> have packet captured this, we are transmitting data to them, but they say they >> are not seeing anything. We are receiving from them, and while we show that >> packets are leaving our interface to them, they are getting nothing at all. >> >> There are good light levels between the two locations and do not understand >> why they are not seeing traffic from us even though we are sending it. Our packet >> counters show we are transmitting to them and receiving from them. >> >> Is it possible to have RX and TX light and things appear to be ok, but have the >> RX on their side fubar in some way that it is not operating correctly in that our >> traffic is not reaching them? > Are you using fixed optics or tunables? Are transponders involved for the CWDM side then you have ?client optics? at 850nm or 1310? Is there a filter involved? Do you have a light meter? What do the optics show for the various light levels and frequencies involved? > > - Jared Fixed optics, there are no transponders, just a passive mux. No filters, though there is a pad on our side. Light levels on our side are good and within spec. I have been trying to find out from the SP what theirs are at presently, but when the circuit was first lit levels were taken and found to be within spec on both ends. Only 1310 and 1471 in use. We are 800+km away from the site so its hard to get some hands/eyes there at present. Thanks. From kwoody at citywest.ca Fri Dec 13 03:20:25 2013 From: kwoody at citywest.ca (Keith) Date: Thu, 12 Dec 2013 19:20:25 -0800 Subject: CWDM question In-Reply-To: <20131213024051.18051218.93740.18135@lakelandnetworks.com> References: <20131213024051.18051218.93740.18135@lakelandnetworks.com> Message-ID: <52AA7CF9.3030508@citywest.ca> That is whats next. They took down the whole fiber instead of just the 1471 wave to test which killed transit...grrr.. They say their tx/rx are within spec. Next is jumpers and sfp swaps I guess. Thanks. On 12/12/2013 6:40 PM, Sam Roche wrote: > If you have a CWDM optical power meter and light source, see if you can measure the > power level on the receiving end and verify that it is within the spec of the SFP. Maybe > it is a bad jumper or port on the 1471 receive on their end or send on your end. > > If the two switches can be brought to the same location, you might also want to connect > them together using short jumpers, but make sure you have a power meter to ensure you > use the proper attenuators to avoid burning out your optics. This would rule out your > fiber and mux in case it an issue with an appliance or SFP. I've had CWDM SFPs burn out > for no apparent reason twice now. > > *From: *Keith > *Sent: *Thursday, December 12, 2013 8:11 PM > *To: *nanog at nanog.org > *Subject: *CWDM question > > > CWDM question > > Hi. > > We are doing a fiber link between us and another SP using CWDM. > > There is traffic flowing just fine at the 1310 wave, and have recently added a > 1471 wave. > > On the 1471 wave there are some problems with it. From our perspective, and we > have packet captured this, we are transmitting data to them, but they say they > are not seeing anything. We are receiving from them, and while we show that > packets are leaving our interface to them, they are getting nothing at all. > > There are good light levels between the two locations and do not understand > why they are not seeing traffic from us even though we are sending it. Our packet > counters show we are transmitting to them and receiving from them. > > Is it possible to have RX and TX light and things appear to be ok, but have the > RX on their side fubar in some way that it is not operating correctly in that our > traffic is not reaching them? > > Thanks. > > > > > > > From symack at gmail.com Fri Dec 13 13:54:32 2013 From: symack at gmail.com (Nick Cameo) Date: Fri, 13 Dec 2013 08:54:32 -0500 Subject: Cisco ADSL2/VDSL2 Voip Router Message-ID: Hello Everyone, I have a customer that is looking for a voip router. The router part is easy however, they need it to support their ADSL/VDSL connection PPoE, and all that lovely stuff. Can you gents and ladies kindly recommend something that would fit all. preferably the cisco route. If you have one not in use, we would be interested in hearing from you. Kind Regards, Nick. From alessandro.ratti at gmail.com Fri Dec 13 14:01:41 2013 From: alessandro.ratti at gmail.com (Alessandro Ratti) Date: Fri, 13 Dec 2013 15:01:41 +0100 Subject: Cisco ADSL2/VDSL2 Voip Router In-Reply-To: References: Message-ID: Hi Nick, you can take a look to this model http://www.cisco.com/en/US/prod/collateral/routers/ps380/ps10082/data_sheet_c78-682548.html . Contact me off list if you need more info. Regards On Fri, Dec 13, 2013 at 2:54 PM, Nick Cameo wrote: > Hello Everyone, > > I have a customer that is looking for a voip router. The router part > is easy however, > they need it to support their ADSL/VDSL connection PPoE, and all that > lovely > stuff. Can you gents and ladies kindly recommend something that would fit > all. preferably the cisco route. > > If you have one not in use, we would be interested in hearing from you. > > Kind Regards, > > Nick. > > -- Ciao, Alessandro From remco at signet.nl Fri Dec 13 14:04:32 2013 From: remco at signet.nl (Remco Bressers) Date: Fri, 13 Dec 2013 15:04:32 +0100 Subject: Cisco ADSL2/VDSL2 Voip Router In-Reply-To: References: Message-ID: <52AB13F0.9040502@signet.nl> Hi Nick, Cisco 867VAE and 887VA are pretty fine routers. Regards, Remco Bressers Signet B.V. On 12/13/2013 02:54 PM, Nick Cameo wrote: > Hello Everyone, > > I have a customer that is looking for a voip router. The router part > is easy however, > they need it to support their ADSL/VDSL connection PPoE, and all that lovely > stuff. Can you gents and ladies kindly recommend something that would fit > all. preferably the cisco route. > > If you have one not in use, we would be interested in hearing from you. > > Kind Regards, > > Nick. > From seth.mos at dds.nl Fri Dec 13 14:06:17 2013 From: seth.mos at dds.nl (Seth Mos) Date: Fri, 13 Dec 2013 15:06:17 +0100 Subject: Cisco ADSL2/VDSL2 Voip Router In-Reply-To: References: Message-ID: <52AB1459.6050306@dds.nl> On 13-12-2013 14:54, Nick Cameo wrote: > Hello Everyone, > > I have a customer that is looking for a voip router. The router part > is easy however, > they need it to support their ADSL/VDSL connection PPoE, and all that lovely > stuff. Can you gents and ladies kindly recommend something that would fit > all. preferably the cisco route. > > If you have one not in use, we would be interested in hearing from you. Something entirely different: Draytek Vigor 2850, maybe? Cheers From joe at nethead.com Fri Dec 13 15:51:17 2013 From: joe at nethead.com (Joe Hamelin) Date: Fri, 13 Dec 2013 07:51:17 -0800 Subject: Cisco ADSL2/VDSL2 Voip Router In-Reply-To: <52AB1459.6050306@dds.nl> References: <52AB1459.6050306@dds.nl> Message-ID: On 13-12-2013 14:54, Nick Cameo wrote: > Hello Everyone, > > I have a customer that is looking for a voip router. The Edgewater EdgeMarc 200 series has worked well for me. The ones that I've used have 2xFXS and 1xFXO ports with ADSL. Lots of knobs in a fairly sane web GUI. http://www.thetelecomspot.com/systems-and-components/sip-and-voip/sip-voip-gateways/edgewater-gateways/edgemarc-200-series.html -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From Sean.Pedersen at usairways.com Fri Dec 13 16:16:00 2013 From: Sean.Pedersen at usairways.com (Pedersen, Sean) Date: Fri, 13 Dec 2013 09:16:00 -0700 Subject: Cisco ADSL2/VDSL2 Voip Router In-Reply-To: References: <52AB1459.6050306@dds.nl> Message-ID: <7EF4A8B03B0A3A44858C8B42E0DB236A0123326D9C9D@PHX-52N-EXM04A.lcc.usairways.com> We used the EM 200 series at my last job. They behaved reasonably well, especially considering the nutty scenarios we deployed them in. If you're committed to Cisco, the 800 series is great as long as you don't intend to terminate TDM traffic and convert to SIP, transcode, or deploy any local voice services via the router such as conference bridging. Then you'd need something in the ISR/ISRG2 line w/ PVDMs installed. -----Original Message----- From: Joe Hamelin [mailto:joe at nethead.com] Sent: Friday, December 13, 2013 8:51 AM To: Seth Mos Cc: NANOG list Subject: Re: Cisco ADSL2/VDSL2 Voip Router On 13-12-2013 14:54, Nick Cameo wrote: > Hello Everyone, > > I have a customer that is looking for a voip router. The Edgewater EdgeMarc 200 series has worked well for me. The ones that I've used have 2xFXS and 1xFXO ports with ADSL. Lots of knobs in a fairly sane web GUI. http://www.thetelecomspot.com/systems-and-components/sip-and-voip/sip-voip-gateways/edgewater-gateways/edgemarc-200-series.html -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From symack at gmail.com Fri Dec 13 16:49:03 2013 From: symack at gmail.com (Nick Cameo) Date: Fri, 13 Dec 2013 11:49:03 -0500 Subject: Cisco ADSL2/VDSL2 Voip Router In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0123326D9C9D@PHX-52N-EXM04A.lcc.usairways.com> References: <52AB1459.6050306@dds.nl> <7EF4A8B03B0A3A44858C8B42E0DB236A0123326D9C9D@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: Ooops, I should have mentioned. We do not need an ISDN gateway (FXO/FXS). The connection is purely SIP. What is important is support for ADSL/ADSL2 VDSL/VDSL2 and PPoE. Bell Canada...... N. From symack at gmail.com Fri Dec 13 17:36:00 2013 From: symack at gmail.com (Nick Cameo) Date: Fri, 13 Dec 2013 12:36:00 -0500 Subject: Cisco ADSL2/VDSL2 Voip Router In-Reply-To: <7EF4A8B03B0A3A44858C8B42E0DB236A0123326D9C9D@PHX-52N-EXM04A.lcc.usairways.com> References: <52AB1459.6050306@dds.nl> <7EF4A8B03B0A3A44858C8B42E0DB236A0123326D9C9D@PHX-52N-EXM04A.lcc.usairways.com> Message-ID: > convert to SIP, transcode, or deploy any > local voice services via the router such as conference bridging. Then you'd > need something in the ISR/ISRG2 line w/ PVDMs installed. Very interesting point! We would the router to do some transcoding yes, to take some load off of the servers. That being said, we were originally looking at a Cisco 3845 integrated router that allows for PVDM2, or 3900 that allow for PVDM3 accompanied with VDSL2 and ADSL2 wan interface card. Your feedback is greatly appreciated. N. From jra at baylink.com Fri Dec 13 18:12:06 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 13 Dec 2013 13:12:06 -0500 (EST) Subject: Catalyst IOS refresher site? Message-ID: <16439970.652.1386958326876.JavaMail.root@benjamin.baylink.com> It's been a bit too long since I was near the high end, so I grabbed a 4507 from my local surplus vendor; dual PS, dual supe, Gig Fiber (large transceivers, alas, not GBIC), and 3 48port RJ45 POE cards. For $60. I love surplus. Is there a good Catalyst-IOS tutorial on line I can buzz through, to refresh my memory on where everything is? Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From streiner at cluebyfour.org Fri Dec 13 15:12:34 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 13 Dec 2013 10:12:34 -0500 (EST) Subject: CWDM question In-Reply-To: <52AA7C48.5050402@citywest.ca> References: <52AA5EC5.9090109@citywest.ca> <52AA7C48.5050402@citywest.ca> Message-ID: On Thu, 12 Dec 2013, Keith wrote: > Fixed optics, there are no transponders, just a passive mux. No filters, > though there is a pad on our side. > Light levels on our side are good and within spec. I have been trying to find > out from the SP what theirs > are at presently, but when the circuit was first lit levels were taken and > found to be within spec on both > ends. Another possibility is that the fiber you're using has higher attenuation at 1471nm than at 1310. While 1471 is outside of the 'water peak' band (E band - 1360-1460nm, centered at 1383nm, iirc), the type of fiber could could still have higher attenuation that runs into the S and O bands. If replacing optics doesn't solve the issue, you'll probably need a test set that can test specifically at 1471 nm. jms From brez at brezworks.com Fri Dec 13 20:25:19 2013 From: brez at brezworks.com (Jeremy Bresley) Date: Fri, 13 Dec 2013 14:25:19 -0600 Subject: Catalyst IOS refresher site? In-Reply-To: <16439970.652.1386958326876.JavaMail.root@benjamin.baylink.com> References: <16439970.652.1386958326876.JavaMail.root@benjamin.baylink.com> Message-ID: <52AB6D2F.5040501@brezworks.com> On 12/13/2013 12:12 PM, Jay Ashworth wrote: > It's been a bit too long since I was near the high end, so I grabbed a > 4507 from my local surplus vendor; dual PS, dual supe, Gig Fiber (large > transceivers, alas, not GBIC), and 3 48port RJ45 POE cards. For $60. > > I love surplus. > > Is there a good Catalyst-IOS tutorial on line I can buzz through, to > refresh my memory on where everything is? Might help if you said what type of line cards and sup you've got. A SupII era card is CatOS, SupIII and newer are IOS, command sets are completely different, and depending on the line cards you've got, you might have some of the really old L2 only cards (can't remember if you could do L3 on the bastard Gig/FE cards only, or if it was dependent on the particular Sup installed). That said, if it's an IOS Sup, I'd start here: http://www.cisco.com/en/US/products/hw/switches/ps4324/prod_command_reference_list.html Jeremy "TheBrez" Bresley brez at brezworks.com From houdini+nanog at clanspum.net Fri Dec 13 20:56:24 2013 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Fri, 13 Dec 2013 14:56:24 -0600 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <20131213205624.GX13944@clanspum.net> Kinkaid, Kyle(kkinkaid at usgs.gov)@Wed, Dec 11, 2013 at 11:46:56AM -0800: > On Wed, Dec 11, 2013 at 11:18 AM, Owen DeLong wrote: > > > It doesn?t. You can get IPv6 working with off-the-shelf equipment if you > > choose to. > > > > Randy chose to use that particular hardware and software combination. > > > I'm curious, do you know of a consumer-grade router which supports > DHCPv6-PD? I have been making plans to put OpenWRT on my home router to get > IPv6 and have found v6 support quite lacking. Most of the routers seem to > like to focus on various transition technologies like 6to4 tunnels. I > would love to go to NewEgg and get a home router for $50 (or even $100) > that is ready to go. > > What's more surprising is even Cisco and Juniper have been lagging. The > SRX only got DHCPv6-PD support in the last 6 months or so and I don't think > the ASA has it yet. However, ISR routers like the 88x and 86x support it. So what it's worth, I'm on Comcast Business, using an ASUS RT-N66U router and a Motorola SB6141 modem. IPv6 Just Works on my network. I don't remember having to do anything strange to the router to make it work, and I'm certainly still running the default firmware. -- Bill Weiss From jra at baylink.com Fri Dec 13 20:59:30 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 13 Dec 2013 15:59:30 -0500 (EST) Subject: Catalyst IOS refresher site? In-Reply-To: <52AB6D2F.5040501@brezworks.com> Message-ID: <4100472.664.1386968370819.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeremy Bresley" > Might help if you said what type of line cards and sup you've got. A > SupII era card is CatOS, SupIII and newer are IOS, command sets are > completely different, and depending on the line cards you've got, you > might have some of the really old L2 only cards (can't remember if you > could do L3 on the bastard Gig/FE cards only, or if it was dependent > on the particular Sup installed). That said, if it's an IOS Sup, I'd > start here: > http://www.cisco.com/en/US/products/hw/switches/ps4324/prod_command_reference_list.html Hmm. I wasn't smart enough to shoot a pic of the front panel, and I'm not picking it up til Monday, so I don't know. I have some background in Catalyst IOS, but it's old and on 3500-class switches, not the bigger iron. Thanks, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jlewis at lewis.org Fri Dec 13 21:59:30 2013 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 13 Dec 2013 16:59:30 -0500 (EST) Subject: do ISPs keep track of end-user IP changes within thier =?UTF-8?Q?network=3F?= In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> Message-ID: On Thu, 12 Dec 2013, Sam Moats wrote: > I'm not sure about the current state of the industry it's been a while since > I was responsible for an access network. In the past we would keep radius > logs for about 4 months, these would include the username,IP address and yes > (to date myself) the caller id of the customer at the time. We used to keep several years worth of RADIUS summary data, which included username, call end time, duration, IP, NAS-IP, ANI, and DNIS, except for where the telco wouldn't sell PRI and we had to use CT1, where those weren't available. How's that for dating? :) Want to go back a little further? http://www.lewis.org/~jlewis/modems1.jpg Rack of Sportsters, "Digicrap"[1] on top, and some Total Control USR modems on the table/overflow. [1] That's what I ended up nicknaming Digicom's rackmount modem chassis as their modems were unreliable (would repeatedly lock up requiring manual/physical resets and causing major problems for our hunt group). We eventually got them to buy it back as they were unable to resolve their problems. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cidr-report at potaroo.net Fri Dec 13 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Dec 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201312132200.rBDM002K098095@wattle.apnic.net> This report has been generated at Fri Dec 13 21:13:35 2013 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 06-12-13 485100 273979 07-12-13 485087 274164 08-12-13 485480 274089 09-12-13 484900 274506 10-12-13 485679 274553 11-12-13 485834 274460 12-12-13 485474 274478 13-12-13 485835 274579 AS Summary 45852 Number of ASes in routing system 18803 Number of ASes announcing only one prefix 4209 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118835200 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 13Dec13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 486128 274536 211592 43.5% All ASes AS28573 3434 96 3338 97.2% NET Servi?os de Comunica??o S.A. AS6389 3032 56 2976 98.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2730 204 2526 92.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4209 1735 2474 58.8% WINDSTREAM - Windstream Communications Inc AS4766 2948 960 1988 67.4% KIXS-AS-KR Korea Telecom AS22773 2302 365 1937 84.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS1785 2148 391 1757 81.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS18881 1721 31 1690 98.2% Global Village Telecom AS18566 2050 565 1485 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2953 1520 1433 48.5% TWTC - tw telecom holdings, inc. AS10620 2695 1325 1370 50.8% Telmex Colombia S.A. AS36998 1854 487 1367 73.7% SDN-MOBITEL AS7303 1738 473 1265 72.8% Telecom Argentina S.A. AS4755 1797 589 1208 67.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1205 141 1064 88.3% VIETEL-AS-AP Viettel Corporation AS22561 1253 225 1028 82.0% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1548 654 894 57.8% BSNL-NIB National Internet Backbone AS35908 919 87 832 90.5% VPLSNET - Krypt Technologies AS7545 2120 1305 815 38.4% TPG-INTERNET-AP TPG Telecom Limited AS18101 989 186 803 81.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1142 379 763 66.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1508 781 727 48.2% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS24560 1097 372 725 66.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1378 655 723 52.5% Uninet S.A. de C.V. AS6983 1292 578 714 55.3% ITCDELTA - ITC^Deltacom AS13977 855 143 712 83.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 734 57 677 92.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6147 789 113 676 85.7% Telefonica del Peru S.A.A. AS4780 1003 330 673 67.1% SEEDNET Digital United Inc. AS4788 881 209 672 76.3% TMNET-AS-AP TM Net, Internet Service Provider Total 54324 15012 39312 72.4% Top 30 total Possible Bogus Routes 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 27.100.7.0/24 AS56096 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS35916 MULTA-ASN1 - MULTACOM CORPORATION 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.114.140.0/22 AS32757 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.21.72.0/22 AS13244 103.21.75.0/24 AS13244 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 177.190.144.0/22 AS26345 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 185.43.8.0/22 AS48573 VIDNOE-AS LLC NFS Telecom 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.22.224.0/20 AS3322 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.202.8.0/21 AS3322 193.254.218.0/23 AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC 194.34.56.0/24 AS3549 GBLX Global Crossing Ltd. 194.34.56.0/25 AS3549 GBLX Global Crossing Ltd. 194.34.56.128/26 AS3549 GBLX Global Crossing Ltd. 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 195.28.168.0/23 AS8655 195.114.4.0/23 AS41158 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.23.189.0/24 AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.49.33.0/24 AS7657 VODAFONE-NZ-NGN-AS Vodafone NZ Ltd. 202.58.113.0/24 AS19161 202.59.240.0/24 AS17477 MCT-SYDNEY Macquarie Telecom 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.32.0/24 AS25617 204.9.33.0/24 AS25617 204.9.34.0/24 AS25617 204.9.35.0/24 AS25617 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.115.110.0/23 AS53709 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.120.0/22 AS32757 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 208.92.224.0/22 AS32757 208.92.226.0/24 AS32757 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Dec 13 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Dec 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201312132200.rBDM0129098109@wattle.apnic.net> BGP Update Report Interval: 05-Dec-13 -to- 12-Dec-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS701 99975 4.5% 4.6 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 2 - AS9829 51052 2.3% 62.9 -- BSNL-NIB National Internet Backbone 3 - AS8402 43636 2.0% 48.0 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS10620 29155 1.3% 12.4 -- Telmex Colombia S.A. 5 - AS13118 23428 1.1% 3346.9 -- ASN-YARTELECOM OJSC Rostelecom 6 - AS14287 20708 0.9% 3451.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 7 - AS3816 18868 0.8% 45.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 8 - AS4775 18640 0.8% 887.6 -- GLOBE-TELECOM-AS Globe Telecoms 9 - AS41691 15621 0.7% 446.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 10 - AS29990 13225 0.6% 6612.5 -- ASN-APPNEXUS - AppNexus, Inc 11 - AS28573 12771 0.6% 8.6 -- NET Servi?os de Comunica??o S.A. 12 - AS59217 12675 0.6% 12675.0 -- AZONNELIMITED-AS-AP Azonne Limited 13 - AS11976 12299 0.6% 183.6 -- FIDN - Fidelity Communication International Inc. 14 - AS6713 11683 0.5% 21.4 -- IAM-AS 15 - AS27738 11298 0.5% 19.6 -- Ecuadortelecom S.A. 16 - AS29049 11172 0.5% 36.3 -- DELTA-TELECOM-AS Delta Telecom LTD. 17 - AS7029 10906 0.5% 7.4 -- WINDSTREAM - Windstream Communications Inc 18 - AS55714 10787 0.5% 42.5 -- APNIC-FIBERLINK-PK Fiberlink Pvt.Ltd 19 - AS11597 10674 0.5% 667.1 -- MERCURY-WIRELESS - Mercury Wireless, LLC 20 - AS4538 10474 0.5% 20.3 -- ERX-CERNET-BKB China Education and Research Network Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS59217 12675 0.6% 12675.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS29990 13225 0.6% 6612.5 -- ASN-APPNEXUS - AppNexus, Inc 3 - AS54465 6181 0.3% 6181.0 -- QPM-AS-1 - QuickPlay Media Inc. 4 - AS22592 4067 0.2% 4067.0 -- HBP - HBP, Inc. 5 - AS14287 20708 0.9% 3451.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 6 - AS13118 23428 1.1% 3346.9 -- ASN-YARTELECOM OJSC Rostelecom 7 - AS60345 4677 0.2% 2338.5 -- NBITI-AS Nahjol Balagheh International Research Institution 8 - AS32244 6648 0.3% 2216.0 -- LIQUID-WEB-INC - Liquid Web, Inc. 9 - AS62431 2109 0.1% 2109.0 -- NCSC-IE-AS National Cyber Security Centre 10 - AS7202 8682 0.4% 1736.4 -- FAMU - Florida A & M University 11 - AS30437 2949 0.1% 1474.5 -- GE-MS003 - General Electric Company 12 - AS37367 1369 0.1% 1369.0 -- CALLKEY 13 - AS2 1314 0.1% 671.0 -- ASHGROUPLTD-AS-AP ASH GROUP LTD. 14 - AS37004 8623 0.4% 1231.9 -- SUBURBAN-AS 15 - AS6629 9876 0.4% 987.6 -- NOAA-AS - NOAA 16 - AS58042 1915 0.1% 957.5 -- BONCH State Educational Institution of Higher Vocational Education The Bonch-Bruevich Saint-Petersburg State University of Telecommunications 17 - AS4775 18640 0.8% 887.6 -- GLOBE-TELECOM-AS Globe Telecoms 18 - AS58499 884 0.0% 884.0 -- JPMC-AS-ID PT Jurnal Pelangi Media Cerdas 19 - AS4 2619 0.1% 591.0 -- Servidor na Web Data Center Ltda 20 - AS23295 766 0.0% 766.0 -- EA-01 - Extend America TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 23416 1.0% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.220.0/22 13213 0.6% AS29990 -- ASN-APPNEXUS - AppNexus, Inc 3 - 103.243.164.0/22 12675 0.5% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 4 - 85.249.160.0/20 12433 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 5 - 192.58.232.0/24 9832 0.4% AS6629 -- NOAA-AS - NOAA 6 - 120.28.62.0/24 9283 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 65.90.49.0/24 7299 0.3% AS3356 -- LEVEL3 Level 3 Communications 9 - 67.210.190.0/23 6340 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 10 - 206.152.15.0/24 6181 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 11 - 115.170.128.0/17 5889 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 12 - 67.210.188.0/23 5772 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 13 - 68.143.17.0/24 5392 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc 14 - 168.223.206.0/23 4340 0.2% AS7202 -- FAMU - Florida A & M University 15 - 168.223.200.0/22 4336 0.2% AS7202 -- FAMU - Florida A & M University 16 - 2.93.235.0/24 4198 0.2% AS8402 -- CORBINA-AS OJSC "Vimpelcom" 17 - 208.78.116.0/22 4142 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 18 - 199.187.118.0/24 4141 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 19 - 208.88.232.0/22 4140 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 20 - 208.73.244.0/22 4140 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 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 sam at circlenet.us Fri Dec 13 22:21:18 2013 From: sam at circlenet.us (Sam Moats) Date: Fri, 13 Dec 2013 17:21:18 -0500 Subject: do ISPs keep track of end-user IP changes within thier =?UTF-8?Q?network=3F?= In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> Message-ID: <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> I still have a soft spot for the Portmasters :-). We had rows of PM2's with US robotics 33.6K sportster modems attached on 8mm tape racks. Back when a town of 40K people could all connect through 2XT1's and everyone was happy. Sam Moats On 2013-12-13 16:59, Jon Lewis wrote: > On Thu, 12 Dec 2013, Sam Moats wrote: > >> I'm not sure about the current state of the industry it's been a >> while since I was responsible for an access network. In the past we >> would keep radius logs for about 4 months, these would include the >> username,IP address and yes (to date myself) the caller id of the >> customer at the time. > > We used to keep several years worth of RADIUS summary data, which > included username, call end time, duration, IP, NAS-IP, ANI, and > DNIS, > except for where the telco wouldn't sell PRI and we had to use CT1, > where those weren't available. How's that for dating? :) > > Want to go back a little further? > > http://www.lewis.org/~jlewis/modems1.jpg > > Rack of Sportsters, "Digicrap"[1] on top, and some Total Control USR > modems on the table/overflow. > > [1] That's what I ended up nicknaming Digicom's rackmount modem > chassis as their modems were unreliable (would repeatedly lock up > requiring manual/physical resets and causing major problems for our > hunt group). We eventually got them to buy it back as they were > unable to resolve their problems. > > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public > key_________ From mstaudinger at corp.earthlink.com Fri Dec 13 22:55:10 2013 From: mstaudinger at corp.earthlink.com (Staudinger, Malcolm) Date: Fri, 13 Dec 2013 22:55:10 +0000 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> Message-ID: I'd say in addition to just "how long", it's "how badly do you need them ". Searchable database could go back a few months while tapes usually exist for a lot longer than that. But you're not going to get the provider to dig through those unless they're under some legal obligation to do so. Malcolm -----Original Message----- From: Ray Wong [mailto:rayw at rayw.net] Sent: Thursday, December 12, 2013 12:50 AM To: Mikael Abrahamsson Cc: nanog at nanog.org Subject: Re: do ISPs keep track of end-user IP changes within thier network? been a while, but seems like lately it's more a question of how long. ISPs can be in position where they need to, but as things have consolidated, seems like they'd really like to forget it as soon as they can. If you've got a specific case in mind, likely best to find a direct contact and get a response about policy, even if it has to be off-record. The big ones (like one I likely shouldn't mention by name unless they do as I don't work for them) definitely do, at least long enough to handle DMCA requests and other legal obligations. -R> On Wed, Dec 11, 2013 at 9:36 PM, Mikael Abrahamsson wrote: > On Wed, 11 Dec 2013, Carlos Kamtha wrote: > > just a general curiousity question. it's been a long time since ive >> worked at an ISP. >> >> back then it was non-expiring DHCP leases and in some cases static IP >> for all.. (yes it was long ago..) >> >> Any feedback would be greatly appreciated.. >> > > Yes, it's very common to keep track of what user account/line had what > IP at what time. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > From mysidia at gmail.com Fri Dec 13 23:21:29 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 13 Dec 2013 17:21:29 -0600 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <20131212173436.GA11300@phobos.panopticism.net> References: <20131212035935.GG54793@ak-labs.net> <52A9DF40.2000607@rsle.net> <20131212173436.GA11300@phobos.panopticism.net> Message-ID: On Thu, Dec 12, 2013 at 11:34 AM, /dev/ph0b0s wrote: > On 12/12, R. Scott Evans wrote: > > I'm no lawyer but in the U.S., 18 USC 2703 appears to indicate this > > data must be kept for at least 180 days. > You are very mistaken. There is no requirement to retain *any* logs > (notwithstanding any orders issued by a court). > My observation would be that 18 USC 2703 appears to provide for requirements for the service provider to disclose certain records, IF the provider has the records stored. The act doesn't say they must keep the records for 180 days in the first place. The act actually appears to impose additional restrictions on records that have been in the electronic system for less than 180 days. If LESS than 180 days, then a warrant is required; if 180 days or MORE, then in some cases, an administrative procedure may be used, instead of a warrant: "that is in electronic storage in an electronic communications system for one hundred and eighty days or less, only pursuant to a warrant issued using the procedures described in the Federal Rules of Criminal Procedure" Section (f) Addresses a requirement to Preserve records, Preserve records and evidence PENDING issuance of a court order or process, SHALL retain for 90 days, extend to an additional 90-day period upon a renewed request by the government entity: " (f) Requirement To Preserve Evidence.? (1) In general.? A provider of wire or electronic communication services or a remote computing service, upon the request of a governmental entity, shall take all necessary steps to preserve records and other evidence in its possession pending the issuance of a court order or other process. (2) Period of retention.? Records referred to in paragraph (1) shall be retained for a period of 90 days, which shall be extended for an additional 90-day period upon a renewed request by the governmental entity. " -- -JH From kamtha at ak-labs.net Sat Dec 14 08:04:38 2013 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Sat, 14 Dec 2013 03:04:38 -0500 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> Message-ID: <20131214080438.GC93463@ak-labs.net> The PMs were fantastic. PM3's were pretty good as well. 2 PRIs or T1s.. 48 56k digital modems, + ISDN support.. :) Carlos. On Fri, Dec 13, 2013 at 05:21:18PM -0500, Sam Moats wrote: > I still have a soft spot for the Portmasters :-). We had rows of PM2's > with US robotics 33.6K sportster modems attached on 8mm tape racks. > Back when a town of 40K people could all connect through 2XT1's and > everyone was happy. > Sam Moats > > On 2013-12-13 16:59, Jon Lewis wrote: From ccosta at gaikai.com Fri Dec 13 03:31:13 2013 From: ccosta at gaikai.com (Christopher Costa) Date: Thu, 12 Dec 2013 19:31:13 -0800 Subject: CWDM question In-Reply-To: <52AA7CF9.3030508@citywest.ca> References: <20131213024051.18051218.93740.18135@lakelandnetworks.com> <52AA7CF9.3030508@citywest.ca> Message-ID: If you're also doing 1310 does that mean there's a splitter cable inline with the passive mux? If so, some are cheap and don't filter well outside of the 1550 band. On Dec 12, 2013 10:23 PM, "Keith" wrote: > That is whats next. They took down the whole fiber instead of just the > 1471 wave to test > which killed transit...grrr.. > > They say their tx/rx are within spec. > > Next is jumpers and sfp swaps I guess. > > Thanks. > On 12/12/2013 6:40 PM, Sam Roche wrote: > >> If you have a CWDM optical power meter and light source, see if you can >> measure the power level on the receiving end and verify that it is within >> the spec of the SFP. Maybe it is a bad jumper or port on the 1471 receive >> on their end or send on your end. >> >> If the two switches can be brought to the same location, you might also >> want to connect them together using short jumpers, but make sure you have a >> power meter to ensure you use the proper attenuators to avoid burning out >> your optics. This would rule out your fiber and mux in case it an issue >> with an appliance or SFP. I've had CWDM SFPs burn out for no apparent >> reason twice now. >> >> *From: *Keith >> *Sent: *Thursday, December 12, 2013 8:11 PM >> *To: *nanog at nanog.org >> *Subject: *CWDM question >> >> >> CWDM question >> >> Hi. >> >> We are doing a fiber link between us and another SP using CWDM. >> >> There is traffic flowing just fine at the 1310 wave, and have recently >> added a >> 1471 wave. >> >> On the 1471 wave there are some problems with it. From our perspective, >> and we >> have packet captured this, we are transmitting data to them, but they say >> they >> are not seeing anything. We are receiving from them, and while we show >> that >> packets are leaving our interface to them, they are getting nothing at >> all. >> >> There are good light levels between the two locations and do not >> understand >> why they are not seeing traffic from us even though we are sending it. >> Our packet >> counters show we are transmitting to them and receiving from them. >> >> Is it possible to have RX and TX light and things appear to be ok, but >> have the >> RX on their side fubar in some way that it is not operating correctly in >> that our >> traffic is not reaching them? >> >> Thanks. >> >> >> >> >> >> >> >> > > From frogstarr78 at gmail.com Sun Dec 15 02:56:53 2013 From: frogstarr78 at gmail.com (Scott Noel-Hemming) Date: Sat, 14 Dec 2013 18:56:53 -0800 Subject: Charter Contact Message-ID: <52AD1A75.2020403@gmail.com> Is anyone from Charter in the Walla Walla area looking for some hardware that was supposed to be delivered today? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From j at arpa.com Sun Dec 15 06:23:00 2013 From: j at arpa.com (jamie rishaw) Date: Sun, 15 Dec 2013 00:23:00 -0600 Subject: Charter Contact In-Reply-To: <52AD1A75.2020403@gmail.com> References: <52AD1A75.2020403@gmail.com> Message-ID: Uh, yea, me. I'll send you an address to forward it to. On Sat, Dec 14, 2013 at 8:56 PM, Scott Noel-Hemming wrote: > Is anyone from Charter in the Walla Walla area looking for some hardware > that was supposed to be delivered today? > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > > -- "sharp, dry wit and brash in his dealings with contestants." - Forbes If voting didn't matter, the GOP wouldn't make it more difficult than buying a gun. /* - teh jamie. ; uri -> http://about.me/jgr */ From explanoit.nanog at explanoit.com Sun Dec 15 23:10:51 2013 From: explanoit.nanog at explanoit.com (explanoit) Date: Sun, 15 Dec 2013 17:10:51 -0600 Subject: do ISPs keep track of end-user IP changes within thier =?UTF-8?Q?network=3F?= In-Reply-To: <20131212035935.GG54793@ak-labs.net> References: <20131212035935.GG54793@ak-labs.net> Message-ID: <6c93d212c6b547ddcb3164f60db17aaa@explanoit.com> Another question: I would think that the systems that keep the logs get backed up to tape, right? Wouldn't this mean the data is kept for years off-site? Do they not offsite backup the access logs ever? Regards, explanoit On 2013-12-11 21:59, Carlos Kamtha wrote: > Hi, > > just a general curiousity question. it's been a long time since ive > worked at an ISP. > > back then it was non-expiring DHCP leases and in some cases static IP > for all.. (yes it was long ago..) > > Any feedback would be greatly appreciated.. > > Carlos. From jlewis at lewis.org Mon Dec 16 16:01:35 2013 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 16 Dec 2013 11:01:35 -0500 (EST) Subject: do ISPs keep track of end-user IP changes within thier =?UTF-8?Q?network=3F?= In-Reply-To: <6c93d212c6b547ddcb3164f60db17aaa@explanoit.com> References: <20131212035935.GG54793@ak-labs.net> <6c93d212c6b547ddcb3164f60db17aaa@explanoit.com> Message-ID: On Sun, 15 Dec 2013, explanoit wrote: > Another question: > I would think that the systems that keep the logs get backed up to tape, > right? Wouldn't this mean the data is kept for years off-site? Do they not > offsite backup the access logs ever? I wouldn't assume anything like that these days. Lots of people gave up on tape for backups years ago. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Vinny_Abello at Dell.com Mon Dec 16 20:16:01 2013 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Mon, 16 Dec 2013 20:16:01 +0000 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <20131214080438.GC93463@ak-labs.net> References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> Message-ID: Dell - Internal Use - Confidential PM3's were pretty solid. PM4's, not so much. They were often problematic requiring periodic reboots of the entire chassis to keep them sane even right up through the last firmware release until Lucent killed them off in favor of their newly acquired Ascend equipment. The team that designed them were good guys. We used to work directly with them on issues and get early access to beta releases of new firmware for the PM's, including new cutting edge protocols such as K56Flex and later V.90. :) -Vinny -----Original Message----- From: Carlos Kamtha [mailto:kamtha at ak-labs.net] Sent: Saturday, December 14, 2013 3:05 AM To: sam at circlenet.us Cc: nanog at nanog.org Subject: Re: do ISPs keep track of end-user IP changes within thier network? The PMs were fantastic. PM3's were pretty good as well. 2 PRIs or T1s.. 48 56k digital modems, + ISDN support.. :) Carlos. On Fri, Dec 13, 2013 at 05:21:18PM -0500, Sam Moats wrote: > I still have a soft spot for the Portmasters :-). We had rows of PM2's > with US robotics 33.6K sportster modems attached on 8mm tape racks. > Back when a town of 40K people could all connect through 2XT1's and > everyone was happy. > Sam Moats > > On 2013-12-13 16:59, Jon Lewis wrote: From paul at paulstewart.org Mon Dec 16 21:09:56 2013 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 16 Dec 2013 16:09:56 -0500 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> Message-ID: Back in the day (geesh I feel old just saying that), I deployed a lot of PM3?s ?. Then we moved to Ascend TNT Max stuff - that was very exciting back then! :) Paul On 12/16/2013, 3:16 PM, "Vinny_Abello at Dell.com" wrote: >Dell - Internal Use - Confidential > >PM3's were pretty solid. PM4's, not so much. They were often problematic >requiring periodic reboots of the entire chassis to keep them sane even >right up through the last firmware release until Lucent killed them off >in favor of their newly acquired Ascend equipment. The team that designed >them were good guys. We used to work directly with them on issues and get >early access to beta releases of new firmware for the PM's, including new >cutting edge protocols such as K56Flex and later V.90. :) > >-Vinny > >-----Original Message----- >From: Carlos Kamtha [mailto:kamtha at ak-labs.net] >Sent: Saturday, December 14, 2013 3:05 AM >To: sam at circlenet.us >Cc: nanog at nanog.org >Subject: Re: do ISPs keep track of end-user IP changes within thier >network? > > >The PMs were fantastic. > >PM3's were pretty good as well. 2 PRIs or T1s.. 48 56k digital modems, + >ISDN support.. :) > >Carlos. > >On Fri, Dec 13, 2013 at 05:21:18PM -0500, Sam Moats wrote: >> I still have a soft spot for the Portmasters :-). We had rows of PM2's >> with US robotics 33.6K sportster modems attached on 8mm tape racks. >> Back when a town of 40K people could all connect through 2XT1's and >> everyone was happy. >> Sam Moats >> >> On 2013-12-13 16:59, Jon Lewis wrote: > From nick at flhsi.com Mon Dec 16 21:21:25 2013 From: nick at flhsi.com (Nick Olsen) Date: Mon, 16 Dec 2013 16:21:25 -0500 Subject: Telx Atlanta Message-ID: <6ad4a69$291567ce$3ef36ae4$@flhsi.com> Greetings, We're looking at getting access to the peering fabric/internet exchange in Telx's Atlanta facility. Looking for feedback from anyone willing to share their experiences with Telx, Participating in "TIE"...etc. As well as if anyone is aware of their third party cross connect policy. The sales rep told me that in order to participate in "TIE" we had to purchase colocation space for our equipment from them, Then cross connect into tie. And that purchasing space from anyone else located in the same building, or purchasing a point to point from $teir1carrier to patch us into the exchange was not possible. Even though their website clearly states "Telx will then run a cross connect to your equipment if you are located inside a Telx facility. If you need a third party cross connect, Telx will provide a Letter of Authorization and a Facility assignment for the third party." On or off list. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 From nick at foobar.org Mon Dec 16 21:22:02 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 16 Dec 2013 21:22:02 +0000 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> Message-ID: <52AF6EFA.2010706@foobar.org> On 16/12/2013 21:09, Paul Stewart wrote: > Back in the day (geesh I feel old just saying that), I deployed a lot of > PM3?s ?. Then we moved to Ascend TNT Max stuff - that was very exciting > back then! "Exciting" was just the word for Ascends. In the mid 90s, I cured lots of this excitement by putting my ascends on a socket timer which physically rebooted them a couple of times daily. The support load dropped off substantially due to that. Nick From jmcleod at musfiber.net Mon Dec 16 21:24:06 2013 From: jmcleod at musfiber.net (Joe McLeod) Date: Mon, 16 Dec 2013 21:24:06 +0000 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> Message-ID: And back in my day we were excited when we deployed the USR (eventually 3Com) Total Control access servers. Thanks, Joe -----Original Message----- From: Paul Stewart [mailto:paul at paulstewart.org] Sent: Monday, December 16, 2013 4:10 PM To: Vinny_Abello at Dell.com; kamtha at ak-labs.net; sam at circlenet.us Cc: nanog at nanog.org Subject: Re: do ISPs keep track of end-user IP changes within thier network? Back in the day (geesh I feel old just saying that), I deployed a lot of PM3?s ?. Then we moved to Ascend TNT Max stuff - that was very exciting back then! :) Paul On 12/16/2013, 3:16 PM, "Vinny_Abello at Dell.com" wrote: >Dell - Internal Use - Confidential > >PM3's were pretty solid. PM4's, not so much. They were often >problematic requiring periodic reboots of the entire chassis to keep >them sane even right up through the last firmware release until Lucent >killed them off in favor of their newly acquired Ascend equipment. The >team that designed them were good guys. We used to work directly with >them on issues and get early access to beta releases of new firmware >for the PM's, including new cutting edge protocols such as K56Flex and >later V.90. :) > >-Vinny > >-----Original Message----- >From: Carlos Kamtha [mailto:kamtha at ak-labs.net] >Sent: Saturday, December 14, 2013 3:05 AM >To: sam at circlenet.us >Cc: nanog at nanog.org >Subject: Re: do ISPs keep track of end-user IP changes within thier >network? > > >The PMs were fantastic. > >PM3's were pretty good as well. 2 PRIs or T1s.. 48 56k digital modems, >+ ISDN support.. :) > >Carlos. > >On Fri, Dec 13, 2013 at 05:21:18PM -0500, Sam Moats wrote: >> I still have a soft spot for the Portmasters :-). We had rows of >> PM2's with US robotics 33.6K sportster modems attached on 8mm tape racks. >> Back when a town of 40K people could all connect through 2XT1's and >> everyone was happy. >> Sam Moats >> >> On 2013-12-13 16:59, Jon Lewis wrote: > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From akennykant at gmail.com Mon Dec 16 21:44:59 2013 From: akennykant at gmail.com (Kenny Kant) Date: Mon, 16 Dec 2013 15:44:59 -0600 Subject: AS209 / Qwest / CenturyLink Message-ID: Could someone from Qwest/CenturyLink AS209 contact me off list. We have two prefixes which are incorrectly being announced from this AS. I'm sure its an old configuration from days gone by. If there is a better / correct procedure to request help for this please let me know. Thanks! Kenny From Vinny_Abello at Dell.com Tue Dec 17 14:44:33 2013 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Tue, 17 Dec 2013 14:44:33 +0000 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <52AF6EFA.2010706@foobar.org> References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> <52AF6EFA.2010706@foobar.org> Message-ID: Dell - Internal Use - Confidential I personally never ran the Ascend gear (outside of a setting up a customer's Ascend Superpipe 95 dual ISDN router one time), but I heard that the TNT gear doubled as space heaters. I remember one facility we were in that had a catastrophic cooling failure and the temperatures went to insane levels. Our PM3's happily kept running and never had an issue where I heard every TNT box in the facility kept rebooting and crashing. -Vinny -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Monday, December 16, 2013 4:22 PM To: Paul Stewart Cc: nanog at nanog.org Subject: Re: do ISPs keep track of end-user IP changes within thier network? On 16/12/2013 21:09, Paul Stewart wrote: > Back in the day (geesh I feel old just saying that), I deployed a lot of > PM3?s ?. Then we moved to Ascend TNT Max stuff - that was very exciting > back then! "Exciting" was just the word for Ascends. In the mid 90s, I cured lots of this excitement by putting my ascends on a socket timer which physically rebooted them a couple of times daily. The support load dropped off substantially due to that. Nick From ikiris at gmail.com Tue Dec 17 14:54:15 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 17 Dec 2013 08:54:15 -0600 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> <52AF6EFA.2010706@foobar.org> Message-ID: All I remember from the TNT days is the meltdown when Code Red happened. Why exactly an access platform should melt down when a worm occurs still bothers me. -Blake On Tue, Dec 17, 2013 at 8:44 AM, wrote: > Dell - Internal Use - Confidential > > I personally never ran the Ascend gear (outside of a setting up a > customer's Ascend Superpipe 95 dual ISDN router one time), but I heard that > the TNT gear doubled as space heaters. I remember one facility we were in > that had a catastrophic cooling failure and the temperatures went to insane > levels. Our PM3's happily kept running and never had an issue where I heard > every TNT box in the facility kept rebooting and crashing. > > -Vinny > > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Monday, December 16, 2013 4:22 PM > To: Paul Stewart > Cc: nanog at nanog.org > Subject: Re: do ISPs keep track of end-user IP changes within thier > network? > > On 16/12/2013 21:09, Paul Stewart wrote: > > Back in the day (geesh I feel old just saying that), I deployed a lot of > > PM3?s ?. Then we moved to Ascend TNT Max stuff - that was very exciting > > back then! > > "Exciting" was just the word for Ascends. In the mid 90s, I cured lots of > this excitement by putting my ascends on a socket timer which physically > rebooted them a couple of times daily. The support load dropped off > substantially due to that. > > Nick > > From sam at circlenet.us Tue Dec 17 14:56:15 2013 From: sam at circlenet.us (Sam Moats) Date: Tue, 17 Dec 2013 09:56:15 -0500 Subject: do ISPs keep track of end-user IP changes within thier =?UTF-8?Q?network=3F?= In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> <52AF6EFA.2010706@foobar.org> Message-ID: <369c724bec77443a8939cd5e29d2d563@www.circlenet.us> That's the day we decided we needed better edge routers :-).. I watch a modem pool infected with code red melt a cisco 3640. Had to throw a Linux box in it's place while I waited for Cisco equipment. Sam Moats On 2013-12-17 09:54, Blake Dunlap wrote: > All I remember from the TNT days is the meltdown when Code Red > happened. > Why exactly an access platform should melt down when a worm occurs > still > bothers me. > > -Blake > > > On Tue, Dec 17, 2013 at 8:44 AM, wrote: > >> Dell - Internal Use - Confidential >> >> I personally never ran the Ascend gear (outside of a setting up a >> customer's Ascend Superpipe 95 dual ISDN router one time), but I >> heard that >> the TNT gear doubled as space heaters. I remember one facility we >> were in >> that had a catastrophic cooling failure and the temperatures went to >> insane >> levels. Our PM3's happily kept running and never had an issue where >> I heard >> every TNT box in the facility kept rebooting and crashing. >> >> -Vinny >> >> -----Original Message----- >> From: Nick Hilliard [mailto:nick at foobar.org] >> Sent: Monday, December 16, 2013 4:22 PM >> To: Paul Stewart >> Cc: nanog at nanog.org >> Subject: Re: do ISPs keep track of end-user IP changes within thier >> network? >> >> On 16/12/2013 21:09, Paul Stewart wrote: >> > Back in the day (geesh I feel old just saying that), I deployed a >> lot of >> > PM3?s ?. Then we moved to Ascend TNT Max stuff - that was very >> exciting >> > back then! >> >> "Exciting" was just the word for Ascends. In the mid 90s, I cured >> lots of >> this excitement by putting my ascends on a socket timer which >> physically >> rebooted them a couple of times daily. The support load dropped off >> substantially due to that. >> >> Nick >> >> From alex at corp.nac.net Tue Dec 17 15:06:06 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 17 Dec 2013 10:06:06 -0500 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> <52AF6EFA.2010706@foobar.org> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB8330B3B8169@EXCHMBX.hq.nac.net> We had gear in the MFS Colo in Whippany, NJ. We had a couple routers (2501's and a 4700M), a couple PM3's, and some other crap. Near us were TNT's and Total Controls from ANS (remember them??). Yeah, it got warm in there, especially when the single 10 ton AC unit failed (about every other day). But, it was way more fun back then. > -----Original Message----- > From: Vinny_Abello at Dell.com [mailto:Vinny_Abello at Dell.com] > > Dell - Internal Use - Confidential > > I personally never ran the Ascend gear (outside of a setting up a customer's > Ascend Superpipe 95 dual ISDN router one time), but I heard that the TNT > gear doubled as space heaters. I remember one facility we were in that had a > catastrophic cooling failure and the temperatures went to insane levels. Our > PM3's happily kept running and never had an issue where I heard every TNT > box in the facility kept rebooting and crashing. > > -Vinny From Valdis.Kletnieks at vt.edu Tue Dec 17 18:37:32 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 17 Dec 2013 13:37:32 -0500 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: Your message of "Tue, 17 Dec 2013 08:54:15 -0600." References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> <52AF6EFA.2010706@foobar.org> Message-ID: <10888.1387305452@turing-police.cc.vt.edu> On Tue, 17 Dec 2013 08:54:15 -0600, Blake Dunlap said: > All I remember from the TNT days is the meltdown when Code Red happened. > Why exactly an access platform should melt down when a worm occurs still > bothers me. Have we gotten any better at control plane meltdown when somebody starts poking lots of multicast addresses per second? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From nick at foobar.org Wed Dec 18 09:41:42 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 18 Dec 2013 09:41:42 +0000 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: <10888.1387305452@turing-police.cc.vt.edu> References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> <52AF6EFA.2010706@foobar.org> <10888.1387305452@turing-police.cc.vt.edu> Message-ID: <52B16DD6.30704@foobar.org> On 17/12/2013 18:37, Valdis.Kletnieks at vt.edu wrote: > Have we gotten any better at control plane meltdown when somebody starts > poking lots of multicast addresses per second? no, a point entirely lost on the vxlan clergy. Nick From matlockken at gmail.com Tue Dec 17 15:05:04 2013 From: matlockken at gmail.com (Ken Matlock) Date: Tue, 17 Dec 2013 08:05:04 -0700 Subject: do ISPs keep track of end-user IP changes within thier network? In-Reply-To: References: <20131212035935.GG54793@ak-labs.net> <7b9f19b3810b26c669acf57189b0a8fe@www.circlenet.us> <20131214080438.GC93463@ak-labs.net> <52AF6EFA.2010706@foobar.org> Message-ID: Wait, you mean to say that the normal mode for TNT's was it *not* to reboot and crash all the time? :) Ascend tech support's stock answer to any issue was either 1) Upgrade the code 2) Oh, you already tried that? downgrade the code! :) And the company that managed to put out a release to 'fix a spelling error' that managed to completely break all IP routing? :) (Yes, I loved the PM2/PM3's) Ken On Tue, Dec 17, 2013 at 7:44 AM, wrote: > Dell - Internal Use - Confidential > > I personally never ran the Ascend gear (outside of a setting up a > customer's Ascend Superpipe 95 dual ISDN router one time), but I heard that > the TNT gear doubled as space heaters. I remember one facility we were in > that had a catastrophic cooling failure and the temperatures went to insane > levels. Our PM3's happily kept running and never had an issue where I heard > every TNT box in the facility kept rebooting and crashing. > > -Vinny > > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Monday, December 16, 2013 4:22 PM > To: Paul Stewart > Cc: nanog at nanog.org > Subject: Re: do ISPs keep track of end-user IP changes within thier > network? > > On 16/12/2013 21:09, Paul Stewart wrote: > > Back in the day (geesh I feel old just saying that), I deployed a lot of > > PM3?s ?. Then we moved to Ascend TNT Max stuff - that was very exciting > > back then! > > "Exciting" was just the word for Ascends. In the mid 90s, I cured lots of > this excitement by putting my ascends on a socket timer which physically > rebooted them a couple of times daily. The support load dropped off > substantially due to that. > > Nick > > From source_route at yahoo.com Wed Dec 18 15:48:27 2013 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 18 Dec 2013 07:48:27 -0800 (PST) Subject: BGP from Juniper to Cisco ASR Message-ID: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor? active 2/5 (authentication failure) 0 bytes Dec 18 15:46:33.615: BGP: ses global? (0x7FB1CD209CF0:0) act Receive NOTIFICATION 2/5 (authentication failure) 0 bytes Although I have seem this on the message boards I am little confused in that the ISP is telling me that there is no authentication enabled on the Juniper and I do not have authentication enabled on the ASR. So what is going on here? From sbrilus at blueyonder.co.uk Wed Dec 18 16:07:06 2013 From: sbrilus at blueyonder.co.uk (Simon Brilus) Date: Wed, 18 Dec 2013 16:07:06 -0000 Subject: Watchguards vs Junipers firewalls Message-ID: <00fb01cefc0b$57cdfbc0$0769f340$@blueyonder.co.uk> Hi all - Has anyone out there had experience of running these firewalls near 1Gig speeds (mainly middle to large packets, not voice) between zones/ports, if possible Specifically we are looking at the Watchguard XTM535 and the Juniper SRX550/600's. I am interested in experiences good and bad on either platforms and usage of IDP/Weblocker etc on them. We currently use SRX240 and Watchguard 1250e but have a need to increase the throughput to nearly 1Gig. Other criteria would be to be to do OSPF/BGP in high availability mode Many thanks Simon From cliff.bowles at apollogrp.edu Wed Dec 18 16:11:46 2013 From: cliff.bowles at apollogrp.edu (Cliff Bowles) Date: Wed, 18 Dec 2013 09:11:46 -0700 Subject: IPv6 /48 advertisements Message-ID: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> I accidentally sent this to nanog-request yesterday. I could use some feedback from anyone that can help, please. Question: will carriers accept IPv6 advertisements smaller than /48? Our org was approved a /36 based on number of locations. The bulk of those IPs will be in the data centers. As we were chopping up the address space, it was determined that the remote campus locations would be fine with a /60 per site. (16 networks of /64). There are usually less than 50 people at the majority of these locations and only about 10 different functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, etc...). Now, there has been talk about putting an internet link in every campus rather than back hauling it all to the data centers via MPLS. However, if we do this, then would we need a /48 per campus? That is massively wasteful, at 65,536 networks per location. Is the /48 requirement set in stone? Will any carriers consider longer prefixes? I know some people are always saying that the old mentality of conserving space needs to go away, but I was bitten by that IPv4 issue back in the day and have done a few VLSM network overhauls. I'd rather not massively allocate unless it's a requirement. Thanks in advance. CWB ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From source_route at yahoo.com Wed Dec 18 16:16:05 2013 From: source_route at yahoo.com (Philip Lavine) Date: Wed, 18 Dec 2013 08:16:05 -0800 (PST) Subject: BGP from Juniper to Cisco ASR In-Reply-To: <656AAF5E8566DF47835F38F66FA8213A15E4773E@ZF-EXC1.Pre2Post.local> References: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> <656AAF5E8566DF47835F38F66FA8213A15E4773E@ZF-EXC1.Pre2Post.local> Message-ID: <1387383365.95133.YahooMailNeo@web122502.mail.ne1.yahoo.com> yes I tried ?multihop even though my peer is on the same /29 On Wednesday, December 18, 2013 8:10 AM, Eric Dugas wrote: Probably a TTL problem. Did you configure ebgp-multihop? Eric Dugas ZEROFAIL / AS40191 edugas at zerofail.com -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: December 18, 2013 10:48 AM To: NANOG list Subject: BGP from Juniper to Cisco ASR Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor? active 2/5 (authentication failure) 0 bytes Dec 18 15:46:33.615: BGP: ses global? (0x7FB1CD209CF0:0) act Receive NOTIFICATION 2/5 (authentication failure) 0 bytes Although I have seem this on the message boards I am little confused in that the ISP is telling me that there is no authentication enabled on the Juniper and I do not have authentication enabled on the ASR. So what is going on here? From cra at WPI.EDU Wed Dec 18 16:16:56 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 18 Dec 2013 11:16:56 -0500 Subject: IPv6 /48 advertisements In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: <20131218161655.GD10689@angus.ind.WPI.EDU> On Wed, Dec 18, 2013 at 09:11:46AM -0700, Cliff Bowles wrote: > Question: will carriers accept IPv6 advertisements smaller than /48? Not generally, no. > Our org was approved a /36 based on number of locations. The bulk of > those IPs will be in the data centers. As we were chopping up the > address space, it was determined that the remote campus locations > would be fine with a /60 per site. (16 networks of /64). There are > usually less than 50 people at the majority of these locations and > only about 10 different functional VLANs (Voice, Data, Local > Services, Wireless, Guest Wireless, etc...). > > Now, there has been talk about putting an internet link in every > campus rather than back hauling it all to the data centers via > MPLS. However, if we do this, then would we need a /48 per campus? > That is massively wasteful, at 65,536 networks per location. Is the > /48 requirement set in stone? Will any carriers consider longer > prefixes? /48 per site is the standard. > I know some people are always saying that the old mentality of > conserving space needs to go away, but I was bitten by that IPv4 > issue back in the day and have done a few VLSM network > overhauls. I'd rather not massively allocate unless it's a > requirement. You need to throw out all old thinking in terms of what happened in IPv4. Current ARIN policy allows a /48 per site and that is how you should architect the network. From edward.dore at freethought-internet.co.uk Wed Dec 18 16:22:20 2013 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Wed, 18 Dec 2013 16:22:20 +0000 Subject: IPv6 /48 advertisements In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: If you?re talking about announcing each location separately, then RIPE have a couple of useful articles about prefix visibility on Ripe Labs: https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths Otherwise I guess you?ll need to talk to your chosen carrier(s) about aggregating your space for you, which will come down to their policies on what routes they will carry internally. Edward Dore Freethought Internet On 18 Dec 2013, at 16:11, Cliff Bowles wrote: > I accidentally sent this to nanog-request yesterday. I could use some feedback from anyone that can help, please. > > Question: will carriers accept IPv6 advertisements smaller than /48? > > Our org was approved a /36 based on number of locations. The bulk of those IPs will be in the data centers. As we were chopping up the address space, it was determined that the remote campus locations would be fine with a /60 per site. (16 networks of /64). There are usually less than 50 people at the majority of these locations and only about 10 different functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, etc...). > > Now, there has been talk about putting an internet link in every campus rather than back hauling it all to the data centers via MPLS. However, if we do this, then would we need a /48 per campus? That is massively wasteful, at 65,536 networks per location. Is the /48 requirement set in stone? Will any carriers consider longer prefixes? > > I know some people are always saying that the old mentality of conserving space needs to go away, but I was bitten by that IPv4 issue back in the day and have done a few VLSM network overhauls. I'd rather not massively allocate unless it's a requirement. > > Thanks in advance. > > CWB > > > > > ________________________________ > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. > From ikiris at gmail.com Wed Dec 18 16:32:16 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 18 Dec 2013 10:32:16 -0600 Subject: IPv6 /48 advertisements In-Reply-To: References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: Regardless of the carriers, you'll find most ASs on the internet only listen to /48 or larger. So even if you get your prefixes accepted by your provider, don't assume you can get anywhere, or have your packets not fall in to uRPF blackholes randomly without a larger aggregate announcement. -Blake On Wed, Dec 18, 2013 at 10:22 AM, Edward Dore < edward.dore at freethought-internet.co.uk> wrote: > If you?re talking about announcing each location separately, then RIPE > have a couple of useful articles about prefix visibility on Ripe Labs: > > > https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering > https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths > > Otherwise I guess you?ll need to talk to your chosen carrier(s) about > aggregating your space for you, which will come down to their policies on > what routes they will carry internally. > > Edward Dore > Freethought Internet > > On 18 Dec 2013, at 16:11, Cliff Bowles wrote: > > > I accidentally sent this to nanog-request yesterday. I could use some > feedback from anyone that can help, please. > > > > Question: will carriers accept IPv6 advertisements smaller than /48? > > > > Our org was approved a /36 based on number of locations. The bulk of > those IPs will be in the data centers. As we were chopping up the address > space, it was determined that the remote campus locations would be fine > with a /60 per site. (16 networks of /64). There are usually less than 50 > people at the majority of these locations and only about 10 different > functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, > etc...). > > > > Now, there has been talk about putting an internet link in every campus > rather than back hauling it all to the data centers via MPLS. However, if > we do this, then would we need a /48 per campus? That is massively > wasteful, at 65,536 networks per location. Is the /48 requirement set in > stone? Will any carriers consider longer prefixes? > > > > I know some people are always saying that the old mentality of > conserving space needs to go away, but I was bitten by that IPv4 issue back > in the day and have done a few VLSM network overhauls. I'd rather not > massively allocate unless it's a requirement. > > > > Thanks in advance. > > > > CWB > > > > > > > > > > ________________________________ > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > > > > From laszlo at heliacal.net Wed Dec 18 16:36:39 2013 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 18 Dec 2013 16:36:39 +0000 Subject: IPv6 /48 advertisements In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: <274E2045-0985-4AFE-A0B7-873DC6DFE30D@heliacal.net> It's standard to filter out anything longer than /48. Your /36 prefix was chosen based on the number of sites, with a /48 per site, so just keep it simple. Trying to manage it in the way IPv4 addresses were managed will just ensure that you will have the same headaches of micro managing sub allocations and trying to guess the right sizes. The address space in V6 is large enough that you don't have to spend your time worrying about this, and that's one of the reasons for using a /48 at each site. Think of an IPv6 /48 like you would think of an IPv4 /24 - except that it's the right size for either your house or your university campus. Laszlo On Dec 18, 2013, at 4:11 PM, Cliff Bowles wrote: > I accidentally sent this to nanog-request yesterday. I could use some feedback from anyone that can help, please. > > Question: will carriers accept IPv6 advertisements smaller than /48? > > Our org was approved a /36 based on number of locations. The bulk of those IPs will be in the data centers. As we were chopping up the address space, it was determined that the remote campus locations would be fine with a /60 per site. (16 networks of /64). There are usually less than 50 people at the majority of these locations and only about 10 different functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, etc...). > > Now, there has been talk about putting an internet link in every campus rather than back hauling it all to the data centers via MPLS. However, if we do this, then would we need a /48 per campus? That is massively wasteful, at 65,536 networks per location. Is the /48 requirement set in stone? Will any carriers consider longer prefixes? > > I know some people are always saying that the old mentality of conserving space needs to go away, but I was bitten by that IPv4 issue back in the day and have done a few VLSM network overhauls. I'd rather not massively allocate unless it's a requirement. > > Thanks in advance. > > CWB > > > > > ________________________________ > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. > From dwhite at olp.net Wed Dec 18 16:36:50 2013 From: dwhite at olp.net (Dan White) Date: Wed, 18 Dec 2013 10:36:50 -0600 Subject: ddos attacks In-Reply-To: <6613b77386ec3b13ce249100d02290c2@mail.gmail.com> References: <6613b77386ec3b13ce249100d02290c2@mail.gmail.com> Message-ID: <20131218163650.GC6045@dan.olp.net> Can anyone recommend a vendor solution for DDOS mitigation? We are looking for a solution that detects DDOS attacks from sflow information and automatically announces BGP /32 blackhole routes to our upstream providers, or a similar solution. Thank You. On 08/05/13?21:09?+1000, Ahad Aboss wrote: >Scott, > >Use a DDOS detection and mitigation system with DPI capabilities to deal >with traditional DDOS attack and anomalous behaviour such as worm >propagation, botnet attacks and malicious subscriber activity such as >flooding and probing. There are only a few vendors who successfully play in >this space who provide a self healing/self defending system. > >Cheers >Ahad >-----Original Message----- >From: sgraun at airstreamcomm.net [mailto:sgraun at airstreamcomm.net] >Sent: Friday, 2 August 2013 11:37 PM >To: nanog at nanog.org >Subject: ddos attacks > >I?m curious to know what other service providers are doing to >alleviate/prevent ddos attacks from happening in your network. Are you >completely reactive and block as many addresses as possible or null0 traffic >to the effected host until it stops or do you block certain ports to prevent >them. What?s the best way people are dealing with them? > >Scott -- Dan White From streiner at cluebyfour.org Wed Dec 18 13:10:07 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 18 Dec 2013 08:10:07 -0500 (EST) Subject: IPv6 /48 advertisements In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: On Wed, 18 Dec 2013, Cliff Bowles wrote: > Question: will carriers accept IPv6 advertisements smaller than /48? Most of the carriers I've seen won't accept anything smaller than /48. You have 4096 /48s to use in your /36. The bigger concern for carriers/ISPs is IPv6 routing table bloat from carrying lots of small individual advertisements. jms From cliff.bowles at apollogrp.edu Wed Dec 18 16:40:34 2013 From: cliff.bowles at apollogrp.edu (Cliff Bowles) Date: Wed, 18 Dec 2013 09:40:34 -0700 Subject: IPv6 /48 advertisements In-Reply-To: References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B4EC@EXCH07-01.apollogrp.edu> I had a feeling... thanks for the feedback. CWB From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Wednesday, December 18, 2013 9:32 AM To: Edward Dore Cc: Cliff Bowles; nanog at nanog.org Subject: Re: IPv6 /48 advertisements Regardless of the carriers, you'll find most ASs on the internet only listen to /48 or larger. So even if you get your prefixes accepted by your provider, don't assume you can get anywhere, or have your packets not fall in to uRPF blackholes randomly without a larger aggregate announcement. -Blake On Wed, Dec 18, 2013 at 10:22 AM, Edward Dore > wrote: If you're talking about announcing each location separately, then RIPE have a couple of useful articles about prefix visibility on Ripe Labs: https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths Otherwise I guess you'll need to talk to your chosen carrier(s) about aggregating your space for you, which will come down to their policies on what routes they will carry internally. Edward Dore Freethought Internet On 18 Dec 2013, at 16:11, Cliff Bowles > wrote: > I accidentally sent this to nanog-request yesterday. I could use some feedback from anyone that can help, please. > > Question: will carriers accept IPv6 advertisements smaller than /48? > > Our org was approved a /36 based on number of locations. The bulk of those IPs will be in the data centers. As we were chopping up the address space, it was determined that the remote campus locations would be fine with a /60 per site. (16 networks of /64). There are usually less than 50 people at the majority of these locations and only about 10 different functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, etc...). > > Now, there has been talk about putting an internet link in every campus rather than back hauling it all to the data centers via MPLS. However, if we do this, then would we need a /48 per campus? That is massively wasteful, at 65,536 networks per location. Is the /48 requirement set in stone? Will any carriers consider longer prefixes? > > I know some people are always saying that the old mentality of conserving space needs to go away, but I was bitten by that IPv4 issue back in the day and have done a few VLSM network overhauls. I'd rather not massively allocate unless it's a requirement. > > Thanks in advance. > > CWB > > > > > ________________________________ > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. > ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From jeroen at massar.ch Wed Dec 18 16:41:55 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 18 Dec 2013 17:41:55 +0100 Subject: IPv6 /48 advertisements In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: <52B1D053.50509@massar.ch> On 2013-12-18 17:11 , Cliff Bowles wrote: > I accidentally sent this to nanog-request yesterday. I could use some feedback from anyone that can help, please. > > Question: will carriers accept IPv6 advertisements smaller than /48? > > Our org was approved a /36 based on number of locations. In GRH (http://www.sixxs.net/tools/grh/) I only see 2620:0:5030::/48, thus did you get another/new/updated one very recently? Note that there are quite a few ISPs who filter on the assigned prefix length, especially for PA address space which should be Aggregated by the Provider (PA). Likely your space comes out of one of the PI blocks, in which case rules tend to be a bit more lax, hence a /48 should get through. Do note that at one point or another there will be ISPs/networks that are going to hit their prefix table sizes on their hardware. These will start filtering aggressively on the assigned prefixes. Greets, Jeroen From moreiras at nic.br Wed Dec 18 16:53:28 2013 From: moreiras at nic.br (Antonio M. Moreiras) Date: Wed, 18 Dec 2013 14:53:28 -0200 Subject: IPv6 /48 advertisements In-Reply-To: References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: <52B1D308.7070206@nic.br> What do you recommend to an end user that have a direct assignment of a /48, and would like to disaggregate as part of a traffic engineering strategy? Moreiras. On 18/12/13 14:32, Blake Dunlap wrote: > Regardless of the carriers, you'll find most ASs on the internet only > listen to /48 or larger. So even if you get your prefixes accepted by your > provider, don't assume you can get anywhere, or have your packets not fall > in to uRPF blackholes randomly without a larger aggregate announcement. > > -Blake > > > On Wed, Dec 18, 2013 at 10:22 AM, Edward Dore < > edward.dore at freethought-internet.co.uk> wrote: > >> If you?re talking about announcing each location separately, then RIPE >> have a couple of useful articles about prefix visibility on Ripe Labs: >> >> >> https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering >> https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths >> >> Otherwise I guess you?ll need to talk to your chosen carrier(s) about >> aggregating your space for you, which will come down to their policies on >> what routes they will carry internally. >> >> Edward Dore >> Freethought Internet >> >> On 18 Dec 2013, at 16:11, Cliff Bowles wrote: >> >>> I accidentally sent this to nanog-request yesterday. I could use some >> feedback from anyone that can help, please. >>> >>> Question: will carriers accept IPv6 advertisements smaller than /48? >>> >>> Our org was approved a /36 based on number of locations. The bulk of >> those IPs will be in the data centers. As we were chopping up the address >> space, it was determined that the remote campus locations would be fine >> with a /60 per site. (16 networks of /64). There are usually less than 50 >> people at the majority of these locations and only about 10 different >> functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, >> etc...). >>> >>> Now, there has been talk about putting an internet link in every campus >> rather than back hauling it all to the data centers via MPLS. However, if >> we do this, then would we need a /48 per campus? That is massively >> wasteful, at 65,536 networks per location. Is the /48 requirement set in >> stone? Will any carriers consider longer prefixes? >>> >>> I know some people are always saying that the old mentality of >> conserving space needs to go away, but I was bitten by that IPv4 issue back >> in the day and have done a few VLSM network overhauls. I'd rather not >> massively allocate unless it's a requirement. >>> >>> Thanks in advance. >>> >>> CWB >>> >>> >>> >>> >>> ________________________________ >>> This message is private and confidential. If you have received it in >> error, please notify the sender and remove it from your system. >>> From ikiris at gmail.com Wed Dec 18 17:19:01 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 18 Dec 2013 11:19:01 -0600 Subject: IPv6 /48 advertisements In-Reply-To: <52B1D308.7070206@nic.br> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> <52B1D308.7070206@nic.br> Message-ID: Your TE is not the rest of the world's routing slot's problem. Get more circuits and do your te with your providers directly. -Blake On Dec 18, 2013 10:57 AM, "Antonio M. Moreiras" wrote: > What do you recommend to an end user that have a direct assignment of a > /48, and would like to disaggregate as part of a traffic engineering > strategy? > > Moreiras. > > On 18/12/13 14:32, Blake Dunlap wrote: > > Regardless of the carriers, you'll find most ASs on the internet only > > listen to /48 or larger. So even if you get your prefixes accepted by > your > > provider, don't assume you can get anywhere, or have your packets not > fall > > in to uRPF blackholes randomly without a larger aggregate announcement. > > > > -Blake > > > > > > On Wed, Dec 18, 2013 at 10:22 AM, Edward Dore < > > edward.dore at freethought-internet.co.uk> wrote: > > > >> If you?re talking about announcing each location separately, then RIPE > >> have a couple of useful articles about prefix visibility on Ripe Labs: > >> > >> > >> > https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering > >> https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths > >> > >> Otherwise I guess you?ll need to talk to your chosen carrier(s) about > >> aggregating your space for you, which will come down to their policies > on > >> what routes they will carry internally. > >> > >> Edward Dore > >> Freethought Internet > >> > >> On 18 Dec 2013, at 16:11, Cliff Bowles > wrote: > >> > >>> I accidentally sent this to nanog-request yesterday. I could use some > >> feedback from anyone that can help, please. > >>> > >>> Question: will carriers accept IPv6 advertisements smaller than /48? > >>> > >>> Our org was approved a /36 based on number of locations. The bulk of > >> those IPs will be in the data centers. As we were chopping up the > address > >> space, it was determined that the remote campus locations would be fine > >> with a /60 per site. (16 networks of /64). There are usually less than > 50 > >> people at the majority of these locations and only about 10 different > >> functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, > >> etc...). > >>> > >>> Now, there has been talk about putting an internet link in every campus > >> rather than back hauling it all to the data centers via MPLS. However, > if > >> we do this, then would we need a /48 per campus? That is massively > >> wasteful, at 65,536 networks per location. Is the /48 requirement set > in > >> stone? Will any carriers consider longer prefixes? > >>> > >>> I know some people are always saying that the old mentality of > >> conserving space needs to go away, but I was bitten by that IPv4 issue > back > >> in the day and have done a few VLSM network overhauls. I'd rather not > >> massively allocate unless it's a requirement. > >>> > >>> Thanks in advance. > >>> > >>> CWB > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> This message is private and confidential. If you have received it in > >> error, please notify the sender and remove it from your system. > >>> > > From pmsac.nanog at gmail.com Wed Dec 18 17:54:22 2013 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Wed, 18 Dec 2013 17:54:22 +0000 Subject: BGP from Juniper to Cisco ASR In-Reply-To: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> References: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> Message-ID: On 18 December 2013 15:48, Philip Lavine wrote: > Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor > active 2/5 (authentication failure) 0 bytes > Dec 18 15:46:33.615: BGP: ses global (0x7FB1CD209CF0:0) act > Receive NOTIFICATION 2/5 (authentication failure) 0 bytes > Although I have seem this on the message boards I am little confused in > that the ISP is telling me that there is no authentication enabled on the > Juniper and I do not have authentication enabled on the ASR. So what is > going on here? > That's an error during the Open phase, so it can't be related to any MD5 authentication configuration - which is absent, as you say so yourself. Make sure you're trying to initiate the BGP session from the right IP address (eventually needing to use "neighbor X update-source ") and that their configuration matches your address correctly (i.e., they have the right address on your side, without any typos on their configuration). It probably wouldn't hurt to confirm they have your peering session configured as "type external". HTH. From tritran at cox.net Wed Dec 18 18:14:44 2013 From: tritran at cox.net (Tri Tran) Date: Wed, 18 Dec 2013 10:14:44 -0800 Subject: wireless ISP in Santa Fe Message-ID: <52B1E614.5020802@cox.net> The only known option is with Cibola for 7M/1M. If anyone know of an alternate provider with higher bandwidth please advise. --Tri Tran From brandon.galbraith at gmail.com Wed Dec 18 18:22:14 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 18 Dec 2013 12:22:14 -0600 Subject: wireless ISP in Santa Fe In-Reply-To: <52B1E614.5020802@cox.net> References: <52B1E614.5020802@cox.net> Message-ID: Have you talked to Cybermesa[1] or LC Wireless (co-op)[2]? [1] http://www.cybermesa.com/ [2] http://www.lcwireless.us/ On Wed, Dec 18, 2013 at 12:14 PM, Tri Tran wrote: > The only known option is with Cibola for 7M/1M. > If anyone know of an alternate provider with higher bandwidth please > advise. > > --Tri Tran > > > From tritran at cox.net Wed Dec 18 18:31:03 2013 From: tritran at cox.net (Tri Tran) Date: Wed, 18 Dec 2013 10:31:03 -0800 Subject: wireless ISP in Santa Fe In-Reply-To: <36NC1n02M176vVM016NEe3> References: <52B1E614.5020802@cox.net> <36NC1n02M176vVM016NEe3> Message-ID: <52B1E9E7.1070800@cox.net> Thanks Brandon. I'll give them a call. On 12/18/2013 10:22 AM, Brandon Galbraith wrote: > Have you talked to Cybermesa[1] or LC Wireless (co-op)[2]? > > [1] http://www.cybermesa.com/ > > [2] http://www.lcwireless.us/ > > > On Wed, Dec 18, 2013 at 12:14 PM, Tri Tran > wrote: > > The only known option is with Cibola for 7M/1M. > If anyone know of an alternate provider with higher bandwidth > please advise. > > --Tri Tran > > > --Tri Tran From dmburgess at linktechs.net Wed Dec 18 18:57:55 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Wed, 18 Dec 2013 12:57:55 -0600 Subject: wireless ISP in Santa Fe References: <52B1E614.5020802@cox.net> Message-ID: <50710E9A7E64454C974049FC998EB655018DDC14@03-exchange.lti.local> You can hit http://www.towercoverage.com and click on north American map to see what may be in that area... contact numbers and e-mail addresses are provided. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? ?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? ?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? ?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? -----Original Message----- From: Tri Tran [mailto:tritran at cox.net] Sent: Wednesday, December 18, 2013 12:15 PM To: nanog at nanog.org Subject: wireless ISP in Santa Fe The only known option is with Cibola for 7M/1M. If anyone know of an alternate provider with higher bandwidth please advise. --Tri Tran From owen at delong.com Wed Dec 18 19:06:58 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Dec 2013 11:06:58 -0800 Subject: IPv6 /48 advertisements In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: <90016801-9EA1-4D33-93C4-A49EF782EC49@delong.com> On Dec 18, 2013, at 08:11 , Cliff Bowles wrote: > I accidentally sent this to nanog-request yesterday. I could use some feedback from anyone that can help, please. > > Question: will carriers accept IPv6 advertisements smaller than /48? Generally, no. Since a /48 should represent nothing larger than a single site, it's not very reasonable to want to route something longer in general. > Our org was approved a /36 based on number of locations. The bulk of those IPs will be in the data centers. As we were chopping up the address space, it was determined that the remote campus locations would be fine with a /60 per site. (16 networks of /64). There are usually less than 50 people at the majority of these locations and only about 10 different functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, etc...). That's still poor planning, IMHO. You can easily get more than enough /48s to give one to each location. There's absolutely no advantage in the IPv6 world to being stingy with address space and no benefit to not putting at least a /48 at every location. You've got 10 VLANs, so you're wasting at most 65,526 networks. Compare that to the fact that using a /64 for a VLAN with less than 2,000,000 hosts on it will wast at least 18,446,744,073,707,551,616 addresses and you begin to realize that sparse addressing in IPv6 and large amounts of excess address capacity are intentional. > Now, there has been talk about putting an internet link in every campus rather than back hauling it all to the data centers via MPLS. However, if we do this, then would we need a /48 per campus? That is massively wasteful, at 65,536 networks per location. Is the /48 requirement set in stone? Will any carriers consider longer prefixes? Massively wasteful is a fact of life in IPv6. Consider it this way... There are two ways to waste address space. One way is, as you describe above, deploying it to locations that are unlikely to fully utilize it. Another way is to leave it sitting in a free pool until long after the protocol is no longer useful. With IPv6, we're not so much choosing between wasting address space or not. We're choosing how much address space gets wasted using method 1 vs. how much gets wasted using method 2. Ideally, we arrive at the protocol end of life with some space remaining in both categories of waste. > I know some people are always saying that the old mentality of conserving space needs to go away, but I was bitten by that IPv4 issue back in the day and have done a few VLSM network overhauls. I'd rather not massively allocate unless it's a requirement. It's a requirement and not massively allocating will bite you harder in IPv6 than space did in IPv4. IPv4 was designed for a different kind of network. It was designed to support some labs and some institutional environments. It was never intended to be the global public internet. IPv6 has been designed with the idea of addressing absolutely everything from the ground up. The design allows for plenty of /48s to number every building that could possibly fit on every planet in the solar system and several other solar systems. Frankly, a /48 per campus is underallocating for any campus that has more than one building. Owen From owen at delong.com Wed Dec 18 19:08:39 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Dec 2013 11:08:39 -0800 Subject: IPv6 /48 advertisements In-Reply-To: <52B1D308.7070206@nic.br> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> <52B1D308.7070206@nic.br> Message-ID: <86768B57-F2DC-47BC-94BD-3B4530B8062B@delong.com> Get another /48 for your other location. Owen On Dec 18, 2013, at 08:53 , Antonio M. Moreiras wrote: > What do you recommend to an end user that have a direct assignment of a > /48, and would like to disaggregate as part of a traffic engineering > strategy? > > Moreiras. > > On 18/12/13 14:32, Blake Dunlap wrote: >> Regardless of the carriers, you'll find most ASs on the internet only >> listen to /48 or larger. So even if you get your prefixes accepted by your >> provider, don't assume you can get anywhere, or have your packets not fall >> in to uRPF blackholes randomly without a larger aggregate announcement. >> >> -Blake >> >> >> On Wed, Dec 18, 2013 at 10:22 AM, Edward Dore < >> edward.dore at freethought-internet.co.uk> wrote: >> >>> If you?re talking about announcing each location separately, then RIPE >>> have a couple of useful articles about prefix visibility on Ripe Labs: >>> >>> >>> https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering >>> https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths >>> >>> Otherwise I guess you?ll need to talk to your chosen carrier(s) about >>> aggregating your space for you, which will come down to their policies on >>> what routes they will carry internally. >>> >>> Edward Dore >>> Freethought Internet >>> >>> On 18 Dec 2013, at 16:11, Cliff Bowles wrote: >>> >>>> I accidentally sent this to nanog-request yesterday. I could use some >>> feedback from anyone that can help, please. >>>> >>>> Question: will carriers accept IPv6 advertisements smaller than /48? >>>> >>>> Our org was approved a /36 based on number of locations. The bulk of >>> those IPs will be in the data centers. As we were chopping up the address >>> space, it was determined that the remote campus locations would be fine >>> with a /60 per site. (16 networks of /64). There are usually less than 50 >>> people at the majority of these locations and only about 10 different >>> functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, >>> etc...). >>>> >>>> Now, there has been talk about putting an internet link in every campus >>> rather than back hauling it all to the data centers via MPLS. However, if >>> we do this, then would we need a /48 per campus? That is massively >>> wasteful, at 65,536 networks per location. Is the /48 requirement set in >>> stone? Will any carriers consider longer prefixes? >>>> >>>> I know some people are always saying that the old mentality of >>> conserving space needs to go away, but I was bitten by that IPv4 issue back >>> in the day and have done a few VLSM network overhauls. I'd rather not >>> massively allocate unless it's a requirement. >>>> >>>> Thanks in advance. >>>> >>>> CWB >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> This message is private and confidential. If you have received it in >>> error, please notify the sender and remove it from your system. >>>> From paul at paulstewart.org Wed Dec 18 19:33:44 2013 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 18 Dec 2013 14:33:44 -0500 Subject: ddos attacks In-Reply-To: <20131218163650.GC6045@dan.olp.net> References: <6613b77386ec3b13ce249100d02290c2@mail.gmail.com> <20131218163650.GC6045@dan.olp.net> Message-ID: We use Arbor for this - works quite well?. Peakflow/TMS .. We don?t do anything announcement wise upstream but don?t see why you couldn?t via communities... I?ve looked at one cloud based solution to date and decided appliance is a better solution specific to our needs. Paul On 12/18/2013, 11:36 AM, "Dan White" wrote: >Can anyone recommend a vendor solution for DDOS mitigation? We are looking >for a solution that detects DDOS attacks from sflow information and >automatically announces BGP /32 blackhole routes to our upstream >providers, >or a similar solution. > >Thank You. > >On 08/05/13 21:09 +1000, Ahad Aboss wrote: >>Scott, >> >>Use a DDOS detection and mitigation system with DPI capabilities to deal >>with traditional DDOS attack and anomalous behaviour such as worm >>propagation, botnet attacks and malicious subscriber activity such as >>flooding and probing. There are only a few vendors who successfully play >>in >>this space who provide a self healing/self defending system. >> >>Cheers >>Ahad >>-----Original Message----- >>From: sgraun at airstreamcomm.net [mailto:sgraun at airstreamcomm.net] >>Sent: Friday, 2 August 2013 11:37 PM >>To: nanog at nanog.org >>Subject: ddos attacks >> >>I?m curious to know what other service providers are doing to >>alleviate/prevent ddos attacks from happening in your network. Are you >>completely reactive and block as many addresses as possible or null0 >>traffic >>to the effected host until it stops or do you block certain ports to >>prevent >>them. What?s the best way people are dealing with them? >> >>Scott > >-- >Dan White > From jcole at tularosa.net Wed Dec 18 20:14:24 2013 From: jcole at tularosa.net (Jerimiah Cole) Date: Wed, 18 Dec 2013 13:14:24 -0700 Subject: wireless ISP in Santa Fe In-Reply-To: <52B1E614.5020802@cox.net> References: <52B1E614.5020802@cox.net> Message-ID: <52B20220.1040109@tularosa.net> On 12/18/2013 11:14 AM, Tri Tran wrote: > The only known option is with Cibola for 7M/1M. > If anyone know of an alternate provider with higher bandwidth please > advise. http://nmbbmapping.org/mapping/ Jerimiah From tritran at cox.net Wed Dec 18 20:34:22 2013 From: tritran at cox.net (Tri Tran) Date: Wed, 18 Dec 2013 12:34:22 -0800 Subject: wireless ISP in Santa Fe In-Reply-To: <38Eu1n01v1Una3W018Ewh7> References: <52B1E614.5020802@cox.net> <38Eu1n01v1Una3W018Ewh7> Message-ID: <52B206CE.1080502@cox.net> Great site. Thank you sir! On 12/18/2013 12:14 PM, Jerimiah Cole wrote: > On 12/18/2013 11:14 AM, Tri Tran wrote: >> The only known option is with Cibola for 7M/1M. >> If anyone know of an alternate provider with higher bandwidth please >> advise. > http://nmbbmapping.org/mapping/ > > Jerimiah > > --Tri Tran From peter.phaal at gmail.com Wed Dec 18 22:31:26 2013 From: peter.phaal at gmail.com (Peter Phaal) Date: Wed, 18 Dec 2013 14:31:26 -0800 Subject: ddos attacks In-Reply-To: <20131218163650.GC6045@dan.olp.net> References: <6613b77386ec3b13ce249100d02290c2@mail.gmail.com> <20131218163650.GC6045@dan.olp.net> Message-ID: Dan, If you are using sFlow for your measurements, then you might want to take a look sFlow-RT for DDoS mitigation. The following case study describes how sFlow and null routing are being used to mitigate flood attacks: http://blog.sflow.com/2013/03/ddos.html The analytics engine will detect flood attacks in less than a second and you can use the embedded scripting API to initiate automated responses. The following articles contain basic DDoS mitigation scripts - you just need to replace the block() and allow() functions with calls to expect scripts, OpenFlow rules, or REST API calls - whatever makes sense in your environment. http://blog.sflow.com/search/label/DoS This is a commercial product, but it's free to try out (no registration required): http://inmon.com/products/sFlow-RT.php Cheers, Peter On Wed, Dec 18, 2013 at 8:36 AM, Dan White wrote: > Can anyone recommend a vendor solution for DDOS mitigation? We are looking > for a solution that detects DDOS attacks from sflow information and > automatically announces BGP /32 blackhole routes to our upstream providers, > or a similar solution. > > Thank You. > > > On 08/05/13 21:09 +1000, Ahad Aboss wrote: > >> Scott, >> >> Use a DDOS detection and mitigation system with DPI capabilities to deal >> with traditional DDOS attack and anomalous behaviour such as worm >> propagation, botnet attacks and malicious subscriber activity such as >> flooding and probing. There are only a few vendors who successfully play >> in >> this space who provide a self healing/self defending system. >> >> Cheers >> Ahad >> -----Original Message----- >> From: sgraun at airstreamcomm.net [mailto:sgraun at airstreamcomm.net] >> Sent: Friday, 2 August 2013 11:37 PM >> To: nanog at nanog.org >> Subject: ddos attacks >> >> I?m curious to know what other service providers are doing to >> alleviate/prevent ddos attacks from happening in your network. Are you >> completely reactive and block as many addresses as possible or null0 >> traffic >> to the effected host until it stops or do you block certain ports to >> prevent >> them. What?s the best way people are dealing with them? >> >> Scott >> > > -- > Dan White > > From edward.dore at freethought-internet.co.uk Wed Dec 18 22:47:37 2013 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Wed, 18 Dec 2013 22:47:37 +0000 Subject: IPv6 /48 advertisements In-Reply-To: References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> Message-ID: Yes, from a filtering point of view a /48 in IPv6 is pretty similar to a /24 in IPv4, as perfectly illustrated by the two links in my post? My point was that if you are getting the carrier to do the announcement for you then they can announce an aggregated /48 prefix and then break that up inside their network (if their internal policies allow it) to give the OP whatever prefix length per site they have decided on. The carrier only needs to carry the more specific prefixes on their backbone and the rest of the internet sees the aggregated prefix. This all depends on the architecture of the OP?s network and what services they are buying from the carrier. Of course, just getting a /48 per site and doing it properly would be the ideal scenario. Edward Dore Freethought Internet On 18 Dec 2013, at 16:32, Blake Dunlap wrote: > Regardless of the carriers, you'll find most ASs on the internet only listen to /48 or larger. So even if you get your prefixes accepted by your provider, don't assume you can get anywhere, or have your packets not fall in to uRPF blackholes randomly without a larger aggregate announcement. > > -Blake > > > On Wed, Dec 18, 2013 at 10:22 AM, Edward Dore wrote: > If you?re talking about announcing each location separately, then RIPE have a couple of useful articles about prefix visibility on Ripe Labs: > > https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering > https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths > > Otherwise I guess you?ll need to talk to your chosen carrier(s) about aggregating your space for you, which will come down to their policies on what routes they will carry internally. > > Edward Dore > Freethought Internet > > On 18 Dec 2013, at 16:11, Cliff Bowles wrote: > > > I accidentally sent this to nanog-request yesterday. I could use some feedback from anyone that can help, please. > > > > Question: will carriers accept IPv6 advertisements smaller than /48? > > > > Our org was approved a /36 based on number of locations. The bulk of those IPs will be in the data centers. As we were chopping up the address space, it was determined that the remote campus locations would be fine with a /60 per site. (16 networks of /64). There are usually less than 50 people at the majority of these locations and only about 10 different functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, etc...). > > > > Now, there has been talk about putting an internet link in every campus rather than back hauling it all to the data centers via MPLS. However, if we do this, then would we need a /48 per campus? That is massively wasteful, at 65,536 networks per location. Is the /48 requirement set in stone? Will any carriers consider longer prefixes? > > > > I know some people are always saying that the old mentality of conserving space needs to go away, but I was bitten by that IPv4 issue back in the day and have done a few VLSM network overhauls. I'd rather not massively allocate unless it's a requirement. > > > > Thanks in advance. > > > > CWB > > > > > > > > > > ________________________________ > > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. > > > > From cb.list6 at gmail.com Wed Dec 18 23:12:28 2013 From: cb.list6 at gmail.com (cb.list6) Date: Wed, 18 Dec 2013 15:12:28 -0800 Subject: ddos attacks In-Reply-To: References: Message-ID: On Aug 2, 2013 10:31 AM, wrote: > > I?m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What?s the best way people are dealing with them? > > Scott > > I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. The facts are that during steady state less than 5% of my aggregate traffic is ipv4 udp. During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever). The attacks last for about 10 minutes, so manual intervention is not possible. Automated intervention has its own warts. Conclusion: ipv4 udp is a toxic dump. It is a shame that DNS (can be tcp), webrtc (should be sctp), and Google's QUIC are going to suffer the rate limited fate. My advice to them is to get aways from ipv4 udp, the problem is getting worse not better. CB From Valdis.Kletnieks at vt.edu Thu Dec 19 00:56:25 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 18 Dec 2013 19:56:25 -0500 Subject: ddos attacks In-Reply-To: Your message of "Wed, 18 Dec 2013 15:12:28 -0800." References: Message-ID: <48604.1387414585@turing-police.cc.vt.edu> On Wed, 18 Dec 2013 15:12:28 -0800, "cb.list6" said: > I am strongly considering having my upstreams to simply rate limit ipv4 > UDP. It is the simplest solution that is proactive. What are the prospects for ipv6 UDP not suffering the same fate? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From elouie at yahoo.com Thu Dec 19 01:01:20 2013 From: elouie at yahoo.com (Eric A Louie) Date: Wed, 18 Dec 2013 17:01:20 -0800 (PST) Subject: BGP from Juniper to Cisco ASR In-Reply-To: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> References: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> Message-ID: <1387414880.57031.YahooMailNeo@web181605.mail.ne1.yahoo.com> When I had that problem, it was because the max-prefixes on the Juniper router was being triggered.?? If I remember correctly.? It's a strange return message for the wrong issue. >________________________________ > From: Philip Lavine >To: NANOG list >Sent: Wednesday, December 18, 2013 7:48 AM >Subject: BGP from Juniper to Cisco ASR > > >Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor? active 2/5 (authentication failure) 0 bytes >Dec 18 15:46:33.615: BGP: ses global? (0x7FB1CD209CF0:0) act Receive NOTIFICATION 2/5 (authentication failure) 0 bytes > >Although I have seem this on the message boards I am little confused in that the ISP is telling me that there is no authentication enabled on the Juniper and I do not have authentication enabled on the ASR. So what is going on here? > > > > From elouie at yahoo.com Thu Dec 19 01:01:25 2013 From: elouie at yahoo.com (Eric A Louie) Date: Wed, 18 Dec 2013 17:01:25 -0800 (PST) Subject: BGP from Juniper to Cisco ASR In-Reply-To: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> References: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> Message-ID: <1387414885.33481.YahooMailNeo@web181602.mail.ne1.yahoo.com> When I had that problem, it was because the max-prefixes on the Juniper router was being triggered.?? If I remember correctly.? It's a strange return message for the wrong issue. >________________________________ > From: Philip Lavine >To: NANOG list >Sent: Wednesday, December 18, 2013 7:48 AM >Subject: BGP from Juniper to Cisco ASR > > >Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor? active 2/5 (authentication failure) 0 bytes >Dec 18 15:46:33.615: BGP: ses global? (0x7FB1CD209CF0:0) act Receive NOTIFICATION 2/5 (authentication failure) 0 bytes > >Although I have seem this on the message boards I am little confused in that the ISP is telling me that there is no authentication enabled on the Juniper and I do not have authentication enabled on the ASR. So what is going on here? > > > > From jlewis at lewis.org Thu Dec 19 01:03:59 2013 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 18 Dec 2013 20:03:59 -0500 (EST) Subject: ddos attacks In-Reply-To: <48604.1387414585@turing-police.cc.vt.edu> References: <48604.1387414585@turing-police.cc.vt.edu> Message-ID: On Wed, 18 Dec 2013 Valdis.Kletnieks at vt.edu wrote: > On Wed, 18 Dec 2013 15:12:28 -0800, "cb.list6" said: > >> I am strongly considering having my upstreams to simply rate limit ipv4 >> UDP. It is the simplest solution that is proactive. > > What are the prospects for ipv6 UDP not suffering the same fate? Roughly 0%, but there's so little v6 traffic compared to v4, you probably don't have to worry about v6 attack traffic yet...particularly if you're not dual stack yet. :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From raaki.88 at gmail.com Thu Dec 19 03:01:34 2013 From: raaki.88 at gmail.com (Rakesh M) Date: Thu, 19 Dec 2013 08:31:34 +0530 Subject: BGP from Juniper to Cisco ASR In-Reply-To: <1387414885.33481.YahooMailNeo@web181602.mail.ne1.yahoo.com> References: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> <1387414885.33481.YahooMailNeo@web181602.mail.ne1.yahoo.com> Message-ID: Whats the frequency of this message occurence ? On Thu, Dec 19, 2013 at 6:31 AM, Eric A Louie wrote: > When I had that problem, it was because the max-prefixes on the Juniper > router was being triggered. If I remember correctly. It's a strange > return message for the wrong issue. > > > > > > >________________________________ > > From: Philip Lavine > >To: NANOG list > >Sent: Wednesday, December 18, 2013 7:48 AM > >Subject: BGP from Juniper to Cisco ASR > > > > > >Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor PEER> active 2/5 (authentication failure) 0 bytes > >Dec 18 15:46:33.615: BGP: ses global (0x7FB1CD209CF0:0) act > Receive NOTIFICATION 2/5 (authentication failure) 0 bytes > > > >Although I have seem this on the message boards I am little confused in > that the ISP is telling me that there is no authentication enabled on the > Juniper and I do not have authentication enabled on the ASR. So what is > going on here? > > > > > > > > > From christopher.morrow at gmail.com Thu Dec 19 04:57:10 2013 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 19 Dec 2013 04:57:10 +0000 Subject: turning on comcast v6 References: <20131213205624.GX13944@clanspum.net> Message-ID: <-2884876786553218692@gmail297201516> Ok, so... with a little messing around with the raspberry-pi + tp-link + wide-dhcpv6 client.. success! more at: http://goo.gl/jnrY7s On Fri Dec 13 2013 at 3:57:49 PM, Bill Weiss wrote: > Kinkaid, Kyle(kkinkaid at usgs.gov)@Wed, Dec 11, 2013 at 11:46:56AM -0800: > > On Wed, Dec 11, 2013 at 11:18 AM, Owen DeLong wrote: > > > > > It doesn?t. You can get IPv6 working with off-the-shelf equipment if > you > > > choose to. > > > > > > Randy chose to use that particular hardware and software combination. > > > > > > I'm curious, do you know of a consumer-grade router which supports > > DHCPv6-PD? I have been making plans to put OpenWRT on my home router to > get > > IPv6 and have found v6 support quite lacking. Most of the routers seem > to > > like to focus on various transition technologies like 6to4 tunnels. I > > would love to go to NewEgg and get a home router for $50 (or even $100) > > that is ready to go. > > > > What's more surprising is even Cisco and Juniper have been lagging. The > > SRX only got DHCPv6-PD support in the last 6 months or so and I don't > think > > the ASA has it yet. However, ISR routers like the 88x and 86x support > it. > > So what it's worth, I'm on Comcast Business, using an ASUS RT-N66U router > and a Motorola SB6141 modem. IPv6 Just Works on my network. I don't > remember having to do anything strange to the router to make it work, and > I'm certainly still running the default firmware. > > -- > Bill Weiss > > From james.braunegg at micron21.com Thu Dec 19 05:34:46 2013 From: james.braunegg at micron21.com (James Braunegg) Date: Thu, 19 Dec 2013 05:34:46 +0000 Subject: ddos attacks In-Reply-To: References: <48604.1387414585@turing-police.cc.vt.edu> Message-ID: Dear All We have been using NSFOCUS Anti DDoS hardware both locally within Australia and Internationally for the past 12 months and have been very happy with the platform capabilities and the support provided by their support engineers. For more information have a read on their website ! http://www.nsfocus.com/en/index.html I would highly recommend looking at their ADS, ADS-m and NTA hardware product lines which as a combination provides a complete automatic platform with monitoring, detection and surgical cleaning of Layer 4/7 IPv4 and IPv6 traffic including providing a client platform ! Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic. Kindest Regards James Braunegg P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braunegg at micron21.com | ABN: 12 109 977 666 W: www.micron21.com/ddos-protection T: @micron21 [Description: Description: Description: Description: M21.jpg] This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Thursday, December 19, 2013 12:04 PM To: Valdis.Kletnieks at vt.edu Cc: nanog at nanog.org Subject: Re: ddos attacks On Wed, 18 Dec 2013 Valdis.Kletnieks at vt.edu wrote: > On Wed, 18 Dec 2013 15:12:28 -0800, "cb.list6" said: > >> I am strongly considering having my upstreams to simply rate limit ipv4 >> UDP. It is the simplest solution that is proactive. > > What are the prospects for ipv6 UDP not suffering the same fate? Roughly 0%, but there's so little v6 traffic compared to v4, you probably don't have to worry about v6 attack traffic yet...particularly if you're not dual stack yet. :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2683 bytes Desc: image001.jpg URL: From eric at ericheather.com Thu Dec 19 05:51:38 2013 From: eric at ericheather.com (Eric C. Miller) Date: Thu, 19 Dec 2013 05:51:38 +0000 Subject: IPv6 /48 advertisements In-Reply-To: <90016801-9EA1-4D33-93C4-A49EF782EC49@delong.com> References: <1A5C3257AD8D4946A4B497A6FAF501743C45E5B476@EXCH07-01.apollogrp.edu> <90016801-9EA1-4D33-93C4-A49EF782EC49@delong.com> Message-ID: Owen, thanks for this explanation. +1! Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, December 18, 2013 2:07 PM To: Cliff Bowles Cc: nanog at nanog.org Subject: Re: IPv6 /48 advertisements On Dec 18, 2013, at 08:11 , Cliff Bowles wrote: > I accidentally sent this to nanog-request yesterday. I could use some feedback from anyone that can help, please. > > Question: will carriers accept IPv6 advertisements smaller than /48? Generally, no. Since a /48 should represent nothing larger than a single site, it's not very reasonable to want to route something longer in general. > Our org was approved a /36 based on number of locations. The bulk of those IPs will be in the data centers. As we were chopping up the address space, it was determined that the remote campus locations would be fine with a /60 per site. (16 networks of /64). There are usually less than 50 people at the majority of these locations and only about 10 different functional VLANs (Voice, Data, Local Services, Wireless, Guest Wireless, etc...). That's still poor planning, IMHO. You can easily get more than enough /48s to give one to each location. There's absolutely no advantage in the IPv6 world to being stingy with address space and no benefit to not putting at least a /48 at every location. You've got 10 VLANs, so you're wasting at most 65,526 networks. Compare that to the fact that using a /64 for a VLAN with less than 2,000,000 hosts on it will wast at least 18,446,744,073,707,551,616 addresses and you begin to realize that sparse addressing in IPv6 and large amounts of excess address capacity are intentional. > Now, there has been talk about putting an internet link in every campus rather than back hauling it all to the data centers via MPLS. However, if we do this, then would we need a /48 per campus? That is massively wasteful, at 65,536 networks per location. Is the /48 requirement set in stone? Will any carriers consider longer prefixes? Massively wasteful is a fact of life in IPv6. Consider it this way... There are two ways to waste address space. One way is, as you describe above, deploying it to locations that are unlikely to fully utilize it. Another way is to leave it sitting in a free pool until long after the protocol is no longer useful. With IPv6, we're not so much choosing between wasting address space or not. We're choosing how much address space gets wasted using method 1 vs. how much gets wasted using method 2. Ideally, we arrive at the protocol end of life with some space remaining in both categories of waste. > I know some people are always saying that the old mentality of conserving space needs to go away, but I was bitten by that IPv4 issue back in the day and have done a few VLSM network overhauls. I'd rather not massively allocate unless it's a requirement. It's a requirement and not massively allocating will bite you harder in IPv6 than space did in IPv4. IPv4 was designed for a different kind of network. It was designed to support some labs and some institutional environments. It was never intended to be the global public internet. IPv6 has been designed with the idea of addressing absolutely everything from the ground up. The design allows for plenty of /48s to number every building that could possibly fit on every planet in the solar system and several other solar systems. Frankly, a /48 per campus is underallocating for any campus that has more than one building. Owen From cb.list6 at gmail.com Thu Dec 19 07:27:56 2013 From: cb.list6 at gmail.com (cb.list6) Date: Wed, 18 Dec 2013 23:27:56 -0800 Subject: Time to stopy saying there is no IPv6 traffice: was Re: ddos attacks Message-ID: On Wed, Dec 18, 2013 at 5:03 PM, Jon Lewis wrote: > On Wed, 18 Dec 2013 Valdis.Kletnieks at vt.edu wrote: > > On Wed, 18 Dec 2013 15:12:28 -0800, "cb.list6" said: >> >> I am strongly considering having my upstreams to simply rate limit ipv4 >>> UDP. It is the simplest solution that is proactive. >>> >> >> What are the prospects for ipv6 UDP not suffering the same fate? >> > > Roughly 0%, but there's so little v6 traffic compared to v4, you probably > don't have to worry about v6 attack traffic yet...particularly if you're > not dual stack yet. :) > > I understand that your answer about nil IPv6 traffic may be appropriate for your network, but for many of us IPv6 is currently a non-trivial amount of traffic that is growing quickly. And, in some cases, IPv6 is the dominate amount of traffic. Here are some quick stats of a few select familiar names from http://www.worldipv6launch.org/measurements/ Google Fiber 70% Virginia Tech 61% Verizon Wireless 40% Comcast 20% AT&T Wireline 15% T-Mobile US 6% > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From tore at fud.no Thu Dec 19 08:53:13 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 19 Dec 2013 09:53:13 +0100 Subject: ddos attacks In-Reply-To: References: <48604.1387414585@turing-police.cc.vt.edu> Message-ID: <52B2B3F9.4060404@fud.no> * James Braunegg > Of course for any form of Anti DDoS hardware to be functional you > need to make sure your network can route and pass the traffic so you > can absorb the bad traffic to give you a chance cleaning the > traffic. So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful. Tore From eugen at imacandi.net Thu Dec 19 09:32:29 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 19 Dec 2013 11:32:29 +0200 Subject: ddos attacks In-Reply-To: <52B2B3F9.4060404@fud.no> References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> Message-ID: Hi, You can also take a look at http://www.packetdam.com/ for DDoS protection. Eugeniu On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson wrote: > * James Braunegg > > > Of course for any form of Anti DDoS hardware to be functional you > > need to make sure your network can route and pass the traffic so you > > can absorb the bad traffic to give you a chance cleaning the > > traffic. > > So in order for an Anti-DDoS appliance to be functional the network > needs to be able to withstand the DDoS on its own. How terribly useful. > > Tore > > From adrian.minta at gmail.com Thu Dec 19 12:08:00 2013 From: adrian.minta at gmail.com (Adrian M) Date: Thu, 19 Dec 2013 14:08:00 +0200 Subject: ddos attacks In-Reply-To: References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> Message-ID: Hi, You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection and BGP triggered blackholing. On Thu, Dec 19, 2013 at 11:32 AM, Eugeniu Patrascu wrote: > Hi, > > You can also take a look at http://www.packetdam.com/ for DDoS protection. > > Eugeniu > > > On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson wrote: > > > * James Braunegg > > > > > Of course for any form of Anti DDoS hardware to be functional you > > > need to make sure your network can route and pass the traffic so you > > > can absorb the bad traffic to give you a chance cleaning the > > > traffic. > > > > So in order for an Anti-DDoS appliance to be functional the network > > needs to be able to withstand the DDoS on its own. How terribly useful. > > > > Tore > > > > > From jtk at cymru.com Thu Dec 19 13:05:40 2013 From: jtk at cymru.com (John Kristoff) Date: Thu, 19 Dec 2013 07:05:40 -0600 Subject: ddos attacks In-Reply-To: References: Message-ID: <20131219070540.16a5abd7@localhost> On Wed, 18 Dec 2013 15:12:28 -0800 "cb.list6" wrote: > I am strongly considering having my upstreams to simply rate limit > ipv4 UDP. It is the simplest solution that is proactive. I understand your willingness to do this, but I'd strongly advise you to rethink such a strategy. At its simplest implementation, as soon as you do this any UDP flood of that size will then starve important UDP traffic. Yes DNS is probably the most important, but NTP is another one important one you may inadvertently harm. > The facts are that during steady state less than 5% of my aggregate > traffic is ipv4 udp. I had found this to be generally true years back when I was doing ops at an edu and had in fact put UDP (and other IP protocol) rate limits at the ingress edge, host facing interfaces. This actually worked pretty well, at least after I also remove the aggregate UDP rate limit in the middle of the network that led to the public Internet. So for instance, a Slammer/Sapphire worm infection was severely limited and contained to impact only a small portion of the infrastructure, meanwhile we could immediately spot the problem when the rate limit alarms were triggered. The problem with your proposal is that it complete the job for your entire network. Now perhaps if you excluded, or provided a separate limit for what you know to be important UDP flows, then the idea may be more palatable to everyday operations. John From rdobbins at arbor.net Thu Dec 19 13:17:19 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 19 Dec 2013 13:17:19 +0000 Subject: ddos attacks In-Reply-To: <52B2B3F9.4060404@fud.no> References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> Message-ID: <22440229-B691-489B-991D-585A2AC1007B@arbor.net> On Dec 19, 2013, at 3:53 PM, Tore Anderson wrote: > So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful. Due to the nature of network infrastructure devices and TCP/IP, it's quite necessary that they themselves are resilient in the face of attack: This is a base requirement for any network operator, without exception. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nick at foobar.org Thu Dec 19 13:40:05 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 19 Dec 2013 13:40:05 +0000 Subject: ddos attacks In-Reply-To: <22440229-B691-489B-991D-585A2AC1007B@arbor.net> References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> <22440229-B691-489B-991D-585A2AC1007B@arbor.net> Message-ID: <52B2F735.4030603@foobar.org> On 19/12/2013 13:17, Dobbins, Roland wrote: > This is a base requirement for any network operator, without exception. in fact, this comes down to cost / benefit / application analysis, without exception. Many hosting profiles don't require this sort of anti-DDoS kit. In many cases it's far cheaper to permanently disconnect a customer who is the subject of continual DoS's rather than fork out loadsamoney for boxes like this. For applications at the higher end of the spectrum, there are many situations where it's more cost effective / resilient / sensible to farm out online content to CDNs, whose infrastructure will be much better equipped to handle several tens of gigs of DDoS traffic than even a reasonably large deployment of local anti-ddos boxes. I'm sure mitigation boxes like this serve well in many situations if the cost / benefit justifies the expenditure, but as with most things, it's a case of applying the best tool for the job rather than blind application of shiny toys. Nick From rdobbins at arbor.net Thu Dec 19 14:08:34 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 19 Dec 2013 14:08:34 +0000 Subject: ddos attacks In-Reply-To: <52B2F735.4030603@foobar.org> References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> <22440229-B691-489B-991D-585A2AC1007B@arbor.net> <52B2F735.4030603@foobar.org> Message-ID: <72574674-CF28-42A4-B984-50E11402CB36@arbor.net> On Dec 19, 2013, at 8:40 PM, Nick Hilliard wrote: > Many hosting profiles don't require this sort of anti-DDoS kit. My post had nothing to do with 'anti-DDoS kit'. > I'm sure mitigation boxes like this serve well in many situations if the cost / benefit justifies the expenditure, but as with most things, it's a > case of applying the best tool for the job rather than blind application of shiny toys. 'Mitigation boxes' like what? Again, my post had nothing to do with 'mitigation boxes' or 'shiny toys'. Unless you count routers and switches as 'shiny toys'. I've never advocated the 'blind application' of any feature, function, mechanism, or 'shiny toy'. Perhaps you've confused me with someone else. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jnegro at advance.net Thu Dec 19 15:14:38 2013 From: jnegro at advance.net (Jeffrey Negro) Date: Thu, 19 Dec 2013 15:14:38 +0000 Subject: Anyone seeing issues with Abovenet/Zayo in Northeast US? Message-ID: We have two MPLS circuits malfunctioning, one from DE to NJ, and another from DE to CA. Both are showing high latency and packet loss. Curious to hear if anyone else is having issues. Thanks From nick at foobar.org Thu Dec 19 15:40:46 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 19 Dec 2013 15:40:46 +0000 Subject: ddos attacks In-Reply-To: <72574674-CF28-42A4-B984-50E11402CB36@arbor.net> References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> <22440229-B691-489B-991D-585A2AC1007B@arbor.net> <52B2F735.4030603@foobar.org> <72574674-CF28-42A4-B984-50E11402CB36@arbor.net> Message-ID: <52B3137E.5060208@foobar.org> On 19/12/2013 14:08, Dobbins, Roland wrote: > My post had nothing to do with 'anti-DDoS kit'. hmm, re-reading it, your post was contextually ambiguous and I read it in a different way to the way that apparently you meant. but yes, if you're doing onsite ddos scrubbing, you needs lotsabandwidth. Nick From Lee at asgard.org Thu Dec 19 16:13:48 2013 From: Lee at asgard.org (Lee Howard) Date: Thu, 19 Dec 2013 11:13:48 -0500 Subject: ddos attacks In-Reply-To: References: <48604.1387414585@turing-police.cc.vt.edu> Message-ID: On 12/18/13 8:03 PM, "Jon Lewis" wrote: >On Wed, 18 Dec 2013 Valdis.Kletnieks at vt.edu wrote: > >> On Wed, 18 Dec 2013 15:12:28 -0800, "cb.list6" said: >> >>> I am strongly considering having my upstreams to simply rate limit ipv4 >>> UDP. It is the simplest solution that is proactive. >> >> What are the prospects for ipv6 UDP not suffering the same fate? > >Roughly 0%, but there's so little v6 traffic compared to v4, you probably >don't have to worry about v6 attack traffic yet...particularly if you're >not dual stack yet. :) -1 uninsightful Can't find any public data showing IPv6 as a percent of total bits, but it's certainly a meaningful percent of hits in many countries and networks. See also http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets- 00 which describes risks from IPv6 to people who think they are running an IPv4-only network. Lee From ed.lewis at neustar.biz Thu Dec 19 16:18:03 2013 From: ed.lewis at neustar.biz (Edward Lewis) Date: Thu, 19 Dec 2013 11:18:03 -0500 Subject: ddos attacks In-Reply-To: References: Message-ID: On Dec 18, 2013, at 18:12, cb.list6 wrote: > I am strongly considering having my upstreams to simply rate limit ipv4 > UDP. It is the simplest solution that is proactive. Recently it's been said that when a protocol is "query/response" (like DNS), willingly suppressing responses might be as harmful as passing all the traffic. This comes from a presentation at October's DNS-OARC workshop: https://indico.dns-oarc.net//getFile.py/access?contribId=4&resId=0&materialId=slides&confId=1 This is a "what is possible in theory" presentation, said to help you set your expectation whether this is a true threat or not. The underlying message is that while a querier is waiting for a response, there is a window of vulnerability in which a forged response might be accepted. If the responder elects not to respond, they increase the (time) duration of that window. While "smart" rate limiting exhibits benefits I suspect "simple" rate limiting might have some undesirable consequences. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Why is it that people who fear government monitoring of social media are surprised to learn that I avoid contributing to social media? From jlewis at lewis.org Thu Dec 19 16:32:46 2013 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 19 Dec 2013 11:32:46 -0500 (EST) Subject: ddos attacks In-Reply-To: References: <48604.1387414585@turing-police.cc.vt.edu> Message-ID: On Thu, 19 Dec 2013, Lee Howard wrote: >>>> I am strongly considering having my upstreams to simply rate limit ipv4 >>>> UDP. It is the simplest solution that is proactive. >>> >>> What are the prospects for ipv6 UDP not suffering the same fate? >> >> Roughly 0%, but there's so little v6 traffic compared to v4, you probably >> don't have to worry about v6 attack traffic yet...particularly if you're >> not dual stack yet. :) > > > -1 uninsightful > > Can't find any public data showing IPv6 as a percent of total bits, but > it's certainly a meaningful percent of hits in many countries and networks. > > See also > http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets- > 00 which describes risks from IPv6 to people who think they are running an > IPv4-only network. Apparently your humor detector is defective. It was meant??as a jab at the poor adoption of IPv6. I'd hope that most people on NANOG would know if they're actually doing any IPv6. I know there's more v6 where I am now, but at a previous employer, out of hundreds of hosting and colo customers, I think the ones who'd even asked about IPv6 could be counted on my fing?ers, and the ones actually doing v6 on one hand. AFAIK, my cable internet provider still isn't offering it...so if I wanted it at home, I'd have to tunnel someplace else. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cb.list6 at gmail.com Thu Dec 19 16:33:21 2013 From: cb.list6 at gmail.com (cb.list6) Date: Thu, 19 Dec 2013 08:33:21 -0800 Subject: ddos attacks In-Reply-To: References: Message-ID: On Thu, Dec 19, 2013 at 8:18 AM, Edward Lewis wrote: > On Dec 18, 2013, at 18:12, cb.list6 wrote: > > > I am strongly considering having my upstreams to simply rate limit ipv4 > > UDP. It is the simplest solution that is proactive. > > > Recently it's been said that when a protocol is "query/response" (like > DNS), willingly suppressing responses might be as harmful as passing all > the traffic. > > This comes from a presentation at October's DNS-OARC workshop: > > https://indico.dns-oarc.net//getFile.py/access?contribId=4&resId=0&materialId=slides&confId=1 > > This is a "what is possible in theory" presentation, said to help you set > your expectation whether this is a true threat or not. > > The underlying message is that while a querier is waiting for a response, > there is a window of vulnerability in which a forged response might be > accepted. If the responder elects not to respond, they increase the (time) > duration of that window. > > While "smart" rate limiting exhibits benefits I suspect "simple" rate > limiting might have some undesirable consequences. > > I completely agree. This why i have not yet implemented IPv4 UDP rate-limiting yet, but it seems inevitable for 2014 if these attacks go on. The profile i have in mind is when UDP exceeds 5x the baseline, then tail-drop. Keep in mind, when UDP exceeds 5x the baseline, the chances are are 99% that the UDP is consuming the entire ISP pipe and everything is rate-limited due to the pipe being saturated. So, this is not a simple either / or. This is degrade UDP proactively or suffer all traffic degrading because there is a huge DDoS coming in (which is the current situation). > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > Why is it that people who fear government monitoring of social media are > surprised to learn that I avoid contributing to social media? > > From EDugas at zerofail.com Wed Dec 18 16:09:31 2013 From: EDugas at zerofail.com (Eric Dugas) Date: Wed, 18 Dec 2013 16:09:31 +0000 Subject: BGP from Juniper to Cisco ASR In-Reply-To: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> References: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> Message-ID: <656AAF5E8566DF47835F38F66FA8213A15E4773E@ZF-EXC1.Pre2Post.local> Probably a TTL problem. Did you configure ebgp-multihop? Eric Dugas ZEROFAIL / AS40191 edugas at zerofail.com -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: December 18, 2013 10:48 AM To: NANOG list Subject: BGP from Juniper to Cisco ASR Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor? active 2/5 (authentication failure) 0 bytes Dec 18 15:46:33.615: BGP: ses global? (0x7FB1CD209CF0:0) act Receive NOTIFICATION 2/5 (authentication failure) 0 bytes Although I have seem this on the message boards I am little confused in that the ISP is telling me that there is no authentication enabled on the Juniper and I do not have authentication enabled on the ASR. So what is going on here? From fergdawgster at mykolab.com Thu Dec 19 19:35:38 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 19 Dec 2013 11:35:38 -0800 Subject: ddos attacks In-Reply-To: References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> Message-ID: <52B34A8A.2080109@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm really surprised no one has mentioned Akamai/Prolexic, especially since their recent marriage. If someone has already mentioned it: Apologies. - - ferg On 12/19/2013 4:08 AM, Adrian M wrote: > Hi, > > You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection > and BGP triggered blackholing. > > > On Thu, Dec 19, 2013 at 11:32 AM, Eugeniu Patrascu > wrote: > >> Hi, >> >> You can also take a look at http://www.packetdam.com/ for DDoS >> protection. >> >> Eugeniu >> >> >> On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson wrote: >> >>> * James Braunegg >>> >>>> Of course for any form of Anti DDoS hardware to be functional you >>>> need to make sure your network can route and pass the traffic so you >>>> can absorb the bad traffic to give you a chance cleaning the >>>> traffic. >>> >>> So in order for an Anti-DDoS appliance to be functional the network >>> needs to be able to withstand the DDoS on its own. How terribly useful. >>> >>> Tore >>> >>> >> > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSs0qFq1pz9mNUZTMRAlHzAJ4snDXa9MSpzSAniMUKcea0L521jQCgxHLH gBUm4ScmJlf5FsC5kJJrmZs= =tLUd -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From source_route at yahoo.com Thu Dec 19 20:27:19 2013 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 19 Dec 2013 12:27:19 -0800 (PST) Subject: BGP from Juniper to Cisco ASR In-Reply-To: References: <1387381707.79042.YahooMailNeo@web122504.mail.ne1.yahoo.com> <1387414885.33481.YahooMailNeo@web181602.mail.ne1.yahoo.com> Message-ID: <1387484839.52265.YahooMailNeo@web122506.mail.ne1.yahoo.com> I was able to solve the issue by statically routing the connected /29 out the connected interface, that way it overrode the BGP learned route for the same subnet (unfortunately this might have been a multi-homing issue that resulted in asymmetrical routing to the primary peer via the secondary peer, since the secondary peer session was already established). I thought BGP was "intelligent" enough to run the TCP session over the directly connected interfaces on the same subnets. I can understand this being an issue with multihop but not multi-homing. On Wednesday, December 18, 2013 7:01 PM, Rakesh M wrote: Whats the frequency of this message occurence ? On Thu, Dec 19, 2013 at 6:31 AM, Eric A Louie wrote: When I had that problem, it was because the max-prefixes on the Juniper router was being triggered.?? If I remember correctly.? It's a strange return message for the wrong issue. > > > > > >>________________________________ >> From: Philip Lavine >>To: NANOG list >>Sent: Wednesday, December 18, 2013 7:48 AM >>Subject: BGP from Juniper to Cisco ASR >> >> > >>Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor? active 2/5 (authentication failure) 0 bytes >>Dec 18 15:46:33.615: BGP: ses global? (0x7FB1CD209CF0:0) act Receive NOTIFICATION 2/5 (authentication failure) 0 bytes >> >>Although I have seem this on the message boards I am little confused in that the ISP is telling me that there is no authentication enabled on the Juniper and I do not have authentication enabled on the ASR. So what is going on here? >> >> >> >> > From dennis at justipit.com Thu Dec 19 20:30:08 2013 From: dennis at justipit.com (=?utf-8?B?ZGVubmlzQGp1c3RpcGl0LmNvbQ==?=) Date: Thu, 19 Dec 2013 15:30:08 -0500 Subject: =?utf-8?B?UmU6IGRkb3MgYXR0YWNrcw==?= Message-ID: Just about every security, network and ADC vendor out there is claiming anti-dos capabilities. Be careful when going that route and do your own validation. I suggest looking at Radware and Arbor (both leaders in the market). To successfully mitigate an attack the ideal solutions will weed out the attack and allow legitimate traffic to continue. Many of the solutions in the commercial market are not much more than rate limiters and are not very forgiving. Just as important realize while spoofed udp floods are popular they are oftened only the first vector, if successfully mitigated attackers quickly adjust and follow with more complex vectors such as application attacks toward http, ssl, dns query floods, etc.. Remember their goal is to bring you down, , divert your attention while they steal your data or perhaps transfer funds. They will go to far lengths to achieve their end result. As you can imagine it's much harder to identify the attack characteristics or for that matter the attacker in these more complex cases. In summary, I'm a firm believer in a hybrid approach with combination of infrastructure acls, rtbh, qos, URPF, tcp stack hardening, local anti-ddos appliances for application attacks and network floods under link capacity to allow you to stay up while deciding to shift routes into cloud band ability to swing up stream to cloud scrubbing center (in house or third party). Sent from my Sprint phone. ----- Reply message ----- From: "Paul Ferguson" To: Subject: ddos attacks Date: Thu, Dec 19, 2013 2:35 PM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm really surprised no one has mentioned Akamai/Prolexic, especially since their recent marriage. If someone has already mentioned it: Apologies. - - ferg On 12/19/2013 4:08 AM, Adrian M wrote: > Hi, > > You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection > and BGP triggered blackholing. > > > On Thu, Dec 19, 2013 at 11:32 AM, Eugeniu Patrascu > wrote: > >> Hi, >> >> You can also take a look at http://www.packetdam.com/ for DDoS >> protection. >> >> Eugeniu >> >> >> On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson wrote: >> >>> * James Braunegg >>> >>>> Of course for any form of Anti DDoS hardware to be functional you >>>> need to make sure your network can route and pass the traffic so you >>>> can absorb the bad traffic to give you a chance cleaning the >>>> traffic. >>> >>> So in order for an Anti-DDoS appliance to be functional the network >>> needs to be able to withstand the DDoS on its own. How terribly useful. >>> >>> Tore >>> >>> >> > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSs0qFq1pz9mNUZTMRAlHzAJ4snDXa9MSpzSAniMUKcea0L521jQCgxHLH gBUm4ScmJlf5FsC5kJJrmZs= =tLUd -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From eugen at imacandi.net Thu Dec 19 20:51:19 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 19 Dec 2013 22:51:19 +0200 Subject: ddos attacks In-Reply-To: References: Message-ID: On Thu, Dec 19, 2013 at 10:30 PM, dennis at justipit.com wrote: > Just about every security, network and ADC vendor out there is claiming > anti-dos capabilities. Be careful when going that route and do your own > validation. I suggest looking at Radware and Arbor (both leaders in the > market). To successfully mitigate an attack the ideal solutions will weed > out the attack and allow legitimate traffic to continue. Many of the > solutions in the commercial market are not much more than rate limiters and > are not very forgiving. Just as important realize while spoofed udp floods > are popular they are oftened only the first vector, if successfully > mitigated attackers quickly adjust and follow with more complex vectors > such as application attacks toward http, ssl, dns query floods, etc.. > Remember their goal is to bring you down, , divert your attention while > they steal your data or perhaps transfer funds. They will go to far > lengths to achieve their end result. As you can imagine it's much harder > to identify the attack characteristics or for that matter the attacker in > these more complex cases. In summary, I'm a firm believer in a hybrid > approach with combination of infrastructure acls, rtbh, qos, URPF, tcp > stack hardening, local anti-ddos appliances for application attacks and > network floods under link capacity to allow you to stay up while deciding > to shift routes into cloud band ability to swing up stream to cloud > scrubbing center (in house or third party). > I know a bit about Radware, and what they do is to learn a traffic pattern from where traffic usually comes and when in case of exceeding a certain threshold, they start dropping traffic from new sources never seen before and then drop some seen before traffic. This works if you are a company with a very localized visitor base (like banking site for certain national or local bank, e-shop and so on) but it kind of doesn't scale that much when it comes to we have people all over the place and we get DDoS-ed with legitimate requests that only consume server resources. What providers do in some regions is to blackhole your subnet if you reach a certain number of packets per second. It sucks, but hey, they also have infrastructure to protect. Eugeniu From dennis at justipit.com Thu Dec 19 21:05:10 2013 From: dennis at justipit.com (=?utf-8?B?ZGVubmlzQGp1c3RpcGl0LmNvbQ==?=) Date: Thu, 19 Dec 2013 16:05:10 -0500 Subject: =?utf-8?B?UmU6IGRkb3MgYXR0YWNrcw==?= Message-ID: I have to disagree with the scaling as I've personally deployed both Arbor and Radware in carrier and MSSP environments, including tier 1, CLEC and cable operators. Deployment models vary from infrastructure protection to scrubbing center and top of rack solutions. Happy to discuss with you further offlist. Cheers Dennis Sent from my Sprint phone. ----- Reply message ----- From: "Eugeniu Patrascu" To: "dennis at justipit.com" Cc: , "NANOG list" Subject: ddos attacks Date: Thu, Dec 19, 2013 3:51 PM On Thu, Dec 19, 2013 at 10:30 PM, dennis at justipit.com wrote: Just about every security, network and ADC vendor out there is claiming anti-dos capabilities. ?Be careful when going that route and do your own validation. ?I suggest looking at Radware and Arbor (both leaders in the market). To successfully mitigate an attack the ideal solutions will weed out the attack and allow legitimate traffic to continue. ?Many of the solutions in the commercial market are not much more than rate limiters and are not very forgiving. ?Just as important realize while spoofed udp floods are popular they are oftened only the first vector, if successfully mitigated attackers quickly adjust and follow with more complex vectors such as application attacks toward http, ssl, dns query floods, etc.. Remember their goal is to bring you down, , divert your attention while they steal your data or perhaps transfer funds. ?They will go to far lengths to achieve their end result. ?As you can imagine it's much harder to identify the attack characteristics or for that matter the attacker in these more complex cases. ?In summary, I'm a firm believer in a hybrid approach with combination of infrastructure acls, rtbh, qos, URPF, tcp stack hardening, local anti-ddos appliances for application attacks and network floods under link capacity to allow you to stay up while deciding to shift routes into cloud band ability to swing up stream to cloud scrubbing center (in house or third party). I know a bit about Radware, and what they do is to learn a traffic pattern from where traffic usually comes and when in case of exceeding a certain threshold, they start dropping traffic from new sources never seen before and then drop some seen before traffic. This works if you are a company with a very localized visitor base (like banking site for certain national or local bank, e-shop and so on) but it kind of doesn't scale that much when it comes to we have people all over the place and we get DDoS-ed with legitimate requests that only consume server resources. What providers do in some regions is to blackhole your subnet if you reach a certain number of packets per second. It sucks, but hey, they also have infrastructure to protect. Eugeniu From rdobbins at arbor.net Thu Dec 19 21:06:26 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 19 Dec 2013 21:06:26 +0000 Subject: ddos attacks In-Reply-To: <52B3137E.5060208@foobar.org> References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> <22440229-B691-489B-991D-585A2AC1007B@arbor.net> <52B2F735.4030603@foobar.org> <72574674-CF28-42A4-B984-50E11402CB36@arbor.net> <52B3137E.5060208@foobar.org> Message-ID: On Dec 19, 2013, at 10:40 PM, Nick Hilliard wrote: > hmm, re-reading it, your post was contextually ambiguous and I read it in a different way to the way that apparently you meant. It was quite clear what was meant, even without looking at the linked presentation, which clarified matters even further. > but yes, if you're doing onsite ddos scrubbing, you needs lotsabandwidth. Once again, nothing in my post said or referred to bandwidth; in fact, simply throwing bandwidth at the problem won't work, as attackers have access to what are for all practical purposes near-infinite resources. In future, it might be a good idea to ensure that the points one attempts to make actually apply to the specific post to which one is replying. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nicholas.oas at gmail.com Thu Dec 19 21:08:19 2013 From: nicholas.oas at gmail.com (Nicholas Oas) Date: Thu, 19 Dec 2013 16:08:19 -0500 Subject: turning on comcast v6 In-Reply-To: <-2884876786553218692@gmail297201516> References: <20131213205624.GX13944@clanspum.net> <-2884876786553218692@gmail297201516> Message-ID: I did an OK job of getting my Linksys E2100L working with Comcast v6 on OpenWRT. It is not officially supported on this platform per se, but a simple hack of the source for WRT160NL allows it to be built. Since I was already rolling my own firmware, I checked the box for 'ipv6' and got the attached result. It works out of the oven, as in I did absolutely no troubleshooting beyond booting and looking to see the ipv6 chicken. If anyone wants more details on exactly what I selected in the menuconfig let me know. -------------- next part -------------- login as: root root at 192.168.0.1's password: BusyBox v1.19.4 (2013-11-11 17:20:10 EST) built-in shell (ash) Enter 'help' for a list of built-in commands. _______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M ----------------------------------------------------- BARRIER BREAKER (Bleeding Edge, r38744) ----------------------------------------------------- * 1/2 oz Galliano Pour all ingredients into * 4 oz cold Coffee an irish coffee mug filled * 1 1/2 oz Dark Rum with crushed ice. Stir. * 2 tsp. Creme de Cacao ----------------------------------------------------- root at OpenWrt:~# opkg list 6relayd - 2013-10-21-ad00c3dd9ee42f172870708724858ab502b3a689 base-files - 147-r38744 busybox - 1.19.4-7 dnsmasq - 2.66-5 dropbear - 2013.59-1 firewall - 2013-10-23 ip6tables - 1.4.20-1 iptables - 1.4.20-1 iw - 3.10-1 jshn - 2013-10-30-a34c8f6918c291275ded2b6fd9b94ac91722ded2 kernel - 3.10.18-1-6127216e96a5793516c624e09001f8a2 kmod-ath - 3.10.18+2013-06-27-1 kmod-ath9k - 3.10.18+2013-06-27-1 kmod-ath9k-common - 3.10.18+2013-06-27-1 kmod-cfg80211 - 3.10.18+2013-06-27-1 kmod-crypto-aes - 3.10.18-1 kmod-crypto-arc4 - 3.10.18-1 kmod-crypto-core - 3.10.18-1 kmod-crypto-hash - 3.10.18-1 kmod-crypto-manager - 3.10.18-1 kmod-crypto-pcompress - 3.10.18-1 kmod-gpio-button-hotplug - 3.10.18-1 kmod-ip6tables - 3.10.18-1 kmod-ipt-conntrack - 3.10.18-1 kmod-ipt-core - 3.10.18-1 kmod-ipt-nat - 3.10.18-1 kmod-ipt-nathelper - 3.10.18-1 kmod-ipv6 - 3.10.18-1 kmod-leds-gpio - 3.10.18-1 kmod-ledtrig-default-on - 3.10.18-1 kmod-ledtrig-netdev - 3.10.18-1 kmod-ledtrig-timer - 3.10.18-1 kmod-ledtrig-usbdev - 3.10.18-1 kmod-lib-crc-ccitt - 3.10.18-1 kmod-mac80211 - 3.10.18+2013-06-27-1 kmod-nls-base - 3.10.18-1 kmod-ppp - 3.10.18-1 kmod-pppoe - 3.10.18-1 kmod-pppox - 3.10.18-1 kmod-slhc - 3.10.18-1 kmod-usb-core - 3.10.18-1 kmod-usb-ohci - 3.10.18-1 kmod-usb2 - 3.10.18-1 libblobmsg-json - 2013-10-30-a34c8f6918c291275ded2b6fd9b94ac91722ded2 libc - 0.9.33.2-1 libgcc - 4.6-linaro-1 libip4tc - 1.4.20-1 libip6tc - 1.4.20-1 libiwinfo - 47 libiwinfo-lua - 47 libjson-c - 0.11-2 libjson-script - 2013-10-30-a34c8f6918c291275ded2b6fd9b94ac91722ded2 liblua - 5.1.5-1 libnl-tiny - 0.1-3 libopenssl - 1.0.1e-2 libubox - 2013-10-30-a34c8f6918c291275ded2b6fd9b94ac91722ded2 libubus - 2013-11-07-8ea96670367e5dd23988b51ee4f0f790393effaf libubus-lua - 2013-11-07-8ea96670367e5dd23988b51ee4f0f790393effaf libuci - 2013-10-15.1-1 libuci-lua - 2013-10-15.1-1 libxtables - 1.4.20-1 lua - 5.1.5-1 luci - svn-r9934-1 luci-app-firewall - svn-r9934-1 luci-i18n-english - svn-r9934-1 luci-lib-core - svn-r9934-1 luci-lib-ipkg - svn-r9934-1 luci-lib-nixio - svn-r9934-1 luci-lib-sys - svn-r9934-1 luci-lib-web - svn-r9934-1 luci-mod-admin-core - svn-r9934-1 luci-mod-admin-full - svn-r9934-1 luci-proto-core - svn-r9934-1 luci-proto-ipv6 - svn-r9934-1 luci-proto-ppp - svn-r9934-1 luci-sgi-cgi - svn-r9934-1 luci-theme-base - svn-r9934-1 luci-theme-bootstrap - svn-r9934-1 mtd - 20 netifd - 2013-10-31-199723ed921160c029a0d15fa95914ddfcdc5cb9 odhcp6c - 2013-10-29-60c9e4d5a26f530e89ed6254e8c09380b50fac08 opkg - 618-6 ppp - 2.4.5-10 ppp-mod-pppoe - 2.4.5-10 procd - 2013-11-08-315f04d8b823adda96041c17f6672b7790376ccb-1 swconfig - 10 uboot-envtools - 2013.10-1 ubox - 2013-11-07.1-0588218d4bc58b0e099272338decbe4734f5678b-1 ubus - 2013-11-07-8ea96670367e5dd23988b51ee4f0f790393effaf ubusd - 2013-11-07-8ea96670367e5dd23988b51ee4f0f790393effaf uci - 2013-10-15.1-1 uhttpd - 2013-11-11-881d6102cf1f7bc6b54ab395c5e4addbfe1ed34c uhttpd-mod-ubus - 2013-11-11-881d6102cf1f7bc6b54ab395c5e4addbfe1ed34c wpad-mini - 20130807-1 zlib - 1.2.8-1 root at OpenWrt:~# ifconfig br-lan Link encap:Ethernet HWaddr 98:FC:11:XX:XX:XX inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: 2601:x:xxxx:xxx::1/60 Scope:Global inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/64 Scope:Link inet6 addr: fde1:xxxx:xxxx::1/60 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1897 errors:0 dropped:0 overruns:0 frame:0 TX packets:1451 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:269454 (263.1 KiB) TX bytes:1019474 (995.5 KiB) eth0 Link encap:Ethernet HWaddr 98:FC:11:XX:XX:XX UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1305 errors:0 dropped:38 overruns:0 frame:0 TX packets:615 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:220038 (214.8 KiB) TX bytes:114232 (111.5 KiB) Interrupt:4 eth1 Link encap:Ethernet HWaddr 98:FC:11:XX:XX:XX inet addr:24.XX.XXX.XX Bcast:24.XX.XXX.255 Mask:255.255.248.0 inet6 addr: 2001:xxx:xxxx:xx:xxx:xxxx:xxxx:xxxx/128 Scope:Global inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2380 errors:0 dropped:0 overruns:0 frame:0 TX packets:1118 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1074529 (1.0 MiB) TX bytes:172638 (168.5 KiB) Interrupt:5 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:64 errors:0 dropped:0 overruns:0 frame:0 TX packets:64 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4912 (4.7 KiB) TX bytes:4912 (4.7 KiB) wlan0 Link encap:Ethernet HWaddr 98:FC:11:XX:XX:XX UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:673 errors:0 dropped:0 overruns:0 frame:0 TX packets:1432 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:82933 (80.9 KiB) TX bytes:1039813 (1015.4 KiB) root at OpenWrt:/etc/config# ls 6relayd dhcp dropbear firewall luci network system ubootenv ucitrack uhttpd wireless root at OpenWrt:/etc/config# cat 6relayd config server default option master wan6 list network lan option rd server option dhcpv6 server option fallback_relay 'rd dhcpv6 ndp' option management_level 1 From rdobbins at arbor.net Thu Dec 19 21:23:59 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 19 Dec 2013 21:23:59 +0000 Subject: ddos attacks In-Reply-To: References: Message-ID: <38CA5FAF-753D-4CC7-89D3-FE9BEA53A485@arbor.net> On Dec 19, 2013, at 6:12 AM, cb.list6 wrote: > I am strongly considering having my upstreams to simply rate limit ipv4 UDP. QoS is a very poor mechanism for remediating DDoS attacks. It ensures that programmatically-generated attack traffic will 'squeeze out' legitimate traffic. > During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever). Have you checked to see whether you and/or your customers have open DNS recursors, misconfigured CPE devices, etc. which can be used as reflectors/amplifiers on your respective networks? Have you implemented NetFlow and S/RTBH? Considered building a mitigation center? Do you work with your peers/upstreams/downstreams to mitigate DDoS attacks when they ingress your network? There are lots of things one can do to increase one's ability to detect, classify, traceback, and mitigate DDoS attacks, yet which aren't CAPEX-intensive. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From cb.list6 at gmail.com Thu Dec 19 21:39:25 2013 From: cb.list6 at gmail.com (cb.list6) Date: Thu, 19 Dec 2013 13:39:25 -0800 Subject: ddos attacks In-Reply-To: <38CA5FAF-753D-4CC7-89D3-FE9BEA53A485@arbor.net> References: <38CA5FAF-753D-4CC7-89D3-FE9BEA53A485@arbor.net> Message-ID: On Dec 19, 2013 4:25 PM, "Dobbins, Roland" wrote: > > > On Dec 19, 2013, at 6:12 AM, cb.list6 wrote: > > > I am strongly considering having my upstreams to simply rate limit ipv4 UDP. > > QoS is a very poor mechanism for remediating DDoS attacks. It ensures that programmatically-generated attack traffic will 'squeeze out' legitimate traffic. > I agree. But ... i am pretty sure i am going to do it. Trade offs. > > During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever). > > Have you checked to see whether you and/or your customers have open DNS recursors, misconfigured CPE devices, etc. which can be used as reflectors/amplifiers on your respective networks? > > Have you implemented NetFlow and S/RTBH? Considered building a mitigation center? > > > > Do you work with your peers/upstreams/downstreams to mitigate DDoS attacks when they ingress your network? > Not answering any of that. But thanks for asking. > There are lots of things one can do to increase one's ability to detect, classify, traceback, and mitigate DDoS attacks, yet which aren't CAPEX-intensive. > I think ipv4 udp is just going to become operationally deprecated. Too much pollution. It is really an epic amount of trash / value ratio in ipv4 udp. I recommend folks enable their auth dns servers for ipv6 ... and dont run open resolvers CB > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From surfer at mauigateway.com Thu Dec 19 22:02:54 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 19 Dec 2013 14:02:54 -0800 Subject: ddos attacks Message-ID: <20131219140254.EA1CEFAC@m0005299.ppops.net> --- cb.list6 at gmail.com wrote: On Dec 19, 2013 4:25 PM, "Dobbins, Roland" wrote: On Dec 19, 2013, at 6:12 AM, cb.list6 wrote: > > I am strongly considering having my upstreams to simply > > rate limit ipv4 UDP. > > QoS is a very poor mechanism for remediating DDoS attacks. > It ensures that programmatically-generated attack traffic > will 'squeeze out' legitimate traffic. I agree. But ... i am pretty sure i am going to do it. Trade offs. ----------------------------------------------------------------- If you don't mind, after your first legit attack reply back to this thread with the details, so others can learn from it when they're looking through the archives. scott From tore at fud.no Thu Dec 19 22:23:37 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 19 Dec 2013 23:23:37 +0100 Subject: ddos attacks In-Reply-To: References: <48604.1387414585@turing-police.cc.vt.edu> <52B2B3F9.4060404@fud.no> <22440229-B691-489B-991D-585A2AC1007B@arbor.net> <52B2F735.4030603@foobar.org> <72574674-CF28-42A4-B984-50E11402CB36@arbor.net> <52B3137E.5060208@foobar.org> Message-ID: <52B371E9.7010300@fud.no> * Dobbins, Roland > Once again, nothing in my post said or referred to bandwidth; The post of mine, to which you replied, did. Perhaps if you had taken your own advice quoted below when replying to me, Nick wouldn't have been contextually confused. Tore > In future, it might be a good idea to ensure that the points one > attempts to make actually apply to the specific post to which one is > replying. From rdobbins at arbor.net Fri Dec 20 03:24:45 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 20 Dec 2013 03:24:45 +0000 Subject: ddos attacks In-Reply-To: References: <38CA5FAF-753D-4CC7-89D3-FE9BEA53A485@arbor.net> Message-ID: On Dec 20, 2013, at 4:39 AM, cb.list6 wrote: > Not answering any of that. But thanks for asking. I wasn't asking those questions in order to elicit information from you, but rather as food for thought as you work through these issues. > I think ipv4 udp is just going to become operationally deprecated. Too much pollution. It is really an epic amount of trash / value ratio in ipv4 udp. This isn't a realistic viewpoint. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From ml at kenweb.org Fri Dec 20 04:11:46 2013 From: ml at kenweb.org (ML) Date: Thu, 19 Dec 2013 23:11:46 -0500 Subject: turning on comcast v6 In-Reply-To: <86a9g64usr.fsf@valhalla.seastrom.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> Message-ID: <52B3C382.7080208@kenweb.org> On 12/11/2013 10:23 PM, Rob Seastrom wrote: > Eric Oosting writes: > >> It brings a tear to my eye that it takes: >> >> 0) A long standing and well informed internet technologist; >> 1) specific, and potentially high end, CPE for the res; >> 2) specific and custom firmware, unsupported by CPE manufacturer ... or >> anyone; >> 3) hand installing several additional packages; >> 4) hand editing config files; >> 5) sysctl kernel flags; >> 6) several shout outs to friends and coworkers for assistance (resources >> many don't have access to); >> 7) oh, and probably hours and hours twiddling with it. >> >> just to get IPv6 to work correctly. >> >> Yea, that's TOTALLY reasonable. > Pretty much works out of the box on Mikrotik RouterOS if you are > secure enough in your geek cred to admit to running such stuff here in > this august forum. > > -r FYI - DHCP-PD is now working better in RouterOS 6.5 Prefix length hints are now available (CLI) only. /ipv6 dhcp-client add add-default-route=yes interface= pool-name=dhcp-pd \ prefix-hint=::/60 In the case of Comcast (and anecdotally ISC DHCP) - You'll either need to wait out the the lease time (4 days) or ask Comcast to nicely clear out your /64 lease manually. Release/renew doesn't release your current DHCP lease. I was getting A /64 and /60 (/64 had a preference of 255) before Comcast removed the /64 lease manually. From morrowc.lists at gmail.com Fri Dec 20 04:43:04 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Dec 2013 23:43:04 -0500 Subject: turning on comcast v6 In-Reply-To: <52B3C382.7080208@kenweb.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> Message-ID: > In the case of Comcast (and anecdotally ISC DHCP) - You'll either need > to wait out the the lease time (4 days) or ask Comcast to nicely clear > out your /64 lease manually. Release/renew doesn't release your current > DHCP lease. I was getting A /64 and /60 (/64 had a preference of 255) > before Comcast removed the /64 lease manually. that's interesting.. I don't see anything except the /64... even when I ask via the pd sla-len hint for a 60, 62, 63 .... :( From owen at delong.com Fri Dec 20 05:30:35 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Dec 2013 21:30:35 -0800 Subject: turning on comcast v6 In-Reply-To: <52B3C382.7080208@kenweb.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> Message-ID: > > FYI - DHCP-PD is now working better in RouterOS 6.5 > > Prefix length hints are now available (CLI) only. > > /ipv6 dhcp-client add add-default-route=yes interface= > pool-name=dhcp-pd \ > prefix-hint=::/60 > I'd like to encourage people to use prefix-hint=::/48. The router should accept the /60 and deal with it, but it's better to have Comcast's logs show that you requested a proper full-size prefix. I'm almost afraid to ask about the phrase "add-default-route=yes" in the dhcp-client configuration. That seems wrong on the face of it since you should be getting your routing information from RA and not DHCP. > In the case of Comcast (and anecdotally ISC DHCP) - You'll either need > to wait out the the lease time (4 days) or ask Comcast to nicely clear > out your /64 lease manually. Release/renew doesn't release your current > DHCP lease. I was getting A /64 and /60 (/64 had a preference of 255) > before Comcast removed the /64 lease manually. Is it somehow harmful to have both? Owen From morrowc.lists at gmail.com Fri Dec 20 05:42:46 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Dec 2013 00:42:46 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> Message-ID: On Fri, Dec 20, 2013 at 12:30 AM, Owen DeLong wrote: >> >> FYI - DHCP-PD is now working better in RouterOS 6.5 >> >> Prefix length hints are now available (CLI) only. >> >> /ipv6 dhcp-client add add-default-route=yes interface= >> pool-name=dhcp-pd \ >> prefix-hint=::/60 >> > > I'd like to encourage people to use prefix-hint=::/48. > > The router should accept the /60 and deal with it, but it's better to have Comcast's logs show that you requested a proper full-size prefix. > > I'm almost afraid to ask about the phrase "add-default-route=yes" in the dhcp-client configuration. That seems wrong on the face of it since you should be getting your routing information from RA and not DHCP. I think if I ask (via wide-dhcpv6-server) for more than is going to be sent I don't get anything configured at all :( I'm pretty sure I get sent a /64 in the response packet, but I don't install that.. which leads to busted v6 configuration on my device. > >> In the case of Comcast (and anecdotally ISC DHCP) - You'll either need >> to wait out the the lease time (4 days) or ask Comcast to nicely clear >> out your /64 lease manually. Release/renew doesn't release your current >> DHCP lease. I was getting A /64 and /60 (/64 had a preference of 255) >> before Comcast removed the /64 lease manually. > > Is it somehow harmful to have both? > > Owen > > From gary.buhrmaster at gmail.com Fri Dec 20 06:07:42 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 20 Dec 2013 06:07:42 +0000 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> Message-ID: On Fri, Dec 20, 2013 at 5:42 AM, Christopher Morrow wrote: > On Fri, Dec 20, 2013 at 12:30 AM, Owen DeLong wrote: .... >> I'd like to encourage people to use prefix-hint=::/48. ... > I think if I ask (via wide-dhcpv6-server) for more than is going to be > sent I don't get anything configured at all :( > > I'm pretty sure I get sent a /64 in the response packet, but I don't > install that.. which leads to busted v6 configuration on my device. I concur (with the request a /48, get a /64, not a /60). At least that is how I recall it used to work (I have not tried for some time at this point, and while I know Comcast has changed things in the interim, I am pretty sure I do not want to wait for Comcast to time out a /64 if that is what I end up getting). If someone has better information, I am willing to consider a test. Gary From saku at ytti.fi Fri Dec 20 08:27:21 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 20 Dec 2013 10:27:21 +0200 Subject: ddos attacks In-Reply-To: References: <38CA5FAF-753D-4CC7-89D3-FE9BEA53A485@arbor.net> Message-ID: <20131220082721.GA9409@pob.ytti.fi> On (2013-12-20 03:24 +0000), Dobbins, Roland wrote: > > I think ipv4 udp is just going to become operationally deprecated. Too much pollution. It is really an epic amount of trash / value ratio in ipv4 udp. > > This isn't a realistic viewpoint. What are realistic options? a) QUIC and MinimaLT - 0 RTT overhead, like UDP - no reflection attacks, like TCP - all traffic encrypted - parity packets to match packet loss to avoid need for resends (QUIC) - non-bursty via packet pacing - solution for buffer bloat (packet pacing can be affected by changing latency) (QUIC) - CPU hit, encryption isn't free, but shouldn't be issue today - mobility, IP is not needed to recognize end-point, you can hop from WLAN to 4G without disconnecting b) ACL between transit provider and transit customer - <50k ports to configure in whole world to make UDP reflection useless DoS vector c) ACL/RPF in significant portion of access ports in whole world - i'm guessing significant portion of access ports are on autopilot with no one to change their configs, so probably not practical. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > -- ++ytti From rdobbins at arbor.net Fri Dec 20 09:33:07 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 20 Dec 2013 09:33:07 +0000 Subject: ddos attacks In-Reply-To: <20131220082721.GA9409@pob.ytti.fi> References: <38CA5FAF-753D-4CC7-89D3-FE9BEA53A485@arbor.net> <20131220082721.GA9409@pob.ytti.fi> Message-ID: <5E2F5873-427C-4E20-A32B-8AFBB48A507B@arbor.net> On Dec 20, 2013, at 3:27 PM, Saku Ytti wrote: > c) ACL/RPF in significant portion of access ports in whole world > - i'm guessing significant portion of access ports are on autopilot with > no one to change their configs, so probably not practical. d) The current state of affairs persists, with no meaningful change in the foreseeable future, except the problem growing worse. My guess is that d) is the most likely outcome. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jamie at photon.com Fri Dec 20 12:36:38 2013 From: jamie at photon.com (Jamie Bowden) Date: Fri, 20 Dec 2013 12:36:38 +0000 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> Message-ID: <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> > From: Owen DeLong [mailto:owen at delong.com] > I'm almost afraid to ask about the phrase "add-default-route=yes" in the > dhcp-client configuration. That seems wrong on the face of it since you > should be getting your routing information from RA and not DHCP. No, no, no, a thousand times no. I'm sure RA is great for small SOHO networks and for ISPs as a means to hand out resources, but in a corporate environment, we hate you. How many times do the IPv6 people have to hear that until DHCPv6 reaches feature parity with DCHPv4, IPv6 is dead to enterprise networks? Jamie From Lee at asgard.org Fri Dec 20 12:56:07 2013 From: Lee at asgard.org (Lee Howard) Date: Fri, 20 Dec 2013 07:56:07 -0500 Subject: turning on comcast v6 In-Reply-To: <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> Message-ID: On 12/20/13 7:36 AM, "Jamie Bowden" wrote: >> From: Owen DeLong [mailto:owen at delong.com] > >> I'm almost afraid to ask about the phrase "add-default-route=yes" in the >> dhcp-client configuration. That seems wrong on the face of it since you >> should be getting your routing information from RA and not DHCP. > >No, no, no, a thousand times no. I'm sure RA is great for small SOHO >networks and for ISPs as a means to hand out resources, but in a >corporate environment, we hate you. How many times do the IPv6 people >have to hear that until DHCPv6 reaches feature parity with DCHPv4, IPv6 >is dead to enterprise networks? "Parity" isn't enough information; what features are missing? RA is part of IPv6, but you don't have to use SLAAC. I'd say it's the DHC people who need to hear it, not the IPv6 people, but YMMV. Lee > >Jamie > > From ml at kenweb.org Fri Dec 20 13:04:31 2013 From: ml at kenweb.org (ML) Date: Fri, 20 Dec 2013 08:04:31 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> Message-ID: <52B4405F.6010207@kenweb.org> On 12/20/2013 12:30 AM, Owen DeLong wrote: >> I'd like to encourage people to use prefix-hint=::/48. >> >> The router should accept the /60 and deal with it, but it's better to have Comcast's logs show that you requested a proper full-size prefix. >> >> I'm almost afraid to ask about the phrase "add-default-route=yes" in the dhcp-client configuration. That seems wrong on the face of it since you should be getting your routing information from RA and not DHCP. >From what I'm told "add-default-route=yes" is a hack by RouterOS developers to add a default route via the link local address you receive DHCP packets from. This will break of course if DHCP server != intended default gateway http://forum.mikrotik.com/viewtopic.php?f=2&t=64595&hilit=IA_PD >> In the case of Comcast (and anecdotally ISC DHCP) - You'll either need >> to wait out the the lease time (4 days) or ask Comcast to nicely clear >> out your /64 lease manually. Release/renew doesn't release your current >> DHCP lease. I was getting A /64 and /60 (/64 had a preference of 255) >> before Comcast removed the /64 lease manually. > Is it somehow harmful to have both? > > Yeah.. RouterOS doesn't install both prefixes into the IPv6 pool used for assigning prefixes to your LAN interfaces. RouterOS is able to encapsulate sniffed packets into a TZSP container and forward them to a host of your choice. I was able to get a PCAP of my DHCPv6 packets between Comcast and I. There were two Advertise packets from Comcast (/64 followed by /60) and RouterOS only replied with (1) Request for the /64 From jamie at photon.com Fri Dec 20 13:07:27 2013 From: jamie at photon.com (Jamie Bowden) Date: Fri, 20 Dec 2013 13:07:27 +0000 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> Message-ID: <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> > From: Lee Howard [mailto:Lee at asgard.org] > On 12/20/13 7:36 AM, "Jamie Bowden" wrote: > >> From: Owen DeLong [mailto:owen at delong.com] > >> I'm almost afraid to ask about the phrase "add-default-route=yes" in the > >> dhcp-client configuration. That seems wrong on the face of it since you > >> should be getting your routing information from RA and not DHCP. > >No, no, no, a thousand times no. I'm sure RA is great for small SOHO > >networks and for ISPs as a means to hand out resources, but in a > >corporate environment, we hate you. How many times do the IPv6 people > >have to hear that until DHCPv6 reaches feature parity with DCHPv4, IPv6 > >is dead to enterprise networks? > "Parity" isn't enough information; what features are missing? RA is part > of IPv6, but you don't have to use SLAAC. > I'd say it's the DHC people who need to hear it, not the IPv6 people, but > YMMV. I have a question. Why does DHCP hand out router, net mask, broadcast address, etc. in IPv4; why don't we all just use RIP and be done with it? You don't have to like how enterprise networks are built, but you better acknowledge that they are their own animal that have their own needs and drivers, and telling them that the way their networks are built are wrong and they need to change their whole architecture, separation of service, security model, etc. to fit your idea of perfection isn't winning friends. You are, however, influencing people. Perhaps not in the manner you intended. Jamie From Lee at asgard.org Fri Dec 20 13:25:12 2013 From: Lee at asgard.org (Lee Howard) Date: Fri, 20 Dec 2013 08:25:12 -0500 Subject: turning on comcast v6 In-Reply-To: <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: On 12/20/13 8:07 AM, "Jamie Bowden" wrote: > > >> "Parity" isn't enough information; what features are missing? RA is >>part >> of IPv6, but you don't have to use SLAAC. >> I'd say it's the DHC people who need to hear it, not the IPv6 people, >>but >> YMMV. > >I have a question. Why does DHCP hand out router, net mask, broadcast >address, etc. in IPv4; why don't we all just use RIP and be done with it? > >You don't have to like how enterprise networks are built, but you better >acknowledge that they are their own animal that have their own needs and >drivers, and telling them that the way their networks are built are wrong >and they need to change their whole architecture, separation of service, >security model, etc. to fit your idea of perfection isn't winning >friends. You are, however, influencing people. Perhaps not in the >manner you intended. So there's an interesting question. You suggest there's a disagreement between enterprise network operators and protocol designers. Who should change? I used to run an enterprise network. It was very different from an ISP network. I didn't say, "You're wrong!" I said, "What's missing?" There are business reasons to run IPv6. The fact that it's different than IPv4 is not a reason not to use it. Lee > >Jamie > From mhuff at ox.com Fri Dec 20 14:29:39 2013 From: mhuff at ox.com (Matthew Huff) Date: Fri, 20 Dec 2013 09:29:39 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover. In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment. ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 > -----Original Message----- > From: Lee Howard [mailto:Lee at asgard.org] > Sent: Friday, December 20, 2013 8:25 AM > To: Jamie Bowden; Owen DeLong; ml at kenweb.org > Cc: North American Network Operators' Group > Subject: Re: turning on comcast v6 > > > > On 12/20/13 8:07 AM, "Jamie Bowden" wrote: > > > > > > >> "Parity" isn't enough information; what features are missing? RA is > >>part > >> of IPv6, but you don't have to use SLAAC. > >> I'd say it's the DHC people who need to hear it, not the IPv6 people, > >>but > >> YMMV. > > > >I have a question. Why does DHCP hand out router, net mask, broadcast > >address, etc. in IPv4; why don't we all just use RIP and be done with it? > > > >You don't have to like how enterprise networks are built, but you better > >acknowledge that they are their own animal that have their own needs and > >drivers, and telling them that the way their networks are built are wrong > >and they need to change their whole architecture, separation of service, > >security model, etc. to fit your idea of perfection isn't winning > >friends. You are, however, influencing people. Perhaps not in the > >manner you intended. > > So there's an interesting question. You suggest there's a disagreement > between enterprise network operators and protocol designers. Who should > change? > > I used to run an enterprise network. It was very different from an ISP > network. I didn't say, "You're wrong!" I said, "What's missing?" > > There are business reasons to run IPv6. The fact that it's different than > IPv4 is not a reason not to use it. > > Lee > > > > >Jamie > > > > From dwcarder at wisc.edu Fri Dec 20 16:51:27 2013 From: dwcarder at wisc.edu (Dale W. Carder) Date: Fri, 20 Dec 2013 10:51:27 -0600 Subject: turning on comcast v6 In-Reply-To: <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: <20131220165127.GD13115@ricotta.doit.wisc.edu> Thus spake Jamie Bowden (jamie at photon.com) on Fri, Dec 20, 2013 at 01:07:27PM +0000: > > From: Lee Howard [mailto:Lee at asgard.org] > > On 12/20/13 7:36 AM, "Jamie Bowden" wrote: > > >> From: Owen DeLong [mailto:owen at delong.com] > > > > >> I'm almost afraid to ask about the phrase "add-default-route=yes" in the > > >> dhcp-client configuration. That seems wrong on the face of it since you > > >> should be getting your routing information from RA and not DHCP. > > > >No, no, no, a thousand times no. I'm sure RA is great for small SOHO > > >networks and for ISPs as a means to hand out resources, but in a > > >corporate environment, we hate you. How many times do the IPv6 people > > >have to hear that until DHCPv6 reaches feature parity with DCHPv4, IPv6 > > >is dead to enterprise networks? Strange, I have an enterprise network with some segments running ipv6 for over a decade ;-) > > "Parity" isn't enough information; what features are missing? RA is part > > of IPv6, but you don't have to use SLAAC. > > I'd say it's the DHC people who need to hear it, not the IPv6 people, but > > YMMV. > > I have a question. Why does DHCP hand out router, net mask, broadcast address, etc. in IPv4; why don't we all just use RIP and be done with it? I think you mean IRDP/rfc1256. We used to run quite a bit of that, too. Dale From Valdis.Kletnieks at vt.edu Fri Dec 20 16:56:14 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 20 Dec 2013 11:56:14 -0500 Subject: turning on comcast v6 In-Reply-To: Your message of "Fri, 20 Dec 2013 12:36:38 +0000." <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> Message-ID: <5490.1387558574@turing-police.cc.vt.edu> On Fri, 20 Dec 2013 12:36:38 +0000, Jamie Bowden said: > How many times do the IPv6 people have to hear that until DHCPv6 reaches > feature parity with DCHPv4, IPv6 is dead to enterprise networks? How many times do the IPv4 people have to hear that many sites are running IPv6 on enterprise networks, and maybe that whole DHCPv6 thing is not as big a deal as you think? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Dec 20 17:52:36 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Dec 2013 12:52:36 -0500 Subject: turning on comcast v6 In-Reply-To: <5490.1387558574@turing-police.cc.vt.edu> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <5490.1387558574@turing-police.cc.vt.edu> Message-ID: On Fri, Dec 20, 2013 at 11:56 AM, wrote: > On Fri, 20 Dec 2013 12:36:38 +0000, Jamie Bowden said: >> How many times do the IPv6 people have to hear that until DHCPv6 reaches >> feature parity with DCHPv4, IPv6 is dead to enterprise networks? > > How many times do the IPv4 people have to hear that many sites are running > IPv6 on enterprise networks, and maybe that whole DHCPv6 thing is not as > big a deal as you think? 'cant we all just get along' ? :) it seems to me that at least: SLAAC works (for some people, without modifications/other-foo) DHCPV6 works (for some folks) both work together there are usecases where: "MachineX must always be 1.2.3.4/32 && a:b:c::4/128" there are usescases where: "pool of machines behind this LAN interface can be anything in this netblock" there are good reasons to have dhcp attirbutes about: dns-server domain searchorder tftp location root device ntp server and with the ability of the 'systems people' to control those destination(s) for population sets in the network. I'm sure it doesn't serve us all (as folk that want the network to continue to grow and succeed) to pidgeon hole people/systems/networks with: "Must use X" or "Must use Y" when both X and Y work perfectly well (or could be made to work perfectly well with some more specification and requirements gathering). happy holidays, ba-humbug... -chris From cscora at apnic.net Fri Dec 20 18:07:35 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Dec 2013 04:07:35 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201312201807.rBKI7Z7Y009088@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, LacNOG, TRNOG, 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 21 Dec, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 475800 Prefixes after maximum aggregation: 190361 Deaggregation factor: 2.50 Unique aggregates announced to Internet: 236234 Total ASes present in the Internet Routing Table: 45782 Prefixes per ASN: 10.39 Origin-only ASes present in the Internet Routing Table: 35490 Origin ASes announcing only one prefix: 16278 Transit ASes present in the Internet Routing Table: 5971 Transit-only ASes present in the Internet Routing Table: 177 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1068 Unregistered ASNs in the Routing Table: 305 Number of 32-bit ASNs allocated by the RIRs: 5558 Number of 32-bit ASNs visible in the Routing Table: 4321 Prefixes from 32-bit ASNs in the Routing Table: 13537 Number of bogon 32-bit ASNs visible in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 1466 Number of addresses announced to Internet: 2660917980 Equivalent to 158 /8s, 154 /16s and 98 /24s Percentage of available address space announced: 71.9 Percentage of allocated address space announced: 71.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.3 Total number of prefixes smaller than registry allocations: 166277 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 112978 Total APNIC prefixes after maximum aggregation: 34171 APNIC Deaggregation factor: 3.31 Prefixes being announced from the APNIC address blocks: 115264 Unique aggregates announced from the APNIC address blocks: 48154 APNIC Region origin ASes present in the Internet Routing Table: 4877 APNIC Prefixes per ASN: 23.63 APNIC Region origin ASes announcing only one prefix: 1211 APNIC Region transit ASes present in the Internet Routing Table: 839 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 794 Number of APNIC addresses announced to Internet: 729350848 Equivalent to 43 /8s, 121 /16s and 2 /24s Percentage of available APNIC address space announced: 85.2 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-63999, 131072-133631 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: 163428 Total ARIN prefixes after maximum aggregation: 81908 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 164196 Unique aggregates announced from the ARIN address blocks: 75953 ARIN Region origin ASes present in the Internet Routing Table: 15934 ARIN Prefixes per ASN: 10.30 ARIN Region origin ASes announcing only one prefix: 6002 ARIN Region transit ASes present in the Internet Routing Table: 1672 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 49 Number of ARIN addresses announced to Internet: 1075463552 Equivalent to 64 /8s, 26 /16s and 69 /24s Percentage of available ARIN address space announced: 56.9 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: 119980 Total RIPE prefixes after maximum aggregation: 61371 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 123716 Unique aggregates announced from the RIPE address blocks: 79314 RIPE Region origin ASes present in the Internet Routing Table: 17576 RIPE Prefixes per ASN: 7.04 RIPE Region origin ASes announcing only one prefix: 8306 RIPE Region transit ASes present in the Internet Routing Table: 2831 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2537 Number of RIPE addresses announced to Internet: 655696868 Equivalent to 39 /8s, 21 /16s and 35 /24s Percentage of available RIPE address space announced: 95.3 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-200191 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: 53303 Total LACNIC prefixes after maximum aggregation: 10055 LACNIC Deaggregation factor: 5.30 Prefixes being announced from the LACNIC address blocks: 58687 Unique aggregates announced from the LACNIC address blocks: 27431 LACNIC Region origin ASes present in the Internet Routing Table: 2059 LACNIC Prefixes per ASN: 28.50 LACNIC Region origin ASes announcing only one prefix: 551 LACNIC Region transit ASes present in the Internet Routing Table: 398 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 933 Number of LACNIC addresses announced to Internet: 146973752 Equivalent to 8 /8s, 194 /16s and 164 /24s Percentage of available LACNIC address space announced: 87.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11809 Total AfriNIC prefixes after maximum aggregation: 2611 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 12471 Unique aggregates announced from the AfriNIC address blocks: 4238 AfriNIC Region origin ASes present in the Internet Routing Table: 697 AfriNIC Prefixes per ASN: 17.89 AfriNIC Region origin ASes announcing only one prefix: 208 AfriNIC Region transit ASes present in the Internet Routing Table: 147 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 8 Number of AfriNIC addresses announced to Internet: 48643712 Equivalent to 2 /8s, 230 /16s and 62 /24s Percentage of available AfriNIC address space announced: 48.3 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 2948 11558 952 Korea Telecom (KIX) 17974 2731 902 88 PT TELEKOMUNIKASI INDONESIA 7545 2121 319 112 TPG Internet Pty Ltd 4755 1804 392 191 TATA Communications formerly 9829 1558 1251 42 BSNL National Internet Backbo 9583 1300 100 537 Sify Limited 9498 1229 309 72 BHARTI Airtel Ltd. 4808 1145 2121 346 CNCGROUP IP network: China169 7552 1134 1080 13 Vietel Corporation 24560 1098 382 167 Bharti Airtel Ltd., Telemedia 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 6389 3028 3688 53 BellSouth.net Inc. 22773 2303 2939 139 Cox Communications, Inc. 1785 2146 686 131 PaeTec Communications, Inc. 18566 2050 379 178 MegaPath Corporation 20115 1681 1662 593 Charter Communications 4323 1630 1081 413 Time Warner Telecom 701 1508 11144 781 MCI Communications Services, 30036 1375 309 574 Mediacom Communications Corp 7018 1308 17746 853 AT&T WorldNet Services 6983 1295 756 580 ITC^Deltacom 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 8402 1884 544 16 OJSC "Vimpelcom" 34984 1366 243 226 TELLCOM ILETISIM HIZMETLERI A 20940 1212 458 913 Akamai Technologies European 31148 1011 45 19 FreeNet ISP 13188 919 99 40 TOV "Bank-Inform" 6849 860 363 38 JSC UKRTELECOM, 8551 846 370 38 Bezeq International 6830 772 2327 425 UPC Distribution Services 12479 683 798 53 Uni2 Autonomous System 35228 551 246 16 Avatar Broadband Limited 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 28573 3430 1839 90 NET Servicos de Comunicao S.A 10620 2691 435 209 Telmex Colombia S.A. 18881 1778 908 20 Global Village Telecom 7303 1743 1163 230 Telecom Argentina Stet-France 8151 1371 2857 429 UniNet S.A. de C.V. 11830 868 364 15 Instituto Costarricense de El 27947 855 93 89 Telconet S.A 6503 791 434 60 AVANTEL, S.A. 6147 788 373 27 Telefonica Del Peru 7738 780 1498 36 Telecomunicacoes da Bahia 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 36998 1819 112 5 Sudanese Mobile Telephone (ZA 24863 889 338 26 LINKdotNET AS number 6713 598 653 27 Itissalat Al-MAGHRIB 8452 420 956 9 TEDATA 24835 298 144 9 RAYA Telecom - Egypt 3741 247 921 209 The Internet Solution 36992 247 526 30 Etisalat MISR 29571 239 21 14 Ci Telecom Autonomous system 15706 219 32 6 Sudatel Internet Exchange Aut 29975 192 668 21 Vodacom 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 28573 3430 1839 90 NET Servicos de Comunicao S.A 6389 3028 3688 53 BellSouth.net Inc. 4766 2948 11558 952 Korea Telecom (KIX) 17974 2731 902 88 PT TELEKOMUNIKASI INDONESIA 10620 2691 435 209 Telmex Colombia S.A. 22773 2303 2939 139 Cox Communications, Inc. 1785 2146 686 131 PaeTec Communications, Inc. 7545 2121 319 112 TPG Internet Pty Ltd 18566 2050 379 178 MegaPath Corporation 8402 1884 544 16 OJSC "Vimpelcom" 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 3028 2975 BellSouth.net Inc. 17974 2731 2643 PT TELEKOMUNIKASI INDONESIA 10620 2691 2482 Telmex Colombia S.A. 22773 2303 2164 Cox Communications, Inc. 1785 2146 2015 PaeTec Communications, Inc. 7545 2121 2009 TPG Internet Pty Ltd 4766 2948 1996 Korea Telecom (KIX) 18566 2050 1872 MegaPath Corporation 8402 1884 1868 OJSC "Vimpelcom" 36998 1819 1814 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 62828 UNALLOCATED 8.21.130.0/24 4323 Time Warner Telecom 62850 UNALLOCATED 8.25.147.0/24 46887 Lightower Fiber Netw 62734 UNALLOCATED 8.31.128.0/24 6939 Hurricane Electric 62773 UNALLOCATED 8.35.180.0/22 3356 Level 3 Communicatio 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 62719 UNALLOCATED 12.27.130.0/24 4323 Time Warner Telecom 62861 UNALLOCATED 12.37.197.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest Communications Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.91.0.0/19 40676 Psychz Networks 23.91.4.0/24 40676 Psychz Networks 23.91.14.0/24 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.80.0/20 21560 Capital Technology Services G 23.91.96.0/20 37958 ChinaCache Networks ASN 23.91.112.0/21 32475 MidPhase Inc. 23.91.120.0/21 36351 SoftLayer Technologies Inc. 23.91.160.0/19 36493 3757277 Canada Inc. (oa 295.c 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:11 /10:31 /11:92 /12:253 /13:473 /14:937 /15:1636 /16:12859 /17:6759 /18:11374 /19:23196 /20:32966 /21:35768 /22:50414 /23:44040 /24:252543 /25:837 /26:986 /27:448 /28:48 /29:72 /30:26 /31:0 /32:15 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2005 2050 MegaPath Corporation 36998 1786 1819 Sudanese Mobile Telephone (ZA 6389 1699 3028 BellSouth.net Inc. 8402 1584 1884 OJSC "Vimpelcom" 22773 1553 2303 Cox Communications, Inc. 30036 1216 1375 Mediacom Communications Corp 1785 1163 2146 PaeTec Communications, Inc. 11492 1148 1185 Cable One 6983 1037 1295 ITC^Deltacom 22561 977 1252 Digital Teleport, Inc Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:925 2:855 3:3 4:16 5:829 6:21 8:618 12:1883 13:3 14:901 15:9 16:3 17:19 20:34 23:616 24:1754 27:1702 31:1516 32:46 33:2 34:5 36:104 37:1955 38:919 39:3 40:182 41:3216 42:238 44:14 46:2106 47:10 49:703 50:859 52:12 54:44 55:5 56:4 57:26 58:1144 59:583 60:370 61:1498 62:1229 63:1978 64:4397 65:2334 66:4133 67:2115 68:1088 69:3295 70:909 71:511 72:2025 74:2587 75:323 76:305 77:1215 78:1029 79:676 80:1285 81:1084 82:643 83:754 84:630 85:1275 86:398 87:1015 88:524 89:1568 90:150 91:5734 92:626 93:1617 94:2104 95:1509 96:520 97:351 98:1082 99:41 100:32 101:693 103:3870 105:533 106:144 107:255 108:548 109:2019 110:966 111:1135 112:607 113:811 114:753 115:1044 116:1014 117:830 118:1237 119:1279 120:340 121:771 122:1885 123:1267 124:1388 125:1447 128:638 129:232 130:357 131:665 132:355 133:159 134:310 135:73 136:277 137:252 138:353 139:171 140:202 141:349 142:550 143:406 144:498 145:90 146:550 147:436 148:790 149:360 150:153 151:479 152:408 153:208 154:49 155:518 156:313 157:419 158:285 159:788 160:359 161:454 162:961 163:252 164:636 165:586 166:280 167:641 168:1044 169:123 170:1151 171:185 172:12 173:1714 174:675 175:547 176:1338 177:2573 178:1905 179:327 180:1604 181:915 182:1423 183:477 184:623 185:1145 186:2779 187:1449 188:1956 189:1269 190:7315 192:7078 193:5440 194:4033 195:3389 196:1347 197:1076 198:4806 199:5527 200:6058 201:2545 202:9016 203:8904 204:4535 205:2637 206:2906 207:2820 208:3955 209:3694 210:3080 211:1632 212:2184 213:1973 214:873 215:85 216:5430 217:1723 218:622 219:323 220:1273 221:591 222:332 223:563 End of report From dougb at dougbarton.us Fri Dec 20 20:16:57 2013 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 20 Dec 2013 12:16:57 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: <52B4A5B9.1040601@dougbarton.us> On 12/20/2013 05:25 AM, Lee Howard wrote: > So there's an interesting question. You suggest there's a disagreement > between enterprise network operators and protocol designers. Who should > change? Rather obviously the protocol designers, since they are clearly out of touch with real-world requirements. RA/SLAAC was a clever idea 20 years ago, and still has value for its original intended purpose, putting dumb clients on the net. However in the time since IPng DHCP won the day. Enterprises have their own administrative structures that work with v4, and see no reason to have to change them to accommodate the lofty goals of the IPv6 luminati. Keep in mind that the vast majority of enterprises are happy with their v4 NATs, aren't affected by address exhaustion issues, and have no reason to move to v6. > I used to run an enterprise network. It was very different from an ISP > network. I didn't say, "You're wrong!" I said, "What's missing?" Apples and cumquats. > There are business reasons to run IPv6. The fact that it's different than > IPv4 is not a reason not to use it. ... except that enterprises have been saying for over a decade that full-featured DHCP is a requirement before they will even look at v6. Not to mention the inherent insecurity of RA/SLAAC, which has yet to be robustly addressed. Yes, rogue DHCP servers are still possible, but the effects are more manageable and arguably easier to mitigate; not to mention the better security for this that is built into most modern networking gear already. Doug From owen at delong.com Fri Dec 20 20:23:10 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Dec 2013 12:23:10 -0800 Subject: turning on comcast v6 In-Reply-To: <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> Message-ID: <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> On Dec 20, 2013, at 6:29 AM, Matthew Huff wrote: > With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover. RA and VRRP are not mutually exclusive. What you can?t have (currently) is routing information distributed by a DHCP server which may or may not actually know anything about the routing environment to which it is sending such information. > In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment. There?s no problem doing this in IPv6. You can easily statically address a system and you can easily turn off privacy addresses. You can even do that and still get your default router via RA or you can statically configure the default router address. As such, can someone please explain what is the actual missing or problematic requirement for the corporate world? Owen > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > >> -----Original Message----- >> From: Lee Howard [mailto:Lee at asgard.org] >> Sent: Friday, December 20, 2013 8:25 AM >> To: Jamie Bowden; Owen DeLong; ml at kenweb.org >> Cc: North American Network Operators' Group >> Subject: Re: turning on comcast v6 >> >> >> >> On 12/20/13 8:07 AM, "Jamie Bowden" wrote: >> >>> >>> >>>> "Parity" isn't enough information; what features are missing? RA is >>>> part >>>> of IPv6, but you don't have to use SLAAC. >>>> I'd say it's the DHC people who need to hear it, not the IPv6 people, >>>> but >>>> YMMV. >>> >>> I have a question. Why does DHCP hand out router, net mask, broadcast >>> address, etc. in IPv4; why don't we all just use RIP and be done with it? >>> >>> You don't have to like how enterprise networks are built, but you better >>> acknowledge that they are their own animal that have their own needs and >>> drivers, and telling them that the way their networks are built are wrong >>> and they need to change their whole architecture, separation of service, >>> security model, etc. to fit your idea of perfection isn't winning >>> friends. You are, however, influencing people. Perhaps not in the >>> manner you intended. >> >> So there's an interesting question. You suggest there's a disagreement >> between enterprise network operators and protocol designers. Who should >> change? >> >> I used to run an enterprise network. It was very different from an ISP >> network. I didn't say, "You're wrong!" I said, "What's missing?" >> >> There are business reasons to run IPv6. The fact that it's different than >> IPv4 is not a reason not to use it. >> >> Lee >> >>> >>> Jamie >>> >> >> From jfbeam at gmail.com Fri Dec 20 20:44:40 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 20 Dec 2013 15:44:40 -0500 Subject: turning on comcast v6 In-Reply-To: <52B4A5B9.1040601@dougbarton.us> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <52B4A5B9.1040601@dougbarton.us> Message-ID: On Fri, 20 Dec 2013 15:16:57 -0500, Doug Barton wrote: > On 12/20/2013 05:25 AM, Lee Howard wrote: >> So there's an interesting question. You suggest there's a disagreement >> between enterprise network operators and protocol designers. Who should >> change? > > Rather obviously the protocol designers, since they are clearly out of > touch with real-world requirements. RA/SLAAC was a clever idea 20 years > ago... Actually, it was "long ago abandoned" IPv4 technology... IPng didn't remember the horrible days of IPv4's ICMP Router Advertisement. (i.e. used SunOS 4, or understand *why* you touch /etc/notrouter during installation) IPv6 didn't have DHCP because the committee had a deep, genetic, hatred of DHCP. (rumor has it, saying D-H-C-P would get you removed from the WG. :-)) IPv6 is the poster child for everything that's wrong with "Designed By Committee". (too much politics and too many personal agendas) From mhuff at ox.com Fri Dec 20 20:50:12 2013 From: mhuff at ox.com (Matthew Huff) Date: Fri, 20 Dec 2013 15:50:12 -0500 Subject: turning on comcast v6 In-Reply-To: <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> Message-ID: <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> On Dec 20, 2013, at 3:23 PM, Owen DeLong wrote: > > On Dec 20, 2013, at 6:29 AM, Matthew Huff wrote: > >> With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover. > > RA and VRRP are not mutually exclusive. What you can?t have (currently) is routing information distributed by a DHCP server which may or may not actually know anything about the routing environment to which it is sending such information. > >> In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment. > > There?s no problem doing this in IPv6. You can easily statically address a system and you can easily turn off privacy addresses. You can even do that and still get your default router via RA or you can statically configure the default router address. > > As such, can someone please explain what is the actual missing or problematic requirement for the corporate world? > > Owen Reality. Owen, not all OS and especially hardware appliances (dedicated NTP appliances, UPS cards, ILO), etc... will work with RA and static addresses. They just don't. Some OS's won't disable SLAAC unless you disable autoconf on the switch. When you do that, they loose the ability to pickup RA. Some will only work with link local gateway addresses, some will only work with link global gateway addresses. There is a lot of cruft out there in the enterprise world that claims IPv6 compatibility, but in the real world doesn't work consistently. Almost all can be made to work, but require custom configuration. Far too much work for many organizations to see value in deployment. In at least on IT department I know of, IPv6 is banned because the CIO read about one of the "advantages" of IPv6 is bringing back the p2p model of IP, and most corporate management has zero interest in having any p2p connectivity within their network. For our desktop environments (Windows 7 and RHEL6) we have two different configurations on the switches on separate VLANs using SLAAC with DHPCv6 and that works fine with RA announcing the NHRP. Other equipment, not so much. From owen at delong.com Fri Dec 20 21:07:06 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Dec 2013 13:07:06 -0800 Subject: turning on comcast v6 In-Reply-To: <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> Message-ID: <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> On Dec 20, 2013, at 12:50 PM, Matthew Huff wrote: > > On Dec 20, 2013, at 3:23 PM, Owen DeLong wrote: > >> >> On Dec 20, 2013, at 6:29 AM, Matthew Huff wrote: >> >>> With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover. >> >> RA and VRRP are not mutually exclusive. What you can?t have (currently) is routing information distributed by a DHCP server which may or may not actually know anything about the routing environment to which it is sending such information. >> >>> In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment. >> >> There?s no problem doing this in IPv6. You can easily statically address a system and you can easily turn off privacy addresses. You can even do that and still get your default router via RA or you can statically configure the default router address. >> >> As such, can someone please explain what is the actual missing or problematic requirement for the corporate world? >> >> Owen > > Reality. > > Owen, not all OS and especially hardware appliances (dedicated NTP appliances, UPS cards, ILO), etc... will work with RA and static addresses. They just don't. Some OS's won't disable SLAAC unless you disable autoconf on the switch. When you Not all devices have working IPv6 stacks. OK, they?re broken, complain to the vendor and get them to fix their product or buy a working product from a different vendor. > do that, they loose the ability to pickup RA. Some will only work with link local gateway addresses, some will only work with link global gateway addresses. There is a lot of cruft out there in the enterprise world that claims IPv6 Link Local gateway addresses are required functionality in IPv6. A device which requires a global gateway address is broken. See above. > compatibility, but in the real world doesn't work consistently. Almost all can be made to work, but require custom configuration. Far too much work for many organizations to see value in deployment. In at least on IT department I know of, IPv6 is banned because the CIO read about one of the ?advantages" of IPv6 is bringing back the p2p model of IP, and most corporate management has zero interest in having any p2p connectivity within their network. IPv4 didn?t work perfectly in the beginning either. Enterprises spent many years getting vendors to correct issues with their iPv4 products and we?re just starting that process with IPv6. I?m asking what?s broken in the protocol design since that?s what the IETF can attempt to fix. > For our desktop environments (Windows 7 and RHEL6) we have two different configurations on the switches on separate VLANs using SLAAC with DHPCv6 and that works fine with RA announcing the NHRP. Other equipment, not so much. Sounds like you need to contact the vendors for that other equipment and get them to fix their IPv6 implementations. Owen From Valdis.Kletnieks at vt.edu Fri Dec 20 21:07:38 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 20 Dec 2013 16:07:38 -0500 Subject: turning on comcast v6 In-Reply-To: Your message of "Fri, 20 Dec 2013 15:50:12 -0500." <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> Message-ID: <28034.1387573658@turing-police.cc.vt.edu> On Fri, 20 Dec 2013 15:50:12 -0500, Matthew Huff said: > There is a lot of cruft out there in the enterprise > world that claims IPv6 compatibility, but in the real world doesn't work > consistently. Almost all can be made to work, but require custom configuration. The exact same thing has been said about most IPv4 equipment, but I don't see anybody yelling to get rid of IPv4 because there's *still* wonky hardware out there all these decades after adoption. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Dec 20 21:15:42 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Dec 2013 16:15:42 -0500 Subject: turning on comcast v6 In-Reply-To: <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> Message-ID: > > Not all devices have working IPv6 stacks. OK, they?re broken, complain to the vendor and get them to fix their product or buy a working product from a different vendor. > I don't know that this is a practical option... for say some systems I know that don't do v6 properly or at all, and which have buying cycles on the 10yr horizon, not 2yrs/etc. BUT... so what? you can do v4/v6 on the same LAN, right? just only use the v4 bits for those devices? I don't think 'eh, toss out your crap, buy new crap' is the right message to send. 'you can cohabitate, this isn't virginia' is though. -chris From marka at isc.org Fri Dec 20 21:51:48 2013 From: marka at isc.org (Mark Andrews) Date: Sat, 21 Dec 2013 08:51:48 +1100 Subject: turning on comcast v6 In-Reply-To: Your message of "Fri, 20 Dec 2013 16:15:42 -0500." References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> Message-ID: <20131220215148.AE92FC1C7D5@rock.dv.isc.org> In message , Christopher Morrow writes: > > > > Not all devices have working IPv6 stacks. OK, they're broken, complain > > to the vendor and get them to fix their product or buy a working product > > from a different vendor. > > > > I don't know that this is a practical option... for say some systems I > know that don't do v6 properly or at all, and which have buying cycles > on the 10yr horizon, not 2yrs/etc. And I hate to say it but people have been saying for over a decade. * request support IPv6 in the products you are purchasing. * test the IPv6 support. * report the bugs found so they can be fixed. This situation was foreseen. Too many people just left this for later and later is here now and the fixes will come too late for some. > BUT... so what? you can do v4/v6 on the same LAN, right? just only use > the v4 bits for those devices? > > I don't think 'eh, toss out your crap, buy new crap' is the right > message to send. 'you can cohabitate, this isn't virginia' is though. > > -chris -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cidr-report at potaroo.net Fri Dec 20 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Dec 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201312202200.rBKM00dM006735@wattle.apnic.net> This report has been generated at Fri Dec 20 21:13:36 2013 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 13-12-13 485835 274502 14-12-13 486126 274562 15-12-13 486152 274400 16-12-13 486445 274456 17-12-13 486333 274429 18-12-13 486595 275312 19-12-13 486898 274827 20-12-13 486354 275172 AS Summary 45927 Number of ASes in routing system 18824 Number of ASes announcing only one prefix 4201 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118834944 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 20Dec13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 487262 275096 212166 43.5% All ASes AS28573 3429 92 3337 97.3% NET Servi?os de Comunica??o S.A. AS6389 3027 56 2971 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2730 195 2535 92.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4201 1734 2467 58.7% WINDSTREAM - Windstream Communications Inc AS4766 2946 960 1986 67.4% KIXS-AS-KR Korea Telecom AS36998 1819 6 1813 99.7% SDN-MOBITEL AS1785 2146 390 1756 81.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS18881 1778 31 1747 98.3% Global Village Telecom AS10620 2691 1080 1611 59.9% Telmex Colombia S.A. AS18566 2049 565 1484 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2945 1516 1429 48.5% TWTC - tw telecom holdings, inc. AS7303 1743 466 1277 73.3% Telecom Argentina S.A. AS4755 1803 594 1209 67.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 2306 1143 1163 50.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS22561 1252 225 1027 82.0% AS22561 - CenturyTel Internet Holdings, Inc. AS7552 1205 188 1017 84.4% VIETEL-AS-AP Viettel Corporation AS9829 1557 634 923 59.3% BSNL-NIB National Internet Backbone AS35908 916 88 828 90.4% VPLSNET - Krypt Technologies AS7545 2122 1307 815 38.4% TPG-INTERNET-AP TPG Telecom Limited AS18101 990 186 804 81.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1145 388 757 66.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1508 781 727 48.2% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS8151 1380 654 726 52.6% Uninet S.A. de C.V. AS24560 1098 373 725 66.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS6983 1295 580 715 55.2% ITCDELTA - ITC^Deltacom AS13977 855 143 712 83.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS4780 1003 324 679 67.7% SEEDNET Digital United Inc. AS855 733 57 676 92.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4788 884 209 675 76.4% TMNET-AS-AP TM Net, Internet Service Provider AS6147 788 113 675 85.7% Telefonica del Peru S.A.A. Total 54344 15078 39266 72.3% Top 30 total Possible Bogus Routes 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 27.100.7.0/24 AS56096 41.76.48.0/21 AS36969 MTL-AS 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS35916 MULTA-ASN1 - MULTACOM CORPORATION 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.114.140.0/22 AS32757 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 80.250.32.0/22 AS37106 ODUA-AS 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.21.72.0/22 AS13244 103.21.75.0/24 AS13244 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 185.43.184.0/22 AS29611 ELITE-AS Elite Limited 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.22.224.0/20 AS3322 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.202.8.0/21 AS3322 193.254.218.0/23 AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC 194.34.56.0/24 AS3549 GBLX Global Crossing Ltd. 194.34.56.0/25 AS3549 GBLX Global Crossing Ltd. 194.34.56.128/26 AS3549 GBLX Global Crossing Ltd. 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 195.28.168.0/23 AS8655 195.114.4.0/23 AS41158 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.23.189.0/24 AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.32.0/24 AS25617 204.9.33.0/24 AS25617 204.9.34.0/24 AS25617 204.9.35.0/24 AS25617 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.115.110.0/23 AS53709 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.120.0/22 AS32757 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 208.92.224.0/22 AS32757 208.92.226.0/24 AS32757 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Dec 20 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Dec 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201312202200.rBKM012C006749@wattle.apnic.net> BGP Update Report Interval: 12-Dec-13 -to- 19-Dec-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 630088 23.4% 151.9 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9829 57165 2.1% 68.9 -- BSNL-NIB National Internet Backbone 3 - AS10620 39572 1.5% 21.9 -- Telmex Colombia S.A. 4 - AS8402 38391 1.4% 33.6 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS3816 34648 1.3% 86.8 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 6 - AS7029 30810 1.1% 8.0 -- WINDSTREAM - Windstream Communications Inc 7 - AS4323 27715 1.0% 20.6 -- TWTC - tw telecom holdings, inc. 8 - AS13118 23022 0.9% 523.2 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS41691 20352 0.8% 581.5 -- SUMTEL-AS-RIPE Summa Telecom LLC 10 - AS4775 19216 0.7% 295.6 -- GLOBE-TELECOM-AS Globe Telecoms 11 - AS7303 19085 0.7% 13.8 -- Telecom Argentina S.A. 12 - AS28024 17151 0.6% 27.7 -- Nuevatel PCS de Bolivia S.A. 13 - AS37492 17058 0.6% 258.5 -- ORANGE-TN 14 - AS6713 16167 0.6% 28.7 -- IAM-AS 15 - AS28573 14475 0.5% 8.9 -- NET Servi?os de Comunica??o S.A. 16 - AS59217 14294 0.5% 14294.0 -- AZONNELIMITED-AS-AP Azonne Limited 17 - AS7552 12752 0.5% 10.5 -- VIETEL-AS-AP Viettel Corporation 18 - AS11976 12203 0.5% 1355.9 -- FIDN - Fidelity Communication International Inc. 19 - AS9583 11790 0.4% 9.8 -- SIFY-AS-IN Sify Limited 20 - AS3475 10889 0.4% 139.6 -- DNIC-AS-03475 - Navy Network Information Center (NNIC) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS59217 14294 0.5% 14294.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS54465 9091 0.3% 9091.0 -- QPM-AS-1 - QuickPlay Media Inc. 3 - AS4771 3638 0.1% 3638.0 -- NZTELECOM Telecom New Zealand Ltd. 4 - AS31459 2290 0.1% 2290.0 -- BBC-RD-AS BBC 5 - AS2818 6768 0.2% 2256.0 -- BBC BBC Internet Services, UK 6 - AS30437 4470 0.2% 2235.0 -- GE-MS003 - General Electric Company 7 - AS5388 2037 0.1% 2037.0 -- ENERGIS-AS Energis UK 8 - AS22592 2027 0.1% 2027.0 -- HBP - HBP, Inc. 9 - AS62431 1966 0.1% 1966.0 -- NCSC-IE-AS National Cyber Security Centre 10 - AS45847 1894 0.1% 1894.0 -- NSTRU-AS-AP university network ,Nakornsitammarat, Thailand 11 - AS14287 10508 0.4% 1751.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 12 - AS32244 6914 0.3% 1728.5 -- LIQUID-WEB-INC - Liquid Web, Inc. 13 - AS7202 8477 0.3% 1695.4 -- FAMU - Florida A & M University 14 - AS11976 12203 0.5% 1355.9 -- FIDN - Fidelity Communication International Inc. 15 - AS55042 1344 0.1% 1344.0 -- USCONECLTD-1992 - US Conec Ltd 16 - AS52085 1301 0.1% 1301.0 -- RU-MEDVEDHOLDING-NET OOO "SKB" 17 - AS2 1094 0.0% 671.0 -- SBDC-AS The Smelly Black Dog Company Pty Ltd 18 - AS6629 10517 0.4% 1051.7 -- NOAA-AS - NOAA 19 - AS24733 764 0.0% 764.0 -- IPRI-AS Institute of Information Recording Problems of the National Academy of Science of Ukraine 20 - AS57201 736 0.0% 736.0 -- EDF-AS Estonian Defence Forces TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22899 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.164.0/22 14294 0.5% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 3 - 85.249.160.0/20 10840 0.4% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 4 - 192.58.232.0/24 10496 0.3% AS6629 -- NOAA-AS - NOAA 5 - 115.170.128.0/17 9705 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange 6 - 89.221.206.0/24 9145 0.3% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 7 - 206.152.15.0/24 9091 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 8 - 222.127.0.0/24 9054 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 9 - 120.28.62.0/24 8928 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 10 - 71.19.134.0/23 8322 0.3% AS3313 -- INET-AS BT Italia S.p.A. 11 - 193.95.93.0/24 8059 0.3% AS37492 -- ORANGE-TN 12 - 193.95.92.0/24 8008 0.3% AS37492 -- ORANGE-TN 13 - 67.210.190.0/23 6482 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 14 - 67.210.188.0/23 5712 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 15 - 168.223.206.0/23 4678 0.2% AS7202 -- FAMU - Florida A & M University 16 - 203.190.255.0/24 4650 0.2% AS24323 -- AAMRA-NETWORKS-AS-AP aamra networks limited, 17 - 165.156.25.0/24 4466 0.1% AS30437 -- GE-MS003 - General Electric Company 18 - 65.90.49.0/24 4305 0.1% AS3356 -- LEVEL3 Level 3 Communications 19 - 68.143.17.0/24 4284 0.1% AS7029 -- WINDSTREAM - Windstream Communications Inc 20 - 199.187.118.0/24 3801 0.1% AS11054 -- LIVEPERSON LivePerson, Inc 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 mhuff at ox.com Fri Dec 20 22:16:08 2013 From: mhuff at ox.com (Matthew Huff) Date: Fri, 20 Dec 2013 17:16:08 -0500 Subject: turning on comcast v6 In-Reply-To: <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> Message-ID: <75E34391-D8F2-4AE8-932F-C58F6A23149B@ox.com> Owen, Have you ever worked in a corporate environment? Replacing equipment can be a 5-7 year window and has to be justified and budgeted. Replacing a piece of equipment because it's an incomplete IPv6 implementation (which has changed considerably as it has been deployed), isn't feasible. There are a lot of things that have changed as IPv6 has been deployed such as DHCPv6 (not even talking about setting default GW via DHCP, but things such as DNS servers, DNS domain name, etc). Not all vendors especially ones in niche markets can update the firmwares that often, and certainly not unless they have a business justification. On Dec 20, 2013, at 4:07 PM, Owen DeLong wrote: > > On Dec 20, 2013, at 12:50 PM, Matthew Huff wrote: > >> >> On Dec 20, 2013, at 3:23 PM, Owen DeLong wrote: >> >>> >>> On Dec 20, 2013, at 6:29 AM, Matthew Huff wrote: >>> >>>> With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover. >>> >>> RA and VRRP are not mutually exclusive. What you can?t have (currently) is routing information distributed by a DHCP server which may or may not actually know anything about the routing environment to which it is sending such information. >>> >>>> In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment. >>> >>> There?s no problem doing this in IPv6. You can easily statically address a system and you can easily turn off privacy addresses. You can even do that and still get your default router via RA or you can statically configure the default router address. >>> >>> As such, can someone please explain what is the actual missing or problematic requirement for the corporate world? >>> >>> Owen >> >> Reality. >> >> Owen, not all OS and especially hardware appliances (dedicated NTP appliances, UPS cards, ILO), etc... will work with RA and static addresses. They just don't. Some OS's won't disable SLAAC unless you disable autoconf on the switch. When you > > Not all devices have working IPv6 stacks. OK, they?re broken, complain to the vendor and get them to fix their product or buy a working product from a different vendor. > >> do that, they loose the ability to pickup RA. Some will only work with link local gateway addresses, some will only work with link global gateway addresses. There is a lot of cruft out there in the enterprise world that claims IPv6 > > Link Local gateway addresses are required functionality in IPv6. A device which requires a global gateway address is > broken. See above. > >> compatibility, but in the real world doesn't work consistently. Almost all can be made to work, but require custom configuration. Far too much work for many organizations to see value in deployment. In at least on IT department I know of, IPv6 is banned because the CIO read about one of the ?advantages" of IPv6 is bringing back the p2p model of IP, and most corporate management has zero interest in having any p2p connectivity within their network. > > IPv4 didn?t work perfectly in the beginning either. Enterprises spent many years getting vendors to correct issues with their iPv4 products and we?re just starting that process with IPv6. > > I?m asking what?s broken in the protocol design since that?s what the IETF can attempt to fix. > > >> For our desktop environments (Windows 7 and RHEL6) we have two different configurations on the switches on separate VLANs using SLAAC with DHPCv6 and that works fine with RA announcing the NHRP. Other equipment, not so much. > > Sounds like you need to contact the vendors for that other equipment and get them to fix their IPv6 implementations. > > Owen > From mhuff at ox.com Fri Dec 20 22:27:15 2013 From: mhuff at ox.com (Matthew Huff) Date: Fri, 20 Dec 2013 17:27:15 -0500 Subject: turning on comcast v6 In-Reply-To: <20131220215148.AE92FC1C7D5@rock.dv.isc.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> <20131220215148.AE92FC1C7D5@rock.dv.isc.org> Message-ID: You can request a fully working IPv6 implementation, but it's not going to stop a purchasing if it doesn't. If you are deciding between two vendors and one is better/cheaper and doesn't have IPv6 and you choose the other, it's likely you will be looking for another job. There is no strong justification for deploying IPv6 in a corporate enterprise currently. Corporate world is focused on the next quarter, not at a 10 year horizon. We decided to roll it out for a number of reasons. One, we had time this summer. Two, we figured it would highlight inherent issues already in our environment (it did, and we found a few doozies), and finally it was a good intellectual exercise. We have it running on all over our desktops, and most of our servers (some issues with license management software and other legacy software prevents us from deploying it on all servers) If we had an orderly shutdown of our IPv6 environment, there would be zero impact to the business. In fact, due to complexity issues, it would arguably we would arguably be better off without it. Perhaps in a few years things will be different. My bet is that even in 5 years, corporate adoption will be very small, maybe as low as 10%. On Dec 20, 2013, at 4:51 PM, Mark Andrews wrote: > > In message , Christopher Morrow writes: >>> >>> Not all devices have working IPv6 stacks. OK, they're broken, complain >>> to the vendor and get them to fix their product or buy a working product >>> from a different vendor. >>> >> >> I don't know that this is a practical option... for say some systems I >> know that don't do v6 properly or at all, and which have buying cycles >> on the 10yr horizon, not 2yrs/etc. > > And I hate to say it but people have been saying for over a decade. > > * request support IPv6 in the products you are purchasing. > * test the IPv6 support. > * report the bugs found so they can be fixed. > > This situation was foreseen. Too many people just left this for > later and later is here now and the fixes will come too late for > some. > >> BUT... so what? you can do v4/v6 on the same LAN, right? just only use >> the v4 bits for those devices? >> >> I don't think 'eh, toss out your crap, buy new crap' is the right >> message to send. 'you can cohabitate, this isn't virginia' is though. >> >> -chris > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From owen at delong.com Fri Dec 20 22:36:29 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Dec 2013 14:36:29 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> <20131220215148.AE92FC1C7D5@rock.dv.isc.org> Message-ID: <9D71CBED-95C5-4A55-8951-5665DB099E8F@delong.com> On Dec 20, 2013, at 14:27 , Matthew Huff wrote: > You can request a fully working IPv6 implementation, but it's not going to stop a purchasing if it doesn't. If you are deciding between two vendors and one is better/cheaper and doesn't have IPv6 and you choose the other, it's likely you will be looking for another job. There is no strong justification for deploying IPv6 in a corporate enterprise currently. Corporate world is focused on the next quarter, not at a 10 year horizon. > Which is it? You need equipment that's right for the next 5-7 years, or, you need to focus on next quarter and not a "10 year horizon"? > We decided to roll it out for a number of reasons. One, we had time this summer. Two, we figured it would highlight inherent issues already in our environment (it did, and we found a few doozies), and finally it was a good intellectual exercise. We have it running on all over our desktops, and most of our servers (some issues with license management software and other legacy software prevents us from deploying it on all servers) This seems wise. Hopefully you're working with your vendors on getting those issues resolved. > If we had an orderly shutdown of our IPv6 environment, there would be zero impact to the business. In fact, due to complexity issues, it would arguably we would arguably be better off without it. Perhaps in a few years things will be different. My bet is that even in 5 years, corporate adoption will be very small, maybe as low as 10%. Maybe... However, what do you plan to do when your employees don't have IPv4 connectivity at home any more? That's likely going to either go away or get a lot more expensive in about 5-7 years. That's not just my prediction... Lee Howard has some pretty good information to back it up. Check out his presentation from the Denver Inet in April of this year. Owen > > > > > On Dec 20, 2013, at 4:51 PM, Mark Andrews wrote: > >> >> In message , Christopher Morrow writes: >>>> >>>> Not all devices have working IPv6 stacks. OK, they're broken, complain >>>> to the vendor and get them to fix their product or buy a working product >>>> from a different vendor. >>>> >>> >>> I don't know that this is a practical option... for say some systems I >>> know that don't do v6 properly or at all, and which have buying cycles >>> on the 10yr horizon, not 2yrs/etc. >> >> And I hate to say it but people have been saying for over a decade. >> >> * request support IPv6 in the products you are purchasing. >> * test the IPv6 support. >> * report the bugs found so they can be fixed. >> >> This situation was foreseen. Too many people just left this for >> later and later is here now and the fixes will come too late for >> some. >> >>> BUT... so what? you can do v4/v6 on the same LAN, right? just only use >>> the v4 bits for those devices? >>> >>> I don't think 'eh, toss out your crap, buy new crap' is the right >>> message to send. 'you can cohabitate, this isn't virginia' is though. >>> >>> -chris >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> > From owen at delong.com Fri Dec 20 22:33:17 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Dec 2013 14:33:17 -0800 Subject: turning on comcast v6 In-Reply-To: <75E34391-D8F2-4AE8-932F-C58F6A23149B@ox.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> <75E34391-D8F2-4AE8-932F-C58F6A23149B@ox.com> Message-ID: <22D4FEDE-6B05-462B-9624-7839070AD97E@delong.com> On Dec 20, 2013, at 14:16 , Matthew Huff wrote: > Owen, > > Have you ever worked in a corporate environment? Replacing equipment can be a 5-7 year window and has to be justified and budgeted. Replacing a piece of equipment because it's an incomplete IPv6 implementation (which has changed considerably as it has been deployed), isn't feasible. There are a lot of things that have changed as IPv6 has been deployed such as DHCPv6 (not even talking about setting default GW via DHCP, but things such as DNS servers, DNS domain name, etc). Not all vendors especially ones in niche markets can update the firmwares that often, and certainly not unless they have a business justification. Yes, I have. We've been advocating that people look at the IPv6 capabilities they need from their vendors, test, report bugs, and insist on working IPv6 implementations for more than 10 years now. The DHCPv6 RFC (3315) was published in July, 2003. DHCPv6 has not actually changed all that significantly and the provisions for DHCPv6 in RAs were standardized around the same time as RFC-3315. The most recent significant change in RAs I can come up with is RFC-6106 which is 2010, but it's entirely optional and just adds DNS search string capabilities to RFC-5006 which goes back to September, 2007. So unless you have a change you can point to that is more recent than 2007, I think we've got the 5-7 year thing pretty well covered. Owen > > > > On Dec 20, 2013, at 4:07 PM, Owen DeLong wrote: > >> >> On Dec 20, 2013, at 12:50 PM, Matthew Huff wrote: >> >>> >>> On Dec 20, 2013, at 3:23 PM, Owen DeLong wrote: >>> >>>> >>>> On Dec 20, 2013, at 6:29 AM, Matthew Huff wrote: >>>> >>>>> With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover. >>>> >>>> RA and VRRP are not mutually exclusive. What you can?t have (currently) is routing information distributed by a DHCP server which may or may not actually know anything about the routing environment to which it is sending such information. >>>> >>>>> In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment. >>>> >>>> There?s no problem doing this in IPv6. You can easily statically address a system and you can easily turn off privacy addresses. You can even do that and still get your default router via RA or you can statically configure the default router address. >>>> >>>> As such, can someone please explain what is the actual missing or problematic requirement for the corporate world? >>>> >>>> Owen >>> >>> Reality. >>> >>> Owen, not all OS and especially hardware appliances (dedicated NTP appliances, UPS cards, ILO), etc... will work with RA and static addresses. They just don't. Some OS's won't disable SLAAC unless you disable autoconf on the switch. When you >> >> Not all devices have working IPv6 stacks. OK, they?re broken, complain to the vendor and get them to fix their product or buy a working product from a different vendor. >> >>> do that, they loose the ability to pickup RA. Some will only work with link local gateway addresses, some will only work with link global gateway addresses. There is a lot of cruft out there in the enterprise world that claims IPv6 >> >> Link Local gateway addresses are required functionality in IPv6. A device which requires a global gateway address is >> broken. See above. >> >>> compatibility, but in the real world doesn't work consistently. Almost all can be made to work, but require custom configuration. Far too much work for many organizations to see value in deployment. In at least on IT department I know of, IPv6 is banned because the CIO read about one of the ?advantages" of IPv6 is bringing back the p2p model of IP, and most corporate management has zero interest in having any p2p connectivity within their network. >> >> IPv4 didn?t work perfectly in the beginning either. Enterprises spent many years getting vendors to correct issues with their iPv4 products and we?re just starting that process with IPv6. >> >> I?m asking what?s broken in the protocol design since that?s what the IETF can attempt to fix. >> >> >>> For our desktop environments (Windows 7 and RHEL6) we have two different configurations on the switches on separate VLANs using SLAAC with DHPCv6 and that works fine with RA announcing the NHRP. Other equipment, not so much. >> >> Sounds like you need to contact the vendors for that other equipment and get them to fix their IPv6 implementations. >> >> Owen >> From eric.oosting at gmail.com Fri Dec 20 22:44:47 2013 From: eric.oosting at gmail.com (Eric Oosting) Date: Fri, 20 Dec 2013 17:44:47 -0500 Subject: turning on comcast v6 In-Reply-To: <75E34391-D8F2-4AE8-932F-C58F6A23149B@ox.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> <75E34391-D8F2-4AE8-932F-C58F6A23149B@ox.com> Message-ID: On Fri, Dec 20, 2013 at 5:16 PM, Matthew Huff wrote: > Owen, > > Have you ever worked in a corporate environment? Replacing equipment can > be a 5-7 year window and has to be justified and budgeted. Replacing a > piece of equipment because it's an incomplete IPv6 implementation (which > has changed considerably as it has been deployed), isn't feasible. Not to put words in Owen's mouth, but let me explain how I interpret what he was saying: Vote with your feet. It's simple ... maybe you can't replace everything in your network that doesn't support IPv6, ( I wish we all had that kind of discretionary budgets) but you can still base purchasing decisions on IPv6 support, and by and large, that isn't happening. Enterprise purchasing just isn't driven by IPv6 features ... if anything, its a check box feature for vendors and ignored by decision makers. Until the enterprise says to the widget salesperson: "i'm not buying this until and unless you truly commit to supporting IPv6" we're stuck where we are. We don't necessarily need you to replace everything in your network that doesn't support it today, we need you to not put a single thing in your network new, or used, that doesn't. Believe me, the vendors will get the message and suddenly even the legacy stuff will start to be fixed. Remember what a PITA it was to get novel to support IPv4? They didn't do it until they had to. -e > There are a lot of things that have changed as IPv6 has been deployed > such as DHCPv6 (not even talking about setting default GW via DHCP, but > things such as DNS servers, DNS domain name, etc). Not all vendors > especially ones in niche markets can update the firmwares that often, and > certainly not unless they have a business justification. > > > > On Dec 20, 2013, at 4:07 PM, Owen DeLong wrote: > > > > > On Dec 20, 2013, at 12:50 PM, Matthew Huff wrote: > > > >> > >> On Dec 20, 2013, at 3:23 PM, Owen DeLong wrote: > >> > >>> > >>> On Dec 20, 2013, at 6:29 AM, Matthew Huff wrote: > >>> > >>>> With RA, what is the smallest interval failover will work? Compare > that with NHRP such as HSRP, VRRP, etc with sub-second failover. > >>> > >>> RA and VRRP are not mutually exclusive. What you can?t have > (currently) is routing information distributed by a DHCP server which may > or may not actually know anything about the routing environment to which it > is sending such information. > >>> > >>>> In corporate networks most of the non-client systems will be > statically addressed with privacy addresses turned off. This is for > regulatory, audit, security and monitoring requirement. One of the many > challenges of ipv6 in a corporate environment. > >>> > >>> There?s no problem doing this in IPv6. You can easily statically > address a system and you can easily turn off privacy addresses. You can > even do that and still get your default router via RA or you can statically > configure the default router address. > >>> > >>> As such, can someone please explain what is the actual missing or > problematic requirement for the corporate world? > >>> > >>> Owen > >> > >> Reality. > >> > >> Owen, not all OS and especially hardware appliances (dedicated NTP > appliances, UPS cards, ILO), etc... will work with RA and static addresses. > They just don't. Some OS's won't disable SLAAC unless you disable autoconf > on the switch. When you > > > > Not all devices have working IPv6 stacks. OK, they?re broken, complain > to the vendor and get them to fix their product or buy a working product > from a different vendor. > > > >> do that, they loose the ability to pickup RA. Some will only work with > link local gateway addresses, some will only work with link global gateway > addresses. There is a lot of cruft out there in the enterprise world that > claims IPv6 > > > > Link Local gateway addresses are required functionality in IPv6. A > device which requires a global gateway address is > > broken. See above. > > > >> compatibility, but in the real world doesn't work consistently. Almost > all can be made to work, but require custom configuration. Far too much > work for many organizations to see value in deployment. In at least on IT > department I know of, IPv6 is banned because the CIO read about one of the > ?advantages" of IPv6 is bringing back the p2p model of IP, and most > corporate management has zero interest in having any p2p connectivity > within their network. > > > > IPv4 didn?t work perfectly in the beginning either. Enterprises spent > many years getting vendors to correct issues with their iPv4 products and > we?re just starting that process with IPv6. > > > > I?m asking what?s broken in the protocol design since that?s what the > IETF can attempt to fix. > > > > > >> For our desktop environments (Windows 7 and RHEL6) we have two > different configurations on the switches on separate VLANs using SLAAC with > DHPCv6 and that works fine with RA announcing the NHRP. Other equipment, > not so much. > > > > Sounds like you need to contact the vendors for that other equipment and > get them to fix their IPv6 implementations. > > > > Owen > > > > > From tb at tburke.us Fri Dec 20 20:15:54 2013 From: tb at tburke.us (Tim Burke) Date: Fri, 20 Dec 2013 14:15:54 -0600 Subject: Verizon mail IP blacklist contact? Message-ID: <52B4A57A.1050108@tburke.us> Anyone happen to have a contact at Verizon that can actually get an IP delisted in their mail blacklist? I've been attempting to get an IP delisted with Verizon for quite some time, and haven't had luck through their web form ( http://my.verizon.com/micro/whitelist/RequestForm.aspx?id=isp), their abuse address, etc. Their autoresponder claims the IP is a dynamic address, when this range is considered static with SORBS, Spamhaus, etc. --Tim From jra at baylink.com Sat Dec 21 04:21:08 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 20 Dec 2013 23:21:08 -0500 (EST) Subject: 5.7 *report In-Reply-To: <13d801cefdb4$4cbf9e50$e63edaf0$@athenet.net> Message-ID: <8556186.1378.1387599668071.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mike Schwartz" > That urks me, too. In many web sites that have a state field, you can > at least type the first letter of your state, but you still have to use the > mouse, unless your state is the first one that starts with any given > letter. > When I type "W", "WA" pops up, so I still have to use the mouse to > select "WI". If I try to type "W" then "I", the popup box jumps to "IA". > > For example, jump to the state field on this website: > > https://www.tigerdirect.com/secure/subscribe2.asp?cm_sp=Masthead-_-NewCustom > er-_-NA > > "W" takes me to "Washington", but if I then type "I" it takes me down > to "International". I can avoid using my mouse if I type "W" and then > down arrow twice, to get past West Virginia. The widget is "pulldown menu with incremental search", and the question is "did they allow multiple character search input" and, as a sub query "how long after you hit a character does the hidden input field reset if you don't hit enter". Seems to me that Jeff Harrison coded a decent incremental search wrapped around a browse lookup at one point ... or maybe it was Ron Klimasewski, one of Microsys's other coders in the 90s. It's been a long time... It's odd, when I have to do maintenance work on tables all three of us had our fingers in, I can tell which of the three of us worked on a given routine; we each had a different view of 1TBS. :-) Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From philfagan at gmail.com Sat Dec 21 05:06:54 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 20 Dec 2013 22:06:54 -0700 Subject: Watchguards vs Junipers firewalls In-Reply-To: <00fb01cefc0b$57cdfbc0$0769f340$@blueyonder.co.uk> References: <00fb01cefc0b$57cdfbc0$0769f340$@blueyonder.co.uk> Message-ID: SRX650 IDP caps at 1gb imix; BGP and OSPF in cluster won't be a problem...but your running up against resource limits if you need to grow. Juniper has a good write up on active active SRX deployments and offer 3gb IDP imix on the 1400. From henry at AegisInfoSys.com Sat Dec 21 05:24:48 2013 From: henry at AegisInfoSys.com (Henry Yen) Date: Sat, 21 Dec 2013 00:24:48 -0500 Subject: 5.7 *report In-Reply-To: <8556186.1378.1387599668071.JavaMail.root@benjamin.baylink.com> References: <13d801cefdb4$4cbf9e50$e63edaf0$@athenet.net> <8556186.1378.1387599668071.JavaMail.root@benjamin.baylink.com> Message-ID: <20131221052447.GW16284@nntp.AegisInfoSys.com> On Fri, Dec 20, 2013 at 23:21:08PM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Mike Schwartz" > > > That urks me, too. In many web sites that have a state field, you can > > at least type the first letter of your state, but you still have to use the > > mouse, unless your state is the first one that starts with any given > > letter. > > When I type "W", "WA" pops up, so I still have to use the mouse to > > select "WI". If I try to type "W" then "I", the popup box jumps to "IA". > > "W" takes me to "Washington", but if I then type "I" it takes me down > > to "International". I can avoid using my mouse if I type "W" and then > > down arrow twice, to get past West Virginia. FWIW for this apparently errant thread, just hit "W" two more times. That is, those select-a-state boxes will usually cycle through all of the listed choices that begin with a selected letter by repeatedly pressing that letter (on a real keyboard, probably not on a smartphone virtual one). -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700) From owen at delong.com Sat Dec 21 20:54:07 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 21 Dec 2013 12:54:07 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <483E6B0272B0284BA86D7596C40D29F902212D9D4ECC@PUR-EXCH07.ox.com> <6CEF1F06-E96B-42D0-874F-F30EA93BD667@delong.com> <653B375D-82F7-4A7F-9739-9F118BF3D7EA@ox.com> <21D7E22B-CE29-476A-8ED7-5FD321429D60@delong.com> <75E34391-D8F2-4AE8-932F-C58F6A23149B@ox.com> Message-ID: On Dec 20, 2013, at 14:44 , Eric Oosting wrote: > > On Fri, Dec 20, 2013 at 5:16 PM, Matthew Huff wrote: > Owen, > > Have you ever worked in a corporate environment? Replacing equipment can be a 5-7 year window and has to be justified and budgeted. Replacing a piece of equipment because it's an incomplete IPv6 implementation (which has changed considerably as it has been deployed), isn't feasible. > > Not to put words in Owen's mouth, but let me explain how I interpret what he was saying: Vote with your feet. > > It's simple ... maybe you can't replace everything in your network that doesn't support IPv6, ( I wish we all had that kind of discretionary budgets) but you can still base purchasing decisions on IPv6 support, and by and large, that isn't happening. Enterprise purchasing just isn't driven by IPv6 features ... if anything, its a check box feature for vendors and ignored by decision makers. > > Until the enterprise says to the widget salesperson: "i'm not buying this until and unless you truly commit to supporting IPv6" we're stuck where we are. > > We don't necessarily need you to replace everything in your network that doesn't support it today, we need you to not put a single thing in your network new, or used, that doesn't. Believe me, the vendors will get the message and suddenly even the legacy stuff will start to be fixed. Remember what a PITA it was to get novel to support IPv4? They didn't do it until they had to. > > -e > Absolutely correct interpretation of my statement. Owen From mpetach at netflight.com Sun Dec 22 03:55:48 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 21 Dec 2013 19:55:48 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: On Fri, Dec 20, 2013 at 5:25 AM, Lee Howard wrote: > > > On 12/20/13 8:07 AM, "Jamie Bowden" wrote: > > > > > > >> "Parity" isn't enough information; what features are missing? RA is > >>part > >> of IPv6, but you don't have to use SLAAC. > >> I'd say it's the DHC people who need to hear it, not the IPv6 people, > >>but > >> YMMV. > > > >I have a question. Why does DHCP hand out router, net mask, broadcast > >address, etc. in IPv4; why don't we all just use RIP and be done with it? > > > >You don't have to like how enterprise networks are built, but you better > >acknowledge that they are their own animal that have their own needs and > >drivers, and telling them that the way their networks are built are wrong > >and they need to change their whole architecture, separation of service, > >security model, etc. to fit your idea of perfection isn't winning > >friends. You are, however, influencing people. Perhaps not in the > >manner you intended. > > So there's an interesting question. You suggest there's a disagreement > between enterprise network operators and protocol designers. Who should > change? > > I used to run an enterprise network. It was very different from an ISP > network. I didn't say, "You're wrong!" I said, "What's missing?" > default route information via DHCPv6. That's what I'm still waiting for. Matt From wbailey at satelliteintelligencegroup.com Sun Dec 22 23:42:03 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 22 Dec 2013 23:42:03 +0000 Subject: Netflix Advice Message-ID: Dear NANOG Gods, Has anyone heard of a nifty way to cache the netflix library without using their Open Connect Appliance? I am not trying to dodge copyrights, or even dodge the netflix service, I am simply trying to find a way to store the netflix library remotely for users behind satellite connections. If any of you have figured this out, or if there is a Netflix person out there listening, feel free to contact me offline. Thanks a lot, and have a Merry Christmas! //warren From rps at maine.edu Mon Dec 23 15:18:55 2013 From: rps at maine.edu (Ray Soucy) Date: Mon, 23 Dec 2013 10:18:55 -0500 Subject: Vyatta to VyOS Message-ID: Many here might be interested, In response to Brocade not giving the community edition of Vyatta much attention recently, some of the more active community members have created a fork of the GPL code used in Vyatta. It's called VyOS, and yesterday they released 1.0. http://vyos.net/ I've been playing with the development builds and it seems to be every bit as stable as the Vyatta releases. Will be interesting to see how the project unfolds :-) -- 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 brandon.galbraith at gmail.com Mon Dec 23 16:37:02 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 23 Dec 2013 10:37:02 -0600 Subject: Netflix Advice In-Reply-To: References: Message-ID: Are you looking to cache it at your ground station? Or on the client side? brandon On Sun, Dec 22, 2013 at 5:42 PM, Warren Bailey wrote: > Dear NANOG Gods, > > Has anyone heard of a nifty way to cache the netflix library without using their Open Connect Appliance? I am not trying to dodge copyrights, or even dodge the netflix service, I am simply trying to find a way to store the netflix library remotely for users behind satellite connections. If any of you have figured this out, or if there is a Netflix person out there listening, feel free to contact me offline. > > Thanks a lot, and have a Merry Christmas! > > //warren From wbailey at satelliteintelligencegroup.com Mon Dec 23 17:19:54 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 23 Dec 2013 17:19:54 +0000 Subject: Netflix Advice In-Reply-To: References: , Message-ID: Client/remote side. Sent from my Mobile Device. -------- Original message -------- From: Brandon Galbraith Date: 12/23/2013 7:37 AM (GMT-09:00) To: Warren Bailey Cc: NANOG Subject: Re: Netflix Advice Are you looking to cache it at your ground station? Or on the client side? brandon On Sun, Dec 22, 2013 at 5:42 PM, Warren Bailey wrote: > Dear NANOG Gods, > > Has anyone heard of a nifty way to cache the netflix library without using their Open Connect Appliance? I am not trying to dodge copyrights, or even dodge the netflix service, I am simply trying to find a way to store the netflix library remotely for users behind satellite connections. If any of you have figured this out, or if there is a Netflix person out there listening, feel free to contact me offline. > > Thanks a lot, and have a Merry Christmas! > > //warren From scott at doc.net.au Mon Dec 23 18:45:18 2013 From: scott at doc.net.au (Scott Howard) Date: Mon, 23 Dec 2013 10:45:18 -0800 Subject: Vyatta to VyOS In-Reply-To: References: Message-ID: Who wants to tell them that it's really 2013? News 22 Dec *2012* Version 1.0.0 (hydrogen) released. Scott On Mon, Dec 23, 2013 at 7:18 AM, Ray Soucy wrote: > Many here might be interested, > > In response to Brocade not giving the community edition of Vyatta much > attention recently, some of the more active community members have created > a fork of the GPL code used in Vyatta. > > It's called VyOS, and yesterday they released 1.0. > > http://vyos.net/ > > I've been playing with the development builds and it seems to be every bit > as stable as the Vyatta releases. > > Will be interesting to see how the project unfolds :-) > > -- > 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 nrollo at kw-corp.com Mon Dec 23 19:18:13 2013 From: nrollo at kw-corp.com (Nolan Rollo) Date: Mon, 23 Dec 2013 19:18:13 +0000 Subject: Vyatta to VyOS In-Reply-To: References: Message-ID: <8eb537889c5c42a2ac33537dd30b248b@KWMAIL.local.kw-corp.com> I wonder how Ubiquiti Networks is going to react to this since their EdgeMax Routers run a fork of the Vyatta code (EdgeOS). http://community.ubnt.com/t5/EdgeMAX/Vyatta-Community-Edition-dead/m-p/591487/highlight/true#M16059 It looks like there is a post in the form where a UBNT Employee said that they were working directly with the VyOS guys. In this case I wonder what other commercial vendor is going to jump on the open source bandwagon. -----Original Message----- From: Scott Howard [mailto:scott at doc.net.au] Sent: Monday, December 23, 2013 1:45 PM To: Ray Soucy Cc: NANOG Subject: Re: Vyatta to VyOS Who wants to tell them that it's really 2013? News 22 Dec *2012* Version 1.0.0 (hydrogen) released. Scott On Mon, Dec 23, 2013 at 7:18 AM, Ray Soucy wrote: > Many here might be interested, > > In response to Brocade not giving the community edition of Vyatta much > attention recently, some of the more active community members have > created a fork of the GPL code used in Vyatta. > > It's called VyOS, and yesterday they released 1.0. > > http://vyos.net/ > > I've been playing with the development builds and it seems to be every > bit as stable as the Vyatta releases. > > Will be interesting to see how the project unfolds :-) > > -- > 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 josh.hoppes at gmail.com Mon Dec 23 21:37:10 2013 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Mon, 23 Dec 2013 15:37:10 -0600 Subject: Vyatta to VyOS In-Reply-To: <8eb537889c5c42a2ac33537dd30b248b@KWMAIL.local.kw-corp.com> References: <8eb537889c5c42a2ac33537dd30b248b@KWMAIL.local.kw-corp.com> Message-ID: Ubiquiti has been contributing to VyOS, so I'm assuming it is the version they are using as the upstream for their code. On Mon, Dec 23, 2013 at 1:18 PM, Nolan Rollo wrote: > I wonder how Ubiquiti Networks is going to react to this since their EdgeMax Routers run a fork of the Vyatta code (EdgeOS). > > http://community.ubnt.com/t5/EdgeMAX/Vyatta-Community-Edition-dead/m-p/591487/highlight/true#M16059 > > It looks like there is a post in the form where a UBNT Employee said that they were working directly with the VyOS guys. In this case I wonder what other commercial vendor is going to jump on the open source bandwagon. > > -----Original Message----- > From: Scott Howard [mailto:scott at doc.net.au] > Sent: Monday, December 23, 2013 1:45 PM > To: Ray Soucy > Cc: NANOG > Subject: Re: Vyatta to VyOS > > Who wants to tell them that it's really 2013? > > News > 22 Dec *2012* > Version 1.0.0 (hydrogen) released. > > > Scott > > > > On Mon, Dec 23, 2013 at 7:18 AM, Ray Soucy wrote: > >> Many here might be interested, >> >> In response to Brocade not giving the community edition of Vyatta much >> attention recently, some of the more active community members have >> created a fork of the GPL code used in Vyatta. >> >> It's called VyOS, and yesterday they released 1.0. >> >> http://vyos.net/ >> >> I've been playing with the development builds and it seems to be every >> bit as stable as the Vyatta releases. >> >> Will be interesting to see how the project unfolds :-) >> >> -- >> 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 zach at zachunderwood.me Mon Dec 23 21:49:07 2013 From: zach at zachunderwood.me (Zach Underwood) Date: Mon, 23 Dec 2013 16:49:07 -0500 Subject: Vyatta to VyOS In-Reply-To: References: <8eb537889c5c42a2ac33537dd30b248b@KWMAIL.local.kw-corp.com> Message-ID: Can I just say this is why I love FOSS. I will be testing VyOS on some of my vyatta routes after the holidays. On Mon, Dec 23, 2013 at 4:37 PM, Josh Hoppes wrote: > Ubiquiti has been contributing to VyOS, so I'm assuming it is the > version they are using as the upstream for their code. > > On Mon, Dec 23, 2013 at 1:18 PM, Nolan Rollo wrote: > > I wonder how Ubiquiti Networks is going to react to this since their > EdgeMax Routers run a fork of the Vyatta code (EdgeOS). > > > > > http://community.ubnt.com/t5/EdgeMAX/Vyatta-Community-Edition-dead/m-p/591487/highlight/true#M16059 > > > > It looks like there is a post in the form where a UBNT Employee said > that they were working directly with the VyOS guys. In this case I wonder > what other commercial vendor is going to jump on the open source bandwagon. > > > > -----Original Message----- > > From: Scott Howard [mailto:scott at doc.net.au] > > Sent: Monday, December 23, 2013 1:45 PM > > To: Ray Soucy > > Cc: NANOG > > Subject: Re: Vyatta to VyOS > > > > Who wants to tell them that it's really 2013? > > > > News > > 22 Dec *2012* > > Version 1.0.0 (hydrogen) released. > > > > > > Scott > > > > > > > > On Mon, Dec 23, 2013 at 7:18 AM, Ray Soucy wrote: > > > >> Many here might be interested, > >> > >> In response to Brocade not giving the community edition of Vyatta much > >> attention recently, some of the more active community members have > >> created a fork of the GPL code used in Vyatta. > >> > >> It's called VyOS, and yesterday they released 1.0. > >> > >> http://vyos.net/ > >> > >> I've been playing with the development builds and it seems to be every > >> bit as stable as the Vyatta releases. > >> > >> Will be interesting to see how the project unfolds :-) > >> > >> -- > >> 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 > >> > > > > -- Zach Underwood (RHCE,RHCSA,RHCT,UACA) My website From dave at temk.in Tue Dec 24 03:14:24 2013 From: dave at temk.in (David Temkin) Date: Mon, 23 Dec 2013 22:14:24 -0500 Subject: Netflix Advice In-Reply-To: References: Message-ID: Hi Warren, Unfortunately there's no way to cache at the client end on servers that we do not control for various reasons (not all technical). You can reach out to me at dtemkin(at)netflix.com if you'd like to discuss further. Regards, -Dave On Mon, Dec 23, 2013 at 12:19 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Client/remote side. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Brandon Galbraith > Date: 12/23/2013 7:37 AM (GMT-09:00) > To: Warren Bailey > Cc: NANOG > Subject: Re: Netflix Advice > > > Are you looking to cache it at your ground station? Or on the client side? > > brandon > > On Sun, Dec 22, 2013 at 5:42 PM, Warren Bailey > wrote: > > Dear NANOG Gods, > > > > Has anyone heard of a nifty way to cache the netflix library without > using their Open Connect Appliance? I am not trying to dodge copyrights, or > even dodge the netflix service, I am simply trying to find a way to store > the netflix library remotely for users behind satellite connections. If any > of you have figured this out, or if there is a Netflix person out there > listening, feel free to contact me offline. > > > > Thanks a lot, and have a Merry Christmas! > > > > //warren > From herro91 at gmail.com Tue Dec 24 17:50:02 2013 From: herro91 at gmail.com (Herro91) Date: Tue, 24 Dec 2013 12:50:02 -0500 Subject: Juniper MAG/SA question - re: split tunneling policy and use of JSAM/WSAM Message-ID: Hello J-NSP and Nanog members Hopefully this is the right forum for this discussion - if not my apologies for further clogging your inbox. Here it goes: Would you consider use of JSAM/WSAM to selectively proxy and tunnel certain applications a form of split tunneling? The traditional concept of split tunnels looks at all traffic Layer 3 and above, versus JSAM/WSAM which looks at application traffic at Layer 7. The context for all of this is from a previous question I put out regarding split tunneling policy on government networks. Thanks! From sam at circlenet.us Tue Dec 24 23:16:59 2013 From: sam at circlenet.us (Sam Moats) Date: Tue, 24 Dec 2013 18:16:59 -0500 Subject: Help me make sense of these traceroutes please Message-ID: Hello Nanog community, I would like to enlist your help with understanding this latency I'm seeing. First some background, I have Level3 circuits in the US and some services in Europe. From Comcast to the US level3 IPs the performance is excellent. The same traceroute to Europe is terrible. The strange part is the problem appears to begin stateside on the same infrastructure that carriers the us traffic. Here is a trace to one of my IPs in the US from Comcast Tracing route to 4.30.x.x over a maximum of 30 hops 1 3 ms 1 ms 1 ms 10.1.1.1 2 30 ms 29 ms 29 ms 71.62.150.1 3 9 ms 9 ms 9 ms xe-0-1-0-32767-sur01.winchester.va.richmond.comc ast.net [68.85.71.165] 4 9 ms 14 ms 10 ms xe-9-0-3-0-ar02.staplesmllrd.va.richmond.comcast .net [68.86.125.149] 5 32 ms 30 ms 34 ms 68.86.91.153 6 36 ms 38 ms 53 ms 23.30.207.98 7 34 ms 28 ms 33 ms vlan51.ebr1.Atlanta2.Level3.net [4.69.150.62] 8 29 ms 28 ms 20 ms ae-63-63.ebr3.Atlanta2.Level3.net [4.69.148.241] 9 27 ms 29 ms 30 ms ae-2-2.ebr1.Washington1.Level3.net [4.69.132.86] 10 24 ms 30 ms 24 ms ae-71-71.csw2.Washington1.Level3.net [4.69.134.1 34] 11 29 ms 31 ms 39 ms ae-41-90.car1.Washington1.Level3.net [4.69.149.1 95] 12 30 ms 30 ms 29 ms ae-2-23.edge7.Washington1.Level3.net [4.68.106.2 38] 13 38 ms 44 ms 43 ms 4.79.x.x 14 * * * Request timed out. (My firewall) 15 39 ms 39 ms 39 ms 4.30.x.x Trace complete. Now here is the same computer tracing to a level3 circuit in Ireland. Tracing route to xxx.yyy.ie [193.1.x.x] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms 10.1.1.1 2 38 ms 33 ms 25 ms 71.62.150.1 3 10 ms 9 ms 9 ms xe-0-1-0-32767-sur01.winchester.va.richmond.comc ast.net [68.85.71.165] 4 14 ms 15 ms 15 ms xe-9-0-3-0-ar02.staplesmllrd.va.richmond.comcast .net [68.86.125.149] 5 28 ms 30 ms 30 ms 68.86.95.65 6 37 ms 37 ms 37 ms 23.30.207.98 7 118 ms * 218 ms vlan51.ebr1.Atlanta2.Level3.net [4.69.150.62] 8 119 ms 218 ms 119 ms ae-63-63.ebr3.Atlanta2.Level3.net [4.69.148.241] 9 221 ms 119 ms 119 ms ae-2-2.ebr1.Washington1.Level3.net [4.69.132.86] 10 118 ms 119 ms 118 ms ae-91-91.csw4.Washington1.Level3.net [4.69.134.1 42] 11 119 ms 119 ms 119 ms ae-92-92.ebr2.Washington1.Level3.net [4.69.134.1 57] 12 117 ms 126 ms 120 ms ae-43-43.ebr2.Paris1.Level3.net [4.69.137.57] 13 128 ms 118 ms 120 ms ae-6-6.car1.Dublin3.Level3.net [4.69.148.53] 14 122 ms 225 ms 124 ms 4.69.148.58 15 124 ms 118 ms 120 ms ae-11-11.car1.Dublin1.Level3.net [4.69.136.93] Notice that the hop from 23.30.207.98 to 4.69.150.62 seems very respectable at around 30ms for US bound traffic. However when I'm tracing from the same Comcast network to an IP that is in Europe the very same hope produces 100ms of latency and about 12% packet loss. Why does this hop treat traffic differently based on it's destination? Is this some weird result of complex asymmetrical routing or something else? I can route around this problem, but it does seem strange and I want to understand it Thanks, Sam Moats From ryan at finnesey.com Tue Dec 24 05:34:37 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Tue, 24 Dec 2013 05:34:37 +0000 Subject: Merry Christmas Message-ID: Wanted to wish everyone a Marry Christmas and all the best in the New Year! Cheers Ryan From jeroen at massar.ch Tue Dec 24 23:55:46 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 25 Dec 2013 00:55:46 +0100 Subject: Help me make sense of these traceroutes please In-Reply-To: References: Message-ID: <52BA1F02.2070505@massar.ch> On 2013-12-25 00:16, Sam Moats wrote: > Hello Nanog community, > I would like to enlist your help with understanding this latency I'm > seeing. You are likely seeing the effects of asymmetric routing. [..] > Tracing route to xxx.yyy.ie [193.1.x.x] www.heanet.ie by chance? :) Though you could use for instance: http://planchet.heanet.ie/toolkit/gui/reverse_traceroute.cgi to do a reverse traceroute, do make sure you force your connectivity to IPv4 as that host will do IPv6 too. (locally nullrouting the destination /128 is the trick I use for 'disabling' IPv6 temporarily). Otherwise the HEANET folks are extremely helpful and clued in, you can always ask them for help with issues. It is the end-of-year though and those Irish folks have lots of really good whiskey, Guinness thus you might have to be patient till the new year. Alternatively, you could use a tool like 'tracepath' or 'mtr' as those reports multiple answers to a response and also check for the TTL on the return packets. Greets, Jeroen From sam at circlenet.us Wed Dec 25 00:03:02 2013 From: sam at circlenet.us (Sam Moats) Date: Tue, 24 Dec 2013 19:03:02 -0500 Subject: Help me make sense of these traceroutes please In-Reply-To: <52BA1F02.2070505@massar.ch> References: <52BA1F02.2070505@massar.ch> Message-ID: <5981f7e5a68abdfa9aaf007924e86596@www.circlenet.us> On 2013-12-24 18:55, Jeroen Massar wrote: > On 2013-12-25 00:16, Sam Moats wrote: >> Hello Nanog community, >> I would like to enlist your help with understanding this latency I'm >> seeing. > > You are likely seeing the effects of asymmetric routing. That's what I was thinking to. > > [..] >> Tracing route to xxx.yyy.ie [193.1.x.x] > > www.heanet.ie by chance? :) Yes they were the owners of the IP I used for the example case and the heanet folks are actually totally awesome :-) > > Though you could use for instance: > http://planchet.heanet.ie/toolkit/gui/reverse_traceroute.cgi > > to do a reverse traceroute, do make sure you force your connectivity > to > IPv4 as that host will do IPv6 too. (locally nullrouting the > destination > /128 is the trick I use for 'disabling' IPv6 temporarily). > > Otherwise the HEANET folks are extremely helpful and clued in, you > can > always ask them for help with issues. It is the end-of-year though > and > those Irish folks have lots of really good whiskey, Guinness thus you > might have to be patient till the new year. Also you'd be amazed how many network issues can be solved with a bunch of IT folks and an ample supply of Guinness > > Alternatively, you could use a tool like 'tracepath' or 'mtr' as > those > reports multiple answers to a response and also check for the TTL on > the > return packets. > > Greets, > Jeroen Thanks, this isn't affecting my service now I've worked around it so it's more a curiosity than anything. It seems really odd to me that the same L3 edge router would route the ICMP unreachable back to me via different paths based on the final destination IP of the of the ICMP echo packet. Well its Christmas eve here and the customers are happy so Guinness seems like the best approach now :-) Thanks and have a good Holiday, Sam Moats From pmsac.nanog at gmail.com Wed Dec 25 00:49:30 2013 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Wed, 25 Dec 2013 00:49:30 +0000 Subject: Help me make sense of these traceroutes please In-Reply-To: <5981f7e5a68abdfa9aaf007924e86596@www.circlenet.us> References: <52BA1F02.2070505@massar.ch> <5981f7e5a68abdfa9aaf007924e86596@www.circlenet.us> Message-ID: On 25 December 2013 00:03, Sam Moats wrote: > On 2013-12-24 18:55, Jeroen Massar wrote: > >> On 2013-12-25 00:16, Sam Moats wrote: >> >>> Hello Nanog community, >>> I would like to enlist your help with understanding this latency I'm >>> seeing. >>> >> >> You are likely seeing the effects of asymmetric routing. >> > > That's what I was thinking to. > > >> [..] >> >>> Tracing route to xxx.yyy.ie [193.1.x.x] >>> >> >> www.heanet.ie by chance? :) >> > > Yes they were the owners of the IP I used for the example case and the > heanet folks are actually totally awesome :-) > > > >> Though you could use for instance: >> http://planchet.heanet.ie/toolkit/gui/reverse_traceroute.cgi >> >> to do a reverse traceroute, do make sure you force your connectivity to >> IPv4 as that host will do IPv6 too. (locally nullrouting the destination >> /128 is the trick I use for 'disabling' IPv6 temporarily). >> >> Otherwise the HEANET folks are extremely helpful and clued in, you can >> always ask them for help with issues. It is the end-of-year though and >> those Irish folks have lots of really good whiskey, Guinness thus you >> might have to be patient till the new year. >> > > Also you'd be amazed how many network issues can be solved with a bunch of > IT folks and an ample supply of Guinness > > > >> Alternatively, you could use a tool like 'tracepath' or 'mtr' as those >> reports multiple answers to a response and also check for the TTL on the >> return packets. >> >> Greets, >> Jeroen >> > > Thanks, this isn't affecting my service now I've worked around it so it's > more a curiosity than anything. It seems really odd to me that the same L3 > edge router would route the ICMP unreachable back to me via different paths > based on the final destination IP of the of the ICMP echo packet. > > Based on the data you provided, my guess is some kind of MPLS transport (please refer to https://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf, pages 46-48). HTH. > Well its Christmas eve here and the customers are happy so Guinness seems > like the best approach now :-) > > Thanks and have a good Holiday, > Sam Moats > > > From m.hotze at hotze.com Wed Dec 25 14:03:45 2013 From: m.hotze at hotze.com (Martin Hotze) Date: Wed, 25 Dec 2013 14:03:45 +0000 Subject: Help me make sense of these traceroutes please Message-ID: > From: Jeroen Massar > To: sam at circlenet.us, nanog at nanog.org > Subject: Re: Help me make sense of these traceroutes please > > On 2013-12-25 00:16, Sam Moats wrote: > > Hello Nanog community, > > I would like to enlist your help with understanding this latency I'm > > seeing. > > You are likely seeing the effects of asymmetric routing. . .. or the effect of passing traffic through NSA infrastructure. SCNR, #m From mysidia at gmail.com Wed Dec 25 15:28:28 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 25 Dec 2013 09:28:28 -0600 Subject: Help me make sense of these traceroutes please In-Reply-To: References: Message-ID: On Wed, Dec 25, 2013 at 8:03 AM, Martin Hotze wrote: > > > On 2013-12-25 00:16, Sam Moats wrote: > ... > > You are likely seeing the effects of asymmetric routing. > . .. or the effect of passing traffic through NSA infrastructure. > > Ah... NSA. That's probably it. So much for my theory of a Router virtual chassis straddling the atlantic. or the extra kinetic energy carried by the overseas-bound packet took longer for the router to absorb and rebound with an ICMP. But in all seriousness --- what is probably happening here, is the result of extra "hops" that don't show up in traceroute. MPLS tunnels could well fit the bill. Other things to consider when latency seems sensitive to destination IP --- are preceding device in the traceroute might also have multiple links to the same device; with one link congested and some form of IP-based load sharing, that happens to be the toward-overseas link. > SCNR, #m -- -JH From Valdis.Kletnieks at vt.edu Wed Dec 25 15:47:09 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 25 Dec 2013 10:47:09 -0500 Subject: Help me make sense of these traceroutes please In-Reply-To: Your message of "Tue, 24 Dec 2013 19:03:02 -0500." <5981f7e5a68abdfa9aaf007924e86596@www.circlenet.us> References: <52BA1F02.2070505@massar.ch> <5981f7e5a68abdfa9aaf007924e86596@www.circlenet.us> Message-ID: <182610.1387986429@turing-police.cc.vt.edu> On Tue, 24 Dec 2013 19:03:02 -0500, Sam Moats said: > Also you'd be amazed how many network issues can be solved with a bunch > of IT folks and an ample supply of Guinness I once heard the claim that if you couldn't explain your network design and have the listener understand it after you had split a pitcher of Guiness, it was probably too complicated. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From johnl at iecc.com Wed Dec 25 16:35:40 2013 From: johnl at iecc.com (John Levine) Date: 25 Dec 2013 16:35:40 -0000 Subject: What's going on with NTP? Message-ID: <20131225163540.13345.qmail@joyce.lan> I have two FreeBSD servers where the NTP daemons are using double digit CPU percentages today rather than the usual 0.01%. Restarting them didn't help. The clock on my Android phone is five hours slow. (It's not the time zone, I checked that.) Is this just my special Christmas present, or are there screwed up NTP servers? Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From javier at kjsl.org Wed Dec 25 16:42:26 2013 From: javier at kjsl.org (Javier Henderson) Date: Wed, 25 Dec 2013 11:42:26 -0500 Subject: What's going on with NTP? In-Reply-To: <20131225163540.13345.qmail@joyce.lan> References: <20131225163540.13345.qmail@joyce.lan> Message-ID: <8610DAD4-CC3C-46E4-B31D-6DD3D01A2BDC@kjsl.org> On Dec 25, 2013, at 11:35 AM, John Levine wrote: > I have two FreeBSD servers where the NTP daemons are using double digit CPU > percentages today rather than the usual 0.01%. Restarting them didn't help. > > The clock on my Android phone is five hours slow. (It's not the time zone, > I checked that.) > > Is this just my special Christmas present, or are there screwed up NTP servers? I suspect your servers are being attacked. Are you seeing a lot of in/out NTP traffic on those FreeBSD servers? -jav From jared at puck.nether.net Wed Dec 25 16:58:36 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 25 Dec 2013 10:58:36 -0600 Subject: What's going on with NTP? In-Reply-To: <8610DAD4-CC3C-46E4-B31D-6DD3D01A2BDC@kjsl.org> References: <20131225163540.13345.qmail@joyce.lan> <8610DAD4-CC3C-46E4-B31D-6DD3D01A2BDC@kjsl.org> Message-ID: <7F3C965F-9A7A-4C67-9357-7C6DF02D9BAD@puck.nether.net> There have been a lot of NTP reflection attacks recently. Think the same as dns amplification. Make sure you restrict access and know how to look at the client list. Jared Mauch > On Dec 25, 2013, at 10:42 AM, Javier Henderson wrote: > > >> On Dec 25, 2013, at 11:35 AM, John Levine wrote: >> >> I have two FreeBSD servers where the NTP daemons are using double digit CPU >> percentages today rather than the usual 0.01%. Restarting them didn't help. >> >> The clock on my Android phone is five hours slow. (It's not the time zone, >> I checked that.) >> >> Is this just my special Christmas present, or are there screwed up NTP servers? > > I suspect your servers are being attacked. Are you seeing a lot of in/out NTP traffic on those FreeBSD servers? > > -jav > > From david at blue-labs.org Wed Dec 25 18:37:36 2013 From: david at blue-labs.org (David Ford) Date: Wed, 25 Dec 2013 13:37:36 -0500 Subject: What's going on with NTP? In-Reply-To: <20131225163540.13345.qmail@joyce.lan> References: <20131225163540.13345.qmail@joyce.lan> Message-ID: <52BB25F0.4040309@blue-labs.org> On 12/25/2013 11:35 AM, John Levine wrote: > I have two FreeBSD servers where the NTP daemons are using double digit CPU > percentages today rather than the usual 0.01%. Restarting them didn't help. > > The clock on my Android phone is five hours slow. (It's not the time zone, > I checked that.) > > Is this just my special Christmas present, or are there screwed up NTP servers? > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > you probably need to configure them correctly with: restrict default ignore and add additional restrict lines if you have need for other legitimate servers to make contact with them. i suspect right now you're providing an ntp amplification attack to the spoofed source address. -david From amitchell at isipp.com Wed Dec 25 20:14:22 2013 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Wed, 25 Dec 2013 13:14:22 -0700 Subject: Help me make sense of these traceroutes please In-Reply-To: References: Message-ID: <30772BC3-4D51-4380-BDFE-E846323A6836@isipp.com> > with a bunch of IT folks and an ample supply of Guinness. My ex used to call it "design fluid". :-) Happy holidays, everyone! Anne Anne P. Mitchell, Attorney at Law CEO/President ISIPP SuretyMail Email Accreditation http://www.ISIPP.com Member, Cal. Bar Cyberspace Law Committee Author: Section 6 of the CAN-SPAM Act of 2003 How do you get to the inbox instead of the spam filter? SuretyMail! Helping businesses keep their email out of the junk folder since 1998 http://www.isipp.com/SuretyMail Author, "They're Your Kids Too: The Single Father's Guide to Defending Your Fatherhood in a Broken Family Law System" http://www.amazon.com/Theyre-Your-Kids-Too-Fatherhood/dp/061551443X From baconzombie at gmail.com Wed Dec 25 20:22:10 2013 From: baconzombie at gmail.com (Bacon Zombie) Date: Wed, 25 Dec 2013 20:22:10 +0000 Subject: Help me make sense of these traceroutes please In-Reply-To: <182610.1387986429@turing-police.cc.vt.edu> References: <52BA1F02.2070505@massar.ch> <5981f7e5a68abdfa9aaf007924e86596@www.circlenet.us> <182610.1387986429@turing-police.cc.vt.edu> Message-ID: Pitcher of Guinness!?! What blasphemy is this, the only way to drink it is via individually poured pint glasses. Back to the issues I'd say MPLS or GHCQ before NSA. On 25 Dec 2013 15:52, wrote: > On Tue, 24 Dec 2013 19:03:02 -0500, Sam Moats said: > > > Also you'd be amazed how many network issues can be solved with a bunch > > of IT folks and an ample supply of Guinness > > I once heard the claim that if you couldn't explain your network design and > have the listener understand it after you had split a pitcher of Guiness, > it was probably too complicated. > > From wbailey at satelliteintelligencegroup.com Wed Dec 25 20:26:36 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 25 Dec 2013 20:26:36 +0000 Subject: Help me make sense of these traceroutes please In-Reply-To: References: <52BA1F02.2070505@massar.ch> <5981f7e5a68abdfa9aaf007924e86596@www.circlenet.us> <182610.1387986429@turing-police.cc.vt.edu>, Message-ID: Thats why you're a bacon zombie. If you were a living person you'd know free beer tastes the same irrespective of the containment vessel. ;) I hope Santa brought all of you what you wanted. If not, blame UPS. Sent from my Mobile Device. -------- Original message -------- From: Bacon Zombie Date: 12/25/2013 11:24 AM (GMT-09:00) To: Valdis.Kletnieks at vt.edu Cc: sam at circlenet.us,nanog at nanog.org Subject: Re: Help me make sense of these traceroutes please Pitcher of Guinness!?! What blasphemy is this, the only way to drink it is via individually poured pint glasses. Back to the issues I'd say MPLS or GHCQ before NSA. On 25 Dec 2013 15:52, wrote: > On Tue, 24 Dec 2013 19:03:02 -0500, Sam Moats said: > > > Also you'd be amazed how many network issues can be solved with a bunch > > of IT folks and an ample supply of Guinness > > I once heard the claim that if you couldn't explain your network design and > have the listener understand it after you had split a pitcher of Guiness, > it was probably too complicated. > > From randy at psg.com Thu Dec 26 00:43:26 2013 From: randy at psg.com (Randy Bush) Date: Wed, 25 Dec 2013 19:43:26 -0500 Subject: What's going on with NTP? In-Reply-To: <20131225163540.13345.qmail@joyce.lan> References: <20131225163540.13345.qmail@joyce.lan> Message-ID: https://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html https://www.team-cymru.org/ReadingRoom/Templates/secure-endrun-template.html From olivier at cochard.me Thu Dec 26 09:23:12 2013 From: olivier at cochard.me (=?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?=) Date: Thu, 26 Dec 2013 10:23:12 +0100 Subject: What's going on with NTP? In-Reply-To: <20131225163540.13345.qmail@joyce.lan> References: <20131225163540.13345.qmail@joyce.lan> Message-ID: On Wed, Dec 25, 2013 at 5:35 PM, John Levine wrote: > I have two FreeBSD servers where the NTP daemons are using double digit CPU > percentages today rather than the usual 0.01%. Restarting them didn't > help. > > The clock on my Android phone is five hours slow. (It's not the time zone, > I checked that.) > > Is this just my special Christmas present, or are there screwed up NTP > servers? > The old NTP server in FreeBSD have a bug that allow to use it for reflexion DOS attacks: http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046822.html Regards, Olivier From Marcus.Josephson at Level3.com Thu Dec 26 16:21:45 2013 From: Marcus.Josephson at Level3.com (Josephson, Marcus) Date: Thu, 26 Dec 2013 16:21:45 +0000 Subject: Help me make sense of these traceroutes please In-Reply-To: References: Message-ID: Start at slide 50: This is documented further by the following Nanog presentation. http://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf -Marcus -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, December 25, 2013 10:28 AM To: Martin Hotze Cc: nanog at nanog.org Subject: Re: Help me make sense of these traceroutes please On Wed, Dec 25, 2013 at 8:03 AM, Martin Hotze wrote: > > > On 2013-12-25 00:16, Sam Moats wrote: > ... > > You are likely seeing the effects of asymmetric routing. > . .. or the effect of passing traffic through NSA infrastructure. > > Ah... NSA. That's probably it. So much for my theory of a Router virtual chassis straddling the atlantic. or the extra kinetic energy carried by the overseas-bound packet took longer for the router to absorb and rebound with an ICMP. But in all seriousness --- what is probably happening here, is the result of extra "hops" that don't show up in traceroute. MPLS tunnels could well fit the bill. Other things to consider when latency seems sensitive to destination IP --- are preceding device in the traceroute might also have multiple links to the same device; with one link congested and some form of IP-based load sharing, that happens to be the toward-overseas link. > SCNR, #m -- -JH From symack at gmail.com Thu Dec 26 16:33:13 2013 From: symack at gmail.com (Nick Cameo) Date: Thu, 26 Dec 2013 11:33:13 -0500 Subject: The Making of a Router Message-ID: Hello Everyone, We are looking to put together a 2u server with a few PCIe 3 x8 (recommendations appreciated). The router will take a voip transcoding line card, and will act as an edge router for a telecom company. For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static routes, and firewall capabilities we are thinking gentoo linux stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. Any comments, feedback, does, and don'ts are much appreciated. Kind Regards, Nick. From faisal at snappytelecom.net Thu Dec 26 16:46:47 2013 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 26 Dec 2013 16:46:47 +0000 (GMT) Subject: The Making of a Router In-Reply-To: References: Message-ID: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> I am a believer of not having to re-invent the wheel... Having said that.. have you looked at 'purpose built appliances' e.g. http://www.lannerinc.com/ http://us.axiomtek.com/ If you are looking for a full router.... Consider such as these... http://www.linktechs.net/ http://www.maxxwave.com/ and there are a few others but the concept is the same Personally, I am not a believer in making a single device be the do all / end all of everything.. While one can do everything on a big server .. however breaking things out e.g. voip trans-coding and routing make maintenance, availability, and ability to create redundancy much more practical. Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Nick Cameo" > To: nanog at nanog.org > Sent: Thursday, December 26, 2013 11:33:13 AM > Subject: The Making of a Router > > Hello Everyone, > > We are looking to put together a 2u server with a few PCIe 3 x8 > (recommendations appreciated). The router will take a voip transcoding > line card, and will act as an edge router for a telecom company. > > For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static > routes, and firewall capabilities we are thinking gentoo linux > stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. > Any comments, feedback, does, and don'ts are much appreciated. > > Kind Regards, > > Nick. > > From trelane at trelane.net Thu Dec 26 16:55:01 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 26 Dec 2013 11:55:01 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: <52BC5F65.3020001@trelane.net> If you're trying to do this cheaply, I'd recommend an appropriate sized Mikrotik router, and perhaps something running digium's transcoding hardware/Asterisk, or some Adtran hardware. Don't put all this in one box. Andrew On 12/26/2013 11:33 AM, Nick Cameo wrote: > Hello Everyone, > > We are looking to put together a 2u server with a few PCIe 3 x8 > (recommendations appreciated). The router will take a voip transcoding > line card, and will act as an edge router for a telecom company. > > For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static > routes, and firewall capabilities we are thinking gentoo linux > stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. > Any comments, feedback, does, and don'ts are much appreciated. > > Kind Regards, > > Nick. > From cabenth at gmail.com Thu Dec 26 16:55:40 2013 From: cabenth at gmail.com (Eric Clark) Date: Thu, 26 Dec 2013 08:55:40 -0800 Subject: The Making of a Router In-Reply-To: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> Message-ID: <70D10C79-B55B-4B38-B801-A945C9E0A2FF@gmail.com> I also wonder about re-inventing the wheel. The router part is easy, you could even do that with a windows box (that's a joke). Obviously capital cost is part of it, but the man hours involved in doing what you're talking about, especially since you are talking about a telco.... whatever you come up with has to be pretty darn reliable... Certainly would be interested in a little more information about the use case. Eric On Dec 26, 2013, at 8:46 AM, Faisal Imtiaz wrote: > I am a believer of not having to re-invent the wheel... > > Having said that.. have you looked at 'purpose built appliances' e.g. > > http://www.lannerinc.com/ > http://us.axiomtek.com/ > > If you are looking for a full router.... > Consider such as these... > http://www.linktechs.net/ > http://www.maxxwave.com/ > > and there are a few others but the concept is the same > > Personally, I am not a believer in making a single device be the do all / end all of everything.. > While one can do everything on a big server .. however breaking things out e.g. voip trans-coding and routing make maintenance, availability, and ability to create redundancy much more practical. > > > Regards > > Faisal Imtiaz > Snappy Internet & Telecom > > > ----- Original Message ----- >> From: "Nick Cameo" >> To: nanog at nanog.org >> Sent: Thursday, December 26, 2013 11:33:13 AM >> Subject: The Making of a Router >> >> Hello Everyone, >> >> We are looking to put together a 2u server with a few PCIe 3 x8 >> (recommendations appreciated). The router will take a voip transcoding >> line card, and will act as an edge router for a telecom company. >> >> For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static >> routes, and firewall capabilities we are thinking gentoo linux >> stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. >> Any comments, feedback, does, and don'ts are much appreciated. >> >> Kind Regards, >> >> Nick. >> >> > From jared at puck.nether.net Thu Dec 26 16:59:21 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 26 Dec 2013 10:59:21 -0600 Subject: The Making of a Router In-Reply-To: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> Message-ID: <46460C19-F640-4E6D-A25A-901E55996F5C@puck.nether.net> Look at the ubnt edgemax devices Jared Mauch > On Dec 26, 2013, at 10:46 AM, Faisal Imtiaz wrote: > > I am a believer of not having to re-invent the wheel... > > Having said that.. have you looked at 'purpose built appliances' e.g. > > http://www.lannerinc.com/ > http://us.axiomtek.com/ > > If you are looking for a full router.... > Consider such as these... > http://www.linktechs.net/ > http://www.maxxwave.com/ > > and there are a few others but the concept is the same > > Personally, I am not a believer in making a single device be the do all / end all of everything.. > While one can do everything on a big server .. however breaking things out e.g. voip trans-coding and routing make maintenance, availability, and ability to create redundancy much more practical. > > > Regards > > Faisal Imtiaz > Snappy Internet & Telecom > > > ----- Original Message ----- >> From: "Nick Cameo" >> To: nanog at nanog.org >> Sent: Thursday, December 26, 2013 11:33:13 AM >> Subject: The Making of a Router >> >> Hello Everyone, >> >> We are looking to put together a 2u server with a few PCIe 3 x8 >> (recommendations appreciated). The router will take a voip transcoding >> line card, and will act as an edge router for a telecom company. >> >> For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static >> routes, and firewall capabilities we are thinking gentoo linux >> stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. >> Any comments, feedback, does, and don'ts are much appreciated. >> >> Kind Regards, >> >> Nick. >> >> From jared at puck.nether.net Thu Dec 26 17:01:13 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 26 Dec 2013 11:01:13 -0600 Subject: The Making of a Router In-Reply-To: <52BC5F65.3020001@trelane.net> References: <52BC5F65.3020001@trelane.net> Message-ID: Have to agree on the below. I've seen too many devices be so integrated they do no task well, and can't be rebooted to troubleshoot due to everyone using them. Jared Mauch > On Dec 26, 2013, at 10:55 AM, Andrew D Kirch wrote: > > Don't put all this in one box. From lord2y at gmail.com Thu Dec 26 17:05:10 2013 From: lord2y at gmail.com (Alessandro Ratti) Date: Thu, 26 Dec 2013 18:05:10 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: if you want build by yourself I will suggest gentoo and/or freebsd with bird (http://bird.network.cz/) for routing stuff (maybe with 10G nics). Don't put all this in one box. +1 On Thu, Dec 26, 2013 at 5:33 PM, Nick Cameo wrote: > Hello Everyone, > > We are looking to put together a 2u server with a few PCIe 3 x8 > (recommendations appreciated). The router will take a voip transcoding > line card, and will act as an edge router for a telecom company. > > For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static > routes, and firewall capabilities we are thinking gentoo linux > stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. > Any comments, feedback, does, and don'ts are much appreciated. > > Kind Regards, > > Nick. > > -- Ciao, Alessandro From wbailey at satelliteintelligencegroup.com Thu Dec 26 17:21:11 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 26 Dec 2013 17:21:11 +0000 Subject: The Making of a Router In-Reply-To: <70D10C79-B55B-4B38-B801-A945C9E0A2FF@gmail.com> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net>, <70D10C79-B55B-4B38-B801-A945C9E0A2FF@gmail.com> Message-ID: <675pvocj7ntdwpnm7dcs0566.1388078459506@email.android.com> Not to mention the fact that this "router" will require support. The build before buy people are silly. Let the smart router guys do their thing and use their box accordingly. When it breaks call to inform them it broke and they will fix it. Diy projects are a nightmare to support. Sent from my Mobile Device. -------- Original message -------- From: Eric Clark Date: 12/26/2013 8:00 AM (GMT-09:00) To: Faisal Imtiaz Cc: nanog at nanog.org Subject: Re: The Making of a Router I also wonder about re-inventing the wheel. The router part is easy, you could even do that with a windows box (that's a joke). Obviously capital cost is part of it, but the man hours involved in doing what you're talking about, especially since you are talking about a telco.... whatever you come up with has to be pretty darn reliable... Certainly would be interested in a little more information about the use case. Eric On Dec 26, 2013, at 8:46 AM, Faisal Imtiaz wrote: > I am a believer of not having to re-invent the wheel... > > Having said that.. have you looked at 'purpose built appliances' e.g. > > http://www.lannerinc.com/ > http://us.axiomtek.com/ > > If you are looking for a full router.... > Consider such as these... > http://www.linktechs.net/ > http://www.maxxwave.com/ > > and there are a few others but the concept is the same > > Personally, I am not a believer in making a single device be the do all / end all of everything.. > While one can do everything on a big server .. however breaking things out e.g. voip trans-coding and routing make maintenance, availability, and ability to create redundancy much more practical. > > > Regards > > Faisal Imtiaz > Snappy Internet & Telecom > > > ----- Original Message ----- >> From: "Nick Cameo" >> To: nanog at nanog.org >> Sent: Thursday, December 26, 2013 11:33:13 AM >> Subject: The Making of a Router >> >> Hello Everyone, >> >> We are looking to put together a 2u server with a few PCIe 3 x8 >> (recommendations appreciated). The router will take a voip transcoding >> line card, and will act as an edge router for a telecom company. >> >> For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static >> routes, and firewall capabilities we are thinking gentoo linux >> stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. >> Any comments, feedback, does, and don'ts are much appreciated. >> >> Kind Regards, >> >> Nick. >> >> > From trelane at trelane.net Thu Dec 26 17:24:49 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 26 Dec 2013 12:24:49 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: <52BC6661.6050702@trelane.net> On 12/26/2013 12:05 PM, Alessandro Ratti wrote: > (maybe with 10G nics). If he can afford a 10G link... he should be buying real gear... I mean, look, I've got plenty of infrastructure horror stories, but lets not cobble together our own 10gbit solutions, please? At least get one of the new microtik CCR's with a 10gig sfp+? They're only a kilobuck... If you can't afford that I suggest you can't afford to be an ISP. Andrew From ag4ve.us at gmail.com Thu Dec 26 17:59:40 2013 From: ag4ve.us at gmail.com (Shawn Wilson) Date: Thu, 26 Dec 2013 12:59:40 -0500 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: Totally agree that a routing box should be standalone for tons of reasons. Even separating network routing and call routing. It used to be that BSD's network stack was much better than Linux's under load. I'm not sure if this is still the case - I've never been put in the situation where the Linux kernel was at its limits. FWIW Jared Mauch wrote: >Have to agree on the below. I've seen too many devices be so integrated >they do no task well, and can't be rebooted to troubleshoot due to >everyone using them. > >Jared Mauch > >> On Dec 26, 2013, at 10:55 AM, Andrew D Kirch >wrote: >> >> Don't put all this in one box. From deleskie at gmail.com Thu Dec 26 18:07:57 2013 From: deleskie at gmail.com (jim deleskie) Date: Thu, 26 Dec 2013 14:07:57 -0400 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: I've recently pushed a "large" BSD box to a load of over 300, for more then an hour, while under test, some things slowed a little, but she kept on working! -jim On Thu, Dec 26, 2013 at 1:59 PM, Shawn Wilson wrote: > Totally agree that a routing box should be standalone for tons of reasons. > Even separating network routing and call routing. > > It used to be that BSD's network stack was much better than Linux's under > load. I'm not sure if this is still the case - I've never been put in the > situation where the Linux kernel was at its limits. FWIW > > Jared Mauch wrote: > >Have to agree on the below. I've seen too many devices be so integrated > >they do no task well, and can't be rebooted to troubleshoot due to > >everyone using them. > > > >Jared Mauch > > > >> On Dec 26, 2013, at 10:55 AM, Andrew D Kirch > >wrote: > >> > >> Don't put all this in one box. > > > From rps at maine.edu Thu Dec 26 19:01:01 2013 From: rps at maine.edu (Ray Soucy) Date: Thu, 26 Dec 2013 14:01:01 -0500 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: You can build using commodity hardware and get pretty good results. I've had really good luck with Supermicro whitebox hardware, and Intel-based network cards. The "Hot Lava Systems" cards have a nice selection for a decent price if you're looking for SFP and SFP+ cards that use Intel chipsets. There might be some benefits in going with something like FreeBSD, but I find that Linux has a lot more eyeballs on it making it much easier to develop for, troubleshoot, and support. There are a few options if you want to go the Linux route. Option 1: Roll your own OS. This takes quite a bit of effort, but if you have the tallant to do it you can generally get exactly what you want. Option 2: Use an established distribution. Vyatta doesn't seem to be doing much with its FOSS release "Vyatta Core" anymore, but the community has forked the GPL parts into "VyOS". I've been watching them pretty closely and helping out where I can; I think the project is going to win over a lot of people over the next few years. http://www.vyatta.org/ http://www.vyos.net/ The biggest point of failure I've experienced with Linux-based routers on whitebox hardware has been HDD failure. Other than that, the 100+ units I've had deployed over the past 3+ years have been pretty much flawless. Thankfully, they currently run an in-memory OS, so a disk failure only affects logging. If you want to build your own OS, I'll shamelessly plug a side project of mine: RAMBOOT http://ramboot.org/ RAMBOOT makes use of the Ubuntu Core rootfs, and a modified boot process (added into initramfs tools, so kernel updates generate the right kernel automatically). Essentially, I use a kernel ramdisk instead of an HDD for the root filesystem and "/" is mounted on "/dev/ram1". The bootflash can be removed while the system is running as it's only mounted to save system configuration or update the OS. I haven't polished it up much, but there is enough there to get going pretty quickly. You'll also want to pay attention to the settings you use for the kernel. Linux is tuned as a desktop or server, not a router, so there are some basics you should take care of (like disabling ICMP redirects, increasing the ARP table size, etc). I have some examples in: http://soucy.org/xorp/xorp-1.7-pre/TUNING or http://soucy.org/tmp/netfilter.txt (more recent, but includes firewall examples). Also a note of caution. I would stick with a longterm release of Linux. I've had good experience with 2.6.32, and 3.10. I'm eager to use some of the post-3.10 features, though, so I'm anxious for the next longterm branch to be locked in. If running a proxy server of any kind, you'll want to adjust TCP_TIMEWAIT_LEN in the header file and re-compile the kernel, else you'll run into ephemeral port exhaustion before you touch the limits of the CPU. I recommend 15 seconds (the default in Linux is 60). Routing-engine -wise. I currently have a large XORP 1.6 deployment because I have a need for multicast routing (PIM-SM), but XORP is very touchy and takes quite a bit of operational experience to avoid problems. Quagga has much more active development and eyeballs. BIRD is also very interesting. I like the model of BIRD a lot (more of a traditional daemon than trying to be a Cisco or Juniper clone). It doesn't seem to be as far along as Quagga though. One of the biggest advantages is the low cost of hardware allows you to maintain spare systems, reducing the time to service restoration in the event of failure. Dependability-wise, I feel that whitebox Linux systems are pretty much at Cisco levels these days, especially if running in-memory. On Thu, Dec 26, 2013 at 1:07 PM, jim deleskie wrote: > I've recently pushed a "large" BSD box to a load of over 300, for more then > an hour, while under test, some things slowed a little, but she kept on > working! > > -jim > > > On Thu, Dec 26, 2013 at 1:59 PM, Shawn Wilson wrote: > > > Totally agree that a routing box should be standalone for tons of > reasons. > > Even separating network routing and call routing. > > > > It used to be that BSD's network stack was much better than Linux's under > > load. I'm not sure if this is still the case - I've never been put in the > > situation where the Linux kernel was at its limits. FWIW > > > > Jared Mauch wrote: > > >Have to agree on the below. I've seen too many devices be so integrated > > >they do no task well, and can't be rebooted to troubleshoot due to > > >everyone using them. > > > > > >Jared Mauch > > > > > >> On Dec 26, 2013, at 10:55 AM, Andrew D Kirch > > >wrote: > > >> > > >> Don't put all this in one box. > > > > > > > -- 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 listas at esds.com.br Thu Dec 26 19:05:36 2013 From: listas at esds.com.br (Eduardo Schoedler) Date: Thu, 26 Dec 2013 17:05:36 -0200 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: For router with Freebsd+BIRD/Quagga, I suggest BSDRP.http://bsdrp.net 2013/12/26 Ray Soucy > You can build using commodity hardware and get pretty good results. > > I've had really good luck with Supermicro whitebox hardware, and > Intel-based network cards. The "Hot Lava Systems" cards have a nice > selection for a decent price if you're looking for SFP and SFP+ cards that > use Intel chipsets. > > There might be some benefits in going with something like FreeBSD, but I > find that Linux has a lot more eyeballs on it making it much easier to > develop for, troubleshoot, and support. There are a few options if you > want to go the Linux route. > > Option 1: Roll your own OS. This takes quite a bit of effort, but if you > have the tallant to do it you can generally get exactly what you want. > > Option 2: Use an established distribution. > > Vyatta doesn't seem to be doing much with its FOSS release "Vyatta Core" > anymore, but the community has forked the GPL parts into "VyOS". I've been > watching them pretty closely and helping out where I can; I think the > project is going to win over a lot of people over the next few years. > > http://www.vyatta.org/ > http://www.vyos.net/ > > The biggest point of failure I've experienced with Linux-based routers on > whitebox hardware has been HDD failure. Other than that, the 100+ units > I've had deployed over the past 3+ years have been pretty much flawless. > > Thankfully, they currently run an in-memory OS, so a disk failure only > affects logging. > > If you want to build your own OS, I'll shamelessly plug a side project of > mine: RAMBOOT > > http://ramboot.org/ > > RAMBOOT makes use of the Ubuntu Core rootfs, and a modified boot process > (added into initramfs tools, so kernel updates generate the right kernel > automatically). Essentially, I use a kernel ramdisk instead of an HDD for > the root filesystem and "/" is mounted on "/dev/ram1". > > The bootflash can be removed while the system is running as it's only > mounted to save system configuration or update the OS. > > I haven't polished it up much, but there is enough there to get going > pretty quickly. > > You'll also want to pay attention to the settings you use for the kernel. > Linux is tuned as a desktop or server, not a router, so there are some > basics you should take care of (like disabling ICMP redirects, increasing > the ARP table size, etc). > > I have some examples in: http://soucy.org/xorp/xorp-1.7-pre/TUNING > or http://soucy.org/tmp/netfilter.txt (more recent, but includes firewall > examples). > > Also a note of caution. I would stick with a longterm release of Linux. > I've had good experience with 2.6.32, and 3.10. I'm eager to use some of > the post-3.10 features, though, so I'm anxious for the next longterm branch > to be locked in. > > If running a proxy server of any kind, you'll want to adjust > TCP_TIMEWAIT_LEN in the header file and re-compile the kernel, else you'll > run into ephemeral port exhaustion before you touch the limits of the CPU. > I recommend 15 seconds (the default in Linux is 60). > > Routing-engine -wise. I currently have a large XORP 1.6 deployment because > I have a need for multicast routing (PIM-SM), but XORP is very touchy and > takes quite a bit of operational experience to avoid problems. Quagga has > much more active development and eyeballs. BIRD is also very interesting. > I like the model of BIRD a lot (more of a traditional daemon than trying > to be a Cisco or Juniper clone). It doesn't seem to be as far along as > Quagga though. > > One of the biggest advantages is the low cost of hardware allows you to > maintain spare systems, reducing the time to service restoration in the > event of failure. Dependability-wise, I feel that whitebox Linux systems > are pretty much at Cisco levels these days, especially if running > in-memory. > > > > > On Thu, Dec 26, 2013 at 1:07 PM, jim deleskie wrote: > > > I've recently pushed a "large" BSD box to a load of over 300, for more > then > > an hour, while under test, some things slowed a little, but she kept on > > working! > > > > -jim > > > > > > On Thu, Dec 26, 2013 at 1:59 PM, Shawn Wilson > wrote: > > > > > Totally agree that a routing box should be standalone for tons of > > reasons. > > > Even separating network routing and call routing. > > > > > > It used to be that BSD's network stack was much better than Linux's > under > > > load. I'm not sure if this is still the case - I've never been put in > the > > > situation where the Linux kernel was at its limits. FWIW > > > > > > Jared Mauch wrote: > > > >Have to agree on the below. I've seen too many devices be so > integrated > > > >they do no task well, and can't be rebooted to troubleshoot due to > > > >everyone using them. > > > > > > > >Jared Mauch > > > > > > > >> On Dec 26, 2013, at 10:55 AM, Andrew D Kirch > > > >wrote: > > > >> > > > >> Don't put all this in one box. > > > > > > > > > > > > > > > -- > 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 > -- Eduardo Schoedler From sethm at rollernet.us Thu Dec 26 19:16:53 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Dec 2013 11:16:53 -0800 Subject: The Making of a Router In-Reply-To: <52BC6661.6050702@trelane.net> References: <52BC6661.6050702@trelane.net> Message-ID: <52BC80A5.1080208@rollernet.us> On 12/26/13, 9:24, Andrew D Kirch wrote: > > If he can afford a 10G link... he should be buying real gear... I mean, > look, I've got plenty of infrastructure horror stories, but lets not > cobble together our own 10gbit solutions, please? At least get one of > the new microtik CCR's with a 10gig sfp+? They're only a kilobuck... If > you can't afford that I suggest you can't afford to be an ISP. Unless all the money is going into the 10 gig link. ~Seth From sethm at rollernet.us Thu Dec 26 19:18:14 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Dec 2013 11:18:14 -0800 Subject: The Making of a Router In-Reply-To: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> Message-ID: <52BC80F6.1010600@rollernet.us> On 12/26/13, 8:46, Faisal Imtiaz wrote: > I am a believer of not having to re-invent the wheel... > > Having said that.. have you looked at 'purpose built appliances' e.g. > > http://www.lannerinc.com/ > http://us.axiomtek.com/ > > If you are looking for a full router.... > Consider such as these... > http://www.linktechs.net/ > http://www.maxxwave.com/ > I bought two Maxxwaves with the Core2 Duo processor and it's an Axiomtek NA-822 inside. It's a nifty platform, I'm probably going to put BIRD on it and make some BGP RRs one of these fine days. I'm too OCD to suffer a "server" in the routing/switching bays as the only thing with ports on the back. I wouldn't imagine trying to route 10 gig with it though, or sharing any functions (like VOIP) on it. ~Seth From faisal at snappytelecom.net Thu Dec 26 19:28:58 2013 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 26 Dec 2013 19:28:58 +0000 (GMT) Subject: The Making of a Router In-Reply-To: <52BC80F6.1010600@rollernet.us> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> <52BC80F6.1010600@rollernet.us> Message-ID: <1556575973.346333.1388086138078.JavaMail.root@snappytelecom.net> Ahh.. so you are the one who bought those two from Ebay ! I was watching, but got to them rather late. If you are the one who got them.. you got a great deal. These have Mikrotik ROS license with them, you can do BGP/ OSPF etc. with them If you want to reload them with other OS, all you got to do is pull out the FlashCard, and install anything else you want. The Core2 Duo Model with Mikrotik ROS ver 5 will handle about 1G to 1.5G of traffic with much trouble. With ROS ver 6 .. they will do about 25-30% more. The i5 & i7 versions will handle 3-5Gig of traffic easily... and these do support 10G SFP+ Intel nic's with ROS 6.x 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: "Seth Mattinen" > To: nanog at nanog.org > Sent: Thursday, December 26, 2013 2:18:14 PM > Subject: Re: The Making of a Router > > On 12/26/13, 8:46, Faisal Imtiaz wrote: > > I am a believer of not having to re-invent the wheel... > > > > Having said that.. have you looked at 'purpose built appliances' e.g. > > > > http://www.lannerinc.com/ > > http://us.axiomtek.com/ > > > > If you are looking for a full router.... > > Consider such as these... > > http://www.linktechs.net/ > > http://www.maxxwave.com/ > > > > > I bought two Maxxwaves with the Core2 Duo processor and it's an Axiomtek > NA-822 inside. It's a nifty platform, I'm probably going to put BIRD on > it and make some BGP RRs one of these fine days. I'm too OCD to suffer a > "server" in the routing/switching bays as the only thing with ports on > the back. > > I wouldn't imagine trying to route 10 gig with it though, or sharing any > functions (like VOIP) on it. > > ~Seth > > From sethm at rollernet.us Thu Dec 26 19:45:51 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Dec 2013 11:45:51 -0800 Subject: The Making of a Router In-Reply-To: <1556575973.346333.1388086138078.JavaMail.root@snappytelecom.net> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> <52BC80F6.1010600@rollernet.us> <1556575973.346333.1388086138078.JavaMail.root@snappytelecom.net> Message-ID: <52BC876F.3090308@rollernet.us> On 12/26/13, 11:28, Faisal Imtiaz wrote: > Ahh.. so you are the one who bought those two from Ebay ! > I was watching, but got to them rather late. > > If you are the one who got them.. you got a great deal. > > These have Mikrotik ROS license with them, you can do BGP/ OSPF etc. with them > If you want to reload them with other OS, all you got to do is pull out the FlashCard, and install anything else you want. > > The Core2 Duo Model with Mikrotik ROS ver 5 will handle about 1G to 1.5G of traffic with much trouble. > With ROS ver 6 .. they will do about 25-30% more. > > The i5 & i7 versions will handle 3-5Gig of traffic easily... and these do support 10G SFP+ Intel nic's with ROS 6.x Nope, that wasn't me. I got mine probably a year ago. I pulled the flash and tried Vyatta on it, but Vyatta turned out to be a buggy unpleasant experience. RouterOS had an IPv6 OSPF bug where it ignores some LSAs that made it a showstopper. ~Seth From eugen at imacandi.net Thu Dec 26 19:58:03 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 26 Dec 2013 21:58:03 +0200 Subject: Juniper MAG/SA question - re: split tunneling policy and use of JSAM/WSAM In-Reply-To: References: Message-ID: On Tue, Dec 24, 2013 at 7:50 PM, Herro91 wrote: > Hello J-NSP and Nanog members > > Hopefully this is the right forum for this discussion - if not my apologies > for further clogging your inbox. > > Here it goes: > > Would you consider use of JSAM/WSAM to selectively proxy and tunnel certain > applications a form of split tunneling? The traditional concept of split > tunnels looks at all traffic Layer 3 and above, versus JSAM/WSAM which > looks at application traffic at Layer 7. > > It's still Layer3, but it looks at the application name which sends the traffic in order to selectively tunnel specific destination networks and ports. I wouldn't call it split tunneling, but it depends on how your security policy classifies this kind of traffic. It's also worth looking at what risks this may bring to your exposed services as it check for process name, not necessarily for it to be valid (you can always create an outlook.exe app that tries to crash the Exchange CAS or something similar). > The context for all of this is from a previous question I put out regarding > split tunneling policy on government networks. > > > From symack at gmail.com Thu Dec 26 20:51:20 2013 From: symack at gmail.com (Nick Cameo) Date: Thu, 26 Dec 2013 15:51:20 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: > Have you tried labbing BSD vs Linux to see which you like better? I'd > probably do that before throwing it in to production. > -- Great advice Thomas! I will be creating a BSD virtual machine to get a feel however, with linux I can think broad scale and forcast better. With BSD, I am concerned with making choices that will shoot me in the foot. In essence, which BSD operating (Free vs OpenBSD) system is more widely supported, and proven successful for this task. I am talking about everything from hardware compatibility to software support for pfsense and openbgpd from the community. Finally, performance comparison to a present day Linux Kernel. PS conntrack optimization for IPTables. Been there done that... I am strong with Gentoo and am pretty sure can put together a rock solid machine, just don't want to turn a blind eye though yeah? N. From symack at gmail.com Thu Dec 26 20:52:18 2013 From: symack at gmail.com (Nick Cameo) Date: Thu, 26 Dec 2013 15:52:18 -0500 Subject: The Making of a Router In-Reply-To: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> Message-ID: On 12/26/13, Faisal Imtiaz wrote: > I am a believer of not having to re-invent the wheel... > > Having said that.. have you looked at 'purpose built appliances' e.g. > > http://www.lannerinc.com/ > http://us.axiomtek.com/ > > If you are looking for a full router.... > Consider such as these... > http://www.linktechs.net/ > http://www.maxxwave.com/ > > and there are a few others but the concept is the same > > Personally, I am not a believer in making a single device be the do all / > end all of everything.. > While one can do everything on a big server .. however breaking things out > e.g. voip trans-coding and routing make maintenance, availability, and > ability to create redundancy much more practical. > Point taken! Transcoding tasks abstracted out :). N. From symack at gmail.com Thu Dec 26 20:58:21 2013 From: symack at gmail.com (Nick Cameo) Date: Thu, 26 Dec 2013 15:58:21 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: On 12/26/13, Alessandro Ratti wrote: > if you want build by yourself I will suggest gentoo and/or freebsd with > bird (http://bird.network.cz/) for routing stuff (maybe with 10G nics). Hello Alessandro, Any benchmarks of freebsd vs openbsd vs present day linux kern? From TYork at exacttarget.com Thu Dec 26 16:57:56 2013 From: TYork at exacttarget.com (Thomas York) Date: Thu, 26 Dec 2013 11:57:56 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: On 12/26/13 11:33 AM, "Nick Cameo" wrote: >Hello Everyone, > >We are looking to put together a 2u server with a few PCIe 3 x8 >(recommendations appreciated). The router will take a voip transcoding >line card, and will act as an edge router for a telecom company. > >For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static >routes, and firewall capabilities we are thinking gentoo linux >stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. >Any comments, feedback, does, and don'ts are much appreciated. > >Kind Regards, > >Nick. > Depends on how skilled you are at maintaining Linux vs BSD, honestly. Personally, I've accomplished something similar with great performance in the past on Linux. I ran Debian 7 + latest compiled Quagga + latest compiled Libreswan + Shorewall. If you're going to have a lot of different people changing the rules, I would go with Shorewall. The syntax is brain-dead simple, even though you're stuck with the network stack limitations of Linux. A lot of my issues with doing this in Linux have to do with distro's loading a bunch of net filter helpers by default, which can be a major pain in the ass (I'm looking at you, SIP and SNMP modules). I had to do a lot of tweaking to the conn track tables to make them large enough to handle lots of traffic, but obviously YMMV. Have you tried labbing BSD vs Linux to see which you like better? I'd probably do that before throwing it in to production. -- Thomas York ExactTarget, a salesforce.com company Network Engineer tyork at exacttarget.com Office: (317) 832-4384 Mobile: (317) 660-5426 From symack at gmail.com Thu Dec 26 21:22:18 2013 From: symack at gmail.com (Nick Cameo) Date: Thu, 26 Dec 2013 16:22:18 -0500 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: Inline response exist, On 12/26/13, Ray Soucy wrote: > You can build using commodity hardware and get pretty good results. > > I've had really good luck with Supermicro whitebox hardware, and > Intel-based network cards. The "Hot Lava Systems" cards have a nice > selection for a decent price if you're looking for SFP and SFP+ cards that > use Intel chipsets. I like the supermicro as well however we have a couple of IBM x3250 with 2 pcie v3 x8 that are begging for a intel network card. > There might be some benefits in going with something like FreeBSD, but I > find that Linux has a lot more eyeballs on it making it much easier to > develop for, troubleshoot, and support. There are a few options if you > want to go the Linux route. This is very important to consider. I would be speculating, or even worse, expecting the same type of community support from the BSD verse that I have been getting from the linux community. > > Option 1: Roll your own OS. This takes quite a bit of effort, but if you > have the tallant to do it you can generally get exactly what you want. If Free/OpenBSD is ruled out, I could crack open the LFS project. You only have to do it once right? Or maybe just reach out to the gentoo community for a stripped version, and build outwards. > The biggest point of failure I've experienced with Linux-based routers on > whitebox hardware has been HDD failure. Other than that, the 100+ units > I've had deployed over the past 3+ years have been pretty much flawless. > SSD > Thankfully, they currently run an in-memory OS, so a disk failure only > affects logging. > If you want to build your own OS, I'll shamelessly plug a side project of > mine: RAMBOOT > > http://ramboot.org/ > > RAMBOOT makes use of the Ubuntu Core rootfs, and a modified boot process > (added into initramfs tools, so kernel updates generate the right kernel > automatically). Essentially, I use a kernel ramdisk instead of an HDD for > the root filesystem and "/" is mounted on "/dev/ram1". > > The bootflash can be removed while the system is running as it's only > mounted to save system configuration or update the OS. > > I haven't polished it up much, but there is enough there to get going > pretty quickly. Ummm, if it's ok with the community, can you kindly elaborate :). I am not too fond of Debian since my horrible experience with Squeeze Desktop. I would maybe like to try this using the combination of SSD, in memory, and Gentoo? > > You'll also want to pay attention to the settings you use for the kernel. > Linux is tuned as a desktop or server, not a router, so there are some > basics you should take care of (like disabling ICMP redirects, increasing > the ARP table size, etc). Totally strip it as much as possible. If anyone has a Gentoo stripped kernel config that they would like to share, please do :). > > I have some examples in: http://soucy.org/xorp/xorp-1.7-pre/TUNING > or http://soucy.org/tmp/netfilter.txt (more recent, but includes firewall > examples). Will definitely look into all your sites. > > Also a note of caution. I would stick with a longterm release of Linux. > I've had good experience with 2.6.32, and 3.10. I'm eager to use some of > the post-3.10 features, though, so I'm anxious for the next longterm branch > to be locked in. > We are comfy with 3.4 right now... > One of the biggest advantages is the low cost of hardware allows you to > maintain spare systems, reducing the time to service restoration in the > event of failure. Dependability-wise, I feel that whitebox Linux systems > are pretty much at Cisco levels these days, especially if running > in-memory. Really interested with the "in-memory", however, I would love to implement it using gentoo as mentioned above. Kind Regards, N. From symack at gmail.com Thu Dec 26 21:26:29 2013 From: symack at gmail.com (Nick Cameo) Date: Thu, 26 Dec 2013 16:26:29 -0500 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: > One of the biggest advantages is the low cost of hardware allows you to > maintain spare systems, reducing the time to service restoration in the > event of failure. Dependability-wise, I feel that whitebox Linux systems > are pretty much at Cisco levels these days, especially if running > in-memory. With your guidance, I can put together a gentoo environment that will run in memory tailored for this purpose, and would be obliged to share it with the community if anyone else is interested. N. From sethm at rollernet.us Thu Dec 26 21:32:33 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Dec 2013 13:32:33 -0800 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: <52BCA071.9090703@rollernet.us> On 12/26/13, 13:22, Nick Cameo wrote: > Ummm, if it's ok with the community, can you kindly elaborate:). I am > not too fond of Debian since my horrible experience with Squeeze Desktop. > I would maybe like to try this using the combination of SSD, in memory, and > Gentoo? Not to sound rude, but if someone gives you a how-to but you don't like it (since making a router and a desktop environment are totally the same thing), you are welcome to come up with your own based on what you like instead of telling them to give you new instructions to suit your preferences. ~Seth From symack at gmail.com Thu Dec 26 21:40:52 2013 From: symack at gmail.com (Nick Cameo) Date: Thu, 26 Dec 2013 16:40:52 -0500 Subject: The Making of a Router In-Reply-To: <52BCA071.9090703@rollernet.us> References: <52BC5F65.3020001@trelane.net> <52BCA071.9090703@rollernet.us> Message-ID: Oh my bad. I did not mean it like that at all! I am more that capable of putting it together using gentoo instead of debian (a little pedagogy goes a long way). And if he would like, he can post the ISO on his webstie alongside the different distro. This is what I was leaning too... Please don't be offended. N. From mpalmer at hezmatt.org Thu Dec 26 23:21:46 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 27 Dec 2013 10:21:46 +1100 Subject: The Making of a Router In-Reply-To: <675pvocj7ntdwpnm7dcs0566.1388078459506@email.android.com> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> <70D10C79-B55B-4B38-B801-A945C9E0A2FF@gmail.com> <675pvocj7ntdwpnm7dcs0566.1388078459506@email.android.com> Message-ID: <20131226232146.GA13499@hezmatt.org> On Thu, Dec 26, 2013 at 05:21:11PM +0000, Warren Bailey wrote: > Not to mention the fact that this "router" will require support. The build > before buy people are silly. Let the smart router guys do their thing and > use their box accordingly. When it breaks call to inform them it broke > and they will fix it. Unless they deem that it's "outside of scope". Or they can't get anyone to you inside of SLA[1]. Or they send someone incompetent. Or it's a problem that's never happened before. > Diy projects are a nightmare to support. *Everything* is a nightmare to support. A DIY project just means that you're betting you're smarter than whoever the vendor sends to fix their thing. Maybe it's a good bet, maybe it isn't. I'm sure you've got plenty of horror stories of DIY project support; I've got plenty of horror stories of vendor support. Perhaps we can get together some day and have a story-off. - Matt [1] So you might get some SLA credits at some point in the future. So what? It won't even cover your SLA payouts to your customers, let alone the lost business and reputation. From symack at gmail.com Thu Dec 26 23:38:07 2013 From: symack at gmail.com (Nick Cameo) Date: Thu, 26 Dec 2013 18:38:07 -0500 Subject: The Making of a Router In-Reply-To: <20131226232146.GA13499@hezmatt.org> References: <1890383367.345314.1388076407430.JavaMail.root@snappytelecom.net> <70D10C79-B55B-4B38-B801-A945C9E0A2FF@gmail.com> <675pvocj7ntdwpnm7dcs0566.1388078459506@email.android.com> <20131226232146.GA13499@hezmatt.org> Message-ID: >> Unless they deem that it's "outside of scope". Or they can't get anyone to >> you inside of SLA[1]. Or they send someone incompetent. Or it's a problem >> that's never happened before. Amen! >> *Everything* is a nightmare to support. A DIY project just means that >> you're betting you're smarter than whoever the vendor sends to fix their >> thing. Maybe it's a good bet, maybe it isn't. Amen Again! >> I'm sure you've got plenty of horror stories of DIY project support; I've >> got plenty of horror stories of vendor support. Perhaps we can get together >> some day and have a story-off. Nightmares come in colours of green, teal, and purple! From Valdis.Kletnieks at vt.edu Thu Dec 26 23:41:37 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 26 Dec 2013 18:41:37 -0500 Subject: The Making of a Router In-Reply-To: Your message of "Thu, 26 Dec 2013 11:33:13 -0500." References: Message-ID: <102947.1388101297@turing-police.cc.vt.edu> On Thu, 26 Dec 2013 11:33:13 -0500, Nick Cameo said: > Hello Everyone, > > We are looking to put together a 2u server with a few PCIe 3 x8 > (recommendations appreciated). The router will take a voip transcoding > line card, and will act as an edge router for a telecom company. Two things you want to do: 1) Split this into multiple boxes if you can. That makes maintaining one component a lot easier, especially when you get to point 2, which is... 2) Redundancy/failover. Sure, it may be more expensive, but the first time your HA failover changes a 2AM "Holy Crap" into an "Oh, bother" it will be worth the price of admission.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jra at baylink.com Thu Dec 26 23:54:26 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 26 Dec 2013 18:54:26 -0500 (EST) Subject: The Making of a Router In-Reply-To: <20131226232146.GA13499@hezmatt.org> Message-ID: <17398067.1754.1388102066367.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matt Palmer" > I've got plenty of horror stories of vendor support. Perhaps we can get > together some day and have a story-off. Just subject-tag it so we can archive it, ok guys? Cheers, -- jr 'whacky weekend' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From olivier at cochard.me Fri Dec 27 00:48:16 2013 From: olivier at cochard.me (=?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?=) Date: Fri, 27 Dec 2013 01:48:16 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: Le 26 d?c. 2013 22:02, "Nick Cameo" a ?crit : > > Any benchmarks of freebsd vs openbsd vs present day linux kern? > Hi, Here are my own benchs using smallest packet size (sorry no Linux): http://dev.bsdrp.net/benchs/BSD.network.performance.TenGig.png My conclusion: building a line-rate gigabit router (or a few rules ipfw firewall) is possible on commodity server without problem with FreeBSD. Building a 10gigabit router (this mean routing about 14Mpps) will be more complex in present day. Note: The packet generator used was the high-perf netmap pkg-gen, allowing me to generate about 13Mpps on this same hardware (under FreeBSD), but I'm not aware of forwarding tools that use netmap: There are only packet generator and capture tools available. From rps at maine.edu Fri Dec 27 01:27:03 2013 From: rps at maine.edu (Ray Soucy) Date: Thu, 26 Dec 2013 20:27:03 -0500 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: The basic idea of RAMBOOT is typical in Embedded Linux development. Linux makes use of multi-stage boot process. One of the stages involves using an initial ramdisk (initrd) to provide a base root filesystem which can be used to locate and mount the system root, then continue the boot process from there. For an in-memory OS, instead of the boot process mounting a pre-loaded storage device with the expected root filesystem (e.g. your installed HDD), you modify it to: 1) Create and format a ramdisk. 2) Create the expected directory structure and system files for the root filesystem on that ramdisk. The root filesystem includes the /dev directory and appropriate device nodes, the basic Linux filesystem and your init program. The easy way to do that is just to have a TAR archive that you extract to the ramdisk on boot, better yet use compression on it (e.g. tar.gz) so that the archive can be read from storage (e.g. USB flash) more quickly. Today, the initramfs in Linux handles a lot more than simply mounting the storage device. It performs hardware discovery and loads appropriate modules. As such the Debian project has a dynamic build system for initramfs that is run to build the initrd when a new kernel package is installed, it's called "initramfs-tools". You can manually build your own initramfs using the examples on the RAMBOOT website, but the point of RAMBOOT is to make building an in-memory OS quick and simple. RAMBOOT instead adds configuration to initramfs-tools so that each time a new initrd is generated, it includes the code needed for RAMBOOT. The RAMBOOT setup adds handling of a new boot target called "ramboot" to the kernel arguments. This allows the same kernel to be used for a normal installation and remain unaffected, but when you add the argument "boot=ramboot" as a kernel option to the bootloader, it triggers the RAMBOOT process described above. Having a common kernel between your development environment and embedded environment makes it much easier to test and verify functionality. The other part of RAMBOOT is that it makes use of "Ubuntu Core". Ubuntu Core is a stripped down minimal (and they really do mean minimal) root filesystem for Embedded Linux development. It includes apt-get, though, so you can install all the packages you need from Ubuntu on the running system. RAMBOOT then has a development script to make a new root filesystem archive with the packages you've installed as a baseline. This allows for you to boot a RAMBOOT system, install your desired packages and change system configuration files as desired, then build a persistent image of that install that will be used for future boots. I also have the start of a script to remove unused kernel modules, and other files (internationalization for example) which add to the OS footprint. You could build the root filesystem on your own (and compile all the necessary packages) but using Ubuntu Core provides a solid base and allows for the rapid addition of packages from the giant Ubuntu repository. Lastly, I make use of SYSLINUX as a bootloader because my goal was to use a USB stick as the bootflash on an Atom box. Unfortunately, the Atom BIOS will only boot a USB device if it has a DOS boot partition, so GRUB was a no-go. The upside is that since the USB uses SYSLINUX and is DOS formatted, it's easily mounted in Windows or Mac OS X, allowing you to copy new images or configuration to it easily. For the boot device I make use of the on-board vertical USB socket on the system board (typical for most system boards these days) and a low-profile USB stick. I find the Verbatim "Store 'n' Go" 8GB USB stick ideally suited for this as it's less than a quarter-inch high after the USB adapter. RAMBOOT as a project is in the very early stages, so you should be comfortable with Linux before you build a system on it. And I really feel it's more of an example than anything at this point. There are several advantages though: The most common point of failure on a Linux system is the storage device (either HDD or SSD). The biggest bottleneck in system performance is storage IO. Using a ramdisk eliminates both these concerns (in fact, even an Atom system has surprisingly great performance when run using a ramdisk). The result is that you get a very reliable, high-performance system. The other benefit to RAMBOOT is that the root filesystem is NOT persistent. This means that like a Cisco device, every boot of the system brings you to a known working state OS-wise. There are hundreds of system files in a Linux system; any one of which being modified could cause problems. For both security and availability concerns a lot of effort is invested in detecting changes to system files and avoiding them. With RAMBOOT the problem is easily avoided. A minimal system can fit within a 512MB ramdisk. But with RAM being so cheap these days, I think even reserving up to 2GB of RAM for a ramdisk would be fine (e.g. for a 4-8GB system). Here is the hardware configuration I originally started RAMBOOT for in 2011 (wanted to avoid the cost of an HDD): $326.36 (shipping included): 1U rack-mount case Supermicro CSE-502L-200B Intel Atom D510 system board with dual Gigabit (Intel 82574L) Supermicro MBD-X7SPA-H-O 2GB RAM 8GB low-profile USB flash drive (which will connect to the internal USB port and be low enough to fit in the case) Verbatim "Store n Stay". No HD; the system will boot off the 8GB flash into RAM and run the OS on a ramdisk. Using the RAMBOOT release that's currently up, I can build a custom Linux in-memory OS in half a day. I can easily update packages for security updates from the Ubuntu project and re-generate a new, updated, image in less time than that. So the initial goal of being able to build something useful quickly was satisfied, at least. My attention has now moved on to building a configuration management system, similar to Vyatta or VyOS and building a real distribution. I was going to call it "Carrier-grade Linux" (cglinux.org), but given the momentum VyOS has I might try to help the VyOS community instead of doing something new on my own. For what it's worth, I'm actually working with the VyOS project to try and incorporate some of the RAMBOOT ideas into VyOS as an install option for in-memory only. If you make use of RAMBOOT I would love to hear about it. :-) On Thu, Dec 26, 2013 at 4:22 PM, Nick Cameo wrote: > Inline response exist, > > On 12/26/13, Ray Soucy wrote: > > You can build using commodity hardware and get pretty good results. > > > > I've had really good luck with Supermicro whitebox hardware, and > > Intel-based network cards. The "Hot Lava Systems" cards have a nice > > selection for a decent price if you're looking for SFP and SFP+ cards > that > > use Intel chipsets. > > I like the supermicro as well however we have a couple of IBM x3250 > with 2 pcie v3 > x8 that are begging for a intel network card. > > > There might be some benefits in going with something like FreeBSD, but I > > find that Linux has a lot more eyeballs on it making it much easier to > > develop for, troubleshoot, and support. There are a few options if you > > want to go the Linux route. > > This is very important to consider. I would be speculating, or even > worse, expecting > the same type of community support from the BSD verse that I have been > getting from the linux community. > > > > > Option 1: Roll your own OS. This takes quite a bit of effort, but if you > > have the tallant to do it you can generally get exactly what you want. > > If Free/OpenBSD is ruled out, I could crack open the LFS project. You only > have to do it once right? Or maybe just reach out to the gentoo community > for a stripped version, and build outwards. > > > The biggest point of failure I've experienced with Linux-based routers on > > whitebox hardware has been HDD failure. Other than that, the 100+ units > > I've had deployed over the past 3+ years have been pretty much flawless. > > > > SSD > > > Thankfully, they currently run an in-memory OS, so a disk failure only > > affects logging. > > If you want to build your own OS, I'll shamelessly plug a side project of > > mine: RAMBOOT > > > > http://ramboot.org/ > > > > RAMBOOT makes use of the Ubuntu Core rootfs, and a modified boot process > > (added into initramfs tools, so kernel updates generate the right kernel > > automatically). Essentially, I use a kernel ramdisk instead of an HDD > for > > the root filesystem and "/" is mounted on "/dev/ram1". > > > > The bootflash can be removed while the system is running as it's only > > mounted to save system configuration or update the OS. > > > > I haven't polished it up much, but there is enough there to get going > > pretty quickly. > > Ummm, if it's ok with the community, can you kindly elaborate :). I am > not too fond of Debian since my horrible experience with Squeeze Desktop. > I would maybe like to try this using the combination of SSD, in memory, and > Gentoo? > > > > > You'll also want to pay attention to the settings you use for the kernel. > > Linux is tuned as a desktop or server, not a router, so there are some > > basics you should take care of (like disabling ICMP redirects, increasing > > the ARP table size, etc). > > Totally strip it as much as possible. If anyone has a Gentoo stripped > kernel > config that they would like to share, please do :). > > > > > I have some examples in: http://soucy.org/xorp/xorp-1.7-pre/TUNING > > or http://soucy.org/tmp/netfilter.txt (more recent, but includes > firewall > > examples). > > Will definitely look into all your sites. > > > > > Also a note of caution. I would stick with a longterm release of Linux. > > I've had good experience with 2.6.32, and 3.10. I'm eager to use some > of > > the post-3.10 features, though, so I'm anxious for the next longterm > branch > > to be locked in. > > > > We are comfy with 3.4 right now... > > > > One of the biggest advantages is the low cost of hardware allows you to > > maintain spare systems, reducing the time to service restoration in the > > event of failure. Dependability-wise, I feel that whitebox Linux systems > > are pretty much at Cisco levels these days, especially if running > > in-memory. > > Really interested with the "in-memory", however, I would love to implement > it using gentoo as mentioned above. > > > Kind Regards, > > N. > -- 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 rps at maine.edu Fri Dec 27 01:29:35 2013 From: rps at maine.edu (Ray Soucy) Date: Thu, 26 Dec 2013 20:29:35 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: Chipsets and drivers matter a lot in the 1G+ range. I've had pretty good luck with the Intel stuff because they offload a lot in hardware and make open drivers available to the community. On Thu, Dec 26, 2013 at 7:48 PM, Olivier Cochard-Labb? wrote: > Le 26 d?c. 2013 22:02, "Nick Cameo" a ?crit : > > > > Any benchmarks of freebsd vs openbsd vs present day linux kern? > > > Hi, > > Here are my own benchs using smallest packet size (sorry no Linux): > http://dev.bsdrp.net/benchs/BSD.network.performance.TenGig.png > > My conclusion: building a line-rate gigabit router (or a few rules ipfw > firewall) is possible on commodity server without problem with FreeBSD. > Building a 10gigabit router (this mean routing about 14Mpps) will be more > complex in present day. > Note: The packet generator used was the high-perf netmap pkg-gen, allowing > me to generate about 13Mpps on this same hardware (under FreeBSD), but I'm > not aware of forwarding tools that use netmap: There are only packet > generator and capture tools available. > -- 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 hannigan at gmail.com Fri Dec 27 02:23:46 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 26 Dec 2013 21:23:46 -0500 Subject: Data Center and IX Standards Published by Open-IX - Certification begins soon! In-Reply-To: References: Message-ID: On Fri, Nov 15, 2013 at 4:16 PM, David Temkin wrote: > I am proud to announce that the final versions of the Data Center and IXP > standards have been completed by their respective working groups and have > been published. > > Data Center: http://goo.gl/s4cGBp > > IXP: http://goo.gl/O5I1my > > Martin Hannigan will follow up shortly with scheduled dates for accepting > applications to become Open-IX Certified. We intend on accepting > applications for Northern Virginia first, immediately followed by NYC and > other markets. I missed this, sorry. NoVA opened a few weeks ago. That was a trial to see what we may have missed. We have received two completed applications there. We're effectively open in North America now and have recently received applications for facilities in AZ, OH and TX. Pending activity in the smaller MSA's like Boston, Cleveland and Omaha. Website == http://www.open-ix.org Announcements == https://www.facebook.com/OpenIXAssociation Mailing List == http://mailman.open-ix.org/mailman/listinfo/public I'm pretty sure we'll be doing an update in ATL. Happy holidays everyone. Best, -M< From Valdis.Kletnieks at vt.edu Fri Dec 27 06:33:26 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Dec 2013 01:33:26 -0500 Subject: The Making of a Router In-Reply-To: Your message of "Thu, 26 Dec 2013 11:16:53 -0800." <52BC80A5.1080208@rollernet.us> References: <52BC6661.6050702@trelane.net> <52BC80A5.1080208@rollernet.us> Message-ID: <130995.1388126006@turing-police.cc.vt.edu> On Thu, 26 Dec 2013 11:16:53 -0800, Seth Mattinen said: > On 12/26/13, 9:24, Andrew D Kirch wrote: > > > > If he can afford a 10G link... he should be buying real gear... I mean, > > look, I've got plenty of infrastructure horror stories, but lets not > > cobble together our own 10gbit solutions, please? At least get one of > > the new microtik CCR's with a 10gig sfp+? They're only a kilobuck... If > > you can't afford that I suggest you can't afford to be an ISP. > > > Unless all the money is going into the 10 gig link. If you've sunk so much into the 10G link (or anything else, for that matter) that you don't have a kilobuck to spare, you're probably undercapitalized to be an ISP. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From m.hotze at hotze.com Fri Dec 27 08:47:49 2013 From: m.hotze at hotze.com (Martin Hotze) Date: Fri, 27 Dec 2013 08:47:49 +0000 Subject: Mikrotik Cloud Core Router and BGP real life experiences? Message-ID: Hi, looking at the specs of Mikrotik Cloud Core Routers it seems to be to good to be true [1] having so much bang for the bucks. So virtually all smaller ISPs would drop their CISCO gear for Mikrotik Routerboards. We are using a handful of Mikrotik boxes, but on a much lower network level (splitting networks; low end router behind ADSL modem, ...). We're happy with them. So I am asking for real life experience and not lab values with Mikrotik Cloud Core Routers and BGP. How good can they handle full tables and a bunch of peering sessions? How good does the box react when adding filters (during attacks)? Reloading the table? etc. etc. I am looking for _real_ _life_ values compared to a CISCO NPE-G2. Please tell me/us from your first hand experience. Thanks! greetings, Martin [1] If something sounds too good to be true, it probably is. From geraint at koding.com Fri Dec 27 09:02:45 2013 From: geraint at koding.com (Geraint Jones) Date: Fri, 27 Dec 2013 22:02:45 +1300 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: Message-ID: <143CF099-E9B5-451D-8223-DA413D822ADE@koding.com> I am going to be deploying 4 as edge routers in the next few weeks, each will have 1 or 2 full tables plus partial IX tables. So I should have some empirical info soon. They will be doing eBGP to upstreams and iBGP/OSPF internally. I went with the 16gb RAM models. However these boxes are basically Linux running on top of tilera CPUs, in terms of throughput as long as everything stays on the fastpath they have no issues doing wire speed on all ports, however the moment you add a firewall rule or the like they drop to 1.5gbps. > On 27/12/2013, at 9:47 pm, Martin Hotze wrote: > > Hi, > > looking at the specs of Mikrotik Cloud Core Routers it seems to be to good to be true [1] having so much bang for the bucks. So virtually all smaller ISPs would drop their CISCO gear for Mikrotik Routerboards. > > We are using a handful of Mikrotik boxes, but on a much lower network level (splitting networks; low end router behind ADSL modem, ...). We're happy with them. > > So I am asking for real life experience and not lab values with Mikrotik Cloud Core Routers and BGP. How good can they handle full tables and a bunch of peering sessions? How good does the box react when adding filters (during attacks)? Reloading the table? etc. etc. > > I am looking for _real_ _life_ values compared to a CISCO NPE-G2. Please tell me/us from your first hand experience. > > Thanks! > > greetings, Martin > > [1] If something sounds too good to be true, it probably is. > > > From m.hotze at hotze.com Fri Dec 27 09:13:02 2013 From: m.hotze at hotze.com (Martin Hotze) Date: Fri, 27 Dec 2013 09:13:02 +0000 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <143CF099-E9B5-451D-8223-DA413D822ADE@koding.com> References: <143CF099-E9B5-451D-8223-DA413D822ADE@koding.com> Message-ID: Thanks, estimated traffic levels are at about half a gig, but at least 50 megs of UDP (VoIP) in both directions. one thing is that I haven't found a solution for redundant power supply. #m > -----Original Message----- > From: Geraint Jones [mailto:geraint at koding.com] > Sent: Friday, December 27, 2013 10:03 AM > To: Martin Hotze > Cc: nanog at nanog.org > Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? > > I am going to be deploying 4 as edge routers in the next few weeks, each > will have 1 or 2 full tables plus partial IX tables. So I should have some > empirical info soon. > > They will be doing eBGP to upstreams and iBGP/OSPF internally. I went with > the 16gb RAM models. > > However these boxes are basically Linux running on top of tilera CPUs, in > terms of throughput as long as everything stays on the fastpath they have > no issues doing wire speed on all ports, however the moment you add a > firewall rule or the like they drop to 1.5gbps. > > > > > On 27/12/2013, at 9:47 pm, Martin Hotze wrote: > > > (...) From ag4ve.us at gmail.com Fri Dec 27 09:21:30 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 27 Dec 2013 04:21:30 -0500 Subject: The Making of a Router In-Reply-To: <130995.1388126006@turing-police.cc.vt.edu> References: <52BC6661.6050702@trelane.net> <52BC80A5.1080208@rollernet.us> <130995.1388126006@turing-police.cc.vt.edu> Message-ID: On Fri, Dec 27, 2013 at 1:33 AM, wrote: > On Thu, 26 Dec 2013 11:16:53 -0800, Seth Mattinen said: >> On 12/26/13, 9:24, Andrew D Kirch wrote: >> > >> > If he can afford a 10G link... he should be buying real gear... I mean, >> > look, I've got plenty of infrastructure horror stories, but lets not >> > cobble together our own 10gbit solutions, please? At least get one of >> > the new microtik CCR's with a 10gig sfp+? They're only a kilobuck... If >> > you can't afford that I suggest you can't afford to be an ISP. >> >> >> Unless all the money is going into the 10 gig link. > > If you've sunk so much into the 10G link (or anything else, for that matter) > that you don't have a kilobuck to spare, you're probably undercapitalized to be > an ISP. > I have issue with this line of thought. Granted, a router is built with custom ASICs and most network people understand IOS. However, this is where the benefit of a multi-thousand buck router ends. Most have limited RAM, so this limits the size of your policies and how many routes can be stored and the likes. With a computer with multi 10s or 100s of gigs of RAM, this really isn't an issue. Routers also have slow-ish processors (which is fine for pure routing since they are custom chips but) if you want to do packet inspection, this can slow things down quite a bit. You could argue that this is the same with iptables or pf. However, if you just offload the packets and analyze generally boring packets with snort or bro or whatever, packets flow as fast as they would without analysis. If you have multiple VPNs, this can start to slow down a router whereas a computer can generally keep up. ... And then there's the money issue. Sure, if you're buying a gig+ link, you should be able to afford a fully spec'd out router. However, (in my experience) people don't order equipment with all features enabled and when you find you need a feature, you have to put in a request to buy it and then it takes a month (if you're lucky) for it to be approved. This isn't the case if you use ipt/pf - if te feature is there, it's there - use it. And if a security flaw is found in a router, it might be fixed in the next month... or not. With Linux/BSD, it'll be fixed within a few days (at the most). And, if your support has expired on a router or the router is EOL, you're screwed. I think in the near future, processing packets with GPUs will become a real thing which will make doing massive real time deep packet inspection at 10G+ a real thing. Granted, your network people knowing IOS when they're hired is a big win for just ordering Cisco. But, I don't see that as a show stopper. Stating the scope of what a box is supposed to be used for and not putting endless crap on it might be another win for an actual router. However, this is a people/business thing and not a technical issue. Also, I'm approaching this as more of a question of the best tool for the job vs pure economics - a server is generally going to be cheaper, but I generally find a server nicer/easier to configure than a router. From geraint at koding.com Fri Dec 27 09:24:12 2013 From: geraint at koding.com (Geraint Jones) Date: Fri, 27 Dec 2013 22:24:12 +1300 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: <143CF099-E9B5-451D-8223-DA413D822ADE@koding.com> Message-ID: <7BEC4AD0-2E73-42F3-875A-34E97FA0D932@koding.com> > On 27/12/2013, at 10:13 pm, Martin Hotze wrote: > > Thanks, > > estimated traffic levels are at about half a gig, but at least 50 megs of UDP (VoIP) in both directions. > > one thing is that I haven't found a solution for redundant power supply. > Buy 2 :) > #m > >> -----Original Message----- >> From: Geraint Jones [mailto:geraint at koding.com] >> Sent: Friday, December 27, 2013 10:03 AM >> To: Martin Hotze >> Cc: nanog at nanog.org >> Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? >> >> I am going to be deploying 4 as edge routers in the next few weeks, each >> will have 1 or 2 full tables plus partial IX tables. So I should have some >> empirical info soon. >> >> They will be doing eBGP to upstreams and iBGP/OSPF internally. I went with >> the 16gb RAM models. >> >> However these boxes are basically Linux running on top of tilera CPUs, in >> terms of throughput as long as everything stays on the fastpath they have >> no issues doing wire speed on all ports, however the moment you add a >> firewall rule or the like they drop to 1.5gbps. >> >> >> >>> On 27/12/2013, at 9:47 pm, Martin Hotze wrote: >> (...) From rps at maine.edu Fri Dec 27 10:14:39 2013 From: rps at maine.edu (Ray Soucy) Date: Fri, 27 Dec 2013 05:14:39 -0500 Subject: The Making of a Router In-Reply-To: References: <52BC5F65.3020001@trelane.net> Message-ID: In talking about RAMBOOT I also realized the instructions are out of date on the website. The "ramboot" boot target script was updated since I created the initial page to generate the correct fstab, and enable the root account, set a hostname, etc. so you can actually use the OS until you create a new image. I extracted the script from the initird to make it easier to grab: http://ramboot.org/download/RAMBOOT/RAMBOOT-pre0.2/SYSLINUX/initrd/scripts/ramboot Essentially, by adding a new "ramboot" script to "/usr/share/initramfs-tools/scripts" along side "nfs" and "local" it creates a new "boot=" target (since the init script looks for "scripts/${BOOT}". As mentioned on the website, the ramboot process needs a more complete version of busybox (for tar archive support) and the mke2fs tool added to "/usr/lib/initramfs-tools/bin/" so they will be available to the initrd. Once you configure networking (see the "INSTALL/setup_network" script) you can do an apt-get update and apt-get the packages you need from Ubuntu 12.04 LTS. Example starting point: apt-get install sudo apt-get install nano apt-get install ssh apt-get install vlan apt-get install bridge-utils On Thu, Dec 26, 2013 at 8:27 PM, Ray Soucy wrote: > The basic idea of RAMBOOT is typical in Embedded Linux development. > > Linux makes use of multi-stage boot process. One of the stages involves > using an initial ramdisk (initrd) to provide a base root filesystem which > can be used to locate and mount the system root, then continue the boot > process from there. > > For an in-memory OS, instead of the boot process mounting a pre-loaded > storage device with the expected root filesystem (e.g. your installed HDD), > you modify it to: > > 1) Create and format a ramdisk. > 2) Create the expected directory structure and system files for the root > filesystem on that ramdisk. > > The root filesystem includes the /dev directory and appropriate device > nodes, the basic Linux filesystem and your init program. > > The easy way to do that is just to have a TAR archive that you extract to > the ramdisk on boot, better yet use compression on it (e.g. tar.gz) so that > the archive can be read from storage (e.g. USB flash) more quickly. > > Today, the initramfs in Linux handles a lot more than simply mounting the > storage device. It performs hardware discovery and loads appropriate > modules. As such the Debian project has a dynamic build system for > initramfs that is run to build the initrd when a new kernel package is > installed, it's called "initramfs-tools". > > You can manually build your own initramfs using the examples on the > RAMBOOT website, but the point of RAMBOOT is to make building an in-memory > OS quick and simple. > > RAMBOOT instead adds configuration to initramfs-tools so that each time a > new initrd is generated, it includes the code needed for RAMBOOT. > > The RAMBOOT setup adds handling of a new boot target called "ramboot" to > the kernel arguments. This allows the same kernel to be used for a normal > installation and remain unaffected, but when you add the argument > "boot=ramboot" as a kernel option to the bootloader, it triggers the > RAMBOOT process described above. > > Having a common kernel between your development environment and embedded > environment makes it much easier to test and verify functionality. > > The other part of RAMBOOT is that it makes use of "Ubuntu Core". Ubuntu > Core is a stripped down minimal (and they really do mean minimal) root > filesystem for Embedded Linux development. It includes apt-get, though, so > you can install all the packages you need from Ubuntu on the running system. > > RAMBOOT then has a development script to make a new root filesystem > archive with the packages you've installed as a baseline. This allows for > you to boot a RAMBOOT system, install your desired packages and change > system configuration files as desired, then build a persistent image of > that install that will be used for future boots. > > I also have the start of a script to remove unused kernel modules, and > other files (internationalization for example) which add to the OS > footprint. > > You could build the root filesystem on your own (and compile all the > necessary packages) but using Ubuntu Core provides a solid base and allows > for the rapid addition of packages from the giant Ubuntu repository. > > Lastly, I make use of SYSLINUX as a bootloader because my goal was to use > a USB stick as the bootflash on an Atom box. Unfortunately, the Atom BIOS > will only boot a USB device if it has a DOS boot partition, so GRUB was a > no-go. The upside is that since the USB uses SYSLINUX and is DOS > formatted, it's easily mounted in Windows or Mac OS X, allowing you to copy > new images or configuration to it easily. > > For the boot device I make use of the on-board vertical USB socket on the > system board (typical for most system boards these days) and a low-profile > USB stick. I find the Verbatim "Store 'n' Go" 8GB USB stick ideally suited > for this as it's less than a quarter-inch high after the USB adapter. > > RAMBOOT as a project is in the very early stages, so you should be > comfortable with Linux before you build a system on it. And I really feel > it's more of an example than anything at this point. > > There are several advantages though: > > The most common point of failure on a Linux system is the storage device > (either HDD or SSD). > The biggest bottleneck in system performance is storage IO. > Using a ramdisk eliminates both these concerns (in fact, even an Atom > system has surprisingly great performance when run using a ramdisk). > > The result is that you get a very reliable, high-performance system. > > The other benefit to RAMBOOT is that the root filesystem is NOT > persistent. This means that like a Cisco device, every boot of the system > brings you to a known working state OS-wise. There are hundreds of system > files in a Linux system; any one of which being modified could cause > problems. For both security and availability concerns a lot of effort is > invested in detecting changes to system files and avoiding them. With > RAMBOOT the problem is easily avoided. > > A minimal system can fit within a 512MB ramdisk. But with RAM being so > cheap these days, I think even reserving up to 2GB of RAM for a ramdisk > would be fine (e.g. for a 4-8GB system). > > Here is the hardware configuration I originally started RAMBOOT for in > 2011 (wanted to avoid the cost of an HDD): > > $326.36 (shipping included): > 1U rack-mount case Supermicro CSE-502L-200B > Intel Atom D510 system board with dual Gigabit (Intel 82574L) Supermicro > MBD-X7SPA-H-O > 2GB RAM > 8GB low-profile USB flash drive (which will connect to the internal USB > port and be low enough to fit in the case) Verbatim "Store n Stay". > > No HD; the system will boot off the 8GB flash into RAM and run the OS on a > ramdisk. > > Using the RAMBOOT release that's currently up, I can build a custom Linux > in-memory OS in half a day. I can easily update packages for security > updates from the Ubuntu project and re-generate a new, updated, image in > less time than that. So the initial goal of being able to build something > useful quickly was satisfied, at least. My attention has now moved on to > building a configuration management system, similar to Vyatta or VyOS and > building a real distribution. I was going to call it "Carrier-grade Linux" > (cglinux.org), but given the momentum VyOS has I might try to help the > VyOS community instead of doing something new on my own. > > For what it's worth, I'm actually working with the VyOS project to try and > incorporate some of the RAMBOOT ideas into VyOS as an install option for > in-memory only. > > If you make use of RAMBOOT I would love to hear about it. :-) > > > > > > > On Thu, Dec 26, 2013 at 4:22 PM, Nick Cameo wrote: > >> Inline response exist, >> >> On 12/26/13, Ray Soucy wrote: >> > You can build using commodity hardware and get pretty good results. >> > >> > I've had really good luck with Supermicro whitebox hardware, and >> > Intel-based network cards. The "Hot Lava Systems" cards have a nice >> > selection for a decent price if you're looking for SFP and SFP+ cards >> that >> > use Intel chipsets. >> >> I like the supermicro as well however we have a couple of IBM x3250 >> with 2 pcie v3 >> x8 that are begging for a intel network card. >> >> > There might be some benefits in going with something like FreeBSD, but I >> > find that Linux has a lot more eyeballs on it making it much easier to >> > develop for, troubleshoot, and support. There are a few options if you >> > want to go the Linux route. >> >> This is very important to consider. I would be speculating, or even >> worse, expecting >> the same type of community support from the BSD verse that I have been >> getting from the linux community. >> >> > >> > Option 1: Roll your own OS. This takes quite a bit of effort, but if >> you >> > have the tallant to do it you can generally get exactly what you want. >> >> If Free/OpenBSD is ruled out, I could crack open the LFS project. You only >> have to do it once right? Or maybe just reach out to the gentoo community >> for a stripped version, and build outwards. >> >> > The biggest point of failure I've experienced with Linux-based routers >> on >> > whitebox hardware has been HDD failure. Other than that, the 100+ units >> > I've had deployed over the past 3+ years have been pretty much flawless. >> > >> >> SSD >> >> > Thankfully, they currently run an in-memory OS, so a disk failure only >> > affects logging. >> > If you want to build your own OS, I'll shamelessly plug a side project >> of >> > mine: RAMBOOT >> > >> > http://ramboot.org/ >> > >> > RAMBOOT makes use of the Ubuntu Core rootfs, and a modified boot process >> > (added into initramfs tools, so kernel updates generate the right kernel >> > automatically). Essentially, I use a kernel ramdisk instead of an HDD >> for >> > the root filesystem and "/" is mounted on "/dev/ram1". >> > >> > The bootflash can be removed while the system is running as it's only >> > mounted to save system configuration or update the OS. >> > >> > I haven't polished it up much, but there is enough there to get going >> > pretty quickly. >> >> Ummm, if it's ok with the community, can you kindly elaborate :). I am >> not too fond of Debian since my horrible experience with Squeeze Desktop. >> I would maybe like to try this using the combination of SSD, in memory, >> and >> Gentoo? >> >> > >> > You'll also want to pay attention to the settings you use for the >> kernel. >> > Linux is tuned as a desktop or server, not a router, so there are some >> > basics you should take care of (like disabling ICMP redirects, >> increasing >> > the ARP table size, etc). >> >> Totally strip it as much as possible. If anyone has a Gentoo stripped >> kernel >> config that they would like to share, please do :). >> >> > >> > I have some examples in: http://soucy.org/xorp/xorp-1.7-pre/TUNING >> > or http://soucy.org/tmp/netfilter.txt (more recent, but includes >> firewall >> > examples). >> >> Will definitely look into all your sites. >> >> > >> > Also a note of caution. I would stick with a longterm release of Linux. >> > I've had good experience with 2.6.32, and 3.10. I'm eager to use some >> of >> > the post-3.10 features, though, so I'm anxious for the next longterm >> branch >> > to be locked in. >> > >> >> We are comfy with 3.4 right now... >> >> >> > One of the biggest advantages is the low cost of hardware allows you to >> > maintain spare systems, reducing the time to service restoration in the >> > event of failure. Dependability-wise, I feel that whitebox Linux >> systems >> > are pretty much at Cisco levels these days, especially if running >> > in-memory. >> >> Really interested with the "in-memory", however, I would love to implement >> it using gentoo as mentioned above. >> >> >> Kind Regards, >> >> N. >> > > > > -- > 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 > -- 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 m.hotze at hotze.com Fri Dec 27 10:59:54 2013 From: m.hotze at hotze.com (Martin Hotze) Date: Fri, 27 Dec 2013 10:59:54 +0000 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <7BEC4AD0-2E73-42F3-875A-34E97FA0D932@koding.com> References: <143CF099-E9B5-451D-8223-DA413D822ADE@koding.com> <7BEC4AD0-2E73-42F3-875A-34E97FA0D932@koding.com> Message-ID: > > On 27/12/2013, at 10:13 pm, Martin Hotze wrote: > > > > Thanks, > > > > estimated traffic levels are at about half a gig, but at least 50 megs > of UDP (VoIP) in both directions. > > > > one thing is that I haven't found a solution for redundant power supply. > > > Buy 2 :) on 3am I only want to read the notification and know what to do first in the morning. And not jump out and bring the spare into production. #m From baldur.norddahl at gmail.com Fri Dec 27 13:05:09 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 27 Dec 2013 14:05:09 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: On the topic of building a software router for an ISP, has anyone tried it using OpenFlow? The idea is to have a Linux server run BGP and a hardware switch to move the packets. The switch would be programmed by the Linux server using the OpenFlow protocol. I am looking at the HP 5400 zl switches as the hardware platform and RouteFlow https://sites.google.com/site/routeflow/ to program the BGP rules. One issue is that the HP switch will only allow a limited amount of rules to be processed in hardware (about 4096 rules I believe). Will this be enough to cover most of the traffic of a FTTH ISP on the fast path? Regards, Baldur From eugen at imacandi.net Fri Dec 27 13:11:16 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Fri, 27 Dec 2013 15:11:16 +0200 Subject: The Making of a Router In-Reply-To: References: Message-ID: On Fri, Dec 27, 2013 at 3:05 PM, Baldur Norddahl wrote: > On the topic of building a software router for an ISP, has anyone tried it > using OpenFlow? The idea is to have a Linux server run BGP and a hardware > switch to move the packets. The switch would be programmed by the Linux > server using the OpenFlow protocol. > > I am looking at the HP 5400 zl switches as the hardware platform and > RouteFlow https://sites.google.com/site/routeflow/ to program the BGP > rules. > > One issue is that the HP switch will only allow a limited amount of rules > to be processed in hardware (about 4096 rules I believe). Will this be > enough to cover most of the traffic of a FTTH ISP on the fast path? > You want to use the switch for what ? To connect last-mile customers ? For L3 aggregation ? You want to run the switch as an edge router with limited BGP ? What's the exact use case you are thinking about ? Eugeniu From francois at menards.ca Fri Dec 27 13:47:53 2013 From: francois at menards.ca (Francois Menard) Date: Fri, 27 Dec 2013 08:47:53 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: <501477B6-89B8-4AB6-991D-A3E6187626CA@menards.ca> You could look into Noviflow! F. Sent from my mobile device. Apologies for any typo. > On Dec 27, 2013, at 8:05, Baldur Norddahl wrote: > > On the topic of building a software router for an ISP, has anyone tried it > using OpenFlow? The idea is to have a Linux server run BGP and a hardware > switch to move the packets. The switch would be programmed by the Linux > server using the OpenFlow protocol. > > I am looking at the HP 5400 zl switches as the hardware platform and > RouteFlow https://sites.google.com/site/routeflow/ to program the BGP rules. > > One issue is that the HP switch will only allow a limited amount of rules > to be processed in hardware (about 4096 rules I believe). Will this be > enough to cover most of the traffic of a FTTH ISP on the fast path? > > Regards, > > Baldur From bclark at spectraaccess.com Fri Dec 27 13:55:59 2013 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 27 Dec 2013 08:55:59 -0500 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: <143CF099-E9B5-451D-8223-DA413D822ADE@koding.com> <7BEC4AD0-2E73-42F3-875A-34E97FA0D932@koding.com> Message-ID: <52BD86EF.3070103@spectraaccess.com> On 12/27/2013 05:59 AM, Martin Hotze wrote: >>> On 27/12/2013, at 10:13 pm, Martin Hotze wrote: >>> >>> Thanks, >>> >>> estimated traffic levels are at about half a gig, but at least 50 megs >> of UDP (VoIP) in both directions. >>> one thing is that I haven't found a solution for redundant power supply. >>> >> Buy 2 :) > on 3am I only want to read the notification and know what to do first in the morning. And not jump out and bring the spare into production. > > #m > > You set them both up configure the spare for fail-over. From mjkelly at gmail.com Fri Dec 27 14:02:02 2013 From: mjkelly at gmail.com (matt kelly) Date: Fri, 27 Dec 2013 09:02:02 -0500 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: Message-ID: My real world experience with these is that they suck. Plain and simple. Don't waste your time. On Dec 27, 2013 3:49 AM, "Martin Hotze" wrote: > Hi, > > looking at the specs of Mikrotik Cloud Core Routers it seems to be to good > to be true [1] having so much bang for the bucks. So virtually all smaller > ISPs would drop their CISCO gear for Mikrotik Routerboards. > > We are using a handful of Mikrotik boxes, but on a much lower network > level (splitting networks; low end router behind ADSL modem, ...). We're > happy with them. > > So I am asking for real life experience and not lab values with Mikrotik > Cloud Core Routers and BGP. How good can they handle full tables and a > bunch of peering sessions? How good does the box react when adding filters > (during attacks)? Reloading the table? etc. etc. > > I am looking for _real_ _life_ values compared to a CISCO NPE-G2. Please > tell me/us from your first hand experience. > > Thanks! > > greetings, Martin > > [1] If something sounds too good to be true, it probably is. > > > > From ray at oneunified.net Fri Dec 27 14:05:56 2013 From: ray at oneunified.net (Raymond Burkholder) Date: Fri, 27 Dec 2013 10:05:56 -0400 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: Message-ID: <075801cf030c$c4002b30$4c008190$@oneunified.net> >My real world experience with these is that they suck. Plain and simple. >Don't waste your time. Would you mind elaborating what you were trying to accomplish and what failed? Thank you. Ray -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From listas at esds.com.br Fri Dec 27 14:10:24 2013 From: listas at esds.com.br (Eduardo Schoedler) Date: Fri, 27 Dec 2013 12:10:24 -0200 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: Message-ID: People who tested say they don't forward more than 500Mbps per port. 2013/12/27 matt kelly > My real world experience with these is that they suck. Plain and simple. > Don't waste your time. > On Dec 27, 2013 3:49 AM, "Martin Hotze" wrote: > > > Hi, > > > > looking at the specs of Mikrotik Cloud Core Routers it seems to be to > good > > to be true [1] having so much bang for the bucks. So virtually all > smaller > > ISPs would drop their CISCO gear for Mikrotik Routerboards. > > > > We are using a handful of Mikrotik boxes, but on a much lower network > > level (splitting networks; low end router behind ADSL modem, ...). We're > > happy with them. > > > > So I am asking for real life experience and not lab values with Mikrotik > > Cloud Core Routers and BGP. How good can they handle full tables and a > > bunch of peering sessions? How good does the box react when adding > filters > > (during attacks)? Reloading the table? etc. etc. > > > > I am looking for _real_ _life_ values compared to a CISCO NPE-G2. Please > > tell me/us from your first hand experience. > > > > Thanks! > > > > greetings, Martin > > > > [1] If something sounds too good to be true, it probably is. > > > > > > > > > -- Eduardo Schoedler From dmburgess at linktechs.net Fri Dec 27 14:39:57 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 27 Dec 2013 08:39:57 -0600 Subject: [SPAM]RE: [SPAM]Re: Mikrotik Cloud Core Router and BGP real life experiences? References: Message-ID: <50710E9A7E64454C974049FC998EB655018DDD92@03-exchange.lti.local> Guess I should chime in here. As far as the CCR, I know several customers running in excess of 1 gig of traffic though them, one has 16 BGP sessions, several of those are full tables, and the rest are on an peering exchange. There are other units, like the ones we supply, that does more than 20 gig in real word usages. They are very capable devices, but depending on how many features you enable, of course that will affect their overall abilities. This would be real word, and yes, I work with 1000's of ISPs across North America, many between 100-10gig of traffic, cable companies, DSL providers, and WISPs, and many of these ONLY use MikroTik. As another person said, grab two and configure so that you split your load up, we have done that in areas where redundancy is important. Seeing the Dual 10GigE model with 8 GigE ports costs $1,249 or so, hard to beat them in price, and add two or more to get your redundancy. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? ?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? ?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? ?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? -----Original Message----- From: Eduardo Schoedler [mailto:listas at esds.com.br] Sent: Friday, December 27, 2013 8:10 AM To: NANOG list Subject: [SPAM]Re: Mikrotik Cloud Core Router and BGP real life experiences? People who tested say they don't forward more than 500Mbps per port. 2013/12/27 matt kelly > My real world experience with these is that they suck. Plain and simple. > Don't waste your time. > On Dec 27, 2013 3:49 AM, "Martin Hotze" wrote: > > > Hi, > > > > looking at the specs of Mikrotik Cloud Core Routers it seems to be > > to > good > > to be true [1] having so much bang for the bucks. So virtually all > smaller > > ISPs would drop their CISCO gear for Mikrotik Routerboards. > > > > We are using a handful of Mikrotik boxes, but on a much lower > > network level (splitting networks; low end router behind ADSL modem, > > ...). We're happy with them. > > > > So I am asking for real life experience and not lab values with > > Mikrotik Cloud Core Routers and BGP. How good can they handle full > > tables and a bunch of peering sessions? How good does the box react > > when adding > filters > > (during attacks)? Reloading the table? etc. etc. > > > > I am looking for _real_ _life_ values compared to a CISCO NPE-G2. > > Please tell me/us from your first hand experience. > > > > Thanks! > > > > greetings, Martin > > > > [1] If something sounds too good to be true, it probably is. > > > > > > > > > -- Eduardo Schoedler From mjkelly at gmail.com Fri Dec 27 14:40:51 2013 From: mjkelly at gmail.com (matt kelly) Date: Fri, 27 Dec 2013 09:40:51 -0500 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <075801cf030c$c4002b30$4c008190$@oneunified.net> References: <075801cf030c$c4002b30$4c008190$@oneunified.net> Message-ID: They can not handle a full routing table. The load balancing doesn't work. They can not properly reassemble fragmented packets, and therefore drop all but the first "piece". They can not reliably handle traffic loads over maybe 200 Mbps, we needed 4-6 Gbps capacity. They can not hold a gre tunnel connection. On Dec 27, 2013 9:07 AM, "Raymond Burkholder" wrote: > > >My real world experience with these is that they suck. Plain and simple. > >Don't waste your time. > > Would you mind elaborating what you were trying to accomplish and what > failed? > > Thank you. > > Ray > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > From brandon at bitradius.com Fri Dec 27 14:29:17 2013 From: brandon at bitradius.com (Brandon Lehmann) Date: Fri, 27 Dec 2013 14:29:17 +0000 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <075801cf030c$c4002b30$4c008190$@oneunified.net> References: , <075801cf030c$c4002b30$4c008190$@oneunified.net> Message-ID: <15AE4040AA24964AAE3DA9F2DE04C4F5012D884DAC@W2K8-EX.corp.bitradius.com> I too am curious... We've used them for a few months as edge devices and most (if not all) *knock on wood* of the issues we've had have been fixed by RouterOS updates, configuration changes (lots of chefs in the kitchen), or were circuit/carrier related. While I would never compare them apples-to-apples to Cisco, Juniper, etc devices... they have, in our experience, proven to be good inexpensive routers with a few quirks here and there. ________________________________________ From: Raymond Burkholder [ray at oneunified.net] Sent: Friday, December 27, 2013 9:05 AM To: 'NANOG list' Subject: RE: Mikrotik Cloud Core Router and BGP real life experiences? >My real world experience with these is that they suck. Plain and simple. >Don't waste your time. Would you mind elaborating what you were trying to accomplish and what failed? Thank you. Ray -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dmburgess at linktechs.net Fri Dec 27 15:00:17 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 27 Dec 2013 09:00:17 -0600 Subject: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? References: <075801cf030c$c4002b30$4c008190$@oneunified.net> Message-ID: <50710E9A7E64454C974049FC998EB655018DDD93@03-exchange.lti.local> We have many with full routing tables. Load balancing, works fine, I have one site with 8 DSL lines doing balancing across them. We typically don't use a GRE tunnel, but OpenVPN or IPSEC work great. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? ?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? ?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? ?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? -----Original Message----- From: matt kelly [mailto:mjkelly at gmail.com] Sent: Friday, December 27, 2013 8:41 AM To: Raymond Burkholder Cc: NANOG list Subject: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? They can not handle a full routing table. The load balancing doesn't work. They can not properly reassemble fragmented packets, and therefore drop all but the first "piece". They can not reliably handle traffic loads over maybe 200 Mbps, we needed 4-6 Gbps capacity. They can not hold a gre tunnel connection. On Dec 27, 2013 9:07 AM, "Raymond Burkholder" wrote: > > >My real world experience with these is that they suck. Plain and simple. > >Don't waste your time. > > Would you mind elaborating what you were trying to accomplish and what > failed? > > Thank you. > > Ray > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. > > > From baldur.norddahl at gmail.com Fri Dec 27 15:07:18 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 27 Dec 2013 16:07:18 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: I need a solution for everything except the last-mile customers. The customers are connected to a Zhone PON switch. From there they will arrive at our core switch as Q-in-Q vlans, one vlan per customer. I need a router that will do two full routing tables for our uplinks, a number of partial routing tables for our IX peers, IPv6 support, IPv4 proxy arp support and the ability to handle a large number of Q-in-Q vlans. And of course I will need two for redundancy. The uplinks, the links to edge switches and many of the IX peers are all 10 Gbit/s links. IPv4 proxy arp is especially important given the state of IPv4 exhaustion. Being a new ISP in the RIPE region, we only got 1024 IPs. When we run out of that initial assignment, we have to buy IP-addresses at a steep price. Therefore we can not afford to give each home a full IPv4 subnet. They will have to share the subnet with multiple other customers. This is achieved through proxy arp on the switch. We are an upstart and just buying the fancy Juniper switch times two would burn half of my seed capital. Like Nick Cameo I have seriously considered going with a Linux solution. I know I can build it. I just don't know if I can make it stable enough or make it perform good enough. I am looking into an OpenFlow solution as a middle ground. It allows me to buy cheaper switches/routers. The servers will do the "thinking" but the actual work of moving packets is still done in hardware on the switches. OpenFlow supports controller fail over, so I will not go down with just one server crash. Poor performance on the servers will not affect customer traffic directly. Regards, Baldur On Fri, Dec 27, 2013 at 2:11 PM, Eugeniu Patrascu wrote: > On Fri, Dec 27, 2013 at 3:05 PM, Baldur Norddahl < > baldur.norddahl at gmail.com> wrote: > >> On the topic of building a software router for an ISP, has anyone tried it >> using OpenFlow? The idea is to have a Linux server run BGP and a hardware >> switch to move the packets. The switch would be programmed by the Linux >> server using the OpenFlow protocol. >> >> I am looking at the HP 5400 zl switches as the hardware platform and >> RouteFlow https://sites.google.com/site/routeflow/ to program the BGP >> rules. >> >> One issue is that the HP switch will only allow a limited amount of rules >> to be processed in hardware (about 4096 rules I believe). Will this be >> enough to cover most of the traffic of a FTTH ISP on the fast path? >> > > You want to use the switch for what ? To connect last-mile customers ? For > L3 aggregation ? You want to run the switch as an edge router with limited > BGP ? What's the exact use case you are thinking about ? > > Eugeniu > From fohdeesha at gmail.com Fri Dec 27 15:18:47 2013 From: fohdeesha at gmail.com (Jon Sands) Date: Fri, 27 Dec 2013 10:18:47 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: On Dec 27, 2013 10:08 AM, "Baldur Norddahl" wrote: > We are an upstart and just buying the fancy Juniper switch times two would burn half of my seed capital. Then you didn't ask for nearly enough capital. From faisal at snappytelecom.net Fri Dec 27 15:31:37 2013 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 27 Dec 2013 15:31:37 +0000 (GMT) Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <143CF099-E9B5-451D-8223-DA413D822ADE@koding.com> References: <143CF099-E9B5-451D-8223-DA413D822ADE@koding.com> Message-ID: <147103975.349858.1388158297792.JavaMail.root@snappytelecom.net> FYI... Mikrotik Cloud Core routers are nice, however one has to keep something in mind when deploying them... Only One Core (of the CPU) is dedicated to each port / process. So this is good so as to contain what happens on a single port from taxing the whole CPU.. But not so good when you need more cpu power than a single core for that port. Also, BGP process will only use one core. While these units make for great 'customer facing' edge routers, with plenty of power and the ability to keep issues contained... The X-86 based (Core2Duo/i5/i7) Mikrotik are more suitable (Processing power wise) for running multiple full BGP tables peering. Regards & Good Luck. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Geraint Jones" > To: "Martin Hotze" > Cc: nanog at nanog.org > Sent: Friday, December 27, 2013 4:02:45 AM > Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? > > I am going to be deploying 4 as edge routers in the next few weeks, each will > have 1 or 2 full tables plus partial IX tables. So I should have some > empirical info soon. > > They will be doing eBGP to upstreams and iBGP/OSPF internally. I went with > the 16gb RAM models. > > However these boxes are basically Linux running on top of tilera CPUs, in > terms of throughput as long as everything stays on the fastpath they have no > issues doing wire speed on all ports, however the moment you add a firewall > rule or the like they drop to 1.5gbps. > > > > > On 27/12/2013, at 9:47 pm, Martin Hotze wrote: > > > > Hi, > > > > looking at the specs of Mikrotik Cloud Core Routers it seems to be to good > > to be true [1] having so much bang for the bucks. So virtually all smaller > > ISPs would drop their CISCO gear for Mikrotik Routerboards. > > > > We are using a handful of Mikrotik boxes, but on a much lower network level > > (splitting networks; low end router behind ADSL modem, ...). We're happy > > with them. > > > > So I am asking for real life experience and not lab values with Mikrotik > > Cloud Core Routers and BGP. How good can they handle full tables and a > > bunch of peering sessions? How good does the box react when adding filters > > (during attacks)? Reloading the table? etc. etc. > > > > I am looking for _real_ _life_ values compared to a CISCO NPE-G2. Please > > tell me/us from your first hand experience. > > > > Thanks! > > > > greetings, Martin > > > > [1] If something sounds too good to be true, it probably is. > > > > > > > > From rnalrd at gmail.com Fri Dec 27 15:35:04 2013 From: rnalrd at gmail.com (Leonardo Arena) Date: Fri, 27 Dec 2013 16:35:04 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: <1388158504.5276.45.camel@df1844j> On gio, 2013-12-26 at 11:33 -0500, Nick Cameo wrote: > Hello Everyone, > > We are looking to put together a 2u server with a few PCIe 3 x8 > (recommendations appreciated). The router will take a voip transcoding > line card, and will act as an edge router for a telecom company. > > For things like BGP (Quagga, Zebra, all that lovely stuff!!!), static > routes, and firewall capabilities we are thinking gentoo linux > stripped for sure however, what about the BSDs? FreeBSD or OpenBSD. > Any comments, feedback, does, and don'ts are much appreciated. > > Kind Regards, > > Nick. > I would definitely consider Alpine Linux [1], which is designed exactly for that purpose. Small footprint, run-from-ram, config from on flash, security oriented. KR, - leo [1] http://alpinelinux.org/about From streiner at cluebyfour.org Fri Dec 27 12:23:36 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 27 Dec 2013 07:23:36 -0500 (EST) Subject: The Making of a Router In-Reply-To: <52BC6661.6050702@trelane.net> References: <52BC6661.6050702@trelane.net> Message-ID: On Thu, 26 Dec 2013, Andrew D Kirch wrote: > If he can afford a 10G link... he should be buying real gear... I mean, > look, I've got plenty of infrastructure horror stories, but lets not cobble > together our own 10gbit solutions, please? At least get one of the new > microtik CCR's with a 10gig sfp+? They're only a kilobuck... If you can't > afford that I suggest you can't afford to be an ISP. +1 Build-your-own routers are perfectly OK for a lab environment if you want to tinker with something, but I absolutely would not put an all-in-one box that I built myself in production. You end up combining some of the downsides of a hardware-based router with some of the downsides of a server (new attack vectors, another device that needs to be backed up, patched, and monitored, possibly getting a new collection of devices and drivers to play nicely with each other, etc). Doing this also requires all of the people in your on-call rotation to be experienced sysadmins / server ops, in addition to being experiences network engineers / NOC ops. There are a lot of occasions with a server where 'just reboot it' can make a problem much worse. Route servers running Linux or *BSD are another story. There are many situations where they can be extremely useful, but they are not all-in-one route server/RADIUS/VPN termination/web server/user shell boxes. jms From nick at flhsi.com Fri Dec 27 16:00:26 2013 From: nick at flhsi.com (Nick Olsen) Date: Fri, 27 Dec 2013 11:00:26 -0500 Subject: Mikrotik Cloud Core Router and BGP real life experiences? Message-ID: <10093d8d$1fc2b14f$24c67684$@flhsi.com> Exactly what Faisal Said. The BGP process appears to be single threaded at the moment. So taking on full BGP tables can be a bit slow compared to a decent X86 box. But in terms of raw forwarding power they are pretty monstrous. We replaced a few Maxxwave 6 port Atom's with the CCR. ~400Mb/s and ~40K pps aggregate across all ports. CPU load went from ~25% to ~0-2%. These are in a configuration where they have little or no firewall/nat/queue rules. And in most cases are running MPLS. We've not had any issues with stability so far either (Knock on wood). Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Faisal Imtiaz" Sent: Friday, December 27, 2013 10:33 AM To: "Geraint Jones" Cc: nanog at nanog.org, "Martin Hotze" Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? FYI... Mikrotik Cloud Core routers are nice, however one has to keep something in mind when deploying them... Only One Core (of the CPU) is dedicated to each port / process. So this is good so as to contain what happens on a single port from taxing the whole CPU.. But not so good when you need more cpu power than a single core for that port. Also, BGP process will only use one core. While these units make for great 'customer facing' edge routers, with plenty of power and the ability to keep issues contained... The X-86 based (Core2Duo/i5/i7) Mikrotik are more suitable (Processing power wise) for running multiple full BGP tables peering. Regards & Good Luck. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Geraint Jones" > To: "Martin Hotze" > Cc: nanog at nanog.org > Sent: Friday, December 27, 2013 4:02:45 AM > Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? > > I am going to be deploying 4 as edge routers in the next few weeks, each will > have 1 or 2 full tables plus partial IX tables. So I should have some > empirical info soon. > > They will be doing eBGP to upstreams and iBGP/OSPF internally. I went with > the 16gb RAM models. > > However these boxes are basically Linux running on top of tilera CPUs, in > terms of throughput as long as everything stays on the fastpath they have no > issues doing wire speed on all ports, however the moment you add a firewall > rule or the like they drop to 1.5gbps. > > > > > On 27/12/2013, at 9:47 pm, Martin Hotze wrote: > > > > Hi, > > > > looking at the specs of Mikrotik Cloud Core Routers it seems to be to good > > to be true [1] having so much bang for the bucks. So virtually all smaller > > ISPs would drop their CISCO gear for Mikrotik Routerboards. > > > > We are using a handful of Mikrotik boxes, but on a much lower network level > > (splitting networks; low end router behind ADSL modem, ...). We're happy > > with them. > > > > So I am asking for real life experience and not lab values with Mikrotik > > Cloud Core Routers and BGP. How good can they handle full tables and a > > bunch of peering sessions? How good does the box react when adding filters > > (during attacks)? Reloading the table? etc. etc. > > > > I am looking for _real_ _life_ values compared to a CISCO NPE-G2. Please > > tell me/us from your first hand experience. > > > > Thanks! > > > > greetings, Martin > > > > [1] If something sounds too good to be true, it probably is. > > > > > > > > From listas at esds.com.br Fri Dec 27 16:06:20 2013 From: listas at esds.com.br (Eduardo Schoedler) Date: Fri, 27 Dec 2013 14:06:20 -0200 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <10093d8d$1fc2b14f$24c67684$@flhsi.com> References: <10093d8d$1fc2b14f$24c67684$@flhsi.com> Message-ID: PPPoE Server is single thread too. 2013/12/27 Nick Olsen > Exactly what Faisal Said. The BGP process appears to be single threaded at > the moment. So taking on full BGP tables can be a bit slow compared to a > decent X86 box. But in terms of raw forwarding power they are pretty > monstrous. > > We replaced a few Maxxwave 6 port Atom's with the CCR. ~400Mb/s and ~40K > pps aggregate across all ports. CPU load went from ~25% to ~0-2%. These are > in a configuration where they have little or no firewall/nat/queue rules. > And in most cases are running MPLS. > > We've not had any issues with stability so far either (Knock on wood). > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > ---------------------------------------- > From: "Faisal Imtiaz" > Sent: Friday, December 27, 2013 10:33 AM > To: "Geraint Jones" > Cc: nanog at nanog.org, "Martin Hotze" > Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? > > FYI... Mikrotik Cloud Core routers are nice, however one has to keep > something in mind when deploying them... > > Only One Core (of the CPU) is dedicated to each port / process. > So this is good so as to contain what happens on a single port from taxing > the whole CPU.. > But not so good when you need more cpu power than a single core for that > port. > > Also, BGP process will only use one core. > > While these units make for great 'customer facing' edge routers, with > plenty of power and the ability to keep issues contained... The X-86 based > (Core2Duo/i5/i7) Mikrotik are more suitable (Processing power wise) for > running multiple full BGP tables peering. > > Regards & Good Luck. > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- > > From: "Geraint Jones" > > To: "Martin Hotze" > > Cc: nanog at nanog.org > > Sent: Friday, December 27, 2013 4:02:45 AM > > Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? > > > > I am going to be deploying 4 as edge routers in the next few weeks, each > will > > have 1 or 2 full tables plus partial IX tables. So I should have some > > empirical info soon. > > > > They will be doing eBGP to upstreams and iBGP/OSPF internally. I went > with > > the 16gb RAM models. > > > > However these boxes are basically Linux running on top of tilera CPUs, > in > > terms of throughput as long as everything stays on the fastpath they have > no > > issues doing wire speed on all ports, however the moment you add a > firewall > > rule or the like they drop to 1.5gbps. > > > > > > > > > On 27/12/2013, at 9:47 pm, Martin Hotze wrote: > > > > > > Hi, > > > > > > looking at the specs of Mikrotik Cloud Core Routers it seems to be to > good > > > to be true [1] having so much bang for the bucks. So virtually all > smaller > > > ISPs would drop their CISCO gear for Mikrotik Routerboards. > > > > > > We are using a handful of Mikrotik boxes, but on a much lower network > level > > > (splitting networks; low end router behind ADSL modem, ...). We're > happy > > > with them. > > > > > > So I am asking for real life experience and not lab values with > Mikrotik > > > Cloud Core Routers and BGP. How good can they handle full tables and a > > > bunch of peering sessions? How good does the box react when adding > filters > > > (during attacks)? Reloading the table? etc. etc. > > > > > > I am looking for _real_ _life_ values compared to a CISCO NPE-G2. > Please > > > tell me/us from your first hand experience. > > > > > > Thanks! > > > > > > greetings, Martin > > > > > > [1] If something sounds too good to be true, it probably is. > > > > > > > > > > > > > > > > -- Eduardo Schoedler From nanog at shankland.org Fri Dec 27 16:26:28 2013 From: nanog at shankland.org (Jim Shankland) Date: Fri, 27 Dec 2013 08:26:28 -0800 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: <075801cf030c$c4002b30$4c008190$@oneunified.net> Message-ID: <52BDAA34.7060002@shankland.org> On 12/27/13 6:40 AM, matt kelly wrote: > They can not handle a full routing table. The load balancing doesn't work. > They can not properly reassemble fragmented packets, and therefore drop all > but the first "piece". They can not reliably handle traffic loads over > maybe 200 Mbps, we needed 4-6 Gbps capacity. They can not hold a gre tunnel > connection. > > Can't say anything about MicroTik specifically, but I've used Linux as a routing platform for many years, off and on, and took a reasonably close look at performance about a year ago, in the previous job, using relatively high-end, but pre-Sandy Bridge, generic hardware. We were looking to support ca. 8 x 10 GbE ports with several full tables, and the usual suspects wanted the usual 6-figure amounts for boxes that could do that (the issue being the full routes -- 8 x 10 GbE with minimal routing is a triviality these days). Routing table size was completely not an issue in our environment; we were looking at a number of concurrent flows in the high-5 to low-6-digit range, and since Linux uses a route cache, it was that number, rather than the number of full tables we carried, that was important. Doing store-and-forward packet processing, as opposed to cut-through switching, took about 5 microseconds per packet, and consumed about that much CPU time. The added latency was not an issue for us; but at 5 us, that's 200Kpps per CPU. With 1500-byte packets, that's about 2.4 Gb/s total throughput; but with 40-byte packets, it's only 64 Mb/s (!). But that's per CPU. Our box had 24 CPUs (if you count a hyperthreaded pair as 2), and this work is eminently parallelizable. So a theoretical upper bound on throughput with this box would have been 4.8 Mpps -- 57.6 Gb/s with 1500-byte packets, 1.5 Gb/s with 40-byte packets. The Linux network stack (plus RSS on the NICs) seemed to do quite a good job of input-side parallelism - but we saw a lot of lock contention on the output side. At that point, we abandoned the project, as it was incidental to the organization's mission. I think that with a little more work, we could have gotten within, say, a factor of 2 of the limits above, which would have been good enough for us (though surely not for everybody). Incrementally faster hardware would have incrementally better performance. OpenFlow, which marries cheap, fast, and dumb ASICs with cheap, slower, and infinitely flexible generic CPU and RAM, seemed, and still seems, like the clearly right approach. At the time, it didn't seem ready for prime time, either in the selection of OpenFlow-capable routers or in the software stack. I imagine there's been some progress made since. Whether the market will allow it to flourish is another question. Below a certain maximum throughput, routing with generic boxes is actually pretty easy. Today, I'd say that maximum is roughly in the low-single-gigabit range. Higher is possible, but gets progressively harder to get right (and it's not a firm bound, anyway, as it depends on traffic mix and other requirements). Whether it's worth doing really depends on your goals and skill. Most people will probably prefer a canned solution from a vendor. People who grow and eat their own food surely eat better, and more cheaply, than those who buy at the supermarket; but it's not for everybody. Jim Shankland From robertg at garlic.com Fri Dec 27 16:45:57 2013 From: robertg at garlic.com (Robert Glover) Date: Fri, 27 Dec 2013 08:45:57 -0800 Subject: Megapath/Covad DNS broken? Message-ID: <52BDAEC5.1070007@garlic.com> Hello, Seems like some Megapath/Covad DNS servers are non-responsive: 64.105.172.26 64.105.172.27 We have dozens of end-users down that utilize these servers. Anyone from MP/Covad alive this morning?? Thanks, -Bobby From sam at circlenet.us Fri Dec 27 17:22:58 2013 From: sam at circlenet.us (Sam Moats) Date: Fri, 27 Dec 2013 12:22:58 -0500 Subject: Help me make sense of these traceroutes please In-Reply-To: References: Message-ID: <86f54a6e70acc5447346812e3aa7792e@www.circlenet.us> Thanks to everyone who responded off list and on. Sam Moats On 2013-12-26 11:21, Josephson, Marcus wrote: > Start at slide 50: > > This is documented further by the following Nanog presentation. > > http://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf > > -Marcus > > > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > Sent: Wednesday, December 25, 2013 10:28 AM > To: Martin Hotze > Cc: nanog at nanog.org > Subject: Re: Help me make sense of these traceroutes please > > On Wed, Dec 25, 2013 at 8:03 AM, Martin Hotze > wrote: >> >> > On 2013-12-25 00:16, Sam Moats wrote: >> > ... > >> > You are likely seeing the effects of asymmetric routing. >> . .. or the effect of passing traffic through NSA infrastructure. >> >> > Ah... NSA. That's probably it. > So much for my theory of a Router virtual chassis straddling the > atlantic. > > or the extra kinetic energy carried by the overseas-bound packet > took longer for the router to absorb and rebound with an ICMP. > > > > > > But in all seriousness --- what is probably happening here, is the > result of extra "hops" that don't show up in traceroute. > MPLS tunnels could well fit the bill. > > > > Other things to consider when latency seems sensitive to destination > IP --- are preceding device in the traceroute might also have > multiple > links to the same device; with one link congested and some form of > IP-based load sharing, that happens to be the toward-overseas link. > > > >> SCNR, #m > > -- > -JH From lists at mtin.net Fri Dec 27 18:01:03 2013 From: lists at mtin.net (Justin Wilson) Date: Fri, 27 Dec 2013 13:01:03 -0500 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <52BDAA34.7060002@shankland.org> References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <52BDAA34.7060002@shankland.org> Message-ID: The issues I see are because of routers versions. The Cloud core routers are a fairly new platform. As such, the software isn?t as stable as it should be. The OS is up to version 6.7. There were some betas before 6.0 was released. However, almost every version that has been released addresses issues with the cloud core. The cloud cores only run Version 6. We did se BGP issues early on accepting more than one full routing table. We saw other issues but they were fixed with subsequent OS software releases. Justin -- Justin Wilson MTCNA ? CCNA ? MTCRE ? MTCWE - COMTRAIN Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.zigwireless.com ? High Speed Internet Options http://www.thebrotherswisp.com ? The Brothers Wisp -----Original Message----- From: Jim Shankland Date: Friday, December 27, 2013 at 11:26 AM To: Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? >On 12/27/13 6:40 AM, matt kelly wrote: >> They can not handle a full routing table. The load balancing doesn't >>work. >> They can not properly reassemble fragmented packets, and therefore drop >>all >> but the first "piece". They can not reliably handle traffic loads over >> maybe 200 Mbps, we needed 4-6 Gbps capacity. They can not hold a gre >>tunnel >> connection. >> >> >Can't say anything about MicroTik specifically, but I've used Linux as a >routing platform for many years, off and on, and took a reasonably close >look at performance about a year ago, in the previous job, using >relatively high-end, but pre-Sandy Bridge, generic hardware. We were >looking to support ca. 8 x 10 GbE ports with several full tables, and >the usual suspects wanted the usual 6-figure amounts for boxes that >could do that (the issue being the full routes -- 8 x 10 GbE with >minimal routing is a triviality these days). > >Routing table size was completely not an issue in our environment; we >were looking at a number of concurrent flows in the high-5 to >low-6-digit range, and since Linux uses a route cache, it was that >number, rather than the number of full tables we carried, that was >important. Doing store-and-forward packet processing, as opposed to >cut-through switching, took about 5 microseconds per packet, and >consumed about that much CPU time. The added latency was not an issue >for us; but at 5 us, that's 200Kpps per CPU. With 1500-byte packets, >that's about 2.4 Gb/s total throughput; but with 40-byte packets, it's >only 64 Mb/s (!). > >But that's per CPU. Our box had 24 CPUs (if you count a hyperthreaded >pair as 2), and this work is eminently parallelizable. So a theoretical >upper bound on throughput with this box would have been 4.8 Mpps -- 57.6 >Gb/s with 1500-byte packets, 1.5 Gb/s with 40-byte packets. > >The Linux network stack (plus RSS on the NICs) seemed to do quite a good >job of input-side parallelism - but we saw a lot of lock contention on >the output side. At that point, we abandoned the project, as it was >incidental to the organization's mission. I think that with a little >more work, we could have gotten within, say, a factor of 2 of the limits >above, which would have been good enough for us (though surely not for >everybody). Incrementally faster hardware would have incrementally >better performance. > >OpenFlow, which marries cheap, fast, and dumb ASICs with cheap, slower, >and infinitely flexible generic CPU and RAM, seemed, and still seems, >like the clearly right approach. At the time, it didn't seem ready for >prime time, either in the selection of OpenFlow-capable routers or in >the software stack. I imagine there's been some progress made since. >Whether the market will allow it to flourish is another question. > >Below a certain maximum throughput, routing with generic boxes is >actually pretty easy. Today, I'd say that maximum is roughly in the >low-single-gigabit range. Higher is possible, but gets progressively >harder to get right (and it's not a firm bound, anyway, as it depends on >traffic mix and other requirements). Whether it's worth doing really >depends on your goals and skill. Most people will probably prefer a >canned solution from a vendor. People who grow and eat their own food >surely eat better, and more cheaply, than those who buy at the >supermarket; but it's not for everybody. > >Jim Shankland > > From cscora at apnic.net Fri Dec 27 18:12:26 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Dec 2013 04:12:26 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201312271812.rBRICQMS008925@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, LacNOG, TRNOG, 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 28 Dec, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 476821 Prefixes after maximum aggregation: 190476 Deaggregation factor: 2.50 Unique aggregates announced to Internet: 236639 Total ASes present in the Internet Routing Table: 45824 Prefixes per ASN: 10.41 Origin-only ASes present in the Internet Routing Table: 35504 Origin ASes announcing only one prefix: 16271 Transit ASes present in the Internet Routing Table: 5971 Transit-only ASes present in the Internet Routing Table: 176 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 2660 Unregistered ASNs in the Routing Table: 629 Number of 32-bit ASNs allocated by the RIRs: 5609 Number of 32-bit ASNs visible in the Routing Table: 4349 Prefixes from 32-bit ASNs in the Routing Table: 13678 Number of bogon 32-bit ASNs visible in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 1520 Number of addresses announced to Internet: 2661350716 Equivalent to 158 /8s, 160 /16s and 253 /24s Percentage of available address space announced: 71.9 Percentage of allocated address space announced: 71.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.4 Total number of prefixes smaller than registry allocations: 166420 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 113329 Total APNIC prefixes after maximum aggregation: 34207 APNIC Deaggregation factor: 3.31 Prefixes being announced from the APNIC address blocks: 115615 Unique aggregates announced from the APNIC address blocks: 48424 APNIC Region origin ASes present in the Internet Routing Table: 4874 APNIC Prefixes per ASN: 23.72 APNIC Region origin ASes announcing only one prefix: 1207 APNIC Region transit ASes present in the Internet Routing Table: 836 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 800 Number of APNIC addresses announced to Internet: 729291968 Equivalent to 43 /8s, 120 /16s and 28 /24s Percentage of available APNIC address space announced: 85.2 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-63999, 131072-133631 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: 163452 Total ARIN prefixes after maximum aggregation: 81927 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 164176 Unique aggregates announced from the ARIN address blocks: 75931 ARIN Region origin ASes present in the Internet Routing Table: 15934 ARIN Prefixes per ASN: 10.30 ARIN Region origin ASes announcing only one prefix: 5997 ARIN Region transit ASes present in the Internet Routing Table: 1667 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 50 Number of ARIN addresses announced to Internet: 1075567744 Equivalent to 64 /8s, 27 /16s and 220 /24s Percentage of available ARIN address space announced: 56.9 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: 120144 Total RIPE prefixes after maximum aggregation: 61394 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 123813 Unique aggregates announced from the RIPE address blocks: 79385 RIPE Region origin ASes present in the Internet Routing Table: 17585 RIPE Prefixes per ASN: 7.04 RIPE Region origin ASes announcing only one prefix: 8311 RIPE Region transit ASes present in the Internet Routing Table: 2835 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2547 Number of RIPE addresses announced to Internet: 655655812 Equivalent to 39 /8s, 20 /16s and 131 /24s Percentage of available RIPE address space announced: 95.3 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-200191 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: 53629 Total LACNIC prefixes after maximum aggregation: 10074 LACNIC Deaggregation factor: 5.32 Prefixes being announced from the LACNIC address blocks: 59123 Unique aggregates announced from the LACNIC address blocks: 27515 LACNIC Region origin ASes present in the Internet Routing Table: 2060 LACNIC Prefixes per ASN: 28.70 LACNIC Region origin ASes announcing only one prefix: 548 LACNIC Region transit ASes present in the Internet Routing Table: 405 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 944 Number of LACNIC addresses announced to Internet: 147391160 Equivalent to 8 /8s, 201 /16s and 2 /24s Percentage of available LACNIC address space announced: 87.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus 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: 11810 Total AfriNIC prefixes after maximum aggregation: 2621 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 12574 Unique aggregates announced from the AfriNIC address blocks: 4208 AfriNIC Region origin ASes present in the Internet Routing Table: 699 AfriNIC Prefixes per ASN: 17.99 AfriNIC Region origin ASes announcing only one prefix: 208 AfriNIC Region transit ASes present in the Internet Routing Table: 146 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 8 Number of AfriNIC addresses announced to Internet: 48542656 Equivalent to 2 /8s, 228 /16s and 179 /24s Percentage of available AfriNIC address space announced: 48.2 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 2946 11558 952 Korea Telecom 17974 2732 902 88 PT Telekomunikasi Indonesia 7545 2121 319 112 TPG Telecom Limited 4755 1810 392 191 TATA Communications formerly 9829 1559 1251 42 National Internet Backbone 9583 1293 100 537 Sify Limited 9498 1235 309 71 BHARTI Airtel Ltd. 7552 1219 1080 13 Viettel Corporation 4808 1138 2120 346 CNCGROUP IP network China169 24560 1098 382 167 Bharti Airtel Ltd., Telemedia 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 6389 3027 3688 53 BellSouth.net Inc. 22773 2320 2939 139 Cox Communications Inc. 1785 2146 686 131 PaeTec Communications, Inc. 18566 2050 379 178 MegaPath Corporation 20115 1682 1664 594 Charter Communications 4323 1629 1081 412 tw telecom holdings, inc. 701 1507 11144 778 MCI Communications Services, 30036 1375 309 574 Mediacom Communications Corp 7018 1309 17746 848 AT&T Services, Inc. 6983 1295 756 580 ITC^Deltacom 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 8402 1868 544 16 OJSC "Vimpelcom" 34984 1359 243 225 TELLCOM ILETISIM HIZMETLERI A 20940 1210 456 913 Akamai International B.V. 31148 1012 45 20 Freenet Ltd. 13188 919 99 41 TOV "Bank-Inform" 6849 860 363 38 JSC "Ukrtelecom" 8551 848 370 38 Bezeq International-Ltd 6830 771 2327 424 Liberty Global Operations B.V 12479 685 798 53 France Telecom Espana SA 35228 551 246 16 Telefonica UK Limited 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 28573 3420 1839 100 NET Servi?os de Comunica??o S 10620 2691 435 209 Telmex Colombia S.A. 18881 1789 908 20 Global Village Telecom 7303 1743 1163 230 Telecom Argentina S.A. 8151 1373 2857 430 Uninet S.A. de C.V. 11830 868 364 15 Instituto Costarricense de El 27947 858 93 89 Telconet S.A 7738 813 1562 37 Telemar Norte Leste S.A. 6503 791 434 60 Axtel, S.A.B. de C.V. 6147 786 373 27 Telefonica del Peru S.A.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 36998 1819 112 5 Sudanese Mobile Telephone (ZA 24863 890 338 26 Link Egypt (Link.NET) 6713 600 653 27 Office National des Postes et 8452 420 956 9 TE-AS 24835 299 144 9 Vodafone Data 3741 247 921 209 Internet Solutions 29571 240 21 14 Cote d'Ivoire Telecom 36992 224 501 29 ETISALAT MISR 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29975 192 668 21 Vodacom 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 28573 3420 1839 100 NET Servi?os de Comunica??o S 6389 3027 3688 53 BellSouth.net Inc. 4766 2946 11558 952 Korea Telecom 17974 2732 902 88 PT Telekomunikasi Indonesia 10620 2691 435 209 Telmex Colombia S.A. 22773 2320 2939 139 Cox Communications Inc. 1785 2146 686 131 PaeTec Communications, Inc. 7545 2121 319 112 TPG Telecom Limited 18566 2050 379 178 MegaPath Corporation 8402 1868 544 16 OJSC "Vimpelcom" 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 3027 2974 BellSouth.net Inc. 17974 2732 2644 PT Telekomunikasi Indonesia 10620 2691 2482 Telmex Colombia S.A. 22773 2320 2181 Cox Communications Inc. 1785 2146 2015 PaeTec Communications, Inc. 7545 2121 2009 TPG Telecom Limited 4766 2946 1994 Korea Telecom 18566 2050 1872 MegaPath Corporation 8402 1868 1852 OJSC "Vimpelcom" 36998 1819 1814 Sudanese Mobile Telephone (ZA 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 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 62828 UNALLOCATED 8.21.130.0/24 4323 tw telecom holdings, 62850 UNALLOCATED 8.25.147.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.91.0.0/19 40676 Psychz Networks 23.91.14.0/24 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.80.0/20 21560 Netstream Communications, LLC 23.91.96.0/20 37958 Beijing Blue I.T Technologies 23.91.112.0/21 32475 SingleHop 23.91.120.0/21 36351 SoftLayer Technologies Inc. 23.91.160.0/19 36493 FIBERNETICS CORPORATION 23.91.160.0/22 36493 FIBERNETICS CORPORATION 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:11 /10:31 /11:92 /12:253 /13:473 /14:939 /15:1639 /16:12867 /17:6772 /18:11420 /19:23245 /20:33090 /21:35784 /22:50691 /23:44145 /24:253000 /25:803 /26:956 /27:436 /28:47 /29:71 /30:26 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2005 2050 MegaPath Corporation 36998 1786 1819 Sudanese Mobile Telephone (ZA 6389 1699 3027 BellSouth.net Inc. 22773 1564 2320 Cox Communications Inc. 8402 1556 1868 OJSC "Vimpelcom" 30036 1216 1375 Mediacom Communications Corp 1785 1163 2146 PaeTec Communications, Inc. 11492 1148 1185 CABLE ONE, INC. 6983 1037 1295 ITC^Deltacom 22561 977 1252 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:927 2:858 3:3 4:16 5:839 6:21 8:637 12:1878 13:3 14:899 15:9 16:3 17:20 18:19 20:36 23:638 24:1752 27:1705 31:1518 32:46 33:2 34:5 36:105 37:1933 38:919 39:3 40:182 41:3336 42:243 44:14 46:2110 47:10 49:706 50:841 52:12 54:44 55:5 56:4 57:26 58:1138 59:590 60:370 61:1495 62:1232 63:1980 64:4380 65:2329 66:4133 67:2101 68:1086 69:3311 70:909 71:511 72:2023 74:2585 75:322 76:305 77:1184 78:1030 79:678 80:1278 81:1077 82:644 83:755 84:640 85:1232 86:402 87:1016 88:521 89:1576 90:150 91:5738 92:620 93:1618 94:2100 95:1483 96:532 97:351 98:1085 99:41 100:32 101:693 103:3882 105:534 106:144 107:258 108:548 109:2036 110:975 111:1135 112:613 113:816 114:763 115:1049 116:1018 117:832 118:1249 119:1297 120:340 121:772 122:1884 123:1289 124:1395 125:1455 128:655 129:234 130:357 131:667 132:343 133:159 134:312 135:73 136:277 137:251 138:354 139:172 140:202 141:349 142:553 143:405 144:497 145:92 146:566 147:428 148:790 149:359 150:153 151:484 152:410 153:205 154:49 155:520 156:314 157:418 158:287 159:808 160:356 161:459 162:959 163:231 164:663 165:582 166:281 167:641 168:1038 169:123 170:1150 171:185 172:12 173:1705 174:675 175:550 176:1359 177:2637 178:1911 179:340 180:1609 181:915 182:1422 183:477 184:630 185:1170 186:2790 187:1445 188:1952 189:1259 190:7313 191:16 192:7091 193:5442 194:4030 195:3408 196:1345 197:1085 198:4814 199:5531 200:6059 201:2553 202:9013 203:8934 204:4536 205:2642 206:2909 207:2811 208:3951 209:3707 210:3076 211:1633 212:2171 213:1974 214:875 215:85 216:5427 217:1702 218:622 219:323 220:1267 221:587 222:348 223:564 End of report From sethm at rollernet.us Fri Dec 27 18:19:23 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 27 Dec 2013 10:19:23 -0800 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <52BDAA34.7060002@shankland.org> Message-ID: <52BDC4AB.3030302@rollernet.us> On 12/27/13, 10:01, Justin Wilson wrote: > The issues I see are because of routers versions. The Cloud core routers > are a fairly new platform. As such, the software isn?t as stable as it > should be. The OS is up to version 6.7. There were some betas before 6.0 > was released. However, almost every version that has been released > addresses issues with the cloud core. The cloud cores only run Version 6. > Unless my knowledge is out of date, the one thing RouterOS has that others in the same scope lack is a full MPLS stack that's not experimental. ~Seth From hmurray at megapathdsl.net Fri Dec 27 19:36:41 2013 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 27 Dec 2013 11:36:41 -0800 Subject: Mikrotik Cloud Core Router and BGP real life experiences? Message-ID: <20131227193641.B284D406062@ip-64-139-1-69.sjc.megapath.net> nanog-request at nanog.org said: > We replaced a few Maxxwave 6 port Atom's with the CCR. ~400Mb/s and ~40K > pps aggregate across all ports. CPU load went from ~25% to ~0-2%. These are > in a configuration where they have little or no firewall/nat/queue rules. > And in most cases are running MPLS. How much CPU does it take to implement BCP-38? -- These are my opinions. I hate spam. From dmburgess at linktechs.net Fri Dec 27 19:54:24 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 27 Dec 2013 13:54:24 -0600 Subject: AOL Postmaster Message-ID: <50710E9A7E64454C974049FC998EB655018DDDC1@03-exchange.lti.local> Can a AOL Postmaster hit me off-list please J Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace From baldur.norddahl at gmail.com Fri Dec 27 20:00:04 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 27 Dec 2013 21:00:04 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: On Fri, Dec 27, 2013 at 4:18 PM, Jon Sands wrote: > On Dec 27, 2013 10:08 AM, "Baldur Norddahl" > wrote: > > > We are an upstart and just buying the fancy Juniper switch times two > would burn half of my seed capital. > > Then you didn't ask for nearly enough capital. > Another told Nick Cameo that if he can afford a 10G link, he can afford Juniper. You could not be more wrong. The 10G uplink goes for $0 in initial fee and less than $4k / month with unlimited traffic. The Juniper gear is $100k up front for two routers able to handle the 10G links. What I get from you guys is that in your opinion it is not possible to set up a small ISP without spending a ton on Juniper or Cisco. I am not buying that. Even if I did not have a clear limit on my capital, I would be looking at avoiding paying that kind of money, because in the end the money comes out of my own pocket. Everybody have critical services running on servers. DHCP, DNS, Radius and so on are all on servers and you will be down if these services are down. What is with the knee jerk reaction for suggesting that the BGP daemon could also be run on a server? There seems to be many advantages of doing it this way, and not all of them are related to cost. Regards, Baldur From nick at flhsi.com Fri Dec 27 20:10:11 2013 From: nick at flhsi.com (Nick Olsen) Date: Fri, 27 Dec 2013 15:10:11 -0500 Subject: Mikrotik Cloud Core Router and BGP real life experiences? Message-ID: <64731928$2e0ddcd5$584e07fc$@flhsi.com> Depends. This router isn't running BCP-38 as it's run at our borders. Looking at the specs. Firewall rules do take it out of fastpath. Which means it's going to take a decent performance hit on paper. I'm not sure if their auto method of enabling BCP-38 IE. the IP>Settings>RP Filter method would accomplish the same outcome, Without taking the router out of fastpath. I assume it works the same as using firewall rules. Just "Behind the scenes". That being said, Real world testing. Running the traffic levels I mentioned before. I put a single simple firewall rule on the router. Which effectively took it out of fastpath. And also enabled connection tracking. I saw no noticeable change in CPU load. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Hal Murray" Sent: Friday, December 27, 2013 2:38 PM To: nanog at nanog.org Cc: "Hal Murray" Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? nanog-request at nanog.org said: > We replaced a few Maxxwave 6 port Atom's with the CCR. ~400Mb/s and ~40K > pps aggregate across all ports. CPU load went from ~25% to ~0-2%. These are > in a configuration where they have little or no firewall/nat/queue rules. > And in most cases are running MPLS. How much CPU does it take to implement BCP-38? -- These are my opinions. I hate spam. From eugen at imacandi.net Fri Dec 27 20:23:11 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Fri, 27 Dec 2013 22:23:11 +0200 Subject: The Making of a Router In-Reply-To: References: Message-ID: On Fri, Dec 27, 2013 at 10:00 PM, Baldur Norddahl wrote: > On Fri, Dec 27, 2013 at 4:18 PM, Jon Sands wrote: > > > On Dec 27, 2013 10:08 AM, "Baldur Norddahl" > > wrote: > > > > > We are an upstart and just buying the fancy Juniper switch times two > > would burn half of my seed capital. > > > > Then you didn't ask for nearly enough capital. > > > > Another told Nick Cameo that if he can afford a 10G link, he can afford > Juniper. You could not be more wrong. The 10G uplink goes for $0 in initial > fee and less than $4k / month with unlimited traffic. The Juniper gear is > $100k up front for two routers able to handle the 10G links. > > What you should understand is not the fact that a 10G interface is expensive, but what you can do with that interface tends to get very expensive. If you want to move traffic from one interface to another, you can achieve this today with two physical interfaces on a Linux box. How many PPS ? Well, that's another story. You then want shaping, Q-in-Q and other stuff which consume a lot of resources even on dedicated hardware. > What I get from you guys is that in your opinion it is not possible to set > up a small ISP without spending a ton on Juniper or Cisco. I am not buying > that. Even if I did not have a clear limit on my capital, I would be > looking at avoiding paying that kind of money, because in the end the money > comes out of my own pocket. > > You can build your ISP without getting big routers but you need to cut back a little bit on your expectations about what you can in terms of features: - Do pool NAT for your users if they accept this. You can easily squeeze a lot of users on a single IP address. Downside is that if one of them does something bad, that IP might get blackholed on some providers and the rest will suffer. Also, you might want to take into consideration regulatory requirements like to know what users used what port to what destination for a certain number of months (in Europe regulations vary, but the smallest period is 6 months). - If you give them VoIP/IPTV then assign a VLAN for VOIP and another for IPTV and run it to all your users to their STBs and make use of IGMP snooping for Multicast traffic on all your switches - You can run full table BGP with Quagga on Linux (it worked for me when the DFZ was at around 270k prefixes, I assume it will work with 480k prefixes today) - also, do you really need full tables ?. Your IGP, if you don't run anything fancy should be a few tens of routes, that can be achieved with modest L3 switches that do 64/128 routes in hardware. > Everybody have critical services running on servers. DHCP, DNS, Radius and > so on are all on servers and you will be down if these services are down. > What is with the knee jerk reaction for suggesting that the BGP daemon > could also be run on a server? There seems to be many advantages of doing > it this way, and not all of them are related to cost. > > For the sake of a good night sleep, you would want to separate all the services on different physical machines for redundancy/availability and load sharing. Once you grow, you can move to more powerful and dedicated hardware for your networking needs. Eugeniu From faisal at snappytelecom.net Fri Dec 27 20:26:13 2013 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 27 Dec 2013 20:26:13 +0000 (GMT) Subject: The Making of a Router In-Reply-To: References: Message-ID: <644085130.351111.1388175973990.JavaMail.root@snappytelecom.net> Well said Baldur.... For those who are movie buffs.. here is the snippet that visually summaries.. http://www.youtube.com/watch?v=dEkOT3IngMQ As to the knee jerk reaction to a server doing routing.... such folks tend to forget that Routers are purpose built servers....and most of the Internet Routing was originally done by servers (or main frames or minis) etc. :) 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 ----- > What I get from you guys is that in your opinion it is not possible to set > up a small ISP without spending a ton on Juniper or Cisco. I am not buying > that. Even if I did not have a clear limit on my capital, I would be > looking at avoiding paying that kind of money, because in the end the money > comes out of my own pocket. > > Everybody have critical services running on servers. DHCP, DNS, Radius and > so on are all on servers and you will be down if these services are down. > What is with the knee jerk reaction for suggesting that the BGP daemon > could also be run on a server? There seems to be many advantages of doing > it this way, and not all of them are related to cost. > > Regards, > > Baldur > From andre-nanog at tomt.net Fri Dec 27 20:36:57 2013 From: andre-nanog at tomt.net (Andre Tomt) Date: Fri, 27 Dec 2013 21:36:57 +0100 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <52BDAA34.7060002@shankland.org> References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <52BDAA34.7060002@shankland.org> Message-ID: <52BDE4E9.8010808@tomt.net> On 27. des. 2013 17:26, Jim Shankland wrote: > Routing table size was completely not an issue in our environment; we > were looking at a number of concurrent flows in the high-5 to > low-6-digit range, and since Linux uses a route cache, it was that > number, rather than the number of full tables we carried, that was > important. FYI, Linux no longer has a routing cache, so any performance numbers with the cache in place is void on modern kernels. It was deemed too fragile, handled mixed traffic badly, and was way easy to DoS. It wasnt simply just ripped out of course, the full lookups was made way faster and a bunch of scalability issues got plugged in the process. All in all, in PPS, Linux should now handle mixed traffic much better, but less diverse traffic patterns might be a little slower than before. However, all in all, much more consistent and predictable. Not everything is peachy though, there are still some cases that sucked last I checked. Running tons of tunnels beeing one. Multicast rx was severely gimped for a while after the removal, but that got fixed. From faisal at snappytelecom.net Fri Dec 27 20:37:52 2013 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 27 Dec 2013 20:37:52 +0000 (GMT) Subject: The Making of a Router In-Reply-To: References: Message-ID: <373999373.351134.1388176672382.JavaMail.root@snappytelecom.net> I Am not trying to be inflammatory.. Why does everything has to be measured in Extremes ? e.g. If someone says I need a 10g interface, why is it automatically assumed that the router is going to be running @ Full Line Rate ? I think we often confuse the performance of "Software" and Hardware as being monolithic, which is far from the truth. In today fast moving world, we don't even bother to look under the hood to see what is it that is being taxed.. the Software ? or Hardware ? or process of how we are doing what we want to get accomplished ? While it is easy to talk about the extremes, we often forget to point out to others that the 'Middle' is a huge place..... Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Eugeniu Patrascu" > To: "Baldur Norddahl" > Cc: nanog at nanog.org > Sent: Friday, December 27, 2013 3:23:11 PM > Subject: Re: The Making of a Router > > On Fri, Dec 27, 2013 at 10:00 PM, Baldur Norddahl > wrote: > > > On Fri, Dec 27, 2013 at 4:18 PM, Jon Sands wrote: > > > > > On Dec 27, 2013 10:08 AM, "Baldur Norddahl" > > > wrote: > > > > > > > We are an upstart and just buying the fancy Juniper switch times two > > > would burn half of my seed capital. > > > > > > Then you didn't ask for nearly enough capital. > > > > > > > Another told Nick Cameo that if he can afford a 10G link, he can afford > > Juniper. You could not be more wrong. The 10G uplink goes for $0 in initial > > fee and less than $4k / month with unlimited traffic. The Juniper gear is > > $100k up front for two routers able to handle the 10G links. > > > > > What you should understand is not the fact that a 10G interface is > expensive, but what you can do with that interface tends to get very > expensive. > If you want to move traffic from one interface to another, you can achieve > this today with two physical interfaces on a Linux box. How many PPS ? > Well, that's another story. You then want shaping, Q-in-Q and other stuff > which consume a lot of resources even on dedicated hardware. > > > > What I get from you guys is that in your opinion it is not possible to set > > up a small ISP without spending a ton on Juniper or Cisco. I am not buying > > that. Even if I did not have a clear limit on my capital, I would be > > looking at avoiding paying that kind of money, because in the end the money > > comes out of my own pocket. > > > > > You can build your ISP without getting big routers but you need to cut back > a little bit on your expectations about what you can in terms of features: > - Do pool NAT for your users if they accept this. You can easily squeeze a > lot of users on a single IP address. Downside is that if one of them does > something bad, that IP might get blackholed on some providers and the rest > will suffer. Also, you might want to take into consideration regulatory > requirements like to know what users used what port to what destination for > a certain number of months (in Europe regulations vary, but the smallest > period is 6 months). > - If you give them VoIP/IPTV then assign a VLAN for VOIP and another for > IPTV and run it to all your users to their STBs and make use of IGMP > snooping for Multicast traffic on all your switches > - You can run full table BGP with Quagga on Linux (it worked for me when > the DFZ was at around 270k prefixes, I assume it will work with 480k > prefixes today) - also, do you really need full tables ?. Your IGP, if you > don't run anything fancy should be a few tens of routes, that can be > achieved with modest L3 switches that do 64/128 routes in hardware. > > > > Everybody have critical services running on servers. DHCP, DNS, Radius and > > so on are all on servers and you will be down if these services are down. > > What is with the knee jerk reaction for suggesting that the BGP daemon > > could also be run on a server? There seems to be many advantages of doing > > it this way, and not all of them are related to cost. > > > > > For the sake of a good night sleep, you would want to separate all the > services on different physical machines for redundancy/availability and > load sharing. > > Once you grow, you can move to more powerful and dedicated hardware for > your networking needs. > > Eugeniu > From listas at esds.com.br Fri Dec 27 20:41:24 2013 From: listas at esds.com.br (Eduardo Schoedler) Date: Fri, 27 Dec 2013 18:41:24 -0200 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <52BDE4E9.8010808@tomt.net> References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <52BDAA34.7060002@shankland.org> <52BDE4E9.8010808@tomt.net> Message-ID: How about SMP Affinity in CCR? System > Resources > IRQ. 2013/12/27 Andre Tomt > On 27. des. 2013 17:26, Jim Shankland wrote: > > > Routing table size was completely not an issue in our environment; we >> were looking at a number of concurrent flows in the high-5 to >> low-6-digit range, and since Linux uses a route cache, it was that >> number, rather than the number of full tables we carried, that was >> important. >> > > > FYI, Linux no longer has a routing cache, so any performance numbers with > the cache in place is void on modern kernels. It was deemed too fragile, > handled mixed traffic badly, and was way easy to DoS. It wasnt simply just > ripped out of course, the full lookups was made way faster and a bunch of > scalability issues got plugged in the process. > > All in all, in PPS, Linux should now handle mixed traffic much better, but > less diverse traffic patterns might be a little slower than before. > However, all in all, much more consistent and predictable. > > Not everything is peachy though, there are still some cases that sucked > last I checked. Running tons of tunnels beeing one. Multicast rx was > severely gimped for a while after the removal, but that got fixed. > > -- Eduardo Schoedler From jared at puck.nether.net Fri Dec 27 21:04:12 2013 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 27 Dec 2013 16:04:12 -0500 Subject: The Making of a Router In-Reply-To: <373999373.351134.1388176672382.JavaMail.root@snappytelecom.net> References: <373999373.351134.1388176672382.JavaMail.root@snappytelecom.net> Message-ID: <71624532-73E8-4230-A201-E19310A5ADB7@puck.nether.net> On Dec 27, 2013, at 3:37 PM, Faisal Imtiaz wrote: > e.g. If someone says I need a 10g interface, why is it automatically assumed that the router is going to be running @ Full Line Rate ? Those of us with experience know that when ?something bad(tm)? happens, those features and ?expensive silicon? start to show some ROI. Is it a full trade-off? Depends on the risks of your business and exposure. You can get some inexpensive hardware to do fairly fancy features these days. That can be very good, but caries that risk. Make sure you evaluate it carefully. - Jared From streiner at cluebyfour.org Fri Dec 27 17:48:48 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 27 Dec 2013 12:48:48 -0500 (EST) Subject: The Making of a Router In-Reply-To: References: Message-ID: On Fri, 27 Dec 2013, Baldur Norddahl wrote: > Everybody have critical services running on servers. DHCP, DNS, Radius and > so on are all on servers and you will be down if these services are down. > What is with the knee jerk reaction for suggesting that the BGP daemon > could also be run on a server? There seems to be many advantages of doing > it this way, and not all of them are related to cost. If you want to use servers as routers, that's your choice. I think what most people in the thread have been saying is not to use one server (or even a pair of servers) for everything. It's one thing if server XYZ goes down and some web services are offline. It's another thing entirely if that same server goes down and your entire business is offline. jms From mpalmer at hezmatt.org Fri Dec 27 21:23:56 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 28 Dec 2013 08:23:56 +1100 Subject: The Making of a Router In-Reply-To: References: Message-ID: <20131227212356.GE13499@hezmatt.org> On Fri, Dec 27, 2013 at 10:18:47AM -0500, Jon Sands wrote: > On Dec 27, 2013 10:08 AM, "Baldur Norddahl" > wrote: > > > We are an upstart and just buying the fancy Juniper switch times two > would burn half of my seed capital. > > Then you didn't ask for nearly enough capital. There *is* a world outside of Silly Valley, you know... a world where money doesn't flow like a mighty cascade from the benevolent wallets of vulture capitalists, into the waiting arms of every crackpot with an elevator pitch. - Matt From faisal at snappytelecom.net Fri Dec 27 21:24:54 2013 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 27 Dec 2013 21:24:54 +0000 (GMT) Subject: The Making of a Router In-Reply-To: <71624532-73E8-4230-A201-E19310A5ADB7@puck.nether.net> References: <373999373.351134.1388176672382.JavaMail.root@snappytelecom.net> <71624532-73E8-4230-A201-E19310A5ADB7@puck.nether.net> Message-ID: <2017239195.351357.1388179494349.JavaMail.root@snappytelecom.net> Fair point.. but in real life, isn't that true for everything... I say the same .... be familiar(honest awareness) with the limits (limitations) and capabilities of your specific solution, be it a 'dyi' or a commercial solution, before pushing it to the limit. Unless of course, you have factored in the ability to deal with the consequences. Most 'DYI' solutions, make the non-techy bean counters very nervous, and seeing a major 'name brand' label for some odd reason makes them real comfortable, ir-respective of the capabilities or function of either solution. If you have to answer to the bean counters, then this is a very valid point to be considered. :) 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: "Jared Mauch" > To: "Faisal Imtiaz" > Cc: "Eugeniu Patrascu" , "North American Network Operators' Group" > Sent: Friday, December 27, 2013 4:04:12 PM > Subject: Re: The Making of a Router > > > On Dec 27, 2013, at 3:37 PM, Faisal Imtiaz wrote: > > > e.g. If someone says I need a 10g interface, why is it automatically > > assumed that the router is going to be running @ Full Line Rate ? > > Those of us with experience know that when ?something bad(tm)? happens, those > features and ?expensive silicon? start to show some ROI. Is it a full > trade-off? Depends on the risks of your business and exposure. > > You can get some inexpensive hardware to do fairly fancy features these days. > That can be very good, but caries that risk. Make sure you evaluate it > carefully. > > - Jared From streiner at cluebyfour.org Fri Dec 27 18:09:04 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 27 Dec 2013 13:09:04 -0500 (EST) Subject: The Making of a Router In-Reply-To: <2017239195.351357.1388179494349.JavaMail.root@snappytelecom.net> References: <373999373.351134.1388176672382.JavaMail.root@snappytelecom.net> <71624532-73E8-4230-A201-E19310A5ADB7@puck.nether.net> <2017239195.351357.1388179494349.JavaMail.root@snappytelecom.net> Message-ID: On Fri, 27 Dec 2013, Faisal Imtiaz wrote: > Most 'DYI' solutions, make the non-techy bean counters very nervous, > and seeing a major 'name brand' label for some odd reason makes them > real comfortable, ir-respective of the capabilities or function of > either solution. For a lot of organizations, one of the values of big dedicated hardware for the network is in the support contracts that are purchased with the hardware. If something breaks, there is someone to call to work with and resolve the situation. In a DIY setup, you're usually on your own. As others have noted, that's fine, if you understand and accept that risk. jms From baldur.norddahl at gmail.com Fri Dec 27 21:40:36 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 27 Dec 2013 22:40:36 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: On Fri, Dec 27, 2013 at 6:48 PM, Justin M. Streiner wrote: > If you want to use servers as routers, that's your choice. I think what > most people in the thread have been saying is not to use one server (or > even a pair of servers) for everything. It's one thing if server XYZ goes > down and some web services are offline. It's another thing entirely if > that same server goes down and your entire business is offline. > You need at least two servers. Much of the functional separation can be achieved by using virtualisation: Two virtual servers per function, but only two physical servers. It is a lot cheaper to just get two beefy servers than to invest in expensive 10G routers. Later on it is easy to move the VMs to more servers if needed. The exception might be any function that moves packets. It is hard to get the necessary performance from dedicated hardware. Trying to do it from a VM will not help. In that case I would dedicate two physical machines to the purpose. However I am actually trying to avoid having the server move packets - I want to use an OpenFlow switch to do the brunt work. Running a BGP daemon on a VM to remote control an OpenFlow switch should not be a problem. Regards, Baldur From rhys at rhavenindustrys.com Fri Dec 27 21:53:48 2013 From: rhys at rhavenindustrys.com (Rhys Rhaven) Date: Fri, 27 Dec 2013 15:53:48 -0600 Subject: Vyatta to VyOS In-Reply-To: References: <8eb537889c5c42a2ac33537dd30b248b@KWMAIL.local.kw-corp.com> Message-ID: <52BDF6EC.5080402@rhavenindustrys.com> This is great. I've been using Vyatta for a long while, but the constant bugs and the lack of turnaround on fixing them was really sad. With my lovely sales rep Erica calling me up every now and again trying to sell more licenses, in the way only soulless sales drones can. Extract money from the customer, disregard all complaints and requests for fixing of simple bugs. I was asking for the puppet/chef modules for Vyatta devices for 2 years and finally ended up using their unsupported CLI api to do part of it myself. That kind of automation is a huge chunk of SDN. I'm curious if VyOS will support "vPlane," which under Broadcom they seem to have finally shipped. http://www.brocade.com/downloads/documents/at_a_glance/brocade-vyatta-5600vrouter-aag.pdf http://dpdk.org/ On 12/23/13, 3:49 PM, Zach Underwood wrote: > Can I just say this is why I love FOSS. I will be testing VyOS on some of > my vyatta routes after the holidays. > > > On Mon, Dec 23, 2013 at 4:37 PM, Josh Hoppes wrote: > >> Ubiquiti has been contributing to VyOS, so I'm assuming it is the >> version they are using as the upstream for their code. >> >> On Mon, Dec 23, 2013 at 1:18 PM, Nolan Rollo wrote: >>> I wonder how Ubiquiti Networks is going to react to this since their >> EdgeMax Routers run a fork of the Vyatta code (EdgeOS). >>> >> http://community.ubnt.com/t5/EdgeMAX/Vyatta-Community-Edition-dead/m-p/591487/highlight/true#M16059 >>> It looks like there is a post in the form where a UBNT Employee said >> that they were working directly with the VyOS guys. In this case I wonder >> what other commercial vendor is going to jump on the open source bandwagon. >>> -----Original Message----- >>> From: Scott Howard [mailto:scott at doc.net.au] >>> Sent: Monday, December 23, 2013 1:45 PM >>> To: Ray Soucy >>> Cc: NANOG >>> Subject: Re: Vyatta to VyOS >>> >>> Who wants to tell them that it's really 2013? >>> >>> News >>> 22 Dec *2012* >>> Version 1.0.0 (hydrogen) released. >>> >>> >>> Scott >>> >>> >>> >>> On Mon, Dec 23, 2013 at 7:18 AM, Ray Soucy wrote: >>> >>>> Many here might be interested, >>>> >>>> In response to Brocade not giving the community edition of Vyatta much >>>> attention recently, some of the more active community members have >>>> created a fork of the GPL code used in Vyatta. >>>> >>>> It's called VyOS, and yesterday they released 1.0. >>>> >>>> http://vyos.net/ >>>> >>>> I've been playing with the development builds and it seems to be every >>>> bit as stable as the Vyatta releases. >>>> >>>> Will be interesting to see how the project unfolds :-) >>>> >>>> -- >>>> 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 cidr-report at potaroo.net Fri Dec 27 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Dec 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201312272200.rBRM00mO042835@wattle.apnic.net> This report has been generated at Fri Dec 27 21:13:40 2013 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 20-12-13 486354 275059 21-12-13 487165 275707 22-12-13 487402 275799 23-12-13 487254 275762 24-12-13 487144 275938 25-12-13 487469 276125 26-12-13 487843 275972 27-12-13 487889 276061 AS Summary 45972 Number of ASes in routing system 18831 Number of ASes announcing only one prefix 4201 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118702848 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 27Dec13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 487538 276069 211469 43.4% All ASes AS28573 3430 92 3338 97.3% NET Servi?os de Comunica??o S.A. AS6389 3027 56 2971 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2731 189 2542 93.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4201 1734 2467 58.7% WINDSTREAM - Windstream Communications Inc AS4766 2946 961 1985 67.4% KIXS-AS-KR Korea Telecom AS36998 1819 6 1813 99.7% SDN-MOBITEL AS18881 1789 31 1758 98.3% Global Village Telecom AS1785 2146 390 1756 81.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 2691 1080 1611 59.9% Telmex Colombia S.A. AS18566 2049 565 1484 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2942 1513 1429 48.6% TWTC - tw telecom holdings, inc. AS7303 1743 461 1282 73.6% Telecom Argentina S.A. AS4755 1810 596 1214 67.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 2322 1159 1163 50.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7552 1254 178 1076 85.8% VIETEL-AS-AP Viettel Corporation AS22561 1252 225 1027 82.0% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1559 660 899 57.7% BSNL-NIB National Internet Backbone AS7545 2122 1307 815 38.4% TPG-INTERNET-AP TPG Telecom Limited AS18101 990 186 804 81.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS35908 906 107 799 88.2% VPLSNET - Krypt Technologies AS4808 1138 384 754 66.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1507 778 729 48.4% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS24560 1098 374 724 65.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1381 659 722 52.3% Uninet S.A. de C.V. AS6983 1295 580 715 55.2% ITCDELTA - ITC^Deltacom AS13977 855 143 712 83.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS4788 884 206 678 76.7% TMNET-AS-AP TM Net, Internet Service Provider AS4780 1004 326 678 67.5% SEEDNET Digital United Inc. AS855 733 57 676 92.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7738 813 139 674 82.9% Telemar Norte Leste S.A. Total 54437 15142 39295 72.2% Top 30 total Possible Bogus Routes 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 27.100.7.0/24 AS56096 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.188.0/22 AS35916 MULTA-ASN1 - MULTACOM CORPORATION 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.114.140.0/22 AS32757 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 80.248.64.0/20 AS30982 CAFETG AS de CAFE Informatique 80.248.64.0/21 AS8513 SKYVISION SkyVision Global Networks Ltd 80.248.64.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.65.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.67.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.68.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.69.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.70.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.71.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.77.0/24 AS30982 CAFETG AS de CAFE Informatique 80.250.32.0/22 AS37106 ODUA-AS 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.21.72.0/22 AS13244 103.21.75.0/24 AS13244 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 185.44.32.0/22 AS24933 MINXS-AS MILLENNIUMS.NET GmbH 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.22.224.0/20 AS3322 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.202.8.0/21 AS3322 193.254.218.0/23 AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC 194.34.56.0/24 AS3549 GBLX Global Crossing Ltd. 194.34.56.0/25 AS3549 GBLX Global Crossing Ltd. 194.34.56.128/26 AS3549 GBLX Global Crossing Ltd. 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 195.28.168.0/23 AS8655 195.114.4.0/23 AS41158 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.23.189.0/24 AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.115.110.0/23 AS53709 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.120.0/22 AS32757 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 208.92.224.0/22 AS32757 208.92.226.0/24 AS32757 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 Dec 27 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Dec 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201312272200.rBRM01vG042850@wattle.apnic.net> BGP Update Report Interval: 19-Dec-13 -to- 26-Dec-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 58402 3.2% 62.1 -- BSNL-NIB National Internet Backbone 2 - AS8402 51576 2.8% 25.5 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS35819 36302 2.0% 69.7 -- MOBILY-AS Etihad Etisalat Company (Mobily) 4 - AS7552 29624 1.6% 23.5 -- VIETEL-AS-AP Viettel Corporation 5 - AS15003 24811 1.4% 91.9 -- NOBIS-TECH - Nobis Technology Group, LLC 6 - AS13118 23152 1.3% 609.3 -- ASN-YARTELECOM OJSC Rostelecom 7 - AS4538 22752 1.2% 43.3 -- ERX-CERNET-BKB China Education and Research Network Center 8 - AS45899 21089 1.1% 64.9 -- VNPT-AS-VN VNPT Corp 9 - AS37004 18982 1.0% 759.3 -- SUBURBAN-AS 10 - AS3816 18867 1.0% 72.0 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 11 - AS41691 18540 1.0% 545.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 12 - AS37492 17705 1.0% 281.0 -- ORANGE-TN 13 - AS4775 16838 0.9% 311.8 -- GLOBE-TELECOM-AS Globe Telecoms 14 - AS9116 16828 0.9% 65.2 -- GOLDENLINES-ASN 012 Smile Communications Ltd. 15 - AS59217 12846 0.7% 12846.0 -- AZONNELIMITED-AS-AP Azonne Limited 16 - AS7602 12788 0.7% 82.5 -- SPT-AS-VN Saigon Postel Corporation 17 - AS13188 12675 0.7% 14.4 -- BANKINFORM-AS TOV "Bank-Inform" 18 - AS31148 11882 0.6% 11.8 -- FREENET-AS Freenet Ltd. 19 - AS36998 11577 0.6% 6.4 -- SDN-MOBITEL 20 - AS6629 10408 0.6% 1486.9 -- NOAA-AS - NOAA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS59217 12846 0.7% 12846.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS54465 8993 0.5% 8993.0 -- QPM-AS-1 - QuickPlay Media Inc. 3 - AS7202 8654 0.5% 4327.0 -- FAMU - Florida A & M University 4 - AS19406 3794 0.2% 3794.0 -- TWRS-MA - Towerstream I, Inc. 5 - AS22747 3087 0.2% 3087.0 -- TCIS - TulsaConnect, LLC 6 - AS30437 4469 0.2% 2234.5 -- GE-MS003 - General Electric Company 7 - AS60345 4421 0.2% 2210.5 -- NBITI-AS Nahjol Balagheh International Research Institution 8 - AS62431 2146 0.1% 2146.0 -- NCSC-IE-AS National Cyber Security Centre 9 - AS4847 9493 0.5% 1898.6 -- CNIX-AP China Networks Inter-Exchange 10 - AS28477 1821 0.1% 1821.0 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS 11 - AS4771 1810 0.1% 1810.0 -- NZTELECOM Telecom New Zealand Ltd. 12 - AS32244 6723 0.4% 1680.8 -- LIQUID-WEB-INC - Liquid Web, Inc. 13 - AS31459 1578 0.1% 1578.0 -- BBC-RD-AS BBC 14 - AS41189 1561 0.1% 1561.0 -- ICONCEPT-AS Faroese Telecom 15 - AS2818 4668 0.2% 1556.0 -- BBC BBC Internet Services, UK 16 - AS6629 10408 0.6% 1486.9 -- NOAA-AS - NOAA 17 - AS1880 6969 0.4% 1161.5 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 18 - AS7741 1113 0.1% 1113.0 -- CIBC-WORLD-MARKETS - CIBC World Markets 19 - AS39250 996 0.1% 996.0 -- ASN-HYPERGRID HyperGrid s.r.l. 20 - AS62445 898 0.1% 898.0 -- ADA-VOICE-AS ADA VOICE SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22988 1.2% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.164.0/22 12846 0.7% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 3 - 85.249.160.0/20 10886 0.6% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 4 - 192.58.232.0/24 10360 0.5% AS6629 -- NOAA-AS - NOAA 5 - 115.170.128.0/17 9474 0.5% AS4847 -- CNIX-AP China Networks Inter-Exchange 6 - 206.152.15.0/24 8993 0.5% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 7 - 193.95.93.0/24 8565 0.4% AS37492 -- ORANGE-TN 8 - 193.95.92.0/24 8546 0.4% AS37492 -- ORANGE-TN 11 - 89.221.206.0/24 7390 0.4% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 12 - 67.210.190.0/23 6203 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 13 - 199.187.118.0/24 4907 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 14 - 165.156.25.0/24 4467 0.2% AS30437 -- GE-MS003 - General Electric Company 16 - 168.223.206.0/23 4377 0.2% AS7202 -- FAMU - Florida A & M University 17 - 168.223.200.0/22 4277 0.2% AS7202 -- FAMU - Florida A & M University 18 - 192.108.213.0/24 3979 0.2% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 19 - 203.8.161.0/24 3942 0.2% AS4802 -- ASN-IINET iiNet Limited 20 - 67.210.188.0/23 3932 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 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 alexander at neilson.net.nz Fri Dec 27 22:36:10 2013 From: alexander at neilson.net.nz (Alexander Neilson) Date: Sat, 28 Dec 2013 11:36:10 +1300 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: <10093d8d$1fc2b14f$24c67684$@flhsi.com> Message-ID: Regards Alexander Alexander Neilson Neilson Productions Ltd Alexander at Neilson.net.nz 021 329 681 > On 28/12/2013, at 5:06 am, Eduardo Schoedler wrote: > > PPPoE Server is single thread too. PPP package is getting a multicore upgrade in 6.8 or 6.9 release. May introduce bugs but they are working to Multi core all the processes properly. > > > 2013/12/27 Nick Olsen > >> Exactly what Faisal Said. The BGP process appears to be single threaded at >> the moment. So taking on full BGP tables can be a bit slow compared to a >> decent X86 box. But in terms of raw forwarding power they are pretty >> monstrous. >> >> We replaced a few Maxxwave 6 port Atom's with the CCR. ~400Mb/s and ~40K >> pps aggregate across all ports. CPU load went from ~25% to ~0-2%. These are >> in a configuration where they have little or no firewall/nat/queue rules. >> And in most cases are running MPLS. >> >> We've not had any issues with stability so far either (Knock on wood). >> >> Nick Olsen >> Network Operations >> (855) FLSPEED x106 >> >> ---------------------------------------- >> From: "Faisal Imtiaz" >> Sent: Friday, December 27, 2013 10:33 AM >> To: "Geraint Jones" >> Cc: nanog at nanog.org, "Martin Hotze" >> Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? >> >> FYI... Mikrotik Cloud Core routers are nice, however one has to keep >> something in mind when deploying them... >> >> Only One Core (of the CPU) is dedicated to each port / process. >> So this is good so as to contain what happens on a single port from taxing >> the whole CPU.. >> But not so good when you need more cpu power than a single core for that >> port. >> >> Also, BGP process will only use one core. >> >> While these units make for great 'customer facing' edge routers, with >> plenty of power and the ability to keep issues contained... The X-86 based >> (Core2Duo/i5/i7) Mikrotik are more suitable (Processing power wise) for >> running multiple full BGP tables peering. >> >> Regards & Good Luck. >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> >> ----- Original Message ----- >>> From: "Geraint Jones" >>> To: "Martin Hotze" >>> Cc: nanog at nanog.org >>> Sent: Friday, December 27, 2013 4:02:45 AM >>> Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? >>> >>> I am going to be deploying 4 as edge routers in the next few weeks, each >> will >>> have 1 or 2 full tables plus partial IX tables. So I should have some >>> empirical info soon. >>> >>> They will be doing eBGP to upstreams and iBGP/OSPF internally. I went >> with >>> the 16gb RAM models. >>> >>> However these boxes are basically Linux running on top of tilera CPUs, >> in >>> terms of throughput as long as everything stays on the fastpath they have >> no >>> issues doing wire speed on all ports, however the moment you add a >> firewall >>> rule or the like they drop to 1.5gbps. >>> >>> >>> >>>> On 27/12/2013, at 9:47 pm, Martin Hotze wrote: >>>> >>>> Hi, >>>> >>>> looking at the specs of Mikrotik Cloud Core Routers it seems to be to >> good >>>> to be true [1] having so much bang for the bucks. So virtually all >> smaller >>>> ISPs would drop their CISCO gear for Mikrotik Routerboards. >>>> >>>> We are using a handful of Mikrotik boxes, but on a much lower network >> level >>>> (splitting networks; low end router behind ADSL modem, ...). We're >> happy >>>> with them. >>>> >>>> So I am asking for real life experience and not lab values with >> Mikrotik >>>> Cloud Core Routers and BGP. How good can they handle full tables and a >>>> bunch of peering sessions? How good does the box react when adding >> filters >>>> (during attacks)? Reloading the table? etc. etc. >>>> >>>> I am looking for _real_ _life_ values compared to a CISCO NPE-G2. >> Please >>>> tell me/us from your first hand experience. >>>> >>>> Thanks! >>>> >>>> greetings, Martin >>>> >>>> [1] If something sounds too good to be true, it probably is. > > > -- > Eduardo Schoedler -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6151 bytes Desc: not available URL: From fohdeesha at gmail.com Fri Dec 27 23:56:13 2013 From: fohdeesha at gmail.com (Jon Sands) Date: Fri, 27 Dec 2013 18:56:13 -0500 Subject: The Making of a Router In-Reply-To: References: Message-ID: <52BE139D.2070505@gmail.com> On 12/27/2013 4:23 PM, Matt Palmer wrote: > There *is* a world outside of Silly Valley, you know... a world where > money doesn't flow like a mighty cascade from the benevolent wallets > of vulture capitalists, into the waiting arms of every crackpot with > an elevator pitch. - Matt Yes, and in that world, one should probably not start up a FTTH ISP when one has not even budgeted for a router, among a thousand other things. And if you must, you should probably figure out your cost breakdown beforehand, not after. Baldur, you mention $200k total to move 10gb with Juniper (which seems insanely off to me). Look into Brocades CER line, you can move 4x 10gbe per chassis for under 12k. -- Jon Sands From rps at maine.edu Sat Dec 28 00:13:05 2013 From: rps at maine.edu (Ray Soucy) Date: Fri, 27 Dec 2013 19:13:05 -0500 Subject: The Making of a Router In-Reply-To: <52BE139D.2070505@gmail.com> References: <52BE139D.2070505@gmail.com> Message-ID: It seems to be a pretty "hot button" issue, but I feel that modern hardware is more than capable of pushing packets. The old wisdom of "only hardware can do it efficiently" is starting to prove untrue. 10G might still be a challenge (I haven't tested), but 1G is not even close to being an issue. Depending on the target for your deployment, it might make sense to whitebox a router or firewall instead of spending 20K on it. Especially if you're working with any kind of scale. TL;DR I think the backlash against anything but big iron routing is becoming an old way of thinking. On Fri, Dec 27, 2013 at 6:56 PM, Jon Sands wrote: > On 12/27/2013 4:23 PM, Matt Palmer wrote: > >> There *is* a world outside of Silly Valley, you know... a world where >> money doesn't flow like a mighty cascade from the benevolent wallets of >> vulture capitalists, into the waiting arms of every crackpot with an >> elevator pitch. - Matt >> > > Yes, and in that world, one should probably not start up a FTTH ISP when > one has not even budgeted for a router, among a thousand other things. And > if you must, you should probably figure out your cost breakdown beforehand, > not after. Baldur, you mention $200k total to move 10gb with Juniper (which > seems insanely off to me). Look into Brocades CER line, you can move 4x > 10gbe per chassis for under 12k. > > -- > Jon Sands > -- 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 bzeeb-lists at lists.zabbadoz.net Sat Dec 28 00:27:36 2013 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat, 28 Dec 2013 00:27:36 +0000 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> Message-ID: <2F2E783F-91DF-40D8-8EAB-92D2E801841F@lists.zabbadoz.net> On 28 Dec 2013, at 00:13 , Ray Soucy wrote: > It seems to be a pretty "hot button" issue, but I feel that modern hardware > is more than capable of pushing packets. The old wisdom of "only hardware > can do it efficiently" is starting to prove untrue. 10G might still be a > challenge (I haven't tested), Read the publications from http://routebricks.org/ (and check the year) I thought there was a presentation about this (or similar) a few years ago but maybe I just remember the ?software router? thread from 5 years ago. /bz ? Bjoern A. Zeeb ????????? ??? ??????? ??????: '??? ??? ???? ?????? ??????? ?? ?? ??????? ??????? ??? ????? ????? ???? ?????? ?? ????? ????', ????????? ?????????, "??? ????? ?? ?????", ?.??? From baldur.norddahl at gmail.com Sat Dec 28 01:18:55 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 28 Dec 2013 02:18:55 +0100 Subject: The Making of a Router In-Reply-To: <52BE139D.2070505@gmail.com> References: <52BE139D.2070505@gmail.com> Message-ID: On Sat, Dec 28, 2013 at 12:56 AM, Jon Sands wrote: > Yes, and in that world, one should probably not start up a FTTH ISP when > one has not even budgeted for a router, among a thousand other things. And > if you must, you should probably figure out your cost breakdown beforehand, > not after. Baldur, you mention $200k total to move 10gb with Juniper (which > seems insanely off to me). Look into Brocades CER line, you can move 4x > 10gbe per chassis for under 12k. > I was saying $100k for two Juniper routers total. Perhaps we could get back on track, instead of trying to second guess what we did or did not budget for. You have absolute no information about our business plans. The Brocade BR-CER-2024F-4X-RT-AC - Brocade NetIron CER 2024F-4X goes for about $21k and we need two of them. That is enough to buy a full year of unlimited 10G internet. And even then, we would be short on 10G ports. It is not that we could not bring that money if that was the only way to do it. It is just that I have so many other things that I could spend that money on, that would further our business plans so much more. I can not even say if the Juniper or the Brocade will actually solve my problem. I need it to route to ten of thousands of VLANS (Q-in-Q), both with IPv4 and IPv6. It needs to act as IPv6 router on every VLAN, and very few devices seems to like having that many IP-addresses assigned. It also needs to do VRRP and proxy arp for every VLAN. The advantage of a software solution is that I can test it all before buying. Also to some limited degree, I am able to fix shortcomings myself. Regards, Baldur From fohdeesha at gmail.com Sat Dec 28 01:47:25 2013 From: fohdeesha at gmail.com (Jon Sands) Date: Fri, 27 Dec 2013 20:47:25 -0500 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> Message-ID: <52BE2DAD.5060302@gmail.com> On 12/27/2013 8:18 PM, Baldur Norddahl wrote: > Brocade NetIron CER 2024F-4X goes for > about $21k As one last aside, if you're paying 21k, you're paying a little more than twice too much. Call Brocade and get yourself a real quote. I think peoples main point here is that any handful of thousand dollars you think you will be saving by going PC based, is going to dissapear the very first downtime you experience with zero support. Also, all the features you mention needing are standard features that any modern router should have no problem with. It's been a while but if I remember right you can terminate and route up to 4096 qinq based ve's on a single CER. If you're network topology has you terminating ten thousand qinq networks on a single box, I would take a step back and examine my network topology (if it were me, anyway) -- Jon Sands From rps at maine.edu Sat Dec 28 01:51:14 2013 From: rps at maine.edu (Ray Soucy) Date: Fri, 27 Dec 2013 20:51:14 -0500 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> Message-ID: On a side note, Q-in-Q support has been added to the recent 3.10 Linux kernel, configured using the "ip" command. It will be popping up in distributions "soon [tm]". Another interesting addition is IPv6 NAT (transparent redirect, prefix translation, etc). On Fri, Dec 27, 2013 at 8:18 PM, Baldur Norddahl wrote: > On Sat, Dec 28, 2013 at 12:56 AM, Jon Sands wrote: > > > Yes, and in that world, one should probably not start up a FTTH ISP when > > one has not even budgeted for a router, among a thousand other things. > And > > if you must, you should probably figure out your cost breakdown > beforehand, > > not after. Baldur, you mention $200k total to move 10gb with Juniper > (which > > seems insanely off to me). Look into Brocades CER line, you can move 4x > > 10gbe per chassis for under 12k. > > > > I was saying $100k for two Juniper routers total. > > Perhaps we could get back on track, instead of trying to second guess what > we did or did not budget for. You have absolute no information about our > business plans. > > The Brocade BR-CER-2024F-4X-RT-AC - Brocade NetIron CER 2024F-4X goes for > about $21k and we need two of them. That is enough to buy a full year of > unlimited 10G internet. And even then, we would be short on 10G ports. > > It is not that we could not bring that money if that was the only way to do > it. It is just that I have so many other things that I could spend that > money on, that would further our business plans so much more. > > I can not even say if the Juniper or the Brocade will actually solve my > problem. I need it to route to ten of thousands of VLANS (Q-in-Q), both > with IPv4 and IPv6. It needs to act as IPv6 router on every VLAN, and very > few devices seems to like having that many IP-addresses assigned. It also > needs to do VRRP and proxy arp for every VLAN. > > The advantage of a software solution is that I can test it all before > buying. Also to some limited degree, I am able to fix shortcomings myself. > > Regards, > > Baldur > -- 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 jlewis at lewis.org Sat Dec 28 02:14:37 2013 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 27 Dec 2013 21:14:37 -0500 (EST) Subject: The Making of a Router In-Reply-To: References: Message-ID: On Fri, 27 Dec 2013, Baldur Norddahl wrote: > Another told Nick Cameo that if he can afford a 10G link, he can afford > Juniper. You could not be more wrong. The 10G uplink goes for $0 in initial > fee and less than $4k / month with unlimited traffic. The Juniper gear is > $100k up front for two routers able to handle the 10G links. > > What I get from you guys is that in your opinion it is not possible to set > up a small ISP without spending a ton on Juniper or Cisco. I am not buying > that. Small ISPs don't need 10gb transit connections. Even if you did want cisco gear capable of handling 10gb transit, it can be done on the secondary market for a fraction of that $100k figure. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From baldur.norddahl at gmail.com Sat Dec 28 02:27:47 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 28 Dec 2013 03:27:47 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: On Sat, Dec 28, 2013 at 3:14 AM, Jon Lewis wrote: > On Fri, 27 Dec 2013, Baldur Norddahl wrote: > > Another told Nick Cameo that if he can afford a 10G link, he can afford >> Juniper. You could not be more wrong. The 10G uplink goes for $0 in >> initial >> fee and less than $4k / month with unlimited traffic. The Juniper gear is >> $100k up front for two routers able to handle the 10G links. >> >> What I get from you guys is that in your opinion it is not possible to set >> up a small ISP without spending a ton on Juniper or Cisco. I am not buying >> that. >> > > Small ISPs don't need 10gb transit connections. Even if you did want > cisco gear capable of handling 10gb transit, it can be done on the > secondary market for a fraction of that $100k figure. > We are a small ISP that sells 1000/1000 service to our customers. It seems wise to have larger pipe upstream than what you are selling... Regards, Baldur From brian at aereo.com Sat Dec 28 02:50:03 2013 From: brian at aereo.com (Brian Loveland) Date: Fri, 27 Dec 2013 21:50:03 -0500 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> Message-ID: Interested on where you are buying transit at $1750/mo for full 10G ports ($0.175/meg)? On Fri, Dec 27, 2013 at 8:18 PM, Baldur Norddahl wrote: > On Sat, Dec 28, 2013 at 12:56 AM, Jon Sands wrote: > > > Yes, and in that world, one should probably not start up a FTTH ISP when > > one has not even budgeted for a router, among a thousand other things. > And > > if you must, you should probably figure out your cost breakdown > beforehand, > > not after. Baldur, you mention $200k total to move 10gb with Juniper > (which > > seems insanely off to me). Look into Brocades CER line, you can move 4x > > 10gbe per chassis for under 12k. > > > > I was saying $100k for two Juniper routers total. > > Perhaps we could get back on track, instead of trying to second guess what > we did or did not budget for. You have absolute no information about our > business plans. > > The Brocade BR-CER-2024F-4X-RT-AC - Brocade NetIron CER 2024F-4X goes for > about $21k and we need two of them. > > *That is enough to buy a full year of unlimited 10G internet. And even > then, we would be short on 10G ports.* > It is not that we could not bring that money if that was the only way to do > it. It is just that I have so many other things that I could spend that > money on, that would further our business plans so much more. > > I can not even say if the Juniper or the Brocade will actually solve my > problem. I need it to route to ten of thousands of VLANS (Q-in-Q), both > with IPv4 and IPv6. It needs to act as IPv6 router on every VLAN, and very > few devices seems to like having that many IP-addresses assigned. It also > needs to do VRRP and proxy arp for every VLAN. > > The advantage of a software solution is that I can test it all before > buying. Also to some limited degree, I am able to fix shortcomings myself. > > Regards, > > Baldur > From wwaites at tardis.ed.ac.uk Sat Dec 28 03:00:51 2013 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sat, 28 Dec 2013 03:00:51 +0000 (GMT) Subject: The Making of a Router In-Reply-To: References: <52BC6661.6050702@trelane.net> Message-ID: <20131228.030051.509727617.wwaites@tardis.ed.ac.uk> On Fri, 27 Dec 2013 07:23:36 -0500 (EST), "Justin M. Streiner" said: > You end up combining some of the downsides of a hardware-based > router with some of the downsides of a server (new attack > vectors, another device that needs to be backed up, patched, and > monitored... Might be a good idea to back up, patch and monitor your routers too... Just sayin' From baldur.norddahl at gmail.com Sat Dec 28 03:04:03 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 28 Dec 2013 04:04:03 +0100 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> Message-ID: On Sat, Dec 28, 2013 at 3:50 AM, Brian Loveland wrote: > Interested on where you are buying transit at $1750/mo for full 10G ports > ($0.175/meg)? > > I did not that claim that. I said two times $21k divided by 12 = $3500 per month. Try he.net. Regards, Baldur From randy at psg.com Sat Dec 28 03:10:06 2013 From: randy at psg.com (Randy Bush) Date: Fri, 27 Dec 2013 22:10:06 -0500 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> Message-ID: clearly you have a deep understanding of what you are doing, the market, what costs and capabilities are, and where to get what you need. now please remind me of what it was you were asking. randy From baldur.norddahl at gmail.com Sat Dec 28 03:15:53 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 28 Dec 2013 04:15:53 +0100 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> Message-ID: On Sat, Dec 28, 2013 at 4:10 AM, Randy Bush wrote: > clearly you have a deep understanding of what you are doing, the market, > what costs and capabilities are, and where to get what you need. now > please remind me of what it was you were asking. > > randy > I asked if anyone here has experience using OpenFlow in an ISP setting. Clearly the answer is no. Regards, Baldur From Valdis.Kletnieks at vt.edu Sat Dec 28 03:49:59 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Dec 2013 22:49:59 -0500 Subject: The Making of a Router In-Reply-To: Your message of "Fri, 27 Dec 2013 20:37:52 +0000." <373999373.351134.1388176672382.JavaMail.root@snappytelecom.net> References: <373999373.351134.1388176672382.JavaMail.root@snappytelecom.net> Message-ID: <215502.1388202599@turing-police.cc.vt.edu> On Fri, 27 Dec 2013 20:37:52 +0000, Faisal Imtiaz said: > e.g. If someone says I need a 10g interface, why is it automatically assumed > that the router is going to be running @ Full Line Rate ? It may not be full line rate - but it's a pretty sure bet that you plan to run it at a fairly high percentage duty cycle, either right now or in the fairly near future. If you weren't, you'd have bought a 1G interface instead. -------------- 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 Sat Dec 28 03:56:13 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Dec 2013 22:56:13 -0500 Subject: The Making of a Router In-Reply-To: Your message of "Sat, 28 Dec 2013 02:18:55 +0100." References: <52BE139D.2070505@gmail.com> Message-ID: <216172.1388202973@turing-police.cc.vt.edu> On Sat, 28 Dec 2013 02:18:55 +0100, Baldur Norddahl said: > I was saying $100k for two Juniper routers total. Right. And the point that others are trying to make clear is that if that $100K is half your capitalization, you have $200K - and that's nowhere near enought to cover all the stuff you're going to hit starting an ISP. (Hint - what's your projected burn rate for the first two months of business?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From randy at psg.com Sat Dec 28 04:06:26 2013 From: randy at psg.com (Randy Bush) Date: Fri, 27 Dec 2013 23:06:26 -0500 Subject: The Making of a Router In-Reply-To: <216172.1388202973@turing-police.cc.vt.edu> References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> Message-ID: > Right. And the point that others are trying to make clear is that if > that $100K is half your capitalization, you have $200K - and that's > nowhere near enought to cover all the stuff you're going to hit > starting an ISP. (Hint - what's your projected burn rate for the > first two months of business?) not to worry. growth is not going to be an issue doing openflow due to today's tcam limits. From Valdis.Kletnieks at vt.edu Sat Dec 28 04:37:32 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Dec 2013 23:37:32 -0500 Subject: The Making of a Router In-Reply-To: Your message of "Fri, 27 Dec 2013 23:06:26 -0500." References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> Message-ID: <218800.1388205452@turing-police.cc.vt.edu> On Fri, 27 Dec 2013 23:06:26 -0500, Randy Bush said: > not to worry. growth is not going to be an issue doing openflow due to > today's tcam limits. I said burn rate, not growth rate, Randy.. .:) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Sat Dec 28 04:59:25 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 28 Dec 2013 04:59:25 +0000 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu>, Message-ID: I propose cage fighting at the next NANOG summit. Sent from my Mobile Device. -------- Original message -------- From: Randy Bush Date: 12/27/2013 7:07 PM (GMT-09:00) To: Valdis.Kletnieks at vt.edu Cc: North American Network Operators' Group Subject: Re: The Making of a Router > Right. And the point that others are trying to make clear is that if > that $100K is half your capitalization, you have $200K - and that's > nowhere near enought to cover all the stuff you're going to hit > starting an ISP. (Hint - what's your projected burn rate for the > first two months of business?) not to worry. growth is not going to be an issue doing openflow due to today's tcam limits. From ag4ve.us at gmail.com Sat Dec 28 05:58:29 2013 From: ag4ve.us at gmail.com (Shawn Wilson) Date: Sat, 28 Dec 2013 00:58:29 -0500 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu>, Message-ID: <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> This has gotten a bit ridiculous. I was hoping someone could give technical insight into why this is good or not and not just "buy a box branded as a router because I said so or your business will fail". I'm all for hearing about the business theory of running an ISP (not my background or day job) but didn't think that's what the OP was asking about (and it didn't seem they were taking business suggestions very well anyway). This thread started cool and about 10 posts in, started sucking. Warren Bailey wrote: >I propose cage fighting at the next NANOG summit. > > >Sent from my Mobile Device. > > >-------- Original message -------- >From: Randy Bush >Date: 12/27/2013 7:07 PM (GMT-09:00) >To: Valdis.Kletnieks at vt.edu >Cc: North American Network Operators' Group >Subject: Re: The Making of a Router > > >> Right. And the point that others are trying to make clear is that if >> that $100K is half your capitalization, you have $200K - and that's >> nowhere near enought to cover all the stuff you're going to hit >> starting an ISP. (Hint - what's your projected burn rate for the >> first two months of business?) > >not to worry. growth is not going to be an issue doing openflow due to >today's tcam limits. From streiner at cluebyfour.org Sat Dec 28 02:34:00 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 27 Dec 2013 21:34:00 -0500 (EST) Subject: The Making of a Router In-Reply-To: <20131228.030051.509727617.wwaites@tardis.ed.ac.uk> References: <52BC6661.6050702@trelane.net> <20131228.030051.509727617.wwaites@tardis.ed.ac.uk> Message-ID: On Sat, 28 Dec 2013, William Waites wrote: > On Fri, 27 Dec 2013 07:23:36 -0500 (EST), "Justin M. Streiner" said: > > > You end up combining some of the downsides of a hardware-based > > router with some of the downsides of a server (new attack > > vectors, another device that needs to be backed up, patched, and > > monitored... > > Might be a good idea to back up, patch and monitor your routers > too... Just sayin' Yes, a given. jms From joe at nethead.com Sat Dec 28 06:21:37 2013 From: joe at nethead.com (Joe Hamelin) Date: Fri, 27 Dec 2013 22:21:37 -0800 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> Message-ID: >Warren Bailey via nanog.org : >I propose cage fighting at the next NANOG summit. Reminds me of some of the BOFs in 2000ish. Anyway, Ray's "TL;DR I think the backlash against anything but big iron routing is becoming an old way of thinking." should send a message to C&J that for other than "Tier 1" providers, a lot of people are looking for something else that pencils out better.. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From wbailey at satelliteintelligencegroup.com Sat Dec 28 06:31:22 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 28 Dec 2013 06:31:22 +0000 Subject: The Making of a Router In-Reply-To: <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> Message-ID: At the very least, could we fight about something worthwhile? I?m all for a good fight, and I?m the first one to trigger the nuclear explosion.. But the subject matter of this peepee competition is tiring. I query the nanog gods frequently, sometimes you get useful feedback and sometimes you get a bunch of haters trying to piss on your parade. There is probably some validity on both sides, but a Friday night email fight should be reserved for those email blacklist douchebags.. Arguing over DIY routers being shittier than radical COTS equipment can be done off list. It?s supposed to be Christmas.. Have a coke and a smile and STFU if you aren?t going to add some value. I can?t wait for this thread to fan back up on Monday morning when the normal(er) people read this. The first rule of fight club is.. You don?t talk about fight club. On 12/27/13, 8:58 PM, "Shawn Wilson" wrote: >This has gotten a bit ridiculous. > >I was hoping someone could give technical insight into why this is good >or not and not just "buy a box branded as a router because I said so or >your business will fail". I'm all for hearing about the business theory >of running an ISP (not my background or day job) but didn't think that's >what the OP was asking about (and it didn't seem they were taking >business suggestions very well anyway). > >This thread started cool and about 10 posts in, started sucking. > >Warren Bailey wrote: >>I propose cage fighting at the next NANOG summit. >> >> >>Sent from my Mobile Device. >> >> >>-------- Original message -------- >>From: Randy Bush >>Date: 12/27/2013 7:07 PM (GMT-09:00) >>To: Valdis.Kletnieks at vt.edu >>Cc: North American Network Operators' Group >>Subject: Re: The Making of a Router >> >> >>> Right. And the point that others are trying to make clear is that if >>> that $100K is half your capitalization, you have $200K - and that's >>> nowhere near enought to cover all the stuff you're going to hit >>> starting an ISP. (Hint - what's your projected burn rate for the >>> first two months of business?) >> >>not to worry. growth is not going to be an issue doing openflow due to >>today's tcam limits. > From stenrulz at gmail.com Sat Dec 28 06:39:55 2013 From: stenrulz at gmail.com (sten rulz) Date: Sat, 28 Dec 2013 17:39:55 +1100 Subject: The Making of a Router Message-ID: There has been a lot of conversation lately regarding 10Gbps+ routing without higher cost devices such as the junipers. I have been looking into a few options myself, below are my opinions so far. What are your recommendations, real life experiences and ideas? - Mikrotik Cloud Core Router The Mikrotik CCR might have 2 SFP+ ports but with any ACLs, etc fast path is disabled, this already limits the functionality a lot. The BGP calculations only happen on a single core which provides very slow performance for full routing tables. RouterOS is very unstable and had a large number of bugs even with version 6. I have had issues using them even on some small test environments, would not recommend this hardware for nearly any setup. - Linux Based Software Routing Quagga is great for BGP with the correct CPUs and configurations. Vyatta or VyOS provides a stable and simple configuration method for Quagga. The issues with all of the options currently available is forwarding plane performance, you are only looking at 1Gbps+ at line rate. Most providers will have to deal with DDOS attacks at one point or another and would not recommend taking the chance. If you are only looking at 1Gbps or less worth of traffic this is a great option. DDOS attacks information from just the Arbor Networks hardware. http://www.digitalattackmap.com/ Userspace processing of the forwarding plane will help a lot to overcome this issue. There are a few different solutions out there but the most common is Intel DPDK. Some of you would know about the Intel DPDK from the upcoming brocade vRouter 5600 which supports 10Gbps line rate per core. I can see Intel DPDK being used for other solutions such as DDOS filtering as currently you require specialised hardware such as Arbor Networks or NSFOCUS. It would be much cheaper if you could do some filtering from x86 hardware at line rate. http://blog.lukego.com/blog/2013/01/04/kernel-bypass-networking/ Brocade vRouter 5600 might be an option when it is released depending on price. As you still need to get all the hardware required and make sure you do your research regarding the chipsets, etc. Most Intel SFP+ NIC will handle around 9MPPS but has great support for drivers. Solarflare have some nice NICs that can handle 16MPPS but I can see a lot more reviews for different manufacturers coming out after the vRouter release. Hopefully VyOS or some other open source project can integrate Intel DPDK. - OpenFlow OpenFlow is a great method for really high PPS but the major limiting factor is the flow entries and flow mods. I personally like this architecture as it allows the control plane to run on X86 and the Data Plane to run on specialised hardware. For providers with 1 IP transit provider and a few peering IX most OpenFlow hardware will support enough flow entries. The issue is supporting providers with a reasonable number of full routing tables; I think summarization will help a decent amount to lower the flow entries required. NoviSwitch 1248 supports 1 million flow entries which is a reasonable number for smaller providers. I have only started to get my hand dirty with OpenFlow and would like to know if anyone is using it in production for routing? What OpenFlow controller are you using? E.g. RouteFlow https://sites.google.com/site/routeflow/ - Brocade CER The older model CER devices had a lot of issues/bugs but the newer models such as BR-CER-2024C-4X-RT-AC seem to be a lot more stable. There are reviews on webhostingtalk with people pushing more than 30Gbps on the newer models without issue. Based on other people?s comments such as Jon Sands the units should be around 10K each new which makes the units cost affective for a lot of implementations. If you are lucky enough to find one second hand you would only be looking around $5-6K. The 2024C-4X-RT has 4 SFP+ ports which is alright but would really like to see some larger options. Currently a lot of people just create a port channel with all 4 ports to a SFP+ switch which allow them to connect more ports up but need to be careful about overprovisioning. - Layer 3 SFP+ Switch Great for providers with only one uplink as they just use a default route but most providers require more than one uplink. There are lot of cheap options out there even the junipers are not that costly. Regards, Steven. Date: Fri, 27 Dec 2013 21:34:00 -0500 (EST) From: "Justin M. Streiner" To: William Waites Cc: nanog at nanog.org Subject: Re: The Making of a Router Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 28 Dec 2013, William Waites wrote: > On Fri, 27 Dec 2013 07:23:36 -0500 (EST), "Justin M. Streiner" < streiner at cluebyfour.org> said: > > > You end up combining some of the downsides of a hardware-based > > router with some of the downsides of a server (new attack > > vectors, another device that needs to be backed up, patched, and > > monitored... > > Might be a good idea to back up, patch and monitor your routers > too... Just sayin' Yes, a given. jms From stenrulz at gmail.com Sat Dec 28 07:09:12 2013 From: stenrulz at gmail.com (sten rulz) Date: Sat, 28 Dec 2013 18:09:12 +1100 Subject: The Making of a Router Message-ID: Hello Baldur, Your design regarding proxy arp for every VLAN might hit some issues. If you look at the nanog history you will find people having issues with proxy arp for large number of VLANs, what is your requirement for proxy arp? Doing something at the access switch will most likely be better for you such as PVLAN or Brocade IP follow ve statement. If you are planning to put clients on the same subnet what are you planning to put in place to limit client stealing each other?s IPs? Only a few Brocade devices support the ARP ACLs rules which are a really nice feature, IP Source Guard works reasonable if using a DHCP server otherwise you need to specify the MAC address. Some other brand switches support filtering the ARP packets per access port. Regards, Steven. Date: Sat, 28 Dec 2013 02:18:55 +0100 From: Baldur Norddahl To: "nanog at nanog.org" Subject: Re: The Making of a Router Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 28, 2013 at 12:56 AM, Jon Sands wrote: > Yes, and in that world, one should probably not start up a FTTH ISP when > one has not even budgeted for a router, among a thousand other things. And > if you must, you should probably figure out your cost breakdown beforehand, > not after. Baldur, you mention $200k total to move 10gb with Juniper (which > seems insanely off to me). Look into Brocades CER line, you can move 4x > 10gbe per chassis for under 12k. > I was saying $100k for two Juniper routers total. Perhaps we could get back on track, instead of trying to second guess what we did or did not budget for. You have absolute no information about our business plans. The Brocade BR-CER-2024F-4X-RT-AC - Brocade NetIron CER 2024F-4X goes for about $21k and we need two of them. That is enough to buy a full year of unlimited 10G internet. And even then, we would be short on 10G ports. It is not that we could not bring that money if that was the only way to do it. It is just that I have so many other things that I could spend that money on, that would further our business plans so much more. I can not even say if the Juniper or the Brocade will actually solve my problem. I need it to route to ten of thousands of VLANS (Q-in-Q), both with IPv4 and IPv6. It needs to act as IPv6 router on every VLAN, and very few devices seems to like having that many IP-addresses assigned. It also needs to do VRRP and proxy arp for every VLAN. The advantage of a software solution is that I can test it all before buying. Also to some limited degree, I am able to fix shortcomings myself. Regards, Baldur From mikevs at xs4all.net Sat Dec 28 14:31:11 2013 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Sat, 28 Dec 2013 15:31:11 +0100 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> Message-ID: <201312281431.rBSEVBdf027686@xs8.xs4all.nl> In article you write: >It seems to be a pretty "hot button" issue, but I feel that modern hardware >is more than capable of pushing packets. The old wisdom of "only hardware >can do it efficiently" is starting to prove untrue. 10G might still be a >challenge (I haven't tested), but 1G is not even close to being an issue. > Depending on the target for your deployment, it might make sense to >whitebox a router or firewall instead of spending 20K on it. Especially if >you're working with any kind of scale. Yes well, but also remember that bandwidth is not everything. Packets per second is. And if you're going to provide internet connectivity to endusers, some of them /will/ get hit with DDOS attacks. With a hardware router you can survive that as long as the DDOS is not consuming all your bandwidth. A software router being bombarded with a few gigabits of 64 byte packets .. not so much. This is also the reason btw that you should look into shaping the outgoing bandwidth to each enduser, to prevent one of them being DDOSsed filling up the entire link he/she is on. Mike. From cma at cmadams.net Sat Dec 28 14:53:53 2013 From: cma at cmadams.net (Chris Adams) Date: Sat, 28 Dec 2013 08:53:53 -0600 Subject: The Making of a Router In-Reply-To: <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> Message-ID: <20131228145353.GB23108@cmadams.net> Once upon a time, Shawn Wilson said: > I was hoping someone could give technical insight into why this is good or not and not just "buy a box branded as a router because I said so or your business will fail". I'm all for hearing about the business theory of running an ISP (not my background or day job) but didn't think that's what the OP was asking about (and it didn't seem they were taking business suggestions very well anyway). There's been some technical insight here I would say. I'm a big Linux, Open Source, and Free Software advocate, and I'll use Linux-based systems for routing/firewalling small stuff, but for high speed/PPS, get a router with a hardware forwarding system (I like Juniper myself). You can build a decently-fast Linux (or *BSD) system, but you'll need to spend a good bit of time carefully choosing motherboards, cards, etc. to maximize packet handling, possibly buying multiple of each to find the best working combination. Make sure you buy a full set of spares once you find a working combination (because in the PC industry, six months is a lifetime). Then you have to build your OS install, tweaking the setup, network stack, etc. After that, you have to stay on top of updates and such (so plan for more reboots); while on a hardware-forwarding router you can mostly partition off the control plane, on a Linux/*BSD system, the base OS is the forwarding plane. Also, if something breaks, falls over under an attack, etc., you're generally going to be on your own to figure it out. Maybe you can Google the answer (and hope it isn't "that'll be fixed in kernel 3.. Not saying that doesn't happen with router vendors (quoting RFCs at router engineers is "fun"), but it is IMHO less often. The question becomes: what is your time worth? You could spend hundreds of hours going from the start to your satisfactory in-service router, and have a potentially higher upkeep cost. Can you hire somebody with all the same Linux/*BSD knowlege as yourself, so you are not on-call for your home-built router around the clock? I've used Linux on all my computers for almost 20 years, I develop on Linux, and contribute to a Linux distribution. However, when I want to record TV to watch later, I plug in a TiVo, not build a MythTV box. There is a significant value in "just plug it in and it works", and if you don't figure your time investment (both up-front and on-going) into the cost, you are greatly fooling yourself. -- Chris Adams From ag4ve.us at gmail.com Sat Dec 28 15:45:24 2013 From: ag4ve.us at gmail.com (Shawn Wilson) Date: Sat, 28 Dec 2013 10:45:24 -0500 Subject: The Making of a Router In-Reply-To: <20131228145353.GB23108@cmadams.net> References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> <20131228145353.GB23108@cmadams.net> Message-ID: <94b65365-fa31-4aeb-8b0c-615552fac0cb@email.android.com> Chris Adams wrote: >Once upon a time, Shawn Wilson said: >> I was hoping someone could give technical insight into why this is >good or not and not just "buy a box branded as a router because I said >so or your business will fail". I'm all for hearing about the business >theory of running an ISP (not my background or day job) but didn't >think that's what the OP was asking about (and it didn't seem they were >taking business suggestions very well anyway). > >There's been some technical insight here I would say. I'm a big Linux, >Open Source, and Free Software advocate, and I'll use Linux-based >systems for routing/firewalling small stuff, but for high speed/PPS, >get >a router with a hardware forwarding system (I like Juniper myself). > >You can build a decently-fast Linux (or *BSD) system, but you'll need >to >spend a good bit of time carefully choosing motherboards, cards, etc. >to >maximize packet handling, possibly buying multiple of each to find the >best working combination. Make sure you buy a full set of spares once >you find a working combination (because in the PC industry, six months >is a lifetime). Then you have to build your OS install, tweaking the >setup, network stack, etc. > >After that, you have to stay on top of updates and such (so plan for >more reboots); while on a hardware-forwarding router you can mostly >partition off the control plane, on a Linux/*BSD system, the base OS is >the forwarding plane. Also, if something breaks, falls over under an >attack, etc., you're generally going to be on your own to figure it >out. >Maybe you can Google the answer (and hope it isn't "that'll be fixed in >kernel 3.. Not saying that doesn't happen with >router vendors (quoting RFCs at router engineers is "fun"), but it is >IMHO less often. > >The question becomes: what is your time worth? You could spend >hundreds >of hours going from the start to your satisfactory in-service router, >and have a potentially higher upkeep cost. Can you hire somebody with >all the same Linux/*BSD knowlege as yourself, so you are not on-call >for >your home-built router around the clock? > >I've used Linux on all my computers for almost 20 years, I develop on >Linux, and contribute to a Linux distribution. However, when I want to >record TV to watch later, I plug in a TiVo, not build a MythTV box. >There is a significant value in "just plug it in and it works", and if >you don't figure your time investment (both up-front and on-going) into >the cost, you are greatly fooling yourself. I agree with all of this to some degree. IDK whether cost of ownership on a hardware router or a desktop is more or less - I jus haven't done the research. We use them at work and at home I have Cisco and Linksys gear (plus Linux doing some things the router could like DHCP) - go figure. I agree that some network cards and boards work better than others (and am partial to the Intel Pro cards - though I'm unsure if they're still the best). I would also hesitate to route that much traffic with a PC. Though, I have no technical reason for this bias. If you have hardware in production, you really should have a spare - whether we're talking servers, HDDs, batteries, or routers. Ie, that comment is not unique to servers. I also don't think warranty has any bearing on this - I've seen servers stay down for over a day because (both HP and Dell for their respective hardware) screwed up and the company didn't budget for a spare board and I've seen a third of a network be taken out because multiple switch ports just died. How much would a spare switch have cost compared to 50 people not online? At any rate, I'm interested in this because I've worked in both environments and haven't seen a large difference between the two approaches (never worked at an ISP or high bandwidth web environment though). I do like the PC router approach because it allows more versatility wrt dumping packets (no need to dig out that 10mbit dumb hub and throttle the whole network), I can run snort or do simple packet inspection with iptables (some routers can do this but most can't or require a license). So I'm sorta leaning to the PC router as being better - maybe not cheaper but better. From dale.rumph at gmail.com Fri Dec 27 15:04:31 2013 From: dale.rumph at gmail.com (Dale Rumph) Date: Fri, 27 Dec 2013 10:04:31 -0500 Subject: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <50710E9A7E64454C974049FC998EB655018DDD93@03-exchange.lti.local> References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <50710E9A7E64454C974049FC998EB655018DDD93@03-exchange.lti.local> Message-ID: Out of all the network hardware I have worked on in operations these were by far some of the worst. I read lots of good things but like most things in life these just dont stack up against a Cisco or Juniper for stability and reliability. Most of the ISP's I have worked with were HSD but i also followed the progression path in the industry so i have time with Dial Up, ADSL/X/...,WISP's, Data Centers etc. and FTTH I generally only see these in WISP's and some DSL installs. Never anything with huge traffic load and full tables. Generally always driven by the cost factor alone without regard to much else imho. But that's just my experience. However maybe there are people that have managed to keep these up and handle all you have requested. just my 2c On Fri, Dec 27, 2013 at 10:00 AM, Dennis Burgess wrote: > We have many with full routing tables. Load balancing, works fine, I have > one site with 8 DSL lines doing balancing across them. We typically don't > use a GRE tunnel, but OpenVPN or IPSEC work great. > > > Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- > Second Edition" > Link Technologies, Inc -- Mikrotik & WISP Support > Services > Office: 314-735-0270 Website: http://www.linktechs.net - Skype: > linktechs > -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE > - 3G - 3.65 - TV Whitespace > > > -----Original Message----- > From: matt kelly [mailto:mjkelly at gmail.com] > Sent: Friday, December 27, 2013 8:41 AM > To: Raymond Burkholder > Cc: NANOG list > Subject: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life > experiences? > > They can not handle a full routing table. The load balancing doesn't work. > They can not properly reassemble fragmented packets, and therefore drop > all but the first "piece". They can not reliably handle traffic loads over > maybe 200 Mbps, we needed 4-6 Gbps capacity. They can not hold a gre tunnel > connection. > > On Dec 27, 2013 9:07 AM, "Raymond Burkholder" wrote: > > > > > >My real world experience with these is that they suck. Plain and simple. > > >Don't waste your time. > > > > Would you mind elaborating what you were trying to accomplish and what > > failed? > > > > Thank you. > > > > Ray > > > > > > -- > > This message has been scanned for viruses and dangerous content by > > MailScanner, and is believed to be clean. > > > > > > > > From lists at mtin.net Sat Dec 28 17:32:22 2013 From: lists at mtin.net (Justin Wilson) Date: Sat, 28 Dec 2013 12:32:22 -0500 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <52BDC4AB.3030302@rollernet.us> References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <52BDAA34.7060002@shankland.org> <52BDC4AB.3030302@rollernet.us> Message-ID: MPLS has been one of Mikrotiks ?selling points?. MPLS has been pretty stable for at least a year or more now. Their documentation has been kinda weak, but the implementation has been good. Justin -- Justin Wilson MTCNA ? CCNA ? MTCRE ? MTCWE - COMTRAIN Aol & Yahoo IM: j2sw http://www.mtin.net ? xISP News & Consulting http://www.zigwireless.com ? High Speed Internet Options http://www.thebrotherswisp.com ? The Brothers Wisp -----Original Message----- From: Seth Mattinen Date: Friday, December 27, 2013 at 1:19 PM To: Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? >On 12/27/13, 10:01, Justin Wilson wrote: >> The issues I see are because of routers versions. The Cloud core >>routers >> are a fairly new platform. As such, the software isn?t as stable as it >> should be. The OS is up to version 6.7. There were some betas before >>6.0 >> was released. However, almost every version that has been released >> addresses issues with the cloud core. The cloud cores only run Version >>6. >> > > >Unless my knowledge is out of date, the one thing RouterOS has that >others in the same scope lack is a full MPLS stack that's not >experimental. > >~Seth > From ikiris at gmail.com Sat Dec 28 19:50:35 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Sat, 28 Dec 2013 13:50:35 -0600 Subject: The Making of a Router In-Reply-To: <94b65365-fa31-4aeb-8b0c-615552fac0cb@email.android.com> References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> <20131228145353.GB23108@cmadams.net> <94b65365-fa31-4aeb-8b0c-615552fac0cb@email.android.com> Message-ID: Pretty much what everyone else said. I'm a huge linux person, almost everything I use is linux, run full Myth set up etc, but I wouldn't use it for a high PPS situation like this. It's just asking for suffering later, at the worst possible times. -Blake On Sat, Dec 28, 2013 at 9:45 AM, Shawn Wilson wrote: > > > Chris Adams wrote: > >Once upon a time, Shawn Wilson said: > >> I was hoping someone could give technical insight into why this is > >good or not and not just "buy a box branded as a router because I said > >so or your business will fail". I'm all for hearing about the business > >theory of running an ISP (not my background or day job) but didn't > >think that's what the OP was asking about (and it didn't seem they were > >taking business suggestions very well anyway). > > > >There's been some technical insight here I would say. I'm a big Linux, > >Open Source, and Free Software advocate, and I'll use Linux-based > >systems for routing/firewalling small stuff, but for high speed/PPS, > >get > >a router with a hardware forwarding system (I like Juniper myself). > > > >You can build a decently-fast Linux (or *BSD) system, but you'll need > >to > >spend a good bit of time carefully choosing motherboards, cards, etc. > >to > >maximize packet handling, possibly buying multiple of each to find the > >best working combination. Make sure you buy a full set of spares once > >you find a working combination (because in the PC industry, six months > >is a lifetime). Then you have to build your OS install, tweaking the > >setup, network stack, etc. > > > >After that, you have to stay on top of updates and such (so plan for > >more reboots); while on a hardware-forwarding router you can mostly > >partition off the control plane, on a Linux/*BSD system, the base OS is > >the forwarding plane. Also, if something breaks, falls over under an > >attack, etc., you're generally going to be on your own to figure it > >out. > >Maybe you can Google the answer (and hope it isn't "that'll be fixed in > >kernel 3.. Not saying that doesn't happen with > >router vendors (quoting RFCs at router engineers is "fun"), but it is > >IMHO less often. > > > >The question becomes: what is your time worth? You could spend > >hundreds > >of hours going from the start to your satisfactory in-service router, > >and have a potentially higher upkeep cost. Can you hire somebody with > >all the same Linux/*BSD knowlege as yourself, so you are not on-call > >for > >your home-built router around the clock? > > > >I've used Linux on all my computers for almost 20 years, I develop on > >Linux, and contribute to a Linux distribution. However, when I want to > >record TV to watch later, I plug in a TiVo, not build a MythTV box. > >There is a significant value in "just plug it in and it works", and if > >you don't figure your time investment (both up-front and on-going) into > >the cost, you are greatly fooling yourself. > > I agree with all of this to some degree. IDK whether cost of ownership on > a hardware router or a desktop is more or less - I jus haven't done the > research. We use them at work and at home I have Cisco and Linksys gear > (plus Linux doing some things the router could like DHCP) - go figure. > > I agree that some network cards and boards work better than others (and am > partial to the Intel Pro cards - though I'm unsure if they're still the > best). I would also hesitate to route that much traffic with a PC. Though, > I have no technical reason for this bias. > > If you have hardware in production, you really should have a spare - > whether we're talking servers, HDDs, batteries, or routers. Ie, that > comment is not unique to servers. I also don't think warranty has any > bearing on this - I've seen servers stay down for over a day because (both > HP and Dell for their respective hardware) screwed up and the company > didn't budget for a spare board and I've seen a third of a network be taken > out because multiple switch ports just died. How much would a spare switch > have cost compared to 50 people not online? > > At any rate, I'm interested in this because I've worked in both > environments and haven't seen a large difference between the two approaches > (never worked at an ISP or high bandwidth web environment though). I do > like the PC router approach because it allows more versatility wrt dumping > packets (no need to dig out that 10mbit dumb hub and throttle the whole > network), I can run snort or do simple packet inspection with iptables > (some routers can do this but most can't or require a license). So I'm > sorta leaning to the PC router as being better - maybe not cheaper but > better. > > From randy at psg.com Sat Dec 28 21:14:15 2013 From: randy at psg.com (Randy Bush) Date: Sat, 28 Dec 2013 16:14:15 -0500 Subject: The Making of a Router In-Reply-To: References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> <20131228145353.GB23108@cmadams.net> <94b65365-fa31-4aeb-8b0c-615552fac0cb@email.android.com> Message-ID: > Pretty much what everyone else said. I'm a huge linux person, almost > everything I use is linux, run full Myth set up etc, but I wouldn't > use it for a high PPS situation like this. It's just asking for > suffering later, at the worst possible times. to paraphrase MO from many years ago (as i do not have a direct quote), do not use home appliances as production routers. there are niches where routeflow/vandervecken are usable. there are niches where quagga/bird/openbgp are useful. but not core/backbone of any non-trivial network. they might be usable for _slightly_ more than trivial if your business model values your time at zero. randy From mpalmer at hezmatt.org Sat Dec 28 21:17:27 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 29 Dec 2013 08:17:27 +1100 Subject: The Making of a Router In-Reply-To: <52BE2DAD.5060302@gmail.com> References: <52BE139D.2070505@gmail.com> <52BE2DAD.5060302@gmail.com> Message-ID: <20131228211727.GA13615@hezmatt.org> On Fri, Dec 27, 2013 at 08:47:25PM -0500, Jon Sands wrote: > On 12/27/2013 8:18 PM, Baldur Norddahl wrote: > >Brocade NetIron CER 2024F-4X goes for > >about $21k > > As one last aside, if you're paying 21k, you're paying a little more > than twice too much. Call Brocade and get yourself a real quote. s/a real quote/a referral to a reseller who takes a week to even return your call, let alone get a quote to you/ Been there, done that, got the T-shirt, about three months ago, and it was for quite a chunk more kit than $21k list. If they're so slack about getting around to taking my money, how sharp are they going to be when I need to cost them money (ask for support)? > I think peoples main point here is that any handful of thousand dollars > you think you will be saving by going PC based, is going to dissapear the > very first downtime you experience with zero support. So that ~$10k device comes with unlimited 24x7 30 minute response time support, which will get me in touch directly with the people who built and maintain the system I'm running, and with SLA penalties large enough to completely cover the additional costs I incur due to the vendor's failure to perform? That's quite a deal. - Matt -- A byte walks into a bar and orders a pint. Bartender asks him "What's wrong?" The byte says "Parity error." Bartender nods and says "Yeah, I thought you looked a bit off." From mpalmer at hezmatt.org Sat Dec 28 21:29:54 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 29 Dec 2013 08:29:54 +1100 Subject: The Making of a Router In-Reply-To: <20131228145353.GB23108@cmadams.net> References: <52BE139D.2070505@gmail.com> <216172.1388202973@turing-police.cc.vt.edu> <0038f44a-5d50-4caa-8501-338b99c3bfa4@email.android.com> <20131228145353.GB23108@cmadams.net> Message-ID: <20131228212954.GB13615@hezmatt.org> On Sat, Dec 28, 2013 at 08:53:53AM -0600, Chris Adams wrote: > There is a significant value in "just plug it in and it works", and if > you don't figure your time investment (both up-front and on-going) into > the cost, you are greatly fooling yourself. What ISP-grade router are you using that is plug-and-play? So far, all the ones I've used have required some quite considerable configuration and testing to verify they do everything I need, and that's *after* I've spent a long time reading lies^Wfine marketing documentation trying to decide which combination of features best suits my needs, and then trying to guess what other features my business might need during the service lifetime of the device. - Matt -- I can only guess that the designer of the things had a major Toilet Duck habit and had managed to score a couple of industrial-sized bottles of the stuff the night before. -- Tanuki From baldur.norddahl at gmail.com Sun Dec 29 02:31:41 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 29 Dec 2013 03:31:41 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: On Sat, Dec 28, 2013 at 8:09 AM, sten rulz wrote: > Hello Baldur, > > Your design regarding proxy arp for every VLAN might hit some issues. If > you look at the nanog history you will find people having issues with proxy > arp for large number of VLANs, what is your requirement for proxy arp? > Doing something at the access switch will most likely be better for you > such as PVLAN or Brocade IP follow ve statement. If you are planning to put > clients on the same subnet what are you planning to put in place to limit > client stealing each other?s IPs? Only a few Brocade devices support the > ARP ACLs rules which are a really nice feature, IP Source Guard works > reasonable if using a DHCP server otherwise you need to specify the MAC > address. Some other brand switches support filtering the ARP packets per > access port. > This is a complex question that depends entirely on the capabilities of the equipment I can get. I was considering an OpenFlow solution, where this is easy: I would make rules that would only forward traffic with correct source IP from each VLAN. If the user tries something funny, nothing happens and his traffic is just dropped. But I am bit let down on the capabilities of current OpenFlow switches. Most only support OpenFlow 1.0 which is simply not good enough. That has no IPv6 support, which naturally is a requirement. I know about the HP offerings, but they only support 4k rules in hardware, which is a far cry from being enough. There is NoviFlow who are still working on getting me a quote. If they can give me a competitive price I might still consider OpenFlow. The problem is this: A conventional approach assigns a full IPv4 subnet to each user. This uses a minimum of 4 addresses of each user. I currently have to pay somewhere between $10 and $20 for each address and this will only become more expensive in the future. The users each have a unique VLAN (Q-in-Q). The question is, what do I put on those VLANs, if I do not want to put a full IPv4 subnet on each? My own answer to that is to have the users share a larger subnet, for example I could have a full class C sized subnet shared between 253 users/VLANs. To allow these users to communicate with each other, and so they can communicate with the default gateway IP, I will need proxy arp. And in a non-OpenFlow solution, also the associated security functions such as DHCP-snooping to prevent hijacking of IP addresses. Which devices can solve this task? To me the work seems quite simple. For outbound packets, check that the source IP matches the expected IP on the VLAN, then forward the packet according to the routing table. For inbound packets, lookup the destination IP and find the correct VLAN, then push the VLAN tag on the packet and forward it using the normal MAC lookup. For ARP packets, lookup the destination VLAN from the destination IP, change the VLAN tag and forward the packet. There is no reason a device should not be able to handle a large number of rules such as the above. The NoviSwitch will do it. However it appears that a lot of devices are quite limited in this regard. I could buy a router/switch for every few thousand users and split the work between them. Split the cost on many users, so the extra cost would probably not be prohibitive. This is the do the work at the edge solution, although I would be hosting the equipment in the same rack as the core router. But why fill a rack with equipment, to do simple dummy work, that should be manageable by a single device? Regards, Baldur From laurent at guerby.net Sun Dec 29 09:10:19 2013 From: laurent at guerby.net (Laurent GUERBY) Date: Sun, 29 Dec 2013 10:10:19 +0100 Subject: The Making of a Router In-Reply-To: References: Message-ID: <1388308219.20281.150.camel@pc2> On Sun, 2013-12-29 at 03:31 +0100, Baldur Norddahl wrote: > (...) > The users each have a unique VLAN (Q-in-Q). The question is, what do I put > on those VLANs, if I do not want to put a full IPv4 subnet on each? > > My own answer to that is to have the users share a larger subnet, for > example I could have a full class C sized subnet shared between 253 > users/VLANs. > > To allow these users to communicate with each other, and so they can > communicate with the default gateway IP, I will need proxy arp. And in a > non-OpenFlow solution, also the associated security functions such as > DHCP-snooping to prevent hijacking of IP addresses. > > Which devices can solve this task? Hi Baldur, Assuming you manage 1.1.1.0/24 and 2001:db8:0::/48 and have a Linux box on both ends you can get rid of IPv4 and v6 interco subnets and arp proxy the following way: 1/ on the gateway ip addr add 1.1.1.0/32 dev lo for all client VLAN "NN" on eth0 : ip -6 addr add fe80::1/64 dev eth0.NN ip -6 route add 2001:db8:0:NN00::/56 via fe80::1:NN dev eth0.NN 2/ on user CPE number "NN" CPE WAN interface being eth0 : ip addr add 1.1.1.NN/32 dev eth0 ip route add 1.1.1.0/32 dev eth0 ip route add default via 1.1.1.0 ip -6 addr add fe80::1:NN/64 dev eth0 ip -6 route add default via fe80::1 dev eth0 # ip -6 addr add 2001:db8:0:NN00::1/56 dev eth0 # optional Note: NN in hex for IPv6 The trick in IPv4 is that linux by default will answer to ARP requests for "1.1.1.0" on all interfaces even if the adress is on the loopback. And in IPv6 use static link local on both ends. You can replace "1.1.1.0" by any IPv4, but since ".0" are rarely assigned to end users it doesn't waste anything and keep traceroute with public IPv4. The nice thing of this setup is that it "virtualizes" the routing from the client point of view: you can split/balance your clients on multiple physical gateways and not change a line to the client configuration while it's being moved, you just have to configure your IGP between gateways to properly distribute internal routes. We (AS197422 / tetaneutral.net) use this for virtual machines too (with "tapNN" interfaces from KVM instead of "eth0.NN"): it allows us to move virtual machines around physical machines without user reconfiguration, not waste any IPv4 and avoid all issues with shared L2 (rogue RA/ARP spoofing/whatever) since there's no shared L2 anymore between user VM. It also allows us to not pre split our IPv4 space in a fixed scheme, we manage only /32 so no waste at all. Of course you still have work to do on PPS tuning. Sincerely, Laurent GUERBY AS197422 http://tetaneutral.net peering http://as197422.net PS: minimum settings on a Linux router echo 1 > /proc/sys/net/ipv4/ip_forward for i in /proc/sys/net/ipv6/conf/*; do for j in autoconf accept_ra; do echo 0 > $i/$j; done;done echo 1 > /proc/sys/net/ipv6/conf/all/forwarding echo 65536 > /proc/sys/net/ipv6/route/max_size for i in /proc/sys/net/ipv4/conf/*/arp_announce; do echo 2 > $i;done PPS: we also like to give /56 to our users in IPv6, it makes a nice /24 IPv4 <=> /48 IPv6 correspondance (256 users). From rps at maine.edu Sun Dec 29 14:11:38 2013 From: rps at maine.edu (Ray Soucy) Date: Sun, 29 Dec 2013 09:11:38 -0500 Subject: The Making of a Router In-Reply-To: <1388308219.20281.150.camel@pc2> References: <1388308219.20281.150.camel@pc2> Message-ID: > for i in /proc/sys/net/ipv4/conf/*/arp_announce; do echo 2 > $i;done +1 setting arp_announce in Linux is essential if being used as a router with more than one subnet. I would also recommend setting arp_ignore. For Linux-based routers, I've found the following settings to be optimal: echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore On a side note, this underscores what a lot of people on-list are saying: If you don't understand the internals of a Linux system, for example, "rolling your own" will bite you. It's also pretty rare to find a network engineer who is also a Linux system-level developer, so finding and maintaining that talent can often be a challenge. Many make a leap and go on to assert that because of this software-based systems can never be viable, which I disagree with. After all, the latest OS offerings from Cisco run a Linux kernel. Nearly all the Ciena DWDM and ME gear I run is built on Linux. These companies aren't doing quite as much with hardware acceleration as they would lead you to believe. I think Intel DPDK will be a disruptive technology for networking. At the end of the day, I'm pretty anxious to see the days of over-priced routers driving up network service costs go away. On Sun, Dec 29, 2013 at 4:10 AM, Laurent GUERBY wrote: > > On Sun, 2013-12-29 at 03:31 +0100, Baldur Norddahl wrote: > > (...) > > The users each have a unique VLAN (Q-in-Q). The question is, what do I put > > on those VLANs, if I do not want to put a full IPv4 subnet on each? > > > > My own answer to that is to have the users share a larger subnet, for > > example I could have a full class C sized subnet shared between 253 > > users/VLANs. > > > > To allow these users to communicate with each other, and so they can > > communicate with the default gateway IP, I will need proxy arp. And in a > > non-OpenFlow solution, also the associated security functions such as > > DHCP-snooping to prevent hijacking of IP addresses. > > > > Which devices can solve this task? > > Hi Baldur, > > Assuming you manage 1.1.1.0/24 and 2001:db8:0::/48 and > have a Linux box on both ends you can get rid of > IPv4 and v6 interco subnets and arp proxy the following way: > > 1/ on the gateway > ip addr add 1.1.1.0/32 dev lo > > for all client VLAN "NN" on eth0 : > ip -6 addr add fe80::1/64 dev eth0.NN > ip -6 route add 2001:db8:0:NN00::/56 via fe80::1:NN dev eth0.NN > > 2/ on user CPE number "NN" CPE WAN interface being eth0 : > ip addr add 1.1.1.NN/32 dev eth0 > ip route add 1.1.1.0/32 dev eth0 > ip route add default via 1.1.1.0 > ip -6 addr add fe80::1:NN/64 dev eth0 > ip -6 route add default via fe80::1 dev eth0 > # ip -6 addr add 2001:db8:0:NN00::1/56 dev eth0 # optional > > Note: NN in hex for IPv6 > > The trick in IPv4 is that linux by default will answer to ARP requests > for "1.1.1.0" on all interfaces even if the adress is on the loopback. > And in IPv6 use static link local on both ends. You can replace > "1.1.1.0" by any IPv4, but since ".0" are rarely assigned to end users > it doesn't waste anything and keep traceroute with public IPv4. > > The nice thing of this setup is that it "virtualizes" the routing from > the client point of view: you can split/balance your clients on multiple > physical gateways and not change a line to the client configuration > while it's being moved, you just have to configure your IGP between > gateways to properly distribute internal routes. > > We (AS197422 / tetaneutral.net) use this for virtual machines too (with > "tapNN" interfaces from KVM instead of "eth0.NN"): it allows us to move > virtual machines around physical machines without user reconfiguration, > not waste any IPv4 and avoid all issues with shared L2 (rogue RA/ARP > spoofing/whatever) since there's no shared L2 anymore between user VM. > It also allows us to not pre split our IPv4 space in a fixed scheme, > we manage only /32 so no waste at all. > > Of course you still have work to do on PPS tuning. > > Sincerely, > > Laurent GUERBY > AS197422 http://tetaneutral.net peering http://as197422.net > > PS: minimum settings on a Linux router > echo 1 > /proc/sys/net/ipv4/ip_forward > for i in /proc/sys/net/ipv6/conf/*; do for j in autoconf accept_ra; do echo 0 > $i/$j; done;done > echo 1 > /proc/sys/net/ipv6/conf/all/forwarding > echo 65536 > /proc/sys/net/ipv6/route/max_size > for i in /proc/sys/net/ipv4/conf/*/arp_announce; do echo 2 > $i;done > > PPS: we also like to give /56 to our users in IPv6, it makes a nice /24 > IPv4 <=> /48 IPv6 correspondance (256 users). > > > -- 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 stenrulz at gmail.com Mon Dec 30 09:30:27 2013 From: stenrulz at gmail.com (sten rulz) Date: Mon, 30 Dec 2013 20:30:27 +1100 Subject: NSA able to compromise Cisco, Juniper, Huawei switches Message-ID: Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx Regards, Steven. From saku at ytti.fi Mon Dec 30 10:06:32 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 30 Dec 2013 12:06:32 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: Message-ID: <20131230100632.GA15285@pob.ytti.fi> On (2013-12-30 20:30 +1100), sten rulz wrote: > Found some interesting news on one of the Australia news websites. > > http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx The quality of this data is too damn low. Not as bad as this though, http://cryptome.org/2013/12/Full-Disclosure.pdf I really think we're doing disservice to an issue which might be at scale of human-rights issue, by spamming media with 0 data news. Where is this backdoor? How does it work? How can I recreate on my devices? Large audience already seems to largely be in ignore mode about NSA revelations, since revelations are very noisy but little signal. -- ++ytti From rdrake at direcpath.com Mon Dec 30 10:06:48 2013 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 30 Dec 2013 05:06:48 -0500 Subject: The state of TACACS+ Message-ID: <52C145B8.7040101@direcpath.com> Ever since first using it I've always liked tacacs+. Having said that I've grown to dislike some things about it recently. I guess, there have always been problems but I've been willing to leave them alone. I don't have time to give the code a real deep inspection, so I'm interested in others thoughts about it. I suspect people have just left it alone because it works. Also I apologize if this is too verbose or technical, or not technical enough, or just hard to read. History: TACACS+ was proposed as a standard to the IETF. They never adopted it and let the standards draft expire in 1998. Since then there have been no official changes to the code. Much has happened between now and then. I specifically was interested in parsing tac_plus logs correctly. After finding idiosyncrasies I decided to look at the source and the RFC to see what was really happening. Logging, or why I got into this mess: In the accounting log, fields are sometimes logged in different order. It appears the client is logging whatever it receives without parsing it or modifying it. That means the remote system is sending them in different orders, so technically the fault lies with them. However, it seems too trusting to take in data and log it without looking at it. This can also cause issues when you send a command like (Cisco) "dir /all nvram:" on a box with many files. The device expands the command to include everything on the nvram (important because you might want to deny access to that command based on something it expanded), but it gets truncated somewhere (not sure if it's the device buffer that is full, tac_plus, or the logging part. I might tcpdump for a while to see if I can figure out what it looks like on the wire) I'm not sure if there are security implications there. Encryption: The existing security consists of md5 XOR with the md5 being composed of a running series of 16 byte hashes, taking the previous hash as part of the seed of the next hash. A sequence number is used so simple replay shouldn't be a factor. Depending on how vulnerable iterative md5 is to it, and how much time you had to sniff the traffic, I would think this would be highly vulnerable to chosen plaintext if you already have a user-level login, or at least partial known plaintext (with the assumption they make backups, you can guess that at least some of the packets will have "show running-config" and other common commands). They also don't pad the encrypted string so you can guess the command (or password) based on the length of the encrypted data. For a better description of the encryption you can read the draft: http://tools.ietf.org/html/draft-grant-tacacs-02 I found an article from May, 2000 which shows that the encryption scheme chosen was insufficient even then. http://www.openwall.com/articles/TACACS+-Protocol-Security For new crypto I would advise multiple cipher support with negotiation so you know what each client and server is capable of. If the client and server supported multiple keys (with a keyid) it would be easier to roll keys frequently, or if it isn't too much overhead they could use public key. Clients: As for clients, Wikipedia lists several that seem to be based on the original open-source tac_plus from Cisco. shrubbery.net has the "official" version that debian and freebsd use. I looked at some of the others and they all seemed to derive from Cisco's code directly or shrubbery.net code, but they retained the name and started doing their own versioning. All the webpages look like they're from 1995. In some cases I think it's intentional but in some ways it shows a lack of care for the code, like it's been dropped since 2000. Documentation is old: This only applies to shrubbery.net's version. I didn't look at the other ones that closely. While all of it appears valid, one Q&A in the FAQ was about IOS 10.3/11.0. Performance questions use the sparc 2 as a target machine. There isn't an INSTALL or README, just the FAQ/CHANGES/COPYING (and a tac_plus.conf manpage), so the learning curve for new users is probably pretty steep. Also there isn't a clear maintainer. The best email address I found was listed in the tacacs+.spec file, for packaging on rpm systems. If you hit the website they give some hints with some outdated, though still functional links. And they list the official email as tac_plus at shrubbery.net Conclusion: Did everyone already know this but me? If so have you moved to Kerberos? Can Kerberos do everything TACACS+ was doing for router authorization? I've got gear that only supports radius and tacacsplus, so in some cases I have no choice but to use one of those, neither of which I would trust over an unencrypted wire. If TACACS+ isn't a dead end then it needs a push to bring the protocol to a new version. There are big name vendors involved in making supported clients and servers. There should be someone invested in keeping it secure and adding features. From ag4ve.us at gmail.com Mon Dec 30 11:12:19 2013 From: ag4ve.us at gmail.com (Shawn Wilson) Date: Mon, 30 Dec 2013 06:12:19 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131230100632.GA15285@pob.ytti.fi> References: <20131230100632.GA15285@pob.ytti.fi> Message-ID: Saku Ytti wrote: >On (2013-12-30 20:30 +1100), sten rulz wrote: > >I really think we're doing disservice to an issue which might be at >scale of >human-rights issue, by spamming media with 0 data news. Where is this >backdoor? How does it work? How can I recreate on my devices? I don't really want you to know how to recreate it until the companies have had a chance to fix said issue. I'd hope, if such issues were disclosed, those news outlets would go through proper channels of disclosure before going to press with it. > >Large audience already seems to largely be in ignore mode about NSA >revelations, since revelations are very noisy but little signal. I think the NSA is hoping that to be the case. But just based on the fact that 60 Minutes did a story on the NSA and the NSA, POTUS, congress, and that half my Twitter, Facebook, and mailing lists are still talking about it (though my networks are probably biased) shows that people are still interested. Also, I think there's a fair chance SCOTUS will take this up due to differing rulings. Before this goes the way of Crypto-AG or clapper, its got quite a fair distance left in it. From jof at thejof.com Mon Dec 30 11:14:52 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Mon, 30 Dec 2013 03:14:52 -0800 Subject: The state of TACACS+ In-Reply-To: <52C145B8.7040101@direcpath.com> References: <52C145B8.7040101@direcpath.com> Message-ID: I don't understand why vendors and operators keep turning to TACACS. It seems like they're often looking to Cisco as some paragon of best security practices. It's a vulnerable protocol, but some times the only thing to choose from. One approach to secure devices that can support only TACACS or RADIUS: Deploy a small embedded *nix machine (Soekris, Raspberry Pi, etc.) that runs a RADSEC (for RADIUS) or stunnel (for TACACS) proxy. Attach it to a short copper with 802.1q, take weak xor'ed requests in on one tag, wrap the requests with TLS, and forward out another tag towards your central AAA box. Kerberos or more certificate-based SSH on routers would be super. SSH with certificates is nice in that it allows authenticators out in the field to verify clients "offline", without needing a central AAA server. However, the tradeoff is that you must then make sure all the clocks are correct and in-sync, and root certificates are verified. On Mon, Dec 30, 2013 at 2:06 AM, Robert Drake wrote: > Ever since first using it I've always liked tacacs+. Having said that > I've grown to dislike some things about it recently. I guess, there have > always been problems but I've been willing to leave them alone. > > I don't have time to give the code a real deep inspection, so I'm > interested in others thoughts about it. I suspect people have just left it > alone because it works. Also I apologize if this is too verbose or > technical, or not technical enough, or just hard to read. > > History: > > TACACS+ was proposed as a standard to the IETF. They never adopted it and > let the standards draft expire in 1998. Since then there have been no > official changes to the code. Much has happened between now and then. I > specifically was interested in parsing tac_plus logs correctly. After > finding idiosyncrasies I decided to look at the source and the RFC to see > what was really happening. > > Logging, or why I got into this mess: > > In the accounting log, fields are sometimes logged in different order. It > appears the client is logging whatever it receives without parsing it or > modifying it. That means the remote system is sending them in different > orders, so technically the fault lies with them. However, it seems too > trusting to take in data and log it without looking at it. This can also > cause issues when you send a command like (Cisco) "dir /all nvram:" on a > box with many files. The device expands the command to include everything > on the nvram (important because you might want to deny access to that > command based on something it expanded), but it gets truncated somewhere > (not sure if it's the device buffer that is full, tac_plus, or the logging > part. I might tcpdump for a while to see if I can figure out what it looks > like on the wire) I'm not sure if there are security implications there. > > Encryption: > > The existing security consists of md5 XOR with the md5 being > composed of a running series of 16 byte hashes, taking the previous hash as > part of the seed of the next hash. A sequence number is used so simple > replay shouldn't be a factor. Depending on how vulnerable iterative md5 is > to it, and how much time you had to sniff the traffic, I would think this > would be highly vulnerable to chosen plaintext if you already have a > user-level login, or at least partial known plaintext (with the assumption > they make backups, you can guess that at least some of the packets will > have "show running-config" and other common commands). They also don't pad > the encrypted string so you can guess the command (or password) based on > the length of the encrypted data. > > For a better description of the encryption you can read the draft: > http://tools.ietf.org/html/draft-grant-tacacs-02 > I found an article from May, 2000 which shows that the encryption scheme > chosen was insufficient even then. > http://www.openwall.com/articles/TACACS+-Protocol-Security > > For new crypto I would advise multiple cipher support with negotiation so > you know what each client and server is capable of. If the client and > server supported multiple keys (with a keyid) it would be easier to roll > keys frequently, or if it isn't too much overhead they could use public key. > > > Clients: > > As for clients, Wikipedia lists several that seem to be based on the > original open-source tac_plus from Cisco. shrubbery.net has the > "official" version that debian and freebsd use. I looked at some of the > others and they all seemed to derive from Cisco's code directly or > shrubbery.net code, but they retained the name and started doing their > own versioning. All the webpages look like they're from 1995. In some > cases I think it's intentional but in some ways it shows a lack of care for > the code, like it's been dropped since 2000. > > Documentation is old: > > This only applies to shrubbery.net's version. I didn't look at the other > ones that closely. While all of it appears valid, one Q&A in the FAQ was > about IOS 10.3/11.0. Performance questions use the sparc 2 as a target > machine. There isn't an INSTALL or README, just the FAQ/CHANGES/COPYING > (and a tac_plus.conf manpage), so the learning curve for new users is > probably pretty steep. Also there isn't a clear maintainer. The best > email address I found was listed in the tacacs+.spec file, for packaging on > rpm systems. > > If you hit the website they give some hints with some outdated, though > still functional links. And they list the official email as > tac_plus at shrubbery.net > > > Conclusion: > > Did everyone already know this but me? If so have you moved to Kerberos? > Can Kerberos do everything TACACS+ was doing for router authorization? > I've got gear that only supports radius and tacacsplus, so in some cases I > have no choice but to use one of those, neither of which I would trust over > an unencrypted wire. If TACACS+ isn't a dead end then it needs a push to > bring the protocol to a new version. There are big name vendors involved > in making supported clients and servers. There should be someone invested > in keeping it secure and adding features. > > > > From saku at ytti.fi Mon Dec 30 11:18:51 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 30 Dec 2013 13:18:51 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> Message-ID: <20131230111851.GA24557@pob.ytti.fi> On (2013-12-30 06:12 -0500), Shawn Wilson wrote: > I don't really want you to know how to recreate it until the companies have had a chance to fix said issue. I'd hope, if such issues were disclosed, those news outlets would go through proper channels of disclosure before going to press with it. Until disclosed it's just speculation and conjecture. If vendors are cooperating with NSA, there is no incentive to fix, there is incentive to claim fix or non-existence of such features. I welcome the short-term havok and damage of such disclose if it would be anywhere near the magnitude implied, it would create pressure to change things. -- ++ytti From rdobbins at arbor.net Mon Dec 30 11:28:26 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 30 Dec 2013 11:28:26 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131230100632.GA15285@pob.ytti.fi> References: <20131230100632.GA15285@pob.ytti.fi> Message-ID: On Dec 30, 2013, at 5:06 PM, Saku Ytti wrote: > The quality of this data is too damn low. The #1 way that Cisco routers and switches are compromised is brute-forcing against an unsecured management plane, with username 'cisco' and password 'cisco. The #1 way that Juniper and switches are compromised is brute-forcing against an unsecured management plane, with username 'cisco' and password 'cisco. ;> Note that both Cisco and Juniper have many platforms, running on various hardware, and running various OSes/trains/releases/throttles ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From saku at ytti.fi Mon Dec 30 11:28:42 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 30 Dec 2013 13:28:42 +0200 Subject: The state of TACACS+ In-Reply-To: <52C145B8.7040101@direcpath.com> References: <52C145B8.7040101@direcpath.com> Message-ID: <20131230112842.GA25340@pob.ytti.fi> On (2013-12-30 05:06 -0500), Robert Drake wrote: > TACACS+ was proposed as a standard to the IETF. They never adopted > it and let the standards draft expire in 1998. Since then there If continued existence of TACACS+ can be justified at IETF level, in parallel with radius and diameter, I have some interest in the subject and would be ready to work with draft. > Encryption: > > For new crypto I would advise multiple cipher support with > negotiation so you know what each client and server is capable of. > If the client and server supported multiple keys (with a keyid) it It seems encryption is your only/major woe? Personally I don't like how we need to keep reimplementing crypto per-application level. We're living in a world where crypto should be standard for all connection, not application issue. There are some solutions to this like BEEP framework or new L4 protocol like QUIC and MinimaLT, any of which I think would be workable as mandatory transport for TACACS. > Clients: > > "official" version that debian and freebsd use. I looked at some of > the others and they all seemed to derive from Cisco's code directly There is also commercial server 'radiator' which does radius and tacacs amongst others. > Did everyone already know this but me? If so have you moved to I think I missed the key revelation. The naive encryption? The limited amount of software available? > Kerberos? Can Kerberos do everything TACACS+ was doing for router I think from networker point of view, it's radiator or tacacs, if it has to work today without new software. And if it can require new software, it can be pretty much arbitrary new protocol, if sound justification can be found. -- ++ytti From rdobbins at arbor.net Mon Dec 30 11:29:49 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 30 Dec 2013 11:29:49 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131230111851.GA24557@pob.ytti.fi> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> Message-ID: <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> On Dec 30, 2013, at 6:18 PM, Saku Ytti wrote: > I welcome the short-term havok and damage of such disclose if it would be anywhere near the magnitude implied, it would create pressure to change > things. This is the type of change we're likely to see, IMHO: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rps at maine.edu Mon Dec 30 13:07:10 2013 From: rps at maine.edu (Ray Soucy) Date: Mon, 30 Dec 2013 08:07:10 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> Message-ID: Even more outrageous than the domestic spying is the arrogance to think that they can protect the details on backdoors into critical infrastructure. They may have basically created the framework for an Internet-wide kill switch, that likely also affects every aspect of modern communication. Since they don't disclose any of this to other agencies, it's very likely that even parts of the DOD is vulnerable. I hope when [if] the truth is learned it is a lot less prevalent than it sounds, but I'm not optimistic. This is why we need all infrastructure to be implemented using open standards, open hardware designs, and open source software IMHO. I hope Cisco, Juniper, and others respond quickly with updated images for all platforms affected before the details leak. On Mon, Dec 30, 2013 at 6:29 AM, Dobbins, Roland wrote: > > On Dec 30, 2013, at 6:18 PM, Saku Ytti wrote: > > > I welcome the short-term havok and damage of such disclose if it would > be anywhere near the magnitude implied, it would create pressure to change > > things. > > This is the type of change we're likely to see, IMHO: > > > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > -- 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 ag4ve.us at gmail.com Mon Dec 30 13:24:01 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 30 Dec 2013 08:24:01 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> Message-ID: On Mon, Dec 30, 2013 at 8:07 AM, Ray Soucy wrote: > > I hope Cisco, Juniper, and others respond quickly with updated images for > all platforms affected before the details leak. So, if this plays out nice (if true, it won't), the fix will come months before the disclosure. Think, if you're leasing a router from your ISP, you might not have the ability to update it (or might violate your contract). So, you need to wait for [manufacturer] to update, test, and release an update, then you need to work with your provider to make sure the update gets pushed correctly. Also, even open hardware isn't completely open - see the Pi - probably the most open of hardware stacks. The CPU isn't completely open. Also, see FreeBSD not using hardware PRNG for this reason. From christopher.morrow at gmail.com Mon Dec 30 13:48:53 2013 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 30 Dec 2013 08:48:53 -0500 Subject: The state of TACACS+ In-Reply-To: <20131230112842.GA25340@pob.ytti.fi> References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> Message-ID: I don't think radius nor kerberos nor ssh with certificates supports command authorization, do they? On Dec 30, 2013 6:33 AM, "Saku Ytti" wrote: > On (2013-12-30 05:06 -0500), Robert Drake wrote: > > > TACACS+ was proposed as a standard to the IETF. They never adopted > > it and let the standards draft expire in 1998. Since then there > > If continued existence of TACACS+ can be justified at IETF level, in > parallel > with radius and diameter, I have some interest in the subject and would be > ready to work with draft. > > > Encryption: > > > > For new crypto I would advise multiple cipher support with > > negotiation so you know what each client and server is capable of. > > If the client and server supported multiple keys (with a keyid) it > > It seems encryption is your only/major woe? Personally I don't like how we > need to keep reimplementing crypto per-application level. We're living in a > world where crypto should be standard for all connection, not application > issue. There are some solutions to this like BEEP framework or new L4 > protocol > like QUIC and MinimaLT, any of which I think would be workable as mandatory > transport for TACACS. > > > Clients: > > > > "official" version that debian and freebsd use. I looked at some of > > the others and they all seemed to derive from Cisco's code directly > > There is also commercial server 'radiator' which does radius and tacacs > amongst others. > > > Did everyone already know this but me? If so have you moved to > > I think I missed the key revelation. The naive encryption? The limited > amount > of software available? > > > Kerberos? Can Kerberos do everything TACACS+ was doing for router > > I think from networker point of view, it's radiator or tacacs, if it has to > work today without new software. And if it can require new software, it > can be > pretty much arbitrary new protocol, if sound justification can be found. > > -- > ++ytti > > From christopher.morrow at gmail.com Mon Dec 30 13:49:20 2013 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 30 Dec 2013 08:49:20 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> Message-ID: Nor accounting... On Dec 30, 2013 8:48 AM, "Christopher Morrow" wrote: > I don't think radius nor kerberos nor ssh with certificates supports > command authorization, do they? > On Dec 30, 2013 6:33 AM, "Saku Ytti" wrote: > >> On (2013-12-30 05:06 -0500), Robert Drake wrote: >> >> > TACACS+ was proposed as a standard to the IETF. They never adopted >> > it and let the standards draft expire in 1998. Since then there >> >> If continued existence of TACACS+ can be justified at IETF level, in >> parallel >> with radius and diameter, I have some interest in the subject and would be >> ready to work with draft. >> >> > Encryption: >> > >> > For new crypto I would advise multiple cipher support with >> > negotiation so you know what each client and server is capable of. >> > If the client and server supported multiple keys (with a keyid) it >> >> It seems encryption is your only/major woe? Personally I don't like how we >> need to keep reimplementing crypto per-application level. We're living in >> a >> world where crypto should be standard for all connection, not application >> issue. There are some solutions to this like BEEP framework or new L4 >> protocol >> like QUIC and MinimaLT, any of which I think would be workable as >> mandatory >> transport for TACACS. >> >> > Clients: >> > >> > "official" version that debian and freebsd use. I looked at some of >> > the others and they all seemed to derive from Cisco's code directly >> >> There is also commercial server 'radiator' which does radius and tacacs >> amongst others. >> >> > Did everyone already know this but me? If so have you moved to >> >> I think I missed the key revelation. The naive encryption? The limited >> amount >> of software available? >> >> > Kerberos? Can Kerberos do everything TACACS+ was doing for router >> >> I think from networker point of view, it's radiator or tacacs, if it has >> to >> work today without new software. And if it can require new software, it >> can be >> pretty much arbitrary new protocol, if sound justification can be found. >> >> -- >> ++ytti >> >> From saku at ytti.fi Mon Dec 30 13:59:48 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 30 Dec 2013 15:59:48 +0200 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> Message-ID: <20131230135948.GA12614@pob.ytti.fi> On (2013-12-30 08:49 -0500), Christopher Morrow wrote: > Nor accounting... I think this is probably sufficient justification for TACACS+. I'm not sure if command authorization is sufficient, as you can deliver group via radius which maps to authorized commands. But if you must support accounting, per-command authorization comes as free gift more or less. -- ++ytti From ck-lists at cksoft.de Mon Dec 30 14:01:55 2013 From: ck-lists at cksoft.de (Christian Kratzer) Date: Mon, 30 Dec 2013 15:01:55 +0100 (CET) Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> Message-ID: Hi, On Mon, 30 Dec 2013, Christopher Morrow wrote: > I don't think radius nor kerberos nor ssh with certificates supports > command authorization, do they? it is with radius afaik ... Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer From cb.list6 at gmail.com Mon Dec 30 14:07:17 2013 From: cb.list6 at gmail.com (cb.list6) Date: Mon, 30 Dec 2013 06:07:17 -0800 Subject: The state of TACACS+ In-Reply-To: <20131230135948.GA12614@pob.ytti.fi> References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <20131230135948.GA12614@pob.ytti.fi> Message-ID: On Dec 30, 2013 9:01 AM, "Saku Ytti" wrote: > > On (2013-12-30 08:49 -0500), Christopher Morrow wrote: > > > Nor accounting... > > I think this is probably sufficient justification for TACACS+. I'm not sure if > command authorization is sufficient, as you can deliver group via radius which > maps to authorized commands. > But if you must support accounting, per-command authorization comes as free > gift more or less. > Yes. Per-command auth and accounting is needed. So what we need is tacacs over TLS (sctp / ipv6) I agree tacacs is long in the tooth and needs to be revisited and invested in. Please take my money (serious) CB > -- > ++ytti > From javier at kjsl.org Mon Dec 30 14:11:40 2013 From: javier at kjsl.org (Javier Henderson) Date: Mon, 30 Dec 2013 09:11:40 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> Message-ID: <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> On Dec 30, 2013, at 9:01 AM, Christian Kratzer wrote: > Hi, > > On Mon, 30 Dec 2013, Christopher Morrow wrote: >> I don't think radius nor kerberos nor ssh with certificates supports >> command authorization, do they? > > it is with radius afaik ... RADIUS does not support command authorization or accounting. -jav From rdobbins at arbor.net Mon Dec 30 14:34:52 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 30 Dec 2013 14:34:52 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> Message-ID: <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> On Dec 30, 2013, at 8:07 PM, Ray Soucy wrote: > I hope Cisco, Juniper, and others respond quickly with updated images for all platforms affected before the details leak. During my time at Cisco, I was involved deeply enough with various platform teams as well as PSIRT, etc., to assert with a pretty high degree of confidence that there were no deliberate secret backdoors inserted into any major Cisco router/switch code prior to 2009, when I left Cisco. And Cisco is such a large company, with so many people involved in coding, compilation, auditing, security issue remediation, et. al. that I doubt very seriously that something like that could be accomplished without leaking pretty promptly. In terms of exploits, the Cisco PSIRT team work with security researchers all the time; while I wasn't a member of PSIRT, I worked very closely with them, and if they'd run across something like that prior to 2009, I'm pretty sure I'd know about it. Every so often, they'd find a non-router/-switch product with default admin credentials, and would work with the product team in question to fix it (this is all public knowledge; you can look through PSIRT advisories on cisco.com and find advisories for default admin credentials for various products, along with links to fixed software versions). And I was also pretty well-acquainted with most of the major software/platform architects, some of whom are still there; none of them would be a party to something like a hidden backdoor, because they all know that it would only be a matter of time until it was found and exploited. The lawful intercept stuff is a partial exception to this, but Fred Baker, Chip Sharp, and Bill Foster went out of their way to proof it as much as possible against unauthorized exploitation, as long as it's implemented correctly, and they put it out there in the public domain via RFC3924. In point of fact, RFC3924 was intended to pre-empt pressure for secret backdoors from LEAs; the idea was to get something that was reasonably secure if implemented correctly out there in the public domain, and adopted as a standard, so that network infrastructure vendors could point to an RFC in order to fend off demands for all this secret-squirrel nonsense. Lawful intercept systems have been exploited in the wild by malicious insiders, but none of the incidents I know about involved Cisco gear. CVE-2008-0960 indirectly impacted lawful intercept due to its SNMP management plane, but responsible network operators should've patched this by now, and should've implemented all the generic BCPs surrounding management-plane traffic, as well. I can't speak for the various third-party lawful-intercept mediation systems, as I've no firsthand knowledge of those. My assumption is that this allegation about Cisco and Juniper is the result of non-specialists reading about lawful intercept for the first time, and failing to do their homework. I don't work for Cisco, and I can't speak for them, but I simply don't find the allegation that there are backdoors hidden in Cisco router/switch code to be credible. Maybe I'm wrong; but since folks are constantly fuzzing Cisco code and looking for ways to exploit it, my guess is that any backdoors would've been found and exploits would be in use in the wild to such a degree that it would've become apparently a long time ago. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From wbailey at satelliteintelligencegroup.com Mon Dec 30 15:05:41 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 30 Dec 2013 15:05:41 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: Message-ID: <8exw39ba1q1f7vb3v45u09g3.1388415934179@email.android.com> I'd love to know how they were getting in flight wifi. Sent from my Mobile Device. -------- Original message -------- From: sten rulz Date: 12/30/2013 12:32 AM (GMT-09:00) To: nanog at nanog.org Subject: NSA able to compromise Cisco, Juniper, Huawei switches Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx Regards, Steven. From Valdis.Kletnieks at vt.edu Mon Dec 30 15:44:08 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 30 Dec 2013 10:44:08 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: Your message of "Mon, 30 Dec 2013 14:34:52 +0000." <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> Message-ID: <152239.1388418248@turing-police.cc.vt.edu> On Mon, 30 Dec 2013 14:34:52 +0000, "Dobbins, Roland" said: > My assumption is that this allegation about Cisco and Juniper is the result > of non-specialists reading about lawful intercept for the first time, and > failing to do their homework. That does raise an interesting question. What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Lee at asgard.org Tue Dec 24 14:15:41 2013 From: Lee at asgard.org (Lee Howard) Date: Tue, 24 Dec 2013 09:15:41 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: From: Matthew Petach Date: Saturday, December 21, 2013 10:55 PM To: Lee Howard Cc: Jamie Bowden , Owen DeLong , "ml at kenweb.org" , "nanog at nanog.org" >> >> So there's an interesting question. You suggest there's a disagreement >> between enterprise network operators and protocol designers. Who should >> change? >> >> I used to run an enterprise network. It was very different from an ISP >> network. I didn't say, "You're wrong!" I said, "What's missing?" > > default route information via DHCPv6. That's what I'm still waiting for. Why? You say, "The protocol suite doesn't meet my needs; I need default gateway in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? Lee > > Matt > From rdobbins at arbor.net Mon Dec 30 16:03:07 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 30 Dec 2013 16:03:07 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <152239.1388418248@turing-police.cc.vt.edu> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> Message-ID: <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> On Dec 30, 2013, at 10:44 PM, wrote: > What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rdobbins at arbor.net Mon Dec 30 16:08:37 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 30 Dec 2013 16:08:37 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> Message-ID: On Dec 30, 2013, at 11:03 PM, Dobbins, Roland wrote: > AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. It's also possible they're talking about something along these lines: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mike at mtcc.com Mon Dec 30 16:11:32 2013 From: mike at mtcc.com (Michael Thomas) Date: Mon, 30 Dec 2013 08:11:32 -0800 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> Message-ID: <52C19B34.8020304@mtcc.com> On 12/30/2013 08:03 AM, Dobbins, Roland wrote: > On Dec 30, 2013, at 10:44 PM, wrote: > >> What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? > AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. > > Also, the way that things are integrated it's usually an explicit decision to pull a piece of functionality in rather than inheriting it. Product managers don't willingly want to waste time pulling things in that a) don't make them money, and b) require support. So I doubt very seriously that CALEA functionality is accidentally included into inappropriate things. Doubly so because of the performance implications. Mike From erey at ernw.de Mon Dec 30 16:16:36 2013 From: erey at ernw.de (Enno Rey) Date: Mon, 30 Dec 2013 17:16:36 +0100 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> Message-ID: <20131230161635.GA16611@ernw.de> On Mon, Dec 30, 2013 at 04:03:07PM +0000, Dobbins, Roland wrote: > > On Dec 30, 2013, at 10:44 PM, wrote: > > > What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? > > AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. at least back in 2007 it could be enabled/configured by SNMP RW access [see slide 43 of the presentation referenced in this post http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] so knowing the term "private" m ight be enough to perform the task remotely. have a good one Enno > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de ======================================================= From bicknell at ufp.org Mon Dec 30 16:19:56 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 30 Dec 2013 10:19:56 -0600 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: <0CC9EF26-1B77-4990-8B29-A55085ABE385@ufp.org> On Dec 24, 2013, at 8:15 AM, Lee Howard wrote: > Why? > You say, "The protocol suite doesn't meet my needs; I need default gateway > in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? Why must the people who want it justify to _you_? This is fundamental part I've not gotten about the IPv6 crowd. IPv4 got to where it is by letting people extend it and develop new protocols and solutions. DHCP did not exist when IPv4 was created, it was tacked on later. Now people want to tack something on to IPv6 to make it more useful to them. Why do they need to explain it to you, if it doesn't affect your deployments at all? Some of us think the model where a DHCP server knows the subnet and hands out a default gateway provides operational advantages. It's an opinion. And the current IPv6 crowds view that not having a default route and relaying on RA's is better is also an opinion. We've spent years of wasted bits and oxygen on ONE STUPID FIELD IN DHCP. Put it in their, and let the market sort it out, unless you can justify some dire harm from doing so. What is more important fast IPv6 adoption or belittling people who want to deploy it in some slightly different way than you did? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From sam at circlenet.us Mon Dec 30 16:18:49 2013 From: sam at circlenet.us (Sam Moats) Date: Mon, 30 Dec 2013 11:18:49 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131230161635.GA16611@ernw.de> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> Message-ID: <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> This might be an interesting example of it's (mis)use. http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%932005 Sam Moats On 2013-12-30 11:16, Enno Rey wrote: > On Mon, Dec 30, 2013 at 04:03:07PM +0000, Dobbins, Roland wrote: >> >> On Dec 30, 2013, at 10:44 PM, >> wrote: >> >> > What percentage of Cisco gear that supports a CALEA lawful >> intercept mode is installed in situations where CALEA doesn't apply, >> and thus there's a high likelyhood that said support is misconfigured >> and abusable without being noticed? >> >> AFAIK, it must be explicitly enabled in order to be functional. It >> isn't the sort of thing which is enabled by default, nor can it be >> enabled without making explicit configuration changes. > > at least back in 2007 it could be enabled/configured by SNMP RW > access [see slide 43 of the presentation referenced in this post > > http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] > so knowing the term "private" m > ight be enough to perform the task remotely. > > have a good one > > Enno > > > > >> >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> >> Luck is the residue of opportunity and design. >> >> -- John Milton >> From brez at brezworks.com Mon Dec 30 16:32:39 2013 From: brez at brezworks.com (Jeremy Bresley) Date: Mon, 30 Dec 2013 10:32:39 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <8exw39ba1q1f7vb3v45u09g3.1388415934179@email.android.com> References: <8exw39ba1q1f7vb3v45u09g3.1388415934179@email.android.com> Message-ID: <52C1A027.2060402@brezworks.com> On 12/30/2013 9:05 AM, Warren Bailey wrote: > I'd love to know how they were getting in flight wifi. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: sten rulz > Date: 12/30/2013 12:32 AM (GMT-09:00) > To: nanog at nanog.org > Subject: NSA able to compromise Cisco, Juniper, Huawei switches > > > Found some interesting news on one of the Australia news websites. > > http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx > > Regards, > Steven. Simple. Grab it from where it hits the base stations. One of the two big in-flight Wifi carriers in the US uses Sprint towers, I believe the other used satellite. They have to get back to a ground station somewhere in order to get network access. Easy to tap it there and send it wherever you want. Grabbing an ad-hoc signal between two endpoints in the air is probably significantly more involved. Implementation of this is left as an exercise for the VERY well-funded reader. ;-) Jeremy "TheBrez" Bresley brez at brezworks.com From wbailey at satelliteintelligencegroup.com Mon Dec 30 16:38:10 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 30 Dec 2013 16:38:10 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <152239.1388418248@turing-police.cc.vt.edu> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net>, <152239.1388418248@turing-police.cc.vt.edu> Message-ID: We had a hell of a time finding anything that supported the calea stuff past a 7206. This was for an in flight global wifi network, hence my original concern. Also note that when we did get it to work, it pretty much didn't. Or I should say.. It worked when it wanted to. How they are mapping pnr to user sessions is beyond me. In our case all of our aaa was being done by a German partner, which further complicated matters. I always assumed they had our traffic via listening stations but they weren't getting it from us. I no longer have a hand in that network, but I am honestly shocked this morning. Sent from my Mobile Device. -------- Original message -------- From: Valdis.Kletnieks at vt.edu Date: 12/30/2013 6:48 AM (GMT-09:00) To: "Dobbins, Roland" Cc: "nanog at nanog.org list" Subject: Re: NSA able to compromise Cisco, Juniper, Huawei switches On Mon, 30 Dec 2013 14:34:52 +0000, "Dobbins, Roland" said: > My assumption is that this allegation about Cisco and Juniper is the result > of non-specialists reading about lawful intercept for the first time, and > failing to do their homework. That does raise an interesting question. What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? From wbailey at satelliteintelligencegroup.com Mon Dec 30 16:38:37 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 30 Dec 2013 16:38:37 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <52C1A027.2060402@brezworks.com> References: <8exw39ba1q1f7vb3v45u09g3.1388415934179@email.android.com>, <52C1A027.2060402@brezworks.com> Message-ID: <7aq3k98k6gcd6wrd63iho1v1.1388421512905@email.android.com> I built the other. Sent from my Mobile Device. -------- Original message -------- From: Jeremy Bresley Date: 12/30/2013 7:34 AM (GMT-09:00) To: nanog at nanog.org Subject: Re: NSA able to compromise Cisco, Juniper, Huawei switches On 12/30/2013 9:05 AM, Warren Bailey wrote: > I'd love to know how they were getting in flight wifi. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: sten rulz > Date: 12/30/2013 12:32 AM (GMT-09:00) > To: nanog at nanog.org > Subject: NSA able to compromise Cisco, Juniper, Huawei switches > > > Found some interesting news on one of the Australia news websites. > > http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx > > Regards, > Steven. Simple. Grab it from where it hits the base stations. One of the two big in-flight Wifi carriers in the US uses Sprint towers, I believe the other used satellite. They have to get back to a ground station somewhere in order to get network access. Easy to tap it there and send it wherever you want. Grabbing an ad-hoc signal between two endpoints in the air is probably significantly more involved. Implementation of this is left as an exercise for the VERY well-funded reader. ;-) Jeremy "TheBrez" Bresley brez at brezworks.com From rdobbins at arbor.net Mon Dec 30 16:49:03 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 30 Dec 2013 16:49:03 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131230161635.GA16611@ernw.de> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> Message-ID: <268A7DCE-AAF5-4265-B045-1D6BA7270659@arbor.net> On Dec 30, 2013, at 11:16 PM, Enno Rey wrote: > at least back in 2007 it could be enabled/configured by SNMP RW access [see slide 43 of the presentation referenced in this post http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] so knowing the term "private" might be enough to perform the task remotely. SNMP RW = configuration. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Mon Dec 30 16:50:32 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 30 Dec 2013 16:50:32 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> Message-ID: <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> On Dec 30, 2013, at 11:18 PM, Sam Moats wrote: > This might be an interesting example of it's (mis)use. > http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%932005 That's one of the cases I know about; it was utilized via Ericsson gear. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rps at maine.edu Mon Dec 30 17:00:57 2013 From: rps at maine.edu (Ray Soucy) Date: Mon, 30 Dec 2013 12:00:57 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> Message-ID: Looking more at the actual leaked information it seems that if the NSA is working with companies, it's not anything the companies are likely aware of. The common form of infection seems to be though software updates performed by administrators (through the NSA hijacking web traffic). They are implimented as firmware and BIOS infections that modify the OS image and persist through software upgrades to provide a persistant back door (PBD). The documents imply that a signiciant of systems deployed are already infected. So this isn't an issue of the NSA working with Cisco and Juniper to include back doors, it's an issue of the NSA modifying those releases after the fact though BIOS implants. Where exatcly the NSA is inserting these we can't be sure. They could be targeted or they could be at the assembly line. Quick Summary of Leaked Information: Source: http://www.spiegel.de/international/world/a-941262.html Firewalls: (1) Cisco PIX and ASA: Codename "JETPLOW" (2) Huawei Eudemon: Codename "HALLUXWATER" (3) Juniper Netscreen and ISG: Codename: "FEEDTROUGH" (4) Juniper SSG and Netscreen G5, 25, and 50, SSG-series: Codename: "GOURMETTROUGH" (5) Juniper SSG300 and SSG500: Codename "SOUFFLETROUGH" Routers: (1) Huawei Router: Codename "HEADWATER" (2) Juniper J-Series: Codename "SCHOOLMONTANA" (3) Juniper M-Series: Codename "SIERRAMONTANA" (4) Juniper T-Series: Codename "STUCCOMONTANA" Servers: (1) HP DL380 G5: Codename "IRONCHEF" (2) Dell PowerEdge: Codename "DEITYBOUNCE" (3) Generic PC BIOS: Codename "SWAP", able to compromise Windows, Linux, FreeBSD, or Solaris using FAT32, NTFS, EXT2, EXT3, or UFS filesystems. USB Cables and VGA Cables: Codename "COTTONMOUTH", this one is a hardware implmant hidden in a USB cable. The diagram shows it's small enough that you would never know its there. Codename "RAGEMASTER", VGA cable, mirrors VGA over the air. Many others. I'm not sure that the list is comprehensive, so I wouldn't say that since Cisco routers are not mentioned (for example) that they're any more safe than Juniper (which is listed often). On Mon, Dec 30, 2013 at 11:50 AM, Dobbins, Roland wrote: > > On Dec 30, 2013, at 11:18 PM, Sam Moats wrote: > > > This might be an interesting example of it's (mis)use. > > http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%932005 > > That's one of the cases I know about; it was utilized via Ericsson gear. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > -- 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 randy at psg.com Mon Dec 30 17:20:49 2013 From: randy at psg.com (Randy Bush) Date: Mon, 30 Dec 2013 07:20:49 -1000 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: > You say, "The protocol suite doesn't meet my needs; I need default > gateway in DHCPv6." So the IETF WG must change for you to deploy > IPv6. Why? this is actually a non-trivial barrier to enterprise deployment and the ietf has been in stubborn denial for years. when an it department has been using dhcp since 2000, do not tell them they have to change to the true religion. fighting with the customer, thoubgh the ipv6 way, is not generally a path to success. randy From streiner at cluebyfour.org Mon Dec 30 14:12:06 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 30 Dec 2013 09:12:06 -0500 (EST) Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: On Tue, 24 Dec 2013, Lee Howard wrote: >>> I used to run an enterprise network. It was very different from an ISP >>> network. I didn't say, "You're wrong!" I said, "What's missing?" >> >> default route information via DHCPv6. That's what I'm still waiting for. > > Why? > You say, "The protocol suite doesn't meet my needs; I need default gateway > in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? DHCPv6 + RA works for that, but still, that really should have been part of the protocol from day one. I see no good reason for it not to be in there. I suspect that will eventually be fixed, but it will be a long time before the majority of DHCPv6 client and server implementations are upgraded to support it. jms From hardenrm at uchicago.edu Mon Dec 30 18:04:48 2013 From: hardenrm at uchicago.edu (Ryan Harden) Date: Mon, 30 Dec 2013 18:04:48 +0000 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> Message-ID: <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> On Dec 24, 2013, at 8:15 AM, Lee Howard wrote: >> default route information via DHCPv6. That's what I'm still waiting for. > > Why? > You say, "The protocol suite doesn't meet my needs; I need default gateway > in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? > > Lee There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there?s little interest (read: budget) in rewriting everything for IPv6. 'Rewrite all of your tools and change your long standing business practices? is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn?t fit into the ?IPv6 way,? but bean counters don?t care much for that when you have to ask for developer time to rewrite everything. Disclaimer: I don?t condone said methods and trickery mentioned above, just pointing out their use. /Ryan From lorell at hathcock.org Mon Dec 30 18:17:30 2013 From: lorell at hathcock.org (Lorell Hathcock) Date: Mon, 30 Dec 2013 12:17:30 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> Message-ID: <01e201cf058b$679dedb0$36d9c910$@hathcock.org> NANOG: Here's the really scary question for me. Would it be possible for NSA-payload traffic that originates on our private networks that is destined for the NSA to go undetected by our IDS systems? For example tcpdump-based IDS systems like Snort has been rooted to ignore or not report packets going back to the NSA? Or netflow on Cisco devices not reporting NSA traffic? Or interface traffic counters discarding NSA-packets to report that there is no usage on the interface when in fact there is? Here's another question. What traffic do we look for on our networks that would be going to the NSA? Thoughts? (And semi-self-consciously adding myself to the NSA list of targets.) Lorell Hathcock -----Original Message----- From: Ray Soucy [mailto:rps at maine.edu] Sent: Monday, December 30, 2013 11:01 AM To: Dobbins, Roland Cc: nanog at nanog.org list Subject: Re: NSA able to compromise Cisco, Juniper, Huawei switches Looking more at the actual leaked information it seems that if the NSA is working with companies, it's not anything the companies are likely aware of. The common form of infection seems to be though software updates performed by administrators (through the NSA hijacking web traffic). They are implimented as firmware and BIOS infections that modify the OS image and persist through software upgrades to provide a persistant back door (PBD). The documents imply that a signiciant of systems deployed are already infected. So this isn't an issue of the NSA working with Cisco and Juniper to include back doors, it's an issue of the NSA modifying those releases after the fact though BIOS implants. Where exatcly the NSA is inserting these we can't be sure. They could be targeted or they could be at the assembly line. Quick Summary of Leaked Information: Source: http://www.spiegel.de/international/world/a-941262.html Firewalls: (1) Cisco PIX and ASA: Codename "JETPLOW" (2) Huawei Eudemon: Codename "HALLUXWATER" (3) Juniper Netscreen and ISG: Codename: "FEEDTROUGH" (4) Juniper SSG and Netscreen G5, 25, and 50, SSG-series: Codename: "GOURMETTROUGH" (5) Juniper SSG300 and SSG500: Codename "SOUFFLETROUGH" Routers: (1) Huawei Router: Codename "HEADWATER" (2) Juniper J-Series: Codename "SCHOOLMONTANA" (3) Juniper M-Series: Codename "SIERRAMONTANA" (4) Juniper T-Series: Codename "STUCCOMONTANA" Servers: (1) HP DL380 G5: Codename "IRONCHEF" (2) Dell PowerEdge: Codename "DEITYBOUNCE" (3) Generic PC BIOS: Codename "SWAP", able to compromise Windows, Linux, FreeBSD, or Solaris using FAT32, NTFS, EXT2, EXT3, or UFS filesystems. USB Cables and VGA Cables: Codename "COTTONMOUTH", this one is a hardware implmant hidden in a USB cable. The diagram shows it's small enough that you would never know its there. Codename "RAGEMASTER", VGA cable, mirrors VGA over the air. Many others. I'm not sure that the list is comprehensive, so I wouldn't say that since Cisco routers are not mentioned (for example) that they're any more safe than Juniper (which is listed often). On Mon, Dec 30, 2013 at 11:50 AM, Dobbins, Roland wrote: > > On Dec 30, 2013, at 11:18 PM, Sam Moats wrote: > > > This might be an interesting example of it's (mis)use. > > http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%93200 > > 5 > > That's one of the cases I know about; it was utilized via Ericsson gear. > > ---------------------------------------------------------------------- > - Roland Dobbins // > > > Luck is the residue of opportunity and design. > > -- John Milton > > > -- 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 ag4ve.us at gmail.com Mon Dec 30 18:35:15 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 30 Dec 2013 13:35:15 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <01e201cf058b$679dedb0$36d9c910$@hathcock.org> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <01e201cf058b$679dedb0$36d9c910$@hathcock.org> Message-ID: On Mon, Dec 30, 2013 at 1:17 PM, Lorell Hathcock wrote: > NANOG: > > Here's the really scary question for me. > > Would it be possible for NSA-payload traffic that originates on our private > networks that is destined for the NSA to go undetected by our IDS systems? > Yup. Absolutely. Without a doubt. > For example tcpdump-based IDS systems like Snort has been rooted to ignore > or not report packets going back to the NSA? Or netflow on Cisco devices > not reporting NSA traffic? Or interface traffic counters discarding > NSA-packets to report that there is no usage on the interface when in fact > there is? > Do you detect 100% of malware in your IDS? Why would anyone need to do anything with your IDS? Craft a PDF, DOC, Java, Flash, or anything else that can run code that people download all the time with payload of unknown signature. This isn't really a network discussion. This is just to say - I seriously doubt there's anything wrong with your IDS - don't skin a cat with a flame thrower, it just doesn't need to be that hard. > Here's another question. What traffic do we look for on our networks that > would be going to the NSA? > Standard https on port 443 maybe? That's how I'd send it. If you need to send something bigger than normal, maybe compromise the email server and have a few people send off some 5 - 10 meg messages? Depends on your normal user base. If you've got a big, complex user base, it's not hard to stay under the radar. Google 'Mandiant APT1' for some real good reading. From Lee at asgard.org Mon Dec 30 18:45:45 2013 From: Lee at asgard.org (Lee Howard) Date: Mon, 30 Dec 2013 13:45:45 -0500 Subject: turning on comcast v6 In-Reply-To: <0CC9EF26-1B77-4990-8B29-A55085ABE385@ufp.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <0CC9EF26-1B77-4990-8B29-A55085ABE385@ufp.org> Message-ID: On 12/30/13 11:19 AM, "Leo Bicknell" wrote: > >On Dec 24, 2013, at 8:15 AM, Lee Howard wrote: > >> Why? >> You say, "The protocol suite doesn't meet my needs; I need default >>gateway >> in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? > >Why must the people who want it justify to _you_? They don't; they have to justify it to the DHC WG at IETF, in order to generate consensus. > >This is fundamental part I've not gotten about the IPv6 crowd. IPv4 got >to >where it is by letting people extend it and develop new protocols and >solutions. >DHCP did not exist when IPv4 was created, it was tacked on later. Now >people want to tack something on to IPv6 to make it more useful to them. >Why do they need to explain it to you, if it doesn't affect your >deployments >at all? You can provision your network any way you like. If you want to create a custom version of DHCP (or your own provisioning protocol), that's fine. There doesn't seem to be consensus that default gateway in DHCP is a good idea. There's "running code" for how to change this. > >Some of us think the model where a DHCP server knows the subnet and hands >out >a default gateway provides operational advantages. It's an opinion. And >the >current IPv6 crowds view that not having a default route and relaying on >RA's >is better is also an opinion. > >We've spent years of wasted bits and oxygen on ONE STUPID FIELD IN DHCP. >Put >it in their, and let the market sort it out, unless you can justify some >dire >harm from doing so. I don't like the "let many flowers bloom" model of protocol development. You end up with a lot of cruft in protocols. Successful protocols tend not to have that (at least, when they become successful). I don't know if it will do harm (though it's easy to imagine DHCP not aligning with default gateways in modern, more mobile networks). But if the barrier for adding fields is "Eh, it probably won't cause dire harm" then we would have pretty messy protocols. > >What is more important fast IPv6 adoption or belittling people who want >to >deploy it in some slightly different way than you did? Did I belittle anybody? I apologize if I did that. It certainly was not my intent. I'm trying to understand a point of view. Lee > >-- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From rps at maine.edu Mon Dec 30 18:55:24 2013 From: rps at maine.edu (Ray Soucy) Date: Mon, 30 Dec 2013 13:55:24 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <01e201cf058b$679dedb0$36d9c910$@hathcock.org> Message-ID: On a side note, I've been involved with organizing the New England regional Collegiate Cyber-Defense Competition for a while, and one our "Red Team" members was able to make a pretty convincing IOS rootkit using IOS TCL scripting to mask configuration from the students. I don't think any students were able to detect it until word got out after it was used a few years in a row. IIRC, Cisco threatened to sue if it was ever released, so no it's not publicly available. It is possible, however. Don't assume that your routers are any safer than your servers. :-) On Mon, Dec 30, 2013 at 1:35 PM, shawn wilson wrote: > On Mon, Dec 30, 2013 at 1:17 PM, Lorell Hathcock > wrote: > > NANOG: > > > > Here's the really scary question for me. > > > > Would it be possible for NSA-payload traffic that originates on our > private > > networks that is destined for the NSA to go undetected by our IDS > systems? > > > > Yup. Absolutely. Without a doubt. > > > For example tcpdump-based IDS systems like Snort has been rooted to > ignore > > or not report packets going back to the NSA? Or netflow on Cisco devices > > not reporting NSA traffic? Or interface traffic counters discarding > > NSA-packets to report that there is no usage on the interface when in > fact > > there is? > > > > Do you detect 100% of malware in your IDS? Why would anyone need to do > anything with your IDS? Craft a PDF, DOC, Java, Flash, or anything > else that can run code that people download all the time with payload > of unknown signature. This isn't really a network discussion. This is > just to say - I seriously doubt there's anything wrong with your IDS - > don't skin a cat with a flame thrower, it just doesn't need to be that > hard. > > > Here's another question. What traffic do we look for on our networks > that > > would be going to the NSA? > > > > Standard https on port 443 maybe? That's how I'd send it. If you need > to send something bigger than normal, maybe compromise the email > server and have a few people send off some 5 - 10 meg messages? > Depends on your normal user base. If you've got a big, complex user > base, it's not hard to stay under the radar. Google 'Mandiant APT1' > for some real good reading. > > -- 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 Lee at asgard.org Mon Dec 30 18:58:17 2013 From: Lee at asgard.org (Lee Howard) Date: Mon, 30 Dec 2013 13:58:17 -0500 Subject: turning on comcast v6 In-Reply-To: <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> Message-ID: On 12/30/13 1:04 PM, "Ryan Harden" wrote: >On Dec 24, 2013, at 8:15 AM, Lee Howard wrote: > >>> default route information via DHCPv6. That's what I'm still waiting >>>for. >> >> Why? >> You say, "The protocol suite doesn't meet my needs; I need default >>gateway >> in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? >> >> Lee > >There are many places that wish to severely restrict or even block RA. >Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like >to do redirection based on MAC. Many are doing this with very short DHCP >leases that hand out different name servers and/or gateways until you >properly auth via $method. You might be able to do this with something >like RADVD, but when you have systems that have been doing this for IPv4 >for years, there?s little interest (read: budget) in rewriting everything >for IPv6. Thank you very much for presenting an actual use case. Seems like a dot1x kind of application, where the host is in a temporary VLAN until authenticated (etc.), right? Same use case, different network solution. > >'Rewrite all of your tools and change your long standing business >practices? is a very large barrier to entry to IPv6. If adding gateway as >an optional field will help people get over that barrier, why not add it? >Sure it doesn?t fit into the ?IPv6 way,? but bean counters don?t care >much for that when you have to ask for developer time to rewrite >everything. Well, the tools have to be rewritten to support IPv6 fields, sockets, and structures anyway. However, there's a difference between, "Make sure you call IP family agnostic libraries and increase field sizes, then let it run" and "Rebuild your network security." DHCP+RA just works in most networks; this is a use case where it could be made to work, but only by changing the network. As for "why not add it?" my answer is that if it's needed, we should add it. If it's not needed, we should not add it. "I want default gateway in DHCPv6" does not answer the question of whether it's needed, which is why I asked why. > > >Disclaimer: I don?t condone said methods and trickery mentioned above, >just pointing out their use. Will consider more. Lee > >/Ryan From randy at psg.com Mon Dec 30 19:09:52 2013 From: randy at psg.com (Randy Bush) Date: Mon, 30 Dec 2013 09:09:52 -1000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <01e201cf058b$679dedb0$36d9c910$@hathcock.org> Message-ID: > IIRC, Cisco threatened to sue if it was ever released you gotta love it. they will roll over and piss themselves for nsa and other who are violating every principle, but threaten paying customers who would report a hole. the question is what have these companies and gov people not violated? randy From admin at marcoteixeira.com Mon Dec 30 16:28:12 2013 From: admin at marcoteixeira.com (Marco Teixeira) Date: Mon, 30 Dec 2013 16:28:12 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131230161635.GA16611@ernw.de> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> Message-ID: Hi all, I've been watching this list for a couple weeks now and while risking beeing flamed, i just wanted to say that any network professional that puts any equipment into production without securing it against the kind of issues mentioned so far (cisco/cisco, snmp private, etc) is negligent and should be fired on the spot. These are not backdoor issues, NSA related, whatever... This is noise. Trying to get this thread on track, can the original poster provide any proof of this so called ability of the so called inteligence agency beeing able to access cisco/juniper, taking into account that management access has been correctly configured ? Regards -Marco --- Cumprimentos / Best regards Marco Teixeira email/gtalk/msn: admin at marcoteixeira.com skype: admin-marcoteixeira.com --- Did you know that Marco Teixeira is an independent, industry expert, senior consultant ? His expertise is available for hire. --- On Mon, Dec 30, 2013 at 4:16 PM, Enno Rey wrote: > On Mon, Dec 30, 2013 at 04:03:07PM +0000, Dobbins, Roland wrote: > > > > On Dec 30, 2013, at 10:44 PM, < > Valdis.Kletnieks at vt.edu> wrote: > > > > > What percentage of Cisco gear that supports a CALEA lawful intercept > mode is installed in situations where CALEA doesn't apply, and thus there's > a high likelyhood that said support is misconfigured and abusable without > being noticed? > > > > AFAIK, it must be explicitly enabled in order to be functional. It > isn't the sort of thing which is enabled by default, nor can it be enabled > without making explicit configuration changes. > > at least back in 2007 it could be enabled/configured by SNMP RW access > [see slide 43 of the presentation referenced in this post > http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] > so knowing the term "private" m > ight be enough to perform the task remotely. > > have a good one > > Enno > > > > > > > > ----------------------------------------------------------------------- > > Roland Dobbins // > > > > Luck is the residue of opportunity and design. > > > > -- John Milton > > > > > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: www.troopers.de > ======================================================= > > From hardenrm at uchicago.edu Mon Dec 30 19:20:25 2013 From: hardenrm at uchicago.edu (Ryan Harden) Date: Mon, 30 Dec 2013 19:20:25 +0000 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> Message-ID: <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> On Dec 30, 2013, at 12:58 PM, Lee Howard wrote: >> >> >> 'Rewrite all of your tools and change your long standing business >> practices? is a very large barrier to entry to IPv6. If adding gateway as >> an optional field will help people get over that barrier, why not add it? >> Sure it doesn?t fit into the ?IPv6 way,? but bean counters don?t care >> much for that when you have to ask for developer time to rewrite >> everything. > > > Well, the tools have to be rewritten to support IPv6 fields, sockets, and > structures anyway. However, there's a difference between, "Make sure you > call IP family agnostic libraries and increase field sizes, then let it > run" and "Rebuild your network security." DHCP+RA just works in most > networks; this is a use case where it could be made to work, but only by > changing the network. Updating tools to add a box for IPv6 fields and tweaking the backend to generate a config file for DHCPv6 which is very similar to DHCP(for v4) is a lot different/easier than having to rewrite and/or split your backend to generate output in a completely different format. However, I'm not as familiar with RADVD as I am with isc-dhcpd so that might be a bad argument. And you don't have to support IPv6 from top to bottom to roll out IPv6 to users. So rewriting for socket support isn't necessary day one. You can route IPv6 for users so they can reach the IPv6 world quickly, then add local services as time/money allows. The biggest driver for IPv6 will be external resources available only via IPv6, not local. (Of course this is from the point of view where your business' primary service isn't outward facing resources.) I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by fully dynamic DHCP, some who do DHCP-Reservations, and some who go static only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6 needs to be flexible enough to handle the fact that not everyone builds identical architectures nor do they have the exact same needs. Being able to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options. Forcing everyone down the same path will just lead to stupid proprietary solutions to a problem that shouldn't exist in the first place. /Ryan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From deleskie at gmail.com Mon Dec 30 19:54:59 2013 From: deleskie at gmail.com (jim deleskie) Date: Mon, 30 Dec 2013 15:54:59 -0400 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> Message-ID: There are many ways a backdoor could be used in a properly secured system. To think otherwise is a huge mistake. I can think of several ways, if tasked and given the resources of a large gov't that I would attack this problem. To assume that those tasked and focused only this type of solution aren't even more capable would be foolhardy. -jim On Mon, Dec 30, 2013 at 12:28 PM, Marco Teixeira wrote: > Hi all, > > I've been watching this list for a couple weeks now and while risking > beeing flamed, i just wanted to say that any network professional that puts > any equipment into production without securing it against the kind of > issues mentioned so far (cisco/cisco, snmp private, etc) is negligent and > should be fired on the spot. > > These are not backdoor issues, NSA related, whatever... This is noise. > Trying to get this thread on track, can the original poster provide any > proof of this so called ability of the so called inteligence agency beeing > able to access cisco/juniper, taking into account that management access > has been correctly configured ? > > Regards > > -Marco > > > --- > Cumprimentos / Best regards > > Marco Teixeira > email/gtalk/msn: admin at marcoteixeira.com > skype: admin-marcoteixeira.com > --- > Did you know that Marco Teixeira is an independent, industry expert, > senior > consultant ? His expertise is available for hire. > --- > > > On Mon, Dec 30, 2013 at 4:16 PM, Enno Rey wrote: > > > On Mon, Dec 30, 2013 at 04:03:07PM +0000, Dobbins, Roland wrote: > > > > > > On Dec 30, 2013, at 10:44 PM, < > > Valdis.Kletnieks at vt.edu> wrote: > > > > > > > What percentage of Cisco gear that supports a CALEA lawful intercept > > mode is installed in situations where CALEA doesn't apply, and thus > there's > > a high likelyhood that said support is misconfigured and abusable without > > being noticed? > > > > > > AFAIK, it must be explicitly enabled in order to be functional. It > > isn't the sort of thing which is enabled by default, nor can it be > enabled > > without making explicit configuration changes. > > > > at least back in 2007 it could be enabled/configured by SNMP RW access > > [see slide 43 of the presentation referenced in this post > > > http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/ > ] > > so knowing the term "private" m > > ight be enough to perform the task remotely. > > > > have a good one > > > > Enno > > > > > > > > > > > > > > ----------------------------------------------------------------------- > > > Roland Dobbins // > > > > > > Luck is the residue of opportunity and design. > > > > > > -- John Milton > > > > > > > > > > > -- > > Enno Rey > > > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > > > Handelsregister Mannheim: HRB 337135 > > Geschaeftsfuehrer: Enno Rey > > > > ======================================================= > > Blog: www.insinuator.net || Conference: www.troopers.de > > ======================================================= > > > > > From ikiris at gmail.com Mon Dec 30 20:19:27 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 30 Dec 2013 14:19:27 -0600 Subject: turning on comcast v6 In-Reply-To: <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> Message-ID: The better question is are you using RIP or ICMP to set gateways in your network now? If you don't use those now, why is RA a better solution in ipv6? -Blake On Mon, Dec 30, 2013 at 1:20 PM, Ryan Harden wrote: > On Dec 30, 2013, at 12:58 PM, Lee Howard wrote: > > >> > >> > >> 'Rewrite all of your tools and change your long standing business > >> practices? is a very large barrier to entry to IPv6. If adding gateway > as > >> an optional field will help people get over that barrier, why not add > it? > >> Sure it doesn?t fit into the ?IPv6 way,? but bean counters don?t care > >> much for that when you have to ask for developer time to rewrite > >> everything. > > > > > > Well, the tools have to be rewritten to support IPv6 fields, sockets, and > > structures anyway. However, there's a difference between, "Make sure you > > call IP family agnostic libraries and increase field sizes, then let it > > run" and "Rebuild your network security." DHCP+RA just works in most > > networks; this is a use case where it could be made to work, but only by > > changing the network. > > Updating tools to add a box for IPv6 fields and tweaking the backend to > generate a config file for DHCPv6 which is very similar to DHCP(for v4) is > a lot different/easier than having to rewrite and/or split your backend to > generate output in a completely different format. However, I'm not as > familiar with RADVD as I am with isc-dhcpd so that might be a bad argument. > > And you don't have to support IPv6 from top to bottom to roll out IPv6 to > users. So rewriting for socket support isn't necessary day one. You can > route IPv6 for users so they can reach the IPv6 world quickly, then add > local services as time/money allows. The biggest driver for IPv6 will be > external resources available only via IPv6, not local. (Of course this is > from the point of view where your business' primary service isn't outward > facing resources.) > > I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by > fully dynamic DHCP, some who do DHCP-Reservations, and some who go static > only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6 > needs to be flexible enough to handle the fact that not everyone builds > identical architectures nor do they have the exact same needs. Being able > to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options. > Forcing everyone down the same path will just lead to stupid proprietary > solutions to a problem that shouldn't exist in the first place. > > /Ryan > From Lee at asgard.org Mon Dec 30 20:32:39 2013 From: Lee at asgard.org (Lee Howard) Date: Mon, 30 Dec 2013 15:32:39 -0500 Subject: turning on comcast v6 In-Reply-To: <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> Message-ID: On 12/30/13 2:20 PM, "Ryan Harden" wrote: >On Dec 30, 2013, at 12:58 PM, Lee Howard wrote: > >>> >>> >>> 'Rewrite all of your tools and change your long standing business >>> practices? is a very large barrier to entry to IPv6. If adding gateway >>>as >>> an optional field will help people get over that barrier, why not add >>>it? >>> Sure it doesn?t fit into the ?IPv6 way,? but bean counters don?t care >>> much for that when you have to ask for developer time to rewrite >>> everything. >> >> >> Well, the tools have to be rewritten to support IPv6 fields, sockets, >>and >> structures anyway. However, there's a difference between, "Make sure >>you >> call IP family agnostic libraries and increase field sizes, then let it >> run" and "Rebuild your network security." DHCP+RA just works in most >> networks; this is a use case where it could be made to work, but only by >> changing the network. > >Updating tools to add a box for IPv6 fields and tweaking the backend to >generate a config file for DHCPv6 which is very similar to DHCP(for v4) >is a lot different/easier than having to rewrite and/or split your >backend to generate output in a completely different format. However, I'm >not as familiar with RADVD as I am with isc-dhcpd so that might be a bad >argument. > >And you don't have to support IPv6 from top to bottom to roll out IPv6 to >users. So rewriting for socket support isn't necessary day one. You can >route IPv6 for users so they can reach the IPv6 world quickly, then add >local services as time/money allows. The biggest driver for IPv6 will be >external resources available only via IPv6, not local. (Of course this is >from the point of view where your business' primary service isn't outward >facing resources.) I agree with you on the above, I just didn't say so very well. > >I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by >fully dynamic DHCP, some who do DHCP-Reservations, and some who go static >only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6 >needs to be flexible enough to handle the fact that not everyone builds >identical architectures nor do they have the exact same needs. Being able >to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options. >Forcing everyone down the same path will just lead to stupid proprietary >solutions to a problem that shouldn't exist in the first place. All of those cases work just as well with DHCP+RA. Only in cases where a router on a subnet is not the correct gateway is RA a problem, AFAIK. You gave one example where that's the case. Another would be where there are two gateways for the same network segment, which don't share an IP address, and you want DHCP to tell hosts which one they should use (rather than, say, manual configuration or GPO). DHCP and RAs do different things. DHCP does host configuration. Router Advertisements advertise routers. When you have both, you can leave off a field in DHCP, and rely on the network to route the packets. Turning off RAs and putting that information into DHCP for each subnet you manage means additional work. It's not a lot of work, admittedly. Lee > >/Ryan From Lee at asgard.org Mon Dec 30 20:49:09 2013 From: Lee at asgard.org (Lee Howard) Date: Mon, 30 Dec 2013 15:49:09 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> Message-ID: I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing. From: Blake Dunlap Date: Monday, December 30, 2013 3:19 PM To: Ryan Harden Cc: Lee Howard , Jamie Bowden , "nanog at nanog.org" Subject: Re: turning on comcast v6 > The better question is are you using RIP or ICMP to set gateways in your > network now? I disagree that that's a better question. I'm not using RIP because my hosts don't support it (at least, not without additional configuration), and it would be a very unusual configuration, adding weight and complexity for no benefit. RAs are the opposite. Not even sure how you would use ICMP to set a default gateway. Maybe there's a field I'm unaware of. > > > If you don't use those now, why is RA a better solution in ipv6? It's built into the fundamentals of IPv6, using the Neighbor Discovery Protocol. It's supported in every stack. It's the default mode of operation. To turn it off, you have to disable part, but not all, of NDP. (Do you also turn off RSs on all hosts?) There could be better solutions; I would like to understand how they are better. Again, in your network, you can do whatever you want. If you want something different standardized, then you need consensus here: https://www.ietf.org/mailman/listinfo/dhcwg Lee From randy at psg.com Mon Dec 30 20:57:42 2013 From: randy at psg.com (Randy Bush) Date: Mon, 30 Dec 2013 10:57:42 -1000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> Message-ID: > These are not backdoor issues, NSA related, whatever... This is noise. > Trying to get this thread on track, can the original poster provide any > proof of this so called ability of the so called inteligence agency beeing > able to access cisco/juniper, taking into account that management access > has been correctly configured ? since you don't seem to read the articles, perhaps an info-graphic http://www.spiegel.de/international/world/a-941262.html randy From ckossmey at cisco.com Mon Dec 30 21:18:41 2013 From: ckossmey at cisco.com (Clay Kossmeyer) Date: Mon, 30 Dec 2013 16:18:41 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches Message-ID: Hi Folks - Clay Kossmeyer here from the Cisco PSIRT. We've published the following document in response to the original (Dec. 29) Der Spiegel article: http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel and are investing the claims in the Dec. 30 Der Spiegel article referencing 'persistent implants' for the PIX and ASA product lines under case number PSIRT-1384943056. Any vulnerabilities we discover will be disclosed via our standard vulnerability handling process documented here: http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html I'm not currently subscribed to NANOG, so if you have a reply you'd like me to see, please copy me directly. Regards, Clay ----- Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx Regards, Steven. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 204 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Mon Dec 30 21:43:16 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Dec 2013 13:43:16 -0800 Subject: turning on comcast v6 In-Reply-To: <0CC9EF26-1B77-4990-8B29-A55085ABE385@ufp.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <0CC9EF26-1B77-4990-8B29-A55085ABE385@ufp.org> Message-ID: On Dec 30, 2013, at 8:19 AM, Leo Bicknell wrote: > > On Dec 24, 2013, at 8:15 AM, Lee Howard wrote: > >> Why? >> You say, "The protocol suite doesn't meet my needs; I need default gateway >> in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? > > Why must the people who want it justify to _you_? In a consensus process, it is not unusual or uncommon for the group to expect a justification for a topic seeking consensus. > This is fundamental part I've not gotten about the IPv6 crowd. IPv4 got to > where it is by letting people extend it and develop new protocols and solutions. > DHCP did not exist when IPv4 was created, it was tacked on later. Now > people want to tack something on to IPv6 to make it more useful to them. > Why do they need to explain it to you, if it doesn't affect your deployments > at all? To the best of my knowledge, those same questions have been asked about all of the IPv4 protocols in the IETF development process, too. If he wants to just go mod his DHCP daemons, he?s welcome to do that. If he wants IETF consensus around a change to the DHCP protocol, then it?s not at all unreasonable for him to have to justify that position to the IETF. > Some of us think the model where a DHCP server knows the subnet and hands out > a default gateway provides operational advantages. It's an opinion. And the > current IPv6 crowds view that not having a default route and relaying on RA's > is better is also an opinion. Sure, but here?s where you break down? The current situation isn?t attributable to ?the current IPv6 crowd? (whoever that is), it?s the current IETF consensus position. Changing that IETF consensus position is a matter of going through the IETF process and getting a new consensus. That requires justifying your position and convincing enough people willing to actively participate in the working group process of that position. I like to think that I would be part of almost any valid definition of ?the current IPv6 crowd?. While I do think that RAs are a better mechanism for most situations, I also support the inclusion of information equivalent to RIOs in DHCP options. > We've spent years of wasted bits and oxygen on ONE STUPID FIELD IN DHCP. Put > it in their, and let the market sort it out, unless you can justify some dire > harm from doing so. It shouldn?t be one stupid field, even if we do put it in. It should be an additional option for providing zero or more RIOs. > What is more important fast IPv6 adoption or belittling people who want to > deploy it in some slightly different way than you did? I do not think it is legitimate to say that asking for justification for a position is belittling. Owen From owen at delong.com Mon Dec 30 21:49:29 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Dec 2013 13:49:29 -0800 Subject: turning on comcast v6 In-Reply-To: <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> Message-ID: On Dec 30, 2013, at 10:04 AM, Ryan Harden wrote: > On Dec 24, 2013, at 8:15 AM, Lee Howard wrote: > >>> default route information via DHCPv6. That's what I'm still waiting for. >> >> Why? >> You say, "The protocol suite doesn't meet my needs; I need default gateway >> in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? >> >> Lee > > There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there?s little interest (read: budget) in rewriting everything for IPv6. > While I do not oppose the inclusion of Routing Information into DHCPv6, I have to say that this seems to be one of the weaker arguments. Please permit me to repeat your statement from an IPv6 perspective? Because many places have poorly thought out cruft that deals with deficiencies in IPv4 by doing stunts that won?t work in the current IPv6 implementation and because we don?t want to rewrite our cruft to take advantage of the cleaner solutions available for these problems in IPv6, we demand that you include the cruft from IPv4 into IPv6 in order to support this hackery. > 'Rewrite all of your tools and change your long standing business practices? is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn?t fit into the ?IPv6 way,? but bean counters don?t care much for that when you have to ask for developer time to rewrite everything. You have to rewrite all your tools to handle the bigger addresses anyway. While you?re at it, why not rewrite them to take advantage of cleaner solutions? > Disclaimer: I don?t condone said methods and trickery mentioned above, just pointing out their use. So you?re defending a position you don?t share? Interesting tactic. Owen From victor at jvknet.com Mon Dec 30 22:37:48 2013 From: victor at jvknet.com (Victor Kuarsingh) Date: Mon, 30 Dec 2013 17:37:48 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> Message-ID: On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard wrote: > I'm not really an advocate for or against DHCP or RAs. I really just want > to understand what feature is missing. > > From: Blake Dunlap > Date: Monday, December 30, 2013 3:19 PM > To: Ryan Harden > Cc: Lee Howard , Jamie Bowden , > "nanog at nanog.org" > Subject: Re: turning on comcast v6 > > > The better question is are you using RIP or ICMP to set gateways in your > > network now? > > I disagree that that's a better question. > I'm not using RIP because my hosts don't support it (at least, not without > additional configuration), and it would be a very unusual configuration, > adding weight and complexity for no benefit. RAs are the opposite. > Not even sure how you would use ICMP to set a default gateway. Maybe > there's a field I'm unaware of. > [VK] The RIP comparison is somewhat confusing to me. I don't see how RIP is comparable in this context (I guess technically you can pass a default route in RIP, but as Lee mentions, the protocol is designed for a different purpose and requires configuration). I guess the ICMP reference fair as Neighbor Discovery is built on ICMP (which is a good thing in my opinion). Perhaps the reference here was to people not using RFC1256 in their networks? > > > > > > > If you don't use those now, why is RA a better solution in ipv6? > > It's built into the fundamentals of IPv6, using the Neighbor Discovery > Protocol. It's supported in every stack. It's the default mode of > operation. To turn it off, you have to disable part, but not all, of NDP. > (Do you also turn off RSs on all hosts?) > > [VK] Although I think there may be a valid case presented for an Option, I agree with Lee with the point that Neighbor Discovery is already built-in so it has operational benefits in that respect. There are many IPv6 deployments out there today in both ISPs and Enterprises, where ND/RAs are being used - this may or may not make RAs "better" then a potential DHCPv6 router option, but we know it (RA method) works in real networks using IPv6. As for a DHCPv6 router option case being made, if there a good reason and technical merit, that should be made to the DHC WG, or perhaps even made at a v6ops ops meeting and the advocate should make note of points made in draft-ietf-dhc-option-guidelines. Changes/updates to DHCPv6 have been made (as with RFC7083) when the problem can be stated with technical merit and people are willing to work on it. regards, Victor K From randy at psg.com Mon Dec 30 22:51:38 2013 From: randy at psg.com (Randy Bush) Date: Mon, 30 Dec 2013 12:51:38 -1000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: Message-ID: > Clay Kossmeyer here from the Cisco PSIRT. shoveling kitty litter as fast as you can, eh? > http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel "The article does not discuss or disclose any Cisco product vulnerabilities." this is disengenuous at best. from the nsa document copied in der spiegel and now many other places: "JETPLOW is a firmware persistence implant for Cisco PIX series and ASA firewalls ..." so in cisco kitty litter lingo, what would be "discuss[ing] or disclos[ing] any Cisco product vulnerabilities? the exploit code itself? randy From sabri at cluecentral.net Mon Dec 30 23:03:37 2013 From: sabri at cluecentral.net (Sabri Berisha) Date: Mon, 30 Dec 2013 15:03:37 -0800 (PST) Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <01e201cf058b$679dedb0$36d9c910$@hathcock.org> Message-ID: <1709517146.809.1388444617204.JavaMail.zimbra@cluecentral.net> Hi, > you gotta love it. they will roll over and piss themselves for nsa and > other who are violating every principle, but threaten paying customers > who would report a hole. Don't forget that for C and J, the U.S. government is a large customer as well. Thanks, Sabri From bicknell at ufp.org Mon Dec 30 23:09:48 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 30 Dec 2013 17:09:48 -0600 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <0CC9EF26-1B77-4990-8B29-A55085ABE385@ufp.org> Message-ID: On Dec 30, 2013, at 3:43 PM, Owen DeLong wrote: > The current situation isn?t attributable to ?the current IPv6 crowd? (whoever that is), it?s the current IETF consensus position. Changing that IETF consensus position is a matter of going through the IETF process and getting a new consensus. That requires justifying your position and convincing enough people willing to actively participate in the working group process of that position. Some of us tried to engage the IETF on this topic in multiple working groups. If you search the archives you'll find this topic has come up before. I would charitably describe the environment there as "hostile" to anyone who has not been inside the IEFT machine for the last 15 years. And that's assuming the working group is "working", there are plenty inside the IEFT that are extremely dysfunctional even when the people on them "agree". It's not enough to tell a bunch of enterprise people who have never dealt with the IETF before that they should go there are plead their case. Most do not know how, and the few who try find themselves berated by that community for being ignorant of the "way things should be". What the enterprise folks need is IPv6 champions, like yourself, like Lee, to user stand their use case that even if you don't end up deploying it on your own network you will show up at the IETF, or at least participate on the IETF mailing lists and help them get what they need, so IPv6 deployment can proceed apace. If you really don't think there is harm, help them go get what they (think they?) need. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bicknell at ufp.org Mon Dec 30 23:24:54 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 30 Dec 2013 17:24:54 -0600 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> Message-ID: <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> On Dec 30, 2013, at 2:49 PM, Lee Howard wrote: > I'm not really an advocate for or against DHCP or RAs. I really just want > to understand what feature is missing. I encourage you to try this simple experiment in your lab, because this happens all day long on corporate networks around the world, and illustrates the differences quite nicely. While not a complete treatment of the operational differences, it's an important illustration. Configure up a simple network topology of three boxes representing a hub and spoke network: DHCP SVR | --lan--r1--wan--hubrtr--wan--r2--lan Number it up as expected for both protocols: wan links: IPv4 /30, IPv6 /64 lan links: IPv4 /24, IPv6 /64 Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests to it. Verify a machine plugged into either of the LANs gets a fully functional network for both protocols. Now, take r1 turn it off, and stick it in a closet. You see, that office closed. Normal every day thing. Plug up two PC's to the remaining LAN off r2. This represents your desktop, and your neighbors desktop. Think Bob from accounting perhaps. Open two windows on each, one with an IPv4 ping, one with an IPv6 ping running. Now, boss man comes in and has a new office opening up. Go grab the r1 box out of the closet, you need to upgrade the code and reconfigure it. Cable it up to your PC with a serial port, open some some sort of terminal program so you can catch the boot and password recover it. Plug it's ethernet into your lan, as you're going to need to tftp down new config, and turn it on. Here's what you will soon find: 1) The IPv6 pings on both machines cease to work. 2) The IPv4 network continues to work just fine. Now, for even more fun, turn on another PC, say Sally from HR just rebooted her machine. It will come up in the same state, IPv6 not working, while IPv4 works just fine. Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are now complaining to him that their network is down, again. Make sure you not only understand the technical nuances of why the problem above happened, but also how to explain them to a totally non-technical CEO. (Oh yeah, go ahead and unplug r1 to "fix" the problem, and observe how long until the pings start working again. I think it's 15 minutes, IIRC. For super-extra credit tell me how to make that time shorter for everyone on the LAN with Cisco or Juniper commands on r2.) I'll give you a hint on understanding this issue. The IETF's grand solution is to replace every ethernet switch in your entire network with new hardware that supports "RA Guard", and then deploy new configuration on every single port of every single device in your network. Please develop a capital justification plan for Mr MoneyBagsCEO for replacing every switch in your network so you can safely deploy IPv6. Now do you understand why people just want to put the route in DHCPv6 and move on? It's not a "feature" that's different between the two, it's that operationally they have entirely different attack surfaces and failure modes. And yes, it involves people doing stupid things. However if the IETF is going to rely on smart people deploying networking devices we might as well give up and go home now. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bicknell at ufp.org Mon Dec 30 23:31:37 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 30 Dec 2013 17:31:37 -0600 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> Message-ID: On Dec 30, 2013, at 4:37 PM, Victor Kuarsingh wrote: > On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard wrote: >>> The better question is are you using RIP or ICMP to set gateways in your >>> network now? >> >> I disagree that that's a better question. >> I'm not using RIP because my hosts don't support it (at least, not without >> additional configuration), and it would be a very unusual configuration, >> adding weight and complexity for no benefit. RAs are the opposite. >> Not even sure how you would use ICMP to set a default gateway. Maybe >> there's a field I'm unaware of. >> > > [VK] The RIP comparison is somewhat confusing to me. I don't see how RIP > is comparable in this context (I guess technically you can pass a default > route in RIP, but as Lee mentions, the protocol is designed for a different > purpose and requires configuration). There was a time, I'm going to roughly guess approximately 1987-1992, although I may be off by a year or two, that you needed to have lived through for this to make sense. You see, in that time the available IGP was, well, RIP. RIPv1. Routers, at least ones you could buy, did not have OSPF, EIGRP, or even in many cases EGP/BGP. They had RIPv1, and perhaps some bleeding edge Cisco's had IGRP. So almost every campus network ran RIPv1. This is also pre-CIDR, so remember every subnet had to have the same mask. For instance the University I went to had a /16, divided into entirely /22 networks for each LAN. The RIP config enabled it for the entire /16. Certain vendors, like Sun (who was popular at the time) shipped SunOS boxes with routed enabled by default, where they received a default route (if the admins filtered) or a full (local) table via RIPv1. In short, there was a time when getting a default route via RIP was in fact common. It was also the time of telnet, and rsh, decidedly pre SSL, ssh, or IPSEC. It was also a time when the Internet came under heavy, well, attack, by people who realized how soft and squishy it was. Injecting a route into RIP allowed you to hijack rsh sessions, for example. Lots of people who were admins at that time learned through personal pain and late night hacking that sending a dynamic route to a box via an unauthenticated protocol was a recipe for disaster. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mysidia at gmail.com Mon Dec 30 23:42:33 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 30 Dec 2013 17:42:33 -0600 Subject: The state of TACACS+ In-Reply-To: <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> Message-ID: On Mon, Dec 30, 2013 at 8:11 AM, Javier Henderson wrote: > Given the problem of remote auth; the restriction of choice of protocols is dictated by what protocols the relying party device supports. This is the problem: You are at the mercy of your router vendor, to support the authentication protocol functionality. Things are workable, but in a sad state. Obviously, providing highly robust, highly secure remote authentication, is not a high priority among the router vendors. They pay lip service to the whole thing. In many cases you might be better off with local auth. How do you feel about having to wait 30 seconds between every command you enter to troubleshoot, to fail to the second server, if the TACACS or RADIUS system is nonresponsive, because the dumb router can't remember which TACACS servers are up and which ones are down, and always tries the first one in the list first? At least RADIUS has the concept of a "dead timer" :) By all rights; routers should be implementing authorization using LDAP over TLS, with a locally cached persistent copy of the directory and credentials (so users can still log in, and their command exec rights cached, in case of network outages).. and authentication with either user SSH public key published in LDAP, Kerberos/GSSAPI with Smartcard and other 2factor auth/OTP support, or LDAP BIND using SASL. RADIUS and TACACS+ are what you get, because they've been there forever, and frequently enough deemed "good enough". Some routers have limited Kerberos support; although, usually, not support for Kerberos ticket forwarding SPNEGO / Negotiate authentication using GSSAPI over SSH. (Over encrypted Telnet, Yes) RADIUS and TACACS+, without IPSEC or TLS encapsulation of all the traffic are both highly insecure by today's standards, and in theory should not be used. Unfortunately; on many network devices, these are your only native central authentication options! Fallback plan: The network should be designed so such connections are not allowed to cross an untrusted Layer 2 domain. If an attacker can sniff auth traffic --- TACACS+ is particularly susceptible to decryption of the entire session including user credentials, whereas RADIUS is particularly susceptible to the possibility of authentication replay. Depending on the router vendor; the available functionality with each protocol, varies..... Cisco is most noted for providing rich functionality over TACACS+ for shell authorization and accounting, and providing very limited RADIUS support. It is not that RADIUS is limited --- its that your device vendor's RADIUS featureset is limited -- which, for all intents and purposes, means, the features available to you are more limited, if you use such gear. > On Dec 30, 2013, at 9:01 AM, Christian Kratzer wrote: > > Hi, > > it is with radius afaik ... > RADIUS does not support command authorization or accounting. > RADIUS protocol supports accounting; and there is no reason RADIUS start-stop accounting events cannot be sent for every shell command --- this is not a protocol limitation, this is a device implementation limitation. Some devices can provide per-command authorization by embedding the command being run in an Access-Request. RADIUS protocol response messages can encapsulate any attribute-value pair that can be sent in a TACACS response. using Vendor-specific attributes. There is a restriction on IOS devices, that arbitrarily forbids certain vendor-specific Attribute-value pairs from being encapsulated in the RADIUS reply message; per-command authorization is among prevented software capabilities of the router, not a limitation of the RADIUS protocol. http://wiki.freeradius.org/vendor/Cisco#Command-Authorization ' cisco-avpair = "shell:cmd=show" would do the trick to authorize the "show" command. except that there is a tiny note for the commands "cmd" and "cmd-arg" saying that they cannot be used for encapsulation in the Vendor-Specific space. These two are the ONLY ones.' > -jav > -- -JH From javier at kjsl.org Tue Dec 31 00:05:04 2013 From: javier at kjsl.org (Javier Henderson) Date: Mon, 30 Dec 2013 19:05:04 -0500 Subject: The state of TACACS+ In-Reply-To: References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> Message-ID: <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> On Dec 30, 2013, at 6:42 PM, Jimmy Hess wrote: > How do you feel about having to wait 30 seconds between every command you enter to troubleshoot, to fail to the second server, if the TACACS or RADIUS system is nonresponsive, because the dumb router can't remember which TACACS servers are up and which ones are down, and always tries the first one in the list first? At least RADIUS has the concept of a "dead timer" :) Are you talking about Cisco routers? The default timeout value for TACACS+ is five seconds, so I?m not sure where you?re coming up with thirty seconds, unless you have seven servers listed on the router and the first six are dead/unreachable. -jav From faust at grift.com Mon Dec 30 23:46:06 2013 From: faust at grift.com (Sharif Torpis) Date: Mon, 30 Dec 2013 16:46:06 -0700 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: Message-ID: <52C205BE.4040409@grift.com> On 12/30/2013 3:51 PM, Randy Bush wrote: >> Clay Kossmeyer here from the Cisco PSIRT. > > shoveling kitty litter as fast as you can, eh? > >> http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel > > "The article does not discuss or disclose any Cisco product vulnerabilities." > > this is disengenuous at best. from the nsa document copied in der > spiegel and now many other places: > > "JETPLOW is a firmware persistence implant for Cisco PIX series and > ASA firewalls ..." > > so in cisco kitty litter lingo, what would be "discuss[ing] or > disclos[ing] any Cisco product vulnerabilities? the exploit code > itself? > > randy > What is the vulnerability in Cisco product Randy? That a 3rd party can replace the firmware in your firewall? There isn't enough information to determine if this is a software vulnerability triggered with exploit code or wholesale firmware replacement. The document refers to an implant but not how it gets there. -- "The first rule of any game is to know that you're in one." -Sandy Lerner, co-founder, Cisco Systems From mysidia at gmail.com Tue Dec 31 00:28:44 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 30 Dec 2013 18:28:44 -0600 Subject: The state of TACACS+ In-Reply-To: <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> References: <52C145B8.7040101@direcpath.com> <20131230112842.GA25340@pob.ytti.fi> <07A7C156-CA0B-4987-837C-C9F5CC11E990@kjsl.org> <2BFFCCA1-9110-47C2-A8EF-C3D81802016E@kjsl.org> Message-ID: On Mon, Dec 30, 2013 at 6:05 PM, Javier Henderson wrote: > > Are you talking about Cisco routers? The default timeout value for TACACS+ > is five seconds, so I?m not sure where you?re coming up with thirty > seconds, unless you have seven servers listed on the router and the first > six are dead/unreachable. > Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously.... this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The "response timeout" might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) -jav > -- -JH From owen at delong.com Tue Dec 31 00:51:24 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Dec 2013 16:51:24 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <0CC9EF26-1B77-4990-8B29-A55085ABE385@ufp.org> Message-ID: > What the enterprise folks need is IPv6 champions, like yourself, like Lee, to user stand their use case that even if you don't end up deploying it on your own network you will show up at the IETF, or at least participate on the IETF mailing lists and help them get what they need, so IPv6 deployment can proceed apace. If you really don't think there is harm, help them go get what they (think they?) need. I don?t think there?s harm to including the option for RIO in DHCPv6. I think there is great harm in continuing the use case presented earlier. I have yet to see a use case from enterprise that actually requires RIO or default route in DHCPv6, and I have seen many many use cases. Most of them are, actually, better solved through education, so I tend to focus my efforts in that area. If you can find someone who wants to pay me to plead the enterprise cases to the IETF, I suppose I might be interested in that job if it came with the right offer, but for now, that?s not what I get paid to do. Owen From owen at delong.com Tue Dec 31 00:56:42 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Dec 2013 16:56:42 -0800 Subject: turning on comcast v6 In-Reply-To: <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> Message-ID: <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> You can accomplish the same thing in IPv4?. Plug in Sally?s PC with Internet Connection Sharing turned on and watch as her DHCP server takes over your network. Yes, you have to pay attention when you plug in a router just like you?d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. Incompetence in execution really isn?t the protocol?s fault. Owen On Dec 30, 2013, at 3:24 PM, Leo Bicknell wrote: > > On Dec 30, 2013, at 2:49 PM, Lee Howard wrote: > >> I'm not really an advocate for or against DHCP or RAs. I really just want >> to understand what feature is missing. > > I encourage you to try this simple experiment in your lab, because this > happens all day long on corporate networks around the world, and > illustrates the differences quite nicely. While not a complete treatment > of the operational differences, it's an important illustration. > > Configure up a simple network topology of three boxes representing a hub > and spoke network: > > DHCP SVR > | > --lan--r1--wan--hubrtr--wan--r2--lan > > Number it up as expected for both protocols: > > wan links: IPv4 /30, IPv6 /64 > lan links: IPv4 /24, IPv6 /64 > > Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests > to it. Verify a machine plugged into either of the LANs gets a fully > functional network for both protocols. > > Now, take r1 turn it off, and stick it in a closet. You see, that office > closed. Normal every day thing. > > Plug up two PC's to the remaining LAN off r2. This represents your desktop, > and your neighbors desktop. Think Bob from accounting perhaps. Open two > windows on each, one with an IPv4 ping, one with an IPv6 ping running. > > Now, boss man comes in and has a new office opening up. Go grab the r1 box > out of the closet, you need to upgrade the code and reconfigure it. Cable > it up to your PC with a serial port, open some some sort of terminal program > so you can catch the boot and password recover it. Plug it's ethernet into > your lan, as you're going to need to tftp down new config, and turn it on. > > Here's what you will soon find: > > 1) The IPv6 pings on both machines cease to work. > > 2) The IPv4 network continues to work just fine. > > Now, for even more fun, turn on another PC, say Sally from HR just rebooted > her machine. It will come up in the same state, IPv6 not working, while > IPv4 works just fine. > > Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are > now complaining to him that their network is down, again. Make sure you > not only understand the technical nuances of why the problem above happened, > but also how to explain them to a totally non-technical CEO. > > (Oh yeah, go ahead and unplug r1 to "fix" the problem, and observe how long > until the pings start working again. I think it's 15 minutes, IIRC. For > super-extra credit tell me how to make that time shorter for everyone on > the LAN with Cisco or Juniper commands on r2.) > > I'll give you a hint on understanding this issue. The IETF's grand > solution is to replace every ethernet switch in your entire network > with new hardware that supports "RA Guard", and then deploy new configuration > on every single port of every single device in your network. Please > develop a capital justification plan for Mr MoneyBagsCEO for replacing > every switch in your network so you can safely deploy IPv6. > > Now do you understand why people just want to put the route in DHCPv6 and > move on? > > It's not a "feature" that's different between the two, it's that operationally > they have entirely different attack surfaces and failure modes. And yes, > it involves people doing stupid things. However if the IETF is going to > rely on smart people deploying networking devices we might as well give up > and go home now. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > From jared at puck.nether.net Tue Dec 31 01:05:10 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 30 Dec 2013 20:05:10 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <0CC9EF26-1B77-4990-8B29-A55085ABE385@ufp.org> Message-ID: <8390744D-0A76-4CAC-9520-2EF48C51C668@puck.nether.net> On Dec 30, 2013, at 7:51 PM, Owen DeLong wrote: > I have yet to see a use case from enterprise that actually requires RIO or default route in DHCPv6, and I have seen many many use cases. > > Most of them are, actually, better solved through education, so I tend to focus my efforts in that area. > > If you can find someone who wants to pay me to plead the enterprise cases to the IETF, I suppose I might be interested in that job if it came with the right offer, but for now, that?s not what I get paid to do. The kinky layer-2 stuff I've seen some places do tells me they won't be able to deploy IPv6 without it. I think the key here is "feature parity" and the whole "96 more bits no magic" aspect. The option is low hanging fruit to solve a problem. Perhaps it's just a conceptual problem (eg: DHCPv4 gives me option #4. I should have a comparable option# in IPv6!). While I may not need option #37 (or folks may not use it), sending a RS in addition to DHCPv6 request is two steps in host configuration, whereas one should be able to suffice (perhaps). It's also about authorization though, I could get a RA back from the RS from an unexpected (rogue) device in the same way I could see a rogue DHCP response as well. I have logging on my DHCP server, but I don't have that capability from a RA/RS stance. One is central (but perhaps relayed), the other is local (and never relayed). Seems a lot of emails over something simple that's not much creep and just "parity". (enjoy other great options here: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options .. I need my quotes server for IPv6 via DHCPv6 too). - Jared From bicknell at ufp.org Tue Dec 31 01:16:04 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 30 Dec 2013 19:16:04 -0600 Subject: turning on comcast v6 In-Reply-To: <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> Message-ID: On Dec 30, 2013, at 6:56 PM, Owen DeLong wrote: > You can accomplish the same thing in IPv4?. > > Plug in Sally?s PC with Internet Connection Sharing turned on and watch as her > DHCP server takes over your network. No, the failure mode is still different. With IPv6 RA's, the rouge router breaks all hosts on the LAN with a single broadcast. With a rogue DHCP server no currently working clients will stop working. In fact many will do directed renews, and never notice said rogue server. It is only a freshly booted host that might be captured by a rogue DHCP server. In a corporate environment the difference between one user getting a rogue DHCP server, being down, and asking for troubleshooting, and taking out an entire department/floor/office is enormous. > Yes, you have to pay attention when you plug in a router just like you?d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. > > Incompetence in execution really isn?t the protocol?s fault. We can't work around incompetent admins. Even the best humans goof from time to time. What we can do is design protocols that are robust, or not in the face of stupidity and accident. I should tell you about the time rogue RA's took down a data center network because in the middle of the night the tech I was talking to couldn't tell if I said port "fifteen" or port "fifty" over the phone, and thus plugged the router into the wrong network taking down several hundred hosts. The IPv4 side was fine for the 30 seconds or so until we straightened it out. There's a reason why there's huge efforts to put RA guard in switches, and do cryptographic RA's. These are two admissions that the status quo does not work for many folks, but for some reason these two solutions get pushed over a simple DHCP router assignment option. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rdobbins at arbor.net Tue Dec 31 02:00:17 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 02:00:17 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> Message-ID: <60635576-6455-4457-AC1E-158B40135727@arbor.net> On Dec 30, 2013, at 11:28 PM, Marco Teixeira wrote: > i just wanted to say that any network professional that puts any equipment into production without securing it against the kind of > issues mentioned so far (cisco/cisco, snmp private, etc) is negligent and should be fired on the spot. Yes, but keep in mind that with near-infinite resources, one can go after internal machines used by network operations personnel, etc. There are multiple things that network operators can and should do to prevent direct unauthorized configuration, to prevent tampering with configuration-management systems, to securing jump-off boxes, to implementing AAA with per-command auth and logging, to monitoring for config changes, etc. Unfortunately, many network operators don't do all these various things, and so it's quite possible for an organization with time and resources to attack via a side-channel. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Dec 31 02:05:08 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 02:05:08 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> Message-ID: <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> On Dec 31, 2013, at 12:00 AM, Ray Soucy wrote: > So this isn't an issue of the NSA working with Cisco and Juniper to include back doors, it's an issue of the NSA modifying those releases after the fact though BIOS implants. Yes, I see this now, thanks. AFAICT, the Cisco boxes listed are ASAs and PIXes, which are essentially Linux PCs running a bunch of userland firewall stuff and which have BIOSes and so forth; they aren't routers/switches. I don't know much about Juniper gear, but it appears that the Juniper boxes listed are similar in nature, albeit running FreeBSD underneath (correction welcome). I know nothing at all about Huawei gear. Compromising PCs with persistent malware/rootkits is pretty routine, so this isn't really surprising, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jeff-kell at utc.edu Tue Dec 31 02:05:47 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 30 Dec 2013 21:05:47 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> Message-ID: <52C2267B.3070807@utc.edu> On 12/30/2013 8:16 PM, Leo Bicknell wrote: > There's a reason why there's huge efforts to put RA guard in switches, and do cryptographic RA's. These are two admissions that the status quo does not work for many folks, but for some reason these two solutions get pushed over a simple DHCP router assignment option. The more disturbing "feature" for those that have been there, done that, debugged the meltdown, and tried to avoid repeating the issue is the growing proliferation of "automatic" discovery/configuration... whether RA / SLAAC / mDNS / Bonjour / uPnP / (the list goes on...). There are too many opportunities for spoofing / MITM / self-propagating "issues". Yes, DHCP is prone to similar issues, but better to focus on "one" service and "one" authoritative source to try to lock down than to try to protect the plethora of growing options to introduce issues from arbitrary sources. But as the market focus appears to continue to try to address the home / SOHO environment of naive users, the "self-configuration" nastiness continues to propagate. It may fit at home / SOHO, but not in the Enterprise, and certainly not in a university environment where you can't be as "restrictive" on a universal basis as you might like to be :( Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Tue Dec 31 02:41:46 2013 From: randy at psg.com (Randy Bush) Date: Mon, 30 Dec 2013 16:41:46 -1000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> Message-ID: >> So this isn't an issue of the NSA working with Cisco and Juniper to >> include back doors, it's an issue of the NSA modifying those releases >> after the fact though BIOS implants. > > Yes, I see this now, thanks. > > AFAICT, the Cisco boxes listed are ASAs and PIXes, which are > essentially Linux PCs running a bunch of userland firewall stuff and > which have BIOSes and so forth; they aren't routers/switches. you may want to read the more complete, well let's say extensive http://leaksource.wordpress.com/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/ From rdobbins at arbor.net Tue Dec 31 02:54:27 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 02:54:27 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> Message-ID: On Dec 31, 2013, at 9:41 AM, Randy Bush wrote: > you may want to read the more complete, well let's say extensive Thanks, Randy - now I see the JunOS stuff in there for J-series and M-series. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From ikiris at gmail.com Tue Dec 31 03:16:17 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 30 Dec 2013 21:16:17 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> Message-ID: The cynic in me says that cisco switch/router gear isn't part of that report on clandestine backdoors, because they don't need said clandestine backdoors to access them... -Blake On Mon, Dec 30, 2013 at 8:54 PM, Dobbins, Roland wrote: > > On Dec 31, 2013, at 9:41 AM, Randy Bush wrote: > > > you may want to read the more complete, well let's say extensive > > Thanks, Randy - now I see the JunOS stuff in there for J-series and > M-series. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > From rdobbins at arbor.net Tue Dec 31 03:30:30 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 03:30:30 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> Message-ID: <8FF7C86F-87BD-4953-9A89-E07917CF1C91@arbor.net> On Dec 31, 2013, at 10:16 AM, Blake Dunlap wrote: > The cynic in me says that cisco switch/router gear isn't part of that report on clandestine backdoors, because they don't need said clandestine backdoors to access them... T-series is in there, too. It's also important to keep in mind that all these purported documents refer to technologies which were supposedly available 5 years ago, based on the dates in the slides. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From sabri at cluecentral.net Tue Dec 31 03:38:12 2013 From: sabri at cluecentral.net (Sabri Berisha) Date: Mon, 30 Dec 2013 19:38:12 -0800 (PST) Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> Message-ID: <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> Hi Roland. > I don't know much about Juniper > gear, but it appears that the Juniper boxes listed are similar in nature, > albeit running FreeBSD underneath (correction welcome). With most Juniper gear, it is actually quite difficult to achieve wire-tapping on a large scale using something as simple as a backdoor in the BIOS. Assuming M/MX/T series, you are correct that the foundation of the control-plane is a FreeBSD-based kernel. However, that control-plane talks to a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which differ per platform and sometimes per line-card). In general, transit-traffic (traffic that enters the PFE and is not destined to the router itself), will not be forwarded via the control-plane. This means that whatever the backdoor is designed to do, simply can not touch the traffic. There are a few exceptions, such as a carefully crafted backdoor capable of altering the next-hop database (the PFEs forwarding table) and mirroring traffic. This however, would mean that the network would already have to be compromised. Another option would be to duplicate target traffic into a tunnel (GRE or IPIP based for example), but that would certainly have a noticeable affect on the performance, if it is possible to perform those operations at all on the target chipset. However, attempting any of the limited attacks that I can think of would require expert-level knowledge of not just the overall architecture, but also of the microcode that runs on the specific PFE that the attacker would target, as well as the ability to partially rewrite that. Furthermore, to embed such a sophisticated attack in a BIOS would seem impossible to me with the first reason being the limited amount of storage available on the EEPROM to store all that binary code. An attack based on corrupted firmware loaded post-manufacturing would also be difficult due to the signed binaries and microcode. If someone were to embed a backdoor it is extremely difficult without Juniper's cooperation. And the last time I looked at the code (I left Juniper a few months ago), I saw nothing that would indicate a backdoor of any kind. -- Thanks, Sabri From jra at baylink.com Tue Dec 31 03:51:13 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 30 Dec 2013 22:51:13 -0500 (EST) Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: Message-ID: <17218455.2014.1388461873466.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ray Soucy" > I hope when [if] the truth is learned it is a lot less prevalent than > it sounds, but I'm not optimistic. > > This is why we need all infrastructure to be implemented using open > standards, open hardware designs, and open source software IMHO. > > I hope Cisco, Juniper, and others respond quickly with updated images > for all platforms affected before the details leak. I hate to be Even More Paranoid Than That (and if I go off-air for more than about a week, assume those Black Eyeshades types whose mention got me kicked off the list after Katrina came for me :-), but contemplate this: === If you were the NSA, and you had a spandy new image with lots of great backdooring and kill-switching all ready to do, and you'd plunked it in Cisco's TAC download site (with or without their knowledge)... ...what do you suppose you'd do? Wouldn't you want some way to motivate everyone to grab that new image and plonk it on all their devices as fast as possible? Wouldn't it be the definition of irony if the way you got everyone to install your bug on their router ... was because they were afraid you already had? Is Ken Thompson turning over in his grave yet? === Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From wwaites at tardis.ed.ac.uk Tue Dec 31 03:58:12 2013 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Tue, 31 Dec 2013 03:58:12 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <17218455.2014.1388461873466.JavaMail.root@benjamin.baylink.com> References: <17218455.2014.1388461873466.JavaMail.root@benjamin.baylink.com> Message-ID: >Is Ken Thompson turning over in his grave yet? I certainly hope not... From randy at psg.com Tue Dec 31 03:59:16 2013 From: randy at psg.com (Randy Bush) Date: Mon, 30 Dec 2013 17:59:16 -1000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <8FF7C86F-87BD-4953-9A89-E07917CF1C91@arbor.net> References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <8FF7C86F-87BD-4953-9A89-E07917CF1C91@arbor.net> Message-ID: > It's also important to keep in mind that all these purported documents > refer to technologies which were supposedly available 5 years ago, > based on the dates in the slides. assumptions that the TAO folk have been taking a long much-deserved sabbatical are probably naive the shocking revelation will come tomorrow when it is announced that there is some piece of equipment or technology which has not been violated randy From nanog at armoredpackets.com Tue Dec 31 04:06:29 2013 From: nanog at armoredpackets.com ([AP] NANOG) Date: Mon, 30 Dec 2013 23:06:29 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> Message-ID: <52C242C5.70905@armoredpackets.com> Sabri, As I was going through reading all these replies, the one thing that continued to poke at me was the requirement of the signed binaries and microcode. The same goes for many of the Cisco binaries, without direct assistance, which is unclear at this point through the cloud of smoke so to speak, it would be difficult to load this code post implementation or manufacturing. Then looking at things from the evil side though, if they owned the system which provides the signing then they could sign virtually anything they wish. This is similar to what happened to Red Hat a number a years ago when they had their repos owned and the packages were compromised but passed just fine because the signing server was owned as well. Not say this is or isn't the case, but I know from my experience were I worked in an ISP running Juniper routers (M & J Series) coast to coast, that with the number of eyes watching these devices, it would have to be done at the firmware level not to be seen by the analysts. This is not out of reach either, it was roughly 5-7 years ago when Ethernet cards were owned with a firmware hack and all the traffic crossing that interface was seen then reported back. I know that all the conversations surrounding this topic were shut down quickly and the conference talks surrounding it dried up as well, everyone I talked to was curious why the conversations of such an attack all of a sudden went silent and have yet to resurface... I think we need to watch and listen/read over the coming weeks and months before we go assuming we have it figured out. Keep in mind the best way to cover up a covert mission is not to cover it up to start with. Put it out there, then flood the channels with false or miss information, until the real mission is so clouded with miss information you can no longer see the real mission resulting in the perfect execution of the op. Just a few thoughts, sorry no answers... -- Thank you, Robert Miller http://www.armoredpackets.com Twitter: @arch3angel On 12/30/13, 10:38 PM, Sabri Berisha wrote: > Hi Roland. > >> I don't know much about Juniper >> gear, but it appears that the Juniper boxes listed are similar in nature, >> albeit running FreeBSD underneath (correction welcome). > With most Juniper gear, it is actually quite difficult to achieve wire-tapping on a large scale using something as simple as a backdoor in the BIOS. > > Assuming M/MX/T series, you are correct that the foundation of the control-plane is a FreeBSD-based kernel. However, that control-plane talks to a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which differ per platform and sometimes per line-card). In general, transit-traffic (traffic that enters the PFE and is not destined to the router itself), will not be forwarded via the control-plane. This means that whatever the backdoor is designed to do, simply can not touch the traffic. There are a few exceptions, such as a carefully crafted backdoor capable of altering the next-hop database (the PFEs forwarding table) and mirroring traffic. This however, would mean that the network would already have to be compromised. Another option would be to duplicate target traffic into a tunnel (GRE or IPIP based for example), but that would certainly have a noticeable affect on the performance, if it is possible to perform those operations at all on the target chipset. > > However, attempting any of the limited attacks that I can think of would require expert-level knowledge of not just the overall architecture, but also of the microcode that runs on the specific PFE that the attacker would target, as well as the ability to partially rewrite that. Furthermore, to embed such a sophisticated attack in a BIOS would seem impossible to me with the first reason being the limited amount of storage available on the EEPROM to store all that binary code. > > An attack based on corrupted firmware loaded post-manufacturing would also be difficult due to the signed binaries and microcode. If someone were to embed a backdoor it is extremely difficult without Juniper's cooperation. And the last time I looked at the code (I left Juniper a few months ago), I saw nothing that would indicate a backdoor of any kind. > From rdobbins at arbor.net Tue Dec 31 04:19:06 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 04:19:06 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <8FF7C86F-87BD-4953-9A89-E07917CF1C91@arbor.net> Message-ID: On Dec 31, 2013, at 10:59 AM, Randy Bush wrote: > assumptions that the TAO folk have been taking a long much-deserved sabbatical are probably naive Indeed; that is my point. These documents allege that the capabilities in question were present five years ago, which is an eternity in tech-time. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Dec 31 04:28:03 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 04:28:03 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> Message-ID: <4B9D1293-970B-4B51-8456-5DE89B0F54C5@arbor.net> On Dec 31, 2013, at 10:38 AM, Sabri Berisha wrote: > Assuming M/MX/T series, you are correct that the foundation of the control-plane is a FreeBSD-based kernel. And the management plane, too? > However, that control-plane talks to a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which differ per platform and sometimes per line-card). In general, transit-traffic (traffic that enters the PFE and is not destined to the router itself), will not be forwarded via the control-plane. These same concepts apply to most Cisco gear, as well. > Another option would be to duplicate target traffic into a tunnel (GRE or IPIP based for example), but that would certainly have a noticeable affect on the performance, if it is possible to perform those operations at all on the target chipset. Something along these lines would be a good guess, along with the ability to alter the config of the device and to mask said alteration. Other purported documents speak of tunneling duplicated traffic, and in fact we've seen tunnels on compromised routers + NAT used by spammers in conjunction with BGP hijacking in order to send out spam-bursts from allocated space (i.e., the precise opposite use-case, heh). Assuming these alleged documents describe actual capabilities, there is some reason for having developed them in the first place. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Dec 31 04:33:52 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 04:33:52 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <52C242C5.70905@armoredpackets.com> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> Message-ID: <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> On Dec 31, 2013, at 11:06 AM, [AP] NANOG wrote: > Then looking at things from the evil side though, if they owned the system which provides the signing then they could sign > virtually anything they wish. Or if they owned *people* with the right level of access to do so, or if there were implementation bugs which could be utilized to bypass or obviate the signing . . . None of the alleged capabilities described in the purported documents is really standalone; they all rely upon other methods/mechanisms in order to provide the required foundation to accomplish their stated goals. > I think we need to watch and listen/read over the coming weeks and months before we go assuming we have it figured out. This is the most pertinent and insightful comment made in this thread. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From victor at jvknet.com Tue Dec 31 04:40:42 2013 From: victor at jvknet.com (Victor Kuarsingh) Date: Mon, 30 Dec 2013 23:40:42 -0500 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> Message-ID: On Mon, Dec 30, 2013 at 6:31 PM, Leo Bicknell wrote: > > On Dec 30, 2013, at 4:37 PM, Victor Kuarsingh wrote: > > > On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard wrote: > >>> The better question is are you using RIP or ICMP to set gateways in > your > >>> network now? > >> > >> I disagree that that's a better question. > >> I'm not using RIP because my hosts don't support it (at least, not > without > >> additional configuration), and it would be a very unusual configuration, > >> adding weight and complexity for no benefit. RAs are the opposite. > >> Not even sure how you would use ICMP to set a default gateway. Maybe > >> there's a field I'm unaware of. > >> > > > > [VK] The RIP comparison is somewhat confusing to me. I don't see how RIP > > is comparable in this context (I guess technically you can pass a default > > route in RIP, but as Lee mentions, the protocol is designed for a > different > > purpose and requires configuration). > > There was a time, I'm going to roughly guess approximately 1987-1992, > although > I may be off by a year or two, that you needed to have lived through for > this > to make sense. > > You see, in that time the available IGP was, well, RIP. RIPv1. Routers, > at > least ones you could buy, did not have OSPF, EIGRP, or even in many cases > EGP/BGP. They had RIPv1, and perhaps some bleeding edge Cisco's had IGRP. > So almost every campus network ran RIPv1 [VK] Leo, I understand the case you mention, but I am not sure if this is a parallel to what the subject is on this thread. I would think we are talking - not about routers and servers here - but end hosts (PCs, tablets, home gateways, smart phones, media devices etc.) which would be the beneficiaries of the [DHCPv6] route option information. I still don't think that RIP's prevalence in 20+ year old network environments, and it's lack of use today, draws a comparison to the validity of using RAs. I get that it [RIP] may have been "default" on may historic boxes, so had similar effect on providing a default route, but the protocol's purpose was not intended to do that for all the hosts on a network (also a world where not all networks were IP as well). RA on the other had was specifically purposed to be used to provide this kind of information to all IPv6 stacks. So I still think we are talking about very different environments in protocol types, purpose and mixture of participating hosts/routers etc. regards, Victor K From nanog at armoredpackets.com Tue Dec 31 04:41:05 2013 From: nanog at armoredpackets.com ([AP] NANOG) Date: Mon, 30 Dec 2013 23:41:05 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> Message-ID: <52C24AE1.90904@armoredpackets.com> Roland, I did fail to mention the HUMINT (Human Intelligence) side of things, thank you for bringing that up! -- Thank you, Robert Miller http://www.armoredpackets.com Twitter: @arch3angel On 12/30/13, 11:33 PM, Dobbins, Roland wrote: > On Dec 31, 2013, at 11:06 AM, [AP] NANOG wrote: > >> Then looking at things from the evil side though, if they owned the system which provides the signing then they could sign >> virtually anything they wish. > Or if they owned *people* with the right level of access to do so, or if there were implementation bugs which could be utilized to bypass or obviate the signing . . . > > None of the alleged capabilities described in the purported documents is really standalone; they all rely upon other methods/mechanisms in order to provide the required foundation to accomplish their stated goals. > >> I think we need to watch and listen/read over the coming weeks and months before we go assuming we have it figured out. > This is the most pertinent and insightful comment made in this thread. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > From blair.trosper at gmail.com Tue Dec 31 04:41:20 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Mon, 30 Dec 2013 22:41:20 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> Message-ID: I'm torn on this. On one hand, it seems sinister. On the other, it's not only what the NSA is tasked with doing, but it's what you'd EXPECT them to be doing in the role as the NSA. I'm not saying it's right or wrong...it creeps me out a little, though...but these are the kinds of things we have demanded that they do (via our elected representatives). More to the point, I really doubt the NSA has any interest whatsoever in my Facebook or Twitter account. It's probable a means to and end...a transitory stop on their way to propagating more widely. They need regular folks to propagate, but in reality, they likely have zero interest in our actual accounts at the end of the day. I think of it a bit like a virus with a slightly less hysterical outcome/plan. On Mon, Dec 30, 2013 at 10:33 PM, Dobbins, Roland wrote: > > On Dec 31, 2013, at 11:06 AM, [AP] NANOG wrote: > > > Then looking at things from the evil side though, if they owned the > system which provides the signing then they could sign > > virtually anything they wish. > > Or if they owned *people* with the right level of access to do so, or if > there were implementation bugs which could be utilized to bypass or obviate > the signing . . . > > None of the alleged capabilities described in the purported documents is > really standalone; they all rely upon other methods/mechanisms in order to > provide the required foundation to accomplish their stated goals. > > > I think we need to watch and listen/read over the coming weeks and > months before we go assuming we have it figured out. > > This is the most pertinent and insightful comment made in this thread. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > From jeff-kell at utc.edu Tue Dec 31 04:54:59 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 30 Dec 2013 23:54:59 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <52C242C5.70905@armoredpackets.com> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> Message-ID: <52C24E23.1070904@utc.edu> On 12/30/2013 11:06 PM, [AP] NANOG wrote: > As I was going through reading all these replies, the one thing that > continued to poke at me was the requirement of the signed binaries and > microcode. The same goes for many of the Cisco binaries, without direct > assistance, which is unclear at this point through the cloud of smoke so > to speak, it would be difficult to load this code post implementation or > manufacturing. Signed binaries?? Surely you jest... Try download *anything* from Cisco TAC these days with a new browser and latest Java and see how many exceptions you have to make to get an "allegedly" legitimate copy of "anything". If you don't like it, open a TAC case, and count the number of exceptions you have to make to get to THAT point as well. And of course they'll want you to upload a "show tech" first thing, and see how many MORE exceptions you have to make to get that to work. Geez, just open ASDM today I have to honor Java exceptions. We're all getting far too conditioned for the "click OK to proceed" overload, and the sources aren't helping. Jeff From mysidia at gmail.com Tue Dec 31 05:08:53 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 30 Dec 2013 23:08:53 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> Message-ID: On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper wrote: > I'm torn on this. On one hand, it seems sinister. On the other, it's not > only what the NSA is tasked with doing, but it's what you'd EXPECT them to > be doing in the role as the NSA. > [snip] The NSA's role is not supposed to include subterfuge and undermining the integrity or security of domestic enterprise infrastructure With any luck, we'll hopefully find absolutely nothing, or that it was "targetted" backdooring against specific targets only. And people have a need to know that the security agencies haven't left a trail of artificially inserted bugs and backdoors in common IT equipment providing critical infrastructures services, and that the agencies haven't prepared a collection of instant-root 0days, that are no more protected then the agencies' other poorly guarded "secrets". There would be a risk that any 'backdoors' are ready to be exploited by other unintended nefarious actors! Because the NSA are apparently great at prepping the flammables and setting fires, but totally incapable of keeping the fires contained, once they (or someone else) lights it. It is not the least bit necessary for the NSA itself to be a nefarious actor exploiting things or even complicit; for the mere presence of any backdoor or surreptitious code to eventually have the potential for serious damage. It could well be a rogue ex-employee of the NSA, such as Snowden, or others, that happened to be aware of technical details, hackers, or members of a foreign nation state, who will just happen to have the time and energy to track down open doors waiting for the taking, AND figure out how to abuse them for evil purposes. There are enough potential 0day risks, without intentional ones, waiting for bad guys to co-opt! -- -JH From kmedcalf at dessus.com Tue Dec 31 05:15:57 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 30 Dec 2013 22:15:57 -0700 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <52C24E23.1070904@utc.edu> Message-ID: <914423c8dfeb4c44a2e6adfb09cdbea3@mail.dessus.com> >We're all getting far too conditioned for the "click OK to proceed" >overload, and the sources aren't helping. If one embarks with deliberation upon a course of action which may entertain certain results then the intent to cause the result so obtained is, by implication, proved. From blair.trosper at gmail.com Tue Dec 31 05:19:37 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Mon, 30 Dec 2013 23:19:37 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> Message-ID: To supplement and amend what I said: These are the KINDS of things we want the NSA to do; however, the institutional oversight necessary to make sure it's Constitutional, warranted, and kept "in bounds" is woefully lacking (if any exists at all). Even FISA is unsatisfactory. At any rate, I agree that the current disposition of the NSA (or, at least, what's been leaking the last few months) is simply unacceptable and cannot be allowed. I say that last part from the perspective of a US citizen, though I'd imagine most people of other nationalities would agree with me, but probably for different reasons. On Mon, Dec 30, 2013 at 11:08 PM, Jimmy Hess wrote: > On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper wrote: > >> I'm torn on this. On one hand, it seems sinister. On the other, it's not >> only what the NSA is tasked with doing, but it's what you'd EXPECT them to >> be doing in the role as the NSA. >> > [snip] > > The NSA's role is not supposed to include subterfuge and undermining the > integrity or security of domestic enterprise infrastructure > > With any luck, we'll hopefully find absolutely nothing, or that it was > "targetted" backdooring against specific targets only. > > And people have a need to know that the security agencies haven't left a > trail of artificially inserted bugs and backdoors in common IT equipment > providing critical infrastructures services, and that the agencies haven't > prepared a collection of instant-root 0days, that are no more protected > then the agencies' other poorly guarded "secrets". > > There would be a risk that any 'backdoors' are ready to be exploited by > other unintended nefarious actors! > Because the NSA are apparently great at prepping the flammables and > setting fires, but totally incapable of keeping the fires contained, > once they (or someone else) lights it. > > > It is not the least bit necessary for the NSA itself to be a nefarious > actor exploiting things or even complicit; for the mere presence of any > backdoor or surreptitious code to eventually have the potential for serious > damage. > > It could well be a rogue ex-employee of the NSA, such as Snowden, or > others, that happened to be aware of technical details, hackers, or > members of a foreign nation state, who will just happen to have the time > and energy to track down open doors waiting for the taking, AND figure > out how to abuse them for evil purposes. > > > There are enough potential 0day risks, without intentional ones, waiting > for bad guys to co-opt! > > -- > -JH > From victor at jvknet.com Tue Dec 31 05:29:56 2013 From: victor at jvknet.com (Victor Kuarsingh) Date: Tue, 31 Dec 2013 00:29:56 -0500 Subject: turning on comcast v6 Message-ID: Leo, On Mon, Dec 30, 2013 at 6:24 PM, Leo Bicknell wrote: > > On Dec 30, 2013, at 2:49 PM, Lee Howard wrote: > > > I'm not really an advocate for or against DHCP or RAs. I really just > want > > to understand what feature is missing. > > I encourage you to try this simple experiment in your lab, because this > happens all day long on corporate networks around the world, and > illustrates the differences quite nicely. While not a complete treatment > of the operational differences, it's an important illustration. > > Configure up a simple network topology of three boxes representing a hub > and spoke network: > > DHCP SVR > | > --lan--r1--wan--hubrtr--wan--r2--lan > > > ..... > > Here's what you will soon find: > > 1) The IPv6 pings on both machines cease to work. > > 2) The IPv4 network continues to work just fine. > > > Yes, in this very specific case, you may get this result. However, this is a very specific case with very specific parameters and conditions. There are also many cases (again specific in nature) which would cause the IPv4 connection to have problems and not the IPv6 connection. As an example, say the failure is now over and we have running state with r1 and r2 as two potential routers out of the LAN to a common WAN for IPv4 and IPv6 connectivity. The DHCPv4 server provides only the address of the r2 router (original on that LAN). Both r1 and r2 provide RAs and the client works over r2 for IPv6 for now. r1 fails, the machines will lose IPv4 connectivity but IPv6 will keep working (as the hosts will detect r1 as unreachable and then use r2). There are a number of assumptions in this use case - but that's the point. One may say that without IPv4, perhaps we have a problem anyway (since I am sure many networks will have some level of dependance on IPv4 for a while) - but the designers of IPv6 will then say that the IPv6 protocol needs to be free from IPv4 baggage to truly succeed IPv4. I am not fighting against the case of the DHCPv6 option, but I am not sure if use cases like the one you mentioned will convince the right audiences that the option is needed. For reference, this concept has died on the vine before - draft-droms-dhc-dhcpv6-default-router-00 as an example. (where technical comments were made to diminish the technical value of using DHCPv6 as an option to provide default gateway information). We can also reference draft-ietf-mif-dhcpv6-route-option from the MIF working group. I think a new initiative to revive this concept will need to address the [negative] points from those previous experiences and contrast them to the operational benefits of having it available. I am willing to help out here, but we need some folks willing to put the use cases together which make a strong case (oh and they will need email stamina). regards, Victor K > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From drc at virtualized.org Tue Dec 31 05:37:35 2013 From: drc at virtualized.org (David Conrad) Date: Mon, 30 Dec 2013 21:37:35 -0800 Subject: turning on comcast v6 In-Reply-To: References: Message-ID: <9684869B-B76C-43B0-86A4-A0BC817E83A4@virtualized.org> On Dec 30, 2013, at 9:29 PM, Victor Kuarsingh wrote: > I think a new initiative to revive this concept will need to address the > [negative] points from those previous experiences and contrast them to the > operational benefits of having it available. I am willing to help out > here, but we need some folks willing to put the use cases together which > make a strong case (oh and they will need email stamina). Or, alternatively, operators who care about this and vendors who are interested in accepting money to implement what the operators want could get together and form, oh I dunno, the Internet DHCP Task Force, which could specify/implement the standard way of solving this particular problem... Regards, -drc -------------- 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 tmorizot at gmail.com Tue Dec 31 07:10:44 2013 From: tmorizot at gmail.com (Timothy Morizot) Date: Tue, 31 Dec 2013 01:10:44 -0600 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> Message-ID: I've been in the process of rolling out IPv6 (again this night) across a very large, highly conservative, and very bureaucratic enterprise. (Roughly 100K employees. More than 600 distinct site. Yada. Yada.) I've had no issues whatsoever implementing the IPv6 RA+DHCPv6 model alongside the IPv4 model. In fact, the IPv6 model has generally been much more straightforward and easy to implement. So I'm a large enterprise operator, not an ISP. Convince me. Because I don't see any need. And if I don't, I'm hard-pressed to see why the IETF would. Scott On Mon, Dec 30, 2013 at 3:49 PM, Owen DeLong wrote: > > On Dec 30, 2013, at 10:04 AM, Ryan Harden wrote: > > > On Dec 24, 2013, at 8:15 AM, Lee Howard wrote: > > > >>> default route information via DHCPv6. That's what I'm still waiting > for. > >> > >> Why? > >> You say, "The protocol suite doesn't meet my needs; I need default > gateway > >> in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why? > >> > >> Lee > > > > There are many places that wish to severely restrict or even block RA. > Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to > do redirection based on MAC. Many are doing this with very short DHCP > leases that hand out different name servers and/or gateways until you > properly auth via $method. You might be able to do this with something like > RADVD, but when you have systems that have been doing this for IPv4 for > years, there?s little interest (read: budget) in rewriting everything for > IPv6. > > > > While I do not oppose the inclusion of Routing Information into DHCPv6, I > have to say that this seems to be one of the weaker arguments. > > Please permit me to repeat your statement from an IPv6 perspective? > > Because many places have poorly thought out cruft that deals with > deficiencies in IPv4 by doing stunts that won?t work in the current IPv6 > implementation and because we don?t want to rewrite our cruft to take > advantage of the cleaner solutions available for these problems in IPv6, we > demand that you include the cruft from IPv4 into IPv6 in order to support > this hackery. > > > > 'Rewrite all of your tools and change your long standing business > practices? is a very large barrier to entry to IPv6. If adding gateway as > an optional field will help people get over that barrier, why not add it? > Sure it doesn?t fit into the ?IPv6 way,? but bean counters don?t care much > for that when you have to ask for developer time to rewrite everything. > > You have to rewrite all your tools to handle the bigger addresses anyway. > While you?re at it, why not rewrite them to take advantage of cleaner > solutions? > > > Disclaimer: I don?t condone said methods and trickery mentioned above, > just pointing out their use. > > So you?re defending a position you don?t share? Interesting tactic. > > Owen > > > From ikiris at gmail.com Tue Dec 31 08:53:17 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 31 Dec 2013 02:53:17 -0600 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> Message-ID: The reason RIP isn't used to hand out routes is not based on age, or protocol design. It's based on the fact that we don't want host segment routes (usually only default) to be announcement based, because that leads to problems and uncomfortable meetings with VPs. DHCP will happily give out a correct gateway that can be managed using some FHRP, or not, and those few (new to the network) users can reboot once it's fixed. The key is it is controlled and can't be just hijacked at a moment's notice. All we've gained by switching to RA is a security hole that must be managed at the L2 level, and the ability to use a slower method of failover than FHRPs purely so we aren't reliant on a single ip address, and the vauge notion that somehow the network and the dhcp server could possibly get out of sync, and that's somehow a worse problem than losing the entire network randomly due to bad/inept actors and either a lack of security, or a security vulnerability. Personally I don't see the trade offs as beneficial, and you also lose the ability to differentiate gateways by host from central control (even though you'd rarely see this done as opposed to separate vlans). -Blake On Mon, Dec 30, 2013 at 10:40 PM, Victor Kuarsingh wrote: > On Mon, Dec 30, 2013 at 6:31 PM, Leo Bicknell wrote: > > > > > On Dec 30, 2013, at 4:37 PM, Victor Kuarsingh wrote: > > > > > On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard wrote: > > >>> The better question is are you using RIP or ICMP to set gateways in > > your > > >>> network now? > > >> > > >> I disagree that that's a better question. > > >> I'm not using RIP because my hosts don't support it (at least, not > > without > > >> additional configuration), and it would be a very unusual > configuration, > > >> adding weight and complexity for no benefit. RAs are the opposite. > > >> Not even sure how you would use ICMP to set a default gateway. Maybe > > >> there's a field I'm unaware of. > > >> > > > > > > [VK] The RIP comparison is somewhat confusing to me. I don't see how > RIP > > > is comparable in this context (I guess technically you can pass a > default > > > route in RIP, but as Lee mentions, the protocol is designed for a > > different > > > purpose and requires configuration). > > > > There was a time, I'm going to roughly guess approximately 1987-1992, > > although > > I may be off by a year or two, that you needed to have lived through for > > this > > to make sense. > > > > You see, in that time the available IGP was, well, RIP. RIPv1. Routers, > > at > > least ones you could buy, did not have OSPF, EIGRP, or even in many cases > > EGP/BGP. They had RIPv1, and perhaps some bleeding edge Cisco's had > IGRP. > > So almost every campus network ran RIPv1 > > > [VK] Leo, I understand the case you mention, but I am not sure if this is > a parallel to what the subject is on this thread. I would think we are > talking - not about routers and servers here - but end hosts (PCs, tablets, > home gateways, smart phones, media devices etc.) which would be the > beneficiaries of the [DHCPv6] route option information. > > I still don't think that RIP's prevalence in 20+ year old network > environments, and it's lack of use today, draws a comparison to the > validity of using RAs. I get that it [RIP] may have been "default" on may > historic boxes, so had similar effect on providing a default route, but the > protocol's purpose was not intended to do that for all the hosts on a > network (also a world where not all networks were IP as well). > > RA on the other had was specifically purposed to be used to provide this > kind of information to all IPv6 stacks. So I still think we are talking > about very different environments in protocol types, purpose and mixture of > participating hosts/routers etc. > > regards, > > Victor K > From baldur.norddahl at gmail.com Tue Dec 31 09:03:51 2013 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 31 Dec 2013 10:03:51 +0100 Subject: turning on comcast v6 In-Reply-To: <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> Message-ID: On Tue, Dec 31, 2013 at 12:24 AM, Leo Bicknell wrote: > Here's what you will soon find: > > 1) The IPv6 pings on both machines cease to work. > That will not actually happen. An IPv6 router is only allowed to announce a prefix by RA if it has a working uplink. Nonetheless you are required to secure your network against rogue DHCP and RA servers on both IPv4 and IPv6. Aside from the obvious reasons why, we can keep to your example, except this time it is a home router used for a home office application with a build in DHCP server. You connect it to your office network and it promptly starts handing out DHCP replies... This is not a big issue, as any useful switch for an enterprise environment will have this functionality. It does mean that you can not keep using dumb non-ipv6 aware switches, but that would be true even if we did not have RA and had to rely on DHCP instead. Regards, Baldur From eugen at imacandi.net Tue Dec 31 12:51:51 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 31 Dec 2013 14:51:51 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> Message-ID: On Tue, Dec 31, 2013 at 5:38 AM, Sabri Berisha wrote: > Hi Roland. > > > I don't know much about Juniper > > gear, but it appears that the Juniper boxes listed are similar in nature, > > albeit running FreeBSD underneath (correction welcome). > > With most Juniper gear, it is actually quite difficult to achieve > wire-tapping on a large scale using something as simple as a backdoor in > the BIOS. > > You would just need an entry-point into the system, nothing fancy at first. > Assuming M/MX/T series, you are correct that the foundation of the > control-plane is a FreeBSD-based kernel. However, that control-plane talks > to a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which > differ per platform and sometimes per line-card). In general, > transit-traffic (traffic that enters the PFE and is not destined to the > router itself), will not be forwarded via the control-plane. This means > that whatever the backdoor is designed to do, simply can not touch the > traffic. There are a few exceptions, such as a carefully crafted backdoor > capable of altering the next-hop database (the PFEs forwarding table) and > mirroring traffic. This however, would mean that the network would already > have to be compromised. Another option would be to duplicate target traffic > into a tunnel (GRE or IPIP based for example), but that would certainly > have a noticeable affect on the performance, if it is possible to perform > those operations at all on the target chipset. > > >From my experience with Juniper, you can actually tell the PFEs to do quite a lot to the packets that flow through the router, I would imagine that programmatically you can tell the router to mirror packets which match a certain criteria (source, destination, ports, protocol) to a chosen destination and it would not get noticed by the NOC monitoring systems (it may not even blip on the throughput graphs) > However, attempting any of the limited attacks that I can think of would > require expert-level knowledge of not just the overall architecture, but > also of the microcode that runs on the specific PFE that the attacker would > target, as well as the ability to partially rewrite that. Furthermore, to > embed such a sophisticated attack in a BIOS would seem impossible to me > with the first reason being the limited amount of storage available on the > EEPROM to store all that binary code. > > All you need is a hook into the system and load your code, the main payload can be easily downloaded from the internet. > An attack based on corrupted firmware loaded post-manufacturing would also > be difficult due to the signed binaries and microcode. If someone were to > embed a backdoor it is extremely difficult without Juniper's cooperation. > And the last time I looked at the code (I left Juniper a few months ago), I > saw nothing that would indicate a backdoor of any kind. > > Who checks the binaries when they are loaded when the OS boots up ? :) From rps at maine.edu Tue Dec 31 13:05:03 2013 From: rps at maine.edu (Ray Soucy) Date: Tue, 31 Dec 2013 08:05:03 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> Message-ID: I think there needs to be some clarification on how these tools get used, how often they're used, and if they're ever cleaned up when no longer part of an active operation. Of course we'll never get that. The amount of apologists with the attitude "this isn't a big deal, nothing to see here, the NSA does this kind of thing" is kind of shocking for this community; especially with the information that's been released over the past few months. This whole backdoor business is a very, very, dangerous game. On Tue, Dec 31, 2013 at 12:19 AM, Blair Trosper wrote: > To supplement and amend what I said: > > These are the KINDS of things we want the NSA to do; however, the > institutional oversight necessary to make sure it's Constitutional, > warranted, and kept "in bounds" is woefully lacking (if any exists at all). > Even FISA is unsatisfactory. > > At any rate, I agree that the current disposition of the NSA (or, at least, > what's been leaking the last few months) is simply unacceptable and cannot > be allowed. I say that last part from the perspective of a US citizen, > though I'd imagine most people of other nationalities would agree with me, > but probably for different reasons. > > > On Mon, Dec 30, 2013 at 11:08 PM, Jimmy Hess wrote: > > > On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper >wrote: > > > >> I'm torn on this. On one hand, it seems sinister. On the other, it's > not > >> only what the NSA is tasked with doing, but it's what you'd EXPECT them > to > >> be doing in the role as the NSA. > >> > > [snip] > > > > The NSA's role is not supposed to include subterfuge and undermining the > > integrity or security of domestic enterprise infrastructure > > > > With any luck, we'll hopefully find absolutely nothing, or that it was > > "targetted" backdooring against specific targets only. > > > > And people have a need to know that the security agencies haven't left a > > trail of artificially inserted bugs and backdoors in common IT equipment > > providing critical infrastructures services, and that the agencies > haven't > > prepared a collection of instant-root 0days, that are no more protected > > then the agencies' other poorly guarded "secrets". > > > > There would be a risk that any 'backdoors' are ready to be exploited by > > other unintended nefarious actors! > > Because the NSA are apparently great at prepping the flammables and > > setting fires, but totally incapable of keeping the fires contained, > > once they (or someone else) lights it. > > > > > > It is not the least bit necessary for the NSA itself to be a nefarious > > actor exploiting things or even complicit; for the mere presence of > any > > backdoor or surreptitious code to eventually have the potential for > serious > > damage. > > > > It could well be a rogue ex-employee of the NSA, such as Snowden, or > > others, that happened to be aware of technical details, hackers, or > > members of a foreign nation state, who will just happen to have the time > > and energy to track down open doors waiting for the taking, AND figure > > out how to abuse them for evil purposes. > > > > > > There are enough potential 0day risks, without intentional ones, waiting > > for bad guys to co-opt! > > > > -- > > -JH > > > -- 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 ag4ve.us at gmail.com Tue Dec 31 13:28:03 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 31 Dec 2013 08:28:03 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> Message-ID: On Tue, Dec 31, 2013 at 8:05 AM, Ray Soucy wrote: > This whole backdoor business is a very, very, dangerous game. While I agree with this (and the issues brought up with NSA's NIST approved PRNG that RSA used). If I were in their shoes, I would have been collecting every bit of data I could (ie, I can't fault them on PRISM and have some serious issues with most of these disclosures). I don't believe that anyone has said "this isn't a big deal". I think even the NSA has said the exact opposite (for different reasons). I have no oppinion at this point of whether they put a back door in routers - I think it's possible. Maybe even with multiple moving parts (submit some HDL to a manufacturer for their own project and allow them to use it for others under an NDA, knowing that the chip could be used in hardware and knowing that something would hit that part of the chip) and no one on either end has to know a back door has been inserted. It's also possible that ANT stuff is propaganda (though the ideas in there are pretty cool and should be implemented under open source). From m.hallgren at free.fr Tue Dec 31 13:29:53 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 31 Dec 2013 14:29:53 +0100 Subject: NSA able to compromise Cisco, Juniper, Huawei switches Message-ID: +1, I fully agree. And not only concerning the "domestic" use by country, but also with regards to "information peering" with neighbors, and such.? Enjoy '14!? mh -------- Message d'origine -------- De : Ray Soucy Date : A : Blair Trosper Cc : "nanog at nanog.org list" Objet : Re: NSA able to compromise Cisco, Juniper, Huawei switches I think there needs to be some clarification on how these tools get used, how often they're used, and if they're ever cleaned up when no longer part of an active operation.? Of course we'll never get that. The amount of apologists with the attitude "this isn't a big deal, nothing to see here, the NSA does this kind of thing" is kind of shocking for this community; especially with the information that's been released over the past few months. This whole backdoor business is a very, very, dangerous game. On Tue, Dec 31, 2013 at 12:19 AM, Blair Trosper wrote: > To supplement and amend what I said: > > These are the KINDS of things we want the NSA to do; however, the > institutional oversight necessary to make sure it's Constitutional, > warranted, and kept "in bounds" is woefully lacking (if any exists at all). >? Even FISA is unsatisfactory. > > At any rate, I agree that the current disposition of the NSA (or, at least, > what's been leaking the last few months) is simply unacceptable and cannot > be allowed.? I say that last part from the perspective of a US citizen, > though I'd imagine most people of other nationalities would agree with me, > but probably for different reasons. > > > On Mon, Dec 30, 2013 at 11:08 PM, Jimmy Hess wrote: > > > On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper >wrote: > > > >> I'm torn on this.? On one hand, it seems sinister.? On the other, it's > not > >> only what the NSA is tasked with doing, but it's what you'd EXPECT them > to > >> be doing in the role as the NSA. > >> > > [snip] > > > > The NSA's role is not supposed to include subterfuge and undermining the > > integrity or security of domestic enterprise infrastructure > > > > With any luck, we'll hopefully find absolutely nothing, or that it was > > "targetted" backdooring against specific targets only. > > > > And people have a need to know that the security agencies haven't left a > > trail of artificially inserted bugs and backdoors in common IT equipment > > providing critical infrastructures services,? and that the agencies > haven't > > prepared a collection of instant-root 0days,? that are no more protected > > then the agencies' other poorly guarded "secrets". > > > > There would be a risk that any 'backdoors' are ready to be exploited by > > other unintended nefarious actors! > > Because the NSA are apparently? great at prepping the flammables and > > setting fires,??? but? totally incapable of? keeping the fires contained, > > once they? (or someone else)? lights it. > > > > > > It is not the least bit necessary for the NSA itself to be a nefarious > > actor? exploiting things or even complicit;? for the mere presence of >? any > > backdoor or surreptitious code to eventually have the potential for > serious > > damage. > > > > It could well be a rogue ex-employee of the NSA, such as Snowden,? or > > others,? that happened to be aware of technical details, hackers, or > > members of a foreign nation state,? who will just happen to have the time > > and energy to track down open doors waiting for the taking,? AND? figure > > out how to abuse them? for evil purposes. > > > > > > There are enough potential 0day risks, without intentional ones,? waiting > > for bad guys to co-opt! > > > > -- > > -JH > > > -- 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 sthaug at nethelp.no Tue Dec 31 13:45:46 2013 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 31 Dec 2013 14:45:46 +0100 (CET) Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: Message-ID: <20131231.144546.74654601.sthaug@nethelp.no> > I think there needs to be some clarification on how these tools get used, > how often they're used, and if they're ever cleaned up when no longer part > of an active operation. Of course we'll never get that. Highly unlikely, I'd say. > The amount of apologists with the attitude "this isn't a big deal, nothing > to see here, the NSA does this kind of thing" is kind of shocking for this > community; especially with the information that's been released over the > past few months. > > This whole backdoor business is a very, very, dangerous game. It *is* a big deal. And if you want to get even more scared, listen to Jacob Appelbaum's talk at the CCC here: http://www.youtube.com/watch?v=b0w36GAyZIA Steinar Haug, Nethelp consulting, sthaug at nethelp.no From saku at ytti.fi Tue Dec 31 14:32:29 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 31 Dec 2013 16:32:29 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131231.144546.74654601.sthaug@nethelp.no> References: <20131231.144546.74654601.sthaug@nethelp.no> Message-ID: <20131231143229.GA6690@pob.ytti.fi> On (2013-12-31 14:45 +0100), sthaug at nethelp.no wrote: > > This whole backdoor business is a very, very, dangerous game. > > It *is* a big deal. And if you want to get even more scared, listen to > Jacob Appelbaum's talk at the CCC here: I'm going to wait calmly for some of the examples being recovered from the field, documented and analysed. I'd love to see for example the pwned Juniper code in action, how do they manage from BIOS to inspect data from HW path, without relying on specific version of FreeBSD, JunOS, control-plane, HW NPU/ASIC. What is it capable of doing, what is it not capable of doing. How does it deliver the data. As they are presented as pervasive and common, I'm sure it's just matter of time when we'll have higher quality of data than screencapture of PDF. -- ++ytti, Commander, FUSAG From bicknell at ufp.org Tue Dec 31 15:03:15 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 31 Dec 2013 09:03:15 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131231143229.GA6690@pob.ytti.fi> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> Message-ID: <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> On Dec 31, 2013, at 8:32 AM, Saku Ytti wrote: > I'm going to wait calmly for some of the examples being recovered from the > field, documented and analysed. If I were Cisco/Juniper/et all I would have a team working on this right now. It should be trivial for them to insert code into the routers that say, hashes all sorts of things (code image, BIOS, any PROMS and EERPOMS and such on the linecards) and submits all of those signatures back. Any APT that has been snuck into those things should be able to be detected. For most of them the signatures should be known, as the code shipped from the factory and was never intended to be modified (e.g. BIOS). A transparent public report about how many devices are running signatures they do not know would be very interesting. Plus, it's an opportunity to sell new equipment to those people, so they can rid themselves of the infection. I also wonder how this will change engineering going forward. Maybe the BIOS should be a ROM chip, not an EEPROM again. Maybe the write line needs to be run through a physical jumper on the motherboard that is normally not present. Why do we accept our devices, be it a PC or a router, can be "persistently" infected. The hardware industry needs to do better. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From herro91 at gmail.com Tue Dec 31 15:08:02 2013 From: herro91 at gmail.com (Herro91) Date: Tue, 31 Dec 2013 10:08:02 -0500 Subject: CEF/etherchannel load balancing algorithms or MLPPPoE Message-ID: Hello, Looking for feedback/suggestions on a design issue. We have a two ethernet connections in a port channel between two Cisco routers (ASR1k), unfortunately we only have one unique flow between traversing the ether/port channel, so traffic is pinned to just one link. I'm looking for options including whether one of the algorithms available for CEF is able to make a load sharing decision if I expose some upper layer information such as DSCP/ToS to CEF to provide unique flows? I also have been considering MLPPPoE, but it does not seem to support more than one member link from what I can tell. Appreciate thoughts and suggestions. Best, -Doug From nanog at mitteilung.com Tue Dec 31 15:22:32 2013 From: nanog at mitteilung.com (nanog at mitteilung.com) Date: Tue, 31 Dec 2013 16:22:32 +0100 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> Message-ID: <52C2E138.3090409@mitteilung.com> Since some weeks all my cisco / juniper equipment was replaced with open source solutions (sometimes with embedded devices) and that works fine. Google as search engine and Facebook accounts are deleted and some more things. Cloud solutions outside europe now are forbidden for me. Thank you NSA & Co. for your "great" work :-( A real thank to Snowden! Best regards, Markus, Germany From Kapeel.Sharma at McKesson.com Tue Dec 31 15:31:30 2013 From: Kapeel.Sharma at McKesson.com (Sharma, Kapeel) Date: Tue, 31 Dec 2013 15:31:30 +0000 Subject: Juniper SSL VPN In-Reply-To: <20131231143229.GA6690@pob.ytti.fi> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> Message-ID: <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> Any one heard of a host checker issue with Juniper VPN today ? Thanks Kapeel From jgwatkin at magmic.com Tue Dec 31 15:43:02 2013 From: jgwatkin at magmic.com (Jamie Gwatkin) Date: Tue, 31 Dec 2013 10:43:02 -0500 Subject: Juniper SSL VPN In-Reply-To: <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> Message-ID: Could be related to this? http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16290 On Tue, Dec 31, 2013 at 10:31 AM, Sharma, Kapeel wrote: > Any one heard of a host checker issue with Juniper VPN today ? > > Thanks > Kapeel > > From Kapeel.Sharma at McKesson.com Tue Dec 31 15:47:21 2013 From: Kapeel.Sharma at McKesson.com (Sharma, Kapeel) Date: Tue, 31 Dec 2013 15:47:21 +0000 Subject: Juniper SSL VPN In-Reply-To: References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> Message-ID: <247429C70AB9D948A4DDECDFA5C23390DB6AB744@DDCEP50018.na.corp.mckesson.com> This is it thanks. Kapeel From: Jamie Gwatkin [mailto:jgwatkin at magmic.com] Sent: Tuesday, December 31, 2013 7:43 AM To: Sharma, Kapeel Cc: nanog at nanog.org Subject: Re: Juniper SSL VPN Could be related to this? http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16290 On Tue, Dec 31, 2013 at 10:31 AM, Sharma, Kapeel > wrote: Any one heard of a host checker issue with Juniper VPN today ? Thanks Kapeel From eyeronic.design at gmail.com Tue Dec 31 15:50:39 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 31 Dec 2013 07:50:39 -0800 Subject: Juniper SSL VPN In-Reply-To: References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> Message-ID: Wow. Thanks for posting this. I thought we were just going crazy yesterday. On Dec 31, 2013 7:45 AM, "Jamie Gwatkin" wrote: > Could be related to this? > http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16290 > > > On Tue, Dec 31, 2013 at 10:31 AM, Sharma, Kapeel < > Kapeel.Sharma at mckesson.com > > wrote: > > > Any one heard of a host checker issue with Juniper VPN today ? > > > > Thanks > > Kapeel > > > > > From lists at mtin.net Tue Dec 31 16:33:34 2013 From: lists at mtin.net (Justin Wilson) Date: Tue, 31 Dec 2013 11:33:34 -0500 Subject: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <50710E9A7E64454C974049FC998EB655018DDD93@03-exchange.lti.local> Message-ID: The biggest problem with Mikrotik is you just can?t call them up for support on buggy code. In a critical network this can be a major problem. Justin --- Justin Wilson MTIN Consulting Mikrotik ? UBNT ? Climbing ? Network Design http://www.mtin.net/ http://www.thebrotherswisp.com -----Original Message----- From: Dale Rumph Date: Friday, December 27, 2013 at 10:04 AM To: Dennis Burgess Cc: NANOG list Subject: Re: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? >Out of all the network hardware I have worked on in operations these were >by far some of the worst. I read lots of good things but like most things >in life these just dont stack up against a Cisco or Juniper for stability >and reliability. Most of the ISP's I have worked with were HSD but i also >followed the progression path in the industry so i have time with Dial Up, >ADSL/X/...,WISP's, Data Centers etc. and FTTH > >I generally only see these in WISP's and some DSL installs. Never anything >with huge traffic load and full tables. Generally always driven by the >cost >factor alone without regard to much else imho. But that's just my >experience. However maybe there are people that have managed to keep these >up and handle all you have requested. > >just my 2c > > >On Fri, Dec 27, 2013 at 10:00 AM, Dennis Burgess >wrote: > >> We have many with full routing tables. Load balancing, works fine, I >>have >> one site with 8 DSL lines doing balancing across them. We typically >>don't >> use a GRE tunnel, but OpenVPN or IPSEC work great. >> >> >> Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- >> Second Edition" >> Link Technologies, Inc -- Mikrotik & WISP Support >> Services >> Office: 314-735-0270 Website: http://www.linktechs.net - Skype: >> linktechs >> -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE >> - 3G - 3.65 - TV Whitespace >> >> >> -----Original Message----- >> From: matt kelly [mailto:mjkelly at gmail.com] >> Sent: Friday, December 27, 2013 8:41 AM >> To: Raymond Burkholder >> Cc: NANOG list >> Subject: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life >> experiences? >> >> They can not handle a full routing table. The load balancing doesn't >>work. >> They can not properly reassemble fragmented packets, and therefore drop >> all but the first "piece". They can not reliably handle traffic loads >>over >> maybe 200 Mbps, we needed 4-6 Gbps capacity. They can not hold a gre >>tunnel >> connection. >> >> On Dec 27, 2013 9:07 AM, "Raymond Burkholder" >>wrote: >> >> > >> > >My real world experience with these is that they suck. Plain and >>simple. >> > >Don't waste your time. >> > >> > Would you mind elaborating what you were trying to accomplish and what >> > failed? >> > >> > Thank you. >> > >> > Ray >> > >> > >> > -- >> > This message has been scanned for viruses and dangerous content by >> > MailScanner, and is believed to be clean. >> > >> > >> > >> >> > From saku at ytti.fi Tue Dec 31 16:50:11 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 31 Dec 2013 18:50:11 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> Message-ID: <20131231165011.GA24355@pob.ytti.fi> On (2013-12-31 09:03 -0600), Leo Bicknell wrote: > If I were Cisco/Juniper/et all I would have a team working on this right now. > It should be trivial for them to insert code into the routers that say, > hashes all sorts of things (code image, BIOS, any PROMS and EERPOMS and > such on the linecards) and submits all of those signatures back. Any I asked earlier today JTAC (#2013-1231-0033) and JTAC asked SIRT for tool to read BIOS and output SHA2 or SHA3 hash, and such tool does not exist yet. I'm dubious, it might be possible even with existing tools. At least it's possible to reflash the BIOS with stock JunOS, as lot of us had to do due to misformatted SSD disks. But fully agreed some of these sanity checks should be added, it's not cure all, maybe the attack changes the answers before showing them, maybe BIOS comes infected from Juniper or from Kontron. But it would create additional barrier. I also emailed Kontrol and told it would be prudent for them to do press release also. Just to know what their public/official statement is. > I also wonder how this will change engineering going forward. Maybe the > BIOS should be a ROM chip, not an EEPROM again. Maybe the write line needs > to be run through a physical jumper on the motherboard that is normally > not present. We can take page from XBOX360 which is designed to be resistant against attack with physical access. Key idea is that use PKI and hide key in such place where it's difficult to recover, namely, if it's inside modern lithography CPU in read-only, it's just financially unviable vector. MS just goofed and forgot to sign DVD firmware. > Why do we accept our devices, be it a PC or a router, can be "persistently" > infected. The hardware industry needs to do better. I'm still taking all these revelations with grain of salt, until real speciment is dissected. -- ++ytti From rubensk at gmail.com Tue Dec 31 16:54:31 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 31 Dec 2013 14:54:31 -0200 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: References: Message-ID: On Fri, Dec 27, 2013 at 6:47 AM, Martin Hotze wrote: > Hi, > > looking at the specs of Mikrotik Cloud Core Routers it seems to be to good > to be true [1] having so much bang for the bucks. So virtually all smaller > ISPs would drop their CISCO gear for Mikrotik Routerboards. > The issue with RouterOS in general, not restricted to CCR's, is an annoying stuck route bug that seems to persist in 6.x versions. It causes packets to keep flowing to paths that are not working, routing protocols detect it but packets keep going there. Performance-wise, if your traffic is distributed among several ports you can benefit from having a core handling each port, but otherwise you should divide Mikrotik pps numbers to fit your scenario. Rubens From jared at puck.nether.net Tue Dec 31 16:57:15 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 31 Dec 2013 11:57:15 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131231165011.GA24355@pob.ytti.fi> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> <20131231165011.GA24355@pob.ytti.fi> Message-ID: On Dec 31, 2013, at 11:50 AM, Saku Ytti wrote: > I asked earlier today JTAC (#2013-1231-0033) and JTAC asked SIRT for tool to > read BIOS and output SHA2 or SHA3 hash, and such tool does not exist yet. I'm > dubious, it might be possible even with existing tools. At least it's possible > to reflash the BIOS with stock JunOS, as lot of us had to do due to > misformatted SSD disks. > But fully agreed some of these sanity checks should be added, it's not cure > all, maybe the attack changes the answers before showing them, maybe BIOS > comes infected from Juniper or from Kontron. But it would create additional > barrier. > > I also emailed Kontrol and told it would be prudent for them to do press > release also. Just to know what their public/official statement is. Most of the vendors (I think Cisco/Juniper) have many of their staff out on vacation this week. I believe both are doing the "mandatory shutdown" or similar that I've seen other folks do around this season. Arbor networks did something similar as well this year. If you are looking at your hardware, you can get inexpensive flash readers/writers out there. I have one I use when doing low level hardware work. There's also tools for your servers (eg: Flashrom) which are available in your favorite repos/ports/elsewhere and work on Linux/FreeBSD/others. You can use this to typically read/checksum your bios quickly on supported hardware. I'm sure they would love to have the efforts that have gone into this e-mail thread followed-up with hardware/research/contributions to improve the software. It shouldn't be too hard for you to read your bios and load it into ida pro or similar to perform checks. - Jared From saku at ytti.fi Tue Dec 31 17:05:57 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 31 Dec 2013 19:05:57 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <52C2E138.3090409@mitteilung.com> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> <52C2E138.3090409@mitteilung.com> Message-ID: <20131231170557.GA25724@pob.ytti.fi> On (2013-12-31 16:22 +0100), nanog at mitteilung.com wrote: > Since some weeks all my cisco / juniper equipment was replaced with open > source solutions (sometimes with embedded devices) and that works fine. > Google as search engine and Facebook accounts are deleted and some more > things. Cloud solutions outside europe now are forbidden for me. Thank > you NSA & Co. for your "great" work :-( Back in 2008 when Sweden publicly stated that their SIGINT police, 'FRA', starts to spy all traffic coming and going to Swedish borders. Finnish pirate party had two suggestions to this revelation 1) Finland needs own direct fibre connection to Germany, to by-pass Swedish spying -- sounds good, since only those who tell about spying, spy -- germany has flawless recent history record about spying 2) Finland needs goverment operated mandator VPN box in border -- Just like other civilized states, like China and Saudi Arabia. Point I'm making, it's naive to think landscape has changed or that non-implied instances are safer. The most local cloud providers I know personally, and conversely they know me personally, so there is quite high degree of likelyhood for them to come up with reason to access my data. If I'm worried about the data, I should store it myself. If the data is non-encrypted email, there are so many points to intercept it at, make sure it is something that survives being published. If it's encrypted, it does not much matter where you store it, as long as you don't decrypt it there. -- ++ytti From Valdis.Kletnieks at vt.edu Tue Dec 31 17:31:47 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 31 Dec 2013 12:31:47 -0500 Subject: Juniper SSL VPN In-Reply-To: Your message of "Tue, 31 Dec 2013 10:43:02 -0500." References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> Message-ID: <252643.1388511107@turing-police.cc.vt.edu> On Tue, 31 Dec 2013 10:43:02 -0500, Jamie Gwatkin said: > Could be related to this? > http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16290 Do I want to ask why *THIS*? "Estimated Fix Date: Juniper engineering has root caused this issue is working to build and release a ESAP fix as soon as possible. The initial estimated release date for the fix is between 12/31/2013 (PST) and 1/3/2014 (PST). We will update this message regularly with the current status until we resolve this issue." We need an emergency fix because a piece of software unexpectedly hit an end-of-life date? Didn't we learn anything 14 years ago??!? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From josh.hoppes at gmail.com Tue Dec 31 17:37:02 2013 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Tue, 31 Dec 2013 11:37:02 -0600 Subject: turning on comcast v6 In-Reply-To: <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> Message-ID: > Now, boss man comes in and has a new office opening up. Go grab the r1 box > out of the closet, you need to upgrade the code and reconfigure it. Cable > it up to your PC with a serial port, open some some sort of terminal program > so you can catch the boot and password recover it. Plug it's ethernet into > your lan, as you're going to need to tftp down new config, and turn it on. Why are you putting a router that you know needs to be reconfigured onto a production network? This could backfire regardless of IPv6, since you could have a similar issue if the router was performing DHCP from a locally configured pool. If someone did this and complained to me I would tell them they just learned a lesson and now know better then to go connecting equipment with an existing configuration to a production network without doing a full review first. From erey at ernw.de Tue Dec 31 17:49:11 2013 From: erey at ernw.de (Enno Rey) Date: Tue, 31 Dec 2013 18:49:11 +0100 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131231165011.GA24355@pob.ytti.fi> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> <20131231165011.GA24355@pob.ytti.fi> Message-ID: <20131231174911.GA33584@ernw.de> Hi, some approaches were discussed in 2010, by Graeme Neilson from NZ here: https://www.troopers.de/wp-content/uploads/2012/10/TROOPERS10_Netscreen_of_the_Dead_Graeme_Neilson.pdf a later year, at the same conference, he gave a private session demonstrating basically the same stuff for JunOS, as ongoing (and, at the time, non-public) research. happy NYE to everybody Enno On Tue, Dec 31, 2013 at 06:50:11PM +0200, Saku Ytti wrote: > On (2013-12-31 09:03 -0600), Leo Bicknell wrote: > > > If I were Cisco/Juniper/et all I would have a team working on this right now. > > It should be trivial for them to insert code into the routers that say, > > hashes all sorts of things (code image, BIOS, any PROMS and EERPOMS and > > such on the linecards) and submits all of those signatures back. Any > > I asked earlier today JTAC (#2013-1231-0033) and JTAC asked SIRT for tool to > read BIOS and output SHA2 or SHA3 hash, and such tool does not exist yet. I'm > dubious, it might be possible even with existing tools. At least it's possible > to reflash the BIOS with stock JunOS, as lot of us had to do due to > misformatted SSD disks. > But fully agreed some of these sanity checks should be added, it's not cure > all, maybe the attack changes the answers before showing them, maybe BIOS > comes infected from Juniper or from Kontron. But it would create additional > barrier. > > I also emailed Kontrol and told it would be prudent for them to do press > release also. Just to know what their public/official statement is. > > > I also wonder how this will change engineering going forward. Maybe the > > BIOS should be a ROM chip, not an EEPROM again. Maybe the write line needs > > to be run through a physical jumper on the motherboard that is normally > > not present. > > We can take page from XBOX360 which is designed to be resistant against attack > with physical access. Key idea is that use PKI and hide key in such place > where it's difficult to recover, namely, if it's inside modern lithography CPU > in read-only, it's just financially unviable vector. MS just goofed and forgot > to sign DVD firmware. > > > Why do we accept our devices, be it a PC or a router, can be "persistently" > > infected. The hardware industry needs to do better. > > I'm still taking all these revelations with grain of salt, until real > speciment is dissected. > > -- > ++ytti > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de ======================================================= From hardenrm at uchicago.edu Tue Dec 31 18:11:17 2013 From: hardenrm at uchicago.edu (Ryan Harden) Date: Tue, 31 Dec 2013 18:11:17 +0000 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> Message-ID: <56080469-490B-41C3-84F1-765671C87F3E@uchicago.edu> On Dec 31, 2013, at 1:10 AM, Timothy Morizot wrote: > I've been in the process of rolling out IPv6 (again this night) across a > very large, highly conservative, and very bureaucratic enterprise. (Roughly > 100K employees. More than 600 distinct site. Yada. Yada.) I've had no > issues whatsoever implementing the IPv6 RA+DHCPv6 model alongside the IPv4 > model. In fact, the IPv6 model has generally been much more straightforward > and easy to implement. > > So I'm a large enterprise operator, not an ISP. Convince me. Because I > don't see any need. And if I don't, I'm hard-pressed to see why the IETF > would. > > Scott I haven't seen anyone in this thread argue that DHCPv6+RA doesn't work. So we'd all expect that you'd do just fine deploying that way for your large enterprise. The point is that there are some (And based on the thread here and over at IPv6-OPS, not just a couple) operators who wish or are required to do things differently. I remember thinking how stupid it was we had to either statically configure or run DHCPv6 (which a lot of clients didn't support) for the sole purpose of handing out name servers, then we finally got around to RFC6106. There were lots of people who just couldn't understand why you'd ever want your router handing out name servers/dns search lists. Sure DHCPv6 was/is the 'right' and 'clean' way to do it, but it shouldn't be required to make IPv6 functional. Clearly the IETF agreed, eventually. IMO, being able to hand out gateway information based on $criteria via DHCPv6 is a logical feature to ask for. Anyone asking for that isn't trying to tell you that RA is broken, that you're doing things wrong, or that their way of thinking is more important that yours. They're asking for it because they have a business need that would make their deployment of IPv6 easier. Which, IMO, should be the goal of these discussions. How do we make it so deploying IPv6 isn't a pain in the butt? No one is asking to change the world, they're asking for the ability to manage their IPv6 systems the same way they do IPv4. /Ryan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jared at puck.nether.net Tue Dec 31 18:21:15 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 31 Dec 2013 13:21:15 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131231174911.GA33584@ernw.de> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> <20131231165011.GA24355@pob.ytti.fi> <20131231174911.GA33584@ernw.de> Message-ID: <426A5573-05F6-408E-B747-0A78A11984E9@puck.nether.net> On Dec 31, 2013, at 12:49 PM, Enno Rey wrote: > Hi, > > some approaches were discussed in 2010, by Graeme Neilson from NZ here: > > https://www.troopers.de/wp-content/uploads/2012/10/TROOPERS10_Netscreen_of_the_Dead_Graeme_Neilson.pdf > > a later year, at the same conference, he gave a private session demonstrating basically the same stuff for JunOS, as ongoing (and, at the time, non-public) research. > > happy NYE to everybody What I found mildly amusing this summer was most of the outlines of the summer "Snowden" stuff was covered in this book: http://www.amazon.com/dp/B00DNL1AXE/ref=nosim?tag=pucknethernet-20&linkCode=sb1&camp=212353&creative=380549 If you have no plans for tomorrow and like this type of stuff, go ahead and take a quick read :) Much of this stuff isn't new. There have been industry groups working on these supply chain assurance and risk models for years. If you are truly paranoid you will be working with these groups already. Pointers available in private if you want them. - Jared From alh-ietf at tndh.net Tue Dec 31 18:36:28 2013 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 31 Dec 2013 10:36:28 -0800 Subject: turning on comcast v6 In-Reply-To: <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> Message-ID: <042b01cf0657$37bedb50$a73c91f0$@tndh.net> (Yes this is a top post ... get over it) Thank you Leo for doing such a great job in this scenario of explaining why acronym familiarity has much more to do with people's entrenched positions, than the actual network manageability they claim to be worried about. The hyperbolic nonsense in >>> replace every ethernet switch in your entire network with new hardware that supports "RA Guard", and then deploy new configuration on every single port of every single device in your network. Please develop a capital justification plan for Mr MoneyBagsCEO for replacing every switch in your network so you can safely deploy IPv6. <<< , clearly shows that it is the spooky acronym "RA" that is more important to focus on than reality. It also does a nice job of wrapping up the point about why an IPv6 rollout needs a long term plan with appropriate multi-year budgeting. ;) For starters, in the scenario described, you only need 1 port protected, and that is for the person that would be doing the configuration, so it is likely pointless. Do you really believe that dhcp messages picked up by the rogue router wouldn't end up answering with the wrong values and breaking both IPv4 & IPv6? Next, do you really believe that DHCP Guard for an IPv4 aware switch will do anything when an IPv6 DHCP message goes by? Don't you have to replace every switch and reconfigure anyway? Or is rogue DHCP service a problem that goes away with IPv4? Why do people continue to insist that a cornerstone of their network security model is tied to an inherently insecure protocol that was never intended to be used as a security tool? ... but I digress ... There are two very different models for IPv6 address/information allocation, and each needs to be fully functional and independent of the other; period. Unfortunately there have been too many voices demanding a 'one size fits all' approach within the IETF, and we have gotten to the current situation where you need to deploy parts of both models to have a functional network. RFC 6106 is a half-baked concession from the 'dhcp is the only true way' crowd to allow home networks to be functional, but if you want anything more than DNS you have to return to the one-true-way, simply because getting consensus for a more generic dhcp-options container in the RA was not going to happen. The Routing Information DHCP option has been held hostage by those that might be described as a 'dhcp is broken by design' crowd, because many saw that as a bargaining point for consensus around a more feature rich RA. Both hard line positions preventing utility in the other model are wrong, but in the presence of a leadership mantra of one-size-fits-all, neither side was willing to allow complete independent functionality to the other. Making progress on the Routing Information option requires a clear scenario to justify it, because vast swamp of dhcp options that have ever been used in IPv4 are not brought forward without some current usage case. Lee was asking for that input, and while the scenario you paint below might be helped by that option, it presumes that every device on the network has additional configuration to ignore an errant RA sent from the router being configured simply because the network is supposed to using DHCP. The only devices I know of that attempt to ignore an RA are Samsung's Android image which do the stupid thing of configuring an address from the RA on the lan, but refuse to create a routing entry from it if there has ever been a route via the 4G radio. (that is fundamentally a platform bug because google lets them set the knobs that way instead of doing the right thing as a metric bias between the available routes for fall back when one or the other goes away) Ryan's different dhcp answers based on auth state is a use case, and if in widespread use as a way around 1X, it might get enough support by itself to carry the day. If there are other use cases which are not self-contradictory justifications of maintaining acronym familiarity, they will spread the support base and make it easier to get past the objections. This is not about which model is 'right', if anything limiting it is about minimizing the different ways people can hang themselves without realizing the risks beforehand. At the end of the day, the IETF's job is to document technologies so vendors can implement for consistent behavior in independently managed networks. Vendors will build whatever they are paid to build, but if you want generic COTS, then lots of people need to justify a specific behavior with some level of consistency to get that documented as the consensus approach. So far there have not been enough consistent scenarios to get an RI option passed. Tony > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Monday, December 30, 2013 3:25 PM > To: Lee Howard > Cc: Jamie Bowden; North American Network Operators' Group > Subject: Re: turning on comcast v6 > > > On Dec 30, 2013, at 2:49 PM, Lee Howard wrote: > > > I'm not really an advocate for or against DHCP or RAs. I really just > > want to understand what feature is missing. > > I encourage you to try this simple experiment in your lab, because this > happens all day long on corporate networks around the world, and illustrates > the differences quite nicely. While not a complete treatment of the > operational differences, it's an important illustration. > > Configure up a simple network topology of three boxes representing a hub > and spoke network: > > DHCP SVR > | > --lan--r1--wan--hubrtr--wan--r2--lan > > Number it up as expected for both protocols: > > wan links: IPv4 /30, IPv6 /64 > lan links: IPv4 /24, IPv6 /64 > > Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests to > it. Verify a machine plugged into either of the LANs gets a fully functional > network for both protocols. > > Now, take r1 turn it off, and stick it in a closet. You see, that office closed. > Normal every day thing. > > Plug up two PC's to the remaining LAN off r2. This represents your desktop, > and your neighbors desktop. Think Bob from accounting perhaps. Open two > windows on each, one with an IPv4 ping, one with an IPv6 ping running. > > Now, boss man comes in and has a new office opening up. Go grab the r1 > box out of the closet, you need to upgrade the code and reconfigure it. > Cable it up to your PC with a serial port, open some some sort of terminal > program so you can catch the boot and password recover it. Plug it's > ethernet into your lan, as you're going to need to tftp down new config, and > turn it on. > > Here's what you will soon find: > > 1) The IPv6 pings on both machines cease to work. > > 2) The IPv4 network continues to work just fine. > > Now, for even more fun, turn on another PC, say Sally from HR just rebooted > her machine. It will come up in the same state, IPv6 not working, while > IPv4 works just fine. > > Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are > now complaining to him that their network is down, again. Make sure you > not only understand the technical nuances of why the problem above > happened, but also how to explain them to a totally non-technical CEO. > > (Oh yeah, go ahead and unplug r1 to "fix" the problem, and observe how > long until the pings start working again. I think it's 15 minutes, IIRC. For > super-extra credit tell me how to make that time shorter for everyone on > the LAN with Cisco or Juniper commands on r2.) > > I'll give you a hint on understanding this issue. The IETF's grand solution is to > replace every ethernet switch in your entire network with new hardware > that supports "RA Guard", and then deploy new configuration on every > single port of every single device in your network. Please develop a capital > justification plan for Mr MoneyBagsCEO for replacing every switch in your > network so you can safely deploy IPv6. > > Now do you understand why people just want to put the route in DHCPv6 > and move on? > > It's not a "feature" that's different between the two, it's that operationally > they have entirely different attack surfaces and failure modes. And yes, it > involves people doing stupid things. However if the IETF is going to rely on > smart people deploying networking devices we might as well give up and go > home now. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > From fw at deneb.enyo.de Tue Dec 31 18:40:04 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 31 Dec 2013 19:40:04 +0100 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: (Randy Bush's message of "Mon, 30 Dec 2013 12:51:38 -1000") References: Message-ID: <877gak27az.fsf@mid.deneb.enyo.de> * Randy Bush: >> Clay Kossmeyer here from the Cisco PSIRT. > > shoveling kitty litter as fast as you can, eh? > >> http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel > > "The article does not discuss or disclose any Cisco product vulnerabilities." > > this is disengenuous at best. from the nsa document copied in der > spiegel and now many other places: > > "JETPLOW is a firmware persistence implant for Cisco PIX series and > ASA firewalls ..." There's a limit to what can reasonably be called a *product* vulnerability. If you physically plant a bug in a phone, does it exploit a vulnerability in the phone? I don't think so. Theoretically, the manufacturer could have filled it completely with glue. But the next step up is drilling out some of that to place the bug, and then you're looking at tamper evidence, and that's an extremely difficult matter. Routers are expected to be modular, so it's difficult to avoid that they have exposed buses with something that approaches DMA capability. On-site debugging hooks through JTAG ports or similar might be essential to reduce downtime in case of severe problems, so I doubt one can get rid of them. Same for firmware downgrade and recovery options. In the end, the defense has to be political, not technical. "We don't want to do this because it's wrong", and not "we can't do this because it's impossible". After all, what's possible can change very quickly. Appeasement in the form of lawful intercept turned out to be failure: even if you comply, it's likely that your own, domestic intelligence agencies consider your infrastructure, you and your colleagues legitimate targets. From saku at ytti.fi Tue Dec 31 18:48:43 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 31 Dec 2013 20:48:43 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131231174911.GA33584@ernw.de> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <294EC566-90C3-4881-A2A6-A9E8B9211F44@ufp.org> <20131231165011.GA24355@pob.ytti.fi> <20131231174911.GA33584@ernw.de> Message-ID: <20131231184843.GA7127@pob.ytti.fi> On (2013-12-31 18:49 +0100), Enno Rey wrote: > some approaches were discussed in 2010, by Graeme Neilson from NZ here: > > https://www.troopers.de/wp-content/uploads/2012/10/TROOPERS10_Netscreen_of_the_Dead_Graeme_Neilson.pdf > > a later year, at the same conference, he gave a private session demonstrating basically the same stuff for JunOS, as ongoing (and, at the time, non-public) research. If I read that correctly, it requires someone to install malicious code to the box and won't persist if someone upgrades it later to non malicious code. What the screenshot of NSA 'implant' says is persistently broken, through malicious BIOS, which dynamically rewrites kernel in-memory post-boot. The netscreen hack, is cute, but it's rather on the same difficulty level as it is to build savegame editor for game. -- ++ytti From cboyd at gizmopartners.com Tue Dec 31 18:55:10 2013 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 31 Dec 2013 12:55:10 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> <52C242C5.70905@armoredpackets.com> <16074D34-9A9F-4F26-9BBA-8487A7C34327@arbor.net> Message-ID: <926BCC21-EE53-4A6D-86CF-9D0B2164272F@gizmopartners.com> On Dec 31, 2013, at 7:05 AM, Ray Soucy wrote: > I think there needs to be some clarification on how these tools get used, > how often they're used, and if they're ever cleaned up when no longer part > of an active operation. Of course we'll never get that. But that's exactly what we need. Look at CALEA. It has its warts and issues, but the rules are published so everyone knows how the game is played. Even with NSLs, there's apparently some oversight, and you can challenge certain aspects (though it's a long and expensive process). But backdooring gear, servers, BIOS, etc. has no rules. It's just chaos. You don't know if a customer has been targeted, so you can't take appropriate steps. You have no way of knowing if your gear is backdoored or who is using the backdoor. And simply knowing that there is a backdoor will increase the chances that it will be found and used by others. The known threat landscape has been increased by orders of magnitude. --Chris From Valdis.Kletnieks at vt.edu Tue Dec 31 18:58:23 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 31 Dec 2013 13:58:23 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: Your message of "Mon, 30 Dec 2013 19:38:12 -0800." <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> References: <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> <20008d58e92d663db01c3c05a8fe4c83@www.circlenet.us> <9BB77A26-7E80-4671-81B1-3B4979C24A57@arbor.net> <4055C305-ADE1-4765-9B82-F096318862AE@arbor.net> <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net> Message-ID: <259561.1388516303@turing-police.cc.vt.edu> On Mon, 30 Dec 2013 19:38:12 -0800, Sabri Berisha said: > However, attempting any of the limited attacks that I can think of would > require expert-level knowledge of not just the overall architecture, but also > of the microcode that runs on the specific PFE that the attacker would target, Already solved problem, from back in the Internet Stone Age. I remember seeing an exploit that asked you whether the target was SunOS 3.2, patch 1, 2, or 3, and launched the correct attack for each. And I can think of a lot of different ways to make the router cough up the needed info (or you can just brute-force loop over all the options till one works - leave the vendor support guy wondering why that line card rebooted 5 time in an hour and then suddenly became rock solid again :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From cabenth at gmail.com Tue Dec 31 19:00:37 2013 From: cabenth at gmail.com (eric clark) Date: Tue, 31 Dec 2013 11:00:37 -0800 Subject: Why are we fixated on Multimode fiber for high bandwidth communication? Message-ID: I've been working with 40 gig for a few years. When I first ordered a switch, one of the first publicly available with full 40 gig, I was appalled that I was going to have to use 4 pair of multimode fiber for each of my connections. I had planned on using single mode because I can do that with 1 pair. Even today, we're still looking at MM fiber instead of SM, even with the horrendous limitations and cost issues of MM. For instance, if you need to go 301 meters or more, you've got to go OM4 which is very expensive. You have to lay 4 times the number of pairs as SM and when we move to 100G, it'll be even worse because they're still doing things in 6,12,etc... SM can do 100G easily, up to 1K with the lower grade fiber, so in the SM 100G world, you'd be installing 1/12 the strands as you would in multi mode. I just can't figure where this makes sense.... I am aware that single mode has more expensive optics, and I know how much they cost when I first looked at this, but if this were the standard, that price would drop enormously. Anyone know why the industry has their head stuck on MultiMode? From randy at psg.com Tue Dec 31 19:07:05 2013 From: randy at psg.com (Randy Bush) Date: Tue, 31 Dec 2013 09:07:05 -1000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <877gak27az.fsf@mid.deneb.enyo.de> References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: > There's a limit to what can reasonably be called a *product* > vulnerability. right. if the product was wearing a low-cut blouse and a short skirt, it's not. it's weasel words (excuse the idiom). shoveling kitty litter over a big steaming pile. let me insert a second advert for jake's 30c3 preso, https://www.youtube.com/watch?v=b0w36GAyZIA randy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available URL: From jared at puck.nether.net Tue Dec 31 19:08:36 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 31 Dec 2013 14:08:36 -0500 Subject: Why are we fixated on Multimode fiber for high bandwidth communication? In-Reply-To: References: Message-ID: <588C85CB-0E6E-49B0-8328-96C2136E318A@puck.nether.net> On Dec 31, 2013, at 2:00 PM, eric clark wrote: > Anyone know why the industry has their head stuck on MultiMode? at 10G the optics costs are about 1/3 that of SMF (SR vs LR). We tend to keep things SMF, but within many older datacenters MMF is broadly available and does meet the needs at a lower cost. There seems to be a shifting trend as well in UPC vs APC connectors. I think much of this problem is clearly articulated here: http://xkcd.com/927/ Everyones needs are a bit different. - Jared From bicknell at ufp.org Tue Dec 31 19:08:49 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 31 Dec 2013 13:08:49 -0600 Subject: turning on comcast v6 In-Reply-To: <042b01cf0657$37bedb50$a73c91f0$@tndh.net> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <042b01cf0657$37bedb50$a73c91f0$@tndh.net> Message-ID: On Dec 31, 2013, at 12:36 PM, Tony Hain wrote: > likely pointless. Do you really believe that dhcp messages picked up by the > rogue router wouldn't end up answering with the wrong values and breaking > both IPv4 & IPv6? Next, do you really believe that DHCP Guard for an IPv4 > aware switch will do anything when an IPv6 DHCP message goes by? Don't you > have to replace every switch and reconfigure anyway? Or is rogue DHCP > service a problem that goes away with IPv4? Why do people continue to insist > that a cornerstone of their network security model is tied to an inherently > insecure protocol that was never intended to be used as a security tool? ... > but I digress ? In the scenario I described, which I suggest is extremely common, the rogue router will not provide any DHCPv4 client with an address, ever. It is configured to forward to a DHCP sever, and based on the steps I suggested it has no route to reach it. It will forward the packet out its down uplink, and never get a reply. It is in fact 100% benign. Let me repeat, it's 100% benign, and will not affect any users, ever. Yes, if the router has a local DHCP server there would be an issue. But that's not actually very common, most of the people running DHCP want a central server and the logging that goes along with it. I'll admit my scenario was contrived, constructed to specifically show ONE aspect of the problem. It is not the only operational issue, but it is one that is easy for engineers to understand and replicate. However, it's also common. I know multiple people who shot themselves in the foot in this very way, with operational networks. It's not a theoretical problem, it's one that happens every day. Here's another problem that happens every day in data centers and offices. Someone accidentally bridges two VLAN's together for a few minutes by plugging in a cable to the wrong port, realizing it and then unplugging it. In an IPv4+DHCPv4 world the majority of the time the impact is, well, NONE. No hosts notice. Some switches compute a new spanning tree adjacency and some broadcast traffic goes where it shouldn't, but everything remains operational. Do the same with IPv6 and all of the hosts on one of the two VLAN's will instantly stop working. There are controlled environments, like a single tenant data center where a rogue DHCP server is simply not a security concern, but where a tech accidentally bridging VLAN's is a very real possibility. The fact of the matter is that the scale, scope, and impact from a rogue DHCP server is entirely different from a rogue RA server. IPv4+DHCP is operationally much more robust in the face of various scenarios, where as IPv6+RA pretty much always results in near instantaneous 100% failure. > Unfortunately there have been too many voices demanding a 'one size fits > all' approach within the IETF, and we have gotten to the current situation > where you need to deploy parts of both models to have a functional network. > RFC 6106 is a half-baked concession from the 'dhcp is the only true way' > crowd to allow home networks to be functional, but if you want anything more > than DNS you have to return to the one-true-way, simply because getting > consensus for a more generic dhcp-options container in the RA was not going > to happen. The Routing Information DHCP option has been held hostage by > those that might be described as a 'dhcp is broken by design' crowd, because > many saw that as a bargaining point for consensus around a more feature rich > RA. Both hard line positions preventing utility in the other model are > wrong, but in the presence of a leadership mantra of one-size-fits-all, > neither side was willing to allow complete independent functionality to the > other. I think you describe the IETF situation reasonably well. The internal bickering between the "RA camp" and the "DHCP camp" have largely prevented either one from producing something robust. > Making progress on the Routing Information option requires a clear scenario > to justify it, because vast swamp of dhcp options that have ever been used > in IPv4 are not brought forward without some current usage case. Lee was > asking for that input, and while the scenario you paint below might be > helped by that option, it presumes that every device on the network has > additional configuration to ignore an errant RA sent from the router being > configured simply because the network is supposed to using DHCP. This is some extremely circular logic. We can't have DHCP until there are options in devices to ignore RA's. We can't have an option to ignore RA's in devices, because at the moment RA's are the only way to get a default route so it doesn't make sense. Someone has to go first, the other side will follow. I suggest it makes a lot more sense to get working DHCP, before pressuring end-user boxes to have an option or even default to ignoring RA's. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dhubbard at dino.hostasaurus.com Tue Dec 31 19:11:35 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 31 Dec 2013 14:11:35 -0500 Subject: Why are we fixated on Multimode fiber for high bandwidth communication? References: Message-ID: My guess would be it's due to existing cable plants. I've worked at a number of places that have tons of multimode fiber run everywhere. If you can re-terminate and re-use, even if inefficiently, it often beats the time and expense required to run new fiber, especially if it's a place that pulling cable may involve trade unions; that gets very expensive to pull what could be a not so expensive cable one or two hundred meters. -----Original Message----- From: eric clark [mailto:cabenth at gmail.com] Sent: Tuesday, December 31, 2013 2:01 PM To: NANOG list Subject: Why are we fixated on Multimode fiber for high bandwidth communication? I've been working with 40 gig for a few years. When I first ordered a switch, one of the first publicly available with full 40 gig, I was appalled that I was going to have to use 4 pair of multimode fiber for each of my connections. I had planned on using single mode because I can do that with 1 pair. Even today, we're still looking at MM fiber instead of SM, even with the horrendous limitations and cost issues of MM. For instance, if you need to go 301 meters or more, you've got to go OM4 which is very expensive. You have to lay 4 times the number of pairs as SM and when we move to 100G, it'll be even worse because they're still doing things in 6,12,etc... SM can do 100G easily, up to 1K with the lower grade fiber, so in the SM 100G world, you'd be installing 1/12 the strands as you would in multi mode. I just can't figure where this makes sense.... I am aware that single mode has more expensive optics, and I know how much they cost when I first looked at this, but if this were the standard, that price would drop enormously. Anyone know why the industry has their head stuck on MultiMode? From wbailey at satelliteintelligencegroup.com Tue Dec 31 19:16:18 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 31 Dec 2013 19:16:18 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: +1 NSA states very clearly this is baked in and ?widely deployed?. Either Cisco is not very happy with their government overlords today, or they are having long meetings at those oversized conference tables trying to figure out what to tell everyone. I?m curious about the implications to the US DoD STIG?s that are put out, as I?m fairly sure they do not mention there is a backdoor that anyone who knows how to knock can access. My other question is.. How are they identifying unique ASA and PIX? Is there a fingerprint mechanism that tells it what?s going on? I?d think there would be quite a few admins out there with really weird syslog entries?? Randy is right here.. Cisco has some ?splainin to do - we buy these devices as ?security appliances?, not NSA rootkit gateways. I hope the .cn guys don?t figure out what?s going on here, I?d imagine there are plenty of ASA?s in the .gov infrastructures. //warren PS - I mentioned .cn specifically because of the Huawei aspect, in addition to the fact that it has been widely publicized we are in a ?cyber war? with them. On 12/31/13, 12:07 PM, "Randy Bush" wrote: >> There's a limit to what can reasonably be called a *product* >> vulnerability. > >right. if the product was wearing a low-cut blouse and a short skirt, >it's not. > >it's weasel words (excuse the idiom). shoveling kitty litter over a big >steaming pile. > >let me insert a second advert for jake's 30c3 preso, >https://www.youtube.com/watch?v=b0w36GAyZIA > >randy > From web at typo.org Tue Dec 31 19:17:38 2013 From: web at typo.org (Wayne E Bouchard) Date: Tue, 31 Dec 2013 12:17:38 -0700 Subject: Why are we fixated on Multimode fiber for high bandwidth communication? In-Reply-To: <588C85CB-0E6E-49B0-8328-96C2136E318A@puck.nether.net> References: <588C85CB-0E6E-49B0-8328-96C2136E318A@puck.nether.net> Message-ID: <20131231191738.GA38054@wakko.typo.org> Basic economics. MM optics come with looser tolerances and are therefore easier to produce. The wider core of the fiber and higher dispersion allowances also mean that the fiber is easier to make. The fiber, though, is the small end of this equation. The optics are the big one. For those who are buying two or three optics a year, a $150 price difference is no big deal. For those who buy two or three hundred optics every other month, this really makes a difference and those are the ones driving the MM development. -Wayne On Tue, Dec 31, 2013 at 02:08:36PM -0500, Jared Mauch wrote: > > On Dec 31, 2013, at 2:00 PM, eric clark wrote: > > > Anyone know why the industry has their head stuck on MultiMode? > > at 10G the optics costs are about 1/3 that of SMF (SR vs LR). > > We tend to keep things SMF, but within many older datacenters MMF is broadly available and does meet the needs at a lower cost. > > There seems to be a shifting trend as well in UPC vs APC connectors. > > I think much of this problem is clearly articulated here: http://xkcd.com/927/ > > Everyones needs are a bit different. > > - Jared --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From rdobbins at arbor.net Tue Dec 31 19:32:28 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 19:32:28 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: <84EFA6A8-DF71-4C58-A20A-DCEC5499F341@arbor.net> On Jan 1, 2014, at 2:07 AM, Randy Bush wrote: > it's weasel words (excuse the idiom). shoveling kitty litter over a big steaming pile. Clayton is responding to the ability that he's allowed, and he's using words very precisely. Here's Cisco's official responses, so far. I know both Clay and jns quite well, and they're both straight-shooters. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gwood83 at gmail.com Tue Dec 31 19:34:02 2013 From: gwood83 at gmail.com (Jonathan Greenwood II) Date: Tue, 31 Dec 2013 11:34:02 -0800 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: The best response I've seen to all this hype and I completely agree with Scott: "Do ya think that you wouldn't also notice a drastic increase in outbound traffic to begin with? It's fun to watch all the hype and things like that, but to truly sit down and think about what it would actually take to make something like this happen, especially on a sustained and "unnoticed" basis, is just asinine. Perhaps more work should be spent maintaining ones own equipment and network than debating the chances that the sky may actually be falling or the NSA hunting your ass down. ;) Just my two cents for the day! Happy New Year! Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713, CCDE #2009::D, CCNP-Data Center, CCNP-Voice, JNCIE-SP #153, JNCIE-ENT #102, JNCIS-QFX, CISSP, et al. IPv6 Gold Certified Engineer, IPv6 Gold Certified Trainer CCSI #21903, JNCI-SP, JNCI-ENT, JNCI-QFX swm at emanon.com Knowledge is power. Power corrupts. Study hard and be Eeeeviiiil......" Jonathan On Tue, Dec 31, 2013 at 11:16 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > +1 > > NSA states very clearly this is baked in and ?widely deployed?. Either > Cisco is not very happy with their government overlords today, or they are > having long meetings at those oversized conference tables trying to figure > out what to tell everyone. I?m curious about the implications to the US > DoD STIG?s that are put out, as I?m fairly sure they do not mention there > is a backdoor that anyone who knows how to knock can access. > > My other question is.. How are they identifying unique ASA and PIX? Is > there a fingerprint mechanism that tells it what?s going on? I?d think > there would be quite a few admins out there with really weird syslog > entries?? > > Randy is right here.. Cisco has some ?splainin to do - we buy these > devices as ?security appliances?, not NSA rootkit gateways. I hope the .cn > guys don?t figure out what?s going on here, I?d imagine there are plenty > of ASA?s in the .gov infrastructures. > > //warren > > PS - I mentioned .cn specifically because of the Huawei aspect, in > addition to the fact that it has been widely publicized we are in a ?cyber > war? with them. > > On 12/31/13, 12:07 PM, "Randy Bush" wrote: > > >> There's a limit to what can reasonably be called a *product* > >> vulnerability. > > > >right. if the product was wearing a low-cut blouse and a short skirt, > >it's not. > > > >it's weasel words (excuse the idiom). shoveling kitty litter over a big > >steaming pile. > > > >let me insert a second advert for jake's 30c3 preso, > >https://www.youtube.com/watch?v=b0w36GAyZIA > > > >randy > > > > > -- Jonathan Greenwood II CCIE #22744 From rdobbins at arbor.net Tue Dec 31 19:34:45 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 19:34:45 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: On Jan 1, 2014, at 2:16 AM, Warren Bailey wrote: > Randy is right here.. Cisco has some ?splainin to do - we buy these devices as ?security appliances?, not NSA rootkit gateways ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From fw at deneb.enyo.de Tue Dec 31 19:43:59 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 31 Dec 2013 20:43:59 +0100 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: (Randy Bush's message of "Tue, 31 Dec 2013 09:07:05 -1000") References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: <87zjngyfeo.fsf@mid.deneb.enyo.de> * Randy Bush: >> There's a limit to what can reasonably be called a *product* >> vulnerability. > > right. if the product was wearing a low-cut blouse and a short skirt, > it's not. Uh-oh, is this an attempt at an argument based on a "blame the victim" rape analogy? From rdobbins at arbor.net Tue Dec 31 19:44:15 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 31 Dec 2013 19:44:15 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: On Jan 1, 2014, at 2:34 AM, Jonathan Greenwood II wrote: > The best response I've seen to all this hype and I completely agree with > Scott: > > "Do ya think that you wouldn't also notice a drastic increase in outbound traffic to begin with? It's fun to watch all the hype and things like > that, but to truly sit down and think about what it would actually take to make something like this happen, especially on a sustained and > "unnoticed" basis, is just asinine. Hopefully, this drives home the importance of all the various BCPs like iACLs, isolated jump-off boxes for interactive access, config-file management, and network telemetry - including visibility into DCN/OOB traffic. There are open-source tools out there which can be used for these purposes. It doesn't require a lot of capex, mainly opex - i.e., elbow-grease. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bedard.phil at gmail.com Tue Dec 31 19:58:44 2013 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 31 Dec 2013 14:58:44 -0500 Subject: Why are we fixated on Multimode fiber for high bandwidth communication? In-Reply-To: Message-ID: Money, really. The optics and fiber cost is cheaper than SM. The standards around SM optics are to reach relatively long distances, so the transmitters and receivers are more expensive and they use way more power. That being said, I see MM in modern datacenters being used in-rack or very short distances due to the reasoning you mentioned, having to run at least 4 pair for 40G or 12 pair in the case of 100GBase-SR10. I know there are structured cabling solutions for handling the bundles but it sure seems like a pain. QSFP28 will bring 100G back down to 4 pairs of fibers at least for those who want to use MM. There was significant push by Google and others to come up with a shorter-reach 100G SM standard (LR10) because people don't want to use 12-pair MTP cables around their datacenter and LR4 wasn't a good fit. We are pretty much all SM for anything 10G and above as a standard, but have looked at 100GBase-SR10 for short-reach 100G interconnects due to the significant reduction in cost and power compared to 100GBase-LR4. Phil On 12/31/13, 2:00 PM, "eric clark" wrote: >I've been working with 40 gig for a few years. When I first ordered a >switch, one of the first publicly available with full 40 gig, I was >appalled that I was going to have to use 4 pair of multimode fiber for >each >of my connections. I had planned on using single mode because I can do >that >with 1 pair. > >Even today, we're still looking at MM fiber instead of SM, even with the >horrendous limitations and cost issues of MM. For instance, if you need to >go 301 meters or more, you've got to go OM4 which is very expensive. You >have to lay 4 times the number of pairs as SM and when we move to 100G, >it'll be even worse because they're still doing things in 6,12,etc... SM >can do 100G easily, up to 1K with the lower grade fiber, so in the SM 100G >world, you'd be installing 1/12 the strands as you would in multi mode. I >just can't figure where this makes sense.... > >I am aware that single mode has more expensive optics, and I know how much >they cost when I first looked at this, but if this were the standard, that >price would drop enormously. > >Anyone know why the industry has their head stuck on MultiMode? From alh-ietf at tndh.net Tue Dec 31 20:16:06 2013 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 31 Dec 2013 12:16:06 -0800 Subject: turning on comcast v6 In-Reply-To: <56080469-490B-41C3-84F1-765671C87F3E@uchicago.edu> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <56080469-490B-41C3-84F1-765671C87F3E@uchicago.edu> Message-ID: <044c01cf0665$22fa8260$68ef8720$@tndh.net> Ryan Harden wrote: ... > > IMO, being able to hand out gateway information based on $criteria via > DHCPv6 is a logical feature to ask for. Anyone asking for that isn't trying to tell > you that RA is broken, that you're doing things wrong, or that their way of > thinking is more important that yours. They're asking for it because they have > a business need that would make their deployment of IPv6 easier. Which, > IMO, should be the goal of these discussions. How do we make it so > deploying IPv6 isn't a pain in the butt? No one is asking to change the world, > they're asking for the ability to manage their IPv6 systems the same way they > do IPv4. As I said in the response to Leo, this issue has been raised before and couldn't get traction because the combination of a one-size-fits-all mantra from the leadership with concession such that the dhcp model would be self-contained, would have led to the end of the RA model. You are correct, neither way is better, and both need to operate independently or in combination, but getting there requires a clear use case, or many similar cases, to make progress. I believe you are correct in that many people do use the dhcp option to assign the router, but quantifying that is a very difficult task because that community rarely worries about driving standards to get their way. I find that most of this community finds innovative ways to reuse tools defined for a different purpose, but its close enough to accomplish the task at hand while avoiding the cost of getting a vendor to build something specific. That is all fine until the original backer of the tool goes a different direction, and ongoing evolution requires someone to justify its continued support. The scattered community has so many different corner-case uses it is hard to make a clear and quantified need for what the tool should become. The primary reason that this is even a discussion is that the decision was made long ago in the DHCP WG to avoid bringing forward unused baggage from the evolution of IPv4 and dhcp by not bringing any options forward until someone documented an ongoing use for it. That remains the only real requirement I am aware of for getting a dhcp option copied forward from IPv4 to IPv6; document a widespread use case. This one has had an artificial requirement of getting past the dhcp vs. RA model wars, but that would have been, and still is easy enough to beat down with sufficiently documented use. Documented use is where things fail, because we loop back to the point about the people using it don't participate in driving the process to demonstrate how widespread the use actually is, and what specific functionality is being used to make sure the new definition is sufficient. Lee asked the question about use cases, and you were the only one that offered one with substance. Compound that with the point that nobody else jumped in with a 'me too', and the case could be made that you are looking for a standard to be defined around your local deployment choices. Not to say your deployment is isolated, wrong, or shouldn't be considered best-practice, rather that it is hard to demonstrate consensus from a single voice. Besides documenting the use case, it will help to fight off objections by also documenting why this innovative use is deployed rather than another widely deployed choice (in the case you present, why not 802.1X?, not that it is better, just 'why not' ; and I personally consider pre-dated or inconsistent implementations at deployment as a perfect justification, but that is just my take). At the end of the day, if operators don't actively participate in the standards process, the outcome will not match their expectations. Tony From randy at psg.com Tue Dec 31 20:30:25 2013 From: randy at psg.com (Randy Bush) Date: Tue, 31 Dec 2013 10:30:25 -1000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <84EFA6A8-DF71-4C58-A20A-DCEC5499F341@arbor.net> References: <877gak27az.fsf@mid.deneb.enyo.de> <84EFA6A8-DF71-4C58-A20A-DCEC5499F341@arbor.net> Message-ID: >> it's weasel words (excuse the idiom). shoveling kitty litter over a >> big steaming pile. > Clayton is responding to the ability that he's allowed, and he's using > words very precisely. qed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available URL: From sthaug at nethelp.no Tue Dec 31 20:33:52 2013 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 31 Dec 2013 21:33:52 +0100 (CET) Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: Message-ID: <20131231.213352.41731731.sthaug@nethelp.no> > The best response I've seen to all this hype and I completely agree with > Scott: > > "Do ya think that you wouldn't also notice a drastic increase in outbound > traffic to begin with? It's fun to watch all the hype and things like > that, but to truly sit down and think about what it would actually take > to make something like this happen, especially on a sustained and > "unnoticed" basis, is just asinine. A drastic increase, definitely. Smaller increases (say a couple of Mbps on a link normally carrying 100 Mbps or more), doubtful. It all depends on the volume of the information you're looking for. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From fergdawgster at mykolab.com Tue Dec 31 20:42:25 2013 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 31 Dec 2013 12:42:25 -0800 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20131231.213352.41731731.sthaug@nethelp.no> References: <20131231.213352.41731731.sthaug@nethelp.no> Message-ID: <52C32C31.3020205@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/31/2013 12:33 PM, sthaug at nethelp.no wrote: >> The best response I've seen to all this hype and I completely agree with >> Scott: >> >> "Do ya think that you wouldn't also notice a drastic increase in >> outbound traffic to begin with? It's fun to watch all the hype and >> things like that, but to truly sit down and think about what it would >> actually take to make something like this happen, especially on a >> sustained and >> "unnoticed" basis, is just asinine. > > A drastic increase, definitely. Smaller increases (say a couple of Mbps > on a link normally carrying 100 Mbps or more), doubtful. > > It all depends on the volume of the information you're looking for. > More than you know. As someone who has seen firsthand, in real time, an adversary exfiltrate documents and other data out of an organization which he has gained unauthorized internal access -- real professionals know how to blend in with the noise & fly under the radar successfully. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSwywoq1pz9mNUZTMRAtFaAKDrbdnfnnPOP6G0DSRUxK4WmbtGhwCfRaQ/ V7MRFxg+dGwNKZgx4qK0Ogs= =XiSA -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From eugen at imacandi.net Tue Dec 31 21:09:58 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 31 Dec 2013 23:09:58 +0200 Subject: Juniper SSL VPN In-Reply-To: <252643.1388511107@turing-police.cc.vt.edu> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> <252643.1388511107@turing-police.cc.vt.edu> Message-ID: On Tue, Dec 31, 2013 at 7:31 PM, wrote: > On Tue, 31 Dec 2013 10:43:02 -0500, Jamie Gwatkin said: > > Could be related to this? > > http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16290 > > Do I want to ask why *THIS*? > > "Estimated Fix Date: > Juniper engineering has root caused this issue is working to build and > release > a ESAP fix as soon as possible. The initial estimated release date for the > fix > is between 12/31/2013 (PST) and 1/3/2014 (PST). We will update this message > regularly with the current status until we resolve this issue." > > We need an emergency fix because a piece of software unexpectedly hit > an end-of-life date? Didn't we learn anything 14 years ago??!? > > Juniper just posted a technical note saying the issue is fixed and a new ESAP package is out. From Valdis.Kletnieks at vt.edu Tue Dec 31 21:19:24 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 31 Dec 2013 16:19:24 -0500 Subject: Juniper SSL VPN In-Reply-To: Your message of "Tue, 31 Dec 2013 23:09:58 +0200." References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> <252643.1388511107@turing-police.cc.vt.edu> Message-ID: <8543.1388524764@turing-police.cc.vt.edu> On Tue, 31 Dec 2013 23:09:58 +0200, Eugeniu Patrascu said: > > We need an emergency fix because a piece of software unexpectedly hit > > an end-of-life date? Didn't we learn anything 14 years ago??!? > > > > > Juniper just posted a technical note saying the issue is fixed and a new > ESAP package is out. Right. The question is why it's coming out on the last day of December, rather than the last day of November, or even October... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From hardenrm at uchicago.edu Tue Dec 31 21:56:59 2013 From: hardenrm at uchicago.edu (Ryan Harden) Date: Tue, 31 Dec 2013 21:56:59 +0000 Subject: turning on comcast v6 In-Reply-To: <044c01cf0665$22fa8260$68ef8720$@tndh.net> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <56080469-490B-41C3-84F1-765671C87F3E@uchicago.edu> <044c01cf0665$22fa8260$68ef8720$@tndh.net> Message-ID: <722C90A3-FA93-4BB2-A2E4-C9E3003B106C@uchicago.edu> On Dec 31, 2013, at 2:16 PM, Tony Hain wrote: > Ryan Harden wrote: > ... >> >> IMO, being able to hand out gateway information based on $criteria via >> DHCPv6 is a logical feature to ask for. Anyone asking for that isn't > trying to tell >> you that RA is broken, that you're doing things wrong, or that their way > of >> thinking is more important that yours. They're asking for it because they > have >> a business need that would make their deployment of IPv6 easier. Which, >> IMO, should be the goal of these discussions. How do we make it so >> deploying IPv6 isn't a pain in the butt? No one is asking to change the > world, >> they're asking for the ability to manage their IPv6 systems the same way > they >> do IPv4. > > As I said in the response to Leo, this issue has been raised before and > couldn't get traction because the combination of a one-size-fits-all mantra > from the leadership with concession such that the dhcp model would be > self-contained, would have led to the end of the RA model. You are correct, > neither way is better, and both need to operate independently or in > combination, but getting there requires a clear use case, or many similar > cases, to make progress. > > I believe you are correct in that many people do use the dhcp option to > assign the router, but quantifying that is a very difficult task because > that community rarely worries about driving standards to get their way. I > find that most of this community finds innovative ways to reuse tools > defined for a different purpose, but its close enough to accomplish the task > at hand while avoiding the cost of getting a vendor to build something > specific. That is all fine until the original backer of the tool goes a > different direction, and ongoing evolution requires someone to justify its > continued support. The scattered community has so many different corner-case > uses it is hard to make a clear and quantified need for what the tool should > become. > > The primary reason that this is even a discussion is that the decision was > made long ago in the DHCP WG to avoid bringing forward unused baggage from > the evolution of IPv4 and dhcp by not bringing any options forward until > someone documented an ongoing use for it. That remains the only real > requirement I am aware of for getting a dhcp option copied forward from IPv4 > to IPv6; document a widespread use case. This one has had an artificial > requirement of getting past the dhcp vs. RA model wars, but that would have > been, and still is easy enough to beat down with sufficiently documented > use. Documented use is where things fail, because we loop back to the point > about the people using it don't participate in driving the process to > demonstrate how widespread the use actually is, and what specific > functionality is being used to make sure the new definition is sufficient. > > Lee asked the question about use cases, and you were the only one that > offered one with substance. Compound that with the point that nobody else > jumped in with a 'me too', and the case could be made that you are looking > for a standard to be defined around your local deployment choices. Not to > say your deployment is isolated, wrong, or shouldn't be considered > best-practice, rather that it is hard to demonstrate consensus from a single > voice. Besides documenting the use case, it will help to fight off > objections by also documenting why this innovative use is deployed rather > than another widely deployed choice (in the case you present, why not > 802.1X?, not that it is better, just 'why not' ; and I personally consider > pre-dated or inconsistent implementations at deployment as a perfect > justification, but that is just my take). At the end of the day, if > operators don't actively participate in the standards process, the outcome > will not match their expectations. > > Tony > > > Couple things? It should be noted that I don't intend to use DHCPv6 to hand out gateway information. I expect DHCPv6+RA to continue to fulfill my needs. So any notion that I'm trying push anything to meet any local deployment choices can be stopped right there. However, I can understand that some places might and do want to deploy things in the scenario I outlined previously. Some would love to deploy IPv6 but are hamstrung by old processes or tools with stupid assumptions or dependencies. Are the processes stupid? yes, Should they be replaced? absolutely. Is explaining that you need to rebuild your processes and tools to support this IPv6 thing that a very small percentage of your customers have even heard of, let alone asked for easy or likely to get approved? no. I think you are absolutely correct in that the people who are stuck deploying with these scenarios don't participate in the standards process or even know where to start with getting their voice heard. I jumped into this conversation not because I have anything to lose or gain from it, but because I noticed the quick and deliberate efforts to brush it aside. There's the "you're doing it wrong" crowd and the "We already squashed this ten times" crowd. Neither of which are constructive. People (yes most network engineers are people) don't take very well to simply being told they're doing it wrong with the only suggestion of fixing it being to redesign everything they do. And perhaps if the subject keeps getting brought up, the user base requesting such a feature isn't as small as the "we've already squashed this" crowd would like us to believe. I'm frustrated by this whole thing because I only jumped in to provide a hypothetical use case in response to those asking for one. Aside from a few, most quickly responded with "Here's an example of why my network doesn't do that, therefore your use case is invalid" and "sucks to be you, If I were you I'd just not deploy that way". Most (not all) of the opponents already have their minds made up on this matter. No use case will be good enough and no number of requests will be enough to consider it. Perhaps many network operators don't participate in the standards process because they can read the archives and see that most ideas that don't fit the status quo are met with severe opposition by the same handful of people that seem to push everyone else around in their particular area of 'expertise'. I'm happy that this particular issue isn't affecting the deployment of IPv6 here. But if I move on to another job or inherit a network with these constraints, I'd be very happy to have this option as a transitional phase until I could get IPv6 deployed in _my_ ideal way with DHCPv6+RA and tools to match. /Ryan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From james.cutler at consultant.com Tue Dec 31 21:59:57 2013 From: james.cutler at consultant.com (James R Cutler) Date: Tue, 31 Dec 2013 15:59:57 -0600 Subject: turning on comcast v6 In-Reply-To: <56080469-490B-41C3-84F1-765671C87F3E@uchicago.edu> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <56080469-490B-41C3-84F1-765671C87F3E@uchicago.edu> Message-ID: On Dec 31, 2013, at 12:11 PM, Ryan Harden wrote: > On Dec 31, 2013, at 1:10 AM, Timothy Morizot wrote: > >> I've been in the process of rolling out IPv6 (again this night) across a >> very large, highly conservative, and very bureaucratic enterprise. (Roughly >> 100K employees. More than 600 distinct site. Yada. Yada.) I've had no >> issues whatsoever implementing the IPv6 RA+DHCPv6 model alongside the IPv4 >> model. In fact, the IPv6 model has generally been much more straightforward >> and easy to implement. >> >> So I'm a large enterprise operator, not an ISP. Convince me. Because I >> don't see any need. And if I don't, I'm hard-pressed to see why the IETF >> would. >> >> Scott > > I haven't seen anyone in this thread argue that DHCPv6+RA doesn't work. So we'd all expect that you'd do just fine deploying that way for your large enterprise. The point is that there are some (And based on the thread here and over at IPv6-OPS, not just a couple) operators who wish or are required to do things differently. I remember thinking how stupid it was we had to either statically configure or run DHCPv6 (which a lot of clients didn't support) for the sole purpose of handing out name servers, then we finally got around to RFC6106. There were lots of people who just couldn't understand why you'd ever want your router handing out name servers/dns search lists. Sure DHCPv6 was/is the 'right' and 'clean' way to do it, but it shouldn't be required to make IPv6 functional. Clearly the IETF agreed, eventually. > > IMO, being able to hand out gateway information based on $criteria via DHCPv6 is a logical feature to ask for. Anyone asking for that isn't trying to tell you that RA is broken, that you're doing things wrong, or that their way of thinking is more important that yours. They're asking for it because they have a business need that would make their deployment of IPv6 easier. Which, IMO, should be the goal of these discussions. How do we make it so deploying IPv6 isn't a pain in the butt? No one is asking to change the world, they're asking for the ability to manage their IPv6 systems the same way they do IPv4. > > /Ryan Please note that Ryan?s ?manage their IPv6 systems? really means ?run their business?. In many organizations the routing network is managed by a different group with different business goals and procedures than end systems. Allowing flexibility for this, if it is not overwhelmingly costly, is a reasonable goal. On my part, I see adding a default route parameter to DHCPv6 about as earth shaking as adding a default NTP server list. In other words, cut the crap and do it so we can save NANOG electrons and get on with solving more important network problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From streiner at cluebyfour.org Tue Dec 31 18:45:05 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 31 Dec 2013 13:45:05 -0500 (EST) Subject: Why are we fixated on Multimode fiber for high bandwidth communication? In-Reply-To: References: Message-ID: On Tue, 31 Dec 2013, David Hubbard wrote: > My guess would be it's due to existing cable plants. I've worked at a > number of places that have tons of multimode fiber run everywhere. If > you can re-terminate and re-use, even if inefficiently, it often beats > the time and expense required to run new fiber, especially if it's a > place that pulling cable may involve trade unions; that gets very > expensive to pull what could be a not so expensive cable one or two > hundred meters. Playing devil's avocate here... Compared to the cost difference between, say 40G SR equivalent optics and 40G LR equivalent optics, the cost of pulling, terminating, and testing new SMF between two relatively close points is pretty small. I say that with the following qualifier: If you have usable path (conduit, innerduct, rackspace for new termination bays, etc) in place between points A and B. If it turns into a situation where you need to dig to lay in new conduit, that's a different matter altogether. The problem is markedly worse at 100G. DPO-24 is just evil, but the cost difference between 100G SR10, LR4, and ER4 optics is still ridiculous. jms From streiner at cluebyfour.org Tue Dec 31 18:54:05 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 31 Dec 2013 13:54:05 -0500 (EST) Subject: Why are we fixated on Multimode fiber for high bandwidth communication? In-Reply-To: References: Message-ID: On Tue, 31 Dec 2013, Justin M. Streiner wrote: > The problem is markedly worse at 100G. DPO-24 is just evil, but the cost > difference between 100G SR10, LR4, and ER4 optics is still ridiculous. Er... MPO-24. Sorry :) jms From wbailey at satelliteintelligencegroup.com Tue Dec 31 23:04:00 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 31 Dec 2013 23:04:00 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: Explaining, not a denial written by their legal department. I find it insanely difficult to believe cisco systems has a backdoor into some of their product lines with no knowledge or participation. Given the fact that RSA had a check cut for their participation (sell outs..), would it be out of the realm of possibility cisco knowingly placed this into their product line? And would it be their mistake to come out with a ?we had no idea!? rather than ?guys with badges and court orders made us do it!?? Google has some deniability, as their networks were compromised without their knowledge. Placing code into a PC BIOS or IOS image is a far different beast than asking a fiber provider to give a split to a governmental agency. Secret squirrel wires with secret squirrel modulation techniques isn?t a surprise to me, what is a surprise to me is the level of acceptance the IT community has shown thus far on NANOG. On a side note, I found it unbelievable the NSA was so pissed off about aeronautical access being hard to capture. The initial article made it seem like they had already gotten ahold of the data, which would have really pissed me off. If it?s really that difficult, I have a NSA proof satellite platform with capacity should anyone need it.. ;) //warren On 12/31/13, 12:34 PM, "Dobbins, Roland" wrote: > >On Jan 1, 2014, at 2:16 AM, Warren Bailey > wrote: > >> Randy is right here.. Cisco has some ?splainin to do - we buy these >>devices as ?security appliances?, not NSA rootkit gateways > >-organization/> > >o-sr-20131229-der-spiegel> > >----------------------------------------------------------------------- >Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From dwheet at gmail.com Tue Dec 31 17:45:00 2013 From: dwheet at gmail.com (Douglas Wheet) Date: Tue, 31 Dec 2013 09:45:00 -0800 Subject: Comcast/Level3 issues Message-ID: Looking for a networking contact at comcast and/or level3. I've been having some slow speed issues with hitting some sites that's going through level3 and I think there might be some congestion. Doug