giovedì 11 novembre 2010

Configurazione del Port-channel Load-Balancing tra Cisco e server HP

Recentemente mi è capitato di avere difficoltà nel far funzionare correttamente un load-balancing di un port-channel composto da 2 interfacce gigabit ethernet collegate ad un server HP anch'esso configurato con le interfacce aggregate con protocollo LACP.
Sostanzialmente il problema risiedeva nel fatto che nonostante avessi correttamente configurato LACP sia lato switch che lato server il traffico non era bilanciato tra le interfacce. (trasmetteva solo una delle due interfacce).
Ho capito che questo accade perché di default il load-balancing sui Catalyst è configurato di default come src-mac dunque il server trasmette il traffico tramite una sola interfaccia in quanto essendo le interfacce fasciate su un port-channel si presentano con un unico MAC address.
La soluzione è quella di configurare il load-balancing come dst-ip.

switch# conf t
switch# port-channel load-balance dst-ip   (a livello globale è applicato a tutti i port-channel presenti sullo switch)



Verifica

Switch#show etherchannel 1 summary

Flags: D − down P − in port−channel
I − stand−alone s − suspended
H − Hot−standby (LACP only)
R − Layer3 S − Layer2
U − in use f − failed to allocate aggregator
· u − unsuitable for bundling
w − waiting to be aggregated
d − default port



Number of channel−groups in use: 1
Number of aggregators: 1
Group Port−channel Protocol Ports
−−−−−−+−−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
1 Po1(SU) LACP Gi2/0/23(P) Gi2/0/24(P)

mercoledì 20 ottobre 2010

Cisco IOS Embedded Packet Capture

Cisco ha da poco rilasciato una nuova funzionalità per l'IOS 12.4(20)T relativa alla cattura ed all'analisi del traffico, l'EPC (Embedded Packet Capture).

Dal siti Cisco vediamo le caratteristiche:

Features and Benefits
Cisco IOS Embedded Packet Capture provides an additional level of embedded systems management not previously seen in Cisco IOS Software. The feature provides enhanced capabilities beyond those previously enabled in the Router IP Traffic Export feature.
EPC includes:


• The ability to capture IPv4 and IPv6 packets in the Cisco Express Forwarding path


• A flexible method for specifying the capture buffer size and type


• EXEC-level commands to start and stop the capture


• Show commands to display packet contents on the device


• Facility to export the packet capture in PCAP format, suitable for analysis using an external tool such as Wireshark


• Extensible infrastructure for enabling packet capture points


Per informazioni :  http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps9913/datasheet_c78-502727.html



Per vederlo nel dettaglio vi rimando al blog CCIE in 3 months dove è spiegato in modo perfetto:

http://ccie-in-3-months.blogspot.com/2008/07/embedded-packet-capture-how-to-make.html





venerdì 15 ottobre 2010

Strani picchi di CPU sui Catalyst 6509

Ieri ho finalmente scoperto cosa causava degli strani picchi di CPU sui centri stella (Cat 6509).Premetto che  l'andamento della CPU viene monitorato da un ottimo tool chiamato Cacti (cacti dot net), e lo stesso è configurato affinché superata una soglia percentuale di CPU esso invia un email con annesso grafico.
Sostanzialmente dopo una verifica ho riscontrato che se ci si collega allo switch in telnet ed a sua volta si fa telnet ad un secondo switch la CPU raggiunge anche il 65-70%.
Facendo una verifica sul sito Cisco e sui gruppi di discussione Cisco non è emerso nessun BUG noto e comunque in questi casi la TAC Cisco sicuramente consiglierebbe l'aggiornamento ad una versione di IOS più recente.Per il momento eviterò di fare telnet da telnet ma se vi dovesse capitare anche a voi sapete dove andare a fare troubleshooting.
La versione che gira sul mio 6509 è la seguente:


CORE-SW-1#dir
Directory of disk0:/

    2  -rw-   150725900   Jan 5 2010 11:43:34 +01:00  s72033-ipservicesk9_wan-vz.122-33.SXI3.bin

E questo è l'andamento della CPU al momento (normale) , ma controllando i giorni precedenti sono chiari i picchi:


CORE-SW-1#sh processes cpu history
                                                            
    3333333332222222222222222332323333222222222222222222222222
    1124522019999999987878999019180013989887666777566667788978
100                                                        
 90                                                        
 80                                                        
 70                                                        
 60                                                        
 50                                                        
 40     *                                                  
 30 **********************************************************
 20 **********************************************************
 10 **********************************************************
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5  
               CPU% per second (last 60 seconds)
              * = maximum CPU%   # = average CPU%
                                                            
    3333333333333333333333333333333333333333333333333333333333
    4432343442422632124645325436543334542449654534445432241212
