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

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:

Since Cisco posted that picture the other day, you know this one:

Well, since that picture was posted there has been some buzz around the chassis in the twitter feeds.  Not much is officially know about this box – but the picture above proves it does exist.  Not only that, I recall seeing a picture from Cisco Live 2011 – London where the EMC booth had one of these Nexus 7009 looking switches in their booth.  Well here is some additional information that I have located using the assumed part number of N7K-C7009
On Cisco’s website they have a MIB posted called CISCO-ENTITY-VENDORTYPE-OID-MIB.my (clicking on that MIB will allow you to view/download it – original link here ).  From what I can gather in the MIB – the Nexus 7009 will have the new Fabric-2 cards, no Fab-1 cards are even listed for this chassis.  When you search the MIB, you can find the following information:
cevChassisN7Kc7009              OBJECT IDENTIFIER ::= { cevChassis 932 }  — N7K-C7009 nexus-9-slot chassis
cevBackplaneN7Kc7009                    OBJECT IDENTIFIER ::= { cevBackplane 57 }       — MosPort9 N7K-C7009 Nexus-9-slot-backplane
cevFanN7Kc7009FanTray           OBJECT IDENTIFIER ::= { cevFan 129 } — N7K-C7009-FAN  Trinacria-fan-nexus9slot
cevN7Kc7009Fab2         OBJECT IDENTIFIER ::= { cevModuleN7KType 14 }           — dijon9 N7K-C7009-FAB2 Fabric for Nexus7000 9slot boxster
Bonus information contained within the MIB is information on the, yet unannounced, Nexus 7006!
Granted, this is only speculation and such – but the MIB information matches what the 7009 has as well.  Only time will tell if this is true.
cevChassisN7Kc7006              OBJECT IDENTIFIER ::= { cevChassis 1054 } — Nexus7000 6slot elsie n7k chassis N7K-C7006
cevBackplaneN7Kc7006                    OBJECT IDENTIFIER ::= { cevBackplane 60 }       — Nexus7000 6slot elsie n7k backplane N7K-C7006
cevFanN7Kc7006FanTray           OBJECT IDENTIFIER ::= { cevFan 147 } — N7K-C7006-FAN  fan for nexus 6slot-chassis
I also did some searching and found this list of Nexus 7009 Part Numbers, and my assumed descriptions (in blue) of what they are.
N7K-C7009-ACC-KIT    Nexus 7009 Accessory Kit
N7K-C7009-BSK             Nexus 7009 Bottom Support Kit
N7K-C7009-CAB-TOP    Nexus 7009 Top section Cable Management?
N7K-C7009-CM-BLK      Nexus 7009 Cable Management Blank?  Unknown
N7K-C7009-F-BLANK  Nexus 7009 Fabric Blank Interface ?
N7K-C7009-FAB-2        Nexus 7009 Fabric 2 Card
N7K-C7009-FAN            Nexus 7009 Fan Tray
N7K-C7009-FD-MB       Nexus 7009 Front Dook Kit
N7K-C7009-L                  Nexus 7009 License
N7K-C7009-RMK           Nexus 7009 Rack Mount Kit
N7K-C7009-SHPPKG    Nexus 7009 Shipping package
N7K-C7009-XL               Nexus 7009 XL
L-N7K-C7009-XL           Nexus 7009 Scalable Feature License (allows XL featuers without requiring a hardware module change)
Another part-number that I have found that is NOT referenced on the Cisco site is this 5.6KW power supply. Wonder if the 7009 can support a smaller power supply, or this is for the Nexus 7006
N7K-AC-5.6KW         5.6kW AC Power Supply

