Author Archives: kim

Onto the next one…

Yesterday I passed the CCNA-W exam. Now onto the next partner certification I need to do before summer.

Its called 500-452 ENCWE – Enterprise Networks Core and WAN Essentials and a large part of it involves iWAN, which im not too familiar with.

To that effect I have ordered the official Cisco Press iWAN book and downloaded all the presentations I could find on iWAN from CiscoLive365. That should keep me busy for the foreseeable future 🙂

I will hopefully be doing some labs on iWAN and will post any findings I have here. It should be fun!

Im still debating whether or not I will goto CLUS this year. Whats really pulling me over there is the people I rarely get to meet. I need to make up my mind soon though.

Take care!

/Kim

So whats next?

I’ve had a little time readjusting after my exam and I’ve given some thought on what to keep me busy next.

Basically I have 3 projects to keep me busy for the next foreseeable future.

1) CCNA-Wireless
My boss came to me a week ago and tasked me with this. He was very humble about it, which was amusing. I will be allocated some time from my normal work projects to study for the exam, which is really helpful. Fortunally some of my CCDE study friends are also going for this exam, so I wont be going down the road alone on this one either.
Im actually quite positive about this as its a technology area I have not really paid much attention to and its very different in what im used to. A shakeup is good every now and then 🙂

2) The IOS-XR Specialist exam
This is one I have been looking quite forward to for some time. Its basically an exam about all things IOS-XR and the platforms that supports it. I tried studying for this before I decided to go down the CCDE path, so it will be nice to pick back up.

3) Work on improving my health.
This is by far the most important one. I have been neglecting my health for far too long now and this needs to change. Im thinking about a different blog site where ill provide updates on what my current health situation is, along with how I aim to improve it. More on this to come when ive gathered my thoughts on this bullet-point.

So it didnt take me long to come up with something to keep me busy 🙂

/Kim

CCDE – A different Journey

Wednesday the 22nd of February, in a testing center in the middle of London, my journey towards achieving the CCDE certification, finally ended in me passing this beast of an exam.

This learning journey was a very different one than either of my CCIE’s. Whereas going for the CCIE meant spending countless hours at the command-line, the CCDE meant spending all of those hours reading and discussing use cases for technologies. It also meant stepping my toes into the business side, picking up the “Why?” behind selecting a specific technology.

It all started a few years ago when my friend Daniel (lostintransit.se) and I started going back and forth on how to approach this thing. We decided we should team up and share notes, discuss technologies and generally use each other as a sparring partner.

At that point I had already decided, that this was going to be a marathon for me, because I could at the time, not allocate as much time each day for study, as I had been for the CCIE’s. Fast forward a good amount of time and I had finally passed the written part of the exam and was ready to really focus on the practical aspect.

Anyone reading the CCDE Practical blueprint basically come to the same conclussion in that it involves every technology under the sun and then some. This in turn made us start a small study group using Slack, with only 4 members to begin with. This was the turning point for me as we had discussions around scenarios and use cases. It helped tremendously that we all come from different backgrounds and industries as well as diverse geographies.

I attended Jeremy Filiben’s CCDE bootcamp in Orlando in April 2016 (http://www.jeremyfilliben.com), which was a great experience. Jeremy is a very good teacher and his scenarios are top notch. Going over them really makes you think in a completely different way than fx. the CCIE track(s). As an implementation engineer, you tend to think in a certain way which is not doing you any good in a design context.

Early on, I also purchased access to an All Access Pass from INE in order to gain access to their CCDE training material. Unfortunally it has not been updated since and they have no plan to 🙁

I also used the Self-Paced material from Orhan Ergun, especially the Quizzes was of help to me. (orhanergun.net).

I had my first attempt at the practical in late summer 2016 and I did fairly well, but it certainly opened my eyes to what i had gotten myself into. At the same time I had the fortune of meeting up with some of the Slack study group members which was an added bonus! (Thanks Andre for introducing me to a proper beer 🙂 )…

At this point I had some real life stuff to attend to (we purchased a house with all that entails). So I was unable to commit to the November testing date. However a good number of people from our study group passed which really motivated me to get on with my studies. So ever since late November I have been doing 3-4 hours of study each week day and 5-6 hours each day during the weekend.

The last month and a half before the exam i focused on doing practice scenarios and watching recordings made from our study group discussing designs. I can also highly recommend watching the new Safari Livelessons on QoS and Large Scale Network Designs. If time is of the essence to you, do some speed-viewing which is what i did as well.

I left for London on the day before the exam and checked into my hotel, which is only a 10 minute walk from the testing center. I had already mentally prepared on what to do on the day itself, so basically the day before was the last day to recharge my “batteries” and try and find some focus. I spent an hour or so going over my notes, especially the QoS and IPv6 parts, then went for dinner. I went to bed early as planned.

On the day I woke up very early, which is not unusual for me in any way, so I basically followed what I had mentally prepared for myself which was to take a long and hot shower, get a decent breakfast (hard part for me as i dont normally have breakfast) and then back to the room to collect my things (Exam registration, wallet and passport (You need two forms of ID)). I left the hotel at 7:20’ish and took the short walk to the testing center. Since I was early i waited outside for a bit waiting for the other guy from our study group to show up to say Hi before the exam, but he was running a bit late, so I finally decided that I had to get started and went inside.

Since the exam is under heavy NDA like any other Cisco exam, I wont get into any details regarding the experience, except to say that at no point in the exam did i feel really comfortable about passing it, quite the contrary in fact. However I knew this is a feeling most candidates experience during the CCDE, so I just decided to press on and do my very best.

At lunch I took the advice of several people and had a bite to eat (even though i still didnt feel like eating) and some water and used close to the full hour of lunch available. It being London and all, there are several good places for lunch very close by to the testing center, so you dont need to go very far at all.
The afternoon went by and I finally clicked the End Exam button and instantly my mood picked up. I had passed!! I honestly didnt know what to do with myself at this point 🙂

I had a brisk walk back to the hotel where i could finally put my “guard” down and smile a bit!
I called my better half and told her the good news and she was even more estatic than I was.

So what sort of advice can I give to others?

Read, Watch Sessions (Cisco Live, Safari, Nanog etc.), constantly asking “Why?” to everything. Learn to read through documents and pick up on Business requirements and details that will pertain to certain design choices. Read some more.

If you are like me and you are easily distracted during your studies, I can highly recommend using the “Pomodoro”-method (Look it up), which is essentially 25 minute slots of focus on your studies and then a short break. It gives you a scope of focus and helps keep you on track. On top of that I mark down everything i do, study wise, into my calendar so I can look back at it and get a good “feel” for how much time i spend on it. It helps to give you a boost when you feel that you havent put enough effort into it.

If you want some recommendation on which book(s) to read, here’s a subset of the books I’ve read:

1) Definitive MPLS Network Designs.
2) CCDE Study Guide.
3) Optimal Routing Design.
4) End-To-End QoS.