100                                                        
 90                                                        
 80                                                        
 70                                                        
 60                                                        
 50                                                        
 40              *     * *  *  **     *    *** *    *      
 30 ##########################################################
 20 ##########################################################
 10 ##########################################################
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5  
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%
                                                                        
    7737333733373377337476737773337443733383347733738373337333733373357333
    9767746475868763787089789667554127766516756877890876667687665685916778
100                                                                    
 90                                                                    
 80 ** *       *  *   * * * ***       *   *   **  * * *   *   *   *   *
 70 ** *   *   *  **  * *** ***   *   *   *   **  * * *   *   *   *   *
 60 ** *   *   *  **  * *** ***   *   *   *   **  * * *   *   *   *   *
 50 ** *   *   *  **  * *** ***   *   *   *  ***  * * *   *   *   *  **
 40 ***** ***************#************************************************
 30 ######################################################################
 20 ######################################################################
 10 ######################################################################
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%




Ho trovato una discussione con un problema simile al mio ma il troubleshooting è stato orientato in un'altra direzione:

https://supportforums.cisco.com/message/1328637


venerdì 8 ottobre 2010

Abilitare entrambe le porte a 10gb sulle supervisor 6 dei Catalyst 4510R

Mi è personalmente accaduto di aver problemi nell'abilitazione di entrambe le interfacce a 10gb presenti sulla supervisor 6 di un catalyst 4510R-E con adattatori 10GBase-SR (X2).
Sostanzialmente se si ha il primo link attivo, la tengiga 5/1, e se si tenta di attivare anche il secondo, tengiga 5/2, questa seconda intefaccia non funzionerà e lo status sarà inactive.
La spiegazione che Cisco fornisce è la seguente:



The TenGig interfaces on the SUP6-E are controlled by a stub ASIC which merges back to a single ASIC within the switch. This creates a limitation to where you can only have one of the TenGig interfaces (per sup) running at line rate. Another limitation to this design is that you cannot mix TenGig and X2 (Gig) at the same time on the same sup.
You can, however, activate both of your TenGig interfaces by placing the switch in a shared backplane mode. This will give you access to both of your interfaces but only in an oversubscribed mode (2:1).
The command to place the switch in shared backplane:
Switch(config)#hw-module uplink mode shared-backplane
After the command is entered (and you reload your switch) you should see something similar to the following for theshow hw-module module port-group command.
Module Port-group Active                         Inactive
-------------------------------------------------------------
   5        1     Te5/1-2                        Gi5/3-6       


E' dunque necessario far si che la scheda abbia un backplane condiviso per avere attive entrambe le interfacce in una modalità denominata "oversubscribed" 2:1       

Dunque basterà inserire il seguente comando:

Switch(config)#hw-module uplink mode shared-backplane

(necessita il riavvio della supervisor)



giovedì 30 settembre 2010

CatOS vs IOS

Spesso capita di trovarsi da alcuni clienti che hanno ancora switch che montano CatOS, questa piccola guida illustra le differenze tra il CatOS ed il nativo IOS:

Cisco ha annunciato l'EOL (end-of-life) per il CatOS, l'ultima versione è la 8.X, il 2009 è stato l'anno
conclusivo della maintenance release ma fornirà supporto fino 2013.

Particolarità del CatOS:
I cambiamenti di configurazione nel CatOS sono scritti nella NVRAM direttamente subito dopo aver digitato il comando
senza dover dare il "write memory".
Tutte le configurazioni sono apportate tramite il caomando "SET" infatti il CatOS è anche chiamato "set based".
Il comando clear annulla un precedente comando.

NB: nei 6509 con a bordo il CatOS bisogna ricordare che esso gestisce il layer2 mentre per il layer 3 (IOS) bisognerà accerdere alla MSFC (tramite il comando session 15)

Particolarità del IOS:

In contrasto al CatOS l'IOs (o native SW) non salva la configurazione in automatico ma è necessario digitare il classico comando copy run start o wr
Se la configurazione non è esplicitamente salvata in caso di riavvio della macchina essa è perduta.
Tutti i comandi di configurazione vengono in "no" seguito dal comando precedentemtne immesso.

Abilitazione di una porta in accesso:

CatOS:

set port name 8/1 porta_vlan2
set vlan 2 8/1

configurazione di porte multiple

set port auxvlan 6/1-48 700

IOS:

interface fast 8/1
descriprion porta_vlan2
swiport access vlan 2
exit
wr

configurazione di porte multiple

