Post-Cisco Live US!

Hello everyone! 😀

Here we are again, as i promised in the previous post, we will talk a little about Cisco Live US!

First things first: It was my first CLUS, I’ve been two times in CLEUR, but never in CLUS or US before. Actually, i had to run the last month with visa and appointments and a lot of paperwork to be there, and it was worth it! 😀

I’ve found a HUGE difference with regards to size and organization between CLUS and CLEUR. Many things that are available in US are not in Europe (like the huge TacOps truck parked in the convention center) and for sure, this is motivated by the amount of people attending. CLEUR had around 7000 attendees and CLUS 27000-28000 (apologies if numbers are not accurate). This doesn’t mean that CLEUR is worse or CLUS is better, the public is different (a lot of people only go either to US or Europe) and as it grows, arrangements around it change to accommodate the people and experiences to offer.

I had the opportunity to check amazing sessions, like Troubleshooting EIGRP/OSPF/IS-IS (imparted by Peter Paluch, Nick Russo and Brad Edgeworth) were INSANE, and i would recommend you to check them out at Cisco Live’s website.

In the keynotes, we had Chuck Robbins telling us that the place to go is simplicity, networks are growing amazingly complex because we are massively connected (say IoT and mobiles devices) and we cannot manage something complex with even more complex processes. So, the call is for simplicity and automation (yeah, dude, start learning python and APIs, it will help). DNA center was heavily mentioned 😉

Could you believe that DevNet reached 500K people registered? Susie gave an inclusive and closer message than other speakers, and let everybody know that all of us, people moving networks forward, learning new stuff and trying to get into the programmability, we are developers. It was a very clever way to invite you there 🙂

Screenshot from 2018-07-12 06-23-36

Now, regardless of where networking is heading (or what industry says its heading), this doesnt mean you will not be needed as a network engineer, experts are ALWAYS needed, and doesnt matter if networks would be automated in the future, they will be moving and working by the same principles networks now. Knowledge is and will be needed always, before operating it you need to understand how it works!

The engineer role is not disappearing, and will not disappear anytime soon 🙂 BUT, its wise to learn more about APIs, programmability and complement your toolbox so you can broaden your scope.

Had the opportunity to record a podcast and an interview (will be released soon), be in a contest – Engineer Deathmatch – and a panel (and the panel was recorded – OMG!)


Did you have the chance to go by DevNet zone? They are growing amazingly! Make sure to check them out (im going through some courses for python, not bad!)

Stepping aside from sessions, technical stuff, business announcements and other topics, what I do believe is one of the most important things in the event (whether its Europe or US) is networking, being social!

Meeting people, saying hello and putting voices in faces you see in twitter and documents you have read before. Although we live in an era where WebEx and other tools shorten distances and make collaboration possible, nothing can replace this feeling of human warmth. After all, these events are possible because of the people, or like Cisco used to say: “The human network” – And let me tell you that, even when CLUS was in Orlando (and its HOT and humid), i felt the most of the real warmth inside the convention center 🙂 (yes, it was a pink/human/poetic moment).

Social interaction is heavily integrated in the fibers of the event, and the social media team at CLUS, the facility maintenance team (the people giving you food and cleaning everything) and the support people (the ones dressing in green and always telling you were the rooms were) are not exempt from this. They were an absolute blast! Remember always to smile to them, they will smile back 😉

I had the chance to win a cape on tuesday for my tweets and i was looking fabulous! (told you its important!)

Screenshot from 2018-07-12 06-44-38

They even congratulated me when i passed an exam ❤

Screenshot from 2018-07-12 06-50-44

Elaine Lopes gave me a superhero mask as a gift, and I had my outfit complete! The next i did was to take a picture with Denise Fishburne ❤

Screenshot from 2018-07-12 06-06-43

Isn’t it amazing? 😀

I cannot stress enough how amazing was to meet the people, take pictures, talk, have coffee, and do it all over again.

As a last point, the CAE!

We had the chance to enjoy Universal Studios Florida for some hours. IT WAS AMAZING! I was doing lines to take the rides and feeling like a kid!

I dont know how it will be in 2019, but, as this year, i will do my best to be everywhere and squeeze the most of it. Its an unique experience!

Thanks for reading!

Bonus pictures!

CLUS Social Media team

Screenshot from 2018-07-12 06-49-38

The following are pictures with a lot of fun and love 😀


This slideshow requires JavaScript.


This slideshow requires JavaScript.

I had the chance meet Wendell Odom (runs in circles) and Denise Donohue! (she gives amazing hugs!) – Also met a dinosaur, Dmitry Figol, Stuart Clark, Mark Holm, Silvia Spiva, Susie Wee, Elaine Lopes, Nicole Wajer and #PaperPeter! (this is not in order of importance! all of them are 🙂 ) – We had fun on an escalator! (nobody was injured) 😀

And, Peter Paluch signed my book! #fangirlmoment (see the cape there?)

Screenshot from 2018-07-12 07-07-39


A lot happened – Updates are in order!

Hello everyone

I have been away for some time (sorry about it) and i’m trying to get back on track to blog more. Gotta say I had my plate full with couple of exams in my queue and a huge workload. Things are moving forward and I promised myself i would do my best to get back on blogging here (as I mostly blog at Cisco Learning Network) 🙂

