Fw: new message
Hey! New message, please read <http://levittownfootdoctor.com/forward.php?lhnze> Tim Peiffer
Fw: new message
Hey! New message, please read <http://t4tdeutsch.org/street.php?h8spi> Tim Peiffer
Fw: new message
Hey! New message, please read <http://prestigeimagegroup.com/very.php?hfy> Tim Peiffer
Re: Minnesota to block online gambling sites?
Not withstanding the legality of such an order, how would one operationally enforce that order? Does this order force carriers into transparent proxy so that L7 filtering can be done? Is the carrier also required to go through geolocator matching any given IP address with 'Minnesota' so that the filtering can be selectively applied? Tim Peiffer Network Support Engineer OIT / Networking and Telecommunications Services University of Minnesota / NorthernLights GigaPOP On Sat, May 2, 2009 at 9:34 AM, Ken Gilmour wrote: For anyone who cares, IMEGA released the letter from the state of Minnesota: http://www.imega.org/wp-content/uploads/2009/05/ab001dd4.pdf 2009/4/29 Ken Gilmour : Hi there, I am just wondering if anyone knows any more about the attempt by Minnesota to block online gambling companies other than what's publicly available (e.g. http://www.gambling911.com/gambling-news/minnesota-regulators-try-block-access-gambing-sites-042909.html)? Such as a list or the letter to the providers? Thank you! Ken -- Tim Peiffer Network Support Engineer Office of Information Technology University of Minnesota/NorthernLights GigaPOP
Re: Potential Prefix Hijack
Mark Tinka 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: All 19 of my prefixes for AS57, AS217 and AS1998 are being hijacked by the same ASN. I sent a note to the ASN contact [EMAIL PROTECTED] I can't seem to contact lacnic for more than a few queries without being blacked out. Tim Peiffer Network Support Engineer Office of Information Technology University of Minnesota/NorthernLights GigaPOP % Joint Whois - whois.lacnic.net % This server accepts single ASN, IPv4 or IPv6 queries % LACNIC resource: whois.lacnic.net % Copyright LACNIC lacnic.net % The data below is provided for information purposes % and to assist persons in obtaining information about or % related to AS and IP numbers registrations % By submitting a whois query, you agree to use this data % only for lawful purposes. % 2008-11-11 00:51:09 (BRST -02:00) aut-num: AS16735 owner: Companhia de Telecomunicacoes do Brasil Central ownerid: BR-CTBC1-LACNIC responsible: Adriana Maria Rocha Paula address: Av Jo�o Pinheiro, 620, Centro address: 38400-126 - Uberl�ndia - MG country: BR phone: +34 3256 2575 [2575] owner-c: AMP routing-c: AMP abuse-c: AMP created: 2605 changed: 20040415 nic-hdl: AMP person: Adriana Maria Rocha Paula e-mail: [EMAIL PROTECTED] address: Rua Jos� Alves Garcia, 415, address: 38400710 - Uberl�ndia - country: BR phone: +34 3256 2575 [2575] created: 20040628 changed: 20040628 % whois.lacnic.net accepts only direct match queries. % Types of queries are: POCs, ownerid, CIDR blocks, IP % and AS numbers. 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: Possible explanations for a large hop in latency
We had a similar situation going from Minneapolis to Kansas City via Chicago. Normal latency from Minneapolis to Chicago via Level3 MPLS network is about 14msec RTT. When the the circuit from Minneapolis to Chicago went out for one reason or another, our MPLS link went from Minneapolis to Tulsa, to Dallas, and then to Chicago.. That added a little latency in the path from Minneapolis to Chicago.. We didn't need to exceed the SLA in order to cry foul. They didn't intentionally create an inefficient path.. The problem was recognized and fixed the same day. Latency on an MPLS circuit is the cumulative latency on the Label Switch Path, and a number of the hops are invisible. The latency per hop is still the same... you just can't see that your traffic is travelling to say Denver or Dallas. Tim Peiffer Network Support Engineer Networking and Telecommunications Services University of Minnesota/NorthernLights GigaPOP Frank Bulk - iNAME wrote: Thanks for the added information. Even if their MPLS path went from the midwest (where I'm located) to San Francisco and then back to St. Louis (where 12.122.112.22 appears to be), I don't think that accounts for a 70 msec jump in traffic. And I don't think they would (intentionally) create such an inefficient MPLS path. Someone off-list told me they tried to trace to 12.88.71.13, but once they hit an AT&T router their ICMP traffic appeared to be blocked. Frank -Original Message- From: John T. Yocum [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 8:09 PM To: [EMAIL PROTECTED] Cc: nanog list Subject: Re: Possible explanations for a large hop in latency The explanation I got, was that the latency seen at the first hop was actually a reply from the last hop in the path across their MPLS network. Hence, all the following hops had very similar latency. Personally, I thought it was rather strange for them to do that. And, I've never seen that occur on any other network. Perhaps someone from ATT would like to chime in. --John Frank Bulk - iNAME wrote: Did that satisfy you? I guess with MPLS they could tag the traffic and send it around the country twice and I wouldn't see it at L3. Frank -Original Message- From: John T. Yocum [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 7:04 PM To: [EMAIL PROTECTED] Cc: nanog list Subject: Re: Possible explanations for a large hop in latency When I asked ATT about the sudden latency jump I see in traceroutes, they told me it was due to how their MPLS network is setup. --John Frank Bulk wrote: Our upstream provider has a connection to AT&T (12.88.71.13) where I relatively consistently measure with a RTT of 15 msec, but the next hop (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending that traffic over a cable modem or to Europe and back, I can't see a reason why there is a consistent ~70 msec jump in RTT. Hops farther along the route are just a few msec more each hop, so it doesn't appear that 12.122.112.22 has some kind of ICMP rate-limiting. Is this a real performance issue, or is there some logical explanation? Frank
Re: Single IP routing problems through Level3
Matt Palmer wrote: We're seeing some really weird issues with connections that go through / to Level3 IP space. Basically, certain "pairs" of IPs (particular L3 IPs coupled with particular IPs of ours) have dodgy/nonexistent connectivity, but if you change the IP at either end everything's hunky dory. I've sniffed (from both ends) pings going from a host in L3 space to our end and seen the pings arrive at our end and head back in the direction of L3, but they never get to their destination. Traceroutes from L3 stop at the next-to-last hop, while traceroutes back get to the hop before L3 space and stop. All of this behaviour is source/dest *pair* specific -- if I ping/traceroute from another address (in the same netblock as the problematic IP, so all the same equipment is involved) at either end, or to another address (again, same netblock) at either end, it all works again. I've got two questions: 1) Has anyone else seen similar behaviour from L3 (or other providers, even), so I know I'm not going mad? 2) What sort of configuration problem or software bug would cause this sort of problem to occur? If it was an IP blacklist (or even a block routing issue) anywhere along the line, surely it wouldn't be sensitive to changing the other end's address to another one in the same /24? Any insight/anecdotes/etc would be greatly appreciated, as it's starting to do my head in. Just knowing I'm not alone with this insanity would be nice at this point. If it makes any difference, the blocks I'm working from at my end are Internap, in 74.201.254.0/23 (we don't have all of it, just most of it), while the far end is 8.12.35.0/24. - Matt We commonly see this sort of problem with Layer2 or Layer3 bonded etherchannel (LACP also). One member of the channel is failing for one reason or another and dropping traffic. The channel is really not a load balance mechanism, but is a frame distribution mechanism. The distribution of frames uses the source and destination IP addresses to hash out to a particular channel member, and that distribution provides a rough balance. The problems noted affect traffic in one direction differently as it is likely assymetric across the channel. Only traffic across the ailing member will be impacted. The above can present itself anywhere in the path if channeling is used. Regards, Tim Peiffer Networking and Telecommunications Services University of Minnesota/NorthernLights GigaPOP