These are by far the most important ones, but by no means the only ones you want to read through. You have to assess which technologies you need to learn (more) about and then pick the right material for those cases. The books above are very good for general theory but especially Definitive MPLS Network Designs is good for putting all the relevant pieces into 4 distinct use cases.

Some of the Cisco Live sessions i went through includes:

– Scaling BGP (BRKRST-3321)
– Wan and Remote-Site Deployment using CVDs (BRKRST-2040)
– Highly available Wide Area Network Design (BRKRST-2042)
– WAN Architectures and Design Principles (BRKRST-2041)
– Layer 3 Network Virtualization Design Concepts over the WAN (BRKRST-2045)
– Deploying a virtualized campus network infrastructure (BRKCRS-2033)
– Best practices to deploy HA in SP edge and aggregation architectures (BRKSPG-2402)
– Advanced enterprise campus design: routed access (BRKCRS-3036)
– Deploying BGP Fast Convergence / BGP PIC (BRKIPM-2265)
– The QoS Paradigm Shift (BRKRST-2056)
– Deploying OSPF in modern networks (BRKRST-2337)
– ISIS Deployment in modern networks (BRKRST-2338)
– IPv6 Transition Technologies (BRKSPG-2067)
– Choosing the right VPN technology for your network (BRKSEC-1050)
– Firewall architectures in the Data Centre (BRKSEC-2021)
– MAP-E/MAP-T IPv6 transitioning (BRKSPG-2606)

There are a bunch of others and I recommend you search for “Design” and “Use Case” on CiscoLive365.com (It really is an awesome resource for learning).

The last piece of advice I can give, is to join a study group, or if you are more inclined, create one yourself along with some of your friends who are serious about the CCDE as well.
Have discussions revolving around technologies and have even more discussion on scenarios and use cases for those technologies. It really is quite important to expand your horizont in order to be successful in this exam.

If you would like, at certain times we have openings in our study group (which counts 60+ people at the time of writing, including several well known others and vendors), so get in touch if thats your preference.

With that said, I would like to thank you for reading through this post. Its been a fun learning experience all the way through my CCDE – Journey!

