From larrysheldon at cox.net Tue Nov 1 03:53:28 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 31 Oct 2016 22:53:28 -0500 Subject: Help interpret a strange traceroute? In-Reply-To: <2KjX1u01X1cZc5601Kjbvc> References: <346d50edd479d7c16a669bd3c02e755b@mailbox.fastserv.com> <2KjX1u01X1cZc5601Kjbvc> Message-ID: <9defe7a7-1157-f427-6311-cdda51baa713@cox.net> On 10/31/2016 14:42, William Herrin wrote: > On Mon, Oct 31, 2016 at 3:33 PM, Randy wrote: >> Any idea how a traceroute (into my network) could end up this fubar'd? >> Discovered this wierd routing while investigating horrendously slow speeds >> (albeit no packet loss) to a particular ISP abroad. > > Hi Randy, > > This is per-packet load balancing. In the forward path the alternates > are different lengths but the traceroute stops as soon as at least one > of the paths reaches the destination. > > The return path is also engaged in per-packet load balancing but the > paths are all the same length. Seems like a lot of bandwidth trying to save bandwidth. Or does that only happen to ICMP? -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account. From Andrew.White2 at charter.com Tue Nov 1 04:14:27 2016 From: Andrew.White2 at charter.com (White, Andrew) Date: Tue, 1 Nov 2016 04:14:27 +0000 Subject: IPv6 automatic reverse DNS In-Reply-To: References: Message-ID: Hi John, Thanks for the info and background. One operational suggestion I have is ? why link synthesis rules to a specific DNS zone? Most larger operators of auth DNS use an IP management tool, like BT Diamond IPAM, BlueCat, or Infoblox. Oftentimes, allocations of IP space will not be on classful boundaries, yet most often reverse DNS zones are on classful boundaries. What may be more operationally useful would be an (optional) feature in auth DNS software that would process an incoming PTR request as follows: 1. Answer the PTR with an entry in the corresponding ip6.arpa or in-addr.arpa zone file if the PTR exists 2. Otherwise, examine a rule set of synthetic PTR responses and answer by the rule set (e.g. 10.0.0.128 matches rule for ?10.0.0.128/27? and returns PTR of 10-0-0-128.dhcp.example.com.) 3. Otherwise, return NXDOMAIN or NOANSWER/NOERROR as appropriate Such a ruleset could apply to forward zones as well to create the matching forward lookup. Just my two cents! Caveat: personal opinion and not the official position of Charter. Andrew ??dr?w Whi?? Charter Network Operations - DAS DNS Desk: 314-394-9594 - Cell: 314-452-4386 andrew.white2 at charter.com From: Woodworth, John R [mailto:John.Woodworth at CenturyLink.com] Sent: Monday, October 31, 2016 11:04 PM To: White, Andrew; 'nanog at nanog.org' Cc: Ballew, Dean; Woodworth, John R Subject: RE: IPv6 automatic reverse DNS -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of White, Andrew > > There are two competing drafts for synthetic rule-based PTR responses > for IPv6 rDNS: > > Howard Lee, Time Warner Cable (now Charter) > https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08 > > J. Woodworth, CenturyLink > https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ > > Nominum and Xerocole/Akamai also have proprietary solutions to this > in their Vantio AuthServ and AuthX products, respectively. > > It seems to me that it is still an open question whether the > recommendations in RFC-1912 that any IP address that accesses the > Internet should have a PTR and matching forward record. My personal > thoughts are that the best solution would be an OPTIONAL standards-based > method of generating DNS responses based on a ruleset if a specific zone > record is not present, and that implementation of that requirement > should be left to the developers of the auth nameserver software. Greetings Andrew, I am new to the group but one of the authors referenced above. My colleagues and I are glad to see the discussion around this issue see some recent movement. As indicated by one of our esteemed WG chairs elsewhere in this thread, I am currently working to provide additional clarity for some of the more difficult concepts in the draft and have not yet requested the next step. Once these changes are complete we will enthusiastically move forward with this request. As I am new to this forum, for the moment I wanted to simply state: synthesized records based on the proposed "bulk rr" method can _only_exist_where_zone_records_do_not_already_. One critical goal of the draft is to make the "intent" of synthesized records easy to transfer between nameservers in authoritative roles. Examples for implementing the draft using fairly straightforward regex manipulation are included but are more of a guideline for making the pattern substitution easier for the implementor and provide a reference for the accompanying examples. Ultimately, as you recommend, the auth nameserver software vendor would be free to provide their own pattern substitution logic (so long as the intent is not lost). DNSSEC for synthesized records also poses its own obvious set of? complications for which we've outlined a number of solutions to help satisfy this challenge. Admittedly, it is a bit of a hefty read but we would love the feedback (directly or in the IETF DNSOP mailing list of course). Thanks, John Woodworth > > Andrew > > Caveat: These thoughts are mine personally and do not represent > any official position of Charter Communications. > > > ??dr?w Whi?? > Charter Network Operations - DAS DNS > Desk: 314-394-9594 ? Cell: 314-452-4386 > andrew.white2 at charter.com > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From josmon at rigozsaurus.com Tue Nov 1 04:27:59 2016 From: josmon at rigozsaurus.com (John Osmon) Date: Mon, 31 Oct 2016 22:27:59 -0600 Subject: Voip faxing In-Reply-To: References: <88BD2EB35BC7983D.6473A1CB-24FC-4B33-9281-7C1BD8E6531B@mail.outlook.com> Message-ID: <20161101042759.GA3853@jeeves.rigozsaurus.com> On Mon, Oct 31, 2016 at 04:52:46AM +0000, Carlos Alcantar wrote: > Hey Samual, > > > you might want to check out the voice ops mailing list, might be a bit more relevant over there. > > > https://puck.nether.net/mailman/listinfo/voiceops Aside from voiceops, here's decade (or more?) old web page that I point people to when they want to deal with Fax over VoIP: http://www.soft-switch.org/foip.html From wolfgang.tremmel at de-cix.net Tue Nov 1 08:35:24 2016 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Tue, 1 Nov 2016 08:35:24 +0000 Subject: Network Maps - Western Europe In-Reply-To: References: <346d50edd479d7c16a669bd3c02e755b@mailbox.fastserv.com> Message-ID: > On 1 Nov 2016, at 00:15, Rod Beck wrote: > > I am trying to determine the physical diversity of the Zayo and Level3 networks vis-a-vis each other on the European racetrack - London/Amsterdam/Frankfurt/Paris/London. It is for a client of mine. try Telegeography.com best regards Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel at de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG K?ln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From dovid at telecurve.com Tue Nov 1 10:59:47 2016 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 1 Nov 2016 06:59:47 -0400 Subject: Help interpret a strange traceroute? In-Reply-To: References: <346d50edd479d7c16a669bd3c02e755b@mailbox.fastserv.com> Message-ID: Does anyone have an IP that involves a load balancing router to test with? On Mon, Oct 31, 2016 at 5:54 PM, Bryan Holloway wrote: > On 10/31/16 4:20 PM, Olivier Benghozi wrote: > >> Hi Randy, >> >> >> ECMP loadbalancing is most frequently done on layer3+layer4 headers, and >> unixlike traceroute use UDP with increasing destination port number for >> each packet (usually starting at 33434), which allows to see the different >> available paths, as wrote William. >> >> Would you want/need to stick to only one traceroute path, you may use >> ICMP traceroute instead of UDP traceroute (no port in ICMP, so only layer 3 >> available to loadbalance, so all packets will go through the same >> interface). >> >> Usually it is achieved by using traceroute -I yourdest >> Windows tracert is ICMP only traceroute by the way. MTR tool is also ICMP >> based by default. >> >> Keep in mind that it looses some useful information, though (since you >> see only one path and don't decide which). >> So, you can also use UDP traceroute with fixed port (by example 33434 >> with no port increase), and try again the same traceroute with another >> destport (with fixed port too, by example 33435), which would display two >> different paths in a more readable way. RTFM is required since the options >> depend on your traceroute particular specie :) >> >> >> Olivier >> >> On 31 oct. 2016 ? 20:42, William Herrin wrote : >>> >>> On Mon, Oct 31, 2016 at 3:33 PM, Randy wrote: >>> >>>> Any idea how a traceroute (into my network) could end up this fubar'd? >>>> Discovered this wierd routing while investigating horrendously slow >>>> speeds >>>> (albeit no packet loss) to a particular ISP abroad. >>>> >>> >>> Hi Randy, >>> >>> This is per-packet load balancing. In the forward path the alternates >>> are different lengths but the traceroute stops as soon as at least one >>> of the paths reaches the destination. >>> >>> The return path is also engaged in per-packet load balancing but the >>> paths are all the same length. >>> >> >> > This is also a handy tool that addresses the same issues: > > https://paris-traceroute.net/ > > From John.Woodworth at CenturyLink.com Tue Nov 1 04:04:20 2016 From: John.Woodworth at CenturyLink.com (Woodworth, John R) Date: Tue, 1 Nov 2016 04:04:20 +0000 Subject: IPv6 automatic reverse DNS Message-ID: -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of White, Andrew > > There are two competing drafts for synthetic rule-based PTR responses > for IPv6 rDNS: > > Howard Lee, Time Warner Cable (now Charter) > https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08 > > J. Woodworth, CenturyLink > https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ > > Nominum and Xerocole/Akamai also have proprietary solutions to this > in their Vantio AuthServ and AuthX products, respectively. > > It seems to me that it is still an open question whether the > recommendations in RFC-1912 that any IP address that accesses the > Internet should have a PTR and matching forward record. My personal > thoughts are that the best solution would be an OPTIONAL standards-based > method of generating DNS responses based on a ruleset if a specific zone > record is not present, and that implementation of that requirement > should be left to the developers of the auth nameserver software. Greetings Andrew, I am new to the group but one of the authors referenced above. My colleagues and I are glad to see the discussion around this issue see some recent movement. As indicated by one of our esteemed WG chairs elsewhere in this thread, I am currently working to provide additional clarity for some of the more difficult concepts in the draft and have not yet requested the next step. Once these changes are complete we will enthusiastically move forward with this request. As I am new to this forum, for the moment I wanted to simply state: synthesized records based on the proposed "bulk rr" method can _only_exist_where_zone_records_do_not_already_. One critical goal of the draft is to make the "intent" of synthesized records easy to transfer between nameservers in authoritative roles. Examples for implementing the draft using fairly straightforward regex manipulation are included but are more of a guideline for making the pattern substitution easier for the implementor and provide a reference for the accompanying examples. Ultimately, as you recommend, the auth nameserver software vendor would be free to provide their own pattern substitution logic (so long as the intent is not lost). DNSSEC for synthesized records also poses its own obvious set of? complications for which we've outlined a number of solutions to help satisfy this challenge. Admittedly, it is a bit of a hefty read but we would love the feedback (directly or in the IETF DNSOP mailing list of course). Thanks, John Woodworth > > Andrew > > Caveat: These thoughts are mine personally and do not represent > any official position of Charter Communications. > > > ??dr?w Whi?? > Charter Network Operations - DAS DNS > Desk: 314-394-9594 ? Cell: 314-452-4386 > andrew.white2 at charter.com > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From John.Woodworth at CenturyLink.com Tue Nov 1 05:11:48 2016 From: John.Woodworth at CenturyLink.com (Woodworth, John R) Date: Tue, 1 Nov 2016 05:11:48 +0000 Subject: IPv6 automatic reverse DNS In-Reply-To: References: Message-ID: > Hi John, > > Thanks for the info and background. > > One operational suggestion I have is ? why link synthesis rules to a > specific DNS zone? > > Most larger operators of auth DNS use an IP management tool, like BT > Diamond IPAM, BlueCat, or Infoblox. Oftentimes, allocations of IP space > will not be on classful boundaries, yet most often reverse DNS zones > are on classful boundaries. > > What may be more operationally useful would be an (optional) feature > in auth DNS software that would process an incoming PTR request as > follows: > > 1. Answer the PTR with an entry in the corresponding ip6.arpa > or in-addr.arpa zone file if the PTR exists > 2. Otherwise, examine a rule set of synthetic PTR responses and > answer by the rule set (e.g. 10.0.0.128 matches rule for > ?10.0.0.128/27? and returns PTR of 10-0-0-128.dhcp.example.com.) > 3. Otherwise, return NXDOMAIN or NOANSWER/NOERROR as appropriate > > Such a ruleset could apply to forward zones as well to create the > matching forward lookup. > Just my two cents! Caveat: personal opinion and not the official > position of Charter. Andrew, Excellent question. Out of necessity we have an in-house federated solution for DNS/DHCP/IP/etc. which solves part of the problem. However, not all data can be managed this way; some more tech-savvy customers expect to manage their own data and transfer it directly to our nameservers for the higher availability, lower latency, tighter security, etc. This then becomes a shared burden at the zone level where, from our perspective, the intent should be easily transferable. I suspect if/when the draft is adopted, other IP management tools may offer the capability of automatically generating the associated "BULK" resource records for the various DNS zones allowing for better interoperability (i.e. "transferability"). One of the draft's features I am most proud of is the concept of superimposed records. This can scale to really huge levels where for example: the RIR could provide patterns for all unclaimed records under "10.in-addr.arpa." which could be overridden by more specific patterns for records under "255.0.10.in-addr.arpa." The DNS ownership now follows the intent of the expected DNS zone owner. If one follows this logic through the ipv6 tree, this concept of ownership becomes even more pronounced. I guess in short, the answer is to maintain the concept of zone ownership :) Thanks, John Woodworth > Andrew > > > ??dr?w Whi?? > Charter Network Operations - DAS DNS > Desk: 314-394-9594 - Cell: 314-452-4386 > andrew.white2 at charter.com > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From sysoleg at yandex.ru Tue Nov 1 18:40:16 2016 From: sysoleg at yandex.ru (Oleg A. Arkhangelsky) Date: Tue, 01 Nov 2016 21:40:16 +0300 Subject: Syn flood to TCP port 21 from priveleged port (80) Message-ID: <5340201478025616@web26o.yandex.ru> From sysoleg at yandex.ru Tue Nov 1 18:44:23 2016 From: sysoleg at yandex.ru (Oleg A. Arkhangelsky) Date: Tue, 01 Nov 2016 21:44:23 +0300 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <5340201478025616@web26o.yandex.ru> References: <5340201478025616@web26o.yandex.ru> Message-ID: <3847611478025863@web35j.yandex.ru> Hello, A couple of cuts from tcpdump output: 21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 1376379765, win 8192, length 0 21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 2254756684, win 8192, length 0 21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 3619475318, win 8192, length 0 21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 2412690982, win 8192, length 0 Does anyone seeing this right now (18:31 UTC)? I see this traffic on at least two completely independent ISPs near Moscow. The rate is about a few dozen PPS hitting all BGP-announced networks. --? wbr, Oleg. "Anarchy is about taking complete responsibility for yourself." ? ? ? Alan Moore. From sysoleg at yandex.ru Tue Nov 1 19:23:42 2016 From: sysoleg at yandex.ru (Oleg A. Arkhangelsky) Date: Tue, 01 Nov 2016 22:23:42 +0300 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <000001d23472$ffbf02f0$ff3d08d0$@truenet.com> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <000001d23472$ffbf02f0$ff3d08d0$@truenet.com> Message-ID: <5600151478028222@web26g.yandex.ru> 01.11.2016, 22:06, "Eric Tykwinski" : > Oleg, > > I'm seeing the same to a single client here source IPs seem to be matching up as well. > I attached a pcap, just so you can compare. > And the same sources: 141.138.128.0 - 141.138.135.255 194.73.173.0 - 194.73.173.127 95.131.184.0 - 95.131.191.255 Massive DDoS against William Hill Organization Ltd? --? wbr, Oleg. "Anarchy is about taking complete responsibility for yourself." ????? Alan Moore. From math at sizone.org Tue Nov 1 19:29:09 2016 From: math at sizone.org (Ken Chase) Date: Tue, 1 Nov 2016 15:29:09 -0400 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <3847611478025863@web35j.yandex.ru> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> Message-ID: <20161101192909.GL29393@sizone.org> seeing an awful lot of port 80 hitting port 21. (Why would port 80 ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts flickering on and off as the service throttled itself at a couple client sites I manage. I see 540 unique source IPs hitting 32 destinations on my network in just 1000 packets dumped on one router. All from multiple sequential registered /24s in whois, but all from one management company: 141.138.128.0/21 and 95.131.184.0/21 role: William Hill Network Services abuse-mailbox: networkservices at williamhill.co.uk address: Infrastructure Services 2 City Walk Sweet Street Leeds LS11 9AR AS49061 course, synfloods can be spoofed... perhaps they're hoping for a retaliation against WHNS. /kc On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: >Hello, > >A couple of cuts from tcpdump output: > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 1376379765, win 8192, length 0 >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 2254756684, win 8192, length 0 >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 3619475318, win 8192, length 0 >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 2412690982, win 8192, length 0 > >Does anyone seeing this right now (18:31 UTC)? I see this traffic >on at least two completely independent ISPs near Moscow. The >rate is about a few dozen PPS hitting all BGP-announced networks. > >--?? >wbr, Oleg. > >"Anarchy is about taking complete responsibility for yourself." >?? ?? ?? Alan Moore. -- Ken Chase - math at sizone.org Guelph Canada From math at sizone.org Tue Nov 1 19:48:19 2016 From: math at sizone.org (Ken Chase) Date: Tue, 1 Nov 2016 15:48:19 -0400 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> Message-ID: <20161101194819.GM29393@sizone.org> Not sure why reflected RSTs are the goal here, they're not much of an amplification to the original syn size. Additionally causing a mild dos of my clients' stuff when it begins throttling # of connections, ie noticeable. (not that i want to help scriptkids improve their attacks...). Im guessing port 80 was chosen for improved fw piercing. Sure is widespread though, 5 clients on very different networks all seeing similar saturation. Someone has a nice complete prescanned list of open ftps for the entire internet out there (or are they just saturating the whole /0?) Easy to filter though: tcp and src port 80 and src net '(141.138.128.0/21 or 95.131.184.0/21)' and dst port 21 Adapt for your fw rules of choice. /kc On Tue, Nov 01, 2016 at 07:39:40PM +0000, Van Dyk, Donovan said: >I think Ken has nailed it. I think the source addresses are spoofed so you reflect the connection (tcp syn ack) to those source addresses. Get enough of those connections and the server is dead. > >Since your port 21 is open > >telnet 109.72.248.114 21 >Trying 109.72.248.114... >Connected to 109.72.248.114. >Escape character is '^]'. > >Your address was probably scanned and saw it could be used in the attack. > >Regards >-- >Donovan Van Dyk > >SOC Network Engineer > >Office: +1.954.620.6002 x911 > >Fort Lauderdale, FL USA > > > > >The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. > > >On 11/1/16, 3:29 PM, "Ken Chase" wrote: > > seeing an awful lot of port 80 hitting port 21. (Why would port 80 > ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts flickering > on and off as the service throttled itself at a couple client sites I manage. > > I see 540 unique source IPs hitting 32 destinations on my network in just 1000 > packets dumped on one router. > > All from multiple sequential registered /24s in whois, but all from one > management company: > > 141.138.128.0/21 and 95.131.184.0/21 > > role: William Hill Network Services > abuse-mailbox: networkservices at williamhill.co.uk > address: Infrastructure Services 2 City Walk Sweet Street Leeds LS11 9AR > > AS49061 > > course, synfloods can be spoofed... perhaps they're hoping for a retaliation > against WHNS. > > /kc > > On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: > >Hello, > > > >A couple of cuts from tcpdump output: > > > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 1376379765, win 8192, length 0 > >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 2254756684, win 8192, length 0 > >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 3619475318, win 8192, length 0 > >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 2412690982, win 8192, length 0 > > > >Does anyone seeing this right now (18:31 UTC)? I see this traffic > >on at least two completely independent ISPs near Moscow. The > >rate is about a few dozen PPS hitting all BGP-announced networks. > > > >--?? > >wbr, Oleg. > > > >"Anarchy is about taking complete responsibility for yourself." > >?? ?? ?? Alan Moore. > -- Ken Chase - math at sizone.org Guelph Canada From emille at abccommunications.com Tue Nov 1 19:52:56 2016 From: emille at abccommunications.com (Emille Blanc) Date: Tue, 1 Nov 2016 12:52:56 -0700 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <20161101192909.GL29393@sizone.org> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> Message-ID: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D57B593F3@exchange> Ditto. Same sources; 141.138.128.0/21 and 95.131.184.0/21 (give or take). Out of 1000 packet sample taken at 12:45:46 PDT (19:45:46 UTC) at boundary, 502 unique sources to 10 destination hosts on our AS. Obligatory data should this be of use to anyone listening in. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase Sent: November-01-16 12:29 PM To: Oleg A. Arkhangelsky Cc: nanog at nanog.org Subject: Re: Syn flood to TCP port 21 from priveleged port (80) seeing an awful lot of port 80 hitting port 21. (Why would port 80 ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts flickering on and off as the service throttled itself at a couple client sites I manage. I see 540 unique source IPs hitting 32 destinations on my network in just 1000 packets dumped on one router. All from multiple sequential registered /24s in whois, but all from one management company: 141.138.128.0/21 and 95.131.184.0/21 role: William Hill Network Services abuse-mailbox: networkservices at williamhill.co.uk address: Infrastructure Services 2 City Walk Sweet Street Leeds LS11 9AR AS49061 course, synfloods can be spoofed... perhaps they're hoping for a retaliation against WHNS. /kc On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: >Hello, > >A couple of cuts from tcpdump output: > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 1376379765, win 8192, length 0 >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 2254756684, win 8192, length 0 >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 3619475318, win 8192, length 0 >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 2412690982, win 8192, length 0 > >Does anyone seeing this right now (18:31 UTC)? I see this traffic >on at least two completely independent ISPs near Moscow. The >rate is about a few dozen PPS hitting all BGP-announced networks. > >--?? >wbr, Oleg. > >"Anarchy is about taking complete responsibility for yourself." >?? ?? ?? Alan Moore. -- Ken Chase - math at sizone.org Guelph Canada From selphie.keller at gmail.com Tue Nov 1 20:13:12 2016 From: selphie.keller at gmail.com (Selphie Keller) Date: Tue, 1 Nov 2016 14:13:12 -0600 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D57B593F3@exchange> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D57B593F3@exchange> Message-ID: Does the synflood have tcp option headers? I am seeing this same activity at our forward observation system, however it's not showing any tcp options like mss,sack,timestamps etc, was curious if others were seeing the same [root at oakridge-intercept(~)]> tcpdump -nn -i eth0 'tcp and (tcp[13] == 2)' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 13:09:32.772506 IP 95.131.190.214.80 > 67.220.207.169.21: Flags [S], seq 3599006989, win 8192, length 0 13:09:32.809446 IP 95.131.185.150.80 > 67.220.207.169.21: Flags [S], seq 2409909072, win 8192, length 0 13:09:33.306737 IP 141.138.133.161.80 > 67.220.207.169.21: Flags [S], seq 1006681302, win 8192, length 0 13:09:33.946427 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq 3627295948, win 8192, length 0 13:09:33.946469 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq 3627295948, win 8192, length 0 13:09:34.263905 IP 194.73.173.103.80 > 67.220.207.170.21: Flags [S], seq 3818041920, win 8192, length 0 13:09:34.415558 IP 194.73.173.243.80 > 67.220.207.169.21: Flags [S], seq 3584410928, win 8192, length 0 On 1 November 2016 at 13:52, Emille Blanc wrote: > Ditto. Same sources; 141.138.128.0/21 and 95.131.184.0/21 (give or take). > > Out of 1000 packet sample taken at 12:45:46 PDT (19:45:46 UTC) at > boundary, 502 unique sources to 10 destination hosts on our AS. > > Obligatory data should this be of use to anyone listening in. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase > Sent: November-01-16 12:29 PM > To: Oleg A. Arkhangelsky > Cc: nanog at nanog.org > Subject: Re: Syn flood to TCP port 21 from priveleged port (80) > > seeing an awful lot of port 80 hitting port 21. (Why would port 80 > ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts > flickering > on and off as the service throttled itself at a couple client sites I > manage. > > I see 540 unique source IPs hitting 32 destinations on my network in just > 1000 > packets dumped on one router. > > All from multiple sequential registered /24s in whois, but all from one > management company: > > 141.138.128.0/21 and 95.131.184.0/21 > > role: William Hill Network Services > abuse-mailbox: networkservices at williamhill.co.uk > address: Infrastructure Services 2 City Walk Sweet Street Leeds > LS11 9AR > > AS49061 > > course, synfloods can be spoofed... perhaps they're hoping for a > retaliation > against WHNS. > > /kc > > On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: > >Hello, > > > >A couple of cuts from tcpdump output: > > > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], > seq 1376379765, win 8192, length 0 > >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], > seq 2254756684, win 8192, length 0 > >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], > seq 3619475318, win 8192, length 0 > >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq > 2412690982, win 8192, length 0 > > > >Does anyone seeing this right now (18:31 UTC)? I see this traffic > >on at least two completely independent ISPs near Moscow. The > >rate is about a few dozen PPS hitting all BGP-announced networks. > > > >--?? > >wbr, Oleg. > > > >"Anarchy is about taking complete responsibility for yourself." > >?? ?? ?? Alan Moore. > > -- > Ken Chase - math at sizone.org Guelph Canada > > From emille at abccommunications.com Tue Nov 1 20:28:54 2016 From: emille at abccommunications.com (Emille Blanc) Date: Tue, 1 Nov 2016 13:28:54 -0700 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D57B593F3@exchange> Message-ID: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D57B59406@exchange> > Does the synflood have tcp option headers? Not seeing any here. From this morning. 12:45:46.180665 194.73.173.17.80 > 216.57.181.189.21: S [tcp sum ok] 1158156467:1158156467(0) win 8192 (DF) (ttl 60, id 18499, len 40) 12:45:46.180667 194.73.173.17.80 > 216.57.181.189.21: S [tcp sum ok] 1158156467:1158156467(0) win 8192 (DF) (ttl 60, id 18499, len 40) 12:45:46.284617 141.138.128.137.80 > 216.57.182.18.21: S [tcp sum ok] 2595766696:2595766696(0) win 8192 (DF) (ttl 69, id 6478, len 40) From: Selphie Keller [mailto:selphie.keller at gmail.com] Sent: November-01-16 1:13 PM To: Emille Blanc Cc: Ken Chase; Oleg A. Arkhangelsky; nanog at nanog.org Subject: Re: Syn flood to TCP port 21 from priveleged port (80) Does the synflood have tcp option headers? I am seeing this same activity at our forward observation system, however it's not showing any tcp options like mss,sack,timestamps etc, was curious if others were seeing the same [root at oakridge-intercept(~)]> tcpdump -nn -i eth0 'tcp and (tcp[13] == 2)' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 13:09:32.772506 IP 95.131.190.214.80 > 67.220.207.169.21: Flags [S], seq 3599006989, win 8192, length 0 13:09:32.809446 IP 95.131.185.150.80 > 67.220.207.169.21: Flags [S], seq 2409909072, win 8192, length 0 13:09:33.306737 IP 141.138.133.161.80 > 67.220.207.169.21: Flags [S], seq 1006681302, win 8192, length 0 13:09:33.946427 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq 3627295948, win 8192, length 0 13:09:33.946469 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq 3627295948, win 8192, length 0 13:09:34.263905 IP 194.73.173.103.80 > 67.220.207.170.21: Flags [S], seq 3818041920, win 8192, length 0 13:09:34.415558 IP 194.73.173.243.80 > 67.220.207.169.21: Flags [S], seq 3584410928, win 8192, length 0 On 1 November 2016 at 13:52, Emille Blanc > wrote: Ditto. Same sources; 141.138.128.0/21 and 95.131.184.0/21 (give or take). Out of 1000 packet sample taken at 12:45:46 PDT (19:45:46 UTC) at boundary, 502 unique sources to 10 destination hosts on our AS. Obligatory data should this be of use to anyone listening in. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase Sent: November-01-16 12:29 PM To: Oleg A. Arkhangelsky Cc: nanog at nanog.org Subject: Re: Syn flood to TCP port 21 from priveleged port (80) seeing an awful lot of port 80 hitting port 21. (Why would port 80 ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts flickering on and off as the service throttled itself at a couple client sites I manage. I see 540 unique source IPs hitting 32 destinations on my network in just 1000 packets dumped on one router. All from multiple sequential registered /24s in whois, but all from one management company: 141.138.128.0/21 and 95.131.184.0/21 role: William Hill Network Services abuse-mailbox: networkservices at williamhill.co.uk address: Infrastructure Services 2 City Walk Sweet Street Leeds LS11 9AR AS49061 course, synfloods can be spoofed... perhaps they're hoping for a retaliation against WHNS. /kc On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: >Hello, > >A couple of cuts from tcpdump output: > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 1376379765, win 8192, length 0 >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 2254756684, win 8192, length 0 >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 3619475318, win 8192, length 0 >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 2412690982, win 8192, length 0 > >Does anyone seeing this right now (18:31 UTC)? I see this traffic >on at least two completely independent ISPs near Moscow. The >rate is about a few dozen PPS hitting all BGP-announced networks. > >--?? >wbr, Oleg. > >"Anarchy is about taking complete responsibility for yourself." >?? ?? ?? Alan Moore. -- Ken Chase - math at sizone.org Guelph Canada From selphie.keller at gmail.com Tue Nov 1 20:40:19 2016 From: selphie.keller at gmail.com (Selphie Keller) Date: Tue, 1 Nov 2016 14:40:19 -0600 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D57B59406@exchange> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D57B593F3@exchange> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D57B59406@exchange> Message-ID: yeah it looks like the person behind the flood may have scanned for active ftp servers, not seeing any activity on other observation subnets of this flood, and so far the only servers showing this port 80 to port 21 is ones that do have actual ftp servers, however, the connection is not actually establishing it's only showing SYN incoming and a SYN-ACK outgoing and never gets a completed 3way handshake, so it could be a very odd reflected syn-ack flood against possible web servers origin ip addresses. On 1 November 2016 at 14:28, Emille Blanc wrote: > > Does the synflood have tcp option headers? > > > > Not seeing any here. From this morning. > > > > 12:45:46.180665 194.73.173.17.80 > 216.57.181.189.21: S [tcp sum ok] > 1158156467:1158156467(0) win 8192 (DF) (ttl 60, id 18499, len 40) > > 12:45:46.180667 194.73.173.17.80 > 216.57.181.189.21: S [tcp sum ok] > 1158156467:1158156467(0) win 8192 (DF) (ttl 60, id 18499, len 40) > > 12:45:46.284617 141.138.128.137.80 > 216.57.182.18.21: S [tcp sum ok] > 2595766696:2595766696(0) win 8192 (DF) (ttl 69, id 6478, len 40) > > > > *From:* Selphie Keller [mailto:selphie.keller at gmail.com] > *Sent:* November-01-16 1:13 PM > *To:* Emille Blanc > *Cc:* Ken Chase; Oleg A. Arkhangelsky; nanog at nanog.org > > *Subject:* Re: Syn flood to TCP port 21 from priveleged port (80) > > > > Does the synflood have tcp option headers? > > > > I am seeing this same activity at our forward observation system, however > it's not showing any tcp options like mss,sack,timestamps etc, was curious > if others were seeing the same > > > > [root at oakridge-intercept(~)]> tcpdump -nn -i eth0 'tcp and (tcp[13] == > 2)' > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes > > > > 13:09:32.772506 IP 95.131.190.214.80 > 67.220.207.169.21: Flags [S], seq > 3599006989, win 8192, length 0 > > 13:09:32.809446 IP 95.131.185.150.80 > 67.220.207.169.21: Flags [S], seq > 2409909072, win 8192, length 0 > > 13:09:33.306737 IP 141.138.133.161.80 > 67.220.207.169.21: Flags [S], seq > 1006681302, win 8192, length 0 > > 13:09:33.946427 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq > 3627295948, win 8192, length 0 > > 13:09:33.946469 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq > 3627295948, win 8192, length 0 > > 13:09:34.263905 IP 194.73.173.103.80 > 67.220.207.170.21: Flags [S], seq > 3818041920, win 8192, length 0 > > 13:09:34.415558 IP 194.73.173.243.80 > 67.220.207.169.21: Flags [S], seq > 3584410928, win 8192, length 0 > > > > > > > > > > On 1 November 2016 at 13:52, Emille Blanc > wrote: > > Ditto. Same sources; 141.138.128.0/21 and 95.131.184.0/21 (give or take). > > Out of 1000 packet sample taken at 12:45:46 PDT (19:45:46 UTC) at > boundary, 502 unique sources to 10 destination hosts on our AS. > > Obligatory data should this be of use to anyone listening in. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ken Chase > Sent: November-01-16 12:29 PM > To: Oleg A. Arkhangelsky > Cc: nanog at nanog.org > Subject: Re: Syn flood to TCP port 21 from priveleged port (80) > > seeing an awful lot of port 80 hitting port 21. (Why would port 80 > ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts > flickering > on and off as the service throttled itself at a couple client sites I > manage. > > I see 540 unique source IPs hitting 32 destinations on my network in just > 1000 > packets dumped on one router. > > All from multiple sequential registered /24s in whois, but all from one > management company: > > 141.138.128.0/21 and 95.131.184.0/21 > > role: William Hill Network Services > abuse-mailbox: networkservices at williamhill.co.uk > address: Infrastructure Services 2 City Walk Sweet Street Leeds > LS11 9AR > > AS49061 > > course, synfloods can be spoofed... perhaps they're hoping for a > retaliation > against WHNS. > > /kc > > On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: > >Hello, > > > >A couple of cuts from tcpdump output: > > > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], > seq 1376379765, win 8192, length 0 > >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], > seq 2254756684, win 8192, length 0 > >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], > seq 3619475318, win 8192, length 0 > >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq > 2412690982, win 8192, length 0 > > > >Does anyone seeing this right now (18:31 UTC)? I see this traffic > >on at least two completely independent ISPs near Moscow. The > >rate is about a few dozen PPS hitting all BGP-announced networks. > > > >--?? > >wbr, Oleg. > > > >"Anarchy is about taking complete responsibility for yourself." > >?? ?? ?? Alan Moore. > > -- > Ken Chase - math at sizone.org Guelph Canada > > > From dvandyk at akamai.com Tue Nov 1 19:39:40 2016 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Tue, 1 Nov 2016 19:39:40 +0000 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <20161101192909.GL29393@sizone.org> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> Message-ID: I think Ken has nailed it. I think the source addresses are spoofed so you reflect the connection (tcp syn ack) to those source addresses. Get enough of those connections and the server is dead. Since your port 21 is open telnet 109.72.248.114 21 Trying 109.72.248.114... Connected to 109.72.248.114. Escape character is '^]'. Your address was probably scanned and saw it could be used in the attack. Regards -- Donovan Van Dyk SOC Network Engineer Office: +1.954.620.6002 x911 Fort Lauderdale, FL USA The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. On 11/1/16, 3:29 PM, "Ken Chase" wrote: seeing an awful lot of port 80 hitting port 21. (Why would port 80 ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts flickering on and off as the service throttled itself at a couple client sites I manage. I see 540 unique source IPs hitting 32 destinations on my network in just 1000 packets dumped on one router. All from multiple sequential registered /24s in whois, but all from one management company: 141.138.128.0/21 and 95.131.184.0/21 role: William Hill Network Services abuse-mailbox: networkservices at williamhill.co.uk address: Infrastructure Services 2 City Walk Sweet Street Leeds LS11 9AR AS49061 course, synfloods can be spoofed... perhaps they're hoping for a retaliation against WHNS. /kc On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: >Hello, > >A couple of cuts from tcpdump output: > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 1376379765, win 8192, length 0 >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 2254756684, win 8192, length 0 >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 3619475318, win 8192, length 0 >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 2412690982, win 8192, length 0 > >Does anyone seeing this right now (18:31 UTC)? I see this traffic >on at least two completely independent ISPs near Moscow. The >rate is about a few dozen PPS hitting all BGP-announced networks. > >--?? >wbr, Oleg. > >"Anarchy is about taking complete responsibility for yourself." >?? ?? ?? Alan Moore. -- Ken Chase - math at sizone.org Guelph Canada From selphie.keller at gmail.com Tue Nov 1 21:59:49 2016 From: selphie.keller at gmail.com (Selphie Keller) Date: Tue, 1 Nov 2016 15:59:49 -0600 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <20161101194819.GM29393@sizone.org> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> <20161101194819.GM29393@sizone.org> Message-ID: Yeah it is an odd ball attack for sure, here is a 5000 packet sample of what I was seeing in connection to this attack https://mystagic.io/80to21.pcap , don't think it's the entire /0 for ftp port as I am not seeing it on many other subnets, which is why I am thinking someone did a pre-scan before conducting this wacky attack, otherwise, I would have likely seen other port 21's seeing activity, but so far any IP that didn't have 21 as an actual service isn't seeing the syn packets. This could be unique to my location, others observing this attack may be able to chime in and report what they are seeing if they seen 80 src syn to port 21 where 21 isn't an actual ftp running. Yeah this is pretty easy to filter. On 1 November 2016 at 13:48, Ken Chase wrote: > Not sure why reflected RSTs are the goal here, they're not much of an > amplification > to the original syn size. Additionally causing a mild dos of my clients' > stuff > when it begins throttling # of connections, ie noticeable. (not that i > want to > help scriptkids improve their attacks...). Im guessing port 80 was chosen > for improved > fw piercing. > > Sure is widespread though, 5 clients on very different networks all seeing > similar > saturation. Someone has a nice complete prescanned list of open ftps for > the > entire internet out there (or are they just saturating the whole /0?) > > Easy to filter though: > > tcp and src port 80 and src net '(141.138.128.0/21 or 95.131.184.0/21)' > and dst port 21 > > Adapt for your fw rules of choice. > > /kc > > > On Tue, Nov 01, 2016 at 07:39:40PM +0000, Van Dyk, Donovan said: > >I think Ken has nailed it. I think the source addresses are spoofed so > you reflect the connection (tcp syn ack) to those source addresses. Get > enough of those connections and the server is dead. > > > >Since your port 21 is open > > > >telnet 109.72.248.114 21 > >Trying 109.72.248.114... > >Connected to 109.72.248.114. > >Escape character is '^]'. > > > >Your address was probably scanned and saw it could be used in the > attack. > > > >Regards > >-- > >Donovan Van Dyk > > > >SOC Network Engineer > > > >Office: +1.954.620.6002 x911 > > > >Fort Lauderdale, FL USA > > > > > > > > > >The information contained in this electronic mail transmission and its > attachments may be privileged and confidential and protected from > disclosure. If the reader of this message is not the intended recipient (or > an individual responsible for delivery of the message to such person), you > are strictly prohibited from copying, disseminating or distributing this > communication. If you have received this communication in error, please > notify the sender immediately and destroy all electronic, paper or other > versions. > > > > > >On 11/1/16, 3:29 PM, "Ken Chase" wrote: > > > > seeing an awful lot of port 80 hitting port 21. (Why would port 80 > > ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" > alerts flickering > > on and off as the service throttled itself at a couple client sites > I manage. > > > > I see 540 unique source IPs hitting 32 destinations on my network > in just 1000 > > packets dumped on one router. > > > > All from multiple sequential registered /24s in whois, but all from > one > > management company: > > > > 141.138.128.0/21 and 95.131.184.0/21 > > > > role: William Hill Network Services > > abuse-mailbox: networkservices at williamhill.co.uk > > address: Infrastructure Services 2 City Walk Sweet Street > Leeds LS11 9AR > > > > AS49061 > > > > course, synfloods can be spoofed... perhaps they're hoping for a > retaliation > > against WHNS. > > > > /kc > > > > On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: > > >Hello, > > > > > >A couple of cuts from tcpdump output: > > > > > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags > [S], seq 1376379765, win 8192, length 0 > > >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags > [S], seq 2254756684, win 8192, length 0 > > >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags > [S], seq 3619475318, win 8192, length 0 > > >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags > [S], seq 2412690982, win 8192, length 0 > > > > > >Does anyone seeing this right now (18:31 UTC)? I see this traffic > > >on at least two completely independent ISPs near Moscow. The > > >rate is about a few dozen PPS hitting all BGP-announced networks. > > > > > >--?? > > >wbr, Oleg. > > > > > >"Anarchy is about taking complete responsibility for yourself." > > >?? ?? ?? Alan Moore. > > > -- > Ken Chase - math at sizone.org Guelph Canada > > From math at sizone.org Tue Nov 1 22:21:26 2016 From: math at sizone.org (Ken Chase) Date: Tue, 1 Nov 2016 18:21:26 -0400 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> <20161101194819.GM29393@sizone.org> Message-ID: <20161101222126.GC1334@sizone.org> what's the density of open port 21s on the planet though? trying to estimate the traffic resulting against the two target /21s. Your dump only has 2 ip's in it though, on your /19 so not representative. My dump is 500 synacks returned in 14 seconds to 32 ips in a /22. This would give 128M ftp responders across the whole /0 (modulo actual space in use, etc, so call it 32M responders?). (It's also a short timespan for a dump as well.) Syn-ack seems to be a 58 byte packet (?ish). 32 * 10^6 * 500/14 * 58*8 / 10^9 = 530 Gbps even if im off by 4 in density of ftp sites on the internet despite my already reducing it by 4, we're talking ~100+ Gbps. /kc On Tue, Nov 01, 2016 at 03:59:49PM -0600, Selphie Keller said: >Yeah it is an odd ball attack for sure, here is a 5000 packet sample of >what I was seeing in connection to this attack >https://mystagic.io/80to21.pcap , don't think it's the entire /0 for ftp >port as I am not seeing it on many other subnets, which is why I am >thinking someone did a pre-scan before conducting this wacky attack, >otherwise, I would have likely seen other port 21's seeing activity, but so >far any IP that didn't have 21 as an actual service isn't seeing the syn >packets. This could be unique to my location, others observing this attack >may be able to chime in and report what they are seeing if they seen 80 src >syn to port 21 where 21 isn't an actual ftp running. Yeah this is pretty >easy to filter. > >On 1 November 2016 at 13:48, Ken Chase wrote: > >> Not sure why reflected RSTs are the goal here, they're not much of an >> amplification >> to the original syn size. Additionally causing a mild dos of my clients' >> stuff >> when it begins throttling # of connections, ie noticeable. (not that i >> want to >> help scriptkids improve their attacks...). Im guessing port 80 was chosen >> for improved >> fw piercing. >> >> Sure is widespread though, 5 clients on very different networks all seeing >> similar >> saturation. Someone has a nice complete prescanned list of open ftps for >> the >> entire internet out there (or are they just saturating the whole /0?) >> >> Easy to filter though: >> >> tcp and src port 80 and src net '(141.138.128.0/21 or 95.131.184.0/21)' >> and dst port 21 >> >> Adapt for your fw rules of choice. >> >> /kc >> >> >> On Tue, Nov 01, 2016 at 07:39:40PM +0000, Van Dyk, Donovan said: >> >I think Ken has nailed it. I think the source addresses are spoofed so >> you reflect the connection (tcp syn ack) to those source addresses. Get >> enough of those connections and the server is dead. >> > >> >Since your port 21 is open >> > >> >telnet 109.72.248.114 21 >> >Trying 109.72.248.114... >> >Connected to 109.72.248.114. >> >Escape character is '^]'. >> > >> >Your address was probably scanned and saw it could be used in the >> attack. >> > >> >Regards >> >-- >> >Donovan Van Dyk >> > >> >SOC Network Engineer >> > >> >Office: +1.954.620.6002 x911 >> > >> >Fort Lauderdale, FL USA >> > >> > >> > >> > >> >The information contained in this electronic mail transmission and its >> attachments may be privileged and confidential and protected from >> disclosure. If the reader of this message is not the intended recipient (or >> an individual responsible for delivery of the message to such person), you >> are strictly prohibited from copying, disseminating or distributing this >> communication. If you have received this communication in error, please >> notify the sender immediately and destroy all electronic, paper or other >> versions. >> > >> > >> >On 11/1/16, 3:29 PM, "Ken Chase" wrote: >> > >> > seeing an awful lot of port 80 hitting port 21. (Why would port 80 >> > ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" >> alerts flickering >> > on and off as the service throttled itself at a couple client sites >> I manage. >> > >> > I see 540 unique source IPs hitting 32 destinations on my network >> in just 1000 >> > packets dumped on one router. >> > >> > All from multiple sequential registered /24s in whois, but all from >> one >> > management company: >> > >> > 141.138.128.0/21 and 95.131.184.0/21 >> > >> > role: William Hill Network Services >> > abuse-mailbox: networkservices at williamhill.co.uk >> > address: Infrastructure Services 2 City Walk Sweet Street >> Leeds LS11 9AR >> > >> > AS49061 >> > >> > course, synfloods can be spoofed... perhaps they're hoping for a >> retaliation >> > against WHNS. >> > >> > /kc >> > >> > On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said: >> > >Hello, >> > > >> > >A couple of cuts from tcpdump output: >> > > >> > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags >> [S], seq 1376379765, win 8192, length 0 >> > >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags >> [S], seq 2254756684, win 8192, length 0 >> > >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags >> [S], seq 3619475318, win 8192, length 0 >> > >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags >> [S], seq 2412690982, win 8192, length 0 >> > > >> > >Does anyone seeing this right now (18:31 UTC)? I see this traffic >> > >on at least two completely independent ISPs near Moscow. The >> > >rate is about a few dozen PPS hitting all BGP-announced networks. >> > > >> > >--?? >> > >wbr, Oleg. >> > > >> > >"Anarchy is about taking complete responsibility for yourself." >> > >?? ?? ?? Alan Moore. >> > -- Ken Chase - math at sizone.org Guelph Canada From israel.lugo at lugosys.com Tue Nov 1 22:32:44 2016 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Tue, 1 Nov 2016 22:32:44 +0000 Subject: netcalc: a tool for aggregating networks, subtracting, and more In-Reply-To: <20161020185949.GK10000@sizone.org> References: <20161020185949.GK10000@sizone.org> Message-ID: Hello, In the spirit of Ken's script below, I've started development of a tool which I called NetCalc: https://github.com/israel-lugo/netcalc (source code) https://pypi.python.org/pypi/netcalc (Python package) Currently, NetCalc allows one to add (aggregate) multiple networks, subtract a network from a larger network, and mix add/subtract operations with an arbitrary mathematical expression. It supports both IPv4 and IPv6, and works very efficiently even with very large networks. It uses the excellent netaddr library for the core address manipulation. Example usage: $ netcalc add 198.18.0.0/24 198.18.1.0/24 10.1/16 10/16 10.0.0.0/15 198.18.0.0/23 $ netcalc sub 192.0.2.0/24 192.0.2.0/28 192.0.2.16/28 192.0.2.32/27 192.0.2.64/26 192.0.2.128/25 $ netcalc expr 2001:db8::/34 - 2001:db8::/38 + 2001:db8:100::/41 2001:db8:100::/41 2001:db8:400::/38 2001:db8:800::/37 2001:db8:1000::/36 2001:db8:2000::/35 More features are planned, this is still just an early release. Right now, things that I can think of being useful: * new command for static information (netmask/bitmask, IP range) * new command for WHOIS queries * new command for splitting a network into smaller networks by prefix length * ability to specify network arguments through a file * ??? The tool is made in Python, and supports both Python 3 (preferred) and Python 2. I'm releasing here with the desire that it will be useful to someone, and hopefully to get some feedback on useful functionality, behavior and so on. Regards, Israel G. Lugo On 10/20/2016 07:59 PM, Ken Chase wrote: > re more general 'network utilities' and scripts: > > http://sizone.org/m/hacks/cidrmath.pl > > adds and removes subnets from networks giving list of remaining/aggregated (sub)nets. > > I couldnt find an online calculator that does this, most are just for 'translation' > from subnet masks<>cidr or cisco inverse masks, etc. > > Wrote it years ago cuz I had an itch. The included perl module populates a > hash entry per ip and I didnt want to write my own, so uses lots of ram+cpu on > big ops (/8 - /9 for eg). But great for earthly operations like /23 - /27 + > /28. > > Yes I should start my own git repo, but i've been lazy. > > No warranties provided. > > If anyone has a faster/better one, that'd be handy. > > /kc > -- > Ken Chase - ken at sizone.org Toronto & Guelph Canada From math at sizone.org Tue Nov 1 23:59:24 2016 From: math at sizone.org (Ken Chase) Date: Tue, 1 Nov 2016 19:59:24 -0400 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <20161101222126.GC1334@sizone.org> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> <20161101194819.GM29393@sizone.org> <20161101222126.GC1334@sizone.org> Message-ID: <20161101235924.GD1334@sizone.org> Most of those networks are served by Prolexic DDOS mitigation (AS 32787), and according to BGPlay have been for a while. (AS carrying untoward material, like a Tor exit node or onion router?) But a couple /24s in the 95.* block are AS14537 Mohawk Internet Tech. in Quebec Canada such as 95.131.188.0/24 - unintended target? (careful who you buy /24's from!) So the only target being affected would be Mohawk unless they're setup to handle it. /kc -- Ken Chase - math at sizone.org Guelph Canada From ryan at finnesey.com Wed Nov 2 03:19:56 2016 From: ryan at finnesey.com (Ryan Finnesey) Date: Wed, 2 Nov 2016 03:19:56 +0000 Subject: DNS Services for a registrar In-Reply-To: References: Message-ID: Thanks everyone for their response. We are going to use the Azure Zone Service. Cheers Ryan From: Matthieu Michaud [mailto:matthieu at nxdomain.fr] Sent: Friday, August 12, 2016 1:34 PM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: DNS Services for a registrar Hi, I have been very happy with route53 while lack of IPv6 support was not an issue for the use case. Did you evaluate CloudFlare in PaaS solution ? Their free plan includes DNS. Best regards, On Fri, Aug 12, 2016 at 7:56 AM, Ryan Finnesey > wrote: We need to provide DNS services for domains we offer as a registrar. We were discussing internally the different options for the deployment. Does anyone see a down side to using IaaS on AWS and Azure? We were also kicking around the idea of a PaaS offering and using Azure DNS or AWS Route 53. Cheers Ryan -- Matthieu MICHAUD From marka at isc.org Wed Nov 2 05:44:22 2016 From: marka at isc.org (Mark Andrews) Date: Wed, 02 Nov 2016 16:44:22 +1100 Subject: DNS Services for a registrar In-Reply-To: Your message of "Wed, 02 Nov 2016 03:19:56 -0000." References: Message-ID: <20161102054422.B47D15895EC3@rock.dv.isc.org> Route 53 have IPv6 now handled out of the .co.uk zones though they still don't do EDNS. Azure also mishandles EDNS. Route 53 returns plain DNS responses when presented with a EDNS(1) query. This breaks validating EDNS(1) clients getting answers from a signed zone. Azure echoes back unknown EDNS options and returns NOERROR NODATA to EDNS(1) queries. This breaks EDNS(1) clients regardless of whether the data is coming from a signed zone or not. It also potentially breaks any client using a EDNS options regardless of the version of EDNS they have in the query. It is server misbehaviour like this that requires clients to whitelist ECS servers. If a DNS COOKIE client is picky it will also break them. EDNS(0) specified how to handle EDNS(1) queries when you only support EDNS(0) back in 1999. It isn't hard to get it right. It also isn't hard to test. Mark harveynorman.com.au. @64.4.48.5 (ns2-05.azure-dns.net.): dns=ok edns=ok edns1=status edns at 512=ok ednsopt=echoed edns1opt=status do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok harveynorman.com.au. @13.107.24.5 (ns3-05.azure-dns.org.): dns=ok edns=ok edns1=status edns at 512=ok ednsopt=echoed edns1opt=status do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok harveynorman.com.au. @40.90.4.5 (ns1-05.azure-dns.com.): dns=ok edns=ok edns1=status edns at 512=ok ednsopt=echoed edns1opt=status do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok harveynorman.com.au. @13.107.160.5 (ns4-05.azure-dns.info.): dns=ok edns=ok edns1=status edns at 512=ok ednsopt=ok edns1opt=status do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok energeticsinstitute.com.au. @205.251.195.234 (ns-1002.awsdns-61.net.): dns=ok edns=ok edns1=status,noopt,soa edns at 512=ok ednsopt=ok edns1opt=status,noopt,soa do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok energeticsinstitute.com.au. @205.251.197.70 (ns-1350.awsdns-40.org.): dns=ok edns=ok edns1=status,noopt,soa edns at 512=ok ednsopt=ok edns1opt=status,noopt,soa do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok energeticsinstitute.com.au. @205.251.192.97 (ns-97.awsdns-12.com.): dns=ok edns=ok edns1=status,noopt,soa edns at 512=ok ednsopt=ok edns1opt=status,noopt,soa do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok energeticsinstitute.com.au. @205.251.198.160 (ns-1696.awsdns-20.co.uk.): dns=ok edns=ok edns1=status,noopt,soa edns at 512=ok ednsopt=ok edns1opt=status,noopt,soa do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok energeticsinstitute.com.au. @2600:9000:5306:a000::1 (ns-1696.awsdns-20.co.uk.): dns=ok edns=ok edns1=status,noopt,soa edns at 512=ok ednsopt=ok edns1opt=status,noopt,soa do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok Mark In message , Ryan Finnesey writes: > Thanks everyone for their response. We are going to use the Azure Zone > Service. > > Cheers > Ryan > > > From: Matthieu Michaud mailto:matthieu at nxdomain.fr > Sent: Friday, August 12, 2016 1:34 PM > To: Ryan Finnesey > Cc: nanog at nanog.org > Subject: Re: DNS Services for a registrar > > Hi, > > I have been very happy with route53 while lack of IPv6 support was not an > issue for the use case. > > Did you evaluate CloudFlare in PaaS solution ? > Their free plan includes DNS. > > Best regards, > > > On Fri, Aug 12, 2016 at 7:56 AM, Ryan Finnesey > > wrote: > We need to provide DNS services for domains we offer as a registrar. We > were discussing internally the different options for the deployment. > Does anyone see a down side to using IaaS on AWS and Azure? > > We were also kicking around the idea of a PaaS offering and using Azure > DNS or AWS Route 53. > > Cheers > Ryan > > > > -- > Matthieu MICHAUD -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Wed Nov 2 07:25:41 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Nov 2016 09:25:41 +0200 Subject: MPLS in the campus Network? In-Reply-To: <20161024201304.GA39078@spider.typo.org> References: <7C7DDF18-2EC7-4414-AC09-9778D8D7B331@arbor.net> <9783dd82-fcc2-1ee2-7a64-d1062e6f2d91@seacom.mu> <9B25E653-391A-4195-ABDA-61FD0350607D@arbor.net> <6a210ce9-6694-86c3-1690-499767d8a669@seacom.mu> <20161024201304.GA39078@spider.typo.org> Message-ID: <6d15ed3c-624f-be83-79e1-0c424f06a64c@seacom.mu> On 24/Oct/16 22:13, Wayne Bouchard wrote: > If the reason for L2 transport is purely customer driven and purely > ptp, then a L2 VPN solution would be better than directly transporting > the frames. If you don't have to bridge it directly, don't. Keep the > core at layer 3 wherever possible. L2 can be very hard to debug when > there are issues. Not sure I understand - are you advocating for EoMPLS (l2vpn) over EoDWDM more often than not, if possible?. Mark. From mark.tinka at seacom.mu Wed Nov 2 07:48:48 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Nov 2016 09:48:48 +0200 Subject: Large BGP Communities beacon in the wild In-Reply-To: <20161027061946.GF37101@Vurt.local> References: <20161011150156.GF4457@hanna.meerval.net> <20161027061946.GF37101@Vurt.local> Message-ID: <68523412-57bb-8137-433c-38c50fafbd92@seacom.mu> On 27/Oct/16 08:19, Job Snijders wrote: > Please verify if you can see 192.147.168.0/24 and 2001:67c:208c::/48 Looks good for me. Both come with: unknown transitive attribute: flag 0xE0 type 0x20 length 0xC value 0000 3CCA 0000 0001 0000 0001 Mark. From lists at chrisk.de Wed Nov 2 08:46:45 2016 From: lists at chrisk.de (Christian Kildau) Date: Wed, 2 Nov 2016 09:46:45 +0100 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: <20161101222126.GC1334@sizone.org> References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> <20161101194819.GM29393@sizone.org> <20161101222126.GC1334@sizone.org> Message-ID: There is some nice research regarding systems "abusable" for reflection by tcp port and the amplification factor depending on the OS: http://www.christian-rossow.de/publications/tcpamplification-woot2014.pdf And in more detail: https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper- kuhrer.pdf Best regards, Chris On Tue, Nov 1, 2016 at 11:21 PM, Ken Chase wrote: > what's the density of open port 21s on the planet though? trying to > estimate > the traffic resulting against the two target /21s. > > Your dump only has 2 ip's in it though, on your /19 so not representative. > > My dump is 500 synacks returned in 14 seconds to 32 ips in a /22. This > would give > 128M ftp responders across the whole /0 (modulo actual space in use, etc, > so call it 32M responders?). (It's also a short timespan for a dump as > well.) > Syn-ack seems to be a 58 byte packet (?ish). > > 32 * 10^6 * 500/14 * 58*8 / 10^9 = 530 Gbps > > even if im off by 4 in density of ftp sites on the internet despite my > already > reducing it by 4, we're talking ~100+ Gbps. > > /kc > > > On Tue, Nov 01, 2016 at 03:59:49PM -0600, Selphie Keller said: > >Yeah it is an odd ball attack for sure, here is a 5000 packet sample of > >what I was seeing in connection to this attack > >https://mystagic.io/80to21.pcap , don't think it's the entire /0 for > ftp > >port as I am not seeing it on many other subnets, which is why I am > >thinking someone did a pre-scan before conducting this wacky attack, > >otherwise, I would have likely seen other port 21's seeing activity, > but so > >far any IP that didn't have 21 as an actual service isn't seeing the syn > >packets. This could be unique to my location, others observing this > attack > >may be able to chime in and report what they are seeing if they seen 80 > src > >syn to port 21 where 21 isn't an actual ftp running. Yeah this is pretty > >easy to filter. > > > >On 1 November 2016 at 13:48, Ken Chase wrote: > > > >> Not sure why reflected RSTs are the goal here, they're not much of an > >> amplification > >> to the original syn size. Additionally causing a mild dos of my > clients' > >> stuff > >> when it begins throttling # of connections, ie noticeable. (not that i > >> want to > >> help scriptkids improve their attacks...). Im guessing port 80 was > chosen > >> for improved > >> fw piercing. > >> > >> Sure is widespread though, 5 clients on very different networks all > seeing > >> similar > >> saturation. Someone has a nice complete prescanned list of open ftps > for > >> the > >> entire internet out there (or are they just saturating the whole /0?) > >> > >> Easy to filter though: > >> > >> tcp and src port 80 and src net '(141.138.128.0/21 or 95.131.184.0/21 > )' > >> and dst port 21 > >> > >> Adapt for your fw rules of choice. > >> > >> /kc > >> > >> > >> On Tue, Nov 01, 2016 at 07:39:40PM +0000, Van Dyk, Donovan said: > >> >I think Ken has nailed it. I think the source addresses are > spoofed so > >> you reflect the connection (tcp syn ack) to those source addresses. > Get > >> enough of those connections and the server is dead. > >> > > >> >Since your port 21 is open > >> > > >> >telnet 109.72.248.114 21 > >> >Trying 109.72.248.114... > >> >Connected to 109.72.248.114. > >> >Escape character is '^]'. > >> > > >> >Your address was probably scanned and saw it could be used in the > >> attack. > >> > > >> >Regards > >> >-- > >> >Donovan Van Dyk > >> > > >> >SOC Network Engineer > >> > > >> >Office: +1.954.620.6002 x911 > >> > > >> >Fort Lauderdale, FL USA > >> > > >> > > >> > > >> > > >> >The information contained in this electronic mail transmission and > its > >> attachments may be privileged and confidential and protected from > >> disclosure. If the reader of this message is not the intended > recipient (or > >> an individual responsible for delivery of the message to such > person), you > >> are strictly prohibited from copying, disseminating or distributing > this > >> communication. If you have received this communication in error, > please > >> notify the sender immediately and destroy all electronic, paper or > other > >> versions. > >> > > >> > > >> >On 11/1/16, 3:29 PM, "Ken Chase" wrote: > >> > > >> > seeing an awful lot of port 80 hitting port 21. (Why would > port 80 > >> > ever be used as source?). Also saw a buncha cpanel "FAILED: > FTP" > >> alerts flickering > >> > on and off as the service throttled itself at a couple client > sites > >> I manage. > >> > > >> > I see 540 unique source IPs hitting 32 destinations on my > network > >> in just 1000 > >> > packets dumped on one router. > >> > > >> > All from multiple sequential registered /24s in whois, but all > from > >> one > >> > management company: > >> > > >> > 141.138.128.0/21 and 95.131.184.0/21 > >> > > >> > role: William Hill Network Services > >> > abuse-mailbox: networkservices at williamhill.co.uk > >> > address: Infrastructure Services 2 City Walk Sweet > Street > >> Leeds LS11 9AR > >> > > >> > AS49061 > >> > > >> > course, synfloods can be spoofed... perhaps they're hoping for > a > >> retaliation > >> > against WHNS. > >> > > >> > /kc > >> > > >> > On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky > said: > >> > >Hello, > >> > > > >> > >A couple of cuts from tcpdump output: > >> > > > >> > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: > Flags > >> [S], seq 1376379765, win 8192, length 0 > >> > >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: > Flags > >> [S], seq 2254756684, win 8192, length 0 > >> > >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: > Flags > >> [S], seq 3619475318, win 8192, length 0 > >> > >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: > Flags > >> [S], seq 2412690982, win 8192, length 0 > >> > > > >> > >Does anyone seeing this right now (18:31 UTC)? I see this > traffic > >> > >on at least two completely independent ISPs near Moscow. The > >> > >rate is about a few dozen PPS hitting all BGP-announced > networks. > >> > > > >> > >--?? > >> > >wbr, Oleg. > >> > > > >> > >"Anarchy is about taking complete responsibility for > yourself." > >> > >?? ?? ?? Alan Moore. > >> > > > -- > Ken Chase - math at sizone.org Guelph Canada > From theodore at ciscodude.net Wed Nov 2 16:13:14 2016 From: theodore at ciscodude.net (Theodore Baschak) Date: Wed, 2 Nov 2016 11:13:14 -0500 Subject: Syn flood to TCP port 21 from priveleged port (80) In-Reply-To: References: <5340201478025616@web26o.yandex.ru> <3847611478025863@web35j.yandex.ru> <20161101192909.GL29393@sizone.org> <20161101194819.GM29393@sizone.org> <20161101222126.GC1334@sizone.org> Message-ID: This might be a little late on this thread, however I just saw the following news item on twitter which seemed pertinent to this story: http://www.theregister.co.uk/2016/11/02/william_hill_ddos/ I guess they're a bookie who's under DDoS? Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ On Wed, Nov 2, 2016 at 3:46 AM, Christian Kildau wrote: > There is some nice research regarding systems "abusable" for reflection by > tcp port and the amplification factor depending on the OS: > http://www.christian-rossow.de/publications/tcpamplification-woot2014.pdf > > And in more detail: > https://www.usenix.org/system/files/conference/ > usenixsecurity14/sec14-paper- > kuhrer.pdf > > Best regards, > Chris > > On Tue, Nov 1, 2016 at 11:21 PM, Ken Chase wrote: > > > what's the density of open port 21s on the planet though? trying to > > estimate > > the traffic resulting against the two target /21s. > > > > Your dump only has 2 ip's in it though, on your /19 so not > representative. > > > > My dump is 500 synacks returned in 14 seconds to 32 ips in a /22. This > > would give > > 128M ftp responders across the whole /0 (modulo actual space in use, etc, > > so call it 32M responders?). (It's also a short timespan for a dump as > > well.) > > Syn-ack seems to be a 58 byte packet (?ish). > > > > 32 * 10^6 * 500/14 * 58*8 / 10^9 = 530 Gbps > > > > even if im off by 4 in density of ftp sites on the internet despite my > > already > > reducing it by 4, we're talking ~100+ Gbps. > > > > /kc > > > > > > On Tue, Nov 01, 2016 at 03:59:49PM -0600, Selphie Keller said: > > >Yeah it is an odd ball attack for sure, here is a 5000 packet sample > of > > >what I was seeing in connection to this attack > > >https://mystagic.io/80to21.pcap , don't think it's the entire /0 for > > ftp > > >port as I am not seeing it on many other subnets, which is why I am > > >thinking someone did a pre-scan before conducting this wacky attack, > > >otherwise, I would have likely seen other port 21's seeing activity, > > but so > > >far any IP that didn't have 21 as an actual service isn't seeing the > syn > > >packets. This could be unique to my location, others observing this > > attack > > >may be able to chime in and report what they are seeing if they seen > 80 > > src > > >syn to port 21 where 21 isn't an actual ftp running. Yeah this is > pretty > > >easy to filter. > > > > > >On 1 November 2016 at 13:48, Ken Chase wrote: > > > > > >> Not sure why reflected RSTs are the goal here, they're not much of > an > > >> amplification > > >> to the original syn size. Additionally causing a mild dos of my > > clients' > > >> stuff > > >> when it begins throttling # of connections, ie noticeable. (not > that i > > >> want to > > >> help scriptkids improve their attacks...). Im guessing port 80 was > > chosen > > >> for improved > > >> fw piercing. > > >> > > >> Sure is widespread though, 5 clients on very different networks all > > seeing > > >> similar > > >> saturation. Someone has a nice complete prescanned list of open ftps > > for > > >> the > > >> entire internet out there (or are they just saturating the whole > /0?) > > >> > > >> Easy to filter though: > > >> > > >> tcp and src port 80 and src net '(141.138.128.0/21 or > 95.131.184.0/21 > > )' > > >> and dst port 21 > > >> > > >> Adapt for your fw rules of choice. > > >> > > >> /kc > > >> > > >> > > >> On Tue, Nov 01, 2016 at 07:39:40PM +0000, Van Dyk, Donovan said: > > >> >I think Ken has nailed it. I think the source addresses are > > spoofed so > > >> you reflect the connection (tcp syn ack) to those source addresses. > > Get > > >> enough of those connections and the server is dead. > > >> > > > >> >Since your port 21 is open > > >> > > > >> >telnet 109.72.248.114 21 > > >> >Trying 109.72.248.114... > > >> >Connected to 109.72.248.114. > > >> >Escape character is '^]'. > > >> > > > >> >Your address was probably scanned and saw it could be used in the > > >> attack. > > >> > > > >> >Regards > > >> >-- > > >> >Donovan Van Dyk > > >> > > > >> >SOC Network Engineer > > >> > > > >> >Office: +1.954.620.6002 x911 > > >> > > > >> >Fort Lauderdale, FL USA > > >> > > > >> > > > >> > > > >> > > > >> >The information contained in this electronic mail transmission > and > > its > > >> attachments may be privileged and confidential and protected from > > >> disclosure. If the reader of this message is not the intended > > recipient (or > > >> an individual responsible for delivery of the message to such > > person), you > > >> are strictly prohibited from copying, disseminating or distributing > > this > > >> communication. If you have received this communication in error, > > please > > >> notify the sender immediately and destroy all electronic, paper or > > other > > >> versions. > > >> > > > >> > > > >> >On 11/1/16, 3:29 PM, "Ken Chase" wrote: > > >> > > > >> > seeing an awful lot of port 80 hitting port 21. (Why would > > port 80 > > >> > ever be used as source?). Also saw a buncha cpanel "FAILED: > > FTP" > > >> alerts flickering > > >> > on and off as the service throttled itself at a couple client > > sites > > >> I manage. > > >> > > > >> > I see 540 unique source IPs hitting 32 destinations on my > > network > > >> in just 1000 > > >> > packets dumped on one router. > > >> > > > >> > All from multiple sequential registered /24s in whois, but > all > > from > > >> one > > >> > management company: > > >> > > > >> > 141.138.128.0/21 and 95.131.184.0/21 > > >> > > > >> > role: William Hill Network Services > > >> > abuse-mailbox: networkservices at williamhill.co.uk > > >> > address: Infrastructure Services 2 City Walk Sweet > > Street > > >> Leeds LS11 9AR > > >> > > > >> > AS49061 > > >> > > > >> > course, synfloods can be spoofed... perhaps they're hoping > for > > a > > >> retaliation > > >> > against WHNS. > > >> > > > >> > /kc > > >> > > > >> > On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. > Arkhangelsky > > said: > > >> > >Hello, > > >> > > > > >> > >A couple of cuts from tcpdump output: > > >> > > > > >> > >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: > > Flags > > >> [S], seq 1376379765, win 8192, length 0 > > >> > >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: > > Flags > > >> [S], seq 2254756684, win 8192, length 0 > > >> > >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: > > Flags > > >> [S], seq 3619475318, win 8192, length 0 > > >> > >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: > > Flags > > >> [S], seq 2412690982, win 8192, length 0 > > >> > > > > >> > >Does anyone seeing this right now (18:31 UTC)? I see this > > traffic > > >> > >on at least two completely independent ISPs near Moscow. > The > > >> > >rate is about a few dozen PPS hitting all BGP-announced > > networks. > > >> > > > > >> > >--?? > > >> > >wbr, Oleg. > > >> > > > > >> > >"Anarchy is about taking complete responsibility for > > yourself." > > >> > >?? ?? ?? Alan Moore. > > >> > > > > > -- > > Ken Chase - math at sizone.org Guelph Canada > > > From randy at psg.com Thu Nov 3 02:39:20 2016 From: randy at psg.com (Randy Bush) Date: Thu, 03 Nov 2016 11:39:20 +0900 Subject: dilemmas Message-ID: the users' dilemma: do you buy a mac today, or wait six month hoping they will fix X (for your particular X)? the sysadmins' dilemma: do you install today's critical update or wait a day until the next one is out before you reboot 50 servers? From bill at herrin.us Thu Nov 3 02:47:24 2016 From: bill at herrin.us (William Herrin) Date: Wed, 2 Nov 2016 22:47:24 -0400 Subject: dilemmas In-Reply-To: References: Message-ID: On Wed, Nov 2, 2016 at 10:39 PM, Randy Bush wrote: > the sysadmins' dilemma: do you install today's critical update or wait a > day until the next one is out before you reboot 50 servers? Neither. You wait for the normal patch cycle because the other six barriers to exploiting the vulnerability will work just fine until then. The vulnerability that cuts through every layer of a well engineered defense is rare. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From royce at techsolvency.com Thu Nov 3 03:03:32 2016 From: royce at techsolvency.com (Royce Williams) Date: Wed, 2 Nov 2016 19:03:32 -0800 Subject: dilemmas In-Reply-To: References: Message-ID: On Wed, Nov 2, 2016 at 6:47 PM, William Herrin wrote: > On Wed, Nov 2, 2016 at 10:39 PM, Randy Bush wrote: > > the sysadmins' dilemma: do you install today's critical update or wait a > > day until the next one is out before you reboot 50 servers? > > Neither. You wait for the normal patch cycle because the other six > barriers to exploiting the vulnerability will work just fine until > then. > > The vulnerability that cuts through every layer of a well engineered > defense is rare. > As is the well-engineered defense. Royce From randy at psg.com Thu Nov 3 03:35:44 2016 From: randy at psg.com (Randy Bush) Date: Thu, 03 Nov 2016 12:35:44 +0900 Subject: dilemmas In-Reply-To: References: Message-ID: On Thu, 03 Nov 2016 12:03:32 +0900, Royce Williams wrote: > On Wed, Nov 2, 2016 at 6:47 PM, William Herrin wrote: >> On Wed, Nov 2, 2016 at 10:39 PM, Randy Bush wrote: >>> the sysadmins' dilemma: do you install today's critical update or >>> wait a day until the next one is out before you reboot 50 servers? >> >> Neither. You wait for the normal patch cycle because the other six >> barriers to exploiting the vulnerability will work just fine until >> then. >> >> The vulnerability that cuts through every layer of a well engineered >> defense is rare. > > As is the well-engineered defense. yep. and thanks for the forward, reminding my why i have a long .procmailrc. From toddunder at gmail.com Thu Nov 3 10:12:39 2016 From: toddunder at gmail.com (Todd Underwood) Date: Thu, 3 Nov 2016 06:12:39 -0400 Subject: dilemmas In-Reply-To: References: Message-ID: randy, On Wed, Nov 2, 2016 at 11:35 PM, Randy Bush wrote: > > yep. and thanks for the forward, reminding my why i have a long > .procmailrc. > if this is an attempt to simply publicly mock someone on the nanog list i have a polite request: keep your snark to yourself. this kind of uncivil behavior is part of what keeps this community so homogenous as it appeals only to people willing to put up with this kind of public nastiness. as someone who i thought supporting increasing diversity in our community, i would expect a higher standard of professionalism and inclusion from you. this may also tend to keep you off of everyone else's increasingly long (but possibly less public) mail filters. apologies if i misunderstood your terse and otherwise apparently content-free missive. cheers, t From nick at foobar.org Thu Nov 3 10:43:54 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 03 Nov 2016 10:43:54 +0000 Subject: dilemmas In-Reply-To: References: Message-ID: <581B14EA.2000301@foobar.org> Randy Bush wrote: > the users' dilemma: do you buy a mac today, or wait six month hoping > they will fix X (for your particular X)? Apparently, they're bringing out an upgraded upgrade soon: > https://blog.pinboard.in/2016/10/benjamin_button_reviews_the_new_macbook_pro/ I'm going to wait for this one before buying. Looks like a much better option than what's on the table right now. Nick From randy at psg.com Thu Nov 3 12:15:21 2016 From: randy at psg.com (Randy Bush) Date: Thu, 03 Nov 2016 21:15:21 +0900 Subject: dilemmas In-Reply-To: <581B14EA.2000301@foobar.org> References: <581B14EA.2000301@foobar.org> Message-ID: >> https://blog.pinboard.in/2016/10/benjamin_button_reviews_the_new_macbook_pro/ > > I'm going to wait for this one before buying. Looks like a much better > option than what's on the table right now. i loved that one! From dave at temk.in Thu Nov 3 19:54:39 2016 From: dave at temk.in (Dave Temkin) Date: Thu, 3 Nov 2016 13:54:39 -0600 Subject: [NANOG-announce] NANOG Registration Fee Changes Message-ID: Greetings, NANOGers- In February 2016, the Board began to review and discuss how best to achieve our stated financial and organizational objectives while ensuring NANOG meetings and associated agendas remain peer reviewed and free of any external financial dependence or influence. NANOG Strategic Goals are: - Maintain Educational 501(c)(3) Non-Profit status - Maintain Membership Policies and Procedures - Maintain tri-annual, peer-reviewed NANOG Conferences - Maintain community email list(s) and archive - Maintain public presentation archives - Adherence to NANOG Financial Controls and Reserve Policy - Ensure funding to provide educational outreach - Continue - Discounted student registration fee - Continue - College Immersion Program - Revised scholarship program (Combine Postel and Fellowship, convert to tuition based) - Revise and reintroduce education courses - Continue to drive increases in member value It is understood that NANOG conferences are, by far, the largest asset of this organization. It is the delivery mechanism for several of the NANOG strategic goals. At the same time, it is also the largest area of concern when planning how best to achieve those goals. The registration fee was last increased in February 2008, while expenses related to producing NANOG meetings have continued to rise with both inflation and breadth of programs and benefits offered. The current meeting registration fee does not cover the cost of producing a NANOG meeting without external funding associated with the NANOG sponsorship program. Thus, in order to maintain our peer reviewed program and funding independence, the following registration fees schedule will apply beginning with NANOG 69: Existing NANOG 69 & Forward - Early: $450 $550 - Standard: $525 $650 - Late: $600 $750 - On-site: $675 $950 The member discount of $25 for all registration fees will continue to apply. The Board is confident that these fees set us on the correct path to adhere to our reserve policy and ensure that the organization is protected in the event that we were faced with unforeseen circumstances. The Board met again after the initial announcement of these registration fee increases at NANOG 68 to review the valuable feedback provided. We decided that it was in the best interests of the organization to move forward with these fee increases immediately and to programatically consider our fees on an annual basis. For the NANOG Board of Directors, Dave Temkin Chair -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From fredrik at i2b.se Thu Nov 3 14:25:20 2016 From: fredrik at i2b.se (Fredrik Holmqvist / I2B) Date: Thu, 03 Nov 2016 13:25:20 -0100 Subject: Google contact needed to help resolve captcha issue Message-ID: Hi. We have a customer who have their /32 IPv6 block captcha blocked, and also their /19 IPv4 have been blocked with captchas. The big issue is that it doesn't help to solve the captchas, there is a new one directly after and solving it gives a new one and so it goes on till you move to Bing do do searches. Even parts of their netblocks that arn't in use are blocked, and have been for 3 weeks now. We have tried to contact google, but no one gets back. There is no useful information on how to solve the issue either. Would be great to have a tool like SPAMhaus or other RBLs, where you as a ISP can see the offending IPs and take care of the problem (if there is one). -- Fredrik Holmqvist I2B (Internet 2 Business) +46-70-740 5033 From carlos at race.com Thu Nov 3 23:03:54 2016 From: carlos at race.com (Carlos Alcantar) Date: Thu, 3 Nov 2016 23:03:54 +0000 Subject: Voip faxing In-Reply-To: <20161101042759.GA3853@jeeves.rigozsaurus.com> References: <88BD2EB35BC7983D.6473A1CB-24FC-4B33-9281-7C1BD8E6531B@mail.outlook.com> , <20161101042759.GA3853@jeeves.rigozsaurus.com> Message-ID: That link shared right there is pretty much gold when it comes to faxing / modems over voip. Thats pretty much what you will get out of any discussion. We have successfully been able to get it to work but we also control the network a-z including the outside plant down to the house. What we have started to notice even when we are passing the calls down into the PSTN through the local interconnect tandems ect people down the line are converting it down to voip. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com ________________________________ From: NANOG on behalf of John Osmon Sent: Monday, October 31, 2016 9:27:59 PM To: nanog at nanog.org Subject: Re: Voip faxing On Mon, Oct 31, 2016 at 04:52:46AM +0000, Carlos Alcantar wrote: > Hey Samual, > > > you might want to check out the voice ops mailing list, might be a bit more relevant over there. > > > https://puck.nether.net/mailman/listinfo/voiceops Aside from voiceops, here's decade (or more?) old web page that I point people to when they want to deal with Fax over VoIP: http://www.soft-switch.org/foip.html From jcurran at arin.net Fri Nov 4 12:34:49 2016 From: jcurran at arin.net (John Curran) Date: Fri, 4 Nov 2016 12:34:49 +0000 Subject: Two upcoming "ARIN on the Road" events - Nashville and Oklahoma City Message-ID: <51BDEB89-83AD-408A-9C11-DCA12720ED41@arin.net> NANOGers - Just a reminder that there are two "ARIN on the Road? events coming up ? in each we will cover a range of registry related topics including DNSSEC, RPKI, ARIN tools and services, and more. We will be in Nashville on 10 November 2016, and Oklahoma City on 8 December 2016. These events are open to all and registration is free. For more information (including venue, agenda, and registration), go to the ARIN Meetings page: https://www.arin.net/participate/meetings/index.html Thanks! /John John Curran President and CEO ARIN From jra at baylink.com Fri Nov 4 17:23:20 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 4 Nov 2016 17:23:20 +0000 (UTC) Subject: 400 N Tampa sells for almost $80M Message-ID: <2023135778.17988.1478280200891.JavaMail.zimbra@baylink.com> The tower is the home of WOW (formerly E-Solutions), which has 2 floors of colo, and about 8 or 9 carriers, making it one of two major carrier hotels in downtown Tampa. As usual, no clue what the new owner's approach will be, though "refurbing and leasing aggressively" is mentioned. If you're in the building, assume they'll cut your fiber at least once. :-) http://www.bizjournals.com/tampabay/news/2016/11/04/downtown-tampas-original-office-tower-sold-for-79.html Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From cscora at apnic.net Fri Nov 4 18:01:48 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Nov 2016 04:01:48 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161104180148.684F4C55A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 05 Nov, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 620869 Prefixes after maximum aggregation (per Origin AS): 221192 Deaggregation factor: 2.81 Unique aggregates announced (without unneeded subnets): 301226 Total ASes present in the Internet Routing Table: 55128 Prefixes per ASN: 11.26 Origin-only ASes present in the Internet Routing Table: 36324 Origin ASes announcing only one prefix: 15345 Transit ASes present in the Internet Routing Table: 6537 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 66 Unregistered ASNs in the Routing Table: 20 Number of 32-bit ASNs allocated by the RIRs: 15993 Number of 32-bit ASNs visible in the Routing Table: 12267 Prefixes from 32-bit ASNs in the Routing Table: 49637 Number of bogon 32-bit ASNs visible in the Routing Table: 298 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 406 Number of addresses announced to Internet: 2830932388 Equivalent to 168 /8s, 188 /16s and 153 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.3 Total number of prefixes smaller than registry allocations: 204079 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156997 Total APNIC prefixes after maximum aggregation: 42889 APNIC Deaggregation factor: 3.66 Prefixes being announced from the APNIC address blocks: 170839 Unique aggregates announced from the APNIC address blocks: 70136 APNIC Region origin ASes present in the Internet Routing Table: 5182 APNIC Prefixes per ASN: 32.97 APNIC Region origin ASes announcing only one prefix: 1148 APNIC Region transit ASes present in the Internet Routing Table: 951 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 35 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2452 Number of APNIC addresses announced to Internet: 759787716 Equivalent to 45 /8s, 73 /16s and 112 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188202 Total ARIN prefixes after maximum aggregation: 89495 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 194343 Unique aggregates announced from the ARIN address blocks: 89058 ARIN Region origin ASes present in the Internet Routing Table: 16147 ARIN Prefixes per ASN: 12.04 ARIN Region origin ASes announcing only one prefix: 5673 ARIN Region transit ASes present in the Internet Routing Table: 1711 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1560 Number of ARIN addresses announced to Internet: 1105588384 Equivalent to 65 /8s, 229 /16s and 240 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 147832 Total RIPE prefixes after maximum aggregation: 72773 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 158624 Unique aggregates announced from the RIPE address blocks: 97522 RIPE Region origin ASes present in the Internet Routing Table: 18143 RIPE Prefixes per ASN: 8.74 RIPE Region origin ASes announcing only one prefix: 7804 RIPE Region transit ASes present in the Internet Routing Table: 3035 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 27 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5084 Number of RIPE addresses announced to Internet: 708868608 Equivalent to 42 /8s, 64 /16s and 122 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 62953 Total LACNIC prefixes after maximum aggregation: 12667 LACNIC Deaggregation factor: 4.97 Prefixes being announced from the LACNIC address blocks: 79261 Unique aggregates announced from the LACNIC address blocks: 37545 LACNIC Region origin ASes present in the Internet Routing Table: 2479 LACNIC Prefixes per ASN: 31.97 LACNIC Region origin ASes announcing only one prefix: 551 LACNIC Region transit ASes present in the Internet Routing Table: 592 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2899 Number of LACNIC addresses announced to Internet: 170795328 Equivalent to 10 /8s, 46 /16s and 33 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15181 Total AfriNIC prefixes after maximum aggregation: 3360 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 17396 Unique aggregates announced from the AfriNIC address blocks: 6595 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 23.64 AfriNIC Region origin ASes announcing only one prefix: 169 AfriNIC Region transit ASes present in the Internet Routing Table: 179 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 272 Number of AfriNIC addresses announced to Internet: 85496064 Equivalent to 5 /8s, 24 /16s and 145 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3598 382 248 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2957 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2705 1498 535 BSNL-NIB National Internet Backbone, IN 4766 2696 11132 739 KIXS-AS-KR Korea Telecom, KR 9808 2229 8698 32 CMNET-GD Guangdong Mobile Communication 4755 2049 428 215 TATACOMM-AS TATA Communications formerl 4808 1747 2290 510 CHINA169-BJ China Unicom Beijing Provin 45899 1609 1240 95 VNPT-AS-VN VNPT Corp, VN 24560 1562 532 229 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3550 2965 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3234 1333 82 SHAW - Shaw Communications Inc., CA 18566 2197 405 110 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1948 2003 406 CHARTER-NET-HKY-NC - Charter Communicat 30036 1776 339 343 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1731 5067 655 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1678 848 227 ITCDELTA - Earthlink, Inc., US 701 1611 10642 669 UUNET - MCI Communications Services, In 7018 1483 20476 1049 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3330 170 16 ALJAWWALSTC-AS , SA 20940 2885 1087 2046 AKAMAI-ASN1 , US 34984 1989 326 360 TELLCOM-AS , TR 13188 1624 99 58 TRIOLAN , UA 12479 1383 1018 49 UNI2-AS , ES 8551 1202 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 6849 1142 355 21 UKRTELNET , UA 8402 1126 544 15 CORBINA-AS OJSC "Vimpelcom", RU 9198 979 352 25 KAZTELECOM-AS , KZ 12389 949 1133 423 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3536 546 140 Telmex Colombia S.A., CO 8151 2288 3364 552 Uninet S.A. de C.V., MX 7303 1533 963 248 Telecom Argentina S.A., AR 6503 1485 437 54 Axtel, S.A.B. de C.V., MX 11830 1351 368 66 Instituto Costarricense de Electricidad 6147 1294 377 28 Telefonica del Peru S.A.A., PE 7738 1018 1882 40 Telemar Norte Leste S.A., BR 28573 1006 2263 171 CLARO S.A., BR 3816 981 473 194 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 906 126 76 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1187 402 50 LINKdotNET-AS, EG 36903 680 342 128 MT-MPLS, MA 37611 673 67 6 Afrihost, ZA 36992 567 1373 25 ETISALAT-MISR, EG 8452 495 1472 15 TE-AS TE-AS, EG 24835 412 624 19 RAYA-AS, EG 37492 388 254 70 ORANGE-TN, TN 29571 365 37 12 CITelecom-AS, CI 15399 309 35 6 WANANCHI-KE, KE 36974 274 139 10 AFNET-AS, CI Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3598 382 248 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3550 2965 146 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3536 546 140 Telmex Colombia S.A., CO 39891 3330 170 16 ALJAWWALSTC-AS , SA 6327 3234 1333 82 SHAW - Shaw Communications Inc., CA 17974 2957 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2885 1087 2046 AKAMAI-ASN1 , US 9829 2705 1498 535 BSNL-NIB National Internet Backbone, IN 4766 2696 11132 739 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3550 3404 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3536 3396 Telmex Colombia S.A., CO 7545 3598 3350 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3330 3314 ALJAWWALSTC-AS , SA 6327 3234 3152 SHAW - Shaw Communications Inc., CA 17974 2957 2886 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2229 2197 CMNET-GD Guangdong Mobile Communication 9829 2705 2170 BSNL-NIB National Internet Backbone, IN 18566 2197 2087 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 2056 BELLSOUTH-NET-BLK - BellSouth.net Inc., Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 64855 PRIVATE 41.220.200.0/21 36945 mcelISP, MZ 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.110.192.0/22 45664 UNKNOWN 27.110.196.0/22 45664 UNKNOWN 27.110.200.0/22 45664 UNKNOWN 27.110.204.0/22 45664 UNKNOWN 27.110.224.0/22 45664 UNKNOWN 27.110.232.0/22 45664 UNKNOWN 27.110.248.0/22 45664 UNKNOWN 27.110.252.0/22 45664 UNKNOWN 41.73.1.0/24 37004 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:102 /12:274 /13:522 /14:1049 /15:1783 /16:13143 /17:7856 /18:13061 /19:25498 /20:38815 /21:40647 /22:71951 /23:60270 /24:344606 /25:450 /26:346 /27:292 /28:59 /29:34 /30:13 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3031 3234 SHAW - Shaw Communications Inc., CA 39891 2896 3330 ALJAWWALSTC-AS , SA 22773 2768 3550 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2089 2197 MEGAPATH5-US - MegaPath Corporation, US 30036 1590 1776 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1441 3536 Telmex Colombia S.A., CO 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1364 1624 TRIOLAN , UA 6983 1324 1678 ITCDELTA - Earthlink, Inc., US 34984 1273 1989 TELLCOM-AS , TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1556 2:812 4:23 5:2236 6:32 8:1000 12:1804 13:50 14:1748 15:46 16:2 17:103 18:126 20:48 23:1919 24:1810 27:2370 31:1799 32:83 33:4 35:3 36:346 37:2392 38:1300 39:39 40:100 41:2914 42:447 43:1879 44:48 45:2218 46:2602 47:105 49:1191 50:929 51:14 52:557 53:2 54:351 55:7 56:4 57:40 58:1584 59:992 60:379 61:1841 62:1521 63:1927 64:4572 65:2180 66:4329 67:2253 68:1141 69:3301 70:1291 71:563 72:2062 74:2590 75:404 76:414 77:1428 78:1311 79:914 80:1305 81:1396 82:984 83:708 84:868 85:1589 86:475 87:1127 88:565 89:2047 90:223 91:6123 92:964 93:2361 94:2404 95:2549 96:558 97:344 98:944 99:91 100:147 101:1176 103:12741 104:2580 105:147 106:464 107:1436 108:785 109:2499 110:1278 111:1658 112:1133 113:1152 114:1098 115:1694 116:1679 117:1557 118:2088 119:1574 120:957 121:1077 122:2278 123:2037 124:1579 125:1829 128:697 129:464 130:415 131:1386 132:619 133:175 134:512 135:204 136:402 137:394 138:1783 139:435 140:597 141:455 142:679 143:937 144:734 145:169 146:952 147:670 148:1385 149:538 150:655 151:888 152:686 153:303 154:697 155:938 156:535 157:539 158:434 159:1278 160:560 161:725 162:2422 163:590 164:779 165:1127 166:350 167:1202 168:2329 169:679 170:2254 171:254 172:783 173:1817 174:764 175:700 176:1740 177:4103 178:2371 179:1171 180:2159 181:1931 182:2104 183:1004 184:831 185:7881 186:3213 187:2180 188:2287 189:1796 190:7896 191:1311 192:9093 193:5742 194:4473 195:3837 196:1823 197:1267 198:5608 199:5830 200:7155 201:3738 202:10152 203:9834 204:4504 205:2739 206:2995 207:3101 208:3987 209:3850 210:3881 211:2044 212:2745 213:2397 214:866 215:67 216:5738 217:1979 218:815 219:599 220:1647 221:879 222:708 223:1321 End of report From javier at advancedmachines.us Fri Nov 4 20:41:16 2016 From: javier at advancedmachines.us (Javier J) Date: Fri, 4 Nov 2016 16:41:16 -0400 Subject: buying a /24 ipv4 Message-ID: What are the going rates these days in north america. What are some good sites to get a block? In the process now of setting up an Org and AS with Arin for a client. Thanks in advance for your help. - Javier From josh at imaginenetworksllc.com Fri Nov 4 20:43:06 2016 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 4 Nov 2016 16:43:06 -0400 Subject: buying a /24 ipv4 In-Reply-To: References: Message-ID: ipv4auctionS.com Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Nov 4, 2016 at 4:41 PM, Javier J wrote: > What are the going rates these days in north america. > > What are some good sites to get a block? > > > In the process now of setting up an Org and AS with Arin for a client. > > Thanks in advance for your help. > > - Javier > From jhaustin at gmail.com Fri Nov 4 20:43:52 2016 From: jhaustin at gmail.com (Jeremy Austin) Date: Fri, 04 Nov 2016 20:43:52 +0000 Subject: buying a /24 ipv4 In-Reply-To: References: Message-ID: Hilco Streambank is ipv4auctions.com They are reasonably competent. On Fri, Nov 4, 2016 at 12:42 PM Javier J wrote: > What are the going rates these days in north america. > > What are some good sites to get a block? > > > In the process now of setting up an Org and AS with Arin for a client. > > Thanks in advance for your help. > > - Javier > From edugas at unknowndevice.ca Fri Nov 4 20:50:00 2016 From: edugas at unknowndevice.ca (Eric Dugas) Date: Fri, 04 Nov 2016 20:50:00 +0000 Subject: buying a /24 ipv4 In-Reply-To: References: Message-ID: <7mfjkbfffai8l41k064o58d0d-2147483647@mailer.nylas.com> I had a good first experience with them. Would do business with them again.![](https://link.nylas.com/open/4sk3yzfka4ymj01d79p0ldahw/local- 7d1f435e-7abb?r=bmFub2dAbmFub2cub3Jn) On Nov 4 2016, at 4:47 pm, Jeremy Austin wrote: > Hilco Streambank is ipv4auctions.com > > They are reasonably competent. On Fri, Nov 4, 2016 at 12:42 PM Javier J wrote: > > > What are the going rates these days in north america. > > What are some good sites to get a block? > > > In the process now of setting up an Org and AS with Arin for a client. > > Thanks in advance for your help. > > \- Javier > From liam at fedney.org Fri Nov 4 21:25:31 2016 From: liam at fedney.org (L Sean Kennedy) Date: Fri, 4 Nov 2016 17:25:31 -0400 Subject: [NANOG-announce] NANOG 69 Washington D.C. - Call for Presentations is Open! Message-ID: NANOG Community, The NANOG Program Committee is excited to announce that we are accepting proposals for all sessions at NANOG 69 in Washington D.C. on February 6-8. Below is a summary of key details from the Call for Presentations and the complete text is available on the NANOG website: https://www.nanog.org/meetings/nanog69/callforpresentations Early bird registration is open for NANOG 69 and hotel rooms in the NANOG block at the conference hotel can be reserved by those interested in making advance travel plans. https://www.nanog.org/meetings/nanog69/home We look forward to seeing all of you in Washington! Sincerely, Sean Kennedy on behalf of the NANOG Program Committee NANOG 69 Call for Presentations The North American Network Operators' Group (NANOG) will hold its 69th conference in Washington, D.C. on February 6-8, 2017. The NANOG Program Committee seeks proposals for presentations, panels, tutorials, and tracks sessions for the NANOG 69 program. We welcome suggestions of speakers or topic ideas. Presentations may cover current technologies already deployed or soon-to-be deployed in the Internet. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations must not be promotional or discuss proprietary solutions. NANOG 69 submissions can be entered on the NANOG Program Committee Tool. How To Submit The primary speaker, moderator, or author should submit a presentation proposal and an abstract on the Program Committee Tool . Please upload draft slides as soon as possible so the Program Committee can understand the intended structure and level of detail covered by the talk. Draft slides are not required for a proposal to be initiated, but they are usually expected before the Program Committee can definitively accept a submission. The following information should be included in the proposal: - Author's name(s) - Professional or Educational Affiliation - A preferred contact email address - A preferred phone number for contact - Submission category (General Session, Panel, Tutorial, or Track) - Presentation Title - Abstract - Slides (attachment or URL), in PowerPoint (preferred) or PDF format Timeline for submission and proposal review - Submitter enters Abstract (and draft slides if possible) in Program Committee Tool . - Any time following Call for Presentations and before deadline for Abstracts - PC performs initial review and assigns a ?Shepherd? to help develop the submission. - Within 2 weeks - Submitter develops draft slides of talk - Please submit initial draft slides early - Panels and Track submissions should provide topic list and intended/confirmed participants - PC reviews slides and continues to work with Submitter as needed to develop topic - Draft presentation slides should be submitted prior to published deadline for slides - PC accepts or declines submission - Agenda assembled and posted - Submitters notified If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the Program Committee, and a representative of the Program Committee will respond. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool without delay! We look forward to reviewing your submission. Key Dates For NANOG 69 Event/Deadline Date Registration for NANOG 69 Opens Friday, 11/4//2016 Agenda Outline for NANOG 69 Posted Friday, 11/4/2016 CFP Deadline: Draft Presentation Slides Due Monday, 12/5/2016 CFP Topic List and NANOG Highlights Page Friday, 12/9/2016 Speaker FINAL presentation Slides to PC Tool Tuesday, 1/24/2017 Lightning Talk Submissions Open (Abstracts Only) Sunday, 2/5/2017 On-site Registration Sunday, 2/5/2017 Further Presentation Guidelines can be found under "Present at a NANOG" and some general advice is available in Tips on Giving a Talk . The NANOG Program Committee seeks proposals for presentations, panels, tutorial sessions, and tracks in all areas of network operations, such as: - Network Connectivity, Interconnection, and Architecture - Network Management and Configuration including Automation - Network Performance, Measurement, and Telemetry - Data Center and Physical Plant including Cooling and Power Efficiency - Network Research - Internet Governance - Routing and Switching Protocols - Network Data and Control Plane Security - Optical and Transmission Technologies - Wireless Networks - DNS, Transport, and Applications - Network Operations and Engineering Professional Experiences Submissions are welcomed by and for network operators of all sizes. Presentations about difficult problems (and interesting solutions) that you encounter in the course of your job are encouraged. The NANOG registration fee is waived for: - General Session presentations: the conference registration fee will be waived for a maximum of one speaker. - General Session panels: conference registration fees will be waived for one panel moderator and all panelists. - Tracks: conference registration fees will be waived for one moderator. - Tutorials: conference registration fees will be waived for one instructor. -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From rjacobs at pslightwave.com Sat Nov 5 14:35:14 2016 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Sat, 5 Nov 2016 14:35:14 +0000 Subject: buying a /24 ipv4 In-Reply-To: <7mfjkbfffai8l41k064o58d0d-2147483647@mailer.nylas.com> References: <7mfjkbfffai8l41k064o58d0d-2147483647@mailer.nylas.com> Message-ID: Same here ... -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas Sent: Friday, November 4, 2016 3:50 PM To: Jeremy Austin Cc: nanog at nanog.org Subject: Re: buying a /24 ipv4 I had a good first experience with them. Would do business with them again.![](https://link.nylas.com/open/4sk3yzfka4ymj01d79p0ldahw/local- 7d1f435e-7abb?r=bmFub2dAbmFub2cub3Jn) On Nov 4 2016, at 4:47 pm, Jeremy Austin wrote: > Hilco Streambank is ipv4auctions.com > > They are reasonably competent. On Fri, Nov 4, 2016 at 12:42 PM Javier J wrote: > > > What are the going rates these days in north america. > > What are some good sites to get a block? > > > In the process now of setting up an Org and AS with Arin for a client. > > Thanks in advance for your help. > > \- Javier > From theodore at ciscodude.net Sat Nov 5 19:12:28 2016 From: theodore at ciscodude.net (Theodore Baschak) Date: Sat, 5 Nov 2016 14:12:28 -0500 Subject: buying a /24 ipv4 In-Reply-To: References: <7mfjkbfffai8l41k064o58d0d-2147483647@mailer.nylas.com> Message-ID: I've just finished a transfer facilitated by Hilco Streambank. Everything went smoothly, the only down side was even though its mentioned all over their website the source had not completed pre-approval with ARIN so that took an extra nearly 2 weeks. Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ > On Nov 5, 2016, at 9:35 AM, Robert Jacobs wrote: > > Same here ... > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Dugas > Sent: Friday, November 4, 2016 3:50 PM > To: Jeremy Austin > Cc: nanog at nanog.org > Subject: Re: buying a /24 ipv4 > > I had a good first experience with them. Would do business with them > again.![](https://link.nylas.com/open/4sk3yzfka4ymj01d79p0ldahw/local- > 7d1f435e-7abb?r=bmFub2dAbmFub2cub3Jn) > > > On Nov 4 2016, at 4:47 pm, Jeremy Austin wrote: > >> Hilco Streambank is ipv4auctions.com > >> > >> They are reasonably competent. > On Fri, Nov 4, 2016 at 12:42 PM Javier J wrote: > >> > >>> What are the going rates these days in north america. >> >> What are some good sites to get a block? >> >> >> In the process now of setting up an Org and AS with Arin for a client. >> >> Thanks in advance for your help. >> >> \- Javier >> > From fredrik at i2b.se Fri Nov 4 13:22:35 2016 From: fredrik at i2b.se (Fredrik Holmqvist / I2B) Date: Fri, 04 Nov 2016 12:22:35 -0100 Subject: Google contact needed to help resolve captcha issue In-Reply-To: <7awp95aumrmyfhda9jthfe2b.1478252272324@email.android.com> References: <7awp95aumrmyfhda9jthfe2b.1478252272324@email.android.com> Message-ID: Hi. It's as useful as banging your head to the wall. All you get is the same information as you get from the captcha page. No help at all. No way to get the issue resolved. On 2016-11-04 08:37, Alexander Maassen wrote: > Tried noc at google.com? > > Kind regards, > > Alexander Maassen > > - Technical Maintenance Engineer Parkstad Support BV > - Maintainer DroneBL > - Peplink Certified Engineer > > -------- Oorspronkelijk bericht -------- > Van: Fredrik Holmqvist / I2B > Datum: 03-11-16 15:25 (GMT+01:00) > Aan: nanog at nanog.org > Onderwerp: Google contact needed to help resolve captcha issue > > Hi. > > We have a customer who have their /32 IPv6 block captcha blocked, and > also their /19 IPv4 have been blocked with captchas. > The big issue is that it doesn't help to solve the captchas, there is > a > new one directly after and solving it gives a new one and so it goes > on > till you move to Bing do do searches. > Even parts of their netblocks that arn't in use are blocked, and have > been for 3 weeks now. > We have tried to contact google, but no one gets back. There is no > useful information on how to solve the issue either. > > Would be great to have a tool like SPAMhaus or other RBLs, where you > as > a ISP can see the offending IPs and take care of the problem (if > there > is one). > > -- > Fredrik Holmqvist > I2B (Internet 2 Business) > +46-70-740 5033 -- Fredrik Holmqvist I2B (Internet 2 Business) 070-740 5033 From elomis at gmail.com Sun Nov 6 21:47:11 2016 From: elomis at gmail.com (Geordie Guy) Date: Sun, 06 Nov 2016 21:47:11 +0000 Subject: Omaha NE link costings Message-ID: Hi list, I'm a NOC lead for an Australia-based insurance company and I've been asked for quick indicative costing for a 100Mbps symmetrical link to an acquired business in Omaha. I've not dropped links into that area before and have no idea of rough costs. Could someone who's bought (or sold) an Internet link in Nebraska drop me a line off-list with what the cost was so I can give rough figures? Geordie From randy at psg.com Mon Nov 7 03:24:11 2016 From: randy at psg.com (Randy Bush) Date: Mon, 07 Nov 2016 12:24:11 +0900 Subject: patch, patch, patssh Message-ID: while i did whine about patching, looking at logs makes me glad i do. the time from patch to active attack is decreasing alarmingly. randy From marka at isc.org Tue Nov 8 03:51:48 2016 From: marka at isc.org (Mark Andrews) Date: Tue, 08 Nov 2016 14:51:48 +1100 Subject: Spitballing IoT Security In-Reply-To: Your message of "Mon, 31 Oct 2016 13:14:10 -0400." References: <20161029180730.GA10801@thyrsus.com> <26234.1477787539@segfault.tristatelogic.com> <20161030044342.GA18488@thyrsus.com> Message-ID: <20161108035148.2904B5970CF1@rock.dv.isc.org> In message , Pierre Lamy write s: > On 30/10/2016 12:43 AM, Eric S. Raymond wrote: > > Ronald F. Guilmette : > >> Two kids with a modest amount of knowledge > >> and a lot of time on their hands can do it from their mom's basement. > > > > I in turn have to call BS on this. If it were really that easy, we'd > > be inundated by Mirais -- we'd have several attacks a *day*. > > > > It's not easy, Mirai was closed source until the actor released it. We > see a pattern again and again, where the bad guys find a private > monetization strategy, milk it, and get out before too much attention is > focused on just them. By dumping the code, the Mirai actors obfuscate > attribution. > > Now that the code is public, we see a huge surge in dumb & pointless > attacks against gaming/mod sites, Dyn, public schools and so on. We also > see bad code "improvements" which were recently referenced. > > http://motherboard.vice.com/read/wannabe-hackers-are-adding-terrible-and-stup > id-features-to-mirai > > The long term problem isn't any manufacturer or Mirai, it's going to be > the long tail of IoT devices that never see a patch, deployed by people > who don't know anything about security (nor should they need to... flame > suit on). When millions of any type of device are put online, times > thousands of products, it only takes one bad guy's "a-ha" moment for > this to happen again. They'll milk it for a while, the attack > vector/method will get pushed down to the skid level, and we'll see a > massive increase in un-targeted attacks by those script kiddies until > the cycle repeats. There's an endless fresh supply of script kiddies. > > While I agree with BCP38 etc, it wouldn't have prevented Mirai. > Self-update functions at some point for these devices are going to get > borked as well, such as a company going bust or forgetting to renew > their auto-update target domain. If you can't get (thousands?) of major > operators to deploy common sense security configurations, how will > similar best practices be implemented by tens of thousands of > manufacturers? Putting device regulations in one country won't impact > the rest of the internet's connected devices either. > > Solutions...? Someone's going to have to take out a hammer, not a > scalpel, for these issues. Actually the way forward is to not look for a magical solution that will stop all evil but to deploy what you can where you can. This reduces the problem space. * Deploying BCP38 means you are no longer a source of spoofed traffic. It doesn't help with all issues but it does with some. * Deploying regulation in one country means that it is less likely to be a source of bad traffic. Manufactures are lazy. With sensible regulation in single country everyone else benefits as manufactures will use a single code base when they can. * Automated updates do reduce the numbers of vulnerable machines to known issues. There are risks but they are nowhere as bad as not doing automated updating. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From elomis at gmail.com Tue Nov 8 04:33:31 2016 From: elomis at gmail.com (Geordie Guy) Date: Tue, 08 Nov 2016 04:33:31 +0000 Subject: Omaha NE link costings In-Reply-To: References: Message-ID: Thanks everyone who replied, I've got rough idea now. Geordie On Mon, 7 Nov 2016 at 08:47 Geordie Guy wrote: > Hi list, > > I'm a NOC lead for an Australia-based insurance company and I've been > asked for quick indicative costing for a 100Mbps symmetrical link to an > acquired business in Omaha. I've not dropped links into that area before > and have no idea of rough costs. Could someone who's bought (or sold) an > Internet link in Nebraska drop me a line off-list with what the cost was so > I can give rough figures? > > Geordie > From rfg at tristatelogic.com Tue Nov 8 05:05:32 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 07 Nov 2016 21:05:32 -0800 Subject: Spitballing IoT Security In-Reply-To: <20161108035148.2904B5970CF1@rock.dv.isc.org> Message-ID: <85741.1478581532@segfault.tristatelogic.com> In message <20161108035148.2904B5970CF1 at rock.dv.isc.org>, Mark Andrews wrote: >* Deploying regulation in one country means that it is less likely > to be a source of bad traffic. Manufactures are lazy. With > sensible regulation in single country everyone else benefits as > manufactures will use a single code base when they can. I said that too, although not as concisely. >* Automated updates do reduce the numbers of vulnerable machines > to known issues. There are risks but they are nowhere as bad as > not doing automated updating. I still maintain, based upon the abundant evidence, that generallized hopes that timely and effective updates for all manner of devices will be available throughout the practical lifetime of any such IoT thingies is a mirage. We will just never be there, in practice. And thus, manufacturers should be encouraged, by force of law if necessary, to design software with a belt-and-suspenders margin of safety built in from the first day of shipping. You don't send out a spacecraft, or a medical radiation machine, without such addtional constraints built in from day one. You don't send out such things and say "Oh, we can always send out of firmware update later on if there is an issue." >From a software perspective, building extra layers of constraints is not that hard to do, and people have been doing this kind of thing already for decades. It's called engineering. The problem isn't in anybody's ability or inability to do safety engineering in the firmware of IoT things. The only problem is providing the proper motivation to cause it to happen. Regards, rfg From john at hypergeek.net Tue Nov 8 23:15:57 2016 From: john at hypergeek.net (John A. Kilpatrick) Date: Tue, 8 Nov 2016 15:15:57 -0800 (PST) Subject: dilemmas In-Reply-To: References: Message-ID: On Thu, 3 Nov 2016, Randy Bush wrote: > the users' dilemma: do you buy a mac today, or wait six month hoping > they will fix X (for your particular X)? It is more: Do I wait for a Mac desktop that doesn't suck, or do I build a Hackintosh? -- John A. Kilpatrick john at hypergeek.net | http://www.hypergeek.net/ remember: no obstacles/only challenges From jra at baylink.com Wed Nov 9 20:56:38 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 9 Nov 2016 20:56:38 +0000 (UTC) Subject: Here we go again. Message-ID: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> The list is not the proper forum for a debate on this topic, and I'm not trying to start one. But ask yourself *now* what happens if you get these kinds of orders, so that you can give a reasoned answer. https://plus.google.com/+LaurenWeinstein/posts/TYxXkeQ2jPW Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From SNaslund at medline.com Wed Nov 9 21:02:04 2016 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 9 Nov 2016 21:02:04 +0000 Subject: Here we go again. In-Reply-To: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402148EB3E5@MUNPRDMBXA1.medline.com> Not trying to start a debate but let me post a controversial topic that is just a guess at what someone might do. Yeah, Ok. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay R. Ashworth Sent: Wednesday, November 09, 2016 2:57 PM To: North American Network Operators' Group Subject: Here we go again. The list is not the proper forum for a debate on this topic, and I'm not trying to start one. But ask yourself *now* what happens if you get these kinds of orders, so that you can give a reasoned answer. https://plus.google.com/+LaurenWeinstein/posts/TYxXkeQ2jPW Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mel at beckman.org Wed Nov 9 21:17:53 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 9 Nov 2016 21:17:53 +0000 Subject: Here we go again. In-Reply-To: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> Message-ID: <7F15FACC-9D6C-4822-B70B-0719AD73D166@beckman.org> You're right, this is not the forum. So why are you abusing it? -mel beckman > On Nov 9, 2016, at 12:57 PM, Jay R. Ashworth wrote: > > The list is not the proper forum for a debate on this topic, and I'm not > trying to start one. > > But ask yourself *now* what happens if you get these kinds of orders, so > that you can give a reasoned answer. > > https://plus.google.com/+LaurenWeinstein/posts/TYxXkeQ2jPW > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bruns at 2mbit.com Wed Nov 9 22:11:27 2016 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 9 Nov 2016 15:11:27 -0700 Subject: Here we go again. In-Reply-To: <7F15FACC-9D6C-4822-B70B-0719AD73D166@beckman.org> References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> <7F15FACC-9D6C-4822-B70B-0719AD73D166@beckman.org> Message-ID: <1fb64019-c418-f81e-b032-7fafda202563@2mbit.com> On 11/9/16 2:17 PM, Mel Beckman wrote: > You're right, this is not the forum. So why are you abusing it? > I do think it's a fair thing to drop in everyone's lap though. Something to think about, and consider, even if privately and to ones self. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From rfg at tristatelogic.com Wed Nov 9 22:39:50 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 09 Nov 2016 14:39:50 -0800 Subject: Here we go again. In-Reply-To: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> Message-ID: <94876.1478731190@segfault.tristatelogic.com> In message <1624203180.33527.1478724998723.JavaMail.zimbra at baylink.com>, "Jay R. Ashworth" wrote: >The list is not the proper forum for a debate on this topic, and I'm not >trying to start one. > >But ask yourself *now* what happens if you get these kinds of orders, so >that you can give a reasoned answer. > > https://plus.google.com/+LaurenWeinstein/posts/TYxXkeQ2jPW There are plenty of reasons for thinking people to be terrified today. I don't know why you've chosen to focus on such a small one. Here's a bigger one: http://bit.ly/2fTdmiG P.S. I agree completely that this is not the proper forum for either discussion or debate on these matters. But given that adherence to the ordinary rules of politness and proper decorum quite clearly did nothing, in the end, to prevent last night's outcome, I for one am willing to forgo them, within limits, e.g. when some of the elephants in the room become just too big to ignore. From bill at herrin.us Wed Nov 9 22:54:06 2016 From: bill at herrin.us (William Herrin) Date: Wed, 9 Nov 2016 17:54:06 -0500 Subject: Here we go again. In-Reply-To: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> Message-ID: On Wed, Nov 9, 2016 at 3:56 PM, Jay R. Ashworth wrote: > But ask yourself *now* what happens if you get these kinds of orders, so > that you can give a reasoned answer. > > https://plus.google.com/+LaurenWeinstein/posts/TYxXkeQ2jPW Hi Jay, I think this discussion is premature. We can hypothesize any number of evils from the President Elect but until someone introduces a bill we can only tilt at windmills. Besides, you are aware of his record of doing what his "handlers" want him to do, right? ;) Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From job at instituut.net Wed Nov 9 23:04:09 2016 From: job at instituut.net (Job Snijders) Date: Thu, 10 Nov 2016 00:04:09 +0100 Subject: Here we go again. In-Reply-To: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> Message-ID: <20161109230409.GI89276@Vurt.local> Hi all, Please consider our Mail List Charter and Policy: http://nanog.org/list The NANOG mailing list is established to provide a forum for the exchange of technical information and the discussion of specific implementation issues that require cooperation among network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, the list is governed by guidelines, such as "Discussion will focus on Internet operational and technical issues as described in the charter of NANOG" and "Postings of political, philosophical, and legal nature are prohibited." Kind regards, Job From sfischer1967 at gmail.com Wed Nov 9 23:08:47 2016 From: sfischer1967 at gmail.com (Steven Fischer) Date: Wed, 9 Nov 2016 23:08:47 +0000 (UTC) Subject: Here we go again. In-Reply-To: <20161109230409.GI89276@Vurt.local> References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> <20161109230409.GI89276@Vurt.local> Message-ID: <560DB18494DBEDF9.00E33F69-88DE-4097-86AB-F75642464C44@mail.outlook.com> Thank you.? Get Outlook for iOS On Wed, Nov 9, 2016 at 6:06 PM -0500, "Job Snijders" wrote: Hi all, Please consider our Mail List Charter and Policy: http://nanog.org/list The NANOG mailing list is established to provide a forum for the exchange of technical information and the discussion of specific implementation issues that require cooperation among network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, the list is governed by guidelines, such as "Discussion will focus on Internet operational and technical issues as described in the charter of NANOG" and "Postings of political, philosophical, and legal nature are prohibited." Kind regards, Job From jessica at litw.in Wed Nov 9 21:55:43 2016 From: jessica at litw.in (Jessica Litwin) Date: Wed, 9 Nov 2016 16:55:43 -0500 Subject: OT: OpenSRS contact? Message-ID: Apologies if this kind of thing isn't allowed but I'm at the end of my tether. If anyone who works at OpenSRS lurks here, can you contact me off-list? I have an issue support is unwilling or unable to fix and they don't seem too keen on escalating it. // jkl From nanog at haller.ws Mon Nov 7 01:59:10 2016 From: nanog at haller.ws (Patrick) Date: Mon, 7 Nov 2016 09:59:10 +0800 Subject: OT: "Read Receipts" Message-ID: <20161107015909.GA5636@haller.ws> Over at Language Hat, they are trying to establish the common pronunciation of "read receipts" [1] To me, they've always just been "DSNs" or "MDNs", however, according to rfc2298, their history goes back further. Of those who lived that history, and actually heard or said "read receipts", did you pronounce "read" as "reed" or as "red"? Thanks! Patrick [1] http://languagehat.com/read-receipts/ From main at kipsang.com Wed Nov 9 17:12:24 2016 From: main at kipsang.com (Michael Bullut) Date: Wed, 9 Nov 2016 20:12:24 +0300 Subject: OSPF vs ISIS - Which do you prefer & why? Message-ID: Greetings Team, ?While I haven't worked with IS-IS before but the only disadvantage I've encountered with OSPF is that it is resource intensive on the router it is running on which is why only one instance runs on any PE & P device on an ISP network. OSPF is pretty good in handling the core network routing while BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP can run on top of OSPF. I came across this *article* when scrolling the web a while back and I still want to find out if am the only one who thinks its a matter of choice between the two. Although there isn't distinct 1:1 argument, it's good we discuss it here and figure out why one prefer one over the other *(consider a huge flat network)**.* What say you ladies and gentlemen? Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang * *Blog: http://www.kipsang.com/ * *E-mail:* *main at kipsang.com
* *---* From larrysheldon at cox.net Thu Nov 10 01:03:36 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 9 Nov 2016 19:03:36 -0600 Subject: OT: "Read Receipts" In-Reply-To: <60h31u00C1cZc56010h5ns> References: <60h31u00C1cZc56010h5ns> Message-ID: <44e29249-8197-172e-d8b5-b1fe3613295a@cox.net> I avoided the other off charter bait, but this is a red dot to me. On 11/6/2016 19:59, Patrick wrote: > Over at Language Hat, they are trying to establish the common > pronunciation of "read receipts" [1] > > To me, they've always just been "DSNs" or "MDNs", however, according to > rfc2298, their history goes back further. > > Of those who lived that history, and actually heard or said "read > receipts", did you pronounce "read" as "reed" or as "red"? I always pronounce them "More danged spam leaking thru the filters" but when I test-read (red) the question, R E A D came out "read (reed)". The burning questions we have to deal with these days, -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account. From randy at psg.com Thu Nov 10 02:04:23 2016 From: randy at psg.com (Randy Bush) Date: Thu, 10 Nov 2016 11:04:23 +0900 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: vi users prefer ospf emacs users prefer is-is randy From jtk at depaul.edu Thu Nov 10 02:27:09 2016 From: jtk at depaul.edu (John Kristoff) Date: Wed, 9 Nov 2016 20:27:09 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: <20161109202709.1cb8a5ec@p50.localdomain> On Wed, 9 Nov 2016 17:12:24 +0000 Michael Bullut
wrote: > Although there isn't distinct 1:1 argument, it's good we discuss it > here and figure out why one prefer one over the other *(consider a > huge flat network)**.* What say you ladies and gentlemen? I'm not sure it is worthy of an argument. I think I've only ever heard of anyone migrating from one to the other. That was AOL presenting their conversion from OSPF to IS-IS at NANOG a number of years ago: The article you refer to more or less covers some of the major differences, largely academic these days. They are close enough alike now that it is probably just best to use what you know or already have running. When I migrated a RIPv2 network to OSPF I don't remember if I consciously choose it over IS-IS for any particular reason or, more likely, just went with it because it seemed like the IETF-preferred way to go. That would have been a dumb reason and later I kind of wish I had used IS-IS, because of the security isolation at layer 2 and relatively modest changes to support IPv6. But I wouldn't go through the trouble of changing it now. There is no compelling reason. I've considered leaving IPv4 on OSPF and putting IPv6 on IS-IS, but I'm not sure it really matters. It might be nice to get the experience on the resume, but that might not be a good justification to the network staff and management for a production network. John From thegameiam at yahoo.com Thu Nov 10 02:28:12 2016 From: thegameiam at yahoo.com (David Barak) Date: Wed, 9 Nov 2016 18:28:12 -0800 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: <1A52FFFD-2D99-4476-874C-0505D0B0E9F0@yahoo.com> > On Nov 9, 2016, at 6:04 PM, Randy Bush wrote: > > vi users prefer ospf > emacs users prefer is-is > So that leaves EIGRP for the nano users? David Barak Sent from mobile device, please excuse autocorrection artifacts From randy at psg.com Thu Nov 10 02:34:46 2016 From: randy at psg.com (Randy Bush) Date: Thu, 10 Nov 2016 11:34:46 +0900 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <1A52FFFD-2D99-4476-874C-0505D0B0E9F0@yahoo.com> References: <1A52FFFD-2D99-4476-874C-0505D0B0E9F0@yahoo.com> Message-ID: >> vi users prefer ospf >> emacs users prefer is-is > So that leaves EIGRP for the nano users? teco From routetarget at gmail.com Thu Nov 10 02:45:14 2016 From: routetarget at gmail.com (RT Parrish) Date: Wed, 9 Nov 2016 21:45:14 -0500 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: I will definitely be looking up the notes from AOL that John referenced. But working for a vendor and getting insight from multiple ISPs, here are a few of the things that I hear most frequently: 1) Network Topology support - The differences between a single OSPF backbone area and a contiguous set of Level-2 adjacencies will occasionally be a deciding factor. 2) Feature Support on a per vendor basis - Some vendors will roll new features out in one or the other protocols prior to the other. Segment Routing and some of its enhancements come to mind as being in ISIS first. 3) Layer 2 adjacencies - I think someone already mentioned that you form adjacencies at layer 2 which also means that with a single adj you can support multiple protocols (v4/v6). OSPF would require two different instances to support both. Maybe good, maybe not. Depends on your desired level of isolation between the two. 4) CPU performance is academic at this point - The SPF calculations in most networks would require next to no difference between the two protocols even if running both IPv4 and v6. End of the day, use the right tool/vendor/technology for the right job. Hope this helps, RT On Wed, Nov 9, 2016 at 12:12 PM, Michael Bullut
wrote: > Greetings Team, > > ?While I haven't worked with IS-IS before but the only disadvantage I've > encountered with OSPF is that it is resource intensive on the router it is > running on which is why only one instance runs on any PE & P device on an > ISP network. OSPF is pretty good in handling the core network routing while > BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP > can run on top of OSPF. I came across this *article* > providers-still-prefer-is-is-over-ospf-when-designing- > large-flat-topologies/> > when > scrolling the web a while back and I still want to find out if am the only > one who thinks its a matter of choice between the two. Although there isn't > distinct 1:1 argument, it's good we discuss it here and figure out why one > prefer one over the other *(consider a huge flat network)**.* What say you > ladies and gentlemen? > > Warm regards, > > Michael Bullut. > > --- > > *Cell:* > *+254 723 393 114.**Skype Name:* *Michael Bullut.* > *Twitter:* > * @Kipsang * > *Blog: http://www.kipsang.com/ * > *E-mail:* *main at kipsang.com
* > > *---* > From josh at kyneticwifi.com Thu Nov 10 02:52:42 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Wed, 9 Nov 2016 20:52:42 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: Vendor support for IS-IS is quite limited - many options for OSPF. On Nov 9, 2016 8:47 PM, "RT Parrish" wrote: > I will definitely be looking up the notes from AOL that John referenced. > But working for a vendor and getting insight from multiple ISPs, here are a > few of the things that I hear most frequently: > > 1) Network Topology support - The differences between a single OSPF > backbone area and a contiguous set of Level-2 adjacencies will occasionally > be a deciding factor. > 2) Feature Support on a per vendor basis - Some vendors will roll new > features out in one or the other protocols prior to the other. Segment > Routing and some of its enhancements come to mind as being in ISIS first. > 3) Layer 2 adjacencies - I think someone already mentioned that you form > adjacencies at layer 2 which also means that with a single adj you can > support multiple protocols (v4/v6). OSPF would require two different > instances to support both. Maybe good, maybe not. Depends on your desired > level of isolation between the two. > 4) CPU performance is academic at this point - The SPF calculations in most > networks would require next to no difference between the two protocols even > if running both IPv4 and v6. > > End of the day, use the right tool/vendor/technology for the right job. > > Hope this helps, > RT > > On Wed, Nov 9, 2016 at 12:12 PM, Michael Bullut
wrote: > > > Greetings Team, > > > > ?While I haven't worked with IS-IS before but the only disadvantage I've > > encountered with OSPF is that it is resource intensive on the router it > is > > running on which is why only one instance runs on any PE & P device on an > > ISP network. OSPF is pretty good in handling the core network routing > while > > BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP > > can run on top of OSPF. I came across this *article* > > > providers-still-prefer-is-is-over-ospf-when-designing- > > large-flat-topologies/> > > when > > scrolling the web a while back and I still want to find out if am the > only > > one who thinks its a matter of choice between the two. Although there > isn't > > distinct 1:1 argument, it's good we discuss it here and figure out why > one > > prefer one over the other *(consider a huge flat network)**.* What say > you > > ladies and gentlemen? > > > > Warm regards, > > > > Michael Bullut. > > > > --- > > > > *Cell:* > > *+254 723 393 114.**Skype Name:* *Michael Bullut.* > > *Twitter:* > > * @Kipsang * > > *Blog: http://www.kipsang.com/ * > > *E-mail:* *main at kipsang.com
* > > > > *---* > > > From mark.tinka at seacom.mu Thu Nov 10 05:59:12 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 07:59:12 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> On 9/Nov/16 19:12, Michael Bullut wrote: > Greetings Team, > > ?While I haven't worked with IS-IS before but the only disadvantage I've > encountered with OSPF is that it is resource intensive on the router it is > running on which is why only one instance runs on any PE & P device on an > ISP network. OSPF is pretty good in handling the core network routing while > BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP > can run on top of OSPF. I came across this *article* > > when > scrolling the web a while back and I still want to find out if am the only > one who thinks its a matter of choice between the two. Although there isn't > distinct 1:1 argument, it's good we discuss it here and figure out why one > prefer one over the other *(consider a huge flat network)**.* What say you > ladies and gentlemen? I've given a talk about this a couple of times since 2008. But our reasons are to choosing IS-IS are: * No requirement to home everything back to Area 0 (Virtual Links are evil). * Integrated IPv4/IPv6 protocol support in a single IGP implementation. * Single level (L2) deployment at scale. * Scalable TLV structure vs. Options structure for OSPFv2. OSPFv3 employs a TLV structure, however. * Inherent scaling features, e.g., iSPF, PRC, e.t.c. Some of these may not be available on all vendor implementations. If you're interested in reviewing the talk I gave on this, a lot more details is in there at: http://www.apricot.net/apricot2009/images/lecture_files/isis_deployment.pdf Ultimately, router CPU's are way faster now, and I could see a case for running a single-area OSPFv2. So I'd likely not be religious about forcing you down the IS-IS path. Mark. From mark.tinka at seacom.mu Thu Nov 10 06:00:57 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 08:00:57 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> Message-ID: And yes, IS-IS not running over IP is also a great thing. Mark. From mark.tinka at seacom.mu Thu Nov 10 06:04:23 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 08:04:23 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <20161109202709.1cb8a5ec@p50.localdomain> References: <20161109202709.1cb8a5ec@p50.localdomain> Message-ID: <751871db-c67f-ae8c-9ac5-8717ee7936c8@seacom.mu> On 10/Nov/16 04:27, John Kristoff wrote: > > I've considered leaving IPv4 on OSPF and putting IPv6 on IS-IS, but I'm > not sure it really matters. It might be nice to get the experience on > the resume, but that might not be a good justification to the network > staff and management for a production network. When I converted an OSPF network at $old_job to IS-IS back in 2011, the NOC were not too pleased with the idea. Took several workshops to reassure them that we didn't all need to move to Mars if we did this. Suffice it to say, the migration went famously, and considering it works well, they didn't even need to touch it at all on an ongoing basis (not that OSPF needed hand-holding). The resistance to move is mostly borne out of fear (and a bit of laziness to learning something new). That can be said for pretty much anything the network has never ran before that Engineering want to implement. Giving them leadership does the trick. Mark. From mark.tinka at seacom.mu Thu Nov 10 06:12:05 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 08:12:05 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: On 10/Nov/16 04:45, RT Parrish wrote: > 1) Network Topology support - The differences between a single OSPF > backbone area and a contiguous set of Level-2 adjacencies will occasionally > be a deciding factor. L2 IS-IS can be as chatty as single-area OSPF. That said, IS-IS has native tools to reduce that chatter (like PRC, and iSPF), but to be honest, I'm not sure it makes much of a difference given today's faster router CPU's. > 2) Feature Support on a per vendor basis - Some vendors will roll new > features out in one or the other protocols prior to the other. Segment > Routing and some of its enhancements come to mind as being in ISIS first. I've noticed that the delay between when IS-IS and/or OSPF pick up a feature the other already has is reasonable. By the time an OSPF has completed evaluating whether they need LFA, it would have been implemented in the IGP. I suppose back then, there was a much bigger between when features made it between both protocols, but things seem to be on par nowadays. > 3) Layer 2 adjacencies - I think someone already mentioned that you form > adjacencies at layer 2 which also means that with a single adj you can > support multiple protocols (v4/v6). OSPF would require two different > instances to support both. Maybe good, maybe not. Depends on your desired > level of isolation between the two. OSPFv3 can support the advertisement of IPv4 prefixes. But you'd still need an IPv6 link layer. > 4) CPU performance is academic at this point - The SPF calculations in most > networks would require next to no difference between the two protocols even > if running both IPv4 and v6. Agree. > > End of the day, use the right tool/vendor/technology for the right job. Agree. Mark. From mark.tinka at seacom.mu Thu Nov 10 06:13:09 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 08:13:09 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: On 10/Nov/16 04:52, Josh Reynolds wrote: > Vendor support for IS-IS is quite limited - many options for OSPF. Depends on the vendor. Cisco have as many knobs for IS-IS as they do for OSPF. Juniper, not so much. Don't know about other vendors. At any rate, many of these knobs are not part of the original protocol spec., although they can be very useful when scaling. Mark. From web at typo.org Thu Nov 10 06:41:50 2016 From: web at typo.org (Wayne Bouchard) Date: Wed, 9 Nov 2016 23:41:50 -0700 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> Message-ID: <20161110064150.GA26871@spider.typo.org> This generally supports my own view that it depends on the topology and the real or potential scale/scope. In my experience, IS-IS is just all around better in a flat, highly interconnected environment such as an ISP or other broadly scaled network. If you have a very (almost exclusively) heirarchical structure and pretty good control over IP addressing and can use summarization effectively, then OSPF can make your core networking much simpler. On a small network that doesn't look to grow at leaps and bounds, I'd favor OSPF. On a large, complex network or a network that has the potential to grow without any sort of predefined structure (ie, more demand based), then IS-IS is probably your win. Note that this doesn't factor in multiple IS-IS levels, something I don't have a great deal of experience with. Mostly, networks I've been associated with just run one great big, gigantic level 0, though they did also experiment with other configurations. -Wayne On Thu, Nov 10, 2016 at 07:59:12AM +0200, Mark Tinka wrote: > > > On 9/Nov/16 19:12, Michael Bullut wrote: > > > Greetings Team, > > > > ???While I haven't worked with IS-IS before but the only disadvantage I've > > encountered with OSPF is that it is resource intensive on the router it is > > running on which is why only one instance runs on any PE & P device on an > > ISP network. OSPF is pretty good in handling the core network routing while > > BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP > > can run on top of OSPF. I came across this *article* > > > > when > > scrolling the web a while back and I still want to find out if am the only > > one who thinks its a matter of choice between the two. Although there isn't > > distinct 1:1 argument, it's good we discuss it here and figure out why one > > prefer one over the other *(consider a huge flat network)**.* What say you > > ladies and gentlemen? > > I've given a talk about this a couple of times since 2008. But our > reasons are to choosing IS-IS are: > > * No requirement to home everything back to Area 0 (Virtual Links are > evil). > > * Integrated IPv4/IPv6 protocol support in a single IGP implementation. > > * Single level (L2) deployment at scale. > > * Scalable TLV structure vs. Options structure for OSPFv2. OSPFv3 > employs a TLV structure, however. > > * Inherent scaling features, e.g., iSPF, PRC, e.t.c. Some of these may > not be available on all vendor implementations. > > If you're interested in reviewing the talk I gave on this, a lot more > details is in there at: > > > http://www.apricot.net/apricot2009/images/lecture_files/isis_deployment.pdf > > Ultimately, router CPU's are way faster now, and I could see a case for > running a single-area OSPFv2. So I'd likely not be religious about > forcing you down the IS-IS path. > > Mark. > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From mark.tinka at seacom.mu Thu Nov 10 06:52:59 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 08:52:59 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <20161110064150.GA26871@spider.typo.org> References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> <20161110064150.GA26871@spider.typo.org> Message-ID: <5e39ef62-2401-b923-f849-b8f7333be413@seacom.mu> On 10/Nov/16 08:41, Wayne Bouchard wrote: > This generally supports my own view that it depends on the topology > and the real or potential scale/scope. In my experience, IS-IS is just > all around better in a flat, highly interconnected environment such as > an ISP or other broadly scaled network. If you have a very (almost > exclusively) heirarchical structure and pretty good control over IP > addressing and can use summarization effectively, then OSPF can make > your core networking much simpler. On a small network that doesn't > look to grow at leaps and bounds, I'd favor OSPF. On a large, complex > network or a network that has the potential to grow without any sort > of predefined structure (ie, more demand based), then IS-IS is > probably your win. I wouldn't base the choice necessarily on the size of the network, although from experience, I'd always choose IS-IS for a large, geographically-dispersed network. What I mean to say is that I'd be happy running IS-IS on a tiny network, as much as I'd run route reflectors in a 3-router network. There isn't that much more effort to get it going compared to considering whether a Mini or a dump truck should be used to take the kids to school every morning. > Note that this doesn't factor in multiple IS-IS > levels, something I don't have a great deal of experience with. > Mostly, networks I've been associated with just run one great big, > gigantic level 0, though they did also experiment with other > configurations. I've run multi-level IS-IS before. To be honest, I'd not recommend it. There are enough features and knobs in IS-IS to quiet the chatter associated with a single-level IS-IS deployment. Running multi-level IS-IS means you need to plan your L1/L2 intersections, figure out what to do with the ATT Bit and look at Route Leaking if you run MPLS (LDP hates route summarization). Needless to say, the Area ID of the NET is more significant in L1/L2 IS-IS than in L2-only IS-IS, as this is what is used to control LSP exchange between levels. This can get very complicated very fast in very large networks. Yep, that's 3 "very's". It's 2016, and any decent router has something-x86 going for it (or at the very least, a reasonably quick non-x86 going for it). I'd stick to single-level IS-IS. Which means L2-only, not L1-only - I know a network :-). My only real issue with IS-IS is the ST and MT (Single Topology and Multi-Topology) nuisance re: IPv6. Many vendors implement ST on turn-up, meaning you need to manually configure the MT knob. This can be painful when you haven't been clued up on MT, run an IPv4-only network and need to enable IPv6. I've gone into a bit of detail on this in my talk that I included in a previous post. Mark. From randy at psg.com Thu Nov 10 09:03:18 2016 From: randy at psg.com (Randy Bush) Date: Thu, 10 Nov 2016 18:03:18 +0900 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <5e39ef62-2401-b923-f849-b8f7333be413@seacom.mu> References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> <20161110064150.GA26871@spider.typo.org> <5e39ef62-2401-b923-f849-b8f7333be413@seacom.mu> Message-ID: > Running multi-level IS-IS means you need to plan your L1/L2 > intersections as painful as ospf in a research rack with more than one router, i run is-is. randy From mark.tinka at seacom.mu Thu Nov 10 09:52:27 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 11:52:27 +0200 Subject: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> <20161110064150.GA26871@spider.typo.org> <5e39ef62-2401-b923-f849-b8f7333be413@seacom.mu> Message-ID: <38dd4d37-2d35-e7fc-3a93-4996a64a0d2f@seacom.mu> On 10/Nov/16 11:03, Randy Bush wrote: > > as painful as ospf If I did run OSPF, I'd probably do it with a single area, likely OSPFv3 with IPv4 address family support. Kinky, but it is 2016... > > in a research rack with more than one router, i run is-is. Good man :-)... Mark. From tom at snnap.net Thu Nov 10 09:56:59 2016 From: tom at snnap.net (Tom Storey) Date: Thu, 10 Nov 2016 09:56:59 +0000 Subject: JP Morgan contact Message-ID: Would anyone from JP Morgan just so happen to be lurking on the list? If so, would you mind contacting me off-list regarding a reachability issue that some of my customers are experiencing with your website(s), specifically jpmpb.com. Thanks Tom From jwbensley at gmail.com Thu Nov 10 10:17:47 2016 From: jwbensley at gmail.com (James Bensley) Date: Thu, 10 Nov 2016 10:17:47 +0000 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> Message-ID: On 10 November 2016 at 05:59, Mark Tinka wrote: > > > On 9/Nov/16 19:12, Michael Bullut wrote: > >> Greetings Team, >> >> While I haven't worked with IS-IS before but the only disadvantage I've >> encountered with OSPF is that it is resource intensive on the router it is >> running on which is why only one instance runs on any PE & P device on an >> ISP network. OSPF is pretty good in handling the core network routing while >> BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP >> can run on top of OSPF. I came across this *article* >> >> when >> scrolling the web a while back and I still want to find out if am the only >> one who thinks its a matter of choice between the two. Although there isn't >> distinct 1:1 argument, it's good we discuss it here and figure out why one >> prefer one over the other *(consider a huge flat network)**.* What say you >> ladies and gentlemen? > > I've given a talk about this a couple of times since 2008. But our > reasons are to choosing IS-IS are: I don't think there is much of a debate to be had any more, the gap between them is so small now (OSPFv3 and ISIS that is, no one would deploy OSPFv2 now in greenfield right?): > * No requirement to home everything back to Area 0 (Virtual Links are > evil). This is a good point I think. > * Integrated IPv4/IPv6 protocol support in a single IGP implementation. This is in OSPv3. > * Single level (L2) deployment at scale. Single area 0 deployment at scale? Bit of a moot point unless you compare a specific device model and specific code version in two identical deployments, its not much to do with the protocol but the vendor implementation and the brute force. > * Scalable TLV structure vs. Options structure for OSPFv2. OSPFv3 > employs a TLV structure, however. OSPv3 has this. > * Inherent scaling features, e.g., iSPF, PRC, e.t.c. Some of these may > not be available on all vendor implementations. OSPF has these too. > Ultimately, router CPU's are way faster now, and I could see a case for > running a single-area OSPFv2. So I'd likely not be religious about > forcing you down the IS-IS path. Yeah this ^ I don't think there is a stronge case for either protocol. Somenoe mentioned the AOL NANOG talk about migrating from OSPF to ISIS. There was a NANOG talk recently-ish about someone migrating from OSPF to BGP. There wasn't even a need for an IGP, BGP scalled better for them (in the DC). BGP these days supports PIC and BFD etc, how much longer to IGPs have? :) James. From zbynek at dialtelecom.cz Thu Nov 10 10:54:38 2016 From: zbynek at dialtelecom.cz (=?UTF-8?B?WmJ5bsSbayBQb3Nww61jaGFs?=) Date: Thu, 10 Nov 2016 11:54:38 +0100 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> Message-ID: <83076d43-4581-eafd-606f-b3c3812c8109@dialtelecom.cz> Dne 10.11.16 v 11:17 James Bensley wrote: >> * Integrated IPv4/IPv6 protocol support in a single IGP implementation. > > This is in OSPv3. In theory, yes. In the real world operators need MPLS label distribution, which is still not supported in many implementations. Regards, Zbynek From Joel.Snyder at Opus1.com Thu Nov 10 12:30:24 2016 From: Joel.Snyder at Opus1.com (Joel M Snyder) Date: Thu, 10 Nov 2016 13:30:24 +0100 Subject: OSPF vs ISIS - Which do you prefer & why? Message-ID: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> >> Vendor support for IS-IS is quite limited - many options for OSPF. >Depends on the vendor. I think you misunderstood his point: it's not the knobs, but the vendors. Generally, when you're trying to integrate random crap into an otherwise well-structured network, you'll find OSPF available, but very rarely IS-IS. I run into this a lot in the security appliance space, where you want your security appliances to either learn or advertise routes internally (VPN tunnel reachability is a big reason for this), but also in devices such as load balancers and other middlebox cruft that occasionally needs to participate in routing advertisement/subscription. Some vendors grab random open source routing protocol code that includes everything and dump it into their boxes, usually accessible via an entirely separate configuration interface; this can include IS-IS, but these implementations rarely actually work as they are usually "check list" implemented for a specific RFP or customer and never get widely tested. The ones who actually care about making it work almost always include RIP and OSPF, with a few shout-outs to BGP. IS-IS (and OSPF v3) rarely makes the cut. In a world where you are doing well-controlled Cisco/Juniper/etc networks with fairly homogeneous code bases, the engineers get to have this discussion. When you have to link in devices for which routing is not their primary reason to exist, your options narrow very quickly. It's not ideal; that's just the way it is. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From swmike at swm.pp.se Thu Nov 10 12:39:00 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 10 Nov 2016 13:39:00 +0100 (CET) Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> References: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> Message-ID: On Thu, 10 Nov 2016, Joel M Snyder wrote: > I think you misunderstood his point: it's not the knobs, but the > vendors. Generally, when you're trying to integrate random crap into an > otherwise well-structured network, you'll find OSPF available, but very > rarely IS-IS. This is a feature of IS-IS. You're less likely to get random crap in your IGP. :P -- Mikael Abrahamsson email: swmike at swm.pp.se From sthaug at nethelp.no Thu Nov 10 12:46:30 2016 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 10 Nov 2016 13:46:30 +0100 (CET) Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> References: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> Message-ID: <20161110.134630.74697221.sthaug@nethelp.no> > I think you misunderstood his point: it's not the knobs, but the > vendors. Generally, when you're trying to integrate random crap into an > otherwise well-structured network, you'll find OSPF available, but very > rarely IS-IS. We never really want to talk IS-IS with random crap - in that case the protocol of choice would be BGP. > I run into this a lot in the security appliance space, where you want > your security appliances to either learn or advertise routes internally > (VPN tunnel reachability is a big reason for this), but also in devices > such as load balancers and other middlebox cruft that occasionally needs > to participate in routing advertisement/subscription. ... > The ones who actually care about making it work almost always include > RIP and OSPF, with a few shout-outs to BGP. IS-IS (and OSPF v3) rarely > makes the cut. We've found that BGP works reasonably well to talk with such boxes, and also that BGP is generally available. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mark.tinka at seacom.mu Thu Nov 10 14:33:27 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 16:33:27 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> Message-ID: <4f1edec0-629e-9ef1-8acb-c2992b84d147@seacom.mu> On 10/Nov/16 12:17, James Bensley wrote: > > I don't think there is much of a debate to be had any more, the gap > between them is so small now (OSPFv3 and ISIS that is, no one would > deploy OSPFv2 now in greenfield right?): Most networks that I know are greenfielding an IGP will deploy both OSPFv2 and OSPFv3. Worst case, just OSPFv2. > > This is in OSPv3. Right, but if a network does not yet want to run IPv6 (2016, anyone), then this becomes an issue as IPv6 NLRI is carried over the IPv6 transport. This could also come down to implementation. I looked at this for the first time back in Junos 9.0 (when it was still an IETF draft), and no other vendor had it yet. It has since matured and I know both Juniper and Cisco have decent code. I can't speak for other vendors, particularly if you multi-vendor. > Single area 0 deployment at scale? Bit of a moot point unless you > compare a specific device model and specific code version in two > identical deployments, its not much to do with the protocol but the > vendor implementation and the brute force. Like I said to Randy, if I did deploy OSPF ever (quite unlikely), there is enough CPU in today's router to, I think, run a single Area 0 for the whole thing. > OSPv3 has this. Yep, as I did mention. > OSPF has these too. More of them in OSPFv3 than OSPFv2. But then again, vendor-specific knobs can be had here for cheap. > Yeah this ^ I don't think there is a stronge case for either protocol. > > Somenoe mentioned the AOL NANOG talk about migrating from OSPF to > ISIS. There was a NANOG talk recently-ish about someone migrating from > OSPF to BGP. There wasn't even a need for an IGP, BGP scalled better > for them (in the DC). > > BGP these days supports PIC and BFD etc, how much longer to IGPs have? :) Sounds like you're talking about BGP-LS. If you are, then BGP-LS still requires an IGP. It's just that the IGP has a much more micro view of the network, while BGP-LS is tasked with the macro side of things. Mark. From mark.tinka at seacom.mu Thu Nov 10 14:34:31 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 16:34:31 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <83076d43-4581-eafd-606f-b3c3812c8109@dialtelecom.cz> References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> <83076d43-4581-eafd-606f-b3c3812c8109@dialtelecom.cz> Message-ID: <16204a54-18b1-e80c-7e9b-da35b45d4393@seacom.mu> On 10/Nov/16 12:54, Zbyn?k Posp?chal wrote: > In theory, yes. In the real world operators need MPLS label > distribution, which is still not supported in many implementations. But dual-stack protocol support in the IGP has nothing to do with MPLS. Now, if you're talking about LDPv6 or SR, then... Mark. From mark.tinka at seacom.mu Thu Nov 10 14:35:51 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Nov 2016 16:35:51 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> References: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> Message-ID: On 10/Nov/16 14:30, Joel M Snyder wrote: > > > In a world where you are doing well-controlled Cisco/Juniper/etc > networks with fairly homogeneous code bases, the engineers get to have > this discussion. When you have to link in devices for which routing > is not their primary reason to exist, your options narrow very > quickly. It's not ideal; that's just the way it is. Quagga's IS-IS implementation is a great example. Mark. From nick at foobar.org Thu Nov 10 16:50:20 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Nov 2016 16:50:20 +0000 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> Message-ID: <5824A54C.20502@foobar.org> Mikael Abrahamsson wrote: > This is a feature of IS-IS. You're less likely to get random crap in > your IGP. > > :P that alone makes a great argument for connecting to this sort of device using bgp. Some vendors approach ospf with a hilarity-first attitude, and at least bgp has the knobs to treat those sort of devices as if they had a contagious disease. Nick From aaron at heyaaron.com Thu Nov 10 17:26:03 2016 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 10 Nov 2016 09:26:03 -0800 Subject: Here we go again. In-Reply-To: <94876.1478731190@segfault.tristatelogic.com> References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> <94876.1478731190@segfault.tristatelogic.com> Message-ID: On Wed, Nov 9, 2016 at 2:39 PM, Ronald F. Guilmette wrote: > There are plenty of reasons for thinking people to be terrified today. > I don't know why you've chosen to focus on such a small one. Here's a > bigger one: > > http://bit.ly/2fTdmiG Ok--so on a somewhat NANOG-related note...please tell me that's not a *real* picture of the nuclear football and that our lives aren't in the hands of Windows Vista... ;) -A From baconzombie at gmail.com Thu Nov 10 17:36:24 2016 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 10 Nov 2016 18:36:24 +0100 Subject: Here we go again. In-Reply-To: References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> <94876.1478731190@segfault.tristatelogic.com> Message-ID: https://youtu.be/Yi_2020LJQo On Nov 10, 2016 18:27, "Aaron C. de Bruyn via NANOG" wrote: > On Wed, Nov 9, 2016 at 2:39 PM, Ronald F. Guilmette > wrote: > > There are plenty of reasons for thinking people to be terrified today. > > I don't know why you've chosen to focus on such a small one. Here's a > > bigger one: > > > > http://bit.ly/2fTdmiG > > Ok--so on a somewhat NANOG-related note...please tell me that's not a > *real* picture of the nuclear football and that our lives aren't in > the hands of Windows Vista... ;) > > -A > From josh at kyneticwifi.com Thu Nov 10 18:01:32 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 12:01:32 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: Cisco is the only "real" IS-IS vendor. Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the whitebox hardware or real SDN capable solutions, you're going to be on OSPF. On Nov 10, 2016 12:13 AM, "Mark Tinka" wrote: > > > On 10/Nov/16 04:52, Josh Reynolds wrote: > > Vendor support for IS-IS is quite limited - many options for OSPF. > > > Depends on the vendor. > > Cisco have as many knobs for IS-IS as they do for OSPF. > > Juniper, not so much. > > Don't know about other vendors. > > At any rate, many of these knobs are not part of the original protocol > spec., although they can be very useful when scaling. > > Mark. > From sthaug at nethelp.no Thu Nov 10 18:22:18 2016 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 10 Nov 2016 19:22:18 +0100 (CET) Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: <20161110.192218.74700815.sthaug@nethelp.no> > Cisco is the only "real" IS-IS vendor. > > Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the > whitebox hardware or real SDN capable solutions, you're going to be on OSPF. Maybe you need to tell us what the other companies aren't getting? We're using IS-IS on (mostly) Juniper and Huawei, but also Alcatel/ Lucent/Nokia and Cisco. It just works. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From davidbass570 at gmail.com Thu Nov 10 18:42:19 2016 From: davidbass570 at gmail.com (David Bass) Date: Thu, 10 Nov 2016 13:42:19 -0500 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: <92239B0E-991A-4E16-A18E-FA54681E82DA@gmail.com> Are you sure those other vendors don't do it too? Lol. Dual stack ISIS on Juniper is a thing of beauty... > On Nov 10, 2016, at 1:01 PM, Josh Reynolds wrote: > > Cisco is the only "real" IS-IS vendor. > > Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the > whitebox hardware or real SDN capable solutions, you're going to be on OSPF. > >> On Nov 10, 2016 12:13 AM, "Mark Tinka" wrote: >> >> >> >> On 10/Nov/16 04:52, Josh Reynolds wrote: >> >> Vendor support for IS-IS is quite limited - many options for OSPF. >> >> >> Depends on the vendor. >> >> Cisco have as many knobs for IS-IS as they do for OSPF. >> >> Juniper, not so much. >> >> Don't know about other vendors. >> >> At any rate, many of these knobs are not part of the original protocol >> spec., although they can be very useful when scaling. >> >> Mark. >> From josh at kyneticwifi.com Thu Nov 10 18:44:08 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 12:44:08 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <20161110.192218.74700815.sthaug@nethelp.no> References: <20161110.192218.74700815.sthaug@nethelp.no> Message-ID: Juniper of their own merits, but they miss many of the IS-IS features Cisco has (of course). Huawei has very "Cisco-like" code, so there's that... Can't speak for Nokia. On Nov 10, 2016 12:22 PM, wrote: > > Cisco is the only "real" IS-IS vendor. > > > > Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the > > whitebox hardware or real SDN capable solutions, you're going to be on > OSPF. > > Maybe you need to tell us what the other companies aren't getting? > We're using IS-IS on (mostly) Juniper and Huawei, but also Alcatel/ > Lucent/Nokia and Cisco. It just works. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From nick at foobar.org Thu Nov 10 19:23:19 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Nov 2016 19:23:19 +0000 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> Message-ID: <5824C927.9050103@foobar.org> Josh Reynolds wrote: > Juniper of their own merits, but they miss many of the IS-IS features > Cisco has (of course). I think people were looking for specifics about the implementation deficits in the junos version which caused enough problems to justify the term "not getting it"? Nick From baldur.norddahl at gmail.com Thu Nov 10 19:43:50 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 10 Nov 2016 20:43:50 +0100 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <5824C927.9050103@foobar.org> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> Message-ID: I prefer OSPF because it is easier to implement when you can just use a normal UDP socket instead of dealing with raw sockets... And at the day work I also prefer OSPFv2 simply because I do not need more protocols in the stack. We are running a MPLS network with the internet service in a L3VPN. IPv6 is also in the L3VPN. This means the underlying network is pure IPv4 and totally isolated from the internet. Why make it more complicated by introducing something that is not IP based? Regards, Baldur From josh at kyneticwifi.com Thu Nov 10 19:45:35 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 13:45:35 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <5824C927.9050103@foobar.org> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> Message-ID: As with anything, it depends on what your needs are. https://pathfinder.juniper.net/feature-explorer/search-features.html Type IS-IS in the box Feature set will vary between JunOS releases. On Thu, Nov 10, 2016 at 1:23 PM, Nick Hilliard wrote: > Josh Reynolds wrote: >> Juniper of their own merits, but they miss many of the IS-IS features >> Cisco has (of course). > > I think people were looking for specifics about the implementation > deficits in the junos version which caused enough problems to justify > the term "not getting it"? > > Nick From p.bonvin at edsi-tech.com Thu Nov 10 20:14:50 2016 From: p.bonvin at edsi-tech.com (Philippe Bonvin) Date: Thu, 10 Nov 2016 20:14:50 +0000 Subject: OSPFv3 with IPSec between Cisco and Juniper gears Message-ID: <1478808897291.21175@edsi-tech.com> Hello folks, Quick question about incompatibility between Cisco and Juniper gears. Without IPSec, OSPFv3 is working as expected. I'm trying to configure IPSec authentification of OSPFv3 between a Juniper SRX and a Cisco router but it seems that they didn't agree to a common key length. Can you confirm that this is a well-known problem or give me the right configuration that I should use ? The error message on the juniper: [edit security ipsec security-association ospfv3 manual direction bidirectional authentication key ascii-text] 'ascii-text "..."' Authentication key size must be 20 bytes On the cisco side: cisco(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 0 ? Hex-string SHA-1 key (40 chars)? Here is an output of the config I'm using on the SRX side: ipsec { security-association ospfv3 { mode transport; manual { direction bidirectional { protocol ah; spi 256; authentication { algorithm hmac-sha1-96; key ascii-text "..."; ## SECRET-DATA } } } } } interface ge-0/0/0.0 { ipsec-sa ospfv3; } Thanks for your help, Philippe [EDSI-Tech Sarl] Philippe Bonvin, Directeur EDSI-Tech S?rl EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41 (0) 21 566 14 15, ext. 99 Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France | T?l?phone: +33 (0)4 86 15 44 78, ext. 99 Disclaimer: This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this information, be advised that you have received this email in error and that any usage, disclosure, distribution, copying of the information or any part of it in any form whatsoever is strictly prohibited. If you have received this email in error please notify the EDSI-Tech helpdesk by phone on +41 21 566 14 15 and then delete this e-mail. From nick at foobar.org Thu Nov 10 20:27:25 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Nov 2016 20:27:25 +0000 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> Message-ID: <5824D82D.9090607@foobar.org> Josh Reynolds wrote: > As with anything, it depends on what your needs are. > > https://pathfinder.juniper.net/feature-explorer/search-features.html > > Type IS-IS in the box > > Feature set will vary between JunOS releases. Josh, you made two statements: 1. Juniper was "not getting it" and 2. "they miss many of the IS-IS features Cisco has". Could you provide details on these "many" features that Junos is missing? Linking to Juniper's feature explorer is hand-waving, and does not answer the question. Nick From josh at kyneticwifi.com Thu Nov 10 20:33:22 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 14:33:22 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <5824D82D.9090607@foobar.org> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> Message-ID: I have not kept up with all of the feature differences between Cisco's implementation and the other vendors. I can only encourage others interested in this to compare the specific feature sets between the two and see if it meets their needs. What I need in an environment from an IGP may be totally different from another data center, transport, or transit network provider. If I were a vendor or one of the other I would likely have a list of what I do support, or what my competition does not support. On Thu, Nov 10, 2016 at 2:27 PM, Nick Hilliard wrote: > Josh Reynolds wrote: >> As with anything, it depends on what your needs are. >> >> https://pathfinder.juniper.net/feature-explorer/search-features.html >> >> Type IS-IS in the box >> >> Feature set will vary between JunOS releases. > > Josh, > > you made two statements: > > 1. Juniper was "not getting it" and > 2. "they miss many of the IS-IS features Cisco has". > > Could you provide details on these "many" features that Junos is > missing? Linking to Juniper's feature explorer is hand-waving, and does > not answer the question. > > Nick > From nick at foobar.org Thu Nov 10 20:47:38 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Nov 2016 20:47:38 +0000 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> Message-ID: <5824DCEA.8030900@foobar.org> Josh Reynolds wrote: > I have not kept up with all of the feature differences between Cisco's > implementation and the other vendors. I can only encourage others > interested in this to compare the specific feature sets between the > two and see if it meets their needs. What I need in an environment > from an IGP may be totally different from another data center, > transport, or transit network provider. so you aren't prepared to (or can't) provide a single detail about all the many features that the junos isis implementation is apparently missing, which would justify saying that Juniper is "not getting it" Ok. Not even one? A tiny little thin one? Just... just one...? Nick From dhubbard at dino.hostasaurus.com Thu Nov 10 21:02:59 2016 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 10 Nov 2016 21:02:59 +0000 Subject: OSPFv3 with IPSec between Cisco and Juniper gears In-Reply-To: <1478808897291.21175@edsi-tech.com> References: <1478808897291.21175@edsi-tech.com> Message-ID: <9F1A846F-D54D-46FE-8219-7C9655A8C314@dino.hostasaurus.com> Wouldn?t you want to use hexadecimal instead of ascii-text, since that would match what the Cisco is asking for? I?m just throwing this out there, I?m not familiar with Juniper but their docs seem to suggest that using hex will cause it to ask for 40 hex chars. David On 11/10/16, 3:14 PM, "NANOG on behalf of Philippe Bonvin via NANOG" wrote: Hello folks, Quick question about incompatibility between Cisco and Juniper gears. Without IPSec, OSPFv3 is working as expected. I'm trying to configure IPSec authentification of OSPFv3 between a Juniper SRX and a Cisco router but it seems that they didn't agree to a common key length. Can you confirm that this is a well-known problem or give me the right configuration that I should use ? The error message on the juniper: [edit security ipsec security-association ospfv3 manual direction bidirectional authentication key ascii-text] 'ascii-text "..."' Authentication key size must be 20 bytes On the cisco side: cisco(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 0 ? Hex-string SHA-1 key (40 chars)? Here is an output of the config I'm using on the SRX side: ipsec { security-association ospfv3 { mode transport; manual { direction bidirectional { protocol ah; spi 256; authentication { algorithm hmac-sha1-96; key ascii-text "..."; ## SECRET-DATA } } } } } interface ge-0/0/0.0 { ipsec-sa ospfv3; } Thanks for your help, Philippe [EDSI-Tech Sarl] Philippe Bonvin, Directeur EDSI-Tech S?rl EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41 (0) 21 566 14 15, ext. 99 Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France | T?l?phone: +33 (0)4 86 15 44 78, ext. 99 Disclaimer: This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this information, be advised that you have received this email in error and that any usage, disclosure, distribution, copying of the information or any part of it in any form whatsoever is strictly prohibited. If you have received this email in error please notify the EDSI-Tech helpdesk by phone on +41 21 566 14 15 and then delete this e-mail. From josh at kyneticwifi.com Thu Nov 10 21:22:51 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 15:22:51 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <5824DCEA.8030900@foobar.org> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> Message-ID: I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS support, which was the last time *I* looked. No, I do not have a list sitting ready, that catalogs in details between product lines and specific firmware versions and subversions between multiple vendors what one supports and what one does not as of Nov 11, 2016. What I can do is point you at the vendor list where you can make a comparison of that vendor to others, for the features that you need in your environment - as I'm not getting paid to maintain such lists, and they are. On Thu, Nov 10, 2016 at 2:47 PM, Nick Hilliard wrote: > Josh Reynolds wrote: >> I have not kept up with all of the feature differences between Cisco's >> implementation and the other vendors. I can only encourage others >> interested in this to compare the specific feature sets between the >> two and see if it meets their needs. What I need in an environment >> from an IGP may be totally different from another data center, >> transport, or transit network provider. > > so you aren't prepared to (or can't) provide a single detail about all > the many features that the junos isis implementation is apparently > missing, which would justify saying that Juniper is "not getting it" > > Ok. > > Not even one? A tiny little thin one? Just... just one...? > > Nick > From p.bonvin at edsi-tech.com Thu Nov 10 21:24:00 2016 From: p.bonvin at edsi-tech.com (Philippe Bonvin) Date: Thu, 10 Nov 2016 21:24:00 +0000 Subject: OSPFv3 with IPSec between Cisco and Juniper gears In-Reply-To: <9F1A846F-D54D-46FE-8219-7C9655A8C314@dino.hostasaurus.com> References: <1478808897291.21175@edsi-tech.com>, <9F1A846F-D54D-46FE-8219-7C9655A8C314@dino.hostasaurus.com> Message-ID: <1478813047406.14125@edsi-tech.com> Yes that was it... sorry for the noise. Now the IPSec SA is up and the neighbors are stuck in ExStart state, but that's another story. ________________________________________ From: David Hubbard Sent: Thursday, November 10, 2016 22:02 To: Philippe Bonvin; nanog at nanog.org Subject: Re: OSPFv3 with IPSec between Cisco and Juniper gears Wouldn?t you want to use hexadecimal instead of ascii-text, since that would match what the Cisco is asking for? I?m just throwing this out there, I?m not familiar with Juniper but their docs seem to suggest that using hex will cause it to ask for 40 hex chars. David On 11/10/16, 3:14 PM, "NANOG on behalf of Philippe Bonvin via NANOG" wrote: Hello folks, Quick question about incompatibility between Cisco and Juniper gears. Without IPSec, OSPFv3 is working as expected. I'm trying to configure IPSec authentification of OSPFv3 between a Juniper SRX and a Cisco router but it seems that they didn't agree to a common key length. Can you confirm that this is a well-known problem or give me the right configuration that I should use ? The error message on the juniper: [edit security ipsec security-association ospfv3 manual direction bidirectional authentication key ascii-text] 'ascii-text "..."' Authentication key size must be 20 bytes On the cisco side: cisco(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 0 ? Hex-string SHA-1 key (40 chars)? Here is an output of the config I'm using on the SRX side: ipsec { security-association ospfv3 { mode transport; manual { direction bidirectional { protocol ah; spi 256; authentication { algorithm hmac-sha1-96; key ascii-text "..."; ## SECRET-DATA } } } } } interface ge-0/0/0.0 { ipsec-sa ospfv3; } Thanks for your help, Philippe [EDSI-Tech Sarl] Philippe Bonvin, Directeur EDSI-Tech S?rl EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41 (0) 21 566 14 15, ext. 99 Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France | T?l?phone: +33 (0)4 86 15 44 78, ext. 99 Disclaimer: This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this information, be advised that you have received this email in error and that any usage, disclosure, distribution, copying of the information or any part of it in any form whatsoever is strictly prohibited. If you have received this email in error please notify the EDSI-Tech helpdesk by phone on +41 21 566 14 15 and then delete this e-mail. [EDSI-Tech Sarl] Philippe Bonvin, Directeur EDSI-Tech S?rl EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41 (0) 21 566 14 15, ext. 99 Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France | T?l?phone: +33 (0)4 86 15 44 78, ext. 99 Disclaimer: This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this information, be advised that you have received this email in error and that any usage, disclosure, distribution, copying of the information or any part of it in any form whatsoever is strictly prohibited. If you have received this email in error please notify the EDSI-Tech helpdesk by phone on +41 21 566 14 15 and then delete this e-mail. From nick at foobar.org Thu Nov 10 21:49:46 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Nov 2016 21:49:46 +0000 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> Message-ID: <5824EB7A.2060602@foobar.org> Josh Reynolds wrote: > I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS > support, which was the last time *I* looked. > > No, I do not have a list sitting ready, that catalogs in details > between product lines and specific firmware versions and subversions > between multiple vendors what one supports and what one does not as of > Nov 11, 2016. > > What I can do is point you at the vendor list where you can make a > comparison of that vendor to others, for the features that you need in > your environment - as I'm not getting paid to maintain such lists, and > they are. So what you're saying is that you can't even provide a single missing feature to justify trash-talking a vendor the way you did? Not even one?? Nick From charles at phukish.com Thu Nov 10 21:53:30 2016 From: charles at phukish.com (Charles van Niman) Date: Thu, 10 Nov 2016 15:53:30 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> Message-ID: I don't think Nick asked for a list, just one single thing, any one thing. To me at least, it doesn't really make sense to make the statement you did, without pointing out what can be done to improve the situation. I would be very interested to hear what network requirements are not being met with Juniper's current IS-IS implementation. /Charles On Thu, Nov 10, 2016 at 3:22 PM, Josh Reynolds wrote: > I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS > support, which was the last time *I* looked. > > No, I do not have a list sitting ready, that catalogs in details > between product lines and specific firmware versions and subversions > between multiple vendors what one supports and what one does not as of > Nov 11, 2016. > > What I can do is point you at the vendor list where you can make a > comparison of that vendor to others, for the features that you need in > your environment - as I'm not getting paid to maintain such lists, and > they are. > > On Thu, Nov 10, 2016 at 2:47 PM, Nick Hilliard wrote: >> Josh Reynolds wrote: >>> I have not kept up with all of the feature differences between Cisco's >>> implementation and the other vendors. I can only encourage others >>> interested in this to compare the specific feature sets between the >>> two and see if it meets their needs. What I need in an environment >>> from an IGP may be totally different from another data center, >>> transport, or transit network provider. >> >> so you aren't prepared to (or can't) provide a single detail about all >> the many features that the junos isis implementation is apparently >> missing, which would justify saying that Juniper is "not getting it" >> >> Ok. >> >> Not even one? A tiny little thin one? Just... just one...? >> >> Nick >> From josh at kyneticwifi.com Thu Nov 10 22:03:18 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 16:03:18 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <5824EB7A.2060602@foobar.org> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> Message-ID: I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush. Cisco has been pushing EIGRP and IS-IS as part of their "showing" for decades. During that same time frame, the majority of the other vendors and the open source daemons have been using OSPF as their IGP offering. In the mean time, Cisco found a need to introduce more and more vendor specific features into their IS-IS offering - no different than any other vendor would do in their situation to promote the business case (better scaling, vendor lock-in, other bits). If you go looking for cross vendor compatibility with as many devices (routers, switches, servers, etc) as possible, you're going to end up with OSPF [or BGP, for the data center types that run it to edge nodes]. You will find a handful, as some have mentioned, of vendors that have adopted the open version of the protocol and have tried to add comparable/compatible features to close the gap. Since the last time I looked, I could not get the same feature sets running IS-IS in a multi-vendor environment as I could running OSPF. This was my experience at the time, based on my research and discussions with the vendors. On Nov 10, 2016 3:49 PM, "Nick Hilliard" wrote: > Josh Reynolds wrote: > > I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS > > support, which was the last time *I* looked. > > > > No, I do not have a list sitting ready, that catalogs in details > > between product lines and specific firmware versions and subversions > > between multiple vendors what one supports and what one does not as of > > Nov 11, 2016. > > > > What I can do is point you at the vendor list where you can make a > > comparison of that vendor to others, for the features that you need in > > your environment - as I'm not getting paid to maintain such lists, and > > they are. > > So what you're saying is that you can't even provide a single missing > feature to justify trash-talking a vendor the way you did? Not even one?? > > Nick > > From nick at foobar.org Thu Nov 10 23:33:39 2016 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Nov 2016 23:33:39 +0000 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> Message-ID: <582503D3.40808@foobar.org> Josh Reynolds wrote: > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand > line hate fueled rant with examples and enough colorful language to make > submarine crews blush. I have no doubt it would be the best rant. It would be a beautiful rant. Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits. Nick From josh at kyneticwifi.com Fri Nov 11 00:00:20 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 18:00:20 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <582503D3.40808@foobar.org> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: As cute as your impotent white knighting of one vendor is (I very much like Juniper BTW), you're absolutely ignoring my original premise and point because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them. So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the point of my statement mind you, it's simply a sidetrack that has wasted enough time already. That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet. Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP. On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: > Josh Reynolds wrote: > > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand > > line hate fueled rant with examples and enough colorful language to make > > submarine crews blush. > > I have no doubt it would be the best rant. It would be a beautiful rant. > > Entertaining and all as hand-waving may be, please let us know if you > manage to unearth any actual facts to support the claims that you made > about junos's alleged feature deficits. > > Nick > > From charles at phukish.com Fri Nov 11 00:24:19 2016 From: charles at phukish.com (Charles van Niman) Date: Thu, 10 Nov 2016 18:24:19 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details. Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs. /Charles On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds wrote: > As cute as your impotent white knighting of one vendor is (I very much like > Juniper BTW), you're absolutely ignoring my original premise and point > because you got your panties in a wad over a potential triviality of an > internet comment - where documentation exists, should one take the time to > go through it, to find discrepancies between them. > > So, if you'd like to prove your point and earn brownie points with $vendor, > on a feature by feature basis please take the time to consult documentation > of two vendors products (you can even pick the platform and subversion > release!) to refute my claim. This has nothing at all to do with the point > of my statement mind you, it's simply a sidetrack that has wasted enough > time already. > > That said, glance across the landscape as a whole of all of the routing > platforms out there. Hardware AND softwsre. Which ones support bare bones > IS-IS? Which ones have a decent subset of extensions? Are they comparable > or compatible with others? The end result is a *very mixed bag*, with far > more not supporting IS-IS at all, or only supporting the bare minimum to > even go by that name in a datasheet. > > Thus, my point stands. If you want as much flexibility in your environment > as you can have, you want OSPF or BGP as your IGP. > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: > >> Josh Reynolds wrote: >> > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand >> > line hate fueled rant with examples and enough colorful language to make >> > submarine crews blush. >> >> I have no doubt it would be the best rant. It would be a beautiful rant. >> >> Entertaining and all as hand-waving may be, please let us know if you >> manage to unearth any actual facts to support the claims that you made >> about junos's alleged feature deficits. >> >> Nick >> >> From josh at kyneticwifi.com Fri Nov 11 00:33:39 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 18:33:39 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: My first post said the following: "Vendor support for IS-IS is quite limited - many options for OSPF." On Nov 10, 2016 6:24 PM, "Charles van Niman" wrote: > Your original point was that a list of vendors "didn't get IS-IS" but > provided no details about what you are talking about. As far as all > the documentation I have read, and some of the documentation you > linked to, it works just fine on quite a few vendors, and a few people > on this list. Your original point mentions nothing about wider OSPF > adoption, which you seem to have shifted to to deflect having to > provide any actual details. > > Are we to assume that your original point was incorrect? As far as the > landscape as a whole, I have seen quite a few networks that get by > with either protocol just fine, the use-case for a given network is > not such a broad landscape, so I think "use the right tool for the > job" seems very apt, and that you can't just say that only two > protocols are suitable for all jobs. > > /Charles > > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds > wrote: > > As cute as your impotent white knighting of one vendor is (I very much > like > > Juniper BTW), you're absolutely ignoring my original premise and point > > because you got your panties in a wad over a potential triviality of an > > internet comment - where documentation exists, should one take the time > to > > go through it, to find discrepancies between them. > > > > So, if you'd like to prove your point and earn brownie points with > $vendor, > > on a feature by feature basis please take the time to consult > documentation > > of two vendors products (you can even pick the platform and subversion > > release!) to refute my claim. This has nothing at all to do with the > point > > of my statement mind you, it's simply a sidetrack that has wasted enough > > time already. > > > > That said, glance across the landscape as a whole of all of the routing > > platforms out there. Hardware AND softwsre. Which ones support bare bones > > IS-IS? Which ones have a decent subset of extensions? Are they comparable > > or compatible with others? The end result is a *very mixed bag*, with far > > more not supporting IS-IS at all, or only supporting the bare minimum to > > even go by that name in a datasheet. > > > > Thus, my point stands. If you want as much flexibility in your > environment > > as you can have, you want OSPF or BGP as your IGP. > > > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: > > > >> Josh Reynolds wrote: > >> > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand > >> > line hate fueled rant with examples and enough colorful language to > make > >> > submarine crews blush. > >> > >> I have no doubt it would be the best rant. It would be a beautiful > rant. > >> > >> Entertaining and all as hand-waving may be, please let us know if you > >> manage to unearth any actual facts to support the claims that you made > >> about junos's alleged feature deficits. > >> > >> Nick > >> > >> > From jackson.tim at gmail.com Fri Nov 11 00:50:48 2016 From: jackson.tim at gmail.com (Tim Jackson) Date: Thu, 10 Nov 2016 18:50:48 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: Maybe you didn't look hard enough? ISIS feature support in a bunch of different products has sucked for a long time vs OSPF, but that's a pretty well known and accepted fact. Generally these features are the same across multiple products from the same vendor (usually across the same OS anyway)... Just name 1 feature that was in Cisco and wasn't in other implementations........... Just one.. Something.. Does ISIS on IOS make and hand out ice cream on Fridays? I want to know if I'm missing out.. -- Tim On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds wrote: > My first post said the following: > > "Vendor support for IS-IS is quite limited - many options for OSPF." > > On Nov 10, 2016 6:24 PM, "Charles van Niman" wrote: > > > Your original point was that a list of vendors "didn't get IS-IS" but > > provided no details about what you are talking about. As far as all > > the documentation I have read, and some of the documentation you > > linked to, it works just fine on quite a few vendors, and a few people > > on this list. Your original point mentions nothing about wider OSPF > > adoption, which you seem to have shifted to to deflect having to > > provide any actual details. > > > > Are we to assume that your original point was incorrect? As far as the > > landscape as a whole, I have seen quite a few networks that get by > > with either protocol just fine, the use-case for a given network is > > not such a broad landscape, so I think "use the right tool for the > > job" seems very apt, and that you can't just say that only two > > protocols are suitable for all jobs. > > > > /Charles > > > > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds > > wrote: > > > As cute as your impotent white knighting of one vendor is (I very much > > like > > > Juniper BTW), you're absolutely ignoring my original premise and point > > > because you got your panties in a wad over a potential triviality of an > > > internet comment - where documentation exists, should one take the time > > to > > > go through it, to find discrepancies between them. > > > > > > So, if you'd like to prove your point and earn brownie points with > > $vendor, > > > on a feature by feature basis please take the time to consult > > documentation > > > of two vendors products (you can even pick the platform and subversion > > > release!) to refute my claim. This has nothing at all to do with the > > point > > > of my statement mind you, it's simply a sidetrack that has wasted > enough > > > time already. > > > > > > That said, glance across the landscape as a whole of all of the routing > > > platforms out there. Hardware AND softwsre. Which ones support bare > bones > > > IS-IS? Which ones have a decent subset of extensions? Are they > comparable > > > or compatible with others? The end result is a *very mixed bag*, with > far > > > more not supporting IS-IS at all, or only supporting the bare minimum > to > > > even go by that name in a datasheet. > > > > > > Thus, my point stands. If you want as much flexibility in your > > environment > > > as you can have, you want OSPF or BGP as your IGP. > > > > > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: > > > > > >> Josh Reynolds wrote: > > >> > I didn't "trash talk" a vendor. If I did, it would be a > multi-thousand > > >> > line hate fueled rant with examples and enough colorful language to > > make > > >> > submarine crews blush. > > >> > > >> I have no doubt it would be the best rant. It would be a beautiful > > rant. > > >> > > >> Entertaining and all as hand-waving may be, please let us know if you > > >> manage to unearth any actual facts to support the claims that you made > > >> about junos's alleged feature deficits. > > >> > > >> Nick > > >> > > >> > > > From josh at kyneticwifi.com Fri Nov 11 00:53:57 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 18:53:57 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: Here's a start! "Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known issues." On Nov 10, 2016 6:50 PM, "Tim Jackson" wrote: > Maybe you didn't look hard enough? > > ISIS feature support in a bunch of different products has sucked for a > long time vs OSPF, but that's a pretty well known and accepted fact. > Generally these features are the same across multiple products from the > same vendor (usually across the same OS anyway)... > > Just name 1 feature that was in Cisco and wasn't in other > implementations........... Just one.. Something.. Does ISIS on IOS make and > hand out ice cream on Fridays? I want to know if I'm missing out.. > > -- > Tim > > On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds > wrote: > >> My first post said the following: >> >> "Vendor support for IS-IS is quite limited - many options for OSPF." >> >> On Nov 10, 2016 6:24 PM, "Charles van Niman" wrote: >> >> > Your original point was that a list of vendors "didn't get IS-IS" but >> > provided no details about what you are talking about. As far as all >> > the documentation I have read, and some of the documentation you >> > linked to, it works just fine on quite a few vendors, and a few people >> > on this list. Your original point mentions nothing about wider OSPF >> > adoption, which you seem to have shifted to to deflect having to >> > provide any actual details. >> > >> > Are we to assume that your original point was incorrect? As far as the >> > landscape as a whole, I have seen quite a few networks that get by >> > with either protocol just fine, the use-case for a given network is >> > not such a broad landscape, so I think "use the right tool for the >> > job" seems very apt, and that you can't just say that only two >> > protocols are suitable for all jobs. >> > >> > /Charles >> > >> > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds >> > wrote: >> > > As cute as your impotent white knighting of one vendor is (I very much >> > like >> > > Juniper BTW), you're absolutely ignoring my original premise and point >> > > because you got your panties in a wad over a potential triviality of >> an >> > > internet comment - where documentation exists, should one take the >> time >> > to >> > > go through it, to find discrepancies between them. >> > > >> > > So, if you'd like to prove your point and earn brownie points with >> > $vendor, >> > > on a feature by feature basis please take the time to consult >> > documentation >> > > of two vendors products (you can even pick the platform and subversion >> > > release!) to refute my claim. This has nothing at all to do with the >> > point >> > > of my statement mind you, it's simply a sidetrack that has wasted >> enough >> > > time already. >> > > >> > > That said, glance across the landscape as a whole of all of the >> routing >> > > platforms out there. Hardware AND softwsre. Which ones support bare >> bones >> > > IS-IS? Which ones have a decent subset of extensions? Are they >> comparable >> > > or compatible with others? The end result is a *very mixed bag*, with >> far >> > > more not supporting IS-IS at all, or only supporting the bare minimum >> to >> > > even go by that name in a datasheet. >> > > >> > > Thus, my point stands. If you want as much flexibility in your >> > environment >> > > as you can have, you want OSPF or BGP as your IGP. >> > > >> > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: >> > > >> > >> Josh Reynolds wrote: >> > >> > I didn't "trash talk" a vendor. If I did, it would be a >> multi-thousand >> > >> > line hate fueled rant with examples and enough colorful language to >> > make >> > >> > submarine crews blush. >> > >> >> > >> I have no doubt it would be the best rant. It would be a beautiful >> > rant. >> > >> >> > >> Entertaining and all as hand-waving may be, please let us know if you >> > >> manage to unearth any actual facts to support the claims that you >> made >> > >> about junos's alleged feature deficits. >> > >> >> > >> Nick >> > >> >> > >> >> > >> > > From josh at kyneticwifi.com Fri Nov 11 00:54:36 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 18:54:36 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: Oops, forgot link. Cooking dinner :) http://www.nongnu.org/quagga/ On Nov 10, 2016 6:53 PM, "Josh Reynolds" wrote: > Here's a start! > > "Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for > IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known > issues." > > On Nov 10, 2016 6:50 PM, "Tim Jackson" wrote: > >> Maybe you didn't look hard enough? >> >> ISIS feature support in a bunch of different products has sucked for a >> long time vs OSPF, but that's a pretty well known and accepted fact. >> Generally these features are the same across multiple products from the >> same vendor (usually across the same OS anyway)... >> >> Just name 1 feature that was in Cisco and wasn't in other >> implementations........... Just one.. Something.. Does ISIS on IOS make and >> hand out ice cream on Fridays? I want to know if I'm missing out.. >> >> -- >> Tim >> >> On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds >> wrote: >> >>> My first post said the following: >>> >>> "Vendor support for IS-IS is quite limited - many options for OSPF." >>> >>> On Nov 10, 2016 6:24 PM, "Charles van Niman" >>> wrote: >>> >>> > Your original point was that a list of vendors "didn't get IS-IS" but >>> > provided no details about what you are talking about. As far as all >>> > the documentation I have read, and some of the documentation you >>> > linked to, it works just fine on quite a few vendors, and a few people >>> > on this list. Your original point mentions nothing about wider OSPF >>> > adoption, which you seem to have shifted to to deflect having to >>> > provide any actual details. >>> > >>> > Are we to assume that your original point was incorrect? As far as the >>> > landscape as a whole, I have seen quite a few networks that get by >>> > with either protocol just fine, the use-case for a given network is >>> > not such a broad landscape, so I think "use the right tool for the >>> > job" seems very apt, and that you can't just say that only two >>> > protocols are suitable for all jobs. >>> > >>> > /Charles >>> > >>> > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds >>> > wrote: >>> > > As cute as your impotent white knighting of one vendor is (I very >>> much >>> > like >>> > > Juniper BTW), you're absolutely ignoring my original premise and >>> point >>> > > because you got your panties in a wad over a potential triviality of >>> an >>> > > internet comment - where documentation exists, should one take the >>> time >>> > to >>> > > go through it, to find discrepancies between them. >>> > > >>> > > So, if you'd like to prove your point and earn brownie points with >>> > $vendor, >>> > > on a feature by feature basis please take the time to consult >>> > documentation >>> > > of two vendors products (you can even pick the platform and >>> subversion >>> > > release!) to refute my claim. This has nothing at all to do with the >>> > point >>> > > of my statement mind you, it's simply a sidetrack that has wasted >>> enough >>> > > time already. >>> > > >>> > > That said, glance across the landscape as a whole of all of the >>> routing >>> > > platforms out there. Hardware AND softwsre. Which ones support bare >>> bones >>> > > IS-IS? Which ones have a decent subset of extensions? Are they >>> comparable >>> > > or compatible with others? The end result is a *very mixed bag*, >>> with far >>> > > more not supporting IS-IS at all, or only supporting the bare >>> minimum to >>> > > even go by that name in a datasheet. >>> > > >>> > > Thus, my point stands. If you want as much flexibility in your >>> > environment >>> > > as you can have, you want OSPF or BGP as your IGP. >>> > > >>> > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: >>> > > >>> > >> Josh Reynolds wrote: >>> > >> > I didn't "trash talk" a vendor. If I did, it would be a >>> multi-thousand >>> > >> > line hate fueled rant with examples and enough colorful language >>> to >>> > make >>> > >> > submarine crews blush. >>> > >> >>> > >> I have no doubt it would be the best rant. It would be a beautiful >>> > rant. >>> > >> >>> > >> Entertaining and all as hand-waving may be, please let us know if >>> you >>> > >> manage to unearth any actual facts to support the claims that you >>> made >>> > >> about junos's alleged feature deficits. >>> > >> >>> > >> Nick >>> > >> >>> > >> >>> > >>> >> >> From jackson.tim at gmail.com Fri Nov 11 01:01:39 2016 From: jackson.tim at gmail.com (Tim Jackson) Date: Thu, 10 Nov 2016 19:01:39 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: So what about commercial implementations? -- Tim On Thu, Nov 10, 2016 at 6:54 PM, Josh Reynolds wrote: > Oops, forgot link. Cooking dinner :) > > http://www.nongnu.org/quagga/ > > On Nov 10, 2016 6:53 PM, "Josh Reynolds" wrote: > >> Here's a start! >> >> "Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for >> IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known >> issues." >> >> On Nov 10, 2016 6:50 PM, "Tim Jackson" wrote: >> >>> Maybe you didn't look hard enough? >>> >>> ISIS feature support in a bunch of different products has sucked for a >>> long time vs OSPF, but that's a pretty well known and accepted fact. >>> Generally these features are the same across multiple products from the >>> same vendor (usually across the same OS anyway)... >>> >>> Just name 1 feature that was in Cisco and wasn't in other >>> implementations........... Just one.. Something.. Does ISIS on IOS make and >>> hand out ice cream on Fridays? I want to know if I'm missing out.. >>> >>> -- >>> Tim >>> >>> On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds >>> wrote: >>> >>>> My first post said the following: >>>> >>>> "Vendor support for IS-IS is quite limited - many options for OSPF." >>>> >>>> On Nov 10, 2016 6:24 PM, "Charles van Niman" >>>> wrote: >>>> >>>> > Your original point was that a list of vendors "didn't get IS-IS" but >>>> > provided no details about what you are talking about. As far as all >>>> > the documentation I have read, and some of the documentation you >>>> > linked to, it works just fine on quite a few vendors, and a few people >>>> > on this list. Your original point mentions nothing about wider OSPF >>>> > adoption, which you seem to have shifted to to deflect having to >>>> > provide any actual details. >>>> > >>>> > Are we to assume that your original point was incorrect? As far as the >>>> > landscape as a whole, I have seen quite a few networks that get by >>>> > with either protocol just fine, the use-case for a given network is >>>> > not such a broad landscape, so I think "use the right tool for the >>>> > job" seems very apt, and that you can't just say that only two >>>> > protocols are suitable for all jobs. >>>> > >>>> > /Charles >>>> > >>>> > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds >>>> > wrote: >>>> > > As cute as your impotent white knighting of one vendor is (I very >>>> much >>>> > like >>>> > > Juniper BTW), you're absolutely ignoring my original premise and >>>> point >>>> > > because you got your panties in a wad over a potential triviality >>>> of an >>>> > > internet comment - where documentation exists, should one take the >>>> time >>>> > to >>>> > > go through it, to find discrepancies between them. >>>> > > >>>> > > So, if you'd like to prove your point and earn brownie points with >>>> > $vendor, >>>> > > on a feature by feature basis please take the time to consult >>>> > documentation >>>> > > of two vendors products (you can even pick the platform and >>>> subversion >>>> > > release!) to refute my claim. This has nothing at all to do with the >>>> > point >>>> > > of my statement mind you, it's simply a sidetrack that has wasted >>>> enough >>>> > > time already. >>>> > > >>>> > > That said, glance across the landscape as a whole of all of the >>>> routing >>>> > > platforms out there. Hardware AND softwsre. Which ones support bare >>>> bones >>>> > > IS-IS? Which ones have a decent subset of extensions? Are they >>>> comparable >>>> > > or compatible with others? The end result is a *very mixed bag*, >>>> with far >>>> > > more not supporting IS-IS at all, or only supporting the bare >>>> minimum to >>>> > > even go by that name in a datasheet. >>>> > > >>>> > > Thus, my point stands. If you want as much flexibility in your >>>> > environment >>>> > > as you can have, you want OSPF or BGP as your IGP. >>>> > > >>>> > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: >>>> > > >>>> > >> Josh Reynolds wrote: >>>> > >> > I didn't "trash talk" a vendor. If I did, it would be a >>>> multi-thousand >>>> > >> > line hate fueled rant with examples and enough colorful language >>>> to >>>> > make >>>> > >> > submarine crews blush. >>>> > >> >>>> > >> I have no doubt it would be the best rant. It would be a beautiful >>>> > rant. >>>> > >> >>>> > >> Entertaining and all as hand-waving may be, please let us know if >>>> you >>>> > >> manage to unearth any actual facts to support the claims that you >>>> made >>>> > >> about junos's alleged feature deficits. >>>> > >> >>>> > >> Nick >>>> > >> >>>> > >> >>>> > >>>> >>> >>> From josh at kyneticwifi.com Fri Nov 11 01:04:32 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 19:04:32 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: So, we need to narrow the discussion now to only commercial solutions? This is fun and all (not really) but you can have your thread. Congrats, you win. I'm not sure what. On Nov 10, 2016 7:01 PM, "Tim Jackson" wrote: > So what about commercial implementations? > > -- > Tim > > On Thu, Nov 10, 2016 at 6:54 PM, Josh Reynolds > wrote: > >> Oops, forgot link. Cooking dinner :) >> >> http://www.nongnu.org/quagga/ >> >> On Nov 10, 2016 6:53 PM, "Josh Reynolds" wrote: >> >>> Here's a start! >>> >>> "Support for OSPFv3 and IS-IS is various beta states currently; IS-IS >>> for IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have >>> known issues." >>> >>> On Nov 10, 2016 6:50 PM, "Tim Jackson" wrote: >>> >>>> Maybe you didn't look hard enough? >>>> >>>> ISIS feature support in a bunch of different products has sucked for a >>>> long time vs OSPF, but that's a pretty well known and accepted fact. >>>> Generally these features are the same across multiple products from the >>>> same vendor (usually across the same OS anyway)... >>>> >>>> Just name 1 feature that was in Cisco and wasn't in other >>>> implementations........... Just one.. Something.. Does ISIS on IOS make and >>>> hand out ice cream on Fridays? I want to know if I'm missing out.. >>>> >>>> -- >>>> Tim >>>> >>>> On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds >>>> wrote: >>>> >>>>> My first post said the following: >>>>> >>>>> "Vendor support for IS-IS is quite limited - many options for OSPF." >>>>> >>>>> On Nov 10, 2016 6:24 PM, "Charles van Niman" >>>>> wrote: >>>>> >>>>> > Your original point was that a list of vendors "didn't get IS-IS" but >>>>> > provided no details about what you are talking about. As far as all >>>>> > the documentation I have read, and some of the documentation you >>>>> > linked to, it works just fine on quite a few vendors, and a few >>>>> people >>>>> > on this list. Your original point mentions nothing about wider OSPF >>>>> > adoption, which you seem to have shifted to to deflect having to >>>>> > provide any actual details. >>>>> > >>>>> > Are we to assume that your original point was incorrect? As far as >>>>> the >>>>> > landscape as a whole, I have seen quite a few networks that get by >>>>> > with either protocol just fine, the use-case for a given network is >>>>> > not such a broad landscape, so I think "use the right tool for the >>>>> > job" seems very apt, and that you can't just say that only two >>>>> > protocols are suitable for all jobs. >>>>> > >>>>> > /Charles >>>>> > >>>>> > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds >>>> > >>>>> > wrote: >>>>> > > As cute as your impotent white knighting of one vendor is (I very >>>>> much >>>>> > like >>>>> > > Juniper BTW), you're absolutely ignoring my original premise and >>>>> point >>>>> > > because you got your panties in a wad over a potential triviality >>>>> of an >>>>> > > internet comment - where documentation exists, should one take the >>>>> time >>>>> > to >>>>> > > go through it, to find discrepancies between them. >>>>> > > >>>>> > > So, if you'd like to prove your point and earn brownie points with >>>>> > $vendor, >>>>> > > on a feature by feature basis please take the time to consult >>>>> > documentation >>>>> > > of two vendors products (you can even pick the platform and >>>>> subversion >>>>> > > release!) to refute my claim. This has nothing at all to do with >>>>> the >>>>> > point >>>>> > > of my statement mind you, it's simply a sidetrack that has wasted >>>>> enough >>>>> > > time already. >>>>> > > >>>>> > > That said, glance across the landscape as a whole of all of the >>>>> routing >>>>> > > platforms out there. Hardware AND softwsre. Which ones support >>>>> bare bones >>>>> > > IS-IS? Which ones have a decent subset of extensions? Are they >>>>> comparable >>>>> > > or compatible with others? The end result is a *very mixed bag*, >>>>> with far >>>>> > > more not supporting IS-IS at all, or only supporting the bare >>>>> minimum to >>>>> > > even go by that name in a datasheet. >>>>> > > >>>>> > > Thus, my point stands. If you want as much flexibility in your >>>>> > environment >>>>> > > as you can have, you want OSPF or BGP as your IGP. >>>>> > > >>>>> > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: >>>>> > > >>>>> > >> Josh Reynolds wrote: >>>>> > >> > I didn't "trash talk" a vendor. If I did, it would be a >>>>> multi-thousand >>>>> > >> > line hate fueled rant with examples and enough colorful >>>>> language to >>>>> > make >>>>> > >> > submarine crews blush. >>>>> > >> >>>>> > >> I have no doubt it would be the best rant. It would be a >>>>> beautiful >>>>> > rant. >>>>> > >> >>>>> > >> Entertaining and all as hand-waving may be, please let us know if >>>>> you >>>>> > >> manage to unearth any actual facts to support the claims that you >>>>> made >>>>> > >> about junos's alleged feature deficits. >>>>> > >> >>>>> > >> Nick >>>>> > >> >>>>> > >> >>>>> > >>>>> >>>> >>>> > From jackson.tim at gmail.com Fri Nov 11 01:06:47 2016 From: jackson.tim at gmail.com (Tim Jackson) Date: Thu, 10 Nov 2016 19:06:47 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: Uh......... I quote: > Cisco is the only "real" IS-IS vendor. > Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the > whitebox hardware or real SDN capable solutions, you're going to be on OSPF. Care to elaborate on any of those commercial vendors? -- Tim On Thu, Nov 10, 2016 at 7:04 PM, Josh Reynolds wrote: > So, we need to narrow the discussion now to only commercial solutions? > > This is fun and all (not really) but you can have your thread. > > Congrats, you win. I'm not sure what. > > On Nov 10, 2016 7:01 PM, "Tim Jackson" wrote: > >> So what about commercial implementations? >> >> -- >> Tim >> >> On Thu, Nov 10, 2016 at 6:54 PM, Josh Reynolds >> wrote: >> >>> Oops, forgot link. Cooking dinner :) >>> >>> http://www.nongnu.org/quagga/ >>> >>> On Nov 10, 2016 6:53 PM, "Josh Reynolds" wrote: >>> >>>> Here's a start! >>>> >>>> "Support for OSPFv3 and IS-IS is various beta states currently; IS-IS >>>> for IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have >>>> known issues." >>>> >>>> On Nov 10, 2016 6:50 PM, "Tim Jackson" wrote: >>>> >>>>> Maybe you didn't look hard enough? >>>>> >>>>> ISIS feature support in a bunch of different products has sucked for a >>>>> long time vs OSPF, but that's a pretty well known and accepted fact. >>>>> Generally these features are the same across multiple products from the >>>>> same vendor (usually across the same OS anyway)... >>>>> >>>>> Just name 1 feature that was in Cisco and wasn't in other >>>>> implementations........... Just one.. Something.. Does ISIS on IOS make and >>>>> hand out ice cream on Fridays? I want to know if I'm missing out.. >>>>> >>>>> -- >>>>> Tim >>>>> >>>>> On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds >>>>> wrote: >>>>> >>>>>> My first post said the following: >>>>>> >>>>>> "Vendor support for IS-IS is quite limited - many options for OSPF." >>>>>> >>>>>> On Nov 10, 2016 6:24 PM, "Charles van Niman" >>>>>> wrote: >>>>>> >>>>>> > Your original point was that a list of vendors "didn't get IS-IS" >>>>>> but >>>>>> > provided no details about what you are talking about. As far as all >>>>>> > the documentation I have read, and some of the documentation you >>>>>> > linked to, it works just fine on quite a few vendors, and a few >>>>>> people >>>>>> > on this list. Your original point mentions nothing about wider OSPF >>>>>> > adoption, which you seem to have shifted to to deflect having to >>>>>> > provide any actual details. >>>>>> > >>>>>> > Are we to assume that your original point was incorrect? As far as >>>>>> the >>>>>> > landscape as a whole, I have seen quite a few networks that get by >>>>>> > with either protocol just fine, the use-case for a given network is >>>>>> > not such a broad landscape, so I think "use the right tool for the >>>>>> > job" seems very apt, and that you can't just say that only two >>>>>> > protocols are suitable for all jobs. >>>>>> > >>>>>> > /Charles >>>>>> > >>>>>> > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds < >>>>>> josh at kyneticwifi.com> >>>>>> > wrote: >>>>>> > > As cute as your impotent white knighting of one vendor is (I very >>>>>> much >>>>>> > like >>>>>> > > Juniper BTW), you're absolutely ignoring my original premise and >>>>>> point >>>>>> > > because you got your panties in a wad over a potential triviality >>>>>> of an >>>>>> > > internet comment - where documentation exists, should one take >>>>>> the time >>>>>> > to >>>>>> > > go through it, to find discrepancies between them. >>>>>> > > >>>>>> > > So, if you'd like to prove your point and earn brownie points with >>>>>> > $vendor, >>>>>> > > on a feature by feature basis please take the time to consult >>>>>> > documentation >>>>>> > > of two vendors products (you can even pick the platform and >>>>>> subversion >>>>>> > > release!) to refute my claim. This has nothing at all to do with >>>>>> the >>>>>> > point >>>>>> > > of my statement mind you, it's simply a sidetrack that has wasted >>>>>> enough >>>>>> > > time already. >>>>>> > > >>>>>> > > That said, glance across the landscape as a whole of all of the >>>>>> routing >>>>>> > > platforms out there. Hardware AND softwsre. Which ones support >>>>>> bare bones >>>>>> > > IS-IS? Which ones have a decent subset of extensions? Are they >>>>>> comparable >>>>>> > > or compatible with others? The end result is a *very mixed bag*, >>>>>> with far >>>>>> > > more not supporting IS-IS at all, or only supporting the bare >>>>>> minimum to >>>>>> > > even go by that name in a datasheet. >>>>>> > > >>>>>> > > Thus, my point stands. If you want as much flexibility in your >>>>>> > environment >>>>>> > > as you can have, you want OSPF or BGP as your IGP. >>>>>> > > >>>>>> > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: >>>>>> > > >>>>>> > >> Josh Reynolds wrote: >>>>>> > >> > I didn't "trash talk" a vendor. If I did, it would be a >>>>>> multi-thousand >>>>>> > >> > line hate fueled rant with examples and enough colorful >>>>>> language to >>>>>> > make >>>>>> > >> > submarine crews blush. >>>>>> > >> >>>>>> > >> I have no doubt it would be the best rant. It would be a >>>>>> beautiful >>>>>> > rant. >>>>>> > >> >>>>>> > >> Entertaining and all as hand-waving may be, please let us know >>>>>> if you >>>>>> > >> manage to unearth any actual facts to support the claims that >>>>>> you made >>>>>> > >> about junos's alleged feature deficits. >>>>>> > >> >>>>>> > >> Nick >>>>>> > >> >>>>>> > >> >>>>>> > >>>>>> >>>>> >>>>> >> From Valdis.Kletnieks at vt.edu Fri Nov 11 04:12:22 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Nov 2016 23:12:22 -0500 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: <21519.1478837542@turing-police.cc.vt.edu> On Thu, 10 Nov 2016 18:54:36 -0600, Josh Reynolds said: > Oops, forgot link. Cooking dinner :) > > http://www.nongnu.org/quagga/ So you have *one* implementation that admits it's still somewhat lacking? Color me...... underwhelmed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From rfg at tristatelogic.com Fri Nov 11 05:25:03 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 10 Nov 2016 21:25:03 -0800 Subject: AS30186 - Squatted or not? You be the judge. Message-ID: <9042.1478841903@segfault.tristatelogic.com> I kinda messed up the last time I posted something here about possible IP address block squatting, so I'm not going to make any definitive assertions regarding conclusion this time. I'm just going to lay out the facts and let all of you good folks decide for yourselves. AS30186 is registered to Ross Technology Inc. of Austin, Texas. Also registered to this same entity are the following IPv4 address blocks: 143.187.0.0/16 204.8.136.0/21 Wikipedia kindly provides us with information about this (former) company: https://en.wikipedia.org/wiki/Ross_Technology "Ross Technology, Inc. was a semiconductor design and manufacturing company, specializing in SPARC microprocessors. It was founded in Austin, Texas in August 1988 by Dr. Roger D. Ross,... ... Ross Technology closed down in 1998 and all its assets and patents became the property of Fujitsu Ltd." So, it would appear that we hve a zombie company, with its very own ASN and valuable /16 and /21 IPv4 address blocks to boot. According to the above history, these are all the rightful property of Fujitsu Ltd. Fujitsu Ltd. is not a small or insignificant company, and to the best of my knowledge it is not currently in any sort of financial straits or difficulties. It would thus seem somewhat implausible that Fujitsu, a big "household name" Japanese company would elect to either sell off or sub-lease out their ASN or either of their valuable Ross-related IPv4 address blocks to scumbag snowshoe spammers. Despite this fact however, abundant evidence I've collected recently indicates rather convincingly that both AS30186 and also, at least, the 204.8.136.0/21 address block are, at the present time, inhabited completely and only by a large scale snowshoe spamming operation. Current forward resilutions of numerous interrelated snowshoe spamming domains provide clear evidence of this: http://pastebin.com/raw/hEY1nxct AS30186 is announcing the following routes at the present moment: 143.187.0.0/24 143.187.1.0/24 143.187.2.0/24 143.187.3.0/24 143.187.4.0/22 143.187.8.0/21 143.187.16.0/20 143.187.32.0/19 143.187.64.0/18 143.187.128.0/24 143.187.129.0/24 143.187.130.0/24 143.187.131.0/24 143.187.132.0/22 143.187.136.0/21 143.187.144.0/20 143.187.160.0/19 143.187.192.0/20 143.187.208.0/20 143.187.224.0/20 143.187.240.0/21 143.187.248.0/21 204.8.136.0/21 I have today personally made a number of diligent efforts to contact any warm body at Fujutsu who both (a) speaks English and who also (b) knows hat an ASN is so that I could discuss this matter with some appropriate network administrator, but I was thwarted at every turn by Fujutsu's bureaucracy, despite having spoken by phone to individuals who I was told could help with this sort of thing, first in San Jose, then in Sunnyvale, and finally in the Phillipines. In the event that, as the evidence suggests, some party not associated with Fujutsu is currently making use of Fujutsu's /16 and /21 blocks, one would think that -someone- at the company might be eager to take back possession of these valuable assets, but apparently no one is. Data obtained by me from bgp.he.net suggests that AS30186 is currently connectedf to the Internet only by the following other ASNs: AS19257 - SUBRIGO CORPORATION AS3491 - PCCW Global I have already attempted to make contact via email with both of these companies regarding AS30186, but am still awating any reply from either. So far it is not looking good. In the meantime, I do encourage everyone to look over the content of the pastebin report whose URL is given above, and I encourage everyone to make up his or her own mind regarding the advisability of accepting traffic at the present time from any IPv4 space routed by AS30186. Regards, rfg P.S. The domains associated with the former Ross Technology, Inc. ASN and IPv4 address blocks appear to be part of a larger pattern upon which I will elaborate further in the near future. From mark.tinka at seacom.mu Fri Nov 11 05:37:38 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:37:38 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: Message-ID: <7a0969a1-6ad9-b138-2a0f-30471e720d3b@seacom.mu> On 10/Nov/16 20:01, Josh Reynolds wrote: > Cisco is the only "real" IS-IS vendor. > > Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the > whitebox hardware or real SDN capable solutions, you're going to be on > OSPF. > We are quite happy with our Cisco-Juniper IS-IS interactions. Granted, IOS, IOS XE and IOS XR all have several IS-IS knobs that Juniper don't, but in all fairness, we aren't complaining. We have the right knobs in the right place on each vendor kit to run a successful IGP domain. Mark. From mark.tinka at seacom.mu Fri Nov 11 05:39:30 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:39:30 +0200 Subject: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <5824C927.9050103@foobar.org> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> Message-ID: <7a61d9bd-8713-6622-595e-5ca9169057cc@seacom.mu> On 10/Nov/16 21:23, Nick Hilliard wrote: > > I think people were looking for specifics about the implementation > deficits in the junos version which caused enough problems to justify > the term "not getting it"? The only IS-IS implementation we struggle with is Quagga. For that, we run OSPFv2 and OSPFv3 on Quagga and redistribute that into the IS-IS core. Use-case is Anycast (DNS, NTP, TACACS+, e.t.c.) on FreeBSD. Mark. From mark.tinka at seacom.mu Fri Nov 11 05:41:40 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:41:40 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> Message-ID: <48ac6389-eb6d-af68-e9a0-af91c2ab1dec@seacom.mu> On 10/Nov/16 21:43, Baldur Norddahl wrote: > > And at the day work I also prefer OSPFv2 simply because I do not need > more protocols in the stack. We are running a MPLS network with the > internet service in a L3VPN. IPv6 is also in the L3VPN. This means the > underlying network is pure IPv4 and totally isolated from the > internet. Why make it more complicated by introducing something that > is not IP based? I'd counter that "Why not make it less complicating by removing an easily-reachable attack vector?" Sure, you can easily protect your OSPF domain from external attack, but that's something your router CPU and/or data plane would have to deal with it had to, and we've all seen situations where filters break in certain code for various reasons. Or vendors change the way filtering works in newer code without properly notifying customers about such changes. Mark. From mark.tinka at seacom.mu Fri Nov 11 05:45:26 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:45:26 +0200 Subject: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> Message-ID: On 10/Nov/16 23:53, Charles van Niman wrote: > I don't think Nick asked for a list, just one single thing, any one > thing. To me at least, it doesn't really make sense to make the > statement you did, without pointing out what can be done to improve > the situation. I would be very interested to hear what network > requirements are not being met with Juniper's current IS-IS > implementation. To be honest, none that I can think of. Many of the feature differences are vendor-specific, particularly with how you can further optimize IS-IS to handle LSP's flooding, flushing, re-calculation, throttling, e.t.c. Bottom line, Juniper fully supports the IS-IS spec., from what we see. Mark. From mark.tinka at seacom.mu Fri Nov 11 05:46:51 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:46:51 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> Message-ID: On 11/Nov/16 00:03, Josh Reynolds wrote: > Since the last time I looked, I could not get the same feature sets running > IS-IS in a multi-vendor environment as I could running OSPF. This was my > experience at the time, based on my research and discussions with the > vendors. I'd be curious to know what features you were getting in OSPF that were unavailable in IS-IS, at the time. Mark. From mark.tinka at seacom.mu Fri Nov 11 05:50:03 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:50:03 +0200 Subject: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: <51b46196-1ebd-37c1-1bda-06a25d1553ea@seacom.mu> On 11/Nov/16 02:00, Josh Reynolds wrote: > That said, glance across the landscape as a whole of all of the routing > platforms out there. Hardware AND softwsre. Which ones support bare bones > IS-IS? Which ones have a decent subset of extensions? Are they comparable > or compatible with others? The end result is a *very mixed bag*, with far > more not supporting IS-IS at all, or only supporting the bare minimum to > even go by that name in a datasheet. I (as I suppose most) would consider full spec. support of the protocol to be a bare minimum and acceptable for production. Non-spec. extensions are nice-to-have. Spec. extensions are part of the bare minimum, and would be supported. I'm all for having no configurations on a router - that way, there are fewer avenues to cause network problems. But, we do need configurations on routers to make them work. So if I don't really the knob, it's no good having it there in the first place. Mark. From rfg at tristatelogic.com Fri Nov 11 05:50:55 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 10 Nov 2016 21:50:55 -0800 Subject: Seeking Google reverse DNS delegation contact Message-ID: <9152.1478843455@segfault.tristatelogic.com> Does anyone here happen to know who at Google I should be talking to if I want to ask a question about their reverse DNS services? I'd just like to ask someone there why anyone at Google thought that it would be a Good Idea for Google to provide reverse DNS services for the 204.8.136.0/21 IP address block, a block that appears to be chock-full to the brim of snowshoe spamming domains. http://pastebin.com/raw/VNwmgMHh http://pastebin.com/raw/Hk3SKGvp P.S. I gave up on the "evil" part some time ago. Now, I'm willing to settle for them just not being spammish. From mark.tinka at seacom.mu Fri Nov 11 05:52:43 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:52:43 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: <9f55fd4a-3dca-1aac-1a1e-7ec58c129931@seacom.mu> On 11/Nov/16 02:33, Josh Reynolds wrote: > My first post said the following: > > "Vendor support for IS-IS is quite limited - many options for OSPF." Again, the only one I know that struggles is Quagga. But I've not heard any reports from anyone running Brocade, Nokia (ALU), Huawei, e.t.c. that IS-IS doesn't work or is quite limited. I can say both Cisco and Juniper have no issues at all in this area. Arista are young in the routing space, but I am confident their implementations will be up to par soon (if they aren't already). Mark. From mark.tinka at seacom.mu Fri Nov 11 05:53:28 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:53:28 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: On 11/Nov/16 02:53, Josh Reynolds wrote: > Here's a start! > > "Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for > IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known > issues." Such as? Mark. From mark.tinka at seacom.mu Fri Nov 11 05:55:05 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:55:05 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: On 11/Nov/16 02:54, Josh Reynolds wrote: > Oops, forgot link. Cooking dinner :) > > http://www.nongnu.org/quagga/ Quagga's IS-IS implementation limitations are well-known. But I don't recall them being in your original list of vendors that had a failed IS-IS implementation (which included Juniper). Mark. From mark.tinka at seacom.mu Fri Nov 11 05:58:51 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 07:58:51 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: On 11/Nov/16 03:04, Josh Reynolds wrote: > So, we need to narrow the discussion now to only commercial solutions? Well, they are the ones we can b*tch and moan to to fix stuff because we pay them a lot of money. I b*tched and moaned to the Quagga routing team and they showed me a place where I could donate money so they can spend more time on a protocol that they don't get a lot of demand for. I can appreciate that (and I have been slacking in making that funding available to them - mea culpa; apologies Mikael and team, I'll resurrect this). Mark. From rfg at tristatelogic.com Fri Nov 11 06:05:15 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 10 Nov 2016 22:05:15 -0800 Subject: NEVERMIND! (was: Seeking Google reverse DNS delegation contact) Message-ID: <9287.1478844315@segfault.tristatelogic.com> My profuse apologies to everyone. It seems that Google is not in fact involved in any way with providing reverse DNS for the 204.8.136.0/21 IP address block. I was deceived into believing it was by some unusual trickey on the part of the spammer-controlled name servers ns1.saversagreeable.com and ns2.saversagreeable.com. You can see the clever deception toward the very end of the dig +trace listing I posted: http://pastebin.com/raw/VNwmgMHh It seems those clever rascal spammers tried to implicate Google's name servers, but it is only their's which are giving out the reverse DNS which suoorts their snowshoe spamming efforts in the 204.8.136.0/21 block. Sorry for my mistake everyone. I wasn't expecting quite this level or kind of reverse DNS delegation trickery. Regards, rfg From sthaug at nethelp.no Fri Nov 11 06:22:47 2016 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 11 Nov 2016 07:22:47 +0100 (CET) Subject: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <7a61d9bd-8713-6622-595e-5ca9169057cc@seacom.mu> References: <5824C927.9050103@foobar.org> <7a61d9bd-8713-6622-595e-5ca9169057cc@seacom.mu> Message-ID: <20161111.072247.41691305.sthaug@nethelp.no> > > I think people were looking for specifics about the implementation > > deficits in the junos version which caused enough problems to justify > > the term "not getting it"? > > The only IS-IS implementation we struggle with is Quagga. > > For that, we run OSPFv2 and OSPFv3 on Quagga and redistribute that into > the IS-IS core. > > Use-case is Anycast (DNS, NTP, TACACS+, e.t.c.) on FreeBSD. We have a similar use case, and we run BGP on Quagga. Works great. Haven't seen a need for either IS-IS or OSPF on Quagga yet. For our core IGP it's IS-IS all the way. We switched from OSPF to IS-IS more than 10 years ago, and never regretted it. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From lear at ofcourseimright.com Fri Nov 11 06:55:26 2016 From: lear at ofcourseimright.com (Eliot Lear) Date: Fri, 11 Nov 2016 07:55:26 +0100 Subject: Spitballing IoT Security In-Reply-To: <85741.1478581532@segfault.tristatelogic.com> References: <85741.1478581532@segfault.tristatelogic.com> Message-ID: <360ddb0d-59a3-f6c1-8bc7-b1dccd784160@ofcourseimright.com> This is, amongst other things, an epidemiological problem. We've known through practical experience since 1989 that worms can spread at the speed of light. And so neither an auto-update process nor BCP 38 filtering alone will stop infection. There may be ways like MUD to slow an infection, but even MUD won't be enough in circumstances when device Bob is attacking Sally on an authorized port. MUD might have prevented Bob from being infected in the first place, but not if the infection came via USB key (for instance). In some of these circumstances where it is critical, one may wish to go "up stack" with an auditing function in the form of an application-layer gateway functionality that examines the semantics of a transaction and lets the good ones through. But that in itself carries risks in several dimensions, the first of which being that the auditor is compromised, the second of which is that the auditor may misinterpret the semantics, and consequently slow the pace of deployment of new code. From an SP/Consumer perspective, I expect this case will be rare. It is worth asking what protections are necessary for a device that regulates insulin. Along these lines I've written a very DRAFTY draft called draft-lear-network-helps-01 that discusses these sorts of situations. That draft needs work and co-authors, perhaps. Eliot On 11/8/16 6:05 AM, Ronald F. Guilmette wrote: > In message <20161108035148.2904B5970CF1 at rock.dv.isc.org>, > Mark Andrews wrote: > >> * Deploying regulation in one country means that it is less likely >> to be a source of bad traffic. Manufactures are lazy. With >> sensible regulation in single country everyone else benefits as >> manufactures will use a single code base when they can. > I said that too, although not as concisely. > >> * Automated updates do reduce the numbers of vulnerable machines >> to known issues. There are risks but they are nowhere as bad as >> not doing automated updating. > I still maintain, based upon the abundant evidence, that generallized > hopes that timely and effective updates for all manner of devices will > be available throughout the practical lifetime of any such IoT thingies > is a mirage. We will just never be there, in practice. And thus, > manufacturers should be encouraged, by force of law if necessary, to > design software with a belt-and-suspenders margin of safety built in > from the first day of shipping. > > You don't send out a spacecraft, or a medical radiation machine, without > such addtional constraints built in from day one. You don't send out > such things and say "Oh, we can always send out of firmware update later > on if there is an issue." > > From a software perspective, building extra layers of constraints is not > that hard to do, and people have been doing this kind of thing already > for decades. It's called engineering. The problem isn't in anybody's > ability or inability to do safety engineering in the firmware of IoT > things. The only problem is providing the proper motivation to cause > it to happen. > > > Regards, > rfg > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: OpenPGP digital signature URL: From mark.tinka at seacom.mu Fri Nov 11 07:11:32 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 09:11:32 +0200 Subject: [SPAM] Re: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <20161111.072247.41691305.sthaug@nethelp.no> References: <5824C927.9050103@foobar.org> <7a61d9bd-8713-6622-595e-5ca9169057cc@seacom.mu> <20161111.072247.41691305.sthaug@nethelp.no> Message-ID: <0e194dfd-5b8c-c00c-965b-b4d2efa820a8@seacom.mu> On 11/Nov/16 08:22, sthaug at nethelp.no wrote: > > We have a similar use case, and we run BGP on Quagga. Works great. > Haven't seen a need for either IS-IS or OSPF on Quagga yet. Two reasons for us: * IGP metrics in the IGP will determine latency-based decisions. I know BGP can infer the IGP metric, but we are just avoiding situations where this could be non-deterministic due to other BGP-things. * BGP occurs at a much higher layer in the network stack. We run the Anycast servers in the IGP domain because that is at a much more basic layer. If BGP fails, we don't want to have problems logging into our routers because it took TACACS+ with it. There have been times when BGP has run into issues but the IGP has remained alive. Via a jump host (and OoB, of course), we were able to maintain connectivity to the network to fix it because those servers are in the IGP domain. Mark. From baldur.norddahl at gmail.com Fri Nov 11 10:07:38 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 11 Nov 2016 11:07:38 +0100 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <48ac6389-eb6d-af68-e9a0-af91c2ab1dec@seacom.mu> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <48ac6389-eb6d-af68-e9a0-af91c2ab1dec@seacom.mu> Message-ID: Den 11. nov. 2016 06.41 skrev "Mark Tinka" : > > > > On 10/Nov/16 21:43, Baldur Norddahl wrote: > >> >> And at the day work I also prefer OSPFv2 simply because I do not need more protocols in the stack. We are running a MPLS network with the internet service in a L3VPN. IPv6 is also in the L3VPN. This means the underlying network is pure IPv4 and totally isolated from the internet. Why make it more complicated by introducing something that is not IP based? > > > I'd counter that "Why not make it less complicating by removing an easily-reachable attack vector?" > > Sure, you can easily protect your OSPF domain from external attack, but that's something your router CPU and/or data plane would have to deal with it had to, and we've all seen situations where filters break in certain code for various reasons. Or vendors change the way filtering works in newer code without properly notifying customers about such changes. > > Mark. No filters. There are just no routes that will take a network packet that arrive on an interface in VRF internet and move it to an interface in VRF default without adding a MPLS header to mark the VRF. With the MPLS header the packet type is no longer IPv4 but MPLS. Therefore there is no way you from the internet or from a customer link can even attempt to inject packets that would be received by the OSPF process. Since we use 10.0.0.0/8 and our vrf internet has no such route, you would just get no route to host if you tried. Regards Baldur From mark.tinka at seacom.mu Fri Nov 11 10:20:49 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 11 Nov 2016 12:20:49 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <48ac6389-eb6d-af68-e9a0-af91c2ab1dec@seacom.mu> Message-ID: On 11/Nov/16 12:07, Baldur Norddahl wrote: > No filters. There are just no routes that will take a network packet that > arrive on an interface in VRF internet and move it to an interface in VRF > default without adding a MPLS header to mark the VRF. With the MPLS header > the packet type is no longer IPv4 but MPLS. > > Therefore there is no way you from the internet or from a customer link can > even attempt to inject packets that would be received by the OSPF process. > Since we use 10.0.0.0/8 and our vrf internet has no such route, you would > just get no route to host if you tried. Good for you. We don't run the whole "Internet in a VRF" architecture (too many moving parts), so not having our IGP being exposed to IP helps :-). Mark. From rfg at tristatelogic.com Fri Nov 11 11:49:20 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 11 Nov 2016 03:49:20 -0800 Subject: AS37135, AS6560, AS32714, AS14029 - Squatted or not? You be the judge. Message-ID: <11042.1478864960@segfault.tristatelogic.com> At least one person has now asserted to me in private email that my suggestion that AS30186 was being squatted on was in fact accurate. Thus, I now feel confident enough to provide here the rest of the story which goes along with that. In a nutshell, AS30186 and also two other ASNs, together appear to all be parts of a single large multi-ASN squat. In addition to what appears to be a squat on AS30186 (the former Ross Technology Inc. of Austin, Texas, which even Wikipedia says has been dead for lo these past 18 years) it appears to me, based on the evidence, that the exact same large scale spamming company is, at present, also usurping and squatting on two additional AFRINIC ASNs, namely AS37135 and AS6560. I provide here listings of the current forward resolutions of a sizable number of snowshoe spammer nonsense domain names (more than 1,400 in total) which are currently associated with various portion of several apparently illicitly appropriated AFRINIC /16 blocks: AS37135: http://pastebin.com/raw/PkBagrpJ AS6560 http://pastebin.com/raw/zg9W2agN The affected, and apparently long-orphaned AFRINIC IPv4 blocks involved are as follows. Note that these have each have their own AFRINIC block registration records which indicate that they belong to, among others, a chemicals & power company (155.237.0.0/16), a manufacturer of stainless steel products (160.115.0.0/16), an international mining company (163.197.0.0/16), a manufacturer of fertilizers and nitrogen compounds (163.198.0.0/16), an agricultural chemicals company (164.155.0.0/16), the Directorate of Information Services for the South African government (165.25.0.0), a Seychelles Islands ISP (168.80.16.0/15), and a South African outsourcing and business services company (196.9.0.0/16). Despite these "official" IPv4 block registrations, based on the evidence as shown in the above Pastebin reports, I am forced to conclude that somehow, magically, all of these long-dormant African entities recently began hosting parts of a large scale snowshoe spamming operation, including even the Directorate of Information Services for the South African government, as well as the South African Post Office (196.10.0.0./16), both of which appear to be kindly lending a hand to these spammers also. Here is the list of affected AFRINIC-allocatded IPv4 blocks: 152.108.0.0/16 155.159.0.0/16 155.235.0.0/16 155.237.0.0/16 160.115.0.0/16 160.116.0.0/16 160.122.0.0/16 163.197.0.0/16 163.198.0.0/16 164.155.0.0/16 165.25.0.0/16 168.76.0.0/16 168.80.16.0/15 196.9.0.0/16 196.10.0.0./16 196.16.0.0/14 196.15.64.0/18 Note that AS37135 and AS6560, which I contend are themselves being squatted on, are currently announcing numerous discrete and discreet /20, /21, and /19 blocks out of the above large blocks, perhaps with a view to the future and to switching their announcements to other and different sub-blocks within these same containing blocks, e.g. when they have so throughly sullied the reputations of the blocks they are currently using so as to have caused those blocks to be universally blacklisted everywhere. In any case, here are the current announcements being made by AS37135 and AS6560, respectively. Note that the set of announcements from these ASNs has changed, and significantly, even just within the past 24 hours. What you are seeing here is just the routes being announced by these two suspicious ASNs as I write this. AS37135: 152.108.0.0/19 155.235.80.0/20 155.235.128.0/19 155.235.224.0/19 155.237.128.0/21 155.237.128.0/19 160.115.32.0/20 160.115.48.0/20 160.115.64.0/20 160.115.80.0/20 160.115.96.0/20 160.115.112.0/20 160.116.112.0/20 160.116.160.0/20 160.116.192.0/20 160.122.0.0/19 160.122.128.0/21 160.122.240.0/21 163.198.0.0/20 163.198.64.0/20 168.76.128.0/20 -- Free State Education Department (not routed earlier today) 196.9.32.0/20 196.9.128.0/20 AS6560: 155.159.128.0/20 155.237.64.0/20 155.237.208.0/20 155.237.224.0/20 155.237.240.0/20 163.197.112.0/20 163.197.144.0/20 163.197.176.0/20 163.197.208.0/20 163.197.240.0/20 163.198.16.0/20 163.198.80.0/20 163.198.96.0/20 163.198.144.0/20 163.198.192.0/20 163.198.224.0/20 164.155.0.0/20 164.155.64.0/20 164.155.128.0/20 164.155.192.0/20 165.25.0.0/20 165.25.32.0/20 165.25.64.0/20 165.25.96.0/20 165.25.128.0/20 165.25.160.0/20 165.25.192.0/20 165.25.224.0/20 168.80.16.0/20 168.80.48.0/20 168.80.80.0/20 168.81.16.0/20 168.81.64.0/20 168.81.176.0/20 168.81.224.0/20 196.9.0.0/20 196.9.16.0/20 196.15.64.0/20 196.15.96.0/20 As I was preparing this post, two furter and additional dodgy looking ASNs also came to my attention, and preliminary analysis suggests that these two additional AFRINIC ASNs, AS32714, and AS14029, together with all of the IP space they are announcing, may perhaps also be squatted on at the present time. Given below are the current announcements from these two additional ASNs. Note that AS32714 is currently announcing routes to some South African IP address blocks, as well as to certain German blocks registered to Daimler AG, and also a number of Chinese /18 blocks registered to the Chinese retailing giant Alibaba, Inc... two companies which I suspect do not really require outside help from South Africa in order to obtain routing to their own IP blocks. Interestingly also, the former Zimbabwean ASN AS14029 does not appear to be actually registered to anyone at all at the present time. This minor annoyance does not, apparently prevent it from announcing a number of rather entirely dubious routes via its lone BGP peer AS260. AS32714: 47.93.0.0/18 47.93.64.0/18 47.93.128.0/18 47.93.192.0/18 53.122.1.0/24 53.122.2.0/24 165.10.0.0/16 196.10.64.0/19 AS14029: 41.77.240.0/22 155.159.254.0/24 155.159.255.0/24 160.122.70.0/24 160.122.71.0/24 168.81.254.0/24 168.81.255.0/24 196.10.61.0/24 196.10.62.0/24 196.10.63.0/24 203.212.160.0/20 I will be looking in more depth into AS32714 and AS14029 shortly, but for now I just wanted to make people aware of these additional two rather curious ASNs and the routes they are currently announcing. On a final note, it has not escaped my notice that all three of the ASNs AS37135, AS6560, and AS14029 appear to have only a single common BGP peer, that being AS260, Xconnect24 Inc. I suspect that this is not entirely a matter of coincidence. I have attempted to make contact via email with Xconnect24, but they have not replied to my polite inquiry. For its part, AS32714 also has but a single BGP peer, that being AS6939, Hurricane Electric, Inc. Regards, rfg From draganj84 at gmail.com Thu Nov 10 15:21:16 2016 From: draganj84 at gmail.com (Dragan Jovicic) Date: Thu, 10 Nov 2016 16:21:16 +0100 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <1abf0216-67fa-c56b-4756-b4003b2946b0@Opus1.com> Message-ID: In my experience/personal opinion, compared to OSPF2/3, in a large ISP, ISIS: - has simpler and better, less bloated code. Think ISIS on Juniper. Think FreeBSD vs Linux. - is more modular to introduce new features. - has certain knobs which makes it a bit more useful for ISP (LSP lifetime/Max number of LSP fragments, etc). This is for a large single L1/L2/backbone area. There are at least 2 design options I would consider before switching to multi-area ISP design. With that said I know of at least two of the largest ISPs tat use OSPF and many use that favor ISIS so it really comes down to ISP's preference and NOC willingness to learn new unfamiliar protocol. BR On Thu, Nov 10, 2016 at 3:35 PM, Mark Tinka wrote: > > > On 10/Nov/16 14:30, Joel M Snyder wrote: > > > > > > > In a world where you are doing well-controlled Cisco/Juniper/etc > > networks with fairly homogeneous code bases, the engineers get to have > > this discussion. When you have to link in devices for which routing > > is not their primary reason to exist, your options narrow very > > quickly. It's not ideal; that's just the way it is. > > Quagga's IS-IS implementation is a great example. > > Mark. > From grandcanuck at gmail.com Thu Nov 10 22:20:04 2016 From: grandcanuck at gmail.com (Charles Gagnon) Date: Thu, 10 Nov 2016 17:20:04 -0500 Subject: USDA IT Contacts? Message-ID: Would anyone have information about IT contacts within the US Government? Some of our IP ranges seem to be blocked from access to some government web servers (discovered on http://www.usda.gov - we get a odd "access denied" page there - traces point to the same IP at akamaitechnologies.com). I have NO idea who to discuss this with. I could not even find a "Contact Us" to use on their website. Regards, -- Charles Gagnon http://unixrealm.com From josh at kyneticwifi.com Fri Nov 11 00:31:47 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 10 Nov 2016 18:31:47 -0600 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> <582503D3.40808@foobar.org> Message-ID: My first post: On Nov 10, 2016 6:24 PM, "Charles van Niman" wrote: > Your original point was that a list of vendors "didn't get IS-IS" but > provided no details about what you are talking about. As far as all > the documentation I have read, and some of the documentation you > linked to, it works just fine on quite a few vendors, and a few people > on this list. Your original point mentions nothing about wider OSPF > adoption, which you seem to have shifted to to deflect having to > provide any actual details. > > Are we to assume that your original point was incorrect? As far as the > landscape as a whole, I have seen quite a few networks that get by > with either protocol just fine, the use-case for a given network is > not such a broad landscape, so I think "use the right tool for the > job" seems very apt, and that you can't just say that only two > protocols are suitable for all jobs. > > /Charles > > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds > wrote: > > As cute as your impotent white knighting of one vendor is (I very much > like > > Juniper BTW), you're absolutely ignoring my original premise and point > > because you got your panties in a wad over a potential triviality of an > > internet comment - where documentation exists, should one take the time > to > > go through it, to find discrepancies between them. > > > > So, if you'd like to prove your point and earn brownie points with > $vendor, > > on a feature by feature basis please take the time to consult > documentation > > of two vendors products (you can even pick the platform and subversion > > release!) to refute my claim. This has nothing at all to do with the > point > > of my statement mind you, it's simply a sidetrack that has wasted enough > > time already. > > > > That said, glance across the landscape as a whole of all of the routing > > platforms out there. Hardware AND softwsre. Which ones support bare bones > > IS-IS? Which ones have a decent subset of extensions? Are they comparable > > or compatible with others? The end result is a *very mixed bag*, with far > > more not supporting IS-IS at all, or only supporting the bare minimum to > > even go by that name in a datasheet. > > > > Thus, my point stands. If you want as much flexibility in your > environment > > as you can have, you want OSPF or BGP as your IGP. > > > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" wrote: > > > >> Josh Reynolds wrote: > >> > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand > >> > line hate fueled rant with examples and enough colorful language to > make > >> > submarine crews blush. > >> > >> I have no doubt it would be the best rant. It would be a beautiful > rant. > >> > >> Entertaining and all as hand-waving may be, please let us know if you > >> manage to unearth any actual facts to support the claims that you made > >> about junos's alleged feature deficits. > >> > >> Nick > >> > >> > From mh at xalto.net Thu Nov 10 22:49:47 2016 From: mh at xalto.net (Michael Hallgren) Date: Thu, 10 Nov 2016 23:49:47 +0100 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <5824D82D.9090607@foobar.org> <5824DCEA.8030900@foobar.org> <5824EB7A.2060602@foobar.org> Message-ID: Hi, What IGP features do you need, and for what reason? Cheers, mh??Le 10 nov. 2016, ? 23:04, Josh Reynolds a ?crit: I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush. Cisco has been pushing EIGRP and IS-IS as part of their "showing" for decades. During that same time frame, the majority of the other vendors and the open source daemons have been using OSPF as their IGP offering. In the mean time, Cisco found a need to introduce more and more vendor specific features into their IS-IS offering - no different than any other vendor would do in their situation to promote the business case (better scaling, vendor lock-in, other bits). If you go looking for cross vendor compatibility with as many devices (routers, switches, servers, etc) as possible, you're going to end up with OSPF [or BGP, for the data center types that run it to edge nodes]. You will find a handful, as some have mentioned, of vendors that have adopted the open version of the protocol and have tried to add comparable/compatible features to close the gap. Since the last time I looked, I could not get the same feature sets running IS-IS in a multi-vendor environment as I could running OSPF. This was my experience at the time, based on my research and discussions with the vendors. On Nov 10, 2016 3:49 PM, "Nick Hilliard" wrote: Josh Reynolds wrote: I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS support, which was the last time *I* looked. No, I do not have a list sitting ready, that catalogs in details between product lines and specific firmware versions and subversions between multiple vendors what one supports and what one does not as of Nov 11, 2016. What I can do is point you at the vendor list where you can make a comparison of that vendor to others, for the features that you need in your environment - as I'm not getting paid to maintain such lists, and they are. So what you're saying is that you can't even provide a single missing feature to justify trash-talking a vendor the way you did? Not even one?? Nick Le 10 nov. 2016 23:04, ? 23:04, Josh Reynolds a ?crit: >I didn't "trash talk" a vendor. If I did, it would be a multi-thousand >line >hate fueled rant with examples and enough colorful language to make >submarine crews blush. > >Cisco has been pushing EIGRP and IS-IS as part of their "showing" for >decades. During that same time frame, the majority of the other vendors >and >the open source daemons have been using OSPF as their IGP offering. In >the >mean time, Cisco found a need to introduce more and more vendor >specific >features into their IS-IS offering - no different than any other vendor >would do in their situation to promote the business case (better >scaling, >vendor lock-in, other bits). > >If you go looking for cross vendor compatibility with as many devices >(routers, switches, servers, etc) as possible, you're going to end up >with >OSPF [or BGP, for the data center types that run it to edge nodes]. You >will find a handful, as some have mentioned, of vendors that have >adopted >the open version of the protocol and have tried to add >comparable/compatible features to close the gap. > >Since the last time I looked, I could not get the same feature sets >running >IS-IS in a multi-vendor environment as I could running OSPF. This was >my >experience at the time, based on my research and discussions with the >vendors. > >On Nov 10, 2016 3:49 PM, "Nick Hilliard" wrote: > >> Josh Reynolds wrote: >> > I'm sure a lot has changed with Juniper as of 2011 in regard to >IS-IS >> > support, which was the last time *I* looked. >> > >> > No, I do not have a list sitting ready, that catalogs in details >> > between product lines and specific firmware versions and >subversions >> > between multiple vendors what one supports and what one does not as >of >> > Nov 11, 2016. >> > >> > What I can do is point you at the vendor list where you can make a >> > comparison of that vendor to others, for the features that you need >in >> > your environment - as I'm not getting paid to maintain such lists, >and >> > they are. >> >> So what you're saying is that you can't even provide a single missing >> feature to justify trash-talking a vendor the way you did? Not even >one?? >> >> Nick >> >> From josh at kyneticwifi.com Fri Nov 11 14:23:04 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 11 Nov 2016 08:23:04 -0600 Subject: USDA IT Contacts? In-Reply-To: References: Message-ID: *Cough* I might know some people. Standby. On Nov 11, 2016 8:17 AM, "Charles Gagnon" wrote: > Would anyone have information about IT contacts within the US Government? > Some of our IP ranges seem to be blocked from access to some government web > servers (discovered on http://www.usda.gov - we get a odd "access denied" > page there - traces point to the same IP at akamaitechnologies.com). > > I have NO idea who to discuss this with. I could not even find a "Contact > Us" to use on their website. > > Regards, > > -- > Charles Gagnon > http://unixrealm.com > From josh at kyneticwifi.com Fri Nov 11 14:25:08 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 11 Nov 2016 08:25:08 -0600 Subject: USDA IT Contacts? In-Reply-To: References: Message-ID: Just a head's up, resolution may not happen today - it's veteran's day, which of course is a federal holiday. On Nov 11, 2016 8:17 AM, "Charles Gagnon" wrote: > Would anyone have information about IT contacts within the US Government? > Some of our IP ranges seem to be blocked from access to some government web > servers (discovered on http://www.usda.gov - we get a odd "access denied" > page there - traces point to the same IP at akamaitechnologies.com). > > I have NO idea who to discuss this with. I could not even find a "Contact > Us" to use on their website. > > Regards, > > -- > Charles Gagnon > http://unixrealm.com > From jherr3 at lsuhsc.edu Fri Nov 11 14:23:03 2016 From: jherr3 at lsuhsc.edu (Herriage, James L.) Date: Fri, 11 Nov 2016 14:23:03 +0000 Subject: USDA IT Contacts? In-Reply-To: References: Message-ID: <2E0B1AECC3CD024381D9AA8704C9448A811C9EAC@SH-ExchMB2.master.lsuhsc.edu> POCs here: uda.gov = 162.79.29.12 https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12 Thanks, Lee -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Charles Gagnon Sent: Thursday, November 10, 2016 4:20 PM To: nanog at nanog.org Subject: USDA IT Contacts? *EXTERNAL EMAIL: EVALUATE* Would anyone have information about IT contacts within the US Government? Some of our IP ranges seem to be blocked from access to some government web servers (discovered on http://www.usda.gov - we get a odd "access denied" page there - traces point to the same IP at akamaitechnologies.com). I have NO idea who to discuss this with. I could not even find a "Contact Us" to use on their website. Regards, -- Charles Gagnon http://unixrealm.com From marcelplug at gmail.com Fri Nov 11 15:42:33 2016 From: marcelplug at gmail.com (Marcel Plug) Date: Fri, 11 Nov 2016 10:42:33 -0500 Subject: Spitballing IoT Security In-Reply-To: <360ddb0d-59a3-f6c1-8bc7-b1dccd784160@ofcourseimright.com> References: <85741.1478581532@segfault.tristatelogic.com> <360ddb0d-59a3-f6c1-8bc7-b1dccd784160@ofcourseimright.com> Message-ID: On Fri, Nov 11, 2016 at 1:55 AM, Eliot Lear wrote: > It is worth asking what protections are necessary for a device that > regulates insulin. Insulin pumps are an example of devices that have been over-regulated to the point where any and all innovation has been stifled. There have been hardly any changes in the last 10+ years, during a time when all other technology has advanced quite a bit. Its off-topic for Nanog, but i promise you this is very frustrating and annoying topic that hits me close to home. There has to be a middle ground. I guarantee we do not want home firewalls, and all the IoT devices to be regulated like insulin pumps and other medical devices. I think I'm starting to agree with those that want to keep government regulation out of this arena... Marcel > Eliot > > > On 11/8/16 6:05 AM, Ronald F. Guilmette wrote: > > In message <20161108035148.2904B5970CF1 at rock.dv.isc.org>, > > Mark Andrews wrote: > > > >> * Deploying regulation in one country means that it is less likely > >> to be a source of bad traffic. Manufactures are lazy. With > >> sensible regulation in single country everyone else benefits as > >> manufactures will use a single code base when they can. > > I said that too, although not as concisely. > > > >> * Automated updates do reduce the numbers of vulnerable machines > >> to known issues. There are risks but they are nowhere as bad as > >> not doing automated updating. > > I still maintain, based upon the abundant evidence, that generallized > > hopes that timely and effective updates for all manner of devices will > > be available throughout the practical lifetime of any such IoT thingies > > is a mirage. We will just never be there, in practice. And thus, > > manufacturers should be encouraged, by force of law if necessary, to > > design software with a belt-and-suspenders margin of safety built in > > from the first day of shipping. > > > > You don't send out a spacecraft, or a medical radiation machine, without > > such addtional constraints built in from day one. You don't send out > > such things and say "Oh, we can always send out of firmware update later > > on if there is an issue." > > > > From a software perspective, building extra layers of constraints is not > > that hard to do, and people have been doing this kind of thing already > > for decades. It's called engineering. The problem isn't in anybody's > > ability or inability to do safety engineering in the firmware of IoT > > things. The only problem is providing the proper motivation to cause > > it to happen. > > > > > > Regards, > > rfg > > > > > From lear at ofcourseimright.com Fri Nov 11 17:55:32 2016 From: lear at ofcourseimright.com (Eliot Lear) Date: Fri, 11 Nov 2016 18:55:32 +0100 Subject: Spitballing IoT Security In-Reply-To: References: <85741.1478581532@segfault.tristatelogic.com> <360ddb0d-59a3-f6c1-8bc7-b1dccd784160@ofcourseimright.com> Message-ID: <293b4596-6869-c6a4-709b-b68e4bd8cde9@ofcourseimright.com> Moving offlist on this. For those who are interested, send ping. On 11/11/16 4:42 PM, Marcel Plug wrote: > On Fri, Nov 11, 2016 at 1:55 AM, Eliot Lear > wrote: > > It is worth asking what protections are necessary for a device that > regulates insulin. > > > Insulin pumps are an example of devices that have been over-regulated > to the point where any and all innovation has been stifled. There > have been hardly any changes in the last 10+ years, during a time when > all other technology has advanced quite a bit. Its off-topic for > Nanog, but i promise you this is very frustrating and annoying topic > that hits me close to home. > > There has to be a middle ground. I guarantee we do not want home > firewalls, and all the IoT devices to be regulated like insulin pumps > and other medical devices. I think I'm starting to agree with those > that want to keep government regulation out of this arena... > > Marcel > > > Eliot > > > On 11/8/16 6:05 AM, Ronald F. Guilmette wrote: > > In message <20161108035148.2904B5970CF1 at rock.dv.isc.org > >, > > Mark Andrews > wrote: > > > >> * Deploying regulation in one country means that it is less likely > >> to be a source of bad traffic. Manufactures are lazy. With > >> sensible regulation in single country everyone else benefits as > >> manufactures will use a single code base when they can. > > I said that too, although not as concisely. > > > >> * Automated updates do reduce the numbers of vulnerable machines > >> to known issues. There are risks but they are nowhere as bad as > >> not doing automated updating. > > I still maintain, based upon the abundant evidence, that > generallized > > hopes that timely and effective updates for all manner of > devices will > > be available throughout the practical lifetime of any such IoT > thingies > > is a mirage. We will just never be there, in practice. And thus, > > manufacturers should be encouraged, by force of law if necessary, to > > design software with a belt-and-suspenders margin of safety built in > > from the first day of shipping. > > > > You don't send out a spacecraft, or a medical radiation machine, > without > > such addtional constraints built in from day one. You don't > send out > > such things and say "Oh, we can always send out of firmware > update later > > on if there is an issue." > > > > From a software perspective, building extra layers of > constraints is not > > that hard to do, and people have been doing this kind of thing > already > > for decades. It's called engineering. The problem isn't in > anybody's > > ability or inability to do safety engineering in the firmware of IoT > > things. The only problem is providing the proper motivation to > cause > > it to happen. > > > > > > Regards, > > rfg > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: OpenPGP digital signature URL: From cscora at apnic.net Fri Nov 11 18:01:45 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Nov 2016 04:01:45 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161111180145.727B0C55A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 12 Nov, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 621131 Prefixes after maximum aggregation (per Origin AS): 220098 Deaggregation factor: 2.82 Unique aggregates announced (without unneeded subnets): 300375 Total ASes present in the Internet Routing Table: 55165 Prefixes per ASN: 11.26 Origin-only ASes present in the Internet Routing Table: 36323 Origin ASes announcing only one prefix: 15347 Transit ASes present in the Internet Routing Table: 6538 Transit-only ASes present in the Internet Routing Table: 166 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 64 Unregistered ASNs in the Routing Table: 19 Number of 32-bit ASNs allocated by the RIRs: 16110 Number of 32-bit ASNs visible in the Routing Table: 12304 Prefixes from 32-bit ASNs in the Routing Table: 49851 Number of bogon 32-bit ASNs visible in the Routing Table: 343 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 430 Number of addresses announced to Internet: 2831675172 Equivalent to 168 /8s, 199 /16s and 239 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.3 Total number of prefixes smaller than registry allocations: 204046 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 157302 Total APNIC prefixes after maximum aggregation: 42681 APNIC Deaggregation factor: 3.69 Prefixes being announced from the APNIC address blocks: 171205 Unique aggregates announced from the APNIC address blocks: 70250 APNIC Region origin ASes present in the Internet Routing Table: 5174 APNIC Prefixes per ASN: 33.09 APNIC Region origin ASes announcing only one prefix: 1146 APNIC Region transit ASes present in the Internet Routing Table: 947 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 35 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2463 Number of APNIC addresses announced to Internet: 759799108 Equivalent to 45 /8s, 73 /16s and 157 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 187791 Total ARIN prefixes after maximum aggregation: 88833 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 194070 Unique aggregates announced from the ARIN address blocks: 87887 ARIN Region origin ASes present in the Internet Routing Table: 16152 ARIN Prefixes per ASN: 12.02 ARIN Region origin ASes announcing only one prefix: 5666 ARIN Region transit ASes present in the Internet Routing Table: 1708 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1572 Number of ARIN addresses announced to Internet: 1105788576 Equivalent to 65 /8s, 232 /16s and 254 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 147975 Total RIPE prefixes after maximum aggregation: 72517 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 158852 Unique aggregates announced from the RIPE address blocks: 97640 RIPE Region origin ASes present in the Internet Routing Table: 18146 RIPE Prefixes per ASN: 8.75 RIPE Region origin ASes announcing only one prefix: 7810 RIPE Region transit ASes present in the Internet Routing Table: 3036 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 27 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5087 Number of RIPE addresses announced to Internet: 708991744 Equivalent to 42 /8s, 66 /16s and 91 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 62929 Total LACNIC prefixes after maximum aggregation: 12695 LACNIC Deaggregation factor: 4.96 Prefixes being announced from the LACNIC address blocks: 79161 Unique aggregates announced from the LACNIC address blocks: 37605 LACNIC Region origin ASes present in the Internet Routing Table: 2482 LACNIC Prefixes per ASN: 31.89 LACNIC Region origin ASes announcing only one prefix: 557 LACNIC Region transit ASes present in the Internet Routing Table: 596 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2909 Number of LACNIC addresses announced to Internet: 170859328 Equivalent to 10 /8s, 47 /16s and 27 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15218 Total AfriNIC prefixes after maximum aggregation: 3364 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 17413 Unique aggregates announced from the AfriNIC address blocks: 6602 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 23.69 AfriNIC Region origin ASes announcing only one prefix: 168 AfriNIC Region transit ASes present in the Internet Routing Table: 181 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 273 Number of AfriNIC addresses announced to Internet: 85819392 Equivalent to 5 /8s, 29 /16s and 128 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3599 382 245 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2962 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2708 1500 539 BSNL-NIB National Internet Backbone, IN 4766 2701 11132 741 KIXS-AS-KR Korea Telecom, KR 9808 2225 8698 32 CMNET-GD Guangdong Mobile Communication 4755 2047 428 215 TATACOMM-AS TATA Communications formerl 4808 1750 2290 513 CHINA169-BJ China Unicom Beijing Provin 45899 1634 1240 96 VNPT-AS-VN VNPT Corp, VN 24560 1564 542 229 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3554 2967 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3145 1333 82 SHAW - Shaw Communications Inc., CA 18566 2197 405 110 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1948 2003 406 CHARTER-NET-HKY-NC - Charter Communicat 30036 1789 340 323 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1730 5067 653 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1678 848 227 ITCDELTA - Earthlink, Inc., US 701 1605 10642 663 UUNET - MCI Communications Services, In 7018 1484 20476 1050 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3330 170 16 ALJAWWALSTC-AS , SA 20940 2922 1103 2073 AKAMAI-ASN1 , US 34984 1986 326 371 TELLCOM-AS , TR 13188 1626 99 58 TRIOLAN , UA 12479 1367 1033 54 UNI2-AS , ES 8551 1201 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 6849 1142 355 21 UKRTELNET , UA 8402 1140 544 15 CORBINA-AS OJSC "Vimpelcom", RU 9198 1090 352 25 KAZTELECOM-AS , KZ 12389 952 1134 424 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3529 544 167 Telmex Colombia S.A., CO 8151 2287 3367 554 Uninet S.A. de C.V., MX 7303 1527 963 245 Telecom Argentina S.A., AR 6503 1485 437 54 Axtel, S.A.B. de C.V., MX 11830 1353 368 66 Instituto Costarricense de Electricidad 6147 1288 377 27 Telefonica del Peru S.A.A., PE 7738 1024 1882 41 Telemar Norte Leste S.A., BR 28573 1013 2264 169 CLARO S.A., BR 3816 987 474 192 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 907 126 77 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1190 402 50 LINKdotNET-AS, EG 36903 682 343 139 MT-MPLS, MA 37611 676 67 6 Afrihost, ZA 36992 567 1373 25 ETISALAT-MISR, EG 8452 494 1472 15 TE-AS TE-AS, EG 24835 418 658 16 RAYA-AS, EG 37492 396 288 72 ORANGE-TN, TN 29571 364 37 12 CITelecom-AS, CI 15399 308 35 6 WANANCHI-KE, KE 36974 275 140 11 AFNET-AS, CI Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3599 382 245 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3554 2967 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3529 544 167 Telmex Colombia S.A., CO 39891 3330 170 16 ALJAWWALSTC-AS , SA 6327 3145 1333 82 SHAW - Shaw Communications Inc., CA 17974 2962 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2922 1103 2073 AKAMAI-ASN1 , US 9829 2708 1500 539 BSNL-NIB National Internet Backbone, IN 4766 2701 11132 741 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3554 3402 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3529 3362 Telmex Colombia S.A., CO 7545 3599 3354 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3330 3314 ALJAWWALSTC-AS , SA 6327 3145 3063 SHAW - Shaw Communications Inc., CA 17974 2962 2891 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2225 2193 CMNET-GD Guangdong Mobile Communication 9829 2708 2169 BSNL-NIB National Internet Backbone, IN 18566 2197 2087 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 2056 BELLSOUTH-NET-BLK - BellSouth.net Inc., Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 64855 PRIVATE 41.220.200.0/21 36945 mcelISP, MZ 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 27.110.192.0/22 45664 UNKNOWN 27.110.196.0/22 45664 UNKNOWN 27.110.200.0/22 45664 UNKNOWN 27.110.204.0/22 45664 UNKNOWN 27.110.224.0/22 45664 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:102 /12:274 /13:522 /14:1050 /15:1789 /16:13153 /17:7864 /18:13076 /19:25497 /20:38454 /21:40665 /22:72015 /23:60478 /24:344876 /25:457 /26:357 /27:299 /28:59 /29:34 /30:12 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 2942 3145 SHAW - Shaw Communications Inc., CA 39891 2896 3330 ALJAWWALSTC-AS , SA 22773 2765 3554 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2089 2197 MEGAPATH5-US - MegaPath Corporation, US 30036 1603 1789 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1443 3529 Telmex Colombia S.A., CO 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1364 1626 TRIOLAN , UA 6983 1324 1678 ITCDELTA - Earthlink, Inc., US 34984 1275 1986 TELLCOM-AS , TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1552 2:817 4:23 5:2238 6:32 8:999 12:1803 13:53 14:1754 15:46 16:2 17:102 18:126 20:48 23:1918 24:1819 27:2356 31:1792 32:83 33:4 35:3 36:349 37:2414 38:1310 39:39 40:102 41:2937 42:451 43:1891 44:47 45:2251 46:2551 47:104 49:1175 50:938 51:15 52:563 53:2 54:350 55:6 56:4 57:40 58:1591 59:997 60:378 61:1840 62:1464 63:1928 64:4585 65:2176 66:4340 67:2258 68:1142 69:3288 70:1288 71:562 72:2064 74:2589 75:405 76:414 77:1436 78:1326 79:914 80:1322 81:1391 82:980 83:712 84:867 85:1584 86:481 87:1124 88:566 89:2040 90:196 91:6124 92:957 93:2370 94:2411 95:2554 96:575 97:344 98:943 99:91 100:147 101:1180 103:12771 104:2582 105:147 106:465 107:1434 108:786 109:2485 110:1278 111:1606 112:1135 113:1150 114:1102 115:1694 116:1682 117:1562 118:2096 119:1574 120:952 121:1088 122:2282 123:2041 124:1587 125:1839 128:690 129:470 130:417 131:1362 132:619 133:175 134:510 135:202 136:394 137:389 138:1796 139:439 140:623 141:462 142:692 143:913 144:711 145:170 146:952 147:665 148:1382 149:554 150:665 151:906 152:684 153:306 154:687 155:943 156:537 157:555 158:434 159:1314 160:562 161:711 162:2426 163:544 164:777 165:1128 166:351 167:1197 168:2342 169:674 170:2276 171:257 172:814 173:1827 174:769 175:710 176:1727 177:4096 178:2378 179:1164 180:2160 181:1896 182:2107 183:1018 184:840 185:7948 186:3177 187:2160 188:2260 189:1798 190:7904 191:1300 192:9129 193:5748 194:4530 195:3850 196:1841 197:1249 198:5619 199:5826 200:7130 201:3720 202:10126 203:9834 204:4503 205:2748 206:3017 207:3114 208:3976 209:3875 210:3895 211:2048 212:2744 213:2422 214:840 215:67 216:5742 217:1982 218:813 219:597 220:1651 221:876 222:712 223:1345 End of report From josh at kyneticwifi.com Fri Nov 11 18:59:16 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 11 Nov 2016 12:59:16 -0600 Subject: USDA IT Contacts? In-Reply-To: <2E0B1AECC3CD024381D9AA8704C9448A811C9EAC@SH-ExchMB2.master.lsuhsc.edu> References: <2E0B1AECC3CD024381D9AA8704C9448A811C9EAC@SH-ExchMB2.master.lsuhsc.edu> Message-ID: Just looking at that info... hasn't been updated since 2005 and is listed as being at Ft Collins. Sooooo I'll be complaining to some people on Monday :) On Fri, Nov 11, 2016 at 8:23 AM, Herriage, James L. wrote: > POCs here: > uda.gov = 162.79.29.12 > https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12 > > > Thanks, > Lee > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Charles Gagnon > Sent: Thursday, November 10, 2016 4:20 PM > To: nanog at nanog.org > Subject: USDA IT Contacts? > > *EXTERNAL EMAIL: EVALUATE* > > Would anyone have information about IT contacts within the US Government? > Some of our IP ranges seem to be blocked from access to some government web servers (discovered on http://www.usda.gov - we get a odd "access denied" > page there - traces point to the same IP at akamaitechnologies.com). > > I have NO idea who to discuss this with. I could not even find a "Contact Us" to use on their website. > > Regards, > > -- > Charles Gagnon > http://unixrealm.com From rwebb at ropeguru.com Fri Nov 11 19:27:12 2016 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Fri, 11 Nov 2016 14:27:12 -0500 Subject: USDA IT Contacts? In-Reply-To: References: <2E0B1AECC3CD024381D9AA8704C9448A811C9EAC@SH-ExchMB2.master.lsuhsc.edu> Message-ID: The very last POC was updated in 2015, but also out of Fort Collins. On Fri, 11 Nov 2016 12:59:16 -0600 Josh Reynolds wrote: > Just looking at that info... hasn't been updated since 2005 and is > listed as being at Ft Collins. > > Sooooo I'll be complaining to some people on Monday :) > > On Fri, Nov 11, 2016 at 8:23 AM, Herriage, James L. wrote: >> POCs here: >> uda.gov = 162.79.29.12 >> https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12 >> >> >> Thanks, >> Lee >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Charles Gagnon >> Sent: Thursday, November 10, 2016 4:20 PM >> To: nanog at nanog.org >> Subject: USDA IT Contacts? >> >> *EXTERNAL EMAIL: EVALUATE* >> >> Would anyone have information about IT contacts within the US Government? >> Some of our IP ranges seem to be blocked from access to some government web servers (discovered on http://www.usda.gov - we get a odd "access denied" >> page there - traces point to the same IP at akamaitechnologies.com). >> >> I have NO idea who to discuss this with. I could not even find a "Contact Us" to use on their website. >> >> Regards, >> >> -- >> Charles Gagnon >> http://unixrealm.com From fw at deneb.enyo.de Fri Nov 11 19:34:46 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 11 Nov 2016 20:34:46 +0100 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> (Mark Tinka's message of "Thu, 10 Nov 2016 07:59:12 +0200") References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> Message-ID: <87bmxl4xpl.fsf@mid.deneb.enyo.de> * Mark Tinka: > I've given a talk about this a couple of times since 2008. But our > reasons are to choosing IS-IS are: Has the name been a problem for you? Asking vendors about support must be a bit awkward these days. From owen at delong.com Fri Nov 11 19:54:11 2016 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Nov 2016 11:54:11 -0800 Subject: USDA IT Contacts? In-Reply-To: References: <2E0B1AECC3CD024381D9AA8704C9448A811C9EAC@SH-ExchMB2.master.lsuhsc.edu> Message-ID: <5FB58A3F-754B-4A46-8AEE-9701BADCE1BA@delong.com> USDA has a LOT of their IT in Ft. Collins, so that?s not irrational. Owen > On Nov 11, 2016, at 11:27 , rwebb at ropeguru.com wrote: > > The very last POC was updated in 2015, but also out of Fort Collins. > > On Fri, 11 Nov 2016 12:59:16 -0600 > Josh Reynolds wrote: >> Just looking at that info... hasn't been updated since 2005 and is >> listed as being at Ft Collins. >> >> Sooooo I'll be complaining to some people on Monday :) >> >> On Fri, Nov 11, 2016 at 8:23 AM, Herriage, James L. wrote: >>> POCs here: >>> uda.gov = 162.79.29.12 >>> https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12 >>> >>> >>> Thanks, >>> Lee >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Charles Gagnon >>> Sent: Thursday, November 10, 2016 4:20 PM >>> To: nanog at nanog.org >>> Subject: USDA IT Contacts? >>> >>> *EXTERNAL EMAIL: EVALUATE* >>> >>> Would anyone have information about IT contacts within the US Government? >>> Some of our IP ranges seem to be blocked from access to some government web servers (discovered on http://www.usda.gov - we get a odd "access denied" >>> page there - traces point to the same IP at akamaitechnologies.com). >>> >>> I have NO idea who to discuss this with. I could not even find a "Contact Us" to use on their website. >>> >>> Regards, >>> >>> -- >>> Charles Gagnon >>> http://unixrealm.com From josh at kyneticwifi.com Fri Nov 11 19:56:07 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 11 Nov 2016 13:56:07 -0600 Subject: USDA IT Contacts? In-Reply-To: <5FB58A3F-754B-4A46-8AEE-9701BADCE1BA@delong.com> References: <2E0B1AECC3CD024381D9AA8704C9448A811C9EAC@SH-ExchMB2.master.lsuhsc.edu> <5FB58A3F-754B-4A46-8AEE-9701BADCE1BA@delong.com> Message-ID: They have a lot more at N.I.T.C. though. https://www.ocio.usda.gov/about-ocio/data-center-operations-dco On Fri, Nov 11, 2016 at 1:54 PM, Owen DeLong wrote: > USDA has a LOT of their IT in Ft. Collins, so that?s not irrational. > > Owen > >> On Nov 11, 2016, at 11:27 , rwebb at ropeguru.com wrote: >> >> The very last POC was updated in 2015, but also out of Fort Collins. >> >> On Fri, 11 Nov 2016 12:59:16 -0600 >> Josh Reynolds wrote: >>> Just looking at that info... hasn't been updated since 2005 and is >>> listed as being at Ft Collins. >>> >>> Sooooo I'll be complaining to some people on Monday :) >>> >>> On Fri, Nov 11, 2016 at 8:23 AM, Herriage, James L. wrote: >>>> POCs here: >>>> uda.gov = 162.79.29.12 >>>> https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12 >>>> >>>> >>>> Thanks, >>>> Lee >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Charles Gagnon >>>> Sent: Thursday, November 10, 2016 4:20 PM >>>> To: nanog at nanog.org >>>> Subject: USDA IT Contacts? >>>> >>>> *EXTERNAL EMAIL: EVALUATE* >>>> >>>> Would anyone have information about IT contacts within the US Government? >>>> Some of our IP ranges seem to be blocked from access to some government web servers (discovered on http://www.usda.gov - we get a odd "access denied" >>>> page there - traces point to the same IP at akamaitechnologies.com). >>>> >>>> I have NO idea who to discuss this with. I could not even find a "Contact Us" to use on their website. >>>> >>>> Regards, >>>> >>>> -- >>>> Charles Gagnon >>>> http://unixrealm.com > From mark.tinka at seacom.mu Sat Nov 12 05:17:38 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 12 Nov 2016 07:17:38 +0200 Subject: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <87bmxl4xpl.fsf@mid.deneb.enyo.de> References: <150623eb-4d6b-a974-a50b-7fc6bd22f712@seacom.mu> <87bmxl4xpl.fsf@mid.deneb.enyo.de> Message-ID: On 11/Nov/16 21:34, Florian Weimer wrote: > > Has the name been a problem for you? Asking vendors about support > must be a bit awkward these days. Why do you reckon? Mark. From baldur.norddahl at gmail.com Sat Nov 12 14:07:46 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 12 Nov 2016 15:07:46 +0100 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <48ac6389-eb6d-af68-e9a0-af91c2ab1dec@seacom.mu> Message-ID: <684d989b-b511-59fa-95d8-6d81c59dc4a5@gmail.com> Den 11/11/2016 kl. 11.20 skrev Mark Tinka: > > > On 11/Nov/16 12:07, Baldur Norddahl wrote: > >> No filters. There are just no routes that will take a network packet that >> arrive on an interface in VRF internet and move it to an interface in VRF >> default without adding a MPLS header to mark the VRF. With the MPLS header >> the packet type is no longer IPv4 but MPLS. >> >> Therefore there is no way you from the internet or from a customer link can >> even attempt to inject packets that would be received by the OSPF process. >> Since we use 10.0.0.0/8 and our vrf internet has no such route, you would >> just get no route to host if you tried. > > Good for you. > > We don't run the whole "Internet in a VRF" architecture (too many > moving parts), so not having our IGP being exposed to IP helps :-). Internet in a VRF just works and it is not at all complicated. I will recommend it for anyone which has the equipment that can do it. I do realise that not everyone can do this however. I have not studied OSPFv3 in detail but it appears that only IPv6 link local addresses are used. Since that can not be routed, I do not think OSPFv3 exposes anything to the Internet. I would probably go with OSPFv3 if I had to configure a network without VRF support. If I was coding an OSPFv3 daemon I would make it bind only to link local addresses on interfaces, which will guarantee that no traffic is received from outsiders. Regards, Baldur From arshad.rad at gmail.com Sat Nov 12 19:28:09 2016 From: arshad.rad at gmail.com (Mehrdad Arshad Rad) Date: Sat, 12 Nov 2016 11:28:09 -0800 Subject: Network Diagnostic Tool Message-ID: Hi, I've started to develop an open source tool 4 months ago to help neteng/sysadmin/sysops please take look at the below link and let me know if you have any suggestions. https://github.com/mehrdadrad/mylg p.s you can download it for different operating systems at http://mylg.io Thanks, Mehrdad From jhellenthal at dataix.net Sun Nov 13 04:05:29 2016 From: jhellenthal at dataix.net (J. Hellenthal) Date: Sat, 12 Nov 2016 22:05:29 -0600 Subject: Network Diagnostic Tool In-Reply-To: References: Message-ID: <8479FC96-7FE9-4938-BA70-9EFAFF8F3BAD@DataIX.net> That is a very cool contribution you've made. Let me run it through some tests and put it to work right away and see if I can provide some feedback and maybe possible patches or incites But thank you!! -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Nov 12, 2016, at 13:28, Mehrdad Arshad Rad wrote: Hi, I've started to develop an open source tool 4 months ago to help neteng/sysadmin/sysops please take look at the below link and let me know if you have any suggestions. https://github.com/mehrdadrad/mylg p.s you can download it for different operating systems at http://mylg.io Thanks, Mehrdad From mark.tinka at seacom.mu Sun Nov 13 06:50:27 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 13 Nov 2016 08:50:27 +0200 Subject: OSPF vs ISIS - Which do you prefer & why? In-Reply-To: <684d989b-b511-59fa-95d8-6d81c59dc4a5@gmail.com> References: <20161110.192218.74700815.sthaug@nethelp.no> <5824C927.9050103@foobar.org> <48ac6389-eb6d-af68-e9a0-af91c2ab1dec@seacom.mu> <684d989b-b511-59fa-95d8-6d81c59dc4a5@gmail.com> Message-ID: <9a57e1ac-50ae-02f0-d626-1443517f3fb4@seacom.mu> On 12/Nov/16 16:07, Baldur Norddahl wrote: > > I have not studied OSPFv3 in detail but it appears that only IPv6 link > local addresses are used. Since that can not be routed, I do not think > OSPFv3 exposes anything to the Internet. I would probably go with > OSPFv3 if I had to configure a network without VRF support. > > If I was coding an OSPFv3 daemon I would make it bind only to link > local addresses on interfaces, which will guarantee that no traffic is > received from outsiders. OSPFv3 does, indeed, form adjacencies against the link-local scope - fe80::/10. This is unlike OSPFv2 which does the same on the configured IPv4 address. If I had to run OSPF, it would certainly be OSPFv3. Even when using it to carry IPv4 NLRI, you still need to run IPv6 on the corresponding interfaces as that is how adjacencies to support either or both address families are formed. Mark. From jfmezei_nanog at vaxination.ca Sun Nov 13 07:03:18 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 13 Nov 2016 02:03:18 -0500 Subject: Here we go again. In-Reply-To: References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> Message-ID: <58281036.2010901@vaxination.ca> On 2016-11-09 17:54, William Herrin wrote: > I think this discussion is premature. We can hypothesize any number of > evils from the President Elect but until someone introduces a bill we > can only tilt at windmills. The president elect chose Mr Eisenach to help fill jobs in FCC and other telecom areas of govt. Mr Eisenach is a regular "expert witness" hired by Telus in Canada at CRTC hearing. In last week's CRTC hearing on net neutrality, he held his very standard pro-incumbent stance against it. And the same arguments will be used to convicne the USA to drop net neutrality to help foster "dynamic competition" (euphemism for "unregulated duopoly"). It is a given that discussion on banning zero rating of content in USA will not happen. It is highly possible that Title II reclassification of ISPs will be revoked. Ted Cruz tried to block the IANA re-organisation. So the direction of where things will be going is fairly clear. AT&T announced zero rated video (aka T0-Mobile with throttling) just after the election so they are quite confident this won't be blocked by FCC. (although merger with Time Warner may be blocked). From dovid at telecurve.com Sun Nov 13 07:07:09 2016 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 13 Nov 2016 02:07:09 -0500 Subject: Here we go again. In-Reply-To: <58281036.2010901@vaxination.ca> References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> <58281036.2010901@vaxination.ca> Message-ID: Consumers can always chose with their wallet. On Sun, Nov 13, 2016 at 2:03 AM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 2016-11-09 17:54, William Herrin wrote: > > > I think this discussion is premature. We can hypothesize any number of > > evils from the President Elect but until someone introduces a bill we > > can only tilt at windmills. > > > The president elect chose Mr Eisenach to help fill jobs in FCC and other > telecom areas of govt. > > Mr Eisenach is a regular "expert witness" hired by Telus in Canada at > CRTC hearing. In last week's CRTC hearing on net neutrality, he held his > very standard pro-incumbent stance against it. And the same arguments > will be used to convicne the USA to drop net neutrality to help foster > "dynamic competition" (euphemism for "unregulated duopoly"). > > It is a given that discussion on banning zero rating of content in USA > will not happen. > > It is highly possible that Title II reclassification of ISPs will be > revoked. > > Ted Cruz tried to block the IANA re-organisation. > > So the direction of where things will be going is fairly clear. > > AT&T announced zero rated video (aka T0-Mobile with throttling) just > after the election so they are quite confident this won't be blocked by > FCC. (although merger with Time Warner may be blocked). > > > > From arturo.servin at gmail.com Sun Nov 13 10:30:32 2016 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 13 Nov 2016 10:30:32 +0000 Subject: Here we go again. In-Reply-To: References: <1624203180.33527.1478724998723.JavaMail.zimbra@baylink.com> <58281036.2010901@vaxination.ca> Message-ID: On Sun, 13 Nov 2016 at 07:08 Dovid Bender wrote: > Consumers can always chose with their wallet. > > As long as you have options, which is the basic problem. There isn't real alternative options. From surfer at mauigateway.com Sun Nov 13 20:48:28 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 13 Nov 2016 12:48:28 -0800 Subject: Eisenach & the FCC - was: [Re: Here we go again.] Message-ID: <20161113124828.F9C1054@m0086238.ppops.net> --- jfmezei_nanog at vaxination.ca wrote: The president elect chose Mr Eisenach to help fill jobs in FCC and other telecom areas of govt. ---------------------------------------------------- That'll have impact on ops, if some of the papers are correct. Briefly: https://www.engadget.com/2016/11/09/under-trump-the-future-of-net-neutrality-and-broadband-is-uncert "Eisenach has made a career out of crusading against industry regulation" "...authored several papers and op-ed pieces that were funded by Net Neutrality opponents ..." http://www.businessinsider.com/donald-trump-fcc-net-neutrality-zero-rating-policy-future-2016-11 "The Economics of Zero Rating." In it, Eisenach defends the concept, writing that "broad-based bans or restrictions on zero-rating plans are likely to be counterproductive and harm consumer welfare." Interesting times ahead... scott From mel at beckman.org Sun Nov 13 21:37:02 2016 From: mel at beckman.org (Mel Beckman) Date: Sun, 13 Nov 2016 21:37:02 +0000 Subject: Eisenach & the FCC - was: [Re: Here we go again.] In-Reply-To: <20161113124828.F9C1054@m0086238.ppops.net> References: <20161113124828.F9C1054@m0086238.ppops.net> Message-ID: Before this snowball gets any bigger, I would like to reiterate the previous commenter calling for this present political discussion to move elsewhere. Here's the NANOG AUP we've all agreed to: NANOG Acceptable Use Policy * Discussion will focus on Internet operational and technical issues as described in the charter of NANOG. * Postings of issues inconsistent with the charter are prohibited. * Postings of political, philosophical, and legal nature are prohibited. You don't have to go home, but you can't stay here. -mel On Nov 13, 2016, at 12:49 PM, Scott Weeks > wrote: --- jfmezei_nanog at vaxination.ca wrote: The president elect chose Mr Eisenach to help fill jobs in FCC and other telecom areas of govt. ---------------------------------------------------- That'll have impact on ops, if some of the papers are correct. Briefly: https://www.engadget.com/2016/11/09/under-trump-the-future-of-net-neutrality-and-broadband-is-uncert "Eisenach has made a career out of crusading against industry regulation" "...authored several papers and op-ed pieces that were funded by Net Neutrality opponents ..." http://www.businessinsider.com/donald-trump-fcc-net-neutrality-zero-rating-policy-future-2016-11 "The Economics of Zero Rating." In it, Eisenach defends the concept, writing that "broad-based bans or restrictions on zero-rating plans are likely to be counterproductive and harm consumer welfare." Interesting times ahead... scott From rod.beck at unitedcablecompany.com Sun Nov 13 21:42:14 2016 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sun, 13 Nov 2016 21:42:14 +0000 Subject: Eisenach & the FCC - was: [Re: Here we go again.] In-Reply-To: References: <20161113124828.F9C1054@m0086238.ppops.net>, Message-ID: Public policy affecting networks is a legitimate topic. Net neutrality has been discussed countless times on this board with no objection from anybody. Regards, Roderick. ________________________________ From: NANOG on behalf of Mel Beckman Sent: Sunday, November 13, 2016 10:37 PM To: surfer at mauigateway.com Cc: nanog at nanog.org Subject: Re: Eisenach & the FCC - was: [Re: Here we go again.] Before this snowball gets any bigger, I would like to reiterate the previous commenter calling for this present political discussion to move elsewhere. Here's the NANOG AUP we've all agreed to: NANOG Acceptable Use Policy * Discussion will focus on Internet operational and technical issues as described in the charter of NANOG. Current Charter | North American Network Operators Group www.nanog.org As amended October 6, 2010. 1. Preamble. The North American Network Operators' Group (NANOG) exists to promote dialog between people concerning the creation ... * Postings of issues inconsistent with the charter are prohibited. * Postings of political, philosophical, and legal nature are prohibited. You don't have to go home, but you can't stay here. -mel On Nov 13, 2016, at 12:49 PM, Scott Weeks > wrote: --- jfmezei_nanog at vaxination.ca wrote: The president elect chose Mr Eisenach to help fill jobs in FCC and other telecom areas of govt. ---------------------------------------------------- That'll have impact on ops, if some of the papers are correct. Briefly: https://www.engadget.com/2016/11/09/under-trump-the-future-of-net-neutrality-and-broadband-is-uncert [https://s.aolcdn.com/dims5/amp:a6317e0b93421c087f056ab209b700d98a021849/t:1200,630/q:80/?url=https%3A%2F%2Fs.aolcdn.com%2Fdims-shared%2Fdims3%2FGLOB%2Fcrop%2F4666x2539%2B0%2B0%2Fresize%2F1600x871%21%2Fformat%2Fjpg%2Fquality%2F85%2Fhttps%3A%2F%2Fs.aolcdn.com%2Fhss%2Fstorage%2Fmidas%2F914aeeebf580a22eca2109764d528600%2F204549332%2F2d3a00d2e6d34d28a309ce5a6622451b.jpeg] Under Trump the future of Net Neutrality and broadband is uncertain www.engadget.com On January 20th, Donald Trump will be sworn in as president of the United States. With a Republican-controlled House and Senate behind him, things in this count... "Eisenach has made a career out of crusading against industry regulation" "...authored several papers and op-ed pieces that were funded by Net Neutrality opponents ..." http://www.businessinsider.com/donald-trump-fcc-net-neutrality-zero-rating-policy-future-2016-11 "The Economics of Zero Rating." In it, Eisenach defends the concept, writing that "broad-based bans or restrictions on zero-rating plans are likely to be counterproductive and harm consumer welfare." Interesting times ahead... scott From mel at beckman.org Sun Nov 13 22:01:16 2016 From: mel at beckman.org (Mel Beckman) Date: Sun, 13 Nov 2016 22:01:16 +0000 Subject: Eisenach & the FCC - was: [Re: Here we go again.] In-Reply-To: References: <20161113124828.F9C1054@m0086238.ppops.net>, , Message-ID: <1F1A87F9-2C20-4C31-AB47-5EE64F080BBC@beckman.org> Rod, I respectfully disagree. This is discussing politics, not the "operational and technical issues" of NANOG's charter. There are other venues for politics. NANOG's AUP prohibits political discussions. -mel On Nov 13, 2016, at 1:42 PM, Rod Beck > wrote: Public policy affecting networks is a legitimate topic. Net neutrality has been discussed countless times on this board with no objection from anybody. Regards, Roderick. ________________________________ From: NANOG > on behalf of Mel Beckman > Sent: Sunday, November 13, 2016 10:37 PM To: surfer at mauigateway.com Cc: nanog at nanog.org Subject: Re: Eisenach & the FCC - was: [Re: Here we go again.] Before this snowball gets any bigger, I would like to reiterate the previous commenter calling for this present political discussion to move elsewhere. Here's the NANOG AUP we've all agreed to: NANOG Acceptable Use Policy * Discussion will focus on Internet operational and technical issues as described in the charter of NANOG. Current Charter | North American Network Operators Group www.nanog.org As amended October 6, 2010. 1. Preamble. The North American Network Operators' Group (NANOG) exists to promote dialog between people concerning the creation ... * Postings of issues inconsistent with the charter are prohibited. * Postings of political, philosophical, and legal nature are prohibited. You don't have to go home, but you can't stay here. -mel On Nov 13, 2016, at 12:49 PM, Scott Weeks > wrote: --- jfmezei_nanog at vaxination.ca wrote: The president elect chose Mr Eisenach to help fill jobs in FCC and other telecom areas of govt. ---------------------------------------------------- That'll have impact on ops, if some of the papers are correct. Briefly: https://www.engadget.com/2016/11/09/under-trump-the-future-of-net-neutrality-and-broadband-is-uncert [https://s.aolcdn.com/dims5/amp:a6317e0b93421c087f056ab209b700d98a021849/t:1200,630/q:80/?url=https%3A%2F%2Fs.aolcdn.com%2Fdims-shared%2Fdims3%2FGLOB%2Fcrop%2F4666x2539%2B0%2B0%2Fresize%2F1600x871%21%2Fformat%2Fjpg%2Fquality%2F85%2Fhttps%3A%2F%2Fs.aolcdn.com%2Fhss%2Fstorage%2Fmidas%2F914aeeebf580a22eca2109764d528600%2F204549332%2F2d3a00d2e6d34d28a309ce5a6622451b.jpeg] Under Trump the future of Net Neutrality and broadband is uncertain www.engadget.com On January 20th, Donald Trump will be sworn in as president of the United States. With a Republican-controlled House and Senate behind him, things in this count... "Eisenach has made a career out of crusading against industry regulation" "...authored several papers and op-ed pieces that were funded by Net Neutrality opponents ..." http://www.businessinsider.com/donald-trump-fcc-net-neutrality-zero-rating-policy-future-2016-11 "The Economics of Zero Rating." In it, Eisenach defends the concept, writing that "broad-based bans or restrictions on zero-rating plans are likely to be counterproductive and harm consumer welfare." Interesting times ahead... scott From ryan at finnesey.com Sun Nov 13 22:36:53 2016 From: ryan at finnesey.com (Ryan Finnesey) Date: Sun, 13 Nov 2016 22:36:53 +0000 Subject: WHOIS Privacy & Proxy Services? Message-ID: Is there any news out of the ICANN meeting that just concluded regarding new policy's around WHOIS Privacy & Proxy Services? From morrowc.lists at gmail.com Sun Nov 13 23:57:19 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 13 Nov 2016 15:57:19 -0800 Subject: NEVERMIND! (was: Seeking Google reverse DNS delegation contact) In-Reply-To: <9287.1478844315@segfault.tristatelogic.com> References: <9287.1478844315@segfault.tristatelogic.com> Message-ID: So... actually someone did tell arin to aim these at ns1/2google.com... I'll go ask arin to 'fix the glitch'. thanks! -chris (sometimes people do this, I have no idea why... perhaps they just like broken ptrs?) On Thu, Nov 10, 2016 at 10:05 PM, Ronald F. Guilmette wrote: > > > My profuse apologies to everyone. It seems that Google is not in fact > involved in any way with providing reverse DNS for the 204.8.136.0/21 > IP address block. I was deceived into believing it was by some > unusual trickey on the part of the spammer-controlled name servers > ns1.saversagreeable.com and ns2.saversagreeable.com. You can see > the clever deception toward the very end of the dig +trace listing > I posted: > > http://pastebin.com/raw/VNwmgMHh > > It seems those clever rascal spammers tried to implicate Google's > name servers, but it is only their's which are giving out the > reverse DNS which suoorts their snowshoe spamming efforts in the > 204.8.136.0/21 block. > > Sorry for my mistake everyone. I wasn't expecting quite this level > or kind of reverse DNS delegation trickery. > > > Regards, > rfg > From rbf+nanog at panix.com Mon Nov 14 00:41:52 2016 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 13 Nov 2016 18:41:52 -0600 Subject: NEVERMIND! (was: Seeking Google reverse DNS delegation Message-ID: <20161114004152.GA27692@panix.com> contact) User-Agent: Mutt/1.6.1 (2016-04-27) On Sun, Nov 13, 2016 at 03:57:19PM -0800, Christopher Morrow wrote: > So... actually someone did tell arin to aim these at > ns1/2google.com... > I'll go ask arin to 'fix the glitch'. For 138.8.204.in-addr.arpa ... ARIN is delegating to ns[12].saversagreeable.com The NS records on the saversagreeable.com servers are pointing to ns[12].google.com. > > http://pastebin.com/raw/VNwmgMHh -- Brett From rubensk at gmail.com Mon Nov 14 00:49:56 2016 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 13 Nov 2016 22:49:56 -0200 Subject: WHOIS Privacy & Proxy Services? In-Reply-To: References: Message-ID: On Sun, Nov 13, 2016 at 8:36 PM, Ryan Finnesey wrote: > Is there any news out of the ICANN meeting that just concluded regarding > new policy's around WHOIS Privacy & Proxy Services? > The Implementation Review Team is just starting its work, so there won't be much news for a while in this topic. You can see presentations and hear recordings of the 2 sessions: https://icann572016.sched.org/event/8cwR/privacy-and-proxy-services-accreditation-implementation-review-team-project-overview https://icann572016.sched.org/event/8dQg/privacy-and-proxy-services-accreditation-program-implementation-review-team-working-meeting But the short version is "ongoing work". Rubens From surfer at mauigateway.com Mon Nov 14 01:25:00 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 13 Nov 2016 17:25:00 -0800 Subject: Eisenach & the FCC - was: [Re: Here we go again.] Message-ID: <20161113172500.F9C08BB@m0086238.ppops.net> --- mel at beckman.org wrote: From: Mel Beckman This is discussing politics, not the "operational and technical issues" of NANOG's charter. ------------------------------------------- BTW, I didn't mean it to be talking politics. He was mentioned in the current discussion, I looked into a little more depth on the person and I thought it'd be interesting to the group. scott From rfg at tristatelogic.com Mon Nov 14 03:41:42 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 13 Nov 2016 19:41:42 -0800 Subject: NEVERMIND! (was: Seeking Google reverse DNS delegation In-Reply-To: <20161114004152.GA27692@panix.com> Message-ID: <47122.1479094902@segfault.tristatelogic.com> In message <20161114004152.GA27692 at panix.com>, Brett Frankenberger wrote: >On Sun, Nov 13, 2016 at 03:57:19PM -0800, Christopher Morrow wrote: >> So... actually someone did tell arin to aim these at >> ns1/2google.com... >> I'll go ask arin to 'fix the glitch'. > >For 138.8.204.in-addr.arpa ... > >ARIN is delegating to ns[12].saversagreeable.com > >The NS records on the saversagreeable.com servers are pointing to >ns[12].google.com. > >> > http://pastebin.com/raw/VNwmgMHh Right, which is what I said. To borrow a word from our former Dear Leader, I misunderestimated the level of either (a) devilish deception or else (b) ordinary garden- variety sheer technical incompence on the part of the current illicit inhabitants of 204.8.136.0/21. And really, I don't even give them much credit for brains, so it is probably the latter, which is somewhat depressing. I mean seriously.... geeezz! What's the world coming to? It seems that the clubs for the low-life deadbeat spammers and IP hijackers are letting *anybody* in these days. I am always annoyed by spam and spammers, but I get REALLY annoyed when I get spammed by nitwits who can't even find their own asses with both hands when it comes to something as simple as setiing up their DNS properly. Next thing you know, they'll be making bonehead novice mistakes like leaving out the trailing periods in the Right Places in their zone files. Honstly, there ought to be a law. If you're gonna spam me and use all these different levels and kinds of deception... massivley violating even the minimalist CAN-SPAM Act in the process... then at least have the courtesy, decency, and self-respect to at least do it in a workmanlike and competent fashion! I mean come on! And that includes the bogus info you put into your WHOIS records too! Seriously, I give you credit for at least picking out a valid random street address, somewhere in fly-over country, but if you're going to go to all the trouble to pick yourself out a domain name, set it all up and then somehow snooker ARIN into delegating an entire /21's worth of reverse DNS to it, then my god, at least pick out something that has an air of believability to it, you know, like austin4u.net or texnets.net or something... not saversagreeable.com which is so totally and transparently bogus. And while you're at it, you should also at least make the WHOIS street address and the phone number area code line up, if not with the place you are pretending to be (Austin, TX) then at least with each other. Honestly, Christ! I've looked at enough phone numbers in enough spammer WHOIS records that I haven't needed to Google area code 702 in years to know that it ain't nowhere near Indianapolis. (Duh!) Look, spammers are gonna spam and hijackers are gonna hijack. We all know this, and for the most part, we've all come to accept it, because there are just too many crooks and/or too many incompetents at every level in the system to ever make it all go away. But if you're gonna spam and/or squat on IP space that clearly isn't your's, then at least have the dignity to actually *earn* your ill-gotten gains, you know, by setting up your deceptions properly. This crap in 204.8.136.0/21 may fool the folks at ARIN, but nobody else is buying it, because you set it up so badly. You are a discredit to spammers and hijackers, and that's saying a lot. This is your "job" fer chrissake? Don't you have any pride? 'nuff said. P.S. Sorry for the rant everybody, but sometimes it just really gets to me when I see quite this level of stoopid in the spammer community. In general I loath and despise spammers, but for some of them at least, I have a grudging respect, because at least they are good at their jobs. But these guys ain't among them. Everything the've done here is so transparently bogus that my dog could spot it, and he's blind in one eye. From ryan at finnesey.com Mon Nov 14 06:00:22 2016 From: ryan at finnesey.com (Ryan Finnesey) Date: Mon, 14 Nov 2016 06:00:22 +0000 Subject: WHOIS Privacy & Proxy Services? In-Reply-To: References: Message-ID: Thank you very helpful. From: Rubens Kuhl [mailto:rubensk at gmail.com] Sent: Sunday, November 13, 2016 7:50 PM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: WHOIS Privacy & Proxy Services? On Sun, Nov 13, 2016 at 8:36 PM, Ryan Finnesey > wrote: Is there any news out of the ICANN meeting that just concluded regarding new policy's around WHOIS Privacy & Proxy Services? The Implementation Review Team is just starting its work, so there won't be much news for a while in this topic. You can see presentations and hear recordings of the 2 sessions: https://icann572016.sched.org/event/8cwR/privacy-and-proxy-services-accreditation-implementation-review-team-project-overview https://icann572016.sched.org/event/8dQg/privacy-and-proxy-services-accreditation-program-implementation-review-team-working-meeting But the short version is "ongoing work". Rubens From outsider at scarynet.org Mon Nov 14 15:12:34 2016 From: outsider at scarynet.org (Alexander Maassen) Date: Mon, 14 Nov 2016 16:12:34 +0100 Subject: Nanog Politics [was: Re: Eisenach & the FCC - was: [Re: Here we go again.]] In-Reply-To: <1F1A87F9-2C20-4C31-AB47-5EE64F080BBC@beckman.org> References: <20161113124828.F9C1054@m0086238.ppops.net>, , <1F1A87F9-2C20-4C31-AB47-5EE64F080BBC@beckman.org> Message-ID: <8d4dfda9f11f8404f7a009d2c6c6285a.squirrel@mail.scarynet.org> Whether it's politics, non-politics, related, offtopic, whatever. It has been discussed in here for lengths and overlengths. This one is no different. And hey, rules exist to be bend >:-) Second, the content of the topic will affect ALL of us, whether you are an ISP, simple admin/tech or anyone else watching and participating on this list as it discusses changes that are to be expected getting a new president with his new associates who probably only looks at the cashflow without having any clue about the technical difficulties and problems they will cause. In all the time I am monitoring nanog know, there is one thing I learned: If you don't like it, simply move it to /dev/null and ignore the contents. On Sun, November 13, 2016 11:01 pm, Mel Beckman wrote: > Rod, > > I respectfully disagree. This is discussing politics, not the "operational > and technical issues" of NANOG's charter. > > There are other venues for politics. NANOG's AUP prohibits political > discussions. > > -mel > > On Nov 13, 2016, at 1:42 PM, Rod Beck > > > wrote: > > > Public policy affecting networks is a legitimate topic. Net neutrality has > been discussed countless times on this board with no objection from > anybody. > > > Regards, > > > Roderick. > > > ________________________________ > From: NANOG > on > behalf of Mel Beckman > > Sent: Sunday, November 13, 2016 10:37 PM > To: surfer at mauigateway.com > Cc: nanog at nanog.org > Subject: Re: Eisenach & the FCC - was: [Re: Here we go again.] > > Before this snowball gets any bigger, I would like to reiterate the > previous commenter calling for this present political discussion to move > elsewhere. Here's the NANOG AUP we've all agreed to: > > > > NANOG Acceptable Use Policy > > * Discussion will focus on Internet operational and technical issues as > described in the charter of NANOG. > Current Charter | North American Network Operators > Group > www.nanog.org > As amended October 6, 2010. 1. Preamble. The North American Network > Operators' Group (NANOG) exists to promote dialog between people > concerning the creation ... > > > > * Postings of issues inconsistent with the charter are prohibited. > > * Postings of political, philosophical, and legal nature are prohibited. > > > > You don't have to go home, but you can't stay here. > > -mel > > On Nov 13, 2016, at 12:49 PM, Scott Weeks > > > wrote: > > > > --- > jfmezei_nanog at vaxination.ca > wrote: > > The president elect chose Mr Eisenach to help fill jobs in FCC > and other telecom areas of govt. > ---------------------------------------------------- > > > > That'll have impact on ops, if some of the papers are correct. > Briefly: > > > https://www.engadget.com/2016/11/09/under-trump-the-future-of-net-neutrality-and-broadband-is-uncert > [https://s.aolcdn.com/dims5/amp:a6317e0b93421c087f056ab209b700d98a021849/t:1200,630/q:80/?url=https%3A%2F%2Fs.aolcdn.com%2Fdims-shared%2Fdims3%2FGLOB%2Fcrop%2F4666x2539%2B0%2B0%2Fresize%2F1600x871%21%2Fformat%2Fjpg%2Fquality%2F85%2Fhttps%3A%2F%2Fs.aolcdn.com%2Fhss%2Fstorage%2Fmidas%2F914aeeebf580a22eca2109764d528600%2F204549332%2F2d3a00d2e6d34d28a309ce5a6622451b.jpeg] > > Under Trump the future of Net Neutrality and broadband is > uncertain > www.engadget.com > On January 20th, Donald Trump will be sworn in as president of the United > States. With a Republican-controlled House and Senate behind him, things > in this count... > > > > "Eisenach has made a career out of crusading against industry > regulation" > > "...authored several papers and op-ed pieces that were funded by > Net Neutrality opponents ..." > > > > http://www.businessinsider.com/donald-trump-fcc-net-neutrality-zero-rating-policy-future-2016-11 > > "The Economics of Zero Rating." In it, Eisenach defends the concept, > writing that "broad-based bans or restrictions on zero-rating plans > are likely to be counterproductive and harm consumer welfare." > > > > Interesting times ahead... > > > scott > From large.hadron.collider at gmx.com Tue Nov 15 05:06:47 2016 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Mon, 14 Nov 2016 21:06:47 -0800 Subject: NEVERMIND! (was: Seeking Google reverse DNS delegation In-Reply-To: <47122.1479094902@segfault.tristatelogic.com> References: <47122.1479094902@segfault.tristatelogic.com> Message-ID: <7077df16-64ae-822d-8ce0-ba44129e2f86@gmx.com> Engage glasses and safety squints. On 2016-11-13 07:41 PM, Ronald F. Guilmette wrote: > In message <20161114004152.GA27692 at panix.com>, > Brett Frankenberger wrote: > >> On Sun, Nov 13, 2016 at 03:57:19PM -0800, Christopher Morrow wrote: >>> So... actually someone did tell arin to aim these at >>> ns1/2google.com... >>> I'll go ask arin to 'fix the glitch'. >> For 138.8.204.in-addr.arpa ... >> >> ARIN is delegating to ns[12].saversagreeable.com >> >> The NS records on the saversagreeable.com servers are pointing to >> ns[12].google.com. >> >>>> http://pastebin.com/raw/VNwmgMHh > > Right, which is what I said. > > To borrow a word from our former Dear Leader, I misunderestimated the > level of either (a) devilish deception or else (b) ordinary garden- > variety sheer technical incompence on the part of the current illicit > inhabitants of 204.8.136.0/21. And really, I don't even give them > much credit for brains, so it is probably the latter, which is > somewhat depressing. I'm not sure what's funnier - Dear Leader, "misunderestimated" or your opinion of intelligence level. > > I mean seriously.... geeezz! What's the world coming to? It seems that > the clubs for the low-life deadbeat spammers and IP hijackers are letting > *anybody* in these days. I am always annoyed by spam and spammers, but > I get REALLY annoyed when I get spammed by nitwits who can't even find > their own asses with both hands when it comes to something as simple as > setiing up their DNS properly. Next thing you know, they'll be making > bonehead novice mistakes like leaving out the trailing periods in the > Right Places in their zone files. True fact: I have made such boneheaded mistakes before. > > Honstly, there ought to be a law. If you're gonna spam me and use all > these different levels and kinds of deception... massivley violating > even the minimalist CAN-SPAM Act in the process... then at least have > the courtesy, decency, and self-respect to at least do it in a workmanlike > and competent fashion! I mean come on! Like, make it a lessener for the sentence? > > And that includes the bogus info you put into your WHOIS records too! > Seriously, I give you credit for at least picking out a valid random > street address, somewhere in fly-over country, but if you're going to > go to all the trouble to pick yourself out a domain name, set it all > up and then somehow snooker ARIN into delegating an entire /21's worth > of reverse DNS to it, then my god, at least pick out something that has > an air of believability to it, you know, like austin4u.net or texnets.net > or something... not saversagreeable.com which is so totally and transparently > bogus. What if it was originally going to be a forum site for couponers who aren't arrogant about it, and then they got sidetracked? > > And while you're at it, you should also at least make the WHOIS street > address and the phone number area code line up, if not with the place > you are pretending to be (Austin, TX) then at least with each other. What if you live in BC, Canada (250 code) and your business phone number is rate-centred in Vermont, USA (802 code) and the same business primarily serves the latter? > Honestly, Christ! I've looked at enough phone numbers in enough spammer > WHOIS records that I haven't needed to Google area code 702 in years to > know that it ain't nowhere near Indianapolis. (Duh!) > > Look, spammers are gonna spam and hijackers are gonna hijack. We all > know this, and for the most part, we've all come to accept it, because > there are just too many crooks and/or too many incompetents at every > level in the system to ever make it all go away. But if you're gonna > spam and/or squat on IP space that clearly isn't your's, then at least > have the dignity to actually *earn* your ill-gotten gains, you know, > by setting up your deceptions properly. This crap in 204.8.136.0/21 > may fool the folks at ARIN, but nobody else is buying it, because you > set it up so badly. You are a discredit to spammers and hijackers, > and that's saying a lot. This is your "job" fer chrissake? Don't you > have any pride? > > 'nuff said. > > > P.S. Sorry for the rant everybody, but sometimes it just really gets > to me when I see quite this level of stoopid in the spammer community. > In general I loath and despise spammers, but for some of them at least, > I have a grudging respect, because at least they are good at their jobs. > But these guys ain't among them. Everything the've done here is so > transparently bogus that my dog could spot it, and he's blind in one > eye. 100%. That just puts the icing on the cake. From rfg at tristatelogic.com Tue Nov 15 05:35:37 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 14 Nov 2016 21:35:37 -0800 Subject: NEVERMIND! (was: Seeking Google reverse DNS delegation In-Reply-To: <7077df16-64ae-822d-8ce0-ba44129e2f86@gmx.com> Message-ID: <52315.1479188137@segfault.tristatelogic.com> In message <7077df16-64ae-822d-8ce0-ba44129e2f86 at gmx.com>, Large Hadron Collider wrote: >> And that includes the bogus info you put into your WHOIS records too! >> Seriously, I give you credit for at least picking out a valid random >> street address, somewhere in fly-over country, but if you're going to >> go to all the trouble to pick yourself out a domain name, set it all >> up and then somehow snooker ARIN into delegating an entire /21's worth >> of reverse DNS to it, then my god, at least pick out something that has >> an air of believability to it, you know, like austin4u.net or texnets.net >> or something... not saversagreeable.com which is so totally and transparently >> bogus. >What if it was originally going to be a forum site for couponers who >aren't arrogant about it, and then they got sidetracked? Yea. Right. And I'm sure they thought that they were gonna need an entire /21 to host one web site. The smell from this is so bad it almost defies description. Regards, rfg From hank at efes.iucc.ac.il Tue Nov 15 06:35:24 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 15 Nov 2016 08:35:24 +0200 Subject: Gmail failure recently? Message-ID: <10041b9e-dbcc-31c3-5949-9f17f4cb6bd5@efes.iucc.ac.il> I woke today to find that all my Inbox items from May 1-Nov 15, 2016 were missing. All other folders are intact. Missing emails are not in Spam, Trash, Archive or auto-fwded. Did pswd reset and have initiated a request to restore the missing emails, but am wondering whether others have experienced some sort of Gmail failure in the past 8 hours. Thanks, Hank From marco at paesani.it Tue Nov 15 08:35:47 2016 From: marco at paesani.it (Marco Paesani) Date: Tue, 15 Nov 2016 09:35:47 +0100 Subject: Gmail failure recently? In-Reply-To: <10041b9e-dbcc-31c3-5949-9f17f4cb6bd5@efes.iucc.ac.il> References: <10041b9e-dbcc-31c3-5949-9f17f4cb6bd5@efes.iucc.ac.il> Message-ID: Hi Hank, I'm user of Gmail with this account but I don't see any issue, the service is normal from my point of view. Kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it 2016-11-15 7:35 GMT+01:00 Hank Nussbacher : > I woke today to find that all my Inbox items from May 1-Nov 15, 2016 > were missing. All other folders are intact. Missing emails are not in > Spam, Trash, Archive or auto-fwded. Did pswd reset and have initiated a > request to restore the missing emails, but am wondering whether others > have experienced some sort of Gmail failure in the past 8 hours. > > Thanks, > Hank > From eric at ericheather.com Tue Nov 15 15:47:43 2016 From: eric at ericheather.com (Eric C. Miller) Date: Tue, 15 Nov 2016 15:47:43 +0000 Subject: Contact at NY State Health Department Message-ID: Is there anyone from NY State Health Department here that can help me with random connection drops? Thank you! Eric Miller From list at satchell.net Wed Nov 16 16:52:19 2016 From: list at satchell.net (Stephen Satchell) Date: Wed, 16 Nov 2016 08:52:19 -0800 Subject: Port 2323/tcp Message-ID: <7cc32d8c-759b-1f6d-326f-dbde57187d20@satchell.net> I've been seeing a lot of rejections in my logs for 2323/tcp. According to the Storm Center, this is what the Mirai botnet scanner uses to look for other target devices. Is it worthwhile to report sightings to the appropriate abuse addresses? (That assumes there *is* an abuse address associated with the IPv4 address that is the source.) Would administrations receiving these notices do anything with them? Alternatively, is there anyone collecting this information from people like me to expose the IP addresses of possible infections? I am toying with the idea of setting up a honey-pot, but I'm so far behind with $DAYJOB that such a project will have to wait a bit. I want to be a good net citizen. I also want to make sure I'm not wasting my time. Today's crop: > 1.34.169.183 > 12.221.236.2 > 14.138.22.12 > 14.169.142.30 > 14.174.71.158 > 14.177.197.101 > 31.168.146.33 > 31.168.212.174 > 36.71.224.179 > 36.72.253.206 > 37.106.18.86 > 42.115.187.189 > 42.117.254.248 > 42.119.228.222 > 43.225.195.180 > 46.59.6.249 > 49.114.192.91 > 58.11.238.146 > 58.186.231.59 > 59.8.136.21 > 59.49.191.4 > 59.57.68.56 > 59.126.35.47 > 59.126.242.70 > 59.127.104.67 > 59.127.242.8 > 60.251.125.125 > 61.219.165.38 > 73.84.152.194 > 78.179.113.148 > 78.186.61.30 > 78.189.169.142 > 78.226.222.234 > 79.119.74.255 > 81.16.8.193 > 81.101.233.14 > 81.214.121.43 > 81.214.134.133 > 81.214.137.197 > 82.77.68.189 > 83.233.40.141 > 85.96.202.199 > 85.99.121.41 > 85.238.103.111 > 86.121.225.48 > 87.251.252.22 > 88.249.224.167 > 89.122.87.239 > 89.151.128.198 > 90.177.91.201 > 92.53.52.235 > 92.55.231.90 > 94.31.239.178 > 94.254.41.152 > 94.255.162.90 > 95.78.245.54 > 95.106.34.92 > 95.161.236.182 > 96.57.103.19 > 101.0.43.13 > 108.203.68.245 > 110.55.108.215 > 110.136.233.10 > 112.133.69.176 > 112.165.93.130 > 112.186.42.216 > 113.5.224.110 > 113.161.64.11 > 113.169.18.153 > 113.171.98.158 > 113.172.4.204 > 113.183.204.112 > 113.188.44.246 > 114.32.28.219 > 114.32.87.32 > 114.32.189.5 > 114.34.29.167 > 114.34.170.10 > 114.35.153.123 > 114.226.53.133 > 115.76.127.118 > 116.73.65.248 > 116.100.170.92 > 117.0.7.77 > 117.1.26.234 > 117.195.254.3 > 118.32.44.99 > 118.42.15.21 > 118.43.112.120 > 118.100.64.159 > 118.163.191.208 > 119.199.160.207 > 119.202.78.47 > 120.71.215.81 > 121.129.203.22 > 121.178.104.129 > 121.180.53.143 > 122.117.245.28 > 123.9.72.86 > 123.16.78.77 > 123.23.49.149 > 123.24.108.10 > 123.24.250.187 > 123.25.74.209 > 123.27.159.13 > 123.240.245.72 > 124.66.99.251 > 124.131.28.38 > 125.166.193.206 > 125.227.138.132 > 138.204.203.66 > 171.97.245.221 > 171.224.7.147 > 171.226.20.220 > 171.232.118.93 > 171.248.210.120 > 171.249.223.213 > 171.250.26.209 > 173.56.21.67 > 175.138.81.130 > 175.203.202.232 > 175.207.137.139 > 175.211.251.156 > 177.207.49.108 > 177.207.67.170 > 177.223.52.193 > 178.222.246.96 > 179.4.140.63 > 179.235.55.39 > 179.253.163.107 > 180.73.117.62 > 180.254.224.10 > 182.37.156.98 > 182.180.80.75 > 182.180.123.43 > 183.46.49.216 > 183.144.245.235 > 186.19.48.158 > 186.69.170.130 > 186.219.1.156 > 187.104.248.17 > 187.211.63.51 > 188.209.153.15 > 189.101.220.244 > 189.234.9.147 > 191.103.35.250 > 191.180.198.31 > 191.249.21.41 > 196.207.83.23 > 197.224.37.108 > 201.243.225.103 > 210.178.250.121 > 211.7.146.51 > 211.216.202.191 > 213.5.216.213 > 213.14.195.100 > 213.170.76.149 > 217.129.243.48 > 218.161.121.178 > 218.186.43.224 > 220.85.169.133 > 220.132.111.124 > 220.133.24.142 > 220.133.198.71 > 220.133.234.229 > 220.134.132.200 > 220.134.193.133 > 220.135.64.43 > 221.145.147.78 > 221.159.105.17 > 221.167.64.53 > 222.254.238.188 > 223.154.223.159 From mel at beckman.org Wed Nov 16 17:25:34 2016 From: mel at beckman.org (Mel Beckman) Date: Wed, 16 Nov 2016 17:25:34 +0000 Subject: Port 2323/tcp In-Reply-To: <7cc32d8c-759b-1f6d-326f-dbde57187d20@satchell.net> References: <7cc32d8c-759b-1f6d-326f-dbde57187d20@satchell.net> Message-ID: It's pretty much part of the IBR now. And what can a provider do, really? It's not likely he will expend much effort blocking customers. Maybe we should all start filtering 2323? -mel via cell > On Nov 16, 2016, at 11:53 AM, Stephen Satchell wrote: > > I've been seeing a lot of rejections in my logs for 2323/tcp. According > to the Storm Center, this is what the Mirai botnet scanner uses to look > for other target devices. > > Is it worthwhile to report sightings to the appropriate abuse addresses? > (That assumes there *is* an abuse address associated with the IPv4 > address that is the source.) Would administrations receiving these > notices do anything with them? > > Alternatively, is there anyone collecting this information from people > like me to expose the IP addresses of possible infections? > > I am toying with the idea of setting up a honey-pot, but I'm so far > behind with $DAYJOB that such a project will have to wait a bit. > > I want to be a good net citizen. I also want to make sure I'm not > wasting my time. > > Today's crop: > >> 1.34.169.183 >> 12.221.236.2 >> 14.138.22.12 >> 14.169.142.30 >> 14.174.71.158 >> 14.177.197.101 >> 31.168.146.33 >> 31.168.212.174 >> 36.71.224.179 >> 36.72.253.206 >> 37.106.18.86 >> 42.115.187.189 >> 42.117.254.248 >> 42.119.228.222 >> 43.225.195.180 >> 46.59.6.249 >> 49.114.192.91 >> 58.11.238.146 >> 58.186.231.59 >> 59.8.136.21 >> 59.49.191.4 >> 59.57.68.56 >> 59.126.35.47 >> 59.126.242.70 >> 59.127.104.67 >> 59.127.242.8 >> 60.251.125.125 >> 61.219.165.38 >> 73.84.152.194 >> 78.179.113.148 >> 78.186.61.30 >> 78.189.169.142 >> 78.226.222.234 >> 79.119.74.255 >> 81.16.8.193 >> 81.101.233.14 >> 81.214.121.43 >> 81.214.134.133 >> 81.214.137.197 >> 82.77.68.189 >> 83.233.40.141 >> 85.96.202.199 >> 85.99.121.41 >> 85.238.103.111 >> 86.121.225.48 >> 87.251.252.22 >> 88.249.224.167 >> 89.122.87.239 >> 89.151.128.198 >> 90.177.91.201 >> 92.53.52.235 >> 92.55.231.90 >> 94.31.239.178 >> 94.254.41.152 >> 94.255.162.90 >> 95.78.245.54 >> 95.106.34.92 >> 95.161.236.182 >> 96.57.103.19 >> 101.0.43.13 >> 108.203.68.245 >> 110.55.108.215 >> 110.136.233.10 >> 112.133.69.176 >> 112.165.93.130 >> 112.186.42.216 >> 113.5.224.110 >> 113.161.64.11 >> 113.169.18.153 >> 113.171.98.158 >> 113.172.4.204 >> 113.183.204.112 >> 113.188.44.246 >> 114.32.28.219 >> 114.32.87.32 >> 114.32.189.5 >> 114.34.29.167 >> 114.34.170.10 >> 114.35.153.123 >> 114.226.53.133 >> 115.76.127.118 >> 116.73.65.248 >> 116.100.170.92 >> 117.0.7.77 >> 117.1.26.234 >> 117.195.254.3 >> 118.32.44.99 >> 118.42.15.21 >> 118.43.112.120 >> 118.100.64.159 >> 118.163.191.208 >> 119.199.160.207 >> 119.202.78.47 >> 120.71.215.81 >> 121.129.203.22 >> 121.178.104.129 >> 121.180.53.143 >> 122.117.245.28 >> 123.9.72.86 >> 123.16.78.77 >> 123.23.49.149 >> 123.24.108.10 >> 123.24.250.187 >> 123.25.74.209 >> 123.27.159.13 >> 123.240.245.72 >> 124.66.99.251 >> 124.131.28.38 >> 125.166.193.206 >> 125.227.138.132 >> 138.204.203.66 >> 171.97.245.221 >> 171.224.7.147 >> 171.226.20.220 >> 171.232.118.93 >> 171.248.210.120 >> 171.249.223.213 >> 171.250.26.209 >> 173.56.21.67 >> 175.138.81.130 >> 175.203.202.232 >> 175.207.137.139 >> 175.211.251.156 >> 177.207.49.108 >> 177.207.67.170 >> 177.223.52.193 >> 178.222.246.96 >> 179.4.140.63 >> 179.235.55.39 >> 179.253.163.107 >> 180.73.117.62 >> 180.254.224.10 >> 182.37.156.98 >> 182.180.80.75 >> 182.180.123.43 >> 183.46.49.216 >> 183.144.245.235 >> 186.19.48.158 >> 186.69.170.130 >> 186.219.1.156 >> 187.104.248.17 >> 187.211.63.51 >> 188.209.153.15 >> 189.101.220.244 >> 189.234.9.147 >> 191.103.35.250 >> 191.180.198.31 >> 191.249.21.41 >> 196.207.83.23 >> 197.224.37.108 >> 201.243.225.103 >> 210.178.250.121 >> 211.7.146.51 >> 211.216.202.191 >> 213.5.216.213 >> 213.14.195.100 >> 213.170.76.149 >> 217.129.243.48 >> 218.161.121.178 >> 218.186.43.224 >> 220.85.169.133 >> 220.132.111.124 >> 220.133.24.142 >> 220.133.198.71 >> 220.133.234.229 >> 220.134.132.200 >> 220.134.193.133 >> 220.135.64.43 >> 221.145.147.78 >> 221.159.105.17 >> 221.167.64.53 >> 222.254.238.188 >> 223.154.223.159 > From nanog at ics-il.net Wed Nov 16 17:38:44 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 16 Nov 2016 11:38:44 -0600 (CST) Subject: Port 2323/tcp In-Reply-To: References: <7cc32d8c-759b-1f6d-326f-dbde57187d20@satchell.net> Message-ID: <1104972441.2255.1479317923404.JavaMail.mhammett@ThunderFuck> Probably best to go with A) what we could do in the best of situations and B) what the rest will do. Some of us are last mile networks and *DO* care. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mel Beckman" To: list at satchell.net Cc: nanog at nanog.org Sent: Wednesday, November 16, 2016 11:25:34 AM Subject: Re: Port 2323/tcp It's pretty much part of the IBR now. And what can a provider do, really? It's not likely he will expend much effort blocking customers. Maybe we should all start filtering 2323? -mel via cell > On Nov 16, 2016, at 11:53 AM, Stephen Satchell wrote: > > I've been seeing a lot of rejections in my logs for 2323/tcp. According > to the Storm Center, this is what the Mirai botnet scanner uses to look > for other target devices. > > Is it worthwhile to report sightings to the appropriate abuse addresses? > (That assumes there *is* an abuse address associated with the IPv4 > address that is the source.) Would administrations receiving these > notices do anything with them? > > Alternatively, is there anyone collecting this information from people > like me to expose the IP addresses of possible infections? > > I am toying with the idea of setting up a honey-pot, but I'm so far > behind with $DAYJOB that such a project will have to wait a bit. > > I want to be a good net citizen. I also want to make sure I'm not > wasting my time. > > Today's crop: > >> 1.34.169.183 >> 12.221.236.2 >> 14.138.22.12 >> 14.169.142.30 >> 14.174.71.158 >> 14.177.197.101 >> 31.168.146.33 >> 31.168.212.174 >> 36.71.224.179 >> 36.72.253.206 >> 37.106.18.86 >> 42.115.187.189 >> 42.117.254.248 >> 42.119.228.222 >> 43.225.195.180 >> 46.59.6.249 >> 49.114.192.91 >> 58.11.238.146 >> 58.186.231.59 >> 59.8.136.21 >> 59.49.191.4 >> 59.57.68.56 >> 59.126.35.47 >> 59.126.242.70 >> 59.127.104.67 >> 59.127.242.8 >> 60.251.125.125 >> 61.219.165.38 >> 73.84.152.194 >> 78.179.113.148 >> 78.186.61.30 >> 78.189.169.142 >> 78.226.222.234 >> 79.119.74.255 >> 81.16.8.193 >> 81.101.233.14 >> 81.214.121.43 >> 81.214.134.133 >> 81.214.137.197 >> 82.77.68.189 >> 83.233.40.141 >> 85.96.202.199 >> 85.99.121.41 >> 85.238.103.111 >> 86.121.225.48 >> 87.251.252.22 >> 88.249.224.167 >> 89.122.87.239 >> 89.151.128.198 >> 90.177.91.201 >> 92.53.52.235 >> 92.55.231.90 >> 94.31.239.178 >> 94.254.41.152 >> 94.255.162.90 >> 95.78.245.54 >> 95.106.34.92 >> 95.161.236.182 >> 96.57.103.19 >> 101.0.43.13 >> 108.203.68.245 >> 110.55.108.215 >> 110.136.233.10 >> 112.133.69.176 >> 112.165.93.130 >> 112.186.42.216 >> 113.5.224.110 >> 113.161.64.11 >> 113.169.18.153 >> 113.171.98.158 >> 113.172.4.204 >> 113.183.204.112 >> 113.188.44.246 >> 114.32.28.219 >> 114.32.87.32 >> 114.32.189.5 >> 114.34.29.167 >> 114.34.170.10 >> 114.35.153.123 >> 114.226.53.133 >> 115.76.127.118 >> 116.73.65.248 >> 116.100.170.92 >> 117.0.7.77 >> 117.1.26.234 >> 117.195.254.3 >> 118.32.44.99 >> 118.42.15.21 >> 118.43.112.120 >> 118.100.64.159 >> 118.163.191.208 >> 119.199.160.207 >> 119.202.78.47 >> 120.71.215.81 >> 121.129.203.22 >> 121.178.104.129 >> 121.180.53.143 >> 122.117.245.28 >> 123.9.72.86 >> 123.16.78.77 >> 123.23.49.149 >> 123.24.108.10 >> 123.24.250.187 >> 123.25.74.209 >> 123.27.159.13 >> 123.240.245.72 >> 124.66.99.251 >> 124.131.28.38 >> 125.166.193.206 >> 125.227.138.132 >> 138.204.203.66 >> 171.97.245.221 >> 171.224.7.147 >> 171.226.20.220 >> 171.232.118.93 >> 171.248.210.120 >> 171.249.223.213 >> 171.250.26.209 >> 173.56.21.67 >> 175.138.81.130 >> 175.203.202.232 >> 175.207.137.139 >> 175.211.251.156 >> 177.207.49.108 >> 177.207.67.170 >> 177.223.52.193 >> 178.222.246.96 >> 179.4.140.63 >> 179.235.55.39 >> 179.253.163.107 >> 180.73.117.62 >> 180.254.224.10 >> 182.37.156.98 >> 182.180.80.75 >> 182.180.123.43 >> 183.46.49.216 >> 183.144.245.235 >> 186.19.48.158 >> 186.69.170.130 >> 186.219.1.156 >> 187.104.248.17 >> 187.211.63.51 >> 188.209.153.15 >> 189.101.220.244 >> 189.234.9.147 >> 191.103.35.250 >> 191.180.198.31 >> 191.249.21.41 >> 196.207.83.23 >> 197.224.37.108 >> 201.243.225.103 >> 210.178.250.121 >> 211.7.146.51 >> 211.216.202.191 >> 213.5.216.213 >> 213.14.195.100 >> 213.170.76.149 >> 217.129.243.48 >> 218.161.121.178 >> 218.186.43.224 >> 220.85.169.133 >> 220.132.111.124 >> 220.133.24.142 >> 220.133.198.71 >> 220.133.234.229 >> 220.134.132.200 >> 220.134.193.133 >> 220.135.64.43 >> 221.145.147.78 >> 221.159.105.17 >> 221.167.64.53 >> 222.254.238.188 >> 223.154.223.159 > From carl at five-ten-sg.com Sun Nov 13 17:33:14 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Sun, 13 Nov 2016 09:33:14 -0800 Subject: pay.gov and IPv6 Message-ID: <1479058394.7406.9.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Following up on a two year old thread, one of my clients just hit this problem. The failure is not that www.pay.gov is not reachable over ipv6 (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 connection, but the connection then hangs waiting for the TLS handshake. openssl s_client -connect www.pay.gov:443 openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 Browsers (at least firefox) see that as a very slow site, and it does not trigger their happy eyeballs fast failover to ipv4. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgoo9AACgkQL6j7milTFsEIhwCfS2nVWDwjGk5LLaPpAntLC8la RpMAniYdP2OmTcx4+lJmaIu538LK9pqJ =SOdT -----END PGP SIGNATURE----- From jeremyp at gmx.us Mon Nov 14 00:49:29 2016 From: jeremyp at gmx.us (Jeremy Parsons) Date: Mon, 14 Nov 2016 01:49:29 +0100 Subject: 198.154.60.0/22 bogon/hijacked? Message-ID: From carl at five-ten-sg.com Tue Nov 15 22:30:03 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Tue, 15 Nov 2016 14:30:03 -0800 Subject: pay.gov and IPv6 Message-ID: <1479249003.3937.6.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Following up on a two year old thread, one of my clients just hit this problem. The failure is not that www.pay.gov is not reachable over ipv6 (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 connection, but the connection then hangs waiting for the TLS handshake. openssl s_client -connect www.pay.gov:443 openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 Browsers (at least firefox) see that as a very slow site, and it does not trigger their happy eyeballs fast failover to ipv4. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC =MS8j -----END PGP SIGNATURE----- From omonnig at gmail.com Wed Nov 16 18:12:50 2016 From: omonnig at gmail.com (Otto Monnig) Date: Wed, 16 Nov 2016 12:12:50 -0600 Subject: Port 2323/tcp In-Reply-To: <7cc32d8c-759b-1f6d-326f-dbde57187d20@satchell.net> References: <7cc32d8c-759b-1f6d-326f-dbde57187d20@satchell.net> Message-ID: We?ve been monitoring/logging/blocking ports 23 and 2323 at our site for the past several weeks, after remediating a 60-75 Mbps attack on a 100 Mbps fiber feed. On port 23, we have accumulated 377,319 different IP addresses hitting our systems. For port 2323, 42,913 different IP addresses. The addresses are widely distributed, making aggregation nearly impossible. Below is a list of offending subnets, ranked by number of offenders (powers of 2), sorry for the length. 14.0.0.0/8 16384 78.0.0.0/8 8192 113.0.0.0/8 8192 117.0.0.0/8 8192 122.0.0.0/8 8192 177.0.0.0/8 8192 179.0.0.0/8 8192 186.0.0.0/8 8192 187.0.0.0/8 8192 189.0.0.0/8 8192 190.0.0.0/8 8192 201.0.0.0/8 8192 1.0.0.0/8 4096 5.0.0.0/8 4096 27.0.0.0/8 4096 36.0.0.0/8 4096 37.0.0.0/8 4096 41.0.0.0/8 4096 42.0.0.0/8 4096 46.0.0.0/8 4096 49.0.0.0/8 4096 59.0.0.0/8 4096 79.0.0.0/8 4096 82.0.0.0/8 4096 88.0.0.0/8 4096 89.0.0.0/8 4096 95.0.0.0/8 4096 109.0.0.0/8 4096 110.0.0.0/8 4096 112.0.0.0/8 4096 114.0.0.0/8 4096 116.0.0.0/8 4096 118.0.0.0/8 4096 119.0.0.0/8 4096 121.0.0.0/8 4096 123.0.0.0/8 4096 124.0.0.0/8 4096 171.0.0.0/8 4096 175.0.0.0/8 4096 176.0.0.0/8 4096 178.0.0.0/8 4096 180.0.0.0/8 4096 181.0.0.0/8 4096 182.0.0.0/8 4096 183.0.0.0/8 4096 191.0.0.0/8 4096 200.0.0.0/8 4096 220.0.0.0/8 4096 31.0.0.0/8 2048 58.0.0.0/8 2048 60.0.0.0/8 2048 61.0.0.0/8 2048 77.0.0.0/8 2048 80.0.0.0/8 2048 81.0.0.0/8 2048 83.0.0.0/8 2048 85.0.0.0/8 2048 86.0.0.0/8 2048 87.0.0.0/8 2048 91.0.0.0/8 2048 92.0.0.0/8 2048 93.0.0.0/8 2048 94.0.0.0/8 2048 103.0.0.0/8 2048 111.0.0.0/8 2048 115.0.0.0/8 2048 120.0.0.0/8 2048 125.0.0.0/8 2048 151.0.0.0/8 2048 188.0.0.0/8 2048 213.0.0.0/8 2048 218.0.0.0/8 2048 222.0.0.0/8 2048 223.0.0.0/8 2048 3.0.0.0/8 1024 6.0.0.0/8 1024 7.0.0.0/8 1024 9.0.0.0/8 1024 11.0.0.0/8 1024 15.0.0.0/8 1024 16.0.0.0/8 1024 17.0.0.0/8 1024 19.0.0.0/8 1024 20.0.0.0/8 1024 21.0.0.0/8 1024 22.0.0.0/8 1024 24.0.0.0/8 1024 25.0.0.0/8 1024 26.0.0.0/8 1024 28.0.0.0/8 1024 29.0.0.0/8 1024 30.0.0.0/8 1024 33.0.0.0/8 1024 34.0.0.0/8 1024 39.0.0.0/8 1024 44.0.0.0/8 1024 48.0.0.0/8 1024 53.0.0.0/8 1024 55.0.0.0/8 1024 56.0.0.0/8 1024 57.0.0.0/8 1024 62.0.0.0/8 1024 84.0.0.0/8 1024 101.0.0.0/8 1024 102.0.0.0/8 1024 106.0.0.0/8 1024 185.0.0.0/8 1024 193.0.0.0/8 1024 194.0.0.0/8 1024 195.0.0.0/8 1024 197.0.0.0/8 1024 202.0.0.0/8 1024 203.0.0.0/8 1024 210.0.0.0/8 1024 211.0.0.0/8 1024 212.0.0.0/8 1024 214.0.0.0/8 1024 215.0.0.0/8 1024 217.0.0.0/8 1024 219.0.0.0/8 1024 221.0.0.0/8 1024 2.0.0.0/8 512 43.0.0.0/8 512 45.0.0.0/8 512 47.0.0.0/8 512 50.0.0.0/8 512 70.0.0.0/8 512 71.0.0.0/8 512 72.0.0.0/8 512 73.0.0.0/8 512 90.0.0.0/8 512 96.0.0.0/8 512 105.0.0.0/8 512 108.0.0.0/8 512 134.0.0.0/8 512 138.0.0.0/8 512 139.0.0.0/8 512 152.0.0.0/8 512 167.0.0.0/8 512 173.0.0.0/8 512 64.0.0.0/8 256 66.0.0.0/8 256 67.0.0.0/8 256 68.0.0.0/8 256 69.0.0.0/8 256 74.0.0.0/8 256 75.0.0.0/8 256 76.0.0.0/8 256 98.0.0.0/8 256 104.0.0.0/8 256 150.0.0.0/8 256 159.0.0.0/8 256 168.0.0.0/8 256 174.0.0.0/8 256 192.0.0.0/8 256 196.0.0.0/8 256 216.0.0.0/8 256 23.0.0.0/8 128 65.0.0.0/8 128 97.0.0.0/8 128 100.0.0.0/8 128 107.0.0.0/8 128 128.0.0.0/8 128 130.0.0.0/8 128 131.0.0.0/8 128 140.0.0.0/8 128 141.0.0.0/8 128 149.0.0.0/8 128 153.0.0.0/8 128 154.0.0.0/8 128 160.0.0.0/8 128 161.0.0.0/8 128 162.0.0.0/8 128 163.0.0.0/8 128 170.0.0.0/8 128 172.0.0.0/8 128 184.0.0.0/8 128 198.0.0.0/8 128 207.0.0.0/8 128 208.0.0.0/8 128 209.0.0.0/8 128 4.0.0.0/8 64 8.0.0.0/8 64 12.0.0.0/8 64 13.0.0.0/8 64 18.0.0.0/8 64 32.0.0.0/8 64 35.0.0.0/8 64 38.0.0.0/8 64 40.0.0.0/8 64 51.0.0.0/8 64 52.0.0.0/8 64 54.0.0.0/8 64 63.0.0.0/8 64 99.0.0.0/8 64 10122.0.0.0/8 64 11122.0.0.0/8 64 114122.0.0.0/8 64 126.0.0.0/8 64 129.0.0.0/8 64 132.0.0.0/8 64 133.0.0.0/8 64 135.0.0.0/8 64 136.0.0.0/8 64 137.0.0.0/8 64 142.0.0.0/8 64 143.0.0.0/8 64 144.0.0.0/8 64 145.0.0.0/8 64 146.0.0.0/8 64 147.0.0.0/8 64 148.0.0.0/8 64 155.0.0.0/8 64 156.0.0.0/8 64 157.0.0.0/8 64 158.0.0.0/8 64 164.0.0.0/8 64 165.0.0.0/8 64 166.0.0.0/8 64 169.0.0.0/8 64 199.0.0.0/8 64 204.0.0.0/8 64 205.0.0.0/8 64 206.0.0.0/8 64 Total 375232 -- Otto Monnig omonnig at gmail.com > On Nov 16, 2016, at 10:52 AM, Stephen Satchell wrote: > > I've been seeing a lot of rejections in my logs for 2323/tcp. According > to the Storm Center, this is what the Mirai botnet scanner uses to look > for other target devices. > > Is it worthwhile to report sightings to the appropriate abuse addresses? > (That assumes there *is* an abuse address associated with the IPv4 > address that is the source.) Would administrations receiving these > notices do anything with them? > > Alternatively, is there anyone collecting this information from people > like me to expose the IP addresses of possible infections? > > I am toying with the idea of setting up a honey-pot, but I'm so far > behind with $DAYJOB that such a project will have to wait a bit. > > I want to be a good net citizen. I also want to make sure I'm not > wasting my time. > > Today's crop: > >> 1.34.169.183 >> 12.221.236.2 >> 14.138.22.12 >> 14.169.142.30 >> 14.174.71.158 >> 14.177.197.101 >> 31.168.146.33 >> 31.168.212.174 >> 36.71.224.179 >> 36.72.253.206 >> 37.106.18.86 >> 42.115.187.189 >> 42.117.254.248 >> 42.119.228.222 >> 43.225.195.180 >> 46.59.6.249 >> 49.114.192.91 >> 58.11.238.146 >> 58.186.231.59 >> 59.8.136.21 >> 59.49.191.4 >> 59.57.68.56 >> 59.126.35.47 >> 59.126.242.70 >> 59.127.104.67 >> 59.127.242.8 >> 60.251.125.125 >> 61.219.165.38 >> 73.84.152.194 >> 78.179.113.148 >> 78.186.61.30 >> 78.189.169.142 >> 78.226.222.234 >> 79.119.74.255 >> 81.16.8.193 >> 81.101.233.14 >> 81.214.121.43 >> 81.214.134.133 >> 81.214.137.197 >> 82.77.68.189 >> 83.233.40.141 >> 85.96.202.199 >> 85.99.121.41 >> 85.238.103.111 >> 86.121.225.48 >> 87.251.252.22 >> 88.249.224.167 >> 89.122.87.239 >> 89.151.128.198 >> 90.177.91.201 >> 92.53.52.235 >> 92.55.231.90 >> 94.31.239.178 >> 94.254.41.152 >> 94.255.162.90 >> 95.78.245.54 >> 95.106.34.92 >> 95.161.236.182 >> 96.57.103.19 >> 101.0.43.13 >> 108.203.68.245 >> 110.55.108.215 >> 110.136.233.10 >> 112.133.69.176 >> 112.165.93.130 >> 112.186.42.216 >> 113.5.224.110 >> 113.161.64.11 >> 113.169.18.153 >> 113.171.98.158 >> 113.172.4.204 >> 113.183.204.112 >> 113.188.44.246 >> 114.32.28.219 >> 114.32.87.32 >> 114.32.189.5 >> 114.34.29.167 >> 114.34.170.10 >> 114.35.153.123 >> 114.226.53.133 >> 115.76.127.118 >> 116.73.65.248 >> 116.100.170.92 >> 117.0.7.77 >> 117.1.26.234 >> 117.195.254.3 >> 118.32.44.99 >> 118.42.15.21 >> 118.43.112.120 >> 118.100.64.159 >> 118.163.191.208 >> 119.199.160.207 >> 119.202.78.47 >> 120.71.215.81 >> 121.129.203.22 >> 121.178.104.129 >> 121.180.53.143 >> 122.117.245.28 >> 123.9.72.86 >> 123.16.78.77 >> 123.23.49.149 >> 123.24.108.10 >> 123.24.250.187 >> 123.25.74.209 >> 123.27.159.13 >> 123.240.245.72 >> 124.66.99.251 >> 124.131.28.38 >> 125.166.193.206 >> 125.227.138.132 >> 138.204.203.66 >> 171.97.245.221 >> 171.224.7.147 >> 171.226.20.220 >> 171.232.118.93 >> 171.248.210.120 >> 171.249.223.213 >> 171.250.26.209 >> 173.56.21.67 >> 175.138.81.130 >> 175.203.202.232 >> 175.207.137.139 >> 175.211.251.156 >> 177.207.49.108 >> 177.207.67.170 >> 177.223.52.193 >> 178.222.246.96 >> 179.4.140.63 >> 179.235.55.39 >> 179.253.163.107 >> 180.73.117.62 >> 180.254.224.10 >> 182.37.156.98 >> 182.180.80.75 >> 182.180.123.43 >> 183.46.49.216 >> 183.144.245.235 >> 186.19.48.158 >> 186.69.170.130 >> 186.219.1.156 >> 187.104.248.17 >> 187.211.63.51 >> 188.209.153.15 >> 189.101.220.244 >> 189.234.9.147 >> 191.103.35.250 >> 191.180.198.31 >> 191.249.21.41 >> 196.207.83.23 >> 197.224.37.108 >> 201.243.225.103 >> 210.178.250.121 >> 211.7.146.51 >> 211.216.202.191 >> 213.5.216.213 >> 213.14.195.100 >> 213.170.76.149 >> 217.129.243.48 >> 218.161.121.178 >> 218.186.43.224 >> 220.85.169.133 >> 220.132.111.124 >> 220.133.24.142 >> 220.133.198.71 >> 220.133.234.229 >> 220.134.132.200 >> 220.134.193.133 >> 220.135.64.43 >> 221.145.147.78 >> 221.159.105.17 >> 221.167.64.53 >> 222.254.238.188 >> 223.154.223.159 > From ahebert at pubnix.net Wed Nov 16 18:19:23 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 16 Nov 2016 13:19:23 -0500 Subject: 198.154.60.0/22 bogon/hijacked? In-Reply-To: References: Message-ID: Hum, Its a 6 weeks old entries in my routers. Even "oddish" its 26272 coming of GTT & HE. 26272 is unassigned at ARIN. ------ My experience with GTT & HE find it curious that they let that happen. ----- 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 11/13/16 19:49, Jeremy Parsons wrote: From savage at savage.za.org Wed Nov 16 18:19:42 2016 From: savage at savage.za.org (Chris Knipe) Date: Wed, 16 Nov 2016 20:19:42 +0200 Subject: Port 2323/tcp In-Reply-To: References: <7cc32d8c-759b-1f6d-326f-dbde57187d20@satchell.net> Message-ID: We have actively started to block 23/tcp to our customer's CPEs.... Huge amounts of connection attempts / scans over our prefixes. All IPv4, zero on IPv6 (not yet at least). On Wed, Nov 16, 2016 at 8:12 PM, Otto Monnig wrote: > We?ve been monitoring/logging/blocking ports 23 and 2323 at our site for > the past several weeks, after remediating a 60-75 Mbps attack on a 100 Mbps > fiber feed. > > On port 23, we have accumulated 377,319 different IP addresses hitting our > systems. For port 2323, 42,913 different IP addresses. > > The addresses are widely distributed, making aggregation nearly impossible. > > Below is a list of offending subnets, ranked by number of offenders > (powers of 2), sorry for the length. > > 14.0.0.0/8 16384 > 78.0.0.0/8 8192 > 113.0.0.0/8 8192 > 117.0.0.0/8 8192 > 122.0.0.0/8 8192 > 177.0.0.0/8 8192 > 179.0.0.0/8 8192 > 186.0.0.0/8 8192 > 187.0.0.0/8 8192 > 189.0.0.0/8 8192 > 190.0.0.0/8 8192 > 201.0.0.0/8 8192 > 1.0.0.0/8 4096 > 5.0.0.0/8 4096 > 27.0.0.0/8 4096 > 36.0.0.0/8 4096 > 37.0.0.0/8 4096 > 41.0.0.0/8 4096 > 42.0.0.0/8 4096 > 46.0.0.0/8 4096 > 49.0.0.0/8 4096 > 59.0.0.0/8 4096 > 79.0.0.0/8 4096 > 82.0.0.0/8 4096 > 88.0.0.0/8 4096 > 89.0.0.0/8 4096 > 95.0.0.0/8 4096 > 109.0.0.0/8 4096 > 110.0.0.0/8 4096 > 112.0.0.0/8 4096 > 114.0.0.0/8 4096 > 116.0.0.0/8 4096 > 118.0.0.0/8 4096 > 119.0.0.0/8 4096 > 121.0.0.0/8 4096 > 123.0.0.0/8 4096 > 124.0.0.0/8 4096 > 171.0.0.0/8 4096 > 175.0.0.0/8 4096 > 176.0.0.0/8 4096 > 178.0.0.0/8 4096 > 180.0.0.0/8 4096 > 181.0.0.0/8 4096 > 182.0.0.0/8 4096 > 183.0.0.0/8 4096 > 191.0.0.0/8 4096 > 200.0.0.0/8 4096 > 220.0.0.0/8 4096 > 31.0.0.0/8 2048 > 58.0.0.0/8 2048 > 60.0.0.0/8 2048 > 61.0.0.0/8 2048 > 77.0.0.0/8 2048 > 80.0.0.0/8 2048 > 81.0.0.0/8 2048 > 83.0.0.0/8 2048 > 85.0.0.0/8 2048 > 86.0.0.0/8 2048 > 87.0.0.0/8 2048 > 91.0.0.0/8 2048 > 92.0.0.0/8 2048 > 93.0.0.0/8 2048 > 94.0.0.0/8 2048 > 103.0.0.0/8 2048 > 111.0.0.0/8 2048 > 115.0.0.0/8 2048 > 120.0.0.0/8 2048 > 125.0.0.0/8 2048 > 151.0.0.0/8 2048 > 188.0.0.0/8 2048 > 213.0.0.0/8 2048 > 218.0.0.0/8 2048 > 222.0.0.0/8 2048 > 223.0.0.0/8 2048 > 3.0.0.0/8 1024 > 6.0.0.0/8 1024 > 7.0.0.0/8 1024 > 9.0.0.0/8 1024 > 11.0.0.0/8 1024 > 15.0.0.0/8 1024 > 16.0.0.0/8 1024 > 17.0.0.0/8 1024 > 19.0.0.0/8 1024 > 20.0.0.0/8 1024 > 21.0.0.0/8 1024 > 22.0.0.0/8 1024 > 24.0.0.0/8 1024 > 25.0.0.0/8 1024 > 26.0.0.0/8 1024 > 28.0.0.0/8 1024 > 29.0.0.0/8 1024 > 30.0.0.0/8 1024 > 33.0.0.0/8 1024 > 34.0.0.0/8 1024 > 39.0.0.0/8 1024 > 44.0.0.0/8 1024 > 48.0.0.0/8 1024 > 53.0.0.0/8 1024 > 55.0.0.0/8 1024 > 56.0.0.0/8 1024 > 57.0.0.0/8 1024 > 62.0.0.0/8 1024 > 84.0.0.0/8 1024 > 101.0.0.0/8 1024 > 102.0.0.0/8 1024 > 106.0.0.0/8 1024 > 185.0.0.0/8 1024 > 193.0.0.0/8 1024 > 194.0.0.0/8 1024 > 195.0.0.0/8 1024 > 197.0.0.0/8 1024 > 202.0.0.0/8 1024 > 203.0.0.0/8 1024 > 210.0.0.0/8 1024 > 211.0.0.0/8 1024 > 212.0.0.0/8 1024 > 214.0.0.0/8 1024 > 215.0.0.0/8 1024 > 217.0.0.0/8 1024 > 219.0.0.0/8 1024 > 221.0.0.0/8 1024 > 2.0.0.0/8 512 > 43.0.0.0/8 512 > 45.0.0.0/8 512 > 47.0.0.0/8 512 > 50.0.0.0/8 512 > 70.0.0.0/8 512 > 71.0.0.0/8 512 > 72.0.0.0/8 512 > 73.0.0.0/8 512 > 90.0.0.0/8 512 > 96.0.0.0/8 512 > 105.0.0.0/8 512 > 108.0.0.0/8 512 > 134.0.0.0/8 512 > 138.0.0.0/8 512 > 139.0.0.0/8 512 > 152.0.0.0/8 512 > 167.0.0.0/8 512 > 173.0.0.0/8 512 > 64.0.0.0/8 256 > 66.0.0.0/8 256 > 67.0.0.0/8 256 > 68.0.0.0/8 256 > 69.0.0.0/8 256 > 74.0.0.0/8 256 > 75.0.0.0/8 256 > 76.0.0.0/8 256 > 98.0.0.0/8 256 > 104.0.0.0/8 256 > 150.0.0.0/8 256 > 159.0.0.0/8 256 > 168.0.0.0/8 256 > 174.0.0.0/8 256 > 192.0.0.0/8 256 > 196.0.0.0/8 256 > 216.0.0.0/8 256 > 23.0.0.0/8 128 > 65.0.0.0/8 128 > 97.0.0.0/8 128 > 100.0.0.0/8 128 > 107.0.0.0/8 128 > 128.0.0.0/8 128 > 130.0.0.0/8 128 > 131.0.0.0/8 128 > 140.0.0.0/8 128 > 141.0.0.0/8 128 > 149.0.0.0/8 128 > 153.0.0.0/8 128 > 154.0.0.0/8 128 > 160.0.0.0/8 128 > 161.0.0.0/8 128 > 162.0.0.0/8 128 > 163.0.0.0/8 128 > 170.0.0.0/8 128 > 172.0.0.0/8 128 > 184.0.0.0/8 128 > 198.0.0.0/8 128 > 207.0.0.0/8 128 > 208.0.0.0/8 128 > 209.0.0.0/8 128 > 4.0.0.0/8 64 > 8.0.0.0/8 64 > 12.0.0.0/8 64 > 13.0.0.0/8 64 > 18.0.0.0/8 64 > 32.0.0.0/8 64 > 35.0.0.0/8 64 > 38.0.0.0/8 64 > 40.0.0.0/8 64 > 51.0.0.0/8 64 > 52.0.0.0/8 64 > 54.0.0.0/8 64 > 63.0.0.0/8 64 > 99.0.0.0/8 64 > 10122.0.0.0/8 64 > 11122.0.0.0/8 64 > 114122.0.0.0/8 64 > 126.0.0.0/8 64 > 129.0.0.0/8 64 > 132.0.0.0/8 64 > 133.0.0.0/8 64 > 135.0.0.0/8 64 > 136.0.0.0/8 64 > 137.0.0.0/8 64 > 142.0.0.0/8 64 > 143.0.0.0/8 64 > 144.0.0.0/8 64 > 145.0.0.0/8 64 > 146.0.0.0/8 64 > 147.0.0.0/8 64 > 148.0.0.0/8 64 > 155.0.0.0/8 64 > 156.0.0.0/8 64 > 157.0.0.0/8 64 > 158.0.0.0/8 64 > 164.0.0.0/8 64 > 165.0.0.0/8 64 > 166.0.0.0/8 64 > 169.0.0.0/8 64 > 199.0.0.0/8 64 > 204.0.0.0/8 64 > 205.0.0.0/8 64 > 206.0.0.0/8 64 > > Total > 375232 > > -- > Otto Monnig > omonnig at gmail.com > > > > > On Nov 16, 2016, at 10:52 AM, Stephen Satchell > wrote: > > > > I've been seeing a lot of rejections in my logs for 2323/tcp. According > > to the Storm Center, this is what the Mirai botnet scanner uses to look > > for other target devices. > > > > Is it worthwhile to report sightings to the appropriate abuse addresses? > > (That assumes there *is* an abuse address associated with the IPv4 > > address that is the source.) Would administrations receiving these > > notices do anything with them? > > > > Alternatively, is there anyone collecting this information from people > > like me to expose the IP addresses of possible infections? > > > > I am toying with the idea of setting up a honey-pot, but I'm so far > > behind with $DAYJOB that such a project will have to wait a bit. > > > > I want to be a good net citizen. I also want to make sure I'm not > > wasting my time. > > > > Today's crop: > > > >> 1.34.169.183 > >> 12.221.236.2 > >> 14.138.22.12 > >> 14.169.142.30 > >> 14.174.71.158 > >> 14.177.197.101 > >> 31.168.146.33 > >> 31.168.212.174 > >> 36.71.224.179 > >> 36.72.253.206 > >> 37.106.18.86 > >> 42.115.187.189 > >> 42.117.254.248 > >> 42.119.228.222 > >> 43.225.195.180 > >> 46.59.6.249 > >> 49.114.192.91 > >> 58.11.238.146 > >> 58.186.231.59 > >> 59.8.136.21 > >> 59.49.191.4 > >> 59.57.68.56 > >> 59.126.35.47 > >> 59.126.242.70 > >> 59.127.104.67 > >> 59.127.242.8 > >> 60.251.125.125 > >> 61.219.165.38 > >> 73.84.152.194 > >> 78.179.113.148 > >> 78.186.61.30 > >> 78.189.169.142 > >> 78.226.222.234 > >> 79.119.74.255 > >> 81.16.8.193 > >> 81.101.233.14 > >> 81.214.121.43 > >> 81.214.134.133 > >> 81.214.137.197 > >> 82.77.68.189 > >> 83.233.40.141 > >> 85.96.202.199 > >> 85.99.121.41 > >> 85.238.103.111 > >> 86.121.225.48 > >> 87.251.252.22 > >> 88.249.224.167 > >> 89.122.87.239 > >> 89.151.128.198 > >> 90.177.91.201 > >> 92.53.52.235 > >> 92.55.231.90 > >> 94.31.239.178 > >> 94.254.41.152 > >> 94.255.162.90 > >> 95.78.245.54 > >> 95.106.34.92 > >> 95.161.236.182 > >> 96.57.103.19 > >> 101.0.43.13 > >> 108.203.68.245 > >> 110.55.108.215 > >> 110.136.233.10 > >> 112.133.69.176 > >> 112.165.93.130 > >> 112.186.42.216 > >> 113.5.224.110 > >> 113.161.64.11 > >> 113.169.18.153 > >> 113.171.98.158 > >> 113.172.4.204 > >> 113.183.204.112 > >> 113.188.44.246 > >> 114.32.28.219 > >> 114.32.87.32 > >> 114.32.189.5 > >> 114.34.29.167 > >> 114.34.170.10 > >> 114.35.153.123 > >> 114.226.53.133 > >> 115.76.127.118 > >> 116.73.65.248 > >> 116.100.170.92 > >> 117.0.7.77 > >> 117.1.26.234 > >> 117.195.254.3 > >> 118.32.44.99 > >> 118.42.15.21 > >> 118.43.112.120 > >> 118.100.64.159 > >> 118.163.191.208 > >> 119.199.160.207 > >> 119.202.78.47 > >> 120.71.215.81 > >> 121.129.203.22 > >> 121.178.104.129 > >> 121.180.53.143 > >> 122.117.245.28 > >> 123.9.72.86 > >> 123.16.78.77 > >> 123.23.49.149 > >> 123.24.108.10 > >> 123.24.250.187 > >> 123.25.74.209 > >> 123.27.159.13 > >> 123.240.245.72 > >> 124.66.99.251 > >> 124.131.28.38 > >> 125.166.193.206 > >> 125.227.138.132 > >> 138.204.203.66 > >> 171.97.245.221 > >> 171.224.7.147 > >> 171.226.20.220 > >> 171.232.118.93 > >> 171.248.210.120 > >> 171.249.223.213 > >> 171.250.26.209 > >> 173.56.21.67 > >> 175.138.81.130 > >> 175.203.202.232 > >> 175.207.137.139 > >> 175.211.251.156 > >> 177.207.49.108 > >> 177.207.67.170 > >> 177.223.52.193 > >> 178.222.246.96 > >> 179.4.140.63 > >> 179.235.55.39 > >> 179.253.163.107 > >> 180.73.117.62 > >> 180.254.224.10 > >> 182.37.156.98 > >> 182.180.80.75 > >> 182.180.123.43 > >> 183.46.49.216 > >> 183.144.245.235 > >> 186.19.48.158 > >> 186.69.170.130 > >> 186.219.1.156 > >> 187.104.248.17 > >> 187.211.63.51 > >> 188.209.153.15 > >> 189.101.220.244 > >> 189.234.9.147 > >> 191.103.35.250 > >> 191.180.198.31 > >> 191.249.21.41 > >> 196.207.83.23 > >> 197.224.37.108 > >> 201.243.225.103 > >> 210.178.250.121 > >> 211.7.146.51 > >> 211.216.202.191 > >> 213.5.216.213 > >> 213.14.195.100 > >> 213.170.76.149 > >> 217.129.243.48 > >> 218.161.121.178 > >> 218.186.43.224 > >> 220.85.169.133 > >> 220.132.111.124 > >> 220.133.24.142 > >> 220.133.198.71 > >> 220.133.234.229 > >> 220.134.132.200 > >> 220.134.193.133 > >> 220.135.64.43 > >> 221.145.147.78 > >> 221.159.105.17 > >> 221.167.64.53 > >> 222.254.238.188 > >> 223.154.223.159 > > > > -- Regards, Chris Knipe From wilhelm at ripe.net Wed Nov 16 18:40:52 2016 From: wilhelm at ripe.net (Rene Wilhelm) Date: Wed, 16 Nov 2016 19:40:52 +0100 Subject: 198.154.60.0/22 bogon/hijacked? In-Reply-To: References: Message-ID: Looks likeAS26272 and 198.154.60.0/22 have been deregistered about a week ago. In ARIN delegation statistics from Nov 8, ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20161108 these are listed as assigned and allocated but in later files that changed to 'reserved'. RIPEstat shows 198.154.60.0/22 has been in the routing system with origin AS26272 since October 2012. https://stat.ripe.net/widget/routing-history#w.resource=198.154.60.0/22 -- Rene On 11/16/16 7:19 PM, Alain Hebert wrote: > Hum, > > Its a 6 weeks old entries in my routers. > > Even "oddish" its 26272 coming of GTT & HE. > > 26272 is unassigned at ARIN. > > ------ > > My experience with GTT & HE find it curious that they let that happen. > > ----- > 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 11/13/16 19:49, Jeremy Parsons wrote: > > From marka at isc.org Wed Nov 16 20:23:57 2016 From: marka at isc.org (Mark Andrews) Date: Thu, 17 Nov 2016 07:23:57 +1100 Subject: pay.gov and IPv6 In-Reply-To: Your message of "Tue, 15 Nov 2016 14:30:03 -0800." <1479249003.3937.6.camel@ns.five-ten-sg.com> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> Message-ID: <20161116202357.4096B5A4FCB4@rock.dv.isc.org> In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl Byington writes : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Following up on a two year old thread, one of my clients just hit this > problem. The failure is not that www.pay.gov is not reachable over ipv6 > (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > connection, but the connection then hangs waiting for the TLS handshake. > > openssl s_client -connect www.pay.gov:443 > > openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > > Browsers (at least firefox) see that as a very slow site, and it does > not trigger their happy eyeballs fast failover to ipv4. Happy eyeballs is about making the connection not whether TCP connections work after the initial packet exchange. I would send a physical letter to the relevent Inspector General requesting that they ensure all web sites under their juristiction that are supposed to be reachable from the public net get audited regularly to ensure that IPv6 connections work from public IP space. While you are sending the letter can you also ask why pay.gov's DNS servers are broken. Checking: 'pay.gov' as at 2016-11-16T20:21:28Z pay.gov @199.169.194.28 (ns1.twai.gov.): edns=ok edns1=timeout edns at 512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns at 512tcp=ok optlist=ok pay.gov @2605:3100:fffc:100::7 (ns1.twai.gov.): edns=ok edns1=timeout edns at 512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns at 512tcp=ok optlist=ok pay.gov @199.169.192.28 (ns2.twai.gov.): edns=ok edns1=timeout edns at 512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns at 512tcp=ok optlist=ok pay.gov @2605:3100:fffd:100::7 (ns2.twai.gov.): edns=ok edns1=timeout edns at 512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns at 512tcp=ok optlist=ok Mark > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA > LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC > =MS8j > -----END PGP SIGNATURE----- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From matthew at matthew.at Wed Nov 16 20:59:32 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 16 Nov 2016 20:59:32 +0000 Subject: pay.gov and IPv6 In-Reply-To: <20161116202357.4096B5A4FCB4@rock.dv.isc.org> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> Message-ID: I fixed it (and Netflix) by turning off IPv6 for all my users... but any chance this is a path MTU issue causing the apparent hang? Matthew Kaufman On Wed, Nov 16, 2016 at 12:26 PM Mark Andrews wrote: > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl Byington > writes > : > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Following up on a two year old thread, one of my clients just hit this > > problem. The failure is not that www.pay.gov is not reachable over ipv6 > > (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > > connection, but the connection then hangs waiting for the TLS handshake. > > > > openssl s_client -connect www.pay.gov:443 > > > > openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > > > > Browsers (at least firefox) see that as a very slow site, and it does > > not trigger their happy eyeballs fast failover to ipv4. > > Happy eyeballs is about making the connection not whether TCP > connections work after the initial packet exchange. > > I would send a physical letter to the relevent Inspector General > requesting that they ensure all web sites under their juristiction > that are supposed to be reachable from the public net get audited > regularly to ensure that IPv6 connections work from public IP space. > > While you are sending the letter can you also ask why pay.gov's DNS > servers are broken. > > Checking: 'pay.gov' as at 2016-11-16T20:21:28Z > > pay.gov @199.169.194.28 (ns1.twai.gov.): edns=ok edns1=timeout edns at 512=noopt > ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns at 512tcp=ok > optlist=ok > pay.gov @2605:3100:fffc:100::7 (ns1.twai.gov.): edns=ok edns1=timeout > edns at 512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok > edns at 512tcp=ok optlist=ok > pay.gov @199.169.192.28 (ns2.twai.gov.): edns=ok edns1=timeout edns at 512=noopt > ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok edns at 512tcp=ok > optlist=ok > pay.gov @2605:3100:fffd:100::7 (ns2.twai.gov.): edns=ok edns1=timeout > edns at 512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok > edns at 512tcp=ok optlist=ok > > Mark > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.14 (GNU/Linux) > > > > iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA > > LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC > > =MS8j > > -----END PGP SIGNATURE----- > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From carl at five-ten-sg.com Wed Nov 16 21:28:55 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Wed, 16 Nov 2016 13:28:55 -0800 Subject: pay.gov and IPv6 In-Reply-To: References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> Message-ID: <1479331735.30976.29.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2016-11-16 at 20:59 +0000, Matthew Kaufman wrote: > I fixed it (and Netflix) by turning off IPv6 for all my users... but > any chance this is a path MTU issue causing the apparent hang? I fixed it by using the rpz feature of bind to disable the AAAA record for www.pay.gov. I lookup the real A record, and then put www.pay.gov IN A %s into the local rpz zone. That suppresses the AAAA record, so local clients are forced into IPv4 for that site. That allows them to use IPv6 for other sites. path MTU - hm, I need to check that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgsz0YACgkQL6j7milTFsEbpwCgiJwZm3R/0VowqNFu4afHwPRq siwAmwdAj2YCLnlNQAs5Q5E5hcthaoiP =yqXb -----END PGP SIGNATURE----- From jared at puck.nether.net Wed Nov 16 21:56:09 2016 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 16 Nov 2016 16:56:09 -0500 Subject: pay.gov and IPv6 In-Reply-To: <1479249003.3937.6.camel@ns.five-ten-sg.com> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> Message-ID: > On Nov 15, 2016, at 5:30 PM, Carl Byington wrote: > > openssl s_client -connect www.pay.gov:443 I?m not seeing the issue here, but they do have some possible issues the way they?re setting cookies (See details below). What path are you seeing to them? I?m also not having the issue from the IETF97 network here in Seoul which has IPv6 as well. puck:~$ traceroute6 www.pay.gov. traceroute to www.pay.gov. (2605:3100:fffd:100::15), 30 hops max, 80 byte packets 1 ge-0-7-0-22.r05.chcgil09.us.bb.gin.ntt.net (2001:418:3f4::1) 0.751 ms 0.871 ms 0.994 ms 2 verio-gw.cgcil.ipv6.att.net (2001:1890:1fff:307:192:205:32:193) 2.008 ms 1.991 ms 2.837 ms 3 cgcil22crs.ipv6.att.net (2001:1890:ff:ffff:12:122:132:198) 27.333 ms 27.167 ms 27.070 ms 4 sl9mo22crs.ipv6.att.net (2001:1890:ff:ffff:12:122:2:178) 27.602 ms 27.646 ms 27.628 ms 5 sl9mo21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:2:217) 30.055 ms 29.894 ms 29.855 ms 6 dlstx22crs.ipv6.att.net (2001:1890:ff:ffff:12:122:2:1) 28.888 ms 27.016 ms 26.933 ms 7 dlstx84crs.ipv6.att.net (2001:1890:ff:ffff:12:123:18:249) 28.126 ms 26.757 ms 26.645 ms 8 2001:1890:ff:ffff:12:122:124:141 (2001:1890:ff:ffff:12:122:124:141) 26.142 ms 26.269 ms 26.179 ms 9 2001:1890:c00:610b::1138:7d27 (2001:1890:c00:610b::1138:7d27) 27.273 ms 27.255 ms 27.544 ms 10 2001:1890:1c08:cf01::2 (2001:1890:1c08:cf01::2) 27.673 ms !X 27.559 ms !X 27.465 ms !X curl -v https://www.pay.gov/public/home * Trying 2605:3100:fffd:100::15... * TCP_NODELAY set * Connected to www.pay.gov (2605:3100:fffd:100::15) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * ALPN/NPN, server did not agree to a protocol * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=www.pay.gov,O=United States Department of Treasury,L=Washington,ST=District of Columbia,C=US * start date: May 28 14:58:43 2015 GMT * expire date: May 29 06:16:02 2018 GMT * common name: www.pay.gov * issuer: CN=Entrust Certification Authority - L1K,OU="(c) 2012 Entrust, Inc. - for authorized use only",OU=See www.entrust.net/legal-terms,O="Entrust, Inc.",C=US > GET /public/home HTTP/1.1 > Host: www.pay.gov > User-Agent: curl/7.51.0 > Accept: */* > < HTTP/1.1 200 OK < Date: Wed, 16 Nov 2016 21:52:08 GMT < Content-type: text/html; charset=ISO-8859-1 < Strict-transport-security: max-age=31536001; includeSubDomains < Cache-Control: no-cache < Cache-Control: no-store < Pragma: no-cache < Expires: Thu, 01 Jan 1970 00:00:00 GMT < X-XSS-Protection: 1; mode=block < Strict-Transport-Security: max-age=31536000 < Set-Cookie: JSESSIONID=949QYsVLKQqBB42HTy91pJnGfnfJthLfQTv02CvDnt7rNQnpSvb1!1259175335!-1040755441!1479333128223; path=/public; secure; HttpOnly < Set-Cookie: JSESSIONID=949QYsVLKQqBB42HTy91pJnGfnfJthLfQTv02CvDnt7rNQnpSvb1!1259175335!-1040755441; path=/public; HttpOnly < Set-Cookie: ClientId=14793331282345260; path=/public; HttpOnly; secure < Set-Cookie: ClientId=1479333128244363; path=/public; HttpOnly; secure < X-FRAME-OPTIONS: DENY < Content-Language: en-US < X-Powered-By: Servlet/2.5 JSP/2.1 < Transfer-encoding: chunked From ler762 at gmail.com Wed Nov 16 22:00:08 2016 From: ler762 at gmail.com (Lee) Date: Wed, 16 Nov 2016 17:00:08 -0500 Subject: pay.gov and IPv6 In-Reply-To: <20161116202357.4096B5A4FCB4@rock.dv.isc.org> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> Message-ID: On 11/16/16, Mark Andrews wrote: > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl Byington > writes > : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Following up on a two year old thread, one of my clients just hit this >> problem. The failure is not that www.pay.gov is not reachable over ipv6 >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 >> connection, but the connection then hangs waiting for the TLS handshake. >> >> openssl s_client -connect www.pay.gov:443 >> >> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 >> >> Browsers (at least firefox) see that as a very slow site, and it does >> not trigger their happy eyeballs fast failover to ipv4. > > Happy eyeballs is about making the connection not whether TCP > connections work after the initial packet exchange. > > I would send a physical letter to the relevent Inspector General > requesting that they ensure all web sites under their juristiction > that are supposed to be reachable from the public net get audited > regularly to ensure that IPv6 connections work from public IP space. That will absolutely work. NIST is still monitoring ipv6 .gov sites https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov so the IG isn't going to do anything there & pay.gov has a contact us page https://pay.gov/public/home/contact that I'd bet works much better than a letter to the IG Regards, Lee From jordi.palet at consulintel.es Wed Nov 16 23:48:10 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Nov 2016 08:48:10 +0900 Subject: pay.gov and IPv6 In-Reply-To: <1479249003.3937.6.camel@ns.five-ten-sg.com> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> Message-ID: <7589A77F-DE70-49D3-A371-1A355ADAE5CA@consulintel.es> It happens too often, unfortunately. People deploying IPv6 at web sites and other services, don?t check if PMTUD is broken by filtering, ECMP, load balancers, etc. This is the case here: tbit from 2001:df0:4:4000::1:115 to 2605:3100:fffd:100::15 server-mss 1440, result: pmtud-fail app: http, url: https://www.pay.gov/ [ 0.009] TX SYN 64 seq = 0:0 [ 0.165] RX SYN/ACK 64 seq = 0:1 [ 0.166] TX 60 seq = 1:1 [ 0.166] TX 371 seq = 1:1(311) [ 0.325] RX 1500 seq = 1:312(1440) [ 0.325] RX 1500 seq = 1441:312(1440) [ 0.325] TX PTB 1280 mtu = 1280 [ 0.325] RX 1362 seq = 2881:312(1302) [ 3.325] RX 1500 seq = 1:312(1440) [ 3.325] TX PTB 1280 mtu = 1280 [ 9.326] RX 1500 seq = 1:312(1440) [ 9.326] TX PTB 1280 mtu = 1280 [ 21.325] RX 1500 seq = 1:312(1440) [ 21.325] TX PTB 1280 mtu = 1280 [ 45.325] RX 1500 seq = 1:312(1440) Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Carl Byington Responder a: Fecha: mi?rcoles, 16 de noviembre de 2016, 7:30 Para: Asunto: pay.gov and IPv6 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Following up on a two year old thread, one of my clients just hit this problem. The failure is not that www.pay.gov is not reachable over ipv6 (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 connection, but the connection then hangs waiting for the TLS handshake. openssl s_client -connect www.pay.gov:443 openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 Browsers (at least firefox) see that as a very slow site, and it does not trigger their happy eyeballs fast failover to ipv4. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC =MS8j -----END PGP SIGNATURE----- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From marka at isc.org Thu Nov 17 00:26:22 2016 From: marka at isc.org (Mark Andrews) Date: Thu, 17 Nov 2016 11:26:22 +1100 Subject: pay.gov and IPv6 In-Reply-To: Your message of "Wed, 16 Nov 2016 17:00:08 -0500." References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> Message-ID: <20161117002622.74D825A57884@rock.dv.isc.org> In message , Lee writes: > On 11/16/16, Mark Andrews wrote: > > > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl Byington > > writes > > : > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA512 > >> > >> Following up on a two year old thread, one of my clients just hit this > >> problem. The failure is not that www.pay.gov is not reachable over ipv6 > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > >> connection, but the connection then hangs waiting for the TLS handshake. > >> > >> openssl s_client -connect www.pay.gov:443 > >> > >> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > >> > >> Browsers (at least firefox) see that as a very slow site, and it does > >> not trigger their happy eyeballs fast failover to ipv4. > > > > Happy eyeballs is about making the connection not whether TCP > > connections work after the initial packet exchange. > > > > I would send a physical letter to the relevent Inspector General > > requesting that they ensure all web sites under their juristiction > > that are supposed to be reachable from the public net get audited > > regularly to ensure that IPv6 connections work from public IP space. > > That will absolutely work. > > NIST is still monitoring ipv6 .gov sites > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov Which show green which means that the tests they are doing are not sufficient. They need to test from behind a 1280 mtu link. The DNSSEC testing is also insufficient. 9-11commission.gov shows green for example but if you use DNS COOKIES (which BIND 9.10.4 and BIND 9.11.0 do) then servers barf and return BADVERS and validation fails. QWEST you have been informed of this already. Why the hell should validating resolver have to work around the crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT servers. You get PAID to do DNS because people think you are compentent to do the job. Evidence shows otherwise. https://ednscomp.isc.org/compliance/gov-full-report.html show the broken servers for .gov. It isn't hard to check. > so the IG isn't going to do anything there & pay.gov has a contact us page > https://pay.gov/public/home/contact > that I'd bet works much better than a letter to the IG You have to be able to get to https://pay.gov/public/home/contact to use it. Most people don't have the skill set to force the use of IPv4. If it is production it should work. It is the I-G's role to ensure this happens. Butts need to kicked. Mark > Regards, > Lee -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jcenile1983 at gmail.com Thu Nov 17 01:48:25 2016 From: jcenile1983 at gmail.com (John Cenile) Date: Thu, 17 Nov 2016 12:48:25 +1100 Subject: Facebook Geo Routing Issues Message-ID: Hello, Does anybody have a contact I could use at Facebook to get a routing issue resolved? Some of our networks are being routed to Miami, rather than using the much closer PoP of Sydney, and it's obviously causing significant performance issues when browsing Facebook. From nanog at ics-il.net Thu Nov 17 01:50:57 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 16 Nov 2016 19:50:57 -0600 (CST) Subject: Facebook Geo Routing Issues In-Reply-To: References: Message-ID: <1291614436.2689.1479347455008.JavaMail.mhammett@ThunderFuck> I'm in Chicago and I saw mine going to Miami as well (per rDNS). Haven't looked into it at all. I did see a video where they said they occasionally purposely give people less than ideal facilities to test connectivity. Maybe that process buggered up? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "John Cenile" To: nanog at nanog.org Sent: Wednesday, November 16, 2016 7:48:25 PM Subject: Facebook Geo Routing Issues Hello, Does anybody have a contact I could use at Facebook to get a routing issue resolved? Some of our networks are being routed to Miami, rather than using the much closer PoP of Sydney, and it's obviously causing significant performance issues when browsing Facebook. From jordi.palet at consulintel.es Thu Nov 17 02:10:16 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Nov 2016 11:10:16 +0900 Subject: pay.gov and IPv6 In-Reply-To: <20161117002622.74D825A57884@rock.dv.isc.org> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> Message-ID: I think it is not just a matter of testing behind a 1280 MTU, but about making sure that PMTUD is not broken, so it just works in any circumstances. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Mark Andrews Responder a: Fecha: jueves, 17 de noviembre de 2016, 9:26 Para: Lee CC: Asunto: Re: pay.gov and IPv6 In message , Lee writes: > On 11/16/16, Mark Andrews wrote: > > > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl Byington > > writes > > : > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA512 > >> > >> Following up on a two year old thread, one of my clients just hit this > >> problem. The failure is not that www.pay.gov is not reachable over ipv6 > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > >> connection, but the connection then hangs waiting for the TLS handshake. > >> > >> openssl s_client -connect www.pay.gov:443 > >> > >> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > >> > >> Browsers (at least firefox) see that as a very slow site, and it does > >> not trigger their happy eyeballs fast failover to ipv4. > > > > Happy eyeballs is about making the connection not whether TCP > > connections work after the initial packet exchange. > > > > I would send a physical letter to the relevent Inspector General > > requesting that they ensure all web sites under their juristiction > > that are supposed to be reachable from the public net get audited > > regularly to ensure that IPv6 connections work from public IP space. > > That will absolutely work. > > NIST is still monitoring ipv6 .gov sites > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov Which show green which means that the tests they are doing are not sufficient. They need to test from behind a 1280 mtu link. The DNSSEC testing is also insufficient. 9-11commission.gov shows green for example but if you use DNS COOKIES (which BIND 9.10.4 and BIND 9.11.0 do) then servers barf and return BADVERS and validation fails. QWEST you have been informed of this already. Why the hell should validating resolver have to work around the crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT servers. You get PAID to do DNS because people think you are compentent to do the job. Evidence shows otherwise. https://ednscomp.isc.org/compliance/gov-full-report.html show the broken servers for .gov. It isn't hard to check. > so the IG isn't going to do anything there & pay.gov has a contact us page > https://pay.gov/public/home/contact > that I'd bet works much better than a letter to the IG You have to be able to get to https://pay.gov/public/home/contact to use it. Most people don't have the skill set to force the use of IPv4. If it is production it should work. It is the I-G's role to ensure this happens. Butts need to kicked. Mark > Regards, > Lee -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From marka at isc.org Thu Nov 17 02:26:47 2016 From: marka at isc.org (Mark Andrews) Date: Thu, 17 Nov 2016 13:26:47 +1100 Subject: pay.gov and IPv6 In-Reply-To: Your message of "Thu, 17 Nov 2016 11:10:16 +0900." References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> Message-ID: <20161117022647.623D25A5A911@rock.dv.isc.org> In message , JORDI PALET M ARTINEZ writes: > I think it is not just a matter of testing behind a 1280 MTU, but about makin > g sure that PMTUD is not broken, so it just works in any circumstances. > > Regards, > Jordi If you don't do MSS fix up a 1280 link in the middle will find PMTUD issues provided the testing host has a MTU > 1280. Mark > -----Mensaje original----- > De: NANOG en nombre de Mark Andrews > Responder a: > Fecha: jueves, 17 de noviembre de 2016, 9:26 > Para: Lee > CC: > Asunto: Re: pay.gov and IPv6 > > > In message l.com> > , Lee writes: > > On 11/16/16, Mark Andrews wrote: > > > > > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl Byingto > n > > > writes > > > : > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA512 > > >> > > >> Following up on a two year old thread, one of my clients just hit th > is > > >> problem. The failure is not that www.pay.gov is not reachable over i > pv6 > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443 > > >> connection, but the connection then hangs waiting for the TLS handsh > ake. > > >> > > >> openssl s_client -connect www.pay.gov:443 > > >> > > >> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443 > > >> > > >> Browsers (at least firefox) see that as a very slow site, and it doe > s > > >> not trigger their happy eyeballs fast failover to ipv4. > > > > > > Happy eyeballs is about making the connection not whether TCP > > > connections work after the initial packet exchange. > > > > > > I would send a physical letter to the relevent Inspector General > > > requesting that they ensure all web sites under their juristiction > > > that are supposed to be reachable from the public net get audited > > > regularly to ensure that IPv6 connections work from public IP space. > > > > That will absolutely work. > > > > NIST is still monitoring ipv6 .gov sites > > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov > > Which show green which means that the tests they are doing are not > sufficient. They need to test from behind a 1280 mtu link. > > The DNSSEC testing is also insufficient. 9-11commission.gov shows > green for example but if you use DNS COOKIES (which BIND 9.10.4 and > BIND 9.11.0 do) then servers barf and return BADVERS and validation > fails. QWEST you have been informed of this already. > > Why the hell should validating resolver have to work around the > crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT > servers. You get PAID to do DNS because people think you are > compentent to do the job. Evidence shows otherwise. > > https://ednscomp.isc.org/compliance/gov-full-report.html show the broken > servers for .gov. It isn't hard to check. > > > so the IG isn't going to do anything there & pay.gov has a contact us p > age > > https://pay.gov/public/home/contact > > that I'd bet works much better than a letter to the IG > > You have to be able to get to https://pay.gov/public/home/contact to use > it. Most people don't have the skill set to force the use of IPv4. > > If it is production it should work. It is the I-G's role to ensure this > happens. Butts need to kicked. > > Mark > > > Regards, > > Lee > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confi > dential. The information is intended to be for the use of the individual(s) n > amed above. If you are not the intended recipient be aware that any disclosur > e, copying, distribution or use of the contents of this information, includin > g attached files, is prohibited. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Thu Nov 17 02:29:09 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 16 Nov 2016 18:29:09 -0800 Subject: NEVERMIND! (was: Seeking Google reverse DNS delegation contact) In-Reply-To: References: <9287.1478844315@segfault.tristatelogic.com> Message-ID: On Sun, Nov 13, 2016 at 3:57 PM, Christopher Morrow wrote: > So... actually someone did tell arin to aim these at ns1/2google.com... > I'll go ask arin to 'fix the glitch'. > > the glitch got fixed, shortly after this message, but not by my/our doing... hrm.. I see passive dns data: bailiwick 136.8.204.in-addr.arpa. count 19 first seen 2016-10-28 16:17:02 -0000 last seen 2016-11-13 08:59:50 -0000 136.8.204.in-addr.arpa. NS ns1.google.com. 136.8.204.in-addr.arpa. NS ns2.google.com. and after that: (overlapping that) bailiwick 204.in-addr.arpa. count 2335 first seen 2015-05-01 16:20:01 -0000 last seen 2016-11-16 21:54:01 -0000 136.8.204.in-addr.arpa. NS ns1.rossinc.net. 136.8.204.in-addr.arpa. NS ns2.rossinc.net. so.. I suspect ross digital/rossinc.net noticed they made a 'mistake' and that that 'mistake' was seen externally and .. fixed things on thier own. With that said, it's possible (so they'll also fix this new problem): dig ns1.rossinc.net dig ns2.rossinc.net both are 'nxdomain' from: ;; ANSWER SECTION: rossinc.net. 3057 IN NS ns57.domaincontrol.com. rossinc.net. 3057 IN NS ns58.domaincontrol.com. which seems sad, and bad.. and .. like someone has made another 'mistake' :( rossinc, you probably want to fix this as well. > thanks! > -chris > (sometimes people do this, I have no idea why... perhaps they just like > broken ptrs?) > > On Thu, Nov 10, 2016 at 10:05 PM, Ronald F. Guilmette < > rfg at tristatelogic.com> wrote: > >> >> >> My profuse apologies to everyone. It seems that Google is not in fact >> involved in any way with providing reverse DNS for the 204.8.136.0/21 >> IP address block. I was deceived into believing it was by some >> unusual trickey on the part of the spammer-controlled name servers >> ns1.saversagreeable.com and ns2.saversagreeable.com. You can see >> the clever deception toward the very end of the dig +trace listing >> I posted: >> >> http://pastebin.com/raw/VNwmgMHh >> >> It seems those clever rascal spammers tried to implicate Google's >> name servers, but it is only their's which are giving out the >> reverse DNS which suoorts their snowshoe spamming efforts in the >> 204.8.136.0/21 block. >> >> Sorry for my mistake everyone. I wasn't expecting quite this level >> or kind of reverse DNS delegation trickery. >> >> >> Regards, >> rfg >> > > From matthew at matthew.at Thu Nov 17 02:47:00 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 17 Nov 2016 02:47:00 +0000 Subject: pay.gov and IPv6 In-Reply-To: <20161117022647.623D25A5A911@rock.dv.isc.org> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> Message-ID: The good news is that I reported this particular site as a problem two and three years ago, both, and it isn't any worse. Matthew Kaufman On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews wrote: > > In message , JORDI > PALET M > ARTINEZ writes: > > I think it is not just a matter of testing behind a 1280 MTU, but about > makin > > g sure that PMTUD is not broken, so it just works in any circumstances. > > > > Regards, > > Jordi > > If you don't do MSS fix up a 1280 link in the middle will find PMTUD issues > provided the testing host has a MTU > 1280. > > Mark > > > -----Mensaje original----- > > De: NANOG en nombre de Mark Andrews < > marka at isc.org> > > Responder a: > > Fecha: jueves, 17 de noviembre de 2016, 9:26 > > Para: Lee > > CC: > > Asunto: Re: pay.gov and IPv6 > > > > > > In message > > l.com> > > , Lee writes: > > > On 11/16/16, Mark Andrews wrote: > > > > > > > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl > Byingto > > n > > > > writes > > > > : > > > >> -----BEGIN PGP SIGNED MESSAGE----- > > > >> Hash: SHA512 > > > >> > > > >> Following up on a two year old thread, one of my clients just > hit th > > is > > > >> problem. The failure is not that www.pay.gov is not reachable > over i > > pv6 > > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port > 443 > > > >> connection, but the connection then hangs waiting for the TLS > handsh > > ake. > > > >> > > > >> openssl s_client -connect www.pay.gov:443 > > > >> > > > >> openssl s_client -servername www.pay.gov -connect > 199.169.192.21:443 > > > >> > > > >> Browsers (at least firefox) see that as a very slow site, and > it doe > > s > > > >> not trigger their happy eyeballs fast failover to ipv4. > > > > > > > > Happy eyeballs is about making the connection not whether TCP > > > > connections work after the initial packet exchange. > > > > > > > > I would send a physical letter to the relevent Inspector General > > > > requesting that they ensure all web sites under their > juristiction > > > > that are supposed to be reachable from the public net get audited > > > > regularly to ensure that IPv6 connections work from public IP > space. > > > > > > That will absolutely work. > > > > > > NIST is still monitoring ipv6 .gov sites > > > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov > > > > Which show green which means that the tests they are doing are not > > sufficient. They need to test from behind a 1280 mtu link. > > > > The DNSSEC testing is also insufficient. 9-11commission.gov shows > > green for example but if you use DNS COOKIES (which BIND 9.10.4 and > > BIND 9.11.0 do) then servers barf and return BADVERS and validation > > fails. QWEST you have been informed of this already. > > > > Why the hell should validating resolver have to work around the > > crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT > > servers. You get PAID to do DNS because people think you are > > compentent to do the job. Evidence shows otherwise. > > > > https://ednscomp.isc.org/compliance/gov-full-report.html show the > broken > > servers for .gov. It isn't hard to check. > > > > > so the IG isn't going to do anything there & pay.gov has a > contact us p > > age > > > https://pay.gov/public/home/contact > > > that I'd bet works much better than a letter to the IG > > > > You have to be able to get to https://pay.gov/public/home/contact > to use > > it. Most people don't have the skill set to force the use of IPv4. > > > > If it is production it should work. It is the I-G's role to ensure > this > > happens. Butts need to kicked. > > > > Mark > > > > > Regards, > > > Lee > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confi > > dential. The information is intended to be for the use of the > individual(s) n > > amed above. If you are not the intended recipient be aware that any > disclosur > > e, copying, distribution or use of the contents of this information, > includin > > g attached files, is prohibited. > > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From jhellenthal at dataix.net Thu Nov 17 03:31:07 2016 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 16 Nov 2016 21:31:07 -0600 Subject: Network Diagnostic Tool In-Reply-To: <8479FC96-7FE9-4938-BA70-9EFAFF8F3BAD@DataIX.net> References: <8479FC96-7FE9-4938-BA70-9EFAFF8F3BAD@DataIX.net> Message-ID: https://twitter.com/jhackenthal/status/799091998594650112 > On Nov 12, 2016, at 22:05, J. Hellenthal wrote: > > That is a very cool contribution you've made. Let me run it through some tests and put it to work right away and see if I can provide some feedback and maybe possible patches or incites > > But thank you!! > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Nov 12, 2016, at 13:28, Mehrdad Arshad Rad wrote: > > Hi, > > I've started to develop an open source tool 4 months ago to help > neteng/sysadmin/sysops please take look at the below link and let me know > if you have any suggestions. > > https://github.com/mehrdadrad/mylg > > p.s you can download it for different operating systems at http://mylg.io > > Thanks, > Mehrdad -- Jason Hellenthal JJH48-ARIN From ler762 at gmail.com Thu Nov 17 17:48:55 2016 From: ler762 at gmail.com (Lee) Date: Thu, 17 Nov 2016 12:48:55 -0500 Subject: pay.gov and IPv6 In-Reply-To: References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> Message-ID: On 11/16/16, Matthew Kaufman wrote: > The good news is that I reported this particular site as a problem two and > three years ago, both, and it isn't any worse. did you contact Pay.gov Customer Service at: 800-624-1373 (Toll free, Option #2) or send an email to pay.gov.clev at clev.frb.org I just called, but I can't duplicate the problem and they need to work with someone that is having a problem reaching the site. Regards, Lee > > Matthew Kaufman > On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews wrote: > >> >> In message , JORDI >> PALET M >> ARTINEZ writes: >> > I think it is not just a matter of testing behind a 1280 MTU, but about >> makin >> > g sure that PMTUD is not broken, so it just works in any circumstances. >> > >> > Regards, >> > Jordi >> >> If you don't do MSS fix up a 1280 link in the middle will find PMTUD >> issues >> provided the testing host has a MTU > 1280. >> >> Mark >> >> > -----Mensaje original----- >> > De: NANOG en nombre de Mark Andrews < >> marka at isc.org> >> > Responder a: >> > Fecha: jueves, 17 de noviembre de 2016, 9:26 >> > Para: Lee >> > CC: >> > Asunto: Re: pay.gov and IPv6 >> > >> > >> > In message >> > > l.com> >> > , Lee writes: >> > > On 11/16/16, Mark Andrews wrote: >> > > > >> > > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl >> Byingto >> > n >> > > > writes >> > > > : >> > > >> -----BEGIN PGP SIGNED MESSAGE----- >> > > >> Hash: SHA512 >> > > >> >> > > >> Following up on a two year old thread, one of my clients just >> hit th >> > is >> > > >> problem. The failure is not that www.pay.gov is not reachable >> over i >> > pv6 >> > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port >> 443 >> > > >> connection, but the connection then hangs waiting for the TLS >> handsh >> > ake. >> > > >> >> > > >> openssl s_client -connect www.pay.gov:443 >> > > >> >> > > >> openssl s_client -servername www.pay.gov -connect >> 199.169.192.21:443 >> > > >> >> > > >> Browsers (at least firefox) see that as a very slow site, and >> it doe >> > s >> > > >> not trigger their happy eyeballs fast failover to ipv4. >> > > > >> > > > Happy eyeballs is about making the connection not whether TCP >> > > > connections work after the initial packet exchange. >> > > > >> > > > I would send a physical letter to the relevent Inspector >> > General >> > > > requesting that they ensure all web sites under their >> juristiction >> > > > that are supposed to be reachable from the public net get >> > audited >> > > > regularly to ensure that IPv6 connections work from public IP >> space. >> > > >> > > That will absolutely work. >> > > >> > > NIST is still monitoring ipv6 .gov sites >> > > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov >> > >> > Which show green which means that the tests they are doing are not >> > sufficient. They need to test from behind a 1280 mtu link. >> > >> > The DNSSEC testing is also insufficient. 9-11commission.gov shows >> > green for example but if you use DNS COOKIES (which BIND 9.10.4 and >> > BIND 9.11.0 do) then servers barf and return BADVERS and validation >> > fails. QWEST you have been informed of this already. >> > >> > Why the hell should validating resolver have to work around the >> > crap you guys are using? DO YOUR JOBS which is to use RFC >> > COMPLIANT >> > servers. You get PAID to do DNS because people think you are >> > compentent to do the job. Evidence shows otherwise. >> > >> > https://ednscomp.isc.org/compliance/gov-full-report.html show the >> broken >> > servers for .gov. It isn't hard to check. >> > >> > > so the IG isn't going to do anything there & pay.gov has a >> contact us p >> > age >> > > https://pay.gov/public/home/contact >> > > that I'd bet works much better than a letter to the IG >> > >> > You have to be able to get to https://pay.gov/public/home/contact >> to use >> > it. Most people don't have the skill set to force the use of IPv4. >> > >> > If it is production it should work. It is the I-G's role to ensure >> this >> > happens. Butts need to kicked. >> > >> > Mark >> > >> > > Regards, >> > > Lee >> > -- >> > Mark Andrews, ISC >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> > >> > >> > >> > >> > >> > ********************************************** >> > IPv4 is over >> > Are you ready for the new Internet ? >> > http://www.consulintel.es >> > The IPv6 Company >> > >> > This electronic message contains information which may be privileged or >> confi >> > dential. The information is intended to be for the use of the >> individual(s) n >> > amed above. If you are not the intended recipient be aware that any >> disclosur >> > e, copying, distribution or use of the contents of this information, >> includin >> > g attached files, is prohibited. >> > >> > >> > >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> > From matthew at matthew.at Thu Nov 17 18:30:37 2016 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 17 Nov 2016 18:30:37 +0000 Subject: pay.gov and IPv6 In-Reply-To: References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> Message-ID: I sent email there and to another contact I had at the time. And I'm not going to break my users by turning IPv6 back on, so someone else will need to work with them. Matthew Kaufman On Thu, Nov 17, 2016 at 9:48 AM Lee wrote: > On 11/16/16, Matthew Kaufman wrote: > > The good news is that I reported this particular site as a problem two > and > > three years ago, both, and it isn't any worse. > > did you contact Pay.gov Customer Service at: > 800-624-1373 <(800)%20624-1373> (Toll free, Option #2) > or send an email to > pay.gov.clev at clev.frb.org > > I just called, but I can't duplicate the problem and they need to work > with someone that is having a problem reaching the site. > > Regards, > Lee > > > > > > Matthew Kaufman > > On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews wrote: > > > >> > >> In message , JORDI > >> PALET M > >> ARTINEZ writes: > >> > I think it is not just a matter of testing behind a 1280 MTU, but > about > >> makin > >> > g sure that PMTUD is not broken, so it just works in any > circumstances. > >> > > >> > Regards, > >> > Jordi > >> > >> If you don't do MSS fix up a 1280 link in the middle will find PMTUD > >> issues > >> provided the testing host has a MTU > 1280. > >> > >> Mark > >> > >> > -----Mensaje original----- > >> > De: NANOG en nombre de Mark Andrews < > >> marka at isc.org> > >> > Responder a: > >> > Fecha: jueves, 17 de noviembre de 2016, 9:26 > >> > Para: Lee > >> > CC: > >> > Asunto: Re: pay.gov and IPv6 > >> > > >> > > >> > In message > >> >> > l.com> > >> > , Lee writes: > >> > > On 11/16/16, Mark Andrews wrote: > >> > > > > >> > > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, Carl > >> Byingto > >> > n > >> > > > writes > >> > > > : > >> > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> > > >> Hash: SHA512 > >> > > >> > >> > > >> Following up on a two year old thread, one of my clients just > >> hit th > >> > is > >> > > >> problem. The failure is not that www.pay.gov is not > reachable > >> over i > >> > pv6 > >> > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the > port > >> 443 > >> > > >> connection, but the connection then hangs waiting for the TLS > >> handsh > >> > ake. > >> > > >> > >> > > >> openssl s_client -connect www.pay.gov:443 > >> > > >> > >> > > >> openssl s_client -servername www.pay.gov -connect > >> 199.169.192.21:443 > >> > > >> > >> > > >> Browsers (at least firefox) see that as a very slow site, and > >> it doe > >> > s > >> > > >> not trigger their happy eyeballs fast failover to ipv4. > >> > > > > >> > > > Happy eyeballs is about making the connection not whether TCP > >> > > > connections work after the initial packet exchange. > >> > > > > >> > > > I would send a physical letter to the relevent Inspector > >> > General > >> > > > requesting that they ensure all web sites under their > >> juristiction > >> > > > that are supposed to be reachable from the public net get > >> > audited > >> > > > regularly to ensure that IPv6 connections work from public IP > >> space. > >> > > > >> > > That will absolutely work. > >> > > > >> > > NIST is still monitoring ipv6 .gov sites > >> > > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov > >> > > >> > Which show green which means that the tests they are doing are not > >> > sufficient. They need to test from behind a 1280 mtu link. > >> > > >> > The DNSSEC testing is also insufficient. 9-11commission.gov > shows > >> > green for example but if you use DNS COOKIES (which BIND 9.10.4 > and > >> > BIND 9.11.0 do) then servers barf and return BADVERS and > validation > >> > fails. QWEST you have been informed of this already. > >> > > >> > Why the hell should validating resolver have to work around the > >> > crap you guys are using? DO YOUR JOBS which is to use RFC > >> > COMPLIANT > >> > servers. You get PAID to do DNS because people think you are > >> > compentent to do the job. Evidence shows otherwise. > >> > > >> > https://ednscomp.isc.org/compliance/gov-full-report.html show the > >> broken > >> > servers for .gov. It isn't hard to check. > >> > > >> > > so the IG isn't going to do anything there & pay.gov has a > >> contact us p > >> > age > >> > > https://pay.gov/public/home/contact > >> > > that I'd bet works much better than a letter to the IG > >> > > >> > You have to be able to get to https://pay.gov/public/home/contact > >> to use > >> > it. Most people don't have the skill set to force the use of > IPv4. > >> > > >> > If it is production it should work. It is the I-G's role to > ensure > >> this > >> > happens. Butts need to kicked. > >> > > >> > Mark > >> > > >> > > Regards, > >> > > Lee > >> > -- > >> > Mark Andrews, ISC > >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> > PHONE: +61 2 9871 4742 <+61%202%209871%204742> > INTERNET: marka at isc.org > >> > > >> > > >> > > >> > > >> > > >> > ********************************************** > >> > IPv4 is over > >> > Are you ready for the new Internet ? > >> > http://www.consulintel.es > >> > The IPv6 Company > >> > > >> > This electronic message contains information which may be privileged > or > >> confi > >> > dential. The information is intended to be for the use of the > >> individual(s) n > >> > amed above. If you are not the intended recipient be aware that any > >> disclosur > >> > e, copying, distribution or use of the contents of this information, > >> includin > >> > g attached files, is prohibited. > >> > > >> > > >> > > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 <+61%202%209871%204742> > INTERNET: marka at isc.org > >> > > > From ler762 at gmail.com Thu Nov 17 20:32:53 2016 From: ler762 at gmail.com (Lee) Date: Thu, 17 Nov 2016 15:32:53 -0500 Subject: pay.gov and IPv6 In-Reply-To: References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> Message-ID: On 11/17/16, Matthew Kaufman wrote: > I sent email there and to another contact I had at the time. and the response was? > And I'm not going to break my users by turning IPv6 back on, so someone > else will need to work with them. That's fine, but until someone is willing to work with them don't expect it to get fixed. Regards, Lee > > Matthew Kaufman > > On Thu, Nov 17, 2016 at 9:48 AM Lee wrote: > >> On 11/16/16, Matthew Kaufman wrote: >> > The good news is that I reported this particular site as a problem two >> and >> > three years ago, both, and it isn't any worse. >> >> did you contact Pay.gov Customer Service at: >> 800-624-1373 <(800)%20624-1373> (Toll free, Option #2) >> or send an email to >> pay.gov.clev at clev.frb.org >> >> I just called, but I can't duplicate the problem and they need to work >> with someone that is having a problem reaching the site. >> >> Regards, >> Lee >> >> >> > >> > Matthew Kaufman >> > On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews wrote: >> > >> >> >> >> In message , >> >> JORDI >> >> PALET M >> >> ARTINEZ writes: >> >> > I think it is not just a matter of testing behind a 1280 MTU, but >> about >> >> makin >> >> > g sure that PMTUD is not broken, so it just works in any >> circumstances. >> >> > >> >> > Regards, >> >> > Jordi >> >> >> >> If you don't do MSS fix up a 1280 link in the middle will find PMTUD >> >> issues >> >> provided the testing host has a MTU > 1280. >> >> >> >> Mark >> >> >> >> > -----Mensaje original----- >> >> > De: NANOG en nombre de Mark Andrews < >> >> marka at isc.org> >> >> > Responder a: >> >> > Fecha: jueves, 17 de noviembre de 2016, 9:26 >> >> > Para: Lee >> >> > CC: >> >> > Asunto: Re: pay.gov and IPv6 >> >> > >> >> > >> >> > In message >> >> > >> > l.com> >> >> > , Lee writes: >> >> > > On 11/16/16, Mark Andrews wrote: >> >> > > > >> >> > > > In message <1479249003.3937.6.camel at ns.five-ten-sg.com>, >> >> > Carl >> >> Byingto >> >> > n >> >> > > > writes >> >> > > > : >> >> > > >> -----BEGIN PGP SIGNED MESSAGE----- >> >> > > >> Hash: SHA512 >> >> > > >> >> >> > > >> Following up on a two year old thread, one of my clients >> >> > just >> >> hit th >> >> > is >> >> > > >> problem. The failure is not that www.pay.gov is not >> reachable >> >> over i >> >> > pv6 >> >> > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the >> port >> >> 443 >> >> > > >> connection, but the connection then hangs waiting for the >> >> > TLS >> >> handsh >> >> > ake. >> >> > > >> >> >> > > >> openssl s_client -connect www.pay.gov:443 >> >> > > >> >> >> > > >> openssl s_client -servername www.pay.gov -connect >> >> 199.169.192.21:443 >> >> > > >> >> >> > > >> Browsers (at least firefox) see that as a very slow site, >> >> > and >> >> it doe >> >> > s >> >> > > >> not trigger their happy eyeballs fast failover to ipv4. >> >> > > > >> >> > > > Happy eyeballs is about making the connection not whether >> >> > TCP >> >> > > > connections work after the initial packet exchange. >> >> > > > >> >> > > > I would send a physical letter to the relevent Inspector >> >> > General >> >> > > > requesting that they ensure all web sites under their >> >> juristiction >> >> > > > that are supposed to be reachable from the public net get >> >> > audited >> >> > > > regularly to ensure that IPv6 connections work from public >> >> > IP >> >> space. >> >> > > >> >> > > That will absolutely work. >> >> > > >> >> > > NIST is still monitoring ipv6 .gov sites >> >> > > https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov >> >> > >> >> > Which show green which means that the tests they are doing are >> >> > not >> >> > sufficient. They need to test from behind a 1280 mtu link. >> >> > >> >> > The DNSSEC testing is also insufficient. 9-11commission.gov >> shows >> >> > green for example but if you use DNS COOKIES (which BIND 9.10.4 >> and >> >> > BIND 9.11.0 do) then servers barf and return BADVERS and >> validation >> >> > fails. QWEST you have been informed of this already. >> >> > >> >> > Why the hell should validating resolver have to work around the >> >> > crap you guys are using? DO YOUR JOBS which is to use RFC >> >> > COMPLIANT >> >> > servers. You get PAID to do DNS because people think you are >> >> > compentent to do the job. Evidence shows otherwise. >> >> > >> >> > https://ednscomp.isc.org/compliance/gov-full-report.html show >> >> > the >> >> broken >> >> > servers for .gov. It isn't hard to check. >> >> > >> >> > > so the IG isn't going to do anything there & pay.gov has a >> >> contact us p >> >> > age >> >> > > https://pay.gov/public/home/contact >> >> > > that I'd bet works much better than a letter to the IG >> >> > >> >> > You have to be able to get to >> >> > https://pay.gov/public/home/contact >> >> to use >> >> > it. Most people don't have the skill set to force the use of >> IPv4. >> >> > >> >> > If it is production it should work. It is the I-G's role to >> ensure >> >> this >> >> > happens. Butts need to kicked. >> >> > >> >> > Mark >> >> > >> >> > > Regards, >> >> > > Lee >> >> > -- >> >> > Mark Andrews, ISC >> >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> >> > PHONE: +61 2 9871 4742 <+61%202%209871%204742> >> INTERNET: marka at isc.org >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > ********************************************** >> >> > IPv4 is over >> >> > Are you ready for the new Internet ? >> >> > http://www.consulintel.es >> >> > The IPv6 Company >> >> > >> >> > This electronic message contains information which may be privileged >> or >> >> confi >> >> > dential. The information is intended to be for the use of the >> >> individual(s) n >> >> > amed above. If you are not the intended recipient be aware that any >> >> disclosur >> >> > e, copying, distribution or use of the contents of this information, >> >> includin >> >> > g attached files, is prohibited. >> >> > >> >> > >> >> > >> >> -- >> >> Mark Andrews, ISC >> >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> >> PHONE: +61 2 9871 4742 <+61%202%209871%204742> >> INTERNET: marka at isc.org >> >> >> > >> > From rfg at tristatelogic.com Thu Nov 17 22:42:58 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 17 Nov 2016 14:42:58 -0800 Subject: Paging Olav van Doorn, Jan Willem Meijer, and Rutger Bevaart Message-ID: <70030.1479422578@segfault.tristatelogic.com> If anybody can give me an email for any of these principals of Xconnect42, Inc. (Neatherlands) aka AS260, I'd appreciate it. I tried to reach somebody (anybody) at their company via the address I found online for the company but never got any response. That was a week ago. I'm real interested to have these guys explain to me why they are peering with the following ASNs, which all appear to have one and only one BGP peer, i.e. Xconnect24, Inc. AS7971 AS10505 AS6560 AS14029 AS37135 AS37137 Note that each and every one of the above six Afrinic-issued ASNs appears to be announcing routes to gobs and gobs of IPv4 space... mostly prevously abandoned AFRINIC space, but also, in the case of AS10505, numerous /17 hunks of Chinese IPv4 space... to which the ASNs in question do not appear to have any relationship, and where a great deal of the relevant IPv4 address space has been filed up to the brim by U.S.A. based snowshoe spammers, including, apparently, at least one convicted felon and former drug trafficker. Note also that two of the /17 routes currently being announced by AS10505 are for IPv4 space allocated by APNIC to Aliyun Computing, Ltd. which Bloomberg lists as a subsidiary of retail giant Alibaba, currently having a market cap of $232.4 bellion dollars (USD). I dunno. maybe it's just me, but I somehow think that a Chinese company worth almost a quarter of a trillion dollars probably doesn't really need to enlist the help of a long-dead South African ISP to route parts of their space for them. http://imgur.com/a/uR0qQ So anyway, I'd really like to have a brief chat with any or all of the following three gentlemen about all this: CEO - Olav van Doorn https://nl.linkedin.com/in/olavvandoorn Co-founder Jan Willem Meijer: https://www.loth.nl/company-profile-custom-connect/ CTO - Rutger Bevaart https://nl.linkedin.com/in/rutgerbevaart If anybody can put me in touch, I'd apperciate it. Thanks. Regards, rfg From josh at kyneticwifi.com Thu Nov 17 22:55:52 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Thu, 17 Nov 2016 16:55:52 -0600 Subject: Facebook Geo Routing Issues In-Reply-To: <1291614436.2689.1479347455008.JavaMail.mhammett@ThunderFuck> References: <1291614436.2689.1479347455008.JavaMail.mhammett@ThunderFuck> Message-ID: Or due to capacity issues. On Nov 16, 2016 7:53 PM, "Mike Hammett" wrote: > I'm in Chicago and I saw mine going to Miami as well (per rDNS). Haven't > looked into it at all. > > I did see a video where they said they occasionally purposely give people > less than ideal facilities to test connectivity. Maybe that process > buggered up? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "John Cenile" > To: nanog at nanog.org > Sent: Wednesday, November 16, 2016 7:48:25 PM > Subject: Facebook Geo Routing Issues > > Hello, > > Does anybody have a contact I could use at Facebook to get a routing issue > resolved? > > Some of our networks are being routed to Miami, rather than using the much > closer PoP of Sydney, and it's obviously causing significant performance > issues when browsing Facebook. > > From carl at five-ten-sg.com Thu Nov 17 23:40:29 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 17 Nov 2016 15:40:29 -0800 Subject: pay.gov and IPv6 In-Reply-To: References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> Message-ID: <1479426029.8037.10.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2016-11-17 at 15:32 -0500, Lee wrote: > That's fine, but until someone is willing to work with them don't > expect it to get fixed. I am working with pay.gov.clev at clev.frb.org, trying to explain the problem. They seem to think I should provide "application name and ID" before they can research this. I responded as below. I will let you know if there is any progress on this. It is 100% reproducible here - and should be reproducible from anywhere with a slightly smaller than normal MTU. We try to get to https://www.pay.gov/public/home - which fails. I presume that is before there is any application name or ID. Try to reach that page from a browser on a machine with ipv6 connectivity that goes thru a tunnel with a 1300 byte MTU. It will fail. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlguP8oACgkQL6j7milTFsFgrQCfY2QLE0njiSRIILTzR4Fjpk3c F3AAnjZj8+3W51Qr9e1oGWAxrUC8Pnf3 =UpN0 -----END PGP SIGNATURE----- From angeladrianld at gmail.com Thu Nov 17 16:57:25 2016 From: angeladrianld at gmail.com (Angel Lopez) Date: Thu, 17 Nov 2016 10:57:25 -0600 Subject: Network Diagnostic Tool In-Reply-To: References: <8479FC96-7FE9-4938-BA70-9EFAFF8F3BAD@DataIX.net> Message-ID: Hi Mehrdad Arshad Rad, Thanks for this awesome! tool congrats On Wed, Nov 16, 2016 at 9:31 PM, Jason Hellenthal wrote: > https://twitter.com/jhackenthal/status/799091998594650112 > > > On Nov 12, 2016, at 22:05, J. Hellenthal wrote: > > > > That is a very cool contribution you've made. Let me run it through some > tests and put it to work right away and see if I can provide some feedback > and maybe possible patches or incites > > > > But thank you!! > > > > -- > > Onward!, > > Jason Hellenthal, > > Systems & Network Admin, > > Mobile: 0x9CA0BD58, > > JJH48-ARIN > > > > On Nov 12, 2016, at 13:28, Mehrdad Arshad Rad > wrote: > > > > Hi, > > > > I've started to develop an open source tool 4 months ago to help > > neteng/sysadmin/sysops please take look at the below link and let me know > > if you have any suggestions. > > > > https://github.com/mehrdadrad/mylg > > > > p.s you can download it for different operating systems at > http://mylg.io > > > > Thanks, > > Mehrdad > > > -- > Jason Hellenthal > JJH48-ARIN > > > > > From rod.beck at unitedcablecompany.com Fri Nov 18 09:54:13 2016 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 18 Nov 2016 09:54:13 +0000 Subject: Amsterdam/London Underesea Cables Message-ID: Hi, I am trying to determine which undersea cables used for London/Amsterdam traffic are the most reliable - fewest outages due to shunt faults and other problems. Looks like most of the traffic traverses the following systems: Farland North UK-Netherlands Ulysses Circe North Concerto My recollection, which is foggy, is that Circe North was rebuilt due to repeated shunt faults. Feel free to contact me offlist so you can share the good, the bad, and the ugly. [?] Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Kir?ly utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221429846_image002.jpg][1467221477350_image005.png] From rutger at custom-connect.com Fri Nov 18 10:02:13 2016 From: rutger at custom-connect.com (Rutger Bevaart) Date: Fri, 18 Nov 2016 10:02:13 +0000 Subject: Subject: Paging Olav van Doorn, Jan Willem Meijer, and Rutger Bevaart Message-ID: Hi Ronald, You obviously managed to find us ;-) All our contact details are on peeringdb.com, our corporate website, LinkedIn, etc. We should be pretty easy to reach. The message you sent to our 24x7 NOC was marked as ?spam?, ironic. Thank you for bringing this to my attention, we?ve asked the customer for clarification on this and in the meantime blocked offending prefixes. We update our filters based on RADB entries which is why these were accepted (valid route entries exist), I?ll evaluate if we need to do more than that. Cheers, Rutger From ler762 at gmail.com Fri Nov 18 14:51:51 2016 From: ler762 at gmail.com (Lee) Date: Fri, 18 Nov 2016 09:51:51 -0500 Subject: pay.gov and IPv6 In-Reply-To: <1479426029.8037.10.camel@ns.five-ten-sg.com> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> Message-ID: On 11/17/16, Carl Byington wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Thu, 2016-11-17 at 15:32 -0500, Lee wrote: >> That's fine, but until someone is willing to work with them don't >> expect it to get fixed. > > I am working with pay.gov.clev at clev.frb.org, trying to explain the > problem. They seem to think I should provide "application name and ID" > before they can research this. They probably want that so they know where to route the ticket. I pointed them at https://tools.ietf.org/html/rfc4890#page-14 and suggested they have someone on the network team use ipv6 to connect to pay.gov over a 1280 byte MTU link. Hopefully that's enough to get the ticket routed to the correct group. > I responded as below. I will let you know > if there is any progress on this. I'd appreciate that. And thanks for being willing to work with them to fix the problem. Lee > It is 100% reproducible here - and > should be reproducible from anywhere with a slightly smaller than normal > MTU. > > > > We try to get to https://www.pay.gov/public/home - which fails. I > presume that is before there is any application name or ID. > > Try to reach that page from a browser on a machine with ipv6 > connectivity that goes thru a tunnel with a 1300 byte MTU. It will fail. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlguP8oACgkQL6j7milTFsFgrQCfY2QLE0njiSRIILTzR4Fjpk3c > F3AAnjZj8+3W51Qr9e1oGWAxrUC8Pnf3 > =UpN0 > -----END PGP SIGNATURE----- > > > From sean at donelan.com Fri Nov 18 17:03:58 2016 From: sean at donelan.com (Sean Donelan) Date: Fri, 18 Nov 2016 12:03:58 -0500 (EST) Subject: pay.gov and IPv6 In-Reply-To: <20161117002622.74D825A57884@rock.dv.isc.org> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> Message-ID: On Thu, 17 Nov 2016, Mark Andrews wrote: > Why the hell should validating resolver have to work around the > crap you guys are using? DO YOUR JOBS which is to use RFC COMPLIANT > servers. You get PAID to do DNS because people think you are > compentent to do the job. Evidence shows otherwise. > > https://ednscomp.isc.org/compliance/gov-full-report.html show the broken > servers for .gov. It isn't hard to check. Engineer complains the universe doesn't match his assumptions. From pf at tippete.net Fri Nov 18 17:39:39 2016 From: pf at tippete.net (Pierfrancesco Caci) Date: Fri, 18 Nov 2016 18:39:39 +0100 Subject: Amsterdam/London Underesea Cables In-Reply-To: (Rod Beck's message of "Fri, 18 Nov 2016 09:54:13 +0000") References: Message-ID: <87pols661w.fsf@snoopy.tippete.net> >>>>> "Rod" == Rod Beck writes: Rod> Hi, Rod> I am trying to determine which undersea cables used for Rod> London/Amsterdam traffic are the most reliable - fewest outages due to Rod> shunt faults and other problems. I'm surprised repeaters are needed at all, the Channel is not that wide after all. -- Pierfrancesco Caci, ik5pvx From cscora at apnic.net Fri Nov 18 18:01:46 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Nov 2016 04:01:46 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161118180146.5983CC55A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 19 Nov, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 623487 Prefixes after maximum aggregation (per Origin AS): 220779 Deaggregation factor: 2.82 Unique aggregates announced (without unneeded subnets): 302048 Total ASes present in the Internet Routing Table: 55250 Prefixes per ASN: 11.28 Origin-only ASes present in the Internet Routing Table: 36327 Origin ASes announcing only one prefix: 15324 Transit ASes present in the Internet Routing Table: 6538 Transit-only ASes present in the Internet Routing Table: 164 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 64 Unregistered ASNs in the Routing Table: 20 Number of 32-bit ASNs allocated by the RIRs: 16184 Number of 32-bit ASNs visible in the Routing Table: 12385 Prefixes from 32-bit ASNs in the Routing Table: 50127 Number of bogon 32-bit ASNs visible in the Routing Table: 386 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 407 Number of addresses announced to Internet: 2832026276 Equivalent to 168 /8s, 205 /16s and 74 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.3 Total number of prefixes smaller than registry allocations: 205446 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 157521 Total APNIC prefixes after maximum aggregation: 42753 APNIC Deaggregation factor: 3.68 Prefixes being announced from the APNIC address blocks: 171530 Unique aggregates announced from the APNIC address blocks: 70096 APNIC Region origin ASes present in the Internet Routing Table: 5184 APNIC Prefixes per ASN: 33.09 APNIC Region origin ASes announcing only one prefix: 1152 APNIC Region transit ASes present in the Internet Routing Table: 942 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 34 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2490 Number of APNIC addresses announced to Internet: 759721284 Equivalent to 45 /8s, 72 /16s and 109 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 187964 Total ARIN prefixes after maximum aggregation: 89402 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 194317 Unique aggregates announced from the ARIN address blocks: 89233 ARIN Region origin ASes present in the Internet Routing Table: 16138 ARIN Prefixes per ASN: 12.04 ARIN Region origin ASes announcing only one prefix: 5654 ARIN Region transit ASes present in the Internet Routing Table: 1711 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1591 Number of ARIN addresses announced to Internet: 1105690016 Equivalent to 65 /8s, 231 /16s and 125 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 149759 Total RIPE prefixes after maximum aggregation: 72610 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 160650 Unique aggregates announced from the RIPE address blocks: 98008 RIPE Region origin ASes present in the Internet Routing Table: 18155 RIPE Prefixes per ASN: 8.85 RIPE Region origin ASes announcing only one prefix: 7793 RIPE Region transit ASes present in the Internet Routing Table: 3037 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 27 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5091 Number of RIPE addresses announced to Internet: 709323136 Equivalent to 42 /8s, 71 /16s and 105 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 62852 Total LACNIC prefixes after maximum aggregation: 12642 LACNIC Deaggregation factor: 4.97 Prefixes being announced from the LACNIC address blocks: 79140 Unique aggregates announced from the LACNIC address blocks: 37727 LACNIC Region origin ASes present in the Internet Routing Table: 2477 LACNIC Prefixes per ASN: 31.95 LACNIC Region origin ASes announcing only one prefix: 552 LACNIC Region transit ASes present in the Internet Routing Table: 593 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2935 Number of LACNIC addresses announced to Internet: 170952512 Equivalent to 10 /8s, 48 /16s and 135 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15199 Total AfriNIC prefixes after maximum aggregation: 3364 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 17443 Unique aggregates announced from the AfriNIC address blocks: 6616 AfriNIC Region origin ASes present in the Internet Routing Table: 741 AfriNIC Prefixes per ASN: 23.54 AfriNIC Region origin ASes announcing only one prefix: 173 AfriNIC Region transit ASes present in the Internet Routing Table: 180 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 278 Number of AfriNIC addresses announced to Internet: 85867520 Equivalent to 5 /8s, 30 /16s and 60 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5548 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3611 390 250 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2964 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2713 1500 539 BSNL-NIB National Internet Backbone, IN 4766 2699 11132 739 KIXS-AS-KR Korea Telecom, KR 9808 2220 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2044 428 216 TATACOMM-AS TATA Communications formerl 4808 1746 2278 510 CHINA169-BJ China Unicom Beijing Provin 45899 1703 1248 93 VNPT-AS-VN VNPT Corp, VN 24560 1565 542 229 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3564 2967 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3156 1333 82 SHAW - Shaw Communications Inc., CA 18566 2196 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1948 2003 406 CHARTER-NET-HKY-NC - Charter Communicat 30036 1769 334 364 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1742 5069 657 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1677 848 227 ITCDELTA - Earthlink, Inc., US 701 1600 10634 657 UUNET - MCI Communications Services, In 7018 1480 20476 1047 ATT-INTERNET4 - AT&T Services, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3330 170 16 ALJAWWALSTC-AS , SA 20940 2937 1113 2082 AKAMAI-ASN1 , US 34984 1990 327 364 TELLCOM-AS , TR 9121 1719 1691 18 TTNET , TR 13188 1607 99 58 TRIOLAN , UA 12479 1375 1033 54 UNI2-AS , ES 8551 1202 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 6849 1142 355 21 UKRTELNET , UA 8402 1139 544 15 CORBINA-AS OJSC "Vimpelcom", RU 9198 1057 352 25 KAZTELECOM-AS , KZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3536 546 142 Telmex Colombia S.A., CO 8151 2287 3371 551 Uninet S.A. de C.V., MX 7303 1528 964 248 Telecom Argentina S.A., AR 6503 1486 437 54 Axtel, S.A.B. de C.V., MX 11830 1354 369 57 Instituto Costarricense de Electricidad 6147 1289 377 27 Telefonica del Peru S.A.A., PE 7738 1024 1882 41 Telemar Norte Leste S.A., BR 28573 1009 2260 177 CLARO S.A., BR 3816 987 474 192 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 909 126 79 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1192 402 50 LINKdotNET-AS, EG 36903 686 345 123 MT-MPLS, MA 37611 680 67 6 Afrihost, ZA 36992 575 1373 25 ETISALAT-MISR, EG 8452 481 1472 15 TE-AS TE-AS, EG 37492 396 288 72 ORANGE-TN, TN 24835 379 594 16 RAYA-AS, EG 29571 364 37 11 CITelecom-AS, CI 15399 309 35 6 WANANCHI-KE, KE 36974 275 140 11 AFNET-AS, CI Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5548 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3611 390 250 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3564 2967 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3536 546 142 Telmex Colombia S.A., CO 39891 3330 170 16 ALJAWWALSTC-AS , SA 6327 3156 1333 82 SHAW - Shaw Communications Inc., CA 17974 2964 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2937 1113 2082 AKAMAI-ASN1 , US 9829 2713 1500 539 BSNL-NIB National Internet Backbone, IN 4766 2699 11132 739 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3564 3412 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3536 3394 Telmex Colombia S.A., CO 7545 3611 3361 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3330 3314 ALJAWWALSTC-AS , SA 6327 3156 3074 SHAW - Shaw Communications Inc., CA 17974 2964 2893 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2220 2187 CMNET-GD Guangdong Mobile Communication 9829 2713 2174 BSNL-NIB National Internet Backbone, IN 18566 2196 2087 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 2056 BELLSOUTH-NET-BLK - BellSouth.net Inc., Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 64855 PRIVATE 41.220.200.0/21 36945 mcelISP, MZ 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 27.110.192.0/22 45664 UNKNOWN 27.110.196.0/22 45664 UNKNOWN 27.110.200.0/22 45664 UNKNOWN 27.110.204.0/22 45664 UNKNOWN 27.110.224.0/22 45664 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:102 /12:274 /13:522 /14:1049 /15:1785 /16:13149 /17:7845 /18:13078 /19:25562 /20:38332 /21:40986 /22:72413 /23:60828 /24:346224 /25:459 /26:365 /27:305 /28:61 /29:38 /30:12 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 2953 3156 SHAW - Shaw Communications Inc., CA 39891 2896 3330 ALJAWWALSTC-AS , SA 22773 2774 3564 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2089 2196 MEGAPATH5-US - MegaPath Corporation, US 30036 1586 1769 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1443 3536 Telmex Colombia S.A., CO 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1351 1607 TRIOLAN , UA 6983 1323 1677 ITCDELTA - Earthlink, Inc., US 34984 1274 1990 TELLCOM-AS , TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1561 2:814 4:23 5:2338 6:32 8:1006 12:1805 13:53 14:1756 15:24 16:2 17:104 18:126 20:48 23:1916 24:1820 27:2377 31:1812 32:82 33:4 35:3 36:351 37:2423 38:1315 39:39 40:100 41:2936 42:455 43:1894 44:49 45:2250 46:2551 47:106 49:1182 50:936 51:16 52:575 53:2 54:352 55:7 56:4 57:40 58:1592 59:1006 60:378 61:1839 62:1476 63:1913 64:4584 65:2174 66:4353 67:2246 68:1141 69:3285 70:1294 71:560 72:2071 74:2595 75:404 76:414 77:1435 78:1536 79:923 80:1343 81:1401 82:994 83:714 84:868 85:1676 86:476 87:1122 88:697 89:2038 90:198 91:6142 92:958 93:2370 94:2416 95:2715 96:561 97:347 98:943 99:92 100:147 101:1179 103:12752 104:2583 105:145 106:465 107:1451 108:788 109:2487 110:1282 111:1645 112:1139 113:1154 114:1094 115:1692 116:1684 117:1559 118:2125 119:1568 120:968 121:1091 122:2287 123:2044 124:1599 125:1840 128:681 129:473 130:420 131:1383 132:617 133:175 134:521 135:205 136:404 137:391 138:1785 139:432 140:620 141:471 142:694 143:894 144:720 145:170 146:952 147:671 148:1386 149:551 150:669 151:971 152:693 153:309 154:692 155:950 156:537 157:564 158:437 159:1317 160:563 161:717 162:2434 163:545 164:778 165:1130 166:352 167:1214 168:2359 169:679 170:2321 171:258 172:819 173:1822 174:765 175:715 176:1743 177:4074 178:2376 179:1133 180:2150 181:1904 182:2117 183:1013 184:838 185:8043 186:3166 187:2136 188:2262 189:1768 190:7884 191:1307 192:9138 193:5752 194:4534 195:3864 196:1856 197:1257 198:5605 199:5830 200:7140 201:3730 202:10118 203:9800 204:4489 205:2764 206:3016 207:3129 208:4035 209:3886 210:3893 211:2050 212:2761 213:2437 214:863 215:67 216:5745 217:1989 218:812 219:598 220:1650 221:874 222:711 223:1344 End of report From spano at datacast.it Fri Nov 18 18:04:33 2016 From: spano at datacast.it (=?utf-8?Q?Giuseppe_Span=C3=B2_-_Datacast_Srl?=) Date: Fri, 18 Nov 2016 19:04:33 +0100 Subject: Autunomous system filtering? Message-ID: <201A093F-2075-4DAF-A398-E8F93440892E@datacast.it> Hi! We are experiencing a strange issue with announcements from our AS207029. On Sept. 16th we began to announce our prefixes 185.85.20.0/22 through our upstream provider AS28716 (E-Planet). Everything worked correctly. Suddenly during the night between 17th and 18th Sept. the visibility of those prefixes dropped heavily (source: ripe stats) and we began experiencing big issues with our customers. We decided then to differentiate the announcements as it follows: AS2876 announces 185.85.20.0/23 AS207029 announces 185.85.22.0/23 (those prefixes are idle at the moment) essentially we split the /22 into two /23 so to keep monitored our AS propagation. What?s happening is interesting: prefixes announced by AS2876 are regularly spread everywhere, those announced by AS207029 not. For example, we can see network 185.85.22.0/23 from HE looking glasses, but we cannot see it into Cogent, Level3 or Split looking glasses. It seems an AS filtering is acting somewhere, and this looks a bit weird to me. Did this ever happen to any of you? Do you have ideas? Our upstream provider (that owns peering sessions with all the above providers) opened tickets to them, but if Network Engineers from Cogent, Level3 or Split should be reading this, could they kindly have a look into their filter configurations? Thank you to all of you for your kind attention. Regards, Giuseppe Span? - Datacast Srl spano at datacast.it From fw at deneb.enyo.de Fri Nov 18 18:11:06 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 18 Nov 2016 19:11:06 +0100 Subject: pay.gov and IPv6 In-Reply-To: <20161117002622.74D825A57884@rock.dv.isc.org> (Mark Andrews's message of "Thu, 17 Nov 2016 11:26:22 +1100") References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> Message-ID: <87twb4slol.fsf@mid.deneb.enyo.de> * Mark Andrews: > The DNSSEC testing is also insufficient. 9-11commission.gov shows > green for example but if you use DNS COOKIES (which BIND 9.10.4 and > BIND 9.11.0 do) then servers barf and return BADVERS and validation > fails. QWEST you have been informed of this already. > > Why the hell should validating resolver have to work around the > crap you guys are using? The protocol doesn't have proper version negotation, and again and again, implementers have tried to force backwards-incompatible implementations on the Internet at large. From carl at five-ten-sg.com Fri Nov 18 18:22:53 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Fri, 18 Nov 2016 10:22:53 -0800 Subject: pay.gov and IPv6 In-Reply-To: <1479426029.8037.10.camel@ns.five-ten-sg.com> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> Message-ID: <1479493373.7178.35.camel@ns.five-ten-sg.com> > > I am working with pay.gov.clev at clev.frb.org, trying to explain the > problem. The intersection of government bureaucracy and technical issues is frustrating to say the least. I just sent the message below, but have no expectation that it will change anything. ============== On Fri, 2016-11-18 at 12:39 +0000, CLEV Pay Gov wrote: > It would be best to discuss this via phone. Please contact our help > desk at the number below and we could see if there's anything we could > do over the phone to help troubleshoot. That is hopeless. Verbal technical discussions rarely work unless both sides can see the same text. Have you ever tried (while talking on the phone) to get someone to type in clev.frb.org without making a bunch of mistakes in the spelling?? Anyway, just for my amusement, I did call 800-624-1373, Option #2, and am on the line now, trying to explain this. 10 minutes and counting. Ok, there does not seem to be any overall ticket for "pay.gov does not work at all". They refuse to open a tech support ticket. > If not, we may need to open a ticket for our technical support. Please open a ticket, and attach the following text for your tech support folks. Alternatively, have them look at the "pay.gov and ipv6" thread on nanog: http://mailman.nanog.org/pipermail/nanog/2016-November/thread.html www.pay.gov has an IPv6 address of 2605:3100:fffd:100::15, but that machine or its upstream routers are filtering icmpv6 messages. That web site is not accessible from systems with an MTU of 1280 bytes. The test case is: echo -e 'GET /public/home HTTP/1.0\n' | \ openssl s_client -servername www.pay.gov -ign_eof -connect \ '[2605:3100:fffd:100::15]:443' Run that (or just use a browser to try https://www.pay.gov) from a system with a 1500 byte MTU, and it works. Run it from a system with upstream connectivity via a tunnel, so the path MTU is smaller, and it fails. Such tunnels are common for IPv6. Please stop filtering icmpv6. From max at stucchi.ch Fri Nov 18 18:36:53 2016 From: max at stucchi.ch (Massimiliano Stucchi) Date: Fri, 18 Nov 2016 19:36:53 +0100 Subject: Autunomous system filtering? In-Reply-To: <201A093F-2075-4DAF-A398-E8F93440892E@datacast.it> References: <201A093F-2075-4DAF-A398-E8F93440892E@datacast.it> Message-ID: Hi, On 18/11/16 19:04, Giuseppe Span? - Datacast Srl wrote: > AS2876 announces 185.85.20.0/23 > AS207029 announces 185.85.22.0/23 (those prefixes are idle at the moment) > It seems an AS filtering is acting somewhere, and this looks a bit weird to me. > Did this ever happen to any of you? Do you have ideas? I think this might be due to missing route: objects for your announcements. I see that you created them for the separate /23s a few hours ago, so you should wait for the upstreams to pick them, which might happen in the next 24 hours, so they can adjust their filters. You could also hope that some engineers pick it up here on list - as you asked - and adjusts filters before the scheduled time comes. Ciao! -- Massimiliano Stucchi MS16801-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From john at hypergeek.net Fri Nov 18 18:54:51 2016 From: john at hypergeek.net (John A. Kilpatrick) Date: Fri, 18 Nov 2016 10:54:51 -0800 (PST) Subject: China to HK providers you like? Message-ID: It's been a while since I've had to look at mainland China connectivity - what is the current situation for point-to-point business circuits from China domestic locations to a datacenter in HK? Does anyone have providers they like? -- John A. Kilpatrick john at hypergeek.net | http://www.hypergeek.net/ remember: no obstacles/only challenges From spano at datacast.it Fri Nov 18 19:39:57 2016 From: spano at datacast.it (spano at datacast.it) Date: Fri, 18 Nov 2016 19:39:57 +0000 Subject: R: Re: Autunomous system filtering? In-Reply-To: References: <201A093F-2075-4DAF-A398-E8F93440892E@datacast.it> Message-ID: <1816644451-1479496875-cardhu_decombobulator_blackberry.rim.net-2003790906-@b1.c2.bise7.blackberry> Thank you Massimiliano. Consider that when we were announcing the whole /22 everything was working correctly, then suddenly some ASs stopped to accept our prefixes. That's why we decided to split the network and announce prefixes with different AS. Moreover the /23 announced by AS2876 spreaded correctly, even if the object has been created at the same time as the other... Ciao! :) Le mail ti raggiungono ovunque con BlackBerry? from Vodafone! -----Original Message----- From: Massimiliano Stucchi Sender: "NANOG" Date: Fri, 18 Nov 2016 19:36:53 To: Reply-To: max at stucchi.ch Subject: Re: Autunomous system filtering? Hi, On 18/11/16 19:04, Giuseppe Span? - Datacast Srl wrote: > AS2876 announces 185.85.20.0/23 > AS207029 announces 185.85.22.0/23 (those prefixes are idle at the moment) > It seems an AS filtering is acting somewhere, and this looks a bit weird to me. > Did this ever happen to any of you? Do you have ideas? I think this might be due to missing route: objects for your announcements. I see that you created them for the separate /23s a few hours ago, so you should wait for the upstreams to pick them, which might happen in the next 24 hours, so they can adjust their filters. You could also hope that some engineers pick it up here on list - as you asked - and adjusts filters before the scheduled time comes. Ciao! -- Massimiliano Stucchi MS16801-RIPE From jordi.palet at consulintel.es Fri Nov 18 20:05:43 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 19 Nov 2016 05:05:43 +0900 Subject: pay.gov and IPv6 In-Reply-To: <1479493373.7178.35.camel@ns.five-ten-sg.com> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> <1479493373.7178.35.camel@ns.five-ten-sg.com> Message-ID: <97BDEF32-892B-48AE-8AA2-C663CF1CD9E0@consulintel.es> I tested from my home and happy eyeballs is not falling back to IPv4. So, I tend to suspect that is not ICMPv6 filtering, but something else, such as wrong load balancer or ECMP configuration. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Carl Byington Responder a: Fecha: s?bado, 19 de noviembre de 2016, 3:22 Para: Asunto: Re: pay.gov and IPv6 > > I am working with pay.gov.clev at clev.frb.org, trying to explain the > problem. The intersection of government bureaucracy and technical issues is frustrating to say the least. I just sent the message below, but have no expectation that it will change anything. ============== On Fri, 2016-11-18 at 12:39 +0000, CLEV Pay Gov wrote: > It would be best to discuss this via phone. Please contact our help > desk at the number below and we could see if there's anything we could > do over the phone to help troubleshoot. That is hopeless. Verbal technical discussions rarely work unless both sides can see the same text. Have you ever tried (while talking on the phone) to get someone to type in clev.frb.org without making a bunch of mistakes in the spelling?? Anyway, just for my amusement, I did call 800-624-1373, Option #2, and am on the line now, trying to explain this. 10 minutes and counting. Ok, there does not seem to be any overall ticket for "pay.gov does not work at all". They refuse to open a tech support ticket. > If not, we may need to open a ticket for our technical support. Please open a ticket, and attach the following text for your tech support folks. Alternatively, have them look at the "pay.gov and ipv6" thread on nanog: http://mailman.nanog.org/pipermail/nanog/2016-November/thread.html www.pay.gov has an IPv6 address of 2605:3100:fffd:100::15, but that machine or its upstream routers are filtering icmpv6 messages. That web site is not accessible from systems with an MTU of 1280 bytes. The test case is: echo -e 'GET /public/home HTTP/1.0\n' | \ openssl s_client -servername www.pay.gov -ign_eof -connect \ '[2605:3100:fffd:100::15]:443' Run that (or just use a browser to try https://www.pay.gov) from a system with a 1500 byte MTU, and it works. Run it from a system with upstream connectivity via a tunnel, so the path MTU is smaller, and it fails. Such tunnels are common for IPv6. Please stop filtering icmpv6. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From yang.yu.list at gmail.com Fri Nov 18 20:36:34 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Fri, 18 Nov 2016 14:36:34 -0600 Subject: Autunomous system filtering? In-Reply-To: <1816644451-1479496875-cardhu_decombobulator_blackberry.rim.net-2003790906-@b1.c2.bise7.blackberry> References: <201A093F-2075-4DAF-A398-E8F93440892E@datacast.it> <1816644451-1479496875-cardhu_decombobulator_blackberry.rim.net-2003790906-@b1.c2.bise7.blackberry> Message-ID: On Fri, Nov 18, 2016 at 1:39 PM, wrote: > Consider that when we were announcing the whole /22 everything was working correctly, then suddenly some ASs stopped to accept our prefixes. That's why we decided to split the network and announce prefixes with different AS. Moreover the /23 announced by AS2876 spreaded correctly, even if the object has been created at the same time as the other... around 11/16 16:00UTC, 185.85.20.0/22's originating ASN changed from AS28716 to AS207029 The route object for 185.85.20.0/22 had origin changed from AS28716 to AS207029 at 2016-11-16T15:09:22Z but AS207029 was not in AS-RETELIT (it is now 2016-11-18T14:34:44Z). So when AS28716's upstreams rebuilt the inbound filter, 185.85.20.0/22 got dropped. When AS28716's upstreams update the filter again, 185.85.22.0/23 should become visible. It looks like the route object for 185.85.20.0/22 has been deleted. Is there a whowas service for routing registries? Yang From rod.beck at unitedcablecompany.com Fri Nov 18 20:51:03 2016 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 18 Nov 2016 20:51:03 +0000 Subject: China to HK providers you like? In-Reply-To: References: Message-ID: PCCW might be a good choice given that Hong Kong is the gateway to China. ________________________________ From: NANOG on behalf of John A. Kilpatrick Sent: Friday, November 18, 2016 7:54 PM To: nanog at nanog.org Subject: China to HK providers you like? It's been a while since I've had to look at mainland China connectivity - what is the current situation for point-to-point business circuits from China domestic locations to a datacenter in HK? Does anyone have providers they like? -- John A. Kilpatrick john at hypergeek.net | http://www.hypergeek.net/ Hypergeek.net www.hypergeek.net A lot of this ride covered the area from my Sunday ride last weekend. We headed south along Blossom Hill until it turned into Santa Theresa - going in the opposite ... remember: no obstacles/only challenges From marka at isc.org Fri Nov 18 20:58:51 2016 From: marka at isc.org (Mark Andrews) Date: Sat, 19 Nov 2016 07:58:51 +1100 Subject: pay.gov and IPv6 In-Reply-To: Your message of "Fri, 18 Nov 2016 19:11:06 +0100." <87twb4slol.fsf@mid.deneb.enyo.de> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <87twb4slol.fsf@mid.deneb.enyo.de> Message-ID: <20161118205851.106695A76A83@rock.dv.isc.org> In message <87twb4slol.fsf at mid.deneb.enyo.de>, Florian Weimer writes: > * Mark Andrews: > > > The DNSSEC testing is also insufficient. 9-11commission.gov shows > > green for example but if you use DNS COOKIES (which BIND 9.10.4 and > > BIND 9.11.0 do) then servers barf and return BADVERS and validation > > fails. QWEST you have been informed of this already. > > > > Why the hell should validating resolver have to work around the > > crap you guys are using? > > The protocol doesn't have proper version negotation, and again and > again, implementers have tried to force backwards-incompatible > implementations on the Internet at large. The servers talk EDNS. They server signed zones which require EDNS support. These are EDNS version 0 queries. BADVERS is the response code for when you receive a EDNS version field higher than the one you implement and it requires that you use EDNS to send the rcode. The query has a EDNS version field of 0. The response has a EDNS version field of 0. The response has a rcode of BADVERS. Yes, the behaviour of how to handle unknown options was clarified in RFC 6891. With RFC 2671 nameserver developer had a choice to make * BADVERS was never a sensible response however. BADVERS had explict instructions for when it should be sent and they didn't include "if there is a EDNS option you don't understand return BADVERS". If you thought the version field was wrong then that made it a malformed request which should elicit a FORMERR. * FORMERR also wasn't a good idea. RFC 2671 didn't say that no options could be added to a EDNS version 1 query but I can see if you thought EDNS version 0 was not allowed to have EDNS options that it could be seen as a malformed record. Unless you know the format of the option you can't sensibly return FORMERR on it. * NOTIMP would have made sense before RFC 6891 was published but we never saw a implementation that did this. * Echoing back the option made some sense, though sending a option that you don't understand is risky. * Ignoring the option also made sense. This is what RFC 6891 says to do and matches the unknown EDNS flags behaviour. * Ask the working group / IETF. I wouldn't be complaining about it if they were only supporting plain DNS. You can tell the difference between a server that supports EDNS and one that doesn't. They behave differently. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From erich at gotfusion.net Sat Nov 19 20:02:15 2016 From: erich at gotfusion.net (Kaiser, Erich) Date: Sat, 19 Nov 2016 14:02:15 -0600 Subject: peeringdb contact me please Message-ID: Anyone out there from PeeringDB, please contact me offlist, we are having trouble updating our records. Erich Kaiser The Fusion Network erich at gotfusion.net Office: 630-621-4804 Cell: 630-777-9291 From job at instituut.net Sat Nov 19 20:09:21 2016 From: job at instituut.net (Job Snijders) Date: Sat, 19 Nov 2016 21:09:21 +0100 Subject: peeringdb contact me please In-Reply-To: References: Message-ID: <20161119200921.GP1072@dhcp-9341.meeting.ietf.org> Hi Erich, everyone, On Sat, Nov 19, 2016 at 02:02:15PM -0600, Kaiser, Erich wrote: > Anyone out there from PeeringDB, please contact me offlist, we are > having trouble updating our records. You can reach PeeringDB support at support at peeringdb.com. Feel free to CC me. Kind regards, Job From sfan at chtsc.net Sat Nov 19 06:10:45 2016 From: sfan at chtsc.net (Steve SY Fan) Date: Sat, 19 Nov 2016 14:10:45 +0800 Subject: China to HK providers you like? In-Reply-To: References: Message-ID: <36C986F3-55A6-46EA-AEDC-7B59858173F4@chtsc.net> You asking for a close circuit, point-to-point one? B'rgds Sent from my mobile device > On Nov 19, 2016, at 4:51 AM, Rod Beck wrote: > > PCCW might be a good choice given that Hong Kong is the gateway to China. > > > ________________________________ > From: NANOG on behalf of John A. Kilpatrick > Sent: Friday, November 18, 2016 7:54 PM > To: nanog at nanog.org > Subject: China to HK providers you like? > > > It's been a while since I've had to look at mainland China connectivity - > what is the current situation for point-to-point business circuits from > China domestic locations to a datacenter in HK? Does anyone have > providers they like? > > > -- > John A. Kilpatrick > john at hypergeek.net | http://www.hypergeek.net/ > Hypergeek.net > www.hypergeek.net > A lot of this ride covered the area from my Sunday ride last weekend. We headed south along Blossom Hill until it turned into Santa Theresa - going in the opposite ... > > > remember: no obstacles/only challenges > > From vstipo at gmail.com Sat Nov 19 06:57:53 2016 From: vstipo at gmail.com (Stipo) Date: Sat, 19 Nov 2016 06:57:53 +0000 Subject: China to HK providers you like? In-Reply-To: References: Message-ID: Afaik, PCCW, China Telecom, China Mobile, and China Unicom are all good options, depending on where in mainland you are attempting to reach. On Fri, Nov 18, 2016 at 12:52 PM Rod Beck wrote: > PCCW might be a good choice given that Hong Kong is the gateway to China. > > > ________________________________ > From: NANOG on behalf of John A. Kilpatrick < > john at hypergeek.net> > Sent: Friday, November 18, 2016 7:54 PM > To: nanog at nanog.org > Subject: China to HK providers you like? > > > It's been a while since I've had to look at mainland China connectivity - > what is the current situation for point-to-point business circuits from > China domestic locations to a datacenter in HK? Does anyone have > providers they like? > > > -- > John A. Kilpatrick > john at hypergeek.net | http://www.hypergeek.net/ > Hypergeek.net < > http://www.hypergeek.net/> > www.hypergeek.net > A lot of this ride covered the area from my Sunday ride last weekend. We > headed south along Blossom Hill until it turned into Santa Theresa - going > in the opposite ... > > > remember: no obstacles/only challenges > > > From vas at mpeks.tomsk.su Sat Nov 19 13:10:05 2016 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Sat, 19 Nov 2016 20:10:05 +0700 Subject: nested prefixes in Internet In-Reply-To: References: Message-ID: <20161119131005.GA29511@admin.sibptus.transneft.ru> Martin T wrote: > > let's assume that there is an ISP "A" operating in Europe region who > has /19 IPv4 allocation from RIPE. From this /19 they have leased /24 > to ISP "B" who is multi-homed. This means that ISP "B" would like to > announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this > gives two possibilities: > > 1) Deaggregate /19 in ISP "A" network and create "inetnum" and "route" > objects for all those networks to RIPE database. This means that ISP > "A" announces around dozen IPv4 prefixes to Internet except this /24 > and ISP "B" announces this specific /24 to Internet. > > 2) ISP "A" continues to announce this /19 to Internet and at the same > time ISP "B" starts to announce /24 to Internet. As this /24 is > more-specific than /19, then traffic to hosts in this /24 will end up > in ISP "B" network. Excuse me for intruding on American Operators from Siberia, but I find this topic very interesting. I have reports that in case (2), some operators (e.g. Rostelecom) don't accept the /24 or even /23 prefix on the grounds that it is part of a larger /19 route already present in the routing table. Could they have a reason not to accept these more specific prefixes other than a whim? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov at sibptus.tomsk.ru From rich at lafferty.ca Sat Nov 19 16:13:30 2016 From: rich at lafferty.ca (Rich Lafferty) Date: Sat, 19 Nov 2016 11:13:30 -0500 Subject: Bell Canada contact - need help with DNS issue References: Message-ID: <57358217-3DA0-4AFC-95F7-29943651B3D7@lafferty.ca> Hi, Does anyone have a NOC or DNS administrator contact at Bell Canada? Their Toronto nameservers are returning SERVFAIL for our domain freshbooks.com since a general Bell DNS issue midday yesterday. $ dig freshbooks.com @207.164.234.129 ; <<>> DiG 9.8.3-P1 <<>> freshbooks.com @207.164.234.129 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54893 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;freshbooks.com. IN A ;; Query time: 305 msec ;; SERVER: 207.164.234.129#53(207.164.234.129) ;; WHEN: Sat Nov 19 10:44:59 2016 ;; MSG SIZE rcvd: 32 No-one outside Bell is reporting issues, and other domains (ours or otherwise) are fine on Bell?s name servers. Thanks, -Rich -- Rich Lafferty Director of IT, FreshBooks - rich at freshbooks.com http://www.freshbooks.com/ Toll-free: (866) 303-6061 Phone: (416) 780-2700 x233 From frnkblk at iname.com Sun Nov 20 02:13:13 2016 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 19 Nov 2016 20:13:13 -0600 Subject: BCP 38 coverage if top x providers ... Message-ID: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> My google fu is failing me, but I believe there was a NANOG posting a year or two ago that mentioned that if the top x providers would implement BCP 38 then y% of the traffic (or Internet) would be de-spoofed. The point was that we don't even need everyone to implement BCP 38, but if the largest (transit?) providers did it, then UDP reflection attacks could be minimized. If someone can recall the key words in that posting and dig it up, that would be much appreciated. Frank From jordi.palet at consulintel.es Sun Nov 20 09:51:16 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 20 Nov 2016 10:51:16 +0100 Subject: pay.gov and IPv6 In-Reply-To: <97BDEF32-892B-48AE-8AA2-C663CF1CD9E0@consulintel.es> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> <1479493373.7178.35.camel@ns.five-ten-sg.com> <97BDEF32-892B-48AE-8AA2-C663CF1CD9E0@consulintel.es> Message-ID: Somebody pointed to me that even happy eyeballs will not fall back to IPv4 when PMTUD is blocked ? This is a big issue, many folks are deploying IPv6 web sites, and not double-checking this. Actually, this is VERY BIG issue with all the 1&1 sites. I tried to contact them many times for more than a year, and they seem to not care, so clearly not a recommended hosting provider, as they don?t care about the quality of service that their customers have. I will change my mind if someone from 1&1 is finally responding, in case they are in this list ? For example, you will not get this working if you have a lower MTU than 1.500, which is quite normal, not just for tunnels, but also because the PPP/others encapsulation in many access links: http://diskmakerx.com/ Furthermore, I mention this filtering problem in the article about the IPv6 survey results, for those that don?t follow RIPE LABS site: https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-survey Regards, Jordi -----Mensaje original----- De: NANOG en nombre de JORDI PALET MARTINEZ Responder a: Fecha: viernes, 18 de noviembre de 2016, 21:05 Para: Asunto: Re: pay.gov and IPv6 I tested from my home and happy eyeballs is not falling back to IPv4. So, I tend to suspect that is not ICMPv6 filtering, but something else, such as wrong load balancer or ECMP configuration. Regards, Jordi -----Mensaje original----- De: NANOG en nombre de Carl Byington Responder a: Fecha: s?bado, 19 de noviembre de 2016, 3:22 Para: Asunto: Re: pay.gov and IPv6 > > I am working with pay.gov.clev at clev.frb.org, trying to explain the > problem. The intersection of government bureaucracy and technical issues is frustrating to say the least. I just sent the message below, but have no expectation that it will change anything. ============== On Fri, 2016-11-18 at 12:39 +0000, CLEV Pay Gov wrote: > It would be best to discuss this via phone. Please contact our help > desk at the number below and we could see if there's anything we could > do over the phone to help troubleshoot. That is hopeless. Verbal technical discussions rarely work unless both sides can see the same text. Have you ever tried (while talking on the phone) to get someone to type in clev.frb.org without making a bunch of mistakes in the spelling?? Anyway, just for my amusement, I did call 800-624-1373, Option #2, and am on the line now, trying to explain this. 10 minutes and counting. Ok, there does not seem to be any overall ticket for "pay.gov does not work at all". They refuse to open a tech support ticket. > If not, we may need to open a ticket for our technical support. Please open a ticket, and attach the following text for your tech support folks. Alternatively, have them look at the "pay.gov and ipv6" thread on nanog: http://mailman.nanog.org/pipermail/nanog/2016-November/thread.html www.pay.gov has an IPv6 address of 2605:3100:fffd:100::15, but that machine or its upstream routers are filtering icmpv6 messages. That web site is not accessible from systems with an MTU of 1280 bytes. The test case is: echo -e 'GET /public/home HTTP/1.0\n' | \ openssl s_client -servername www.pay.gov -ign_eof -connect \ '[2605:3100:fffd:100::15]:443' Run that (or just use a browser to try https://www.pay.gov) from a system with a 1500 byte MTU, and it works. Run it from a system with upstream connectivity via a tunnel, so the path MTU is smaller, and it fails. Such tunnels are common for IPv6. Please stop filtering icmpv6. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From surfer at mauigateway.com Sun Nov 20 20:19:35 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 20 Nov 2016 12:19:35 -0800 Subject: list scrap by long time participant? Message-ID: <20161120121935.5456E0CC@m0087792.ppops.net> --- Begin forwarded message: Hi Ladies and Gentlemen, We have three of the top five transit providers in our portfolio: Telia, Cogent, and GTT. Also NTT, Telecom Italia, and PCCW. Telia pricing is attractive given the quality of the product. Contact me for further details. --------------------------------------------------------- Did anyone get this? I hesitate to think a long time NANOG participant sent me this. NANOG is the only way he would've gotten my email address. scott From job at instituut.net Sun Nov 20 20:52:36 2016 From: job at instituut.net (Job Snijders) Date: Sun, 20 Nov 2016 21:52:36 +0100 Subject: list scrap by long time participant? In-Reply-To: <20161120121935.5456E0CC@m0087792.ppops.net> References: <20161120121935.5456E0CC@m0087792.ppops.net> Message-ID: <20161120205236.GB1100@Vurt.local> On Sun, Nov 20, 2016 at 12:19:35PM -0800, Scott Weeks wrote: > --- Begin forwarded message: > > Hi Ladies and Gentlemen, > > XXXX. > Contact me for further details. > --------------------------------------------------------- > > Did anyone get this? I hesitate to think a long time NANOG > participant sent me this. NANOG is the only way he would've gotten my > email address. > > scott Scott, everyone, If you receive spam or other crap, and you suspect it is because of your NANOG mailing list membership, please reach out to admins at nanog.org. Kind regards, Job From carl at five-ten-sg.com Mon Nov 21 00:07:15 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Sun, 20 Nov 2016 16:07:15 -0800 Subject: pay.gov and IPv6 In-Reply-To: References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> <1479493373.7178.35.camel@ns.five-ten-sg.com> <97BDEF32-892B-48AE-8AA2-C663CF1CD9E0@consulintel.es> Message-ID: <1479686835.13553.4.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote: > For example, you will not get this working if you have a lower MTU > than 1.500, which is quite normal, not just for tunnels, but also > because the PPP/others encapsulation in many access links: > http://diskmakerx.com/ curl -6 -v http://diskmakerx.com/ That works here via an he.net tunnel. Perhaps 1and1 fixed something. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgyOp4ACgkQL6j7milTFsFslACfaRbslKuUHrxGJyuI+j8X/Sle AZ8AoIg2wF/GWBdDtphQSuD9/gGMDfOA =4nAp -----END PGP SIGNATURE----- From marka at isc.org Mon Nov 21 00:26:34 2016 From: marka at isc.org (Mark Andrews) Date: Mon, 21 Nov 2016 11:26:34 +1100 Subject: pay.gov and IPv6 In-Reply-To: Your message of "Sun, 20 Nov 2016 16:07:15 -0800." <1479686835.13553.4.camel@ns.five-ten-sg.com> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> <1479493373.7178.35.camel@ns.five-ten-sg.com> <97BDEF32-892B-48AE-8AA2-C663CF1CD9E0@consulintel.es> <1479686835.13553.4.camel@ns.five-ten-sg.com> Message-ID: <20161121002634.2128F5A93C7F@rock.dv.isc.org> In message <1479686835.13553.4.camel at ns.five-ten-sg.com>, Carl Byington writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote: > > For example, you will not get this working if you have a lower MTU > > than 1.500, which is quite normal, not just for tunnels, but also > > because the PPP/others encapsulation in many access links: > > > http://diskmakerx.com/ > > curl -6 -v http://diskmakerx.com/ > > That works here via an he.net tunnel. Perhaps 1and1 fixed something. And the advertised MSS was what? On my box I'm seeing 1220 for IPv6 compared with 1460 for IPv4. 1220 shouldn't see PMTU problems. 1460 on the other hand will cause problems as more clients are forced behind IPv4 as a service links. 11:14:50.056215 IP 172.30.42.121.52280 > 217.160.0.214.80: Flags [S], seq 2115844511, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 538455715 ecr 0,sackOK,eol], length 0 11:14:50.137770 IP6 2001:470:a001:4:c00d:3d8c:14e7:6de3.52282 > 2001:8d8:100f:f000::2d5.80: Flags [S], seq 4181372812, win 65535, options [mss 1220,nop,wscale 4,nop,nop,TS val 538455793 ecr 0,sackOK,eol], length 0 Mark > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlgyOp4ACgkQL6j7milTFsFslACfaRbslKuUHrxGJyuI+j8X/Sle > AZ8AoIg2wF/GWBdDtphQSuD9/gGMDfOA > =4nAp > -----END PGP SIGNATURE----- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From carl at five-ten-sg.com Mon Nov 21 01:03:41 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Sun, 20 Nov 2016 17:03:41 -0800 Subject: pay.gov and IPv6 In-Reply-To: <20161121002634.2128F5A93C7F@rock.dv.isc.org> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> <1479493373.7178.35.camel@ns.five-ten-sg.com> <97BDEF32-892B-48AE-8AA2-C663CF1CD9E0@consulintel.es> <1479686835.13553.4.camel@ns.five-ten-sg.com> <20161121002634.2128F5A93C7F@rock.dv.isc.org> Message-ID: <1479690221.13553.18.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Mon, 2016-11-21 at 11:26 +1100, Mark Andrews wrote: > And the advertised MSS was what? On my box I'm seeing 1220 for > IPv6 compared with 1460 for IPv4. 1220 shouldn't see PMTU problems. --> 2001:8d8:100f:f000::2d5 syn w/ mss 1440 <-- 2001:8d8:100f:f000::2d5 syn,ack w/ mss 1420 --> 2001:8d8:100f:f000::2d5 ack --> 2001:8d8:100f:f000::2d5 GET / HTTP/1.1 <-- 2001:8d8:100f:f000::2d5 ack <-- 2001:8d8:100f:f000::2d5 data... data is a 1480 byte ipv6 packet: ip6.header.payload.length = 1440 which is the tcp packet tcp.header.length = 32 bytes tcp.data.size = 1408 bytes (http response) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlgyRUYACgkQL6j7milTFsH8tgCeLB9E9C2pjFqgp1w2YpipmvzZ ib4Ani/cQmAgEo3QPfA9hMntGq4VLoO/ =mmCW -----END PGP SIGNATURE----- From jfmezei_nanog at vaxination.ca Mon Nov 21 06:58:57 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 21 Nov 2016 01:58:57 -0500 Subject: Voice channels (FTTH, DOCSIS, VoLTE) Message-ID: <58329B31.3070806@vaxination.ca> I need to verify some claims made by incumbents in Canada that VoLTE data travels on a totally separate channel between the phone and the antenna. Does anyone have links to relevant VoLTE documentation that would provide how VoLTE is provisioned ? I was under the impression that it was more of an "app" on the phone that used the same IP address given for access to Internet. Does the phone get a separate IP and possibly separate VLAN with dedicated bandwidth to ensure voice call quality? Or are all the performance tricks done on land beyond the antenna once the packets are identified as VoLTE, but the phone itself just treats them as a normal app ? I know that for FTTH, there is a separate "channel" where the "POTS" emulation can be provided with its own dedicated IP and bandwidth. Would DOCSIS be the same as FTTH, with the cableco voice service riding isnide the same DOCSIS bandwidth but with pre-allocated bandwidth, or do they allocate separate NTSC channels with a totally separate data pipe ? (in which case, in systems with only 42mhz of uplink frequencies, the voice would have its own NTSC channel on uplink? From saper at saper.info Mon Nov 21 07:39:07 2016 From: saper at saper.info (Marcin Cieslak) Date: Mon, 21 Nov 2016 07:39:07 +0000 Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: <58329B31.3070806@vaxination.ca> References: <58329B31.3070806@vaxination.ca> Message-ID: On Mon, 21 Nov 2016, Jean-Francois Mezei wrote: > Would DOCSIS be the same as FTTH, with the cableco voice service riding > isnide the same DOCSIS bandwidth but with pre-allocated bandwidth, or do > they allocate separate NTSC channels with a totally separate data pipe ? DOCSIS has a possibility to provision unidirectional data flows with certain quality of service characteristics. A pair of these is usually dedicated to a casual Internet connection, another one can be used for layer 2 telephony service, etc. Allocating a whole TV channel frequency would be a big waste. Not even sure it would be possible with standard DOCSIS. Marcin Cie?lak From jordi.palet at consulintel.es Mon Nov 21 07:51:16 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 21 Nov 2016 08:51:16 +0100 Subject: pay.gov and IPv6 In-Reply-To: <20161121002634.2128F5A93C7F@rock.dv.isc.org> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> <1479493373.7178.35.camel@ns.five-ten-sg.com> <97BDEF32-892B-48AE-8AA2-C663CF1CD9E0@consulintel.es> <1479686835.13553.4.camel@ns.five-ten-sg.com> <20161121002634.2128F5A93C7F@rock.dv.isc.org> Message-ID: <44B615BC-8CE7-41D9-8165-95F562B496C7@consulintel.es> Tested again from four different networks. Not working for me. Same in other web sites hosted by 1&1 (for example www.legalveritas.es). All their IPv6 web sites are broken, every time I need to access their web sites, need to disable IPv6, I know how to do that, but regular folks not. tbit from 2001:df0:4:4000::1:115 to 2001:8d8:100f:f000::2d5 server-mss 1420, result: pmtud-fail app: http, url: http://diskmakerx.com/ [ 0.010] TX SYN 64 seq = 0:0 [ 0.286] RX SYN/ACK 64 seq = 0:1 [ 0.286] TX 60 seq = 1:1 [ 0.297] TX 233 seq = 1:1(173) [ 0.573] RX 60 seq = 1:174 [ 0.799] RX 1480 seq = 1:174(1420) [ 0.799] RX 73 seq = 1421:174(13) [ 0.799] RX 1480 seq = 1434:174(1420) [ 0.799] RX 1480 seq = 2854:174(1420) [ 0.799] TX PTB 1280 mtu = 1280 [ 0.799] RX 1480 seq = 4274:174(1420) [ 0.799] RX 1480 seq = 5694:174(1420) [ 0.799] RX 1480 seq = 7114:174(1420) [ 0.801] RX 1480 seq = 8534:174(1420) [ 0.809] TX 60 seq = 174:1 [ 0.821] RX 1480 seq = 9954:174(1420) [ 0.824] RX 1480 seq = 11374:174(1420) [ 1.628] RX 1480 seq = 1:174(1420) [ 1.629] TX PTB 1280 mtu = 1280 [ 3.288] RX 1480 seq = 1:174(1420) [ 3.288] TX PTB 1280 mtu = 1280 [ 6.612] RX 1480 seq = 1:174(1420) [ 6.612] TX PTB 1280 mtu = 1280 [ 13.252] RX 1480 seq = 1:174(1420) Regards, Jordi -----Mensaje original----- De: Mark Andrews Responder a: Fecha: lunes, 21 de noviembre de 2016, 1:26 Para: Carl Byington CC: , Asunto: Re: pay.gov and IPv6 In message <1479686835.13553.4.camel at ns.five-ten-sg.com>, Carl Byington writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote: > > For example, you will not get this working if you have a lower MTU > > than 1.500, which is quite normal, not just for tunnels, but also > > because the PPP/others encapsulation in many access links: > > > http://diskmakerx.com/ > > curl -6 -v http://diskmakerx.com/ > > That works here via an he.net tunnel. Perhaps 1and1 fixed something. And the advertised MSS was what? On my box I'm seeing 1220 for IPv6 compared with 1460 for IPv4. 1220 shouldn't see PMTU problems. 1460 on the other hand will cause problems as more clients are forced behind IPv4 as a service links. 11:14:50.056215 IP 172.30.42.121.52280 > 217.160.0.214.80: Flags [S], seq 2115844511, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 538455715 ecr 0,sackOK,eol], length 0 11:14:50.137770 IP6 2001:470:a001:4:c00d:3d8c:14e7:6de3.52282 > 2001:8d8:100f:f000::2d5.80: Flags [S], seq 4181372812, win 65535, options [mss 1220,nop,wscale 4,nop,nop,TS val 538455793 ecr 0,sackOK,eol], length 0 Mark > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlgyOp4ACgkQL6j7milTFsFslACfaRbslKuUHrxGJyuI+j8X/Sle > AZ8AoIg2wF/GWBdDtphQSuD9/gGMDfOA > =4nAp > -----END PGP SIGNATURE----- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From swmike at swm.pp.se Mon Nov 21 07:53:41 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 21 Nov 2016 08:53:41 +0100 (CET) Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: <58329B31.3070806@vaxination.ca> References: <58329B31.3070806@vaxination.ca> Message-ID: On Mon, 21 Nov 2016, Jean-Francois Mezei wrote: > I need to verify some claims made by incumbents in Canada that VoLTE > data travels on a totally separate channel between the phone and the > antenna. Typically it travels on another "bearer" compared to Internet traffic. http://blog.3g4g.co.uk/2013/08/volte-bearers.html Think of bearers as "tunnels" between the mobile core network and the device. They have a lot in common with ATM PVCs in that they can have different QoS characteristics. So the VoLTE bearer can have scheduling priorities that means it'll always be low-latency and highest priority, meaning it might work well when the "Internet" bearer does not. -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Mon Nov 21 08:07:37 2016 From: joelja at bogus.com (joel jaeggli) Date: Mon, 21 Nov 2016 00:07:37 -0800 Subject: pay.gov and IPv6 In-Reply-To: <44B615BC-8CE7-41D9-8165-95F562B496C7@consulintel.es> References: <1479249003.3937.6.camel@ns.five-ten-sg.com> <20161116202357.4096B5A4FCB4@rock.dv.isc.org> <20161117002622.74D825A57884@rock.dv.isc.org> <20161117022647.623D25A5A911@rock.dv.isc.org> <1479426029.8037.10.camel@ns.five-ten-sg.com> <1479493373.7178.35.camel@ns.five-ten-sg.com> <97BDEF32-892B-48AE-8AA2-C663CF1CD9E0@consulintel.es> <1479686835.13553.4.camel@ns.five-ten-sg.com> <20161121002634.2128F5A93C7F@rock.dv.isc.org> <44B615BC-8CE7-41D9-8165-95F562B496C7@consulintel.es> Message-ID: <03194760-e786-c293-fc34-b8c8c25654b5@bogus.com> 00:02:02.758900 IP6 2601:647:4201:XXXX.60962 > 2605:3100:fffd:100::15.443: Flags [S], seq 2375673666, win 65535, options [mss 1440,nop,wscale 5,nop,nop,TS val 568401205 ecr 0,sackOK,eol], length 0 00:02:02.811619 IP6 2605:3100:fffd:100::15.443 > 2601:647:4201:XXXX.60962: Flags [S.], seq 2570148804, ack 2375673667, win 4320, options [mss 1440,nop,nop,TS val 2246573166 ecr 568401205,sackOK,eol], length 0 it's happy to do 1440 which is unsprising, as1239 is probably not therefore the source of the pmtud hole. On 11/20/16 11:51 PM, JORDI PALET MARTINEZ wrote: > Tested again from four different networks. Not working for me. > > Same in other web sites hosted by 1&1 (for example www.legalveritas.es). All their IPv6 web sites are broken, every time I need to access their web sites, need to disable IPv6, I know how to do that, but regular folks not. > > tbit from 2001:df0:4:4000::1:115 to 2001:8d8:100f:f000::2d5 > server-mss 1420, result: pmtud-fail > app: http, url: http://diskmakerx.com/ > [ 0.010] TX SYN 64 seq = 0:0 > [ 0.286] RX SYN/ACK 64 seq = 0:1 > [ 0.286] TX 60 seq = 1:1 > [ 0.297] TX 233 seq = 1:1(173) > [ 0.573] RX 60 seq = 1:174 > [ 0.799] RX 1480 seq = 1:174(1420) > [ 0.799] RX 73 seq = 1421:174(13) > [ 0.799] RX 1480 seq = 1434:174(1420) > [ 0.799] RX 1480 seq = 2854:174(1420) > [ 0.799] TX PTB 1280 mtu = 1280 > [ 0.799] RX 1480 seq = 4274:174(1420) > [ 0.799] RX 1480 seq = 5694:174(1420) > [ 0.799] RX 1480 seq = 7114:174(1420) > [ 0.801] RX 1480 seq = 8534:174(1420) > [ 0.809] TX 60 seq = 174:1 > [ 0.821] RX 1480 seq = 9954:174(1420) > [ 0.824] RX 1480 seq = 11374:174(1420) > [ 1.628] RX 1480 seq = 1:174(1420) > [ 1.629] TX PTB 1280 mtu = 1280 > [ 3.288] RX 1480 seq = 1:174(1420) > [ 3.288] TX PTB 1280 mtu = 1280 > [ 6.612] RX 1480 seq = 1:174(1420) > [ 6.612] TX PTB 1280 mtu = 1280 > [ 13.252] RX 1480 seq = 1:174(1420) > > > > Regards, > Jordi > > > -----Mensaje original----- > De: Mark Andrews > Responder a: > Fecha: lunes, 21 de noviembre de 2016, 1:26 > Para: Carl Byington > CC: , > Asunto: Re: pay.gov and IPv6 > > > In message <1479686835.13553.4.camel at ns.five-ten-sg.com>, Carl Byington writes: > On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote: > > For example, you will not get this working if you have a lower MTU > > than 1.500, which is quite normal, not just for tunnels, but also > > because the PPP/others encapsulation in many access links: > > > http://diskmakerx.com/ > > curl -6 -v http://diskmakerx.com/ > > That works here via an he.net tunnel. Perhaps 1and1 fixed something. > > > And the advertised MSS was what? On my box I'm seeing 1220 for > > IPv6 compared with 1460 for IPv4. 1220 shouldn't see PMTU problems. > > > 1460 on the other hand will cause problems as more clients are > > forced behind IPv4 as a service links. > > > 11:14:50.056215 IP 172.30.42.121.52280 > 217.160.0.214.80: Flags > [S], seq 2115844511, win 65535, options [mss 1460,nop,wscale > 4,nop,nop,TS val 538455715 ecr 0,sackOK,eol], length 0 > > 11:14:50.137770 IP6 2001:470:a001:4:c00d:3d8c:14e7:6de3.52282 > > 2001:8d8:100f:f000::2d5.80: Flags [S], seq 4181372812, win 65535, > options [mss 1220,nop,wscale 4,nop,nop,TS val 538455793 ecr > 0,sackOK,eol], length 0 > > > Mark > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From niels=nanog at bakker.net Mon Nov 21 12:01:33 2016 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 21 Nov 2016 13:01:33 +0100 Subject: nested prefixes in Internet In-Reply-To: <20161119131005.GA29511@admin.sibptus.transneft.ru> References: <20161119131005.GA29511@admin.sibptus.transneft.ru> Message-ID: <20161121120133.GI45065@excession.tpb.net> * vas at mpeks.tomsk.su (Victor Sudakov) [Sun 20 Nov 2016, 03:07 CET]: >I have reports that in case (2), some operators (e.g. Rostelecom) >don't accept the /24 or even /23 prefix on the grounds that it is >part of a larger /19 route already present in the routing table. > >Could they have a reason not to accept these more specific prefixes >other than a whim? If you announce a prefix you must deliver traffic sent to addresses covered by it. You don't go announcing 0.0.0.0/0 to your peers either. If a customer takes a /24 and announces it elsewhere, a transit provider runs the risk of accepting inbound traffic without having the possibility to bill their customer for it if it accepts more specifics from e.g. a peer. -- Niels. From vas at mpeks.tomsk.su Mon Nov 21 14:08:07 2016 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Mon, 21 Nov 2016 21:08:07 +0700 Subject: nested prefixes in Internet In-Reply-To: <20161121120133.GI45065@excession.tpb.net> References: <20161119131005.GA29511@admin.sibptus.transneft.ru> <20161121120133.GI45065@excession.tpb.net> Message-ID: <20161121140807.GA72524@admin.sibptus.transneft.ru> Niels Bakker wrote: > >I have reports that in case (2), some operators (e.g. Rostelecom) > >don't accept the /24 or even /23 prefix on the grounds that it is > >part of a larger /19 route already present in the routing table. > > > >Could they have a reason not to accept these more specific prefixes > >other than a whim? > > If you announce a prefix you must deliver traffic sent to addresses > covered by it. You don't go announcing 0.0.0.0/0 to your peers either. > > If a customer takes a /24 and announces it elsewhere, a transit > provider runs the risk of accepting inbound traffic without having > the possibility to bill their customer for it if it accepts more > specifics from e.g. a peer. That's all correct from the point of view of the provider annoncing the /19 route, and should be their risk. My question was however from a different perspective. If AS333 receives a /19 from AS111 and a /24 from AS222 (where AS222's /24 is nested within AS111's /19), what reason might AS333 have to ignore the /24? AS333 is not concerned with possible monetary relations between AS111 and AS222. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov at sibptus.tomsk.ru From ryan.nsplist at gmail.com Mon Nov 21 15:41:21 2016 From: ryan.nsplist at gmail.com (Ryan L) Date: Mon, 21 Nov 2016 10:41:21 -0500 Subject: nested prefixes in Internet In-Reply-To: <20161121140807.GA72524@admin.sibptus.transneft.ru> References: <20161119131005.GA29511@admin.sibptus.transneft.ru> <20161121120133.GI45065@excession.tpb.net> <20161121140807.GA72524@admin.sibptus.transneft.ru> Message-ID: Hopefully they would be flexible with this sort of policy under certain circumstances. I could see this as being somewhat problematic for mitigation providers, since longer mask preemption is a commonly used method to take on traffic for scrubbing, as well as customers potentially using a more specific for migration activity. Or heck, even a less corner case scenario of traffic engineering to a particular location via more specific route. To me, it just sounds like more headache than it may be worth to have to deal with that sort of thing. On Mon, Nov 21, 2016 at 9:08 AM, Victor Sudakov wrote: > Niels Bakker wrote: > > >I have reports that in case (2), some operators (e.g. Rostelecom) > > >don't accept the /24 or even /23 prefix on the grounds that it is > > >part of a larger /19 route already present in the routing table. > > > > > >Could they have a reason not to accept these more specific prefixes > > >other than a whim? > > > > If you announce a prefix you must deliver traffic sent to addresses > > covered by it. You don't go announcing 0.0.0.0/0 to your peers either. > > > > If a customer takes a /24 and announces it elsewhere, a transit > > provider runs the risk of accepting inbound traffic without having > > the possibility to bill their customer for it if it accepts more > > specifics from e.g. a peer. > > That's all correct from the point of view of the provider annoncing > the /19 route, and should be their risk. > > My question was however from a different perspective. If AS333 > receives a /19 from AS111 and a /24 from AS222 (where AS222's /24 is > nested within AS111's /19), what reason might AS333 have to ignore the /24? > AS333 is not concerned with possible monetary relations between AS111 > and AS222. > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > sip:sudakov at sibptus.tomsk.ru > From jlewis at lewis.org Mon Nov 21 16:24:20 2016 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 21 Nov 2016 11:24:20 -0500 (EST) Subject: nested prefixes in Internet In-Reply-To: <20161121140807.GA72524@admin.sibptus.transneft.ru> References: <20161119131005.GA29511@admin.sibptus.transneft.ru> <20161121120133.GI45065@excession.tpb.net> <20161121140807.GA72524@admin.sibptus.transneft.ru> Message-ID: On Mon, 21 Nov 2016, Victor Sudakov wrote: > That's all correct from the point of view of the provider annoncing > the /19 route, and should be their risk. > > My question was however from a different perspective. If AS333 > receives a /19 from AS111 and a /24 from AS222 (where AS222's /24 is > nested within AS111's /19), what reason might AS333 have to ignore the /24? > AS333 is not concerned with possible monetary relations between AS111 > and AS222. RIB/FIB bloat. They may figure the least specific route is good enough for getting packets to the destination and assume anything more specific is just the usual pointless deaggregation so commonly seen on the Internet. Maybe they're putting off hardware upgrades required by a current-day unfiltered full table. Maybe there are features that stop working properly on their routers if they load several unfiltered full tables into the RIB. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jra at baylink.com Mon Nov 21 16:26:59 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 21 Nov 2016 16:26:59 +0000 (UTC) Subject: Oracle buys... Dyn. Message-ID: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> Happy Monday. This seems to me to be equivalent (and bad for the same reasons) to cable companies and/or ISPs being co-owned with program providers. http://www.zdnet.com/article/oracle-acquires-dns-provider-dyn-to-take-on-amazons-lead-in-the-cloud How will this affect *your* operations planning, if at all? Am I being overly cynical about Larry Ellison? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jhellenthal at dataix.net Mon Nov 21 17:18:02 2016 From: jhellenthal at dataix.net (J. Hellenthal) Date: Mon, 21 Nov 2016 11:18:02 -0600 Subject: Oracle buys... Dyn. In-Reply-To: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> Message-ID: Don't blame ya I'm a little negative on this one too as I can already "assume" specialized DNS integration with oracle products among possibly ?oracle cloud? Structures spawning up for competition with AWS, Azure ... others but these are just speculations. -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Nov 21, 2016, at 10:26, Jay R. Ashworth wrote: Happy Monday. This seems to me to be equivalent (and bad for the same reasons) to cable companies and/or ISPs being co-owned with program providers. http://www.zdnet.com/article/oracle-acquires-dns-provider-dyn-to-take-on-amazons-lead-in-the-cloud How will this affect *your* operations planning, if at all? Am I being overly cynical about Larry Ellison? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From edugas at unknowndevice.ca Mon Nov 21 17:19:45 2016 From: edugas at unknowndevice.ca (Eric Dugas) Date: Mon, 21 Nov 2016 17:19:45 +0000 Subject: Oracle buys... Dyn. In-Reply-To: References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> Message-ID: I chuckled at "In September, after the release of Oracle's second-generation Infrastructure-as-a-Service (IaaS) datacenters, Oracle CTO Larry Ellison proclaimed that "Amazon's lead is over" in the cloud market." Eric On Nov 21 2016, at 12:18 pm, J. Hellenthal wrote: > Don't blame ya I'm a little negative on this one too as I can already "assume" specialized DNS integration with oracle products among possibly ?oracle cloud? Structures spawning up for competition with AWS, Azure ... others but these are just speculations. > > \-- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN > > On Nov 21, 2016, at 10:26, Jay R. Ashworth wrote: > > Happy Monday. > > This seems to me to be equivalent (and bad for the same reasons) to cable companies and/or ISPs being co-owned with program providers. > > http://www.zdnet.com/article/oracle-acquires-dns-provider-dyn-to-take-on- amazons-lead-in-the-cloud > > How will this affect *your* operations planning, if at all? Am I being overly cynical about Larry Ellison? :-) > > Cheers, \-- jra > > \-- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jhellenthal at dataix.net Mon Nov 21 17:27:57 2016 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 21 Nov 2016 11:27:57 -0600 Subject: Oracle buys... Dyn. In-Reply-To: References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> Message-ID: <18C899CD-AA2A-4032-9747-00B39964401B@dataix.net> Lets just hope so, or Id think that the there will eventually be a price hike by AWS to compensate for Oracle?s outrageous costs. But again only speculation at this point. > On Nov 21, 2016, at 11:22, Akshay Kumar wrote: > > Route53 just uses Dyn and Ultra. I would expect AWS to roll out their own soon. > > On Mon, Nov 21, 2016 at 12:18 PM, J. Hellenthal wrote: > Don't blame ya I'm a little negative on this one too as I can already "assume" specialized DNS integration with oracle products among possibly ?oracle cloud? Structures spawning up for competition with AWS, Azure ... others but these are just speculations. > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Nov 21, 2016, at 10:26, Jay R. Ashworth wrote: > > Happy Monday. > > This seems to me to be equivalent (and bad for the same reasons) to cable > companies and/or ISPs being co-owned with program providers. > > http://www.zdnet.com/article/oracle-acquires-dns-provider-dyn-to-take-on-amazons-lead-in-the-cloud > > How will this affect *your* operations planning, if at all? Am I being > overly cynical about Larry Ellison? :-) > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > -- Jason Hellenthal JJH48-ARIN From rod.beck at unitedcablecompany.com Mon Nov 21 17:34:33 2016 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Mon, 21 Nov 2016 17:34:33 +0000 Subject: Oracle buys... Dyn. In-Reply-To: <18C899CD-AA2A-4032-9747-00B39964401B@dataix.net> References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> , <18C899CD-AA2A-4032-9747-00B39964401B@dataix.net> Message-ID: Oracle has exhibition booths at most web hosting events in Europe. They get very little traffic. Am skeptical they can be a player. - R. ________________________________ From: NANOG on behalf of Jason Hellenthal Sent: Monday, November 21, 2016 6:27 PM To: North American Network Operators' Group Subject: Re: Oracle buys... Dyn. Lets just hope so, or Id think that the there will eventually be a price hike by AWS to compensate for Oracle's outrageous costs. But again only speculation at this point. > On Nov 21, 2016, at 11:22, Akshay Kumar wrote: > > Route53 just uses Dyn and Ultra. I would expect AWS to roll out their own soon. > > On Mon, Nov 21, 2016 at 12:18 PM, J. Hellenthal wrote: > Don't blame ya I'm a little negative on this one too as I can already "assume" specialized DNS integration with oracle products among possibly ?oracle cloud? Structures spawning up for competition with AWS, Azure ... others but these are just speculations. > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Nov 21, 2016, at 10:26, Jay R. Ashworth wrote: > > Happy Monday. > > This seems to me to be equivalent (and bad for the same reasons) to cable > companies and/or ISPs being co-owned with program providers. > > http://www.zdnet.com/article/oracle-acquires-dns-provider-dyn-to-take-on-amazons-lead-in-the-cloud [http://zdnet3.cbsistatic.com/hub/i/r/2016/11/21/28ab95ae-b687-4f4b-8caf-03c9062595ad/thumbnail/770x578/f50013e5a44bbde27721ff1b4d6e562f/screen-shot-2016-11-21-at-13-26-57.jpg] Oracle acquires DNS powerhouse Dyn to take on leading cloud players | ZDNet www.zdnet.com Oracle is a strong player in the datacenter realm, but with this deal, perhaps Larry Ellison's cloud dreams are coming closer. > > How will this affect *your* operations planning, if at all? Am I being > overly cynical about Larry Ellison? :-) > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > -- Jason Hellenthal JJH48-ARIN From eli at siliconsprawl.com Mon Nov 21 18:08:27 2016 From: eli at siliconsprawl.com (Eli Lindsey) Date: Mon, 21 Nov 2016 13:08:27 -0500 Subject: Oracle buys... Dyn. In-Reply-To: <18C899CD-AA2A-4032-9747-00B39964401B@dataix.net> References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> <18C899CD-AA2A-4032-9747-00B39964401B@dataix.net> Message-ID: <1479751707.863028.794871001.00434384@webmail.messagingengine.com> > On Nov 21, 2016, at 11:22, Akshay Kumar wrote: > > Route53 just uses Dyn and Ultra. I would expect AWS to roll out their own soon. This is completely false. -eli From leefuller23 at gmail.com Mon Nov 21 18:22:11 2016 From: leefuller23 at gmail.com (Lee Fuller) Date: Mon, 21 Nov 2016 18:22:11 +0000 Subject: Oracle buys... Dyn. In-Reply-To: <1479751707.863028.794871001.00434384@webmail.messagingengine.com> References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> <18C899CD-AA2A-4032-9747-00B39964401B@dataix.net> <1479751707.863028.794871001.00434384@webmail.messagingengine.com> Message-ID: Yes false. Amazon do use dyn + others for their own domains in addition to their own Route 53 but Route 53 itself is a completely separate service. Kind Regards Lee Fuller (mobile) PGP: 4F58 D91E 3886 2AAA 26F5 17BD FA12 7914 8308 45D0 On 21 Nov 2016 6:16 pm, "Eli Lindsey" wrote: > > On Nov 21, 2016, at 11:22, Akshay Kumar wrote: > > > > Route53 just uses Dyn and Ultra. I would expect AWS to roll out their > own soon. > > This is completely false. > > -eli > From dsp at fb.com Mon Nov 21 18:35:28 2016 From: dsp at fb.com (Doug Porter) Date: Mon, 21 Nov 2016 18:35:28 +0000 Subject: Facebook Geo Routing Issues In-Reply-To: <1291614436.2689.1479347455008.JavaMail.mhammett@ThunderFuck> References: , <1291614436.2689.1479347455008.JavaMail.mhammett@ThunderFuck> Message-ID: Please send details of your mistargeting to me offlist and we'll take a look. Please include the ips of your rdns as observed by . -- dsp ________________________________ From: NANOG on behalf of Mike Hammett Sent: Wednesday, November 16, 2016 5:50:57 PM To: John Cenile Cc: nanog at nanog.org Subject: Re: Facebook Geo Routing Issues I'm in Chicago and I saw mine going to Miami as well (per rDNS). Haven't looked into it at all. I did see a video where they said they occasionally purposely give people less than ideal facilities to test connectivity. Maybe that process buggered up? ----- Mike Hammett Intelligent Computing Solutions https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ics-2Dil.com&d=DgICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=MF3a4wEnEeEz9tFgYNQ_0w&m=hGHpg7HEOs8pvyDgxRdzwrfx47z4OzMxGNVrLep7PPI&s=2h-7_wY816g9xPqBfaEhuKWLRyx-PulhMJqe3aHAZ4g&e= Midwest-IX https://urldefense.proofpoint.com/v2/url?u=http-3A__www.midwest-2Dix.com&d=DgICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=MF3a4wEnEeEz9tFgYNQ_0w&m=hGHpg7HEOs8pvyDgxRdzwrfx47z4OzMxGNVrLep7PPI&s=QalI7b2Q2U_Mxb_wP9sIsftaGWoqaSDcwbat8S1xp5U&e= ----- Original Message ----- From: "John Cenile" To: nanog at nanog.org Sent: Wednesday, November 16, 2016 7:48:25 PM Subject: Facebook Geo Routing Issues Hello, Does anybody have a contact I could use at Facebook to get a routing issue resolved? Some of our networks are being routed to Miami, rather than using the much closer PoP of Sydney, and it's obviously causing significant performance issues when browsing Facebook. From eli at siliconsprawl.com Mon Nov 21 18:47:45 2016 From: eli at siliconsprawl.com (Eli Lindsey) Date: Mon, 21 Nov 2016 13:47:45 -0500 Subject: Oracle buys... Dyn. In-Reply-To: References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> <18C899CD-AA2A-4032-9747-00B39964401B@dataix.net> <1479751707.863028.794871001.00434384@webmail.messagingengine.com> Message-ID: <1479754065.872562.794908521.66B6057A@webmail.messagingengine.com> amazonaws.com is split Route 53/ultra - given resolver retry behavior and the impact of screwing up DNS, there's little reason not to use multiple providers on such a domain. However, most subdomains will delegate to R53 only (eg. dig +trace s3-us-west-1.amazonaws.com). None of this is related to Route 53 as a service. -eli On Mon, Nov 21, 2016, at 01:29 PM, Akshay Kumar wrote: > Yeah amazonaws.com NOT route53. > > On Mon, Nov 21, 2016 at 1:22 PM, Lee Fuller > wrote: >> Yes false. Amazon do use dyn + others for their own domains in >> addition to their own Route 53 but Route 53 itself is a completely >> separate service. >> Kind Regards >> >> Lee Fuller (mobile) >> PGP: 4F58 D91E 3886 2AAA 26F5 17BD FA12 7914 8308 45D0 >> >> >> On 21 Nov 2016 6:16 pm, "Eli Lindsey" wrote: >>> > On Nov 21, 2016, at 11:22, Akshay Kumar >>> > wrote: >>> > >>> > Route53 just uses Dyn and Ultra. I would expect AWS to roll out >>> > their own soon. >>> >>> This is completely false. >>> >>> -eli From jfmezei_nanog at vaxination.ca Mon Nov 21 19:13:13 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 21 Nov 2016 14:13:13 -0500 Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: References: <58329B31.3070806@vaxination.ca> Message-ID: <58334749.9080309@vaxination.ca> On 2016-11-21 02:53, Mikael Abrahamsson wrote: > Typically it travels on another "bearer" compared to Internet traffic. > > http://blog.3g4g.co.uk/2013/08/volte-bearers.html > > Think of bearers as "tunnels" between the mobile core network and the > device. Many thanks for the pointer. The fact that VoLTE has its own dedicated APN explains things. I am however a bit confused on the "bearer" term. Say a carrier has spectrum in 700Mhz bands A and B each 5mhz in each direction, bonded together as a single 10mhz (each way) channel. The docunment states: "R.92 requires the use of a particular set of radio bearers" Does this mean that a bearer is given specific spectrum within a block (such as a dedicated colour on a fibre) or that it is just given dedicated capacity on the single data channel formed by LTE compressing all of the spectrum into one big channel ? I though I understood the concept when the name "tunnel" had been mentioned because I understand that a handset estabishes a "hopping" tunnel with local IP which changes as you move from tower to tower, but the tunnel itself maintains a permanent IP connection that remains unchanged as you move from tower to tower. In such a concept, I could understand each tunnel (one to the data APN, one to the IMS/VoLTE APN) having bandwidth allocations. But when the text brought up "radio bearer", I got confused again sicne radio implies breaking the spectrum apart, which would reduce LTE compression efficiency. From joelja at bogus.com Mon Nov 21 20:18:01 2016 From: joelja at bogus.com (joel jaeggli) Date: Mon, 21 Nov 2016 12:18:01 -0800 Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: <58334749.9080309@vaxination.ca> References: <58329B31.3070806@vaxination.ca> <58334749.9080309@vaxination.ca> Message-ID: On 11/21/16 11:13 AM, Jean-Francois Mezei wrote: > On 2016-11-21 02:53, Mikael Abrahamsson wrote: > >> Typically it travels on another "bearer" compared to Internet traffic. >> >> http://blog.3g4g.co.uk/2013/08/volte-bearers.html >> >> Think of bearers as "tunnels" between the mobile core network and the >> device. > Many thanks for the pointer. The fact that VoLTE has its own dedicated > APN explains things. > > I am however a bit confused on the "bearer" term. > > Say a carrier has spectrum in 700Mhz bands A and B each 5mhz in each > direction, bonded together as a single 10mhz (each way) channel. > > The docunment states: > "R.92 requires the use of a particular set of radio bearers" the radio bearers described are are the signaling radio bearers. their existence is independent of of the link/mac layer configuration. The mac layer layer (e-utra) exists below the l2 bearers. https://en.wikipedia.org/wiki/E-UTRA > Does this mean that a bearer is given specific spectrum within a block > (such as a dedicated colour on a fibre) or that it is just given > dedicated capacity on the single data channel formed by LTE compressing > all of the spectrum into one big channel ? > > I though I understood the concept when the name "tunnel" had been > mentioned because I understand that a handset estabishes a "hopping" > tunnel with local IP which changes as you move from tower to tower, but > the tunnel itself maintains a permanent IP connection that remains > unchanged as you move from tower to tower. In such a concept, I could > understand each tunnel (one to the data APN, one to the IMS/VoLTE APN) > having bandwidth allocations. these are URBs they are terminated between the UE and the P-GW > But when the text brought up "radio bearer", I got confused again sicne > radio implies breaking the spectrum apart, which would reduce LTE > compression efficiency. SRB and URB are the l2 presentation of the tunnels established for user and signaling traffic. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From jfmezei_nanog at vaxination.ca Mon Nov 21 23:12:09 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 21 Nov 2016 18:12:09 -0500 Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: References: <58329B31.3070806@vaxination.ca> <58334749.9080309@vaxination.ca> Message-ID: <58337F49.5080004@vaxination.ca> On 2016-11-21 15:18, joel jaeggli wrote: > SRB and URB are the l2 presentation of the tunnels established for user > and signaling traffic. OK, so wth LTE, if carrier has 10mhz up and down, this represents a single chunk of spectrum providing one pipe ? (in fibre terms: a single light colour through one strand) The "smoke and mirrors" is accomplished by having different tunnels inside that one pipe, with some tunnels granted QoS or other preferential treatment between the IMS/VoiP servers and the RAN ? When a handset sends a VolTE packet to the "IMS" APN, is there any preferential treatment given between the handset and the antenna ? Or does preferential treatment begin at the RAN where the packet is recognized as going to "IMS" APN and going on the fast track to it ? or put another way. If everyone uploads a HD selfie movie at the same time, are handset uploads slowled with normal TCP flow control (drop a packet, no ack received, handset halves the TCP window size)? In other words, some router near antenna, to prioriotize packets to the IMS/VoLTE server, will flow control normal IP traffic to maintain sufficient upload capacity for VolTE traffic ? Or are the tunnels fixed in capacity such that unused capacity in one is never used by the other ? >From a policy point of view, if I propose a net neutrality policy, I have to make sure it doesn't prevent normal VoLTE functioning, while preventing abuse of the ability for an incumbent to prioritize/zero-rate its own services. For instance: AT&T in USA zero rates voice but not video calls over VoLTE. Rogers in Canada zero rates both voice and video calls over VoLTE. So if VoLTE video travels to the same IMS as voice, and not through the normal IP APN, that means AT&T has to count the video traffic separately and add it. But if Video goes through the normal IP traffic APN, it gets counted fairly, like Skype packets, but Rogers then captures that netflow and later deducts it from the total usage. The issue here is that VoLTE is the new kid on the block with video capability and incumbents can use their power to displace competitors such as Skype/Facetime and that may constitute undue preference, unless the standards are such that they have no choice because that it how it has to work. (But AT&T shows that it can still count video and treat video calls fairly compared o skype video calls). From joelja at bogus.com Tue Nov 22 02:56:38 2016 From: joelja at bogus.com (joel jaeggli) Date: Mon, 21 Nov 2016 18:56:38 -0800 Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: <58337F49.5080004@vaxination.ca> References: <58329B31.3070806@vaxination.ca> <58334749.9080309@vaxination.ca> <58337F49.5080004@vaxination.ca> Message-ID: On 11/21/16 3:12 PM, Jean-Francois Mezei wrote: > On 2016-11-21 15:18, joel jaeggli wrote: > > >> SRB and URB are the l2 presentation of the tunnels established for user >> and signaling traffic. > OK, so wth LTE, if carrier has 10mhz up and down, this represents a > single chunk of spectrum providing one pipe ? (in fibre terms: a single > light colour through one strand) Not really the air interface uses OFDMA coding scheme, so it is both divided into sub-carriers from 1.4 to 20mhz wide which are then also scheduled accordingly. > The "smoke and mirrors" is accomplished by having different tunnels > inside that one pipe, with some tunnels granted QoS or other > preferential treatment between the IMS/VoiP servers and the RAN ? you kinda want you qos policy to apply end-to-end in the carrier network, not just on the ran. > When a handset sends a VolTE packet to the "IMS" APN, is there any > preferential treatment given between the handset and the antenna ? sure, hence the qos policy template on the radio bearer. differing numbers of subcarriers and slots can be assigned to UE based on the services they are using. > Or > does preferential treatment begin at the RAN where the packet is > recognized as going to "IMS" APN and going on the fast track to it ? > > or put another way. If everyone uploads a HD selfie movie at the same > time, are handset uploads slowled with normal TCP flow control (drop a > packet, no ack received, handset halves the TCP window size)? Those flows going to have the best effort policy. but yes it is reasonable to presume that in the event of congestion the best effort queue will be preferentially dropped. likewise if you have voice and data going at the same time they are not strictly speaking competing for resources, because the volte radio bearer has a resource assigned to it and the and the ip data bearer has a resource assigned to it. > In other words, some router near antenna, to prioriotize packets to the > IMS/VoLTE server, will flow control normal IP traffic to maintain > sufficient upload capacity for VolTE traffic ? > > Or are the tunnels fixed in capacity such that unused capacity in one is > never used by the other ? > > > > From a policy point of view, if I propose a net neutrality policy, I > have to make sure it doesn't prevent normal VoLTE functioning, while > preventing abuse of the ability for an incumbent to prioritize/zero-rate > its own services. > For instance: > > > AT&T in USA zero rates voice but not video calls over VoLTE. > Rogers in Canada zero rates both voice and video calls over VoLTE. > > So if VoLTE video travels to the same IMS as voice, and not through the > normal IP APN, that means AT&T has to count the video traffic separately > and add it. But if Video goes through the normal IP traffic APN, it gets > counted fairly, like Skype packets, but Rogers then captures that > netflow and later deducts it from the total usage. > > The issue here is that VoLTE is the new kid on the block with video > capability and incumbents can use their power to displace competitors > such as Skype/Facetime and that may constitute undue preference, unless > the standards are such that they have no choice because that it how it > has to work. (But AT&T shows that it can still count video and treat > video calls fairly compared o skype video calls). > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From jfmezei_nanog at vaxination.ca Tue Nov 22 07:01:25 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 22 Nov 2016 02:01:25 -0500 Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: References: <58329B31.3070806@vaxination.ca> <58334749.9080309@vaxination.ca> <58337F49.5080004@vaxination.ca> Message-ID: <5833ED45.7040705@vaxination.ca> On 2016-11-21 21:56, joel jaeggli wrote: > Not really the air interface uses OFDMA coding scheme, so it is both > divided into sub-carriers from 1.4 to 20mhz wide which are then also > scheduled accordingly. I have read in a number of places that 1 * 20mhz yields much more capacity than 2 * 10mhz for LTE. but... On the other hand, just read something on > https://www.nxp.com/files/wireless_comm/doc/white_paper/3GPPEVOLUTIONWP.pdf and it states: ## Unlike single carrier systems described above, OFDM communication systems do not rely on increased symbol rates in order to achieve higher data rates. This makes the task of managing ISI much simpler. ***OFDM systems break the available bandwidth into many narrower sub-carriers and transmit the data in parallel streams.*** Each subcarrier is modulated using varying levels of QAM modulation, e.g. QPSK, QAM, 64QAM or possibly higher orders depending on signal quality. Each OFDM symbol is therefore a linear combination of the instantaneous signals on each of the sub-?carriers in the channel. Because data is transmitted in parallel rather than serially, OFDM symbols are generally MUCH longer than symbols on single carrier systems of equivalent data rate. ## At page 8: ## In OFDMA, users are allocated a specific number of subcarriers for a predetermined amount of time. These are referred to as physical resource blocks (PRBs) in the LTE specifications. PRBs thus have both a time and frequency dimension. ## At page 9, a table shows that a PRB is 180KHz, and that if you have 20mhz of spectrum, you have 100 PRBs. And more importantly: ## A PRB is the smallest element of resource allocation assigned by the base station scheduler. ## Intertingly, the data I have read in that document points to performance that is linear with more spectrum, no mention that 1 block of 20mhz yields more capacity than 2 blocks of 10mhz. So, if I read this right, (and please confirm if I understand correctly), an LTE system of 20mhz breaks itself into 100 180KHz chunks (a PRB) and the base station then schedules which user gets to use which PRB. So instead of giving each use a time slot, OFDMA gives it one or more PRB, a frequency slot 180KHz wide ? I assume that this is how VoLTE gets priority, with VoLTE bandwidth causing the base station to give the handset enough PRBs to handle the VoLTE connection, at the expense of normal users who will see a reduced number pf PRBs given to them for default data ? Is that how it works ? Would it be correct to assume there is some baseband signalling so the base station tells each user which PRBs it should be listening to (and sending on for the uplink) ? (One piece of text which helped me understand was stating that LTE doesn't transmit packets). From tdurack at gmail.com Tue Nov 22 14:32:51 2016 From: tdurack at gmail.com (Tim Durack) Date: Tue, 22 Nov 2016 14:32:51 +0000 Subject: SFP DOM SNMP Polling? Message-ID: I have a vendor that does not support SFP DOM SNMP polling. They state this is due to EEPROM read life cycle. Constant reads will damage the SFP. We SNMP poll SFP DOM from Cisco equipment without issue. Not heard this one before. Trying to see if there is some validity to the statement. Thoughts? Tim:> From mel at beckman.org Tue Nov 22 14:56:37 2016 From: mel at beckman.org (Mel Beckman) Date: Tue, 22 Nov 2016 14:56:37 +0000 Subject: SFP DOM SNMP Polling? In-Reply-To: References: Message-ID: Seems bogus to me. I can't imagine why realtime stats would be in flash rather than RAM. In fact, that can't be the case: they have to update the stats many more times per second than SNMP would poll them. -mel beckman > On Nov 22, 2016, at 6:33 AM, Tim Durack wrote: > > I have a vendor that does not support SFP DOM SNMP polling. They state this > is due to EEPROM read life cycle. Constant reads will damage the SFP. > > We SNMP poll SFP DOM from Cisco equipment without issue. > > Not heard this one before. Trying to see if there is some validity to the > statement. Thoughts? > > Tim:> From mel at beckman.org Tue Nov 22 15:00:31 2016 From: mel at beckman.org (Mel Beckman) Date: Tue, 22 Nov 2016 15:00:31 +0000 Subject: SFP DOM SNMP Polling? In-Reply-To: References: , Message-ID: <953619E4-AE7E-4035-B6A5-1F7E2D8A89D4@beckman.org> cisco-nsp at puck.nether.net on the CC is a cross-post to another list, resulting in bounces if you're not subscribed to both lists. So I am removing cisco-nsp at puck.nether.net as NANOG does not permit cross-site posting. -mel beckman > On Nov 22, 2016, at 6:57 AM, Mel Beckman wrote: > > Seems bogus to me. I can't imagine why realtime stats would be in flash rather than RAM. In fact, that can't be the case: they have to update the stats many more times per second than SNMP would poll them. > > -mel beckman > >> On Nov 22, 2016, at 6:33 AM, Tim Durack wrote: >> >> I have a vendor that does not support SFP DOM SNMP polling. They state this >> is due to EEPROM read life cycle. Constant reads will damage the SFP. >> >> We SNMP poll SFP DOM from Cisco equipment without issue. >> >> Not heard this one before. Trying to see if there is some validity to the >> statement. Thoughts? >> >> Tim:> From ahebert at pubnix.net Tue Nov 22 15:26:42 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 22 Nov 2016 10:26:42 -0500 Subject: BCP 38 coverage if top x providers ... In-Reply-To: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> References: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> Message-ID: <32e4b501-712a-553e-2744-dfdfde488650@pubnix.net> Hi Frank, Applying BCP38 at those level is more risky because of the sheer volume of transit & prefixes. For years, people have been working hard pushing the responsibility of BCP38 to outside their sandbox. You may remember one of those instance. ----- 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 11/19/16 21:13, Frank Bulk wrote: > My google fu is failing me, but I believe there was a NANOG posting a year > or two ago that mentioned that if the top x providers would implement BCP 38 > then y% of the traffic (or Internet) would be de-spoofed. The point was > that we don't even need everyone to implement BCP 38, but if the largest > (transit?) providers did it, then UDP reflection attacks could be minimized. > > If someone can recall the key words in that posting and dig it up, that > would be much appreciated. > > Frank > > From jared at puck.nether.net Tue Nov 22 15:35:47 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 22 Nov 2016 10:35:47 -0500 Subject: [c-nsp] SFP DOM SNMP Polling? In-Reply-To: References: Message-ID: > On Nov 22, 2016, at 9:32 AM, Tim Durack wrote: > > I have a vendor that does not support SFP DOM SNMP polling. They state this > is due to EEPROM read life cycle. Constant reads will damage the SFP. > > We SNMP poll SFP DOM from Cisco equipment without issue. > > Not heard this one before. Trying to see if there is some validity to the > statement. Thoughts? It?s entirely possible some people implement it poorly and the read cycles count. With 100k cycles somewhat typical for those bytes, it?s certainly something that could be seen if polling every 5 minutes in 347 days, but I think that?s a datapoint that most SFPs are warranted for much longer than 347 days. As the DDM data is stored not at 0x50 but at 0x51/0x52 in optics this is more likely done with a micro controller presenting the ram backed data via reads to/from those specific bytes. - Jared From jared at puck.nether.net Tue Nov 22 15:44:09 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 22 Nov 2016 10:44:09 -0500 Subject: BCP 38 coverage if top x providers ... In-Reply-To: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> References: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> Message-ID: <9EB78A78-CC71-4DBE-ABA6-4B05FB7E6496@puck.nether.net> > On Nov 19, 2016, at 9:13 PM, Frank Bulk wrote: > > My google fu is failing me, but I believe there was a NANOG posting a year > or two ago that mentioned that if the top x providers would implement BCP 38 > then y% of the traffic (or Internet) would be de-spoofed. The point was > that we don't even need everyone to implement BCP 38, but if the largest > (transit?) providers did it, then UDP reflection attacks could be minimized. > > If someone can recall the key words in that posting and dig it up, that > would be much appreciated. If you assume 80% of traffic comes out of your local CDN node, that remaining 20% may not be too difficult for you to do something with. The problem appears because various engineering thresholds that existed in the 90s have been violated. 40(64) byte packet testing is no longer the norm by vendors. Those of us who carry a full table and are expected to provide all the features are the minority in purchasing equipment by volume and revenue so the push is harder. A double lookup of the packet is twice as expensive and perhaps impractical in some (or many) cases. - Jared From ekgermann at semperen.com Tue Nov 22 16:36:45 2016 From: ekgermann at semperen.com (Eric Germann) Date: Tue, 22 Nov 2016 11:36:45 -0500 Subject: Anyone from American Express mail operations here? Message-ID: Pardon the interruption Please contact me off list. EKG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3705 bytes Desc: not available URL: From paul at paulstewart.org Tue Nov 22 16:37:59 2016 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 22 Nov 2016 11:37:59 -0500 Subject: Bell Canada contact - need help with DNS issue In-Reply-To: <57358217-3DA0-4AFC-95F7-29943651B3D7@lafferty.ca> References: <57358217-3DA0-4AFC-95F7-29943651B3D7@lafferty.ca> Message-ID: <93BA6A9E-D5E1-4BC0-BA2F-5DF201A7D422@paulstewart.org> Try dnsadmin at bell.ca ? I haven?t used that address in quite some time but someone did respond to it some time ago Paul > On Nov 19, 2016, at 11:13 AM, Rich Lafferty wrote: > > > Hi, > > Does anyone have a NOC or DNS administrator contact at Bell Canada? Their Toronto nameservers are returning SERVFAIL for our domain freshbooks.com since a general Bell DNS issue midday yesterday. > > > $ dig freshbooks.com @207.164.234.129 > > ; <<>> DiG 9.8.3-P1 <<>> freshbooks.com @207.164.234.129 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54893 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;freshbooks.com. IN A > > ;; Query time: 305 msec > ;; SERVER: 207.164.234.129#53(207.164.234.129) > ;; WHEN: Sat Nov 19 10:44:59 2016 > ;; MSG SIZE rcvd: 32 > > > No-one outside Bell is reporting issues, and other domains (ours or otherwise) are fine on Bell?s name servers. > > Thanks, > > -Rich > > -- > Rich Lafferty > Director of IT, FreshBooks - rich at freshbooks.com > http://www.freshbooks.com/ > Toll-free: (866) 303-6061 > Phone: (416) 780-2700 x233 > From mloftis at wgops.com Tue Nov 22 17:11:57 2016 From: mloftis at wgops.com (Michael Loftis) Date: Tue, 22 Nov 2016 09:11:57 -0800 Subject: [c-nsp] SFP DOM SNMP Polling? In-Reply-To: References: Message-ID: On Tue, Nov 22, 2016 at 6:32 AM, Tim Durack wrote: > I have a vendor that does not support SFP DOM SNMP polling. They state this > is due to EEPROM read life cycle. Constant reads will damage the SFP. Complete and total garbage. Reading from EEPROM and Flash both DO NOT WEAR. It is the erase+write cycle that wears them. Further typical EEPROM life cycle is ~1M erase/write cycles. If you wrote it every minute you could conceivably wear it out in a couple years...but thats flat out not how it works. The EEPROM, if any, is not going to be used for statistics data....maybe fail counts of some kind, lifetime (hours) maybe...that sort of thing. > > We SNMP poll SFP DOM from Cisco equipment without issue. > > Not heard this one before. Trying to see if there is some validity to the > statement. Thoughts? > > Tim:> > _______________________________________________ > 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/ -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From mel at beckman.org Tue Nov 22 17:39:50 2016 From: mel at beckman.org (Mel Beckman) Date: Tue, 22 Nov 2016 17:39:50 +0000 Subject: [c-nsp] SFP DOM SNMP Polling? In-Reply-To: References: Message-ID: Michael, I totally missed the fact that reads don?t stress EEPROMs! Excellent point, and makes the vendor?s claim totally bogus. Probably just one employees claim, but the vendor should step up and fix the real problem. -mel > On Nov 22, 2016, at 9:11 AM, Michael Loftis wrote: > > On Tue, Nov 22, 2016 at 6:32 AM, Tim Durack wrote: >> I have a vendor that does not support SFP DOM SNMP polling. They state this >> is due to EEPROM read life cycle. Constant reads will damage the SFP. > > Complete and total garbage. Reading from EEPROM and Flash both DO NOT > WEAR. It is the erase+write cycle that wears them. Further typical > EEPROM life cycle is ~1M erase/write cycles. If you wrote it every > minute you could conceivably wear it out in a couple years...but thats > flat out not how it works. The EEPROM, if any, is not going to be > used for statistics data....maybe fail counts of some kind, lifetime > (hours) maybe...that sort of thing. > > >> >> We SNMP poll SFP DOM from Cisco equipment without issue. >> >> Not heard this one before. Trying to see if there is some validity to the >> statement. Thoughts? >> >> Tim:> >> _______________________________________________ >> 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/ > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler From ttauber at 1-4-5.net Tue Nov 22 19:11:14 2016 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 22 Nov 2016 14:11:14 -0500 Subject: [c-nsp] SFP DOM SNMP Polling? In-Reply-To: References: Message-ID: I'm no expert in EEPROMs but recall awhile back we had an optical vendor (transport-side, not router-side) that did do frequent writes (maybe it was for performance info) to EEPROM and burned them out that way after a couple of years. Maybe your vendor is saying they don't support reporting this way because they would do it via writing to the EEPROM which is bad for it. Not saying whether they could do it some different way that would make it supportable, but who knows. May be some fundamental shortcoming/limitation of their design (or their OEM's design). $0.02 Tony On Tue, Nov 22, 2016 at 12:11 PM, Michael Loftis wrote: > On Tue, Nov 22, 2016 at 6:32 AM, Tim Durack wrote: > > I have a vendor that does not support SFP DOM SNMP polling. They state > this > > is due to EEPROM read life cycle. Constant reads will damage the SFP. > > Complete and total garbage. Reading from EEPROM and Flash both DO NOT > WEAR. It is the erase+write cycle that wears them. Further typical > EEPROM life cycle is ~1M erase/write cycles. If you wrote it every > minute you could conceivably wear it out in a couple years...but thats > flat out not how it works. The EEPROM, if any, is not going to be > used for statistics data....maybe fail counts of some kind, lifetime > (hours) maybe...that sort of thing. > > > > > > We SNMP poll SFP DOM from Cisco equipment without issue. > > > > Not heard this one before. Trying to see if there is some validity to the > > statement. Thoughts? > > > > Tim:> > > _______________________________________________ > > 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/ > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler > From tdurack at gmail.com Tue Nov 22 19:58:30 2016 From: tdurack at gmail.com (Tim Durack) Date: Tue, 22 Nov 2016 19:58:30 +0000 Subject: [c-nsp] SFP DOM SNMP Polling? In-Reply-To: References: Message-ID: A typical SFP spec sheet leads me to conclude that reading optic values repeatedly is expected. For example: https://www.finisar.com/sites/default/files/resources/AN_2030_DDMI_for_SFP_Rev_E2.pdf (I selected Finisar as they have complete spec sheets publicly available.) I question the vendor statement... Tim:> From me at anuragbhatia.com Thu Nov 24 14:46:00 2016 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 24 Nov 2016 20:16:00 +0530 Subject: IPv6 dumps on Oregon route views Message-ID: Hello everyone Was wondering if anyone is aware of mrt dump link for IPv6 dumps of Oregon route views? I see on the website it links to http://archive.routeviews.org/ipv6/ which gives a list of various collectors except for Oregon. The default "bgpdata" directory inside has dumps which are empty. On the Oregon route-views route-views.routeviews.org CLI: route-views> sh bgp ipv6 unicast summary BGP router identifier 128.223.51.103, local AS number 6447 BGP table version is 46628425, main routing table version 46628425 36322 network entries using 9879584 bytes of memory 700439 path entries using 100863216 bytes of memory 331618/17259 BGP path/bestpath attribute entries using 82241264 bytes of memory 3607348 BGP AS-PATH entries using 175182046 bytes of memory 111346 BGP community entries using 11638354 bytes of memory 793 BGP extended community entries using 34044 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 379838508 total bytes of memory BGP activity 8323321/7623230 prefixes, 545522618/517975111 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2001:388:1::13 4 7575 0 0 1 0 0 never Active 2001:388:1::16 4 7575 57344 1861 46628302 0 0 14:12:16 34047 2001:418:0:1000::F016 4 2914 148129 7618 46628302 0 0 2d10h 32871 2001:470:0:1A::1 4 6939 14390766 202805 46628302 0 0 18w2d 32990 2001:590::451F:6FF4 4 4436 0 0 1 0 0 never Active 2001:668:0:3:FFFF:0:ADCD:39EA 4 53364 1255881 57104 46628302 0 0 5w1d 33142 2001:918:0:5::1 4 3303 61123 3849 46628302 0 0 2d10h 32994 and much more. I am trying to look for mrt dump of this specific collector. Thanks. -- Anurag Bhatia anuragbhatia.com From kemp at network-services.uoregon.edu Thu Nov 24 18:17:19 2016 From: kemp at network-services.uoregon.edu (John Kemp) Date: Thu, 24 Nov 2016 10:17:19 -0800 Subject: IPv6 dumps on Oregon route views In-Reply-To: References: Message-ID: <731f8b45-4bdb-5f2a-2158-3b75190455f9@network-services.uoregon.edu> We don't save from the hardware router, i.e. route-views.routeviews.org. We had done that for quite some time, I think up until 2008. But the load on doing full dumps from the command-line was too much, and interfered with normal users. So at that point, we switched the ASCII dumps to route-views2. Easiest way to look at V6 is just use route-views6.routeviews.org. That's a dedicated V6 box. You can libbgpdump bgpdump command to decode. {rsync,ftp,http}://archive.routeviews.org/route-views6/bgpdata/ That's multi-hop. If you want an exchange collector for V6, then you might want paix, sydney, linx, eqix, saopaulo, sg... instead. John Kemp help at routeviews.org On 11/24/2016 06:46 AM, Anurag Bhatia wrote: > Hello everyone > > > > Was wondering if anyone is aware of mrt dump link for IPv6 dumps of Oregon > route views? > > I see on the website it links to http://archive.routeviews.org/ipv6/ which > gives a list of various collectors except for Oregon. The default "bgpdata" > directory inside has dumps which are empty. > > > > > On the Oregon route-views route-views.routeviews.org CLI: > > > route-views> sh bgp ipv6 unicast summary > BGP router identifier 128.223.51.103, local AS number 6447 > BGP table version is 46628425, main routing table version 46628425 > 36322 network entries using 9879584 bytes of memory > 700439 path entries using 100863216 bytes of memory > 331618/17259 BGP path/bestpath attribute entries using 82241264 bytes of > memory > 3607348 BGP AS-PATH entries using 175182046 bytes of memory > 111346 BGP community entries using 11638354 bytes of memory > 793 BGP extended community entries using 34044 bytes of memory > 0 BGP route-map cache entries using 0 bytes of memory > 0 BGP filter-list cache entries using 0 bytes of memory > BGP using 379838508 total bytes of memory > BGP activity 8323321/7623230 prefixes, 545522618/517975111 paths, scan > interval 60 secs > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > State/PfxRcd > 2001:388:1::13 4 7575 0 0 1 0 0 never > Active > 2001:388:1::16 4 7575 57344 1861 46628302 0 0 14:12:16 > 34047 > 2001:418:0:1000::F016 > 4 2914 148129 7618 46628302 0 0 2d10h > 32871 > 2001:470:0:1A::1 > 4 6939 14390766 202805 46628302 0 0 18w2d > 32990 > 2001:590::451F:6FF4 > 4 4436 0 0 1 0 0 never > Active > 2001:668:0:3:FFFF:0:ADCD:39EA > 4 53364 1255881 57104 46628302 0 0 5w1d > 33142 > 2001:918:0:5::1 4 3303 61123 3849 46628302 0 0 2d10h > 32994 > > > and much more. > > > > I am trying to look for mrt dump of this specific collector. > > > > > Thanks. > From rich at lafferty.ca Fri Nov 25 01:05:53 2016 From: rich at lafferty.ca (Rich Lafferty) Date: Thu, 24 Nov 2016 20:05:53 -0500 Subject: Bell Canada contact - need help with DNS issue In-Reply-To: <93BA6A9E-D5E1-4BC0-BA2F-5DF201A7D422@paulstewart.org> References: <57358217-3DA0-4AFC-95F7-29943651B3D7@lafferty.ca> <93BA6A9E-D5E1-4BC0-BA2F-5DF201A7D422@paulstewart.org> Message-ID: <58378E71.4010200@lafferty.ca> dnsadmin@ is no longer, but I was able to get a ticket past the front-line business support to an _incredibly_ helpful enterprise-level support desk who figured out what was going on and paged (!) their DNS team to intervene. I figured that the depths of Bell Canada were innavigable but we managed to get a resolution a day sooner than a TTL. -Rich > Paul Stewart > November 22, 2016 at 11:37 AM > Try dnsadmin at bell.ca ? I haven?t used that > address in quite some time but someone did respond to it some time ago > > Paul > > > Rich Lafferty > November 19, 2016 at 11:13 AM > Hi, > > Does anyone have a NOC or DNS administrator contact at Bell Canada? > Their Toronto nameservers are returning SERVFAIL for our domain > freshbooks.com since a general Bell DNS issue midday yesterday. > > > $ dig freshbooks.com @207.164.234.129 > > ; <<>> DiG 9.8.3-P1 <<>> freshbooks.com @207.164.234.129 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54893 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;freshbooks.com. IN A > > ;; Query time: 305 msec > ;; SERVER: 207.164.234.129#53(207.164.234.129) > ;; WHEN: Sat Nov 19 10:44:59 2016 > ;; MSG SIZE rcvd: 32 > > > No-one outside Bell is reporting issues, and other domains (ours or > otherwise) are fine on Bell?s name servers. > > Thanks, > > -Rich > From akshay at mongodb.com Mon Nov 21 17:22:33 2016 From: akshay at mongodb.com (Akshay Kumar) Date: Mon, 21 Nov 2016 12:22:33 -0500 Subject: Oracle buys... Dyn. In-Reply-To: References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> Message-ID: Route53 just uses Dyn and Ultra. I would expect AWS to roll out their own soon. On Mon, Nov 21, 2016 at 12:18 PM, J. Hellenthal wrote: > Don't blame ya I'm a little negative on this one too as I can already > "assume" specialized DNS integration with oracle products among possibly > ?oracle cloud? Structures spawning up for competition with AWS, Azure ... > others but these are just speculations. > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Nov 21, 2016, at 10:26, Jay R. Ashworth wrote: > > Happy Monday. > > This seems to me to be equivalent (and bad for the same reasons) to cable > companies and/or ISPs being co-owned with program providers. > > http://www.zdnet.com/article/oracle-acquires-dns-provider- > dyn-to-take-on-amazons-lead-in-the-cloud > > How will this affect *your* operations planning, if at all? Am I being > overly cynical about Larry Ellison? :-) > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > From akshay at mongodb.com Mon Nov 21 18:29:47 2016 From: akshay at mongodb.com (Akshay Kumar) Date: Mon, 21 Nov 2016 13:29:47 -0500 Subject: Oracle buys... Dyn. In-Reply-To: References: <21289926.28146.1479745619011.JavaMail.zimbra@baylink.com> <18C899CD-AA2A-4032-9747-00B39964401B@dataix.net> <1479751707.863028.794871001.00434384@webmail.messagingengine.com> Message-ID: Yeah amazonaws.com NOT route53. On Mon, Nov 21, 2016 at 1:22 PM, Lee Fuller wrote: > Yes false. Amazon do use dyn + others for their own domains in addition to > their own Route 53 but Route 53 itself is a completely separate service. > > Kind Regards > > Lee Fuller (mobile) > PGP: 4F58 D91E 3886 2AAA 26F5 17BD FA12 7914 8308 45D0 > > On 21 Nov 2016 6:16 pm, "Eli Lindsey" wrote: > >> > On Nov 21, 2016, at 11:22, Akshay Kumar wrote: >> > >> > Route53 just uses Dyn and Ultra. I would expect AWS to roll out their >> own soon. >> >> This is completely false. >> >> -eli >> > From adamkuj at gmail.com Wed Nov 23 21:17:01 2016 From: adamkuj at gmail.com (Adam) Date: Wed, 23 Nov 2016 16:17:01 -0500 Subject: CGNAT - Seeking Real World Experience Message-ID: I'm crunching the numbers on the cost effectiveness of implementing CGN vs IPv4 auctions. The determining factor is how many ephemeral ports are reserved for each customer. This is for a residential broadband environment. Is anybody doing deterministic NAT/PAT (i.e. each customer gets X ports - no more, no less)? My thinking is that X=8192 would cover even the power users. However, with only 8 customers per public IPv4 address, CGN is not worth the trouble. With X=8192, our money and time would better be spent acquiring additional IPv4 space. Are people successfully using a smaller deterministic port allocation? What's your X? If I can't make the numbers work for deterministic NAT, I might be able to live with dynamic port assignments. Specifically, I'm referring to what vendor J calls "Port Block Allocation". I was thinking 1024 ports per block, with up to 8 blocks per customer (and a bunch of log correlation to determine who was using which ip:port tuple at a given datetime). I *can* make the math work out in favor of CGN if the average customer uses <= 3072 ports (3 blocks). But is that going to be enough? I'd love to hear other people's experiences. Thanks! -Adam From main at kipsang.com Thu Nov 24 15:06:31 2016 From: main at kipsang.com (Michael Bullut) Date: Thu, 24 Nov 2016 18:06:31 +0300 Subject: Zoho Mail - SPF & DKIM Records... Message-ID: Greetings Team, Has anybody set up SPF & DKIM for a domain whose e-mails are handled by Zoho? Running into trouble setting them up. Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang * *Blog: http://www.kipsang.com/ * *E-mail:* *main at kipsang.com
* *---* From cb.list6 at gmail.com Fri Nov 25 04:06:01 2016 From: cb.list6 at gmail.com (Ca By) Date: Fri, 25 Nov 2016 04:06:01 +0000 Subject: CGNAT - Seeking Real World Experience In-Reply-To: References: Message-ID: On Thu, Nov 24, 2016 at 7:05 PM Adam wrote: > I'm crunching the numbers on the cost effectiveness of implementing CGN vs > IPv4 auctions. The determining factor is how many ephemeral ports are > reserved for each customer. This is for a residential broadband > environment. > > Is anybody doing deterministic NAT/PAT (i.e. each customer gets X ports - > no more, no less)? My thinking is that X=8192 would cover even the power > users. However, with only 8 customers per public IPv4 address, CGN is not > worth the trouble. With X=8192, our money and time would better be spent > acquiring additional IPv4 space. Are people successfully using a smaller > deterministic port allocation? What's your X? > > If I can't make the numbers work for deterministic NAT, I might be able to > live with dynamic port assignments. Specifically, I'm referring to what > vendor J calls "Port Block Allocation". I was thinking 1024 ports per > block, with up to 8 blocks per customer (and a bunch of log correlation to > determine who was using which ip:port tuple at a given datetime). I *can* > make the math work out in favor of CGN if the average customer uses <= 3072 > ports (3 blocks). But is that going to be enough? I'd love to hear other > people's experiences. > > Thanks! > -Adam > We see around 70% of traffic using ipv6 (goog, fb, netflix, ... now cloudfront and Cloudflare ) , that takes a lot of the sting out of CGN cost. CB From twh at megagroup.ru Fri Nov 25 08:18:55 2016 From: twh at megagroup.ru (Stepan Kucherenko) Date: Fri, 25 Nov 2016 11:18:55 +0300 Subject: CGNAT - Seeking Real World Experience In-Reply-To: References: Message-ID: Don't try detereministic NAT, it's not worth it. You'll waste a lot of port capacity on most users, and it might still be problematic for power users. Just try to match one user to one real IP, many sites/applications don't like when there are several requests from one user with different IPs. After that just stack as many users on one IP as you can and that's it. It's the only way CGN can be worth the trouble. If you really need to know who was using which port, just log them and correlate them when/if the need arises. On 24.11.2016 00:17, Adam wrote: > I'm crunching the numbers on the cost effectiveness of implementing CGN vs > IPv4 auctions. The determining factor is how many ephemeral ports are > reserved for each customer. This is for a residential broadband environment. > > Is anybody doing deterministic NAT/PAT (i.e. each customer gets X ports - > no more, no less)? My thinking is that X=8192 would cover even the power > users. However, with only 8 customers per public IPv4 address, CGN is not > worth the trouble. With X=8192, our money and time would better be spent > acquiring additional IPv4 space. Are people successfully using a smaller > deterministic port allocation? What's your X? > > If I can't make the numbers work for deterministic NAT, I might be able to > live with dynamic port assignments. Specifically, I'm referring to what > vendor J calls "Port Block Allocation". I was thinking 1024 ports per > block, with up to 8 blocks per customer (and a bunch of log correlation to > determine who was using which ip:port tuple at a given datetime). I *can* > make the math work out in favor of CGN if the average customer uses <= 3072 > ports (3 blocks). But is that going to be enough? I'd love to hear other > people's experiences. > > Thanks! > -Adam > From nanog at namor.ca Fri Nov 25 16:09:06 2016 From: nanog at namor.ca (J) Date: Fri, 25 Nov 2016 10:09:06 -0600 Subject: Zoho Mail - SPF & DKIM Records... In-Reply-To: References: Message-ID: <1589c3f583b.e0afc21736757.3173326353094153792@namor.ca> Not DKIM, but, SPF, being the simplest, yes. I doubt that's much help. ---- On Thu, 24 Nov 2016 09:06:31 -0600 Michael Bullut <main at kipsang.com> wrote ---- Greetings Team, Has anybody set up SPF & DKIM for a domain whose e-mails are handled by Zoho? Running into trouble setting them up. Warm regards, Michael Bullut. From zvernhout at gmail.com Fri Nov 25 16:55:02 2016 From: zvernhout at gmail.com (Matthew Vernhout) Date: Fri, 25 Nov 2016 11:55:02 -0500 Subject: Zoho Mail - SPF & DKIM Records... In-Reply-To: <1589c3f583b.e0afc21736757.3173326353094153792@namor.ca> References: <1589c3f583b.e0afc21736757.3173326353094153792@namor.ca> Message-ID: To get DKIM setup with Zoho you need to open a support ticket with then and they will give you the instructions. When I set it up it was a manual request to them and not something you could self help. SPF is simple, just add this to your record: include:zoho.com Cheers, Matt On 25/11/2016 11:09 AM, J wrote: > Not DKIM, but, SPF, being the simplest, yes. I doubt that's much help. > ---- On Thu, 24 Nov 2016 09:06:31 -0600 Michael Bullut <main at kipsang.com> wrote ---- > > Greetings Team, > > Has anybody set up SPF & DKIM for a domain whose e-mails are handled by > Zoho? Running into trouble setting them up. > > Warm regards, > > Michael Bullut. > > > > > > From cscora at apnic.net Fri Nov 25 18:01:56 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Nov 2016 04:01:56 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161125180156.C96F4C55A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 26 Nov, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 623316 Prefixes after maximum aggregation (per Origin AS): 221044 Deaggregation factor: 2.82 Unique aggregates announced (without unneeded subnets): 302782 Total ASes present in the Internet Routing Table: 55320 Prefixes per ASN: 11.27 Origin-only ASes present in the Internet Routing Table: 36351 Origin ASes announcing only one prefix: 15321 Transit ASes present in the Internet Routing Table: 6551 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 62 Unregistered ASNs in the Routing Table: 18 Number of 32-bit ASNs allocated by the RIRs: 16307 Number of 32-bit ASNs visible in the Routing Table: 12418 Prefixes from 32-bit ASNs in the Routing Table: 50327 Number of bogon 32-bit ASNs visible in the Routing Table: 438 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 406 Number of addresses announced to Internet: 2832190628 Equivalent to 168 /8s, 207 /16s and 204 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.3 Total number of prefixes smaller than registry allocations: 205576 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156914 Total APNIC prefixes after maximum aggregation: 42915 APNIC Deaggregation factor: 3.66 Prefixes being announced from the APNIC address blocks: 171012 Unique aggregates announced from the APNIC address blocks: 70398 APNIC Region origin ASes present in the Internet Routing Table: 5194 APNIC Prefixes per ASN: 32.92 APNIC Region origin ASes announcing only one prefix: 1155 APNIC Region transit ASes present in the Internet Routing Table: 942 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2510 Number of APNIC addresses announced to Internet: 759790148 Equivalent to 45 /8s, 73 /16s and 122 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188162 Total ARIN prefixes after maximum aggregation: 89363 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 194504 Unique aggregates announced from the ARIN address blocks: 89415 ARIN Region origin ASes present in the Internet Routing Table: 16130 ARIN Prefixes per ASN: 12.06 ARIN Region origin ASes announcing only one prefix: 5641 ARIN Region transit ASes present in the Internet Routing Table: 1707 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1599 Number of ARIN addresses announced to Internet: 1105886880 Equivalent to 65 /8s, 234 /16s and 126 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 149381 Total RIPE prefixes after maximum aggregation: 72721 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 160364 Unique aggregates announced from the RIPE address blocks: 98187 RIPE Region origin ASes present in the Internet Routing Table: 18178 RIPE Prefixes per ASN: 8.82 RIPE Region origin ASes announcing only one prefix: 7801 RIPE Region transit ASes present in the Internet Routing Table: 3053 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5091 Number of RIPE addresses announced to Internet: 709403520 Equivalent to 42 /8s, 72 /16s and 163 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 63199 Total LACNIC prefixes after maximum aggregation: 12692 LACNIC Deaggregation factor: 4.98 Prefixes being announced from the LACNIC address blocks: 79506 Unique aggregates announced from the LACNIC address blocks: 37752 LACNIC Region origin ASes present in the Internet Routing Table: 2485 LACNIC Prefixes per ASN: 31.99 LACNIC Region origin ASes announcing only one prefix: 549 LACNIC Region transit ASes present in the Internet Routing Table: 597 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2941 Number of LACNIC addresses announced to Internet: 170815808 Equivalent to 10 /8s, 46 /16s and 113 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15270 Total AfriNIC prefixes after maximum aggregation: 3345 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 17524 Unique aggregates announced from the AfriNIC address blocks: 6664 AfriNIC Region origin ASes present in the Internet Routing Table: 741 AfriNIC Prefixes per ASN: 23.65 AfriNIC Region origin ASes announcing only one prefix: 175 AfriNIC Region transit ASes present in the Internet Routing Table: 183 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 277 Number of AfriNIC addresses announced to Internet: 85820672 Equivalent to 5 /8s, 29 /16s and 133 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3608 390 246 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2959 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2702 1499 548 BSNL-NIB National Internet Backbone, IN 4766 2700 11132 740 KIXS-AS-KR Korea Telecom, KR 9808 2231 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2045 428 217 TATACOMM-AS TATA Communications formerl 45899 1710 1244 96 VNPT-AS-VN VNPT Corp, VN 4808 1651 2164 475 CHINA169-BJ China Unicom Beijing Provin 24560 1567 542 228 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3573 2967 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3287 1333 82 SHAW - Shaw Communications Inc., CA 18566 2196 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1950 2006 405 CHARTER-NET-HKY-NC - Charter Communicat 30036 1771 334 363 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1737 5069 652 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1677 848 227 ITCDELTA - Earthlink, Inc., US 701 1600 10634 657 UUNET - MCI Communications Services, In 16509 1495 2800 507 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 2952 1115 2088 AKAMAI-ASN1 , US 9121 2041 1691 18 TTNET , TR 34984 1983 327 364 TELLCOM-AS , TR 13188 1606 99 58 TRIOLAN , UA 12479 1383 1032 53 UNI2-AS , ES 8551 1201 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 6849 1143 355 22 UKRTELNET , UA 8402 1137 544 15 CORBINA-AS OJSC "Vimpelcom", RU 12389 954 1134 424 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3533 545 148 Telmex Colombia S.A., CO 8151 2285 3369 550 Uninet S.A. de C.V., MX 7303 1528 964 247 Telecom Argentina S.A., AR 6503 1486 437 54 Axtel, S.A.B. de C.V., MX 11830 1419 368 66 Instituto Costarricense de Electricidad 6147 1281 377 27 Telefonica del Peru S.A.A., PE 28573 1035 2263 171 CLARO S.A., BR 7738 1022 1882 41 Telemar Norte Leste S.A., BR 3816 988 474 193 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 911 126 80 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1215 402 50 LINKdotNET-AS, EG 36903 692 348 117 MT-MPLS, MA 37611 680 67 6 Afrihost, ZA 36992 575 1373 25 ETISALAT-MISR, EG 8452 472 1472 15 TE-AS TE-AS, EG 24835 419 658 16 RAYA-AS, EG 37492 396 288 72 ORANGE-TN, TN 29571 364 37 11 CITelecom-AS, CI 15399 310 35 6 WANANCHI-KE, KE 36974 275 140 11 AFNET-AS, CI Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5545 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3608 390 246 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3573 2967 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3533 545 148 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3287 1333 82 SHAW - Shaw Communications Inc., CA 17974 2959 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2952 1115 2088 AKAMAI-ASN1 , US 9829 2702 1499 548 BSNL-NIB National Internet Backbone, IN 4766 2700 11132 740 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3573 3421 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3533 3385 Telmex Colombia S.A., CO 7545 3608 3362 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3287 3205 SHAW - Shaw Communications Inc., CA 17974 2959 2888 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2231 2198 CMNET-GD Guangdong Mobile Communication 9829 2702 2154 BSNL-NIB National Internet Backbone, IN 18566 2196 2087 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 2056 BELLSOUTH-NET-BLK - BellSouth.net Inc., Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 64855 PRIVATE 41.220.200.0/21 36945 mcelISP, MZ 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 27.110.192.0/22 45664 UNKNOWN 27.110.196.0/22 45664 UNKNOWN 27.110.200.0/22 45664 UNKNOWN 27.110.204.0/22 45664 UNKNOWN 27.110.224.0/22 45664 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:102 /12:274 /13:522 /14:1050 /15:1785 /16:13147 /17:7830 /18:13011 /19:25386 /20:38145 /21:40607 /22:72461 /23:60786 /24:346839 /25:473 /26:378 /27:310 /28:62 /29:38 /30:12 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3083 3287 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2782 3573 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2089 2196 MEGAPATH5-US - MegaPath Corporation, US 30036 1587 1771 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1443 3533 Telmex Colombia S.A., CO 9121 1423 2041 TTNET , TR 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1351 1606 TRIOLAN , UA 6983 1323 1677 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1569 2:802 4:23 5:2331 6:32 8:1012 12:1806 13:54 14:1756 15:24 16:2 17:102 18:126 20:48 23:1919 24:1817 27:2378 31:1803 32:83 33:6 35:3 36:364 37:2427 38:1301 39:42 40:99 41:2941 42:458 43:1896 44:50 45:2245 46:2540 47:106 49:1179 50:939 51:14 52:588 53:2 54:353 55:8 56:4 57:40 58:1594 59:1006 60:379 61:1846 62:1478 63:1935 64:4574 65:2176 66:4357 67:2253 68:1146 69:3288 70:1295 71:561 72:2071 74:2593 75:404 76:417 77:1437 78:1556 79:922 80:1349 81:1409 82:998 83:711 84:867 85:1685 86:475 87:1123 88:716 89:2036 90:198 91:6093 92:930 93:2368 94:2433 95:2676 96:558 97:348 98:944 99:93 100:147 101:1186 103:12836 104:2595 105:147 106:468 107:1465 108:788 109:2488 110:1279 111:1644 112:1141 113:1167 114:1053 115:1694 116:1682 117:1559 118:2119 119:1577 120:977 121:1094 122:2292 123:2041 124:1603 125:1846 128:676 129:472 130:422 131:1360 132:611 133:176 134:521 135:206 136:403 137:393 138:1795 139:435 140:607 141:472 142:697 143:886 144:727 145:169 146:950 147:664 148:1386 149:551 150:678 151:967 152:694 153:310 154:690 155:947 156:541 157:566 158:434 159:1323 160:559 161:723 162:2448 163:544 164:787 165:1122 166:356 167:1217 168:2356 169:684 170:2345 171:259 172:822 173:1822 174:763 175:715 176:1741 177:4098 178:2381 179:1135 180:2151 181:1980 182:2123 183:1016 184:835 185:8080 186:3186 187:2204 188:2273 189:1766 190:7912 191:1321 192:9152 193:5759 194:4557 195:3868 196:1873 197:1259 198:5598 199:5829 200:7158 201:3739 202:10177 203:9813 204:4479 205:2763 206:3003 207:3128 208:4057 209:3890 210:3904 211:2054 212:2751 213:2416 214:848 215:67 216:5758 217:1984 218:818 219:600 220:1655 221:878 222:715 223:1358 End of report From ken at wemonitoremail.com Fri Nov 25 13:06:14 2016 From: ken at wemonitoremail.com (Ken O'Driscoll) Date: Fri, 25 Nov 2016 13:06:14 +0000 Subject: Zoho Mail - SPF & DKIM Records... In-Reply-To: References: Message-ID: <1480079174.2378.4.camel@wemonitoremail.com> Hi Michael, Yes, very familiar with Zoho. What's the problem you're encountering? Feel free to get in touch off-list also. Ken. --? Ken O'Driscoll / We Monitor Email t: +353 1 254 9400 | w: www.wemonitoremail.com On Thu, 2016-11-24 at 18:06 +0300, Michael Bullut wrote: > Greetings Team, > > Has anybody set up SPF & DKIM for a domain whose e-mails are handled by > Zoho? Running into trouble setting them up. > > Warm regards, > > Michael Bullut. > > --- > > *Cell:* > *+254 723 393 114.**Skype Name:* *Michael Bullut.* > *Twitter:* > * @Kipsang * > *Blog: http://www.kipsang.com/ * > *E-mail:* *main at kipsang.com
* > > *---* From achatz at forthnet.gr Sun Nov 27 07:58:10 2016 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Sun, 27 Nov 2016 09:58:10 +0200 Subject: CGNAT - Seeking Real World Experience In-Reply-To: References: Message-ID: <583A9212.3030701@forthnet.gr> I had given some numbers for PBA in http://puck.nether.net/pipermail/cisco-nsp/2016-February/101908.html -- Tassos Adam wrote on 23/11/16 23:17: > I'm crunching the numbers on the cost effectiveness of implementing CGN vs > IPv4 auctions. The determining factor is how many ephemeral ports are > reserved for each customer. This is for a residential broadband environment. > > Is anybody doing deterministic NAT/PAT (i.e. each customer gets X ports - > no more, no less)? My thinking is that X=8192 would cover even the power > users. However, with only 8 customers per public IPv4 address, CGN is not > worth the trouble. With X=8192, our money and time would better be spent > acquiring additional IPv4 space. Are people successfully using a smaller > deterministic port allocation? What's your X? > > If I can't make the numbers work for deterministic NAT, I might be able to > live with dynamic port assignments. Specifically, I'm referring to what > vendor J calls "Port Block Allocation". I was thinking 1024 ports per > block, with up to 8 blocks per customer (and a bunch of log correlation to > determine who was using which ip:port tuple at a given datetime). I *can* > make the math work out in favor of CGN if the average customer uses <= 3072 > ports (3 blocks). But is that going to be enough? I'd love to hear other > people's experiences. > > Thanks! > -Adam > From jra at baylink.com Mon Nov 28 02:44:30 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 28 Nov 2016 02:44:30 +0000 (UTC) Subject: BCP 38 coverage if top x providers ... In-Reply-To: <9EB78A78-CC71-4DBE-ABA6-4B05FB7E6496@puck.nether.net> References: <002e01d242d3$a5a348c0$f0e9da40$@iname.com> <9EB78A78-CC71-4DBE-ABA6-4B05FB7E6496@puck.nether.net> Message-ID: <776866450.43777.1480301070889.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Jared Mauch" > To: "Frank Bulk" > Cc: nanog at nanog.org > Sent: Tuesday, November 22, 2016 10:44:09 AM > Subject: Re: BCP 38 coverage if top x providers ... >> On Nov 19, 2016, at 9:13 PM, Frank Bulk wrote: >> >> My google fu is failing me, but I believe there was a NANOG posting a year >> or two ago that mentioned that if the top x providers would implement BCP 38 >> then y% of the traffic (or Internet) would be de-spoofed. The point was >> that we don't even need everyone to implement BCP 38, but if the largest >> (transit?) providers did it, then UDP reflection attacks could be minimized. >> >> If someone can recall the key words in that posting and dig it up, that >> would be much appreciated. > > If you assume 80% of traffic comes out of your local CDN node, that remaining > 20% > may not be too difficult for you to do something with. The problem appears > because > various engineering thresholds that existed in the 90s have been violated. > > 40(64) byte packet testing is no longer the norm by vendors. Those of us who > carry > a full table and are expected to provide all the features are the minority in > purchasing equipment by volume and revenue so the push is harder. A double > lookup > of the packet is twice as expensive and perhaps impractical in some (or many) > cases. It was me, Frank, as I said in an offlist email your mail server a) didn't like and b) took 4 days to complain about. :-) I believe I said "top 10" or "top 20" eyeball carriers, and I was shooting from the hip, based on my apprehension of the sizes there of. 80/20 rule, as Jared implies. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Nov 28 02:47:17 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 28 Nov 2016 02:47:17 +0000 (UTC) Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: References: <58329B31.3070806@vaxination.ca> Message-ID: <316009285.43782.1480301237176.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Mikael Abrahamsson" > To: "Jean-Francois Mezei" > Cc: Nanog at nanog.org > Sent: Monday, November 21, 2016 2:53:41 AM > Subject: Re: Voice channels (FTTH, DOCSIS, VoLTE) > On Mon, 21 Nov 2016, Jean-Francois Mezei wrote: > >> I need to verify some claims made by incumbents in Canada that VoLTE >> data travels on a totally separate channel between the phone and the >> antenna. > > Typically it travels on another "bearer" compared to Internet traffic. > > http://blog.3g4g.co.uk/2013/08/volte-bearers.html > > Think of bearers as "tunnels" between the mobile core network and the > device. They have a lot in common with ATM PVCs in that they can have > different QoS characteristics. So the VoLTE bearer can have scheduling > priorities that means it'll always be low-latency and highest priority, > meaning it might work well when the "Internet" bearer does not. That is congruent with my understanding of how cableco voice is provisioned; it has different rules WRT VoN -- specifically about 911 -- because the cable company segregates it and handles it differently (your cablemodem is expected to be tied to your service address -- or whatever terminal device does the voice). Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From lguillory at reservetele.com Mon Nov 28 03:18:20 2016 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 28 Nov 2016 03:18:20 +0000 Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: <316009285.43782.1480301237176.JavaMail.zimbra@baylink.com> References: <58329B31.3070806@vaxination.ca> , <316009285.43782.1480301237176.JavaMail.zimbra@baylink.com> Message-ID: <1924FCA2-65D7-4302-A664-5E649AE07620@reservetele.com> With MGCP we're just using DSx Qos which is just services classification within the packet cable standard. Still runs over the same docsis network as all other traffic and not separated besides qos side of things. We use a 64K reserved channel to set the call up, after that each call has its own service flow that is QOSed. We also have reserved BW in the CMTS for 911 calls so that they always get through. Where the modem resides in relation to 911 isn't really a factor as we go by services address for the account, a customer could moved the modem to another house across town and it will still work. I know Time Warner has completely separate networks for voice and data, they didn't even reside on the same CMTS from what I understand. Don't know of anyone else doing it that way. Luke Sent from my iPhone On Nov 27, 2016, at 8:49 PM, Jay R. Ashworth > wrote: Luke Guillory Network Operations Manager [cid:image1f21cf.JPG at 56d24e46.43b1142f] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ----- Original Message ----- From: "Mikael Abrahamsson" > To: "Jean-Francois Mezei" > Cc: Nanog at nanog.org Sent: Monday, November 21, 2016 2:53:41 AM Subject: Re: Voice channels (FTTH, DOCSIS, VoLTE) On Mon, 21 Nov 2016, Jean-Francois Mezei wrote: I need to verify some claims made by incumbents in Canada that VoLTE data travels on a totally separate channel between the phone and the antenna. Typically it travels on another "bearer" compared to Internet traffic. http://blog.3g4g.co.uk/2013/08/volte-bearers.html Think of bearers as "tunnels" between the mobile core network and the device. They have a lot in common with ATM PVCs in that they can have different QoS characteristics. So the VoLTE bearer can have scheduling priorities that means it'll always be low-latency and highest priority, meaning it might work well when the "Internet" bearer does not. That is congruent with my understanding of how cableco voice is provisioned; it has different rules WRT VoN -- specifically about 911 -- because the cable company segregates it and handles it differently (your cablemodem is expected to be tied to your service address -- or whatever terminal device does the voice). Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Nov 28 03:21:23 2016 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 28 Nov 2016 03:21:23 +0000 (UTC) Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: <1924FCA2-65D7-4302-A664-5E649AE07620@reservetele.com> References: <58329B31.3070806@vaxination.ca> <316009285.43782.1480301237176.JavaMail.zimbra@baylink.com> <1924FCA2-65D7-4302-A664-5E649AE07620@reservetele.com> Message-ID: <1602517006.43826.1480303283081.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Luke Guillory" > To: "jra" > Cc: "North American Network Operators' Group" > Sent: Sunday, November 27, 2016 10:18:20 PM > Subject: Re: Voice channels (FTTH, DOCSIS, VoLTE) > With MGCP we're just using DSx Qos which is just services classification within > the packet cable standard. Still runs over the same docsis network as all other > traffic and not separated besides qos side of things. > > We use a 64K reserved channel to set the call up, after that each call has its > own service flow that is QOSed. > > We also have reserved BW in the CMTS for 911 calls so that they always get > through. > > Where the modem resides in relation to 911 isn't really a factor as we go by > services address for the account, a customer could moved the modem to another > house across town and it will still work. > > I know Time Warner has completely separate networks for voice and data, they > didn't even reside on the same CMTS from what I understand. Don't know of > anyone else doing it that way. It's my jackleg appraisal -- I'm not an attorney much less an FCC specialist attorney -- that that subjects your service to regulations and restrictions that don't pertain to people who do it the other way; you are simply a VoN carrier, competing with all the other VoN carriers like Vonage; if you *do* give your own traffic priority, then you're violating... title II? Some net neutrality provision that they don't cause they're not *moving the calls* "over the Internet". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From me at anuragbhatia.com Mon Nov 28 11:17:10 2016 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 28 Nov 2016 16:47:10 +0530 Subject: IPv6 dumps on Oregon route views In-Reply-To: <731f8b45-4bdb-5f2a-2158-3b75190455f9@network-services.uoregon.edu> References: <731f8b45-4bdb-5f2a-2158-3b75190455f9@network-services.uoregon.edu> Message-ID: Hi John http://archive.routeviews.org/route-views6/bgpdata/ makes sense and gives a reasonable view of table I was looking for. Thanks for your reply! On Thu, Nov 24, 2016 at 11:47 PM, John Kemp < kemp at network-services.uoregon.edu> wrote: > > We don't save from the hardware router, i.e. route-views.routeviews.org. > > We had done that for quite some time, I think up until 2008. But the > load on > doing full dumps from the command-line was too much, and interfered with > normal users. So at that point, we switched the ASCII dumps to > route-views2. > > Easiest way to look at V6 is just use route-views6.routeviews.org. That's > a dedicated V6 box. You can libbgpdump bgpdump command to decode. > {rsync,ftp,http}://archive.routeviews.org/route-views6/bgpdata/ > > That's multi-hop. If you want an exchange collector for V6, then you might > want paix, sydney, linx, eqix, saopaulo, sg... instead. > > John Kemp > help at routeviews.org > > > On 11/24/2016 06:46 AM, Anurag Bhatia wrote: > > Hello everyone > > > > > > > > Was wondering if anyone is aware of mrt dump link for IPv6 dumps of > Oregon > > route views? > > > > I see on the website it links to http://archive.routeviews.org/ipv6/ > which > > gives a list of various collectors except for Oregon. The default > "bgpdata" > > directory inside has dumps which are empty. > > > > > > > > > > On the Oregon route-views route-views.routeviews.org CLI: > > > > > > route-views> sh bgp ipv6 unicast summary > > BGP router identifier 128.223.51.103, local AS number 6447 > > BGP table version is 46628425, main routing table version 46628425 > > 36322 network entries using 9879584 bytes of memory > > 700439 path entries using 100863216 bytes of memory > > 331618/17259 BGP path/bestpath attribute entries using 82241264 bytes of > > memory > > 3607348 BGP AS-PATH entries using 175182046 bytes of memory > > 111346 BGP community entries using 11638354 bytes of memory > > 793 BGP extended community entries using 34044 bytes of memory > > 0 BGP route-map cache entries using 0 bytes of memory > > 0 BGP filter-list cache entries using 0 bytes of memory > > BGP using 379838508 total bytes of memory > > BGP activity 8323321/7623230 prefixes, 545522618/517975111 paths, scan > > interval 60 secs > > > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > > State/PfxRcd > > 2001:388:1::13 4 7575 0 0 1 0 0 never > > Active > > 2001:388:1::16 4 7575 57344 1861 46628302 0 0 > 14:12:16 > > 34047 > > 2001:418:0:1000::F016 > > 4 2914 148129 7618 46628302 0 0 2d10h > > 32871 > > 2001:470:0:1A::1 > > 4 6939 14390766 202805 46628302 0 0 18w2d > > 32990 > > 2001:590::451F:6FF4 > > 4 4436 0 0 1 0 0 never > > Active > > 2001:668:0:3:FFFF:0:ADCD:39EA > > 4 53364 1255881 57104 46628302 0 0 5w1d > > 33142 > > 2001:918:0:5::1 4 3303 61123 3849 46628302 0 0 2d10h > > 32994 > > > > > > and much more. > > > > > > > > I am trying to look for mrt dump of this specific collector. > > > > > > > > > > Thanks. > > > > -- Anurag Bhatia anuragbhatia.com From karim.adel at gmail.com Mon Nov 28 17:53:41 2016 From: karim.adel at gmail.com (Kasper Adel) Date: Mon, 28 Nov 2016 09:53:41 -0800 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT Message-ID: Hi, Vendor X wants you to run their VNF (Router, Firewall or Whatever) and they refuse to give you root access, or any means necessary to do 'maintenance' kind of work, whether its applying security updates, or any other similar type of task that is needed for you to integrate the Linux VM into your IT eco-system. Would this be an acceptable offering in today's IT from different type of Enterprises (Minux the Googles, Facebooks...etc) ? Thanks From mark.tinka at seacom.mu Mon Nov 28 18:04:08 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 28 Nov 2016 20:04:08 +0200 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: References: Message-ID: On 28/Nov/16 19:53, Kasper Adel wrote: > Hi, > > Vendor X wants you to run their VNF (Router, Firewall or Whatever) and they > refuse to give you root access, or any means necessary to do 'maintenance' > kind of work, whether its applying security updates, or any other similar > type of task that is needed for you to integrate the Linux VM into your IT > eco-system. > > Would this be an acceptable offering in today's IT from different type of > Enterprises (Minux the Googles, Facebooks...etc) ? Vote with your feet. Mark. From jared at puck.nether.net Mon Nov 28 18:10:29 2016 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 28 Nov 2016 13:10:29 -0500 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: References: Message-ID: <80DC6D6F-E608-4E84-B758-9C63F584DBC3@puck.nether.net> > On Nov 28, 2016, at 12:53 PM, Kasper Adel wrote: > > Hi, > > Vendor X wants you to run their VNF (Router, Firewall or Whatever) and they > refuse to give you root access, or any means necessary to do 'maintenance' > kind of work, whether its applying security updates, or any other similar > type of task that is needed for you to integrate the Linux VM into your IT > eco-system. > > Would this be an acceptable offering in today's IT from different type of > Enterprises (Minux the Googles, Facebooks...etc) ? my experiences say that most people would accept this. things like IT are a cost and any way to externalize that cost makes sense. If you look at something like a SMB service, where you have mandatory NID or provider managed CPE/handoff, having a solution pre-built seems like a no-brainer. Of course, if you?re on nanog@ chances are you could build your own pfSense based solution or iptables setup. The question is does it scale, or how do you scale or automate it? There are only so many Mark/Jared/Kasper?s out there. I look at what happened with Hotel networking, with consolidation by a few players like wayport, er AT&T and you have a mostly stable workable product that has all the warts you?d expect from a consistent product delivery. What I?ve observed from our customers, they appreciate consistent service delivery globally, and the same would likely apply to those wanting to purchase a managed firewall service. - jared From mark.tinka at seacom.mu Mon Nov 28 18:34:15 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 28 Nov 2016 20:34:15 +0200 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: <80DC6D6F-E608-4E84-B758-9C63F584DBC3@puck.nether.net> References: <80DC6D6F-E608-4E84-B758-9C63F584DBC3@puck.nether.net> Message-ID: <677b1fe8-4281-596d-c5b1-1a37b59bdef6@seacom.mu> On 28/Nov/16 20:10, Jared Mauch wrote: > my experiences say that most people would accept this. things like IT are a cost > and any way to externalize that cost makes sense. If you look at something like > a SMB service, where you have mandatory NID or provider managed CPE/handoff, > having a solution pre-built seems like a no-brainer. Agreed - if the customer neither has nor wants to maintain the skill-set necessary to operate the solution, then outsourcing it to a vendor (or their partner) means they will want to make sure the customer does not have the chance to mess it up. So yes, if I were in the vendor's/partner's position, I'd lock down root as well. But if you're a power user and have the team for this, I'd walk. Mark. From president at isoc-ny.org Mon Nov 28 03:27:08 2016 From: president at isoc-ny.org (Joly MacFie) Date: Sun, 27 Nov 2016 22:27:08 -0500 Subject: Voice channels (FTTH, DOCSIS, VoLTE) In-Reply-To: <316009285.43782.1480301237176.JavaMail.zimbra@baylink.com> References: <58329B31.3070806@vaxination.ca> <316009285.43782.1480301237176.JavaMail.zimbra@baylink.com> Message-ID: On Sun, Nov 27, 2016 at 9:47 PM, Jay R. Ashworth wrote: > That is congruent with my understanding of how cableco voice is > provisioned; > it has different rules WRT VoN -- specifically about 911 -- because the > cable > company segregates it and handles it differently (your cablemodem is > expected > to be tied to your service address -- or whatever terminal device does the > voice). > ?I've seen some telco types refer to this as VuIP i.e. "under IP" to differentiate? from VoIP such as Skype , Vonage, etc Not sure if this applies to LTE. j -- Joly MacFie President - Internet Society New York Chapter (ISOC-NY) http://isoc-ny.org 218 565 9365 From brian at turnkeyinternet.net Mon Nov 28 13:13:06 2016 From: brian at turnkeyinternet.net (Brian Ellwood) Date: Mon, 28 Nov 2016 08:13:06 -0500 Subject: Softlayer abuse contact Message-ID: Could someone with Softlayer abuse contact me off list? I have a netblock that cannot communicate with your network - emailed abuse@ about 2 weeks ago and didn't hear back. Thank you. From rsk at gsp.org Mon Nov 28 18:44:25 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 28 Nov 2016 13:44:25 -0500 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: References: Message-ID: <20161128184425.GA5272@gsp.org> On Mon, Nov 28, 2016 at 09:53:41AM -0800, Kasper Adel wrote: > Vendor X wants you to run their VNF (Router, Firewall or Whatever) and they > refuse to give you root access, or any means necessary to do 'maintenance' > kind of work, whether its applying security updates, or any other similar > type of task that is needed for you to integrate the Linux VM into your IT > eco-system. Thus simultaneously (a) making vendor X a far more attractive target for attacks and (b) ensuring that when -- not if, when -- vendor X has its infrastructure compromised that the attackers will shortly thereafter own part of your network, for a value of "your" equal to "all customers of vendor X". (By the way, this isn't really much of a leap on my part, since it's already happened.) ---rsk From egon at egon.cc Mon Nov 28 18:44:07 2016 From: egon at egon.cc (James Downs) Date: Mon, 28 Nov 2016 10:44:07 -0800 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: References: Message-ID: <20161128184407.GA7243@nemesis.egontech.com> On Mon, Nov 28, 2016 at 09:53:41AM -0800, Kasper Adel wrote: > Would this be an acceptable offering in today's IT from different type of > Enterprises (Minux the Googles, Facebooks...etc) ? The comments from others on this thread have some good points to make, but in my experience, even at places that outsource to SaaS, a black box on the internal network isn't going to fly. Cheers, -j From rbf+nanog at panix.com Mon Nov 28 18:56:40 2016 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Mon, 28 Nov 2016 12:56:40 -0600 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: <20161128184425.GA5272@gsp.org> References: <20161128184425.GA5272@gsp.org> Message-ID: <20161128185640.GA24813@panix.com> On Mon, Nov 28, 2016 at 01:44:25PM -0500, Rich Kulawiec wrote: > On Mon, Nov 28, 2016 at 09:53:41AM -0800, Kasper Adel wrote: > > Vendor X wants you to run their VNF (Router, Firewall or Whatever) and they > > refuse to give you root access, or any means necessary to do 'maintenance' > > kind of work, whether its applying security updates, or any other similar > > type of task that is needed for you to integrate the Linux VM into your IT > > eco-system. > > Thus simultaneously (a) making vendor X a far more attractive target for > attacks and (b) ensuring that when -- not if, when -- vendor X has its > infrastructure compromised that the attackers will shortly thereafter > own part of your network, for a value of "your" equal to "all customers > of vendor X". > > (By the way, this isn't really much of a leap on my part, since it's > already happened.) Sure. But that's mostly the risk of running a black-box appliance. It doesn't really matter if it's a VM or a piece of hardware. Businesses that are comfortable with physical appliances (running on Intel hardware under the covers) for Router/Firewall/Whatever accept little additional risk if they then run that same code on a VM. (Sure, there's the possibility of the virtual appliance being compromised, and then being used to exploit a hypervisor bug that allows breaking out of the VM. So the risk isn't *zero*. But the overwhelming majority of the risk comes from the decision to run the appliance, not the HW vs. VM decision.) -- Brett From hannigan at gmail.com Mon Nov 28 20:03:44 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 28 Nov 2016 15:03:44 -0500 Subject: Softlayer abuse contact In-Reply-To: References: Message-ID: [ Has been coming up a lot lately. A public response may be useful, YMMV ] After abuse@, which many still do answer, I try the SOA (which is really old fashioned I guess) if I don't get an answer from abuse@ ;; ANSWER SECTION: softlayer.com. 900 IN SOA ns1.softlayer.net. root.softlayer.com. 2016101401 7200 600 1728000 43200 More and more blocking cases these days are also related to IP reputation and malware infections. I'm not aware of any self service capabilities for at least confirmation. Once you're spotted, many application layer firewalls refuse to service your requests e.g. webserver claiming "not allowed". Softlayer was also acquired by IBM. Could try their SOA: ;; ANSWER SECTION: ibm.com. 86400 IN SOA asia3.akam.net. hostmaster.akamai.com. 1480273175 43200 7200 604800 3600 [ I'd go with whoever owns the IP address space you are trying to reach regardless of a packet filter or application filter ] WHOIS queries on the domain occasionally point to someone with clue. Registry Registrant ID: Registrant Name: Domain Administrator Registrant Organization: Softlayer Technologies, Inc. Registrant Street: 4849 Alpha Road Registrant City: Dallas Registrant State/Province: TX Registrant Postal Code: 75244 Registrant Country: US Registrant Phone: XXXX (look it up, it's there ) Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: XXXXXX In the last few years, and when near the end of the road, the twittersphere has proven an awesome mechanism to reach out and touch someone. I've had 100% success there. If you have a peering relationship, IMHO opinion it is fair game to try them if all else fails. Most peering teams are super happy to help get you to the right people and especially if you've tried. Helping someone solve a problem via peering relationships has always brought a smile to my face and made that five o'clock beer taste even better. Good luck! Cheers, -M< On Mon, Nov 28, 2016 at 8:13 AM, Brian Ellwood via NANOG wrote: > Could someone with Softlayer abuse contact me off list? > > I have a netblock that cannot communicate with your network - emailed > abuse@ about 2 weeks ago and didn't hear back. > > Thank you. > > From riel at surriel.com Mon Nov 28 18:46:19 2016 From: riel at surriel.com (Rik van Riel) Date: Mon, 28 Nov 2016 13:46:19 -0500 Subject: Comcast business IPv6 vs rbldnsd & PSBL Message-ID: <1480358779.9604.1.camel@surriel.com> First of all, kudos to Comcast for trying to roll out IPv6 across their entire network. Static IPv6 netblocks seem to be available for Comcast business users, and IPv6 is enabled unconditionally in the CPE routers used by Comcast business class internet. Unfortunately, the software in the two available CPE routers (SMC & Cisco) is horribly broken when it comes to IPv6. The TL;DR summary: even when IPv6 firewalling is disabled in the configuration, the router still tracks every IPv6 "connection", which causes every single DNS lookup to fill up a slot in its connection tracking table. The router's logs say it blocks tens of thousands of IPv6 connections every day, despite firewalling being "disabled" on the router. Once the connection tracking table fills up, both IPv6 and IPv4 start having trouble, with packet loss on ICMP, high ping times to the local router (and the internet), and new connections not establishing. The router randomly crashes and reboots too, sometimes multiple times a day. This ends up breaking both IPv6 and IPv4. It only takes about 300kbit/s of DNS traffic to trigger the bug, in both the SMC and the Cisco routers. Are there any Comcast NOC or other technical people present who could help? I am interested both in helping resolve the firmware issues in the routers (there will no doubt be other customers who hit this in the future, as IPv6 becomes ore common) or, if that is not an option, finding some way to avoid the issue. http://forums.businesshelp.comcast.com/t5/Equipment-Modems-Gateways/Cis co-DPC3941B-slows-to-a-crawl-and-crashes-several-times-a-day/td-p/30807 -- All Rights Reversed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From xxnog at ledeuns.net Tue Nov 29 08:36:14 2016 From: xxnog at ledeuns.net (Denis Fondras) Date: Tue, 29 Nov 2016 09:36:14 +0100 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: References: Message-ID: <20161129083614.GQ28073@carcass.ledeuns.net> > On 28/Nov/16 19:53, Kasper Adel wrote: > > Hi, > > Vendor X wants you to run their VNF (Router, Firewall or Whatever) and they > refuse to give you root access, or any means necessary to do 'maintenance' > kind of work, whether its applying security updates, or any other similar > type of task that is needed for you to integrate the Linux VM into your IT > eco-system. > > Would this be an acceptable offering in today's IT from different type of > Enterprises (Minux the Googles, Facebooks...etc) ? > As long as the vendor will be held liable for ANY (and I mean it) problem that could happen on my infrastructure. From a.harrowell at gmail.com Tue Nov 29 10:55:07 2016 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Tue, 29 Nov 2016 10:55:07 +0000 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: <20161129083614.GQ28073@carcass.ledeuns.net> References: <20161129083614.GQ28073@carcass.ledeuns.net> Message-ID: This is a really interesting thread; my telco clients are mad keen on various solutions of this general form. As a rule they would love to consolidate their various SME and enterprise CPEs down to a single x86 box that gets configured with VNFs from a central VIM or container pool. But they'd also love to sell you all your networking out of that box - and one of the big questions I have is just how many companies would accept "LAN as a Service". It may be even more difficult for SMEs as the cost of going back on the deal is higher the less in-house capability you have. On Tue, Nov 29, 2016 at 8:36 AM, Denis Fondras wrote: > > On 28/Nov/16 19:53, Kasper Adel wrote: > > > > Hi, > > > > Vendor X wants you to run their VNF (Router, Firewall or Whatever) and > they > > refuse to give you root access, or any means necessary to do > 'maintenance' > > kind of work, whether its applying security updates, or any other similar > > type of task that is needed for you to integrate the Linux VM into your > IT > > eco-system. > > > > Would this be an acceptable offering in today's IT from different type of > > Enterprises (Minux the Googles, Facebooks...etc) ? > > > > As long as the vendor will be held liable for ANY (and I mean it) problem > that > could happen on my infrastructure. > From mark.tinka at seacom.mu Tue Nov 29 11:35:34 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 29 Nov 2016 13:35:34 +0200 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: References: <20161129083614.GQ28073@carcass.ledeuns.net> Message-ID: On 29/Nov/16 12:55, Alexander Harrowell wrote: > This is a really interesting thread; my telco clients are mad keen on > various solutions of this general form. As a rule they would love to > consolidate their various SME and enterprise CPEs down to a single x86 box > that gets configured with VNFs from a central VIM or container pool. But > they'd also love to sell you all your networking out of that box - and one > of the big questions I have is just how many companies would accept "LAN as > a Service". It may be even more difficult for SMEs as the cost of going > back on the deal is higher the less in-house capability you have. I'd say it's reasonably common. We have a number of 3rd party companies running the LAN's of our enterprise customers, here in Africa. Mark. From johnstong at westmancom.com Tue Nov 29 14:19:20 2016 From: johnstong at westmancom.com (Graham Johnston) Date: Tue, 29 Nov 2016 14:19:20 +0000 Subject: Brocade MLXe Selective FIB Population Message-ID: <82C0CE81789FE64D8F4D152631918297117DA559@MSG6.westman.int> Does anybody have information on how to selective populate the IPv4 FIB on a Brocade MLXe? Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From bicknell at ufp.org Tue Nov 29 15:02:42 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 29 Nov 2016 07:02:42 -0800 Subject: Accepting a Virtualized Functions (VNFs) into Corporate IT In-Reply-To: <80DC6D6F-E608-4E84-B758-9C63F584DBC3@puck.nether.net> References: <80DC6D6F-E608-4E84-B758-9C63F584DBC3@puck.nether.net> Message-ID: <20161129150241.GA45887@ussenterprise.ufp.org> In a message written on Mon, Nov 28, 2016 at 01:10:29PM -0500, Jared Mauch wrote: > my experiences say that most people would accept this. things like IT are a cost > and any way to externalize that cost makes sense. If you look at something like > a SMB service, where you have mandatory NID or provider managed CPE/handoff, > having a solution pre-built seems like a no-brainer. Historically, I agree. However I sense the winds are changing on this issue. Various auditors and certification schemes have changed over the past 2-3 years to be much more skeptical of these sorts of devices. They want to see "endpoint security" (AV and/or Fingerprinting) on all devices. To the extent these "appliance" VM's are standard OS's (often CentOS) they are more insistant it should be possible. Where it is not possible, they want to see severe network quarantine, for instance per host firewalls to lock down the devices. I'm not sure why the OP was asking, but if they are developing a new product of this type I might suggest they consider their response to a customer who says they need endpoint security on it before building it. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From tj at pcguys.us Tue Nov 29 09:06:00 2016 From: tj at pcguys.us (TJ Trout) Date: Tue, 29 Nov 2016 01:06:00 -0800 Subject: 10G switch drops traffic for a split second Message-ID: I recently upgraded my core network from 1G to 10G and after the upgrade I have noticed that my 10G switch during peak traffic (1500mbps, 100,000pps) seems to be dropping traffic for a split second across all ports and all vlans. I immediately replaced the switch with a different brand/model and the problem persists. Sometimes traffic drops to zero, others it drops to 50%, problem is very random but seems to occur with much more frequency during high PPS (pushing high traffic / iperf does not induce problem) Could this be MTU? I've tried flow control, hard code duplex, stp on/off etc I'm at a loss any ideas? TJ Trout Volt Broadband From lguillory at reservetele.com Tue Nov 29 16:29:52 2016 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 29 Nov 2016 16:29:52 +0000 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFAFD87A9@RTC-EXCH01.RESERVE.LDS> What model switch? What's the config look like, all L2 or L3 as well? Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of TJ Trout Sent: Tuesday, November 29, 2016 3:06 AM To: nanog at nanog.org Subject: 10G switch drops traffic for a split second I recently upgraded my core network from 1G to 10G and after the upgrade I have noticed that my 10G switch during peak traffic (1500mbps, 100,000pps) seems to be dropping traffic for a split second across all ports and all vlans. I immediately replaced the switch with a different brand/model and the problem persists. Sometimes traffic drops to zero, others it drops to 50%, problem is very random but seems to occur with much more frequency during high PPS (pushing high traffic / iperf does not induce problem) Could this be MTU? I've tried flow control, hard code duplex, stp on/off etc I'm at a loss any ideas? TJ Trout Volt Broadband From cra at WPI.EDU Tue Nov 29 16:32:53 2016 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 29 Nov 2016 11:32:53 -0500 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: <20161129163253.GK21085@angus.ind.wpi.edu> Without more detail, I'm grasping at straws here, but see this recent thread about QoS and microbursts on the juniper-nsp list: https://puck.nether.net/pipermail/juniper-nsp/2016-November/033692.html Do you have ports with different speeds connected? Another idea: Are you using Spanning Tree Protocol and seeing lots of TCNs? On Tue, Nov 29, 2016 at 01:06:00AM -0800, TJ Trout wrote: > I recently upgraded my core network from 1G to 10G and after the upgrade I > have noticed that my 10G switch during peak traffic (1500mbps, 100,000pps) > seems to be dropping traffic for a split second across all ports and all > vlans. I immediately replaced the switch with a different brand/model and > the problem persists. > > Sometimes traffic drops to zero, others it drops to 50%, problem is very > random but seems to occur with much more frequency during high PPS (pushing > high traffic / iperf does not induce problem) > > Could this be MTU? I've tried flow control, hard code duplex, stp on/off etc > > I'm at a loss any ideas? > > TJ Trout > Volt Broadband From jtk at depaul.edu Tue Nov 29 17:39:41 2016 From: jtk at depaul.edu (John Kristoff) Date: Tue, 29 Nov 2016 11:39:41 -0600 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: <20161129113941.24d27968@p50.localdomain> On Tue, 29 Nov 2016 09:06:00 +0000 TJ Trout wrote: > Could this be MTU? I've tried flow control, hard code duplex, stp on/off etc > I'm at a loss any ideas? This sounds like a common problem that certain data center environments run into with 10 Gb/s and higher loads. In a nutshell, a simple throw money at it solution to the problem is to use a switch with larger buffers. Nonetheless, there are plenty of good sources of material about the phenomenon, such as: John From Jason_Livingood at comcast.com Tue Nov 29 17:45:39 2016 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Tue, 29 Nov 2016 17:45:39 +0000 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: <1480358779.9604.1.camel@surriel.com> References: <1480358779.9604.1.camel@surriel.com> Message-ID: I can send it along to folks here at Comcast. - Jason On 11/28/16, 1:46 PM, "NANOG on behalf of Rik van Riel" wrote: First of all, kudos to Comcast for trying to roll out IPv6 across their entire network. Static IPv6 netblocks seem to be available for Comcast business users, and IPv6 is enabled unconditionally in the CPE routers used by Comcast business class internet. Unfortunately, the software in the two available CPE routers (SMC & Cisco) is horribly broken when it comes to IPv6. The TL;DR summary: even when IPv6 firewalling is disabled in the configuration, the router still tracks every IPv6 "connection", which causes every single DNS lookup to fill up a slot in its connection tracking table. The router's logs say it blocks tens of thousands of IPv6 connections every day, despite firewalling being "disabled" on the router. Once the connection tracking table fills up, both IPv6 and IPv4 start having trouble, with packet loss on ICMP, high ping times to the local router (and the internet), and new connections not establishing. The router randomly crashes and reboots too, sometimes multiple times a day. This ends up breaking both IPv6 and IPv4. It only takes about 300kbit/s of DNS traffic to trigger the bug, in both the SMC and the Cisco routers. Are there any Comcast NOC or other technical people present who could help? I am interested both in helping resolve the firmware issues in the routers (there will no doubt be other customers who hit this in the future, as IPv6 becomes ore common) or, if that is not an option, finding some way to avoid the issue. http://forums.businesshelp.comcast.com/t5/Equipment-Modems-Gateways/Cis co-DPC3941B-slows-to-a-crawl-and-crashes-several-times-a-day/td-p/30807 -- All Rights Reversed. From swmike at swm.pp.se Tue Nov 29 17:47:22 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 29 Nov 2016 18:47:22 +0100 (CET) Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: On Tue, 29 Nov 2016, TJ Trout wrote: > Could this be MTU? I've tried flow control, hard code duplex, stp on/off > etc As others have pointed out, you probably have a switch with small buffers. If you also have flow control and you have something that triggers flow control to turn off packet forwarding, your small-buffer-switch might fill up all (shared) buffers on that port and now you're dropping traffic to all ports. So trying to find if you have something where flow control is enabled and is being triggered might be something worthwhile to do, and also perhaps just turn off flow control on all ports to make sure. -- Mikael Abrahamsson email: swmike at swm.pp.se From hugo at slabnet.com Tue Nov 29 18:23:41 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 29 Nov 2016 10:23:41 -0800 Subject: BFD on back-to-back connected BGP-speakers Message-ID: <20161129182341.GB16300@bamboo.slabnet.com> Good morning, nanog, Is there any/sufficient benefit in adding BFD onto BGP sessions between directly-connected routers? If we have intermediate L2 devices such that we can't reliably detect link failures BFD can help us quickly detect peers going away even when link remains up, but what about sessions with: - eBGP with peering to interface addresses (not loopback) - no multi-hop - direct back-to-back connections (no intermediate devices except patch panels) Possible failure scenarios where I could see this helping would be fat fingering (filters implemented on one or the other side drops traffic from the peer) or e.g. something catastrophic that causes the control plane to go away without any last gasp to the peer. Or is adding BFD into the mix in this type of setup getting into increasing effort/complexity (an additional protocol) for dimishing returns? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bryan at shout.net Tue Nov 29 18:28:44 2016 From: bryan at shout.net (Bryan Holloway) Date: Tue, 29 Nov 2016 12:28:44 -0600 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: References: <1480358779.9604.1.camel@surriel.com> Message-ID: <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> I concur with the kudos bit, but I'll also concur that the CPE support appears to be limited. Another example: IPv6 prefix delegation is broken on the SMCD3G-CCR, and according to the following threads: http://www.gossamer-threads.com/lists/nsp/ipv6/54761 (scroll down to the IPv6 OPERATIONS - BUSINESS section) http://forums.businesshelp.comcast.com/t5/IPV6/Dual-Stack-on-SMC-D3GCCR-and-Cisco-DPC3939B/td-p/20504 ... others have the same issue and there isn't much of an incentive to fix it. When I asked if I could use my own CPE, I was told no, because I'm a "business customer", which is a requirement if you want static v4 IPs. Anyone have any success with a different model CPE and Comcast v6? I love that they hand out a /56 by default, but it's not of much use if I can only use a single /64. - bryan On 11/29/16 11:45 AM, Livingood, Jason wrote: > I can send it along to folks here at Comcast. > > - Jason > > On 11/28/16, 1:46 PM, "NANOG on behalf of Rik van Riel" wrote: > > First of all, kudos to Comcast for trying to roll out IPv6 across > their entire network. Static IPv6 netblocks seem to be available > for Comcast business users, and IPv6 is enabled unconditionally > in the CPE routers used by Comcast business class internet. > > Unfortunately, the software in the two available CPE routers > (SMC & Cisco) is horribly broken when it comes to IPv6. > > The TL;DR summary: even when IPv6 firewalling is disabled in > the configuration, the router still tracks every IPv6 "connection", > which causes every single DNS lookup to fill up a slot in its > connection tracking table. > > The router's logs say it blocks tens of thousands of IPv6 > connections every day, despite firewalling being "disabled" on > the router. > > Once the connection tracking table fills up, both IPv6 and IPv4 > start having trouble, with packet loss on ICMP, high ping times > to the local router (and the internet), and new connections not > establishing. The router randomly crashes and reboots too, > sometimes multiple times a day. > > This ends up breaking both IPv6 and IPv4. > > It only takes about 300kbit/s of DNS traffic to trigger the bug, > in both the SMC and the Cisco routers. > > Are there any Comcast NOC or other technical people present who > could help? > > I am interested both in helping resolve the firmware issues in > the routers (there will no doubt be other customers who hit this > in the future, as IPv6 becomes ore common) or, if that is not an > option, finding some way to avoid the issue. > > > http://forums.businesshelp.comcast.com/t5/Equipment-Modems-Gateways/Cis > co-DPC3941B-slows-to-a-crawl-and-crashes-several-times-a-day/td-p/30807 > > -- > All Rights Reversed. > From jared at puck.nether.net Tue Nov 29 18:34:32 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 29 Nov 2016 13:34:32 -0500 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> References: <1480358779.9604.1.camel@surriel.com> <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> Message-ID: <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> Folks at Comcast have told me to ask for the SMC gateway to be replaced with either the netgear or Cisco to solve that issue. Jared Mauch > On Nov 29, 2016, at 1:28 PM, Bryan Holloway wrote: > > I concur with the kudos bit, but I'll also concur that the CPE support appears to be limited. Another example: IPv6 prefix delegation is broken on the SMCD3G-CCR, and according to the following threads: > > http://www.gossamer-threads.com/lists/nsp/ipv6/54761 (scroll down to the IPv6 OPERATIONS - BUSINESS section) > > http://forums.businesshelp.comcast.com/t5/IPV6/Dual-Stack-on-SMC-D3GCCR-and-Cisco-DPC3939B/td-p/20504 > > ... others have the same issue and there isn't much of an incentive to fix it. > > When I asked if I could use my own CPE, I was told no, because I'm a "business customer", which is a requirement if you want static v4 IPs. > > Anyone have any success with a different model CPE and Comcast v6? I love that they hand out a /56 by default, but it's not of much use if I can only use a single /64. > > - bryan > > >> On 11/29/16 11:45 AM, Livingood, Jason wrote: >> I can send it along to folks here at Comcast. >> >> - Jason >> >> On 11/28/16, 1:46 PM, "NANOG on behalf of Rik van Riel" wrote: >> >> First of all, kudos to Comcast for trying to roll out IPv6 across >> their entire network. Static IPv6 netblocks seem to be available >> for Comcast business users, and IPv6 is enabled unconditionally >> in the CPE routers used by Comcast business class internet. >> >> Unfortunately, the software in the two available CPE routers >> (SMC & Cisco) is horribly broken when it comes to IPv6. >> >> The TL;DR summary: even when IPv6 firewalling is disabled in >> the configuration, the router still tracks every IPv6 "connection", >> which causes every single DNS lookup to fill up a slot in its >> connection tracking table. >> >> The router's logs say it blocks tens of thousands of IPv6 >> connections every day, despite firewalling being "disabled" on >> the router. >> >> Once the connection tracking table fills up, both IPv6 and IPv4 >> start having trouble, with packet loss on ICMP, high ping times >> to the local router (and the internet), and new connections not >> establishing. The router randomly crashes and reboots too, >> sometimes multiple times a day. >> >> This ends up breaking both IPv6 and IPv4. >> >> It only takes about 300kbit/s of DNS traffic to trigger the bug, >> in both the SMC and the Cisco routers. >> >> Are there any Comcast NOC or other technical people present who >> could help? >> >> I am interested both in helping resolve the firmware issues in >> the routers (there will no doubt be other customers who hit this >> in the future, as IPv6 becomes ore common) or, if that is not an >> option, finding some way to avoid the issue. >> >> >> http://forums.businesshelp.comcast.com/t5/Equipment-Modems-Gateways/Cis >> co-DPC3941B-slows-to-a-crawl-and-crashes-several-times-a-day/td-p/30807 >> >> -- >> All Rights Reversed. >> From deleskie at gmail.com Tue Nov 29 18:46:54 2016 From: deleskie at gmail.com (jim deleskie) Date: Tue, 29 Nov 2016 14:46:54 -0400 Subject: BFD on back-to-back connected BGP-speakers In-Reply-To: <20161129182341.GB16300@bamboo.slabnet.com> References: <20161129182341.GB16300@bamboo.slabnet.com> Message-ID: Hugo, I've used this configuration in a past line when I may of had multiple L2 steps between L3 devices. The only concern we had was around load BFD put on _some_ endpoint routers, if was handles on the RouteProcessor vs on line cards. -jim On Tue, Nov 29, 2016 at 2:23 PM, Hugo Slabbert wrote: > Good morning, nanog, > > Is there any/sufficient benefit in adding BFD onto BGP sessions between > directly-connected routers? If we have intermediate L2 devices such that > we can't reliably detect link failures BFD can help us quickly detect peers > going away even when link remains up, but what about sessions with: > > - eBGP with peering to interface addresses (not loopback) > - no multi-hop > - direct back-to-back connections (no intermediate devices except patch > panels) > > Possible failure scenarios where I could see this helping would be fat > fingering (filters implemented on one or the other side drops traffic from > the peer) or e.g. something catastrophic that causes the control plane to > go away without any last gasp to the peer. > > Or is adding BFD into the mix in this type of setup getting into > increasing effort/complexity (an additional protocol) for dimishing returns? > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > From ryan.nsplist at gmail.com Tue Nov 29 19:13:13 2016 From: ryan.nsplist at gmail.com (Ryan L) Date: Tue, 29 Nov 2016 14:13:13 -0500 Subject: BFD on back-to-back connected BGP-speakers In-Reply-To: <20161129182341.GB16300@bamboo.slabnet.com> References: <20161129182341.GB16300@bamboo.slabnet.com> Message-ID: Hugo, I think those are all valid potential reasons to use BFD. I use it for some of the same reasons even on direct connect peers. Only time I ever recall actively avoiding it if I had the capability was if I had NSF/SSO, since they didn't used to (still don't?) play very well together. On Tue, Nov 29, 2016 at 1:23 PM, Hugo Slabbert wrote: > Good morning, nanog, > > Is there any/sufficient benefit in adding BFD onto BGP sessions between > directly-connected routers? If we have intermediate L2 devices such that > we can't reliably detect link failures BFD can help us quickly detect peers > going away even when link remains up, but what about sessions with: > > - eBGP with peering to interface addresses (not loopback) > - no multi-hop > - direct back-to-back connections (no intermediate devices except patch > panels) > > Possible failure scenarios where I could see this helping would be fat > fingering (filters implemented on one or the other side drops traffic from > the peer) or e.g. something catastrophic that causes the control plane to > go away without any last gasp to the peer. > > Or is adding BFD into the mix in this type of setup getting into > increasing effort/complexity (an additional protocol) for dimishing returns? > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > From riel at surriel.com Tue Nov 29 19:13:59 2016 From: riel at surriel.com (Rik van Riel) Date: Tue, 29 Nov 2016 14:13:59 -0500 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> References: <1480358779.9604.1.camel@surriel.com> <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> Message-ID: <1480446839.31110.13.camel@surriel.com> On Tue, 2016-11-29 at 13:34 -0500, Jared Mauch wrote: > Folks at Comcast have told me to ask for the SMC gateway to be > replaced with either the netgear or Cisco to solve that issue.? Over the past year and a bit, I have had all three of the Comcast business routers in my network. The Netgear only stayed for one day - after about 10-15 minutes of "heavy" (~300kbit/s) DNS lookups coming in from the outside, it was almost impossible to make new TCP connections across the router, either IPv4 or IPv6. The SMC D3G-CCR mostly worked, except at some point during the year, the fraction of traffic going over IPv6 went high enough to wreck the D3G, causing it to crash and reboot several times a day, without having enough diagnostics for me to figure out what was going on. The Cisco DPC3941B seems to fail in pretty much the same way as the SMC D3G-CCR, but it has enough diagnostics that I could finally figure out what was happening. With "Gateway Smart Packet Detection" disabled, and the "Firewall completely disabled", the logs are still showing tens of thousands of dropped IPv6 connections every day. In other words, the config options that supposedly disable the firewall completely, do not in fact disable the firewall code, and I am still hitting connection tracking limits. DNS lookups coming from randomized port numbers (to avoid spoofing issues) mean every DNS query takes up another slot in the connection tracking table. Once the table is full, the router will search for a re-usable slot before routing a packet. This can cause ping times to 10.1.10.1 (the router) to go as high as 800ms. This is from a system sitting 5ft from the router. If the router does not find any re-usable slot in the connection tracking table, packets can get lost. This leads to the "fun" scenario where pinging the router from a system directly connected to it shows 30% packet loss, while streaming video over an already established TCP stream continues at full speed! Not a symptom I ever expected to see... -- All rights reversed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From randy at psg.com Tue Nov 29 19:40:30 2016 From: randy at psg.com (Randy Bush) Date: Tue, 29 Nov 2016 11:40:30 -0800 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: <1480446839.31110.13.camel@surriel.com> References: <1480358779.9604.1.camel@surriel.com> <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> <1480446839.31110.13.camel@surriel.com> Message-ID: i am running my own (why rent at silly costs) dpc3008 and wfm. randy From swmike at swm.pp.se Tue Nov 29 19:43:55 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 29 Nov 2016 20:43:55 +0100 (CET) Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: <1480446839.31110.13.camel@surriel.com> References: <1480358779.9604.1.camel@surriel.com> <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> <1480446839.31110.13.camel@surriel.com> Message-ID: On Tue, 29 Nov 2016, Rik van Riel wrote: > Not a symptom I ever expected to see... It's pretty obvious that the CPEs being sold for this "business service" isn't meant for the kind of service you run. They're probably doing connection tracking for ACK optimization, this should not be done for UDP but it's still being done. They probably have a connection limit of a few thousand connections (not uncommon for these kinds of devices) and it's not possible to turn off what you need to turn off to make them work correctly. Do you have any other options in your area for other ISPs that can offer a better service for you? Otherwise you might hack around it by running an IPSEC/UDP tunnel to somewhere else where there isn't this kind of connection limit. -- Mikael Abrahamsson email: swmike at swm.pp.se From lguillory at reservetele.com Tue Nov 29 19:48:48 2016 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 29 Nov 2016 19:48:48 +0000 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: References: <1480358779.9604.1.camel@surriel.com> <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> <1480446839.31110.13.camel@surriel.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFAFD8FDA@RTC-EXCH01.RESERVE.LDS> Because if you want static IPs from them you must rent one of the following. Cisco DPC3939B or DPC3941B Netgear CG3000DCR SMC Networks SMCD3G Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush Sent: Tuesday, November 29, 2016 1:41 PM To: Rik van Riel Cc: North American Network Operators' Group Subject: Re: Comcast business IPv6 vs rbldnsd & PSBL i am running my own (why rent at silly costs) dpc3008 and wfm. randy From saku at ytti.fi Tue Nov 29 19:57:28 2016 From: saku at ytti.fi (Saku Ytti) Date: Tue, 29 Nov 2016 21:57:28 +0200 Subject: BFD on back-to-back connected BGP-speakers In-Reply-To: <20161129182341.GB16300@bamboo.slabnet.com> References: <20161129182341.GB16300@bamboo.slabnet.com> Message-ID: On 29 November 2016 at 20:23, Hugo Slabbert wrote: Hey, > - eBGP with peering to interface addresses (not loopback) > - no multi-hop > - direct back-to-back connections (no intermediate devices except patch > panels) > > Possible failure scenarios where I could see this helping would be fat > fingering (filters implemented on one or the other side drops traffic from > the peer) or e.g. something catastrophic that causes the control plane to go > away without any last gasp to the peer. > > Or is adding BFD into the mix in this type of setup getting into increasing > effort/complexity (an additional protocol) for dimishing returns? If you have HW liveliness detection and fast-failover, I think BFD probably will just reduce availability due its failures being more probable than the edge cases in your setup. I personally would not run BFD here. -- ++ytti From bryan at shout.net Tue Nov 29 19:58:25 2016 From: bryan at shout.net (Bryan Holloway) Date: Tue, 29 Nov 2016 13:58:25 -0600 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFAFD8FDA@RTC-EXCH01.RESERVE.LDS> References: <1480358779.9604.1.camel@surriel.com> <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> <1480446839.31110.13.camel@surriel.com> <8D89F96B7AB1B84F9E049CC7BB91BF5CFAFD8FDA@RTC-EXCH01.RESERVE.LDS> Message-ID: Not to mention that they "raised my rent" a few months ago by $5/mo, which is pretty ludicrous considering that a) it doesn't actually work as advertised, and b) it probably cost them $20-30 to purchase those SMCs wholesale in the first place. They've made their money on my CPE many many times over. But that's just the way it is. On 11/29/16 1:48 PM, Luke Guillory wrote: > Because if you want static IPs from them you must rent one of the following. > > Cisco DPC3939B or DPC3941B > Netgear CG3000DCR > SMC Networks SMCD3G > > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > _________________________________________________________________________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush > Sent: Tuesday, November 29, 2016 1:41 PM > To: Rik van Riel > Cc: North American Network Operators' Group > Subject: Re: Comcast business IPv6 vs rbldnsd & PSBL > > i am running my own (why rent at silly costs) dpc3008 and wfm. > > randy > From jared at puck.nether.net Tue Nov 29 20:07:52 2016 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 29 Nov 2016 15:07:52 -0500 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: References: <1480358779.9604.1.camel@surriel.com> <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> <1480446839.31110.13.camel@surriel.com> Message-ID: Can't do that with the business service. Oh well, to have choices. Jared Mauch > On Nov 29, 2016, at 2:40 PM, Randy Bush wrote: > > i am running my own (why rent at silly costs) dpc3008 and wfm. > > randy From rwebb at ropeguru.com Tue Nov 29 21:18:11 2016 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 29 Nov 2016 16:18:11 -0500 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: References: <1480358779.9604.1.camel@surriel.com><8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net><0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net><1480446839.31110.13.camel@surriel.com> Message-ID: To clarify, you cannot rent AND have static IP's. You can rent your own modem ofr business service when using dynamic IP's. Robert Webb On Tue, 29 Nov 2016 15:07:52 -0500 Jared Mauch wrote: > Can't do that with the business service. Oh well, to have choices. > > Jared Mauch >> On Nov 29, 2016, at 2:40 PM, Randy Bush wrote: >> >> i am running my own (why rent at silly costs) dpc3008 and wfm. >> >> randy From tj at pcguys.us Tue Nov 29 21:28:22 2016 From: tj at pcguys.us (TJ Trout) Date: Tue, 29 Nov 2016 13:28:22 -0800 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: Luke; All l2, no l3. only 4 vlans. 2 peers trunked to a router which trunks back to 2 devices (microwave backhauls). Chuck; All ports are 10g except the 2 peers are 1g and trunk back to a 10g port for the router wan No TCN's Brian; I have tried a IBM G8124 and a Ubiquiti ES-16-XG both show same exact drops across all ports, makes me think it's a config issue. MTU, FC, something. Andrew; I have tried with FC disabled, but I will try that one more time. Mikael; Is it possible to over run the buffers of a 320gbps backplane switch with only 1.5gbps traffic? I think the switch is rated for 140m PPS and I'm only pushing 100k PPS On Tue, Nov 29, 2016 at 9:47 AM, Mikael Abrahamsson wrote: > On Tue, 29 Nov 2016, TJ Trout wrote: > > Could this be MTU? I've tried flow control, hard code duplex, stp on/off >> etc >> > > As others have pointed out, you probably have a switch with small buffers. > > If you also have flow control and you have something that triggers flow > control to turn off packet forwarding, your small-buffer-switch might fill > up all (shared) buffers on that port and now you're dropping traffic to all > ports. > > So trying to find if you have something where flow control is enabled and > is being triggered might be something worthwhile to do, and also perhaps > just turn off flow control on all ports to make sure. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From mloftis at wgops.com Tue Nov 29 21:47:49 2016 From: mloftis at wgops.com (Michael Loftis) Date: Tue, 29 Nov 2016 13:47:49 -0800 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: Yes it is absolutely possible to overrun the buffers. Any kind of backpressure (FC) from hosts, or 10G->1G transitions can easily cause it. Even if in a 10s window you're not over 1G if the 10G sender attempts to back to back too many frames in a row (Like say sendfile() API type calls) BOOM, dropping frames in the switch. On Tue, Nov 29, 2016 at 1:28 PM, TJ Trout wrote: > Luke; > > All l2, no l3. only 4 vlans. 2 peers trunked to a router which trunks back > to 2 devices (microwave backhauls). > > Chuck; > > All ports are 10g except the 2 peers are 1g and trunk back to a 10g port > for the router wan > > No TCN's > > Brian; > > I have tried a IBM G8124 and a Ubiquiti ES-16-XG both show same exact drops > across all ports, makes me think it's a config issue. MTU, FC, something. > > Andrew; > > I have tried with FC disabled, but I will try that one more time. > > Mikael; > > Is it possible to over run the buffers of a 320gbps backplane switch with > only 1.5gbps traffic? I think the switch is rated for 140m PPS and I'm only > pushing 100k PPS From tj at pcguys.us Tue Nov 29 21:53:23 2016 From: tj at pcguys.us (TJ Trout) Date: Tue, 29 Nov 2016 13:53:23 -0800 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: I plan on disabling FC on everything tonight, I've done that before but I want to be sure. Anything that can be done about the 2 x 1G peers trunking to the 10G router transition that can be fixed? should I be rate limiting the vlan for the peers at 1G so the 10G router isn't trying to send more than 1G? On Tue, Nov 29, 2016 at 1:47 PM, Michael Loftis wrote: > Yes it is absolutely possible to overrun the buffers. Any kind of > backpressure (FC) from hosts, or 10G->1G transitions can easily cause > it. Even if in a 10s window you're not over 1G if the 10G sender > attempts to back to back too many frames in a row (Like say sendfile() > API type calls) BOOM, dropping frames in the switch. > > On Tue, Nov 29, 2016 at 1:28 PM, TJ Trout wrote: > > Luke; > > > > All l2, no l3. only 4 vlans. 2 peers trunked to a router which trunks > back > > to 2 devices (microwave backhauls). > > > > Chuck; > > > > All ports are 10g except the 2 peers are 1g and trunk back to a 10g port > > for the router wan > > > > No TCN's > > > > Brian; > > > > I have tried a IBM G8124 and a Ubiquiti ES-16-XG both show same exact > drops > > across all ports, makes me think it's a config issue. MTU, FC, something. > > > > Andrew; > > > > I have tried with FC disabled, but I will try that one more time. > > > > Mikael; > > > > Is it possible to over run the buffers of a 320gbps backplane switch with > > only 1.5gbps traffic? I think the switch is rated for 140m PPS and I'm > only > > pushing 100k PPS > From beckman at angryox.com Tue Nov 29 23:10:28 2016 From: beckman at angryox.com (Peter Beckman) Date: Tue, 29 Nov 2016 18:10:28 -0500 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: On Tue, 29 Nov 2016, TJ Trout wrote: > I plan on disabling FC on everything tonight, I've done that before but I > want to be sure. > > Anything that can be done about the 2 x 1G peers trunking to the 10G router > transition that can be fixed? should I be rate limiting the vlan for the > peers at 1G so the 10G router isn't trying to send more than 1G? This thread reminded me of a blog post that struck me as useful 5 years ago, and again today. Measuring throughput, when dealing with buffers and troubleshooting errors and packet loss, must be done at a sub-one-second sampling rate. http://blog.serverfault.com/2011/06/27/per-second-measurements-dont-cut-it/ Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From mloftis at wgops.com Tue Nov 29 23:16:17 2016 From: mloftis at wgops.com (Michael Loftis) Date: Tue, 29 Nov 2016 15:16:17 -0800 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: Yeah you also have to look for not so obvious things like MAC Pause frames sent/received...QoS counters, all sorts of VERY platform specific stuff. Right royal pain, especially since some do not expose these statistics at all. On Tue, Nov 29, 2016 at 3:10 PM, Peter Beckman wrote: > > On Tue, 29 Nov 2016, TJ Trout wrote: > >> I plan on disabling FC on everything tonight, I've done that before but I >> want to be sure. >> >> Anything that can be done about the 2 x 1G peers trunking to the 10G >> router >> transition that can be fixed? should I be rate limiting the vlan for the >> peers at 1G so the 10G router isn't trying to send more than 1G? > > > This thread reminded me of a blog post that struck me as useful 5 years > ago, and again today. Measuring throughput, when dealing with buffers and > troubleshooting errors and packet loss, must be done at a sub-one-second > sampling rate. > > http://blog.serverfault.com/2011/06/27/per-second-measurements-dont-cut-it/ > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From lguillory at reservetele.com Tue Nov 29 23:16:26 2016 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 29 Nov 2016 23:16:26 +0000 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFAFDC40F@RTC-EXCH01.RESERVE.LDS> Here is the video from Facebook on Monitoring, managing and troubleshooting large scale networks they did last year on the subject as well. https://www.youtube.com/watch?v=BRY9xwg5nAU Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Peter Beckman Sent: Tuesday, November 29, 2016 5:10 PM To: TJ Trout Cc: nanog Subject: Re: 10G switch drops traffic for a split second On Tue, 29 Nov 2016, TJ Trout wrote: > I plan on disabling FC on everything tonight, I've done that before > but I want to be sure. > > Anything that can be done about the 2 x 1G peers trunking to the 10G > router transition that can be fixed? should I be rate limiting the > vlan for the peers at 1G so the 10G router isn't trying to send more than 1G? This thread reminded me of a blog post that struck me as useful 5 years ago, and again today. Measuring throughput, when dealing with buffers and troubleshooting errors and packet loss, must be done at a sub-one-second sampling rate. http://blog.serverfault.com/2011/06/27/per-second-measurements-dont-cut-it/ Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From tomi.hakala at pobox.fi Tue Nov 29 17:06:26 2016 From: tomi.hakala at pobox.fi (Tomi Hakala) Date: Tue, 29 Nov 2016 19:06:26 +0200 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: <3335ea57-7bea-19b9-8e17-c082c5ea65c4@pobox.fi> If you have congestion on outgoing interfaces you are most likely running out of packet buffer space on your switch. Especially campus class switches have small buffers, 4 MB or so and it can run out during high bursts and interface congestion. With some switches you could alleviate problem by rearranging congested interfaces to ports with seperate buffer pool, but you have to check with your switch vendor or documentation if your switches have shared or split buffer pools. Or just replace your switches with ones having deeper buffers. Tomi On 29.11.2016 11.06, TJ Trout wrote: > I recently upgraded my core network from 1G to 10G and after the upgrade I > have noticed that my 10G switch during peak traffic (1500mbps, 100,000pps) > seems to be dropping traffic for a split second across all ports and all > vlans. I immediately replaced the switch with a different brand/model and > the problem persists. > > Sometimes traffic drops to zero, others it drops to 50%, problem is very > random but seems to occur with much more frequency during high PPS (pushing > high traffic / iperf does not induce problem) > > Could this be MTU? I've tried flow control, hard code duplex, stp on/off etc > > I'm at a loss any ideas? > > TJ Trout > Volt Broadband From lorenzo.mainardi at digitelitalia.com Tue Nov 29 18:33:37 2016 From: lorenzo.mainardi at digitelitalia.com (Lorenzo Mainardi) Date: Tue, 29 Nov 2016 18:33:37 +0000 Subject: BRAS/BNG Suggestion Message-ID: Good morning, Could you suggest some vendors of BRAS/BNG for PPPoE termination? We have more than 20.000 users. In my short list there are already Juniper, Cisco and NOKIA/ALU. Do you have any other honorable brand or good experiences? Regards digitel Via della Fortezza 6 - 50129 Firenze www.digitelitalia.com - 800 901 669 Ing. Lorenzo Mainardi Tel +39 055 4624933 Fax +39 055 4624 947 lom at digitelitalia.com From jbaldwin at antinode.net Wed Nov 30 16:25:28 2016 From: jbaldwin at antinode.net (James Baldwin) Date: Wed, 30 Nov 2016 10:25:28 -0600 Subject: Disney Brands GeoIP Contact Message-ID: Does anyone have contacts at Disney or an associated brand (Hulu, Disney, ESPN)? They all appear to have out of date or incorrect GeoIP information for our Level3 block. I have been able to whitelist our corporate locations with Hulu however I have been unable to reach anyone at the other sites. I would love to find out which third party they are using for their information and correct the problem at the source (MaxMind is correct). - James From swmike at swm.pp.se Wed Nov 30 16:43:49 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 30 Nov 2016 17:43:49 +0100 (CET) Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: On Tue, 29 Nov 2016, TJ Trout wrote: > Is it possible to over run the buffers of a 320gbps backplane switch > with only 1.5gbps traffic? I think the switch is rated for 140m PPS and > I'm only pushing 100k PPS If your switch is the typical small-buffered-switch that has become more and more common the past few years, then the entire switch might have buffer to keep packets for 0.1ms or less. So if someone says "flow control off" for 0.1ms, depending on the implementation, you might then start seeing packet drops on all ports until that device turns flow control back on. -- Mikael Abrahamsson email: swmike at swm.pp.se From ler762 at gmail.com Wed Nov 30 16:58:06 2016 From: ler762 at gmail.com (Lee) Date: Wed, 30 Nov 2016 11:58:06 -0500 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: On 11/30/16, Mikael Abrahamsson wrote: > On Tue, 29 Nov 2016, TJ Trout wrote: > >> Is it possible to over run the buffers of a 320gbps backplane switch >> with only 1.5gbps traffic? I think the switch is rated for 140m PPS and >> I'm only pushing 100k PPS > > If your switch is the typical small-buffered-switch that has become more > and more common the past few years, then the entire switch might have > buffer to keep packets for 0.1ms or less. So if someone says "flow control > off" for 0.1ms, depending on the implementation, you might then start > seeing packet drops on all ports until that device turns flow control > back on. I always disabled flow control on the theory that VoIP & flow control are incompatible. just out of curiosity - anyone have it enabled? if so, why? Lee From martijnschmidt at i3d.net Wed Nov 30 18:56:23 2016 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Wed, 30 Nov 2016 19:56:23 +0100 Subject: Brocade MLXe Selective FIB Population In-Reply-To: <82C0CE81789FE64D8F4D152631918297117DA559@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297117DA559@MSG6.westman.int> Message-ID: <07cbfa48-5251-7957-2f68-ae5c1c549d50@i3d.net> Hi Graham, I haven't personally tried this but do have plenty of hands-on experience with the MLXe platform. As far as I understood from previous conversations with my Brocade SE, if your firmware is recent enough and the card doesn't have any ports used in a certain VRF the selective FIB download will happen automatically.. you can verify this with the "show cam-partition usage" command. However, if you want to load a full Internet routing table while running a VRF-capable CAM profile you will need -X2 series linecards with the "cam-mode amod slot #" setting for ports which belong to the default VRF (e.g. the one which contains the 600k+ IPv4 prefixes). All the other cards whose FIB is going to be selectively populated may have -X, -M, or even -DM route table scalability. Best regards, Martijn Schmidt On 11/29/2016 03:19 PM, Graham Johnston wrote: > Does anybody have information on how to selective populate the IPv4 FIB on a Brocade MLXe? > > Graham Johnston > Network Planner > Westman Communications Group > 204.717.2829 > johnstong at westmancom.com > P think green; don't print this email. >