Re: Vendors spamming NANOG attendees
the discussion about the external spam kinda exceeds the volume of the spam itself. just my 2 cents. just block, delete, continue life Kind regards, Alexander Maassen - Technical Maintenance Engineer Parkstad Support BV- Maintainer DroneBL- Peplink Certified Engineer Oorspronkelijk bericht Van: b...@theworld.com Datum: 15-06-17 20:09 (GMT+01:00) Aan: Dan Hollis Cc: Niels Bakker , nanog@nanog.org, b...@theworld.com Onderwerp: Re: Vendors spamming NANOG attendees On June 14, 2017 at 14:22 goe...@sasami.anime.net (Dan Hollis) wrote: > On Wed, 14 Jun 2017, b...@theworld.com wrote: > > Merely deciding not to patronize them may not be sufficient and that's > > why we make that sort of thing just outright illegal rather than hope > > market forces will suffice. > > Most spam is sent from compromised machines anyway, so there are already > criminal violations involved in sending spam. FWIW I believe the context was a vendor spamming NANOG attendees (see the Subject:) so not likely being done from compromised machines. That said, yes, a lot of spam is sent from compromised machines as you say. But criminal violations can be additive, even rising to things like RICO charges (a pattern of organized criminal behavior etc.) which can be both criminal and civil and added onto charges like the criminality of specific mechanisms (compromised systems etc.) It really depends on how interested one can get the legal machinery in the problem. Thus far that's hit or miss. I can't find any instance where RICO charges were used against a spam gang tho, at least on a quick search. -- -Barry Shein Software Tool & Die | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 17 Jun, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 651216 Prefixes after maximum aggregation (per Origin AS): 253596 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 313678 Total ASes present in the Internet Routing Table: 57522 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49794 Origin ASes announcing only one prefix: 21982 Transit ASes present in the Internet Routing Table:7728 Transit-only ASes present in the Internet Routing Table:221 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 42 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table:50 Numnber of instances of unregistered ASNs: 54 Number of 32-bit ASNs allocated by the RIRs: 19084 Number of 32-bit ASNs visible in the Routing Table: 14816 Prefixes from 32-bit ASNs in the Routing Table: 60261 Number of bogon 32-bit ASNs visible in the Routing Table:65 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:395 Number of addresses announced to Internet: 2848765156 Equivalent to 169 /8s, 204 /16s and 180 /24s Percentage of available address space announced: 76.9 Percentage of allocated address space announced: 76.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 216985 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 178613 Total APNIC prefixes after maximum aggregation: 51337 APNIC Deaggregation factor:3.48 Prefixes being announced from the APNIC address blocks: 177820 Unique aggregates announced from the APNIC address blocks:73451 APNIC Region origin ASes present in the Internet Routing Table:8177 APNIC Prefixes per ASN: 21.75 APNIC Region origin ASes announcing only one prefix: 2284 APNIC Region transit ASes present in the Internet Routing Table: 1158 Average APNIC Region AS path length visible:4.4 Max APNIC Region AS path length visible: 42 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3010 Number of APNIC addresses announced to Internet: 763804388 Equivalent to 45 /8s, 134 /16s and 186 /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-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:198323 Total ARIN prefixes after maximum aggregation:94647 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 200232 Unique aggregates announced from the ARIN address blocks: 92051 ARIN Region origin ASes present in the Internet Routing Table:17902 ARIN Prefixes per ASN:11.18 ARIN Region
Google Cloud and IX - Traffic behavior
Hi, Anyone aware of different traffic behavior depending if the target goes through normal peering than through an exchanges google exists in? We're facing a weird issue where the same GCLD Instance can upload up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot get more than 20Mbps on similar hosts (8 of them) sittings on our peering links. PS; Those sames hosts get up to their link limit ( 1Gbps ) between each others and others test points we have; PS: Wireshark capture show nothing abnormal; PS: Links aren't congested, and so on... Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test point with a TorIX access -- - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443
Re: Google Cloud and IX - Traffic behavior
Alain, When you refer to "normal peering" do you mean Internet transit? Or are these PNI's with Google? Do the GCLD instance you reach through "normal peering" have higher latency than through TorIX? -- Stephen On 2017-06-16 6:58 PM, Alain Hebert wrote: Hi, Anyone aware of different traffic behavior depending if the target goes through normal peering than through an exchanges google exists in? We're facing a weird issue where the same GCLD Instance can upload up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot get more than 20Mbps on similar hosts (8 of them) sittings on our peering links. PS; Those sames hosts get up to their link limit ( 1Gbps ) between each others and others test points we have; PS: Wireshark capture show nothing abnormal; PS: Links aren't congested, and so on... Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test point with a TorIX access
Re: Google Cloud and IX - Traffic behavior
i also see now that you are a guru rinpoche as wlell but with valerie home any minute i must stop will come back though > On Jun 16, 2017, at 7:42 PM, Stephen Fulton wrote: > > Alain, > > When you refer to "normal peering" do you mean Internet transit? Or are > these PNI's with Google? Do the GCLD instance you reach through "normal > peering" have higher latency than through TorIX? > > -- Stephen > > On 2017-06-16 6:58 PM, Alain Hebert wrote: >> Hi, >> Anyone aware of different traffic behavior depending if the target goes >> through normal peering than through an exchanges google exists in? >> We're facing a weird issue where the same GCLD Instance can upload up to >> 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot >> get more than 20Mbps on similar hosts (8 of them) sittings on our peering >> links. >> PS; Those sames hosts get up to their link limit ( 1Gbps ) between each >> others and others test points we have; >> PS: Wireshark capture show nothing abnormal; >> PS: Links aren't congested, and so on... >> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps. Its my only test >> point with a TorIX access >
