Newsgroup: it.comp.reti.ip-admin
Titolo: Dubbio su ARP

Supponiamo di avere due switch connessi ad un singolo server
mediante bonding.
Uno dei due switch sarï¿œ attestato sul link in standby.
In condizioni normali, il traffico in ingresso sarï¿œ
instradato tramite lo switch 'primario', visto che
il link in standby non emette traffico, lo switch in
standby non riceverï¿œ mai le risposta ARP da parte del
server, di conseguenza non ï¿œ al corrente di chi c'ï¿œ
connesso alla porta in questione.
Il primario muore, quello in standby si attiva.
Si verifica questa situazione:
mac address in cache sia sul primario, che sul secondario.
Dopo quanto il primario si accorge che il server non ï¿œ
piï¿œ li ricalcolando la tabella ed eliminando il mac?
Lo fa subito appena vede un cambio di stato della porta?
(cavo scollegato, porta rotta, nic rotta e cosï¿œ via)
Altrimenti entrambi gli switch risponderanno sempre alle
richieste per il mac address in questione, quelle sullo
switch di standby andranno a buon fine visto che il
server ï¿œ connesso li, le altre no, dato che il server
non ï¿œ fisicamente connesso ma il mac ï¿œ ancora in cache.
La topologia ï¿œ questa:
   sw1       sw2
+-----+   +------+
+-----+   +------+
    \         /
      \     /
        \ /
        | |
      +------+
      +------+
       server
Questo discorso vale senza il link di collegamento tra i due switch.
Se ci fosse tale link, lo switch ex-master riceverebbe un update
arp proveniente dal server transitato dallo switch in standby
aggiornando le proprie tabelle.
Ma senza link, che succede?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Ma senza link, che succede?
Che avrai grossi problemi anche normalmente, dato che una macchina con
il link attivo su sw2 (magari perchè la NIC su sw1 è andata a donnine)
non riuscirà a parlare con nessuno di coloro i quali hanno attivo il
link su sw1...
-- 
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/

 link su sw1...
Hai ragione, ma io ho dei 2960-24TT-L, le due porte giga o le
mando al core o le metto tra gli switch.
Però aspetta, io ho anche una sorta di distributore:
    sw1       sw2
  +-----+   +-----+
  +     +===+     +
  +-----+   +-----+
     \   / \  /
     +---+  +---+
sw3 +---+  +---+ sw4
       \      /
       +------+
       +------+ server
server 1 comunica con sw3
server 2 comunica con sw4 perchè è morta la scheda.
se il server 2 vuole comunicare con server1, sw4 non
ha idea di dove esso si trovi, quindi fa un flood
anche verso sw1 ed sw2, i quali, avendo tutti i link
attivi anche verso sw3 recapiteranno il pacchetto.
in pratica:
server2 -> sw4 -> sw1+sw2 -> sw3 -> server1
In questo modo sw3 ed sw4 non si parlano perchè
le due uplink sono in etherchannel verso uno stack
composto da sw1 ed sw2, ma potranno comunicare
ugualmente tra loro facendo il giro lungo, ovvero
attraverso il distributore (che è messo li apposta)
Il link tra sw3 ed sw4 mi farebbe evitare il routing
attraverso il distributore, ma non avendo abbastanza
porte non posso farlo. (meglio fare un giro più lungo
full-gigabit che creare un etherchannel da 400mbit, imho)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 
In questo caso, un link tra sw3 e sw4 sarebbe completamente inutile,
dato che auspicabilmente avrai configurato STP affinchè sw1 e sw2 siano
root e backup, quindi un eventuale tra sw3 e sw4 sarebbe sempre in block...


 root e backup, quindi un eventuale tra sw3 e sw4 sarebbe sempre in block...
... sw1 ed sw2 sono in stack, alla fin fine è come un singolo switch.
il collegamento che vedi è lo stack, non una connessione tradizionale.
Quindi tornando al punto di prima, io non ho (non vorrei avere) STP,
pertanto, chi flusha la tabella di eventuali altri switch?
In teoria non ci sarebbe bisogno di un flush totale, se non cambiando
l'intera topologia, ma non è il mio caso. I punti critici li faccio
in stack, quindi la topologia non dovrebbe mai cambiare. Se cambia è
perchè tutta la rete è crollata.
O mi sfugge qualche cosa?

 O mi sfugge qualche cosa?
