sábado, 31 de marzo de 2012

SNMP MIBs y traps comunes en Radware Alteon

"En esta entrada incluyo algunos traps SNMP y OIDs que pueden ser configurados en la monitorización de los dispostivos Radware Alteon, separados en dos tablas."

Algunos OIDs de la versión AlteonOS 28:

Nombre
OID
Descripción
CPU
cpuUtil1Second
1.3.6.1.4.1.1872.2.5.1.2.2.1.0
The percentage of CPU utilization as measured over the last one second interval.
cpuUtil4Seconds
1.3.6.1.4.1.1872.2.5.1.2.2.2.0
The percentage of CPU utilization as measured over the last four second interval.
cpuUtil64Seconds
1.3.6.1.4.1.1872.2.5.1.2.2.3.0
The percentage of CPU utilization as measured over the last 64 second interval.
Port Stats
portStatsTable
1.3.6.1.4.1.1872.2.5.1.2.3.1
The table of port statistics.
portStatsIndx
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.1
The port index
portStatsPhyIfOutNUcastPkts           
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.10
The total number of packets that higher-level protocols requested be transmitted to a non-unicast (i.e., a subnetwork-broadcast or subnetwork-multicast) address, including those
that were discarded or not sent.
portStatsPhyIfOutDiscards  
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.11
The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding  such a packet could be to free up buffer space.
portStatsPhyIfOutErrors     
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.12
The number of outbound packets that could not be transmitted because of errors.
portStatsPhyIfOutQLen      
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.13
The length of the output packet queue (in packets)
portStatsPhyIfInBroadcastPkts           
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.14
The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer.
portStatsPhyIfOutBroadcastPkts           
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.15
The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer including those that were discarded or not sent.
portStatsPhyIfInOctets       
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.2
The total number of octets received on the  interface, including framing characters.
portStatsPhyIfInUcastPkts   
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.3
The number of subnetwork-unicast packets delivered to a higher-layer protocol.
portStatsPhyIfInNUcastPkts 
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.4
The number of non-unicast (i.e., subnetwork-broadcast or subnetwork-multicast) packets delivered to a higher-layer protocol.
portStatsPhyIfInDiscards    
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.5
The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.
portStatsPhyIfInErrors        
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.6
The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol
portStatsPhyIfInUnknownProtos           
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.7
The number of packets received via the interface which were discarded because of an unknown or unsupported protocol.
portStatsPhyIfOutOctets     
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.8
The total number of octets transmitted out of the interface, including framing characters.
portStatsPhyIfOutUcastPkts 
1.3.6.1.4.1.1872.2.5.1.2.3.1.1.9
The total number of packets that higher-level protocols requested be transmitted to a subnetwork-unicast address, including those that were discarded or not sent.
TCP Packets
ipInReceives       
1.3.6.1.2.1.4.3
The total number of input datagrams received from interfaces, including those received in error
ipInHdrErrors      
1.3.6.1.2.1.4.4
The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc.
ipInAddrErrors    
1.3.6.1.2.1.4.5
The number of input datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IP Gateways and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.
ipForwDatagrams
1.3.6.1.2.1.4.6
The number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination.
In entities which do not act as IP Gateways, this counter will include only those packets which were Source-Routed via this entity, and the Source-Route option processing was successful.
ipInUnknownProtos
1.3.6.1.2.1.4.7
The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.
ipInDiscards       
1.3.6.1.2.1.4.8
The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this
counter does not include any datagrams discarded while awaiting re-assembly
ipInDelivers        
1.3.6.1.2.1.4.9
The total number of input datagrams successfully delivered to IP user-protocols (including ICMP).
ipOutRequests     
1.3.6.1.2.1.4.10
The total number of IP datagrams which local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams  counted in ipForwDatagrams.
ipOutDiscards     
1.3.6.1.2.1.4.11
The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted
in ipForwDatagrams if any such packets met this (discretionary) discard criterion
ipOutNoRoutes   
1.3.6.1.2.1.4.12
The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this 'no-route' criterion. Note that this includes any
datagarms which a host cannot route because all of its default gateways are down
ipReasmTimeout  
1.3.6.1.2.1.4.13
The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity.
ipReasmReqds    
1.3.6.1.2.1.4.14
The number of IP fragments received which needed to be reassembled at this entity
ipReasmOKs       
1.3.6.1.2.1.4.15
The number of IP datagrams successfully re-assembled
ipReasmFails      
1.3.6.1.2.1.4.16
The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc). Note that this is not necessarily a count of discarded IP fragments
since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.
ipFragOKs         
1.3.6.1.2.1.4.17
The number of IP datagrams that have been successfully fragmented at this entity
ipFragFails         
1.3.6.1.2.1.4.18
The number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set
ipFragCreates     
1.3.6.1.2.1.4.19
The number of IP datagram fragments that have been generated as a result of fragmentation at this entity.
UDP Packets
udpInDatagrams  
1.3.6.1.2.1.7.1
The total number of UDP datagrams delivered to UDP users
udpNoPorts        
1.3.6.1.2.1.7.2
The total number of received UDP datagrams for which there was no application at the destination port.
udpInErrors        
1.3.6.1.2.1.7.3
The number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port.
udpOutDatagrams
1.3.6.1.2.1.7.4
The total number of UDP datagrams sent from this entity
Real Servers
slbStatRServerTable
.1.3.6.1.4.1.1872.2.1.8.2.5 
The real server statistics table
slbStatRServerEntry
.1.3.6.1.4.1.1872.2.1.8.2.5.1 
The statistics of a particular real server
slbStatRServerIndex
.1.3.6.1.4.1.1872.2.1.8.2.5.1.1 
The real server number that identifies the server.
slbStatRServerCurrSessions
.1.3.6.1.4.1.1872.2.1.8.2.5.1.2 
The number of sessions that are currently handled by
the real server.
slbStatRServerTotalSessions
.1.3.6.1.4.1.1872.2.1.8.2.5.1.3 
The total number of sessions that are handled by the
real server
slbStatRServerFailures
.1.3.6.1.4.1.1872.2.1.8.2.5.1.4 
The total number of times that the real server is
claimed down
slbStatRServerHighestSessions
.1.3.6.1.4.1.1872.2.1.8.2.5.1.5 
The highest sessions that have been handled by the real
server.
slbStatRServerHCOctets
.1.3.6.1.4.1.1872.2.1.8.2.5.1.6 
The total number of octets received and transmitted out
of the real server
slbStatRServerHCOctetsLow32
.1.3.6.1.4.1.1872.2.1.8.2.5.1.7 
The total number of octets received and transmitted out
of the real server
slbStatRServerHCOctetsHigh32
.1.3.6.1.4.1.1872.2.1.8.2.5.1.8 
The higher 32 bit value of octets received and transmitted out
of the real server.
Virtual Servers
slbStatVServerTable
.1.3.6.1.4.1.1872.2.1.8.2.7            
The virtual server statistics table.
slbStatVServerEntry
.1.3.6.1.4.1.1872.2.1.8.2.7.1            
The statistics of a particular virtual server group.
slbStatVServerIndex
.1.3.6.1.4.1.1872.2.1.8.2.7.1.1 
The virtual server number that identifies the server.
slbStatVServerCurrSessions
.1.3.6.1.4.1.1872.2.1.8.2.7.1.2 
The number of sessions that are currently handled by
the virtual server.
slbStatVServerTotalSessions
.1.3.6.1.4.1.1872.2.1.8.2.7.1.3 
The total number of sessions that are handled by the
virtual server
slbStatVServerHighestSessions
.1.3.6.1.4.1.1872.2.1.8.2.7.1.4 
The total number of times that the virtual server is
claimed down
slbStatVServerHCOctets
.1.3.6.1.4.1.1872.2.1.8.2.7.1.5 
The total number of octets received and transmitted out
of the virtual server
slbStatVServerHCOctetsLow32
.1.3.6.1.4.1.1872.2.1.8.2.7.1.6 
The total number of octets received and transmitted out
of the virtual server
slbStatVServerHCOctetsHigh32
.1.3.6.1.4.1.1872.2.1.8.2.7.1.7 
The higher 32 bit value of octets received and transmitted out
of the virtual server.
slbStatVServerHeaderHits
.1.3.6.1.4.1.1872.2.1.8.2.7.1.8 
The current HTTP header hits.
slbStatVServerHeaderMisses
.1.3.6.1.4.1.1872.2.1.8.2.7.1.9             
The current HTTP header misses
slbStatVServerHeaderTotalSessions
.1.3.6.1.4.1.1872.2.1.8.2.7.1.10 
The current HTTP total sessions
DNS
dnsSlbStatTCPQueries                  
1.3.6.1.4.1.1872.2.5.4.2.13.1
Total number of TCP DNS queries.
dnsSlbStatUDPQueries                  
1.3.6.1.4.1.1872.2.5.4.2.13.2
Total number of UDP DNS queries
dnsSlbStatInvalidQueries   
1.3.6.1.4.1.1872.2.5.4.2.13.3
Total number of UDP invalid DNS queries
dnsSlbStatMultipleQueries 
1.3.6.1.4.1.1872.2.5.4.2.13.4
Total number of UDP DNS multiple queries
dnsSlbStatDnameParseErrors           
1.3.6.1.4.1.1872.2.5.4.2.13.5
Total number of UDP DNS name parse errors
dnsSlbStatFailedMatches  
1.3.6.1.4.1.1872.2.5.4.2.13.6
Total number of UDP DNS failed matches
dnsSlbStatInternalErrors    
1.3.6.1.4.1.1872.2.5.4.2.13.7
Total number of DNS parsing internal errors



