November 2010 - Test - lists.nanog.org

Experiences with 3Com/H3C/HP S5800/A5800 switches?
by Ulf Zimmermann 23 Nov '10

23 Nov '10

Can anyone with experiences on the S5800/A5800 series of 3Com/H3C/HP switches email of off-list with good/bad stuff? Also maybe a pointer at manuals for the OS? My reseller so far is having a hard time finding them for me. -- Regards, Ulf.

1 0

Re: Introducing draft-denog-v6ops-addresspartnaming (fwd)
by Jay Nugent 23 Nov '10

23 Nov '10

Documenting my support publically, as requested. --- Jay ---------- Forwarded message ---------- Date: Mon, 22 Nov 2010 23:26:31 +0100 From: Richard Hartmann <richih.mailinglist(a)gmail.com> To: Jay Nugent <jjn(a)nuge.com> Subject: Re: Introducing draft-denog-v6ops-addresspartnaming On Mon, Nov 22, 2010 at 19:46, Jay Nugent <jjn(a)nuge.com> wrote: > Â I like "hexquad" for any value between the colons being greater than > zero. Â Example :abcd: OK, noted :) Are you willing to answer on-list to document your support publically? > Â I like "hexnot" when the value between the colons is zero. Â Example :: I honestly think that they look and sound way too similar which may lead to confusion. Richard

1 0

IPv6 6to4 and dns
by Jeroen van Aart 22 Nov '10

22 Nov '10

What would be the best way to configure your dns once you've set up IPv6 6to4? Separate the IPv4 and IPV6 domains or let them be the same? That is, use something like example.com for your existing IPv4 address and something like 6.example.com for IPv6 (and www.6.example.com etc.)? Or is it safe to have both A and AAAA records for the same domain name? Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html

6 8

Re: Introducing draft-denog-v6ops-addresspartnaming
by Robert Bonomi 22 Nov '10

22 Nov '10

> From nanog-bounces+bonomi=mail.r-bonomi.com(a)nanog.org Fri Nov 19 14:18:02 2010 > Date: Fri, 19 Nov 2010 12:19:34 -0800 > From: Joel Jaeggli <joelja(a)bogus.com> > To: Owen DeLong <owen(a)delong.com> > Subject: Re: Introducing draft-denog-v6ops-addresspartnaming > Cc: bmanning(a)vacation.karoshi.com, nanog(a)nanog.org > > On 11/19/10 10:56 AM, Owen DeLong wrote: > >> It is always two bytes. A byte is not always an octet. Some machines do > > > > It is always two OCTETS. A byte is not always an octet... > > Assuming you have a v6 stack on your cdc6600 a v6 address fits in 22 > bytes not 16. <pedant> 3 words of CPU memory (with 50+ bits available to possibly pack 'something else useful' in.) One could get away with 11 words of PPU memory, but that would require pack/unpack on every move between CPU<->PPU address-spaces. </pedant> just implementing a K&R 'C' compiler was a real challenge on that hardware. :) > One can define that byte size for the purposes of the human reading of > addresses ipv6 as 8 bits, without getting into machine specific details. > what's important to the machine isn't the division of the address into > parts (they aren't divided in the machine representation it's just one > long row of bits) but rather where the mask falls. Yup. When talking IP, the 'network byte size' is fixed at 8 bits. This is 'cast in stone', as is 'network byte order', and 'bit order'. If the 'scope' of the term is restricted to Internet protocol/connectivity contexts, one can use 'byte' unambiguously as a referant to an 8-bit qty.

1 0

Re: Introducing draft-denog-v6ops-addresspartnaming
by Robert Bonomi 22 Nov '10

22 Nov '10