Sì: di rivedere il funzionamento e le opzioni di STP (e/o, meglio, di RSTP).


 Sì: di rivedere il funzionamento e le opzioni di STP (e/o, meglio, di RSTP).
Direi di si.
Però, rimuovendo STP, perchè superfluo in questo caso, rimuovendo
(obbligatoriamente) il link tra i due switch, i problemi di ARP non
dovrebbero più verificarsi, giusto?
Se il server1 comunicasse con sw3 mentre il server2 comunicasse con sw4,
il risultato sarebbe un giro più lungo dei frame, che transiterebbero
tramite il centrostella. Invece, a parità di switch (ovvero situazione
normale con solo sw3 attivo per tutti i server) il traffico sarebbe
sempre gestito da sw3 stesso.
Non credo ci sia altro da considerare, a questo livello.
Così facendo dovrei essere esente da SPOF.

 configurata, meno roba rischia di far casino.
Personalmente STP mi sta sulle balle, ma mi sta più su le balle che si fotta
tutto per un loop (e avviene più spesso di quanto si creda dalle mie parti).
Per quanto riguarda il protocollo in più questo è assolutamente ininfluente
sotto ogni aspetto, di performance, di traffico e di qualsiasi altra cosa.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 sotto ogni aspetto, di performance, di traffico e di qualsiasi altra cosa.
Si, è vero, il rischio dei loop è elevato (anche perchè ci vogliono due
secondi esatti a farne uno) quindi credo che sarò costretto ad attivare
RSTP più per dormire bene di notte, che per altri motivi.

 dovrebbero più verificarsi, giusto?
Sbagliato. Diventano peggio.
In caso di STP classico, il cambio di stato della porta causa un
topology notification, che forza tuttli gli switch della rete a far
scadere la mac-address-table in 15 secondi.
In caso di STP cisco-style, una configurazione ragionata e non buttata a
caso (studiati a cosa serve e come funziona "uplinkfast") porta al
refresh dei soli mac-address coinvolti dal cambio di topologia, a costo
sostanzialmente nullo (un paio di frame "gratuiti" inviati in multicast
per aggiornare gli instradamenti) ed in tempo praticamente nullo.
Nel caso di RSTP, più o meno la stessa cosa, salvo dettagli, e più o
meno gratis.
Nel caso di assenza completa di STP, si aspetta pazientemente che le
macchine stesse inviino qualcosa per loro grazia (che arriverà
inevitabilmente da una porta diversa dalla precedente, causando
aggiornamento dei dati in CAM), oppure, nel peggiore dei casi (con
macchine accedute prevalentemente dall'esterno, ma che non generano
molto traffico "spontaneamente") che i dati di instradamento "in panza"
a tutti gli switch della rete scadano, con una attesa anche di svariati
minuti durante i quali le macchine sono irraggiungibili...


 minuti durante i quali le macchine sono irraggiungibili...
Ecco, questo volevo sapere.
Quindi la situazione ancora non quadra.
Anche attivando STP, nel mio caso non ci sarà mai un cambio di
topologia, perchè ci sarà sempre un link attivo e mai un loop.
per fa scattare STP dovrei generare un loop manualmente.
I 4 switch sono in stack e protetti da dei collegamenti in etherchannel.
A meno di interventi manuali alla pene di segugio, li i loop non ci sono
e di conseguenza STP sta zitto e buono.
A valle, però, ho dei server con le nic in bonding active/passive.
Su tutti forzo la nic associata ad sw3 ad essere la primaria, quindi in
condizioni normali, non sussiste alcun problema.
Al server2 muore la nic, l'altra si attiva.
A livello STP la topologia non è cambiata, quindi nessuno forza un
flush delle tabelle. Resto sempre punto a capo.
sw3 aveva il server2 in tabella, la nic è morta, se questo evento
fa scattare (deve essere un must al 100%, niente condizionale) un
flush delle tabelle o quantomeno la rimozione dei mac associati a
quella porta, ok, il problema non sussiste, ma se nessuno forza il
flush su sw3, finchè il server 2 non parla con il mondo esterno, le
tabelle resteranno 'sballate'.
Non capisco in che modo l'uplinkfast possa aiutare. Il problema è
a valle in questo caso. Se il guasto alla nic o la rimozione del cavo
forzasse il flush, sarei a posto, altrimenti boh, non saprei come fare.

 Non capisco in che modo l'uplinkfast possa aiutare.