Y algunos traps interesantes:

Nombre
   OID
Descripción
linkUp
1.3.6.1.6.3.1.1.5.4
A linkUp trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links has transitioned out of the down state.
linkDown
1.3.6.1.6.3.1.1.5.3
A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links  is about to transition into the down state.
altSwSlbRealServerUp
1.3.6.1.4.1.1872.2.5.7.6
A altSwSlbRealServerUp trap signifies that the real server (which had gone down )is back up and operational now. slbCurCfgRealServerIndex is the affected Real Server Number. The range is from 1 to slbRealServerMaxSize. slbCurCfgRealServerIpAddr is the IP address of the affected Real Server.  slbCurCfgRealServerName is the optional Name given to the affected Real Server.
altSwSlbRealServerDown
1.3.6.1.4.1.1872.2.5.7.7
A altSwSlbRealServerDown trap signifies that the real server has gone down and is out of service. slbCurCfgRealServerIndex is the affected Real Server Number. The range is from 1 to slbRealServerMaxSize. slbCurCfgRealServerIpAddr is the IP address of the affected Real Server. slbCurCfgRealServerName is the optional Name given to the affected Real Server.
altSwSlbRealServerServiceUp
1.3.6.1.4.1.1872.2.5.7.14
A altSwSlbRealServerServiceUp trap signifies that the service port of the real server is up and operational. slbCurCfgRealServerIndex is the affected Real Server Number. The range is from 1 to the value return from slbRealServerMaxSize. slbCurCfgRealServerIpAddr is the IP address of the affected Real Server. slbCurCfgRealServerName is the optional Name given to the affected Real Server. slbCurCfgVirtualServiceRealPort referenced in slbCurCfgVirtServicesTable. This is the layer 4 real port number of  the service.
altSwSlbRealServerServiceDown
1.3.6.1.4.1.1872.2.5.7.15
A altSwSlbRealServerServiceDown trap signifies that the service port of the real server is down and out of service. slbCurCfgRealServerIndex is the affected Real Server Number. The range is from 1 to the value return from slbRealServerMaxSize. slbCurCfgRealServerIpAddr is the IP address of the affected Real Server. slbCurCfgRealServerName is the optional Name given to the affected Real Server. slbCurCfgVirtualServiceRealPort referenced in slbCurCfgVirtServicesTable. This is the layer 4 real port number of the service.
altSwSlbRealServerOperEna
1.3.6.1.4.1.1872.2.5.7.34
A altSwSlbRealServerOperEna trap signifies that the real server is enabled operationally. The real server will be send traffic again. slbCurCfgRealServerIndex is the affected real server number. The range is from 1 to slbRealServerMaxSize. slbCurCfgRealServerIpAddr is the IP address of the affected real server. slbCurCfgRealServerName is the optional name given to the affected real server.
altSwSlbRealServerOperDis
1.3.6.1.4.1.1872.2.5.7.33
A altSwSlbRealServerOperDis trap signifies that the real server is disabled operationally. The real server will not be sent any traffic from the switch until the real server enabled operationally. slbCurCfgRealServerIndex is the affected real server number. The range is from 1 to slbRealServerMaxSize. slbCurCfgRealServerIpAddr is the IP address of the affected real server. slbCurCfgRealServerName is the optional name given to the affected real server.
altSwSlbVirtServerServicesUp
1.3.6.1.4.1.1872.2.5.7.25
A altSwSlbVirtServerServicesUp trap signifies that the service ports of the virtual server is up and operational. slbCurCfgVirtServerIndex is the affected Virtual Server Number. The range is from 1 to the value return from slbVirtServerTableMaxSize. slbCurCfgVirtServerIpAddress is the IP address of the affected Virtual Server. slbCurCfgVirtServerVname is the optional Name given to the affected Virtal Server.
altSwSlbVirtServerServicesDown
1.3.6.1.4.1.1872.2.5.7.26
A altSwSlbVirtServerServicesDown trap signifies that the service ports of the Virtual server is down and out of service. slbCurCfgVirtServerIndex is the affected Virtual Server Number. The range is from 1 to the value return from slbVirtServerTableMaxSize. slbCurCfgVirtServerIpAddress is the IP address of the affected Virtual Server. slbCurCfgVirtServerVname is the optional Name given to the affected Virtual Server.
altSwVrrpNewMaster
1.3.6.1.4.1.1872.2.5.7.16
The altSwVrrpNewMaster trap indicates that the sending agent has transitioned to 'Master' state. vrrpCurCfgVirtRtrIndx is the VRRP virtual router table index referenced in vrrpCurCfgVirtRtrTable. The range is from 1 to vrrpVirtRtrTableMaxSize. vrrpCurCfgVirtRtrAddr is the VRRP virtual router IP address.
altSwVrrpNewBackup
1.3.6.1.4.1.1872.2.5.7.17
The altSwVrrpNewBackup trap indicates that the sending agent has transitioned to 'Backup' state. vrrpCurCfgVirtRtrIndx is the VRRP virtual router table index referenced in vrrpCurCfgVirtRtrTable. The range is from 1 to vrrpVirtRtrTableMaxSize. vrrpCurCfgVirtRtrAddr is the VRRP virtual router IP address.
altSwDeviceTemperatureNormal
1.3.6.1.4.1.1872.2.5.7.40
Sent whenever the temperature changes back to normal.
altSwDeviceTemperatureHigh
1.3.6.1.4.1.1872.2.5.7.41
Sent whenever the temperature changes to high.
altSwDeviceTemperatureCritical
1.3.6.1.4.1.1872.2.5.7.42
Sent whenever the temperature becomes critical.
altSwTempExceedThreshold
1.3.6.1.4.1.1872.2.5.7.22
A altSwTempExceedThreshold trap signifies that the switch temperature has exceeded maximum safety limits. altSwTrapDisplayString specifies the sensor, the current sensor temperature and the threshold for the particular sensor.
altSwDualPowerSupplyUp
1.3.6.1.4.1.1872.2.5.7.44
This info trap is sent when a power supply changes state from inactive to active on a dual power supply device.
altSwDualPowerSupplyProblem
1.3.6.1.4.1.1872.2.5.7.43
This warning trap is sent when a power supply becomes inactive on a dual power supply device.
altSwPrimaryPowerSupplyFailure
1.3.6.1.4.1.1872.2.5.7.1
A altSwPrimaryPowerSupplyFailure trap signifies that the primary power supply failed.
altSwTputReachThreshold
1.3.6.1.4.1.1872.2.5.7.47
Sent whenever the throughput reaches threshold value.
altSwTputExceedLimit
1.3.6.1.4.1.1872.2.5.7.48
Sent whenever the throughput exceeds threshold value.
altSwcacheBelow80
1.3.6.1.4.1.1872.2.5.7.55
Allocated cache space is below 80%
altSwcacheReache80
1.3.6.1.4.1.1872.2.5.7.54
Allocated cache space has reached 80%.
altSwcacheLimitShortSpace
1.3.6.1.4.1.1872.2.5.7.53
Temporarily limiting caching due to critical cache space shortage.
altSwcpuFell80
1.3.6.1.4.1.1872.2.5.7.58
CPU utilization has dropped below 80%, while before that it was above 80%.
altSwcpuCross80
1.3.6.1.4.1.1872.2.5.7.57
CPU utilization has reached 80%, while before that it was below 80%
altSwlogDiskSpace
1.3.6.1.4.1.1872.2.5.7.56
80% of logging disk space was reached.
altSwSlbRealServerMaxConnReached
1.3.6.1.4.1.1872.2.5.7.8
A altSwSlbRealServerMaxConnReached trap signifies that the real server has reached maximum connections. The Real server will not be sent any more traffic from the switch until the number of connections drops below the maximum. If a backup server has been specified, it will be used to service additional requests, which is referred to as an Overflow server. slbCurCfgRealServerIndex is the affected Real Server Number. The range is from 1 to slbRealServerMaxSize. slbCurCfgRealServerIpAddr is the IP address of the affected Real Server. slbCurCfgRealServerName is the optional Name given to the affected Real Server.
altSwDefGwDown
1.3.6.1.4.1.1872.2.5.7.3
A altSwDefGwDown trap signifies that the default gateway is down. ipCurCfgGwIndex is the index of the Gateway in ipCurCfgGwTable. The range for ipCurCfgGwIndex is from 1 to ipGatewayTableMax. ipCurCfgGwAddr is the IP address of the default gateway.
altSwLoginFailure
1.3.6.1.4.1.1872.2.5.7.19
A altSwLoginFailure trap signifies that someone failed to enter a valid username/password combination. altSwTrapDisplayString specifies whether the login attempt was from CONSOLE or TELNET. In case of TELNET login it also specifies the IP address of the host from which the attempt was made."
altSwloginSsh
1.3.6.1.4.1.1872.2.5.7.51
User <user-name> has logged in via SSH console.
altSwSlbSynAttack
1.3.6.1.4.1.1872.2.5.7.20
A altSwSlbSynAttack trap signifies that a SYN attack has been detected. altSwTrapRate specifies the number of new half-open sessions per second.
altSwSlbSessAttack
1.3.6.1.4.1.1872.2.5.7.23
A altSwSlbSessAttack trap signifies that a SLB attack has been detected. altSwTrapRate specifies the number of new sessions per second.
altSwFanFailure
1.3.6.1.4.1.1872.2.5.7.24
A altSwFanFailure trap signifies that a fan failure has occured.
altSwBulkApply
1.3.6.1.4.1.1872.2.5.7.39
A altSwBulkApply trap signifies that new configuration has been applied.
altSwtmpCecLimitMemShort
1.3.6.1.4.1.1872.2.5.7.59
The device is near full memory capacity <% memory usage>. Temporarily limiting maximum number of connections.
altSwcertExpDays
1.3.6.1.4.1.1872.2.5.7.71
Server Certificate will expire in X days.

