google imap timeouts / slowness from Toronto Canada ?

[mike tancsa]

Anyone else seeing google imap timeouts / slowness ?  We hit their 
services in Toronto Canada for ipv6 and ipv4 via gtt (However, ipv4 
seems to come back via Torix). I am not seeing packet loss, just a lot 
of slowness in response at the app layer. google status says all ok.  
Problems started around 3:30am EST. My traffic comes out of AS11647.  
tcp acks come back super quick. Just random delays in the Push of the 
app response. example pcap below of "slow" and one "normal"



traceroute6 to imap.gmail.com (2607:f8b0:4004:c1b::6d) from 
*2607:f3e0::12*, 64 hops max, 16 byte packets

 1  host6  0.169 ms
 2  toronto-torix-6  7.452 ms
 3  *
 4  google-b.ip6.torontointernetxchange.net  5.442 ms
 5  2001:4860:0:1::322f  5.456 ms
 6  2001:4860:0:1::3244  6.075 ms
 7  2001:4860::c:4002:fc1a  27.485 ms
 8  2001:4860::c:4002:6523  26.352 ms
 9  2001:4860::c:4002:332e  26.528 ms
10  2001:4860::c:4002:a29a  27.551 ms
11  2001:4860::cc:4001:efe0  55.962 ms
12  2001:4860:0:1::e63  26.644 ms
13  *
14  *
15  *

src ip 64.7.153.12

 2  gtt-core1-10G (67.43.129.247)  5.225 ms
 3  ae4-68.cr5-tor1.ip4.gtt.net (69.174.3.205)  7.868 ms
 4  ae2.cr2-tor1.ip4.gtt.net (141.136.105.230)  10.595 ms
 5  74.125.147.196 (74.125.147.196)  8.620 ms
 6  192.178.98.45 (192.178.98.45)  8.997 ms
 7  192.178.98.54 (192.178.98.54)  8.943 ms
 8  142.251.231.171 (142.251.231.171)  18.056 ms
 9  142.251.68.58 (142.251.68.58)  21.095 ms
10  142.251.69.191 (142.251.69.191)  27.531 ms
11  142.251.226.101 (142.251.226.101)  27.294 ms
12  216.239.57.97 (216.239.57.97)  27.101 ms
13  142.251.245.105 (142.251.245.105)  27.056 ms
14  *
15  *


slow

12:27:25.602118 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [S], seq 3558477261, win 65535, options [mss 1440,nop,wscale 
6,sackOK,TS val 366746043 ecr 0], length 0
12:27:25.629789 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [S.], seq 3828362457, ack 3558477262, win 65535, options [mss 
1440,sackOK,TS val 998507935 ecr 366746043,nop,wscale 8], length 0
12:27:25.629824 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [.], ack 1, win 1026, options [nop,nop,TS val 366746071 ecr 
998507935], length 0
12:27:25.630041 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [P.], seq 1:206, ack 1, win 1026, options [nop,nop,TS val 
366746071 ecr 998507935], length 205
12:27:25.657752 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [.], ack 206, win 261, options [nop,nop,TS val 998507963 ecr 
366746071], length 0
12:27:25.659493 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [.], seq 1:1209, ack 206, win 261, options [nop,nop,TS val 
998507965 ecr 366746071], length 1208
12:27:25.659504 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [P.], seq 1209:2417, ack 206, win 261, options [nop,nop,TS val 
998507965 ecr 366746071], length 1208
12:27:25.659518 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [.], ack 2417, win 988, options [nop,nop,TS val 366746100 ecr 
998507965], length 0
12:27:25.659617 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [.], seq 2417:3625, ack 206, win 261, options [nop,nop,TS val 
998507965 ecr 366746071], length 1208
12:27:25.659627 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [P.], seq 3625:4227, ack 206, win 261, options [nop,nop,TS val 
998507965 ecr 366746071], length 602
12:27:25.659641 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [.], ack 4227, win 1016, options [nop,nop,TS val 366746100 ecr 
998507965], length 0
12:27:25.669774 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [P.], seq 206:332, ack 4227, win 1026, options [nop,nop,TS val 
366746110 ecr 998507965], length 126
12:27:25.697747 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [P.], seq 4227:4517, ack 332, win 261, options [nop,nop,TS val 
998508003 ecr 366746110], length 290
12:27:25.705534 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [P.], seq 4517:4613, ack 332, win 261, options [nop,nop,TS val 
998508011 ecr 366746110], length 96
12:27:25.705550 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [.], ack 4613, win 1024, options [nop,nop,TS val 366746146 ecr 
998508003], length 0
12:27:25.705945 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [P.], seq 332:408, ack 4613, win 1026, options [nop,nop,TS val 
366746146 ecr 998508003], length 76
12:27:25.738466 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [.], ack 408, win 261, options [nop,nop,TS val 998508044 ecr 
366746146], length 0
12:27:57.854752 IP6 2607:f8b0:4004:c19::6c.993 > 2607:f3e0::12.56498: 
Flags [P.], seq 4613:4911, ack 408, win 261, options [nop,nop,TS val 
998540161 ecr 366746146], length 298
12:27:57.855295 IP6 2607:f3e0::12.56498 > 2607:f8b0:4004:c19::6c.993: 
Flags [P.], seq 408:453, ack 4911, win 1026, options [nop,nop,TS val 
366778296 ecr 998540161], length 45
12:27:57.882290 IP6 2607:f8b0:4004:c19::6c.993 > 

Re: Help with broken routing in MTL (AS577 174 11647) Bell, Cogent, Me

[mike tancsa]

Looks to be fixed as of ~ 14:55 Eastern.

    ---Mike

On 6/24/2022 1:49 PM, mike tancsa wrote:
We noticed random traffic originating from AS577 stopped getting to 
our ASN via Cogent in Montreal at around 00:24 this morning. Based on 
the pattern I am guessing a broken next hop on one leg of a larger 
link ?  e.g. IP traffic leaving AS577 towards IP addresses in one of 
my /19s will 100% work for certain IPs and 100% fail for others all 
within that same /19.


e.g. from 142.112.93.72 (an IP originating in AS577) to one of the IPs 
below in my 64.7.128.0/19


64.7.134.1 100% fail
64.7.134.2 100% pass
64.7.134.3 fail
64.7.134.4 fail
64.7.134.5 fail
64.7.134.6 fail
64.7.134.7 100% pass
64.7.134.8 100% fail
64.7.134.9 fail
64.7.134.10 pass

Its just packets towards my ASN that are failing. Packets TO  577 via 
174 all work fine.


Traceroutes good and bad all look like this

% traceroute -s 142.112.93.72 -q1 -I 64.7.134.2
traceroute to 64.7.134.2 (64.7.134.2) from 142.112.93.72, 64 hops max, 
48 byte packets

 1  lns5-ottawa23_lo0.net.bell.ca (64.230.11.188)  10.507 ms
 2  64.230.98.68 (64.230.98.68)  17.539 ms
 3  tcore4-montreal02_1-9-0-0.net.bell.ca (64.230.79.127) 18.150 ms
 4  cr02-mtrlpq02ho6_bundle-ether1.net.bell.ca (142.124.127.251) 
13.787 ms

 5  bx1-montrealgz_et-0-0-5.net.bell.ca (64.230.26.135)  12.237 ms
* 6  **
 7  be2089.ccr21.ymq01.atlas.cogentco.com (154.54.45.113) 13.337 ms
 8  be3259.ccr31.yyz02.atlas.cogentco.com (154.54.41.205) 17.969 ms
 9  sentex.demarc.cogentco.com (38.104.158.78)  17.126 ms
10  agas-core1-em0.sentex.ca (67.43.129.251)  39.960 ms
11  agas-lns1c-c.sentex.ca (64.7.129.19)  32.171 ms
12  orbiting.anysphere.com (64.7.134.2)  49.336 ms

% traceroute -s 142.112.93.72 -q1 -I 64.7.134.1
traceroute to 64.7.134.1 (64.7.134.1) from 142.112.93.72, 64 hops max, 
48 byte packets

 1  lns5-ottawa23_lo0.net.bell.ca (64.230.11.188)  10.229 ms
 2  64.230.98.66 (64.230.98.66)  13.346 ms
 3  tcore3-montreal02_hu2-4-0-2.net.bell.ca (64.230.78.252) 12.660 ms
 4  cr01-mtrlpq02ho5_bundle-ether1.net.bell.ca (142.124.127.233) 
12.423 ms

 5  bx1-montrealgz_et-0-0-1.net.bell.ca (64.230.26.133)  12.225 ms
*6  **
 7  *
 8  *
 9  *
10  *
11  *

Not sure if hop 6 is a Bell device or Cogent device. I have a ticket 
open with Cogent, but they dont see any issues in their network. I am 
not a direct customer of Bell, so I cant open a ticket with them. Was 
hoping someone from AS577 would see this and take a look.


    ---Mike

Help with broken routing in MTL (AS577 174 11647) Bell, Cogent, Me

[mike tancsa]

We noticed random traffic originating from AS577 stopped getting to our 
ASN via Cogent in Montreal at around 00:24 this morning. Based on the 
pattern I am guessing a broken next hop on one leg of a larger link ?  
e.g. IP traffic leaving AS577 towards IP addresses in one of my /19s 
will 100% work for certain IPs and 100% fail for others all within that 
same /19.


e.g. from 142.112.93.72 (an IP originating in AS577) to one of the IPs 
below in my 64.7.128.0/19


64.7.134.1 100% fail
64.7.134.2 100% pass
64.7.134.3 fail
64.7.134.4 fail
64.7.134.5 fail
64.7.134.6 fail
64.7.134.7 100% pass
64.7.134.8 100% fail
64.7.134.9 fail
64.7.134.10 pass

Its just packets towards my ASN that are failing. Packets TO  577 via 
174 all work fine.


Traceroutes good and bad all look like this

% traceroute -s 142.112.93.72 -q1 -I 64.7.134.2
traceroute to 64.7.134.2 (64.7.134.2) from 142.112.93.72, 64 hops max, 
48 byte packets

 1  lns5-ottawa23_lo0.net.bell.ca (64.230.11.188)  10.507 ms
 2  64.230.98.68 (64.230.98.68)  17.539 ms
 3  tcore4-montreal02_1-9-0-0.net.bell.ca (64.230.79.127) 18.150 ms
 4  cr02-mtrlpq02ho6_bundle-ether1.net.bell.ca (142.124.127.251)  13.787 ms
 5  bx1-montrealgz_et-0-0-5.net.bell.ca (64.230.26.135)  12.237 ms
* 6  **
 7  be2089.ccr21.ymq01.atlas.cogentco.com (154.54.45.113) 13.337 ms
 8  be3259.ccr31.yyz02.atlas.cogentco.com (154.54.41.205) 17.969 ms
 9  sentex.demarc.cogentco.com (38.104.158.78)  17.126 ms
10  agas-core1-em0.sentex.ca (67.43.129.251)  39.960 ms
11  agas-lns1c-c.sentex.ca (64.7.129.19)  32.171 ms
12  orbiting.anysphere.com (64.7.134.2)  49.336 ms

