Data Center - Tag - Fryguy's Blog

Cisco Champion of Data Center

Fryguy — Fri, 13 Dec 2013 13:05:11 +0000

Some time ago, not sure how long ago, Cisco started a Cisco Champion program for people who are passionate about Cisco and active on social media ( twitter, Facebook, Google Plus, etc). I am glad to say that I and flattered and honored to be called a Cisco Champion Data Center.

Taking some words from the Champion site – http://www.cisco.com/web/about/facts_info/champions.html#~overview, , the Cisco Champion program is:

Passionate Experts, Global Champions for Change

What makes a Cisco Champion? Passion, plus a desire to share their perspectives with the community. There are Cisco Champions all over the world. They represent a variety of segments across the IT industry. And they offer their time to help others learn about Cisco and connect with Cisco in unique ways.

In addition to sharing their insights and expertise, Cisco Champions make a difference by:

Supporting their peers in social communities, forums, and networks
Sharing their relevant experiences and thoughts on Cisco blogs
Providing valuable feedback directly to Cisco
And more

CCIE Data Center Hardware Cost Estimate

Fryguy — Tue, 20 Mar 2012 17:20:36 +0000

That picture about describes the cost of the new CCIE Data Center Hardware. Keep in mind, that this is list price – and my best uneducated guess at what we will see on the lab in the terms of hardware and quantity. Regardless, I think I will nickname this new certification – The Million Dollar CCIE!

CCIE Data Center Written Number – 350-080

Fryguy — Thu, 15 Mar 2012 14:33:43 +0000

As you all are probably aware, I have been keeping an eye out for info on the CCIE Data Center track. I came across some more information and just wanted to take a moment and share it with you.
If you head on over to the Cisco Page on Certification Exams – http://www.cisco.com/web/learning/le3/le11/learning_all_certification_exams_list.html and look around you will notice that CCIE Data Center is listed with MISSING LINK under the numbers 350-080 as well as a MISSING LINK to the CCIE Data Center Lab exam information. At least now we know what test to take, alas it is not on Pearson Vue site – yet. I might give this one a shot at Cisco Live US this year.

Nexus 7000 Modules and their Racing Heritage

Fryguy — Mon, 01 Aug 2011 12:08:42 +0000

I figured I would take a few moments and blog about the different Nexus 7000 I/O modules families – the M1 and F1 (formerly D1). It is my understanding that the M in M1 stands for Multifuction and the F in F1 stands for Fabric/FCOE (or fast, depending on who you ask) . So, can you sense a car theme here with this line-up? M1? F1? Well, it only gets better – read on!
(Update 8/7/2012) – Barry Reyes (Twitter) posted a picture on twitter about Formula 1 Racking and the Nexus line cards. Below is that picture:

First lets start with the M1 line cards – the N7K-M108X2-12L, N7K-M132XP-12, N7K-M148GT/S, N7K-M148GT/S-11L, N7K-M102CF-22L and N7K-M106FQ-23L. Some of the common features to all the M1 series of line cards is that they are L2/L3 capable, will support LISP as well as OTV.

The N7K-M108X2-12L is a 8-port 10G line card that uses the X2 series of GBICs. The X2 GBICs that are supported include the SR, LR, LRM, ER, ZR, LX4 and the CX4. This card was named after the Adelaide Street Circuit in South Australia. Some of the specs of this card are:

Nexus 7009 – More information

Fryguy — Tue, 19 Jul 2011 12:00:38 +0000

A few months ago I did a quick post on the Nexus 7009 when it was pseudo announced (here ). When I was attending Cisco Live 2011 last week in Las Vegas I found out that they had a Nexus 7009 in their Data Center booth in World of Solutions for all to see. So, I figured I would post some updated information that I was able to gather or figure out. All this information was being openly spoken in the booth, nothing here was gathered from any other resource then what I was able to hear. To recap, below is a picture of the new family member, the 7009 along side its big brothers the 7010 and the 7018. As you can see there are some nice size differences. The Nexus 7009 us 14RU, the 7010 21RU, and the 7018 25RU. [][2]

Cisco Live 2011 – Sunday – Next Gen Data Center Infrastructure

