Re: IPv6 transits (Was: Cogent input)
i can confirm that Level(3), at least in Madrid area is only offering tunneled IPv6. --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Robert Blayzor rblayzor.b...@inoc.net wrote: On Jun 14, 2009, at 6:04 PM, Jeroen Massar wrote: For people trying to find the list, check: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit Since when has Level3 offered native IPv6? I nag our rep SE's just about every month on when and right now AFAIK it's still just tunnels. -- Robert Blayzor, BOFH INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/
Re: delays to google
maybe is a good time to enable IPv6 :-) We noticed issues on IPv4, but IPv6 was working perfectly (we are on Google IPv6 program)... I was able to access google all the times, as i was using IPv6 as preferred transport IPv4: traceroute to www.google.com (209.85.227.104), 30 hops max, 40 byte packets 1 ge130-1000m.cr2.lisboa.nfsi.pt (81.92.200.126) 0.159 ms 0.154 ms 0.148 ms 2 xe12-10GE.xmr1.Lisbon.as25137.net (81.92.201.10) 0.330 ms 0.408 ms 0.450 ms 3 if-3-1.core1.PV9-Lisbon.as6453.net (195.219.187.49) 0.238 ms 0.279 ms if-3-2.core1.PV9-Lisbon.as6453.net (195.219.186.9) 0.275 ms 4 if-12-0-0.mcore3.L78-London.as6453.net (195.219.144.5) 27.960 ms 27.993 ms 28.083 ms 5 if-1-0-0.mse1.LRT-London.as6453.net (195.219.144.2) 27.483 ms 27.225 ms 27.224 ms 6 if-13-0-0-3.mcore3.LDN-London.as6453.net (195.219.195.21) 34.298 ms 33.299 ms 33.242 ms 7 Vlan1254.icore1.LDN-London.as6453.net (195.219.195.90) 27.223 ms 27.219 ms 27.302 ms 8 xe-10-2-0-edge3.london1.level3.net (4.68.63.105) 27.444 ms 27.444 ms 27.437 ms 9 ae-11-51.car1.London1.Level3.net (4.69.139.66) 27.566 ms 27.673 ms ae-21-52.car1.London1.Level3.net (4.69.139.98) 27.656 ms 10 * * * 11 * * * 12 * 66.249.95.170 (66.249.95.170) 373.764 ms 72.14.232.134 (72.14.232.134) 387.434 ms 13 * * * 14 * (209.85.243.93) 403.618 ms * 15 wy-in-f104.google.com (209.85.227.104) 376.948 ms * * IPv6: traceroute to www.google.com (2001:4860:a004::68), 30 hops max, 40 byte packets 1 ge-1.Edge1.ip6.Lisbon.NFSi.pt (2001:b18::) 8.656 ms 8.692 ms 8.736 ms 2 2001:5a0:1500::1 (2001:5a0:1500::1) 0.585 ms^C r...@matrix:/var/log# traceroute6 www.google.com traceroute to www.google.com (2001:4860:a004::68), 30 hops max, 40 byte packets 1 ge-1.Edge1.ip6.Lisbon.NFSi.pt (2001:b18::) 0.133 ms 0.212 ms 0.209 ms 2 2001:5a0:1500::1 (2001:5a0:1500::1) 0.198 ms 2001:5a0:1500::11 (2001:5a0:1500::11) 0.192 ms * 3 2001:5a0:1500::1a (2001:5a0:1500::1a) 26.925 ms * * 4 2001:5a0:c00:100::e (2001:5a0:c00:100::e) 36.672 ms * * 5 2001:5a0:200::5 (2001:5a0:200::5) 130.695 ms 130.838 ms 130.826 ms 6 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 42.306 ms 41.953 ms 42.176 ms 7 * * * 8 * * * 9 ww-in-x68.google.com (2001:4860:a004::68) 42.858 ms 45.349 ms 44.190 ms Those traceroutes have been taken 1 hour ago, orso, but now everything looks ok in both protocols. cheers, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/
Re: IXP
- kris foster kris.fos...@gmail.com wrote: painfully, with multiple circuits into the IX :) I'm not advocating Paul's suggestion at all here Kris Totally agree with you Kris. For the IX scenario (or at least looking in a Public way) it seems Another Terrible Mistake to me. IMHO, when you are in a Public IX, you usually want to reach everyone's network without hassling around. Then it is your problem, and yours peer problem if we peer or not. When you overload a certain port at a Public IX, you rather upgrade that Port, or, Move particular bit pushers and movers for a Private Peering port (if it really makes technical and economical sense). I don't see how this idea that came out there could benefit the operational daily works (For IX, For IX Customers) , also, it would require work from the (usually) Neutral IX, when users need to connect ear other, which, will lead in more money to pay. (hey IX OPS.. we are company X and Z, and we signed a nice peering agreement.. can you please virtual patch us ?) Where is the neutrality here ? Time ? What if my equipment brokes at 3 AM and IX Ops need to change configs ? Ok, ones could say... it is automated... BUT.. what is the really security behind automation ? The portal is on the Wild Web, right ? This happens today on datacenters, with real cross connects, usually thru MMR's (Meet me Rooms).I don't want to have a Virtual Meet me Room, on Internet exchanges where i peer. This is my view. I might be wrong, but i don't care, as i am square as a rock. :-) I don't understand how can this new concept (or really old, considering ancient ATM peering and stuff), can be better, more secure, and cheaper for all. cheers, --nvieira
Re: downloading speed
link speed duplex mismatch ? --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - chandrashakher pawar learn.chan...@gmail.com wrote: Dear Group member, We are level one ISP. one of my customer is connected to fast ethernet. His link speed 100,000 kbps. while downloading any thing from net he downloading speed donot go above 200 kbps. While doing multiple download he get aroung 200 kbps in every window. But when he close all the windows no change in downloading speed is observed. our router is C12KPRP-K4P-M Please advise what could be the cause? -- Regards Chandrashakher Pawar IPNOC Customer Services Operations Tata communication AS6453 mobil + 91 9225633948 + 91 9324509268 learn.chan...@gmail.com
Re: Google Over IPV6
yup... and it is nice, adwords don't work pretty well (or at least on the GeoIP thingie), and i get less publicity to look at :-) --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Robert D. Scott rob...@ufl.edu wrote: http://www.google.com/intl/en/ipv6/ http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html Any one making use of Google IPV6? Robert D. Scott rob...@ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell
Re: anyone else seeing very long AS paths?
Hi, Anyone onlist knows the similar command (bgp maxas-limit NN) on Foundry XMR platform ? regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Jon Lewis jle...@lewis.org wrote: On Mon, 16 Feb 2009, John van Oppen wrote: Yep we saw the same, every customer with old IOS had their sessions die to us at the same time... That always makes for an interesting time when watching the NMS system... Is there a reason you don't use something like bgp maxas-limit NN on your transit sessions? We saw this too, but it stopped at our transit routers. There was actually another a few days ago. Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 39412 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625... Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868... -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Global Blackhole Service
In that way, Spamcop and other folks are DOS'ing for years aswell. And in fact, by denying things around, they are just scrubing and filtering, to make our day happier, avoiding huge masses of spam and useless crap. I don't see it the way you do. A project like this, like also spamcop, are great paths to take out the scum and undesired things from the net. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Randy Bush ra...@psg.com wrote: would this itself not be a dos path? randy
Re: Global Blackhole Service
Hi Suresh, But in the meanwhile, a decade later, it does not longer exist. At least, i can't reach that host, and i was unable to find working documentation on google of how about this project works, today. In fact, the first link that google gave out, says that this project is dead at least 2 years ago. http://www.dnsbl.com/2007/02/status-of-rblmapsvixcom-invalid-domain.html I think that we all have a real opportunity here for make something that can be useful to all. And, we are not talk of spam here, but, to mitigate time, money and patience consuming DDoS attacks, which often are easier to mitigate only at the Source and at the Destination, while at Destinatation, sink is the only viable solution that is out there today. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Suresh Ramasubramanian ops.li...@gmail.com wrote: On Fri, Feb 13, 2009 at 8:27 PM, Jens Ott - PlusServer AG j@plusserver.de wrote: - - What do you think about such service? - - Would you/your ASN participate in such a service? - - Do you see some kind of usefull feature in such a service? - - Do you have any comments? Ah. rbl.maps.vix.com from about a decade back when it was available as a bgp feed. But only for ddos sources. srs
Re: Global Blackhole Service
Ok, however, what i am talking about is a competelly diferent thing, and i think that my thoughts are alligned with Jens. We want to have a Sink-BGP-BL, based on Destination. Imagine, i as an ISP, host a particular server that is getting nn Gbps of DDoS attack. I null route it, and start advertising a /32 to my upstream providers with a community attached, for them to null route it at their network. However, the attacks continue going, on and on, often flooding internet exchange connections and so. A solution like this, widelly used, would prevent packets to leave their home network, mitigating with effective any kind of DDoS (or packet flooding). Obviously, we need a few people to build this (A Website, an organization), where when a new ISP connects is added to the system, a prefix list should be implemented, preventing that ISP to announce IP addresses that DON'T belong to him. The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, and those member ISP's, should apply route-maps or whatever they want, but, in the end they want to discard the traffic to those prefixes (ex: Null0 or /dev/null). This is a matter or getting enough people to kick this off, to build a website, to establish one or two route-servers and to give use to. Once again, i am interested on this, if others are aswell, let know. This should be a community-driven project. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Valdis Kletnieks valdis.kletni...@vt.edu wrote: How do you vet proposed new entries to make sure that some miscreant doesn't DoS a legitimate site by claiming it is in need of black-holing? Note that it's a different problem space than a bogon BGP feed or a spam-source BGP feed - if the Cymru guys take another 6 hours to do a proper paperwork and background check to verify a bogon, or if Paul and company take another day to verify something really *is* a cesspit of spam sources, it doesn't break the basic concept or usability of the feed. You usually don't *have* a similar luxury if you're trying to deal with a DDoS, because those are essentially a real-time issue. Oh, and cleaning up an entry in a timely fashion is also important, otherwise an attacker can launch a DDoS, get the target into the feed, and walk away...
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space
security by obscurity is not the way, everyone knows it. those guys will figure it out sooner or later (where later, might take ages). in the meanwhile, a lot have pseudo-secured networks thru triple-nat, quadruple-nat, multiple ipsec'd layered and so, and others live with the hammer in their suitcase for fixing things around when the clue is gone. often they forgot the neat webserver box that run's some strange software, which no one updates, and... in the end is the cheese hole around their network... but, in the other end, money talks, and bulls**t walks, so, we might be all wrong, and they might be right, who knows ? who cares anyway ? :-) --nvieira - John Osmon jos...@rigozsaurus.com wrote: It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) I know that some auditors want to hold people to that standard. I stopped working with the credit card people at that point...
Re: Shaping on a large scale
Check Ipoque solutions. http://www.ipoque.com/ regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Bruce Grobler br...@yoafrica.com wrote: Hi, Does anyone know of any Shaping appliances to shape customers based on IP, allow for a quota per IP and qos mechanisms like LLQ?, This is should be something that can sit in between two border router's and support a small ISP (2 customers), also an opensource solution would be great! Regards, Bruce
Re: Potential Prefix Hijack
That's not true, as not all our prefixes were hijacked nor leaked, since they were originating them. If they were leaking them you might be able to see further AS's on the AS-PATH, incluiding the legitimate AS for originating those prefixes. My point here is also about peers and upstreams to set properly filter or max-prefix settings to avoid those nasty things. Am i seeing things in a blur way ? or this is supposed to happen as wind flows ? regards, --- Nuno Vieira nfsi telecom, lda. [EMAIL PROTECTED] Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Raymond Dijkxhoorn [EMAIL PROTECTED] wrote: Hi! We were hijacked aswell, by 27664 16735 Our affected prefixes were: 94.46.0.0/16 194.88.142.0/23 194.11.23.0/24 82.102.0.0/18 195.246.238.0/23 194.107.127.0/24 81.92.192.0/19 193.227.238.0/23 We are trying to contact them in order to get some feedback, and some good explanation for this. The obviously were leaking full routing, are we all gonna annnounce 'my prefix was in there also?' Bye, Raymond.
Re: Potential Prefix Hijack
Howdy, We were hijacked aswell, by 27664 16735 Our affected prefixes were: 94.46.0.0/16 194.88.142.0/23 194.11.23.0/24 82.102.0.0/18 195.246.238.0/23 194.107.127.0/24 81.92.192.0/19 193.227.238.0/23 We are trying to contact them in order to get some feedback, and some good explanation for this. In the meanwhile, there are lots of evidence spread around (thanks to RIS RIPE, Routeviews, BGPmon and others) http://www.ris.ripe.net/dashboard/27664 http://www.ris.ripe.net/dashboard/16735 In the meanwhile we are sending notices to the Upstreams of those ASN's, in order for them to apply proper filtering to their downstream customers to avoid situations like this. On the List i was able to found: AS8167 - TELESC AS6762 - SEABONE AS12956 - TELEFONICA AS3549 - GLOBAL CROSSING AS17379 - Interlig I welcome others to do the same, in order to avoid replicas for this situation. Regards, --- Nuno Vieira nfsi telecom, lda. [EMAIL PROTECTED] Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Network Fortius [EMAIL PROTECTED] wrote: Same problems here, for AS26028 Stefan On Mon, Nov 10, 2008 at 8:54 PM, Mark Tinka [EMAIL PROTECTED]wrote: Hi all. Anyone know how we can contact AS16735 and their upstream AS27664. We think they are hijacking a number of our prefixes (AS24218- and AS17992-originated). Thanks BGPmon: e.g., Possible Prefix Hijack (Code: 11) 1 number of peer(s) detected this updates for your prefix 61.11.208.0/20: Update details: 2008-11-11 02:24 (UTC) 61.11.208.0/20 Announced by: AS16735 (Companhia de Telecomunicacoes do Brasil Central) Transit AS: 27664 (CTBC MultimÃdia) ASpath: 27664 16735 = RIPE's RIS BGPlay confirms the same, for about the last hour. E-mails to them won't get there (of course), so our NOC are contacting them via Gmail/Yahoo. All help appreciated. Cheers, Mark.
Re: rackmount managed PDUs
We use APANET powerswitches, and we are quite happy with them. 24 ports units, around 600 EUR per unit. www.apanet.pl --- Nuno Vieira nfsi telecom, lda. [EMAIL PROTECTED] Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Justin M. Streiner [EMAIL PROTECTED] wrote: As much as I hate to tear people away from the Intercage/Atrivo debacle and semi-tangential rants, I'll take one for the team and do it :) I have an opportunity coming up to rebuild an existing machine room space to an extent. It's not a total gut-and-refit, but I'll at least get to put in some new infrastructure. That said, I'd be interested in hearing about peoples' experiences with various rackmountable managed PDUs. I have some Tripp Lite PDUMH30NETs that work well and are reasonably priced, but they have a few quirks (no RS-232 console port, web interface seems to be a little shaky with Firefox, etc) that would become more annoying when scaled up to several rows of new rack footprints. I'm also open to using managed vertically mounted PDUs. The plan is for each footprint to have A and B feeds, so two PDUMH30NETs would take up 4U per footprint, which is a bit much... I don't need to worry about distributing DC power - just AC. This site will be lights-out most of the time, so robust remote management capabilities are a must. Any thoughts/insight are greatly appreciated. jms
Re: Teleglobe appears to be spam-source zombie network?
Try reach them at [EMAIL PROTECTED] cheers, --- Nuno Vieira nfsi telecom, lda. [EMAIL PROTECTED] Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Jo Rhett [EMAIL PROTECTED] wrote: We started getting a flood of autobot spam to our listed abuse mailbox about an hour ago out of Teleglobe. Trying to find someone to shut this down has found that 1. Teleglobe has no listed abuse contacts for any of their netblocks 2. The few of their records which have listed e-mail addresses all bounce 3. All listed phone numbers on any netblocks we can find are invalid Any chance that RIPE is more strigent than ARIN and would pull their netblocks until they fix this stuff? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