% traceroute -s 142.112.93.72 -q1 -I 64.7.134.1
traceroute to 64.7.134.1 (64.7.134.1) from 142.112.93.72, 64 hops max, 
48 byte packets

 1  lns5-ottawa23_lo0.net.bell.ca (64.230.11.188)  10.229 ms
 2  64.230.98.66 (64.230.98.66)  13.346 ms
 3  tcore3-montreal02_hu2-4-0-2.net.bell.ca (64.230.78.252)  12.660 ms
 4  cr01-mtrlpq02ho5_bundle-ether1.net.bell.ca (142.124.127.233) 12.423 ms
 5  bx1-montrealgz_et-0-0-1.net.bell.ca (64.230.26.133)  12.225 ms
*6  **
 7  *
 8  *
 9  *
10  *
11  *

Not sure if hop 6 is a Bell device or Cogent device. I have a ticket 
open with Cogent, but they dont see any issues in their network. I am 
not a direct customer of Bell, so I cant open a ticket with them. Was 
hoping someone from AS577 would see this and take a look.


    ---Mike

Re: facebook outage (resolving)

[mike tancsa]

Getting the odd message through, but DNS looks good via their Toronto,
Canada pop


% traceroute -q1 -I a.dns.facebook.com
traceroute to star.c10r.facebook.com (31.13.80.8), 64 hops max, 48 byte
packets
 1  torix-core1-10G (67.43.129.248)  0.140 ms
 2  facebook-a.ip4.torontointernetxchange.net (206.108.35.2)  0.880 ms
 3  po103.psw02.yyz1.tfbnw.net (74.119.78.131)  0.365 ms
 4  173.252.67.57 (173.252.67.57)  0.341 ms
 5  edge-star-shv-01-yyz1.facebook.com (31.13.80.8)  0.263 ms
% traceroute6 -q1 -I a.dns.facebook.com
traceroute6 to star.c10r.facebook.com (2a03:2880:f00e:a:face:b00c:0:2)
from 2607:f3e0:0:80::290, 64 hops max, 20 byte packets
 1  toronto-torix-6  0.133 ms
 2  facebook-a.ip6.torontointernetxchange.net  0.532 ms
 3  po103.psw01.yyz1.tfbnw.net  0.322 ms
 4  po1.msw1ah.01.yyz1.tfbnw.net  0.335 ms
 5  edge-star6-shv-01-yyz1.facebook.com  0.267 ms
% traceroute6 -q1 -I d.dns.facebook.com
traceroute6 to star.c10r.facebook.com (2a03:2880:f00e:a:face:b00c:0:2)
from 2607:f3e0:0:80::290, 64 hops max, 20 byte packets
 1  toronto-torix-6  0.126 ms
 2  facebook-a.ip6.torontointernetxchange.net  0.673 ms
 3  po103.psw01.yyz1.tfbnw.net  0.349 ms
 4  po1.msw1ah.01.yyz1.tfbnw.net  0.332 ms
 5  edge-star6-shv-01-yyz1.facebook.com  0.264 ms
% traceroute -q1 -I d.dns.facebook.com
traceroute to star.c10r.facebook.com (31.13.80.8), 64 hops max, 48 byte
packets
 1  torix-core1-10G (67.43.129.248)  0.139 ms
 2  facebook-a.ip4.torontointernetxchange.net (206.108.35.2)  41.394 ms
 3  po103.psw02.yyz1.tfbnw.net (74.119.78.131)  0.285 ms
 4  173.252.67.57 (173.252.67.57)  0.309 ms
 5  edge-star-shv-01-yyz1.facebook.com (31.13.80.8)  0.211 ms
%

% host www.facebook.com a.ns.facebook.com
Using domain server:
Name: a.ns.facebook.com
Address: 2a03:2880:f0fc:c:face:b00c:0:35#53
Aliases:

www.facebook.com is an alias for star-mini.c10r.facebook.com.
% host -4 www.facebook.com a.ns.facebook.com
Using domain server:
Name: a.ns.facebook.com
Address: 129.134.30.12#53
Aliases:

www.facebook.com is an alias for star-mini.c10r.facebook.com.
%

On 10/4/2021 5:41 PM, Baldur Norddahl wrote:
>
>
> man. 4. okt. 2021 23.33 skrev Bill Woodcock  >:
>
>
>
> > On Oct 4, 2021, at 11:21 PM, Bill Woodcock  > wrote:
> >
> >
> >
> >> On Oct 4, 2021, at 11:10 PM, Bill Woodcock  > wrote:
> >>
> >> They’re starting to pick themselves back up off the floor in
> the last two or three minutes.  A few answers getting out.  I
> imagine it’ll take a while before things stabilize, though.
> >
> > nd we’re back:
> >
> > WoodyNet-2:.ssh woody$ dig www.facebook.com
>  @9.9.9.9 
>
> So that was, what…  15:50 UTC to 21:05 UTC, more or less…  five
> hours and fifteen minutes.
>
> That’s a lot of hair burnt all the way to the scalp, and some
> third-degree burns beyond that.
>
> Maybe they’ll get one or two independent secondary authoritatives,
> so this doesn’t happen again.  :-)
>
>
>
> We have had dns back for a while here but the site is still down. Not
> counting this as over yet.
>
>
>

Global statistics during the experiment (was Re: BGP Experiment)

[Mike Tancsa]

On 1/23/2019 8:27 PM, Töma Gavrichenkov wrote:
>
>> Replying to throw in my support behind continuing the experiment as well.
> +1. I've yet to see any disruptions caused by the experiment in my area.
>
Speaking of which, were there any statistics gathered and published
before, during and after the experiment about the size of the global
routing table and how many ASNs were impacted ?

    ---Mike



-- 
-------
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   

Re: cogent last night

[Mike Tancsa]

On 2/26/2018 12:21 PM, Aaron Gould wrote:
> No, I Wasn't the only one.  2 other neighboring South Texas ISP's just told
> me they had same packet loss/high latency issues on their cogent connection
> during same time frame.
> 
> Anyone know why this occurred and how far reaching it was ?
Interesting, I pick up Cogent in Toronto and saw some sort of issue
between them and sites I pick up out of AS577 (via in Cogent in
Chicago). BGP paths seemed to be there, but traffic dropped to almost
nothing for about 10min. By the time I got online to look, the issue had
resolved.  This was at about 02:05 Eastern to ~ 02:20.  Were they
perhaps doing some big upgrades ?

---Mike

-- 
-------
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada

Re: AS PATH limits

[Mike Tancsa]

197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
> 262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 26
>   >2197 262197 262197 262197 262197 262197 262197 262197 262197 ?
>   >>   >
>   >>   >/kc
>   >>   >--
>   >>   >Ken Chase - m...@sizone.org Guelph Canada
>   >> 
> 
> 


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: PCIe adapters supporting long distance 10GB fiber?

[Mike Tancsa]

On 6/15/2017 5:10 AM, chiel wrote:
> the server without it going first into a router/switch from vendor x. It
> seems to me that all the 10GB PCIe cards only support either copper
> 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very
> few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I
> can't seem to find any.

The chelsio 10G (T420 and T520) cards seem to support a wide variety. I
only have a couple of LR SFPs. Not sure about longer distances but they
seem to support every SFP I have tried in them. They are relatively
inexpensive. Perhaps give it a try and see

---Mike


-- 
-------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: Oh dear, we've all been made redundant...

[Mike Tancsa]

On 3/19/2016 7:16 PM, Warren Kumari wrote:
> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
> 
> Fixes all issues, less downtime, less stress...
> setup, every 24 hours and after a power failure. Do you have a modem/router
> combo? No problem! NetReset will also power cycle the modem/router combo.
> 
> 
> Automatically resets user's Internet every 24 hours


Excellent!  With any luck, it would be at the exact same time for all
users.  I was just thinking the other day, "You know, my RADIUS servers
just dont get enough spike load..."

    ---Mike



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO

[Mike Tancsa]

On 9/18/2014 4:42 PM, Brock Massel wrote:

Hi folks,
I'm hoping someone can shed some light on the situation.

The 192.250.24 addresses have been reachable for several months in the current 
configuration with no reported issues. Since the 16th we have been hearing 
reports that destinations in that block are unavailable for some.

Several looking glass' report network not in table.


Which ones ? I see you via just Rogers (AS812). Do you have transit with 
anyone else ?


TATA (AS6453) does not seem to know about you for some reason.  They 
peer directly with Rogers. Perhaps the RADB entries are not there for 
you ?  I think they create their filters based on that.



% whois -h whois.ra.net 192.250.24.0
route:  192.250.24.0/24
descr:  PNAP-ACS inflow route
origin: AS19294
mnt-by: MAINT-SGNS
changed:corey.dr...@sungard.com 20070201
source: RADB

route:  192.250.24.0/23
descr:  Encompass Europe
origin: AS702
member-of:  RS-UUNETNL
remarks:---
remarks:E-mail is the preferred contact method!
remarks:---
remarks:Please use one of the following addresses:
remarks:ab...@nl.uu.net   - for abuse notification
remarks:supp...@nl.uu.net - for technical questions
remarks:i...@nl.uu.net- for anything else
remarks:---
notify: ripe-guard...@nl.uu.net
mnt-by: AS1890-MNT
mnt-by: UUNET-MNT
changed:mar...@eu.uu.net 20011030
source: RIPE
remarks:
remarks:* THIS OBJECT IS NOT VALID
remarks:* Please note that all personal data has been removed 
from this object.
remarks:* To view the original object, please query the RIPE 
Database at:

remarks:* http://www.ripe.net/whois
remarks:

route:192.250.24.0/24
descr:Descartes-Inflow-ATL
origin:   AS19294
mnt-by:   ASN-INFLOW-NET
changed:  rdar...@inflow.com 20040330
source:   SAVVIS



--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: Facebook down?

[Mike Tancsa]

Back up now (from Toronto) with the following IPs 
(69.171.237.20,2a03:2880:10:cf07:face:b00c:0:1)


Was down when I first checked.

% telnet www.facebook.com 443
Trying 69.171.237.20...
telnet: connect to address 69.171.237.20: Connection refused
Trying 2a03:2880:10:cf07:face:b00c:0:1...
telnet: connect to address 2a03:2880:10:cf07:face:b00c:0:1: Connection 
refused

telnet: Unable to connect to remote host
%

% telnet www.facebook.com 443
Trying 69.171.237.20...
Connected to star.c10r.facebook.com.
Escape character is '^]'.
^]
telnet cl
Connection closed.
% telnet -6  www.facebook.com 443
Trying 2a03:2880:10:cf07:face:b00c:0:1...
Connected to star.c10r.facebook.com.
Escape character is '^]'.
^]
telnet cl
Connection closed.
%


On 9/3/2014 3:46 PM, aUser wrote:

Appears to be in Oregon, Southern Oregon.  Mobile too.

Sent from my iPhone 5S.


On Sep 3, 2014, at 12:45 PM, Marshall Eubanks marshall.euba...@gmail.com 
wrote:

This message has no content.






--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Anyone from AS7160 (Oracle) around ?

[Mike Tancsa]