Fryguy — Mon, 11 Jul 2011 04:04:00 +0000

Well, Day two of Cisco Live 2011 for me (for some this is your first day as you are still arriving).

For me, I am taking an 8 hour Techtorial on Next Generation Data Center Infrastructure TECDCT-8001. This is a paid seminar that has covered some great material – and probably help to generate some future blog posts as well!

Mike Herbert took the first part of the class and did a great review of some of the changes that have happened in the data center over the past few years. From the evolving 3-tier architecture with Spanning Tree and such all the way to Fabric Path and TRILL. Nothing was really in depth but was a great setting of the stage for the day. Some of the things that I liked was the discussion on the Data Center Standards and where different things are in the flow. Another nice discussion was data center cabling and the potential future of cabling. From the traditional home-run cabling that many of us use today to the discussion of top of rack (TOR) and end of row (EOR) drivers with regards to 10g and beyond cabling. Problems discussed where primarily the cost of running those lengths of cables to the cross-talk potentials due to the power required to drive the data. Oh yeah, Mike gets some bonus points for mentioning LISP during the presentation as well.

CCIE Data Center – Rumored

Fryguy — Tue, 05 Jul 2011 12:12:17 +0000

With Networkers, err Cisco Live, coming up quickly in less then a week the rumor mill is a buzzing with some good rumors. There is a rumor that a new little brother in the Nexus line is coming, but the one that has my attention is perhaps a new CCIE level certification – might even be retiring one that has overlapping technologies (storage). Over on 2bccie.com, there is a post in regards to the CCIE Data Center track being discussed on day during the CCIE Lunch at Cisco Live Melbourne – link. While that is all still rumors, here is what I can gather by researching available resources and taking some educated guesses on what would be on the lab. I will also admit that this was briefly discussed at Cisco Live 2010 and that was in a session that would have the knowledge about the topic, so much of this comes from what I can read from my chicken scratch notes. Obviously, Cisco has been working on this for some time and the maturity of the line is finally at the stage and market saturation where this certification makes sense.

What's in my toolbag

Fryguy — Thu, 16 Jun 2011 17:56:32 +0000

This post is more of an informative post with regards to what tools I tend to use on a regular basis in my job. Recently, Stretch wrote about what was in his tool bag over on PacketLife.Net . He has some GREAT information over there beside just that post, so if you have never visited you should wander over there when you have time.

For the most part I tend to use the many of the same tools he discussed, but figured it would be nice to share what I have in my bag. So, without further typing, here we go!
Note: If you click on the pictures it will take you to a link to where you can either get the tool or a similar tool if the one I had is no longer availablee

This is probably my most used tool when I do not have to make cables. It contains just about every nut, bolt, and screw that you will find in a data center. It is easy to use, quick to find, and very versatile. No need to separate screw drivers or pliers, just grab this and you are good to go!

More LiSP – using it to enable IPv6 over IPv4

Fryguy — Fri, 08 Apr 2011 22:51:15 +0000

Ok, now that I have that basic LISP post out, you know this one LISP – Say What?!, I figured I would build upon that configuration. Today I will show you how to overlay IPv6 at your sites while keeping your core IPv4 only. There is no IPv6 addressing nor routing configured on the core Routers and this post will continue where the other one left off, no configuration changes have been made prior to this post, except I did have to upgrade from a base image to an Enterprise image to support IPv6 on R2, R3, and R4. R1 is still running an IOS that does not support LISP nor IPv6. This post will focus on the configuration first and then the explanation of how last.
Below is the same topology I used in the other LISP post, just added some IPv6 addressing and routing protocols for Site-A and Site-B. I am going to build on what we have done in the other lab, so not all the necessary LISP configs are here for a scratch-built config. I have included the full configs in the bottom of this post if you would like to look at them.