domingo, 16 de octubre de 2011

Arquitectura MultiDataCenter – Extensión de red L2

"Esta es la primera de una serie de entradas sobre el diseño de infraestructuras multi-DataCenter (red, almacenamiento y sistemas). En este caso se trata de aclarar la extensión de VLANs y direccionamientos a lo largo de varios Centros de Datos, o también llamado extensiones de Data Center (DCI)"
 
Aunque existen argumentos en contra de la extensión L2 de los Data Centers relacionados con las restricciones de latencia y ancho de banda que se encuentran en los enlaces inter-DC, o los costes asociados al despliegue de estas arquitecturas, se pretende dar un repaso a los principales conceptos relacionados con estas topologías.
 
Como primer paso hay que aclarar el origen de la necesidad de expandir una misma red a lo largo de varios Data Centers, entre los más destacables se encuentran:
  •   Movilidad de cargas: Pensando en un despliegue de infraestructura de servidores virtualizados, al disponer de una misma red extendida, se pueden transferir máquinas virtuales de un Data Center a otro, sin las complicaciones de terceras herramientas o complicados sistemas de reconfiguración automática de servidores virtuales, posibilitando el reparto de cargas (Data Centers activo-activo) y el máximo aprovechamiento de recursos.
  • Prevención de desastres y continuidad de sistemas: En caso de un desastre en uno de los centros, se pueden restablecer los servicios en un tiempo mínimo gracias a la posibilidad de creación de clusters extendidos entre varios Data Centers
  • ·Minimizar el tiempo de parada: Esta ventaja es, en realidad, la suma de las dos anteriores. Al disponer de varios Centros de Datos activos, se pueden balancear los servicios prestados por un Data Center a otro diferente ante posibles actuaciones programadas que requieran parada de uno de estos centros.


