CCIE – BGP

Aprovechando mi preparación para el CCIE R&S voy a ir comentando las features más importantes relacionada con BGP.

1-Aggregate-address: similar al término summary pero a diferencia de ser usado con protocolos IGP se usa con BGP; por tanto para advertir rutas aggregate-address antes deberán de estar en la tabla de rutas de BGP. Para ello usaremos redistribution.

La sintaxis sería: aggregate-address address mask [as-set] [as-confed-set] [summary-only] [suppress-mapmap-name] [advertise-map map-name] [attribute-map map-name]

Screen Shot 2017-03-18 at 16.38.13.png

A continuación vamos a explicar mediante ejemplos el usao de cada uno de los atributos:

2-Origin: aporta info de como fue inyectada la ruta en BGP.

Posibles valores:

En el caso de rutas creadas con aggregate-address debemos de tener en cuenta:

  1. Si no usamos as-set la ruta agregada usará el valor de ORIGIN i
  2. Si usamos as-set y todos los prefijos que están siendo sumarizados usan ORIGIN i, entonces el valor de ORIGIN para la ruta aggregate será i
  3. Si usamos as-set y al menos un prefijo usa ORIGIN code ?; aggregate tendrá codigo ?

3-Route-reflector:permite enviar los updates IBGP a otros neighbors IBGP modificando la IBGP Split-Horizon rule.

¿Cómo puedo identificar el Route Reflector?

Si contiene cualquiera de estos comandos:

bgp cluster-id
neighbor route-reflector-client

Para saber a quién publica las rutas el Route-Reflector server:

Las únicas que no se advierten son hacia los Non-clients.

4-Route-dampening: usado para no propagar rutas hacia prefijos inestables.

Consiste en penalizar con “penalty value” por cada vez que flapee. En el caso de el valor de penalty ser superior al de supress limit; esta ruta será supressed.

Una vez la ruta se ha dejado de propagar, el valor de penalty debe ser reducido para ser inferior a reuse limit y así propagar el prefijo de nuevo. Half time es el encargado de reducir a la mitad el penalty value cada 15 minutos; de modo que si la ruta sigue estable cuando alcance un valor inferior a resuse limit aparecerá de nuevo la ruta en la tabla BGP.
Mientras que maximum suppress será el tiempo máximo que una ruta será eliminada.

5-Route-Backdoor: cuando la AD de eBGP es menor que la AD de un IGP protocol como OSPF o EIGRP.

En el siguiente ejemplo se observará:

Puesto que el AD por defecto de BGP es 20 y el de OSPF es 110; el R1 alcanzará el prefijo 99.0.0.0/8 con el AS Path: 101 102. Si queremos que se use el enlace OSPF deberíamos de modificar la AD de OSPF o en el caso de BGP usar el comando: network 99.0.0.0 backdoor. En caso de caer el enlace de OSPF seguirá alcanzando el prefijo por eBGP.

6-BGP Confederations: consiste en dividir un AS en sub-AS. De este modo varios routers que antes eran neighbor iBGP dentro de un AS ahora podrían pasar a ser eBGP por la separación con sub-AS.

7-BGP Route reflector: permite propagar prefijos aprendidos por iBGP a otros neighbors iBGP.

8-BGP Prepend-Regex Attribute:

Anuncios
Publicado en CCIE | Deja un comentario

Network Device Discovery tool

This week I have found out an awesome tool to discovery devices in a complex network.

This tool is known as NeDi and was created by the consultant Remo Rickli.

To proper work you only need to keep on the next steps:

  1. SNMP
    • SNMP on Devices RO mode
      •  snmp server-host nedisnmp ro
    • Modify file nedi.conf
      # NeDi 1.0.9 configuration file
      #============================================================================
      # Device Access
      #============================================================================
      # Set SNMP communities (preferred ones first).
      # If authentication protocol is set, it will be treated as v3
      #
      # name aprot apass pprot ppass
      ###########################################################################################
      # 10-9-2014 SNMP
      ###########################################################################################
      comm nedisnmp
  2.       Seedlist File
    • You don’t need to modify the file. By default is configured.

After previous settings you will can enjoy of features like vlans, broadcast traffic, topology…

Screen Shot 2017-02-24 at 20.01.00.png

 

Screen Shot 2017-02-24 at 20.10.37.png

For download software or inspect more about NeDi tool visit NeDi

At the end I would like to thank you to Remo Rickli for your support.

Publicado en Switching | Deja un comentario

Extend Layer 2 Domains

Now, I am analyzing a complex network that consists of hundreds of Switches between 2 interconnected buildings by Layer2.

One month ago I suffered a Layer 2 loop that was propagated to both buildings. Due to I need to break up Layer 2 domains in order to isolate the effects of broadcast, flooding and Layer 2 loops.

 In order to break layer 2 I need create Layer 3 interconnection but in this way I will need STP and the multicast traffic layer 2 won’t be propagated.

For get the next goals:

  1. Extend Layer 2 domain across multiple ToR (Leaf)
  2. Prevent all issues of Layer2 like ARP Traffic, broadcast amplification, loop layer 2
  3. Remove the need for STP (is ineffective)

I am considering a few alternatives:

TRILL, Fabric Path (Cisco), PLURIBUS, VXLAN, NVGRE, GENEVE…

Please, told us your experience and use cases about this new protocols.

Thanks in advance!

Publicado en Switching | Deja un comentario

Another Hard Day At The Office

The last week after 5 hours of intervention I got a VoIP hybrid cluster (Virtual CUCM + Physical).

Unfortunately the CUCM Publisher was crash; this is the worst incidence that can occur in VoIP environment.

In this way, I decided  create a new Virtual CUCM publisher:

