Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Netdisco2 Macsuck CPU Utilization on Cisco Catalyst 6500
(Oliver Gorwits)
2. Naming hosts with public IPv6 and Private IPv4 addresses
(Nikolaos Milas)
3. Re: Naming hosts with public IPv6 and Private IPv4 addresses
(Simon Hobson)
4. Re: Naming hosts with public IPv6 and Private IPv4 addresses
(Ivan Brunello)
5. Re: Naming hosts with public IPv6 and Private IPv4 addresses
(Simon Hobson)
6. Re: Naming hosts with public IPv6 and Private IPv4 addresses
(Jethro R Binks)
--- Begin Message ---
Hi Dirk,
On 2015-03-02 15:38, Troendle, Dirk (SCC) wrote:
I am occuring these problems with macsuck on my Backbone Routers
(which are both Cisco Catalyst 6500):
1)Macsuck takes very long (>3 hours) on these devices
Wow, that's a long time! How many entries are there in the MAC address
table on one of these devices? (I know that 6500 can support a very
large set of hosts)
Also, does the macsuck ever finish, or does it timeout?
2)While macsuck runs, the CPU is at 100% on the device, which causes
other snmp requests (e.g. from other monitoring services like
cacti/icinga/etc.) to timeout.
Unfortunately this is kind of normal for the 6500 platform, because
they have feeble CPUs and also need to do a lot of work to translate the
MAC address table from its internal format to the SNMP format. Having
said that, there are many happy Netdisco users with 6500 - normally it
should be a quick job to macsuck - perhaps someone else on the list can
offer suggestions?
regards,
oliver.
Is there an easy fix for this behaviour or should I just blacklist
these devices for macsuck (with the macsuck_no option)?
I am using Netdisco 2.029014
best regards,
Dirk
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
by Intel and developed in partnership with Slashdot Media, is your
hub for all
things parallel software development, from weekly thought leadership
blogs to
news, videos, case studies, tutorials and more. Take a look and join
the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
Hello,
I would like to ask for your experience and advice on the following
situation:
When we use a private IPv4 subnet (e.g. 10.10.10.0/24) with NAT (to
access the Internet) and at the same time (i.e. on the same LAN or VLAN)
we use a public IPv6 address space, what should be the naming policy for
hosts with dual stack, i.e. with a private IPv4 address and a public
IPv6 address?
Naming using public IPv6 addresses leads to public names (e.g.
example.com), while naming using private IPv4 addresses leads to private
names (e.g. example.local).
What is the best way to reconcile the two? I feel that hosts should not
be meant to have double names (in order to avoid management and dns havoc).
A (single) name should be an easy way to address a host, regardless
whether it is using IPv6 or IPv4; this idea is largely defeated if we
need to address/recognize (*in the local network*) a host using a
different name in IPv6 and in IPv4.
Thanks in advance for your advice and thoughts.
Nick
--- End Message ---
--- Begin Message ---
Nikolaos Milas <[email protected]> wrote:
> When we use a private IPv4 subnet (e.g. 10.10.10.0/24) with NAT (to
> access the Internet) and at the same time (i.e. on the same LAN or VLAN)
> we use a public IPv6 address space, what should be the naming policy for
> hosts with dual stack, i.e. with a private IPv4 address and a public
> IPv6 address?
>
> Naming using public IPv6 addresses leads to public names (e.g.
> example.com), while naming using private IPv4 addresses leads to private
> names (e.g. example.local).
Nooooooo
You should never name *anything* as .local
.local is reserved for multicast DNS (aka mDNS, Zeroconf, Bonjour). Using
.local as your internal domain breaks this. Even Microsoft have advised against
using .local for many years.
IMO the approach should be to use company.com (or whatever your *registered*
domain name is. If you really insist on not using the same domain internally
and externally then register a second domain. Split horizon DNS will easily fix
the internal vs external issues.
While split horizon DNS is probably technically broken, it's a reasonable "fix"
for having NAT which is the most fundamental "broken" thin in IP addressing.
> A (single) name should be an easy way to address a host, regardless
> whether it is using IPv6 or IPv4; this idea is largely defeated if we
> need to address/recognize (*in the local network*) a host using a
> different name in IPv6 and in IPv4.
I agree.
So using your main domain name, you could have bigswitch.company.com with both
A and AAAA records in the internal DNS view - but not appearing at all in the
external view. For servers, you could have bigserver.company.com with A and
AAAA records internally, but only an A record (it's public, outside of the NAT,
address) in the external view if you don't have IPv6 connectivity externally.
Boy, the "fun" i've had in the past trying to explain these concepts to some
people !
--- End Message ---
--- Begin Message ---
I happen to see another approach.
use FQDN company.com for public site, and use a subdomain (e.g.
priv.company.com) for internal resources.
Internal resources are mapped to private ip address, public (such as
www.company.com) are mapped to NAT ip addresses.
of course, you maintain two sets of DNS, one serving external, with only
public records, and one serving internal, with only private ones.
Furthermore, using the "priv" subdomain, it is also easier to set PTR
records (i usually rely heavily on consistent - A/AAAA and PTR - records).
One more suggestion: use always "virtual", additional ip/ipv6 addresses for
ANY published services; each server should have its own address, and one or
more additional ip(v4/v6) address for services.
This makes virtualization of services (e.g. by putting behind a
load-balancer), or moving services from one machine to another a lot easier.
And keep a different record for every service which could be split (i.e.
not "mail", but "smtp/mailout" and "pop3/imap/mailin", since when your
service begin to scale, you would prefer to separata the MTA from the MDA).
Sound obvious, but rarely it is, and I happened to make weird thing to
non-properly splitted services)
Not "you ought to do this way" but simply "I avoided several headaches by
making this way". Take what you find useful.
My two cents.
Ivan
On Tue, Mar 3, 2015 at 11:00 AM, Simon Hobson <[email protected]>
wrote:
> Nikolaos Milas <[email protected]> wrote:
>
> > When we use a private IPv4 subnet (e.g. 10.10.10.0/24) with NAT (to
> > access the Internet) and at the same time (i.e. on the same LAN or VLAN)
> > we use a public IPv6 address space, what should be the naming policy for
> > hosts with dual stack, i.e. with a private IPv4 address and a public
> > IPv6 address?
> >
> > Naming using public IPv6 addresses leads to public names (e.g.
> > example.com), while naming using private IPv4 addresses leads to private
> > names (e.g. example.local).
>
> Nooooooo
> You should never name *anything* as .local
> .local is reserved for multicast DNS (aka mDNS, Zeroconf, Bonjour). Using
> .local as your internal domain breaks this. Even Microsoft have advised
> against using .local for many years.
>
> IMO the approach should be to use company.com (or whatever your
> *registered* domain name is. If you really insist on not using the same
> domain internally and externally then register a second domain. Split
> horizon DNS will easily fix the internal vs external issues.
>
> While split horizon DNS is probably technically broken, it's a reasonable
> "fix" for having NAT which is the most fundamental "broken" thin in IP
> addressing.
>
>
> > A (single) name should be an easy way to address a host, regardless
> > whether it is using IPv6 or IPv4; this idea is largely defeated if we
> > need to address/recognize (*in the local network*) a host using a
> > different name in IPv6 and in IPv4.
>
> I agree.
> So using your main domain name, you could have bigswitch.company.com with
> both A and AAAA records in the internal DNS view - but not appearing at all
> in the external view. For servers, you could have bigserver.company.com
> with A and AAAA records internally, but only an A record (it's public,
> outside of the NAT, address) in the external view if you don't have IPv6
> connectivity externally.
>
> Boy, the "fun" i've had in the past trying to explain these concepts to
> some people !
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Netdisco mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/netdisco-users
>
--- End Message ---
--- Begin Message ---
Ivan Brunello <[email protected]> wrote:
> use FQDN company.com for public site, and use a subdomain (e.g.
> priv.company.com) for internal resources.
> Internal resources are mapped to private ip address, public (such as
> www.company.com) are mapped to NAT ip addresses.
Yup, that'll do it too.
> One more suggestion: use always "virtual", additional ip/ipv6 addresses for
> ANY published services; each server should have its own address, and one or
> more additional ip(v4/v6) address for services.
> This makes virtualization of services (e.g. by putting behind a
> load-balancer), or moving services from one machine to another a lot easier.
Or at least use different DNS names. Mind you, using different IPs (and only
listening on the right IP for each service) does mean that people who ignore
your instructions will find things don't work.
> Not "you ought to do this way" but simply "I avoided several headaches by
> making this way". Take what you find useful.
Always good to see what other people do - no "right" or "wrong" (well mostly no
"wrong" !), just different approaches.
--- End Message ---
--- Begin Message ---
On Tue, 3 Mar 2015, Simon Hobson wrote:
> Mind you, using different IPs (and only listening on the right IP for
> each service) does mean that people who ignore your instructions will
> find things don't work.
Sounds like a win to me.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK
The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.
--- End Message ---
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
