CCIE GNS3 Topology

This post is dedicated to the best practise for setting up CCIE R&S lab and I want to show you how to set up a practise rack to where you will never ever have to switch a single cable again , no matter what your lab topology looks like , the set up that does it all !
The only difference between this one and the previous topology is that I have changed the symbols so it’s easier to differentiate devices on screen but except for that it is all the same and no other changes have been made. Further down I have added initial configs files for CBT Nuggets CCIE series, INE , IP Expert and Narbik (Super Lab)
CCIE R&S topology I have built and been using on GNS3 for the CCIE journey.
So far I have seen and used topologies with a GNS3 built in Frame Relay switch plus 6 routers (INE spec) so I’ve decided to create one with CLI configurable Frame Switch and connect all devices in a way so that you are able to create any topology without the need of changing the cabling etc … The reason for 17 devices being used is because some of the CCIE preparation series like IP Expert, CCIE Service Provider see image   have topologies with more than 6 routers which is expectable from Cisco in the current v4 Lab exam but the idea is so we can practise not only INE lab scenarios with 6 routers but also IP Expert lab scenarios where Quadruple CCIE Scott Morris uses topology with 9 routers instead and of course for us to become more familiar with the actual frame relay switch configuration.
In case you having some issues with connectivity or the gns3 is crashing just after you start the topology, change the (127.0.0.1 with localhost) or vice versa in the .net file.
Please remember, that you can’t run most of layer 2 technologies command, since GNS3 (and all emulators) just do the software, where switches are mostly ASIC programmed to run the features.
This topology is customizable which means that with a little tweaking (vlans, ip addreses, frame switch config etc…) you will be able to practise any R&S scenario you can possibly find out there.
See intial configs below – INE lab specification VOL1
Frame_switch   BB1   BB2   BB3   R1   R2   R3   R4   R5   R6   SW1   SW2   SW3   SW4

See intial configs below – IP Expert lab specification VOL1
FRAME_SWITCH   BB1   BB2   BB3   SW1   SW2   SW3   SW4   R1   R2   R4   R5   R6   R7   R8   R9

See intial configs below – CBT Nuggets lab specification (CCIE R&S LAB SERIES)
CBT_BB1   FRAME_SWITCH_CBT   CBT_SW1   CBT_SW2   CBT_SW3   CBT_SW4
CBT_R1  CBT_R2   CBT_R3   CBT_R4   CBT_R5   CBT_R6   CBT_R7

See intial configs below – Narbik Super Lab specification (CCIE R&S LAB SERIES)
SW1 – SW2 – SW3 – SW4
vlan data
vlan 111
vlan 112
vlan 113
vlan 3
apply
exit

Read More

Filtering routers from a neighbor using prefix-lists

The this post I’m going to filter routes allow only those from R1 specifically with prefix length between 17 – 19 long into the routing table of R3
The routing table on R3 looks like this at the moment:
17.0.0.0/19 is subnetted, 2 subnets
R       17.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
R       17.2.0.0 [120/1] via 10.1.1.2, 00:00:02, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
R       1.1.1.1 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/0
12.0.0.0/18 is subnetted, 2 subnets
R       12.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
R       12.2.0.0 [120/1] via 10.1.1.2, 00:00:02, FastEthernet0/0
13.0.0.0/17 is subnetted, 2 subnets
R       13.0.0.0 [120/1] via 10.1.1.1, 00:00:08, FastEthernet0/0
R       13.2.0.0 [120/1] via 10.1.1.2, 00:00:03, FastEthernet0/0
14.0.0.0/9 is subnetted, 2 subnets
R       14.0.0.0 [120/1] via 10.1.1.1, 00:00:08, FastEthernet0/0
R       14.128.0.0 [120/1] via 10.1.1.2, 00:00:03, FastEthernet0/0
Configuration steps
1) Configure a prefix-list to filter routes

R3(config)#ip prefix-list R1-Filter permit 0.0.0.0/0 ge 17 le 19

2) Configure a prefix-list that identifies the routing source

R3(config)#ip prefix-list R1 seq 5 permit 10.1.1.1/32    

3) Apply the distribute-list prefix

R3(config)#router rip
R3(config-router)#distribute-list prefix R1-Filter gateway R1 in f0/0

The result is just those routes in the perfix-list are allowed and only from R1 (10.1.1.1)

R3(config-router)#do sh ip ro rip
17.0.0.0/19 is subnetted, 1 subnets
R       17.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
12.0.0.0/18 is subnetted, 1 subnets
R       12.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
13.0.0.0/17 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0

Read More

IPv6 Routing Protocol Redistribution

Though the transition period from IPv4 to IPv6 is going to last for a long time in which both protocols will coexist, we shouldn’t forget that the final goal of IPv6 is to completely replace IPv4.
The best way to gain more experience with the new intricacies and challenges of IPv6 is to test IPv6-based services in the presence of IPv4 as well in a pure IPv6 environment.
The purpose of this lab is to test redistribution between IPv6 routing protocols in an exclusively IPv6 environment.

So I am following exactly the same scenario as the previous post about IPv4 redistribution and I will point out some particularities related to IPv6.
I will start by the problematic design of redistribution from one routing domain into another with lower (better) administrative distance.
If you are not familiar with routing redistribution I strongly recommend you to take a look at the previous post.

Redistribution from one routing domain into another with lower (better) administrative distance:

All the following topologies are subject to the same concept:

As an example, I picked up the case where the source routing domain is EIGRP (internal prefix AD =90 and external prefix AD = 170) and the destination domain is OSPF with a better AD of 110.
Picture 1: Lab High level design

