August 2012 - Test - lists.nanog.org

Packets dropped due to ICMP off
by Jim Ray 09 Aug '12

09 Aug '12

Awe, man, don't laugh too hard. Turned out to be problem with Firefox. Safari on iPhone and IE on PC work. I learned something, too, and appreciate the input: tracert using ICMP is not valid test. Not everyone has ping enabled. So, what looks like packet loss at next hop is really ICMP turned off. Sent from my iPhone

2 1

UCSF Network Admin??
by Robert Glover 09 Aug '12

09 Aug '12

Hello, Is there anyone with clue from UCSF on-list? Or if someone knows how to put me in contact with them, that would be great. We are not able to query their DNS servers from our network. We've got users not able to access anything UCSF due to this. Thus far, their response has been to manually put DNS entries into our users hosts file, not actually fix the real issue. Thanks, -Robert

15 17

next hop packet loss
by Jim Ray 08 Aug '12

08 Aug '12

Good afternoon. I am a newbie to this group, and this post is my first post ever. A friend from another list recommended this group. I have a Time Warner Business Class connection and am unable to reach http://www.checkpoint.com to research product line I wish to carry. I did a trace route and confirmed packets are past my network, Time Warner network and onto next hop where they execute jump to nowhere instruction. Time Warner says it is off their network, and they can't help. I received no reply from above.net next hop. What is the best way to solve this type of problem? Here is the tracert just now (it has been failing for weeks): C:\Documents and Settings\jim.ray>tracert checkpoint.com Tracing route to checkpoint.com [216.200.241.66] over a maximum of 30 hops: 1 52 ms 28 ms 37 ms 10.129.96.1 2 10 ms 12 ms 16 ms ten13-0-0-238.rlghnca-rtr1.nc.rr.com [66.26.32.2 42] 3 16 ms 12 ms 12 ms ae19.rlghncpop-rtr1.southeast.rr.com [24.93.64.0 ] 4 19 ms 23 ms 24 ms 107.14.19.20 5 16 ms 19 ms 19 ms 107.14.19.133 6 28 ms 20 ms 19 ms xe-0-1-1.er2.iad10.us.above.net [64.125.12.61] 7 23 ms 19 ms 19 ms xe-2-0-0.cr2.dca2.us.above.net [64.125.31.209] 8 74 ms 49 ms 56 ms xe-0-2-0.cr2.iah1.us.above.net [64.125.28.50] 9 77 ms 79 ms 79 ms xe-0-3-0.cr2.lax112.us.above.net [64.125.30.50] 10 85 ms 86 ms 86 ms xe-1-0-0.cr2.sjc2.us.above.net [64.125.31.233] 11 84 ms 92 ms 86 ms xe-1-1-0.er2.sjc2.us.above.net [64.125.26.202] 12 86 ms 86 ms 105 ms 64.124.201.230.b709.above.net [64.124.201.230] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com <http://www.neuserivernetworks.com/> <http://www.neuserivernetworks.com/>

5 9

Re: Bell Canada outage?
by up＠3.am 08 Aug '12

08 Aug '12

> > Hi, > > .-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius > Jahandarie wrote: >> On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon >> <zachary.mcgibbon+nanog(a)gmail.com> wrote: >>> Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing >>> table is going nuts with Bell advertising a lot of routes they shouldn't be >> >> Bell leaked a full table. To add to the fun, it seems that TATA took >> the full table and releaked it. > > A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the > cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems > to have happened is that they leaked routes learned from VIDEOTRON to Bell. > > Based on BGP data I see that at 17:27 UTC AS46618 ( Dery Telecom Inc) > started to leak a 'full table', or at least a significant chunk of it to > its provider Bell AS577. > Bell propagated that to it's peers. Tata was one of the ones that > accepted all of that. > > I can see that Bell propagated at least 74,109 prefixes learned from > AS46618 to Tata. Tata selected 70,160 of those routes. Interesting. I have a server hosted on Bell Canada's network and I saw an outage of about 30 minutes today, but it ONLY affected connections from Verizon's network. This includes my own FIOS connection. I still could connect to the server through Comcast, Level 3 and XO with no problems. Traceroutes from my Verizon IP only got 2 hops, stopping at a philly router and traceroutes back to the same IP from that server got as far as NYC.

1 0

Bell Canada outage?
by Zachary McGibbon 08 Aug '12

08 Aug '12

Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing table is going nuts with Bell advertising a lot of routes they shouldn't be