Quick rundown on color codes again:
Router Output
Notes
Commands
Lets start with R4, the LISP MS/MR device. We will configure this to accept the IPv6 networks to the xTR routers at Site A and Site B
We need to enable IPv6 Routing on R4. There will no no IPv6 interfaces, but it still needs to understand how to route IPv6 for when a request comes in
LISP_R4_MP_MR(config)# ipv6 unicast-routing
Now we need to enable the IPv6 address family under the VRF, just like we did for IPv4.
LISP_R4_MP_MR(config)# vrf definition lisp
LISP_R4_MP_MR(config-vrf)# rd 1:1
LISP_R4_MP_MR(config-vrf)# address-family ipv6
LISP_R4_MP_MR(config-vrf-af)# exit-address-family
Now enable LISP to be a map-server and resolver for IPv6
LISP_R4_MP_MR(config)# ipv6 lisp map-server
LISP_R4_MP_MR(config)# ipv6 lisp map-resolver
And just like IPv4, we need to add the IPv6 networks for the mappings for Site A and Site B
LISP_R4_MP_MR(config)# lisp site Site-A
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 2001:DB8:0:1::/64 accept-more-specifics
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 2001:DB8:0:2::/64 accept-more-specifics
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 2001:DB8:0:3::/64 accept-more-specifics
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 2001:DB8:0:25::/64 accept-more-specifics
LISP_R4_MP_MR(config)# lisp site Site-B
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 2001:DB8:0:1001::/64 accept-more-specifics
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 2001:DB8:0:1002::/64 accept-more-specifics
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 2001:DB8:0:1003::/64 accept-more-specifics
LISP_R4_MP_MR(config-lisp-site)# eid-prefix 2001:DB8:0:1036::/64 accept-more-specifics
That is all that is necessary on R4 in order for LISP. Just to prove there is no IPv6 configured:
LISP_R4_MP_MR# sh ipv int br
GigabitEthernet0/0         [up/up]
unassigned
Now, lets to the other two routers that are not part of LISP, namely R5 and R6.
R5 first
First we will enable IPv6 routing
LISP_R5(config)# ipv6 unicast-routing
Configure and enable IPv6 OSPF process 1
LISP_R5(config)# ipv6 router ospf 1
LISP_R5(config-rtr)# log-adjacency-changes
Now we can assign our IPv6 addresses to our existing Loopback addresses and place these interfaces into OSPF PID 1 Area 0
LISP_R5(config)# interface Loopback1
LISP_R5(config-if)# ipv6 address 2001:DB8:0:1::5/64
LISP_R5(config-if)# ipv6 ospf 1 area 0
LISP_R5(config)# interface Loopback2
LISP_R5(config-if)# ipv6 address 2001:DB8:0:2::5/64
LISP_R5(config-if)# ipv6 ospf 1 area 0
LISP_R5(config)# interface Loopback3
LISP_R5(config-if)# ipv6 address 2001:DB8:0:3::5/64
LISP_R5(config-if)# ipv6 ospf 1 area 0
LISP_R5(config)# interface FastEthernet0/1
LISP_R5(config-if)# ipv6 address 2001:DB8:0:25::5/64
LISP_R5(config-if)# ipv6 ospf 1 area 0
That is all that is needed for R5. The reason we created an OSPF process is so that we can learn an IPv6 default ( ::/0 ) route from R2
now R6
Just like R5, we will enable IPv6 routing.
LISP_R6(config)# ipv6 unicast-routing
Then create the IPv6 OSPF Process 1
LISP_R6(config)# ipv6 router ospf 1
LISP_R6(config-rtr)# log-adjacency-changes
Now we will assign the IPv6 addresses to the interfaces as well as place the interfaces in IPv6 OSPF Process ID 1, Area 0
LISP_R6(config)# interface Loopback1
LISP_R6(config-if)# ipv6 address 2001:DB8:0:1001::6/64
LISP_R6(config-if)# ipv6 ospf 1 area 0
LISP_R6(config)# interface Loopback2
LISP_R6(config-if)# ipv6 address 2001:DB8:0:1002::6/64
LISP_R6(config-if)# ipv6 ospf 1 area 0
LISP_R6(config)# interface Loopback3
LISP_R6(config-if)# ipv6 address 2001:DB8:0:1003::6/64
LISP_R6(config-if)# ipv6 ospf 1 area 0
LISP_R6(config)# interface GigabitEthernet0/1
LISP_R6(config-if)# ipv6 address 2001:DB8:0:1036::6/64
LISP_R6(config-if)# ipv6 ospf 1 area 0
Again, that is all for R6. And just like R5, we created OSPF so that we can learn an IPv6 default ( ::/0 ) route from R3
So, now we can configure our xTR routers – R2 and R3. R2 first
R2
Again, we need to enable IPv6 on these devices
LISP_R2(config)# ipv6 unicast-routing
Now we create the IPv6 OSPF process and configure it to generate the default route ( ::/0 ) to R5
LISP_R2(config)# ipv6 router ospf 1
LISP_R2(config-rtr)# default-information originate always
There are no configuration changes on G0/0, it maintains its IPv4 address – there is NO IPv6 configured on this interface.
LISP_R2(config)# interface GigabitEthernet0/0
Now we can configure the EID side of the network with IPv6 and place the interface into IPv6 OSPF PID 1, Area 0
LISP_R2(config)# interface GigabitEthernet0/1
LISP_R2(config-if)# ipv6 address 2001:DB8:0:25::2/64
LISP_R2(config-if)# ipv6 ospf 1 area 0
Now we can configure this device to be an xTR and the associated LISP map-resolver and LISP map-server
LISP_R2(config)# ipv6 lisp itr
LISP_R2(config)# ipv6 lisp itr map-resolver 10.1.14.4
LISP_R2(config)# ipv6 lisp etr
LISP_R2(config)# ipv6 lisp etr map-server 10.1.14.4 key Fryguy
Now we have to tell the MR/MS what EIDs are reachable via our RLOC interface
LISP_R2(config)# ipv6 lisp database-mapping 2001:DB8:0:1::/64 IPv4-interface GigabitEthernet0/0 priority 1 weight 100
LISP_R2(config)# ipv6 lisp database-mapping 2001:DB8:0:2::/64 IPv4-interface GigabitEthernet0/0 priority 1 weight 100
LISP_R2(config)# ipv6 lisp database-mapping 2001:DB8:0:3::/64 IPv4-interface GigabitEthernet0/0 priority 1 weight 100
LISP_R2(config)# ipv6 lisp database-mapping 2001:DB8:0:25::/64 IPv4-interface GigabitEthernet0/0 priority 1 weight 100
Now onto R3
R3
Like all the other routes, we will enable IPv6
LISP_R3(config)# ipv6 unicast-routing
…and configure OSPF PID 1. Again, configuring the router to generate the ::/0 route for R6
LISP_R3(config)# ipv6 router ospf 1
LISP_R3(config-rtr)# default-information originate always
Now we an configure the IPv6 side of the router, and as with all the other routers, place the interface into OSPF
LISP_R3(config)# interface GigabitEthernet0/0
LISP_R3(config-if)# ipv6 address 2001:DB8:0:1036::3/64
LISP_R3(config-if)# ipv6 ospf 1 area 0
Again, we do not make any changes to the LISP RLOC interface, no IPv6 on this interface!
LISP_R3(config)# interface GigabitEthernet0/1
Now we can configure the router to be an xTR with the MS/MR of 10.1.14.4
LISP_R3(config)# ipv6 lisp itr
LISP_R3(config)# ipv6 lisp itr map-resolver 10.1.14.4
LISP_R3(config)# ipv6 lisp etr
LISP_R3(config)# ipv6 lisp etr map-server 10.1.14.4 key Fryguy
And now all the database mappings for the EIDs that are reachable via the RLOC interface
LISP_R3(config)# ipv6 lisp database-mapping 2001:DB8:0:1000::/54 IPv4-interface GigabitEthernet0/1 priority 1 weight 100
LISP_R3(config)# ipv6 lisp database-mapping 2001:DB8:0:1001::/64 IPv4-interface GigabitEthernet0/1 priority 1 weight 100
LISP_R3(config)# ipv6 lisp database-mapping 2001:DB8:0:1002::/64 IPv4-interface GigabitEthernet0/1 priority 1 weight 100
LISP_R3(config)# ipv6 lisp database-mapping 2001:DB8:0:1003::/64 IPv4-interface GigabitEthernet0/1 priority 1 weight 100
LISP_R3(config)# ipv6 lisp database-mapping 2001:DB8:0:1036::/64 IPv4-interface GigabitEthernet0/1 priority 1 weight 100
So, now that everything is configured, lets do a PING from R5 Loopback1 to R6 Loopback1
LISP_R5# ping ipv6 2001:DB8:0:1001::6 source loopback 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:1001::6, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
LISP_R5#
There we go, it worked! LISP allowed us to encapsulate the IPv6 packet within IPv4 without have to configure 6to4 tunnels and such.
Why? Well, LISP encapsulate the original packet when it goes from one RLOC to the other RLOC 🙂
Now that we have that all configured and tested, lets look at the output from R4 using a the command sh lisp site summary. As you will see, we now have 4 configured networks for IPv6 and 4 registered. Our IPv4 routes and networks are still there from before, none of that changed.
LISP_R4_MP_MR# sh lisp site summary
…………………….———– IPv4 ———–……….———– IPv6 ———–
Site name……….Configured Registered Incons Configured Registered Incons
Site-A…………………………2……………2……….……………4…………….4……….
Site-B…………………………2…………….2……….…………..4…………….4……….
Number of configured sites:……………………..2
Number of registered sites:………………………2
Sites with inconsistent registrations:………….
IPv4
..Number of configured EID prefixes:…………..4
..Number of registered EID prefixes:……………4
IPv6
..Number of configured EID prefixes:…………..8
..Number of registered EID prefixes:……………8
LISP_R4_MP_MR#
Now we can look at the output from show lisp site to see what networks are registered. As you can see, both IPv4 and Ipv6 networks are listed with their perspective RLOC routers.