Aislamiento de caminos

Antes de abordar las topologías y los protocolos asociados es necesario aclarar un concepto importante, el aislamiento de caminos en los enlaces de interconexión de Data Centers.

Cada vez más a menudo es necesario llevar a cabo una virtualización de la red, desde la creación de redes paralelas que presten acceso a Internet a los usuarios “invitados”, la segmentación departamental o la provisión de redes a varios clientes bajo una misma infraestructura. Esta diferenciación es necesario que se conserve en el enlace que une los Centros de Datos distribuidos.

Para llevar a cabo esta virtualización de manera sencilla se puede realizar un diseño con varios VRFs, de manera que se crearía un VRF por cada zona, a la cual se asociarían las diferentes redes/VLANs. Para aislar cada uno de los caminos en la interconexión de los Data Center se podría utilizar un enlace físico para cada uno de ellos, pero esto no sería eficiente y en la práctica se deben utilizan otras técnicas de virtualización del enlace. Si el enlace entre los Data Centers tiene más de un salto, se debe realizar algún tipo de túnel o recurrir a funcionalidades proporcionadas por los protocolos de interconexión de los Centros de Datos. 


Protocolos y topologías

Tradicionalmente se han extendido las VLANs de cada DC mediante protocolos como Frame-Relay o ATM, ya que el concepto de VLAN puede ser similar al conseguido mediante DLCIs y PVCs. También se han utilizado las llamadas Metro-Ethernet que es una VPN L2, en la que la red del proveedor transporta tramas Ethernet y donde las direcciones MAC son usadas para determinar el encaminamiento. Estos enfoques tienen como principal problema la escalabilidad y el aporte de servicios añadidos como QoS, encriptación, etc, por lo que actualmente suelen utilizarse otros protocolos como MPLS, como se verá a continuación.

