Project

General

Profile

Actions

Task #7930

closed

Monitoring LAN in place6

Added by Timothée Floure over 4 years ago. Updated 11 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
04/21/2020
Due date:
% Done:

0%

Estimated time:
PM Check date:

Description

Fnux

Monitoring services is a pain at the moment: either I have to configure prometheus by hand to monitor a service, or I have to make a hole for the node's specific IP so that it joins the consul cluster.
Could we have some kind of internal "monitoring LAN" that we attach to the VM in ONE? This subnet could be wired to be able to access the consul cluster.

Nico

ok. Proceed as follows:
delegate a new /64 from 2a0a:e5c0:2::/48 in netbox
Create an opennebula network for it, cluster = place6, ciara (all clusters that are in place6)
Don't configure a gateway - we keep this as an add-on network
Reconfigure the firewall to allow accessing consul from this network
(all in a redmine ticket, cc llnu kjg)

2020-05-29, vxlan

  • We create a vxlan device
  • We create a bridge containing the vxlan device
  • And we are happy
Actions #1

Updated by Timothée Floure over 4 years ago

Allocated 2a0a:e5c0:2:b::/64 (https://netbox.ungleich.ch/ipam/prefixes/208/). This netbox thing is very convenient.

Actions #2

Updated by Timothée Floure over 4 years ago

place6-monitoring allocated in ONE.

Actions #3

Updated by Nico Schottelius over 4 years ago

  • Description updated (diff)
Actions #4

Updated by Nico Schottelius over 4 years ago

Check #1 vxlan communication doesn't work:


[14:45:29] server2.place6:~# ip addr add 2a0a:e5c0:100::42/64 dev bond0.33.010
[14:40:10] server11.place6:~# ip addr add 2a0a:e5c0:100::32/64 dev bond0.33.010
[14:42:44] server11.place6:~# ping -c3 2a0a:e5c0:100::42
PING 2a0a:e5c0:100::42(2a0a:e5c0:100::42) 56 data bytes

--- 2a0a:e5c0:100::42 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2051ms

[14:43:03] server11.place6:~# 

Actions #5

Updated by Nico Schottelius over 4 years ago

Vlan communication works:

[14:43:03] server11.place6:~# ip addr add 2a0a:e5c0:100:1::32/64 dev bond0.33
[14:44:06] server11.place6:~# ping -c3 2a0a:e5c0:100:1::42
PING 2a0a:e5c0:100:1::42(2a0a:e5c0:100:1::42) 56 data bytes
64 bytes from 2a0a:e5c0:100:1::42: icmp_seq=1 ttl=64 time=0.533 ms
64 bytes from 2a0a:e5c0:100:1::42: icmp_seq=2 ttl=64 time=0.335 ms
64 bytes from 2a0a:e5c0:100:1::42: icmp_seq=3 ttl=64 time=0.281 ms

--- 2a0a:e5c0:100:1::42 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 0.281/0.383/0.533/0.108 ms
[14:44:18] server11.place6:~#

[14:59:08] server2.place6:~# ping 2a0a:e5c0:100::32
PING 2a0a:e5c0:100::32(2a0a:e5c0:100::32) 56 data bytes
64 bytes from 2a0a:e5c0:100::32: icmp_seq=1 ttl=64 time=0.530 ms
64 bytes from 2a0a:e5c0:100::32: icmp_seq=2 ttl=64 time=0.435 ms
64 bytes from 2a0a:e5c0:100::32: icmp_seq=3 ttl=64 time=0.490 ms
64 bytes from 2a0a:e5c0:100::32: icmp_seq=4 ttl=64 time=0.522 ms
64 bytes from 2a0a:e5c0:100::32: icmp_seq=5 ttl=64 time=2.54 ms
64 bytes from 2a0a:e5c0:100::32: icmp_seq=6 ttl=64 time=0.504 ms
64 bytes from 2a0a:e5c0:100::32: icmp_seq=7 ttl=64 time=0.338 ms
64 bytes from 2a0a:e5c0:100::32: icmp_seq=8 ttl=64 time=2.59 ms
64 bytes from 2a0a:e5c0:100::32: icmp_seq=9 ttl=64 time=0.782 ms
^C
--- 2a0a:e5c0:100::32 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 151ms
rtt min/avg/max/mdev = 0.338/0.969/2.593/0.860 ms
[14:59:48] server2.place6:~# 

Seems we need a global ip on the vlan interface

Actions #6

Updated by Nico Schottelius over 4 years ago

Adding vxlan 33 to apu-routers:

# For vxlans
auto eth1.33
iface eth1.33 inet static
  address 2a0a:e5c0:2:c::IPSUFFIX/64
  netmask 64
  post-up /sbin/ip link set $IFACE mtu 9000

Firewall rule:

        # no traffic is supposed to get into the vxlan network
        ip6 daddr $vxlan_network drop

Actions #7

Updated by Timothée Floure over 4 years ago

Up and running! It still need:

  • Documentation.
  • Testing/checking on cdist-backed vlan creation on ONe workers.
Actions #8

Updated by Timothée Floure almost 4 years ago

  • Status changed from In Progress to Waiting
  • Assignee deleted (Timothée Floure)

This thing is nice in theory but painful in practice: they are too many moving parts. I'm pretty sure we can design simpler service discovery if needed.

Actions #9

Updated by Nico Schottelius 11 months ago

  • Status changed from Waiting to Rejected
Actions

Also available in: Atom PDF