- NANOG - lists.nanog.org

Re: Charter and Cox contacts
by daniel＠pyranah.com 15 May '19

15 May '19

First off, I apologize for the list. I didn't realize my replies included the entire original email... Mark, we do not run a mail server. The issue is a lot of our customers have their 2nd homes here, so when they come up they are using their email provided by their 1st home ISP. A number of our customers use Cox, Charter, and Spectrum and can receive email just fine but cannot send. Report from a mac book pro email client showed Cox to be blocking the IP that we NAT most customers through. Message: 7 Date: Tue, 14 May 2019 11:22:41 -0700 (PDT) From: Mark Milhollan <mlm(a)pixelgate.net> To: NANOG list <nanog(a)nanog.org> Subject: Re: Charter and Cox contacts Message-ID: <alpine.LNX.2.00.1905141115120.5030(a)arcghar.ybpny> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 13 May 2019, Stephen Satchell wrote: >On 5/13/19 12:11 PM, daniel(a)pyranah.com wrote: >>Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, >>our IP has been blocked by them and our customers are unable to send email >>via their charter/cox accounts. Thanks > >Would you be talking about port 25/tcp outbound? Lots of ISPs will >block port 25 as a rule; If this is the case, that your customers cannot use your mail servers to relay mail then provide port 587/TCP (SUBMISSION) or even 465/TCP (SMTPS, deprecated). If you mean that your mail servers can't send mail to Charter and Cox addresses, then indeed you need to find out what happened, fix it then request removal from their (and other) blacklists for which contacts there would be helpful (I am not one). /mark Daniel Temple VP of Operations Pyranah Communications, LLC 828-743-2470 ext.205 Pyranah.com Like us on Facebook!

1 0

Re: Cisco Crosswork Network Insights - or how to destroy a useful service
by Patrick McEvilly 15 May '19

15 May '19

https://honestnetworker.net/2019/01/31/recent-bgpmon-net-announcement/ From: NANOG <nanog-bounces+patrick_mcevilly=harvard.edu(a)nanog.org> on behalf of Mike Hammett <nanog(a)ics-il.net> Date: Wednesday, May 15, 2019 at 8:35 AM To: Hank Nussbacher <hank(a)efes.iucc.ac.il> Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> Subject: Re: Cisco Crosswork Network Insights - or how to destroy a useful service Resent-From: Patrick McEvilly <patrick_mcevilly(a)harvard.edu> Cisco ruins everything they touch. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Hank Nussbacher" <hank(a)efes.iucc.ac.il> To: nanog(a)nanog.org Sent: Wednesday, May 15, 2019 4:50:10 AM Subject: Cisco Crosswork Network Insights - or how to destroy a useful service I have started to use Cisco Crosswork Network Insights which is the replacement for BGPmon and I am shocked at how Cisco has managed to destroy a useful tool. I have had a paid 50 prefix account since the day BGPmon became available and helped two clients implement a 500 prefix license over the past 4 years. None will be buying Cisco Crosswork Network Insights, based on my recommendation. I really don’t know where to begin since there is so much to dislike in this new GUI. I will try to give you just a small taste but I suggest you request a 90 day trial license and try it out for yourself. This was not designed by someone who deals with BGP hijacks or who manages a network. It was probably given to some GUI developer with a minimal understanding of what the users needed. How do I know this? Take for example the main configuration menu: https://crosswork.cisco.com/#/configuration with the first tab of “prefixes”. On that page there is no mention of which ASN the prefix is associated with. That of course was fundamental in the BGPmon menu: https://portal.bgpmon.net/myprefixes.php Or take for example its “express configuration”, where you insert an ASN and it automatically finds all prefixes and creates a policy. But does it know the name of the ASN? Nope. Something again that was basic in BGPmon via: https://portal.bgpmon.net/myasn.php is non-existent in CNI. Or how about the alarms one gets to an email? Want to see how that looks? From: Crosswork Admin [mailto:admin@crosswork.cisco.com] Sent: 15 May 2019 11:39 To: Hank Nussbacher <Hank(a)mail.iucc.ac.il> Subject: CCNI Notification Active alarm count 1 starting at 2019-05-15 08:34:42.960762315 +0000 UTC. Please click on the link for each alarm below: https://crosswork.cisco.com/#/alarm/ba7c5084-f05d-4c12-a17f-be9e815d6647 Compare that with what we used to get: ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 99.201.0.0/16: Prefix Description: Kuku net Update time: 2018-08-12 17:50 (UTC) Detected by #peers: 140 Detected prefix: 99.201.131.0/24 Announced by: AS222246 (BGP hijacking Ltd) Upstream AS: AS111111 (Clueless ISP allowing customer hijacking Ltd) ASpath: 555555 444444 333333 111111 222246 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=830521190 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=830521190 That is just a small sampling. Maybe two years down the road, Cisco will speak to customers first before destroying a useful service. Anyone else trying this out and feels the same or feels differently? Disappointed, Hank