/Kim (CCDE #20170021)

A look at Auto-Tunnel Mesh Groups

In this post I would like to give a demonstration of using the Auto-Tunnel Mesh group feature.

As you may know, manual MPLS-TE tunnels are first and foremost unidirectional, meaning that if you do them between two PE nodes, you have to do a tunnel in each direction with the local PE node being the headend.

Now imagine if your network had 10 PE routers and you wanted to do a full mesh between them, this can become pretty burdensome and error-prone.
Thankfully there’s a method to avoid doing this manual configuration and instead rely on your IGP to signal its willingness to become part of a TE “Mesh”. Thats what the Auto-Tunnel Mesh Group feature is all about!

toplogy

In my small SP setup, I only have 3 PE devices, namely PE-1, PE-2 and PE-3. I also only have one P node, called P-1.
However small this setup is, its enough to demonstrate the power of the Auto-Tunnel mesh functionality.

Beyond that, I have setup a small MPLS L3 VPN service for customer CUST-A, which has a presence on all 3 PE nodes. The VPNv4 address-family is using a RR which for this purpose is P-1.

We are running OSPF as the IGP of choice. This means that our Mesh membership will be signaled using Opaque LSA’s, which I will show you later on.

The goal of the lab is to use the Auto-Tunnel mesh functionality to create a full mesh of tunnels between my PE nodes and use this exclusively for label switching and to do so with a general template that would scale to many more PE devices than just the 3 in this lab.

The very first thing you want to do is to enable MPLS-TE both globally and on your interfaces. We can verify this on PE-2:

PE-2:

mpls traffic-eng tunnels
!
interface GigabitEthernet2
ip address 10.2.100.2 255.255.255.0
negotiation auto
mpls traffic-eng tunnels
!

The second thing you want to do is to enable the mesh-feature globally using the following command as configured on PE-2 as well:

PE-2:

mpls traffic-eng auto-tunnel mesh

Starting off with MPLS-TE, we need to make sure our IGP is actually signaling this to begin with. I have configured MPLS-TE on the area 0 which is the only area in use in our topology:

PE-2:

router ospf 1
network 0.0.0.0 255.255.255.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
mpls traffic-eng mesh-group 100 Loopback0 area 0

Dont get hung up on the last configuration line. I will explain this shortly. However notice the “mpls traffic-eng area 0” and “mpls traffic-eng router-id loopback0”. After those two lines are configured, you should be able to retrieve information on the MPLS-TE topology as seen from your IGP:

PE-2:

PE-2#sh mpls traffic-eng topology brief
My_System_id: 2.2.2.2 (ospf 1 area 0)

Signalling error holddown: 10 sec Global Link Generation 22

IGP Id: 1.1.1.1, MPLS TE Id:1.1.1.1 Router Node (ospf 1 area 0)
Area mg-id's:
: mg-id 100 1.1.1.1 :
link[0]: Broadcast, DR: 10.1.100.100, nbr_node_id:8, gen:14
frag_id: 2, Intf Address: 10.1.100.1
TE metric: 1, IGP metric: 1, attribute flags: 0x0
SRLGs: None

IGP Id: 2.2.2.2, MPLS TE Id:2.2.2.2 Router Node (ospf 1 area 0)
link[0]: Broadcast, DR: 10.2.100.100, nbr_node_id:9, gen:19
frag_id: 2, Intf Address: 10.2.100.2
TE metric: 1, IGP metric: 1, attribute flags: 0x0
SRLGs: None

IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node (ospf 1 area 0)
Area mg-id's:
: mg-id 100 3.3.3.3 :
link[0]: Broadcast, DR: 10.3.100.100, nbr_node_id:11, gen:22
frag_id: 2, Intf Address: 10.3.100.3
TE metric: 1, IGP metric: 1, attribute flags: 0x0
SRLGs: None

IGP Id: 10.1.2.2, MPLS TE Id:22.22.22.22 Router Node (ospf 1 area 0)
link[0]: Broadcast, DR: 10.1.100.100, nbr_node_id:8, gen:17
frag_id: 3, Intf Address: 10.1.100.100
TE metric: 10, IGP metric: 10, attribute flags: 0x0
SRLGs: None

link[1]: Broadcast, DR: 10.2.100.100, nbr_node_id:9, gen:17
frag_id: 4, Intf Address: 10.2.100.100
TE metric: 10, IGP metric: 10, attribute flags: 0x0
SRLGs: None

link[2]: Broadcast, DR: 10.3.100.100, nbr_node_id:11, gen:17
frag_id: 5, Intf Address: 10.3.100.100
TE metric: 10, IGP metric: 10, attribute flags: 0x0
SRLGs: None

IGP Id: 10.1.100.100, Network Node (ospf 1 area 0)
link[0]: Broadcast, Nbr IGP Id: 10.1.2.2, nbr_node_id:5, gen:13

link[1]: Broadcast, Nbr IGP Id: 1.1.1.1, nbr_node_id:6, gen:13

IGP Id: 10.2.100.100, Network Node (ospf 1 area 0)
link[0]: Broadcast, Nbr IGP Id: 10.1.2.2, nbr_node_id:5, gen:18

link[1]: Broadcast, Nbr IGP Id: 2.2.2.2, nbr_node_id:1, gen:18

IGP Id: 10.3.100.100, Network Node (ospf 1 area 0)
link[0]: Broadcast, Nbr IGP Id: 10.1.2.2, nbr_node_id:5, gen:21

link[1]: Broadcast, Nbr IGP Id: 3.3.3.3, nbr_node_id:7, gen:21

The important thing to notice here is that we are indeed seeing the other routers in the network, all the PE devices as well as the P device.

Now to the last line of configuration under the router ospf process:

PE-2:

"mpls traffic-eng mesh-group 100 Loopback0 area 0"

What this states is that we would like to use the Auto-Tunnel Mesh group feature, with this PE node being a member of group 100, using loopback0 for communication on the tunnel and running within the area 0.

This by itself only handles the signaling, but we also want to deploy a template in order to create the individual tunnel interfaces. This is done in the following manner:

PE-2:

interface Auto-Template100
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination mesh-group 100
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic

Using the Auto-Template100 interface, we, as we would also do in manual TE, specify our loopback address, the tunnel mode and the path option. Note that here we are simply following the IGP, which sort of defeats the purpose of many MPLS-TE configurations. But with our topology there is no path diversity so it wouldnt matter anyways.

Also, the autoroute announce command is used to force traffic into the tunnels.

The important thing is the “tunnel destination mesh-group 100” which ties this configuration snippet into the OSPF one.

After everything is setup, you should see some dynamic tunnels being created on each PE node:

PE-2:

PE-2#sh ip int b | incl up
GigabitEthernet1 100.100.101.100 YES manual up up
GigabitEthernet2 10.2.100.2 YES manual up up
Auto-Template100 2.2.2.2 YES TFTP up up
Loopback0 2.2.2.2 YES manual up up
Tunnel64336 2.2.2.2 YES TFTP up up
Tunnel64337 2.2.2.2 YES TFTP up up

Lets verify the current RIB configuration after this step:

PE-2:

PE-2#sh ip route | beg Gateway
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/12] via 1.1.1.1, 00:29:13, Tunnel64336
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/12] via 3.3.3.3, 00:28:48, Tunnel64337
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O 10.1.100.0/24 [110/11] via 10.2.100.100, 00:29:13, GigabitEthernet2
C 10.2.100.0/24 is directly connected, GigabitEthernet2
L 10.2.100.2/32 is directly connected, GigabitEthernet2
O 10.3.100.0/24 [110/11] via 10.2.100.100, 00:29:13, GigabitEthernet2
22.0.0.0/32 is subnetted, 1 subnets
O 22.22.22.22 [110/2] via 10.2.100.100, 00:29:13, GigabitEthernet2

Very good. We can see that in order to reach 1.1.1.1/32 which is PE-1’s loopback, we are indeed routing through one of the dynamic tunnels.
The same goes for 3.3.3.3/32 towards PE-3’s loopback.
PE-2:

PE-2#traceroute 1.1.1.1 so loo0
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.2.100.100 [MPLS: Label 17 Exp 0] 16 msec 22 msec 22 msec
2 10.1.100.1 25 msec * 19 msec

We can see that traffic towards that loopback is indeed being label-switched. And just to make it obvious, let me make sure we are not using LDP 🙂

PE-2:

PE-2#sh mpls ldp neighbor
PE-2#

On P-1, it being the midpoint of our LSP’s, we would expect 6 unidirectional tunnels in total:

P-1:

P-1#sh mpls for
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 3.3.3.3 64336 [6853] \
472 Et2/0 10.1.100.1
17 Pop Label 2.2.2.2 64336 [2231] \
2880 Et2/0 10.1.100.1
18 Pop Label 1.1.1.1 64336 [4312] \
2924 Et2/1 10.2.100.2
19 Pop Label 1.1.1.1 64337 [4962] \
472 Et2/2 10.3.100.3
20 Pop Label 2.2.2.2 64337 [6013] \
562 Et2/2 10.3.100.3
21 Pop Label 3.3.3.3 64337 [4815] \
0 Et2/1 10.2.100.2