Hi,
I have been trying to get a hold of someone who looks after ASN 
7160 since last Thursday both directly (OrgTechEmail), and indirectly 
via upstreams with no luck.  I am trying to resolve or at least 
understand a routing reachability issue between our two networks. It 
seems packets from ASN7160 are not able to get back to some of my 
netblocks in AS 11647.

e.g.

eg. this is fine
% traceroute -q1 -s 98.159.240.105 -Picmp 68.233.77.173
traceroute to 68.233.77.173 (68.233.77.173) from 98.159.240.105, 64 hops 
max, 72 byte packets

 1  cogent-vl38-tor-hespler-v38 (205.211.165.117)  0.091 ms
 2  gi1-18.mag02.yyz02.atlas.cogentco.com (38.104.158.77)  0.701 ms
 3  te0-7-0-12.ccr22.yyz02.atlas.cogentco.com (154.54.40.165)  0.765 ms
 4  be2080.ccr42.ord01.atlas.cogentco.com (154.54.42.5)  15.871 ms
 5  be2003.ccr21.ord03.atlas.cogentco.com (154.54.29.22)  17.882 ms
 6  38.104.102.102 (38.104.102.102)  17.395 ms
 7  border2.te7-1-bbnet1.chg004.pnap.net (64.94.32.19)  16.335 ms
 8  oraclebol-7.border2.chg004.pnap.net (74.217.8.106)  16.945 ms
 9  VIP-CH-77-173.taleo.net (68.233.77.173)  17.014 ms

This is not
% traceroute -q1 -s 205.211.165.119 -Picmp 68.233.77.173
traceroute to 68.233.77.173 (68.233.77.173) from 205.211.165.119, 64 
hops max, 72 byte packets

 1  cogent-vl38-tor-hespler-v38 (205.211.165.117)  0.145 ms
 2  gi1-18.mag02.yyz02.atlas.cogentco.com (38.104.158.77)  7.926 ms
 3  te0-7-0-12.ccr22.yyz02.atlas.cogentco.com (154.54.40.165)  1.081 ms
 4  be2080.ccr42.ord01.atlas.cogentco.com (154.54.42.5)  15.699 ms
 5  be2003.ccr21.ord03.atlas.cogentco.com (154.54.29.22)  15.394 ms
 6  *
 7  *
 8  *

Same with 64.7.137.0/24 and 64.7.135.0/24 for some reason, but not all 
subnets within 64.7.128.0/19 are blocked.


% traceroute -q1 -s 64.7.135.1 -Picmp 68.233.77.173
traceroute to 68.233.77.173 (68.233.77.173) from 64.7.135.1, 64 hops 
max, 60 byte packets

 1  iolite3 (199.212.135.73)  0.234 ms
 2  cogent-vl108 (67.43.129.246)  2.575 ms
 3  gi1-18.mag02.yyz02.atlas.cogentco.com (38.104.158.77)  2.844 ms
 4  te0-7-0-12.ccr21.yyz02.atlas.cogentco.com (154.54.40.137)  3.460 ms
 5  be2079.ccr41.ord01.atlas.cogentco.com (154.54.27.181)  17.338 ms
 6  be2005.ccr21.ord03.atlas.cogentco.com (66.28.4.74)  17.962 ms
 7  *
vs
% traceroute -q1 -s 64.7.138.225 -Picmp 68.233.77.173
traceroute to 68.233.77.173 (68.233.77.173) from 64.7.138.225, 64 hops 
max, 60 byte packets

 1  iolite3 (199.212.135.73)  0.193 ms
 2  cogent-vl108 (67.43.129.246)  2.210 ms
 3  gi1-18.mag02.yyz02.atlas.cogentco.com (38.104.158.77)  2.469 ms
 4  te0-7-0-12.ccr22.yyz02.atlas.cogentco.com (154.54.40.165)  3.091 ms
 5  be2080.ccr42.ord01.atlas.cogentco.com (154.54.42.5)  17.566 ms
 6  be2003.ccr21.ord03.atlas.cogentco.com (154.54.29.22)  18.457 ms
 7  38.104.102.102 (38.104.102.102)  17.831 ms
 8  border2.te8-1-bbnet2.chg004.pnap.net (64.94.32.83)  22.324 ms
 9  oraclebol-7.border2.chg004.pnap.net (74.217.8.106)  19.091 ms
10  VIP-CH-77-173.taleo.net (68.233.77.173)  20.318 ms

The issue started around July 3rd some time.  I have tried the listed 
contacts


OrgTechHandle: NOC2096-ARIN
OrgTechName:   Network Operation Center
OrgTechPhone:  +1-877-524-5665
OrgTechEmail:  network-contact...@oracle.com
OrgTechRef:http://whois.arin.net/rest/poc/NOC2096-ARIN

with no luck since last Thursday.  The toll free people were trying 
their best to understand who within Oracle I was trying to reach, but 
its not part of their normal decision tree.


via TATA and abovenet gives similar results.

 traceroute -q1 -Picmp -s 205.211.165.121 68.233.77.173
traceroute to 68.233.77.173 (68.233.77.173) from 205.211.165.121, 64 
hops max, 72 byte packets

 1  ix-11-2-3-0.tcore1.TNK-Toronto.as6453.net (209.58.16.21)  0.170 ms
 2  if-5-0-0-5.core4.TNK-Toronto.as6453.net (63.243.172.25)  30.856 ms
 3  if-0-3-2-0.tcore1.CT8-Chicago.as6453.net (63.243.172.34)  14.203 ms
 4  63.243.129.14 (63.243.129.14)  13.967 ms
 5  ae4.cr1.ord2.us.above.net (64.125.28.49)  12.203 ms
 6  ae9.mpr1.ord11.us.above.net (64.125.24.106)  13.043 ms
 7  ae4.mpr1.ord5.us.above.net (64.125.24.94)  15.027 ms
 8  *
 traceroute -q1 -Picmp -s 67.43.129.244 68.233.77.173
traceroute to 68.233.77.173 (68.233.77.173) from 67.43.129.244, 64 hops 
max, 72 byte packets

 1  ix-11-2-3-0.tcore1.TNK-Toronto.as6453.net (209.58.16.21)  29.514 ms
 2  if-11-0-0-4.core4.TNK-Toronto.as6453.net (64.86.33.42)  0.376 ms
 3  if-2-3-2-0.tcore1.CT8-Chicago.as6453.net (63.243.172.42)  12.124 ms
 4  63.243.129.14 (63.243.129.14)  13.624 ms
 5  ae4.cr1.ord2.us.above.net (64.125.28.49)  12.607 ms
 6  ae9.mpr1.ord11.us.above.net (64.125.24.106)  14.290 ms
 7  ae4.mpr1.ord5.us.above.net (64.125.24.94)  13.500 ms
 8  208.185.21.162 (208.185.21.162)  13.476 ms
 9  VIP-CH-77-173.taleo.net (68.233.77.173)  13.778 ms



---Mike

--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http

Re: Anyone from AS7160 (Oracle) around ? How about Inernap and Voxel ?

[Mike Tancsa]

Thanks to an unnamed frontline staff member who worked hard to find the 
right people at Oracle, I found the right people at Oracle-- She had no 
idea what I was talking about, but knew how to figure out how to find 
who I needed and didnt give up!


It seems Oracle is being sent bogus routing information from their PNAP 
peer. They are learning, what seems to be a random subnet of prefixes 
(two of which I am not even announcing-- 64.7.135.0/24 and 
64.7.137.0/24) that are learned from Torix. The path that 7160 sees is


19024 29791 8001 11670 11647

They see the following prefixes leaking out of Torix. But if they do a 
traceroute, the packets just bounce around between Voxel and PNAP. 
Traceroute below.  I have emailed the listed POCs, but no response. 
Anyone here from those 2 networks ?


64.7.128.0/24  *[BGP/170] 1w4d 11:08:57, localpref 100
  AS path: 19024 29791 8001 11670 11647 I
 to 74.217.8.105 via xe-2/2/0.0
64.7.135.0/24  *[BGP/170] 1w4d 12:03:19, localpref 100
  AS path: 19024 29791 8001 11670 11647 I
 to 74.217.8.105 via xe-2/2/0.0
64.7.137.0/24  *[BGP/170] 1w4d 13:52:08, localpref 100
  AS path: 19024 29791 8001 11670 11647 I
 to 74.217.8.105 via xe-2/2/0.0
198.235.180.0/24   *[BGP/170] 1w4d 06:07:16, localpref 100
  AS path: 19024 29791 8001 11670 11647 I
 to 74.217.8.105 via xe-2/2/0.0
198.235.181.0/24   *[BGP/170] 1w3d 06:53:31, localpref 100
  AS path: 19024 29791 8001 11670 11647 I
 to 74.217.8.105 via xe-2/2/0.0
198.235.183.0/24   *[BGP/170] 1w4d 02:44:55, localpref 100
  AS path: 19024 29791 8001 11670 11647 I
 to 74.217.8.105 via xe-2/2/0.0
204.138.108.0/24[BGP/170] 1w4d 05:18:36, localpref 100
  AS path: 19024 29791 8001 11670 11647 I
 to 74.217.8.105 via xe-2/2/0.0
205.211.165.0/24   *[BGP/170] 1w4d 08:04:32, localpref 100
  AS path: 19024 29791 8001 11670 11647 I
 to 74.217.8.105 via xe-2/2/0.0


traceroute to 64.7.135.1 (64.7.135.1), 30 hops max, 40 byte packets
 1  74.217.8.105 (74.217.8.105)  0.642 ms  0.514 ms  0.503 ms
 2  64.94.32.14 (64.94.32.14)  1.479 ms  1.564 ms  1.503 ms
 3  208.122.29.21 (208.122.29.21)  11.579 ms  1.428 ms  1.388 ms
 4  66.151.28.149 (66.151.28.149)  1.773 ms 66.151.28.141 
(66.151.28.141)  1.580 ms  1.524 ms

 5  64.94.32.14 (64.94.32.14)  1.448 ms  1.554 ms  1.558 ms
 6  208.122.29.21 (208.122.29.21)  10.274 ms  1.245 ms  1.232 ms
 7  66.151.28.149 (66.151.28.149)  1.831 ms  1.800 ms  1.785 ms
 8  64.94.32.78 (64.94.32.78)  2.027 ms 64.94.32.14 (64.94.32.14) 
1.519 ms  1.605 ms

 9  208.122.29.21 (208.122.29.21)  8.869 ms  1.291 ms  1.269 ms
10  66.151.28.149 (66.151.28.149)  1.872 ms  3.619 ms  1.869 ms
11  64.94.32.78 (64.94.32.78)  2.080 ms  1.956 ms  3.242 ms
12  208.122.29.21 (208.122.29.21)  6.033 ms  1.332 ms  1.302 ms
13  66.151.28.141 (66.151.28.141)  1.818 ms  2.006 ms  1.882 ms
14  64.94.32.14 (64.94.32.14)  1.699 ms  1.670 ms  1.615 ms
15  208.122.29.21 (208.122.29.21)  9.590 ms  1.566 ms  1.540 ms
16  66.151.28.149 (66.151.28.149)  1.891 ms  1.978 ms  1.869 ms
17  64.94.32.78 (64.94.32.78)  2.139 ms 64.94.32.14 (64.94.32.14)  1.726 
ms  1.741 ms

