SP Study Material – Routing Bits

So most if not all RS candidates have at least heard if not used Ruhann’s routing bits handbook.

I used it whilst studying during R&S and am so happy that Ruhann has released a companion version for the SP track.

Up until now he has hinted at its release but nothing has come out until today, if you head over to his blog here you can download a free sample of the upcoming SP handbook for free.

Although it is geared towards candidates that are going for their CCIE I also find it useful to be able to grab a subject and look up config examples, one handy feature as well is that he lists the exact DocCD location of every feature as well so if you ever need to know where SPD or CBAC is located you can just check the relevant section on the handbook.

Posted in Uncategorized | 1 Reply

Cisco Nexus 7K – Secret decoder ring

Back when I first starting using the 7K’s I thought the naming of the line cards followed the same logical naming scheme of all other Cisco equipment (by that I mean there is no logic to it at all!).

It was when I was watching one of this years Cisco Live presentations on the 7K architecture that it all became a lot clearer.

So without further ado here is how to use the magical Nexus 7K linecard decoder ring:

N7K-M224XP-23L

N7K - Signifies that the card is for a Nexus 7K
M2  - Show that this is an M2 generation / type card
24  - The number of ports on the card
X   - That each of the ports is capable of running at 10Gbps
P   - That each of the ports uses the SFP+ type of transceiver
2   - That the module uses / requires FAB2 modules
3   - The number of fabric modules needed to run at full capacity
L   - That the card is licensed to hold a L(arge) routing table (licensed)

CCIE Update and plaque

So this week my CCIE package arrived along with this little beauty.

CCIE Plaque

I had no idea these things weighed so much, mind you I suppose for $1500 its what you should expect 😛

I’m currently on with studying for the SP, all good so far as a lot of it is very familiar due to my day job but there are still a fair few new things to learn before I make an attempt.

Perhaps try and make a lab attempt by the end of the year? I guess we will wait and see.

Posted in Uncategorized | 1 Reply

Service Provider – Half-Duplex VPN’s

Cisco Half Duplex VRF’s (HD VRF’s)

The other day whilst reading up on some SP topics I came across a rarely used function available on some higher end Cisco models called half duplex VRF’s (or HD VRF’s in some places).

I know it is quite a common thing to see in service provider topologies where you have a radius / virtual-template driven platform such as a DSL LNS etc but up until now I wasn’t aware that it can also be used on other platforms on regular (non virtual) interfaces.

For the demo topology I am going to use a faily simple network of three 7200’s in GNS3. According to the Cisco documentation here this feature has been around since 12.4(20)T or 12.2(33)SRC for the SR train.

In the topolgy I am using R1 and R2 to emulate customer sites which will be a member of the same VRF on R3 which will play the role of our PE.

HD VRF Topology

Although I am not going to actually use MP-BGP to create a VPNv4 topology you can still see the hub-and-spoke effect on the two devices.

One reason that this feature is used is that in a traditional MPLS VPN topology if you wanted a hub and spoke VPN you would have to have a seperate VRF on a particular PE for every ‘spoke’ site which although it may not be much of a problem if you only have a couple, imagine if you have 1000 spoke sites connected, the administrative work involved in create a new spoke VRF every time would become tiresome VERY quickly!

With HD VRF’s you have two different types of VRF in which you place an interface, you have the upstream which is typically where routes from your hub site will live (possibly just a default route) and you have the downstream which is where all hub routes are placed to be exported.

Due to the fact that only the upstream VRF is used for forwarding on the PE it means that although all the sites routes are in one place in the downstream VRF they are unable to forward traffic between sites (as seen below).

It should be noted that in the example I will be using the more modern VRF implementation that supports multiple address families, I will do another post on this later this week.

### Here is the basic config from R3 which defines both the upstream and the downstream VRF's, as you can see nothing special here.

vrf definition DOWNSTREAM
 rd 100:2
 route-target export 100:2
 route-target import 100:2
 !
 address-family ipv4
 exit-address-family
!
!
vrf definition UPSTREAM
 rd 100:1
 route-target export 100:1
 route-target import 100:1
 !
 address-family ipv4
 exit-address-family

We then define the usual addressing on the spokes/CE’s

## R1
interface FastEthernet0/0
 ip address 10.1.3.1 255.255.255.0
 duplex auto
 speed auto
!
ip route 0.0.0.0 0.0.0.0 10.1.3.3

## R2
interface FastEthernet0/0
 ip address 10.2.3.2 255.255.255.0
 duplex auto
 speed auto
!
ip route 0.0.0.0 0.0.0.0 10.2.3.3

## The static routes here are used for reachability to the loopback on R3

So that we have something to test to we will create a Loopback on R3 which would usually (if we were using more devices) live up at the hub site but for demonstration it is going to sit in the DOWNSTREAM VRF (but not using HD VRF’s).

interface Loopback0
 vrf forwarding DOWNSTREAM
 ip address 3.3.3.3 255.255.255.255
end

The configuration on the spoke facing interfaces is where we start to see the HD VRF’s used:

interface FastEthernet0/0
 vrf forwarding UPSTREAM downstream DOWNSTREAM
 ip address 10.1.3.3 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 vrf forwarding UPSTREAM downstream DOWNSTREAM
 ip address 10.2.3.3 255.255.255.0
 duplex auto
 speed auto

Now if the config is all correct we should be able to ping from spoke->hub but not from spoke->spoke….

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/17/36 ms
R1#
R1#
R1#ping 10.2.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.3.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

So there we go, with just two VRF’s on a PE device you can create a complete hub & spoke topology without allowing traffic to pass between spoke sites.