The other week (week when I stared this post, now its a month!) I attended Tech Field Day #5 in San Jose, CA.  During this event, Drobo presented their technology to us – what it is – how it works – and where it is aimed.  I have to admit that I have been looking at a Drobo for a few years now and never pulled the trigger – until now.  Let me preface that by saying I did purchase a Netgear ReadyNAS NV+ a few years ago instead of a Drobo – and I do still have the Netgear – but am glad that I have added the Drobo to my home storage solution.  I purchased this unit from Drobo directly, using my own funds, and did use a publicly available discount code of BESTDEALEVER
What is a Drobo, in case you are wondering – well – let me let Cali Lewis explain and demonstrate:
[youtube=http://www.youtube.com/watch?v=05yqvb5n36M&feature=player_detailpage]
Ok, so now that I have shown the obligatory video that everyone has probably already seen, I can continue.  There are a few differences in the unit that I purchased, Drobo FS, and the one in the video.  The two big differences are that the Drobo FS holds 5 drives and also has a built-in Gigabit Ethernet port.  No USB or other connectivity required, just plug it into the network and go!
Why did I chose to buy a Drobo when I already have a ReadyNAS from Netgear?  It comes down to the simplicity of the Drobo and how it works.  The Drobo is very simple, there are no drive carriers, the lights are very easy to understand (green, red, yellow), the web interface is simple and direct, and you do not have to be a Computer person to really use it.  I felt that this last piece of information is key – if ever I lost a drive when I was traveling  it would be easy to walk any member of my family through the process of replacing a the bad drive.
While looking at the Drobo you can quickly gauge the health of the unit. In the picture below you can see that all the drives are healthy (Green lights on the right) and the utilization is about 30% or so (Blue lights across the bottom).  What is really nice about this is that you do not need to look at the control panel software to see what is going on with the system.  You can just look at the unit and know that you have space and all the drives are good.  Heck, even a cell phone photo like the one below lets you know the health of the unit just by looking!

Well, today we can welcome the Cisco Nexus 7009 to the Nexus family.  It joins its big brothers the 7010 and 7018 as you can see below.

So, what does this new chassis give us over its bigger brothers?  Well for one thing, SPACE!  The Nexus 7009 is only 14RU compared to the 7010 at 21RU and the 7018 at 25RU. What does that actually mean, well if you look at a standard 6509 / 6509E chassis – they are 15RU.  This new Nexus 7009 is actually 1RU smaller, nice!  One of the biggest complaints with the Nexus is that it is difficult to install if you are replacing an existing 6509 chassis with one, the 7010 is bigger and – as we all know – space in a data center is very precious!

Just a quick post on Drobo.
We visited them on Tech Field Day and heard about their offerings as well as touched their product. To be quite honest, I was very impressed with what I saw. I have been considering getting a Drobo for quite some time and finally pulled the trigger. The discount code BESTDEALEVER was too hard to pass up.
So, why am I telling you this? Simple, I will do a write-up that consists of my TFD5 experience with Drobo and my experience with an actual unit. Their product is top notch and deserves a justified write-up. Just writing based on my experience at TFD5 would not do their product justice. Being able to relate my experience at TFD as well as the setup and use of the unit is what it deserves.
Hoping that the order shows up quickly so I can get this post done (also want to play with the new toy 🙂 )
Tech Field Day Disclosure:
Drobo was a sponsor of Tech Field Day 5, and as such was responsible for a portion of my airfare and hotel accommodations. At no time did Drobo ask for nor were they promised any kind of consideration in this article. Any and all analysis and opinions are mine and mine alone.

While attending Tech Field Day #5, INFOBLOX presented their IP Address Management (IPAM) application, Insight,  to the group.  The goal of this product is to help you to manage your IP Addresses via an application instead of the traditional approach.  My initially reaction to this was – Why?  Why would a company need this box to managed IP addresses? Isn’t that what Microsoft DHCP/DNS does?
When you think of IPAM in a company you typically think about using either spreadsheet applications, or DHCP with a combination of DHCP reservations.  This approach works well, but to be honest it does have its limitations.  It does not scale well, it can really only be used by one person at a time (spreadsheets), the database is subject to corruption on the server, and changes get lost because someone was working on a copy of a copy of a copy.  We have all been there and seen it, managing an IP scheme via spreadsheet is possible – but has its challenges.  There has to be a better way, and that is what INFOBLOX thought as well.
In my experience, as a company grows, each sites starts to “control their IP destiny” in different ways.  These can be via VLANs that have different IP ranges; IP ranges that are not contiguous; IP ranges that are way too big for the task at hand (can you say /16), or even not keeping like servers in like segments (i.e. all Exchange boxes across an enterprise with an IP of 10.x.1.50/24).  I won’t even go into the problem of someone just putting on IP on a device, only later to find out that it is a duplicate IP address for a critical server.  An IPAM application can assist in identifying these problems, rectifying them with rules, as well as checks and balances.
Another common problem is DNS across an enterprise.  There is typically one group who controls access to this system, and if you want a change you either need to e-mail them or open a ticket with the Support Desk.  This process can add time to a deployment, is subject to error, or just upright confusion when you say you want MyRouter.MyDomain.Network to map to these multitude of IP Addresses.  Yes, it does work and gets the workload off you plate, but there has to be a better way.  Also when it comes to DNS, I tend to want to use Router-Interface.location for DNS entries, and that can be tough to explain to someone who is used to Server.domain.
So, what does INFOBLOX do that makes it so much better.  Well, that is simple – just gives you central location via the web to manage your IPAM.  No more spreadsheets, no more IP address surprises, and no more what addresses are available questions.  Their product allows you to have a central repository of all IP addresses across your enterprise.  You are able to find available IP addresses easily, and then quickly assign them to a new device.  What is also cool is that the product can map out an IP address to a port on a switch (provided SNMP and such is enabled).  The product will scan your network for new IP addresses that have appeared on the network, build IP maps based of the discovery, as well as provide you the location of said device (uses SNMP to poll switches and such) if you want to know where it is.
The SNMP feature is great just for the Server guys in my opinion – they can find out where something is located instead of always asking the Network team.  They can use this feature to find out speed, duplex, mac address, switchport connection, switch information, etc.  That feature alone is worth the price of admission if you ask me!  Many times I am asked “Where is this connected?”; “What speed and duplex do you see?”; “What are the switchport capabilities 100/100?”  – with this tool those calls will no longer be there.
There is a demo available that you can actually download and run under VMWare Player (VMPlayer) so you can actually take it for a test run.  To be honest, it is a bit tough to figure out at first (I probably should read the help file) – but I think the product is worth it.  It makes it easier to manage the network, see what IP addresses are in use, as well as what the device is.  To get the demo, you need to provide your information and they will then send you a link to download the software – you can find the request page here – http://www.infoblox.com/en/resources/freeware.html.  The VMWare Player is available here as well (VMWare account required).
Tech Field Day Disclosure
INFOBLOX was a sponsor of Tech Field Day 5, and as such was responsible for a portion of my airfare and hotel accommodations.  At no time did INFOBLOX ask for nor were they promised any kind of consideration in this article.  Any and all analysis and opinions are mine and mine alone.

Well it is now Sunday, two days after Tech Field Day #5 ended.  I am finally starting to digest everything that was presented to the team and just wanted to take a moment and share some of my experiences.  I am going to hold off on commenting on the data gathered from the presentation because I would like to gather some more information, review my notes, as well as even review some of the wonderful video that was shot.
Let me start off with the invitation to the event.  To be quite honest I was very surprised to be invited to this event because I did not think I was worthy of attendance.  When I was asked, I was very excited at first – then humbled by the invitation.  It is because of all of you that I was able to go – and that I thank you for. If you are interesting in being a delagate, some of the things that are sought after are respected by your peers, knowledgeable in the industry, and being respectful to others. To apply to be a delegate, please feel free to visit Gestalt IT at this link.
When it comes to the preparation for the event, it shows that they know what they are doing.  The travel arrangements are spot on, your hotel room is ready for you when you get there, the transportation schedule is worked out to the minute (and we all know that is an amazing thing to do!), and the dinner arrangements are perfect.  You can tell this is a profession organization and knows how to plan an event!  The preparation that they do is amazing, if not mind boggling.   They have a schedule that is well communicated, well planned, and very well thought out.  They also make sure that the presenters are aware without actually interrupting the event – they run a fine show.

Well, the week has finally come and the hours are ticking until Tech Field Day #5 in San Jose, CA begins. Tomorrow will be a fun filled travel day for me (ABE – ORD – SJC) and then then the real fun will begin that evening.
Cannot wait to see what the the vendors have to share and say and as well as what I am going to learn. This will be a great adventure for me!
Watch for some blogging during the event, I will do my best to keep things up to date.

This is just a quick post on how to setup CallManager Express for home using a Cisco 2800 series router.
The specs for this network are:

• My home telephone number is 6105555555 (pretty cool, eh?  j/k – that is a fictitious number for this posting.)
• Cisco PoE Capable Switch
• Cisco 2811 Series Routers w/256 memory and 512 compact flash
• VIC2-2FXO card for analog telephone in the house
• VIC2-2FXS card for the connection to the Telephone Company
• Cisco ASA 5500 Firewall for Internet connectivity
• Cisco 7960G IP Phones
• Cisco 7920 Wireless Phone
• A few normal Analog phones around the house.
• Hold music via multicast – BMG.wav
• Web services hosted on berbee.com
• CallManager Express v7.1

So, quick background on the FXO and FXS cards. These cards are what allow you to connect your router to the Telephone company for inbound/outbound calling or to an analog phone.  The FXS provides battery to (S)tuff, FXO points toward the Central (O)ffice (Thanks Tom for the analogy)
Below is an image that depicts the cards and their connections.