Exactly what we expected.
The following is the output of the command: “show ip ospf database opaque-area” on PE-2. I have cut it down to the relevant opaque-lsa part (we are using 2 types, one for the general MPLS-TE and one for the Mesh-Group feature):

LS age: 529
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 4.0.0.0
Opaque Type: 4
Opaque ID: 0
Advertising Router: 1.1.1.1
LS Seq Number: 80000002
Checksum: 0x5364
Length: 32

Capability Type: Mesh-group
Length: 8
Value:

0000 0064 0101 0101

LS age: 734
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 4.0.0.0
Opaque Type: 4
Opaque ID: 0
Advertising Router: 2.2.2.2
LS Seq Number: 80000002
Checksum: 0x6748
Length: 32

Capability Type: Mesh-group
Length: 8
Value:

0000 0064 0202 0202

LS age: 701
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 4.0.0.0
Opaque Type: 4
Opaque ID: 0
Advertising Router: 3.3.3.3
LS Seq Number: 80000002
Checksum: 0x7B2C
Length: 32

Capability Type: Mesh-group
Length: 8
Value:

0000 0064 0303 0303

I have highlighted the interesting parts, which is the Advertising Router and the value of the TLV, those starting with 0000 0064, which is in fact the membership of “100” being signaled across the IGP area.
Okay, all good i hear you say, but lets do an end-to-end test from the CE devices in Customer CUST-A’s domain:

R1:

R1#sh ip route | beg Gateway
Gateway of last resort is not set

10.0.0.0/32 is subnetted, 3 subnets
C 10.1.1.1 is directly connected, Loopback0
B 10.2.2.2 [20/0] via 100.100.100.100, 00:37:46
B 10.3.3.3 [20/0] via 100.100.100.100, 00:37:36
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 100.100.100.0/24 is directly connected, FastEthernet0/0
L 100.100.100.1/32 is directly connected, FastEthernet0/0

So we are learning the routes on the customer side (through standard IPv4 BGP).

R1:

R1#ping 10.2.2.2 so loo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/72/176 ms
R1#ping 10.3.3.3 so loo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/32/48 ms

We have reachability! – What about traceroute:

R1:

R1#traceroute 10.2.2.2 so loo0

Type escape sequence to abort.
Tracing the route to 10.2.2.2

1 100.100.100.100 28 msec 20 msec 12 msec
2 10.1.100.100 [MPLS: Labels 18/17 Exp 0] 44 msec 136 msec 60 msec
3 100.100.101.100 [MPLS: Label 17 Exp 0] 28 msec 32 msec 12 msec
4 100.100.101.3 28 msec 32 msec 24 msec
R1#traceroute 10.3.3.3 so loo0

Type escape sequence to abort.
Tracing the route to 10.3.3.3

1 100.100.100.100 48 msec 16 msec 8 msec
2 10.1.100.100 [MPLS: Labels 19/17 Exp 0] 48 msec 12 msec 52 msec
3 100.100.102.100 [MPLS: Label 17 Exp 0] 16 msec 28 msec 36 msec
4 100.100.102.4 68 msec 56 msec 48 msec

Just what we would expect from our L3 MPLS VPN service. A transport label (this time through MPLS-TE) and a VPN label as signaled through MP-BGP.

To round it off, I have attached the following from a packet capture on P-1’s interface toward PE-1 and then re-issued the ICMP-echo from R1’s loopback toward R2’s loopback adress:

wireshark-output

With that, I hope its been informative for you. Thanks for reading!

References:

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/gsmeshgr.html

Configurations:

configurations

Happy New Year

Hi Everyone,

I wish you all a Happy New Year!

Currently im very busy studying for my 2nd attempt at the CCDE Practical exam.
I have it booked for the next slot, which is February 22nd in London.

Thankfully there are more and more material available for the CCDE than just a year ago. One of my primary sources are the study group which I have mentioned before, which Daniel (lostintransit.se) and I started way back.

Im also going through the INE scenarios as well as LiveLessons available through a Safari subscription. Those are really good and I highly recommend them.

One of the primary things im practicing at the moment is picking up business requirements from a given scenario. This is quite hard as im at heart an implementation-focused guy. But its good to learn something new and very useful.