interface range fast 6/1 - 48
switchport voice vlan 700



Abilitazione di una porta in trunk:

CatOS:

set port name 8/1 porta_trunk
set trunk 8/1 on isl
clear trunk 8/1 (vlan non necessarie)

aggiunta di vlan nel trunk

set trunk 8/1 (vlan)

IOS:

interface giga 8/1
descriprion porta_trunk
swiport mode trunk
switchport trunk encapsulation isl
switchport trunk allowed vlan 1,2,10-15
exit
wr

aggiunta di vlan nel trunk

switchport trunk allowed vlan add (vlan)

exit

wr

Comandi utili:

CATOS:

set vlan <vlanid> port
set port disable
set port duplex
set port speed
set port jumbo
set spantreeportfast
set qosenable
set port channel
set trunk

show cam dynamic
show channel info or show port channel
show mac
show port <slot/port>
show logging buffer
show modules
show version
show port inline power
show environment power
show environment [temp | cooling]


IOS:

1) switchport
2) switchportmode access
3) switchportaccess vlan <>
shutdown (interface mode)
duplex
speed
mtu 9216
spanning-tree portfast
mlsqos
channel-group <group> mode (interface mode)
switchportmode trunk (vlan database command)

show mac-address-table dynamic
show etherchannelsummary
show interface counters [errors | trunk]
show interface <type slot/port> status
show run interface <type slot/port>
show log
show modules
show version
show power inline
show power
show environment [temp | cooling]

mercoledì 29 settembre 2010

Funzionalità del protocollo Spanning-tree

Spanning Tree Portfast

Il comando mette immediatamente l'interfaccia in Forwarding State dal Blocking State bypassando gli stati di listening e learning.Il comando di usa principalmente su porte dove vi sono connessi host o servers in modo che essi si connettano subito alla rete invece di attendere la convergenza dello spanning tree.
Le interfacce connesse ai pc non ricevono i BPDU.






BPDU Guard

Il comando può essere abilitato sia globalmente sullo switch piuttosto che che per ciscuna interfaccia ma con le dovute differenze funzionali.
A livello globale si abilita su un'interfaccia con già attivo lo spanning tree portfast con il comando spanning-tree portfast bpduguard enable.
Lo spanning tree spegne la porta che lavora in modalità portfast nel caso in cui riceva dei BPDU, se ciò accade per una porta che si trova configurata in port-fast c'è un errore di  configurazione in quanto le porte configurate in port fast non devono ricevere Bpdu e dunque la porta viene messa in error-disable.
A livello d'interfaccia il comando è spanning-tree bpduguard enable (senza portfast).Se l'interfaccia riceve i BPDU va in err-disable.
Il BPDU guard fornisce una riposta sicura allle configurazioni invalide e si usa nei service provider affinchè una porta in accesso (host) partecipi allo spanning tree.
BPDU Filtering

Anche questo comando si può configurare sia a livello globale che a livello d'interfaccia ma vi sono differenze.
A livello globale si configura con il comando spanning-tree portfast bpdufilter default.Questo comando previene che le interfacce che sono configurate in portfast non possano inviare o ricevere BPDU.Lo si configura a livello globale in modo che gli host connessi a queste intefacce non ricevano BPDU, se un interfaccia riceve un BPDU essa perde il suo port-fast e il BPDU filtering viene disabilitato.
A livello d'interfaccia lo si può abilitare con il comando spanning-tree bpdufilter enable anche senza configurare il portfast, in questo modo evitiamo all'interfaccia di ricevere o inviare BPDU.

NB:Abilitare il BPDU Filtering su un'interfaccia equivale a disabilitare lo spanning tree su di essa e pùo generare loops di spanning tree




UplinkFast

Gli switch in una rete gerarchica possono essere raggruppati in backcone,distribution e access.Tutti hanno  2 link verso lo switch maggiore e di questi due link uno è attivo.
Se uno switch perde connettività inizia ad utilizzare il percorso alternativo appena lo spanning tree sceglie la nuova root port.
Abilitando l'UplinkFast con il comando spanning-tree uplinkfast in globale sullo switch acceleriamo la scelta della nuova root port quando un link od uno switch cade o quando lo spanning tree effettua ricalcola.La transizione della root port allo stato di forwarding è immediata saltando il listening ed il learning come dovrebbe essere.
Quando lo spanning tree riconfigura la nuova root port, le altre interfacce trasmettono alla rete dei pacchetti multicast, uno per ogni indirizzo imparato su ciscuna interfaccia.
Si possono limitare questi invii di multicast riducendo il max-update-rate  (default 150 per secondo), se si mette zero la topologia convergerà molto lentamente dopo una perdita di connettività.
NB: Il comando è molto utile con gli switch di accesso e meno consigliato con i core switches.
L'uplinkfast fornisce una rapida convergenza dopo un failure della rete e fornisce load balancing tra link L2 ridondati utilizzando gli uplink groups.Un uplink group è un set di interafacce layer 2 di cui solo una è in forwarding in ogni momento.Nello specifico un uplink group consiste della root port(in forwarding) ed un set di porte in blocking, esso forinisce un percorso alternativo nel caso in cui l'interfaccia in forwarding cada.