1 0

Charter and Cox contacts
by daniel＠pyranah.com 14 May '19

14 May '19

Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, our IP has been blocked by them and our customers are unable to send email via their charter/cox accounts. Thanks Daniel Temple VP of Operations Pyranah Communications, LLC 828-743-2470 ext.205 <http://www.pyranah.com/> Pyranah.com <https://www.facebook.com/cashiersvalleyelectronics/> Like us on Facebook!

3 2

IPv6 ingress filter
by Amos Rosenboim 14 May '19

14 May '19

Hello, As we are trying to tighten the security for IPv6 traffic in our network, I was looking for a reference IPv6 ingress filter. I came up with Job Snijders suggestion (thank you Job) that can be conveniently found at whois -h whois.ripe.net fltr-martian-v6 After applying the filter I noticed some traffic from 6to4 addresses (2002::/16) to our native IPv6 prefixes (residential users in this case). The traffic is a mix of both UDP and TCP but all on high port numbers on both destination and source. It seems to me like some P2P traffic, but I really can’t tell. This got me thinking, why should we filter these addresses at all ? I know 6to4 is mostly dead, but is it inherently bad ? And if so, why is the prefix (2002::/16) still being routed ? I would love to hear some thoughts on this, and understand if others are actually filtering this at both data plane and control plane. Thanks, Amos Rosenboim --

2 2

Re: Charter and Cox contacts
by daniel＠pyranah.com 14 May '19

14 May '19

"On 5/13/19 12:11 PM, daniel(a)pyranah.com wrote: > Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, > our IP has been blocked by them and our customers are unable to send email > via their charter/cox accounts. Thanks Would you be talking about port 25/tcp outbound? Lots of ISPs will block port 25 as a rule; you have to call to have it opened. At the same time, you can request the PTR record you need to keep big mail receivers happy." It's the outgoing smtp ports, 587 for charter and 465 for cox. They are open on my end but our IP address that most of our customers are natted through is blocked by the email servers. Daniel Temple VP of Operations Pyranah Communications, LLC 828-743-2470 ext.205 Pyranah.com Like us on Facebook! -----Original Message----- From: NANOG <nanog-bounces(a)nanog.org> On Behalf Of nanog-request(a)nanog.org Sent: Tuesday, May 14, 2019 8:00 AM To: nanog(a)nanog.org Subject: NANOG Digest, Vol 136, Issue 14 Send NANOG mailing list submissions to nanog(a)nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request(a)nanog.org You can reach the person managing the list at nanog-owner(a)nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 2. Re: Ownership of Routers on Both Ends of Transnational Links (Pengxiong Zhu) 3. Re: Issues with SIP packets between VZ Fios and NTT (Brielle Bruns) 4. Re: Ownership of Routers on Both Ends of Transnational Links (Christopher Morrow) 5. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 6. Re: Ownership of Routers on Both Ends of Transnational Links (Pengxiong Zhu) 7. Re: Issues with SIP packets between VZ Fios and NTT (Brielle Bruns) 8. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 9. Re: Ownership of Routers on Both Ends of Transnational Links (Christopher Morrow) 10. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 11. Re: Issues with SIP packets between VZ Fios and NTT (Jared Mauch) 12. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 13. Re: Issues with SIP packets between VZ Fios and NTT (Pete Rohrman) 14. Charter and Cox contacts (daniel(a)pyranah.com) 15. Mostly name and shame... (bzs(a)theworld.com) 16. Re: Ownership of Routers on Both Ends of Transnational Links (Randy Bush) 17. Re: Charter and Cox contacts (Stephen Satchell) 18. RE: FCC Hurricane Michael after-action report (frnkblk(a)iname.com) 19. Re: FCC Hurricane Michael after-action report (Mike Bolitho) 20. Re: Issues with SIP packets between VZ Fios and NTT (Saku Ytti) 21. Re: NTP for ASBRs? (Mark Tinka) 22. Re: NTP for ASBRs? (colin johnston) 23. Fwd: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open (Mark Tinka) 24. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) ---------------------------------------------------------------------- Message: 1 Date: Mon, 13 May 2019 11:21:12 -0400 From: Dovid Bender <dovid(a)telecurve.com> To: NANOG <nanog(a)nanog.org> Subject: Issues with SIP packets between VZ Fios and NTT Message-ID: <CAM3TTh2qpkWOD2DPy2GU-9hHkKUX8GVExfjYmmq0YEeCyubaKw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, Over the last 48 hours we have been getting a lot of alerts of customers phones losing registrations to us. All the complaints are coming from customers that are on VZ Fios in the NYC area. Anyone else see anything strange going on? TIA. Dovid

