Re: IPv6 and multicast listener discovery
If you enable MLD snooping on your switches, the switch will block multicast going out irrelevant ports. The idea is to reduce broadcast in a broadcast domain. On Fri, Jun 4, 2021 at 11:03 PM William Herrin wrote: > Howdy, > > Question for those more versed in IPv6 than I: Is there any harm from > dropping ICMPv6 multicast listener discovery reports in a network > which does NOT use any multicast routing (i.e. only uses multicast > which stays within the local link). I see a LOT of idle node chatter > in the form of these reports which, of course, flood every station > since they are themselves multicast. As far as I can tell they are > used only to tell a multicast router whether to repeat a particular > set of multicast packets to the instant link. Which in my network is > -never- because there are no routed multicast packets to be repeated. > > Regards, > Bill Herrin > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ >
IPv6 and multicast listener discovery
Howdy, Question for those more versed in IPv6 than I: Is there any harm from dropping ICMPv6 multicast listener discovery reports in a network which does NOT use any multicast routing (i.e. only uses multicast which stays within the local link). I see a LOT of idle node chatter in the form of these reports which, of course, flood every station since they are themselves multicast. As far as I can tell they are used only to tell a multicast router whether to repeat a particular set of multicast packets to the instant link. Which in my network is -never- because there are no routed multicast packets to be repeated. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: BCP38 on public-facing Ubuntu servers
Grant Taylor via NANOG wrote: >On 6/3/21 8:44 AM, William Herrin wrote: >> rp_filter is great until your network is slightly less than a perfect >> hierarchy. Then your Linux "router" starts mysteriously dropping packets >> and, as with allow_local, Linux doesn't have any way to generate logs >> about it so you end up with these mysteriously unexplained packet >> discards matching no conceivable rule in iptables... This failure has >> too often been the bane of my existence when using Linux for advanced >> networking. > >I don't remember the particulars, but I thought that was the domain of >log_martians (net.ipv4.conf.*.log_martians). > >Without log_martians or explicitly looking for such, no, you won't get any >indication of such drops. Yes, enabling the log_martians sysctl will generate a kernel log message for each rp_filter failure (subject to rate limiting). There are also stat counters in /proc/net/stat/rt_cache (one line per CPU) for in_martian_dst and in_martian_src which increment regardless of the log_martians setting. The rp_filter sysctl defaults to strict mode (== 1) on Ubuntu, but can be set to loose mode (== 2); the difference is, essentially, in strict mode the reverse path must be the same interface as the ingress interface, whereas in loose mode the reverse path can be any interface (as long as the source address is reachable). https://www.kernel.org/doc/Documentation/networking/ip-sysctl.rst -J --- -Jay Vosburgh, jay.vosbu...@canonical.com
Re: Arin taking down raking
> 1) unreachable publication point / CA == 'ok, see you in 30 mins on my > next cycle through the world' (no real changes) yup. much ado about nothing > b) revoking some portion of their claimed resources in various forms of > CA == 'ideally a bunch of routes suddenly go unknown' == 'ok' > iii) making a bunch of validatable changes to ROA/certs/content == 'worse > possible outcome, likely to make a bunch of routes invalid' if the CA's pub point is available and the data have been modified, which includes removal, then all sorts of wild things can happen. but there is no need for arin to formally test that last as each of the RIRs has untentionally done so at least once; sometimes for over a day. randy
Weekly Routing Table Report
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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@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 Jun, 2021 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 861529 Prefixes after maximum aggregation (per Origin AS): 325860 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 409458 Total ASes present in the Internet Routing Table: 71380 Prefixes per ASN: 12.07 Origin-only ASes present in the Internet Routing Table: 61374 Origin ASes announcing only one prefix: 25347 Transit ASes present in the Internet Routing Table: 10006 Transit-only ASes present in the Internet Routing Table:318 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 54 Max AS path prepend of ASN ( 48366) 51 Prefixes from unregistered ASNs in the Routing Table: 1039 Number of instances of unregistered ASNs: 1046 Number of 32-bit ASNs allocated by the RIRs: 36221 Number of 32-bit ASNs visible in the Routing Table: 30122 Prefixes from 32-bit ASNs in the Routing Table: 140143 Number of bogon 32-bit ASNs visible in the Routing Table:29 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:526 Number of addresses announced to Internet: 3040850816 Equivalent to 181 /8s, 63 /16s and 179 /24s Percentage of available address space announced: 82.1 Percentage of allocated address space announced: 82.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 291740 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 229660 Total APNIC prefixes after maximum aggregation: 65549 APNIC Deaggregation factor:3.50 Prefixes being announced from the APNIC address blocks: 225654 Unique aggregates announced from the APNIC address blocks:90093 APNIC Region origin ASes present in the Internet Routing Table: 11612 APNIC Prefixes per ASN: 19.43 APNIC Region origin ASes announcing only one prefix: APNIC Region transit ASes present in the Internet Routing Table: 1636 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 31 Number of APNIC region 32-bit ASNs visible in the Routing Table: 6773 Number of APNIC addresses announced to Internet: 774887424 Equivalent to 46 /8s, 47 /16s and 216 /24s APNIC AS Blocks4608-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-147769 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:248257 Total ARIN prefixes after maximum aggregation: 113608 ARIN Deaggregation factor: 2.19 Prefixes being announced from the ARIN address blocks: 248329 Unique aggregates announced from the ARIN address blocks:118437 ARIN Region origin ASes present in the Internet Routing Table:18819 ARIN Prefixes per ASN:13.20 ARIN
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
Baldur Norddahl wrote: Sorry but that claim is completely wrong. Cabling cost scales linearly with the number of cores. My apology to Masataka Ohta for my too strong wording by calling you wrong. The moderators put me in place. I wanted to say I disagree with the claim. I rather thank you for your very strong statements with so obviously wrong reasoning, as it is trivially easy for me and, as you can see, other participants of the list to argue against. It is true that trenching costs are higher than the cables themselves. But that does not mean the cables are cheap and that it is an insignificant cost. Cables + duct is about 20% of our cost to lay down the network. "Cables + duct is about 20%"??? Are you saying reduction of 20% of cost of single star by PON matters if duct cost of PON, which is as significant as that of single star, could be ignored? Maybe. it could actually be 20% of cost reduction, if, in addition, cost of complicated closure and unnecessarily lengthy drop cable cost of PON could be ignored. So? Not having huts with active equipment spread all around is also a huge cost saving that can not be ignored. Are you saying single star has "huts with active equipment"? The reality is that reach of single star without active relays is a lot longer than that of PON, because single star does not use splitters, which is lossy. With a fiber of 0.2dB/km loss, 9dB loss inherent to 8 way splitter of PON means 45km less reach. I should point out that I probably buy more cable than most. The exact pricing is of course not public, but lets say a core cost somewhere between 1 to 2 USD cents per meter. Then When? 50 years ago? Masataka Ohta
Re: NAT devices not translating privileged ports
Current gen Cisco ASA firewalls have logic so that if the connection from a private host originated from a privileged source port, the NAT translation to public IP also uses an unprivileged source port (not necessarily the same source port though). I found out that this behavior can cause issues when you have devices on your network that implement older DNS libraries or configs using UDP 53 as a source and destination port for their DNS lookups. Occasionally the source port gets translated to one that ISC BIND servers have in a blocklist (chargen, echo, time, and a few others) and the query is ignored. As I recall, this behavior is hard coded so patching and recompiling BIND is required to work around it. I forget what the older ASA behavior was. It may have been to leave the source port unchanged through the NAT process (I think this is what you mean by "not translated"). In that case the client doesn't implement source port randomization and the NAT doesn't "upgrade" the connection to a random source port so I don't really see it as an issue. Ideally the client would implement source port randomization itself so it would be using source ports within its ephemeral port range for outgoing connections. --Blake On 6/4/2021 7:36 AM, Jean St-Laurent via NANOG wrote: I believe all devices will translate a privileged ports, but it won't translate to the same number on the other side. It will translate to an unprivileged port. Is it what you meant or really there are some devices that will not translate at all a privileged port? What are you trying to achieve? Jean -Original Message- From: NANOG On Behalf Of Fernando Gont Sent: June 4, 2021 3:00 AM To: nanog@nanog.org Subject: NAT devices not translating privileged ports Folks, While discussing port randomization (in the context of https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt ), it has been raised to us that some NAT devices do not translate the source port if the source port is a privileged port (<1024). Any clues/examples of this type of NATs? Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
All I'm going to say is at $5/foot for fiber, even if it's 864 count, you are royally overpaying for material! Josh Luthman 24/7 Help Desk: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Jun 4, 2021 at 3:42 AM Baldur Norddahl wrote: > > > On Fri, Jun 4, 2021 at 2:53 AM Masataka Ohta < > mo...@necom830.hpcl.titech.ac.jp> wrote: > >> Baldur Norddahl wrote: >> >> > Sorry but that claim is completely wrong. Cabling cost scales linearly >> with >> > the number of cores. >> > > My apology to Masataka Ohta for my too strong wording by calling you > wrong. The moderators put me in place. I wanted to say I disagree with the > claim. > > >> Most of cabling cost is cost to lay cables. Backhoe costs. >> Space factor of a fiber cable is negligible if you put a >> cable into utility tunnels which is wide, especially when >> tunnels were used for copper cables of POTS. >> > > It is true that trenching costs are higher than the cables themselves. But > that does not mean the cables are cheap and that it is an > insignificant cost. Cables + duct is about 20% of our cost to lay down the > network. Not having huts with active equipment spread all around is also a > huge cost saving that can not be ignored. > > > The cost of 144 is not >> > double that of 72. 288 is not double the cost of 144. >> >> Yup. When PON was first conceived several tens of years ago, core >> cost a lot. But, today... >> > > I should point out that I probably buy more cable than most. The exact > pricing is of course not public, but lets say a core cost somewhere between > 1 to 2 USD cents per meter. Then you simply multiply up to get an > approximate price of the cable. Holds true for cables with more than about > 12 cores. This is because with larger cables the cost of the cores dominate > the price of the cable. When you buy as much as we do, you do not really > get a huge rebate for buying more cores in a single cable - we already buy > insane amounts of core - it is just distributed in more cables. > > The moderator is right in that we do not seem to progress much here in > this discussion. So lets agree to disagree. But let me get this closing > comment in anyway... the guy that actually builds PON networks says he does > so, because it is significantly cheaper. We have no other motivations as > our network is not open to third parties in any case. Our motivation is to > stay profitable. > > Regards, > > Baldur > > >
Re: New minimum speed for US broadband connections
GPON is full duplex. Two different wavelengths for the two directions. 1490/1310. Wireless we'll say you're doing 20 MHz. That doesn't divide up. That's simply 20 MHz half duplex. With fixed timing (for colocation) it means that you simply can't shift your ratios. Josh Luthman 24/7 Help Desk: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Jun 4, 2021 at 8:50 AM Baldur Norddahl wrote: > > > On Fri, Jun 4, 2021 at 1:49 PM Mike Hammett wrote: > >> Assuming you were able to get the maximum capacity (you don't for a >> variety of reasons), the maximum capacity of a given access point is 1.2 >> gigabit/s. On a 2:1 ratio, that's about 800 megs down and 400 megs up. >> >> > Here is a graph of traffic from approx 200 GPON customers, with a mix of > 200/200 and 1000/1000 subscription types: > > https://oz9h.dk/graph.png > > Something tells me that would also work just fine with wireless operating > at link speed of 1,2 Gbps. You would of course not be able to do 1000 Mbps > upload with a link of 400 up, but you would be able to sell 200/200 no > problem. The limit would be downstream capacity, not upstream. > > Regards, > > Baldur > > >
Re: New minimum speed for US broadband connections
On Fri, Jun 4, 2021 at 1:49 PM Mike Hammett wrote: > Assuming you were able to get the maximum capacity (you don't for a > variety of reasons), the maximum capacity of a given access point is 1.2 > gigabit/s. On a 2:1 ratio, that's about 800 megs down and 400 megs up. > > Here is a graph of traffic from approx 200 GPON customers, with a mix of 200/200 and 1000/1000 subscription types: https://oz9h.dk/graph.png Something tells me that would also work just fine with wireless operating at link speed of 1,2 Gbps. You would of course not be able to do 1000 Mbps upload with a link of 400 up, but you would be able to sell 200/200 no problem. The limit would be downstream capacity, not upstream. Regards, Baldur
RE: NAT devices not translating privileged ports
I believe all devices will translate a privileged ports, but it won't translate to the same number on the other side. It will translate to an unprivileged port. Is it what you meant or really there are some devices that will not translate at all a privileged port? What are you trying to achieve? Jean -Original Message- From: NANOG On Behalf Of Fernando Gont Sent: June 4, 2021 3:00 AM To: nanog@nanog.org Subject: NAT devices not translating privileged ports Folks, While discussing port randomization (in the context of https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt ), it has been raised to us that some NAT devices do not translate the source port if the source port is a privileged port (<1024). Any clues/examples of this type of NATs? Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
NAT devices not translating privileged ports
Folks, While discussing port randomization (in the context of https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt ), it has been raised to us that some NAT devices do not translate the source port if the source port is a privileged port (<1024). Any clues/examples of this type of NATs? Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: DANE of SMTP Survey
Hello Mr. Tinka & Mr. Andrews , Please see below . On Thu, 3 Jun 2021, Mark Tinka wrote: On 6/3/21 00:25, babydr DBA James W. Laferriere wrote: The Below is to keep thread of thought accurate ... On Wed, 2 Jun 2021, Mark Tinka wrote: * Step 2 - take your time cluing up on getting your zone signed, and being part of the solution toward a more secure Internet. No pressure, at your pace. Again , Will this handle the case of self-signed only ? Not sure I understand your question, in both cases of recursion and authoritative. The Signing of the 'Zone' , Can the 'Zone' be signed by a self-signed key ? Or MUST I (and others) rely on a external certificate authority ? Mind you I notice in rfc6487 (note(s)) about self-signed certificates . So Maybe I am being a bit over worried about having to spend more money just to keep my 2 ip-ranges routing in light of the RPKI initative(s) . Which Mr. Andrews response below answers quite succinctly , On Thu, 3 Jun 2021, Mark Andrews wrote: DANE works with self generated CERTs. The TLSA record provides the cryptographic link back to the DNSSEC root. Thank You Mr. Andrews , Muchly . Is what I was hoping for . Thank You Both . JimL -- +-+ | James W. Laferriere| SystemTechniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | j...@system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +-+
Re: New minimum speed for US broadband connections
Assuming you were able to get the maximum capacity (you don't for a variety of reasons), the maximum capacity of a given access point is 1.2 gigabit/s. On a 2:1 ratio, that's about 800 megs down and 400 megs up. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Baldur Norddahl" To: "NANOG" Sent: Thursday, June 3, 2021 5:03:53 PM Subject: Re: New minimum speed for US broadband connections On Thu, Jun 3, 2021 at 11:46 PM Mike Hammett < na...@ics-il.net > wrote: 2.4 gigabit per channel, but only 1.2 gigabit from a given access point. Most often, WISPs choose down\up ratios between 85/15 and 66/34 and then sell plans appropriately. If we're now required to have a symmetric 100 megs, you'll be robbing even more of the downstream for the upstream. Why would you do that? So that you're relatively capable of providing what you're selling. The alternative is gross oversubscription. 66/34 is 2:1 or exactly the same as GPON (2.4 down, 1.2 up). We sell 1000 symmetrical on that GPON and the customers are happy. You would have much less oversubscription with 100/100 on a 1.2 Gbps wireless with 66:34 down/up ratio, than we are doing with GPON and 1000/1000. We are also doing 128 customers on a single OLT port. Remember that a single customer only adds a few Mbps peak to your bandwidth usage. Regards, Baldur
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
On Fri, Jun 4, 2021 at 2:53 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Baldur Norddahl wrote: > > > Sorry but that claim is completely wrong. Cabling cost scales linearly > with > > the number of cores. > My apology to Masataka Ohta for my too strong wording by calling you wrong. The moderators put me in place. I wanted to say I disagree with the claim. > Most of cabling cost is cost to lay cables. Backhoe costs. > Space factor of a fiber cable is negligible if you put a > cable into utility tunnels which is wide, especially when > tunnels were used for copper cables of POTS. > It is true that trenching costs are higher than the cables themselves. But that does not mean the cables are cheap and that it is an insignificant cost. Cables + duct is about 20% of our cost to lay down the network. Not having huts with active equipment spread all around is also a huge cost saving that can not be ignored. > The cost of 144 is not > > double that of 72. 288 is not double the cost of 144. > > Yup. When PON was first conceived several tens of years ago, core > cost a lot. But, today... > I should point out that I probably buy more cable than most. The exact pricing is of course not public, but lets say a core cost somewhere between 1 to 2 USD cents per meter. Then you simply multiply up to get an approximate price of the cable. Holds true for cables with more than about 12 cores. This is because with larger cables the cost of the cores dominate the price of the cable. When you buy as much as we do, you do not really get a huge rebate for buying more cores in a single cable - we already buy insane amounts of core - it is just distributed in more cables. The moderator is right in that we do not seem to progress much here in this discussion. So lets agree to disagree. But let me get this closing comment in anyway... the guy that actually builds PON networks says he does so, because it is significantly cheaper. We have no other motivations as our network is not open to third parties in any case. Our motivation is to stay profitable. Regards, Baldur