18  208.122.29.21 (208.122.29.21)  8.236 ms  1.416 ms  1.403 ms
19  66.151.28.149 (66.151.28.149)  2.251 ms  1.987 ms  1.968 ms
20  64.94.32.78 (64.94.32.78)  2.154 ms 64.94.32.14 (64.94.32.14)  1.818 
ms  1.754 ms

21  208.122.29.21 (208.122.29.21)  7.431 ms  1.684 ms  1.434 ms
22  66.151.28.141 (66.151.28.141)  1.758 ms  1.764 ms  2.006 ms
23  64.94.32.14 (64.94.32.14)  1.798 ms  1.691 ms 64.94.32.78 
(64.94.32.78)  2.201 ms

24  208.122.29.21 (208.122.29.21)  8.134 ms  1.469 ms  1.485 ms
25  66.151.28.141 (66.151.28.141)  10.774 ms  1.885 ms 66.151.28.149 
(66.151.28.149)  1.794 ms
26  64.94.32.14 (64.94.32.14)  1.720 ms 64.94.32.78 (64.94.32.78)  3.555 
ms 64.94.32.14 (64.94.32.14)  1.831 ms

27  208.122.29.21 (208.122.29.21)  1.762 ms  1.696 ms  1.714 ms
28  66.151.28.149 (66.151.28.149)  2.074 ms 66.151.28.141 
(66.151.28.141)  2.286 ms  1.919 ms
29  64.94.32.78 (64.94.32.78)  3.616 ms  2.337 ms 64.94.32.14 
(64.94.32.14)  1.911 ms

30  208.122.29.21 (208.122.29.21)  1.737 ms  1.528 ms  1.554 ms

---Mike

On 7/8/2014 9:15 AM, Mike Tancsa wrote:

Hi,
 I have been trying to get a hold of someone who looks after ASN
7160 since last Thursday both directly (OrgTechEmail), and indirectly
via upstreams with no luck.  I am trying to resolve or at least
understand a routing reachability issue between our two networks. It
seems packets from ASN7160 are not able to get back to some of my
netblocks in AS 11647.
e.g.

eg. this is fine
% traceroute -q1 -s 98.159.240.105 -Picmp 68.233.77.173
traceroute to 68.233.77.173 (68.233.77.173) from 98.159.240.105, 64

Re: Anyone from AS7160 (Oracle) around ? How about Inernap and Voxel ?

[Mike Tancsa]

It seems Oracle is being sent bogus routing information from their PNAP
peer. They are learning, what seems to be a random subnet of prefixes
(two of which I am not even announcing-- 64.7.135.0/24 and
64.7.137.0/24) that are learned from Torix. The path that 7160 sees is

19024 29791 8001 11670 11647


The nice people at pnap actually took my call--I have had a couple in 
the past say, Sorry, you are not our customer. click..  They found 
an issue with their routing engine injecting stale / bogus info into 
parts of their network and corrected it.


---Mike

--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: Parsing Syslog and Acting on it, using other input too

[Mike Tancsa]

On 8/29/2013 9:03 AM, Kasper Adel wrote:
 Hello.
 
 I am looking for a way to do proactive monitoring of my network, what I am
 specifically thinking about is receiving syslog msgs from the routers and

You might want to look at

http://www.ossec.net/

---Mike




-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: GMail IPv6 IMAP Issue, or is it Just Me?

[Mike Tancsa]

On 6/1/2013 1:53 PM, Stevens, Brant I. wrote:
 Is anyone else having issues reaching GMail on IPv6 via IMAP, or is it just
 me?
 
 imac01:~ branto$ telnet -6 imap.gmail.com 993
 Trying 2607:f8b0:400d:c01::6c...
 telnet: connect to address 2607:f8b0:400d:c01::6c: Operation timed out
 telnet: Unable to connect to remote host


Looks ok for me via Toronto, Ont, Canada

0(marble)% host imap.gmail.com
imap.gmail.com is an alias for gmail-imap.l.google.com.
gmail-imap.l.google.com has address 74.125.142.108
gmail-imap.l.google.com has address 74.125.142.109
gmail-imap.l.google.com has IPv6 address 2607:f8b0:4003:c01::6c
0(marble)%

% traceroute6 -q1 2607:f8b0:4003:c01::6c
traceroute6 to 2607:f8b0:4003:c01::6c (2607:f8b0:4003:c01::6c) from
2607:f3e0::2, 64 hops max, 12 byte packets
 1  iolite4-6  0.560 ms
 2  toronto-torix-6  4.678 ms
 3  he.ip6.torontointernetxchange.net  3.793 ms
 4  2001:478:245:1::6  5.810 ms
 5  2001:4860::1:0:e38  3.471 ms
 6  2001:4860::8:0:2fe9  16.342 ms
 7  2001:4860::8:0:29ee  31.341 ms
 8  2001:4860::2:0:95e  31.340 ms
 9  *
10  ob-in-x6c.1e100.net  30.584 ms


1(marble)% openssl s_client -host imap.gmail.com -port 993
CONNECTED(0003)
depth=1 /C=US/O=Google Inc/CN=Google Internet Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-BEGIN CERTIFICATE-
MIIDgDCCAumgAwIBAgIKVEsbtQABAACELjANBgkqhkiG9w0BAQUFADBGMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu
dGVybmV0IEF1dGhvcml0eTAeFw0xMzA0MTUwODQ0MDBaFw0xMzEyMzExNTU4NTBa
MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N
b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw5pbWFw
LmdtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3a/wUjZBSOgZ
EeyRqaSaKEwS8+1y/8AK9HdplSR72PU+iBc7HyA4aXgD6XYEJVoyGsO97nMj+oeN
2iNvKfkPvTrn2YnQfJLuxpEw9gwIHvwVqy3TNpHwt4DHnxOg5CxV8e7PaCAhAXD+
uj0H09aVFJmfYDnU0VSSukNJX2MZSJUCAwEAAaOCAVEwggFNMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUY9A6EExy3NNFBc2R0vrY8lpf
OB8wHwYDVR0jBBgwFoAUv8Aw6/VDET5nup6R+/xq2uNrEiQwWwYDVR0fBFQwUjBQ
oE6gTIZKaHR0cDovL3d3dy5nc3RhdGljLmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhv
cml0eS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS5jcmwwZgYIKwYBBQUHAQEEWjBY
MFYGCCsGAQUFBzAChkpodHRwOi8vd3d3LmdzdGF0aWMuY29tL0dvb2dsZUludGVy
bmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9yaXR5LmNydDAMBgNVHRMB
Af8EAjAAMBkGA1UdEQQSMBCCDmltYXAuZ21haWwuY29tMA0GCSqGSIb3DQEBBQUA
A4GBAAcrDCcXCKZ2VNcJv31SSXTKs1AH0sU1lvAB0kzy3mIB/H8UHvMz1+T3Lfmy
68bqBSM97W6MO6UiqmVvbMhwPBrktUVT/Q4cWskVf2MONrW3g0UtX47L1ocs/WZe
XdUTkjQ3EFCzxpw4joHefndfZHsEn0VrjZR49kzR9+1Me7Rz
-END CERTIFICATE-
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority
---
No client certificate CA names sent
---
SSL handshake has read 1752 bytes and written 325 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: RC4-SHA
Session-ID:
881124D0017ADA0B7D8CEB26ECBCBCF86AF8A593600858D165164A17B2C0C652
Session-ID-ctx:
Master-Key:
667BDFF99C7FE7733C8CB36FE2F73C76380DE2AC9453A0D3D621E39CE64EC1259BC8AB8FE65C425E15BCA467B80FD274
Key-Arg   : None
Start Time: 1370137039
Timeout   : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
* OK Gimap ready for requests from 199.212.134.2 bj1if1491559oac.162
^C
1(marble)%  
-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: Bell Canada outage?

[Mike Tancsa]

On 8/8/2012 2:50 PM, Jeff Wheeler wrote:
 
 It also took over 10 minutes for my BGP withdraws to propagate from
 Bell to their neighbors, including Level3.  I would guess Bell
 Canada's routers all have very busy CPU.
 

I saw the same sort of behaviour from TATA. I shut my peer with them,
yet TATA was still advertising to Level3 a good 15min after !??!

route-views traceroute 199.212.134.1

Type escape sequence to abort.
Tracing the route to 199.212.134.1

  1 vl-51.uonet1-gw.uoregon.edu (128.223.51.2) [AS 3582] 280 msec 364
msec 280 msec
  2 3.xe-1-3-0.uonet10-gw.uoregon.edu (128.223.3.10) [AS 3582] 252 msec
272 msec 272 msec
  3 eugn-car1-gw.nero.net (207.98.68.177) [AS 3701] 272 msec 268 msec
244 msec
  4 eugn-core1-gw.nero.net (207.98.64.161) [AS 3701] 260 msec 272 msec
280 msec
  5 ge-6-21.car1.Sacramento1.Level3.net (4.53.200.1) [AS 3356] 296 msec
260 msec 312 msec
  6 ae-11-11.car2.Sacramento1.Level3.net (4.69.132.150) [AS 3356] [MPLS:
Label 83 Exp 0] 304 msec 328 msec 376 msec
  7 ae-4-4.ebr2.SanJose1.Level3.net (4.69.132.158) [AS 3356] [MPLS:
Label 1123 Exp 0] 328 msec 252 msec 308 msec
  8 ae-3-3.ebr1.Denver1.Level3.net (4.69.132.58) [AS 3356] [MPLS: Label
1191 Exp 0] 332 msec 240 msec 232 msec
  9 ae-1-100.ebr2.Denver1.Level3.net (4.69.151.182) [AS 3356] [MPLS:
Label 1189 Exp 0] 252 msec 56 msec 40 msec
 10 ae-3-3.ebr1.Chicago2.Level3.net (4.69.132.62) [AS 3356] [MPLS: Label
1186 Exp 0] 72 msec 72 msec 248 msec
 11 ae-1-51.edge3.Chicago3.Level3.net (4.69.138.136) [AS 3356] 200 msec
344 msec 200 msec
 12 tata-level3.chicago3.level3.net (4.68.110.194) [AS 3356] 204 msec
200 msec 216 msec
 13  *  *  *
 14 if-4-2.tcore1.MTT-Montreal.as6453.net (64.86.31.17) [AS 6453] 80 msec
if-13-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.32.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 84 msec 228 msec
 15  *  *  *
 16 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453]
[MPLS: Label 1678 Exp 0] 260 msec 244 msec 236 msec
 17 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 272 msec
if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 272 msec
if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 260 msec
 18 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 224 msec 208 msec 204 msec
 19 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453]
[MPLS: Label 1678 Exp 0] 260 msec 344 msec 300 msec
 20 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 256 msec
if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453]
[MPLS: Label 1678 Exp 0] 240 msec
if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 268 msec
 21 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 232 msec
if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 248 msec
if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 256 msec
 22 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 232 msec 240 msec 240 msec
 23 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453]
[MPLS: Label 1678 Exp 0] 244 msec *  *
 24 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 284
msec 208 msec 220 msec
 25 if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 204
msec 256 msec
if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 204 msec
 26 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 224 msec 424 msec 208 msec
 27 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453]