A lot happened since my last blog, let me resume here briefly:

  • Got selected Cisco Champion for 2017 and 2018
  • Got selected Cisco Designated VIP for 2017 and 2018
  • Attempted (3 times) and passed CCDE written exam
  • Attempted (waiting for results) CCDE Practical exam back on May 30th
  • Attempted and passed CCIE R&S exam at Cisco Live US 2018 (can’t believe it yet)
  • Met a lot of personalities of the networking/twitter world at CLUS and CLEUR this year
  • Won a cape at CLUS and wore it like a superhero the whole time! 😀
  • Recorded podcasts at CLEUR and CLUS (Cisco Champion Radio – – will be published in some weeks)
  • Recorded an episode of Engineering Deathmatch at CLUS (blog about it is coming)
  • Blogged some new stuff at Cisco Learning Network (In English and Spanish!)
  • Made incredible friendships over the months 🙂

Took me 3 attempts to pass the CCDE written exam back in August 2017, a beast of exam, wide scope to cover, many topics, and of course, tricky questions. Funny thing: failed second attempt by 9 points! (life is quite sarcastic sometimes). Had some awesome counseling by Daniel Dib, Mark Holm and Juan Garcia during my preparations!

Recently also attempted CCDE Practical Exam on May 30th 2018 at Madrid. I have to say it was an awesome experience, the closest you can be to a real life situation in an exam. I am still waiting for results, and, regardless of the outcome – passing or failing, that exam has been, by far, the best one I have ever taken. Kudos to Elaine Lopes!

During my preparation I had help from many sources, certified CCDE guys in a study group, like Jeremy Filiben (comprehensive CCDE training), Daniel Dib (he was an awesome guidance for me), Kim Pedersen, Malcolm Booden, Nick Russo, Andre Azevedo, Michael “Zig” Zsiga (and many others – sorry if i did not mention you, my memory sucks) and study partners like Mike Mcphee, Jason Beltrane, Juan Garcia, and of course, my dear friend Peter Paluch (to whom I hold my utmost gratitude for his time, patience and disposition with me and my minced meat brain).

Speaking of CCDE: Juan Garcia and me are writing and translating content for Cisco Learning Network related to that certification and Unleashing CCDE blog posts in Spanish! (oh yeah!). Elaine was a key supporter of this idea (another kudos for her!)

You can find the content in Spanish for Cisco Learning Network here

For the other topics, I will be writing blog posts to talk specifically about them (like the Engineering Deathmatch episode at CLUS) or a summary of CLUS itself. There is a lot to write! 😀

More updates are coming, thanks for reading! 🙂

Twitter profiles of people/groups mentioned in this post:

Daniel Dib, Jeremy Filiben, Elaine Lopes, Peter Paluch, Nick Russo, Kim Pedersen, Mark Holm, Andre Azevedo, Michael Zsiga, Juan Garcia, Malcolm Booden, Mike Mcphee Jason Beltrane, Engineering Deathmatch, Cisco Champion, Learning@Cisco

Returning to the world of the living, aaaand… CCDP achieved! :D

Hello everyone! 😀

I know i know… I have been quite away from the blog (sorry about that). I have been veeery busy with work and studies. Actually, now I am a little bit more “free” than before, because I took the ARCH exam. So, no deadline now! 😀

I will be writing the pending stuff from IPv6 (here is the first IPv6 friendly post) and some other new stuff requested by some of my students/friends in Venezuela (yeah guys, finally i will). Feel free to post your suggestions and i can try to write something and make a decent lab with some examples (and funny names like my world-famous Potato-ACLs 😀).

Now! As the tittle says: I passed the ARCH exam! 😀 So, that makes me a CCDP certified professional (sounds fancy, right?) and i am aiming for CCDE.

Talking about the exam: its a very hard one. You need to know a lot of stuff from other branches (like Service Provider, Data Center or Security) in terms of design. How technologies work, the details that can change everything! From my perspective, this is not an easy and fast exam. And I don’t think any CCNP R&S guy will pass ARCH exam in the first attempt without studying properly the technologies and having the correct mindset. Actually, as the CCDP Official Certification Guide (link here) is not released yet, i was studying with the CCDE Official Certification Guide (and some stuff are deep) but there is a difference, a big one. You must know some stuff before even trying to get it. Like how MPLS works, how OSPF and IS-IS work, what are the differences between them, and stuff like that. Knowing how they work means deep knowledge (like forwarding address in OSPF, for example). I handle a lot of DC stuff (ACI and non-ACI environments) daily, and that helped me. That being said, I would strongly recommend anyone taking this exam to wait for the OCG and then read some stuff additionally (like Cisco Validated Designs) to grasp the stuff very well and remember best practices and stuff like that. In my opinion, the exam is quite fair according with the responsibility you will have being the design guy there! Some months ago the exam was not good (some confusing wording in the questions and very model specific questions). A friend, Daniel Larsson wrote a post about it in CLN (link here) giving his feedback back in February. After that, several folks have been posting there their feedback regarding the exam. Feel free to take a look (i will write my feedback there also). Additionally, i must say that the exam is not that “Cisco Centric” as you may think. My experience was a very open exam, considering technologies and conditions to implement them. Yes, you will see some (few of them) questions about Cisco technologies) but the overall exam is quite wide and open. I enjoyed it, actually (and felt like i was going to fail in the middle of it).

As I wrote before, a different mindset is needed. You will need to think in business needs and application needs before thinking in technologies that are going to be implemented. The needs will give you the direction and correct technology to implement. In Cisco Learning Network you can watch free CCDP webinars (yeees! free!) taught by Andre Laurent and Marwan AlShawi (link here) and that can help you a lot. They explained incredibly well the mindset you must have (which is the most important element you need IMHO) and gave excellent examples. If you want to go deeper, you can also read CCDE posts (link here) written by Elaine Lopes and you will also learn a lot with interesting information, challenges and more! Everything is done in CLN and its free! (ruuuun!)