La solución adoptada depende de varios factores fuera del dominio meramente técnico, como el coste o la disponibilidad del servicio por parte del proveedor, por ello se van a plantear la tres posibilidades de interconexión que puede proporcionar el ISP, apuntando a sus ventajas y deficiencias:

  • Conectividad a nivel 1
    También llamada conectividad sobre fibra oscura, es el método más sencillo de despliegue pero no siempre está disponible, además hay que contar con el elevado coste de esta solución. 

    Al ser conectividad L1, puede ser utilizada para también extender la SAN.

    Puede ser utilizada tanto para arquitecturas de Data Center punto a punto como para topologías multipunto, gracias a la formación de anillos DWDM.
  • Conectividad a nivel 2
Este método suele ser utilizado cuando no se puede disponer de fibra oscura ya sea por precio, disponibilidad o distancia entre Data Centers.

El protocolo utilizado más extensamente es MPLS ya que permite el aislamiento de caminios en el enlace mediante la utilización de etiquetas y por su capacidad de proveer conexiones del tipo any-to-any sin tener que mantener múltiples conexiones punto a punto.

Existen dos aproximaciones para realizar la conexión a nivel L2: Ethernet over MPLS (EoMPLS), para entornos punto a punto; y Virtual Private VLAN Service (VPLS), para multipunto.