LISP_R4_MP_MR# sh lisp site
LISP Site Registration Information
Site Name      Last      Up   Who Last             Inst     EID Prefix
Register       Registered           ID
Site-A         00:00:02 yes 10.1.12.2                     150.1.25.0/24
…………….00:00:02 yes 10.1.12.2                     150.1.125.0/24
……………. 00:00:07 yes 10.1.12.2                     2001:DB8:0:1::/64
……………. 00:00:07 yes 10.1.12.2                     2001:DB8:0:2::/64
……………. 00:00:07 yes 10.1.12.2                     2001:DB8:0:3::/64
……………. 00:00:07 yes 10.1.12.2                     2001:DB8:0:25::/64
Site-B         00:00:53 yes 10.1.13.3                     150.1.36.0/24
……………. 00:00:53 yes 10.1.13.3                     150.1.136.0/24
……………. 00:00:10 yes 10.1.13.3                     2001:DB8:0:1001::/64
……………. 00:00:10 yes 10.1.13.3                     2001:DB8:0:1002::/64
……………. 00:00:10 yes 10.1.13.3                     2001:DB8:0:1003::/64
……………. 00:00:10 yes 10.1.13.3                     2001:DB8:0:1036::/64
LISP_R4_MP_MR#
Now, just like I did for the IPv4 only lab, here is the debug output from debug lisp control-plane all. If you need an explanation, just refer to the prior post please.

