FluxTuna 0.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,383 @@
1
+ [h1 Lab 2: Introduction to Static Routing]
2
+
3
+ [h2 Aim]
4
+
5
+ [quote]
6
+ To implement a two router configuration, connecting a small branch
7
+ network to another the network, via a common shared network.
8
+ [end]
9
+
10
+ For the purpose of this lab, you only need to set-up the [ac TCPIP] network
11
+ stack: we will do most of our network testing using [tt ping] to start
12
+ with. Once you have the [ac TCPIP] network working, try enabling other
13
+ services and see what happens.
14
+
15
+ [h2 Objectives]
16
+
17
+ [ol]
18
+
19
+ [item You will be able to use [tt ifconfig] to set-up basic [ac TCPIP]
20
+ parameters on a Unix system]
21
+
22
+ [item You will be able to identify how a router may be used to
23
+ join physically unrelated networks.]
24
+
25
+ [item You will be able to configure [ac TCPIP] in a routed
26
+ environment, and identify the differences between a Routed and a
27
+ Switched network]
28
+
29
+ [item You will be able to identify the need for an automatically
30
+ configured network routers]
31
+
32
+ [end]
33
+
34
+ [h2 Pre-Requisites]
35
+
36
+ [ul]
37
+
38
+ [item You will need a copy of the [tt OpenBSD Console] client, available from
39
+ [link this site|ftp://10.72.46.182/Images]. These notes assume you will be
40
+ using image version [tt 07]. Ask the tutor for details if you are unsure.]
41
+
42
+ [item You should be familiar with running an operating system image under
43
+ VMWare in the labs. If you haven't set-up a client image before, have a look
44
+ on the module lab page for a tutorial on VMWare which will take you through
45
+ the steps.]
46
+
47
+ [item You should be aware of how to set-up a basic Ethernet network. We will
48
+ not be using anything fancy, but should should be comfortable with the patch
49
+ panel and basic switch set-up.]
50
+
51
+ [item Finally it would be a good ideal to have some familiarity with the
52
+ basics of [ac IP] addressing and sub-netting theory. Again we won't be doing
53
+ anything very complicated in this lab, but you will some some knowledge to
54
+ answer the questions at the end...]
55
+
56
+ [end]
57
+
58
+ [h2 Equipment]
59
+
60
+ [ul]
61
+ [item 1 $\times$ switch on the rack system]
62
+ [item 2 $\times$ computers capable of running VMWare 6.0]
63
+ [item 2 $\times$ UTP Cat5 patch cables]
64
+ [end]
65
+
66
+ [h2 Recommended Reading]
67
+
68
+ Most of the background documentation is available on the module site, under
69
+ the notes for [e Block 2] of the module.
70
+
71
+ If you have not used a Unix system before, have a look at the [e Brief Guide
72
+ to Unix] available on the module Wiki. You will also find links to the Unix
73
+ manual ([tt man]) pages of the commands used in this lab.
74
+
75
+ [h2 Scenario]
76
+
77
+ [figure:LabNet]
78
+ [image IP_Routing_Lab_Base_Network]
79
+ [caption Myertor Project Office Network Topology]
80
+ [end]
81
+
82
+ Myertor has a large number of satellite project office, usually located within
83
+ a customers site. In common with then network topology at most large
84
+ companies, the intermediate networks connecting the project office to
85
+ headquarters is 'rented' from an [ac ISP] and not used exclusively for this
86
+ link. Our [ac ISP] allocates addresses for our border routers from the [tt
87
+ 172.20.0.0/16] block, so the [e external] address of each border router will
88
+ live somewhere in here.
89
+
90
+ Project offices, by contrast, are set-up using the addresses taken from the
91
+ [tt 192.168.x.0/24] block, using different values for [tt x] in each office.
92
+ This requires the border routers at the project site to be set-up to send
93
+ packets destined for other office (or headquarters) across the 'foreign'
94
+ network [tt 172.20.0.0/16]. A rough picture of this network topology is shown
95
+ in [ref LabNet].
96
+
97
+ In this lab we will look at the steps required to get basic routing services
98
+ working in this topology. By the end, we should have a network which allows
99
+ people at any project office to connect to any other network. We will start,
100
+ though, with just two networks: once you know how to join these together, you
101
+ can add any other network with a few commands.
102
+
103
+ [h2 Setting up the Headquarters Border Router]
104
+
105
+ The first host we will set-up will be the border router for the
106
+ 'headquarters' network. You will run a [tt http] server (Apache) on this
107
+ host to give us something to test against. Later we will attach a new
108
+ virtual image to the internal interface of this host, and run Apache on
109
+ this new image to simulate the corporate web server.
110
+
111
+ Before we start the OpenBSD image, make sure you first virtual Ethernet
112
+ card is set to [e Bridged] mode and you second Ethernet card is set to
113
+ [e Host Only]. This connects your first virtual Ethernet card to the
114
+ network, and allows us to add other images to you network using VMWare.
115
+ If you get any questions from VMWare over whether to image was moved or
116
+ copied, select the default [e copied] when prompted[fn VMWare
117
+ generates the [sc mac] addresses for the virtual machines when the
118
+ image is first created. Selecting [e copied] forces VMWare to
119
+ regenerate the [sc mac] addresses, allowing you to have multiple
120
+ images attached to the same network. If you select [e move], VMWare
121
+ would use the original [sc mac] address, and everyone would end up
122
+ with the same one. At the very least this will cause confusion, but it
123
+ would normally prevent the networking working at all.].
124
+
125
+ Start the OpenBSD image, and wait for the [tt login:] prompt to appear.
126
+ Login to the OpenBSD image using the username [tt root] and the password
127
+ [tt gold]. If you are asked for a terminal type, press [tt Enter] to
128
+ select the default ([tt VT220])[fn OpenBSD is often run 'headless',
129
+ i.e. without a keyboard or monitor, using the serial port. So when you login
130
+ as root, OpenBSD doesn't automatically assume you will be using a standard
131
+ terminal, so it asks you which terminal you do want. Most of the time we don't
132
+ really care, and the default emulation of a [tt VT220] will work on most
133
+ output devices.].This will give you a basic command prompt: all further
134
+ commands are entered at this prompt.
135
+
136
+ Next, set-up the basic network using the [tt ifconfig]
137
+ command[fn All Unix systems use the 'interface configuration'
138
+ command [tt ifconfig] to perform [e temporary] configuration of
139
+ the network interfaces. Some, e.g. Silicon Graphics Irix, use
140
+ [tt ifconfig] to perform permanent alterations as well. Under
141
+ OpenBSD you will have to edit the relevant [tt hostname] file in the
142
+ [tt /etc] directory if you want your configurations to survive a
143
+ reboot of the image. Have a look at the [man:5 hostname.if] manual
144
+ page ('[tt man hostname.if]') for more details.]. You will need
145
+ to set the external (i.e. bridged) Ethernet card [tt vic0] to the address
146
+ of the [ac ISP] network. We will use the address block '[tt 172.20.0.0/16]'
147
+ for the [ac ISP] network: all border routers [e must] connect to the
148
+ network to function. You border router will also have the external
149
+ address [tt 172.20.x.1], where [tt x] is the number of your network patch
150
+ port.
151
+
152
+ Before we configure the network using the [tt ifconfig] command, type
153
+
154
+ [command]
155
+ ifconfig
156
+ [end]
157
+
158
+ at the command prompt and look at the output. Now type
159
+
160
+ [command]
161
+ ifconfig vic0 inet 172.20.x.1
162
+ [end]
163
+
164
+ substituting [tt x] for your patch number. Type
165
+
166
+ [command]
167
+ ifconfig
168
+ [end]
169
+
170
+ again, and look at the output. What has changed? How has the network
171
+ interface been set-up (e.g. look at the netmask and broadcast address)?
172
+
173
+ [medskip]
174
+
175
+ Repeat this procedure for your internal network card, [tt vic1], using
176
+ the network address [tt 192.168.x.1] (where [tt x] is again your patch
177
+ number).
178
+
179
+ [medskip]
180
+
181
+ Before we leave this machine, start the Apache web server by typing
182
+
183
+ [command]
184
+ httpd
185
+ [end]
186
+
187
+ at the command prompt. Check the web server is running by typing
188
+
189
+ [command]
190
+ lynx 192.168.x.1
191
+ [end]
192
+
193
+ (where [tt x] is you patch number). This will launch the text-mode
194
+ browser, [tt lynx], and you should see a welcome page. If you do, all is
195
+ well and you can press [tt Ctrl+C] or type [tt q] to quit.
196
+
197
+ [h2 Setting up the Project Office Border Router]
198
+
199
+ Now we have a working web server on the headquarters network, use
200
+ [e another physical machine] to set-up an another OpenBSD image as a border
201
+ router. Remember to check the first Ethernet card is in [e Bridged] mode
202
+ and the second is in [e Host Only] mode before you try to configure the
203
+ image. You will need to configure the external address as you did the first,
204
+ and the internal network address should follow a similar pattern as well.
205
+
206
+ [h2 Checking Connections]
207
+
208
+ Patch the two border routers into the [s same] switch. First check each
209
+ border router can see the other by using the [tt ping]
210
+ command[fn The [tt ping] command should be available on any
211
+ host with a [ac TCPIP] stack. Essentially it sends an [sc icmp echo]
212
+ packet, and waits for the foreign host to send a [sc icmp echo
213
+ reply] in response. If your host sees the reply, you can usually assume
214
+ the network connection between the two hosts is working. See the
215
+ [tt ping] manual page (also in the Appendix) for more details.]. For
216
+ example, if one border router is [tt 172.20.3.1] try typing
217
+
218
+ [command]
219
+ ping 172.20.3.1
220
+ [end]
221
+
222
+ You should start to see lots of positive replies (and the connection LEDs on
223
+ the switch should also be flashing as well). When you are satisfied the
224
+ connection is working, press [tt Ctrl+C] to cancel the [tt ping]s. If
225
+ you don't get a response [e check your physical connections!]
226
+
227
+ Now try to [tt ping] the [tt internal] address of each router
228
+ [e from the router itself]. For instance a border router with the address
229
+ [tt 172.20.3.1] should have an internal address of [tt 192.168.3.1].
230
+ Thus the command
231
+
232
+ [command]
233
+ ping 192.168.3.1
234
+ [end]
235
+
236
+ should also work. You should [e not\/] be able to see the internal
237
+ address of the [e other\/] border router[fn Why not?].
238
+
239
+ [h2 Expanding the Headquarters Network]
240
+
241
+ You should now have two proto-networks, with two border routers who can
242
+ connect to each other. We will now set-up a web server on the 'headquarters'
243
+ network, demonstrating how ordinary network clients would be set-up in your
244
+ network. This is also a good test that all the previous steps are working as
245
+ expected.
246
+
247
+ Set-up another OpenBSD image on your Headquarters network, setting [e both]
248
+ virtual Ethernet cards on that image to [e Host Only] mode. This web server
249
+ is now effectively 'trapped' inside the machine: it can only communicate with
250
+ the outside world via your networks border router.
251
+
252
+ Log into the image as the [tt root] user and set-up the first Ethernet
253
+ card ([tt vic0]) to the address [tt 192.168.x.10], using you port
254
+ number for [tt x]. Start the Apache web browser using the [tt httpd]
255
+ command.
256
+
257
+ You should now be able to the web browser on this machine from the
258
+ headquarters border router. [s Check this works before going any further]!
259
+ Your web server should also be able to [tt ping] the internal address of
260
+ your border router.
261
+
262
+ Now set the border router as the default gateway[fn Most IP network
263
+ hosts have very limited routing abilities. All they can do is pass packets
264
+ [e directly] to other hosts [e on the same network]. If they need to
265
+ talk to hosts on another network, they have to pass the packet onto a (border)
266
+ router who can route the packet on that hosts behalf. This host is called the
267
+ [e default gateway], or sometime simply the [e gateway], as it acts as a
268
+ door to the rest of the network. You may also see this host referred to as the
269
+ [e host of last resort], since technically we turn to this host whenever
270
+ our routing table cannot supply the next-hop or the direct path to the host.
271
+ Routers can therefore also have a [e default gateway], as we will see in
272
+ later labs.] for this new web server, using the [tt route] command:
273
+
274
+ [command]
275
+ route add 0/0 192.168.x.1
276
+ [end]
277
+
278
+ using your patch number for [tt x]. The rather strange address
279
+ [tt 0/0] is a short-hand for 'any', and will match all networks that don't
280
+ appear in the routing table. Some versions of [tt route] (including
281
+ OpenBSD's) allow you to use the name [tt default] instead of the catch all
282
+ address. Thus we could type
283
+
284
+ [command]
285
+ route add default 192.168.x.1
286
+ [end]
287
+
288
+ Now type[fn We will use the [tt -n] option of [tt show] to
289
+ disable DNS lookups. Usually [tt route] will try to display the name of
290
+ the router, instead of the raw IP address. Since we don't have DNS enabled
291
+ yet, though, this won't work.]
292
+
293
+ [command]
294
+ route -n show | head
295
+ [end]
296
+
297
+ to look at the first 20 lines output from the [tt route show]
298
+ command[fn The [tt |] or [e pipe] is used in Unix to join two or
299
+ more commands together. The [tt route] command usually produces a lot of
300
+ text, so we pipe (or re-direct) this output to the [tt head] command which
301
+ displays only the first few lines (20 by default). We could also use the
302
+ [tt less] command to page though the output, e.g. by doing [tt route
303
+ -n show | less]. See the man pages of [tt head] and [tt less] for more
304
+ details.]. What is this output telling you?
305
+
306
+ From other machine, try to connect to the new web server? Does this work? If
307
+ not, why not (and why might it be working from the border router)?
308
+
309
+ On the border router, enable IP packet forwarding by typing
310
+
311
+ [command]
312
+ sysctl net.inet.ip.forwarding=1
313
+ [end]
314
+
315
+ Now go to another machine and try to connect to the new web server
316
+ again. Does it work this time? What might have changed?
317
+
318
+ [h2 Further Work]
319
+
320
+ [note]
321
+ The problems in this section are optional, however if you have the
322
+ time they should help you understanding of the concepts introduced in
323
+ this lab.
324
+ [end]
325
+
326
+ [h3 How do we extend the static routing tables?]
327
+
328
+ Once you have your network up and running, you should find other peoples
329
+ networks around as well. Can you connect to these networks? If not, why
330
+ not? Can you configure your router to enable you to connect to any other
331
+ available network? What steps do you need to take, and which machines
332
+ need to be reconfigured?
333
+
334
+ [h3 What path are the packets taking through the network?]
335
+
336
+ In our simple network, the path taken by the packets should be
337
+ deterministic: no router is more than one hop away from any other
338
+ router. Usually, however, more than one router is involved. The
339
+ challenge is knowing which ones; especially when you aren't getting the
340
+ results you expect.
341
+
342
+ This problem is common enough that many tools exist to help you find out
343
+ what's going on. The oldest (and therefore the easiest to find) is the
344
+ [tt tracert] ('trace route') command, details of which are available
345
+ though the [tt man] page or on the module wiki.
346
+
347
+ Investigate the use of the [tt tracert] command on the network. What
348
+ does this command tell you about the network? What problems might this
349
+ command help you to identify (or even solve)?
350
+
351
+ [h3 Finding troublesome nodes]
352
+
353
+ On the OpenBSD images, you also have the [tt mtr] command
354
+ installed as well (again see the [tt man] page). Essentially, this command
355
+ combines the [tt ping] and [tt tracert] commands. How does this
356
+ tools compare to the plain [tt tracert] command? What at the
357
+ advantages and disadvantages of using [tt mtr] instead of
358
+ [tt tracert]?
359
+
360
+ [h2 Questions]
361
+
362
+ [ol]
363
+
364
+ [item What is the purpose of using a rack system, plus patch panels
365
+ for the routers?]
366
+
367
+ [item What is the difference between a [e router] and a [e switch]?]
368
+
369
+ [item Could we use a [e switch] to connect the remote network
370
+ instead of the two border routers? Briefly justify your answer.]
371
+
372
+ [item Why are the machines acting as routers connected to each
373
+ other via a switch, rather than being directly connected together?]
374
+
375
+ [item What is the purpose of enabling IP forwarding on the OpenBSD
376
+ routers? Why might this capability be disabled by default?]
377
+
378
+ [item Look at the network addresses and masks used in this exercise. Why might
379
+ we have chosen '[tt 172.20.0.0/16]' for the [ac ISP] network and
380
+ '[tt 192.168.x.0/24]' for the project and headquarters network? What
381
+ difference does this make to the routers when making routing decisions?]
382
+
383
+ [end]
@@ -0,0 +1 @@
1
+ title: Lab 2