Labs - Tag - Fryguy's Bloghttps://hugo.fryguy.net/tags/labs/Labs - Tag - Fryguy's BlogHugo -- gohugo.ioenFri, 27 Dec 2013 14:00:40 +0000Cisco CSR1000v For Home Labshttps://hugo.fryguy.net/2013/12/27/cisco-csr1000v-for-home-labs/Fri, 27 Dec 2013 14:00:40 +0000Fryguyhttps://hugo.fryguy.net/2013/12/27/cisco-csr1000v-for-home-labs/

I have been using the Cisco CSR1000V for my home lab setup for a little bit now.  There have been some questions on how to set this up for a home lab and I figured I would cover how I am using it.
For this post, here is what we are going to build –  a three (3) node CSR1000V network and three (3) vSwitch Networks to connect the CSR1000Vs together.  We will also configure the CSR1000V to have connectivity back to the “home production” network so that we can SSH/Telnet to these routers when we are labbing.

Obtaining the CSR1000V Router Software

To obtain the Cisco CSR1000V you need to download it from Cisco at this LINK and click on the Download software as seen circled below

]]>IOS XR – OSPF Configurationhttps://hugo.fryguy.net/2012/09/14/ios-xr-ospf-configuration/Fri, 14 Sep 2012 13:22:03 +0000Fryguyhttps://hugo.fryguy.net/2012/09/14/ios-xr-ospf-configuration/

 

Time for some OSPF configs, these will build off the previous configs we just did.  For this lab, the other router, R2, was
preconfigured to support the connections.

We will place our loopback and out g0/3/0/2 interface into OSPF process LAB and area 0.0.0.0

RP/0/7/CPU0:R1#
RP/0/7/CPU0:R1#conf t
Thu Mar 29 19:37:52.671 UTC


Defineour OSPF process name
RP/0/7/CPU0:R1(config)#router ospf LAB

Now to define our area first
RP/0/7/CPU0:R1(config-ospf)#area 0.0.0.0

Now we can place the interfaces into the area, no need to entering subnets
RP/0/7/CPU0:R1(config-ospf-ar)#inter loo0
RP/0/7/CPU0:R1(config-ospf-ar-if)#inter g0/3/0/2
RP/0/7/CPU0:R1(config-ospf-ar-if)#exit
RP/0/7/CPU0:R1(config-ospf-ar)#exit
RP/0/7/CPU0:R1(config-ospf)#exit
RP/0/7/CPU0:R1(config)#commit

Thu Mar 29 19:38:15.182 UTC
RP/0/7/CPU0:R1(config)#