LISP_R2# debug lisp control-plane all
LISP_R2#
*Apr 8 22:18:21.098: LISP: Processing data signal for EID prefix 2001:DB8:0:1001::6/128
*Apr 8 22:18:21.098: LISP: Remote EID prefix 2001:DB8:0:1001::6/128, Change state to incomplete (method: data-signal, state: unknown, rlocs: 0).
*Apr 8 22:18:21.098: LISP: Remote EID prefix 2001:DB8:0:1001::6/128, Scheduling map requests (incomplete) (method: data-signal, state: incomplete, rlocs: 0).
*Apr 8 22:18:21.130: LISP: Send map request for EID prefix 2001:DB8:0:1001::6/128
*Apr 8 22:18:21.130: LISP: Remote EID prefix 2001:DB8:0:1001::6/128, Send map request (1) (method: data-signal, state: incomplete, rlocs: 0).
*Apr 8 22:18:21.130: LISP: AF IPv6, Sending map-request from 2001:DB8:0:25::2 to 2001:DB8:0:1001::6 for EID 2001:DB8:0:1001::6/128, ITR-RLOCs 1, nonce 0xC4B2E8BE-0x4DCA442F (encap src 10.1.12.2, dst 10.1.14.4).
*Apr 8 22:18:21.130: LISP: Processing received Map-Reply message from 10.1.13.3 to 10.1.12.2
*Apr 8 22:18:21.130: LISP: Received map reply nonce 0xC4B2E8BE-
LISP_R2#0x4DCA442F, records 1
*Apr 8 22:18:21.130: LISP: Map Request prefix 2001:DB8:0:1001::6/128 remote EID prefix, Received reply with rtt 0ms.
*Apr 8 22:18:21.130: LISP: Processing mapping information for EID prefix 2001:DB8:0:1001::/64
*Apr 8 22:18:21.130: LISP: Remote EID prefix 2001:DB8:0:1001::/64, Change state to complete (method: map-reply, state: unknown, rlocs: 0).
*Apr 8 22:18:21.130: LISP: Remote EID prefix 2001:DB8:0:1001::/64, Starting idle timer (method: map-reply, state: complete, rlocs: 0).
*Apr 8 22:18:21.130: LISP: Remote EID prefix 2001:DB8:0:1001::6/128, Change state to deleted (method: data-signal, state: incomplete, rlocs: 0).
*Apr 8 22:18:21.134: LISP: Remote EID prefix 2001:DB8:0:1001::/64, Recalculated RLOC status bits from 0x0 to 0x1 (method: map-reply, state: complete, rlocs: 1).
*Apr 8 22:18:21.134: LISP RIB_RWATCH: (default:ipv4:base) T 10.1.13.3/32 EVENT Track start
*Apr 8 22:18:21.134: LISP RIB_RWATCH: (default:ipv4:base) N 10.1.13.3/32 Adding track
*Apr 8 22:18:21.134: LISP RIB_RWATCH: (default:ipv4:base) N 10.1.13.3/32 QP Schedule query
*Apr 8 22:18:21.134: LISP RIB_RWATCH: (default:ipv4:base) T 10.1.13.3/32 EVENT Query found route
*Apr 8 22:18:21.134: LISP RIB_RWATCH: (default:ipv4:base) R 10.0.0.0/8 d=1 p=1 -> 10.1.12.1 (base) 0 Updating
*Apr 8 22:18:21.134: LISP RIB_RWATCH: Adding to client notification queue
*Apr 8 22:18:21.134: LISP: Remote EID prefix 2001:DB8:0:1001::/64 locator 10.1.13.3 priority 1 weight 100, Added locator (method: map-reply, state: complete, rlocs: 1).
*Apr 8 22:18:21.134: LISP RIB_RWATCH: (default:ipv4:base) W 10.1.13.3/32 c=0x69B38AB8 Client notified reachable
LISP_R2#
LISP_R2#
Now from R5 I will ping the rest of the IPv6 interfaces on R6:
LISP_R5# ping ipv6 2001:DB8:0:1002::6 source loopback 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:1002::6, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
LISP_R5# ping ipv6 2001:DB8:0:1003::6 source loopback 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:1003::6, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
LISP_R5#
This way we can now look at the R2 LISP Map Cache
LISP_R2# sh ipv6 lisp map-cache
LISP IPv6 Mapping Cache, 4 entries
::/0, uptime: 00:11:01, expires: never, via static
Negative cache entry, action: send-map-request
2001:DB8:0:1001::/64, uptime: 00:10:50, expires: 23:49:02, via map-reply, complete
Locator    Uptime    State      Pri/Wgt
10.1.13.3 00:10:50 up           1/100
2001:DB8:0:1002::/64, uptime: 00:00:07, expires: 23:59:45, via map-reply, complete
Locator    Uptime    State      Pri/Wgt
10.1.13.3 00:00:07 up           1/100
2001:DB8:0:1003::/64, uptime: 00:00:02, expires: 23:59:50, via map-reply, complete
Locator    Uptime    State      Pri/Wgt
10.1.13.3 00:00:02 up           1/100
LISP_R2#
As you can see, all the IPv6 routes are reachable via 10.1.13.3 – an IPv4 address 🙂
Here are the configs for the routers
R1
R2
R3
R4
R5
R6

