Changes between Version 7 and Version 8 of GEC15Agenda/AdvancedGENITopoOmni/Instructions/ClickExampleExperiment


Ignore:
Timestamp:
10/19/12 03:08:55 (12 years ago)
Author:
nriga@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC15Agenda/AdvancedGENITopoOmni/Instructions/ClickExampleExperiment

    v7 v8  
    296296That's it!  Now, let's look inside to see what's going on.
    297297
    298 == Looking under the hood ==
     298== 7. Looking under the hood ==
    299299
    300300Please note: the interface names and MAC addresses below are for the sample configuration shown in the figure above. You will want to refer to your network diagram to get the correct interfaces and addresses for your configuration.
     
    302302Let's take a look at what's happening in the four routers in your configuration. There are two basic router configurations. (You can find all of these files on any of your router hosts.)
    303303
    304 === Packet transformation ===
    305 
    306 The more interesting configuration appears here, in the '''top.click''' configuration file.
    307 
    308 {{{
     304=== 7b. Packet transformation ===
     305
     306  i. The more interesting configuration appears here, in the '''top.click''' configuration file. In a local terminal type:
     307  {{{
     308 ssh -A top "cat top.click"
     309}}}
     310  The output will look like :
     311  {{{
    309312// This portion accepts IP packets,
    310313// reformats them, and routes them
     
    343346}}}
    344347
    345 As indicated in the comments, the top portion of the configuration listens ('''!FromDevice''') for IP packets arriving on the interface connected to '''hostA''' (that's '''eth3''' in this example). It then creates a new 16-byte field at the head of the packet (two bytes added by the '''Unstrip''' operation, plus the existing 14-byte Ethernet header. It fills that field with what could be important routing instructions, but in this case is just graffiti ('''!StoreData'''). The '''route''' operation then routes the packet via either the '''left''' or '''right''' router toward '''hostB'''. In either case, it wraps the packet in a fresh Ethernet header ('''!EtherEncap''') with a distinctive ether type code (0x7744), logs the new packet on its way out ('''Print''') and sends it out on the correct interface ('''!ToDevice''').
    346 
    347 The bottom portion of the configuration is intended for packets coming out of the core network to '''hostA'''.  It accepts packets from either the '''left''' or '''right''' router, logs them, strips off thirty bytes (Ethernet header plus your 16-byte new header field), puts on a fresh Ethernet header, and sends them along to '''hostA'''.
    348 
    349 The configuration for the '''bottom''' router is exactly symmetric, routing packets between '''hostB''' and the core network, but using different graffiti.
    350 
    351 === Simple Forwarding ===
    352 
    353 The '''left''' router configuration is much simpler.  Here's the '''left.click''' file:
     348  As indicated in the comments, the top portion of the configuration listens ('''!FromDevice''') for IP packets arriving on the interface connected to '''hostA''' (that's '''eth3''' in this example). It then creates a new 16-byte field at the head of the packet (two bytes added by the '''Unstrip''' operation, plus the existing 14-byte Ethernet header. It fills that field with what could be important routing instructions, but in this case is just graffiti ('''!StoreData'''). The '''route''' operation then routes the packet via either the '''left''' or '''right''' router toward '''hostB'''. In either case, it wraps the packet in a fresh Ethernet header ('''!EtherEncap''') with a distinctive ether type code (0x7744), logs the new packet on its way out ('''Print''') and sends it out on the correct interface ('''!ToDevice''').
     349
     350  The bottom portion of the configuration is intended for packets coming out of the core network to '''hostA'''.  It accepts packets from either the '''left''' or '''right''' router, logs them, strips off thirty bytes (Ethernet header plus your 16-byte new header field), puts on a fresh Ethernet header, and sends them along to '''hostA'''.
     351
     352  The configuration for the '''bottom''' router is exactly symmetric, routing packets between '''hostB''' and the core network, but using different graffiti.
     353
     354=== 7b. Simple Forwarding ===
     355
     356The '''left''' router configuration is much simpler.  In a local terminal type:
     357{{{
     358 ssh -A left "cat left.click"
     359}}}
     360  The output will look like :
    354361
    355362{{{
     
    372379This configuration just blindly forwards packets. It picks up any packet from the '''top''' router, updates the Ethernet header, and passes it along to the '''bottom''' router. The same applies in the reverse direction.  Again, the configuration for the '''right''' router is exactly analogous.
    373380
    374 === Monitoring your core network ===
    375 
    376 Let's watch how the packets travel through the network. The terminal windows on your four router hosts show the log output from the '''Print''' statements shown above, one line per packet.
    377 
    378 Type <enter> a few times in each router window to create a space below the existing log entries, so you can identify new log messages as they appear.
    379 
    380 Now go to your window for hostA, where your '''nc''' command is still running. Type a message into this window. You should see a log message in three of your four router windows. In this example, you might see:
    381 
    382 In the '''top''' router log:
    383 {{{
     381=== 8. Monitoring your core network ===
     382
     383Let's watch how the packets travel through the network.
     384  i. In a local terminal type:
     385  {{{
     386  ssh -A top "tail -f /tmp/click.log"
     387}}}
     388  i. Go to your window for hostA, where your '''nc''' command is still running. Type a message into this window. You should see a log message in three of your four router windows. In this example, you might see:
     389  i. In the local terminal you will see:
     390  {{{
    384391outR:   76 | 000423b7 192e0004 23b71ce0 7744416c 69636557 61734865
    385392}}}
    386393
    387 This log entry says that the '''top''' router received a packet from '''hostA''', modified it, and sent it out to the '''right''' router. If the entry started with '''outL''', that would indicate that it sent the packet out to the '''left''' router. Let's look a bit at the start of the packet (the first 24 bytes are logged). It starts with an Ethernet header. The first six bytes are the MAC address of the destination interface, that's 00:04:23:B7:19:2E, the MAC address of '''eth4''' on '''right'''. The next six bytes are the MAC address of the source interface, 00:04:23:B7:1C:E0, or '''eth4''' on '''top'''. Next comes your ether type, 0x7744. The remaining bytes, "416c 69636557 61734865" are the start of the first field in your new protocol, "!AliceWasHe" in ASCII.
    388 
    389 Since this packet was routed to the right, there's an entry in the '''right''' router log. This entry indicates that a packet was received from '''top'''. The logged contents show the packet sent to '''bottom''', with rewritten MAC addresses, corresponding to '''eth5''' on '''bottom''' and '''eth5''' on '''right'''.
    390 
    391 {{{
    392 top:   76 | 000423b7 42590004 23b7192f 7744416c 69636557 61734865
    393 }}}
    394 
    395 Finally, here's the entry on '''bottom''':
    396 {{{
    397 inR:   76 | 000423b7 42590004 23b7192f 7744416c 69636557 61734865
    398 }}}
    399 
    400 It shows the same packet received from '''right'''. After logging, the packet is rewritten into IP and sent to '''hostB'''.
    401 
    402 Try typing a few different lines to hostA. You should see some packets routed to the left and some to the right. The routing decision is based on the '''route :: Classifier(27/01%01,-);''' entry in the '''top''' router configuration. Here, the router is looking at the low-order bit of the checksum on the initial IP packet (now at byte position 27 with the addition of the new sixteen byte field at the start of the header). Packets with odd checksums go to the left; those with even checksums go right.
    403 
    404 Try typing a few lines to hostB. You should see similar behavior, but starting from '''bottom''' and working up. You'll also see the different value inserted in the new header field.
    405 
    406 == Clean up ==
     394  This log entry says that the '''top''' router received a packet from '''hostA''', modified it, and sent it out to the '''right''' router. If the entry started with '''outL''', that would indicate that it sent the packet out to the '''left''' router. Let's look a bit at the start of the packet (the first 24 bytes are logged). It starts with an Ethernet header. The first six bytes are the MAC address of the destination interface, that's 00:04:23:B7:19:2E, the MAC address of '''eth4''' on '''right'''. The next six bytes are the MAC address of the source interface, 00:04:23:B7:1C:E0, or '''eth4''' on '''top'''. Next comes your ether type, 0x7744. The remaining bytes, "416c 69636557 61734865" are the start of the first field in your new protocol, "!AliceWasHe" in ASCII.
     395
     396  Try typing a few different lines to hostA. You should see some packets routed to the left and some to the right. The routing decision is based on the '''route :: Classifier(27/01%01,-);''' entry in the '''top''' router configuration. Here, the router is looking at the low-order bit of the checksum on the initial IP packet (now at byte position 27 with the addition of the new sixteen byte field at the start of the header). Packets with odd checksums go to the left; those with even checksums go right.
     397
     398== 9. Clean up ==
    407399
    408400When you're done, please release your resources so they'll be available to others.
    409401
    410402{{{
    411 omni.py deletesliver -a http://www.emulab.net/protogeni/xmlrpc/am StupidSliceName
    412 }}}
    413 
    414 == Moving forward with your experiment ==
    415 
    416 This sample experiment is just a very simple demonstration of how to run a Click-based routing configuration using ProtoGENI. For a more meaningful experiment, you may want to try some of the variations described below. We'd love to hear what you're doing with Click and GENI, and we're here to help. Please let us know at [mailto:help@geni.net].
    417 
    418 === Improved routing ===
    419 
    420 Instead of writing "!AliceWasHere" in your packets, perhaps include some real routing instructions. Modify the Click configurations to route packets accordingly.
    421 
    422 === Richer topology ===
    423 
    424 Incorporate additional hosts into a core network topology that's more interesting than a simple diamond.
    425 
    426 === Improved performance with kernel-level Click ===
    427 
    428 The Click router supports kernel-level operation. The principles are the same, but the setup is a bit more involved. To use kernel-level Click, you will probably want first to develop and debug your setup at the user level. Drop us a line at [mailto:help@geni.net] for help setting up Click in kernel mode.
    429 
    430 === Wide-area routing ===
    431 
    432 Modify your rspec to include some ProtoGENI hosts on the Internet2 backbone or at multiple ProtoGENI sites. Additional information available at http://protogeni.net or [mailto:help@geni.net].
     403omni.py deletesliver -a pg-utah <slicename>
     404}}}