FAX

Se utilizaran los siguientes link para realizar un resumen :

http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_fax_services_over_ip_application_guide/fxappdoc.html

troubleshooting :
http://www.cisco.com/en/US/tech/tk652/tk777/technologies_tech_note09186a0080114565.shtml#topic3-6
http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_Fax_Call_Flow

configuracion :
https://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/dt_t38fx.html

comandos de referencia :
http://www.cisco.com/en/US/docs/ios/12_2/voice/command/reference/vrf_r.html#wp1028033

Problema TCP over VSAT

Caso :
En el local remoto se tiene instalado un acceso VSAT como acceso a la red IP MPLS, en el local principal se tiene un acceso Metro Ethernet .
Un terminal en el local remoto directamente conectado al equipo Modem/Router Satelital IDirect 3100, establecía sesión TCP con un servidor en el local principal.
El problema se presentaba como desconección de la sesión TCP cada 102 segundos exactamente.

En el gráfico adjunto se muestra la desconexión de la sesión TCP con un paquete RST originado desde el servidor.

Analizando las capturas realizadas se encuentra algo muy curioso :

Las sesiones TCP se establecen y se mantienen con un TCP Keepalive con respuesta TCP Keepalive-ACK, se observa que el terminal envía un paquete TCP Keepalive y es respondido por el server, lo raro es que el tiempo de respuesta esperado debería ser de unos 600 o 700 ms, en este caso se encuentra un tiempo de respuesta de 28 ms.

Se deduce que el IDirect responde a los paquetes TCP y no es el server, aunque la comunicación se realiza terminal-server.

El IDirect utiliza mecanismos de aceleración de tráfico y el comportamiento anteriormente descrito es normal en ese escenario. Con el fin de un correcto funcionamiento del sistema terminal-server procederemos a desactivar esa funcionalidad.

Algunos conceptos con IDirect :

Aumentos de la eficiencia de ancho de banda

El apoyo a una amplia variedad de los más avanzados códigos de producto turbo (TPC) FECs, la serie 5000 ofrece más flexibilidad para el diseño de redes y optimización. Características tales como la aceleración TCP y HTTP DNS local y aumentar el rendimiento de caché de rendimiento, y maximizar la experiencia del usuario.

Preguntas Frecuentes

P: ¿Que es ancho de banda compartido?

R: El Ancho de Banda compartido es el servicio de red que no se dedica a un solo cliente. Por ejemplo, si el cliente compra el servicio de la transferencia directa 1024kbps por el upload 128kbps con una contención de 10:1 (1024x128) estamos hablando de un servicio compartido, el sistema puede no realizarse realmente a las velocidades completas 1024x128 siempre. Diversos abastecedores tienen diversos esquemas para cómo comparten Ancho de Banda. Los abastecedores utilizan Ancho de Banda compartida proyectan para bajar el costo de proporcionar servicio del Internet.

Prediciendo cómo un canal será utilizado con frecuencia, pueden partir el uso de canales dedicados costosos entre clientes múltiples. Los sistemas compartidos del Ancho de Banda costaron típicamente al cliente 1:5 a 1:10 tanto como Ancho de Banda dedicada. El Ancho de Banda compartido es más adecuado a la pequeña empresa y a los usuarios caseros, y a los sitios que apoyan a menos de 30 usuarios en un solo VSAT

P: ¿Que es el Ancho de Banda Dedicado?

R: El Ancho de Banda dedicado es el servicio de red que se dedica al cliente. Por ejemplo, si el cliente compra el servicio de la transferencia directa 256kbit por el upload 256kbit (256x256), el sistema está garantizado para tener ese servicio siempre a esa velocidad. El canal es reservado para el uso de ese sistema.

El Ancho de Banda dedicada es muy flexible, y viene generalmente en un número de niveles del upload y de la transferencia directa de 32kbit a 8mbit, dependiendo del hardware. Es también posible comprar un canal dedicado y compartirlo a través de un número de sistemas que pertenezcan al mismo cliente. El Ancho de Banda dedicada es más adecuado a los clientes de las Grandes Empresa tales como Internet Service Provider (ISP) y sitios que apoyan a más de 50 usuarios en un solo VSAT.

P: ¿Que es el CIR (Committed Information Rate)

R: En castellano significa Tarifa Confiada de la Información (CIR) garantiza un nivel mínimo del servicio (Ancho de Banda). Por ejemplo, usted contrata un ancho de banda de 512Kbps y su proveedor le dice que esta con un CIR de 20% con una contención 20:1. Lo que le esta diciendo es que no le garantiza el 100% de la velocidad que usted a contratado y que lo mínimo que tendrá es el 20% de lo que contrato y que también esta en un plan de concurrencia de 20 terminales Vsat el cual están en una misma Portadora. Así como también la Banda que se anuncia como de “upload 128 kbit” no garantiza 128 velocidades del kbit. Aunque tales sistemas han publicado promedios, no se ofrece ninguna garantía que ésta está siempre disponible. El CIR, aseguran a un cliente que el Ancho de Banda disponible nunca cae debajo de cierto punto. Algunos abastecedores ofrecen el CIR en sistemas con un Ancho de Banda compartida para un coste mensual adicional. Corporación PeruData Center le ofrece una contención de 5:1 con un CIR 70% solamente en sistemas iDirect.

P: Que es "TCP acceleration?

R: Transmission Control Protocol (TCP) El Transmission Control Protocol (TCP) utiliza un "three-way handshake", para iniciar conexiones de datos confiables entre dos puntos en una red del IP (tal como el Internet). Debido a los tiempos ida-vuelta largos implicados en comunicaciones de VSAT, muchas unidades comerciales “spoof” de VSAT este proceso para iniciar la conexión del TCP rápidamente. Esto spoofing se llama “aceleración del TCP”. Es realizada por la mayoría de los sistemas vendidos por Corporación PeruData Center, incluyendo Hughes DirecWay, Tachyon, e iDirect. Típicamente, el hardware para el servicio dedicado de la Ancho de Banda carece esta característica y debe ser proporcionado por el hardware separado en ambos finales del acoplamiento de VSAT (en el sitio de cliente y en el Network Operations Center

P: ¿Se comparte o se dedica el servicio del iDirect?

R: El servicio del iDirect está disponible como Ancho de Banda compartida o dedicada. el servicio compartido iDirect utiliza “un plan del cociente de la parte”. Cada canal se comparte entre los clientes múltiples, que afirman para el servicio según lo necesitado. Por ejemplo, un cliente con un cociente de la parte de 10:1 está utilizando un canal que pueda tener hasta 10 otros clientes en él. El servicio está disponible en muchos cocientes entre 4:1 y 50:1. Ver por favor tu plan del servicio para los detalles.

P: ¿Puedo utilizar Voz-sobre-IP (VOIP), el webcam, y servicios de la videoconferencia con servicio del iDirect?

R: Sí. Sin embargo, la calidad depende del porcentaje de disponibilidad comprado y no garantizamos que estos servicios funcionan en servicio compartido de forma optima. Para garantizar servicio, se debería comprar el servicio dedicado o una cantidad apropiada de kbps. Para asi poder tener garantizado el servicio de VOIP y VIDEO El servicio de VOIP con Corporacion PeruData Center VOIP requiere de una línea de dedicada de 30Kbps o los tan llamados canales de voz para asi garantizar la calidad de la voz. Este precio se observa especialmente en las opciones de tasación del iDirect. Consultar por favor sobre los planes exclusivamente que se necesita para los servicios de VOIP, webcam, vídeo, u otros.

TCP/IP over Satellite

A significant difficulty encountered in supporting TCP/IP applications over satellite has to do with the inherent latency or delay of satellite systems. Because satellites are 23,000 miles above the earth, the time it takes for a signal to go from the ground to the satellite and back to the ground is just over 1/4 second. The TCP/IP protocol was designed for guaranteed transport. A server or PC sending data will begin by sending a few packets and then waiting for an acknowledgment that the data was received before sending any more. If the data is successfully received and acknowledged, the sending device will send more packets at a faster rate. It will continue to speed up until acknowledgments are lost. This tells the sending device what the speed or bandwidth capability of the transport services is, and it will send remaining data at that rate. Unfortunately, satellite latency appears to the sending TCP/IP device as a very slow or congested circuit. It expects an acknowledgment within a short time period and when it doesn’t get it, it throttles back and retries. Satellite vendors circumvented this problem by using TCP acceleration techniques sometimes called spoofing. This is based on the same techniques that were used to solve similar problems with IBM SNA/SDLC and other older protocols in the past. Many satellite solutions require an external device to provide TCP acceleration. Almost all legacy solutions accelerate TCP in only one direction. Many of the solutions are based on ‘spoofing’ the TCP/IP protocol. The problem here is that there is no end-to-end management of the TCP session, so if a packet is dropped midway through transferring a large file, the file must be retransmitted from the beginning. iDirect provides bi-directional TCP acceleration, built into the satellite router and hub equipment at both the remote site and teleport hub equipment. Further, the data transmission is tracked and buffered and occasional acknowledgments are sent end-to-end so that if an error does occur, only the corrupted portion need be retransmitted.

Another related issue is TCP Session Setup. This can be seen when pulling up a web page that has multiple links on it for content. Each one of these links must go through a connection/acknowledgment process that must be performed sequentially and is directly affected by satellite latency. iDirect provides HTTP or Web Acceleration that works in both directions. It dramatically improves web response by eliminating the need for the acknowledgment packets to traverse the satellite link. This results in downloading pages smoothly and quickly as though on a terrestrial link.

How to turn off the TCP Acceleration on a remote modem?
Answer:
1. Telnet to remote.
2. Enter this line exactly (disables TCP Acceleration in the remote):
spoof params set spoof_passthru 1
The telnet session should drop at this time.
--
3. Telnet to Protocol Processor, port xxxxx.
4. Enter the following line:
rmt s/n
where s/n is the serial number of the remote in line 1.
5. Enter this line exactly (disables TCP Acceleration in the PP):
spoof params set spoof_passthru 1
6. Telnet to remote to verify connectivity.


La solución se obtuvo deshabilitando la aceleración TCP en el hub y modem Satelital.

Con el Ibuilder en modo gráfico en la opción custom :
Lado HUB
[REMOTE_DEFINITION]
spoof_passthru=1

Lado REMOTO
[SPOOF]
spoof_passthru=1

VPN CISCO

cliente VPN cisco :

download
http://rapidshare.de/files/48490766/vpnclient-win-msi-5.0.05.0290-k9.exe.html

Configuracion del cliente VPN cisco :

connection entry : meridiam
Description :
host: 190.41.x.x
Authentication :
Group Authentication :
Name : SALES
Password : xxxx
Transport :
IPSec over UDP



config :

aaa authentication login default local
aaa authentication login sdm_vpn_xauth_ml_1 local
aaa authentication login VPNAUTHEN local
aaa authorization exec default local
aaa authorization network VPNAUTHOR local


username xxxx privilege 15 secret 5 $1$D9eL$4yQG.FuGc7LjR1eaNj128/
username xxxx privilege 15 secret 5 $1$xQwy$IvGhyALDuBI6r8jOo1peF.
username xxxx privilege 15 secret 5 $1$QKnE$fx.fmQbSlL0zMGdg3LgvY1
username xxxx privilege 15 secret 5 $1$SCG3$A9FeqoDymTTD2plsxY5ZS.
!
!
crypto isakmp policy 3
hash md5
authentication pre-share
group 2
!
crypto isakmp client configuration group SALES
key cisco123
domain cisco.com
pool IPPOOL
acl 104
netmask 255.255.255.250
!
!
crypto ipsec transform-set MYSET esp-aes 256 esp-sha-hmac
!
crypto dynamic-map DYNMAP 10
set transform-set MYSET
reverse-route
!
!
crypto map CLIENTMAP client authentication list VPNAUTHEN
crypto map CLIENTMAP isakmp authorization list VPNAUTHOR
crypto map CLIENTMAP client configuration address respond
crypto map CLIENTMAP 10 ipsec-isakmp dynamic DYNMAP

interface Vlan1
ip address 137.135.128.15 255.255.255.0 secondary
ip address 192.168.110.5 255.255.255.0
no ip redirects
ip virtual-reassembly
ip route-cache flow
load-interval 30
crypto map CLIENTMAP
hold-queue 100 out

ip local pool IPPOOL 192.168.111.71 192.168.111.80

access-list 104 permit ip 192.168.110.0 0.0.0.255 any

config WEBVPN :

WebVPN

Generate PKI trustpoint

crypto pki trustpoint NETCONF.CO.UK
enrollment selfsigned
subject-name cn=webvpn.netconf.co.uk
revocation-check none
rsakeypair NETCONF.CO.UK-self-signed
!
crypto pki enroll NETCONF.CO.UK
Enable HTTPS

ip http server
ip http access-class 98
ip http authentication aaa
ip http secure-server
ip http path flash:
!
access-list 98 permit 217.205.209.128 0.0.0.15
access-list 98 deny any log
Create SSL Gateway

webvpn gateway SSL
hostname webvpn.netconf.co.uk
ip address INTERNET_ADDRESS port 443
ssl trustpoint NETCONF.CO.UK
inservice
Create SSL Context's

webvpn context LETMEIN
title "WEBVPN.NETCONF.CO.UK: AUTHORISED ACCESS ONLY"
ssl authenticate verify all
!
port-forward "portlist"
local-port 22 remote-server "172.17.0.1" remote-port 22 description "SERVER1 SSH"
local-port 80 remote-server "172.17.0.1" remote-port 80 description "SERVER1 HTTP"
policy group default
port-forward "portlist"
default-group-policy default
gateway SSL domain letmein
max-users 1
inservice

acceso a pagina de recusos cisco

https://cisco.hosted.jivesoftware.com/community/connections/espanol?view=overview

Recursos web cisco

ip route-cache flow o ip flow ingress… Cual usar?

If you’ve ever configured a router for NetFlow, you may have had to work with either, or both, of these commands.

When configuring NetFlow on your router, you have two sets of configurations to setup. First, being your global commands that define which version of NetFlow is being used, where the flows will be exported, and on what port.

After configuring the global commands, however, you also need to configure the interfaces that will be using NetFlow. To enable flows on an interface, you have two commands that are very similar in nature, but used in different circumstances.

For more information regarding NetFlow configurations, check out this Activating NetFlow Guide.

So, back to the original question: “Do I use ip route-cache flow or ip flow ingress?”

Deciding which interfaces you want to monitor will answer this question.

If you are interested in monitoring flows on a physical interface, you would use ip route-cache flow. By enabling ip route-cache flow on the physical interface, it will in turn enable flows on all subsequent sub-interfaces.

But let’s say that you are not interested in seeing flows on sub-interfaces x,y and z; but you do want to see flows on subs a, b and c, from that same interface. This is where the command comes into use.

So as a quick summary:
ip route-cache flow will enable flows on the physical interface and all sub-interfaces associated with it.

ip flow ingress will enable flows on individual sub-interfaces, as opposed to all of them on the same interface.

Cisco’s article on Netflow and subinterface support offers a wealth of information on this subject.

**NOTE** With NetFlow v5, we only had the option to monitor inbound statistics using the ip flow ingress command. However, with the release of NetFlow v9, we now have the option to monitor traffic leaving each interface via ip flow egress. Check out this blog which tackles the question: Which one is better to use? Ingress or Egress?