Giganews/AS30094 Contact
Hello, Can someone from Giganews/AS30094 please contact me off-list? Thanks Regards, - Carlos Friacas See: Network Services Area www.fccn.pt FCT - Fundacao para a Ciencia e a Tecnologia www.fct.pt FCCN Unit www.geant.net Av. do Brasil, 101, 1700-066 Lisboa, Portugal, Europe www.gigapix.pt Tel:+351 218440100 NOC:+351 218440101 Fax:+351 218472167 www.6deploy.eu - Internet is just routes (550752/22735), naming (billions) ... people!
Problem reaching AS32
Hi, AS1930 is again feeling reachability issues, now with AS32. (there was a thread last week about wikipedia reachability also reported from our side -- there was nothing wrong within our network) We are now having problems reaching AS32 in California. Traceroute stops well away from our (direct) transit providers. I've already tried to push packets towards the two AS32's transit providers i see (AS46749 and AS2153) and i can't get through to AS32. Is it possible this has something to do with the previous thread (Century Link outage)? (i'm in Europe, i know very little about US networks) I've also tried to send e-mail to n...@cenic.org, but both their MXs are not reachable either... :-( Other local commercial providers seem to be able to reach AS32, so there should be something in the way against AS1930's prefixes. Thanks. Regards, Carlos Friaças
Re: Problem reaching AS32
It's solved now! :-)) Thanks to CENIC's NOC. Regards, Carlos On Tue, 7 May 2013, Carlos Friacas wrote: Hi, AS1930 is again feeling reachability issues, now with AS32. (there was a thread last week about wikipedia reachability also reported from our side -- there was nothing wrong within our network) We are now having problems reaching AS32 in California. Traceroute stops well away from our (direct) transit providers. I've already tried to push packets towards the two AS32's transit providers i see (AS46749 and AS2153) and i can't get through to AS32. Is it possible this has something to do with the previous thread (Century Link outage)? (i'm in Europe, i know very little about US networks) I've also tried to send e-mail to n...@cenic.org, but both their MXs are not reachable either... :-( Other local commercial providers seem to be able to reach AS32, so there should be something in the way against AS1930's prefixes. Thanks. Regards, Carlos Friaças
Reachability problem with AS8388 [194.63.246.0/23]
Hello, Does anyone has reachability issues with AS8388? It seems i'm unable to get packets back from 194.63.246.0/23, but only if the source is my 193.136.0.0/15 block, at AS1930. It works well from my other netblocks. I'm basically performing a (non-recursive) DNS query to DNS servers within 194.63.246.0/23. I've been trying to involve upstream providers to take a deeper look at this problem, but i haven't had any luck so far. I can't even get a traceroute back to my network from anyone at AS8388. Any suggestions? Best Regards, Carlos Friaças
Re: Reachability problem with AS8388 [194.63.246.0/23]
On Tue, 12 Feb 2013, Grant Ridder wrote: Hello, Can you provide the traceroute? Yes. Please see below. We were already told they drop icmp packets making the traceroute useless beyond 62.38.94.98 I strongly suspect there is an issue only on the return path, but i would need a traceroute originated at the other end so i can be sure and understand where the packets (tcp udp) are exactly being dropped. Regards, Carlos Friaças # traceroute 194.63.247.20 traceroute to 194.63.247.20 (194.63.247.20), 30 hops max, 60 byte packets 1 193.136.2.29 (193.136.2.29) 0.278 ms 0.256 ms 0.241 ms 2 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) 0.294 ms 0.282 ms 0.269 ms 3 fccn.mx2.lis.pt.geant.net (62.40.124.97) 0.332 ms 0.320 ms 0.337 ms 4 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) 12.650 ms 12.725 ms 12.641 ms 5 as2.rt1.gen.ch.geant2.net (62.40.112.25) 34.808 ms 34.791 ms 34.863 ms 6 ae3.rt1.fra.de.geant2.net (62.40.112.161) 43.062 ms 43.022 ms 43.010 ms 7 te0-7-0-5.ccr22.fra03.atlas.cogentco.com (149.6.42.73) 43.724 ms 43.808 ms 43.889 ms 8 te0-0-0-2.ccr22.ams03.atlas.cogentco.com (130.117.3.89) 50.106 ms te0-2-0-2.ccr22.ams03.atlas.cogentco.com (130.117.1.65) 50.240 ms te0-0-0-2.ccr22.ams03.atlas.cogentco.com (130.117.3.89) 50.114 ms 9 te0-2-0-0.ccr22.lon13.atlas.cogentco.com (130.117.1.170) 55.518 ms te0-0-0-0.ccr22.lon13.atlas.cogentco.com (130.117.1.225) 55.453 ms te0-5-0-0.ccr22.lon13.atlas.cogentco.com (154.54.61.154) 55.689 ms 10 te0-1-0-0.ccr22.lon01.atlas.cogentco.com (154.54.57.178) 55.570 ms te0-4-0-0.ccr22.lon01.atlas.cogentco.com (130.117.0.205) 55.452 ms te0-2-0-0.ccr22.lon01.atlas.cogentco.com (154.54.57.174) 55.481 ms 11 te2-1.mag02.lon01.atlas.cogentco.com (154.54.74.114) 55.439 ms 55.356 ms 55.342 ms 12 149.6.187.234 (149.6.187.234) 55.370 ms 55.451 ms 55.493 ms 13 POS00-07-00-03.med00.brd.hol.gr (62.38.36.13) 127.954 ms * 127.106 ms 14 tengigaeth00-01-00-02.med00.ccr.hol.gr (62.38.97.29) 136.321 ms * * 15 tengigaeth00-07-00-00.med00.csr.hol.gr (62.38.94.98) 125.525 ms 125.519 ms 125.584 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -Grant On Tue, Feb 12, 2013 at 6:01 AM, Carlos Friacas cfria...@fccn.pt wrote: Hello, Does anyone has reachability issues with AS8388? It seems i'm unable to get packets back from 194.63.246.0/23, but only if the source is my 193.136.0.0/15 block, at AS1930. It works well from my other netblocks. I'm basically performing a (non-recursive) DNS query to DNS servers within 194.63.246.0/23. I've been trying to involve upstream providers to take a deeper look at this problem, but i haven't had any luck so far. I can't even get a traceroute back to my network from anyone at AS8388. Any suggestions? Best Regards, Carlos Friaças
Re: IPv6: numbering of point-to-point-links
Hi Lasse, We use /64s. ::1 for one end, ::2 for the second end. Using /126s or /127s (or even /120s) is a result of going with the v4 mindset of conservation. With a /32 you have 65536 /48s, and then 65536 /64s. Guess you only need 1 /48 for all the p-to-p links, no? Regards, Carlos (portuguese NREN, 6deploy.eu project partner) On Mon, 24 Jan 2011, Lasse Jarlskov wrote: Hi all. While reading up on IPv6, I've seen numerous places that subnets are now all /64. I have even read that subnets defined as /127 are considered harmful. However while implementing IPv6 in our network, I've encountered several of our peering partners using /127 or /126 for point-to-point links. What is the Best Current Practice for this - if there is any? Would you recommend me to use /64, /126 or /127? What are the pros and cons? -- Best regards, Lasse Jarlskov Systems architect - IP Telenor DK
Re: Depeering as an IPv6 driver (was: Re: Sprint / Cogent)
On Thu, 30 Oct 2008, Brandon Galbraith wrote: On 10/30/08, Jared Mauch [EMAIL PROTECTED] wrote: On Oct 30, 2008, at 6:55 PM, Deepak Jain wrote: I wonder if judicious use of 6to4 and Teredo would allow an IPv6 (single homed) user to access now missing parts of the Internet. Me thinks, yes. So would some CGN (Carrier Grade Nat anyone) too. Last I knew Cogent wasn't doing any IPv6.. has that changed? - Jared Not that I know of. We tried to get IPv6 transit from Cogent several months ago (we already have IPv4 transit), and were told it's not available yet. Did they provide you with a roadmap ? :-) ./Carlos -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: [EMAIL PROTECTED]
Re: IPv6 Wow
On Mon, 13 Oct 2008, Mikael Abrahamsson wrote: On Sun, 12 Oct 2008, Daniel Senie wrote: I do wonder whether where the Vista machines on public IPs really are. I also have to wonder if performance is really better when those users are routed over 6to4 in Europe from, say California, or whether they'd actually get better performance if they stuck in a NAT box, resulting in their using IPv4 instead? I'd say it's very rare where IPv6 will give you better performance than IPv4 right now. Rare = Absolutely Yes. Impossible = No :-) Regarding where they are, I'd say all over the place. It's very common in my regional market to hand out one or more public IPs, and if the customer doesn't put their own NAT box there, then their Vista computer(s) will have public IPs and will use 6to4. Regarding 6to4 or Teredo, I've done some testing of my own and the statelessness of 6to4 makes it avoid some of the session setup/NAT travesal magic of Teredo that slows Teredo down. I'd much rather see the NAT boxes do 6to4 and run native on their local LAN segment, than having end hosts do Teredo to get thru the NAT. It'll give the end user a better IPv6 experience. Fully agree. Unfortunately not every NATbox/cheap-consumer-router is happy to pass on 6to4 packets to its next hop :-( -- Mikael Abrahamssonemail: [EMAIL PROTECTED] Cheers, - Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.6deploy.org Av. do Brasil, n.101 www.ipv6.eu 1700-066 Lisboa, Portugal, Europe Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt - The end is near see http://ipv4.potaroo.net Internet is just routes (282391/1511), naming (billions) and... people! Esta mensagem foi enviada de: / This message was sent from: 2001:690:2080:8004:250:daff:fe3b:2830 Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato. Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received due to any error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately.