Now to look at our IP Protocols running:
RP/0/7/CPU0:R1#sh ip proto
Thu Mar 29 19:38:24.113 UTC
Routing Protocol OSPF LAB
Router Id: 1.1.1.1
Distance: 110
Non-Stop Forwarding: Disabled
Redistribution:
None
Area 0.0.0.0
Loopback0
GigabitEthernet0/3/0/2
RP/0/7/CPU0:R1#

]]>More LiSP – using it to enable IPv6 over IPv4https://hugo.fryguy.net/2011/04/08/more-lisp-using-it-to-enable-ipv6-over-ipv4/Fri, 08 Apr 2011 22:51:15 +0000Fryguyhttps://hugo.fryguy.net/2011/04/08/more-lisp-using-it-to-enable-ipv6-over-ipv4/

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

]]>Using a Cisco Device as a TFTP Serverhttps://hugo.fryguy.net/2011/01/26/using-a-cisco-device-as-a-tftp-server/Wed, 26 Jan 2011 13:00:01 +0000Fryguyhttps://hugo.fryguy.net/2011/01/26/using-a-cisco-device-as-a-tftp-server/The other day I mentioned about using a router as a TFTP server to upgrade other devices.  Since I did mention that, it makes sense to post on how to use a router for this functionality.
Have you ever need to upgrade the IOS on a remote device?  Happened to have more then one of those at a remote site? Have multiple devices at a site to upgrade?  I am sure we have all been there at one time or another with one or all of these scenarios.  Most of us tend to pre-load the code on the devices in preparation for the upgrade, but what happens when you have insufficient space on the device you need to upgrade?  Typically that means performing the IOS transfer when you are doing the upgrade and not before – that is usually during sleeping hours and not business hours.
What happens if you could A) send a USB drive to the site and have someone plug it in or B) Copy the files necessary to another device and use that to copy the files from?  Both of these sound much better then having to upload code in the middle of the night.  Well, but configuring your router to act as a TFTP server, you might allow yourself some sleep time instead of watching the !!!!! – and the occasional 000 – go across the screen.
For this blog, lets use this topology:

]]>LACP Configuration and multi-chassis Etherchannel on Nexus 7000 with vPC, Part 2 of 2https://hugo.fryguy.net/2010/09/13/lacp-configuration-and-multi-chassis-etherchannel-on-nexus-7000-with-vpc-part-2-of-2/Mon, 13 Sep 2010 23:47:25 +0000Fryguyhttps://hugo.fryguy.net/2010/09/13/lacp-configuration-and-multi-chassis-etherchannel-on-nexus-7000-with-vpc-part-2-of-2/This is the second part in a two part post on Etherchannel on the Nexus 7000.  In the first part I covered how to configure vPC on the Nexus 7000, here I will cover what it takes to get a remote switch to uplink to the Nexus 7000 core switches using vPC/Multi-chassis etherchannel. Here is a diagram depicting the layout that we are using. For this part of the post, we will focus on the blue line that is connecting both Nexus switches to the 3750 Stack. On the Cisco 3750 switches (they are in a stack configuration of two switches) we need to configure the interface to be in a channel-group - for this example Iam using Channel-Group 6 (the switch is actually named StackSwitch06). What you will also notice is that you configure the 3750 Stack just like it was only connected to one switch, just one single port-channel that consists of all the ports connected to both Nexus switches. For this example we are using ports G1/0/1, G1/0/24, G2/0/1, and G2/0/24. One thing I want to mention, when you are thinking about your uplinks to your core switches, be aware of the switch ASIC layout. I say this because I have seen many times when companies use ports 23 and 24 to uplink to a core switch. The problem with this is that: 1) The same ASIC is probably controlling both ports, and if     it goes bad your links to the switch are gone and your     switch is also isolated. 2) You have a better chance of oversubscribing the ASIC     before the uplink when utilization is high on the channel. Now, onto the configuration, first up the Cisco 3750s.     interface GigabitEthernet 1/0/1      description [----[ Uplink to N7K1 - E9/10 ]----]     switchport trunk encapsulation dot1q      switchport mode trunk     channel-group 6 mode active     interface GigabitEthernet1/0/24      description [----[ Uplink to N7K2 - E9/10 ]----]      switchport trunk encapsulation dot1q      switchport mode trunk      channel-group 6 mode active     interface GigabitEthernet 2/0/1      description [----[ Uplink to N7K1 - E10/10]----]      switchport trunk encapsulation dot1q      switchport mode trunk      channel-group 6 mode active     interface GigabitEthernet2/0/24      description [----[ Uplink to N7K2 - E10/10]----]      switchport trunk encapsulation dot1q      switchport mode trunk      channel-group 6 mode active      Once the interfaces are assigned to the channel-group, we can configure the etherchannel on the Cisco 3750s. Notice that there is no vPC info nor anything else that says this is connected to two switches.      interface Port-channel6       switchport trunk encapsulation dot1q       switchport mode trunk Now, on the Nexus side we need to do some configurations as well. Both Nexus switches are also configured the same, so there are no differences in the switch configs.     interface Ethernet9/10        description [----[ StackSwitch6-1 ]----]        switchport        switchport mode trunk        channel-group 6 mode active        no shutdown 
     interface Ethernet10/10
       description [----[ StackSwitch6-1 ]----]
       switchport
       switchport mode trunk
       channel-group 6 mode active
       no shutdown
Now, when it comes to configuring the etherchannel on the Nexus
switches, is is configured the same except for the addition of
a vPC identifier. I recommend using the same number that you used
for the port-channel for easy identification, but that is up to you.
   interface port-channel6
     description [----[ LACP EtherChannel for StackSwitch6 ]----]
     switchport
     switchport mode trunk
     vpc 6

