Well, today is the day – first day for CCIE SP Class.

Well, today is the day. I am heading out to Columbus, OH to attend a CCIE SP bootcamp class hosted by IPExpert. Looking forward to this as I know there are some things I need to learn.
I am not taking the CCIE SP test just to get “another CCIE” but to actually learn more about the technology and how I can apply it to the place I work at.

Been a little quiet lately, trying to brush up on things and get ready for class next week.  I have a CCIE Service Provider bootcamp scheduled with IPExpert on 11/8-12 in Columbus, OH. Really looking forward to the class, especially since Marko (@icemarkon on Twitter) is one of the teachers.
See what happens!  I will post my thoughts and reflections once the class is complete.
 
 
 

I was trying to figure out how to redistribute routes between some VRFs for a project that I am working on.  I won’t get into details of the project or specifics, but ultimately the goal was to be able to leak routes between the VRFs so that we can gain access to the management ports on some devices.  Since VRFs are separate routing tables that co-exist within the same router and cannot see each other, getting communication between them can be difficult at best.
Using some the features of PE routers, you can overcome this limitation by using BGP to redistribute between them.
Below is the diagram that we will be using for this config.  What we will do is configure R3 to redistribute routes between VRF RED and VRF BLUE to enable connectivity.

R7 and R8 are just basic configs like you would do on an ordinary router
Basic R7 Configuration:
!
interface Loopback0
ip address 10.1.7.7 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.37.7 255.255.255.0
!
router eigrp 100
network 10.0.0.0
no auto-summary
!
Basic R8 Configuration:
!
interface Loopback0
ip address 10.1.8.8 255.255.255.0
!
interface FastEthernet0/1
ip address 10.1.38.8 255.255.255.0
!
router eigrp 200
network 10.0.0.0
no auto-summary
!
Now when it comes to R3, we need to be a little creative.  Here we will place the interfaces in the appropriate VRFs and configure EIGRP and BGP.
Note:  Fa0/0 will be in VRF BLUE and Fa0/1 will be in VRF RED
R3 Configuration items:
We will define VRF RED and BLUE here and also assign it an RD (route distinguisher) to ID these routes
Link – http://en.wikipedia.org/wiki/Route_distinguisher
VRF BLUE will have a RD of 1:1 and VRF RED will have a RD of 1:2.
The command route-target will allow us to import and export based on the RD assigned to a given network.
ip vrf BLUE
rd 1:1
route-target export 1:1
route-target import 1:1
route-target import 1:2
ip vrf RED
rd 1:2
route-target export 1:2
route-target import 1:2
route-target import 1:1
Next step is to configure the interfaces in the appropriate VRFs
interface FastEthernet0/0
ip vrf forwarding BLUE
ip address 10.1.37.3 255.255.255.0
__
interface FastEthernet0/1
ip vrf forwarding RED
ip address 10.1.38.3 255.255.255.0
Since this router will be running EIGRP under different VRFs, we will need to great a top-level AS and then get into the address-family commands to configure the VRF EIGRP AS
router eigrp 1
no auto-summary
!
address-family ipv4 vrf RED ! <- This will allow us to configure EIGRP for VRF RED
__network 10.1.38.3 0.0.0.0
no auto-summary
autonomous-system 200 !<- This is the EIGRP AS number for VRF RED
exit-address-family
!
address-family ipv4 vrf BLUE !<- This will allow us to configure EIGRP for VRF BLUE
__network 10.1.37.3 0.0.0.0
no auto-summary
autonomous-system 100 !<- This is the EIGRP AS number for VRF BLUE
exit-address-family
!
The next step is going to be to configure a lone BGP session where we can redistribute and place the routes in a VPNV4 environment.  Basically we are creating a lone SP network where VPNV4 routes are “exchanged”.  You do not need a neighbor for this, just a BGP session configured and IPV4 VRF families.
router bgp 1
no synchronization
bgp log-neighbor-changes
no auto-summary
!
address-family ipv4 vrf RED !<- Here we will configure BGP for VRF RED and redistribute routes learned from EIGRP in
redistribute eigrp 200
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf BLUE !<-  Here we configure BGP for VRF BLUE and then redistribute routes learned from EIGRP in
redistribute connected
redistribute eigrp 100
no auto-summary
no synchronization
exit-address-family
!
Lastly we will need to configure EIGRP to redistribute BGP learned routes:
router eigrp 1
!
address-family ipv4 vrf VRF2
redistribute bgp 1 metric 1 1 1 1 1500
exit-address-family
!
address-family ipv4 vrf VRF1
redistribute bgp 1 metric 1 1 1 1 1500
exit-address-family
Once you have done that, R7 can now ping R8

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

Well, just wanted to post up what has been g0ing on and the lack of updates.
On Monday (10/4) I sat the CCIE SP lab in RTP  – results I did not pass.  I was not ready, close but need to fill in some gaps. Based on that attempt, I am going to spend some quality time in a training class next month at IPExpert.  Hopefully Marco can fill my head with the knowledge that I need 🙂
Add to that we are going on our yearly trek to Disney on Saturday, things have been busy.
 
I have not abandoned this blog, nowhere near that – just been a little busier with life lately.
 
Jeff

I am still here, just been a little busy for the past few days.  Took some time off from work to work on the house, that is all.
I am planning to blog some things on 10Gbps cabling and associated GBICs soon as well as some more Nexus stuff in the coming month.  If there is anything that you would like me to blog about, please do not hesitate to suggest – I am here to help you, I have the opportunity to learn more as well.
Thanks,
Jeff

Argh, time to get to studying again. Now that the Nexus installation is behind me – need to get my butt in gear (Thanks Carl) and get studying again. So, here we go again!
Perhaps I will blog some SP stuff soon, probably would be good to start that soon.

Saw a quote today that I wanted to share. Not sure who said it, but it is one to remember.
“Life’s not about the breaths we take, but the moments that take our breath away.”

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.