No, l'uplinkfast ti serve per gli uplink, appunto.
Vedi se
http://cisco.biz/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094641.shtml
chiarisce quando e come (e perchè) si usa.


 chiarisce quando e come (e perchè) si usa.
Stavo anche guardando il Link-State tracking, ma non mi si visualizzano
le immagini della documentazione.
Te questa la vedi?
http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_46_se/configuration/guide/swethchl_files/141680.jpg

 altra cosa.
Tra l'altro STP è abbastanza trasparente da configurare... voglio dire, per 
una configurazione base non deve fare nulla o quasi.
-- 
Vide

 una configurazione base non deve fare nulla o quasi.
Quello che mi auguro.
Anche perchè nel mio caso, non avrei alcun link in blocking visto che
i due centrostella sono in stack ed uno dei due link sulle nic è
in blocking a livello di bonding, quindi non ci sono loop.
Però, a parte la maggiore sicurezza che ti può dare STP nel caso
un pirla facesse un loop (cosa non da poco), nel mio caso pratico,
STP non dovrebbe essere strettamente necessario, visto che in caso
di guasto ad una delle nic, o guasto alla porta dello switch di accesso
o guasto al cavo, il bonding farà lo switch sulla seconda scheda ed
invierà dei gratuitous arp che si propagheranno per tutto il dominio
di broadcast aggiornando di fatto le tabelle arp e di conseguenza
i dati in CAM.
Dal punto di vista teorico, STP non dovrebbe essere necessario, giusto?
Mi interessa sapere questo o se ho dimenticato qualche passaggio
fondamentale come implementazione.
Poi attiverò STP ugualmente per una maggiore sicurezza, ma vorrei sapere
a priori se il sistema funzionerà grazie al bonding ed ai gratuitous arp
o se funzionerà solo grazie ad STP.


una configurazione base non deve fare nulla o quasi.
Dicono tutti cosï¿œ, fino al primo guasto incomprensibile. <g>
-- 
ciao, |
Marco | The Internet is full. Go away.  -- Joel Furr

 /me tocca ferro (dello switch)
LOL.
Però, nessuno mi ha ancora dato conferma se in caso di gratuitous arp
emessi dal bonding, STP è necessario ugualmente.
Vorrei approfondire la cosa, perchè sulla carta non mi sembra
necessario. (per questo singolo scopo)

 necessario. (per questo singolo scopo)
Tecnicamente, finchè non ci sono ridondanze nei link, no.
Praticamente, in qualsiasi rete con più di uno switch togliere STP
significa andare in cerca di guai.
Pensa solo a che accade la prima volta che canni la configurazione di
uno degli etherchannel.


 uno degli etherchannel.
Mi sta bene, ma lasciamo per un attimo da parte STP inteso come
"protezione loop".
Come si diceva l'altro giorno, se mi muore una delle nic sul server,
lo switch in standby diventa attivo per quel server.
Se il server non comunica nessuno, nessuno switch facente parte dello
stesso dominio di broadcast aggiorna le proprie tabelle, pertanto i
pacchetti continuerebbero ad essere inoltrati allo switch vecchio.
Ma visto che il bonding genera dei grtuitous arp quando cambia la
nic attiva del bonding, il problema di cui sopra non sussisterebbe.
Ci penserebbero i gratuitous arp a forzare gli update delle tabelle.
Rimuovendo l'invio di ARP in caso di cambio link, ma attivando STP,
tutto funzionerebbe ugualmente, perchè in tal caso sarebbe STP a
far forzare le tabelle degli switch a causa di un topology change.
Ho capito bene? E' così?
Se si, in questo preciso scenario, STP ed i gratuitous arp emanati
dal bonding porterebbero ad avere lo stesso risultato ma con modalità
differenti.

 differenti.