-OVA:Cisco_OVA_CUCM

In order to keep the same license that old crashed CUCM server you will need to do rehosting.

Once the CUCM Publisher was created and working we deal with the most dificult duties that are database replication between Virtual and Physical CUCM.

The key to get database replication successfully are these commands:

             a.utils dbreplication stop all  (Only on the publisher)
             b.utils dbreplication dropadmindb (First on all the subscribers one by one then the publisher)
            c.utils dbreplication reset all ( Only on the publisher )

You don’t doubt more and migrate to virtualize platform your VoIP servers.

I hope you like it.

Publicado en Uncategorized | Deja un comentario

Cloud Computing

The efficiency of a cloud implementation depends on how well the cloud software stack components communicate with each other, the cloud infraestructure devices (cpu, network, storage…)

screen-shot-2016-12-11-at-19-54-26

Publicado en Cloud | Deja un comentario

Evil Foca

Today we are introducing one of the best and intuitive tool for security pentesters and auditors whose purpose it is to test security in IPv4 and IPv6 data networks.

foca

After go over this security tool we verify that has a wealth of security features such as:

  • Man In The Middle (MITM) attack

          The well-known “Man In The Middle” is an attack in which the wrongdoer creates    the possibility of reading, adding, or modifying information that is located in a channel between two terminals with neither of these noticing. Within the MITM attacks in IPv4 and IPv6 Evil Foca considers the following techniques:

 

  • ARP Spoofing

    Consists in sending ARP messages to the Ethernet network. Normally the objective is to associate the MAC address of the attacker with the IP of another device. Any traffic directed to the IP address of the predetermined link gate will be erroneously sent to the attacker instead of its real destination.

 

  • DHCP ACK Injection

    Consists in an attacker monitoring the DHCP exchanges and, at some point during the communication, sending a packet to modify its behavior. Evil Foca converts the machine in a fake DHCP server on the network.

 

  • Neighbor Advertisement Spoofing

    The principle of this attack is identical to that of ARP Spoofing, with the difference being in that IPv6 doesn’t work with the ARP protocol, but that all information is sent through ICMPv6 packets. There are five types of ICMPv6 packets used in the discovery protocol and Evil Foca generates this type of packets, placing itself between the gateway and victim.

 

  • SLAAC attack

    The objective of this type of attack is to be able to execute an MITM when a user connects to Internet and to a server that does not include support for IPv6 and to which it is therefore necessary to connect using IPv4. This attack is possible due to the fact that Evil Foca undertakes domain name resolution once it is in the communication media, and is capable of transforming IPv4 addresses in IPv6.

 

  • Fake DHCPv6 server

    This attack involves the attacker posing as the DCHPv6 server, responding to all network requests, distributing IPv6 addresses and a false DNS to manipulate the user destination or deny the service.

 

  • Denial of Service (DoS) attack

    The DoS attack is an attack to a system of machines or network that results in a service or resource being inaccessible for its users. Normally it provokes the loss of network connectivity due to consumption of the bandwidth of the victim’s network, or overloads the computing resources of the victim’s system.

 

  • DoS attack in IPv4 with ARP Spoofing

    This type of DoS attack consists in associating a nonexistent MAC address in a victim’s ARP table. This results in rendering the machine whose ARP table has been modified incapable of connecting to the IP address associated to the nonexistent MAC.

 

  • DoS attack in IPv6 with SLAAC attack

    In this type of attack a large quantity of “router advertisement” packets are generated, destined to one or several machines, announcing false routers and assigning a different IPv6 address and link gate for each router, collapsing the system and making machines unresponsive.

 

  • DNS Hijacking

    The DNS Hijacking attack or DNS kidnapping consists in altering the resolution of the domain names system (DNS). This can be achieved using malware that invalidates the configuration of a TCP/IP machine so that it points to a pirate DNS server under the attacker’s control, or by way of an MITM attack, with the attacker being the party who receives the DNS requests, and responding himself or herself to a specific DNS request to direct the victim toward a specific destination selected by the attacker.

 

 

 

Publicado en Pentesting | Deja un comentario

FortiGate-VMX v.2

Teniendo en cuenta que para el próximo año 2017 el 50% de las compañías a nivel global tendrán modelos de cloud híbridas hoy os presentamos el nuevo Fortigate para plataformas cloud híbridas o privadas.

Esta versión de firewall es perfecta para la securización de tráfico “East-West” de aplicaciones o databases de nuestra red.

Antes de realizar la implantación es importante conocer el “size workload” de la red. En el caso de no ser suficiente con la versión virtual que presentamos hoy una buena práctica sería usar para analizar Layer-4 un edge firewall mientras que para Layer-7 usariamos el FGT-VMXv.2

Una vez hayamos decidido por ejemplo si usaremos un Firewall físico en modo load balancing hacia varios VM fortigates, o si será un entorno full virtual vamos a ver su instalación:

  1. Licencia

El proceso es como un Fortigate físico, una vez realizada la compra del device, via mail recibiremos el “license registration code”.

screen-shot-2016-11-27-at-17-38-07

2) FortiGate-VMX Service Manager

Ir a “support.fortinet.com” y en la sección “Register/Renew” descargar el “license file” en local.

Descargaremos también la imagen (.ovf) de la página de Fortinet

Se configurará en Fortigate los parámetros de NSX

screen-shot-2016-11-27-at-17-53-44

FGT#config sys global
FGT(global)#config nsx setting
FGT(setting)#exec nsx service add 

Ya por último ya veremos que el servicio “FGTVMXV2” ya aparece.

screen-shot-2016-11-27-at-17-59-32

 

Publicado en Uncategorized | Deja un comentario