Use those resources to learn and get yourself closer to the CCDP and CCDE certifications. I really enjoyed reading and watching videos about design and discussing stuff with other people. The best answer ever whenever someone ask you a question about network design: “It depends”

Again, sorry for the delay. Will be back shortly with more posts for you. Study hard, learn a lot, ask questions, be curious!

See you around.

PS: I am writing this post using the time in the maintenance windows scheduled while other guys are checking firewall rules. I already did my part 😀 Use your time wisely, young Padawan! 😀

IPv4 to IPv6: from 32 to 128 bits

Here we are again, people! This time, i decided to write a post about IPv6, being this protocol part of our present and future (even past, because it is being used since years ago). As most of you must have IPv4 (because IPv6 adoption is going SO slow), maybe IPv6 could be an alien protocol for you. Some people say its difficult, so, i want to explain a little bit here to make it clear. I do not think its difficult, i think it is different 🙂 If you are used to IPv4, which is likely, then it can be shocking at the beginning, but,we can make cool examples here, right? 😀

The facts

As yo may know, IPv4 addresses are exhausted years ago, it looked inexhaustible 20 years ago, but now, its over! Why? well, now we have smartphones, tablets, laptops, and several types of devices, all of them needing internet connection. The internet changed the way we live, learn, transport (Thank God, Google Maps!), work, and even flirt! (you were not waiting that, do you? xD). So, its everywhere AND we are using it a lot. This exhaustion was foreseen by experts many years ago, that’s why IPv6 was developed. Of course, it was in its early stages and not ready, but a temporal solution for this exhaustion was needed as fast as possible. That’s the moment when NAT made its appearance.

With NAT we could deplete IPv4 exhaustion’s speed and make a little longer our agony 🙂 In no time we were able to share one or several IPv4 public addresses with hundreds/thousand of users in the same private network (yikes!). Imagine the amount of people in China and India, that they need 4-5 layers of NAT! D:

So, enough history and funny facts. What about the differences? Are we going to find the same type of addresses in IPv6? Its true that broadcast doesn’t exist there? how so? what about IPv4 and IPv6 in parallel? did i turn of the oven before writing this? 😀

These questions and many others are going to be answered here! Same hour, same channel, don’t miss it! 😀

IPv6 and IPv4 are very different, not just the format, also the way we write them, hierarchy and so on. We will see here 🙂

The bits

We were used to 32 bits and dotted decimal notation. In IPv4 world, 32 bits were enough for 4.3 billion of addresses (sounds like a lot, but NO) and it seemed endless in that moment. Guess what? IPv6 went a way far from that, and address format is 128 bits! So, the magic number of public addresses is something like 340 trillion trillion trillion and i am not stuttering! 😀

IPv4 address format is singular, easy and short. 32 bits, separated in 4 groups of 8 bits (called Octets) each by a dot. That’s why we say dotted decimal (pretty obvious, huh?). Every group can have a number from 0 to 255. A common example that EVERYONE have seen in some moment of their life is something like the following: /24

I’m pretty sure i rang a bell in your head, because this is the private IP range configured by home routers. Depending of the vendor, third octet can have a different values, but logic is the same 😉

In the case of IPv6 we have 128 bits, divided in 8 groups of 16 bits each (called Hextet) separated by a colon. Every Hextet is written in hexadecimal and values can be between 0x0000 and 0xFFFF. This is an example of an iPv6 address:


Yeah, it doesn’t look pretty and i don’t think i would be able to memorize several of them. The cool part is that we can simplify it, following some rules. This is the first one:

The leading zeroes in any 16-bit segment do not have to be written; if any 16-bit segment has fewer than four hexadecimal digits, it is assumed that the missing digits are leading zeroes.

So, following that, we can write a single zero (0) in those hextets and simplify our address this way:


Remember, this just can be done with leading zeroes! Else, we can enter into an ambiguous ground.

What about this address?


We can write it this way:


BUT, then we reduce it even more! Making use of another rule:

Any single, contiguous string of one or more 16-bit segments consisting of all zeroes can be represented with a double colon.

In simpler words, if we see more than one hextet filled with zeroes, we can simplify them with a double colon (:)  So, our address will be now something like this:


YES! See that? A couple of rules are handy! 😀

But, read again! This can only be done ONCE! Why? Because we can indicate an ambiguous address. Take this example:


If you apply the double colon rule here twice, then you would write something wrong like this:


Why is this wrong? Because we don’t know the length of the consecutive zeroes strings. So, it could be indicating several addresses like:

  • 2001:0000:0DB8:AC10:FE01:0000:0000:0000
  • 2001:0000:0000:0000:0DB8:AC10:FE01:0000

When the correct one is:


See the difference? So, we can use both rules together is we have several goups of hextets filled with zeroes and not contiguous. We can write the address in these ways:

  • 2001::DB8:AC10:FE01:0:0
  • 2001:0:0:DB8:AC10:FE01::

This way of simplifying IPv6 addresses by the application of these two rules mentioned earlier its called Compressed Format.

Another interesting fact:

In IPv4 we could identify the network and host portion easily, using bitcount and subnet masks. In IPv6 its always done by bitcount. How do we do that? Easy peasy! Our address, followed by a forward slash and the number of bits of the prefix:


Also, you can set the host addresses to zero, as we did in IPv4 and write something like this:


Some advantages over IPv4

  • Simplified configuration: literally “plug and play”, as soon as you plug you copper cable to the PC, it creates by itself a local address (i will explain that later in detail) automatically. It uses your MAC address as part of the local address. (cool, huh?)
  • Better end-to-end connectivity: We know that NAT was a huge help for IPv4, but for IPv6 we don’t need it to communicate with other IPv6 hosts! You will get a public and reachable address thanks to the huge space that IPv6 has. No more NAT, baby! 😀
  • “Embedded Security”: I put this between quotation marks. Why? Based on the security section in  RFC 6434

Previously, IPv6 mandated implementation of IPsec and recommended the
key management approach of IKE.  This document updates that
recommendation by making support of the IPsec Architecture [RFC4301]
a SHOULD for all IPv6 nodes.  Note that the IPsec Architecture
requires (e.g., Section 4.5 of RFC 4301) the implementation of both
manual and automatic key management.  Currently, the default
automated key management protocol to implement is IKEv2 [RFC5996].

This document recognizes that there exists a range of device types
and environments where approaches to security other than IPsec can be
justified.  For example, special-purpose devices may support only a
very limited number or type of applications, and an application-
pecific security approach may be sufficient for limited management
or configuration capabilities.  Alternatively, some devices may run
on extremely constrained hardware (e.g., sensors) where the full
IPsec Architecture is not justified

So, in few words, yeah, IPSec implementation is possible, and a SHOULD, but its not a MUST. A lot of people say that IPv6 is more secure because of IPSec, but, its not mandatory. It’s secure, IF it is ENABLED. So, do not believe blindly in those comments.

Also, i would like to share with you the meaning of the words SHOULD, SHOULD NOT, MUST and MUST NOT in the RFCs.  RFC 2119 describes how those words must be interpreted.

Based on RFC 2119:


 This word, or the adjective "RECOMMENDED", mean that there may 
  exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

Also, there is a RFC about security implications. RFC 7123 states:

In general, networks should enforce on native IPv6 traffic the same
   security policies currently enforced on IPv4 traffic.

So, even if its claimed that IPv6 has native security support (which means your OS should support it), same policies should be enabled as its done in IPv4 networks (firewalls, filtering, etc).

  • Better QoS support/More efficient IP packet: The IPv6 packet has a “flow label” field that gives better identification when its treated for QoS. Routers can use this field to assign the packet to an specific flow. Also, there is no need for checksum at IP Layer, so, it does not need to be calculated at every hop. This is now handled by upper layers protocols.
  • Opportunity for new services: Now that NAT is gone, new services that were not possible easily because of the NAT layer, can be implemented. Everything based on end-to-end connectivity.


Phew! This was a lot of information, right? And there is still, too much out to discuss. So, here a new saga is born! IPv6 Saga! 😀

In next posts we will talk about address types, uses, methods of address assignation and some transition mechanisms between IPv4 and IPv6. This is just getting started! 🙂

Thanks for reading!

ACLs: Filtering Insights

Heeello everyone! Again, sorry for the late post, I am trying to do them more often (sometimes it’s quite challenging). GRE Saga is on hold, i am looking for actors and proper scenes to make the history interesting. So, castings are taking place! If you have suggestions about a new topic or whatever you think can help the blog, click here and send me a message! 😀

Today I will introduce you one of the most basic and filtering techniques that you will ever find out there. You will learn that ACLs are the very foundation of filtering techniques and a huge support for routing protocols and other deep stuff that require selective matching. Simple doesn’t mean useless, actually, sometimes the challenge is to do simple things in an excellent and flawless way 😉

Its time to introduce you to the almighty (Drums in the background) Access Control Lists (ACLs)! How do they work? What can you do with them? Well… we will find out! 😀

First of all: Everyone call them Access Lists, the “control” keyword gets sucked into the dark hole of laziness we have as engineers. Yes, you have it. If not, find it now! (You will need it, trust me). It must be close to Pizza Galaxy or Burger Nebula (I couldn’t resist it!).

The facts

ACLs are like the big security guys with black shirts in the door of your routers. They even have this list with several lines. In ACL’s language, this lines are called Access Control Entries (ACEs), and they follow a match/not match logic. Its pretty simple: you specify details, such as source and destination ip address. Then, an action, like permit or deny. Aaaaand, voila! You have a simple access list. That’s all! (I told you it was simple!).

Key fact: every ACL is evaluated top-down. That means every ACE (every line) is checked until there is a match. When a match is found, no more entries are evaluated after the match. With every ACE you enter in an ACL, automatically it gets a sequence number (every time it sums 10), so, keep an eye on that. We will dig into details about this later in this post.

You can create several types of ACLs: Standard, Extended and Named. ACLs are identified by their number. So, depending on the number you give to them when creating, they will be standard or extended. If you check here you will see a short summary from Cisco. Before, many moons ago, when networking was dealing with dinosaurs, you had to put your ACLs in a number range in order to identify them (that was before IOS 11.2). Now you can name them! Which is easier for troubleshooting. For now, we will focus on these two types of ACLs (using Cisco’s table):

ACL Number Ranges

Protocol Range
Standard IP 1–99 and 1300–1999
Extended IP 100–199 and 2000–2699

Standard ACLs are quite simple, just an address and a network mask, with the action to follow if it’s matched. In the case of Extended ACLs, you can get fussy if you want (wink wink). You can specify source address, destination address, protocol number, protocol name, service, source and destination port number and logging. Sounds interesting, huh?

