[ntp:hackers] Re: IPv6 Multicasting

David L. Mills mills at udel.edu
Thu Jun 30 20:07:57 PDT 2005


Danny,

I expect what happened was that the pogo hardware was changed out for a 
more modern machine and that changed the MAC address. I'm really nervous 
about tying the IPv6 address to the MAC address, as the machines do get 
swapped out from time to time.

The backroom machines are in some disarray, as the basement fiber is 
still dark. I haven't figured out how to resume the IPv6 configuration 
and tunnel to campus.

I did send a wakeup call to our campus IT about IPv6.

Dave

Danny Mayer wrote:

> Well I did a little digging. The campus dns zone has AAAA records that 
> disagree with the address that your servers are configured with.
>
> This is what the campus servers are reporting for IPv6 addresses:
>
> pogo-ip6.udel.edu.      86400   IN      AAAA 
> 3ffe:b80:17d2:1:a00:20ff:fe81:76e7
> malarky-ip6.udel.edu.   86400   IN      AAAA 
> 3ffe:b80:17d2:2:a00:20ff:fec6:5a74
> howland-ip6.udel.edu.   86400   IN      AAAA 
> 3ffe:b80:17d2:2:250:daff:fedd:5333
> whimsy-ip6.udel.edu.    86400   IN      AAAA 
> 3ffe:b80:17d2:2:a00:20ff:fe89:bc1f
> hepzibah-ip6.udel.edu.  86400   IN      AAAA 
> 3ffe:b80:17d2:1:260:8ff:fe11:d903
> mort-ip6.udel.edu.      86400   IN      AAAA 
> 3ffe:b80:17d2:2:203:baff:fe02:a79e
> bridgeport-ip6.udel.edu. 86400  IN      AAAA 
> 3ffe:b80:17d2:1:a00:20ff:fe9e:c95b
> beauregard-ip6.udel.edu. 86400  IN      AAAA 
> 3ffe:b80:17d2:2:280:5fff:fed2:e80
> baldwin-ip6.udel.edu.   86400   IN      AAAA 
> 3ffe:b80:17d2:1:a00:20ff:fe9e:8cd5
>
> From ifconfig (abbreviated) on pogo:
> hme0:1:  inet6 3ffe:b80:17d2:1:a00:20ff:fea5:1800/64
>
> which disagrees, and
>
> from ifconfig (abbreviated) on hepzibah:
> xl0: inet6 3ffe:b80:17d2:1:260:8ff:fe11:d903 prefixlen 64
>
> which does agree.
>
> So some of the addresses may be incorrect. I'm having connection 
> problems at the moment otherwise I'd be able to check the others.
> Looks like the DNS record is wrong for pogo.
>
> Danny
>
> David L. Mills wrote:
>
>> Danny,
>>
>> I did a little more poking and found Solaris ping and traceroute to 
>> pogo-ip6.udel.edu reports unknown host. However, ssh and ntpd can 
>> resolve that name. Then I noticed the address they resolved does not 
>> match the address seen in pogo netstat -r. The prefix looks okay but 
>> the last 32 bits do not. An attempt to ssh from pogo to 
>> hepzibah-ip6.udel.edu does in fact connect, then stalls in ssh at 
>> file ~mills/ssh/.identity type -1. At least something seems to work.
>>
>> Dave
>>
>> Danny Mayer wrote:
>>
>>> David L. Mills wrote:
>>>
>>>> Danny,
>>>>
>>>> You are exactly right. If our local staff is to maintain my Solaris 
>>>> machines, I need to use the "standard" libraries and 
>>>> configurations. For that matter, if I am the resource to 
>>>> build/configure the FreeBSD machines here, I need to use whatever 
>>>> comes out of the standard box.
>>>>
>>>> The NTP sandbox here is a wart on the side of the department in 
>>>> that the department NIS defines the campus and department 
>>>> environment - users, groups, host names, netgroups, etc., while the 
>>>> additional users, groups, etc., for the NTP corps is defined on the 
>>>> pogo NIS maps and exported to malarky and whimsy. The design is to 
>>>> use NIS from pogo and the department machines, including pogo, to 
>>>> establish the NTP sandbox via NIS and when that fails on pogo to 
>>>> revert to DNS. The problem is that pogo DNS fails for whatever 
>>>> cause. I have no idea what to do about that, especially since it 
>>>> once worked.
>>>>
>>>
>>> Dave, we'll help if we can. Can you tell us what exactly is failing,
>>> where it's failing and what you see? Just give us the symptoms, what 
>>> you
>>> see, we'll figure out the cause. What machines does it fail on? What is
>>> doing the lookup and fails, NTP?
>>>
>>>> It would seem the root cause here is the interface between NIS and 
>>>> DNS on pogo. Interestingly enough, dig does resolve pogo-ip6 on 
>>>> pogo, but not on our department machines, which allegedly have the 
>>>> same configuration.
>>>
>>>
>>>
>>>
>>> Which are the departmental machines that are failing? Is this NTP
>>> running that's failing lookup? Or something else? If NTP did you point
>>> ntp.conf server at pogo-ip6 or do something else?
>>>
>>>  I am told Sun is to deprecate NIS in favor of LDAP. I am
>>>
>>>> also told the campus DNS is maintained via a Sybase database system 
>>>> and providing IPv6 requires considerable investment.
>>>
>>>
>>>
>>>
>>> I don't believe that. The last time we had a discussion about IPv6 on
>>> the campus, it was because they thought the they were going to have to
>>> use A6 records which has since become relegated to experimental. 
>>> However
>>> they had implemented AAAA records and that was no problem. In addition,
>>> the campus better get used to IPv6, that's what the Internet is moving
>>> towards, although slower than I expected. So on that point, you can 
>>> tell
>>> them that they need to get with the program, we're not going back.
>>>
>>>  Having said that, I am
>>>
>>>> told the campus guys expect to do what needs when the time comes. I 
>>>> will try to convince them the time is now.
>>>>
>>> Yes, IPv6 is here. They better get used to it. It's better that they 
>>> get
>>> through the growing pains with us who have a clue and can guide them
>>> than in the future when they are thrown into the pool to sink or swim.
>>>
>>>> If there is something we can do on pogo as workaround until a more 
>>>> generic solution is available, please advise.
>>>>
>>>
>>> As soon as we know what the symptoms are and what's failing, we'll come
>>> up with ideas.
>>>
>>> Danny
>>>
>>>> Dave
>>>
>>>
>>>
>>
>> _______________________________________________
>> hackers mailing list
>> hackers at support.ntp.org
>> https://support.ntp.org/mailman/listinfo/hackers
>>




More information about the hackers mailing list