1 0

Issues with SIP packets between VZ Fios and NTT
by Dovid Bender 14 May '19

14 May '19

Hi, Over the last 48 hours we have been getting a lot of alerts of customers phones losing registrations to us. All the complaints are coming from customers that are on VZ Fios in the NYC area. Anyone else see anything strange going on? TIA. Dovid

5 10

Fwd: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open
by Mark Tinka 14 May '19

14 May '19

FYI. Mark. -------- Forwarded Message -------- Subject: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open Date: Mon, 13 May 2019 11:06:53 +0000 From: Portia Rabonda <portia.rabonda(a)safnog.net> To: afnog(a)afnog.org <afnog(a)afnog.org> Greetings All, It gives us great pleasure to announce that the SAFNOG-5 & iWeek 2019 event registration is now open! SAFNOG, in collaboration with iWeek, is proud to announce that this year’s event registration is free of charge. SAFNOG-5 and iWeek 2019 will be held between the 26th- 28th August, 2019, in Johannesburg, South Africa. SAFNOG-5 seats are limited to 120 people, to reserve your spot, register through our website: http://safnog.org/. Please take note to select “SAFNOG-5” as the main event of attendance to secure your free seat. Information about the event programme, the venue, travel information and other important updates will be made available on http://safnog.org/ in due time. We are officially 105 days from the big showdown in Jozi! We look forward to seeing you there! Regards, Portia Rabonda on Behalf of SAFNOG MC

1 0

Re: NTP for ASBRs?
by Scott Weeks 14 May '19

14 May '19

--- bryan(a)shout.net wrote: From: Bryan Holloway <bryan(a)shout.net> On 5/8/19 4:00 PM, Scott Weeks wrote: > --- job(a)ntt.net wrote: > From: Job Snijders <job(a)ntt.net> > > on this topic, i strongly recommend to operate all > devices in the Etc/UTC timezone, this makes > coordination with external entities much easier. > ---------------------------------------- > > > Yes, this! Holy crap I come upon a lot of networks > that don't do this and it's always painful. Now if only we could get rid of Daylight Saving Time ... ------------------------------------------ Luckily, Hawaii doesn't have that problem... https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#Haw… But, that's the thing. One time. No trying to figure out who does DST and who doesn't. >From the above: =========================================== Arizona has not observed DST since 1967 Calif - in 2018, voters ratified a legislative plan for year-round daylight saving time, subject to congressional approval. On March 6, 2018, the Florida Senate approved the "Sunshine Protection Act" which would put Florida on permanent Daylight Saving Time year round...Congress would need to amend the existing 1966 federal law to allow the change. Hawaii has never observed daylight saving time ============================================ etc... scott

9 12

USA to Mexico IXP Equipment Recommendations
by NJ 14 May '19

14 May '19

Advice and/or suggestions wanted. Any input greatly appreciated. *Scenario:* We have run fiber from the USA to Mexico and have an exchange point in place. Our fiber connections are dark and therefore we can use any configuration we want on as many pairs as we want. Currently we have decided to light two 100gig connections and they are piping across the border already. We have 200gig going to Los Angeles (Wilshire Adjacent) and are looking to the mexico interested community of network engineers to identify how our peering point in Tijuana can be made to best service the networks in the region (and abroad if they build in). Our IXP is good, but we want to update/upgrade and put in a future-compatible robust solution instead of what we have in there now. We are an open IXP and are wondering how you would prefer to peer and what your equipment recommendations are and why. We're not afraid to spend (some) money but we do want it to not be complete overkill however should last at least 5 to 10 years before any upgrade would be required. Also to note, we are running our own bandwidth over the pipes as well so we would like to keep them separated. *Norm* A.A.S. R.A. Lifetime Member *Archaeology, Astronautics and SETI Research Association* SETI Project Lifetime Contributor

1 0