> From nanog-bounces+bonomi=mail.r-bonomi.com(a)nanog.org Fri Nov 19 11:05:33 2010 > Subject: Re: Introducing draft-denog-v6ops-addresspartnaming > From: Owen DeLong <owen(a)delong.com> > Date: Fri, 19 Nov 2010 08:58:45 -0800 > To: Richard Hartmann <richih.mailinglist(a)gmail.com> > Cc: bmanning(a)vacation.karoshi.com, nanog(a)nanog.org > > > On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote: > > > On Fri, Nov 19, 2010 at 07:00, <bmanning(a)vacation.karoshi.com> wrote: > > > >> problem is, its not alwas ggoig to be two bytes... > > > > It's always two bytes, but people may choose to omit them. That is a > > social, not a (purely) technical, syntax, though. > > It is always two bytes. A byte is not always an octet. Some machines do > have byte sizes other than 8 bits, although few of them are likely to have > IPv6 stacks, so, this may be an academic distinction at this point. I suppose one could call the explicitly-present fields 'bi-bytes', and the compressed-out sequence the 'bye-bytes'.

1 0

Re: Introducing draft-denog-v6ops-addresspartnaming
by Jeff Aitken 22 Nov '10

22 Nov '10

[ Meant to send this to the list and not directly to Richard. ] On Fri, Nov 19, 2010 at 03:07:40AM +0100, Richard Hartmann wrote: > If any of you have any additional suggestions, you are more than > welcome to share them. I heard "hexquad" somewhere awhile back and have been using it since... looking over the other options present in your poll, I think I still prefer it, but I could live with either "hextet" or simply "quad" as well. --Jeff

2 2

Re: Introducing draft-denog-v6ops-addresspartnaming
by Daniel Hagerty 22 Nov '10

22 Nov '10

Richard Hartmann <richih.mailinglist(a)gmail.com> writes: > I will add quad to -03 anyway. If you get a few +1 on hexquad, I am > against adding that, as well. Quad is a standard term for "64 bit integer" in C/C++. For example: $ grep -c quad /usr/src/sys/netinet6/*|awk -F: '{tot+=$2} END{print tot}' 171 which is to say, the kame derived ipv6 stack on this machine uses one of the *quad_t types 171 times. Ambiguating usages like "Take the least signifigant quad of that ipv6 address" to mean either 16 bits or 64 bits, when it currently is unamibigously 64 bits won't make the lives of C/C++ programmers writing IPv6 code any easier.

2 1

XO/AS2828 -> Cogent/AS174 blackholing
by Tore Anderson 22 Nov '10

22 Nov '10

Hi list, I'm seeing blackholing on my inbound traffic from XO and their downstreams (notably CNN) via Cogent. Prepending towards Cogent changes my inbound path from 2828 174 39029 to 2828 3549 3292 39029 and it works fine, even though the outbound path is still via Cogent: tore@cr3> traceroute 2610:18::3050 wait 2 no-resolve traceroute6 to 2610:18::3050 (2610:18::3050) from 2a02:c0:1000:1::2, 64 hops max, 12 byte packets 1 2a02:c0:1000:1::1 0.822 ms 1.290 ms 0.355 ms 2 2001:978:2:30::1 0.465 ms 0.477 ms 0.395 ms 3 * * * 4 * * * 5 2001:7f8:4::ae:1 582.740 ms * 82.538 ms 6 * * * 7 2001:504:f::c 106.967 ms 109.421 ms 107.129 ms 8 2001:550:3::11e 121.969 ms 103.842 ms 112.119 ms 9 2610:18::3050 143.462 ms 142.717 ms 145.179 ms 2610:18::3050 is the first hop in XO's network on the way to ipv6.cnn.com. If I stop prepending towards Cogent, 2001:550:3::11e is the last hop that gives me any replies. So it appears my announcements reach XO, but the packets gets lost somewhere along the line. Cogent told me they found nothing wrong with their end of the peering. Anyone in or behind XO with the same problem? 2001:978:1:326::2 is an example of a router in Cogent's network (in Stockholm) that should respond to pings if everything works fine. It seems like the problem happens with Cogent's own routes as well, as neither 2610:18::3050 nor 2620:0:2200:8:8888:8888:8888:8901 (ipv6.cnn.com) get any replies when pinging from Cogent's looking glass. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27

1 1

id.apple.com
by Nathan Eisenberg 22 Nov '10

22 Nov '10

Would a mail-op from id.apple.com please contact me off-list?

1 0

switch about routing p
by Deric Kwok 22 Nov '10

22 Nov '10

Hi I read switch that supports PIM / ESRP / VRRP What are they? Thank you

2 1