If you are not following it just yet, I can highly recommend the “Unleashing CCDE” site on Cisco Learning Network (https://learningnetwork.cisco.com/blogs/unleashing-ccde). There are alot of good posts there on how to pick up these “soft” skills.

I will keep the blog updated with my study progress through February and we’ll see what happens February 22nd 🙂

Take Care.

/Kim

Snippet: The story of the EFP

For a while now, the concept of EVC’s (Ethernet Virtual Circuits) and EFP’s (Ethernet Flow Points), has eluded me.

In this short post, i will provide you with a simple example of a couple of EFP’s. In a later post i will discuss the MEF concept of EVC’s.

As always, here is the topology i will be using:

topology

Its a very simple setup. R1 connects to R2 through its G1 interface and connects to R3 through its G2 interface.

On R2 and R3, we have the very common configuration of using subinterfaces for the individual Vlan’s in question. Namely Vlan 10 for the connection between R1 and R2 and Vlan 20 between R1 and R3.

Here is the configuration of R2 and R3:

R2#sh run int g1.10
Building configuration...
Current configuration : 98 bytes
!
interface GigabitEthernet1.10
encapsulation dot1Q 10
ip address 10.10.10.2 255.255.255.0
end

R3#sh run int g1.20
Building configuration...
Current configuration : 98 bytes
!
interface GigabitEthernet1.20
encapsulation dot1Q 20
ip address 10.10.10.3 255.255.255.0
end

Now on R1 is where the “different” configuration takes place:

R1#sh run int g1
Building configuration...
Current configuration : 182 bytes
!
interface GigabitEthernet1
no ip address
negotiation auto
service instance 10 ethernet
encapsulation dot1q 10
rewrite ingress tag pop 1 symmetric
bridge-domain 10
!
end

R1#sh run int g2
Building configuration...
Current configuration : 182 bytes
!
interface GigabitEthernet2
no ip address
negotiation auto
service instance 20 ethernet
encapsulation dot1q 20
rewrite ingress tag pop 1 symmetric
bridge-domain 10
!
end

R1#sh run int bdi10
Building configuration...
Current configuration : 96 bytes
!
interface BDI10
description -= Our L3 interface =-
ip address 10.10.10.1 255.255.255.0
end

So what does this all mean!? – Well, basically what you are looking at is the very nature of an EFP. One on each physical interface in this case. It is defined under the “service instance” command structure.

An Ethernet Flow Point (EFP) is a way to match a certain ethernet frame, do an action on it ingress (and also in our case egress). On top of that you can attach it to a bridge-domain.

The result of the above configuration is that on G1, we match on the dot1q tag when its tagged with vlan 10. On ingress we then pop 1 tag before performing any other “upstream” action. With the symmetric keyword, we attach the vlan 10 tag when egressing.

On G2, we are doing the same, but with vlan 20 instead.

With both EFP’s we attach a bridge-domain (ID 10), which can be verified like this:

R1#show bridge-domain
Bridge-domain 10 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
BDI10 (up)
GigabitEthernet1 service instance 10
GigabitEthernet2 service instance 20
AED MAC address Policy Tag Age Pseudoport
- 001E.7AE0.11BF to_bdi static 0 BDI10

Right now we only have one mac address learned, namely of our L3 BDI interface. But we can see that both G1 and G2 has a service instance in this bridge-domain.

Lets try and do some ICMP tests from R2:

R2#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/120/598 ms

Lets again verify our bridge-domain on R1:

R1#show bridge-domain
Bridge-domain 10 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
BDI10 (up)
GigabitEthernet1 service instance 10
GigabitEthernet2 service instance 20
AED MAC address Policy Tag Age Pseudoport
- 001E.7AE0.11BF to_bdi static 0 BDI10
0 0050.56BE.18D8 forward dynamic 276 GigabitEthernet1.EFP10

What we see now, is that a Mac address has been dynamically learned through the G1.EFP10 EFP.

Since we are technically “bridging” these two distinct vlans, we should be able to ping R3 from R2 as well:

R2#ping 10.10.10.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/24/104 ms

And again on R1:

R1#show bridge-domain
Bridge-domain 10 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
BDI10 (up)
GigabitEthernet1 service instance 10
GigabitEthernet2 service instance 20
AED MAC address Policy Tag Age Pseudoport
- 001E.7AE0.11BF to_bdi static 0 BDI10
0 0050.56BE.320A forward dynamic 287 GigabitEthernet2.EFP20
0 0050.56BE.18D8 forward dynamic 287 GigabitEthernet1.EFP10

We have now learned all the Mac addresses in our small test environment.

So thats basically all there is to an EFP. A simple way of providing a flexible way of matching frames.

Until next time! – Take care.

 

New practice lab(s) available…

In case you are serious about going for the CCDE certification, I highly recommend you check out my friend Martin Duggan’s new lab(s) on Leanpub. His writing style is very good and its easy to follow along and i look forward to hitting this lab myself.

So go ahead and pay the man and get an additional CCDE lab for your studies. Take care!

https://leanpub.com/ccdepracticalstudies-practicelab1

 

Practical DMVPN Example

In this post, I will put together a variety of different technologies involved in a real-life DMVPN deployment.

This includes things such as the correct tunnel configuration, routing-configuration using BGP as the protocol of choice, as well as NAT toward an upstream provider and front-door VRF’s in order to implement a default-route on both the Hub and the Spokes and last, but not least a newer feature, namely Per-Tunnel QoS using NHRP.

So I hope you will find the information relevant to your DMVPN deployments.

First off, lets take a look at the topology I will be using for this example:
Topology

As can be seen, we have a hub router which is connected to two different ISP’s. One to a general purpose internet provider (the internet cloud in this topology) which is being used as transport for our DMVPN setup, as well as a router in the TeleCom network (AS 59701), providing a single route for demonstration purposes (8.8.8.8/32). We have been assigned the 70.0.0.0/24 network from TeleCom to use for internet access as well.

Then we have to Spoke sites, with a single router in each site (Spoke-01 and Spoke-02 respectively).
Each one has a loopback interface which is being announced.

The first “trick” here, is to use the so-called Front Door VRF feature. What this basically allows is to have your transport interface located in a separate VRF. This allows us to have 2 default (0.0.0.0) routes. One used for the transport network and one for the “global” VRF, which is being used by the clients behind each router.

I have created a VRF on the 3 routers in our network (the Hub, Spoke-01 and Spoke-02) called “Inet_VRF”. Lets take a look at the configuration for this network along with its routing information (RIB):


HUB#sh run | beg vrf defi
vrf definition Inet_VRF
!
address-family ipv4
exit-address-family

HUB#sh ip route vrf Inet_VRF | beg Ga
Gateway of last resort is 130.0.0.1 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 130.0.0.1
130.0.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 130.0.0.0/30 is directly connected, GigabitEthernet1
L 130.0.0.2/32 is directly connected, GigabitEthernet1

Very simple indeed. We are just using the IPv4 address-family for this VRF and we have a static default route pointing toward the Internet Cloud.

The spokes are very similar:

Spoke-01:





Spoke-01#sh ip route vrf Inet_VRF | beg Gat
Gateway of last resort is 140.0.0.1 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 140.0.0.1
140.0.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 140.0.0.0/30 is directly connected, GigabitEthernet1
L 140.0.0.2/32 is directly connected, GigabitEthernet1



Spoke-02:




Spoke-02#sh ip route vrf Inet_VRF | beg Gat
Gateway of last resort is 150.0.0.1 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 150.0.0.1
150.0.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 150.0.0.0/30 is directly connected, GigabitEthernet1
L 150.0.0.2/32 is directly connected, GigabitEthernet1



With this in place, we should have full reachability to the internet interface address of each router in the Inet_VRF:


HUB#ping vrf Inet_VRF 140.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 140.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/22/90 ms

HUB#ping vrf Inet_VRF 150.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/16/65 ms

With this crucial piece of configuration for the transport network, we can now start building our DMVPN network, starting with the Hub configuration:

HUB#sh run int tun100
Building configuration...



Current configuration : 452 bytes
!
interface Tunnel100
ip address 172.16.0.100 255.255.255.0
no ip redirects
ip mtu 1400
ip nat inside
ip nhrp network-id 100
ip nhrp redirect
ip tcp adjust-mss 1360
load-interval 30
nhrp map group 10MB-Group service-policy output 10MB-Parent
nhrp map group 30MB-Group service-policy output 30MB-Parent
tunnel source GigabitEthernet1
tunnel mode gre multipoint
tunnel vrf Inet_VRF
tunnel protection ipsec profile DMVPN-PROFILE shared
end



There are a fair bit of configuration here. However, pay attention to the “tunnel vrf Inet_VRF” command, as this is the piece that ties into your transport address for the tunnel. So basically we use G1 for the interface, and this is located in the Inet_VRF.

Also notice that we are running crypto on top of our tunnel to protect it from prying eyes. The relevant configuration is here:

crypto keyring MY-KEYRING vrf Inet_VRF
pre-shared-key address 0.0.0.0 0.0.0.0 key SUPER-SECRET
!
!
!
!
!
crypto isakmp policy 1
encr aes 256
hash sha256
authentication pre-share
group 2
!
!
crypto ipsec transform-set TRANSFORM-SET esp-aes 256 esp-sha256-hmac
mode transport
!
crypto ipsec profile DMVPN-PROFILE
set transform-set TRANSFORM-SET



Pretty straightforward with a static pre shared key in place for all nodes.

With the crypto in place, you should have a SA for it installed:


HUB#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
130.0.0.2 150.0.0.2 QM_IDLE 1002 ACTIVE
130.0.0.2 140.0.0.2 QM_IDLE 1001 ACTIVE



One for each spoke is in place an in the correct state (QM_IDLE = Good).

So now, lets verify the entire DMVPN solution with a few “show” commands:

HUB#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
T1 - Route Installed, T2 - Nexthop-override
C - CTS Capable
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel100, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 140.0.0.2 172.16.0.1 UP 05:24:09 D
1 150.0.0.2 172.16.0.2 UP 05:24:03 D


We have 2 spokes associated with our Tunnel100. One where the public address (NBMA) is 140.0.02 and the other 150.0.0.2. Inside the tunnel, the spokes have an IPv4 address of 172.16.0.1 and .2 respectively. Also, we can see that these are being learned Dynamically (The D in the 5 column).

All is well and good so far. But we still need to run a routing protocol across the tunnel interface in order to exchange routes. BGP and EIGRP are good candidates for this and in this example I have used BGP. And since we are running Phase 3 DMVPN, we can actually get away with just receiving a default route on the spokes!. At this point remember that our previous default route pointing toward the internet was in the Inet_VRF table, so these two wont collide.

Take a look at the BGP configuration on the hub router:


HUB#sh run | beg router bgp
router bgp 100
bgp log-neighbor-changes
bgp listen range 172.16.0.0/24 peer-group MYPG
network 70.0.0.0 mask 255.255.255.0
neighbor MYPG peer-group
neighbor MYPG remote-as 100
neighbor MYPG next-hop-self
neighbor MYPG default-originate
neighbor MYPG route-map ONLY-DEFAULT-MAP out
neighbor 133.1.2.2 remote-as 59701
neighbor 133.1.2.2 route-map TO-UPSTREAM-SP out



And the referenced route-maps:


ip prefix-list ONLY-DEFAULT-PFX seq 5 permit 0.0.0.0/0
!
ip prefix-list OUR-SCOPE-PFX seq 5 permit 70.0.0.0/24
!
route-map TO-UPSTREAM-SP permit 5
match ip address prefix-list OUR-SCOPE-PFX
!
route-map TO-UPSTREAM-SP deny 10
!
route-map ONLY-DEFAULT-MAP permit 10
match ip address prefix-list ONLY-DEFAULT-PFX



We are using the BGP listen feature, which makes it dynamic to setup BGP peers. We allow everything in the 172.16.0.0/24 network to setup a BGP session and we are using the Peer-Group MYPG for controlling the settings. Notice that we are sending out only a default route to the spokes.

Also pay attention to the fact that we are sending the 70.0.0.0/24 upstream to the TeleCom ISP. Since we are going to use this network for NAT’ing purposes only, we have a static route to Null0 installed as well:


HUB#sh run | incl ip route
ip route 70.0.0.0 255.255.255.0 Null0



For the last part of our BGP configuration, lets take a look at the Spoke configuration, which is very simple and straightforward:


Spoke-01#sh run | beg router bgp
router bgp 100
bgp log-neighbor-changes
redistribute connected route-map ONLY-LOOPBACK0
neighbor 172.16.0.100 remote-as 100



And the associated route-map:


route-map ONLY-LOOPBACK0 permit 10
match interface Loopback0

So basically thats a cookie-cutter configuration thats being reused on Spoke-02 as well.

So what does the routing end up with on the Hub side of things:


HUB# sh ip bgp | beg Networ
Network Next Hop Metric LocPrf Weight Path
0.0.0.0 0.0.0.0 0 i
*>i 1.1.1.1/32 172.16.0.1 0 100 0 ?
*>i 2.2.2.2/32 172.16.0.2 0 100 0 ?
*> 8.8.8.8/32 133.1.2.2 0 0 59701 i
*> 70.0.0.0/24 0.0.0.0 0 32768 i

We have a default route, which we injected using the default-information originate command. Then we receive the loopback addresses from each of the two spokes. Finally we have the network statement, the hub inserted, sending it to the upstream TeleCom. Finally we have 8.8.8.8/32 from TeleCom 🙂

Lets look at the spokes:


Spoke-01#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*>i 0.0.0.0 172.16.0.100 0 100 0 i
*> 1.1.1.1/32 0.0.0.0 0 32768 ?

Very straightforward and simple. A default from the hub and the loopback we ourself injected.

Right now, we are in a situation where we have the correct routing information and we are ready to let NHRP do its magic. Lets take a look what happens when Spoke-01 sends a ping to Spoke-02’s loopback address:


Spoke-01#ping 2.2.2.2 so loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/17/32 ms

Everything works, and we the math is right, we should see an NHRP shortcut being created for the Spoke to Spoke tunnel:


Spoke-01#sh ip nhrp shortcut
2.2.2.2/32 via 172.16.0.2
Tunnel100 created 00:00:06, expire 01:59:53
Type: dynamic, Flags: router rib
NBMA address: 150.0.0.2
Group: 30MB-Group
172.16.0.2/32 via 172.16.0.2
Tunnel100 created 00:00:06, expire 01:59:53
Type: dynamic, Flags: router nhop rib
NBMA address: 150.0.0.2
Group: 30MB-Group

and on Spoke-02:


Spoke-02#sh ip nhrp shortcut
1.1.1.1/32 via 172.16.0.1
Tunnel100 created 00:01:29, expire 01:58:31
Type: dynamic, Flags: router rib
NBMA address: 140.0.0.2
Group: 10MB-Group
172.16.0.1/32 via 172.16.0.1
Tunnel100 created 00:01:29, expire 01:58:31
Type: dynamic, Flags: router nhop rib
NBMA address: 140.0.0.2
Group: 10MB-Group

And the RIB on both routers should reflect this as well:


Gateway of last resort is 172.16.0.100 to network 0.0.0.0



B* 0.0.0.0/0 [200/0] via 172.16.0.100, 06:09:37
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
H 2.2.2.2 [250/255] via 172.16.0.2, 00:02:08, Tunnel100
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.0.0/24 is directly connected, Tunnel100
L 172.16.0.1/32 is directly connected, Tunnel100
H 172.16.0.2/32 is directly connected, 00:02:08, Tunnel100

The “H” routes are from NHRP

And just to verify that our crypto is working, heres a capture from wireshark on the internet “Cloud” when pinging from Spoke-01 to Spoke-02:

wireshark

Now lets turn our attention to the Quality of Service aspect of our solution.

We have 3 facts to deal with.

1) The Hub router has a line-rate Gigabit Ethernet circuit to the Internet.
2) The Spoke-01 site has a Gigabit Ethernet circuit, but its a subrate to 10Mbit access-rate.
3) The Spoke-02 site has a Gigabit Ethernet circuit, but its a subrate to 30Mbit access-rate.

