lunes, 25 de enero de 2016
GARMIN
GARMIN - Actualizacion mapas G 2689 LMT
Podemos descargas mapas alternos : http://mapas.alternativaslibres.es/descargas.php
De vez en cuando, Garmin suele actualizar sus productos y con ello también incorporar cambios, uno de ellos fue con algunos de sus nuevos GPS, como el Nuvi 2495 (muy parecido al Nuvi 40) que, además de tener un software/OS más actualizado, también viene con una sorpresa: no es “reconocido” cómo unidad de disco cuando lo conectamos en una PC y por lo tanto, no tiene una letra de unidad asignada, no podemos “verlo” y con ello tampoco cargarle los mapas.
SOLUCION:
En la pantalla de seteo de volumen (donde está la barra que podemos deslizar con el dedo) hay que presionar la esquina superior derecha por 10 segundos. Va a aparecer una pantalla con seteos para el desarrollador.
Bajar con la flechita hasta llegar a la pantalla MTP Settings.
Entrar a esa pantalla. Cambiar la opcion de Auto Detect a la opcion Mass Storage Single Session.
Presionar Guardar, volver a la pantalla principal del GPS y, sin apagarlo, conectar el GPS a la PC.
La razón de porque no se le asigna letra sería porque Garmin modificó el protocolo de transmisión de datos entre la PC y el GPS. Anteriormente usaba Mass Storage (que asigna una letra al GPS en Windows) y ahora usa MTP (Mass Transfer Protocol). que no asigna letra en Windows. Es por eso que hay que modificar este seteo para ver la carpeta.
La modificación del seteo se revierte luego de desconectar el GPS de la PC. Si quieren hacer esta modificación permanente hay que elegir, en la carpeta de MTP Setting la opcion de Mass Storage en vez de Mass Storage Single Session."
Listo, ahora a actualizar los mapas de este Garmin.
Descarga el mapa Directo a GPS, obtendras un archivo gmapsupp.img que debes renombrar a gmapprom1.img
xxxxxxxx
Aparentemente, y por lo que he experimentado, el Garmin Nuvi puede interpretar 4 mapas con distintos nombres en la Unidad de Memoria y 1 en la SD simultáneamente.
De todas maneras, se puede cargar varios mapas en un solo archivo -gmapsupp.img- por medio del MapSource. Ejemplo: Mapear más Brasil.
Tengo organizado mis mapas de manera individual, con estos nombres:
En la memoria de la Unidad:
- gmapbmap.img = Mapa base, que viene con el equipo.
- gmapprom.img = Mapa precargado de fabrica (EEUU, Canada)
- gmapsupp.img = Mapear V8
- gmapprom1.img = Mapear Nautico V2
En la tarjeta de Memoria SD:
- gmapsupp.img = Brasil
(Notese que hay dos gmapsupp.img. Uno en cada memoria y ambos funcionan correctamente)
Otro nombre que se admitiría es gmapsup2.img, pero a mi no me funcionó.
Lo que no se recomienda por traer conflictos, es tener dos versiones de un mismo mapa en el Gps. Ejemplo: Mapear 7.5 en tarjeta SD y Mapear 8 en la Unidad, o viceversa.
viernes, 9 de octubre de 2009
Instalacion de Nagios
Partimos de una instalación limpia de debian etch con apache2. Lo primero que necesitamos es instalar nuestro entorno de compilación. Hay un paquete en debian con todo lo que necesitas para ello.
apt-get install build-essential
El segundo paso es instalar las librerías necesarias para, posteriormente, compilar nagios. Necesitamos las jpeg, png y gd2. Para las dos primeras no tuve ningún problema en instalar las que vienen con la distribución estable:
apt-get install libjpeg62 libjpeg62-dev libpng12-0 libpng12-dev
bajarse las fuentes de gd2 y compilarlos también:
cd /tmp
wget -c http://www.libgd.org/releases/gd-2.0.35.tar.gz
tar xzf gd-2.0.35.tar.gz
cd gd-2.0.35
./configure
make
make installLo siguiente es crear los grupos y usuarios necesarios para nagios:
useradd nagios
passwd nagios
groupadd nagios
groupadd nagcmd
usermod -G nagios nagios
usermod -G nagios josemaria
usermod -G nagcmd nagios
usermod -G nagcmd www-data
Ya lo tenemos todo listo. Ahora toca bajarse Nagios, compilarlo e instalarlo. Visita la página oficial para asegurarte de que usas las últimas versiones disponible. Por lo demás, la secuencia usando las versiones actuales es la siguiente:
cd /tmp
wget -c http://tinyurl.com/2jyzao/nagios-3.0a5.tar.gz
wget -c http://tinyurl.com/2mqzzk/nagios-plugins-1.4.9.tar.gz
tar xzf nagios-3.0a5.tar.gz
cd nagios-3.0a5
./configure --with-command-group=nagcmd
make all
make install
make install-init
make install-config
make install-commandmode
make install-webconf
cd ..
tar xzf nagios-plugins-1.4.9.tar.gz
cd nagios-plugins-1.4.9
./configure --with-nagios-user=nagios --with-nagios-group=nagios
make
make install
Creamos una contraseña para el acceso web del usuario nagiosadmin y reiniciamos apache:
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
/etc/init.d/apache2 reload
Y por último arrancamos nagios y, si no presenta ningún error, creamos un enlace para que de ahora en adelante arranque de forma automática al iniciar la máquina:
/etc/init.d/nagios start
ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios
miércoles, 25 de febrero de 2009
Asterisk-Java
Asterisk-Java
El paquete Asterisk-Java consiste de un set de clases Java que le permiten facilmente construir aplicaciones Java que interactua con servidores PBX Asterisk. Asterisk-Java soporta ambas interfaces que Asterisk provee para este escenario: The FastAGI protocol and the Manager API.La implementacion FastAGI soporta todos los commands actualmente habiles de Asterisk.
El Manager API implementation soporra recibir eventos del Asterisk server (e.g. call progess, registered peers, channel state) y enviar acciones a Asterisk (e.g. originate call, agent login/logoff, start/stop voice recording).
A complete list of the available events and actions is available in the javadocs.
Asterisk-Java is available under Apache license from http://asterisk-java.org/.
Referencia
Asterisk-Java es usado en varios entornos comerciales y por los siguientes Open Source projects:- Asterisk-IM: A plugin for the Jive Messenger XMPP (jabber) server. It provides integrated presence between your IM client and phone, notification of incoming calls by IM and originate calls from supported IM clients.
- Asterisk Desktop Manager (ADM): A desktop application that will allow for automatic on-call volume reduction, one click dial from clipboard, integrated phonebook and more.
Asterisk manager API
The Asterisk Manager API
The Asterisk Manager allows a client program to connect to an Asterisk instance and issue commands or read PBX events over a TCP/IP stream. Integrators will find this particularly useful when trying to track the state of a telephony client inside Asterisk, and directing that client based on custom (and possibly dynamic) rules.
A simple "key: value" line-based protocol is utilized for communication between the connecting client and the Asterisk PBX. Lines are terminated using CRLF. For the sake of discussion below, we will use the term "packet" to describe a set of "key: value" lines that are terminated by an extra carriage return.
New in Asterisk 1.4: AJAM is a new JavaScript-based technology which allows web browsers or other HTTP enabled applications and web pages to directly access the Asterisk Manager Interface (AMI) via HTTP.
Protocol Behavior
The protocol has the following characteristics:
- Before issuing commands to Asterisk, you must establish a manager session (see below).
- Packets may be transmitted in either direction at any time after authentication.
- The first line of a packet will have a key of "Action" when sent from the client, but "Event" or "Response" when sent from Asterisk to the client.
- The order of lines within a packet is insignificant, so you may use your favorite programming language's native unordered dictionary type to efficiently store a single packet.
- CRLF is used to delimit each line and a blank line (two CRLF in a row) indicates the end of the command which Asterisk is now expected to process.
Packet Types
The type of a packet is determined by the existence of one of the following keys:- Action: A packet sent by the connected client to Asterisk, requesting a particular Action be performed. There are a finite (but extendable) set of actions available to the client, determined by the modules presently loaded in the Asterisk engine. Only one action may be outstanding at a time. The Action packet contains the name of the operation to be performed as well as all required parameters.
- Response: the response sent by Asterisk to the last action sent by the client.
- Event: data pertaining to an event generated from within the Asterisk core or an extension module.
cada paquete son usados en 2 diferentes contextos: en el primero informan a clientes acerca del estado de cambios en Asterisk (Como nuevos canales que se inician creados y colgados o agentes que se loguean y desloguean) en la otra manera ellos son usados para transportar el response payload para acciones que devuelven una lista de datos. on the other hand they are used to transport the response payload for actions that return a list of data (actions que generan eventos). Cuando el cliente envia una accion generando eventos, Asterisk envia un paquete respuesta indicando sucesos y conteniendo una linea: "Response: Follows". Entonces se envia zero o mas eventos que contienen el actual payload y finalmente un evento de accion completa conteniendo el ActionID de el Action packet que disparó esto. An example of an event generating action is the Status action that triggers Status events for each active channel. When all Status events have been sent a terminating a StatusComplete event is sent.
Opening a Manager Session and Authenticating as a User
In order to access the Asterisk Manager functionality a user needs to establish a session by opening a TCP/IP connection to the listening port (usually 5038) of the Asterisk instance and logging into the manager using the 'Login' action. This requires a previously established user account on the Asterisk server. User accounts are configured in /etc/asterisk/manager.conf. A user account consists of a set of permitted IP hosts, an authentication secret (password), and a list of granted permissions.
There is a finite set of permissions, each may be granted with either "read", "write", or "read/write" granularity. If a client is granted the ability to read a given class, Asterisk will send it events of that class. If a client is granted the ability to write a given class, it may send actions of that class.
To login and authenticate to the manager, you must send a "Login" action, with your user name and secret (password) as parameters. Here is an example:
Action: login
Username: admin
Secret: god
If you do not need to subscribe to events being generated by Asterisk, you may also include the "Events: off" parameter, which will prevent event packets being sent to your connection. This is the equivalent of calling the "Events" action. Example:
Action: login
Username: admin
Secret: god
Events: off
Action Packets
When sending Asterisk an action, extra keys may be provided to further direct execution, for example, you may wish to specify a number to call, a channel to disconnect. Additionally, if your action causes Asterisk to execute an entry in the dialplan, you may wish to pass variables to the dialplan (available as of bug 1268). This is done exactly the same way you would send keys.
To send Asterisk an action, follow this simple format:
Action: <action type><CRLF>
<Key 1>: <Value 1><CRLF>
<Key 2>: <Value 2><CRLF>
...
Variable: <Variable 1>=<Value 1><CRLF>
Variable: <Variable 2>=<Value 2><CRLF>
...
<CRLF>
Manager Actions
Output from the CLI command show manager commands:
(For Asterisk 1.4 and greater, use manager show commands)
- AbsoluteTimeout: Set Absolute Timeout (privilege: call,all)
- ChangeMonitor: Change monitoring filename of a channel (privilege: call,all)
- Command: Execute Command (privilege: command,all)
- Events: Control Event Flow
- ExtensionState: Check Extension Status (privilege: call,all)
- GetVar: Gets a Channel Variable (privilege: call,all)
- Hangup: Hangup Channel __(privilege: call,all)
- IAXpeers: List IAX Peers (privilege: system,all)
- ListCommands: List available manager commands
- Logoff: Logoff Manager
- MailboxCount: Check Mailbox Message Count (privilege: call,all)
- MailboxStatus: Check Mailbox (privilege: call,all)
- Monitor: Monitor a channel (privilege: call,all)
- Originate: Originate Call (privilege: call,all)
- ParkedCalls: List parked calls
- Ping: Ping
- QueueAdd: Queues (privilege: agent,all)
- QueueRemove: Queues (privilege: agent,all)
- Queues: Queues
- QueueStatus: Queue Status
- Redirect: Redirect (privilege: call,all)
- SetCDRUserField: Set the CDR UserField (privilege: call,all)
- SetVar: Set Channel Variable (privilege: call,all)
- SIPpeers: List SIP Peers (chan_sip2 only. Not available in chan_sip as of 9/20/2004) (privilege: system,all)
- Status: Status (privilege: call,all)
- StopMonitor: Stop monitoring a channel (privilege: call,all)
- ZapDialOffhook: Dial over Zap channel while offhook
- ZapDNDoff: Toggle Zap channel Do Not Disturb status OFF
- ZapDNDon: Toggle Zap channel Do Not Disturb status ON
- ZapHangup: Hangup Zap Channel
- ZapTransfer: Transfer Zap Channel
- ZapShowChannels: Show Zap Channels
FastAGI
Implementa el Asterisk Gateway Interface (AGI) over TCP sockets. Ayuda a aliviar la carga del CPU del server Asterisk redireccionando recursos a otro server en la Red. Para indicar al server Asterisk a realizar una coneccion de red se deberá indicar el hostname or IP address of the server donde el FastAGI service is hosted and preface it with agi://:
exten => 5551212,1,AGI(agi://192.168.0.2)
Asterisk intenta conectarse al especificado server sobre el port 4573. El port tambien puede ser especificado si se escoge el servicio AGI en otro port :
exten => 5551212,1,AGI(agi://192.168.0.2:8675)
Un request puede tambien ser especificado en la llamada FastAGI , tal que podemos tener multiples AGIs en una unica locacion de red.
This request allows the FastAGI service to differentiate between different locations in the dialplan. For example:
exten => 5551212,1,AGI(agi://192.168.0.2/GetCallerRecord)
and:
exten => 5551212,1,AGI(agi://192.168.0.2/CallerWantsCustomerService)
The request portion of these calls will be received by the FastAGI service as the agi_network_script AGI variable. Asterisk will also include the agi_network AGI variable. For example, the FastAGI in the previous example would receive something like this when called by Asterisk:
agi_network: yes
agi_network_script: /CallerWantsCustomerService
Passing Arguments to FastAGI
Asterisk 1.2 & 1.4
With Asterisk 1.2 through 1.4, when using standard AGI, you can pass variables on the command line to your local scripts. This is not possible with FastAGI, however, but can be simulated using agi_network_script and a query syntax similar to that used by HTTP. For example:exten => 5551212,1,AGI(agi://192.168.0.2/GetCallerRecord?extension=${EXTEN})
It is the responsibility of your FastAGI framework to parse this information out of the agi_network_script variable. Some FastAGI implementations already do this for you, so be sure to check the documentation for your particular framework.
Error Handling
Asterisk 1.4 & 1.6.x
As of Asterisk 1.4 a new channel variable, AGISTATUS, is set to SUCCESS upon successful execution of an AGI. If there was a problem connecting to the FastAGI service, the channel variable is set to FAILURE, allowing the dialplan to perform alternate steps as not to interrupt the call flow. If the calling channel hangs up during execution of the AGI, AGISTATUS is set to HANGUP.FastAGI Servers
Java
- Asterisk-java - Includes a FastAGI server and allows you to write your AGI scripts in Java. It also now supports the Asterisk Manager API.
- Jast Agi
- OrderlyCalls (successor to JAGIServer) offers full support for FastAGI and Manager in an easy-to-use Named Service environment. Includes Web Deployer for developing integrated VOIP-HTML applications.
AGI enhancements
asterisk-agi-audiotx
This is an extension module for the Asterisk Gateway Interface (AGI) that adds commands to allow the transfer of audio files to and from Asterisk via the AGI session. This is useful when using FastAGI from a remote host; sounds recorded by Asterisk may be retrieved by remote FastAGI-providing service, for example, or sound files required by the remote service may be dynamically added to the Asterisk server.This module adds the following AGI commands:
- PUT SOUNDFILE
- GET SOUNDFILE
- ISEXISTING SOUNDFILE
jueves, 25 de diciembre de 2008
Lanzar llamadas en forma automatica
[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
[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, 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
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)