This is it... This is real world!

I am doing the lab, CCNA Labs - Cisco for the Real World in GNS3 and as of now I have reached the end of Phase 3 and I can say that this lab is amazing. I've configured familiar things which are on the CCNA scope like VLANS and Trunking, NAT, Static route. I also configured EtherChannel which is discussed in CCNA but I don't remember having configured one during labs on my Cisco Networking Academy class few years back. There are also major topics which are not in the CCNA scope like Inter-VLAN with L3 Switching and (drum roll) ... VPN configuration!

In this lab, I am to setup the Branch Office network which has different VLANS, runs VOIP, with two APs one for Public and one for Private. The Private AP is connected to the internal private network while the Public AP can only connect to the Internet. There is a SERVER which can be accessed from the Internet and hosts should be able to access the Internet by passing through NAT. Then the Branch Office must be able to connect to the Corporate Office using VPN where in the addresses must not pass NAT.

The most exciting part so far in doing this lab is connecting routers to the Internet via my Network Interface card and I am able to ping Google.com from GNS3! This is real world!

Inter-VLAN using L3 Switching on GNS3

Wow, I am not aware it's almost a month since my last post here. I've been busy with other stuffs, sending out applications, getting interviewed, etc. I'm counting down the days towards graduation and hopefully my CCNA exam. After that, I think I can really focus all my energy in finding that networking job.

I don't usually write a post unless I have an inspiration for it and for this post, I got the inspiration from the 8th nugget of CCNA Labs – Cisco for the Real World. I am going to setup Inter-VLAN not with router-on-a-stick but with Layer 3 switching.  This is the topology:

The switches in the topology are actually 3725 routers with a 16-port EtherSwitch module. This is how you emulate switches in GNS3. For the IOS, I am using c3725-advipservicesk9-mz.124-3 which I have been using in my labs. I changed the icon so that I can really feel that I am configuring switches and not routers.

Configuring EIGRP Authentication

Unlike OSPF, EIGRP supports only one type of authentication: MD5.

To configure MD5 authentication, first you need to define a key chain, one or more key numbers and a key-string. Then you need to enable MD5 authentication on the interface with this key chain.

To prepare the topology, we have this basic configuration, with other parameters left to default:

R1

hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface Serial0/0
 ip address 10.1.1.1 255.255.255.0
 clock rate 2000000
!
router eigrp 99
 network 1.0.0.0
 network 10.0.0.0
 no auto-summary

CCNA Latest Updates

Bad news to all fellow CCNA students and candidates, effective 01/16/2012, CCNA Composite Exam (640-802) has increased to $295 ($45 increase) and both ICND1 (640-822) and ICND2 (640-816) to $150 each ($25 increase).

Meanwhile, good news for all Cisco Networking Academy students and alumni, Packet Tracer 5.3.3 is now released and available for download. Go to the Academy website and login with your account and click the Packet Tracer image at the left panel.

Packet Tracer version 5.3.3 is a maintenance release that fixes functional and technical issues in the previous versions. It replaces Packet Tracer version 5.3.2. Packet Tracer 5.3.3 supports activities authored in Packet Tracer 4.x, 5.0.x, 5.1.x, 5.2.x, and 5.3.x. Please note that the last two courses of the CCNA Discovery and CCNA Exploration curricula require Packet Tracer version 4.11 at a minimum, CCNA Security requires version 5.2 at a minimum, and the Packet Tracer Skills Based Assessments require version 5.3.2 at a minimum. The curricula are fully compatible with Packet Tracer 5.3.3.

The End of Trilogy (Hopefully)

I was going through my usual reading today, to be exact, Chapter 3: Troubleshooting LAN Switching of CCNA ICND2 Official Cert Guide 3rd Edition and I came across a text explaining the details of switch forwarding path. And then I just realized that I totally miscomprehend the idea of VLAN tagging. The proof is my previous post explaining about the problem with Native VLAN. 

Quoting what I've said:

As I ping from PC1 which is in VLAN 20 to the switches which has management interface of interface VLAN 88, it has to go to R1 from the trunk link. The frame was supposed to be tagged with VLAN 88 but since we defined VLAN 88 on S2 as the Native VLAN, the frame is not tagged (no 802.1Q header).

My idea is when a host has to send a frame to a host in another VLAN, the switch tags the frame with VLAN ID of the receiving host before forwarding it to the trunk link -- this is where I got it wrong.