En la página web personal de Jonathan Rosenberg (el padre de las RFCs de SIP, SIMPLE, STUN, ICE, etc…), vienen varios tutoriales y presentaciones sobre VoIP, que pueden estar muy bien para hacerse una idea rápida sobre la materia, explicando detalles interesantes en algunos temas.
La parte de tutoriales y presentaciones no tiene desperdicio:
Sobre el tema de simuladores de los diferentes interfaces diameter y nodos empleados en LTE/IMS hay diversas opciones disponibles, y muchas de ellas son open source.
El simulador diameter más utilizado es Seagull:
http://gull.sourceforge.net/doc/diameter.html
http://www.linkedin.com/groups/Can-some-one-suggest-Diameter-4056876.S.74026186
Después hay otros componentes que implementan/simulan las diferentes cajas e interfaces de una red LTE, como el freePCRF:
También existen varias cajas hechas utilizando la librería jDiameter (hecha en java):
http://blog.morethanspec.com/2011/11/diameter-seagull-and-jdiameter-test.html
https://code.google.com/p/mobicents/wiki/MobicentsDiameterRA
O el simulador del HSS:
Sin olvidarnos de la parte radio (el eNodeB), que ahí le está metiendo caña Fabrice Bellard:
Otros proyectos sobre la parte radio se pueden ver en este blog:
http://hokietux.net/blog/blog/2013/07/07/lte/
Sin olvidarnos de OpenBTS, que es uno de los proyectos respaldados por la gente de Yate:
A mi me llama bastante el tema de las librerías de diameter existentes en el proyecto erlang/OTP, bastante actualizadas, por cierto, para programar los servidores e interfaces diameter como necesites para cada caja:
http://www.erlang.org/doc/apps/diameter/users_guide.html
http://www.erlang.org/doc/apps/diameter/index.html
http://www.erlang-factory.com/upload/presentations/432/DiameterStack.pdf
He estado buscando un poco posibles soluciones alternativas para montar un Full MVNO con LTE, y aparecen algunos proyectos alternativos:
Este es un proyecto de GGSN, que tiene desarrollo activo y muy reciente:
http://cgit.osmocom.org/openggsn/
Dentro del proyecto osmocom, hay otras soluciones, mas orientadas a la parte de radio:
http://openbsc.osmocom.org/trac/
En el proyecto openSS7 hay un HLR, y otros elementos relacionados:
http://www.openss7.org/map_design.html
En el proyecto ss7ware, también hay los elementos para montar un MVNO LTE, con la ventaja de que los elementos también sirven para la red 3G actual.
Esto es para el HLR/HSS:
ss7ware.com/products.php?product=openhss
Esto es para la MSC/VLR:
http://ss7ware.com/products.php?product=openvolte
Esto es para el GGSNy SGSN:
http://ss7ware.com/products.php?product=opensae
Y aquí describe el sistema en general:
http://ss7ware.com/solutions.php?product=unified_core_network
Aquí también hay un proyecto para un HSS abierto:
Y aquí un blog sobre el tema de una solución open source para montar una red LTE:
http://telecom.ashishbanerjee.com
Aquí también hay un proyecto de una red opensource, pero con fines de investigación y pruebas:
En la parte de radio, está el proyecto de openLTE lanzado por Fabrice Bellard (el genio del proyecto FFMPEG, QEMU, la máquina virtual de Linux sobre javascript, y otras cosas increíbles):
http://myriadrf.org/open-source-lte/
En la documentación de Yate, viene una explicación y diagrama de los elementos de una red GSM, tal y como yo la conocía cuando estaba en Amena:
http://docs.yate.ro/wiki/Mobile_networks
Esto está relacionado con el proyecto de BTS que están desarrollando los de Yate, para integrarlo con los de ss7ware en un sistema LTE completo:
Como veis hay material y proyectos de sobra. Además hay soluciones con soporte comercial (como en el caso de ss7ware) para montar una red que sirva para 3G y 4G/LTE.
En cuanto a la documentación de LTE, hay de sobra y todo está disponible públicamente:
http://www.3gpp.org/DynaReport/36-series.htm
http://en.wikipedia.org/wiki/LTE_%28telecommunication%29
Iperf es una herramienta muy útil para comprobar el ancho de banda real de conexión disponible. Tanto para Unix y/o Windows.
Iperf puede configurarse en 2 modos:
El host en modo iperf servidor escucha conexiones remotas originadas desde potenciales host iperf cliente. El host iperf cliente define los parámetros de test de ancho de banda, y se conecta al servidor remoto.
apt-get install iperf
iperf -s
root@smokeping1:/# iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————
Se puede arrancar el servidor manual, o como demonio. Para este segundo caso se debe añadir el parámetro -D (se ejecuta iperf como demonio en background).
iperf -s -D
iperf -s -D > /var/log/iperf-log.log
root@server:/home/ubuntu# iperf -s -D > /var/log/iperf-log.log
Running Iperf Server as a daemon
The Iperf daemon process ID : 3546
root@server:/home/ubuntu#
Iperfs necesita ejecutarse en el host local en modo cliente, así como en el servidor remoto en modo servidor. Se debe explicitar la ip con el argument -c.
iperf -c ip_servidor.
[root@fc18-atica ~]# iperf -c 112.131.5.76
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 85.0 KByte (default)
————————————————————
[ 3] local 10.134.16.230 port 51345 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-13.4 sec 7.75 MBytes 4.85 Mbits/sec
[root@fc18-atica ~]#
La duración por defecto es 10. Se puede explicitar una duración mayor con el argumento t.
iperf -c ipserver -t 60 (duración 60 sgs).
root@observium:/etc# iperf -c 112.131.5.76 -t 3 (duración total de 3sgs).
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 23.5 KByte (default)
————————————————————
[ 3] local 172.0.0.14 port 44967 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 3.0 sec 323 MBytes 902 Mbits/sec
root@observium:/etc#
Por defecto es cero. En este caso hay un único reporte.
iperf -c ip_server -i 2
root@observium:/etc# iperf -c 112.131.5.76 -t 6 -i1
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 23.5 KByte (default)
————————————————————
[ 3] local 172.0.0.14 port 44968 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 99.6 MBytes 836 Mbits/sec
[ 3] 1.0- 2.0 sec 102 MBytes 851 Mbits/sec
[ 3] 2.0- 3.0 sec 102 MBytes 854 Mbits/sec
[ 3] 3.0- 4.0 sec 102 MBytes 856 Mbits/sec
[ 3] 4.0- 5.0 sec 102 MBytes 860 Mbits/sec
[ 3] 5.0- 6.0 sec 102 MBytes 852 Mbits/sec
[ 3] 0.0- 6.0 sec 609 MBytes 851 Mbits/sec
root@observium:/etc#
Se comprueba la velocidad en un sentido y luego en el otro.
Se utiliza el argumento r para comprobar la dirección en un sentido y luego en el otro. Primero desde el servidor al cliente y luego en sentido contrario. Con el argumento d sería el orden al revés.
iperf -c ip_servidor -r .
El TCP windows size se puede cambiar mediante el argumento -w seguido por el número de bytes. En el siguiente ejemplo sería una windows size de 125 KB. Se puede hacer tanto en el cliente como en el servidor.
ip -c ip_server -w 128000
Por defecto Iperf usa TCP. Si se desea utilizar UDP debe utilizarse tanto en el servidor como en el cliente el argumento u.
iperf -c ip_server -u
iperf -s -u
El resultado contendrá una métrica extra para el packet loss. Esta debe ser lo más pequeña posible como es natural.
Se utiliza el argumento v para comprobar la versión del iperf.
root@server:/home/ubuntu# iperf -v
iperf version 2.0.5 (08 Jul 2010) pthreads
Se utiliza el argumento h para comprobar toda la lista de argumentos soportados por iperf.
Client/Server:
-f, –format [kmKM] format to report: Kbits, Mbits, KBytes, MBytes
-i, –interval # seconds between periodic bandwidth reports
-l, –len #[KM] length of buffer to read or write (default 8 KB)
-m, –print_mss print TCP maximum segment size (MTU – TCP/IP header)
-o, –output <filename> output the report or error message to this specifie d file
-p, –port # server port to listen on/connect to
-u, –udp use UDP rather than TCP
-w, –window #[KM] TCP window size (socket buffer size)
-B, –bind <host> bind to <host>, an interface or multicast address
-C, –compatibility for use with older versions does not sent extra msgs
-M, –mss # set TCP maximum segment size (MTU – 40 bytes)
-N, –nodelay set TCP no delay, disabling Nagle’s Algorithm
-V, –IPv6Version Set the domain to IPv6
Server specific:
-s, –server run in server mode
-U, –single_udp run in single threaded UDP mode
-D, –daemon run the server as a daemon
Client specific:
-b, –bandwidth #[KM] for UDP, bandwidth to send at in bits/sec
(default 1 Mbit/sec, implies -u)
-c, –client <host> run in client mode, connecting to <host>
-d, –dualtest Do a bidirectional test simultaneously
-n, –num #[KM] number of bytes to transmit (instead of -t)
-r, –tradeoff Do a bidirectional test individually
-t, –time # time in seconds to transmit for (default 10 secs)
-F, –fileinput <name> input the data to be transmitted from a file
-I, –stdin input the data to be transmitted from stdin
-L, –listenport # port to receive bidirectional tests back on
-P, –parallel # number of parallel client threads to run
-T, –ttl # time-to-live, for multicast (default 1)
-Z, –linux-congestion <algo> set TCP congestion control algorithm (Linux onl y)
Miscellaneous:
-x, –reportexclude [CDMSV] exclude C(connection) D(data) M(multicast) S(set tings) V(server) reports
-y, –reportstyle C report as a Comma-Separated Values
-h, –help print this message and quit
-v, –version print version information and quit
[KM] Indicates options that support a K or M suffix for kilo- or mega-
The TCP window size option can be set by the environment variable
TCP_WINDOW_SIZE. Most other options can be set by an environment variable
IPERF_<long option name>, such as IPERF_BANDWIDTH.
Report bugs to <iperf-users@lists.sourceforge.net>
root@server:/home/ubuntu#
#512K
En relación con el problemón que ha habido con el tamaño de las entradas de prefijos en los routers BGP #512K (pasado 12 agosto), estos son los comandos útiles para ver el tema de las entradas en la TCAM en los routers BGP:
1) Con esto vemos el dimensionado de las entradas:
BGP_sp_mad_C01#sh mls cef maximum-routes FIB TCAM maximum routes :
=======================
Current :-
——-
IPv4 – 768k
MPLS – 32k
IPv6 + IP Multicast – 112k (default)
2) Con esto podemos saber que es lo que está consumiendo actualmente:
BGP_sp_mad_C01#sh mls cef summary
Total routes: 507123
IPv4 unicast routes: 507110
IPv4 Multicast routes: 3
MPLS routes: 1
IPv6 unicast routes: 9
IPv6 multicast routes: 0
EoM routes: 0
3) Con esto podemos averiguar si en algún momento el router ha sobrepasado alguno de los límites configurados en el hardware:
BGP_sp_mad_C01#sh mls cef exception status Current IPv4 FIB exception state = FALSE Current IPv6 FIB exception state = FALSE Current MPLS FIB exception state = FALSE
4) Por último (pero no menos importante), con este comando tenemos información detallada de las capacidades de cada procesadora (con picos de tráfico por tarjeta, etc…):
BGP_sp_mad_C01#sh platform hardware capacity System Resources
PFC operating mode: PFC3CXL
Supervisor redundancy mode: administratively sso, operationally sso
Switching resources: Module Part number Series CEF mode
1 7600-SIP-400 CEF256 CEF
2 7600-SIP-400 CEF256 CEF
3 WS-X6704-10GE CEF720 CEF
4 WS-X6704-10GE CEF720 CEF
5 RSP720-3CXL-GE supervisor CEF
6 RSP720-3CXL-GE supervisor CEF
Power Resources
Power supply redundancy mode: administratively redundant
operationally redundant
System power: 2669W, 0W (0%) inline, 1981W (74%) total allocated
Powered devices: 0 total, 0 Class3, 0 Class2, 0 Class1, 0 Class0, 0 Cisco
Flash/NVRAM Resources
Usage: Module Device Bytes: Total Used %Used
3 dfc#3-bootflash: 32768000 0 0%
4 dfc#4-bootflash: 32768000 0 0%
5 SP sup-bootdisk: 518799360 181633024 35%
5 SP const_nvram: 127212 736 1%
5 SP nvram: 4059328 42536 1%
5 RP bootdisk: 518799360 0 0%
6 slavenvram: 4059328 42536 1%
6 slaveconst_nvram: 127212 736 1%
6 slavesup-bootdisk: 512090112 153755648 30%
6 slavebootdisk: 512090112 0 0%
CPU Resources
CPU utilization: Module 5 seconds 1 minute 5 minutes
3 0% / 0% 0% 0%
4 0% / 0% 0% 0%
5 RP 2% / 1% 7% 7%
5 SP 11% / 4% 17% 16%
6 RP 0% / 0% 0% 0%
6 SP 10% / 3% 13% 11%
Processor memory: Module Bytes: Total Used %Used
3 199560096 44738032 22%
4 199560096 44738036 22%
5 RP 1767501440 703985232 40%
5 SP 697855300 325334884 47%
6 RP 1767501440 224678068 13%
6 SP 670689728 296054500 44%
I/O memory: Module Bytes: Total Used %Used
5 RP 134217728 39163552 29%
5 SP 67108864 34114152 51%
6 RP 134217728 39163552 29%
6 SP 67108864 34114152 51%
EOBC Resources
Module Packets/sec Total packets Dropped packets
3 Rx: 11 8467346 0
Tx: 5 871269 0
4 Rx: 12 8463915 0
Tx: 6 871425 0
5 RP Rx: 81 5595544 0
Tx: 49 4916667 0
5 SP Rx: 23 2867868 0
Tx: 31 3247413 0
6 RP Rx: 0 204837 0
Tx: 0 180449 0
6 SP Rx: 11 624649 0
Tx: 10 493665 0
VLAN Resources
VLANs: 4094 total, 8 VTP, 0 extended, 35 internal, 4051 free
L2 Forwarding Resources
MAC Table usage: Module Collisions Total Used %Used
5 0 98304 29 1%
6 0 98304 29 1%
VPN CAM usage: Total Used %Used
512 0 0%
L3 Forwarding Resources
Module FIB TCAM usage: Total Used %Used
5 72 bits (IPv4, MPLS, EoM) 819200 507165 62%
144 bits (IP mcast, IPv6) 114688 12 1%
detail: Protocol Used %Used
IPv4 507164 62%
MPLS 1 1%
EoM 0 0%
IPv6 9 1%
IPv4 mcast 3 1%
IPv6 mcast 0 0%
Adjacency usage: Total Used %Used
1048576 461 1%
Forwarding engine load:
Module pps peak-pps peak-time
5 526897 616731 12:52:18 Europe/ Wed Aug 13 2014
6 525469 617711 12:52:13 Europe/ Wed Aug 13 2014
Switch Fabric Resources
Bus utilization: current: 1%, peak was 1% at 15:55:24 Europe/ Wed Aug 13 2014
Fabric utilization: Ingress Egress
Module Chanl Speed rate peak rate peak
1 0 20G 0% 5% @03:42 13Aug14 0% 1% @02:27 13Aug14
2 0 20G 1% 4% @13:38 13Aug14 0% 5% @04:03 13Aug14
3 0 20G 2% 5% @09:39 13Aug14 2% 4% @03:07 13Aug14
3 1 20G 3% 13% @15:50 13Aug14 2% 6% @10:52 13Aug14
4 0 20G 1% 2% @11:59 13Aug14 0% 2% @03:12 13Aug14
4 1 20G 1% 4% @10:52 13Aug14 3% 12% @15:50 13Aug14
5 0 20G 1% 2% @02:27 13Aug14 3% 5% @09:36 13Aug14
6 0 8G 2% 6% @09:19 13Aug14 3% 9% @09:36 13Aug14
… vamos, que no tiene desperdicio el comando.