Re: Ownership of Routers on Both Ends of Transnational Links
by Pengxiong Zhu 13 May '19

13 May '19

Thanks again for your insightful responses! The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. How about the case that the IP belongs to a Chinese ISP and is located in US(from RTT result), can we say it is very likely or definitely owned/operated by the Chinese ISP? Why would some ISP try to rent routers of Chinese ISP in US? For example, a traceroute from Ohio to an IP in China. Hop 17 and hop 18 should be located in US based on the RTT, and yet they belong to a Chinese AS(China Telecom). Does this mean that Chinese Telecom is managing these two hops? HOST: Loss% Snt Last Avg Best Wrst StDev 6. AS??? 100.65.11.97 0.0% 100 2.0 1.0 0.4 12.6 1.3 7. AS??? 52.93.15.238 0.0% 100 2.4 2.0 1.5 11.4 1.1 8. AS??? 52.93.14.134 0.0% 100 21.9 26.3 4.2 54.4 11.3 9. AS??? 52.93.14.119 0.0% 100 2.6 2.1 1.6 10.8 1.2 10. AS??? 100.91.27.86 0.0% 100 25.8 26.2 25.6 34.9 1.2 11. AS??? 54.239.42.197 0.0% 100 25.5 25.9 25.4 35.8 1.5 12. AS??? 100.91.4.218 0.0% 100 25.9 26.2 25.1 38.3 1.6 13. AS??? 100.91.4.217 0.0% 100 25.4 26.0 25.3 41.4 2.0 14. AS??? 100.91.5.85 0.0% 100 25.3 25.8 25.2 29.1 0.9 15. AS??? 54.239.103.86 0.0% 100 25.6 30.0 25.2 49.1 3.8 16. AS??? 54.239.103.77 0.0% 100 25.3 25.6 25.2 28.1 0.5 17. AS4134 218.30.53.1 0.0% 100 28.0 29.1 25.2 33.1 2.3 18. AS4134 202.97.50.21 0.0% 100 32.4 29.1 25.2 33.5 2.4 19. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 20. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 21. AS4134 202.97.94.121 0.0% 100 186.8 185.6 181.8 189.8 2.3 22. AS4816 119.147.222.6 0.0% 100 182.6 183.5 182.4 195.8 1.8 23. AS4816 183.2.182.130 0.0% 100 181.7 183.3 181.5 207.0 3.9 24. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 25. AS45102 116.251.113.158 0.0% 100 176.7 177.9 176.5 186.7 2.1 26. AS45102 116.251.115.141 0.0% 100 213.2 213.4 213.1 218.5 0.6 Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 7:37 PM Erik Sundberg <ESundberg(a)nitelusa.com> wrote: > May sure when you are dealing with transnational links to watch the > latency so you can tell when the link goes international. Just because you > are going from a US Network provider to China Telecom doesn't mean that > your not connecting to them in the united states. > > > > For example a traceroute from Denver to 27.29.128.1 which is an IP in > China Telecom's network. > > It's about 26ms between Denver and Los Angeles. Hop 5 to Hop 6 > > China Telecom connects to GTT in Los Angeles Hop7/8 > > On Hop 8 is in the United State and Hop 9 is across the pacific. Because > the latency goes from 31 ms to 183 ms. > > > Just something to keep in mind. > > > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. _gateway > 0.0% 14 1.0 1.2 1.0 2.8 0.5 > 2. te-0-0-26.ear2.den1.us.nitelusa.net > 0.0% 14 0.9 1.0 0.8 2.1 0.4 > 3. te-0-0-26.ear1.den1.us.nitelusa.net > 0.0% 14 1.1 1.6 1.1 2.9 0.7 > 4. te-0-0-1-0.cr1.den1.us.nitelusa.net > 0.0% 14 1.0 1.0 1.0 1.1 0.0 > 5. ae1-122.cr0-den2.ip4.gtt.net > 0.0% 14 0.5 1.2 0.3 6.9 2.0 > 6. et-0-0-47.cr3-lax2.ip4.gtt.net > 0.0% 14 26.5 26.4 26.2 26.7 0.2 > 7. as4134.lax20.ip4.gtt.net > 0.0% 14 27.7 28.7 26.8 30.1 1.1 > 8. 202.97.50.29 > 0.0% 14 31.4 30.6 26.8 34.1 2.4 > 9. 202.97.41.129 > 0.0% 14 183.3 187.1 183.3 190.8 2.4 > 10. 202.97.94.101 > 0.0% 14 187.9 188.6 186.1 211.2 6.8 > 11. 202.97.94.141 > 0.0% 13 177.8 180.7 177.2 184.2 2.3 > 12. 202.97.67.54 > 0.0% 13 199.5 201.2 197.4 205.1 2.6 > 13. 111.177.110.62 > 0.0% 13 205.9 206.3 205.9 208.2 0.7 > 14. 27.29.128.1 > 0.0% 13 202.6 202.8 202.5 203.9 0.4 > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg(a)nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* Zhiyun Qian <zhiyunq(a)cs.ucr.edu> > *Sent:* Tuesday, April 16, 2019 1:02:36 PM > *To:* Erik Sundberg > *Cc:* Pengxiong Zhu; Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Erik, > > Thanks a lot for the information! This is extremely helpful. We are > conducting an analysis on performance/policy-related study on transnational > links. We are hoping to submit a paper soon. Will be glad to share all the > details once we have a draft! > > Best, > -Zhiyun > > > On Tue, Apr 16, 2019 at 10:35 AM Erik Sundberg <ESundberg(a)nitelusa.com> > wrote: > > CPE is usually ran by the customer. Some provider do offer managed routers > for a fee. Kinda like renting a cable modem from your provider. > > > What are your guys trying to accomplish or find out? > > Erik > > > > Erik Sundberg > Sr. Network Engineer > Nitel > 350 N Orleans Street > Suite 1300N > Chicago, Il 60654 > Desk: 773-661-5532 > Cell: 708-710-7419 > NOC: 866-892-0915 > Email: esundberg(a)nitelusa.com > web: www.nitelusa.com > > ------------------------------ > *From:* Pengxiong Zhu <pzhu011(a)ucr.edu> > *Sent:* Tuesday, April 16, 2019 12:32 PM > *To:* Erik Sundberg > *Cc:* Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Thanks a lot! > > Are the Customer Devices managed by Telia or the customer? > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Tue, Apr 16, 2019 at 7:43 AM Erik Sundberg <ESundberg(a)nitelusa.com> > wrote: > > I hope this helps with the breakdown for telia. > > > > > Telia i think is using /31's for there serial blocks now > > 62.115.170.56 (Telia Edge Rotuer) > > 62.115.170.57 (Customer Device) > > > > chinaunicom-ic-341501-sjo-b21.c.telia.net. > > > <Customername>-<CircuitID>-<POP>-<router>.c.telia.net > > > > Customer: ChinaUnicom > > Telia Circuit ID's are: ic-123456 > > POP: SJO (Airport code) > > Router: b21 > > Doamin: c.telia.net "Customer.telia.net" > > > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg(a)nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* NANOG <nanog-bounces(a)nanog.org> on behalf of Pengxiong Zhu < > pzhu011(a)ucr.edu> > *Sent:* Monday, April 15, 2019 11:36:45 PM > *To:* nanog(a)nanog.org > *Cc:* Keyu Man; Zhiyun Qian; Zhongjie Wang > *Subject:* Ownership of Routers on Both Ends of Transnational Links > > Howdy folks, > > We are a group of researchers at UC Riverside conducting some measurement > about transnational networks. In particular, we are interested in studying > the ownership of routers on the two sides of transnational links. > > We have some concrete questions which we hope someone can shed some light > on. Basically when we send packets from US/Canada to China, through > traceroute and the RTT of each hop, we can locate the last hop in the US > before the packets enter China (*there is a large jump of RTT of 100+ms > from this hop onwards*). Oftentimes the ownership of such routers is > ambiguous. > > These hops whose IPs seem to belong to US or European ISPs (*according to > BGP info*) but their reverse DNS names have *chinaunicom* in it, which is > a Chinese ISP. > AS1299 Telia Company AB > 62.115.170.57 name = chinaunicom-ic-341501-sjo-b21.c.telia.net. > 62.115.33.230 name = chinaunicom-ic-302366-las-bb1.c.telia.net. > 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. > > AS701 Verizon Business > 152.179.103.254 name = chinaunicom-gw.customer.alter.net. > > While the following routers, they don't have a reverse DNS name at all, > which seem to be uncommon if they were managed by US or European ISPs but > quite common for Chinese ISPs. > AS6453 TATA COMMUNICATIONS (AMERICA) INC > 63.243.205.90 > 66.110.59.118 > > Can anyone confirm that these are indeed managed by the Chinese ISPs (even > though they are physically located in the US according to the traceroute > and RTT analysis)? > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. >

3 4