[MPLS: Label 1678 Exp 0] 220 msec *  *
 28 if-5-0-0.mcore3.TTT-Scarborough.as6453.net (64.86.31.22) [AS 6453]
[MPLS: Label 1678 Exp 0] 136 msec 128 msec
if-1-0-0.core4.TNK-Toronto.as6453.net (63.243.172.1) [AS 6453] 116 msec
 29 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) [AS 6453]
[MPLS: Label 3208 Exp 0] 128 msec 124 msec 116 msec
 30  *  152 msec 120 msec
route-views


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: incoming smtp from v6 addresses

[Mike Tancsa]

On 1/4/2012 5:10 AM, Randy Bush wrote:
 for incoming mail that is *accepted*, i.e. not stuff like
 2012-01-04 00:37:28 REJECT because 118.39.80.118 listed in 
 rbl-plus.mail-abuse.org
 2012-01-04 00:37:28 H=(nexo.es) [118.39.80.118] F=ped...@nexo.es 
 rejected RCPT owner-radius...@ops.ietf.org: blocked because 118.39.80.118 
 is in  blacklist at rbl-plus.mail-abuse.org: Mail from 118.39.80.118 blocked 
 using Trend Micro Email Reputation database. Please see 
 http://www.mail-abuse.com/cgi-bin/lookup?118.39.80.118
 2012-01-04 00:37:28 no host name found for IP address 118.39.80.118
 2012-01-04 00:37:29 REJECT 118.39.80.118 too many bad recip
 2012-01-04 00:37:29 REJECT because 118.39.80.118 listed in 
 rbl-plus.mail-abuse.org
 
 7.8% is over ipv6 transport
 
 but only 2% of outgoing deliveries are over ipv6.

For accepted mail today,

2% is v6 for outbound,
4% for v6 is inbound.

I suspect the higher inbound values might be due to tech mailling lists
which tend to come from IPv6 enabled hosts ?

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: Verizon Issues? East Coast US

[Mike Tancsa]

Hi,
Yeah, I was just seeing some issues through TATA (AS6453) with routes
being blackholed in Newark, or at least that was where the packets
stopped. I had to shut my peer with them and I just finished opening a
trouble ticket.

A traceroute to 209.167.35.0/24 from a source addr in 205.211.164.0/24
byte packets
 1  teleglobe-vl38-tor (205.211.165.121)  0.259 ms  0.465 ms  0.488 ms
 2  if-2-3-513.core4.TNK-Toronto.as6453.net (209.58.16.21)  0.987 ms
0.981 ms  0.565 ms
 3  if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2)  53.390
ms  2.973 ms  2.991 ms
 4  if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34)  20.481 ms
62.938 ms  20.967 ms
 5  if-2-2.tcore2.NJY-Newark.as6453.net (66.198.70.2)  20.986 ms  21.059
ms  20.871 ms
 6  * * *

Not sure if it was after them or coming back to them.  Same source addr
through AS174 is fine



---Mike


On 8/3/2011 3:27 PM, James Smallacombe wrote:
 
 I'm having issues through Verizon too...I have a server colocated in
 Vancouver...could it be a Canadian thing with Verizon?
 
  2  l100.phlapa-vfttp-60.verizon-gni.net (98.114.95.1)  8.910 ms  8.760
 ms 7.026 ms
  3  g3-0-2-860.phlapa-lcr-08.verizon-gni.net (130.81.139.120)  10.711 ms
 8.466 ms  10.698 ms
  4  * * *
  5  so-13-2-0-0.res-bb-rtr2.verizon-gni.net (130.81.19.118)  14.937 ms
 15.975 ms  15.148 ms
  6  0.ae2.br2.iad8.alter.net (152.63.34.73)  14.346 ms  13.943 ms 
 14.833 ms
  7  * * *
  8  * * *
 
 I can ssh to the box from other networks, and here's a traceroute back
 to my Verzon FIOS IP...other Verizon customers (DSL, etc) report same
 problem:
 
  2  static-209-17-142-114.gtcust.grouptelecom.net (209.17.142.114) 
 0.744 ms  0.642 ms  0.620 ms
  3  static-66-38-255-9.gtcust.grouptelecom.net (66.38.255.9)  0.750 ms
 0.657 ms  0.649 ms
  4  GE3-0.PEERA-VANCBC.IP.GROUPTELECOM.NET (66.59.190.6)  0.730 ms 
 0.694 ms  0.693 ms
  5  bx4-vancouver_G1-1-6.net.bell.ca (67.69.199.105)  0.847 ms  0.836 ms
 0.828 ms
  6  core4-vancouver_ge8-0-0.net.bell.ca (64.230.183.109)  4.637 ms
 core3-vancouver_ge8-0-0.net.bell.ca (64.230.183.105)  113.794 ms
 17.328 ms
  7  core2-seattle_pos4-0-0_core.net.bell.ca (64.230.144.97)  23.686 ms
 core1-seattle_pos6-0-0_core.net.bell.ca (64.230.144.89)  4.672 ms
 core2-seattle_pos4-0-0_core.net.bell.ca (64.230.144.97)  5.720 ms
  8  bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22)  4.358 ms
 bx2-seattle_POS11-0-0.net.bell.ca (64.230.186.26)  4.396 ms
 bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22)  4.353 ms
  9  Comcast-peering.net.bell.ca (67.69.246.198)  4.991 ms  4.795 ms 
 4.795 ms
 10  pos-0-4-0-0-cr01.seattle.wa.ibone.comcast.net (68.86.86.137)  8.285
 ms 5.258 ms  4.919 ms
 11  pos-0-6-0-0-cr01.denver.co.ibone.comcast.net (68.86.87.49)  46.892
 ms 46.901 ms  46.952 ms
 12  pos-0-13-0-0-cr01.chicago.il.ibone.comcast.net (68.86.85.245) 
 57.243 ms  57.359 ms  57.333 ms
 13  pos-2-13-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.87.25)  85.080
 ms  85.020 ms  85.069 ms
 14  te-2-1-pe01.philadelphia.pa.ibone.comcast.net (68.86.84.194)  87.264
 ms  86.372 ms  86.453 ms
 15  75.149.230.250 (75.149.230.250)  86.548 ms  86.489 ms  86.439 ms
 
 
 On Mon, 28 Feb 2011, Mike Tancsa wrote:
 
 I was just looking at an issue between 701 in Toronto.   Seems to be
 resolved now-- at least the issue I was seeing.


 the bad traceroute, looked like
 
 3  if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3)  0.988 ms  0.978
 ms  1.578 ms
 4  209.58.94.10 (209.58.94.10)  1.902 ms  71.416 ms  3.472 ms
 5  if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34)  22.286 ms 
 21.957 ms  29.472 ms
 6  if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14)  67.961 ms
if-3-0-0.mcore3.NJY-Newark.as6453.net (216.6.57.121)  21.449 ms 
 20.956 ms
 7  if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66)  21.975 ms 
 22.467 ms  21.977 ms
 8  Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49)  20.977 ms * 
 30.520 ms
 9  0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173)  21.478 ms  21.458 ms 
 21.477 ms
 10  *
 11  *

 Now its working

 
 3  if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3)  0.975 ms
 4  209.58.94.10 (209.58.94.10)  1.975 ms
 5  if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34)  21.445 ms
 6  if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14)  54.472 ms
 7  if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66)  112.426 ms
 8  Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49)  22.964 ms
 9  0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173)  21.455 ms
 10  0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117)  21.466 ms
 11  0.so-5-1-0.XT2.TOR2.ALTER.NET (152.63.128.121)  34.958 ms
 12  0.POS7-1.GW2.TOR2.ALTER.NET (152.63.131.205)  33.958 ms


 When it was not working, packets would not get from my AS (11647) to
 the target in IP in AS701.  But packets from 701 would get back to my
 AS.  The AS path in both directions are 701-6453-11647 and 11647 6453
 701...  I saw a similar outage to VPNs I have in AS15290 which I see
 as 11647 6453 701 15290.  However, I did

Re: Verizon Issues? East Coast US

[Mike Tancsa]

On 8/3/2011 3:31 PM, James Smallacombe wrote:
 
 
 However, I AM seeing problems right now as described below...anybody
 aware of any Verizon issues?

I was told by TATA one of their core routers in NY is not reachable. So
perhaps some inadvertent black hole routing between them / by them.

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: Verizon Issues? East Coast US

[Mike Tancsa]

On 8/3/2011 5:32 PM, Jason Lixfeld wrote:
 On 2011-08-03, at 3:50 PM, Mike Tancsa wrote:
 
 On 8/3/2011 3:31 PM, James Smallacombe wrote:


 However, I AM seeing problems right now as described below...anybody
 aware of any Verizon issues?

 I was told by TATA one of their core routers in NY is not reachable. So
 perhaps some inadvertent black hole routing between them / by them.
 
 Do you have a ticket number, Mike?  Seems like they are still blackholing 
 traffic.

I will send the ticket offlist. The last update I got from them an hr ago



Dear Customer,

Our TAC team investigated and found still our router in New York is
facing issue.
We have to emergency upgraded the ios and clear the issue.

We will update after activity is completed.


---Mike
-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: where are all the IPv6 tools?

[Mike Tancsa]

On 5/25/2011 3:29 PM, Kyle Duren wrote:
 On Wed, May 25, 2011 at 11:54 AM, Jay Borkenhagen j...@braeburn.org wrote:

 Do folks here know of IPv6 tools that might provide some of the
 functions the above tools provide for IPv4?

 
 I recommend IPv6gen.
 
 http://code.google.com/p/ipv6gen/
 
 Very useful. Granted its not what you were asking for exactly

I use it as well. Great tool. (In the FreeBSD ports tree too). I have
also made use of the perl tool Net::IPv6Addr.

---Mike



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: IPv6 foot-dragging

[Mike Tancsa]