Once you have it configured on the Nexus, make sure it is up and
in the vPC correctly.        

     N7K1# sh int port-channel 6  
     port-channel6 is up
     vPC Status: Up, vPC number: 6
     Hardware: Port-Channel, address: 5475.d04f.1165 (bia 5475.d04f.1165)  
     Description: [----[ LACP EtherChannel for RackSwitch6 ]----]   
     Members in this channel: Eth9/10, Eth10/10  
     N7K1#
Once you have confirmed that all is working correctly, you can
check out the StackSwitch spanning tree information: 

     StackSwitch06#sh spanning-tree interface port-channel 6 
     Vlan             Role Sts Cost      Prio.Nbr Type
     ---------------- ---- --- --------- -------- --------------------------------
     VLAN0001         Root FWD 3         128.656  P2p
     VLAN0002         Root FWD 3         128.656  P2p
     VLAN0003         Root FWD 3         128.656  P2p
     VLAN0004         Root FWD 3         128.656  P2p
     VLAN0005         Root FWD 3         128.656  P2p
     StackSwitch06#
You will see that even though you are connected to two switches,
the port-channel is seen as a single spanning-tree
path to the root.
]]>LACP Configuration and multi-chassis Etherchannel on Nexus 7000 with vPC, Part 1 of 2https://hugo.fryguy.net/2010/09/13/lacp-configuration-and-multi-chassis-etherchannel-on-nexus-7000-with-vpc-part-1/Mon, 13 Sep 2010 15:21:21 +0000Fryguyhttps://hugo.fryguy.net/2010/09/13/lacp-configuration-and-multi-chassis-etherchannel-on-nexus-7000-with-vpc-part-1/The other day I received a question on Ether-channel and the Nexus 7000 - based on the question I felt it would be also good to include the information here. This will be a 2-part post, first part is the Nexus configuration for vPC, the second post will be on the mutli-chassis ether-channel configuration around the 3750 as well as the Nexus 7000 switches. What are the benefits of Multi-chassis (vPC) ether-channel?  Basically all your up-links from your switches are in FORWARDING mode, nothing is in blocking mode in your spanning tree domain.  What this means is that you have a loop free topology in your data center and all links can be utilized. Below is the diagram of the configuration that I will be showing here.  There will be a Layer 2 Ether-channel vPC between the Nexus 7010-1 and Nexus 7010-2 (Orangish line), a Layer 3 Ether-channel for vPC keep-alive (Red line), as well as a mutli-chassis (vPC) ether-channel from a 3750 stack to Nexus 7010-1 and Nexus 7010-2 with all links in a single ether-channel bundle. Configuration for both of the Nexus switches is the same except where noted. Configuration for the Nexus switches First thing to do is enable the vPC feature: feature vpc Once you have enabled the vPC feature, you should create your keep-alive links. Here I create a port-channel via LACP over ports 9/1 and 10/1. You will also notice that I have spread the channel over two line cards. This has been done to help assure maximum redundancy. If a card where to go bad, the other card would still be active in the port-channel. interface Ethernet9/1   description [----[ vPC KeepAlive to CoreSwitch2 ]----]   channel-group 101 mode active ! Assign port to port-channel 101 via LACP   no shutdown interface Ethernet10/1   description [----[ vPC KeepAlive to CoreSwitch2 ]----]   channel-group 101 mode active   no shutdown Now we can create the VRF for the keep-alive link. I suggest using a dedicated VRF for security and sanity purpose. This VRF will not participate in your global routing table, thus allowing for more stability and also the prevention of duplicate IP addresses in the network. vrf context VPC100_KA Now we can create the Layer 3 interface on the port-channel and assign it to the new VRF, VPC100_KA interface port-channel101   description [----[ vPC Keep-Alive link between CoreSwitches ]----]   vrf member VPC100_KA ! Assign this interface into the appropriate VRF   ip address 10.10.10.1/30 ! The other side of the link is .2/30 Now you can configuration the vPC Peer links (Orangish lines). Since I am using 10G links for this connection, I have set the rate mode to Dedicated. This prevents any chance for over subscription on the 10G port. It also disables the other 3 ports in group, so you need to keep that in mind when you are designing your deployment.   interface Ethernet7/1   description [-[ vPC Connection to Nexus 7010-2 - E7/1 ]-]   switchport    switchport mode trunk ! Set the mode to trunk     rate-mode dedicated force ! Force the rate-mode     mtu 9216     udld enable ! Since this is also fiber, enable UDLD     channel-group 100 mode active ! Assign to port-channel 100     no shutdown   !    interface Ethernet8/1    description [-[ vPC Connection to Nexus 7010-2 - E8/1 ]-]    switchport    switchport mode trunk    rate-mode dedicated force    mtu 9216    udld enable    channel-group 100 mode active no shutdown   ! Now to configure the port-channel as a vPC link as well as the vPC domain information.   interface port-channel100    description [-[ vPC Peer-Link between Nexus Switches ]-]    switchport    switchport mode trunk    vpc peer-link ! Assign this port-channel as a vpc peer-link    spanning-tree port type network    mtu 9216 ! vpc domain 100 role priority 16000 ! Here I hard-coded switch 1 to be the vPC master. switch 2 was left as the default peer-keepalive destination 10.10.10.2 source 10.10.10.1 vrf VPC100_KA ! The other side has the IP addresses reversed Had to move the formatting above to get the command to fit, sorry. Let's check the port-channel and make sure it is up with the appropriate members. As you can see from the output, Eth7/1 and Eth8/1 are members of the channel. N7K1# sh int port-channel 100 port-channel100 is up  [------ SNIP - Output omitted! ------] Members in this channel: Eth7/1, Eth8/1 N7K1# Also check the vPC and the vPC keep-alive link N7K1# sh vpc Legend:        (*) - local vPC is down, forwarding via vPC peer-link  vPC domain id                        : 100   Peer status                          : peer adjacency formed ok        vPC keep-alive status                : peer is alive                   Configuration consistency status     : success   Type-2 consistency status            : success   vPC role                            : primary, operational secondary  Number of vPCs configured            : 9     Peer Gateway                         : Disabled  Dual-active excluded VLANs           : -  vPC Peer-link status  ---------------------------------------------------------------------  id   Port   Status Active vlans      --   ----   ------ --------------------------------------------------  1    Po100  up     1-224 N7K1# sh vpc peer-keepalive vPC keep-alive status           : peer is alive                 --Peer is alive for             : (1486816) seconds, (684) msec --Send status                   : Success --Last send at                  : 2010.09.11 12:38:36 872 ms --Sent on interface             : Po101 --Receive status                : Success --Last receive at               : 2010.09.11 12:38:36 872 ms --Received on interface         : Po101 --Last update from peer         : (0) seconds, (161) msec vPC Keep-alive parameters --Destination                    : 10.10.10.2 --Keepalive interval            : 1000 msec --Keepalive timeout             : 5 seconds --Keepalive hold timeout        : 3 seconds --Keepalive vrf                 : VPC100_KA --Keepalive udp port            : 3200 --Keepalive tos                 : 192 N7K1# As of now, both switches are connected via vPC. This concludes the first post, the second post will be up shortly and will focus around the Cisco 3750 configuration as well as the associated configs on the Nexus 7000 switches.]]>Nexus 7000 Training Documentationhttps://hugo.fryguy.net/2010/07/05/nexus-7000-training-documentation/Mon, 05 Jul 2010 15:57:01 +0000Fryguyhttps://hugo.fryguy.net/2010/07/05/nexus-7000-training-documentation/A few weeks ago the company that I work for received our Nexus 7000 (7010 to be exact) switches.  Since my team was not familiar with these switches, I decided to write some quick training docs and labs for them.  Since they where well received ( or perhaps they just do not know better ), I have decided to share them with the rest of the population.
These  docs are by no-means an end-all be-all type document on the Nexus 7000 switches, but they might be enough to get you familiar with them. They are in PDF format below:
Nexus 7000 Lab Answers ver1
Nexus 7000 Training Docs
Any questions, please let me know.
Cards 2, 3, 4, 7, 8, 9 and 10 are N7K-M148GT; cards 5 and 6 are N7K-SUP1, and cards 7 and 8 are N7K-M132XP.
There has been a recent request to post the cabling diagram, here it is to the best of my memory:

The configs for the switch and the router have been lost to time, but perhaps one day I can recreate them.
Updated March 2013:
Ron Fuller, David Jansen, and Matthew McPherson have released NX-OS and Cisco Nexus Switching, 2nd Edition recently.  Below is a link to Amazon where you can purchased this book.  It is a great addition to any technical library and covers the NX-OS in great depth.  I was also a technical review on this book.

]]>