11 16

IPTV, Multicast, and IPv6 Transition
by Tom Taylor 08 Aug '12

08 Aug '12

This may be way off in the future for some of you, or others may be past it. In support of possible work on IPv6 transition in the IETF MBONED Working Group, I'm looking for an indication of what use cases are realistic for operators who: -- deliver IPTV to their customers -- use multicast for the purpose, either now or in the near future -- are making the transition from IPv4 to IPv6. First question: does anyone anticipate a situation where you will have to translate multicast content from a IPv4-only source so it can be delivered to an IPv6-only receiver, or vice versa? Second question: the current official view is that dual stack is the sensible way to transition your network, and failing that, you can use Automatic Multicast Tunneling, an almost-ready Internet Draft available at http://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/ to tunnel multicast packets through a single-stack network when necessary. Do you consider your requirements adequately addressed by this view? People who really want to be helpful can comment on the problem statement and use cases documented in http://datatracker.ietf.org/doc/draft-ietf-mboned-v4v6-mcast-ps/ Thanks for your attention. Privacy will be respected if people want to reply privately. Tom Taylor Consultant

1 0

MXLogic outage
by Duane Toler 08 Aug '12

08 Aug '12

Probably old news by now, but MXLogic folks are having some major issues today and not reliably receiving inbound mail. Several of our customers are talking with MXLogic about it. FYI. -- Duane Toler detoler(a)gmail.com

3 3

raging bulls
by Eugen Leitl 08 Aug '12

08 Aug '12

http://www.wired.com/business/2012/08/ff_wallstreet_trading/all/ Some interesting, network-relevant content there (but for the neutrino and drone rubbish).

12 21

RE: raging bulls
by Naslund, Steve 08 Aug '12

08 Aug '12

Are there not mechanisms to handle replay attacks? There is also the minor matter of fraud and regulatory concerns. You might get away with it a few times but not often enough to avoid a potential death penalty of being disconnected. Steve -----Original Message----- From: Alexandre Snarskii [mailto:snar@snar.spb.ru] Sent: Wednesday, August 08, 2012 9:46 AM To: Naslund, Steve Cc: Alexandre Snarskii Subject: Re: raging bulls On Wed, Aug 08, 2012 at 09:08:18AM -0500, Naslund, Steve wrote: > Also, we are only talking about a delay long enough to satisfy the > longest circuit so you could not push your timestamp very far back and > would have to get the fake one done pretty quickly in order for it to > be worthwhile. The real question is could you fake a cryptographic > timestamp fast enough to actually gain time on the system. Possibly > but it would be a very tall order. Looks like replay attack works here: "attacker" can easily record encrypted timestamps and reuse them some milliseconds later, claiming "I had no knowledge on how market changed during this time, it's my provider had to re-route my traffic!!" > > Steve > > -----Original Message----- > From: Chu, Yi [NTK] [mailto:Yi.Chu@sprint.com] > Sent: Wednesday, August 08, 2012 9:01 AM > To: Naslund, Steve; nanog(a)nanog.org > Subject: RE: raging bulls > > What prevents someone to fake an earlier timestamp? Money can bend > light, sure can a few msec. > > yi > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund@medline.com] > Sent: Wednesday, August 08, 2012 9:53 AM > To: nanog(a)nanog.org > Subject: RE: raging bulls > > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. > It would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then > take them in order. They could certainly use less expensive > connections and ensure that international traders get a fair shake. > > Steven Naslund > > -- In theory, there is no difference between theory and practice. But, in practice, there is.

1 0

RE: raging bulls
by Ryan Malayter 08 Aug '12

08 Aug '12

"Naslund, Steve" <SNaslund () medline com> wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. It > would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then take > them in order. They could certainly use less expensive connections and > ensure that international traders get a fair shake. I can't see any incentive for any *influential* party involved (the big firms or the exchanges) to make the process "fair". The exchange gets more money for low-latency network access and expensive co-location. The moneyed firms with HFT capability of course do not want anyone else to have their advantage. Even governments don't want long-distance traders to have "fair" access, as that reduces the advantage of local tax-paying firms, thereby reducing tax revenue, jobs, etc. HFT is not just a US phenomenon; all major exchanges have basically the same sort of phenomenon. So UK-based trading firms with HFT setups very close to the FTSE exchanges have advantage over US-based firms that don't have HFT setups in London. -- RPM

1 0