This is a continuation of my previous work. The original topology was created last December. If you follow my posts, you’ll know that shortly after then I paused my studies for ROUTE and passed the CCDA, CCNA Voice and SWITCH exams. During the past eight months since that time, I feel like my level of networking knowledge has increased dramatically. Nearly two years ago, the thought of achieving the CCNA seemed like a distant but attainable goal. As I write this, on the verge of achieving the CCNP certification, that is exactly how I feel about the CCIE certification.
Originally, I looked over my notes and wrote down the topics I felt were essential to the ROUTE exam, then designed a topology on paper based on those topics. I then assembled the topology in GNS3 and came up with a preliminary IPv4 addressing scheme. However, at that time, I was stumped with the prospect of coming up with an IPv6 address scheme, and the project essentially halted last December.
I always knew I would return to the project, and here are the results.
The initial creation was performed after watching some training videos, reading the official cert guide, and going through some of the official lab manual. This time, I did all of that, read the foundation learning guide, went through the entire lab manual, and dug deeper into the topics, including reading various RFCs. In fact, by taking the time to read RFC4193, I discovered that private IPv6 addressing is so simple, it was actually no problem to come up with an IPv6 addressing scheme for the project once I was equipped with the proper knowledge. In fact, I feel I’ve become comfortable enough with IPv6 addresses that it makes me wonder why in 2013 we aren’t further along with the global migration to IPv6 as it provides so much more flexibility with addressing than IPv4 does. Not just in terms of raw address space, of course, but in the layout of subnets.
In particular with regards to this project, I generated a “global private” IPv6 prefix and then mapped the IPv6 subnet to the prefix. So, for example, the IPv4 address of the g2/0 interface on the ISP11 router is 10.30.14.1/30. The IPv6 address is FDA7:2ED4:506D:3014::1/64. The IPv6 address is composed of the unique local designation FD, followed by the pseudo-randomly-generated unique local prefix A72ED4506D (equaling FD17:2ED4:506D::/48). In my private IPv4 address scheme, I used the 10.0.0.0 major network for the entire topology and changed the middle two octets based on the location of the link. The second two octets map perfectly to the IPv6 subnet. For the host portion of the IPv6 address, I could have used auto-generated EUI-64 addresses, but instead I used ::1’s and ::2’s for better readability, since every IPv6 link in the topology is statically assigned.
I also modified the topology from the original by removing the redundant squares from the ISP1 and ISP2 regions, opting instead of have redundant triangles, as I posted about before. Though there is still the section between the Border and ISP routers that is a physical redundant square, once configured it is a logical triangle due to the use of different routing protocols.
As I was writing the implementation for the OSPF section, I discovered a couple of large mistakes in the topology. I was surprised that I had made such large mistakes in the first place. In the original topology, there was a section of the OSPF side that was to be designated an OSPF stub area. However, I didn’t take into account that all routers in the OSPF area must agree on the stub flag. My original design was in error because I had created OSPF area 2 directly attached to area 1 in order to demonstrate the OSPF virtual-link capability. However, I did not intend for the attached OA1 router to be a stub. Though it is true that I could have created a separate OSPF stub area attached to OA1 with a virtual-link to area 0, I already had OA2 for the purpose of demonstrating virtual links and I wanted to keep the stub area concept separate in the topology. If I were using physical routers, I would have done that in order to keep the required number of routers down, but in the virtual world you don’t have to do that.
The other major design flaw, in both the EIGRP and OSPF domains, was the IPv4 addressing scheme with regards to summarization. I knew from the beginning that the ROUTE topics covered summarization, but I initially forgot to take into account summarized routes accidentally overlapping with routes that I did not wish to summarize. So I revised the IPv4 address scheme in certain sections of the OSPF and EIGRP domains.
I initially designed the topology so that I could have a section on configuring iBGP route reflectors and confederations. Upon review, I realized that that is outside the scope of the ROUTE exam. I remember when I first started studying for ROUTE last year, I was having a difficult time with many of the concepts of BGP just because it was new to me and I had never worked with it before. So in attempt to try to learn more, I viewed some training videos from the former Cisco BGP course. In that course there is discussion of both route reflectors and confederations, so the ideas snuck into my original design. Since this design is based around the ROUTE exam, I decided to remove those two topics. Cisco has an excellent, short configuration guide available, however.
In completing the project for the purpose of demonstrating various ROUTE topics, I created various implementation steps. Some of the steps are purposefully ambiguous as there are multiple ways to perform them while still being within the realm of the ROUTE topics. Also, there are a few different corner cases that are covered in ROUTE, but I decided not to implement them in my topology. There’s a few IPv6 topics and most notably IP SLA that I didn’t cover. Although each of these tasks could be implemented in individual labs, my goal for this project was to create a comprehensive lab where I could fit as many of the major topics as possible into a single internetwork simultaneously. In doing that, and not yet being an expert in network design (but I’ll get there!), it was difficult to truly fit in everything without going through several major redesigns (as it is, I went through a few different fairly major revisions from my original creation last year). I’m not at all saying that it can’t be done, I just don’t have the time to do it currently.
As mentioned in a previous post, this project reached a point where it had the potential of pushing my ROUTE exam date back. In coming up with the implementation steps, I had to use a lot of skills that are covered on the TSHOOT exam to discover and correct mistakes in both the topology as well as my implementation questions. In the end, I revised the topology a couple of times, and my implementation steps several times. In fact, I ended up needing to remove a couple more topics due to mistakes in the design that would take too much time to fix without a proper redesign. For example, the “IPv6 Branch” section is not even used in the implementation.
I also ran into some limits with GNS3, especially after all of the routing protocols were implemented. This project was designed on a Macbook Pro with an i7 CPU and 16 GB of RAM. When I first load the project and turn on all the virtual routers with only IP addresses configured (no actual implementation steps followed yet), the CPU stays around 30%. With all of the steps implemented, the CPU stays at around 85%. There are definitely some optimizations that could be made, such as making sure to run only a single routing platform such as the 3725, but that would require more time to redesign the topology.
I learned a lot by creating this project, which luckily was the end goal, regardless of the actual success of the design and implementation. Some notable things I encountered were the results of different methods of default routing for the different routing protocols, iBGP implementation issues such as update-source and next-hop-self, eBGP advertisement issues with regards to routes actually being in the routing table. There was also one item in particular that I don’t remember being in any of the study material, and this may be platform/IOS-version dependent, but when I configured EIGRP routing for IPv6, despite enabling it on the individual links, I had to go into IPv6 EIGRP router configuration mode and issue no shutdown before it actually worked. I thought that was rather strange, as it doesn’t work that way for IPv4.
So in the end, these were the topics that I felt were important to the ROUTE exam and led to the creation of the topology and implementation steps:
• Passive Interface
• Manual Unicast Neighbor
• P2MP Split Horizon
• P2MP Bandwidth Control
• EIGRP Stub
• Filter Routes via ACL, Distribute List,vRoute Map
• Default Route Injection
• Passive Interface
• Frame Relay Operation
• LSA Type 3 Filtering via ACL,vDistribute List, Route Map
• Default Route
• Stub area
• Virtual Link
• eBGP connectivity
• Loopback / Update-Source / ebgp-multihop
• Route injection via network commandvand redistribution
• Route aggregation
• iBGP connectivity, Route reflector, confederation
• Route filtering via distribute-list, prefix-list, filter-list, route-map
• OSPF / EIGRP / RIP
• Route filtering
• Route tagging
Path Control / IP SLA:
• Policy routing
• IP SLA object tracking
• Influence outbound BGP
• Influence inbound BGP
• Floating Static Routes
• DHCP Server
• IPsec VPN
• IPv6 Addressing
• IPv6 Routing
• RIPng / OSPFv3 / EIGRPv6
• Manual Tunnel
• 6to4 Tunnel
• ISATAP Tunnel
The final IPv4 and IPv6 addressing scheme is:
IPv4 Address Scheme (based on RFC1918):
Enterprise OSPF Domain: 10.10.x.x
Enterprise EIGRP Domain: 10.20.x.x
Enterprise Border Routers:
Redistribution Domain: 10.50.x.x
Additional Loopbacks (Router-ID / Possible OOB Management Network):
|eBGP Transit Domain||lo60||10.60.254.x|
|eBGP ISP1 Non-Transit||lo70||10.70.254.x|
|eBGP ISP2 Non-Transit||lo80||10.80.254.x|
IPv6 Address Scheme (Based on RFC4193):
And finally, here are the implementation challenge steps I came up with. I was not able to cover all of the topics that I listed before, but I believe at least 85% of them are covered in one way or another.
- Configure the appropriate frame-relay mappings on EStub, ES1, ES2 and ES3.
- Configure EIGRP for AS1 on all links on ES1, ES2, ES3, EStub and ESummary. Configure EIGRP AS1 for Border1 and Border2 only on the specific links connecting to the EIGRP domain (including the link between Border1 and Border2).
- Configure MD5 authentication on the links between ESummary, Border1 and Border2 in the EIGRP domain.
- Manually configure the neighborship between ESummary and EStub.
- Configure ESummary to advertise the link to EIPv6 without forming an EIGRP neighborship.
- Configure ES1, ES2 and ES3 as EIGRP stub routers.
- On ESummary, advertise a summary route encompassing 10.20.0.0 – 10.20.63.255 toward both Border1 and Border2.
- Prevent ESummary from receiving the OS3 LAN prefix 10.10.70.0/24 via distribute-list
- Manually configure the bandwidth of the ES1, ES2 and ES3 serial links to 128kbps. Manually configure the EStub serial link to 384kbps and limit the EIGRP bandwidth to 25%.
- Disable split-horizon on the serial interface of EStub.
- Create static default routes to ISP11 and ISP21 on Border1 and Border2. Redistribute the static routes into EIGRP.
- Configure the appropriate frame-relay mappings on OStub, OS1, OS2 and OS3.
- Configure the appropriate links on ABR1, Border1 and Border2 (including the link between Border1 and Border2) for the OSPF backbone area.
- Configure the appropriate links on ABR1 and OA1 for OSPF area 1.
- Configure OA1 to advertise the link to OIPv6 without forming an OSPF neighborship. Ensure OIPv6 can still reach the rest of the network.
- Configure the appropriate links on OA1 and OA2 for OSPF area 2.
- Prevent OS1, OS2 and OS3 from Designated Router eligibility.
- Configure the appropriate links on ABR1, OStub, OS1, OS2 and OS3 for OSPF area 3 and configure it as a regular stub area.
- Configure the frame relay network as type “nonbroadcast”.
- Configure an OSPF virtual-link between OA2 and ABR1.
- Configure MD5 authentication on the links between ABR1, Border1 and Border2 in the OSPF domain.
- Prevent ABR1 from adding the ES3 LAN prefix 10.20.70.0/24 to the routing table.
- Summarize all OSPF area 3 routes on ABR1.
- Configure Border1 and Border2 to send a permanent default route into OSPF.
- Redistribute all OSPF routes into EIGRP on Border1. Redistribute all EIGRP routes into OSPF on Border2.
- Redistribute EIGRP routes into RIP on RDR11 and RDR12. Deny routes with a tag of 120 from being redistributed. Assign a tag of 90 to the redistributed routes.
- Redistribute EIGRP routes with all subnets into OSPF on RDR21 and RDR22. Deny routes with a tag of 110 from being redistributed. Assign a tag of 90 to the redistributed routes.
- Redistribute RIP routes into EIGRP on RDR11 and RDR12. Deny routes with a tag of 90 from being redistributed. Assign a tag of 120 to the redistributed routes.
- Redistribute OSPF routes into EIGRP on RDR21 and RDR22. Deny routes with a tag of 90 from being redistributed. Assign a tag of 110 to the redistributed routes.
- On RDR11, configure a default route to ISP13’s f3/0 IP address. Redistribute the default route into EIGRP on RDR11.
- Configure RDR21 to send a default route into OSPF.
- Configure Border1 and Border2 as members of AS65003 and advertise the summarized IP address space of the OSPF and EIGRP domains.
- Configure an iBGP neighborship between Border1 and Border2.
- Configure ISP11 as a member of AS65001 and advertise the 10.30.0.0/16 and 10.50.0.0/16 address ranges.
- Configure ISP21 as a member of AS65002 and advertise the 10.40.0.0/16 address range.
- Create the following eBGP neighborships: Border1 ISP11, Border1 ISP21, Border2 ISP11, Border2 ISP21. Prevent AS65003 from becoming a transit between ISP1 and ISP2.
- Create eBGP neighborships between ISP11 and ISP21, IPS14 and ISP24 with MD5 authentication. Use the ISP1 lo30 and ISP2 lo40 loopbacks as the update source.
- Configure an iBGP mesh inside ISP1 and ISP2. Use ISP1 lo30 and ISP2 lo40 loopbacks as the update source. Use OSPF (on the inter-ISP1 links and loopbacks only) as the internal routing protocol for ISP1. Use EIGRP AS 65002 (on the inter-ISP2 links and loopbacks only) as the internal routing protocol for ISP2.
- On ISP13, configure a static route to the Redistribution domain via the IP address for RDR11’s f1/0 interface. Redistribute the static route into BGP.
Path Control Section:
- Configure the local preference to prefer Border2 as the default exit point.
- Configure policy routing on RIP so that all routes toward OSPF will prefer RDR12.
- Configure policy routing on OSPF so that all routes toward RIP will prefer RDR22.
Branch/Remote Operations Section:
- Configure a GRE/IPsec VPN tunnel between RDR11 and ES1. Use 10.200.0.1 and 10.200.0.2, respectively, as the tunnel endpoints.
- Configure OSPFv3 on all of the internal links in ISP1.
- Configure EIGRPv6 on all of the internal links in ISP2.
- Configure a manual IPv6 in IPv4 tunnel between OIPv6 and EIPv6. Configure IPv6 addresses of your choice on each end of the tunnel, so long as they are in the same subnet.
- Enable RIP on all IPv6 interfaces on EIPv6 and OIPv6.
In the end, I really learned a lot from this experience, and I look forward to a future, cleaner revision of this project (when I find some time). I had a lot of fun working on it and troubleshooting my initial design issues. Rest assured, there are still mistakes and omissions in the current topology. Looking ahead, I will probably use IOU/IOL for large topology designs, as GNS3 can be somewhat limiting. Who knows, maybe we’ll all be lucky and Cisco will make VIRL available soon 🙂
Attached is a PDF of the lab information, and an archive of the GNS3 project. The archive is only 2MB, but be forewarned that it decompresses to 1.5 GB. If you found any of this helpful in any way, drop me a line 🙂