Für dhcpd: br- oder bat-?

Technik Gluon
1

Moin,

Verständnisfrage: wo sollte auf dem Gateway der dhcpd laufen, auf dem Bridge- oder dem Batman-Interface? Irgendwie haben wrr beides, und die bat-Variante erschließt sich mir irgendwie nicht?

root@gw-gut01:~# ps -Aelf | grep dhcp | grep -v grep
4 D dhcpd    14418     1  0  80   0 -  9208 jbd2_l 18:46 ?        00:00:06 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf br-ffgt

root@l2tp-ber01 ~ # ps -Aelf | grep dhcp | grep -v grep
4 S dhcpd    16274     1  0  80   0 - 12605 poll_s Nov06 ?        00:33:04 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf bat01 bat02 bat03 bat04 bat05 bat06
2

hi

wenn das bat in ner bridge liegt wird es nur funktionieren wenn du es auf der bridge laufen lässt.

Sollte das bat alleine stehen ohne in ner Bridge zu sein muss es natürlich aufs bat

Gruß

Christian

3

Hmm. Also hier ist die jeweilige Brigde im Batman-Interface und dhcpd läuft eben mal auf batXX und mal auf br-XXXX.

Ansible-basiertes Setup:

root@l2tp-ber01 ~ # batctl -m bat01 if
br01: active
t01-karte: active
t01-l2tp-ham01: active
root@l2tp-ber01 ~ # brctl show br01
bridge name     bridge id               STP enabled     interfaces
br01            8000.02caffee0104       no              l2tp103-103
                                                        l2tp104-104
                                                        l2tp118-118
                                                        l2tp122-122

Puppet-basiertes Setup:

root@gw-gut01:~# batctl -m bat-ffgt if
Efastdgut01: active
Etmpstats: active
Egw00: active
ens8: active
ens7: active
ens9: active
ens10: active
ffgt-mesh-vpn: active
root@gw-gut01:~# brctl show br-ffgt
bridge name     bridge id               STP enabled     interfaces
br-ffgt         8000.06aa549ec598       no              Ehopglass
                                                        El2tpgut02
                                                        bat-ffgt
4

hi

im ersten Fall ist die Bridge im Batman, das Batmaninterface also alleine und nicht in der Bridge. Das würde für mich heißen das Batman Interface braucht die IP und darauf muss auch der dhcpd laufen.

Im 2. Fall, ist das bat-ffgt in der Bridge, hier hat vermutlich bat-ffgt keine IP mehr sondern br-ffgt, dhcpd muss hier dann natürlich auf der br-ffgt laufen.

Am besten einfach mal einlesen wie so eine Bridge genau funktioniert.

Gruß

Christian

1 „Gefällt mir“
5

Damit batman gut funktionieren kann sollte unter batman nie eine bridge liegen, wenn das die CPU mit macht. Nur dann kann batman seine Filterfähigkeiten ausspielen. Kostet leider CPU, aber wenn an diesen Bridges z.B. WLAN-Backbone hängt, das dann z.B. im Dreieck läuft, braucst Du wieder was wie Spanning Tree. Das wiederum löst einen teil der Probleme die batman löst, aber eventuell auf andere Routingweise → potentiell schlechtes Netz. Da muss man sehr genau aufpassen was dann wirklich wo dran hängt.
Ansonsten: alles was unter einer Bridge hängt darf nicht separat konfiguriert werden. Wenn brXX batXX beinhaltet läuft der dhcp-Server auf brXX.
Du musst allerdings kein brXX haben, du kannst auch batXX direkt nutzen, wenn es keinen konkreten brXX-Bedarf gibt. Auf Nodes ist der konkrete Bedarf dass da das Client-WLAN dran hängt.
Ich habe GWs am laufen die da z.B. noch direkt OpenVPN-Clients mit rein lassen für Wartung, das hängt dann parallel zu batXX unter brXX.
In Deinem Fall wäre El2tpgut02 etwas an dem Clients hängen (kein batman Filter), Efastdgut01 dagegen hat batman Traffic.

Ganz generell kann es sein, dass es scheint ein Interface das unterhalb einer Bridge hängt und z.B. eine IP konfiguriert hat, richtig reagiert. Das ist aber ein Trugschluss. Das führt auch immer wieder zu Problemen bei Servern die ein konfiguriertes Netzwerkinterface in eine Bridge migriert haben.

6

Manchmal hilft es, drüber zu sprechen :wink: Das Detail hab’ ich in der Tat übersehen; danke.

7

Danke für die Hintergründe.

Das ist schon bekannt; wie gesagt, ich war wohl so fixiert auf „das ist gleich gebaut, nur der dhcpd läuft woanders“, daß ich auf den Unterschied nicht geachtet habe: Betriebsblind.

Was mich an der Stelle immer wieder irritiert ist, daß auch gebridgte Interfaces ihre LL-Adresse haben/behalten:

root@l2tp-ber01 ~ # brctl show br01
bridge name     bridge id               STP enabled     interfaces
br01            8000.02caffee0104       no              l2tp103-103
                                                        l2tp104-104
                                                        l2tp118-118
                                                        l2tp122-122
root@l2tp-ber01 ~ # ip addr show l2tp103-103
34: l2tp103-103: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1364 qdisc fq_codel master br01 state UNKNOWN group default qlen 1000
    link/ether 3e:75:0e:16:4d:ce brd ff:ff:ff:ff:ff:ff
    inet6 fe80::3c75:eff:fe16:4dce/64 scope link 
       valid_lft forever preferred_lft forever
root@l2tp-ber01 ~ # ip addr show l2tp104-104
35: l2tp104-104: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1364 qdisc fq_codel master br01 state UNKNOWN group default qlen 1000
    link/ether fe:21:4c:41:fd:01 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc21:4cff:fe41:fd01/64 scope link 
       valid_lft forever preferred_lft forever

Ist wegen der Sonderbedeutung fe80::/64 aber wohl egal.

8

Wir lösen das mit logical-in. Die übrigen Teilnehmer der Bridge können nicht untereinander kommunizieren. Alles muss durch Batman.

9

Ich verstehe dass das funktioniert, aber ich verstehe nicht, warum jemand das so tun sollte. Das ist nicht robust und funktioniert nur wenn entsprechende Firewallregeln aktiv sind. Ich verstehe natürlich sofort, dass das möglicherweise historisch so geworden ist.

10

Man kann die L2TP-Interfaces nicht direkt ins Batman hängen, weil das häufig abstürzt, wenn ein Interface entfernt wird. Zumindest war es früher so. Falls das gelöst ist, kann die Brücke weg.