Finally, Named ACLs, are the best part of the group. You can name them (quite obvious, huh?), which is MUCH MORE easy to find than a numbered ACLs. You can named them in a way that they tell you what are you doing with them. Not just for you, also for other people reading your configuration. Its easier to read “NAT_ACL” than a number, because then you must find in some place of your documentation, what is that ACL doing. Functionality is almost the same, you can even do some stuff in named ACLs than you can’t with numbered/extended ACLs (like reflexive ACLs – we can talk about it later).

You have two ways to configure them:

Old School way:

R1(config)#access-list ?

  <1-99>            IP standard access list

  <100-199>         IP extended access list

  <1000-1099>       IPX SAP access list

  <1100-1199>       Extended 48-bit MAC address access list

  <1200-1299>       IPX summary address access list

  <1300-1999>       IP standard access list (expanded range)

  <200-299>         Protocol type-code access list

  <2000-2699>       IP extended access list (expanded range)

  <2700-2799>       MPLS access list

  <300-399>         DECnet access list

  <700-799>         48-bit MAC address access list

  <800-899>         IPX standard access list

  <900-999>         IPX extended access list

  compiled          Enable IP access-list compilation

  dynamic-extended  Extend the dynamic ACL absolute timer

  rate-limit        Simple rate-limit specific access list

Syntax is this one:

Router(config)#access-list ACL_Identifier_number permit|deny IP_Address|host|any [log]

And, named mode (you need to enter first in the ACL configuration mode):

Router(config)#ip access-list extended ACL_name_number

Router(config-ext-acl)# permit|deny IP_protocol source_IP_address wildcard_mask [protocol_information] destination_IP_address wildcard_mask [protocol_information] [log]

We have talked about what we can match, but, lets talk about practical uses. Why would you use an Standard ACL? They just can filter based on ip address, not detailed as Extended. Well, it depends! If you want to block traffic from a certain host to a server, for whatever the reason, you can use a Standard ACL! 😀 Aaaand, as we are talking about this, i have just remembered that i haven’t told you how to enable them, just creating! (my bad there!)

You can enable them when applying to an interface, in that moment you can decide also in which direction you want to filter. Inbound or outbound. Sometimes it’s a tricky question, so, an easy way to get the answer is thinking of you as the router. Traffic going in your direction is INBOUND, and traffic going in the opposite direction as where you are, is OUTBOUND. People also say that coming to the router is inbound, and leaving the router is outbound. It works also as a good example.

You can apply one ACL per protocol, per direction (inbound/outbound), per interface. 

Key fact#2: There is an implicit deny at the end of EVERY ACL. Which means you cant see it, but ITS THERE! Whatever you are not permitting in previous ACEs, is going to be denied at the end of the ACL. So, be careful!

Key fact#3: Standard ACLs should be placed near destination, because of the limited filtering based on ip address. Extended ACLs should be placed near the source. What could happen if we do not follow this guideline? Well. Think about it. IF you apply a Standard ACL near the source: you may end up blocking traffic you do not need to block. Extended ACL near destination: you are letting traffic move in the network (from source to destination) and it will be blocked anyway when arriving to destination. So, you will lose bandwidth.

A good way to remember the correct implementation is to think this way:

Standard close to destination ——-  One “S” (Correct)

Extended close to Source          ——-  One “S” (Correct)

Standard close to Source             ——- Two “S” (Incorrect)

Extended close to destination ——- No “S” (Incorrect)

This example can be found here on Cisco Learning Network, written by Martin.


Now that we have learned a lot of theory, what about a lab? 😀

We will build a simple lab like this one:

Captura de pantalla 2016-07-23 a la(s) 08.45.45

So, let imagine we want to block traffic comming from network and going to network If we dont want to block an specific protocol, then we can use an Standard ACL. Lets do it 😀

Remember we must create a static route in order to reach loopbacks

R1(config)#ip route

R1(config)#do ping                          

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 12/38/108 ms

R2(config)#ip route

R2(config)#do ping

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 16/27/52 ms

Now, as we want to block traffic from network going towards network, and we will use a Standard ACL, we must place the ACL in R2. Remember, Standard ACLs are placed close to destination 😉

So, lets create it!

R2(config)#access-list 1 deny

R2(config)#access-list 1 permit any

R2(config)#int fa 0/0                             

R2(config-if)#ip access-group 1 inbound <—– Binding ACL and specifying direction

Remember that the ACLs have a implicit DENY in the end, so, whatever we do not allow to pass, will be blocked by the implicit DENY. With this last line, we make sure that the rest of the traffic, except the one we are blocking, will be allowed.

In order to use an ACL, we have to bind it to an interface and specify the direction we want it to filter. We do it with “ip access-group” command.

Now that we have created and placed our ACL, how about a test?

If we try to ping, it will succeed!


Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/40 ms

But, why?

The reason is that the router is pinging from the closet interface, which is fa 0/0. And, from that ip address, the traffic is alllowed. But, what about pinging from the loopback which addresses are blocked?

R1#ping source lo0 <— source address will be loopback’s

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:

Packet sent with a source address of


Success rate is 0 percent (0/5) <—— See that? DENIED!

Now, how would be the same access list, but extended?

R2(config)#access-list 101 deny icmp echo

R2(config)#access-list 101 permit ip any any

and, lets make a quick show:

R2(config)#do sh ip access

Standard IP access list 1

    10 deny, wildcard bits (30 matches)

    20 permit any (30 matches)

Extended IP access list 101

    10 deny icmp echo

    20 permit ip any any

See the difference? We need to be more specific here, because the level of detail is higher! You will see that you get a lot of details when you type “?” after every word. I will leave that part to you, that way you can make cool experiments 😀

Remember when i told you that the ACLs have sequence numbers? There you have them!

