On Wed, Aug 24, 2016 at 08:36:49AM -0700, Luke Bigum wrote:
> Here we have very strict control over our hardware and what interface goes
> where. We keep CentOS 6's naming scheme on Dell hardware, so p2p1 is PCI
> slot 2, Port 1, and don't try rename it.
Isn't CentOS 6 still using eth0, 1, 2, 3? How do you handle different
hardware having different slot numbers, or PCI bridges shifting bus
numbers?
> We have a 3rd party patch manager tool (patchmanager.com), LLDP on
> our switches, and a Nagios check that tells me if an interface is not
> plugged into the switch port it is supposed to be plugged into
> (according to patchmanager).
Nice ;-) Is the code for the Nagios stuff public?
> This works perfectly on Dell hardware because the PCI name mapping
> works.
And you don't have many different kinds of servers.
> On really old HP gear it doesn't work,
What does that mean?
> We still need some sort of "glue record" that says "this interface should
> be up and have this IP". In our older designs this was managed entirely in
> Hiera - so there's a giant multi-level hash that we run create_resources()
> over to define every single network interface. You can imagine the amount
> of Hiera data we have.
That's what we're trying to avoid. Can you share example snippets?
> In the newer designs which are a lot more of a role/profile approach
> I've been trying to conceptualise the networking based on our
> profiles. So if one of our servers is fulfilling function "database"
> there will be a Class[profile::database]. This Class might create a
> bonded interface for the "STORAGE" network and another interface for
> the "CLIENT" network.
That is interesting and a nice concept. But nothing one introduces
just to remedy an error report named "help, my interface names do not
fit any more".
So you do create network interfaces in the profile and not in the
role?
> Through various levels of Hiera I can define the STORAGE network as
> VLAN 100, because it might be a different vlan tag at a different
> location. Then at the Hiera node level (on each individual server) I
> will have something like:
>
> profile::database::bond_storage_slaves: [ 'p2p1', 'p2p2' ]
>
> That's the glue. At some point I need to tell Puppet that on this specific
> server, the storage network is a bond of p2p1 and p2p2.
So you need to know when writing this code what kind of hardware the
system is running on, probably down to firmware version and hardware
extras?
> I have bounced around the idea of removing this step and trusting the
> switch - ie: write a fact to do an LLDP query for the VLAN of the switch
> port each interface is connected to, that way you wouldn't need the glue,
> there'd be a fact called vlan_100_interfaces.
So the fact would be coming from the _server_ based on what lldpcli
show neighbors detail returns, which is supposed to include the VLAN
information? Would this work on 801.1q trunks as well?
> Two problems with this approach: we end up trusting the switch to be
> our source of truth (it may not be correct,
The switch uses its own source of truth which also influences which
network traffic gets sent down the link, so trusting the switch will
at least fail to the safe side and avoid accidentally putting full
trust on an Internet link.
> and, what if the switch port is down?).
One would have to fall back to a certain safety net then.
> Secondly the quality and consistency of LLDP information you get out
> of various manufacturers of networking hardware is very different, so
> relying on LLDP information to define your OS network config is a bit
> risky for me.
Is it really this bad? I do have experience with HP and Cisco, and
their LLDP/CDP information is usually fine.
> It's a different story for our VMs. Since they are Puppet defined we
> specify a MAC address and so we "know" which MAC will be attached to which
> VM bridge. We drop a MAC based udev rule into the guest to name them
> similarly, ie: eth100 is on br100.
How do you puppet define your MAC addresses? Which virtualization do
you use? Can i see a code snippet?
> That's what we do, but it's made easy by an almost homogeneous hardware
> platform and strict physical patch management.
Yes. The homogenous hardware platform is probably something that can
only be maintained for really large installations.
> When I read about your problem, it sounds like you are missing a "glue
> record" that describes your logical interfaces to your physical devices.
We're desperately trying to avoid having this in Hiera.
> If you were to follow something along the lines of our approach, you
> might have something like this:
>
> class profile::some_firewall(
> $external_interface_name = 'eth0',
> $internal_interface_name = 'eth1',
> $perimiter_interface_name = 'eth2'
> ) {
> firewall { '001_allow_internal':
> chain => 'INPUT',
> iniface => $internal_interface_name,
> action => 'accept',
> proto => 'all',
> }
>
> firewall { '002_some_external_rule':
> chain => 'INPUT',
> iniface => $external_interface_name,
> action => 'accept',
> proto => 'tcp',
> dport => '443',
> }
> }
>
> That very simple firewall profile probably already works on your HP
> hardware, and on your Dell hardware you'd need to override the 3 parameters
> in Hiera:
>
> profile::some_firewall::internal_interface_name: 'em1'
> profile::some_firewall::external_interface_name: 'p3p1'
> profile::some_firewall::perimiter_interface_name: 'p1p1'
On the Dell R680, yes. A hypothetical "R680s" would need some other
definition, and a VMware Vm comes up with eno<number> interfaces with
eight-digit <number>, basically random.
Thanks for your input, I appreciate it.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20160825122110.GW2471%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