Picture 2: Low level design

Lab content:

1- Redistribution
2- Test connectivity from the BR R1
3- Solutions to overcome suboptimal paths
   3.1- Control paths by controlling the redistribution at the border routers
   3.2- Change the AD per-prefixes
   3.3- Filter prefixes from IGPs into the routing table using inbound distribute-list
   3.4- Prefix summarization
4- Troubleshooting notes5- Conclusion

1- Redistribution

- Redistribute 2001:DB8:123:3333::/64 (external domain/connected) into EIGRP at R3

The network 2001:DB8:123:3333::/64 can be administred with a different IGP than EIGRP or just a directly connected network (a loopback interface in our case).

Because EIGRP differentiates between internal and external prefixes by assigning different Administrative Distances, the prefix 2001:DB8:123:3333::/64 become (D EX) with AD=170.

ipv6 router eigrp 123 router-id 3.3.3.33 no shutdown redistribute ospf 123 metric 1500 1 100 1 1500 route-map to-eigrp include-connected ! ipv6 prefix-list ospf-pfx seq 5 permit 2001:DB8:123:3333::/64 ! ! route-map to-eigrp permit 10 match ipv6 address prefix-list ospf-pfx set tag 3333

Read More

IPv6 multicast over IPv6 IPSec VTI

IPv4 IPSec doesn’t support multicast, we need to use GRE (unicast) to encapsulate multicast traffic and encrypt it. As a consequence, more complication and an additional level of routing, so less performance.

One of the advantages of IPv6 is the support of IPSec authentication and encryption (AH, ESP) right in the extension headers, which makes it natively support IPv6 multicast.
In this lab we will be using IPv6 IPSec site-to-site protection using VTI to natively support IPv6 multicast.

The configuration involves three topics: IPv6 routing, IPv6 IPSec and IPv6 multicast. Each process is built on the top the previous one, so before touching IPsec, make sure you have local connectivity for each segment of the network and complete reachability through IPv6 routing.
Next step, you can move to IPv6 IPSec and change routing configuration accordingly (through VTI).
IPv6 multicast relies on a solid foundation of unicast reachability, so once you have routes exchanged between the two sides through the secure connection you can start configuring IPv6 multicast (BSR, RP, client and server simulation).

Picture1: Lab topology

Lab outline

• Routing
  • OSPFv3
  • EIGRP for IPv6
• IPv6 IPSec
  • Using IPv6 IPSec VTI
  • Using OSPFv3 IPSec security feature
• IPv6 Multicast
  • IPv6 PIM BSR
• Offline lab
• Troubleshooting cases
• Performance testing

Routing

Note: IPv6 Routing relies on link-local addresses, so for troubleshooting purpose, link-local IPs are configured to be similar to their respective global addresses, so they are easily recognisable. This will be of a tremendous help during troubleshooting. Otherwise you will find yourself trying to decode the matrix : )

OSPFv3

Needs an interface configured with IPv4 address for Router-id
OSPFv3 offloads security to IPv6 native IPv6, so you can secure OSPFv3 communications on purpose: per- interface or per-area basis.

Read More

Sending with one key and accepting another

With RIP text based authentication you can send with one key and accept another. The key sent will be the lower key in the key chain and the higher one is used to match the other sides sent key.
R4(config)#key chain RIP-AUTH
R4(config-keychain)#key 1
R4(config-keychain-key)#key-string cisco
R4(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 1993 infinite
R4(config-keychain-key)#key 2
R4(config-keychain-key)#key-string ccie
R4(config-keychain-key)#send-lifetime 00:00:00 Jan 1 1993 infinite
R4(config-keychain-key)#
R4(config-keychain-key)#interface Serial0/1
R4(config-if)# ip rip authentication mode text
R4(config-if)# ip rip authentication key-chain RIP-AUTH
R5(config)#key chain RIP-AUTH
R5(config-keychain)#key 1
R5(config-keychain-key)#key-string ccie
R5(config-keychain-key)#send-lifetime 00:00:00 1 jan 1993 infinite
R5(config-keychain-key)#key 2
R5(config-keychain-key)#key-string cisco
R5(config-keychain-key)#accept-lifetime 00:00:00 1 jan 1993 infinite
R5(config-keychain-key)#ex
R5(config-keychain)#int s0/1
R5(config-if)#ip rip authentication key-chain RIP-AUTH
With this configuration R4 will send “cisco” and R5 “ccie”. Also Note: Text authentication is the default option.

Read More

EIGRP Unequal LoadBalancing and Path Control

Hi All,
I have been Cisco reading and doing labs all weekend and still have about 6hrs before I decide it’s time to stop!
This afternoon I have found this video http://www.youtube.com/watch?v=ErUzMl0a-E8&feature=relmfu made by Mohammad Said and I must tell you that this is the best resource I have ever been able to find which explains exactly how EIGRP calculates its metric and decides which way to route packets.  I have seen and practised many EIGRP labs but without any doubt this one is my favourite !
For the past 3 hrs I have been drawing and carefully looking into EIGRP metric calculation , successors , feasible successors , advertise distance and feasible distance based on Mohammad’s video and finally it’s all clear !
After you’ve watched and understood Mohammad’s video , there is no way Cisco can trick you on your R&S lab exam , well they still can and probably will but not with EIGRP metrics
GNS3 net file : EIGRP Unequal LoadBalancing and Path Control
Basic configs : EIGRPLOADBALAN_CONFIG

Read More