Every time you create a new ACE, it will assign it a sequence number 10 units higher than the previous one. WHY? Because an ACE cannot be modified. So, if you need to add something before ACE 20, you must delete the ACL and do it again. It will evaluate them in an incremental order. Remember this ACL was created under the older mode.

But, with named mode ACLs you can! 😀

Lets make it again in named mode.

R2(config)#ip access-list extended POTATO

R2(config-ext-nacl)#?    <—– See that now we are in a different mode! 😮

Ext Access List configuration commands:

  <1-2147483647>  Sequence Number  <—- You can specify the sequence number!

  default         Set a command to its defaults

  deny            Specify packets to reject

  dynamic         Specify a DYNAMIC list of PERMITs or DENYs

  evaluate        Evaluate an access list

  exit            Exit from access-list configuration mode

  no              Negate a command or set its defaults

  permit          Specify packets to forward

  remark          Access list entry comment

R2(config-ext-nacl)#deny gre <— This is a test to then put the ACE that denies ICMP before it. We are not doing GRE tunnels this time.

R2(config-ext-nacl)#permit ip any any  <— Always permit the rest of the traffic!

Lets make a show:

R2(config-ext-nacl)#do sh ip acces

Standard IP access list 1

    10 deny, wildcard bits (30 matches)

    20 permit any (30 matches)

Extended IP access list 101

    10 deny icmp echo

    20 permit ip any any

Extended IP access list POTATO

    10 deny gre

    20 permit ip any any

How to add something before the ACE with sequence number 20?

R2(config-ext-nacl)#15 deny icmp

And, now, show again! 😀

R2(config-ext-nacl)#do sh ip acces                                      

Standard IP access list 1

    10 deny, wildcard bits (30 matches)

    20 permit any (30 matches)

Extended IP access list 101

    10 deny icmp echo

    20 permit ip any any

Extended IP access list POTATO

    10 deny gre

    15 deny icmp  <—- OH YEAH! 😀

    20 permit ip any any <—- Remember this always when you create an ACL!

Now, lets apply it on our interface! We should be blocked when making a ping.

R2(config-if)#int fa 0/0               

R2(config-if)#ip access-group POTATO in

From R1’s perspective:

R1#ping source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:

Packet sent with a source address of


Success rate is 0 percent (0/5)

Now, lets see if the ACL is being matched

R2(config-if)#do sh ip acces                                      

Standard IP access list 1

    10 deny, wildcard bits (30 matches)

    20 permit any (30 matches)

Extended IP access list 101

    10 deny icmp echo

    20 permit ip any any

Extended IP access list POTATO

    10 deny gre

    15 deny icmp (85 matches) <– A lot of pings there!

    20 permit ip any any

See that? We can block whatever we want with ACLs. And this is just the basic stuff! We can get creative 😀

NOTE: It was easier to do everything in R2. But, if you have been paying attention, you should have noticed that the ideal point to place the EXTENDED ACL, was on R1’s Fa0/0 interface, not R2. Because it should be CLOSE to source (if extended).

I hope you have enjoyed this post as much as i did writing it!

As always, try at home, make some experiments, get creative, and… let me know of you want to share your results, suggest topics for next post, or whatever you think can help here at recurseit 😀

See you around!

GRE Tunnels III: Security awakens

Heeey! 😀 Here we are again (sorry for the delay in this post, been quite busy lately), this time we will talk about security (a little bit) on GRE tunnels.

As we talked previously (see previous chapters of the GRE Saga), we can establish a tunnel between two peers, over the public internet, right? (chapter 1). Then, we saw that GRE is stateless, so, we cannot determine if the other side of the tunnel is reachable or not. We must have a route in order to bring up the tunnel interface (which is logical), but we don’t know about the other end. That changed a bit when we discovered that we could implement keepalives (chapter 2), which is like having an annoying friend asking you every “n” seconds something like: “Dude, Are you there?”

Now, we also learned that GRE tunnels can help you to carry other protocols and they are sent as unicast packets (single sender and single receiver), BUT, they have a terrible weakness (like Superman’s)… They are NOT secure 😦

There is something really cool called IPSec (we can make a post about it later) which is a protocol that allows us to secure our communications by encrypting and authenticating each IP packet per session (feel like ninja). I agree, IPSec is very handy, BUT, if you establish an IPSec tunnel between two peers, it only supports unicast traffic 😦 So, broadcast and multicast are out of the equation, which means that we cannot implement routing protocols that rely on multicast, for example.

So, we have GRE in one side, which carries any other protocols but it’s not secure, AND, we have IPSec, which is secure, but only can carry unicast traffic. Are you thinking the same i am? (because i was thinking in Chinese food!) YES! What about ENCRYPTING a GRE tunnel with IPSec? YEAH! That’s BRILLIANT! (that nerd guy in the corner knows everything!)

Our result will be the following: We will encapsulate our packets in a GRE packet, right? then, that GRE packet will be encapsulated into an IP packet… AND, guess what? we encrypt THAT IP packet and its sent as unicast through an IPSec tunnel. Isn’t that cool? We have this unbeatable networking ninja matryoshka that protects our packets when they travel through public internet.

I am sure there is some people thinking about encapsulation, and that is a special detail that needs to be considered. In order to encapsulate our packets in GRE, router needs to add an overhead (24 bytes) to inform the other router about whats is carrying. Now, we need to encapsulate it IN IPSec, so, that adds a little more overhead.

This is a table from Cisco identifying bytes needed:

IPSec-Overhead table

