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! 😀

Advertisements

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:

192.168.1.0 /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:

2001:0000:0000:0000:DB8:800:200C:417A

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:

2001:0:0:0:DB8:800:200C:417A

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

What about this address?

FF01:0000:0000:0000:0000:0000:0000:0001

We can write it this way:

FF01:0:0:0:0:0:0:1

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:

FF01::1

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:

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

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

2001::DB8:AC10:FE01::

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:

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

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:

3ffe:1944:100:a::bc:2500:d0b/64

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

3ffe:1944:100:a::/64

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:

SHOULD

 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 10.10.1.0/24 and going to network 10.10.2.0/24. 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 10.10.2.0 255.255.255.0 12.12.12.2

R1(config)#do ping 10.10.2.1                          

Type escape sequence to abort.

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

!!!!!

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

R2(config)#ip route 10.10.1.0 255.255.255.0 12.12.12.1

R2(config)#do ping 10.10.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.1.1, 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 10.10.1.0 network going towards 10.10.2.0 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 10.10.1.0 0.0.0.255

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!

R1#ping 10.10.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.2.1, 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 10.10.2.1 source lo0 <— source address will be loopback’s

Type escape sequence to abort.

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

Packet sent with a source address of 10.10.1.1

UUUUU

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 10.10.1.1 0.0.0.255 10.10.2.1 0.0.0.255 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   10.10.1.0, wildcard bits 0.0.0.255 (30 matches)

    20 permit any (30 matches)

Extended IP access list 101

    10 deny icmp 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255 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 10.10.1.1 0.0.0.255 10.10.2.1 0.0.0.255 <— 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   10.10.1.0, wildcard bits 0.0.0.255 (30 matches)

    20 permit any (30 matches)

Extended IP access list 101

    10 deny icmp 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255 echo

    20 permit ip any any

Extended IP access list POTATO

    10 deny gre 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255

    20 permit ip any any

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

R2(config-ext-nacl)#15 deny icmp 10.10.1.1 0.0.0.255 10.10.2.1 0.0.0.255

And, now, show again! 😀

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

Standard IP access list 1

    10 deny   10.10.1.0, wildcard bits 0.0.0.255 (30 matches)

    20 permit any (30 matches)

Extended IP access list 101

    10 deny icmp 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255 echo

    20 permit ip any any

Extended IP access list POTATO

    10 deny gre 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255

    15 deny icmp 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255  <—- 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 10.10.2.1 source lo0

Type escape sequence to abort.

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

Packet sent with a source address of 10.10.1.1

UUUUU

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   10.10.1.0, wildcard bits 0.0.0.255 (30 matches)

    20 permit any (30 matches)

Extended IP access list 101

    10 deny icmp 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255 echo

    20 permit ip any any

