Fryguy_pa - Tag - Fryguy's Blog

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 – Why you should go. . .

Fryguy — Thu, 14 Apr 2011 12:06:30 +0000

Well, it is almost that time a year when all the “Networkers” get together at the annual Cisco Live event. It is still a few months away when I am writing this – but as we all know – time slows down for no one. I wanted to take a few moments and share with you why I attend as well as why you should consider attending. Please keep in mind that my experience is a bit different from the normal attendee as I am considered a NetVet as well as a CCIE, and being that we get a few additional perks during the event.

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

Nexus 7009

Fryguy — Thu, 31 Mar 2011 01:12:40 +0000

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!

Using a Cisco Device as a TFTP Server

Fryguy — Wed, 26 Jan 2011 13:00:01 +0000

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:

Nexus 7000 and the Show Tech command (gzip too)

Fryguy — Tue, 25 Jan 2011 13:18:24 +0000

Recently I have experience some interesting first-level support from our Cisco VAR. They are not too familiar with the Nexus 7000 and insisted on us sending them a SHOW TECH from the switch. If you are not familiar with a Nexus 7000, let me tell you – the show tech from this box can be over 100 Megs! So, when they asked for that I was like – are you sure? really really sure? I just have to say – thank you DropBox and public folders! I used DropBox place the file and then send the support the public link. Not sure that most e-mail systems would appreciate that large of a file!
So, if the Show Tech Support is so big, how do you get the information that support needs? Well, instead of running a complete show tech, you run it for the sections you need!
Here is a list of what you can append to a Show Tech-Support command: (show tech-support option)
N7K1-CoreSwitch1# sh tech-support ?

>               Redirect it to a file
»              Redirect it to a file in append mode
aaa             Display aaa information
aclmgr          ACL commands
adjmgr          Display Adjmgr information
arp             Display ARP information
ascii-cfg       Show ascii-cfg information for technical support personnel
assoc_mgr       Gather detailed information for assoc_mgr troubleshooting
bgp             Display BGP status and configuration
bootvar         Gather detailed information for bootvar troubleshooting
brief           Display the switch summary
callhome        Callhome troubleshooting information
cdp             Gather information for CDP trouble shooting
cert-enroll     Display certificates information
cfs             Gather detailed information for cfs troubleshooting
cli             Gather information for parser troubleshooting
clis            Gather information for CLI Server troubleshooting
commands        Show commands executed as part of show tech-support commands
details         Gather detailed information for troubleshooting
dhcp            Gather detailed information for dhcp troubleshooting
eem             Show EEM tech-support information
eigrp           Display EIGRP status and configuration
eltm            Eltm debug info
ethpm           Gather detailed information for ETHPM troubleshooting
forwarding      Forwarding debug information
ha              Gather detailed information for HA troubleshooting
hsrp            Show hsrp tech-support information
icmpv6          Display Icmpv6 information
im              Gather detailed information for IM troubleshooting
include-time    Gather tech-support and capture time taken to execute each
command
interface-vlan Gather detailed information for interface-vlan
troubleshooting
internal        Gather internal info for troubleshooting
ip              Display IP information
ipqos           IP QoS Manager
ipv4            Display IP information
ipv6            Display IPV6 information
l2fm            L2fm debug info
l2pt            Gather information for l2pt troubleshooting
l3vm            Display VRF information
lacp            Gather detailed information for LACP component
license         Display licensing information
logging         Show information on logging for technical support staff
m2fib           Gather detailed information for M2FIB troubleshooting
m2rib           Gather detailed information for M2RIB troubleshooting
mfwd            Display MCASTFWD status and configuration
module          Gather info related to a module
monitor         Gather detailed information for monitor troubleshooting
multicast       Display V4 Multicast information
netflow         Show NetFlow tech-support information
netstack        Gather information for NETSTACK troubleshooting
npacl           Display npacl information
pixm            Gather detailed information for PIXM troubleshooting
pixmc           PIXMC Information
pktmgr          Display Packet Manager information
port-channel    Gather detailed information for port channel troubleshooting
port-profile    Gather information for troubleshooting port-profiles
port-security   Port security related command
Ok, color code again:
Red – Router Output
Blue – Commands
Green – Notes
Traditionally when we have done show tech-support, we have always done terminal length to 0, set the capture buffer on our terminal application, and then executed the command – like this:
First we set the length to 0
FryGuyR1#terminal length 0
Then we configure our terminal to capture the data

Static ARP entries on NX-OS

Fryguy — Thu, 28 Oct 2010 13:55:10 +0000