So, what does it tell you? that WE NEED/MUST (if you want it to work properly) change the MTU (1500 bytes by default) to allow this encryption process to run without affecting our traffic forwarding.

Also, we have this little table from Cisco about IPSec and GRE together:

IPSec-GRE MTU table.png

PS: IPSec transform Set is a combination of individuals IPSec transforms designed to enact an specific security policy for traffic flow. In transport mode the original IP packet is not encrypted, only the payload (we need a post only for IPSec for sure!).

NOW, how about doing a quick lab to check our theory? 😀

Remember the lab from chapter 1? We will apply IPSec to our tunnels


I created a couple of loopback interfaces to simulate a connected network. The idea is to make our traffic being encrypted and encrypted and then reaching the loopback interfaces. Simulating a branch office or something like that 🙂

Initial configurations:


interface Tunnel0
ip address
ip mtu 1400
tunnel source Ethernet3/0
tunnel destination

interface Ethernet3/0
ip address

interface Loopback0
ip address


interface Tunnel0
ip address
ip mtu 1400
tunnel source Ethernet3/0
tunnel destination

interface Ethernet3/0
ip address

interface Loopback0
ip address

Now, we need to add static routes to routers to be able to reach loopback interfaces.

On R1:

ip route

On R2:

ip route

Now we make pings to check connectivity:


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/31/64 ms


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/60 ms

Woohooo! 😀 Everything working so far, BUT, NOT SECURE! Lets implement the IPSec encryption!

We need to create an access list to match the traffic that is going to be encrypted

Piece of cake! We need to match the OUTSIDE interface of routers in the access lists.

On R1:

access-list 101 permit gre host host

On R2:

access-list 101 permit gre host host

Configure an isakmp policy (set of rules and configurations that must match in both sides)

crypto isakmp policy 1
authentication pre-share

Here we are telling routers to match a pre-shared key for authentication (remember that IPSec authenticates and encrypts)

Now we create the pre-shared key that routers will use and the peer to send that key:

On R1

crypto isakmp key secured-potato address

On R2

crypto isakmp key secured-potato address

See the syntax! crypto isakmp key [pre-shared key] address [peer address]

Now the transform set used by both routers, must match both sides. (we will talk in deep later about this)

crypto ipsec transform-set potato esp-3des esp-md5-hmac

On this transform set we choose what we will use to encrypt and a tag to identify it (potato is the tag)

This is our full configuration, up to this point:


crypto isakmp policy 1
authentication pre-share
crypto isakmp key secured-potato address
crypto ipsec transform-set potato esp-3des esp-md5-hmac


crypto isakmp policy 1
authentication pre-share
crypto isakmp key secured-potato address
crypto ipsec transform-set potato esp-3des esp-md5-hmac

Guess what? now that we have a peer, a pre-shared key, an ACL that must match out traffic to be encrypted, a transform set and a tag… We need to put everything together!

So, we need to create a crypto map! Its like a giant security blender 😀


crypto map NINJA_POTATO 10 ipsec-isakmp
set peer
set transform-set potato
match address 101

crypto map NINJA_POTATO 10 ipsec-isakmp
set peer
set transform-set potato
match address 101

Keep an eye on this process. We are creating a crypto map, and matching everything we configured before to make them work together. Its like networking glue! 😀

Check the syntax! Its like a route map, but with security features.

crypto map [name] [sequence number] ipsec-isakmp (set of rules used)

Now, people, we need to apply that crypto map to our interfaces. This is the easy part 🙂

Depending of the ios version, you must apply it in the physical and logical interface as well

interface Tunnel0
crypto map NINJA_POTATO

interface e 3/0
crypto map NINJA_POTATO

We should receive a message like this:


Now that everything is in place (finally!) lets test connectivity.

R1(config)#do ping

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/16/32 ms

R2(config)#do ping

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/19/32 ms

And, also lets check the crypto sessions! 😀

Interface: Tunnel0 Ethernet3/0
Session status: UP-ACTIVE  <—- (OH YEAH)
Peer: port 500
IKE SA: local remote Active
IPSEC FLOW: permit 47 host host
Active SAs: 2, origin: crypto map

R2(config)#do sh crypto session
Crypto session current status

Interface: Tunnel0 Ethernet3/0
Session status: UP-ACTIVE   <—- (OH YEAH)
Peer: port 500
IKE SA: local remote Active
IPSEC FLOW: permit 47 host host
Active SAs: 2, origin: crypto map

Congratulations! you have implemented your first IPSec encryption over a GRE tunnel! 😀

More IPSec in following post!

Thanks for reading

GRE Tunnels II: Endless connections

As every movie saga, like Terminator, Star Wars, The Naked gun, Shrek or Resident Evil (loved that one), GRE tunnels are going to have an interesting and cinematographic role here at our blog. Maybe not re-killing zombies (yes, killing them again!) or saving a princes making the dragon eat a dwarf king (that escalated quicky), but with several post about it. Part of this was a recommendation from my dear friend Micheline Murphy (@MichyfishMurphy), she is a dedicated student and also a wonderful person (follow her, i command you!). You can be relaxed, no one is losing a hand in this saga (i did! Shh, Luke! no one is talking about you!).

In the beginning of the GRE saga we made a simple lab with two routers and a tunnel between them. Kinda easy, huh? This time, we are going to make something more interesting. Not the same as destroying the death star, but we will learn something cool! 😀

After this introduction (where are my drums in the background?) then we should head to the topics. First of all: did you know that exist the Put A Pillow On Your Fridge Day? Its on May 29. Make space in your fridge for your pillow! (i could not resist it lol)

Now, let’s focus!

The facts

