Newsgroup: it.comp.os.linux.sys
Titolo: Limitare multicast vrrp

Esiste un modo per limitare il traffico multicast di vrrp
evitando di mandarlo in giro per la rete.
non ricordo più dove ho letto di questa cosa, mi sapete
illuminare? Vorrei fare in modo che il traffico venga
inviato solo ad un host, evitando, se possibile, una vlan
dedicata tra i due nodi.
So che si fa, ma non ricordo come.

 evitando di mandarlo in giro per la rete.
Definisci "mandarlo in giro per la rete".
Il traffico multicast di VRRP avviene verso 224.0.0.18, che è
non-routato per definizione (tanto che di norma i relativi datagrammi
hanno TTL=1).
Quindi non "va in giro per la rete", ma viene immesso solamente sul
local-link (aka: broadcast domain).
Parti dalla base: quale è il problema?
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Parti dalla base: quale è il problema?
Fare in modo che gli host conessi dentro lo stesso broadcast domain
non vedano traffico VRRP.
Tant'è che ho parlato appositamente di VLAN proprio per suddividere il
broadcast, ma ho letto in giro di poter limitare il traffico VRRP verso
un singolo host, probabilmente non facendolo annunciare in multicast
ma in unicast verso un neighbor ben preciso.

 ma in unicast verso un neighbor ben preciso.
A parte che non credo Cisco lo supporti (di norma uso HSRP, però, quindi
ammetto impreparazione al riguardo), io eviterei sentitamente, per
semplicità di manutenzione.
Soprattutto se nello stesso segmento devi avere più di 2 gateway in
funzione, poi ci diventi scemo...


 funzione, poi ci diventi scemo...
Si, l'avevo previsto, ma difficilmente ci saranno gateway.
Eventualmente, come posso ridondare il firsthop senza vrrp e senza
configurare il client?

 configurare il client?
Con qualsiasi meccanismo di failover, mi verrebbe da dire.
Heartbeat (il vecchio) consente di usare unicast per il dialogo, per dire.
Mi pare un po' ammazzar mosche con gli ICBM, ma se credi...


 Mi pare un po' ammazzar mosche con gli ICBM, ma se credi...
Ok, allora resto con vrrp che ho sempre usato.
Mi confermi quindi che avere il traffico vrrp che gira nel dominio
è "normale" e del tutto comprensibile?

 Parti dalla base: quale è il problema?
Il problema è che sul router VRRP mi terminano le VLAN dei clienti.
Alcuni di questi clienti hanno un solo IP ed assegno una sorta di
punto-punto /30 con la rispettiva VLAN.
Fin qui tutto ok, se non fosse che la punto-punto (almeno lato mio)
deve essere ridondanta, ovvero il mio indirizzo (supponiamo il .1)
deve essere un virtuale di VRRP.
Avendo una p-t-p vrrp non è in grado di comunicare con l'altro gemello,
visto che non è presente sulla stessa subnet.
Cercavo quindi di trovare un modo per limitare lo spreco di IP (servono
almeno 3 IP per ciascuna istanza VRRP, uno per il virtuale che "gira"
tra i due nodi, uno per il nodo1 ed uno per il nodo2.
Segregando in VLAN, devo mettere dentro la stessa vlan anche gli ip dei
nodi. Sfiga vuole che VRRP invia in multicast solo tramite l'interfaccia
sulla quale gira il virtual address, indipendentemente dal source
address impostato per gli hello, quindi, o metto 3 ip per ciascuna
vlan e perdo le punto-punto (oltre che diventa un macello assurdo
da gestire), oppure vedo di escogitare qualche cosa con i gruppi, in
modo da gestire tutte le istanze tramite un singolo gruppo in ascolto
sulla ethernet fuori vlan (quindi avrei due ip fuori vlan per tutta
la configurazione vrrp ed un solo ip virtuale per ciascuna vlan).

 sulla quale gira il virtual address
Ed è un bene che sia così. Altrimenti un nodo che perde connettività per
la VLAN dove sta il cliente ma non con l'altro nodo (con cui comunica su
una VLAN diversa) non sarà mai visto come "failed"...


 una VLAN diversa) non sarà mai visto come "failed"...
