Vrack 3 + RIPE IP Block

LVI 2018-05-15 19:41:56 UTC #1

Bonjour,

Je m'intéresse s'il y a une solution pour vrack 3 (si l'ID de vrack est pn-NNNNN) et IP failover associé au vrack.

Dans ma situation,
- Un vrack (pn-*****, donc vrack version 3)
- Un IP Failover /29 (CA-BHS)
- Deux serveurs dédiés (chacun a deux NICs ix0 et ix1, situés CA-BHS)

Le vrack semble bien, parce que deux serveurs peuvent communiquer avec IP privé via ix1, mais l'IP Failover n'est pas utilisable.

Justement en désactivant ix0 pour que le serveur forcement puisse utiliser ix1,

ifconfig ix0 delete
ifconfig ix0 down
ifconfig ix1 down
ifconfig ix1 inet IPFAILOVER netmask NETMASK broadcast BCAST
route add default GATEWAY
ifconfig ix1 up

Alors ça donne aucune connexion (ping GATEWAY timeout, arp de GATEWAY n'est pas résolu).

Effectivement, le ping de ma maison vers GATEWAY est marche, donc je pense que le router est prêt, mais ix1 qui est connecté au vrack ne peut pas communiquer au GATEWAY actuellement.

S'il y a quelqu'un qui peut utiliser vrack3 + IPFailover, j'aimerais savoir comment vous avez configuré.

Merci d'avance.

TBC_Ly0n 2018-05-15 21:44:46 UTC #2

Salut,

C'est trivial... Non, je déconne, c'est capillotracté au possible.
Néanmoins, vu le nommage de tes interfaces réseau, ça laisse supposer que c'est du FreeBSD que je ne connais pas pour savoir si c'est réalisable sur ce type d'OS. D'après mes recherches, ça devrait l'être.

Chez OVH :

Les IP Failover ne peuvent être assignées qu'à une IP (exit le bloc RIPE /29)
Les paquets sortants par ixX doivent sortir avec l'IP source de ixX (sous peine de générer des anomalies réseau qu'OVH ne laissera pas passer)
Dans la majeure partie des cas, une seule route par défaut est définie par serveur

Néanmoins...

On peut définir plusieurs tables de routage
On peut spécifier les règles qui définissent quand une table de routage doit s'appliquer

Ce qu'il faut réaliser :

une table de routage pour ix0
une table de routage pour ix1
des règles qui définissent les cas dans lesquels les tables sont utilisées.

En fait, il faut chercher "two defaults gateways" pour trouver quelques sources intéressantes. On tombe sur ce genre de messages : https://forums.freebsd.org/threads/multiple-ips-in-different-subnets-default-routing.50699/

Sur du Linux, il y a plus d'exemples... Tant pis pour toi !

LVI 2018-05-16 06:19:13 UTC #3

Bonjour TBC_Ly0n,

(j'ai changé le sujet RIPE IP Block au lieu d'IP Failover)

Effectivement, comme j'ai montré que

ifconfig ix0 delete
ifconfig ix0 down
En FreeBSD, ces commands effacent le tableau de routing. Alors, dès que ix1 est configuré et activé
ifconfig ix1 inet IPFAILOVER netmask NETMASK broadcast BCAST
route add default GATEWAY
ifconfig ix1 up
seul route ix1 est défini.

Donc à partir cet étape, tous les packets sortent via ix1 vers GATEWAY.
De plus, comme vous avez indiqué, FreeBSD a une solution similaire "setfib" comme Linux pour que le OS puisse avoir plusieurs tableaux de routing.

C'est le tableau de routing

Routing tables (fib: 1)

Internet:
Destination        Gateway            Flags     Netif Expire
default            GATEWAY            UGS         ix1
127.0.0.1          link#3             UH          lo0
SERVERIP/24        link#1             U           ix0
RIPEIPBLOCK/29     link#2             U           ix1

Pour voir que tous les packets sortent via ix1,
root@HOST:~ # tcpdump -i ix1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ix1, link-type EN10MB (Ethernet), capture size 262144 bytes
^Z
Suspended
root@HOST:~ # bg
[1] tcpdump -i ix1 &
root@HOST:~ # /usr/sbin/setfib 1 ping GATEWAY
PING GATEWAY (GATEWAY): 56 data bytes
03:28:57.078906 ARP, Request who-has GATEWAYADDR tell RIPEIPdeSERVER, length 28
03:28:57.079606 ARP, Reply GATEWAYADDR is-at 10:f3:11:5b:7c:f5 (oui Unknown), length 46
03:28:57.079613 IP RIPEIPdeSERVER > GATEWAYADDR: ICMP echo request, id 35229, seq 0, length 64
03:28:58.142445 IP RIPEIPdeSERVER > GATEWAYADDR: ICMP echo request, id 35229, seq 1, length 64
03:28:59.205990 IP RIPEIPdeSERVER > GATEWAYADDR: ICMP echo request, id 35229, seq 2, length 64

Donc je pense que le routing est bien configuré.

De plus, maintenant je trouve que ARP de GATEWAY est résolue comme 10:f3:11:5b:7c:f5 est trouvé, mais le gateway ne réponds pas toujours. (Maleheuresement OVH support ne m'a pas répondu.)

En tout cas merci pour votre aide.

TBC_Ly0n 2018-05-16 07:43:01 UTC #4

Pour avoir questionné OVH sur ce sujet, ils ont souvent tendance à dire que ce n'est pas possible (ce qui est partiellement faux, je le fais très bien sous Linux). Il faut ruser, mais ça se fait.

Une fois l'adresse montée sur ix1 (eth1 dans mon cas en fait), je lance cette commande :
/usr/sbin/arping -qc 1 -S $IP -i $INTERFACE $GATEWAY
Ca a l'avantage de forcer la gateway à voir la machine, sa MAC, son IP. il faudra surement adapter la ligne de commande.

Dans ta configuration, par contre, une fois que tu as défini la route par défaut comme étant celle de ix1, tu ne pourras plus utiliser l'adresse IP de ix0. Ca peut être problématique. et c'est là qu'il faut trouver la solution pour avoir une table de routage conditionnée par l'IP source.

LVI 2018-05-16 10:14:13 UTC #5

Merci pour votre réponse.

root@HOST:~ # ifconfig ix1
ix1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=e407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
	ether 00:1e:67:ec:**:**
	hwaddr 00:1e:67:ec:**:**
	inet IPADDR netmask 0xfffffff8 broadcast BCAST 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect (10Gbase-T <full-duplex,rxpause,txpause>)
	status: active
root@HOST:~ # /usr/sbin/setfib 1 netstat -rn
Routing tables (fib: 1)

Internet:
Destination        Gateway            Flags     Netif Expire
default            GATEWAY	          UGS         ix1
127.0.0.1          link#3             UH          lo0
IPADDR_SERV/24     link#1             U           ix0
RIPEIPBLOCK/29     link#2             U           ix1

Dans le tableau n° 1, on utilise default gateway comme on souhaite.
Alors en utilisant ce gateway, l'arping marche. (l'output est par tcpdump -i ix1)

root@HOST:~ # /usr/sbin/setfib 1 arping -c 1 -S IPADDR GATEWAY
ARPING GATEWAY
05:33:50.331162 ARP, Request who-has GATEWAY tell IPADDR, length 44
05:33:50.331852 ARP, Reply GATEWAY is-at 10:f3:11:5b:7c:f5 (oui Unknown), length 46
60 bytes from 10:f3:11:5b:7c:f5 (GATEWAY): index=0 time=742.357 usec

--- GATEWAY statistics ---
1 packets transmitted, 1 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 0.742/0.742/0.742/0.000 ms

mais pour le ping normal, il ne répond pas.

root@HOST:~ # /usr/sbin/setfib 1 ping GATEWAY
PING GATEWAY (GATEWAY): 56 data bytes
05:34:10.632701 IP IPADDR > GATEWAY: ICMP echo request, id 65287, seq 0, length 64
05:34:11.696035 IP IPADDR > GATEWAY: ICMP echo request, id 65287, seq 1, length 64
05:34:12.759607 IP IPADDR > GATEWAY: ICMP echo request, id 65287, seq 2, length 64
^C
--- GATEWAY ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

En fait, l'autre server (Dans une même RIPE IP Block) via ix1 répond le ping, et broadcast aussi marche. Il semble que le réseau est bien configuré et je pense donc qu'il reste à connecter au gateway.

le ping marche vers l'autre.

root@HOST:~ # /usr/sbin/setfib 1 ping AUTRESERVER

PING AUTRESERVER (AUTRESERVER): 56 data bytes
05:43:16.404712 ARP, Request who-has AUTRESERVER tell IPADDR, length 28
05:43:16.404974 ARP, Reply AUTRESERVER is-at a4:bf:01:**:**:** (oui Unknown), length 46
05:43:16.404981 IP IPADDR > AUTRESERVER: ICMP echo request, id 53258, seq 0, length 64
05:43:16.405171 IP AUTRESERVER > IPADDR: ICMP echo reply, id 53258, seq 0, length 64
64 bytes from AUTRESERVER: icmp_seq=0 ttl=64 time=0.478 ms

le packet broadcast est bien arrivé.

05:43:21.672142 IP AUTRESERVER > vrrp.mcast.net: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
05:43:22.672376 IP AUTRESERVER > vrrp.mcast.net: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20
05:43:23.672616 IP AUTRESERVER > vrrp.mcast.net: VRRPv2, Advertisement, vrid 1, prio 150, authtype simple, intvl 1s, length 20

En tout cas, j'essaierai d'utilise l'OS de rescue mode Linux pour soigneusement intervenir le routing.

LVI 2018-05-17 20:16:51 UTC #6

Enfin, le problème est résolu.
L'OVH a déclaré qu'il y avait un bug dans routers.
D'après que l'intervention est terminée, tout le réseau vrack est bien marche.

Merci!

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVH Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres OVH Community.