[1] http://www.voip-info.org/wiki/view/Asterisk+cli+originate
[2] http://www.voip-info.org/wiki/view/Asterisk+manager+API
[3] http://www.voip-info.org/tiki-index.php?page=Asterisk+auto-dial+out
En mi caso funcionò :
originate SIP/Sitatel/13582352 extension 1001
se realizò la llamada a mi rpm y luego lo conectò a la extension 1001 (primero timbrò el celular y luego el anexo).
desde linux :
FaJoa:~# asterisk -rx "originate SIP/Sitatel/13582352 extension 1001"
originate SIP/Sitatel/13582352 application Festival " el circuito 22352 esta caido, el circuito 22352 esta caido"
llama al celu y lee los mensajes, pero con un tono robotizado, falta afinar ese tema.
para instalar festival:
http://phylevn.mexrom.net/index.php/Blog/CommentsRSS/id/index.php/blog/show/67.html
http://www.voztovoice.org/?q=node/97
Festival con voces en español:
Las voces las podeis descargar desde aquí:
http://forja.guadalinex.org/repositorio/frs/?group_id=21&release_id=110
jueves, 25 de diciembre de 2008
jueves, 18 de diciembre de 2008
Troubleshooting SIP Trunks with Cisco CallManager 5.x
El rfc 2833 (DTMF) Media Termination Point (MTP) pasa a travéz caracteristicas de transparente DTMF tonos entre SIP endpoint que requieran o transcoding o el uso de RSVP (Resource Reservation Protocol )
SIP with CallManager 5.x
Introduce mejoras a SIP Trunks y sobrelleva las limitantes de release anteriores como un simple codec soportado, carecer de soporte de video y el obligado soporte MTP Media terminal point para RFC2833 DTMF.
The other enhancements to SIP trunks in Cisco Unified CallManager 5.0 are the support for REFER, header replacement, Subscribe/Notify, message waiting indication (MWI), MTP removal, video support, multiple SIP trunks per inbound port number, SIP Redirection 3XX, transport layer security (TLS), digest authentication, call preservation, and T.38 fax relay.
Media Termination Point for SIP Trunks
Se puede configurar dispositivos SIP en el CallManager (lineas y trunks) a siempre usar MTP, si los parametros seteados no son usar MTP (por default), cisco localiza dinamicamente un MTP si el metodo DTMF para llamadas no son compatibles.
Por ejemplo SCCP phones soportan sólamente out-of-band DTMF.
Telefonos SIP (model 7905, 7912, 7940, 7960) soportan RFC 2833.
Como los metodos DTMF no son los mismos, cisco localiza un MTP.
Si un SCCP phone soporta tanto RFC2833 y out-of-band como es el caso del 7971, cisco no localiza un MTP por que ambos phones soportan RFC2833.
con el mismo metodo de DTMF soportado en ambos telefonos, no es necesario un MTP.
SIP with CallManager 5.x
Introduce mejoras a SIP Trunks y sobrelleva las limitantes de release anteriores como un simple codec soportado, carecer de soporte de video y el obligado soporte MTP Media terminal point para RFC2833 DTMF.
The other enhancements to SIP trunks in Cisco Unified CallManager 5.0 are the support for REFER, header replacement, Subscribe/Notify, message waiting indication (MWI), MTP removal, video support, multiple SIP trunks per inbound port number, SIP Redirection 3XX, transport layer security (TLS), digest authentication, call preservation, and T.38 fax relay.
Media Termination Point for SIP Trunks
Se puede configurar dispositivos SIP en el CallManager (lineas y trunks) a siempre usar MTP, si los parametros seteados no son usar MTP (por default), cisco localiza dinamicamente un MTP si el metodo DTMF para llamadas no son compatibles.
Por ejemplo SCCP phones soportan sólamente out-of-band DTMF.
Telefonos SIP (model 7905, 7912, 7940, 7960) soportan RFC 2833.
Como los metodos DTMF no son los mismos, cisco localiza un MTP.
Si un SCCP phone soporta tanto RFC2833 y out-of-band como es el caso del 7971, cisco no localiza un MTP por que ambos phones soportan RFC2833.
con el mismo metodo de DTMF soportado en ambos telefonos, no es necesario un MTP.
Understanding Session Initiation Protocol (SIP)
Se utilizan los siguientes componentes:
•SIP Proxy Server— Trabaja como un dispositivo intermedio que recibe request SIP de un cliente y forwards el request a nombre del cliente. Puede proveer funciones como authentication, authorization, network access control, routing, reliable request retransmission, and security.
•Redirect Server— Provee al cliente con info acerca del next hop o hops que un mensaje debe tomar, el cliente contacta con el next hop server o user agent server directamente.
•Registrar Server— El server de registro procesa request de user agent clients para registro de su ubicacion actual. Redirect o Proxy server a menudo contienen servidores de registro.
•User Agent (UA)— Una combinacion de user agent client (UAC) y user agent server (UAS) que inicia y recibe SIP request. Un UAC inicia un SIP request. Un UAS es una aplicacion server que contacta al user cuando este recibe yn SIP request. El UAS devuelve yna respuesta a nombre de el user. Cisco CallManager puede actuar como ambos server o cliente (un back-to-back user agent).
SIP usa un request/response metodo para establecer comunicaciones entre varios componentes en la red y ultimadamente establecer una llamada o sesion entre 2 o mas endpoints. Una simple sesion puede envolver varios clientes y servers.
identificacion de usuarios en una red SIP trabaja con :
•A unique phone or extension number.
•A unique SIP address that appears similar to an e-mail address and uses the format sip:@. The user ID can be either a user name or an E.164 address. Cisco CallManager only supports E.164 addresses; it does not support email addresses.
SIP and Cisco CallManager
Todos los protocolos requieren una interfaz de señalizacion (trunk) o un gateway sean creados para aceptar y originar llamadas. Para SIP el usuario debe crear una interface de señalizacion.
Interfaces de señalizacion SIP conectan redes Cisco CallManager y redes SIP que son atendidas por un SIP Proxy Server. Como con otros protocolos, componentes SIP encajan bajo la capa de dispositivos (layer device) de una arquitectura CallManager.
Como en el caso de H323, multiples logicas interfaces de señalizacion SIP pueden ser configurados en la base de datos del CallManager y asociados a route groups. route lists y route patterns.
Para proveer redundancia, en el caso de falla de una interface logica SIP, otra interface logica SIP debe proveer servicio en el mismo route group list. tambien podemos asignar multiples modos Cisco CallManager bajo un pool de dispositivos interfaces de señalizacion SIP.
Interfaces de señalizacion SIP usan enrutamiento basado en puerto, con una interface de señalizacion SIP conectando a una red SIP. Cisco CallManager aceptan llamadas de un dispositivo SIP siempre y cuando el mensaje arrive en el configurado puerto de entrada. Cuando se configure multiple interfaces de señalizacion, configure un unico incomming-port por cada interface SIP. Utilizar el mismo puerto para varias interfaces de señalización pueden causar una alarma.
SIP Networks
Media Termination Point (MTP) Devices
Cisco CallManager requiere un RFC2833 dual tone multifrequency (DTMF) compatible con dispositivos MTP para hacer llamadas SIP.
El actual standar para SIP usa tipo de payload in-band RTP para indicar tonos DTMF. AVVID componentes como telefonos SCCP IP soportan solo payload DTMF out-of-band . Por lo tanto un dispositivo MTP compatible con RFC2833 actua como un translator entre inband and out-of-band DTMF.
DTMF Relay Calls Between SIP Endpoints and Cisco CallManager
Basado en el RFC 2833 el estandar SIP usa tipo de payload in-band para indicar tonos DTMF. Componentes AVVID como SCCP IP Phone no soportan in-band payload. Un dispositivo MTP compatible con RFC 2833 monitorea para los tipos de payloads y traduce entre in-band y out-band los tipos de payload.
El siguiente flujo de llamada muestra el dispositivo software MTP procesando inband DTMF digitos de un SIP Phone para comunicarse con Gateway PRI, el stream RTP lleva RFC 2833 DTMF , como indica por un dinamico tipo de payload.
1. The SIP Phone initiates a payload type response when the user enters a number on the keypad. The SIP Phone transfers the DTMF in-band digit (per RFC 2833) to the MTP device.
2. The MTP device extracts the in-band DTMF digit and passes the digit out of band to Cisco CallManager.
3. Cisco CallManager then relays the DTMF digit out of band to the gateway or IVR system.
Generating DTMF Digits
1. The SCCP IP Phone user presses buttons on the keypad. Cisco CallManager collects the out-of-band digits from the SCCP IP phone.
2. Cisco CallManager passes the out-of-band digits to the MTP device.
3. The MTP device converts the digits to RFC 2833 RTP compliant inband digits and forwards them to the SIP client.
Trunk Configuration Checklist
Configuration Steps
Procedures and Related Topics
Step 1
Create a SIP trunk.
For outgoing calls, configure the destination address (the address of the SIP Proxy Server).
Configure the destination port.
Configure a unique incoming port for each SIP interface.
Adding a Trunk, Cisco CallManager Administration Guide
Trunk Configuration Settings, Cisco CallManager Administration Guide
Step 2
Verify the RFC 2833 compliant MTP device is configured.
Trunk Configuration Settings, Cisco CallManager Administration Guide
In the trunk configuration, the MTP field is always checked. SIP requires an RFC 2833 compliant MTP device. For more information on MTP, see Media Termination Point Configuration, Cisco CallManager Administration Guide.
Step 3
Assign to a Route Pattern, Route Group, or Route List, if needed.
Route Pattern/Hunt Pilot Configuration,Cisco CallManager Administration Guide
Route Group Configuration, Cisco CallManager Administration Guide
Route/Hunt List Configuration, Cisco CallManager Administration Guide
Step 4
Configure SIP timers, counters, and service parameters, if necessary.
Service Parameters Configuration, Cisco CallManager Administration Guide.
For specific configurable values, see SIP Service Parameters.
Step 5
Verify the Annunciator is active, if necessary.
Annunciator Configuration, Cisco CallManager Administration Guide.
Step 6
If a SIP Proxy server is used as the destination address, configure static routes to point to all IP addresses or domain names of the SIP interface Call Manager Group.
Trunk Configuration Settings, Cisco CallManager Administration Guide
The device pool field can be an IP address, fully-qualified domain name (FQDN), or DNS SRV name.
•SIP Proxy Server— Trabaja como un dispositivo intermedio que recibe request SIP de un cliente y forwards el request a nombre del cliente. Puede proveer funciones como authentication, authorization, network access control, routing, reliable request retransmission, and security.
•Redirect Server— Provee al cliente con info acerca del next hop o hops que un mensaje debe tomar, el cliente contacta con el next hop server o user agent server directamente.
•Registrar Server— El server de registro procesa request de user agent clients para registro de su ubicacion actual. Redirect o Proxy server a menudo contienen servidores de registro.
•User Agent (UA)— Una combinacion de user agent client (UAC) y user agent server (UAS) que inicia y recibe SIP request. Un UAC inicia un SIP request. Un UAS es una aplicacion server que contacta al user cuando este recibe yn SIP request. El UAS devuelve yna respuesta a nombre de el user. Cisco CallManager puede actuar como ambos server o cliente (un back-to-back user agent).
SIP usa un request/response metodo para establecer comunicaciones entre varios componentes en la red y ultimadamente establecer una llamada o sesion entre 2 o mas endpoints. Una simple sesion puede envolver varios clientes y servers.
identificacion de usuarios en una red SIP trabaja con :
•A unique phone or extension number.
•A unique SIP address that appears similar to an e-mail address and uses the format sip:
SIP and Cisco CallManager
Todos los protocolos requieren una interfaz de señalizacion (trunk) o un gateway sean creados para aceptar y originar llamadas. Para SIP el usuario debe crear una interface de señalizacion.
Interfaces de señalizacion SIP conectan redes Cisco CallManager y redes SIP que son atendidas por un SIP Proxy Server. Como con otros protocolos, componentes SIP encajan bajo la capa de dispositivos (layer device) de una arquitectura CallManager.
Como en el caso de H323, multiples logicas interfaces de señalizacion SIP pueden ser configurados en la base de datos del CallManager y asociados a route groups. route lists y route patterns.
Para proveer redundancia, en el caso de falla de una interface logica SIP, otra interface logica SIP debe proveer servicio en el mismo route group list. tambien podemos asignar multiples modos Cisco CallManager bajo un pool de dispositivos interfaces de señalizacion SIP.
Interfaces de señalizacion SIP usan enrutamiento basado en puerto, con una interface de señalizacion SIP conectando a una red SIP. Cisco CallManager aceptan llamadas de un dispositivo SIP siempre y cuando el mensaje arrive en el configurado puerto de entrada. Cuando se configure multiple interfaces de señalizacion, configure un unico incomming-port por cada interface SIP. Utilizar el mismo puerto para varias interfaces de señalización pueden causar una alarma.
SIP Networks
Media Termination Point (MTP) Devices
Cisco CallManager requiere un RFC2833 dual tone multifrequency (DTMF) compatible con dispositivos MTP para hacer llamadas SIP.
El actual standar para SIP usa tipo de payload in-band RTP para indicar tonos DTMF. AVVID componentes como telefonos SCCP IP soportan solo payload DTMF out-of-band . Por lo tanto un dispositivo MTP compatible con RFC2833 actua como un translator entre inband and out-of-band DTMF.
DTMF Relay Calls Between SIP Endpoints and Cisco CallManager
Basado en el RFC 2833 el estandar SIP usa tipo de payload in-band para indicar tonos DTMF. Componentes AVVID como SCCP IP Phone no soportan in-band payload. Un dispositivo MTP compatible con RFC 2833 monitorea para los tipos de payloads y traduce entre in-band y out-band los tipos de payload.
El siguiente flujo de llamada muestra el dispositivo software MTP procesando inband DTMF digitos de un SIP Phone para comunicarse con Gateway PRI, el stream RTP lleva RFC 2833 DTMF , como indica por un dinamico tipo de payload.
1. The SIP Phone initiates a payload type response when the user enters a number on the keypad. The SIP Phone transfers the DTMF in-band digit (per RFC 2833) to the MTP device.
2. The MTP device extracts the in-band DTMF digit and passes the digit out of band to Cisco CallManager.
3. Cisco CallManager then relays the DTMF digit out of band to the gateway or IVR system.
Generating DTMF Digits
1. The SCCP IP Phone user presses buttons on the keypad. Cisco CallManager collects the out-of-band digits from the SCCP IP phone.
2. Cisco CallManager passes the out-of-band digits to the MTP device.
3. The MTP device converts the digits to RFC 2833 RTP compliant inband digits and forwards them to the SIP client.
Trunk Configuration Checklist
Configuration Steps
Procedures and Related Topics
Step 1
Create a SIP trunk.
For outgoing calls, configure the destination address (the address of the SIP Proxy Server).
Configure the destination port.
Configure a unique incoming port for each SIP interface.
Adding a Trunk, Cisco CallManager Administration Guide
Trunk Configuration Settings, Cisco CallManager Administration Guide
Step 2
Verify the RFC 2833 compliant MTP device is configured.
Trunk Configuration Settings, Cisco CallManager Administration Guide
In the trunk configuration, the MTP field is always checked. SIP requires an RFC 2833 compliant MTP device. For more information on MTP, see Media Termination Point Configuration, Cisco CallManager Administration Guide.
Step 3
Assign to a Route Pattern, Route Group, or Route List, if needed.
Route Pattern/Hunt Pilot Configuration,Cisco CallManager Administration Guide
Route Group Configuration, Cisco CallManager Administration Guide
Route/Hunt List Configuration, Cisco CallManager Administration Guide
Step 4
Configure SIP timers, counters, and service parameters, if necessary.
Service Parameters Configuration, Cisco CallManager Administration Guide.
For specific configurable values, see SIP Service Parameters.
Step 5
Verify the Annunciator is active, if necessary.
Annunciator Configuration, Cisco CallManager Administration Guide.
Step 6
If a SIP Proxy server is used as the destination address, configure static routes to point to all IP addresses or domain names of the SIP interface Call Manager Group.
Trunk Configuration Settings, Cisco CallManager Administration Guide
The device pool field can be an IP address, fully-qualified domain name (FQDN), or DNS SRV name.
Cisco CallManager Trunk SIP
En un entorno de procesos de llamadas distribuido, Cisco Callmanager se comunica con otro cluster Cisco Callmanager, PSTN u otro dispositivo como PBX, utilizando trunk signaling y gateway de voz.
Configuracion TRUNK
la configuracion Trunk en Cisco CallManager depende del diseño de red y protocolos de control de llamadas que son usados en IP WAN. Todos los protocolos requieren que un signaling interface (trunk) o un gateway debe ser creado para aceptar y originar llamadas. Se especifica el tipo de signaling interface cuando se configura el gateway en CallManager Cisco. Por ejemplo al configurar conecciones QSIG al CallManager se debe añadir un MCGP voice gateway que soporte protocol QSIG. Se configura el E1 PRI trunk interface a usar el tipo de protocol QSIG.
Trunk Types in Cisco CallManager Administration
•H.225 Trunk (Gatekeeper Controlled)
In a H.323 network that uses gatekeepers, use an H.225 trunk with gatekeeper control to configure a connection to a gatekeeper for access to other Cisco CallManager clusters and to H.323 devices. An H.225 trunk can communicate with any H.323 gatekeeper-controlled endpoint. When you configure an H.323 gateway with gatekeeper control in Cisco CallManager Administration, use an H.225 trunk. To choose this method, use Device > Trunk and choose H.225 Trunk (Gatekeeper Controlled).
•Intercluster Trunk (Gatekeeper Controlled)
In a distributed call-processing network with gatekeepers, use an intercluster trunk with gatekeeper control to configure connections between clusters of Cisco CallManager systems. Gatekeepers provide call admission control and address resolution for intercluster calls. A single intercluster trunk can communicate with all remote clusters. To choose this method, use Device > Trunk and choose Inter-Cluster Trunk (Gatekeeper Controlled) in Cisco CallManager Administration.
•Intercluster Trunk (Non-Gatekeeper Controlled)
In a distributed network that has no gatekeeper control, you must configure a separate intercluster trunk for each device pool in a remote cluster that the local Cisco CallManager can call over the IP WAN. The intercluster trunks statically specify the IP addresses or host names of the remote devices.To choose this method, use Device > Trunk and choose Inter-Cluster Trunk (Non-Gatekeeper Controlled) in Cisco CallManager Administration.
•SIP Trunk
Usamos SIP Trunk para configurar una interface de señalización con el Cisco CallManager para llamadas SIP.
SIP trunks (or signaling interfaces) connect Cisco CallManager clusters with a SIP proxy server.
Un SIP signaling interface usa port-based routing y Cisco CallManager acepta llamadas de cualquier gateway siempre y cuando los mensajes SIP arrivan al puerto que esta configurado como una interface de señalizacion SIP. La interface de señalización SIP usa request y responses para establecer, mantener y terminar llamadas entre 2 o más endpoints.
Para escoger este metodo: use Device > Trunk and escoger SIP Trunk in Cisco CallManager Administration.
You must also configure route groups and route patterns that use the SIP trunks to route the SIP calls.
Configuracion TRUNK
la configuracion Trunk en Cisco CallManager depende del diseño de red y protocolos de control de llamadas que son usados en IP WAN. Todos los protocolos requieren que un signaling interface (trunk) o un gateway debe ser creado para aceptar y originar llamadas. Se especifica el tipo de signaling interface cuando se configura el gateway en CallManager Cisco. Por ejemplo al configurar conecciones QSIG al CallManager se debe añadir un MCGP voice gateway que soporte protocol QSIG. Se configura el E1 PRI trunk interface a usar el tipo de protocol QSIG.
Trunk Types in Cisco CallManager Administration
•H.225 Trunk (Gatekeeper Controlled)
In a H.323 network that uses gatekeepers, use an H.225 trunk with gatekeeper control to configure a connection to a gatekeeper for access to other Cisco CallManager clusters and to H.323 devices. An H.225 trunk can communicate with any H.323 gatekeeper-controlled endpoint. When you configure an H.323 gateway with gatekeeper control in Cisco CallManager Administration, use an H.225 trunk. To choose this method, use Device > Trunk and choose H.225 Trunk (Gatekeeper Controlled).
•Intercluster Trunk (Gatekeeper Controlled)
In a distributed call-processing network with gatekeepers, use an intercluster trunk with gatekeeper control to configure connections between clusters of Cisco CallManager systems. Gatekeepers provide call admission control and address resolution for intercluster calls. A single intercluster trunk can communicate with all remote clusters. To choose this method, use Device > Trunk and choose Inter-Cluster Trunk (Gatekeeper Controlled) in Cisco CallManager Administration.
•Intercluster Trunk (Non-Gatekeeper Controlled)
In a distributed network that has no gatekeeper control, you must configure a separate intercluster trunk for each device pool in a remote cluster that the local Cisco CallManager can call over the IP WAN. The intercluster trunks statically specify the IP addresses or host names of the remote devices.To choose this method, use Device > Trunk and choose Inter-Cluster Trunk (Non-Gatekeeper Controlled) in Cisco CallManager Administration.
•SIP Trunk
Usamos SIP Trunk para configurar una interface de señalización con el Cisco CallManager para llamadas SIP.
SIP trunks (or signaling interfaces) connect Cisco CallManager clusters with a SIP proxy server.
Un SIP signaling interface usa port-based routing y Cisco CallManager acepta llamadas de cualquier gateway siempre y cuando los mensajes SIP arrivan al puerto que esta configurado como una interface de señalizacion SIP. La interface de señalización SIP usa request y responses para establecer, mantener y terminar llamadas entre 2 o más endpoints.
Para escoger este metodo: use Device > Trunk and escoger SIP Trunk in Cisco CallManager Administration.
You must also configure route groups and route patterns that use the SIP trunks to route the SIP calls.
martes, 16 de octubre de 2007
VLAN Access list
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
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
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
Suscribirse a:
Entradas (Atom)