Con EoMPLS  los operadores pueden ofrecer conectividad con servicios LAN transparentes garantizados, escalables y seguros. Además con el aprovisionamiento dinámico de MPLS, se mejora la gestión y manejabilidad de los túneles, reduciendo los problemas relacionados con su despliegue a gran escala.
EoMPLS permite, además, ofrecer gran ancho de banda a un coste menor, lo que unido a los mecanismos de QoS extremo a extremo garantizan el rendimiento de los servicios desplegados.

Mientras que EoMPLS es utilizado en entornos punto a punto, cuando existen varios DC el protocolo elegido es VPLS. Este protocolo forma un grupo de virtual switch instances (VSI), conectados utilizando Ethernet over MPLS en una topología full-mesh, consiguiendo actuar como un único switch general para todos los DC.

Aun así existen varios problemas de los vpls basadas en VLAN como la limitación del número de VLANs 4094 VLANs o la limitación de direcciones MAC que pueden gestionar, así como el tiempo de convergencia ante fallos o la transmisión de tráfico multicast.
  • Conectividad de nivel 3
    Esta debería ser la última opción, debido a sus problemas de rendimiento (latencia, jitter, etc), ya que consiste en el encapsulamiento de los anteriores protocolos en un túnel GRE.

    Al existir este encapsulamiento adicional se deberá tener en cuenta que es necesario, para minimizar el efecto de la fragmentación de paquetes, disminuir el MTU de los Data Centers debido a la adicción de cabeceras que supone el protocolo GRE.

    Existen nuevas alternativas, como la nueva versión del protocolo L2TP, el denominado L2TPv3 que permite la multiplexación de enlaces punto a punto (pseudowires), del mismo modo que MPLS, además de aportar otras funcionalidades que minimizan el riesgo de creación de “blackholes” en el tráfico


