Sie sind auf Seite 1von 8

2010-10-22 Name: ___________________________

10F NET3008 Midterm-Solutions


1. Router C is connected to the Frame Relay cloud via multipoint interface S0/0 at an access rate of 512
kbps with each location configured using the CIR and BW values shown. Dynamic routing via
EIGRP 10 is being used between the hub at C to the spokes at E through H. The administrator is
finding that EIGRP traffic is occasionally slowing payload traffic to a crawl at router C.

a. What exactly is the problem?


- by default, up to half the BW on each spoke can be used for EIGRP traffic
__ - with values configured as shown, the total inbound EIGRP traffic from the spokes to
3 C can be as much as (128 x 3) + 64 = 448 kbps; also, if all VCs were configured at C
separately with their actual BWs, outbound EIGRP traffic would also be at this rate,
rather than being constrained to 256k (half of the 512k we have available)
- since 448k approaches the 512 kbps at C, this can choke the traffic there
Mark allocation:
1 mark for each point above
b. Assuming all devices are connected
to the FR cloud via s0/0, give the
__ IOS commands that would be
8 directly relevant to solving
the problem.

IOS Command Reminders:

bandwidth kbps
ip bandwidth-percent eigrp AS-num percent
int int-name-type.sub-if-num {point-to-point | multipoint}

- At C, we group like bandwidth VCs under the same sub-if


- we configure BW values such that the sum accurately reflects that available at the main
interface (512K on S0/0 = BW of s0/0.1 + BW of s0/0.2)
- we also configure EIGRP bandwidth usage on both sub-interfaces to ensure that on any
single VC we use exactly what’s allowable (i.e. 50% of the actual BW available)
** recall that the default behaviour at a multipoint i/f (or sub-if), is for EIGRP to simply divide
the total BW by the number of configured VCs and then use up to 50% of that for routing on
each VC
** the parent interface is bound by 50% of the sum of the configured BW values on all sub-ifs

C(config)# int s0/0.1 point-to-point Mark allocation:


descr – single VC to router H 1 - sub-if to router H
band 128 1 - multipoint sub-if to E, F & G
int s0/0.2 multipoint 3 x each “bandwidth” command
descr – bundles 3 VCs to routers E, F & G 2 x each “ip bandwidth-p” cmd
band 384 1 - indicating same config applies
ip bandwidth-percent eigrp 10 100
to E, F & G
E(config)# int s0/0
descr – single VC to router C
band 128
ip bandwidth-percent eigrp 10 100

Also configure at routers F & G, as shown above for router E. No change to router H.

Page 1 of 8
2010-10-22 Name: ___________________________

2. Consider the topology below along with the partial configurations shown for R4. Notice that R4 is
participating in two separate routing domains, one using OSPF and the other, EIGRP. All addresses in
the OSPF domain are numbered in the 172.16.0.0/16 range, while those in the EIGRP domain are
numbered in the 172.30.0.0/16 range. With all links up, the given configuration provides full
reachability between routing domains as well as the Internet.

__
6

a. Exactly how does the manual summary route configured on s0 affect R4’s own routing table?
Mark
- it will auto-generate a summary discard route for that entire block, with AD=5
allocation:
172.16.0.0/16, egress to null0
2 marks for
each part
b. Briefly explain why the “default-info originate” command in R4 should be changed to
include the “always” option. (i.e. Without it, what problem could occur?)

- without “always”, if connectivity to ISP was lost, the quad-0 route would be removed
and R4 would stop propagating default into the OSPF routing domain
- this would result in loss of reachability from the OSPF domain to the EIGRP domain

c. Provide a different solution (other than adding the “always” option, as suggested above).

- introduce a floating static quad-0 so it satisfies OSPF even if the “real” quad-0 is
removed due to problems at the Internet link; due to its high AD, this route will “float”
and only be placed in the routing table if the actual Internet route to ISP is lost; it will
also explicitly discard Internet-bound traffic while the ISP link is down

R4(config)# ip route 0.0.0.0 0.0.0.0 null0 250

Page 2 of 8
2010-10-22 Name: ___________________________

3. Consider the following network topology showing an enterprise running EIGRP (as shown by the
dotted circle), using the class B address space 172.50.0.0/16. Note that this address space is
currently less than half-used. That is, no ip address values have been configured or used from
172.50.128.0 onwards.

___
16

The following configurations have already been applied, and other than what is shown below, no
static routes or summary routes (including auto-summary) exist.

ISP(config)# ip route 172.50.0.0 255.255.0.0 s0/0

Border1(config)# ip route 0.0.0.0 0.0.0.0 s0/0


Border1(config)# router eigrp 5
Border1(config-router)# redist static
Border1(config-router)# network 172.50.0.0

Sales2(config)# int s0/0


Sales2(config-if)# ip summary-addr eigrp 5 172.50.0.0 255.255.224.0

a. On the Sales2 router, only the 2 networks shown have currently been implemented, but a
summary address has been configured (given above) to reserve a portion of the "172.50"
class B network for the Sales group. What range of ip address values is represented by the
given summary address command?
2 Marks 172.50.0.0 to 172.50.31.255

b. Complete the table below to trace the packet at each step as HostA pings 172.50.25.2.

Packet forwarded to: Explanation:


• router Admin1 Admin1 configured as gateway for HostA
• router Sales1 summary route 172.50.0.0/19 originating from Sales2
6 Marks advertised from Sales1 to Admin1
• router Sales2 based on manual summary 172.50.0.0/19 from Sales2
• null0 on Sales2 since best match is the summary discard for 172.50.0.0/19,
ping packet is discarded

Page 3 of 8
2010-10-22 Name: ___________________________

c. Complete the table below to trace the packet at each step as HostA pings 172.50.205.2.

Packet forwarded to: Explanation:


• router Admin1 Admin1 configured as gateway for HostA
• router Border1 since dest’n network doesn’t exist, pkt will follow the default route
6 Marks being propagated through the EIGRP domain by Border1
• router ISP still no route match so pkt follows Border1’s quad-0, out s0/0
• router Border1 IP dest’n matches ISP’s static 172.50.0.0/16 back to Border1
2 Marks last 2 steps above, will loop repeatedly until packet TTL expires & it’s discarded

4. Consider the following hub & spoke topology between the Cisco router at HQ in Ottawa and a
number of small branches in the outlying regions, each of which has a single router. Static routing is
currently in use, but due to rapid growth in the number of remote branches being added, the
customer is seeking a solution with less administrative burden.

Below are the static routes that have been configured on the different routers:
__
6 Ottawa(config)# ip route 192.168.1.0 255.255.255.0 192.168.0.1
Ottawa(config)# ip route 192.168.2.0 255.255.255.0 192.168.0.2
Ottawa(config)# ip route 192.168.3.0 255.255.255.0 192.168.0.3

Perth(config)# ip route 0.0.0.0 0.0.0.0 192.168.0.254

Pembroke(config)# ip route 0.0.0.0 0.0.0.0 192.168.0.254

Kingston(config)# ip route 0.0.0.0 0.0.0.0 192.168.0.254

Specify the configuration commands that must be added, changed and deleted in order for you to
implement On Demand Routing for this topology. Also state any assumptions and/or conditions
required for its successful operation.

2 Marks - delete all 6 configuration lines shown above by using the “no” form of the same command

1 Mark - add configuration line: Ottawa(config)# router odr

Conditions/Assumptions:
3 Marks - all spoke routers must be Cisco
- all spoke routers must have no routing protocol configured
- all routers must have CDP enabled

Page 4 of 8
2010-10-22 Name: ___________________________

5. Consider the command dialog below …


13 marks, 1 each on diagram as follows:
R3#sh ip ospf data router 3.3.3.3 1. Router R3 - 3.3.3.3
2. connected Ethernet ...
OSPF Router with ID (3.3.3.3) (Process ID 1) 3. ... to another router (unknown ID)
4. ... which is a DR in that segment
Router Link States (Area 5) -----------
5. R3's IP = 172.16.17.17
LS age: 44 6. other router's IP = 172.16.17.18
Options: (No TOS-capability, DC) 7. in Area 5
LS Type: Router Links 8. 3.3.3.3 also connected over serial link
Link State ID: 3.3.3.3 -----------
Advertising Router: 3.3.3.3 9. … to another router
LS Seq Number: 80000003 10. ... of ID 9.9.9.9
Checksum: 0xA053 11. R3's IP = 172.16.14.91
Length: 72 12. network ID = 172.16.14.64 - on serial link
Number of Links: 3 13. mask /26 - on serial link

Link connected to: a Transit Network


(Link ID) Designated Router address: 172.16.17.18
Note: minus 0.5
(Link Data) Router Interface address: 172.16.17.17
Number of TOS metrics: 0 mark for each
TOS 0 Metrics: 1 aspect on diagram
not supported by
Link connected to: another Router (point-to-point) the data shown
(Link ID) Neighboring Router ID: 9.9.9.9
(Link Data) Router Interface address: 172.16.14.91
__ Number of TOS metrics: 0
TOS 0 Metrics: 781
14
Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.16.14.64
(Link Data) Network Mask: 255.255.255.192
Number of TOS metrics: 0
TOS 0 Metrics: 781
1 Mark
a. What number of LSA type is represented by this output? LSA Type 1
b. Based on the given output, draw as much of the network as possible. Include the following
information on your diagram, wherever it is known: network prefix, network mask, interface
IP, router ID, OSPF area, DR/BDR role.

Mark allocation

Page 5 of 8
2010-10-22 Name: ___________________________

6. Your friend Jim who works for ITA has sent you the partial topology diagram below in order to tap
into your OSPF expertise.

He says he has set the router ID of R10 to 255.255.255.255 to ensure it becomes the DR in network
__ 10.2.100.0/24, and also has R11's router ID set to 255.255.255.254 to make it the BDR. However,
8 he has found that R10 has also become the DR in network 10.2.132.0/22, even though he needs R10
to be the BDR there, with R14 being the DR. He would like your advice on his approach and how
he can achieve his goal. What do you tell him?

- [explain why/when RID works] router ID is only used during DR/BDR elections if all interfaces
in a multi-access segment are at equal priority (e.g all are at their default of 1due to no
interface priority having been configured)
4 Marks - in this case that segment’s DR will be chosen as the device having the highest router ID
(and for BDR, the second highest)
- [never count on RID – use i/f priority instead] Jim’s approach is flawed … one should never set
router ID to influence DR elections because that affects the entire device, regardless of the
segments to which it is connected
- [explain why] since DR roles are by network segment, we can precisely (and flexibly) select a
segment’s DR or BDR by boosting the priority of its connected interface accordingly
- [using i/f priority buys you one more thing] we can even ensure that a device never becomes
DR/BDR in a segment by configuring its connected interface priority to zero
- one way to achieve Jim’s goal, is to set interface priorities as follows:
- f0/4 = 10
4 Marks for solution using i/f priority
- f0/3 = 5
(only 1 mark if a solution is provided using RID values)
- f0/1 = 10
- f0/0 = 5 (in case other routers are later added to this segment)

7. Consider the following categories describing aspects of an area within an OSPF routing domain.

A. Number of ABRs: a) 1 b) 2 c) 3 or more d) not relevant

B. Number of IA routes (if a regular area): e) 5 f) 50 g) 5,000 h) not relevant


__
3 C. Number of External routes (if a regular area): j) 5 k) 50 l) 5,000 m) not relevant

Choose one item from each of categories A, B & C above, that together, would characterize an area
that's well suited to be configured as a TSA but NOT as a Stub. a, g, j

Page 6 of 8
2010-10-22 Name: ___________________________

8.

In a recent lab, we dealt with the topology above, where EIGRP auto-summary was enabled on R1
and R4 (but not on R2 and R3). Otherwise, assume that all other issues have been corrected and
EIGRP has fully converged with all links up/up.

__ a. Describe the packet (type, source, dest) that would be generated if we issue the command
“R1# ping 10.1.4.1 source loop0”. ICMP echo request from 10.1.1.1 to 10.1.4.1
2
b. Explain in detail why this ping fails, with direct reference to the various “10” routes in this
topology, how they are advertised and adopted (or not) throughout. (i.e. explain step-by-step
__ what happens, and why it happens)

7 - auto-summ on R4 has generated a 10/8 route which is advertised out s0/0/0 to R3


- this prevents R4 from advertising 10.1.4.0/24 to R3
- depending upon link speeds (which affect the route metrics), this 10/8 route could be
propagated by R3 to R2, eventually reaching R1
- auto-summ on R1 also auto-generates a 10/8 summary route (advertised to R2)
- however, R1 will NOT adopt any 10/8 route received from R2 because it has that same
route (same prefix/mask) with a lower admin distance (EIGRP summary is 5 versus 90 for
any route received from R2)
- therefore, regardless of the link speeds, the only “10” routes in R1 are its connected
10.1.1.0/24 and the 10/8 summary
- since the ping destination 10.1.4.1 doesn’t match the connected route, the best match is
the 10/8 summary discard
- the ping is routed using this route, thereby sending it to null0 (i.e. discarding it) at R1

Page 7 of 8
2010-10-22 Name: ___________________________

c. Assume now we disable auto-summary on R4, but leave it enabled on R1. With the situation
___ changed, explain again (as in part b.) what happens, and why it happens, when we retry the
command “R1# ping 10.1.4.1 source loop0”.
109.
- due to auto-summ being off at R4, it is now eligible to advertise its 10.1.4.0/24 network to
R3 (as it’s no longer advertising 10/8 to R3)
- this 10.1.4.0/24 route is propagated by R3 to R2, eventually reaching R1
- R1 still has its own 10/8 summary, but 10.1.4.0/24 is NOT the same route, so it’s adopted
and entered into R1’s routing table
- now the ping destination of 10.1.4.1 matches this new route, so it’s followed routing the
packet out s0/0/0 to R2
- the echo request packet is then forwarded from R2 to R3, eventually reaching R4
- R1, meanwhile, is still advertising the 10/8 summary to R2 (due to auto-summ) who
propagates it to R3, eventually reaching R4 (now that there’s no competing 10/8 summary
coming from R4, this is a certainty)
- R4 (not having its own 10/8 summary), will adopt this 10/8 route (originated by R1)
- so the only “10” routes in R4 are its own connected 10.1.4.0/24 and R1’s 10/8 summary
- on the echo reply packet destined for 10.1.1.1, R4’s best match is the summary route
- the reply packet is sent to R3, forwarded to R2 and eventually reaches R1, so the ping
succeeds!!

Page 8 of 8