On 5/11/2011 11:03 AM, ja...@jamesstewartsmith.com wrote:
 I have had similar problems with our providers, and these are tier 1 
 companies that should have already been full deployed.  These are also some 
 of the more expensive providers on a per Mb basis.  The one provider that was 
 full IPv6 ready was Cogent.  HE is also IPv6 (although we don't use them atm.)

There are a number of networks in Canada that provide v6 transit both
big and small.  I have v6 transit from TATA, HE and Cogent out of
Toronto.  Many Canadian networks peer at Torix which also lists their v6
status.

http://www.torix.net/peers.php



---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: VPN tunnels between US and China dropping/slow

[Mike Tancsa]

On 5/10/2011 10:12 AM, Thomas York wrote:
 At my current place of business, we have several manufacturing plants in
 China as well as the United States. All of the plants have an OVPN tunnel to
 a datacenter here in Indianapolis which connect all of the plants. Our China
 plants pay for the basic 3mbit/3mbit fiber internet connections. I've had a
 hell of a time keeping their tunnels up. They're running on port 443 over
 TCP now, but every month or so the tunnel degrades so badly I have to switch
 the port. I've recently tried tunneling OVPN (UDP) over a GRE tunnel and

Perhaps a DPI issue ?  We make use of OpenVPN a lot here.  When the
local ILEC started rolling out their DPI boxes, our VPN traffic was
initially identified as bit torrent traffic and was being tampered with.
 Of course they said that was impossible... It took a good month before
I was able to get to the right people to actually look at the pcaps that
demonstrated the issue.  I setup an openvpn tunnel between the two
impacted sites (A,B)

From A, I would do a straight up icmp ping to B. It would get to the
other side 100% clean.

At the same, time, I would do a ping inside the VPN tunnel.  It would
show dropped packets.

I then used hping to generate UDP packets of the same size or bigger of
the VPN packets, but with all FF as the payload, so it didnt look like
anything to the DPI boxes. This too would get to the other side 100% of
the time.  But the VPN UDP packets would experience loss.  The DPI
vendor then made some patches and/or config changes to stop messing up
our traffic and we have been ok since.

Not sure what you can do on the China side to test things, but perhaps
setup an OpenVPN instance in one of those free test instances in Amazon
and see if you see the loss from there to China.


---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: OT: Question/Netflix issues?

[Mike Tancsa]

Where do you pick up their feeds from ?  A lot of their content seems to
come from CDNs like Akamai in my neighbourhood (in this case, Torix).
That being said, I just tried to watch a movie and all I get is
Checking for device activation My browser seems to be blabbing
back and forth with
208.75.79.32  on port 443
which I see 11647 6453 7922 2906.

---Mike



On 3/22/2011 7:14 PM, Joe Blanchard wrote:
 Greetings,
 
   I know this is way off topic, but is anyone else getting calls/tickets
 about Netflix access problems?
 
 I tried (sucessfully) to duplicate the issues, seems like extremely slow
 responses from the servers I have tested, as well seems the web servers
 are also either overloaded or just dropping packets. Just wondering if
 anyone else is seeing the same.
 
 Kind Regards,
 -Joe Blanchard
 
 


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

gmail issues ?

[Mike Tancsa]

Anyone seeing gmail issues ? I checked at
http://www.google.com/appsstatus#hl=en

and it says all ok. Yet I either get an RST, or it just times out, or
the 3 way handshake completes, and then just FINs my connection. I tried
a number of different source IPs inside my network as well as some
outside my AS.

# telnet gmail-smtp-in.l.google.com 25
Trying 74.125.95.27...
telnet: connect to address 74.125.95.27: Connection refused
telnet: Unable to connect to remote host


17:12:29.464719 IP 64.7.153.18.19574  209.85.225.27.25: Flags [S], seq
688245543, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val
2436358711 ecr 0], length 0
17:12:29.496153 IP 209.85.225.27.25  64.7.153.18.19574: Flags [S.], seq
2208544696, ack 688245544, win 5672, options [mss 1430,sackOK,TS val
1980791251 ecr 2436358711,nop,wscale 6], length 0
17:12:29.496174 IP 64.7.153.18.19574  209.85.225.27.25: Flags [.], ack
1, win 8330, options [nop,nop,TS val 2436358743 ecr 1980791251], length 0
17:12:29.528117 IP 209.85.225.27.25  64.7.153.18.19574: Flags [F.], seq
1, ack 1, win 89, options [nop,nop,TS val 1980791283 ecr 2436358743],
length 0
17:12:29.528135 IP 64.7.153.18.19574  209.85.225.27.25: Flags [.], ack
2, win 8330, options [nop,nop,TS val 2436358775 ecr 1980791283], length 0
17:12:29.528195 IP 64.7.153.18.19574  209.85.225.27.25: Flags [F.], seq
1, ack 2, win 8330, options [nop,nop,TS val 2436358775 ecr 1980791283],
length 0
17:12:29.559511 IP 209.85.225.27.25  64.7.153.18.19574: Flags [.], ack
2, win 89, options [nop,nop,TS val 1980791314 ecr 2436358775], length 0


---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: Verizon Issues? East Coast US

[Mike Tancsa]

I was just looking at an issue between 701 in Toronto.   Seems to be resolved 
now-- at least the issue I was seeing.


the bad traceroute, looked like

 3  if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3)  0.988 ms  0.978 ms  
1.578 ms
 4  209.58.94.10 (209.58.94.10)  1.902 ms  71.416 ms  3.472 ms
 5  if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34)  22.286 ms  21.957 ms 
 29.472 ms
 6  if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14)  67.961 ms
if-3-0-0.mcore3.NJY-Newark.as6453.net (216.6.57.121)  21.449 ms  20.956 ms
 7  if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66)  21.975 ms  22.467 ms  
21.977 ms
 8  Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49)  20.977 ms *  30.520 
ms
 9  0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173)  21.478 ms  21.458 ms  21.477 ms
10  *
11  *

Now its working


 3  if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3)  0.975 ms
 4  209.58.94.10 (209.58.94.10)  1.975 ms
 5  if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34)  21.445 ms
 6  if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14)  54.472 ms
 7  if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66)  112.426 ms
 8  Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49)  22.964 ms
 9  0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173)  21.455 ms
10  0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117)  21.466 ms
11  0.so-5-1-0.XT2.TOR2.ALTER.NET (152.63.128.121)  34.958 ms
12  0.POS7-1.GW2.TOR2.ALTER.NET (152.63.131.205)  33.958 ms


When it was not working, packets would not get from my AS (11647) to the target 
in IP in AS701.  But packets from 701 would get back to my AS.  The AS path in 
both directions are 701-6453-11647 and 11647 6453 701...  I saw a similar 
outage to VPNs I have in AS15290 which I see as 11647 6453 701 15290.  However, 
I did not have time to check if it was the same behaviour with loss being in 
one direction. In both cases, IPs that follow 11647 174 701 and 701 174 11647 
and 11647 174 7018 15290  and 15290 7018 174 11647 were not impacted.

---Mike



On 2/28/2011 9:53 PM, ML wrote:
 Seeing some packet loss via Cogent.
 
 www.internetpulse.net seems to be lighting up.
 
 


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

Re: IPv6 BGP table size comparisons

[Mike Tancsa]

On 12/24/2010 12:55 PM, Elliott, Andrew wrote:
 -Original Message-
 From: Seth Mattinen [mailto:se...@rollernet.us] 
 Sent: Thursday, December 23, 2010 8:37 PM
 To: nanog@nanog.org
 Subject: Re: IPv6 BGP table size comparisons
 
 On 12/21/10 2:18 PM, Frank Bulk wrote:
 There are 4,035 routes in the global IPv6 routing table.  This is what one
 provider passed on to me for routes (/48 or larger prefixes), extracted from
 public route-view servers.
  ATT AS7018: 2,851 (70.7%)
  Cogent AS174: 2,864 (71.0%)
  GLBX AS3549: 3,706 (91.8%)
  Hurricane Electric AS6939: 3,790 (93.9%)
  Qwest AS209: 3,918 (97.1%)
  TINET (formerly Tiscali) AS3257: 3,825 (94.8%)
  Verizon AS701: 3,938 (97.6%)
 
 
 Sprint (AS1239) is sending 3,779 routes.
 
 XO Communications (AS2828) is sending 3973 prefixes.


I had a quick look at the diff between routes given to me by AS174 and
6453 and other v6 peers and here is what I found based on missing /32s.
 (I excluded /48s for now)

There are some 490 /32s missing from Cogent from my network in Toronto,
Canada.   The majority are paths via just 6939.  Of those that are not
just 6939, I see them via the following AS paths.

  11647 6453 293
  11647 6453 701 668
  11647 6453 30071 13645
  11647 13030 15716
  11647 6453 5511
  11647 6453 6830
  11647 6453 25137
  11647 6453 30071 2549
  11647 6453 30071 10318
  11647 6453 6762 7303
  11647 6453 30071
  11647 6453 6762 8280
  11647 6453 13030
  11647 13030
  11647 6453 701
  11647 6453 6762
  11647 6453 5511 8346
  11647 6453 30071
  11647 6453 13030 8271
  11647 13030 8271
  11647 6453 13030 33845
  11647 6453 701 18061 9555
  11647 6453 6762 7642
  11647 6453 30071 6536
  11647 6453 701 18750
  11647 6453 30071 19151
  11647 6453 701 26773
  11647 6453 30071 10326
  11647 6453 30071 19151 16842
  11647 6453 30071 19151 31877
  11647 6453 30071 19151 22911
  11647 6453 30071 13911
  11647 6453 30071 7786
  11647 6453 30071 13911 14595
  11647 6453 6762 7303 4270
  11647 6453 6762 7303 4270 27770
  11647 6453 6762 7303 4270 5692
  11647 6453 13030 48218
  11647 13030 48218
  11647 6453 13030 20634
  11647 13030 20634
  11647 6453 701 12702 24807
  11647 6453 6830
  11647 6453 5511 8697
  11647 6453 6762 31463
  11647 13030 9191
  11647 6453 13030 25164
  11647 13030 25164
  11647 6453 13030 16242
  11647 13030 16242
  11647 6453 13030 28717
  11647 6453 13030 25563
  11647 13030 25563
  11647 6453 5511 3215
  11647 6453 5511 3215
  11647 6453 5511 3215
  11647 6453 5511 12493
  11647 6453 13030 44573
  11647 6453 13030 35366
  11647 6453 13030 29430
  11647 13030 29430
  11647 6453 13030 21232
  11647 13030 21232
  11647 6453 13030 47617
  11647 13030 47617
  11647 6453 6830 20825
  11647 6453 6762 8953
  11647 6453 13030 15216
  11647 13030 15216
  11647 6453 13030
  11647 13030


e.g.

 2607:f078::/32
  11647 6453 701 18750
  11647 6939 18750

and

2a01:c910::/32
 11647 6453 5511 3215
 11647 6939 5511 3215

Re: IPv6 BGP table size comparisons

[Mike Tancsa]

On 12/21/2010 5:18 PM, Frank Bulk wrote:
 There are 4,035 routes in the global IPv6 routing table.  This is what one
 provider passed on to me for routes (/48 or larger prefixes), extracted from
 public route-view servers.
   ATT AS7018: 2,851 (70.7%)
   Cogent AS174: 2,864 (71.0%)
   GLBX AS3549: 3,706 (91.8%)
   Hurricane Electric AS6939: 3,790 (93.9%)
   Qwest AS209: 3,918 (97.1%)
   TINET (formerly Tiscali) AS3257: 3,825 (94.8%)
   Verizon AS701: 3,938 (97.6%)

TATA (AS6453) out of Toronto, Canada  3,747.

For my v4 transit, I only see 0.3% difference from my largest and
smallest view.   Where as with ipv6, the difference is almost 25%.  For
/48 and shorter, I see 757 paths missing from AS174 that I see on my
other 2 v6 transit providers.

---Mike

Re: IPv6 BGP table size comparisons

[Mike Tancsa]