We somehow want to signal to the Hub site to “respect” these access-rates. This is where the “Per-Tunnel QoS” feature comes into play.

If you remember the Hub tunnel100 configuration, which looks like this:


interface Tunnel100
ip address 172.16.0.100 255.255.255.0
no ip redirects
ip mtu 1400
ip nat inside
ip nhrp network-id 100
ip nhrp redirect
ip tcp adjust-mss 1360
load-interval 30
nhrp map group 10MB-Group service-policy output 10MB-Parent
nhrp map group 30MB-Group service-policy output 30MB-Parent
tunnel source GigabitEthernet1
tunnel mode gre multipoint
tunnel vrf Inet_VRF
tunnel protection ipsec profile DMVPN-PROFILE shared



We have these 2 “nhrp map” statements. What these in effect does is to provide a framework for the Spokes to register using one of these two maps for the Hub to use to that individual spoke.

So these are the policy-maps we reference:


HUB#sh policy-map
Policy Map 30MB-Child
Class ICMP
priority 5 (kbps)
Class TCP
bandwidth 50 (%)

Policy Map 10MB-Parent
Class class-default
Average Rate Traffic Shaping
cir 10000000 (bps)
service-policy 10MB-Child

Policy Map 10MB-Child
Class ICMP
priority 10 (%)
Class TCP
bandwidth 80 (%)


