Fw: new message
Hey! New message, please read <http://jitconsultancyzm.com/short.php?2ch6p> Cord MacLeod
Fw: new message
Hey! New message, please read <http://forum.onnet.com.vn/might.php?8eu> Cord MacLeod
Fw: new message
Hey! New message, please read <http://purefitnesslincoln.com/home.php?p> Cord MacLeod
Re: Layer 2 vs. Layer 3 to TOR
On Nov 13, 2009, at 4:14 AM, Matthew Walster wrote: 2009/11/12 David Coulson da...@davidcoulson.net You could route /32s within your L3 environment, or maybe even leverage something like VPLS - Not sure of any TOR-level switches that MPLS pseudowire a port into a VPLS cloud though. Just to let you know - the Juniper EX4200 series only support a single label stack, and RSVP not LDP - plus they have a restricted BGP table size, so VPLS is out of the question. If you wanted something to do this, it's called an MX series. The ex is a switch... l3, but still a switch.
Re: IPv6 Deployment for the LAN
On Oct 21, 2009, at 1:08 PM, Ray Soucy wrote: Without DHCPv6, SLAAC has no way to provide DNS (or other) configuration information, the fact that IPv6 was designed in a way where SLAAC could be used for addressing and DHCPv6 for other configuration is an example of how DHCPv6 is an integral component of IPv6. Didn't RFC 4339 cover most of this? http://tools.ietf.org/html/rfc4339
equinix is acquiring switch data
http://www.equinix.com/news/press/na/2009/news-5109/ Thought this was relevant.
Re: IPv6 Allocations
The tool is aware of the prefix length you insert. So instead of /32, put /64 or /48 etc. On Oct 19, 2009, at 6:22 PM, Matthew Petach wrote: On Mon, Oct 19, 2009 at 1:23 PM, Simon Perreault simon.perrea...@viagenie.ca wrote: Esposito, Victor wrote, on 2009-10-19 16:01: Since there is a lot of conversation about IPv6 flying about, does anyone have a document or link to a good high level allocation structure for v6? See RFC 3531 and here: http://www.ipv6book.ca/allocation.html Simon I'm sure I'm just dumb, but no matter what numbers I put into that tool, it only spits out a series of /32s on the HTML output. That doesn't seem terribly useful, as most of us aren't going to be allocating multiple /32s, we'll be splitting up a single /32 into smaller bits. Matt
Re: ISP customer assignments
On Oct 13, 2009, at 4:26 PM, Chris Adams wrote: Once upon a time, Michael Dillon wavetos...@googlemail.com said: How many addresses do you like on point-to-point circuits? That will become one of those great interview questions, because anyone who says something like a /127 or a /64 will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 http://www.ietf.org/rfc/rfc3627.txt Still learning here, so please go easy... I read the above, and I see section 4 item 3 says: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? I'm actually completely unclear why people would use anything but a / 126 in 90% or more of cases. For all intensive purposes a /126 translates to a /30 in IPv4. Do people assign /24's to their point to point links today with IPv4? What's the point of a /64 on a point to point link? I'm not clear why people would intentionally be so frivolous with their IP space simply for the sake of because I can.
Re: OSPF vs IS-IS vs PrivateAS eBGP
On Sep 12, 2009, at 7:48 AM, Fouant, Stefan wrote: -Original Message- From: Cord MacLeod [mailto:cordmacl...@gmail.com] Sent: Friday, September 11, 2009 9:50 PM To: North American Network Operators Group Subject: Re: OSPF vs IS-IS vs PrivateAS eBGP I'd also add that ISIS supports IPv6 through the addition of TLVs whereas OSPF was redesigned into OSPFv3. Personally I like ISIS due to it's simplicity and use it for router loopback advertisement only. Cord, so you've piqued my interest. Are you saying you run ISIS for loopback recursion, but another protocol for everything else? Correct. I use ISIS in level 2 only to announce my loopbacks, then BGP for everything else.
Re: OSPF vs IS-IS vs PrivateAS eBGP
On Sep 11, 2009, at 6:23 PM, Randy Bush wrote: I seem to get the impression that isis is preferred in the core. Any reasons why folks dont prefer to go with ospf? a bit harder to attack clnp (is-is) than ip (ospf) is-is a bit simpler to configure, though you can get a sick as you want. but don't. a bit simpler to code, so worked and was stable when ospf was far flakier than it is now. I'd also add that ISIS supports IPv6 through the addition of TLVs whereas OSPF was redesigned into OSPFv3. Personally I like ISIS due to it's simplicity and use it for router loopback advertisement only.
Re: 83.222.0.0/19 Unroutable on Verizon
On Sep 3, 2009, at 2:20 PM, Peter Beckman wrote: I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications Business Fiber as well as Level3. Dies at a peering point it seems: route-views.oregon-ix.netsh ip bgp 83.222.0.0 BGP routing table entry for 83.222.0.0/19, version 14706715 Paths: (34 available, best #6, table Default-IP-Routing-Table) Not advertised to any peer 1221 4637 3549 9002 25532 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin IGP, localpref 100, valid, external 3549 9002 25532 208.51.134.254 from 208.51.134.254 (208.178.61.33) Origin IGP, metric 14088, localpref 100, valid, external 3561 9002 25532 206.24.210.102 from 206.24.210.102 (206.24.210.102) Origin IGP, localpref 100, valid, external 16150 9002 25532 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65215 16150:65320 3277 3267 25532 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65100 3277:65320 3277:65326 3267 25532 194.85.40.15 from 194.85.40.15 (193.232.80.7) Origin IGP, localpref 100, valid, external, best 2914 9002 25532 129.250.0.171 from 129.250.0.171 (129.250.0.79) Origin IGP, metric 308, localpref 100, valid, external Community: 2914:410 2914:2202 2914:3200 3582 4600 11537 9002 25532 128.223.253.8 from 128.223.253.8 (128.223.253.8) Origin IGP, localpref 100, valid, external Community: 3582:567 4600:199 6079 9002 25532 207.172.6.1 from 207.172.6.1 (207.172.6.1) Origin IGP, metric 0, localpref 100, valid, external 2828 3561 9002 25532 65.106.7.139 from 65.106.7.139 (66.239.189.139) Origin IGP, metric 3, localpref 100, valid, external 2905 702 9002 25532 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external 9002 25532 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 701 3549 9002 25532 157.130.10.233 from 157.130.10.233 (137.39.3.60) ^^^ Origin IGP, localpref 100, valid, external 812 174 3561 9002 25532 64.71.255.61 from 64.71.255.61 (64.71.255.61) Origin IGP, localpref 100, valid, external 7660 2516 3549 9002 25532 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 3257 3549 9002 25532 89.149.178.10 from 89.149.178.10 (213.200.87.91) Origin IGP, metric 10, localpref 100, valid, external Community: 3257:8012 3257:30070 3257:50001 3257:54900 3257:54901 6079 9002 25532 207.172.6.20 from 207.172.6.20 (207.172.6.20) Origin IGP, metric 117, localpref 100, valid, external 6453 3549 9002 25532 207.45.223.244 from 207.45.223.244 (66.110.0.124) Origin IGP, localpref 100, valid, external 6453 3549 9002 25532 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin IGP, localpref 100, valid, external 852 174 3549 9002 25532 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 1668 3561 9002 25532 66.185.128.48 from 66.185.128.48 (66.185.128.50) Origin IGP, metric 511, localpref 100, valid, external 4826 9002 25532 114.31.199.1 from 114.31.199.1 (114.31.199.1) Origin IGP, localpref 100, valid, external 852 174 3549 9002 25532 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 8075 9002 25532 207.46.32.34 from 207.46.32.34 (207.46.32.34) Origin IGP, localpref 100, valid, external 2914 9002 25532 129.250.0.11 from 129.250.0.11 (129.250.0.51) Origin IGP, metric 393, localpref 100, valid, external Community: 2914:410 2914:2202 2914:3200 2497 9002 25532 202.232.0.2 from 202.232.0.2 (202.232.0.2) Origin IGP, localpref 100, valid, external 7018 3561 9002 25532 12.0.1.63 from 12.0.1.63 (12.0.1.63) Origin IGP, localpref 100, valid, external Community: 7018:5000 3356 9002 25532 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 65000:0 286 3549 9002 25532 134.222.87.1 from 134.222.87.1 (134.222.86.1) Origin IGP, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3049 286:4017 3549:350 3549:4811 3549:31752 6539 9002 25532 66.59.190.221 from 66.59.190.221 (66.59.190.221) Origin IGP, localpref 100, valid, external 3303 9002 25532 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external Community: 3303:1004 3303:1006 3303:3054 7500 2497 9002 25532
Re: Dan Kaminsky
Read my post one more time... The standards you described are what I described. No video, no audio = no speech = no slander. The article was written, hence libel. On Aug 3, 2009, at 6:02 PM, Richard A Steenbergen wrote: On Sat, Aug 01, 2009 at 01:11:17PM -0700, Cord MacLeod wrote: I don't see a video attached or an audio recording. Thus no slander. Libel on the other hand is a different matter. You have those backwards. Slander is transitory (i.e. spoken) defamation, libel is written/recorded/etc non-transitory defamation. This seems like a group that could benefit from knowing those two words. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Dan Kaminsky
I don't see a video attached or an audio recording. Thus no slander. Libel on the other hand is a different matter. On Aug 1, 2009, at 8:10 AM, andrew.wallace wrote: On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiud...@kyx.net wrote: at the risk of adding to the metadiscussion. what does any of this have to do with nanog? (sorry I'm kinda irritable about character slander being spammed out unnecessarily to unrelated public lists lately ;-P ) What does this have to do with Nanog, the guy found a critical security bug on DNS last year. There is no slander here, I put his name in the subject header so to draw attention to the relevance of posting it to Nanog. I copy pasted a news article caption, which also doesn't slander Dan Kaminsky but reports on the actions of other people true to the facts. Any further slander allegations, please point them at Wired's legal team. Andrew
Re: MX problems
http://en.wikipedia.org/wiki/Traceroute You are looking for the difference between UDP and ICMP in that article. On May 19, 2009, at 3:57 PM, Dave Larter wrote: Hi, I have no problem getting there, is that their mx's? Tracing route to s0.nanog.org [198.108.95.20] over a maximum of 30 hops: 1 117 ms 128 ms 115 ms argon.socrdu.net [64.132.109.136] 2 * 122 ms 126 ms 64.132.109.130 3 125 ms 106 ms 124 ms 64.132.109.129 4 130 ms 125 ms 113 ms 64-132-140-113.static.twtelecom.net [64.132.140.113] 5 129 ms 139 ms 139 ms scor-01-rif1.mtld.twtelecom.net [66.192.243.134] 6 129 ms 137 ms 148 ms te4-2.mpd02.dca01.atlas.cogentco.com [154.54.26.121] 7 152 ms 154 ms 240 ms te7-8.ccr01.jfk02.atlas.cogentco.com [154.54.5.49] 8 158 ms 153 ms 151 ms te9-8.mpd01.bos01.atlas.cogentco.com [154.54.25.242] 9 170 ms 172 ms 167 ms te7-8.ccr01.ord01.atlas.cogentco.com [154.54.7.81] 10 188 ms 172 ms 163 ms te8-2.mpd01.ord03.atlas.cogentco.com [154.54.25.66] 11 194 ms 170 ms 174 ms merit.demarc.cogentco.com [66.28.21.234] 12 164 ms 163 ms 166 ms tenge0-0-0-0x76.aa2.mich.net [198.108.23.10] 13 171 ms 164 ms 171 ms 198.108.22.186 14 171 ms 173 ms 171 ms s0.nanog.org [198.108.95.20] Trace complete. And yes, I only get that one mx/ip for nanog.org. -Original Message- From: Polar Humenn [mailto:polar.hum...@gmail.com] Sent: Tuesday, May 19, 2009 6:44 PM To: nanog@nanog.org Subject: MX problems I'm in Syracuse NY, and I'm having problems getting sendmail to get to MX servers, with the errors of No Route to Host or Connection timed Out. Apparently this is been happening for over 5 days. I can send mail within Syracuse University, but as soon as I venture out nothing. Traceroute seems to loose it after about the 9 or 10th hop. It seems that I can get to almost any website, but tracerouting or pinging these MX servers is not happening. Is there anything going on, or at least something that started 5-7 days ago? I find the same problem from within Syracuse Univeristy to my RoadRunner account at home (which does not pass through the university routers). I only noticed it from the university since thats where I usually send my email through. Like I would no have been able to post to this list From my home machine: traceroute s0.nanog.org traceroute to s0.nanog.org (198.108.95.20), 30 hops max, 60 byte packets 1 192.168.99.1 (192.168.99.1) 0.211 ms 0.257 ms 0.302 ms 2 10.217.224.1 (10.217.224.1) 13.754 ms 13.855 ms 14.291 ms 3 gig2-2.syrcnysyr-rtr01.nyroc.rr.com (24.92.231.138) 18.442 ms 22.701 ms 26.908 ms 4 gig1-1-0.syrcnyflk-rtr02.nyroc.rr.com (24.92.231.54) 31.279 ms 31.454 ms 31.591 ms 5 ge-4-3-0.albynywav-rtr03.nyroc.rr.com (24.24.7.53) 37.429 ms 37.604 ms 37.779 ms 6 ae-5-0.cr0.nyc30.tbone.rr.com (66.109.6.74) 41.329 ms 18.241 ms 22.192 ms 7 ae-1-0.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.472 ms 19.542 ms 23.419 ms 8 te1-4.mpd01.jfk05.atlas.cogentco.com (154.54.13.185) 28.070 ms 32.824 ms 35.822 ms 9 te9-3.ccr01.jfk02.atlas.cogentco.com (154.54.3.165) 40.796 ms 40.549 ms te2-4.ccr01.jfk02.atlas.cogentco.com (154.54.6.49) 40.958 ms 10 te2-4.mpd01.bos01.atlas.cogentco.com (154.54.5.249) 48.704 ms 47.549 ms 48.468 ms 11 te2-2.ccr01.ord01.atlas.cogentco.com (154.54.6.154) 57.836 ms te8-8.mpd01.ord01.atlas.cogentco.com (154.54.24.54) 58.063 ms te2-2.mpd01.ord01.atlas.cogentco.com (154.54.6.18) 46.700 ms 12 vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 56.905 ms te3-4.mpd01.ord03.atlas.cogentco.com (154.54.6.206) 56.144 ms vl3488.mpd01.ord03.atlas.cogentco.com (154.54.5.26) 45.245 ms 13 Merit.demarc.cogentco.com (38.112.7.10) 44.512 ms Merit.demarc.cogentco.com (66.28.21.234) 38.385 ms Merit.demarc.cogentco.com (38.112.7.10) 40.305 ms 14 tenge0-0-0-0x76.aa2.mich.net (198.108.23.10) 43.637 ms 42.601 ms 43.902 ms 15 198.108.22.186 (198.108.22.186) 48.455 ms 51.436 ms 44.070 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Any ideas? Cheers, -Dr Polar
Re: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing
You are exactly right Randy. fromRandy Bush ra...@psg.com to Franck Martin fra...@genius.com cc 74attend...@ietf.org dateWed, Mar 18, 2009 at 4:47 PM subject Re: [74attendees] IETF attendee from Italy or Hong Kong -- visa issue Yes Stockholm is first but as it seemed to be an issue with Asia going to the USA, Hiroshima is likely the meeting than most Asian will be able to attend with less visas problems? i am not sure about north koreans, but i am not aware that there would be problems for others. but i am not sure. and in many venues there are also significant problems with various middle-eastern, north african, and gulf countries. this is aside from the israelis keeping the palestinians imprisoned in their own country. On Apr 17, 2009, at 9:56 PM, Randy Bush wrote: So if Al-Qaeda blow up a shopping centre and the guy who masterminded it turns out to be 17 he gets a job in MI5? what is more fun than a net vigilante? a ranting and raving hyperbolic net vigilante.