Problemas a tener en cuenta

Tras abordar las topologías de Data Centers con redes expandidas, es necesario conocer los principales aspectos a tener en cuenta en el diseño de este tipo de soluciones: 

  • ·         Aislamiento de protocolo Spanning-Tree
Es importante que cualquier problema L2 quede contenido en un único Data Center, por lo que el protocolo STP sea suprimido en los enlaces inter-site.
Este aislamiento también beneficia al rendimiento, ya que se no se extenderán los paquetes TCN producidos por los cambios de topología a nivel 2,  y cuyo efecto es la disminución del temporizador de la tabla CAM, provocando aumentos en el consumo de CPU por parte de los switches e incluso la pérdida de paquetes.
  • ·         Prevención de bucles extremo a extremo
Al no disponer de protocolo Spanning-Tree  entre los DC (punto anterior) puede provocarse un bucle a nivel 2, por lo que hay que confiar en técnicas que eviten esta posibilidad, como los agregados de enlace en topologías punto a punto.
Por otro lado, aunque se eviten bucles con agregados en arquitecturas punto a punto, o  mediante los procedimientos del protocolo de interconexión (IP, MPLS, etc), puede existir un bucle global generado por la interconexión de varios DC mediante enlaces dobles, como puede verse a continuación:

Ilustración 1 – Bucle inter-DataCenter

Para evitar estos bucles existen tecnologías que pueden ser utilizadas, como por ejemplo VSS, o la utilización de la técnica de semáforos, mediante la cual solo uno de los uplinks del Data Center está activo, por lo que no pueden existir este tipo de bucles.
La metodología de semáforos utiliza la técnica de N-PE en backup, utilizando el Embedded Event Manager (EEM) para asegurarse de que solo uno de los nodos está activo por cada VLAN.
  •            Blockholes

    Es importante propagar la caída del enlace pseudowire o los enlaces externos a los nodos que forman
    parte de la capa de agregación, por ejemplo extendiendo el fallo a los puertos configurados como
    MPLS port-mode,  para que no se formen blackholes. En las plataformas Cisco existen varios
    métodos, dependiendo de la plaforma, como la funcionalidad Remote Ethernet Port Shutdown de los
    routers ASR1000 o la utilización del EEM por parte de los Catalyst 6500, a parte del track en los
    grupos HSRP.
  • ·         Optimización de rutas
Existe un problema claro al extender la capa 2 a lo largo de múltiples Data Centers y es la utilización de rutas no optimizadas al enviar paquetes al Gateway por defecto que reside en el Data Center remoto, no en al que está situado localmente, tal y como puede comprobarse en el siguiente esquema:


Ilustración 2 –Rutas sub-óptimas

Para mejorar este esquema se podrían formar grupos de VLANs y balancear entre los dos centros pero, si lo que se desea es suprimir estas rutas no optimizadas, existe la posibilidad de crear listas ACL que impidan la comunicación entre las direcciones MAC de los nodos HSRP, de tal manera que la IP virtual de default Gateway sea conservada a la vez por nodos residentes en diferentes Data Center, permitiendo que siempre el Default Gateway esté situado localmente. 


Nuevos protocolos

Debido al “fenómeno Cloud”, existe bastante innovación en tecnologías relacionadas con la interconexión de Centros de Datos, algunas de ellas provenientes del sector Open Source, aunque todavía tengan muy poco recorrido, como Quantum (http://wiki.openstack.org/Quantum) que forma parte del conglomerado de tecnologías OpenStack, pero una de las más interesantes es la desarrollada por Cisco para su gama de productos Nexus 7000 llamada Overlay Transport Virtualization (OTV).

OTV proporciona un medio de transporte L2 a lo largo de una infraestructura IP introduciendo el concepto de MAC routing mediante la compartición de un plano de control distribuido por la plataforma que actualiza la información de las direcciones MAC conectadas a cada Site, de modo que se limita el flooding de paquetes L2 por la infraestructura.

También con OTV se elimina la necesidad de creación de circuitos virtuales (pseudowires), lo que aporta cierto grado de flexibilidad e independencia de los protocolos subyacentes, tiene medios internos para evitar los bucles inter-site y mejora los tiempos de failover y el tratamiento del tráfico multicast.
También es remarcables que posee la capacidad de realizar el filtrado automático del tráfico FHRP, por lo que no hay que recurir al método mostrado en el punto anterior para evitar las rutas subóptimas al default Gateway.