Ma guarda: se pigli la tua macchina e togli il bonding.
Metti invece le due interfacce in bridge e assegni l'IP al bridge.
Bada di configurare STP in modo che il bridge in questione non possa
*mai* diventare root dello spanning tree, e assicurati che parli la
stessa versione di STP usata dagli switch.
Hai ottenuto una ridondanza delle NIC senza usare bonding (sì, "sucks,
but works"...)


 but works"...)
Ma il problema non è come avere ridondanza delle NIC senza bonding,
bensì capire se per quanto riguarda "la questione mac" come da inizio
thread, un gratuitous arp emesso dal driver del bonding possa sostituire
in toto il topology change di STP.
Entrambi portano ad un update delle tabelle CAM
In questo momento è più un esercizio accademico che altro.
Mi serve per capire. Ora mi vado a vedere in che modo STP forza 
l'update delle tabelle CAM.
Le svuota e basta? Di conseguenza al primo frame ricevuto sullo switch,
tale switch opererà in flooding, riaggiornando, di fatto, le proprie
tabelle. Se così fosse, un gratuitous arp sarebbe preferibile, perchè
stando alla documentazione cisco, un ARP ricevuto su una porta
differente da quella presente nelle CAM, aggiornerebbe il record di
solamente tale mac e non di tutta la tabella.

 l'update delle tabelle CAM.
La ricezione di un topology change ha l'effetto di ridurre il TTL delle
entry in CAM a 15 secondi.
Quindi dopo 15 secondi al massimo tutti gli switch hanno perso qualunque
nozione della posizione di qualsiasi MAC (esclusi i propri, ovviamente)
e iniziano a trattare i relativi frame in flooding.
In una rete sufficientemente ampia, avrai sempre una macchina da qualche
parte che si spegne o si accende e un link che cambia di stato. Il
risultato è che hai tutta la rete che lavora perennemente quasi come se
come fosse fatta di HUB.
Per evitare questo problema, Cisco ha introdotto il concetto di portfast
per le singole porte.
Mettere una porta in modalità portfast significa indicare espressamente
allo switch che lì non attaccherai mai un altro switch.
Quindi la porta viene "tirata su" appena c'è link, senza aspettare di
vedere se dalla stessa arrivano BPDU e cosa dicono.
E il cambio di stato di una porta in portfast *non* causa topology change.
Suggerisco *vivamente* di prenderti un buon testo sulle reti L2, o
-meglio ancora, se te lo paga qualcuno- frequentare un corso dedicato
come ad esempio il BCMSN per Cisco.
Aspettarsi di imparare 'sta roba per via empirica o -peggio ancora-
aspettarsi di poter progettare una rete di una certa dimensione con
cognizione di causa senza avere dimestichezza con i dettagli di questo
livello (che è l'ABC: le cose realmente complesse sono ben altre...) non
porta lontano...


 porta lontano...
non devo progettare nulla, e proprio perchè voglio imparare alcune cose
sto cercando di capire se in questa precisa situazione (fregandomene dei
loop o altre problematiche) il metodo arp possa essere sufficiente o se
STP si rende necessario ugualmente.
Da quel che conosco, il metodo ARP basta ed avanza ed anzi, a livello
teorico, sembra anche essere maggiormente ottimizzato per i motivi di
cui sopra. (non ha senso svuotare tutte le CAM per 1 singolo cambio di
porta).
Come hai detto te stesso in qualche thread precedente, non posso nemmeno
usare il portfast sulle porte in bonding, altrimenti non si genererebbe
nessun topology change, quindi non avrei nemmeno possibilità di fare
ottimizzazioni lato STP.

 rimozione dei dati in CAM.
Oppure vedi come funziona e capisci che hanno due finalità diverse. E
che il bonding, dovendo essere indipendente dalle features degli switch,
si arrangia già da solo, STP o non STP.


 si arrangia già da solo, STP o non STP.
Non mi fraintendere.
Io *SO* che hanno due finalità differenti.
Ma in *questo* caso, il risultato è il medesimo, o tramite STP ed il
suo topology change che (tra le tante cose) fa eliminare anche i dati
in CAM, o tramite un gratuitous arp che li aggiorna.
Il mio obiettivo, in questo esempio, è rimuovere dalle CAM la vecchia
associazione MAC/Porta. Devo fare solo questo, al resto ci penso dopo
aver finito di leggere il funzionamento di STP. 
O la aggiorno tramite il sistema ARP, o faccio svuotare tutto tramite
STP.
Vorrei sapere solo questo, è un dubbio che non riesco a colmare da solo
e mi servirebbe una conferma.

 STP.
Visto che limiti espressamente la trattazione allo scenario di bonding e
che abbiamo già detto che il codice di bonding lo fa da solo, tu non
devi fare proprio nulla.
A meno che tu non stia scrivendo in driver per il bonding.


 A meno che tu non stia scrivendo in driver per il bonding.
Voglio sapere se il risultato in questo singolo caso è il medesimo,
con la differenza che sempre in questo singolo caso, la soluzione
con ARP, sulla carta, potrebbe essere più ottimizzata dato
che comporterebbe l'update dei soli dati modificati e non lo
svuotamento totale della tabella.
Quindi tornando al discorso iniziale, ma mi hai già risposto,
salvo loop, dovrebbe bastare un normale bonding con gratuitous arp
senza STP.
Che poi STP faccia tante altre belle cose e che sia consigliabile
attivarlo anche in questa situazione, è tutto un altro discorso.
Dimentico qualche cosa? se muore una nic, come da domanda iniziale,
fa tutto il driver del bonding, senza dover scomodare altri protocolli,
giusto? Quindi il problema che avevo sollevato ad inizio thread (ovvero
la non raggiungibilità del server) non dovrebbe sussistere perchè
gestito direttamente dal bonding.


 meno gratis.
Quindi tu suggeriresti di attivare STP (o RSTP) e magari mettere le
porte direttamente connesse ai server in portfast?
Mi può star bene, ma avrei comunque un problema collaterale nel caso
un pirlone mettesse in bridge le due nic del server (generando un
bel loop tra switch) [1] o collegasse una porta impostata a portfast 
(quindi che ignora le BPDU e va automaticamente in forwarding) 
ad un altro switch.
Non avrei alcuna protezione, perchè adesso come adesso la rete è già
priva di loop, avendo stack ed etherchannel, STP servirebbe per farmi
dormire sereno la notte, ma se inizio a mettere le 24 porte connesse
ai server in portfast, mi ritroverei con un STP funzionante a metà:
24 porte soggette a potenziali loop (quelle in portfast) e 2 porte
non soggette a loop, che però sono sempre utilizzate perchè in
etherchannel.
Diciamo che un errore umano è più probabile che si verifichi nel
collegare una porta vuota di uno switch ad una porta vuota dell'altro
switch, piuttosto che staccare volutamente uno degli uplink per
connetterlo volutamente ad una porta in portfast.
Quindi probabilmente conviene lasciare tutte le porte in modalità
"standard" e far calcolare l'albero ad RSTP anche in fase di boot 
dello switch.
O no?
[1] Pensandoci bene, se si dovesse formare un loop tra la porta in
portfast dello switch1, il server e la porta in portfast dello switch2,
STP dovrebbe comunque proteggere dai loop disattivando una delle uplink
degli switch e reinstradando tutto usando il server proprio come bridge
facendo transitare tutto il traffico li in mezzo.

 bel loop tra switch)
spanning-tree portfast bpduguard default


 spanning-tree portfast bpduguard default
Interessante, non avevo visto questa possibilità.
Così facendo, la porta inizia subito in modalità
forwarding (per via del portfast), se però la
porta dovesse ricevere una BPDU significa che si
è presentato un loop ed il bpduguard mi ammazza
la porta.
Conviene quindi tenere sempre attivo STP, mettere
le 24 porte connesse agli host in portfast, attivare
il bpduguard su quelle porte e fare affidamento sul
gratuitous arp in caso di cambio NIC visto che una
porta in portfast non emette topology change, da quel
che ho capito.
