Un switch puede filtrar los paquetes utilizando la tabla TCAM, antes de llegar a multilayer switch.
para ello creamos VLAN access-list VACLsque afectaran a como los paquetes son tratados dentro de la Vlan.
para la configuracion:
Switch(config)# vlan access-map map-name [sequence-number]
Switch(config-access-map)# match {ip address {acl-number | acl-name}} | {ipx address
{acl-number | acl-name}} | {mac address acl-name}
Switch(config-access-map)# action {drop | forward [capture] | redirect interface type mod/num}
finalmente lo aplicamos a una VLAN interface :
Switch(config)# vlan filter map-name vlan-list vlan-list
por ejemplo:
Switch(config)# ip access-list extended local-17
Switch(config-acl)# permit ip host 192.168.99.17 192.168.99.0 0.0.0.255
Swtich(config-acl)# exit
Switch(config)# vlan access-map block-17 10
Switch(config-access-map)# match ip address local-17
Switch(config-access-map)# action drop
Switch(config-access-map)# vlan access-map block-17 20
Switch(config-access-map)# action forward
Switch(config-access-map)# exit
Switch(config)# vlan filter block-17 vlan-list 99
notamos que se esta aplicando a la VLAN 99
Private VLANS
dentro de una Vlan nos da la posibilidad de segmentar tráfico.
Un normal o primary Vlan puede ser lógicamente asociado con un especial unidireccional o secndary Vlan. Host asociados con un secondary Vlan pueden comunicarse con ports en el primary Vlan (un router por ejemplo) pero no con otro secondary vlan.
un secondary Vlan puede ser de los siguientes tipos:
Isolated: el puerto del switch puede alcanzar a la Vlan principal pero no a otro secondary Vlan. Adicionalmente los host asociados al mismo isolated Vlan no se pueden alcanzar entre si.
Community: Los host asociados se verán entre si y a la Vlan principal, pero no a otra vlan community.
Esto nos provee la forma de crear segmentos que no se verán entre sí.
se debe definir el port con uno de los modos:
Promiscuous: El puerto se conecta aun comun gateway router, switch, etc
Host: Los host se comunican con puertos promiscuos o de la misma comunidad.
Configuracion Private VLANs
comenzaremos definiendo la secundaria Vlan:
Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan {isolated | community}
luego
Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association {secondary-vlan-list | add secondary-vlan-list | remove secondary-vlan-list}
asociamos los puertos del switch con private VLANs
Switch(config-if)# switchport mode private-vlan {host | promiscuous}
Switch(config-if)# switchport private-vlan host-association primary-vlan-id secondary-vlan-id
Use the following interface configuration command to map promiscuous mode ports to primary and
secondary VLANs:
Switch(config-if)# switchport private-vlan mapping {primary-vlan-id} {secondary-vlan-list} | {add secondary-vlan-list} | {remove secondary-vlan-list}
ejemplo:
Switch(config)# vlan 10
Switch(config-vlan)# private-vlan community
Switch(config)# vlan 20
Switch(config-vlan)# private-vlan community
Switch(config)# vlan 30
Switch(config-vlan)# private-vlan isolated
Switch(config)# vlan 100
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 10,20,30
Switch(config-vlan)# exit
Switch(config)# interface range fastethernet 1/1 – 1/2
Switch(config-if)# switchport private-vlan host-association 100 10
Switch(config)# interface range fastethernet 1/4 – 1/5
Switch(config-if)# switchport private-vlan host-association 100 20
Switch(config)# interface fastethernet 1/3
Switch(config-if)# switchport private-vlan host-association 100 30
Switch(config)# interface fastethernet 2/1
Switch(config-if)# switchport mode private-vlan promiscuous
Switch(config-if)# switchport private-vlan mapping 100 10,20,30
Remote SPAN
El source y destination pueden estar en diferentes swicth.
iniciamos la configuración de RSPAN con la definicion del proposito especial.
Si se configura en el vtp server, se propagara a otro switch, de no usarse vtp asegurarse de crear la vlan de RSPAN en todos los switch,
Switch(config)# vlan vlan-id
Switch(config-vlan)# remote-span
Switch(config)# monitor session session source {interface type mod/num | vlan vlan-id} [rx | tx | bo th ]
Switch(config)# monitor session session destination remote vlan rspan-vlan-id
en el switch destino:
Switch(config)# monitor session session source remote vlan rspan-vlan-id
Switch(config)# monitor session session destination {interface type | vlan vlan-id}
ejemplo:
Catalyst A
vlan 999
remote-span
monitor session 1 source interface fastethernet 1/1 both
monitor session 1 destination remote vlan 999
Catalyst B
vlan 999
remote-span
Catalyst C
vlan 999
remote-span
monitor session 1 source remote vlan 999
monitor session 1 destination interface fastethernet 4/48
martes, 16 de octubre de 2007
lunes, 15 de octubre de 2007
Configuracion DiffServ QoS
Para habilitar QoS en el switch :
Switch(config)# mls qos
Paquetes que ingresan al switch son asignados un valor dscp derivado solo del qos que es validado de la cola de ingreso. El parametro validado es mapeado en los valores DSCP.
En la cola de salida, los paquetes con DSCP son convertidos a CoS , tal que se puede usar determinado metodo.
Podemos aplicar QoS Trust en 2 formas :
Por interface
Como parte de una politica QoS sobre un específico tipo de tráfico.
switch(config-if)#mls qos trust { cos, dscp, ip-precedence }
switch(config-if)#no mls qos trust
pone a cero 0 el dscp o CoS ó
a un valor por default CoS en la interface defindo por el comando: mls qos cos value
mapeando cos a dscp :
CoS 0 1 2 3 4 5 6 7
dscp 0(default) 8(AF10) 16(AF20) 24(AF30) 32(AF40) 40(EF) 48(Internet-work ctl) 56(Network ctl)
para cambiar el mapeo podemos usar el comando de configuracion global :
switch(config)# mls qos map cos-dscp dscp1 ... dscp8
El ip precedence tambien se mapea de la misma forma :
se puede cambiar con el siguiente comando:
switch(config)# mls qos map ip-prec-dscp dscp1 ... dscp8
valores de ingreso dscp pueden ser mapeados a otros dscp usando mutación dscp map.
switch(config)#mls qos map dscp-mutation dscp-mutation-name in-dscp to out-dscp
para aplicarlo en alguna interface:
swicth(config-if)#mls qos dscp-mutation dscp-mutation-name
Definiendo QoS Policy
1. Uno o más clases de QoS son definido para clasificar tráfico específico.
2. Uno o más QoS policies son definidos al referenciar un grupo de multiples clases QoS como una simple entidad. Estas clases identifican a un grupo de diferentes tipos de tráfico. Cada police contiene acciones que pueden ser mark, policer o shape trafico clasificado por cada class.
3. cada interface de salida puede ser asignado un QoS policy en cada dirección, por ejemplo una politica puede ser asignada para inbound y otra para outbound.
Definiendo un QoS class para clasificar tráfico
switch(config)# class-map class-name [match-all | match-any]
podemos usar access-list para match el tráfico, tambien se puede usar NBAR para match tráfico dinamico.
swicth(config-cmap)# match access-group name access-list tambien se puede usar :
switch(config-cmap)# match ip-precedence ip-prec1 [...ip-precN]
switch(config-cmap)# match ip dscp dscp1 [..dscpN]
podemos usar NBAR :
switch(config-cmap)# match protocol protocol-name
nuevos protocolos pueden ser añadidos utlizando PDLM.
Definiendo Policy
swicth(config)# policy-map policy-name
swicth(config-pmap)# class class-name
swicth(config-pmap)# set ip dscp dscp-value
swicth(config-pmap)# set ip precedence precedence-value
en otro caso, solo cierto trafico debera ser validado
swicth(config-pmap)# trust {cos | dscp | ip-precedence}
police [aggregate name] [flow] bits-per-second normal-burst-bytes [extended-burst-
bytes] [pir peak-rate-bps] [conform-action action] [exceed-action action] [violate-
action action]
Here, an action can be one of the following:
drop—Drop the packet.
set-dscp-transmit [new-dscp]—Set the DSCP value in the packet.
set-prec-transmit [new-precedence]—Set the IP Precedence value in the packet.
transmit—Send the packet normally.
se aplica de la siguiente forma :
Switch(config-if)# service-policy [input | output] policy-name
podemos asignar pesos referente a weighted round robin
Switch(config-if)# wrr-queue bandwidth weight1 weight2 [weight3] [weight4]
el numero de colas en una interface cisco varia segun la plataforma.
Switch(config)# mls qos
Paquetes que ingresan al switch son asignados un valor dscp derivado solo del qos que es validado de la cola de ingreso. El parametro validado es mapeado en los valores DSCP.
En la cola de salida, los paquetes con DSCP son convertidos a CoS , tal que se puede usar determinado metodo.
Podemos aplicar QoS Trust en 2 formas :
Por interface
Como parte de una politica QoS sobre un específico tipo de tráfico.
switch(config-if)#mls qos trust { cos, dscp, ip-precedence }
switch(config-if)#no mls qos trust
pone a cero 0 el dscp o CoS ó
a un valor por default CoS en la interface defindo por el comando: mls qos cos value
mapeando cos a dscp :
CoS 0 1 2 3 4 5 6 7
dscp 0(default) 8(AF10) 16(AF20) 24(AF30) 32(AF40) 40(EF) 48(Internet-work ctl) 56(Network ctl)
para cambiar el mapeo podemos usar el comando de configuracion global :
switch(config)# mls qos map cos-dscp dscp1 ... dscp8
El ip precedence tambien se mapea de la misma forma :
se puede cambiar con el siguiente comando:
switch(config)# mls qos map ip-prec-dscp dscp1 ... dscp8
valores de ingreso dscp pueden ser mapeados a otros dscp usando mutación dscp map.
switch(config)#mls qos map dscp-mutation dscp-mutation-name in-dscp to out-dscp
para aplicarlo en alguna interface:
swicth(config-if)#mls qos dscp-mutation dscp-mutation-name
Definiendo QoS Policy
1. Uno o más clases de QoS son definido para clasificar tráfico específico.
2. Uno o más QoS policies son definidos al referenciar un grupo de multiples clases QoS como una simple entidad. Estas clases identifican a un grupo de diferentes tipos de tráfico. Cada police contiene acciones que pueden ser mark, policer o shape trafico clasificado por cada class.
3. cada interface de salida puede ser asignado un QoS policy en cada dirección, por ejemplo una politica puede ser asignada para inbound y otra para outbound.
Definiendo un QoS class para clasificar tráfico
switch(config)# class-map class-name [match-all | match-any]
podemos usar access-list para match el tráfico, tambien se puede usar NBAR para match tráfico dinamico.
swicth(config-cmap)# match access-group name access-list tambien se puede usar :
switch(config-cmap)# match ip-precedence ip-prec1 [...ip-precN]
switch(config-cmap)# match ip dscp dscp1 [..dscpN]
podemos usar NBAR :
switch(config-cmap)# match protocol protocol-name
nuevos protocolos pueden ser añadidos utlizando PDLM.
Definiendo Policy
swicth(config)# policy-map policy-name
swicth(config-pmap)# class class-name
swicth(config-pmap)# set ip dscp dscp-value
swicth(config-pmap)# set ip precedence precedence-value
en otro caso, solo cierto trafico debera ser validado
swicth(config-pmap)# trust {cos | dscp | ip-precedence}
police [aggregate name] [flow] bits-per-second normal-burst-bytes [extended-burst-
bytes] [pir peak-rate-bps] [conform-action action] [exceed-action action] [violate-
action action]
Here, an action can be one of the following:
drop—Drop the packet.
set-dscp-transmit [new-dscp]—Set the DSCP value in the packet.
set-prec-transmit [new-precedence]—Set the IP Precedence value in the packet.
transmit—Send the packet normally.
se aplica de la siguiente forma :
Switch(config-if)# service-policy [input | output] policy-name
podemos asignar pesos referente a weighted round robin
Switch(config-if)# wrr-queue bandwidth weight1 weight2 [weight3] [weight4]
el numero de colas en una interface cisco varia segun la plataforma.
viernes, 12 de octubre de 2007
Quality of Service
Hasta ahora hemos visto si un paquete puede ser enviado, no como puede serlo.
Diferentes tipos de aplicaciones tienen diferentes requerimientos de como debe la data ser enviada.
Delay - el total delay de un punto inicial al final es llamado latencia.
Jitter - La variacion de delay es llamado jitter, el audio es suceptible a ella.
Loss - En extremos casos los paquetes durante congestión serán dropeados.
Para aliviar estas condiciones una red emplea mecanismos QoS.
Tipos de QoS :
- Best-effort delivery
- Integrated Services model
- Differentiated Sevices model
Best Effort Delivery
una red que simplemente envia paquetes en el orden en que es recibida no tiene un real QoS.
Switch y router hacen "best effort" para entregar paquetes tan rapidamente posible, no ve el tipo de tráfico o la necesidad de priorizar servicios.
Integrated Services Model
Un enfoque a QoS es el modelo IntServ. La idea básica es establecer un camino de data priorizado. el RSVP fue desarrolado el mecanismo para manejar y reservar un adecuado camino bandwidth para una aplicación.
Differentiated Services Model
Modelo DiffServ, permite manejar cada paquete sobre una base individual. Cada router se configura con politicas QoS para monitorear y reenviar.
IntServ aplica QoS sobre un flujo basico, DiffServ se aplica sobre per-hop.
DiffServ tambien basa esta decision QoS en base a la información contenida en cada paquete.
DiffServ QoS
Layer 2 QoS Classification
Frames Layer 2 no tienen mecanismos para indicar la prioridad o importancia de su contenido. Por lo tanto, un switch capa 2 puede solo enviar frames de acuerdo a best-efford.
Cuando las tramas son llevadas de un switch a otro, una oportunidad de clasificación ocurre.
El trunk añade un tag indicando source VLAN number. La encapsulación tambien incluye un campo que puede marcar CoS de cada trama.
Layer 3 QoS Classification with DSCP
Los paquetes IP tienen ToS byte, que puede ser usado para marcar paquetes.
Este byte tiene 3 bits IP Precendence value y 4 bits ToS value.
Se usa un valor conocido como DSCP Differentiated Service Code Point.
ToS Byte : P2 - P1 - P0 - T3 - T2 - T1 - T0 - Zero
DS Byte : DS5 - DS4 - DS3 - DS2 - DS1 - DS0 - ECN1 - ECN0
IP Precedence :
Routine 0
Priority 1
Inmediate 2
Flash 3
Flash Override 4
Critical 5
Internetwork Control 6
Network control 7
Ingress Queueing
Muchos switch tienen 2 tipos de colas de ingreso : un strict priority queue y standard queue.
Si QoS es habilitado en todos, algunos paquetes son automaticamente puestos en prioridad estricta. paquetes que llegan con CoS de 5 son puestos en queue strict priority.
Classification, trust and Marking
Cada switch debe decidir cuando trust incoming QoS values.
policier
Despues de que un paquete ha sido clasificado, se puede configurar el switch para limitar el bandwidth de cierto tipo de trafico. tenemos 2 tipos :
-Microflow policers : mantiene track del BW usado por cada flujo de trafico granular, como un source y destination address usando especificos puertos.
-Aggregate policers : monitorea y controla un flujo acumulativo que viaja a travez de uno o mas port ingreso o VLANs.
Scheduling
Paquetes que estan listos para enviarse o entregarse son puestos en la cola de salida. Estas colas son servidos de acuerdo a un predefinido configurable metodo scheduling.
Los switchs catalyst usualmente tienen multiples colas habilitados en cada port de salida. Una cola es reservada como strict priority. Esta cola mantiene paquetes time-critical como voice stream. Las otras colas son llamadas estandard queues y son servidas en un configurable prioridad, siempre debajo de un strict priority queue.
Los paquetes son asignados a la cola de salida de acuerdo a una funcion de mapeado, basado en un valor CoS. Por default paquetes con CoS 0 a 3 son puestos a la primera cola estandar, mientras que CoS 4 a 7 iran a la segunda cola estandar.
Basicamente, la congestion es manejada en la manera que las colas sean servidas. Los switch catalyst usan una tecnica llamada WRR Weighted Round Robin. El tamaño de la cola es configurada como un % del total del espacio de cola. Entonces a cada cola se le asigna un peso, por lo que una cola con mayor peso es atendida primero. Las colas son atendidas en round.robin, una despues de otra. La sola excepcion es priority queue, que siempre es atendida hasta quedar vacia.
Congestion Avoidance (Evitar congestion)
La funcion de las colas del puerto del switch es proveer un espacio para paquetes que esperan a ser transmitidos cuando el port no lo puede transmitir inmediatamente. Si un puerto se congestiona, la cola empieza a llenarse. Si la congestion es severa, los nuevos paquetes no podrán ser guardados en la cola y deberan ser dropeados.
De alguna manera, un switch debe anticiparse o evitar severa congestion usando uno de los siguientes metodos disponibles :
- Tail drop
- Weighted Random Early Detection
Tail Drop
Es usado como un basico y drastico medio de evitar la congestion en colas de puertos. Los paquetes son puestos en una cola donde la cabeza son cercanos a ser transmitidos y el final es lejano en la cola. cuando la cola se llena en capacidad, algun nuevo paquete que arriva son simplemente dropeados en el fin de la cola.
Weighted Random Early Detection
Dropea paquetes aleatoriamente en la cola, tal que nunca se llene.
dentro de cada cola tenemos varios umbrales que WRED puede usar, cada umbral marca el nivel en la cola donde empezará a dropear, por ejemplo si tenemos 2 umbrales, el primero al 50% con CoS 0 y 1 y otro umbral al 75% para CoS 2 y 3, cuando la cola se llene al 50% empezará a dropear paquetes con CoS 0 y 1, si pese a ello se llena la cola al 75% enpezará a dropear paquetes con CoS 2 y 3.
Switch Port Queues
p: priority queue
q: estandar queue
t: configurable wred queue
ejemplo: 1p2q2t
el priority queue nunca tiene un umbral, todos los paquetes se envian.
show queueing interface f0/12
show interface f0/12 capabilities
Diferentes tipos de aplicaciones tienen diferentes requerimientos de como debe la data ser enviada.
Delay - el total delay de un punto inicial al final es llamado latencia.
Jitter - La variacion de delay es llamado jitter, el audio es suceptible a ella.
Loss - En extremos casos los paquetes durante congestión serán dropeados.
Para aliviar estas condiciones una red emplea mecanismos QoS.
Tipos de QoS :
- Best-effort delivery
- Integrated Services model
- Differentiated Sevices model
Best Effort Delivery
una red que simplemente envia paquetes en el orden en que es recibida no tiene un real QoS.
Switch y router hacen "best effort" para entregar paquetes tan rapidamente posible, no ve el tipo de tráfico o la necesidad de priorizar servicios.
Integrated Services Model
Un enfoque a QoS es el modelo IntServ. La idea básica es establecer un camino de data priorizado. el RSVP fue desarrolado el mecanismo para manejar y reservar un adecuado camino bandwidth para una aplicación.
Differentiated Services Model
Modelo DiffServ, permite manejar cada paquete sobre una base individual. Cada router se configura con politicas QoS para monitorear y reenviar.
IntServ aplica QoS sobre un flujo basico, DiffServ se aplica sobre per-hop.
DiffServ tambien basa esta decision QoS en base a la información contenida en cada paquete.
DiffServ QoS
Layer 2 QoS Classification
Frames Layer 2 no tienen mecanismos para indicar la prioridad o importancia de su contenido. Por lo tanto, un switch capa 2 puede solo enviar frames de acuerdo a best-efford.
Cuando las tramas son llevadas de un switch a otro, una oportunidad de clasificación ocurre.
El trunk añade un tag indicando source VLAN number. La encapsulación tambien incluye un campo que puede marcar CoS de cada trama.
Layer 3 QoS Classification with DSCP
Los paquetes IP tienen ToS byte, que puede ser usado para marcar paquetes.
Este byte tiene 3 bits IP Precendence value y 4 bits ToS value.
Se usa un valor conocido como DSCP Differentiated Service Code Point.
ToS Byte : P2 - P1 - P0 - T3 - T2 - T1 - T0 - Zero
DS Byte : DS5 - DS4 - DS3 - DS2 - DS1 - DS0 - ECN1 - ECN0
IP Precedence :
Routine 0
Priority 1
Inmediate 2
Flash 3
Flash Override 4
Critical 5
Internetwork Control 6
Network control 7
Ingress Queueing
Muchos switch tienen 2 tipos de colas de ingreso : un strict priority queue y standard queue.
Si QoS es habilitado en todos, algunos paquetes son automaticamente puestos en prioridad estricta. paquetes que llegan con CoS de 5 son puestos en queue strict priority.
Classification, trust and Marking
Cada switch debe decidir cuando trust incoming QoS values.
policier
Despues de que un paquete ha sido clasificado, se puede configurar el switch para limitar el bandwidth de cierto tipo de trafico. tenemos 2 tipos :
-Microflow policers : mantiene track del BW usado por cada flujo de trafico granular, como un source y destination address usando especificos puertos.
-Aggregate policers : monitorea y controla un flujo acumulativo que viaja a travez de uno o mas port ingreso o VLANs.
Scheduling
Paquetes que estan listos para enviarse o entregarse son puestos en la cola de salida. Estas colas son servidos de acuerdo a un predefinido configurable metodo scheduling.
Los switchs catalyst usualmente tienen multiples colas habilitados en cada port de salida. Una cola es reservada como strict priority. Esta cola mantiene paquetes time-critical como voice stream. Las otras colas son llamadas estandard queues y son servidas en un configurable prioridad, siempre debajo de un strict priority queue.
Los paquetes son asignados a la cola de salida de acuerdo a una funcion de mapeado, basado en un valor CoS. Por default paquetes con CoS 0 a 3 son puestos a la primera cola estandar, mientras que CoS 4 a 7 iran a la segunda cola estandar.
Basicamente, la congestion es manejada en la manera que las colas sean servidas. Los switch catalyst usan una tecnica llamada WRR Weighted Round Robin. El tamaño de la cola es configurada como un % del total del espacio de cola. Entonces a cada cola se le asigna un peso, por lo que una cola con mayor peso es atendida primero. Las colas son atendidas en round.robin, una despues de otra. La sola excepcion es priority queue, que siempre es atendida hasta quedar vacia.
Congestion Avoidance (Evitar congestion)
La funcion de las colas del puerto del switch es proveer un espacio para paquetes que esperan a ser transmitidos cuando el port no lo puede transmitir inmediatamente. Si un puerto se congestiona, la cola empieza a llenarse. Si la congestion es severa, los nuevos paquetes no podrán ser guardados en la cola y deberan ser dropeados.
De alguna manera, un switch debe anticiparse o evitar severa congestion usando uno de los siguientes metodos disponibles :
- Tail drop
- Weighted Random Early Detection
Tail Drop
Es usado como un basico y drastico medio de evitar la congestion en colas de puertos. Los paquetes son puestos en una cola donde la cabeza son cercanos a ser transmitidos y el final es lejano en la cola. cuando la cola se llena en capacidad, algun nuevo paquete que arriva son simplemente dropeados en el fin de la cola.
Weighted Random Early Detection
Dropea paquetes aleatoriamente en la cola, tal que nunca se llene.
dentro de cada cola tenemos varios umbrales que WRED puede usar, cada umbral marca el nivel en la cola donde empezará a dropear, por ejemplo si tenemos 2 umbrales, el primero al 50% con CoS 0 y 1 y otro umbral al 75% para CoS 2 y 3, cuando la cola se llene al 50% empezará a dropear paquetes con CoS 0 y 1, si pese a ello se llena la cola al 75% enpezará a dropear paquetes con CoS 2 y 3.
Switch Port Queues
p: priority queue
q: estandar queue
t: configurable wred queue
ejemplo: 1p2q2t
el priority queue nunca tiene un umbral, todos los paquetes se envian.
show queueing interface f0/12
show interface f0/12 capabilities
jueves, 11 de octubre de 2007
MULTICAST
Overview :
En una red tenemos 3 tipos de trafico IP:
-Unicast
-Broadcast
-Multicast
Generalmente el tráfico es unidireccional, por que muchos host están recibiendo la misma data. sin embargo el paquete de retorno puede ser unicast.
Tambien el tráfico es enviado como best-effort connectionless, utilizando UDP comunmente.
Host que quieren recibir data de una fuente multicast pueden entrar o salir dinamicamente de grupos multicast, tambien un host puede decidir ser miembro de uno o más grupos multicast al mismo tiempo. La tarea de la red será enviar tráfico multicast al grupo miembro sin molestar a host no interesados.
Multicast Addressing :
se tiene la clase C en el rango de 224.0.0.0 a 239.255.255.255 estrictamente para multicast. Los dispositivos de red pueden rapidamente discriminar con sólo ver los 4 mas significativos bits, 1110.
Para relacionar una IP multicast con una direccion MAC no se usa ARP, en su lugar se usa un valor identificador reservado único (OUI) que siempre inicia con 0100.5e el próximo bit es 0 (cero) y los 23 bit restantes son mapeados utilizando los menores bits de la direccion multicast IP.
Se nota que 5 bits no son transferidos dentro de la MAC address, por lo que existe la posibilidad de que no sean únicos, pueden haber 32 diferentes IP multicast con la misma MAC Address.
Algunas de las direcciones IP multicast se reservan para un uso particular :
Completo espacio multicast : 224.0.0.0 - 239.255.255.255
link-local address : 224.0.0.0 - 224.0.0.255 usado por protocolos de red, sólo en un segmento de red, el router no reenvía estos paquetes.
Administratively scoped address : 239.0.0.0 - 239.255.255.255 usado en privados dominios multicast, no pueden ser ruteadas entre dominios.
Globally scoped address : 224.0.1.0 - 238.255.255.255 usado por una entidad, pueden ser ruteados, deben ser unicos y globalmente significativos.
Ruteando tráfico Multicast :
El tráfico IP Multicast debe ser ruteado igual que otro paquete capa 3, la diferencia es conocer donde enviar los paquetes. Los paquetes unicast tienen un solo interface destino (aun si tenemos multiples paths), mientras que lon paquetes IP multicast pueden tener varios interfaces destinos, dependiendo donde los recipientes son localizados.
Se tienen varios protocolos de enrutamiento multicast, pero nos enfocaremos en PIM Protocol Independent Multicast.
primero debemos de habilitar multicast routing en el router con el sgt comando :
switch(config)# ip multicast-routing
Multicast Trees
El router debe determinar el forwarding path de los paquetes multicast desde la fuente a cada uno de los recipientes. Pensemos en la red como un arbol, en la raiz se encuentra la fuente enviando paquetes a específicas direcciones multicast.
Si un router conoce donde se encuentran los grupos de recipientes, tambien conoce a que bifurcaciones del arbol enviar los paquetes. Algunos router no tendrán recipientes downstream por lo que no se le enviará trafico multicast, otros router pueden tener recipientes downstream.
Esta estructura es similar a Spanning Tree Topology, con un root y nodos en los extremos (recipientes), tambien es libre de loops.
Reverse Path Forwarding
Router usualmente realizan un test a cada paquete multicast que reciben. RPF es para asegurar que los paquetes no sean inyectados de retorno al arbol en una locación.
Cuando un paquete es recibido en una interface del router, la fuente IP address es inspeccionada. La idea es verificar que el paquete arrivó en la misma interfaz donde la fuente se encuentre, si esto es verdadero el paquete procede de una rama del arbol lejos de la fuente. Si no es verdadero el paquete se inyectó en una inesperada interface, dirigido hacia la fuente.
Al realizar el RFM, el router PIM verá la dirección de la fuente en la tabla de enrutamiento unicast. Si la interface next-hop usado para alcanzar la fuente hace match con la interfaz donde el paquete fue recibido, el paquete puede ser enviado o replicado a los recipientes multicast, en otro caso es descartado.
IGMP
Como hace el router para conocer los recipientes de un grupo multicast ? al recibir trafico multicast de una fuente, ambos la fuente y cada recipiente deben primero ingresar a un comun grupo multicast. este grupo es también conocido por el multicast IP address.
Un host puede entrar a un grupo multicast por enviar un request a un router local. Esto a travéz del protocolo IGMP. ahora tenemos IGMPv2. Cuando varios host entran a un grupo por contactarse a sus router locales, es el protocolo PIM el que conecta estos puntos para formar el arbol multicast entre routers.
IGMPv1
Al entrar a un grupo multicast, un host puede dinamicamente enviar un mensae Membership Report IGMP a este router local. Este mensaje le dice al router a que grupo multicast address los host estan registrandose.
El multicast address es usado como el destino IP address, como el grupo que se lista en el mensaje.
Cada 60 seg, un router en cada segmento de red preguntan a todos los host para ver si estan interesados en recibir tráfico multicast. El roouter es conocido como el IGMPv1 querier y funciona simplemente para invitar a host a inscribirse al grupo. Queries son enviados al 224.0.0.1 all-hosts. Los host interesados en inscribirse o seguir recibiendo responden con un membership report.
Host pueden ingresar a un grupo multicast en cualquier tiempo, sin embargo IGMPv1 no tiene un mecanismo que permita al host dejar el grupo si este no está intersado. En su lugar si no se recibe en 3 tiempos de query intervalos se deja al host fuera del grupo. Esto produce que el tráfico siga enviandose al grupo hasta 3 minutos despues que se paralizó el escucha.
notamos que el router no necesita mantener una completa lista de cada grupo multicast que es activo, sólo necesita recordar las interfaces en las que se encuentran activas.
IGMPv2
Los queries pueden ser enviados como general queries a todos los host (como en IGMPv1), asi como un grupo específico de queries a sólo miembros de un grupo específico.
Tambien los host son permitidos a dejar un grupo dinamicamente, el host envía un mensaje Leave Group a todos los routers 224.0.0.2 .
Nota: si algun IGMPv1 router está en un segmento, todos los routers deben correr OGMPv1, de otra manera los router IGMPv1 no conocerán los mensajes IGMPv2.
sobre interfaces con PIM configurados, IGMPv2 es habilitado.
PIM
Protocolo de enrutamiento para enviar trafico multicast. Opera independientemente de algun otro protocolo.
Hace uso de la tabla de enrutamiento unicast y no mantiene otra tabla.
PIM puede operar en 2 modos, dependiendo de la densidad de los recipientes en un grupo multicast, cisco a desarrollado un tercer modo hibrido :
- PIM Dense Mode
- PIM Sparse Mode
- PIM Sparse-Dense Mode
tambien tenemos 2 versiones de PIM 1 y 2.
PIM Dense Mode
Tambien llamado PIM-DM, si es seguro asumir que los recipeintes de grupos multicast estan localizados en cada subnet.
El multicast arbol es construido primero por permitir trafico de la fuente a cada dense mode router en la red. El arbol crece de arriba a abajo. Por un corto tiempo, innecesario tráfico es permitido. Sin embargo cada router recibe tráfico para el grupo, éste decide donde están los activos recipientes esperando a recibir data.
si es así el router permanece quieto y deja que el flujo continue. Si no tiene host registrados para el grupo multicast dentro del router, envía un mensaje Prune al vecino dirigido a la fuente. La rama del arbol es puesto prune off tal que innecesario trafico no continua.
Para configurar PIM Dense Mode en una interface, se usa el sgt comando :
switch(config-if)# ip pim dense-mode
SPIM Sparse Mode
Tambien llamado PIM-SM, con la diferencia de que el arbol multicast no se extiende al router mientras un host no esté inscrito, el arbol se contruye de abajo hacia arriba.
Se trabaja con la idea de una estructura de arbol compartida, donde el root no es necesariamente la fuente multicast. El root es centralmente localizado en la red. Este es llamado Rendezvous Pint (RP).
switch(config-if)# ip pim sparse-mode
PIM Sparse-Dense Mode
Se puede soportar ambos, por que existen en diferentes grupos multicast en la red. Si un grupo tiene RP definido, Sparse Mode es usado, en otro caso Dense Mode .
se configura con :
switch(config-if)# ip pim sparse-dense mode
Comandos para verificar multicast Routing con PIM
show ip route - muestra validas rutas
show ip pim neighbor - muestra vecinos PIM routers
show ip rpf ip-address - verifica RPF informacion para una direccion host
show ip pim rp - muestra PIM RPs
show ip pim autorp - muestra PIMv1 Auto-RP
En una red tenemos 3 tipos de trafico IP:
-Unicast
-Broadcast
-Multicast
Generalmente el tráfico es unidireccional, por que muchos host están recibiendo la misma data. sin embargo el paquete de retorno puede ser unicast.
Tambien el tráfico es enviado como best-effort connectionless, utilizando UDP comunmente.
Host que quieren recibir data de una fuente multicast pueden entrar o salir dinamicamente de grupos multicast, tambien un host puede decidir ser miembro de uno o más grupos multicast al mismo tiempo. La tarea de la red será enviar tráfico multicast al grupo miembro sin molestar a host no interesados.
Multicast Addressing :
se tiene la clase C en el rango de 224.0.0.0 a 239.255.255.255 estrictamente para multicast. Los dispositivos de red pueden rapidamente discriminar con sólo ver los 4 mas significativos bits, 1110.
Para relacionar una IP multicast con una direccion MAC no se usa ARP, en su lugar se usa un valor identificador reservado único (OUI) que siempre inicia con 0100.5e el próximo bit es 0 (cero) y los 23 bit restantes son mapeados utilizando los menores bits de la direccion multicast IP.
Se nota que 5 bits no son transferidos dentro de la MAC address, por lo que existe la posibilidad de que no sean únicos, pueden haber 32 diferentes IP multicast con la misma MAC Address.
Algunas de las direcciones IP multicast se reservan para un uso particular :
Completo espacio multicast : 224.0.0.0 - 239.255.255.255
link-local address : 224.0.0.0 - 224.0.0.255 usado por protocolos de red, sólo en un segmento de red, el router no reenvía estos paquetes.
Administratively scoped address : 239.0.0.0 - 239.255.255.255 usado en privados dominios multicast, no pueden ser ruteadas entre dominios.
Globally scoped address : 224.0.1.0 - 238.255.255.255 usado por una entidad, pueden ser ruteados, deben ser unicos y globalmente significativos.
Ruteando tráfico Multicast :
El tráfico IP Multicast debe ser ruteado igual que otro paquete capa 3, la diferencia es conocer donde enviar los paquetes. Los paquetes unicast tienen un solo interface destino (aun si tenemos multiples paths), mientras que lon paquetes IP multicast pueden tener varios interfaces destinos, dependiendo donde los recipientes son localizados.
Se tienen varios protocolos de enrutamiento multicast, pero nos enfocaremos en PIM Protocol Independent Multicast.
primero debemos de habilitar multicast routing en el router con el sgt comando :
switch(config)# ip multicast-routing
Multicast Trees
El router debe determinar el forwarding path de los paquetes multicast desde la fuente a cada uno de los recipientes. Pensemos en la red como un arbol, en la raiz se encuentra la fuente enviando paquetes a específicas direcciones multicast.
Si un router conoce donde se encuentran los grupos de recipientes, tambien conoce a que bifurcaciones del arbol enviar los paquetes. Algunos router no tendrán recipientes downstream por lo que no se le enviará trafico multicast, otros router pueden tener recipientes downstream.
Esta estructura es similar a Spanning Tree Topology, con un root y nodos en los extremos (recipientes), tambien es libre de loops.
Reverse Path Forwarding
Router usualmente realizan un test a cada paquete multicast que reciben. RPF es para asegurar que los paquetes no sean inyectados de retorno al arbol en una locación.
Cuando un paquete es recibido en una interface del router, la fuente IP address es inspeccionada. La idea es verificar que el paquete arrivó en la misma interfaz donde la fuente se encuentre, si esto es verdadero el paquete procede de una rama del arbol lejos de la fuente. Si no es verdadero el paquete se inyectó en una inesperada interface, dirigido hacia la fuente.
Al realizar el RFM, el router PIM verá la dirección de la fuente en la tabla de enrutamiento unicast. Si la interface next-hop usado para alcanzar la fuente hace match con la interfaz donde el paquete fue recibido, el paquete puede ser enviado o replicado a los recipientes multicast, en otro caso es descartado.
IGMP
Como hace el router para conocer los recipientes de un grupo multicast ? al recibir trafico multicast de una fuente, ambos la fuente y cada recipiente deben primero ingresar a un comun grupo multicast. este grupo es también conocido por el multicast IP address.
Un host puede entrar a un grupo multicast por enviar un request a un router local. Esto a travéz del protocolo IGMP. ahora tenemos IGMPv2. Cuando varios host entran a un grupo por contactarse a sus router locales, es el protocolo PIM el que conecta estos puntos para formar el arbol multicast entre routers.
IGMPv1
Al entrar a un grupo multicast, un host puede dinamicamente enviar un mensae Membership Report IGMP a este router local. Este mensaje le dice al router a que grupo multicast address los host estan registrandose.
El multicast address es usado como el destino IP address, como el grupo que se lista en el mensaje.
Cada 60 seg, un router en cada segmento de red preguntan a todos los host para ver si estan interesados en recibir tráfico multicast. El roouter es conocido como el IGMPv1 querier y funciona simplemente para invitar a host a inscribirse al grupo. Queries son enviados al 224.0.0.1 all-hosts. Los host interesados en inscribirse o seguir recibiendo responden con un membership report.
Host pueden ingresar a un grupo multicast en cualquier tiempo, sin embargo IGMPv1 no tiene un mecanismo que permita al host dejar el grupo si este no está intersado. En su lugar si no se recibe en 3 tiempos de query intervalos se deja al host fuera del grupo. Esto produce que el tráfico siga enviandose al grupo hasta 3 minutos despues que se paralizó el escucha.
notamos que el router no necesita mantener una completa lista de cada grupo multicast que es activo, sólo necesita recordar las interfaces en las que se encuentran activas.
IGMPv2
Los queries pueden ser enviados como general queries a todos los host (como en IGMPv1), asi como un grupo específico de queries a sólo miembros de un grupo específico.
Tambien los host son permitidos a dejar un grupo dinamicamente, el host envía un mensaje Leave Group a todos los routers 224.0.0.2 .
Nota: si algun IGMPv1 router está en un segmento, todos los routers deben correr OGMPv1, de otra manera los router IGMPv1 no conocerán los mensajes IGMPv2.
sobre interfaces con PIM configurados, IGMPv2 es habilitado.
PIM
Protocolo de enrutamiento para enviar trafico multicast. Opera independientemente de algun otro protocolo.
Hace uso de la tabla de enrutamiento unicast y no mantiene otra tabla.
PIM puede operar en 2 modos, dependiendo de la densidad de los recipientes en un grupo multicast, cisco a desarrollado un tercer modo hibrido :
- PIM Dense Mode
- PIM Sparse Mode
- PIM Sparse-Dense Mode
tambien tenemos 2 versiones de PIM 1 y 2.
PIM Dense Mode
Tambien llamado PIM-DM, si es seguro asumir que los recipeintes de grupos multicast estan localizados en cada subnet.
El multicast arbol es construido primero por permitir trafico de la fuente a cada dense mode router en la red. El arbol crece de arriba a abajo. Por un corto tiempo, innecesario tráfico es permitido. Sin embargo cada router recibe tráfico para el grupo, éste decide donde están los activos recipientes esperando a recibir data.
si es así el router permanece quieto y deja que el flujo continue. Si no tiene host registrados para el grupo multicast dentro del router, envía un mensaje Prune al vecino dirigido a la fuente. La rama del arbol es puesto prune off tal que innecesario trafico no continua.
Para configurar PIM Dense Mode en una interface, se usa el sgt comando :
switch(config-if)# ip pim dense-mode
SPIM Sparse Mode
Tambien llamado PIM-SM, con la diferencia de que el arbol multicast no se extiende al router mientras un host no esté inscrito, el arbol se contruye de abajo hacia arriba.
Se trabaja con la idea de una estructura de arbol compartida, donde el root no es necesariamente la fuente multicast. El root es centralmente localizado en la red. Este es llamado Rendezvous Pint (RP).
switch(config-if)# ip pim sparse-mode
PIM Sparse-Dense Mode
Se puede soportar ambos, por que existen en diferentes grupos multicast en la red. Si un grupo tiene RP definido, Sparse Mode es usado, en otro caso Dense Mode .
se configura con :
switch(config-if)# ip pim sparse-dense mode
Comandos para verificar multicast Routing con PIM
show ip route - muestra validas rutas
show ip pim neighbor - muestra vecinos PIM routers
show ip rpf ip-address - verifica RPF informacion para una direccion host
show ip pim rp - muestra PIM RPs
show ip pim autorp - muestra PIMv1 Auto-RP
Router Redundancy and Load Balancing
HSRP:
Propietario de cisco, todos los routers que participan son asignados a un grupo HSRP.
Se elige un activo, un stanby y los demás quedan en estado listen hsrp.
se envian paquetes hello al multicast 224.0.0.2 "all routers" al UPD port 1985 cada 3 segundos.
El numero de grupo puede ser de 0 a 255, pero los routers solo soportan hasta 16 grupos.
Proceso de elección :
Se basa en el priority value (default 100). se puede configurar manualmente con :
switch(config-if)#standby group prioryty value
si los valores priority son iguales se decide por el mayor IP address.
Se presentan los siguientes estados en el router que participa en HSRP:
Disabled, Init, Listen, Speak, Stanby, Active.
El default holdtime timer : 10seg (3 hello time)
lo podemos cambiar con :
switch(config-if)#standby group timers value
Un router que está en estado activo HSRP, por deault no dejará de serlo aún si aparece otro router con mayor prioridad.
Si queremos que un router asuma el estado activo en cuanto esté disponible, utlizamos el preemp :
switch(config-if)#standby group preempt [delay seg]
el router puede preempt inmediatamente, podemos utlizar delay si queremos retardar el estado activo, util cuando tenemos protocolos con tiempos de convergencia.
tambien podemos utilizar un metodo simple de autenticación :
switch(config-if)#standby group authentication string
deberá ser configurado en todos los routers del grupo HSRP.
HSRP dará la oportunidad a otro router de ser el activo en caso de fallas.
Cuando una interface es tracked, hsrp reduce la prioridad en un valor configurado cuando la interface cae. Si más de una interface cae se reduce aun más por cada una.
switch(config-if)#standby group track interface decrementvalue
otro router será elegido active sólo si:
- otro router tiene mayor prioridad
- el router tiene configurado el preempt.
sin preempt el role activo no se le puede dar a otro router
HSRP define una interface virtual que se configurará :
switch(config-if)#standby group ip ip-addr [secondary]
este será el utlizado por todos los miembros del grupo hsrp.
respecto a la MAC address : se forma utilizando el formato : 0000.0c07.acxx
donde xx es el nuemero de grupo en hexadecimal.
por ejemplo el grupo 16 tendra la mac 0000.0c07.ac10
Load Balancing with HSRP :
al tener 2 router uno activo y el otro en standby, el tráfico será cursado por uno de ellos solamente. sin embargo podemos crear 2 grupos y utlizar el artificio siguiente a fin de balancear la carga de los routers y cada uno de ellos sea el standby del otro en caso de fallas.
Virtual Router Redundancy Protocol (VRRP) :
Es un estandar definido en IETF, similar a HSRP.
VRRP provee un gateway de redundancia de un grupo de routers. El activo es llamado master router y los demás están en estado backup.
Los grupos varian de 0 a 255 y las prioridades de 1 a 254, 100 es el default
El virtual MAC address es: 0000.5e00.01xx siendo xx el grupo en hexadecimal.
VRRP advierte cada 1 segundo.
por default tiene configurado el preempt, no tiene mecanismo de tracking interfaces para permitir a otros routers tener el role de master.
VRRP envia advertisements al 224.0.0.18 con protocolo IP 112.
asignar una prioridad: vrrp group priority level
alterar advertisement timer : vrrp group timers advertise [msec] interval
learn advertisement interval del master router : vrrp group timers learn
disable preempting : no vrrp group preempt
cambiar preempt delay : vrrp group preempt [delay seconds]
authentication : vrrp group authentication string
asignar IP virtual : vrrp group ip ip-address [secondary]
Gateway Load balancing Protocol (GLBP)
Protocolo propietario de cisco, para sobrellevar limitaciones de los protocolos redundancia de router existentes, es mucho mas dinamico y robusto.
Es habilitado sólo para el Catalyst 6500 Supervisor 720 con IOS 12.2(14)SX.
Al proveer un router virtua, multiples swich(router) son asignados a un grupo comun GLBP.
Todos los router en el grupo pueden participar y ofrecer load balancing para forwarding una porción o todo el tráfico.
todos los clientes host usan un mismo IP gateway, pero diferentes MAC adress que selecciona un router del grupo.
Se puede ofrecer los siguientes metodos de balanceo :
Round robin
Weighted
Host-dependent
Propietario de cisco, todos los routers que participan son asignados a un grupo HSRP.
Se elige un activo, un stanby y los demás quedan en estado listen hsrp.
se envian paquetes hello al multicast 224.0.0.2 "all routers" al UPD port 1985 cada 3 segundos.
El numero de grupo puede ser de 0 a 255, pero los routers solo soportan hasta 16 grupos.
Proceso de elección :
Se basa en el priority value (default 100). se puede configurar manualmente con :
switch(config-if)#standby group prioryty value
si los valores priority son iguales se decide por el mayor IP address.
Se presentan los siguientes estados en el router que participa en HSRP:
Disabled, Init, Listen, Speak, Stanby, Active.
El default holdtime timer : 10seg (3 hello time)
lo podemos cambiar con :
switch(config-if)#standby group timers value
Un router que está en estado activo HSRP, por deault no dejará de serlo aún si aparece otro router con mayor prioridad.
Si queremos que un router asuma el estado activo en cuanto esté disponible, utlizamos el preemp :
switch(config-if)#standby group preempt [delay seg]
el router puede preempt inmediatamente, podemos utlizar delay si queremos retardar el estado activo, util cuando tenemos protocolos con tiempos de convergencia.
tambien podemos utilizar un metodo simple de autenticación :
switch(config-if)#standby group authentication string
deberá ser configurado en todos los routers del grupo HSRP.
HSRP dará la oportunidad a otro router de ser el activo en caso de fallas.
Cuando una interface es tracked, hsrp reduce la prioridad en un valor configurado cuando la interface cae. Si más de una interface cae se reduce aun más por cada una.
switch(config-if)#standby group track interface decrementvalue
otro router será elegido active sólo si:
- otro router tiene mayor prioridad
- el router tiene configurado el preempt.
sin preempt el role activo no se le puede dar a otro router
HSRP define una interface virtual que se configurará :
switch(config-if)#standby group ip ip-addr [secondary]
este será el utlizado por todos los miembros del grupo hsrp.
respecto a la MAC address : se forma utilizando el formato : 0000.0c07.acxx
donde xx es el nuemero de grupo en hexadecimal.
por ejemplo el grupo 16 tendra la mac 0000.0c07.ac10
Load Balancing with HSRP :
al tener 2 router uno activo y el otro en standby, el tráfico será cursado por uno de ellos solamente. sin embargo podemos crear 2 grupos y utlizar el artificio siguiente a fin de balancear la carga de los routers y cada uno de ellos sea el standby del otro en caso de fallas.
Virtual Router Redundancy Protocol (VRRP) :
Es un estandar definido en IETF, similar a HSRP.
VRRP provee un gateway de redundancia de un grupo de routers. El activo es llamado master router y los demás están en estado backup.
Los grupos varian de 0 a 255 y las prioridades de 1 a 254, 100 es el default
El virtual MAC address es: 0000.5e00.01xx siendo xx el grupo en hexadecimal.
VRRP advierte cada 1 segundo.
por default tiene configurado el preempt, no tiene mecanismo de tracking interfaces para permitir a otros routers tener el role de master.
VRRP envia advertisements al 224.0.0.18 con protocolo IP 112.
asignar una prioridad: vrrp group priority level
alterar advertisement timer : vrrp group timers advertise [msec] interval
learn advertisement interval del master router : vrrp group timers learn
disable preempting : no vrrp group preempt
cambiar preempt delay : vrrp group preempt [delay seconds]
authentication : vrrp group authentication string
asignar IP virtual : vrrp group ip ip-address [secondary]
Gateway Load balancing Protocol (GLBP)
Protocolo propietario de cisco, para sobrellevar limitaciones de los protocolos redundancia de router existentes, es mucho mas dinamico y robusto.
Es habilitado sólo para el Catalyst 6500 Supervisor 720 con IOS 12.2(14)SX.
Al proveer un router virtua, multiples swich(router) son asignados a un grupo comun GLBP.
Todos los router en el grupo pueden participar y ofrecer load balancing para forwarding una porción o todo el tráfico.
todos los clientes host usan un mismo IP gateway, pero diferentes MAC adress que selecciona un router del grupo.
Se puede ofrecer los siguientes metodos de balanceo :
Round robin
Weighted
Host-dependent
martes, 2 de octubre de 2007
Understanding Spanning-Tree Protocol Topology Changes
Que pasa cuando se presentan TCN en un entorno STP ?
El switch que detecta el cambio de topología, envia un TCN al root bridge, éste a su vez envía un TCA al switch que envió el TCN e inunda a todos los demás switch con TC, de ésta manera todos los switch se enteran de que ocurrió un cambio en la topología.
Para evitar el problema del default aging time (5min), todos los switch modifican éste tiempo a un valor mag age + forward delay (20+15 seg), de ésta manera la tabla de arp se actualiza más rápido.
Esto es una ventaja pero tambien trae consecuencias, por lo que se recomienda configurar Port Fast en los puertos que no participan en el STP. mayor detalle se menciona en el siguiente artículo en cisco : http://www.cisco.com/warp/public/473/17.html
El switch que detecta el cambio de topología, envia un TCN al root bridge, éste a su vez envía un TCA al switch que envió el TCN e inunda a todos los demás switch con TC, de ésta manera todos los switch se enteran de que ocurrió un cambio en la topología.
Para evitar el problema del default aging time (5min), todos los switch modifican éste tiempo a un valor mag age + forward delay (20+15 seg), de ésta manera la tabla de arp se actualiza más rápido.
Esto es una ventaja pero tambien trae consecuencias, por lo que se recomienda configurar Port Fast en los puertos que no participan en el STP. mayor detalle se menciona en el siguiente artículo en cisco : http://www.cisco.com/warp/public/473/17.html
lunes, 17 de septiembre de 2007
Asterisk
http://blog.infomagia.com/index.php?cat=2
Empresa que se dedica a Asterisk :
http://www.downetworks.co.cr/?gclid=CKb91p2lzI4CFQIQFQodW04bAA
Como enlazar 2 *
http://www.asterisk-peru.com/node/800
empresas asterisk
http://www.synetcom.com.mx/asterisk.php
interesante link :
http://www.asterisk-peru.com/node/453
Negocios con VoIP
http://www.4m.com.pe
Empresa que se dedica a Asterisk :
http://www.downetworks.co.cr/?gclid=CKb91p2lzI4CFQIQFQodW04bAA
Como enlazar 2 *
http://www.asterisk-peru.com/node/800
empresas asterisk
http://www.synetcom.com.mx/asterisk.php
interesante link :
http://www.asterisk-peru.com/node/453
Negocios con VoIP
http://www.4m.com.pe
sábado, 15 de septiembre de 2007
links de interes
http://picasaweb.google.com/ahsanchez Fotos varios
http://www.free-tests.com/ examenes cisco ccna ccnp
http://www.julianmenendez.es/documentos/asterisk_hylafax_iaxmodem
http://www.speakeasy.net/speedtest/ probar velocidad de acceso a internet
http://home.cfl.rr.com/eaa/Bandwidth.htm
http://www.net130.com/CMS/Pub/cert1/cer_ccnp1/cert_ccnp_ActualTests/2005_06_27_27566.htm
http://www.javapassion.com/j2ee/index.html#Introduction_of_this_course
http://www.programemos.com/index.php?option=com_content&task=view&id=40&Itemid=52 envio de correo manualmente
http://www.asteriskblog.com/
http://www.google.com/intl/es/options/ herramientas google
http://www.seologs.com/ip-domains.html verificar dominios alojados en la misma IP
http://www.free-tests.com/ examenes cisco ccna ccnp
http://www.julianmenendez.es/documentos/asterisk_hylafax_iaxmodem
http://www.speakeasy.net/speedtest/ probar velocidad de acceso a internet
http://home.cfl.rr.com/eaa/Bandwidth.htm
http://www.net130.com/CMS/Pub/cert1/cer_ccnp1/cert_ccnp_ActualTests/2005_06_27_27566.htm
http://www.javapassion.com/j2ee/index.html#Introduction_of_this_course
http://www.programemos.com/index.php?option=com_content&task=view&id=40&Itemid=52 envio de correo manualmente
http://www.asteriskblog.com/
http://www.google.com/intl/es/options/ herramientas google
http://www.seologs.com/ip-domains.html verificar dominios alojados en la misma IP
Suscribirse a:
Entradas (Atom)