hai ragione, quindi non posso nemmeno usare i gruppi.
E quindi? Come si fa? Devo usare obbligatoriamente 3 ip
per ciascuna VLAN? devo assegnare come minimo una /29.
Un enorme spreco.
Oppure devo piazzare un alias con degli IP privati, ma non
vorrei che ciò arrecasse qualche problema nel routing, visto
che in tal caso (ho già provato) tramite un traceroute viene
preso in considerazione l'ip privato.
così per intenderci:
eth0.10   = 
1.1.1.1/30
eth0.10:1 = 
10.0.0.1/30
1.1.1.1 è il default gw per il cliente, e gira sui due nodi.
10.0.0.1 è l'ip del primo nodo, il secondo avrà .2 e sarà
la 'fonte' degli hello.

 Un enorme spreco.
E' parte del costo della ridondanza, IMHO...


 E' parte del costo della ridondanza, IMHO...
Mi sta bene, ma allora meglio usare gli alias magari con
ip pubblici sempre punto-punto tra i due nodi.
in questo modo, il virtuale sarà sempre una /30 ed i miei
nodi comunicano con una loro /30 appoggiata sulla stessa vlan.
stesso numero di IP 'sprecati' ma con una /30 lato cliente.
usare ip privati tra i due nodi può avere implicazioni
ne routing?
Dovrebbero servire solo per il traffico vrrp.

 ne routing?
Mai provato, sinceramente.
Ipotizzando che il gateway VRRP ridistribuisca in IGP, dovresti
accertarti del fatto che la rete del VIP sia iniettata in IGP come
directly connected.
Significa quantomeno che il router passivo non inietta la rotta (nè la
directly connected nè la eventuale static alla rete delegata al cliente,
dato che il next-hop è irraggiungibile in assenza del VIP) fino a che
VRRP non cambia di stato, con il risultato di avere un tempo di
convergenza lievemente dilatato, ma sarebbe il problema minore.
Suggerisco di fare un po' di test...


 Suggerisco di fare un po' di test...
Funzionare funziona, ho fatto dei test ieri, il problema è
solo uno: con il traceroute vedo attraversare l'ip locale e non
il VIP. Sembra funzionare tutto correttamente, ma non so se questo
possa portare a problemi.
Ad esempio:
internet
miogateway
10.0.0.1
ipcliente
tutti ip pubblici tranne quel 10.0.0.1. In realtà quella macchina
dispone del VIP, ed il traffico passa di li proprio perchè il VIP
è il default gw.
Non ho idea se sia solo un fattore estetico o possa portare a
malfunzionamenti.

 malfunzionamenti.
Le ADSL di Telecom hanno avuto una configurazione simile per anni (non
so se ce l'abbiano ancora), quindi propenderei per la prima...


 so se ce l'abbiano ancora), quindi propenderei per la prima...
Si ma mi pare una porcata.
Comunque ho notato che se inserisco una subnet pubblica anzichè quella
privata, il traceroute mostra come hop il VIP e non il real ip del nodo.
Se invece metto una subnet privata, il traceroute mostra il real ip del
nodo che sta attraversando e non il VIP.
Cosa può essere? Non saprei spiegarmi il perchè.
(non centra niente: una punto-punto ipv6 è una /126 ? 
Ad esempio ::1:1/126 e ::1:2/126 ?)

 Ad esempio ::1:1/126 e ::1:2/126 ?)
Qui apri una diatriba lunga...
In IPv6 non esistono indirizzi di network e broadcast, quindi puoi farlo
anche con una /127: due indirizzi e basta.
Alcuni hanno documentato problemi con /127 e usano /126 come con IPv4.
Alcuni altri sostengono che essendo IPv6 costruito attorno al concetto
di reti da /64, anche le ptp devono essere /64
Altri ancora usano cose intermedie per mera questione di comodità.
Tipicamente una /112, dato che in tal modo hai indirizzi allineati agli
ultimi due byte, che rendono più facile identificare le reti di
appartenenza "a vista"...
Io uso /126, per quel che vale...


 Alcuni hanno documentato problemi con /127 e usano /126 come con IPv4.
Il /127, ad un rapidissimo test, non me lo accetta.
Ecco il perchè della domanda sulla /126