On 12/21/2010 7:10 PM, Mike Tancsa wrote:
 On 12/21/2010 5:18 PM, Frank Bulk wrote:
 There are 4,035 routes in the global IPv6 routing table.  This is what one
 provider passed on to me for routes (/48 or larger prefixes), extracted from
 public route-view servers.
  ATT AS7018: 2,851 (70.7%)
  Cogent AS174: 2,864 (71.0%)
  GLBX AS3549: 3,706 (91.8%)
  Hurricane Electric AS6939: 3,790 (93.9%)
  Qwest AS209: 3,918 (97.1%)
  TINET (formerly Tiscali) AS3257: 3,825 (94.8%)
  Verizon AS701: 3,938 (97.6%)
 
 TATA (AS6453) out of Toronto, Canada  3,747.
 
 For my v4 transit, I only see 0.3% difference from my largest and
 smallest view.   Where as with ipv6, the difference is almost 25%.  For
 /48 and shorter, I see 757 paths missing from AS174 that I see on my
 other 2 v6 transit providers.

While looking at whats missing, I found this interesting /48.

+2607:fed0::/32
+2607:fed8::/32
+2607:ff08:cafe::/48
+2607:ff20::/32


The 2607:ff08::/32 is visible on Cogent.  But I guess they are not
serving coffee there, only on TATA and HE.

---Mike

Re: Wholesale DSL implementation in Canada

[Mike Tancsa]

On 12/13/2010 10:10 AM, James Smith wrote:
 
 We're looking at implementing a DSL private network in various provinces in 
 Canada.  There seems to be two main ways to do this: build the network 
 yourself by creating relationships with the local DSL providers (Bell, Telus, 
 MTS, etc) ; or build the network using a third-party that already has a DSL 
 infrastructure in place.  The third-party DSL infrastructure is a sure thing, 
 since they've been doing it for a while.  However, we're looking at a large 
 number of locations so the cost of implementing the DSL internally seems to 
 be more compelling.
 
 Not having implemented a DSL infrastructure before, I'm wondering if anyone 
 on NANOG has any advice on this?  What technical or political issues might we 
 run into?  What is the best choice of hardware? (Juniper or Cisco)?  Feel 
 free to contact me off-list if you'd prefer.

For regulations, start with http://www.crtc.gc.ca/

How you can lease copper loops, how you can colo in CO etc are all laid
out in various tariffs

---Mike

Re: IPv6

[Mike Tancsa]

On 11/18/2010 4:39 PM, Nick Olsen wrote:
 Curious as to who is running IPv6 with TW Telecom or Cogent.
 I'm wanting to turn up native IPv6 with them, And wanted to hear 
 thoughts/experiences.
 I assume it should be a non-event. We've already got a prefix from arin 
 that we are going to announce.
 

Hi,
It was very painless and straight forward with Cogent. TATA (6453) was a
little more paperwork than I anticipated and took some time to process.

---Mike

Re: IPv6

[Mike Tancsa]

On 11/18/2010 5:14 PM, Lee Riemer wrote:
 Try tracerouting to 2001:500:4:13::81 (www.arin.net) or 
 2001:470:0:76::2 (www.he.net) via Cogent.
 

Interesting. I noticed a similar issue with  ipv6.cnn.com today. I dont
see it via TATA, but see it via Cogent.  So whats the story behind it
and ARIN not being seen through cogent ?  Is it due to no v6 relation
bewtween he.net and Cogent ?

2620:0:2200:8::::8901  (whats with the crazy 8s?)

see
http://lg.as6453.net/lg/

Router: gin-mtt-mcore3
Site: CA, Montreal - MTT, TATA COMM. INT. CENTER
Command: traceroute ipv6 2620:0:2200:8::::8901


Tracing the route to 2620:0:2200:8::::8901

  1  *  *  *
  2  *  *  *
  3  *  *  *
  4  *  *  *

---Mike

Re: IPv6

[Mike Tancsa]

On 11/18/2010 5:44 PM, Mike Tancsa wrote:
 On 11/18/2010 5:14 PM, Lee Riemer wrote:
 Try tracerouting to 2001:500:4:13::81 (www.arin.net) or 
 2001:470:0:76::2 (www.he.net) via Cogent.

 
 Interesting. I noticed a similar issue with  ipv6.cnn.com today. I dont
 see it via TATA, but see it via Cogent.  So whats the story behind it
 and ARIN not being seen through cogent ?  Is it due to no v6 relation
 bewtween he.net and Cogent ?
 
 2620:0:2200:8::::8901  (whats with the crazy 8s?)
 
 see
 http://lg.as6453.net/lg/
 
 Router: gin-mtt-mcore3
 Site: CA, Montreal - MTT, TATA COMM. INT. CENTER
 Command: traceroute ipv6 2620:0:2200:8::::8901
 
 


I see it as 2620:0:2200::/48  from HE ( 6939 2828 5662 )  and Cogent (
174 2828 5662)

TATA says...

Router: gin-mtt-mcore3
Site: CA, Montreal - MTT, TATA COMM. INT. CENTER
Command: show bgp ipv6 unicast 2620:0:2200::/48


% Network not in table

I wonder how many 'holes' are like this...

---Mike

Re: Token ring? topic hijack: was Re: Mystery open source switching

[Mike Tancsa]

At 03:43 PM 11/2/2010, Chris Boyd wrote:


On Nov 1, 2010, at 11:48 AM, Nick Hilliard wrote:

 And FDDI and X.25 and every single legacy protocol

Are there still any commercial X.25 nets in operation?



DATAPAC in Canada was running at least until Jan of this year. The 
price per month kept getting turned up and up and up and up to 
encourage the last users to migrate away.  By the end, I think all 
that was left were various banking / POS applications. I seem to 
recall the price around $1,500 a month at the end.


---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

Re: Odd cableone traceroute with 0.0.0.0 in path

[Mike Tancsa]

At 02:55 PM 10/28/2010, Brielle Bruns wrote:
Okay, so this has my head hurting a bit just trying to figure out 
just how this is possible and what kind of equipment would pull this stunt.


misconfig of a p2p addr somewhere ?  perhaps someone used 0.0.0.0/30 
as a p2p addr for kicks.


e.g. I just tried this at home.

on a next hop router,
# ifconfig igb1 0.0.0.0/30 alias


on a node/workstation behind the above router

0(i5)# ifconfig em0 0.0.0.1/30 alias
0(i5)# route add 173.194.32.104 0.0.0.0

0(i5)# telnet -s 10.255.255.27 173.194.32.104 80
Trying 173.194.32.104...
Connected to yyz06s05-in-f104.1e100.net.
Escape character is '^]'.


And looking for the arp who has, it is indeed asking for 0.0.0.0's 
MAC addr for the next hop.


15:07:38.308758 00:15:17:ed:36:e5  ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: Request who-has 0.0.0.0 tell 0.0.0.1, length 46
15:07:38.308764 00:30:48:94:88:21  00:15:17:ed:36:e5, ethertype ARP 
(0x0806), length 42: Reply 0.0.0.0 is-at 00:30:48:94:88:21, length 28


---Mike



Tracing from here (cableone cable modem) to the outside world, I end 
up with the following at the beginning of my traceroute.


 1  192.168.1.1 (192.168.1.1)  2.759 ms  0.803 ms  0.769 ms
 2  0.0.0.0 (0.0.0.0)  10.462 ms  9.543 ms  8.043 ms
 3  192.168.32.65 (192.168.32.65)  9.984 ms  9.654 ms  9.570 ms
 4  te-4-4.car2.seattle1.level3.net (4.53.146.117)  25.960 
ms  21.798 ms  24.144 ms

  etc

0.0.0.0 as one of the hops.So, I pulled out LFT to make sure 
traceroute isn't going nuts.


Layer Four Traceroute (LFT) version 3.1
Using device en1, 192.168.1.101:53
TTL LFT trace to 207.70.17.213:80/tcp
 1  192.168.1.1 0.9/0.9ms
 2 /9.8/10.3ms
 3  192.168.32.65 9.7/8.3ms
 4  10.255.255.1 9.1/8.4ms
 5  te-4-4.car2.seattle1.level3.net (4.53.146.117) 29.0/20.2ms

Fun, no entry for hop 2, plus there's an extra hop at #4.  Lets use verbose.

Layer Four Traceroute (LFT) version 3.1 ... (verbosity level 2)
Using device en1, 192.168.1.101:53
SENT TCP  TTL=1 SEQ=648736948 FLAGS=0x2 ( SYN )
SENT TCP  TTL=2 SEQ=648736949 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=648736948 SRC=192.168.1.1 PTTL=1 PSEQ=648736948
SENT TCP  TTL=3 SEQ=648736950 FLAGS=0x2 ( SYN )
SENT TCP  TTL=4 SEQ=648736951 FLAGS=0x2 ( SYN )
SENT TCP  TTL=5 SEQ=648736952 FLAGS=0x2 ( SYN )
SENT TCP  TTL=6 SEQ=648736953 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=648736949 SRC=0.0.0.0 PTTL=2 PSEQ=648736949
SENT TCP  TTL=7 SEQ=648736954 FLAGS=0x2 ( SYN )
RCVD ICMP SEQ=648736950 SRC=192.168.32.65 PTTL=3 PSEQ=648736950
RCVD ICMP SEQ=648736951 SRC=10.255.255.1 PTTL=4 PSEQ=648736951
RCVD ICMP SEQ=648736953 SRC=4.68.105.30 PTTL=6 PSEQ=648736953


Am I going nuts, or is something really messed up somewhere upstream 
from the cable modem?  To quote someone from IRC who's just as 
confused, the null route just talked to me.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

Re: Did your BGP crash today?

[Mike Tancsa]

At 12:40 PM 8/30/2010, Kevin Oberman wrote:


This only way they could have caught this one was to have tested to a
CRS which had another router to which it was announcing the attribute in
a mal-formed packet. Worse, the resets should just keep happening as the
CRS would still have the route with the unknown attribute which would
just generate another malformed update to cause the session to reset
again.

While it may be possible to recover from something like this, it sure
would not be easy.



We experienced something like this a year ago on a couple of quagga 
boxes. At least we had source code to go through and resources to 
make use of that source code to find the problem and implement a 
quick work around.  Its for situations like this, debugging logging 
is ohhh so important.


What did people do in this case to identify the issue ?  Did you just 
pass it off to your vendor ? or did anyone try to diagnose it locally 
?  If so, what did you do ?



---Mike



--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

Any RIM / blackberry folks around ?

[Mike Tancsa]

Trying to open a ticket with Rogers but they say nothing is 
wrong.  Seems to be some DNS issue at RIM?  Their MX handlers are 
rejecting mail saying the sending domain does not exist...



0[marble]# host -tmx rogers.blackberry.net
rogers.blackberry.net mail is handled by 10 mx01.bis.na.blackberry.com.
rogers.blackberry.net mail is handled by 10 mx02.bis.na.blackberry.com.
rogers.blackberry.net mail is handled by 10 mx03.bis.na.blackberry.com.
rogers.blackberry.net mail is handled by 10 mx04.bis.na.blackberry.com.
0[marble]# telnet mx01.bis.na.blackberry.com 25
Trying 216.9.248.32...
Connected to mx01.bis.na.blackberry.com.
Escape character is '^]'.
220 as64.bis.na.blackberry.com ESMTP
HELO marble.sentex.ca
250 as64.bis.na.blackberry.com
MAIL From: postmas...@rim.com
451 #4.1.8 Domain of sender address postmas...@rim.com does not resolve
MAIL From: postmas...@rogers.com
451 #4.1.8 Domain of sender address postmas...@rogers.com does not resolve
421 Exceeded allowable connection time, disconnecting.
Connection closed by foreign host.
1[marble]#