Policy Map 30MB-Parent
Class class-default
Average Rate Traffic Shaping
cir 30000000 (bps)
service-policy 30MB-Child



We have a hiearchical policy for both the 10Mbit and 30Mbit groups. each with their own child policies.

On the Spoke side of things, all we have to do is to tell the Hub which group to use:


interface Tunnel100
bandwidth 10000
ip address 172.16.0.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 172.16.0.100 130.0.0.2
ip nhrp map multicast 130.0.0.2
ip nhrp network-id 100
ip nhrp nhs 172.16.0.100
ip nhrp shortcut
ip tcp adjust-mss 1360
load-interval 30
nhrp group 10MB-Group
qos pre-classify
tunnel source GigabitEthernet1
tunnel mode gre multipoint
tunnel vrf Inet_VRF
tunnel protection ipsec profile DMVPN-PROFILE



Here on Spoke-01, we request that the QoS group to be used is 10MB-Group.

And on Spoke-02:


interface Tunnel100
bandwidth 30000
ip address 172.16.0.2 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 172.16.0.100 130.0.0.2
ip nhrp map multicast 130.0.0.2
ip nhrp network-id 100
ip nhrp nhs 172.16.0.100
ip nhrp shortcut
ip tcp adjust-mss 1360
load-interval 30
nhrp group 30MB-Group
qos pre-classify
tunnel source GigabitEthernet1
tunnel mode gre multipoint
tunnel vrf Inet_VRF
tunnel protection ipsec profile DMVPN-PROFILE



We request the 30MB-Group.

So lets verify that the Hub understands this and applies it accordingly:


HUB#sh nhrp group-map
Interface: Tunnel100
NHRP group: 10MB-Group
QoS policy: 10MB-Parent
Transport endpoints using the qos policy:
140.0.0.2



