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.
- data/.document +5 -0
- data/.rvmrc +27 -0
- data/Gemfile +51 -0
- data/Gemfile.lock +61 -0
- data/HISTORY +16 -0
- data/LICENSE +13 -0
- data/README.rdoc +20 -0
- data/Rakefile +100 -0
- data/VERSION +1 -0
- data/bin/whitecloth +49 -0
- data/lib/LICENSE +20 -0
- data/lib/WhiteCloth.rb +24 -0
- data/lib/whitecloth/cli/base.rb +102 -0
- data/lib/whitecloth/cli/commands/bootstrap.rb +103 -0
- data/lib/whitecloth/cli/commands/help.rb +106 -0
- data/lib/whitecloth/cli/commands/show.rb +87 -0
- data/lib/whitecloth/cli/commands.rb +29 -0
- data/lib/whitecloth/cli/logger.rb +88 -0
- data/lib/whitecloth/cli.rb +29 -0
- data/test/data/bayeux/Labs/Lab1/L1_Internet.byx +536 -0
- data/test/data/bayeux/Labs/Lab1/L1_Internet.yaml +1 -0
- data/test/data/bayeux/Labs/Lab2/L2_StaticR.byx +383 -0
- data/test/data/bayeux/Labs/Lab2/L2_StaticR.yaml +1 -0
- data/test/data/bayeux/Labs/Lab3/L3_DNS.byx +943 -0
- data/test/data/bayeux/Labs/Lab3/L3_DNS.yaml +1 -0
- data/test/data/bayeux/Labs/Labs.byx +1 -0
- data/test/data/bayeux/Labs/Labs.yaml +1 -0
- data/test/data/bayeux/Resources/Resources.byx +91 -0
- data/test/data/bayeux/Resources/Resources.yaml +1 -0
- data/test/data/bayeux/Welcome.byx +49 -0
- data/test/data/bayeux/Welcome.yaml +1 -0
- data/test/data/data_test.rb +29 -0
- data/test/dir_walk/create_witness_test.rb +39 -0
- data/test/init_test.rb +26 -0
- metadata +268 -0
@@ -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
|