This is another simple BGP test file in Packet Tracer 5.3. We can see selection of the best route by AS_PATH.
Showing posts with label Packet Tracer. Show all posts
Showing posts with label Packet Tracer. Show all posts
Friday, July 23, 2010
Wednesday, July 21, 2010
My VLANs are all gone?! "VTP Chaos" Packet Tracer Demo
Related Posts:
Packet Tracer,
VTP
This file was inspired by the example presented in APJ Instructor Forum on July 15, 2010.
Friday, April 30, 2010
BGP sample practice, in the new Packet Tracer 5.3
Related Posts:
BGP,
Packet Tracer
I created this practice to test the Packet Tracer 5.3 features of BGP.
Wednesday, May 13, 2009
Provide across 3 VLANs, Layer 3 connectivity using a router with 3 LAN interfaces (CNA-03-006)
CCNA Exploration 4.0, Semester 3, "Provide across 3 VLANs, Layer 3 connectivity using a router with 3 LAN interfaces" Packet Tracer 5.0 practice file (CNA-03-006).
Previous practices we are separating PCs into different VLANs. In this practice we are going to connect them together instead using Layer 3 router!
Because only 3 VLANs, we only have to prepare a router with 3 LAN interfaces.
It wont' be difficult for you if you have get through Semester 2 well. You only have to make sure each switch ports the router's interfaces connecting to is in the same VLAN as those PCs they service. Of course, the 3 inter-switch link should also be enabled as "Trunk Link".
You can use this practice as a review of Semester 2's knowledge!
Previous practices we are separating PCs into different VLANs. In this practice we are going to connect them together instead using Layer 3 router!
Because only 3 VLANs, we only have to prepare a router with 3 LAN interfaces.
It wont' be difficult for you if you have get through Semester 2 well. You only have to make sure each switch ports the router's interfaces connecting to is in the same VLAN as those PCs they service. Of course, the 3 inter-switch link should also be enabled as "Trunk Link".
You can use this practice as a review of Semester 2's knowledge!
Thursday, May 7, 2009
Enable VTP to distribute VLAN information, and provide two Virtual LAN (VLAN), using 3 connected switches (CNA-03-004)
CCNA Exploration 4.0, Semester 3, "Enable VTP to distribute VLAN information, and provide two Virtual LAN (VLAN), using 3 connected switches" Packet Tracer 5.0 practice file (CNA-03-004).
The diagram is in fact the same as the previous example. You must have noticed that it is really bothering to add VLANs on switches one after one. In this case, we are going to make use of a special automatic method by IOS itself: the VTP protocol.
VTP stands for VLAN Trunking Protocol. It is a proprietary protocols among Cisco switches to distribute VLAN information.
Although it is not difficult for you to "peep" at "CoreSwitch"'s configuration in this Packet Tracer file, I wish you do not try it. What I want you to feel is to enable VTP only and then observe "Switch1" and "Switch2" getting VLAN information automatically!
In this case, "Switch1" and "Switch2" can play the VTP role as "Client". That is, it listens VLAN information advertised from the VTP "Server" role switches.
Client Configs:
Server Configs:
Just like the VLAN information, we cannot see them in the running configuration. We can issue "show vtp status" command to check VTP status.
Switch1:
CoreSwitch:
The diagram is in fact the same as the previous example. You must have noticed that it is really bothering to add VLANs on switches one after one. In this case, we are going to make use of a special automatic method by IOS itself: the VTP protocol.
VTP stands for VLAN Trunking Protocol. It is a proprietary protocols among Cisco switches to distribute VLAN information.
Although it is not difficult for you to "peep" at "CoreSwitch"'s configuration in this Packet Tracer file, I wish you do not try it. What I want you to feel is to enable VTP only and then observe "Switch1" and "Switch2" getting VLAN information automatically!
In this case, "Switch1" and "Switch2" can play the VTP role as "Client". That is, it listens VLAN information advertised from the VTP "Server" role switches.
Client Configs:
Switch1(config)#vtp mode client
Switch1(config)#vtp domain ccna
Switch1(config)#
Server Configs:
CoreSwitch(config)#vtp mode server
CoreSwitch(config)#vtp domain ccna
CoreSwitch(config)#
Just like the VLAN information, we cannot see them in the running configuration. We can issue "show vtp status" command to check VTP status.
Switch1:
Switch1#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 255
Number of existing VLANs : 7
VTP Operating Mode : Client
VTP Domain Name : ccna
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x9E 0x49 0xD8 0xC7 0xED 0x7C 0xB2 0x01
Configuration last modified by 20.1.1.101 at 3-1-93 00:01:58
Switch1#
CoreSwitch:
CoreSwitch#show vtp status
VTP Version : 2
Configuration Revision : 4
Maximum VLANs supported locally : 255
Number of existing VLANs : 7
VTP Operating Mode : Server
VTP Domain Name : ccna
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x9E 0x49 0xD8 0xC7 0xED 0x7C 0xB2 0x01
Configuration last modified by 20.1.1.101 at 3-1-93 00:01:58
Local updater ID is 20.1.1.101 on interface Vl1 (lowest numbered VLAN interface found)
CoreSwitch#
Providing two Virtual LAN (VLAN), using 3 connected switches (CNA-03-003)
CCNA Exploration 4.0, Semester 3, "Providing two Virtual LAN (VLAN), using 3 connected switches" Packet Tracer 5.0 practice file (CNA-03-003).
This practice is continued from previous Practice 1 and Practice 2. Essentially, we must configure the two "Inter-switch Links" manually as "Trunk Link".
But that's not enough. One thing I have to point out is we also have to declare VLAN 10 and VLAN 20 in the middle switch: "CoreSwitch". We often forget about this when we implement LAN switching.
Why should we do this? This is because of the design of a hardware switch. It cannot "guess" how many VLANs could be there. Switches only separate and forward frames tagged as certain VLANs when it knows those VLANs exist. If we forget to declare them, then the "CoreSwitch" will not recognize frames tagged as VLAN 10 and VLAN 20, and thus drops all frames of them. We lose connectivity for both VLAN 10 and VLAN 20 in the end.
Then why we do not have to "declare" VLAN 10 and VLAN 20 in previous examples? This is because when we configure some switch port as access link of "VLAN 10", Cisco IOS add "VLAN 10" automatically for us. The same thing happens for VLAN 20, too. However, because we do not configure any switch ports in "CoreSwitch" as neither VLAN 10 nor VLAN 20, we have to declare them by ourselves.
We cannot know from "running-config" about which VLANs are added. We have to issue "show vlan" command to display the VLANs we successfully declared.
Before we add VLANs:
After we declared VLANs, we will see the differences:
This practice is continued from previous Practice 1 and Practice 2. Essentially, we must configure the two "Inter-switch Links" manually as "Trunk Link".
But that's not enough. One thing I have to point out is we also have to declare VLAN 10 and VLAN 20 in the middle switch: "CoreSwitch". We often forget about this when we implement LAN switching.
Why should we do this? This is because of the design of a hardware switch. It cannot "guess" how many VLANs could be there. Switches only separate and forward frames tagged as certain VLANs when it knows those VLANs exist. If we forget to declare them, then the "CoreSwitch" will not recognize frames tagged as VLAN 10 and VLAN 20, and thus drops all frames of them. We lose connectivity for both VLAN 10 and VLAN 20 in the end.
Then why we do not have to "declare" VLAN 10 and VLAN 20 in previous examples? This is because when we configure some switch port as access link of "VLAN 10", Cisco IOS add "VLAN 10" automatically for us. The same thing happens for VLAN 20, too. However, because we do not configure any switch ports in "CoreSwitch" as neither VLAN 10 nor VLAN 20, we have to declare them by ourselves.
CoreSwitch(config)#vlan 10 CoreSwitch(config-vlan)#exit CoreSwitch(config)#vlan 20 CoreSwitch(config-vlan)#exit CoreSwitch(config)#
We cannot know from "running-config" about which VLANs are added. We have to issue "show vlan" command to display the VLANs we successfully declared.
Before we add VLANs:
CoreSwitch#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Fa0/24
Gig1/1, Gig1/2
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1 enet 100001 1500 - - - - - 0 0
1002 enet 101002 1500 - - - - - 0 0
1003 enet 101003 1500 - - - - - 0 0
1004 enet 101004 1500 - - - - - 0 0
1005 enet 101005 1500 - - - - - 0 0
CoreSwitch#
After we declared VLANs, we will see the differences:
CoreSwitch#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/13, Fa0/14
Fa0/15, Fa0/16, Fa0/17, Fa0/18
Fa0/19, Fa0/20, Fa0/21, Fa0/22
Fa0/23, Fa0/24, Gig1/1, Gig1/2
10 VLAN0010 active
20 VLAN0020 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1 enet 100001 1500 - - - - - 0 0
10 enet 100010 1500 - - - - - 0 0
20 enet 100020 1500 - - - - - 0 0
1002 enet 101002 1500 - - - - - 0 0
1003 enet 101003 1500 - - - - - 0 0
1004 enet 101004 1500 - - - - - 0 0
1005 enet 101005 1500 - - - - - 0 0
CoreSwitch#
Tuesday, May 5, 2009
Providing two Virtual LAN (VLAN), using 2 connected switches (CNA-03-002)
CCNA Exploration 4.0, Semester 3, "Providing two Virtual LAN (VLAN), using 2 connected switches" Packet Tracer 5.0 practice file (CNA-03-002).
Continuing from previous example, but we add one more switch to do the same thing.
Looking at the only link between the two switches in the diagram, we now have to "mix" frames in the two Virtual LANs (VLANs) going through that link. Of course, if we add up more VLANs, the same link would get more frames belonging to more different VLANs mixing in that link.
Then how can a switch tell which frame belongs to which VLAN? Yes, adding tags on each frame is a great solution! Cisco 2950s and Cisco 2960s support only one type of tagging: IEEE 802.1Q.
If a inter-switch link is mixing frames from different VLANs, we call it a "Trunk Link". The ports of its both sides are called "Trunk Ports" Just like a real tree, while the "trunk" nourishes branches and leaves, a "trunk link" services several VLANs.
If a switch port is used for one PC or one server only, then we do not have to mix and add tags. These ports are just "normal" Ethernet switch ports without any tagging. We call them "Access Link". The switch ports of its both sides are called "Access Ports".
From the diagram and above discussion, we know we have to configure the only link as "Trunk Link". The simplest way to do so is to "manually" configure both sides of the link into mode "Trunk".
The example is like this:
The other configuration is just the same as the previous example. You can check the Packet Tracer files yourself!
Continuing from previous example, but we add one more switch to do the same thing.
Looking at the only link between the two switches in the diagram, we now have to "mix" frames in the two Virtual LANs (VLANs) going through that link. Of course, if we add up more VLANs, the same link would get more frames belonging to more different VLANs mixing in that link.
Then how can a switch tell which frame belongs to which VLAN? Yes, adding tags on each frame is a great solution! Cisco 2950s and Cisco 2960s support only one type of tagging: IEEE 802.1Q.
If a inter-switch link is mixing frames from different VLANs, we call it a "Trunk Link". The ports of its both sides are called "Trunk Ports" Just like a real tree, while the "trunk" nourishes branches and leaves, a "trunk link" services several VLANs.
If a switch port is used for one PC or one server only, then we do not have to mix and add tags. These ports are just "normal" Ethernet switch ports without any tagging. We call them "Access Link". The switch ports of its both sides are called "Access Ports".
From the diagram and above discussion, we know we have to configure the only link as "Trunk Link". The simplest way to do so is to "manually" configure both sides of the link into mode "Trunk".
The example is like this:
interface FastEthernet0/11
switchport mode trunk
The other configuration is just the same as the previous example. You can check the Packet Tracer files yourself!
Friday, May 1, 2009
Does Cisco's Packet Tracer software support BGP?
Related Posts:
Cisco Network Academy,
Packet Tracer
I was totally wrong on this post! Please go to this new page instead!
Show IP Protocols: BGP sample practice, in the new Packet Tracer 5.3
I tested. No!
Will BGP be added into it? I do not think so!
Cisco's Packet Tracer software is just for very entry level learners of Cisco and network technologies. It is designed for pre-CCNA or CCNA people's practicing only!
Then how to practice BGP? Maybe "Dynamips" is a good idea!
Show IP Protocols: BGP sample practice, in the new Packet Tracer 5.3
Will BGP be added into it? I do not think so!
Cisco's Packet Tracer software is just for very entry level learners of Cisco and network technologies. It is designed for pre-CCNA or CCNA people's practicing only!
Then how to practice BGP? Maybe "Dynamips" is a good idea!
Wednesday, April 29, 2009
Enable Virtual LAN (VLAN) to seperate two Layer 2 worlds (CNA-03-001)
CCNA Exploration 4.0, Semester 3, "Enable Virtual LAN (VLAN) to seperate two Layer 2 worlds" Packet Tracer 5.0 practice file (CNA-03-001).
Virtual LAN (VLAN) service, for short, is to make one physical switch look like and used like multiple logical switches. This is indeed a "virtualization" of Ethernet switches, just like the concept of "virtualization computing" now. "Virtualization computing" is quite a hot topic recently. If you have used VMWare or Microsoft Virtual PC, you would know what virtualization is!
I will talk more about "Virtualization" in the future! Let's go back to the main topic.
This practice is to get familiar with assigning different switch ports to different VLANs.
According to the requirements displayed in the diagram, once we assign the switch ports connecting to PC1 and PC3 to VLAN 10, and then assign switch ports connecting to PC2 and PC4 to VLAN 20, our jobs are done. Two worlds are seperated!
To assign switch port to designated VLAN we can configure like the this: (Suppose the designated VLAN number is 10)
Virtual LAN (VLAN) service, for short, is to make one physical switch look like and used like multiple logical switches. This is indeed a "virtualization" of Ethernet switches, just like the concept of "virtualization computing" now. "Virtualization computing" is quite a hot topic recently. If you have used VMWare or Microsoft Virtual PC, you would know what virtualization is!
Virtual LAN <---> Virtual Machine
I will talk more about "Virtualization" in the future! Let's go back to the main topic.
This practice is to get familiar with assigning different switch ports to different VLANs.
According to the requirements displayed in the diagram, once we assign the switch ports connecting to PC1 and PC3 to VLAN 10, and then assign switch ports connecting to PC2 and PC4 to VLAN 20, our jobs are done. Two worlds are seperated!
To assign switch port to designated VLAN we can configure like the this: (Suppose the designated VLAN number is 10)
interface FastEthernet 0/1 switchport access vlan 10
Tuesday, April 28, 2009
Observe and solve Classful addressing problem, using OSPF (CNA-02-007)
CCNA Exploration 4.0, Semester 2, "Observe and solve Classful addressing problem, using OSPF" Packet Tracer 5.0 practice file (CNA-02-007).
I like to use OSPF because I do not have to worry about any "Classful" problem at all: there is no "Classful" function in its design and no backward compatibility burdens. No "no auto-summary" command in OSPF!
As long as OSPF is running fine, all routes would also be fine!
I like to use OSPF because I do not have to worry about any "Classful" problem at all: there is no "Classful" function in its design and no backward compatibility burdens. No "no auto-summary" command in OSPF!
As long as OSPF is running fine, all routes would also be fine!
R2>sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
O 10.1.1.0 [110/65] via 172.30.2.1, 00:00:24, Serial0/0/0
O 10.2.2.0 [110/65] via 192.168.4.1, 00:00:24, Serial0/0/1
172.30.0.0/24 is subnetted, 3 subnets
O 172.30.1.0 [110/65] via 172.30.2.1, 00:00:24, Serial0/0/0
C 172.30.2.0 is directly connected, Serial0/0/0
C 172.30.3.0 is directly connected, FastEthernet0/0
C 192.168.4.0/24 is directly connected, Serial0/0/1
O 192.168.5.0/24 [110/65] via 192.168.4.1, 00:00:24, Serial0/0/1
R2>
Monday, April 27, 2009
Observe and solve Classful addressing problem, using EIGRP (CNA-02-006)
CCNA Exploration 4.0, Semester 2, "Observe and solve Classful addressing problem, using EIGRP" Packet Tracer 5.0 practice file (CNA-02-006).
I choose to re-use the same network diagram and addressing as the previous example. Many of us might think when we just dump the old RIPs and use the modern ones such as EIGRP, the Classful addressing problem would be solved by itself. However, since EIGRP is an "Enhanced" version of "IGRP", to minimize impact to customers Cisco still set its behaviors to "Classful" by default. It's not enough to only enable EIGRP! See below in the wrong solution (Backup Link), the problem is the same as before:
The key is to turn off "Classful behaviors" by manually adding "no auto-summary" command!
After this command, the correct result is now like this (Backup Link):
- CNA-02-006.pkt, (Backup Link)
- CNA-02-006-wrong-sol.pkt, (Backup Link)
- CNA-02-006-final-sol.pkt, (Backup Link)
I choose to re-use the same network diagram and addressing as the previous example. Many of us might think when we just dump the old RIPs and use the modern ones such as EIGRP, the Classful addressing problem would be solved by itself. However, since EIGRP is an "Enhanced" version of "IGRP", to minimize impact to customers Cisco still set its behaviors to "Classful" by default. It's not enough to only enable EIGRP! See below in the wrong solution (Backup Link), the problem is the same as before:
R2>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
D 10.0.0.0/8 [90/2172416] via 172.30.2.1, 00:00:10, Serial0/0/0
[90/2172416] via 192.168.4.1, 00:00:10, Serial0/0/1
172.30.0.0/16 is variably subnetted, 4 subnets, 2 masks
D 172.30.0.0/16 is a summary, 00:00:10, Null0
D 172.30.1.0/24 [90/2172416] via 172.30.2.1, 00:00:10, Serial0/0/0
C 172.30.2.0/24 is directly connected, Serial0/0/0
C 172.30.3.0/24 is directly connected, FastEthernet0/0
C 192.168.4.0/24 is directly connected, Serial0/0/1
D 192.168.5.0/24 [90/2172416] via 192.168.4.1, 00:00:10, Serial0/0/1
R2>
The key is to turn off "Classful behaviors" by manually adding "no auto-summary" command!
router eigrp 1
network 172.30.0.0
network 192.168.4.0
no auto-summary
After this command, the correct result is now like this (Backup Link):
R2>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
D 10.1.1.0 [90/2172416] via 172.30.2.1, 00:00:35, Serial0/0/0
D 10.2.2.0 [90/2172416] via 192.168.4.1, 00:00:34, Serial0/0/1
172.30.0.0/24 is subnetted, 3 subnets
D 172.30.1.0 [90/2172416] via 172.30.2.1, 00:00:35, Serial0/0/0
C 172.30.2.0 is directly connected, Serial0/0/0
C 172.30.3.0 is directly connected, FastEthernet0/0
C 192.168.4.0/24 is directly connected, Serial0/0/1
D 192.168.5.0/24 [90/2172416] via 192.168.4.1, 00:00:34, Serial0/0/1
R2>
Tuesday, April 7, 2009
Solving Classful addressing problem, using RIP (CNA-02-005)
CCNA Exploration 4.0, Semester 2, "Solving Classful addressing problem, using RIP" Packet Tracer 5.0 practice file (CNA-02-005).
In this example, the IP addressing scheme is only allowed in the our current new "Classless" world. That's why any old "Classful" routing protocols will not work.
The problem is at the routing entries in R2's routing table. Two "10.0.0.0/8" entries will be there. This is a typical "Classful" world behavior: when advertising routing information to other "classful network address"'s router, all subnet routes will be summarized into one route, which is exactly the same as your own "classful network address".
In this case, the "classful network address" is exactly "10.0.0.0/8". The peer router is R2 and is not within this classful network address.
That's why 50% of packets destined for either 10.1.1.0/24 or 10.2.2.0/24 would go to the wrong router and get dropped!
Here is the wrong routing table, by using RIP version 1 (CNA-02-005-wrong-sol.pkt, Backup Link):
Therefore, we can only implement "Classless" protocols, such as RIP version 2. (CNA-02-005-final-sol.pkt, Backup Link). Also remember to add "no auto-summary" command to disable RIPv2's "Classful behavior"!
- CNA-02-005.pkt, (Backup Link)
- CNA-02-005-wrong-sol.pkt, (Backup Link)
- CNA-02-005-final-sol.pkt, (Backup Link)
In this example, the IP addressing scheme is only allowed in the our current new "Classless" world. That's why any old "Classful" routing protocols will not work.
The problem is at the routing entries in R2's routing table. Two "10.0.0.0/8" entries will be there. This is a typical "Classful" world behavior: when advertising routing information to other "classful network address"'s router, all subnet routes will be summarized into one route, which is exactly the same as your own "classful network address".
In this case, the "classful network address" is exactly "10.0.0.0/8". The peer router is R2 and is not within this classful network address.
That's why 50% of packets destined for either 10.1.1.0/24 or 10.2.2.0/24 would go to the wrong router and get dropped!
Here is the wrong routing table, by using RIP version 1 (CNA-02-005-wrong-sol.pkt, Backup Link):
R2>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
R 10.0.0.0/8 [120/1] via 192.168.4.1, 00:00:17, Serial0/0/1
[120/1] via 172.30.2.1, 00:00:14, Serial0/0/0
172.30.0.0/24 is subnetted, 3 subnets
R 172.30.1.0 [120/1] via 172.30.2.1, 00:00:14, Serial0/0/0
C 172.30.2.0 is directly connected, Serial0/0/0
C 172.30.3.0 is directly connected, FastEthernet0/0
C 192.168.4.0/24 is directly connected, Serial0/0/1
R 192.168.5.0/24 [120/1] via 192.168.4.1, 00:00:17, Serial0/0/1
R2>
Therefore, we can only implement "Classless" protocols, such as RIP version 2. (CNA-02-005-final-sol.pkt, Backup Link). Also remember to add "no auto-summary" command to disable RIPv2's "Classful behavior"!
R2>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
R 10.1.1.0 [120/1] via 172.30.2.1, 00:00:12, Serial0/0/0
R 10.2.2.0 [120/1] via 192.168.4.1, 00:00:12, Serial0/0/1
172.30.0.0/24 is subnetted, 3 subnets
R 172.30.1.0 [120/1] via 172.30.2.1, 00:00:12, Serial0/0/0
C 172.30.2.0 is directly connected, Serial0/0/0
C 172.30.3.0 is directly connected, FastEthernet0/0
C 192.168.4.0/24 is directly connected, Serial0/0/1
R 192.168.5.0/24 [120/1] via 192.168.4.1, 00:00:12, Serial0/0/1
R2>
Thursday, March 26, 2009
Observe advertisement of Default Route by automatic routing protocol, still using RIPv1 (CNA-02-004)
CCNA Exploration 4.0, Semester 2, "Observe advertisement of Default Route by automatic routing protocol, still using RIPv1" Packet Tracer 5.0 practice file (CNA-02-004).
In this example we do observation only. You will see how I use RIPv1 to advertise "Default Route".
Making that happen depends on 2 keys:
Then we can see the "Default Route" on R3:
In this example we do observation only. You will see how I use RIPv1 to advertise "Default Route".
Making that happen depends on 2 keys:
- The "Default Route" should be already in R2's routing table.
- R2 is configured with "default-information originate" statement.
ip route 0.0.0.0 0.0.0.0 172.30.2.1
router rip
network 172.30.0.0
network 192.168.4.0
default-information originate
Then we can see the "Default Route" on R3:
R3>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 192.168.4.2 to network 0.0.0.0
R 172.30.0.0/16 [120/1] via 192.168.4.2, 00:00:19, Serial0/0/0
C 192.168.4.0/24 is directly connected, Serial0/0/0
C 192.168.5.0/24 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/1] via 192.168.4.2, 00:00:19, Serial0/0/0
R3>
Wednesday, March 25, 2009
Automatic routing table maintenance by routing protocol configuration, still using RIPv1 (CNA-02-003)
CCNA Exploration 4.0, Semester 2, "Automatic routing table maintenance by routing protocol configuration, still using RIPv1" Packet Tracer 5.0 practice file (CNA-02-003).
I believe many people were not quite satisfied by previous practice: the IP addresses were not the same. Now in this practice I changed all the IP addresses to the same as the first practice. We still use RIPv1 this time.
It would be much more persuasive that "automatic" ways are better than "manual" ways.
In addition to this, I also want to illustrate one "Classful" behavior in this practice. Classful world's router always summarize all subnet routes to only one route: the class network address it belongs to, when telling to other routers not in the same class network address.
We have 3 subnet routes of 172.30.1.0/24, 172.30.2.0/24, 172.30.3.0/24 in this practice. But R3 will only see 172.30.0.0/16, the one B class network address they belong to.
I believe many people were not quite satisfied by previous practice: the IP addresses were not the same. Now in this practice I changed all the IP addresses to the same as the first practice. We still use RIPv1 this time.
It would be much more persuasive that "automatic" ways are better than "manual" ways.
In addition to this, I also want to illustrate one "Classful" behavior in this practice. Classful world's router always summarize all subnet routes to only one route: the class network address it belongs to, when telling to other routers not in the same class network address.
We have 3 subnet routes of 172.30.1.0/24, 172.30.2.0/24, 172.30.3.0/24 in this practice. But R3 will only see 172.30.0.0/16, the one B class network address they belong to.
R3#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
R 172.30.0.0/16 [120/1] via 192.168.4.2, 00:00:25, Serial0/0/0
C 192.168.4.0/24 is directly connected, Serial0/0/0
C 192.168.5.0/24 is directly connected, FastEthernet0/0
R3#
Tuesday, March 24, 2009
Automatic routing table maintenance by routing protocol configuration, using RIPv1 (CNA-02-002)
CCNA Exploration 4.0, Semester 2, "Automatic routing table maintenance by routing protocol configuration, using RIPv1" Packet Tracer 5.0 practice file (CNA-02-002).
In this example, we are experiencing "automatic" way of routing table maintenance. We use RIPv1 (RIP version 1) .
Note, the IP addresses are not the same as the previous practice.
I believe after this practice, everyone would appreciate the beauty of such "automatic" way!
In this example, we are experiencing "automatic" way of routing table maintenance. We use RIPv1 (RIP version 1) .
Note, the IP addresses are not the same as the previous practice.
I believe after this practice, everyone would appreciate the beauty of such "automatic" way!
Tuesday, December 9, 2008
Manual routes only configuration practice (CNA-02-001)
CCNA Exploration 4.0, Semester 2, "Manual routes only configuration" Packet Tracer 5.0 practice file (CNA-02-001).
In this example, we practice adding "manual routes" only, to maintain full connectivity.
The diagram shown in this example is quite simple. However, we will quickly learn in it: if we maintain all the necessary routes manually by hand, we could make a lot of careless mistakes. And the result is only a partially working network. The worst thing is, we have to examine all routers to find out where the problem is!
That's why we have to study so much about "automatic" ways to maintain full connectivity!
Many documents did not explain the following terms clear. In fact:
In this example, we practice adding "manual routes" only, to maintain full connectivity.
The diagram shown in this example is quite simple. However, we will quickly learn in it: if we maintain all the necessary routes manually by hand, we could make a lot of careless mistakes. And the result is only a partially working network. The worst thing is, we have to examine all routers to find out where the problem is!
That's why we have to study so much about "automatic" ways to maintain full connectivity!
Many documents did not explain the following terms clear. In fact:
- Static means Manual
- Dynamic means Automatic
Tuesday, August 19, 2008
Packet Tracer 5.0 Released!
Related Posts:
Cisco Network Academy,
Packet Tracer
The newest version of Packet Tracer, version 5.0, is now open for Academy users to download!
Packet Tracer 5.0, including powerful simulation, visualization, authoring, assessment, and collaboration capabilities, will help students and teachers collaborate, solve problems, and learn concepts in an engaging and dynamic social environment.
References:
Packet Tracer 5.0 Multimedia Show
Cisco Network Academy Page
Subscribe to:
Posts (Atom)
Popular Posts
-
CCNA Exploration 4.0, Semester 4, "Dual Stack IPv6 and IPv4 configuration " Packet Tracer 5.0 practice file (CNA-04-006). ... -
I created this practice to test the Packet Tracer 5.3 features of BGP. -
Fire-like Kapok blossoms in Taipei City, Taiwan To show the reserved VLAN numbers on both IOS and NX-OS, the common command is: sho... -
We hear a lot of directions when we are talking about Data Center technologies: Northbound, Southbound, and even Eastbound/Westbound. What d... -
One working switch port on my Cisco Catalyst 2950 suddenly went down by itself! Of course, my phone rang when I was having dinner, and the...