0[marble]# host -tmx telus.blackberry.net
telus.blackberry.net mail is handled by 10 mx01.bis.na.blackberry.com.
telus.blackberry.net mail is handled by 10 mx02.bis.na.blackberry.com.
telus.blackberry.net mail is handled by 10 mx03.bis.na.blackberry.com.
telus.blackberry.net mail is handled by 10 mx04.bis.na.blackberry.com.
0[marble]# telnet mx01.bis.na.blackberry.com 25
Trying 216.9.248.32...
Connected to mx01.bis.na.blackberry.com.
Escape character is '^]'.
220 as18.bis.na.blackberry.com ESMTP
HELO marble.sentex.ca
250 as18.bis.na.blackberry.com
MAIL From: postmas...@blackberry.net
250 sender postmas...@blackberry.net ok
QUIT
221 as18.bis.na.blackberry.com
Connection closed by foreign host.
1[marble]# telnet mx01.bis.na.blackberry.com 25
Trying 216.9.248.32...
Connected to mx01.bis.na.blackberry.com.
Escape character is '^]'.
220 as08.bis.na.blackberry.com ESMTP
HELO marble.sentex.ca
250 as08.bis.na.blackberry.com
MAIL From: postmas...@telus.com
451 #4.1.8 Domain of sender address postmas...@telus.com does not resolve




Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

Re: cisco.com (back now)

[Mike Tancsa]

I see it now via

6453 7132 109
174 1239 109

---Mike





Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

Re: Cogent input

[Mike Tancsa]

At 10:01 AM 6/11/2009, Andrew Mulholland wrote:


We didn't have such problems.



Had nx1Gig from them.

On the few occasions where we had some slight issues, I was happy to
be able to get through to some one useful on the phone quickly, and
not play pass the parcel with call centre operatives.



This matches our experience as well. When there are issues, they are 
EASY to get a hold of and the people who answer the phone clueful and 
dedicated to dealing with IP issues, not can I help you with your 
long distance bill Also, they are pretty good about keeping us 
informed about maintenance issues. I would not use them as a sole 
provider (why run your own AS if you only have one transit provider?) 
but certainly I am happy keeping them in the mix to date.


We havent seen the same level of issues as some people in YYZ have 
seen, but I think that seems to be more on their 100Mb connections 
for some reason. On the gig service we are on, they are fairly 
reliable.  Not quite as good as TATA/Teleglobe has been for us however.


---Mike 

Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ?

[Mike Tancsa]

At 12:19 AM 4/10/2009, Rubens Kuhl wrote:

On shared media like radio access, every unwanted packet means less
performance you will get out of the network.
This can be done by NAT,
stateful filtering with public IPs or stateless filtering with public
IPs; the advantage of doing NAT is making it easier for the end-point
software to know that (two ways: noticing your local IP address is
from RFC1918 space, or connecting to a server that tells your IP in
order to compare it to the local address).

As such, GPRS, EDGE, EVDO, HSPA, LTE and Mobile WiMAX services have
good reasons to use NAT, and most do.


Speaking of unwanted traffic, I was quite surprised how much unwanted 
traffic I see on my RFC 1918 space thats given out by one of the 
Canadian telcos-- i.e. this is behind the giant natting firewalls


Blocking all inbound traffic and logging to pflog (pcap format)

Its full of cruft like this

0[i7]# tcpdump -nr /var/log/pflog | head -2
reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)
16:01:09.899554 IP 10.141.184.158.2167  10.141.81.113.445: Flags 
[S], seq 2743613661, win 53760, options [mss 1360,nop,wscale 
3,nop,nop,TS[|tcp]
16:01:10.439516 IP 10.141.184.158.2167  10.141.81.113.445: Flags 
[S], seq 2743613661, win 53760, options [mss 1360,nop,wscale 
3,nop,nop,TS[|tcp]


Looking at the pflogs for the last 3 days of just port 445 and 135 
scans traffic as well as the odd ping packet


1[i7]# cat pflo* | tcpdump -nr - -w /tmp/scan.pcap port 445 or port 135 or icmp
reading from file -, link-type PFLOG (OpenBSD pflog file)
tcpdump: pcap_loop: bogus savefile header
1[i7]# tcpstat -r /tmp/scan.pcap -a
Bytes/sec   =  0.4  B
Bytes/minute= 26.2  B
Bytes/hour  =  1.5 KB
Bytes/day   = 36.8 KB
Bytes/month =  1.1 MB
0[i7]#

Hmmm... considering some plans start at 1MB per month

---Mike 

web problems ssl issues

[Mike Tancsa]

Not sure if others are running into this or not, but we had a few 
vague support calls come in at once about browser 'ssl problems' and 
some issues with some websites 'taking forever to come up'...  It 
looks like the common problem is bringing up pages that have


src=https://siteseal.thawte.com/cgi/server/thawte_seal_generator.exe;

embedded in the web page the end user goes to.

Depending on how the page is written, it can seem (to the end user 
anyways) as if the page is taking for ever to come up. The browser is 
blocking on talking to the site seal server.



e.g. from the first syn, it was almost 25 seconds before the 
verisign/thawte server responded.


10:37:18.894068 IP 199.212.134.18.65064  65.205.248.240.443: S 
2515327385:2515327385(0) win 64240 mss 1460,nop,wscale 0,nop,nop,sackOK
10:37:21.860159 IP 199.212.134.18.65064  65.205.248.240.443: S 
2515327385:2515327385(0) win 64240 mss 1460,nop,wscale 0,nop,nop,sackOK
10:37:27.794374 IP 199.212.134.18.65064  65.205.248.240.443: S 
2515327385:2515327385(0) win 64240 mss 1460,nop,wscale 0,nop,nop,sackOK
10:37:39.865205 IP 199.212.134.18.62217  65.205.248.242.443: S 
3464052443:3464052443(0) win 64240 mss 1460,nop,wscale 0,nop,nop,sackOK
10:37:42.881109 IP 199.212.134.18.62217  65.205.248.242.443: S 
3464052443:3464052443(0) win 64240 mss 1460,nop,wscale 0,nop,nop,sackOK
10:37:42.961994 IP 65.205.248.242.443  199.212.134.18.62217: S 
3993252659:3993252659(0) ack 3464052444 win 5840 mss 
1460,nop,nop,sackOK,nop,wscale 2

10:37:42.962311 IP 199.212.134.18.62217  65.205.248.242.443: . ack 1 win 64240
10:37:42.962799 IP 199.212.134.18.62217  65.205.248.242.443: P 
1:103(102) ack 1 win 64240
10:37:43.035470 IP 65.205.248.242.443  199.212.134.18.62217: . ack 
103 win 1460
10:37:43.037779 IP 65.205.248.242.443  199.212.134.18.62217: . 
1:1461(1460) ack 103 win 1460
10:37:43.041639 IP 65.205.248.242.443  199.212.134.18.62217: . 
1461:2921(1460) ack 103 win 1460
10:37:43.042292 IP 199.212.134.18.62217  65.205.248.242.443: . ack 
2921 win 64240
10:37:43.118203 IP 65.205.248.242.443  199.212.134.18.62217: P 
2921:3967(1046) ack 103 win 1460
10:37:43.119345 IP 199.212.134.18.62217  65.205.248.242.443: P 
103:285(182) ack 3967 win 63194


network connectivity to 65.205.248.0/24 is fine for me.  It looks to 
be at the application layer at verisign ?


Just a heads up in case your helpdesk runs into this issue as well as 
it seems to be a rather obscure problem that sent us on a wild goose 
chase at first.  Some browsers deal with it differently. on IE, most 
of the page does not display until the seal comes up or times out.


---Mike


Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

Re: web problems ssl issues

[Mike Tancsa]

At 02:32 PM 3/5/2009, Christopher Morrow wrote:


Perhaps Thawte/VS is experiencing some LB or load issues?


If any verisign folks are around, it would make life a lot easier if 
an RST was sent instead of timing out like it is/was


---Mike 

RE: Yahoo DNS broken?

[Mike Tancsa]

At 03:40 PM 12/3/2008, Mills, Charles wrote:

Their other pages (finance.yahoo.com) and such seem to resolve ok.

Wondering if it isn't part of a bigger problem because I got a complaint
that many sites
Were unreachable for a bit.



www.yahoo.com seems to be a CNAME for wa1.b.yahoo.com and delegated to ...

;; Received 201 bytes from 192.41.162.30#53(L.GTLD-SERVERS.NET) in 39 ms

www.yahoo.com.  300 IN  CNAME   www.wa1.b.yahoo.com.
wa1.b.yahoo.com.300 IN  NS  yf1.yahoo.com.
wa1.b.yahoo.com.300 IN  NS  yf2.yahoo.com.
;; Received 123 bytes from 68.180.131.16#53(ns1.yahoo.com) in 27 ms


% host yf1.yahoo.com
yf1.yahoo.com has address 68.142.254.15

Neither yf1.yahoo.com nor yf2 are responding to queries for me, but I 
can reach them


0[granite]% time host wa1.b.yahoo.com 68.142.254.15
;; connection timed out; no servers could be reached
0.002u 0.000s 0:10.00 0.0%  0+0k 0+0io 0pf+0w
1[granite]%

% ping -c 1 yf1.yahoo.com
PING yf1.yahoo.com (68.142.254.15): 56 data bytes
64 bytes from 68.142.254.15: icmp_seq=0 ttl=56 time=28.282 ms

--- yf1.yahoo.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.282/28.282/28.282/0.000 ms

---Mike 

Re: Querstions about COGENT and their services...

[Mike Tancsa]

At 12:10 PM 6/3/2008, David Coulson wrote:
the cheapest, that's for sure. I've not heard anything about them in 
the last couple of months, but the last year has been filled with 
almost monthly service outages or congestion.



They are also one of the biggest providers... Proportionally 
speaking, if they had the same percentage of failures as a provider 
10% of their size, it would appear Cogent is worse as there would 
be more reports.  Also, in my experience, I find Cogent pretty good 
about admitting to outages, even if we didnt notice it.  Some 
providers on the other hand do everything possible to hide any issues...


Cogent's pricing in Canada is not that far off from a number of other 
providers I could choose from so to say you get what you pay for 
misses a bit of detail.  They are not the cheapest, but in that price 
range, I like the service they offer and have found them a relatively 
reliable provider.  There are other premiere / Tier 1 providers 
that I found gave worse service, had billing that would drive my AP 
people crazy and were far more difficult to deal with from a trouble 
ticket perspective.



---Mike 

Re: Power/temperature monitoring

[Mike Tancsa]

At 10:58 AM 5/30/2008, Frank Bulk wrote:


Required:
- temperature sensor
- 110 VAC power monitoring (on/off, not necessarily current)
- Ethernet interface (at least SNMP, Web GUI and


We have been using Uptime Devices.  Our units have room for 3 
sensors (we have 2 temp and one for humidity).  Web, SNMP, ethernet, 
external AC power blob. Its a fairly small form factor and it has 
been reliable for us over the years.  Alerts work as expected and 
havent had any false positives either over the years.


---Mike