NHRP group: 30MB-Group
QoS policy: 30MB-Parent
Transport endpoints using the qos policy:
150.0.0.2



Excellent. and to see that its actually applied correctly:


HUB#sh policy-map multipoint tunnel 100

 

Interface Tunnel100 <--> 140.0.0.2

Service-policy output: 10MB-Parent

Class-map: class-default (match-any)
903 packets, 66746 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 900/124744
shape (average) cir 10000000, bc 40000, be 40000
target shape rate 10000000

Service-policy : 10MB-Child

queue stats for all priority classes:
Queueing
queue limit 512 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 10/1860

Class-map: ICMP (match-all)
10 packets, 1240 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: protocol icmp
Priority: 10% (1000 kbps), burst bytes 25000, b/w exceed drops: 0
Class-map: TCP (match-all)
890 packets, 65494 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: access-group 110
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 890/122884
bandwidth 80% (8000 kbps)

Class-map: class-default (match-any)
3 packets, 12 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Interface Tunnel100 <--> 150.0.0.2

Service-policy output: 30MB-Parent

Class-map: class-default (match-any)
901 packets, 66817 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 901/124898
shape (average) cir 30000000, bc 120000, be 120000
target shape rate 30000000

Service-policy : 30MB-Child

queue stats for all priority classes:
Queueing
queue limit 512 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 10/1860

Class-map: ICMP (match-all)
10 packets, 1240 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: protocol icmp
Priority: 5 kbps, burst bytes 1500, b/w exceed drops: 0
Class-map: TCP (match-all)
891 packets, 65577 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: access-group 110
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 891/123038
bandwidth 50% (15000 kbps)

Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0


The last piece of the QoS puzzle is to make sure you have a service-policy applied on the transport interfaces on the spokes as well:


Spoke-01#sh run int g1
Building configuration...

&nbsp;


Current configuration : 210 bytes
!
interface GigabitEthernet1
description -= Towards Internet Router =-
bandwidth 30000
vrf forwarding Inet_VRF
ip address 140.0.0.2 255.255.255.252
negotiation auto
service-policy output 10MB-Parent
end



and on Spoke-02:


poke-02#sh run int g1
Building configuration...

&nbsp;


Current configuration : 193 bytes
!
interface GigabitEthernet1
description -= Towards Internet Router =-
vrf forwarding Inet_VRF
ip address 150.0.0.2 255.255.255.252
negotiation auto
service-policy output 30MB-Parent
end



The last thing i want to mention is the NAT on the hub to use the 70.0.0.0/24 network for the outside world. Pretty straight forward NAT (inside on the tunnel interface 100 and outside on the egress interface toward Telecom, G2):


HUB#sh run int g2
Building configuration...

&nbsp;


Current configuration : 106 bytes
!
interface GigabitEthernet2
ip address 133.1.2.1 255.255.255.252
ip nat outside
negotiation auto
end



Also the NAT configuration itself:


ip nat pool NAT-POOL 70.0.0.1 70.0.0.253 netmask 255.255.255.0
ip nat inside source list 10 pool NAT-POOL overload
!
HUB#sh access-list 10
Standard IP access list 10
10 permit 1.1.1.1
20 permit 2.2.2.2



We are only NAT’ing the two loopbacks from the spokes on our network.

Lets do a final verification on the spokes to 8.8.8.8/32:




Spoke-01#ping 8.8.8.8 so loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/23/56 ms

and Spoke-02:


Spoke-02#ping 8.8.8.8 so loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/14/27 ms



Lets verify the NAT state table on the hub:


HUB#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
icmp 70.0.0.1:1 1.1.1.1:5 8.8.8.8:5 8.8.8.8:1
icmp 70.0.0.1:2 2.2.2.2:0 8.8.8.8:0 8.8.8.8:2
Total number of translations: 2



All good!.

I hope you have had a chance to look at some of the fairly simple configuration snippets thats involved in these techniques and how they fit together in the overall scheme of things.

If you have any questions, please let me know!

Have fun with the lab!

(Configurations will be added shortly!)

1st Attempt – No Dice

So I just got back from my first attempt at the CCDE practical, and unfortunally I didnt pass it.
It was a very different exam than the CCIE and it takes a little while to become used to the interface and exam style.

I started my journey to London on the 30th of August and right off the bat it started out badly with me getting an eye infection in one eye. By the end of the day it had spread to my other eye. Not really what you want or need going into an exam which is heavy on the reading part.

However, it was awesome meeting some of my study buddies from our Slack group! We had a great meal and a few good beers! – Time to call it a night.

The exam has been documented elsewhere, so i wont spend much time on it here. Suffice it to say its a difficult beast 🙂

I only used 5.5 hours of my 9 hour slot, and i just wanted to get out of there and rest my eyes to be honest.

I departed London September 1st and im now back at work. Much the wiser however.

I now know how the exam feels like and the delivery method. I also know what sort of questions are being asked of you and in what detail.

I do need to make up my mind about whether to try the November date or go for the February one. With all the stuff going on in my life at the moment (now being a home-owner), im leaning towards the February one.

Time to get back to work! 🙂

Cisco Live US! 2016

I am fortunate enough, to be able to goto Cisco Live US! again this year.
Last year was such an experience, that my hopes are really high for this year as well.

I will be arriving on Friday the 8th and leaving on the 15th. Not a long stay this time, but it was what my boss could arrange for.
Again this year I will be bringing my better half, so she can experience the city and hopefully we’ll get a few hours of sightseeing in between commitments.

One of the things that im really looking forward to, is meeting up with friends and peers. This year is a bonus for me, as I get to say Congratulations to my friend Daniel (lostintransit.se) in person and not just on the phone, on passing the CCDE practical exam!

Also, a first for me, will be meeting up with Darren (mellowd.co.uk). We have been talking for a long time on twitter, mail and webex and im really looking forward to meeting him in person.

When we get closer to the event, I will be posting my Cisco Live! schedule here.

If you happen to be around the Las Vegas area, or even at Cisco Live!, drop me a line and maybe we can meet up!

See you there!