LISP – Locator Identifier Separation Protocol (Say what?)

Fryguy — Thu, 07 Apr 2011 14:57:38 +0000

Recently I have been working on a crazy busy project at work as well as preparing for the CCIE SP lab (did not pass). Well now that is all behind me so I figured I would take some personal time and play with some technology that I have read about, talked about, and even sat through presentations at Cisco Live (aka Networkers) in the past. What is this technology that has me so interested you might ask. Well, its LISP – Locator Identifier Separation Protocol (ietf draft can be found here – http://tools.ietf.org/pdf/draft-ietf-lisp-11.pdf). The next question you may have is why does this interest me? To be honest, I have no idea – just thought it was a nifty idea.
So, what is LISP? The easiest way to explain it is to give you a common analogy that we all understand, DNS. When a user wants to access a website – in this case – blog.fryguy.net, they send a DNS query to the configured DNS server. The DNS servers then resolves that DNS name to an IP address – 76.74.254.123 – and sends that back to the client. The client web application then makes a connection to the web server and retrieves the website.

Well, in LISP a very similar thing happens. If a router needs to send a packet to 76.74.254.123, and that route is not in the local routing table – it sends a query to the LISP Map Resolver. The LISP Map Resolver then looks at its database and tells the router that the network can be reached via 4.71.170.2. The router then sends a LISP encapsulated packet to 4.71.170.2 to be then forwarded onto its ultimate destination.

That is a very simple explanation on how it works, and one that I hope most networking folks should be able to understand. Now lets take it a step further – and think about moving a device around, yet keeping the same IP address (think vmotion). If you are registering a device location with a server, you can then move that device around and the mapping server will be able to redirect you to the correct site. There are other things that LISP can do, but I will save the IPv6 one for a future post.
We have host 100.100.100.100/32, called an EID – Endpoint Identifier – that is sitting behind Router A. Router A will register that network, or host in this case, with the LISP Map Server. It will say to get to the EID prefix of 100.100.100.100/32, send the packet to Router A. We also have another EID at 200.200.200.200/32 that is sitting behind Router B. Router B will also register with the LISP Map Server that host 200.200.200.200/32 is reachable via Router B. So if 200.200.200.200/32 wants to talk to 100.100.100.100/32, it will send the packet to Router B – Router B will then ask the LISP Mapping Server how to get to 100.100.100.100/32. The LISP Map server will respond – to get to 100.100.100.100/32, send the packet to Router A. Router B would then in turn send the packet to Router A, who will then process the packet and forward it onto 100.100.100.100/32.
Now what happens if we move 100.100.100.100/32 to Site C? In a normal network, we would have to change the IP address of the host to a network that is reachable via Router C. You typically cannot advertise the same network from two sites and expect things to work correctly. But with LISP, you can move the host around and not change the IP address. Why? Well, the Mapping server is what tells the routers who want to talk to 100.100.100.100/32 how to get to the host.
So lets move 100.100.100.100/32 to a location in Site-C behind Router C. Router C would then register with the LISP Map server that 100.100.100.100/32 is now reachable via Router C. The next time that 200.200.200.200/32 goes to talk to 100.100.100.100/32, Router B will query the LISP Map Server who will then tell it, to get to 100.100.100.100/32, send the packet to Router C for processing.

Another use case could be with a multi-homed site, like the picture below. Typically with BGP you can only “recommend” an ingress point into your network, you have no way of guaranteeing the traffic will only flow into Router B from your upstream ISP. Sure, you can prepend AS numbers; tweak the mutli-exit discriminator (MED), etc – but it is only a suggestion to your upstream ISP. So what can LISP do for us here? Easy, you can set a priority to the mapping on the LISP server. You can say that Router A has a higher priority for ingress traffic then Router B. The LISP server will then return the path with the lowest Priority listed is the preferred route. This will help to make sure that the traffic is flowing inbound the way that you want it to.

So lets list out some of the components of a LISP environment: