Yu Cheng (Jade)
ICS 351
Lab Report 4 part 3
October 26, 2008
[Exercise 5A-5B]
We connected the ethernet interfaces of the PCs and the routers. We used the
following commands to configure the IP addresses and the interfaces on the PCs:
on PC1: `ifconfig eth0 10.0.1.1/24`
on PC1: `ifconfig eth1 10.0.2.1/24`
on PC2: `ifconfig eth0 10.0.1.2/24`
on PC2: `ifconfig eth1 10.0.5.2/24`
on PC3: `ifconfig eth0 10.0.3.4/24`
on PC3: `ifconfig eth1 10.0.4.4/24`
on PC4: `ifconfig eth0 10.0.6.7/24`
on PC4: `ifconfig eth1 10.0.7.7/24`
We used the following commands to turn on the OSPF protocol and configure the IP
addresses and interfaces on the routers:
<Router1>
on PC1: `minicom`
username: cisco
password: cisco
yourname# config t
yourname(config)# no ip routing
yourname(config)# ip routing
yourname(config)# no router rip
yourname(config)# router ospf 1
yourname(config-router)# network 10.0.0.0 255.255.255 area 1
yourname(config-router)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.3.3 255.255.255.0
yourname(config-if)# interface fa0/1
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.2.3 255.255.255.0
yourname(config-if)# end
yourname# clear ip route *
<Router2>
yourname(config)# router ospf 1
yourname(config-router)# network 10.0.0.0 255.255.255 area 1
yourname(config-router)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.4.5 255.255.255.0
yourname(config-if)# interface fa0/1
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.2.5 255.255.255.0
yourname(config-if)# end
yourname# clear ip route *
<Router3>
yourname(config)# router ospf 1
yourname(config-router)# network 10.0.0.0 255.255.255 area 1
yourname(config-router)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.5.6 255.255.255.0
yourname(config-if)# interface fa0/1
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.6.6 255.255.255.0
yourname(config-if)# end
yourname# clear ip route *
<Router4>
yourname(config)# router ospf 1
yourname(config-router)# network 10.0.0.0 255.255.255 area 1
yourname(config-router)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.5.8 255.255.255.0
yourname(config-if)# interface fa0/1
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.7.8 255.255.255.0
yourname(config-if)# end
yourname# clear ip route *
We configured the PCs to run OSPF using the Zebra package. We first enabled IP
forwarding on the PCs and added the Zebra directory to the path. The commands
we used were as follows:
on PC#: `echo "1" > /proc/sys/net/ipv4/ip_forward`
on PC#: `export PATH=/etc/rc.d/init.d/:$PATH`
on PC#: `zebra start`
on PC#: `ripd stop`
on PC#: `ripd status`
on PC#: `zebra restart`
on PC#: `ospfd start`
on PC#: `telnet localhost 2604`
Since this was the begining of the lab and we didn't run ripd on the machines
before this exercise, the commands `ripd stop` was not needed. We further
configured the PCs to run ospfd. We used commands:
<PC1>
ospf> enable
ospf# config t
ospf(config)# router ospf
ospf(config-router)# network 10.0.0.0/8 area 1
ospf(config-router)# router-id 10.0.1.1
ospf(config-router)# no passive-interface eth0
ospf(config-router)# no passive-interface eth1
ospf(config-if)# end
ospf# exit
<PC2>
ospf> enable
ospf# config t
ospf(config)# router ospf
ospf(config-router)# network 10.0.0.0/8 area 1
ospf(config-router)# router-id 10.0.1.2
ospf(config-router)# no passive-interface eth0
ospf(config-router)# no passive-interface eth1
ospf(config-if)# end
ospf# exit
<PC3>
ospf> enable
ospf# config t
ospf(config)# router ospf
ospf(config-router)# network 10.0.0.0/8 area 1
ospf(config-router)# router-id 10.0.3.4
ospf(config-router)# no passive-interface eth0
ospf(config-router)# no passive-interface eth1
ospf(config-if)# end
ospf# exit
<PC4>
ospf> enable
ospf# config t
ospf(config)# router ospf
ospf(config-router)# network 10.0.0.0/8 area 1
ospf(config-router)# router-id 10.0.6.7
ospf(config-router)# no passive-interface eth0
ospf(config-router)# no passive-interface eth1
ospf(config-if)# end
ospf# exit
We used traceroute and ping commands to verify the configuration. The commands
did not go through at first. We added 'no shutdown' to configure the routers'
interfaces and issued the commands again. This time, they were successful. We
also used command `netstat -rn` on the PCs and command `show ip route` on the
routers to display the routing tables. The hosts and routers all had routing
information of the other networks in the system.
[Exercise 5C]
We started the wireshark on PC1 and set a display filter to display only OSPF
packets. We issued a traceroute from PC3 to PC4 using `traceroute 10.0.7.7`.
We observed that the packets went from PC3 to Router 2 to PC1 to PC2 to Router4
and reached PC4.
10.0.4.4 10.0.4.5 10.0.2.1 10.0.1.2 10.0.5.8 10.0.7.7
We started a ping command from PC3 to PC4 `ping 10.0.7.7` with no time
limitation. We then disconnected the interface 0 on Router4. This
disconnection removed Router4 from the picture.
Question 5-a
We observed that it was very fast for the system to reestablish the connections.
We terminated the ping command by typing "Ctrl-C". By looking at the ping
statistics, we observed a 2% packets loss. We lost 6 out of 231 packets.
Therefore the connection was down for 6 secondes.
-------------------------- 10.0.7.7 ping statistics ---------------------------
231 packets transmitted, 225 received, 2% packet loss, time 230577ms
rtt min/avg/max/mdev = 0.715/0.917/1.149/0.064 ms
-------------------------------------------------------------------------------
Question 5-b
We observed 3 OSPF LS Update packets and 2 OSPF LS Acknowledge packets. The
rest of the OSPF packets were Hello packets.
Question 5-c
The OSPF LS Update packets were used for flooding link state information.
Question 5-d
When there are no network changes, OSPF will use very little bandwidth (only
sending hello packets). As soon as there is an outage, however, OSPF will flood
the network as the change is sent to every router, and then every router
notifies every other router in its area about the change. In the system, there
is very little network traffic when there are no route updates, and the network
is flooded when there are updates and information gets propagated throughout the
network as quickly as possible.
Question 5-e
OSPF runs directly over the Internet Protocol's network layer. OSPF packets are
therefore encapsulated solely by IP and local data-link headers. OSPF does not
define a way to fragment its protocol packets and depends on IP fragmentation
when transmitting packets larger than the network MTU. The OSPF packet types
that are likely to be large, such as LS Update and LS Acknowledgment packets,
can usually be split into several separate protocol packets without loss of
functionality. In the OSPF packets that we saved, we saw "Type: IP (0x0800)".
Question 5-f
The destination address of OSPF packets is 224.0.0.5. The range from 224.0.0.0
to 224.0.0.255 is designated for multicasting on the local LAN only. Well-known
examples are RIPv2 which uses 224.0.0.9 and OSPF which uses the 224.0.0.5.
We saved the ping staticstics as ex5c-7.txt. We also saved the reestablished
traceroute output into the same file. After the re-connection, the packets from
PC3 to PC4 went through Router2, PC1, PC2, and Router3.
10.0.4.4 10.0.4.5 10.0.2.1 10.0.1.2 10.0.5.6 10.0.7.7
We saved the link state database on all PCs and routers as ex5c-9routers.txt,
ex5c-9PC1.txt, ex5c-9PC2.txt, ex5c-9PC3.txt, and ex5c-9PC4.txt. The entities
were the same. We verified that all routers and PCs indeed had the same
link-stated database.
--------------------------Router Link States (Area 1)--------------------------
Link ID ADV Router
10.0.1.1 10.0.1.1
10.0.1.2 10.0.1.2
10.0.2.3 10.0.2.3
10.0.2.5 10.0.2.5
10.0.3.4 10.0.3.4
10.0.5.6 10.0.5.6
10.0.5.8 10.0.5.8
10.0.6.7 10.0.6.7
---------------------------Net Link States (Area 1)----------------------------
Link ID ADV Router
10.0.1.2 10.0.1.2
10.0.2.1 10.0.1.1
10.0.3.4 10.0.3.4
10.0.4.4 10.0.3.4
10.0.5.2 10.0.1.2
10.0.6.6 10.0.5.6
10.0.7.8 10.0.5.8
We also stopped the wireshark and saved one packet for each of the three types
of OSPF packets we observed. They are ex5c-10-1.txt, OSPF LS Update,
ex5c-10-2.txt, OSPF LS Acknowledge, ex5c-10-3.txt, and OSPF Hello Packet.
[Exercise 6]
We reconfigured the PCs and routers to assgin different area numbers to these
network entities. We first restarted ospfd using `zebra restart` and `ospfd
restart`. We then used the following commands to configure the area numbers:
<PC3>
ospf> enable
ospf# config t
ospf(config)# router ospf
ospf(config-router)# router-id 10.0.3.4
ospf(config-router)# network 10.0.3.0/24 area 1
ospf(config-router)# network 10.0.4.0/24 area 1
ospf(config-if)# end
ospf# exit
<PC4>
ospf> enable
ospf# config t
ospf(config)# router ospf
ospf(config-router)# router-id 10.0.6.7
ospf(config-router)# network 10.0.6.0/24 area 2
ospf(config-router)# network 10.0.7.0/24 area 2
ospf(config-if)# end
ospf# exit
<PC1>
ospf> enable
ospf# config t
ospf(config)# router ospf
ospf(config-router)# router-id 10.0.1.1
ospf(config-router)# network 10.0.2.0/24 area 1
ospf(config-router)# network 10.0.1.0/24 area 0
ospf(config-if)# end
ospf# exit
<PC2>
ospf> enable
ospf# config t
ospf(config)# router ospf
ospf(config-router)# router-id 10.0.1.2
ospf(config-router)# network 10.0.5.0/24 area 2
ospf(config-router)# network 10.0.1.0/24 area 0
ospf(config-if)# end
ospf# exit
<Router1>
yourname# config t
yourname(config)# no router ospf 1
yourname(config)# router ospf 1
yourname(config-router)# network 10.0.3.0 0.0.0.255 area 1
yourname(config-router)# network 10.0.2.0 0.0.0.255 area 1
yourname(config-router)# end
yourname # clear ip ospf 1 process
<Router2>
yourname# config t
yourname(config)# no router ospf 1
yourname(config)# router ospf 1
yourname(config-router)# network 10.0.2.0 0.0.0.255 area 1
yourname(config-router)# network 10.0.4.0 0.0.0.255 area 1
yourname(config-router)# end
yourname # clear ip ospf 1 process
<Router3>
yourname# config t
yourname(config)# no router ospf 1
yourname(config)# router ospf 1
yourname(config-router)# network 10.0.5.0 0.0.0.255 area 2
yourname(config-router)# network 10.0.6.0 0.0.0.255 area 2
yourname(config-router)# end
yourname # clear ip ospf 1 process
<Router4>
yourname# config t
yourname(config)# no router ospf 1
yourname(config)# router ospf 1
yourname(config-router)# network 10.0.5.0 0.0.0.255 area 2
yourname(config-router)# network 10.0.7.0 0.0.0.255 area 2
yourname(config-router)# end
yourname # clear ip ospf 1 process
We displayed the link-stated databases using command `show ip ospf datasase` on
the routers and command `show ip ospf database` on the PCs. We saved the link
state databases of the PCs and router as ex6-4PC1.txt, ex6-4PC2.txt,
ex6-4PC3.txt, ex6-4PC4.txt, and ex6-4routers.txt.
Question 4-a
In the PCs' databases, we observed data for two areas in PC1 and PC2. PC1 had
area 10.0.0.0 and area 10.0.0.1. PC2 had area 10.0.0.0 and area 10.0.0.2. PC3
had area 10.0.0.1. PC4 had area 10.0.0.2. In exercise 5, there was data for
only one area, 10.0.0.1, in all the PCs' link-state databases.
In the routers' databases, we observed that Router1 and Router2 belonged to area
1. Router3 and Router4 belonged to area 2. In excercise 5, the routers
belonged to area 1.
Question 4-b
Routers in area 1 know all about the networks on the other side, and this
information was advertised by PC1.
-----------------------Summary Net Link States (Area 1)------------------------
Link ID ADV Router
10.0.1.0 10.0.1.1
10.0.5.0 10.0.1.1
10.0.6.0 10.0.1.1
10.0.7.0 10.0.1.1
-------------------------------------------------------------------------------
A router has a separate link state database for every area to which it belongs.
All routers belonging to the same area have identical topological databases for
the area. Therefore, the summary above is for both Router1 and Router2.
Question 4-c
Routers in area 0, the backbone area, know all about the networks in area 1 and
area 2. This information was advertised by either PC1 or PC2.
----------------------Summary Link States (Area 0.0.0.0)-----------------------
Link ID ADV Router
10.0.2.0 10.0.1.1
10.0.3.0 10.0.1.1
10.0.4.0 10.0.1.1
10.0.5.0 10.0.1.2
10.0.6.0 10.0.1.2
10.0.7.0 10.0.1.2
-------------------------------------------------------------------------------
The summary above is for both PC1 and PC2 because they belong to the same area.
Question 4-d
As described in the two tables above, PC1 advertised the topology of area 2 to
the PCs and the routers in area 1. PC1 obtained this information from PC2. PC2
advertised the topology of area 1 to PCs and routers in area2. PC2 obtained
this information from PC1.
We then displayed the area routers known to Router1 and area 1 using command
`show ip ospf border-routers`. We saved the output to the same file,
ex6-4routers.txt. This command displays the internal OSPF routing table entries
to an Area Border Route (ABR) and Autonomous System Boundary Router (ASBR).
--------------------------show ip ospf border-routers--------------------------
OSPF Process 1 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 10.0.1.1 [1] via 10.0.2.1, FastEthernet0/1, ABR, Area 1, SPF 10
-------------------------------------------------------------------------------
As shown in the output, the border router for Router1 is PC1, 10.0.1.1.
Information from outside of area 1 would go through 10.0.1.1 and 10.0.2.1 to
the interface 0/1 on Router1. This is how Router1 learns about other networks
that are outside of area 1.
We obversved two types of OSPF packets that we did not observe previously. They
were OSPF DB Descr packets and OSPF LS Request packets. We saved one OSPF DB
Descr packet as ex6-6-1.txt and one OSPF LS Request packet as ex6-6-2.txt.
[Exercise 7]
We disconnected the cables and connected them with a new setup. We started the
wireshark on PC4 at the beginning of the exercise. We disabled OSPF processes
that were running using command `no router ospf 1`. We stopped the zebra
process on all PCs using command `zebra stop`.
Since the lab PCs run BGP but the routers don't, we configured the PCs as
routers and the routers as PCs. We first manually changed the AS numbers of the
PCs. We used the following command to display the content of the configuration
setup. We change the As number to 100 for PC1, 200 for PC2, and 300 for PC3.
We saved and closed the files.
on PC#: `gedit /etc/quagga/bgpd.conf`
We realized later that we could also do it using command `router bgp #`. We
restarted zebra and bgpd. We used the following command to configure the PCs.
on PC1: `telnet localhost 2605`
username: cisco
password: cisco
bgp> enable
bgpd# config t
bgpd(config)# router bgp 100
bgpd(config-router)# neighbor 10.0.4.2 remote-as 200
bgpd(config-router)# neighbor 10.0.4.3 remote-as 300
bgpd(config-if)# end
bgpd# exit
on PC2: `telnet localhost 2605`
username: cisco
password: cisco
bgp> enable
bgpd# config t
bgpd(config)# router bgp 200
bgpd(config-router)# neighbor 10.0.4.1 remote-as 100
bgpd(config-router)# neighbor 10.0.4.3 remote-as 300
bgpd(config-if)# end
bgpd# exit
on PC3: `telnet localhost 2605`
username: cisco
password: cisco
bgp> enable
bgpd# config t
bgpd(config)# router bgp 200
bgpd(config-router)# neighbor 10.0.4.1 remote-as 100
bgpd(config-router)# neighbor 10.0.4.2 remote-as 200
bgpd(config-if)# end
bgpd# exit
on PC4: `zebra stop`
on PC4: `bgpd stop`
We used the following commands to configure the routers:
<Router1>
yourname# config t
yourname(config)# ip route 10.0.0.0 255.0.0.0 10.0.1.1
yourname(config)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.1.10 255.255.255.0
<Router2>
yourname# config t
yourname(config)# ip route 10.0.0.0 255.0.0.0 10.0.2.2
yourname(config)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.2.10 255.255.255.0
<Router3>
yourname# config t
yourname(config)# ip route 10.0.0.0 255.0.0.0 10.0.3.3
yourname(config)# interface fa0/0
yourname(config-if)# no shutdown
yourname(config-if)# ip address 10.0.3.10 255.255.255.0
We issued ping commands and traceroutes to verify the configuration. We
observed successful connections between PCs and routers. We saved the output of
the following commands as ex7a-7router1.txt, ex7a-7router2.txt, and
ex7a-7router3.txt.
on PC# netstat -rn
bgpd# show ip bgp
bgpd# show ip bgp paths
Question 7-a
We observed only one type of BGP packets. They were KEEPALIVE messages.
BGP sends 19 bytes long KEEPALIVE messages at an interval specified by the
KEEPALIVE Interval timer in the BGP router configuration (the default is 60
seconds).
If a BGP peer misses three keepalives (180 seconds) all routes from that peer
are suppressed according to the holdtime timer setting. The holdtime timer
determines how long a peer should wait to hear a KEEPALIVE or UPDATE message
before assuming the neighbor is down, shutting down the BGP session, and
withdrawing all routes from its announcements.
Question 7-b
The main reason is reliability. BGP is a unicast protocol. It needs to be
secure and reliable. TCP transmission uses three-way handshaking. Two Ack
messages are required for a successful communication. Also, BGP defines
neighbors manually, and there is no periodic update in BGP. The update and
database is big. Since we don't repeat the sending periodically, reliability is
very important.
Question 7-c
The next-hop attribute for AS 100 on Router2 is 10.0.4.1. As we can see in the
routing table below, the Gateway for network 10.0.1.0 is 10.0.4.1.
---------------------------[root@PC2 ~]# netstat -rn---------------------------
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.4.0 0.0.0.0 255.255.255.240 U 0 0 0 eth1
10.0.1.0 10.0.4.1 255.255.255.0 UG 0 0 0 eth1
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.3.0 10.0.4.3 255.255.255.0 UG 0 0 0 eth1
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
-------------------------------------------------------------------------------
Question 7-d
BGP peers are BGP neighbors. They are established by manual configuration
between routers to create a TCP session on port 179. In this topology, the
neighboring AS 100, AS 200, and AS 300 are BGP peers.
We stopped the wireshark and saved the output as file ex7a-7wireshark.txt.
An AS-PATH is a sequence of intermediate ASs between source and destination
routers that form a directed route for packets to travel. Neighboring ASs use
BGP to exchange update messages about how to reach different AS prefixes. After
each router makes a new local decision on the best route to a destination, it
will send that route, or path information, along with accompanying distance
metrics and path attributes, to each of its peers. As this information travels
through the network, each router along the path prepends its unique AS number to
a list of ASs in the BGP message. This list is the route's AS-PATH. An AS-PATH
in conjunction with an AS prefix provides a specific handle for a one-way
transit route through the network.
[Exercise 7b]
We saved the output of command `show ip bgp neighbors` on Router2 as ex7b-1.txt.
We started wireshark on PC4 with a display filter "bgp". We configured the
routers (PCs in this exercise) to use a shorter keepalive timer and a shorter
holdtime timer. We then disconnected the cable of interface 1 on Router1 (PC1).
on PC#: `telnet localhost 2605`
username: cisco
password: cisco
bgp> enable
bgpd# config t
bgpd(config)# router bgp #
bgpd(config-router)# timers bgp 10 30
bgpd(config-if)# end
bgpd# exit
Question 4-a
The KEEPALIVE messages were constantly sent to the peers. When KEEPALIVE
messages went down, after the certain period of time the peers would assume this
connection had gone down.
Question 4-b
The BGP UPDATE Message indicated that there was a link problem. We saved the
detail of one BGP UPDATE Message as ex7b-4.txt
We displayed the neighbor information using `show ip bgp neighbors` on Router3
(PC3). We saved them as ex7b-5ROUTER3.txt. We also saved the routing table of
Router2 and Router3 (PC2 and PC3) as ex7b-6ROUTER2.txt and ex7b-6ROUTER3.txt.
---------------------------[root@PC2 ~]# netstat -rn---------------------------
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.4.0 0.0.0.0 255.255.255.240 U 0 0 0 eth1
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.3.0 10.0.4.3 255.255.255.0 UG 0 0 0 eth1
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
---------------------------[root@PC3 ~]# netstat -rn---------------------------
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.4.0 0.0.0.0 255.255.255.240 U 0 0 0 eth1
10.0.2.0 10.0.4.2 255.255.255.0 UG 0 0 0 eth1
10.0.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
From the routing tables above, we observed that the entry for network 10.0.1.0
was gone. We stopped the wireshark and saved the output as ex7b-7.txt