GRE tunnels are designed to be stateless 😦 that means that one end of the tunnel does not have idea if the other end is reachable! Its routing in the dark! D: That’s the reason behind the fact that if you have a tunnel interface, but not a route to the other tunnel endpoint, the tunnel will not come up. We will make an example about it! 🙂 Last time was easier because we just had two directly connected routers, but in real world we will not have directly connected client’s router, right? 😉

So, what happens when we have something in the middle? Normally, a tunnel interface goes up as soon as you have a route to it. But, what if the destination is not reachable? what if a link goes down? As GRE are stateless, guess what? Your traffic is going to be blackholed. BUT, we can also make that connection reliable!

We can implement a feature called GRE Keepalives. Let’s read a quote from Cisco’s documentation to find out what we can do (don’t be worried, then we can translate it for humans).

The GRE tunnel keepalive mechanism is similar to PPP keepalives in that it gives the ability for one side to originate and receive keepalive packets to and from a remote router even if the remote router does not support GRE keepalives. Since GRE is a packet tunneling mechanism for tunneling IP inside IP, a GRE IP tunnel packet can be built inside another GRE IP tunnel packet. For GRE keepalives, the sender prebuilds the keepalive response packet inside the original keepalive request packet so that the remote end only needs to do standard GRE decapsulation of the outer GRE IP header and then revert the inner IP GRE packet to the sender.

Now, for humans: imagine you are playing hot potato with someone, but you are not using a potato, its a matryoskaSo, when you open it, there is a another matryoska with a sticked and shinning post-it (those fluorescent green ones that literally glow in darkness and burn your pupils when you see them) with a message that says: “Let me know when you receive this”. Well, more or less (kinda complicated example, huh?). You just have to inform the other tunnel endpoint that the packet was received. Why would you need this?

(You! The nerd guy in the corner! Tell us!)

Yes sir! Because we can test reachability! 😀

So, in few words, if we don’t receive an answer from the other side, then we can assume there is not reachability and our traffic is going to be lost. So, the tunnel interface can shut itself down (yes, dynamically) if there is not answer! Isn’t that cool? The router will do it by itself! (Oh dear! Our baby is growing up! A post ago we were just teaching it about a tunnel! :’) )

Let’s take a look to it in a lab!

This will be our topology

GRE P2P 3 Routers

And, our configurations, at least for a start:


interface Ethernet3/0
ip address

interface Tunnel0
ip address
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Ethernet3/0
tunnel destination


interface Ethernet3/0
ip address
interface Ethernet3/1
ip address


interface Ethernet3/1
ip address

interface Tunnel0
ip address
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Ethernet3/1
tunnel destination

Lets take a look at their routing tables:




Now, we want to establish a tunnel between R1 and R3, and we have configured virtual tunnel interfaces in both sides! So, lets make a ping From R1 to see what happens:

Ping R1-R3 (II)

BUT, why? 😦

Let’s check the tunnels! Something is happening here!

Tunnel0 R1 and R3 (II)

See that? As we don’t have a route in any route pointing to the other end of the tunnel, it will not come up. How can we make it work? With networking duct tape! (yes, static routes).

Routes R1 and R3 (II)

And puff! Having a static route in our configuration brings our tunnels up! 😀

Our new routing tables!

Routes R1 and R3 (after duct tape) (II)

Now that our tunnels are up, we can configure keepalives! why? Well, the sad story is that those tunnels are up because of the static route, but it doesn’t guarantee that the other end of the tunnel will be reachable. We need a keepalive to check if your friend in the other side is there.

The syntax of this command is pretty easy, and its applied on the tunnel interface:

Keepalive [Seconds] [Retries]

The default values are 10 seconds for the interval and 3 retries.

So, what will happen here? Keepalives are being sent every [seconds] and after some number of [retries] without answer, the interface will turn itself down.

When i receive the first keepalive, i start to count. At 10 seconds (by default) i am expecting the next one. If i don’t receive it, i will start to count another ten seconds, but i have one retry accounted. So, if on the next opportunity i don’t receive the packet, then i have two, and so on…

After 40 seconds, which is the same as 1 try and 3 retries, without answer, the router will shut the interface down.

If the router receives one keepalive before the expiration time, it will reset the counters! Everything will be on zero again and it will start to count from the beginning.

keepalive 5  3

After adding this commands to our tunnels, i created an ACL in R2 and applied it inbound on the interface Ethernet 3/1 (to torture R3 and R1). As the routers could not reach the other end of the tunnel, after trying and retrying, the tunnel must go down.

R2#show ip access-lists 100
Extended IP access list 100
10 deny gre any any (56 matches)
20 permit ip any any

R1 and R3 shutdown tunnel0 (II)

Here in this screenshot you can appreciate the debug of the keepalives. Before and after the access list were applied in the interface of R2.

We have R3 (up), R1 (bottom) and R2 (right). First, both routers were receiving the keepalives and the tunnels were up. But, what happened when the ACL was applied in R2?

After one try and 3 retries of sending a keepalive and not receiving a response (see R3), it shut the interface down by itself.

See that? they went down!

Lets bring them back up! Well, something better! Lets remove the ACL on R2 and watch how they revive from their ashes! 😀

R1 and R3 up tunnel0 (II)

After the first keepalive received again, intermediately the tunnel is brought back up by R1 and R3! Isn’t that cool? 😀

As we could demonstrate, keepalives work, and very well!



Lab it up and tell me how it goes!

I hope you have enjoyed and learned a lot, like me doing this lab.


More of GRE coming on its way! Wait for it!

The Saga continues!