Cross-Stack UplinkFast

Per i catalyst 3750 l'uplinkfast è il cross-stack Uplink (CSUF).Esso fornisce una rapida transizione di spanning-tree(convergenza in meno di 1 secondo)per uno stack di switch.
Durante la transizione, un link ridindato alternativo nello stack è messo in forwarding state senza causare spanning-tree loops o perdita di connettività con il core switch.
Il comando è spanning-tree uplinkfast in globale.Il CSUF non fornisce sempre una transizione rapida, a volte impiega 30-40 secondi.
Esso assicura che un link dello stack è eletto come rootpath.

Loop Guard

Si utilizza per prevenire che le root port o alternative possano diventare designated port a causa di un guasto ad un link unidirezionale.Questi funzionalità è efficente se abilitata su tutta la rete
Se abbiamo uno stack da 3 ed ogni switch ha un'interfaccia verso il core, nel caso in cui il primo switch cada si usa il link del secondo come root port e cosi via.(in meno di 1 secondo)
Si configura con il comando spanning-tree loopguard default (a livello globale)

BackboneFast

Backbonefast rileva dei guasti indiretti nel core del backbone, è una tecnologia complemetare all'UplinkFast, che risponde ai problemi sui link direttamente connessi gli switch di accesso.
Esso ottimizza il maximum-age timer, che controlla l'ammontare di tempo che lo switch immagazzina relativo alle informazioni di protocollo ricevute su di un'interfaccia.
Quando uno switch riceve un BPDU inferiore dalla designated port di un altro switch, il BPDU è un segnale che quest'altro switch potrebbe aver perso il suo percorso verso il root switch, ed il backboneFast prova
a trovare un percorso alternativo verso il root switch.
Si abilita con il comando spannig-tree backbonefast in globale, inizia quando una root port o una interfaccia bloccata su uno switch riceve BPDU inferiori dal suo switch designato.Un BPDU inferiore identifica uno
switch che si dichiara sia come root bridge sia come designated switch.
Quando uno switch riveve un BPDU inferiore, significa che il link al quale lo switch non è direttamente connesso (link indiretto) ha fallito(dunque il designated switch ha perso la sua connessione al root switch)
Le regole dello spanning-tree fanno si che lo switch ignori BPDU inferiori per il maximum age time configurato dal comando spanning-tree vlan XX.
Lo switch prova a trovare se ha un percorso alternativo verso il root switch.Se BPDU inferiori arrivano su di una interfaccia bloccata, la root port e le altre interfacce bloccate dello switch diventano percorsi alternativi
verso il root switch.
Se BPDU inferiori arrivano sulla root port, tutte le interfacce bloccate diventano percorsi alternativi verso il root bridge.Se BPDU inferiori arrivano sulla root port e non vi sono interfacce bloccate lo switch pensa di aver perso connettività verso il root switch, causando la scadenza del maximum aging time sulla root port e diventa il root switch in base alle regole dello STP.
Se lo switch ha percorsi alternativi al root switch esso li usa per inviare al root bridge dei RLQ Root link query request.Lo switch invia RLQ su tutti i percorsi alternativi per imparare se un membro dello stack ha un root link alternativoverso il root switch ed attende per un RLQ reply da altri switch della rete oppure dello stack.Quando un membro dello stack riceve una reply RQL da un membro non dello stack su un'intrfaccia bloccata la risposta è destinata ad un altro switch non in stack, esso inoltra il reply packet comunque sia lo stato dello spanning tree dell'interfaccia.
Quando un membro dello stack riceve una reply RQL da un membro non dello stack e la risposta è destinata allo stack. il membro dello stack inoltra la risposta in modo che tutti i membri dello stack la ricevano.
Se lo switch scopre che c'è un path alternativo veros il root, esso fa scadere il max aging time dell'intrfaccia che ha ricevuto il BPDU inferiore,se tutti i path alternativi verso il root indicano che lo switch ha perso connettività al root switch, esso fa scadere il max aging time sull'interfaccia che ha ricevuto il reply RLQ.

Esempio:

3 switch a tringolo a,b e c.Switch a è il root.Se il link tra a e b cade c non può saperlo in quanto non è connesso direttamente ad a.Ma dato che b è connesso direttamente ad a capisce che c'è la disconnessione e elegge se stesso come root ed invia BPDU allo switch
c, identificandosi come root.Quando c riceve BPDU inferiori dallo switch b, capisce che c'è stato un problema.A quel punto il backbonefast permette all'interfaccia bloccata dello switch C di attivarsi (in listen) senza attendere il max aging time scaduto.












Root Guard

La rete L2 di un sp può includere molti switch che non sono gestiti dal service provider.In questa topologia, lo spanning tree può riconfigurare se stesso e scegliere uno switch del cliente come root switch.
Possiamo evitare ciò abilitando il root guard sull'interfaccia dello switch del SP che connette il nuovo switch esterno.Se gli switch operano il multiple spanning-tree (MST),il root guard forza l'interfaccia ad essere la designated port.
Il root guard abilitato su un'interfaccia agisce su tutte le vlan al quale lo switch appartiene, lo si fa tramite il comando spanning-tree guard root (sulla interfaccia)






giovedì 16 settembre 2010

Policy Based Routing PBR

CISCO Policy based Routing (PBR) : route-map
Le Route-map posso essere utilizzate in molte applicazioni , una di queste può essere quella di sovrascrivere la tabella di routing di un router ed influenzare la direzione del traffico dati in due o diversi percorsi
Sotto troviamo un esempio di una Policy Based Routing (PBR) utilizzata per instradare differenti subnet attraverso differenti router.


Istraderemo :
- Pacchetti da 10.20.10.0/24 (vlan 10) a 172.20.10.0/24 tramite Link 2
- Pacchetti da 10.20.20.0/24 (vlan 20) a 172.20.10.0/24 tramite Link 1
- Gli altri pacchetti tramite il gateway 10.20.5.254 sull'interfaccia Gigabit Ethernet 3/48
La Policy based routing nei router Cisco può essere implementata utilizzando le « route-map » che sono poi applicate come policy alle interfacce interessate.
La route-map ha una lista di comandi denominati « match » e « set » dove match definisce i criteri della policy map (access list standard o estese) e dove set definisce le azioni da eseguire in caso in cui vi sia un match dei criteri incontrati.
Modifico il routing verso una sola rete da una particolare subnet che è definita nelle ACL standard. Questa ACL è poi riscontrata nella route-map e applicata come Ip Policy per i cambiamenti di routing nel funzionamento del routing stesso.
Primo passo: Creare le ACL :
BraveHeart-R-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
BraveHeart-R-C(config)# access-list 100 permit ip 10.20.10.0 0.255.255.255 172.20.10.0 0.255.255.255
BraveHeart-R-C(config)# access-list 101 permit ip 10.20.20.0 0.255.255.255 172.20.10.0 0.255.255.255
BraveHeart-R-C(config)# access-list 102 permit ip 10.20.10.0 0.255.255.255 any
BraveHeart-R-C(config)# access-list 102 permit ip 10.20.20.0 0.255.255.255 any



Secondo passo:  creare la route-map 

Creeremo una route map ciamata Global-route map.
L'orine di matching è il numero id della route map 9->10->11
BraveHeart-R-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
BraveHeart-R-C(config)# route-map Sample-routemap permit 9
BraveHeart-R-C(config-route-map)# match ip address 101
BraveHeart-R-C(config-route-map)# set ip next-hop 10.20.6.1
BraveHeart-R-C(config)# route-map Sample-routemap permit 10
BraveHeart-R-C(config-route-map)# match ip address 100
BraveHeart-R-C(config-route-map)# set ip next-hop 10.20.7.1
BraveHeart-R-C(config)# route-map Sample-routemap permit 11
BraveHeart-R-C(config-route-map)# match ip address 102
BraveHeart-R-C(config-route-map)#set default interface GigabitEthernet 3/48
Si crea poi una route-map chiamata « Sample-routemap » che corrisponde all' ACLs 100,101,102 della network che deve essere coinvolta nella route-map.
Applicare la Policy Route-map all'interfaccia
Questa route-map viene poi applicata all'interface vlan 10 e 20.
BraveHeart-R-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
BraveHeart-R-C(config)#int vlan 10
BraveHeart-R-C(config-if)# ip policy route-map Sample-routemap
BraveHeart-R-C(config-if)#exit
BraveHeart-R-C(config)#int vlan 20
BraveHeart-R-C(config-if)# ip policy route-map Sample-routemap
BraveHeart-R-C(config-if)#end