IPv6 prefix delegation feature

We will dive into IPv6 prefix delegation prefix.

First of all, we will make a real simple topology :


R1 acts as a DHCP server and use the prefix delegation feature. But how it works ? How it is configured ?

R1 :

R2 :

Debug trace on R2 (debug ipv6 dhcp) :

We have acquired the prefix via PD aka Prefix Delegation feature :

On R3 or R4 :

If we debug we will see (debug ipv6 interface, debug ipv6 dhcp, debug ipv6 nd) :

Finally, we are able to ping the DHCPv6 server :

IP SLA operation

IP SLA is a great tool to automation some treatment. You could do great things with it. We will work on IP SLA Reaction here.

What is it ? You could launch some action on some state of an IP SLA. Such as (Even if it is not a good example) : some nested ping.









The job here, is to check R4 – R3 and R4 – R2 if IP SLA beetween R1 – R4 is awful.

We could do this such as :
R4 :

We do an analyze on each segment of path and if it fails on our condition, it traps it.

Obvisouly on R1 :

CCIE R&S studies planner

I don’t know if it will really help someone but you can download here my CCIE planner spreadsheet : CCIE_Planner

It will provide you :

  • Monthly review based on CCIEv5 R&S blueprint ;
  • Planner from beginning point to your deadline lab attempt : it calculates how to organize your studies based on your initial self assessment ;
  • Daily organization ;
  • Weekly organization ;
  • Monthly organization ;
  • Yearly organization ;
  • Calculate your study time ;
  • IpExpert vol1 lab & topics ;
  • Logistics ;

It is provided as is and under GPLv2.

Have fun with your studies.

BGP rib-failure

I think everyone now what is a RIB-Failure in BGP context. It sounds obviously as an exact same route with a lowest AD as {e|i}BGP. We have VRF-Lite on R1 here :

Capture d’écran 2016-02-01 à 22.29.40

We have :

So the only route we can have a RIB-Failure due to lowest AD is : What is the problem with others ?
We can know this by using :

The problem is :

You know surely now why it is in ‘RIB-Failure’ state…

BGP review – ‘received-only’ prefix state

Today a little review :

Why the path through is not used, although it is the a better path to ?
Why is it marked as “received-only”

“Received-only” means as it says that this prefix is received, stored in Adj-IN, but cannot be selected for a valid prefix. Why ?

Lot of reasons. Commons are : route-maps, NEXTHOP not reachable…


In my example, the problem is here : a route-map without an explicit permit.

Je dis aime, la haine je la jette… Bonne écoute Daesh ;)

Sorry, but this time it will be a french article.

Ce qu’il faut que la France reste :

  • Amour ;
  • Diversité culturelle ;
  • Fête ;
  • Liberté !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ;
  • Laïcité ;
  • Passions et liberté de les exprimer par toutes les manières que se soit dans le respect des autres ;

Redback magic command

For those of you who are working with Redback equipments, this command can be useful :

Then you will have access to all commands the CLI hide you such as : ‘show sub ip’ or ‘show qos meter’ …

GETVPN : Group Encrypted Transport VPN

Schema Here it comes. We will use the same topology as the last two blog posts.
This time we will play with GETVPN. GETVPN is a Cisco technology. One of the advantage of GETVPN is that we are able to build somespoke-to-spoke IPSEC tunnel without Tunnel interface and it is highly scalable.

We could say to me : ok, man ! but you could do this by means of static tunnels. Yes you can, BUT with GETVPN you can maintain easily full mesh networks by means of Key Server and the GETVPN technology.

Tunnel is build between GM (Group Member). The Key Server (KS) maintains security policies and is not part of the Forwarding Path. This server is here to provide security policy and make it possible to GM to build a encrypted tunnel between each other. No need to pass through a central node. GETVPN is a answer, DMVPN phase 3 is another 🙂

We have R4 as KS with a loopback address :
We have R2 and R3 as our spokes. These routers has each other a loopback 99 with a different /24 subnet.

  • R2 :
  • R3 :

Let’s go and see how it is configured. Begin with the Key Server :

Now R2 and R3 :

GM use and interact with the KS to build their IPSec SA. Here, the security policy is identified by “identity number 12345”.

To make my topology works I have been obliged to add a static route towards my remote endpoints. I have been obliged to due to a bug on my IOS. It crashes if I add a “reverse-route” command in my crypto map.

Now, we could try to ping each other :

Good ! it pings. Let’s see if it is encrypted :

https://www.cloudshark.org/captures/a99bd1404eaa or http://www.clucas.fr/downloads/GETVPN.pcap

Great it works 🙂

Now see some troubleshooting commands :

Ok each SA encrypt and decrypts the correct number of packets 🙂

KS side :

For more information : http://www.cisco.com/c/en/us/products/collateral/security/group-encrypted-transport-vpn/deployment_guide_c07_554713.html

Have fun with GETVPN !!


IPSEC VTI stands for IPSEC Virtual Tunnel Interface.

Besides traditionnal IPSEC configuration with cyrpto map, VTI allows to use an interface. It is useful to apply some policies as we can do as other : service-policy, …

For this example, I will use the previous topology with four routers (R1, R2, R3, R4) : see the blog post below for a diagram.

I will implement a IPSEC VTI tunnel between R2 and R4.

VTI is really simple to implement :


And :

When the two tunnels are implemented the two tunnels states to up/up. Previous state is up/down.

We could do this kind of things and others :



How can DMVPN can make some QOS per spoke ?

It is what we will configure today :

Here is the network :





I will not explain how NHRP works in detail here.

R1, R2, R3, R4 use IS-IS (for fun) as IGP.

Now, here it comes DMVPN configurations :

And for R3 :

!!! WARNING !!!  ‘ip nhrp group’ and ‘ip nhrp map group xxx service-policy output yyy’ commands are not displayed with ‘?’. But the correct way is ‘nhrp group xxx’ and ‘nhrp map group xxx service-policy out pm’.

The mapping of the policy-map on the multipoint tunnel is done when the NHRP request is sent (on the spoke we flag it by means of ‘ip nhrp group toto’). Some extra fields in the NHRP packet show that ‘this’ kind of trafic through this IP must be grouped with ‘this’ spoke.

We can see the mapping by :

And we can see statistics by this command :