Oh the joys of Microsoft Network Load Balancing (NLB). One of the wonderful ways that it is usually configured is using a Multicast MAC address utilizing a Unicast IP address. Needless to say, most network devices do not like that and thus have problems when devices outside the local LAN attempt to connect to the NLB address. In order to work around this problem you need to configure a static ARP entry on the gateway so that the devices know how to get to the server.
On IOS, this is not so hard as you configure the a static ARP entry (arp 10.1.1.99 0300.5e11.1111). That command there on the gateway will usually get things working. You may also need to define where that MAC address lives – and the command to do that would be mac-address-table static 0300.5e11.1111 vlan 200 interface fa2/3 fa2/4 This information was obtained from a Cisco document can be found here if you need more information – http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml
Now, on the NX-OS it is a little different as you need to configure the static ARP entry under the VLAN interface in order for it to work:
interface Vlan100
no shutdown
description [—-[ Standard VM VLAN ]—-]
no ip redirects
ip address 10.1.1.2/24
ip arp 10.1.1.99 0300.5e11.1111
N7K1# sh ip arp | inc 1111
10.1.1.99 – 0300.5e11.1111 Vlan100

What is the difference between the Nexus 7010 and 7018?

Fryguy — Thu, 16 Sep 2010 00:21:14 +0000

I was chatting with one of my old co-workers the other day and he mentioned that most people (Exec Level) do not always understand the difference in the Nexus 7010 and 7018 switches. So, based on that chat conversation I figured I would just post up some information on the similarities and the differences between the two.
First difference, size and weight. The Nexus 7010 is 36.5″ (92.7 cm) tall and can weight up to 516 lb (235 kg) whereas the Nexus 7018 is 43.5″ tall (110.5 cm) and can weigh up to 696 lb (316 kg) fully loaded. That equates to the Nexus 7010 being about 21RU and the 7018 25RU. Both are also the full depth of a standard 4-post rack – so you need to be aware of quite a bit when designing the space layout around them. Below is an image from Cisco’s web site ( http://www.cisco.com/en/US/products/ps9402/index.html ) that shows the 7018 on the left and the 7010 on the right.

The next difference in them is the slot capacity and performance. The Nexus 7010 is a 10-slot chassis but slots 5 and 6 are reserved for Supervisors, so the real capacity is 8 line cards. In the 7018 you have an 18 slot chassis and slots 9 and 10 are reserved for supervisors, thus providing 16 available slots for line cards. With the currently available supervisors and cards, the Nexus 7010 can handle 480 Mpps and the 7018 can support twice that, 960 Mpps. In both the Nexus 7010 and 7018 chassis you can have up to 5 fabric modules installed, but there is a difference between the 7010 and the 7018 the cards. In the 7010, the cards are in a vertical mounting whereas in the 7018 they are in a horizontal mount. This is one of the only cards that I know which is unique to each chassis. All the other line cards (supervisors, 1g, 10g, etc) are interchangeable between the two.
When you look at the Nexus 7010 and the line cards, in order for the fabric card to “touch” all the line cards, it would have to be mounted horizontally. In the 7018, the line cards are horizontal – so the fabric card needs to be vertical. It is just how the backplane connections work in these chassis’s. At least, that is my understanding of why they are different.
The Nexus 7018 (N7k-C7018-FAB-1) is pictured on the left and the 7010 Fabric module (N7K-C7010-FAB-1) is on the right.

Like the fabric cards that are found on the back, the fan trays that are found on the back are unique to each switch. The Nexus 7018 fan tray (N7K-C7018-FAN) is larger and contains more fans as the airflow on that chassis is side-to-side, but the 7010 fan tray (N7K-C7010-FAN) is a smaller as the chassis airflow is front to back. The 7018 fan tray is picture below on the left and the 7010 fan tray is on the right. When it comes to the Nexus 7018 airflow, Panduit actually makes a special rack just for this switch to accommodate the airflow in a cold aisle/hot aisle data center. More information can be found on Panduit’s website at http://www.panduit.com/groups/MPM-BR/documents/InstallationInstruction/CMSCONT_035895.pdf

The final difference that I am aware of is with the power supplies. Today there are three power supplies for the Nexus 7000 switches, two that are AC powered and one that is DC powered. There is a 6000 kW AC (N7K-AC-6.0KW), a 7500 kW AC (N7k-AC-7.5KW), and finally a 6000 kW DC (N7K-DC-6.0KW) power supply. In the Nexus 7010 you can have up to three power supplies installed and in the 7018 you can have up to four installed. With the 6000 kW power supply, the cable connected is a standard C19 to country specific plug type. On the 7500 kW one, the cable is hard-wired to the power supply and must be ordered with the correct plug type. When it comes to the DC power supply, there is also a DC Power Interface Unit that you will need in order to provide the DC power to the power supply.
Pictures of the power supplies are below with the 6000 kW on the left, the 7.5KW on the right and the DC one below.

LACP Configuration and multi-chassis Etherchannel on Nexus 7000 with vPC, Part 2 of 2

Fryguy — Mon, 13 Sep 2010 23:47:25 +0000

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 2

Fryguy — Mon, 13 Sep 2010 15:21:21 +0000

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.