Extended IP access list POTATO

    10 deny gre 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255

    15 deny icmp 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255 (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

GRE 2 Routers ENCRYPTED

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:

R1———————————–

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

interface Ethernet3/0
ip address 12.12.12.1 255.255.255.0

interface Loopback0
ip address 10.10.1.1 255.255.255.0

R2———————————–

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

interface Ethernet3/0
ip address 12.12.12.2 255.255.255.0

interface Loopback0
ip address 10.10.2.1 255.255.255.0

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

On R1:

ip route 10.10.2.0 255.255.255.0 172.16.0.0

On R2:

ip route 10.10.1.0 255.255.255.0 172.16.0.0

Now we make pings to check connectivity:

R1#ping 10.10.2.1

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

R2#ping 10.10.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, 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 12.12.12.1 host 12.12.12.2

On R2:

access-list 101 permit gre host 12.12.12.2 host 12.12.12.1

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 12.12.12.2

On R2

crypto isakmp key secured-potato address 12.12.12.1

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:

R1————————————————–

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

R2—————————————————-

crypto isakmp policy 1
authentication pre-share
crypto isakmp key secured-potato address 12.12.12.1
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 😀

R1————————————-

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

R2————————————-
crypto map NINJA_POTATO 10 ipsec-isakmp
set peer 12.12.12.1
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:

%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

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

R1(config)#do ping 10.10.2.1

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

R2(config)#do ping 10.10.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, 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: 12.12.12.2 port 500
IKE SA: local 12.12.12.1/500 remote 12.12.12.2/500 Active
IPSEC FLOW: permit 47 host 12.12.12.1 host 12.12.12.2
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: 12.12.12.1 port 500
IKE SA: local 12.12.12.2/500 remote 12.12.12.1/500 Active
IPSEC FLOW: permit 47 host 12.12.12.2 host 12.12.12.1
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:

R1:

interface Ethernet3/0
ip address 12.12.12.1 255.255.255.0

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

R2:

interface Ethernet3/0
ip address 12.12.12.2 255.255.255.0
interface Ethernet3/1
ip address 23.23.23.2 255.255.255.0

R3:

interface Ethernet3/1
ip address 23.23.23.3 255.255.255.0

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

Lets take a look at their routing tables:

R1 RIB (II)

R2 RIB (II)

R3 RIB (II)

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!

GRE Tunnels

All cadets salute the GRE tunnels! 😀

Today we will talk a little about GRE tunnels, a very useful protocol that can help you a lot. As you may now, its present in CCNP R&S blueprint and CCNA v2/v3 as well blueprint (check here for more information about V2 to v3 changes). But, what are the GRE tunnels? how can we use them? why is the sky blue? did you know that the otters sleep hugging between them? (Otterly lovely!)

We will find the answers to those questions here! 😀 (I also want to know why the sky is blue)

What are the GRE tunnels? (You! back there! Excellent question! 5 points for gryffindor!)

First of all, what does GRE means? well, it stands for Generic Routing Encapsulation. Its a tunneling protocol developed by Cisco (oh yeah! no sharing) that can encapsulate a wide variety of protocols inside an IP packet over virtual interfaces. Oh boy that sounds quite interesting! So, we can encapsulate a lot of protocols with GRE and send them through virtual interfaces, which are called tunnels. How can this happen? Well, GRE encapsulate your original packet (lets call it payload) INSIDE a GRE packet, and that GRE packet can be encapsulated into another protocols and then forwared. When the packet arrives the other end of the tunnel, the router rips off the external ip packet, which contains the GRE overhead, and delivers the original packet to its destination. Its like sending a matryoshka! (you know you want to click that link)

Now that we have our firsts answers, come at least two more questions on the top of my head: how can we use them? what are the advantages? what kind of problem solve these not-for-share tunnels? (it later became an industry standard)

Really the otters sleep hugging between them? (I couldn’t resist it)

 

How can we use them?

Well… GRE  allows Routing of IP packets between private IPv4 networks which are separated over public IPv4 internet. It allows, in fact, almost any protocol payload (like a Swiss knife protocol).

 

What are the advantages?

It supports encapsulating IPv4 broadcast and multicast traffic. (Isn’t that AWESOME?).

Thats a huge advantage over a normal IPSec tunnel, which just supports unicast traffic.

 

What are the disadvantages?

GRE tunnels are not secure because GRE by itself does not encrypt its data payload 😦

BUT, it can be used together with IPSec to provide network security. You can encrypt your GRE tunnel with IPSec! 😀

 

TIME FOR A QUICK LAB! (OH YEAH!)

I made a quick lab to show you the simple configuration you need to do to get a GRE tunnel working! 😀

First of all: we will need a couple of routers, some cool music, coffee, and snacks! 😀

This is the topology

GRE 2 Routers

And this is the simple configuration you need to get it working

!R1’s Configuration———————

interface Tunnel0
ip address 172.16.0.1 255.255.255.0
tunnel source Ethernet3/0
tunnel destination 12.12.12.2

interface Ethernet3/0
ip address 12.12.12.1 255.255.255.0

!R2’s configuration———————-

interface Tunnel0
ip address 172.16.0.2 255.255.255.0
tunnel source Ethernet3/0
tunnel destination 12.12.12.1

interface Ethernet3/0
ip address 12.12.12.2 255.255.255.0

As simple as configure source and destination of our tunnel. You can specify a source up address or interface of your router.

After this Copy-paste festival, we will get something like this:

R1 RIBR2 RIB

As you could see, we have in our RIB routes to directly connected interfaces and to the tunnel interfaces. Why do we use an address in the tunnels? Well, we are encapsulatin our GRE packet into an IP packet! 😀 Its like a digital matryoshka!  (the link is at the top)

Now, to check the encapsulation, check her this out!

Packet Capture R2 to R1 (ping)

Thats a ping made from R2 to R1 from between tunnel addresses. In the capture we can see as IPv4 (our public addresses) get encapsulated into GRE, and then, GRE gets encapsulated into IPv4 again (our private addresses into the tunnel). Come on! Don’t you think that this is so COOL? Our matryoshka has born! 😀

NOTE: You must have considerations with GRE. Your MTU must be reduced in your interface in order to avoid problems overpassing the 1500 bytes standard valor. Its recommended that you put also a couple of commands on your tunnel interfaces, as a good practice. Since GRE is an encapsulating protocol, we adjust the MTU to 1400 bytes and maximum segment size (mss) to 1360 bytes. Because most transport MTUs are 1500 bytes and we have an added overhead because of GRE, we must reduce the MTU to account for the extra overhead. A setting of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a minimum.

Commands: (configured in interface sub-mode, in the tunnel interface)

R2(config-if)# ip mtu 1400

R2(config-if)# ip tcp adjust-mss 1360

 

Give it a try and tell me how it goes! 😀

Next post will include GRE and some other cool thing bundled together.

This has been an interesting post and networking world is HUGE! This journey is just getting started!

 

Stay tuned! 😀

PS: Check here to know the answer about the otters and here about the sky and its color.

See that? not just networking! 😀

CCNA Refresh!

As you maybe are aware of, Cisco announced on May 17th an interesting change in its Cisco Certified Entry Networking Technician (CCENT) and Cisco Certified Network Associate (CCNA) Routing and Switching certifications. As always happens with this announcements, there are changes on the exam numbers and their blueprint. I will let you know in a quick synthesis a couple of things here and we can make a deep dive in a next post 🙂

First of all: exam numbers!

ICND1 v2.0 – 100-101

ICND2 v2.0 – 200-101

CCNA v2.0 – 200-120

Remembering a little about them: CCNA can be taken in two ways. You can take Interconnecting Cisco Networking Devices 1 (ICND1), which will certify you as a CCENT, and Interconnecting Cisco Networking Devices 2 (ICND2), which will certify you as a CCNA (after passing ICND1, of course). The other way is to take the CCNA composite exam, which complies both ICNDs in one very interesting and challenging exam. Yes, choose wisely, young engineer. You can decide if taking the red pill of the blue pill, its up to you (feels like Matrix, huh?).

The cool part about this announcement, is that Cisco did not change the exam structure, requirements, or simply eliminated any certification (which they can, its their certification program anyway xD). Its a very simple change, easy to understand. Now, the funny part lies in the contents. Some of them removed (thank God), some new added (oh yeah!) and another ones moved (maybe now i have your attention).

Now, the new exam numbers are the following:

ICND1 v3.0 – 100-105

ICND2 v3.0 – 200-105

CCNA v3.0 – 200-125

Regarding new contents and what party they organized to distribute them, CCNA/ICND1/ICND2 will have an holistic view of networking nowadays. We will see RIP again in ICND1 (this is not the “nowadays” i was talking about), which is curious because they removed it in 2013. A little bit from design’s perspective, new devices (yes!) like: Access Points (APs), Wireless Lan Controllers (WLC) and Firewalls (isn’t that exciting?). Link Layer Discovery Protocol (LLDP, something like Cisco Discovery Protocol (CDP) but free, and with some cool stuff!), A LOT of IPv6, which is excellent, SYSLOG, more about DNS and DHCP (should i write them completely?). DHCP Snooping, eBGP (that was a surprise), L3 Etherchannel, Generic Encapsulation Protocol (GRE) tunnels (yay!) and VTP returns! But, this time, you can TURN IT OFF! Even IPv6 ACLs, Software Defined Networking (SDN), Cloud technologies and WAN architecture, Dynamic Multipoint VPN (DMVPN) and a little of QoS.

At least for me, this new curriculum sounds AWESOME! Some topics are actually tested in CCNP exams, so, this is getting interesting! Dear CCNAers, you have a lot to learn. This new blueprint of the CCNA certification is more challenging and modern. As i see it, CCNAs are going out with better knowledge and an holistic view of the network. This sounds so exciting that i am wishing to make the whole CCNA again!

NOW, before you start running in circles because of the new exam numbers, WAIT! Cisco established a deadline to take those exams! 😀 You can breathe now!

The last days to take those exams are the following:

ICND1 100-101: August 20, 2016

ICND2 200-101: September 24, 2016

CCNA 200-120: August 20, 2016

This is a comparison published by Cisco in this link: Comparison

So, you have a couple of options here: Take the previous exam, which is still doable. Start learning NOW the new contents from the new exam series, or… you can just wait and see how desperation possesses nervous people as the deadline comes towards them (just kidding).

As far as i know, the Official Certification Guide (OCG) for ICND1 is out! and ICND2 Official Certification Guide (OCG) should  be out in early July (based on information from Mr. Wendel Odom (he is like a Networking Jedi Master)).

 

We can talk in details about this in a next post.

For now, i hope you have enjoyed this post and found it useful.

See you around! 🙂