1510 LabManual OPNK2004

1510 Understanding IP Model Internals and Interfaces Lab
1510: Understanding IP Model Internals and Interfaces Lab 1: Building a simple Layer-3 encryption de ice
! er ie"
Your job is to build a device that implements Layer-3 encryption. The requirements are to model encryption and decryption delays and encryption overhead in terms of packet size. Packets must be selectively encrypted based on destination address and port information.
!b#ecti es
. !se the IP address API to construct "P address ran#es from address and subnet mask strin#s. $. %btain socket information &address' protocol' port( from an "P data#ram. 3. )heck if a packet destination falls *ithin an address ran#e. +. ,odel packet size and delay overhead accordin# to user confi#uration. -. .erify correct operation by runnin# a simulation.
$escription
The encryption device contains one processor and t*o transceivers. The node model is already built and available for use. The device is a standalone node. "t can encrypt/decrypt packets of any technolo#y &0thernet' PPP' etc.( "t can be connected to other devices &host nodes' routers' etc.( usin# point-to-point links such as PPP links' 1baseT 0thernet links' etc.
CONFIDENTIAL INFORMATION: DO NOT DISCLOSE, FORWARD, DISTRIBUTE, SHARE, OR MAKE COPIES OF THIS DOCUMENT IN WHOLE OR IN PART. Copyrigh !""# OPNET T$%h&o'ogi$(, I&%.
P)g$ * o+ ,!
Traffic comin# in from one port is sent out on the other port. The node has an 20ncryption "nformation3 attribute defined on it *here the user can specify encryption delay and byte overhead' and a list of destination addresses and ports. %nly traffic bound for these destination addresses and ports must be encrypted. Your job is to add code to the process inside the 2crypto3 module to read the confi#ured attributes and use these attributes to perform encryption. "n the interest of time' some code has already been added to the process. You *ill be fillin# the #aps.
Instructions
4%T05 "f you do not *ant to do the steps but just *ant to follo* alon#' please use the _ref version of the project' node and process models. Inspect the parameters for encryption . 6tart ,odeler. $. %pen the node model 1510_crypto_device. a. !se File / Open (Node Model) / 1510_crypto_device. b. The model is present in the !"op_#odels directory. 3. 07amine the node attribute $ncryption Infor#ation. a. "n the node model' click on Interfaces / Model Attri%&tes. b. "n the model attributes dialo# bo7' double-click on the 'efa&lt (al&e cell of the $ncryption Infor#ation attribute.
P)g$ ! o+ ,!
c. 4otice that the user can specify encryption and decryption delays as *ell as the byte overhead.
d. 8ouble-click on the (al&e cell of the 'estination Infor#ation attribute.
e. 4otice that the user can specify destination address' mask' port and protocol values. 9ny packet matchin# all these values must be encrypted. f. )lose all open dialo# bo7es by clickin# on the ancel button. Read the encryption parameters into the process model +. 8ouble-click the crypto module in the node model. This *ill open the process model crypto_1510.
P)g$ - o+ ,!
a. The process contains a forced state called 6tart. The encryption parameters are read in this state. Then the process *aits in the :ait state. "f an unencrypted packet arrives at the node' the process invokes the function encrypt;pkt &(' *hich encrypts the packet if it meets the confi#ured encryption criteria. "f an encrypted packet arrives at the node' then the function decrypt;pkt &( is invoked' *hich decrypts the packet. -. %pen the $nter $)ecs of the *tart state. a. 8ouble-click on the top portion of the *tart state.
<. )ode has already been added to read the encryption delay and size overhead specification &lines = > $$(.
=. ?ead the "P address strin# and convert it into the "netT;9ddress structure. a. 9fter the comment 21510! +ead t,e IP address attri%&te3 &around line 33( add the follo*in# lines5
op_ima_obj_attr_get_str (dest_objid, "Address", 64, addr_str);
P)g$ # o+ ,!
addr = inet_address_create (addr_str, InetC_Addr_Family_ n!no"n);
The dest_o%-id variable is the object "8 of the 'estination Infor#ation attribute. The variable addr_str contains the confi#ured "P address in the strin# form. The return value addr is the "P address in the Inet._Address format. b. 6ince *e do not kno* the address family at the time of parsin# the strin#' *e can use Inet _Addr_Fa#ily_/n0no1n as the second ar#ument. The function inet_address_create () *ill determine *hether the address is .+ or .< based on the contents of the strin#. @. %bserve the *&%net Mas0/Prefi) 2en3t, attribute bein# read belo* this code. "f the user has entered an "Pv+ address' then it is assumed that the user has entered the subnet mask in the standard "P notation. Aence if the address family is .+' then the subnet mask is translated usin# ip_address_create (). %n the other hand' if the user has entered an "Pv< address in the address field' then he/she is e7pected to enter the mask as a prefi7 len#th inte#er. "n this case' the function atoi () is used to translate the strin# into a prefi7 len#th. This is an illustration of ho* model code can be *ritten to *ork *ith both "Pv+ and "Pv< confi#uration.
B. "ncomin# packets are checked to see if they fall in the address ran#e specified by this address and subnet mask. To facilitate easy checkin#' combine the address and mask to create a sin#le address ran#e data structure. a. 9fter the comment 21510! reate destination address ran3e fro# address and #as03 &around line <+(' add the follo*in# line.
dest_in#o_ptr$%addr_range = inet_address_range_create (addr, mas!);
1. %bserve ho* the port and protocol values are bein# read into inte#er fields belo* this code &around line = (.
. 6ave the chan#es. a. )lick on File / *ave.
P)g$ , o+ ,!
Check if incoming packet is eligible for encryption $. "n the $)it $)ecs of the 4ait state' code has already been added to see if an incomin# packet is encrypted or not. a. 0ncrypted packets are identified by a special field in the packet &04)?YPT08;CL9D;%?"D;6"E0;C8;"480F(.
3. %pen the f&nction %loc0 of the process by clickin# on the F5 icon. +. The first function is named pac0et_is_eli3i%le_for_encryption (). This is the function to *hich *e *ill be addin# code. -. ?etrieve the socket information of the packet. a. 9fter the comment 21510! +ead soc0et infor#ation fro# pac0et3 &around line $(' add the follo*in# line.
ip_s&pport_ip_p!t_soc!et_in#o_e'tract (p!ptr, (soc!et_in#o);
b. 4otice ho* a sin#le function can be used to di# into both !8P and T)P packets to retrieve port information. <. !ser may have specified multiple encryption destinations. :e check a#ainst all the destinations in a for loop. =. %bserve the port and protocol checks &around lines 3 > 3<(. @. 9dd the address ran#e check. a. 9fter the comment 21510! ,ec0 pac0et destination a3ainst confi3&red address ran3e3 &around line 3@(' add the follo*in# line.
matc)_#o&nd = inet_address_range_c)ec! (soc!et_in#o*dest_address, (dest_in#o_ptr$%addr_range);
Model encryption and decryption delay and size overhead B. The functions to model encryption and decryption have already been *ritten. $1. %bserve the three operations performed in the function encrypt_p0t () &around line -3 in the function block(. a. %ri#inal size &before encryption( is stored in a special field in the packet. i. The special field identifies this packet as an encrypted packet. ii. The ori#inal size is used by the decryptor node to set the packet size back to its ori#inal value. b. The encryption overhead is added to the total size of the packet usin# the kernel procedure op_p0_total_si6e_set ().
P)g$ . o+ ,!
c. The encryption delay is modeled by sendin# the packet out after a finite delay usin# the kernel procedure op_p0_send_delayed ().
$ . %bserve the three operations performed in the function decrypt_p0t (). a. 6ize of the packet is restored to its ori#inal value. b. 6pecial field identifyin# this packet as an encrypted packet is stripped from the packet. c. Packet is sent out after a decryption delay.
$$. )lose the function block and save the chan#es in the process model. a. !se File / *ave to close the function block. b. !se File / *ave to save the process model. c. !se o#pile / o#pile ode to compile the process model.
Verify the correct operation of the encryption device in a simulation $3. %pen the project 1510. a. !se File / Open (Pro-ect) / 1510. b. The project is present in the !"op_#odels directory. c. The project should open in the scenario 2a%_1.
P)g$ / o+ ,!
$+. 6cenario description a. There are three hosts' t*o of *hich belon# to the same corporation and one that belon#s to an e7ternal net*ork. b. The "P addresses of the hosts are indicated in the names. c. Three traffic flo*s are confi#ured from the device B+; 1; ; Gt*o #oin# to the outside host 3-; 11;$1; ' and one #oin# to B+; =1;31; . . Crom the top menu' click on .raffic / Open Flo1s 5ro1ser. $. "n the tree-vie* on the left-hand side' navi#ate to the flo*s ori#inatin# from B+; 1; ; . 3. Ai#hli#ht any of the flo*s to vie* the traffic profile in bits/sec and packets/sec.
P)g$ 0 o+ ,!
+. 0ach of these flo*s #enerates traffic of $11 bits/sec at the rate of -. )lose the flo*s bro*ser *hen done.
packet/sec.
d. You *ill confi#ure the device rypto 1 to encrypt traffic correspondin# to only one of the three flo*s' viz. the flo* named *ec&re .raffic. e. You *ill confi#ure the device rypto 1 to add an encryption overhead of =- bytes &<11 bits( to each packet that matches the encryption criteria. 7&estion! 4,at is t,e e)pected traffic on t,e lin0 %et1een t,e so&rce node (189_10_1_1) and t,e encryption device ( rypto 1): and on t,e lin0 %et1een t,e encryption device ( rypto 1) and t,e ro&ter (;ate1ay 1)< $-. )onfi#ure encryption parameters on rypto 1. a. ?i#ht-click on rypto 1 and choose $dit Attri%&tes. b. 07pand the $ncryption Infor#ation attribute by clickin# on the plus &H( si#n to its left. c. 6et the delays and overhead as sho*n.
P)g$ 1 o+ ,!
d. 6ince *e *ish to encrypt only traffic correspondin# to the flo* named *ec&re .raffic' *e must first e7amine its socket information. e. Leave the attributes dialo# bo7 of the crypto device as it is' and ri#ht-click on the flo*s #oin# from B+; 1; ; to 3-; 11;$1; . f. 6elect $dit Attri%&tes option on the *ec&re .raffic flo*.
#. 07pand the *oc0et Infor#ation attribute by clickin# on the &H( si#n. h. %bserve that this is a /'P traffic flo* bound for the port =000.
P)g$ *" o+ ,!
i. )lose the $dit Attri%&tes dialo# bo7 for the flo* by clickin# on ancel. j. %n the node rypto 1' add the destination information of the packets to be encrypted. . )ome back to the rypto 1 Attri%&tes dialo# bo7. $. 8ouble-click on the (al&e column of the 'estination Infor#ation attribute.
3. 6et the number of ro*s in the table to ' and press $nter.
+. 6et the fields of 'estination Infor#ation as follo*s5
k. )lick O> on all open bo7es to save chan#es. $<. 07amine the encryption confi#uration on rypto =.
P)g$ ** o+ ,!
a. ?i#ht-click on rypto = and select $dit Attri%&tes. b. 4otice that only 'ecryption 'elay is confi#ured.
c. )lose the dialo# bo7. $=. ?un the simulation by clickin# on '$* / +&n 'iscrete $vent *i#&lation. $@. .erify that only one traffic flo* is #ettin# encrypted. a. 07pected results Total traffic on link before encryption &189_10_1_1 ? rypto 1( is 3<11 bits/sec &3 traffic flo*s at $11 bits/sec each(. 0ncryption adds <11 bits to each packet and there is packet per second for the 6ecure Traffic flo*. 6o traffic must increase by <11 bits/sec. %ther t*o flo*s are not encrypted. Total traffic on link after encryption must be +$11 bits/sec. 6ince encryption delay on rypto 1 and decryption delay on rypto = are both set to 1.$ sec' the end-to-end delay for *ec&re .raffic must be at least 1.+ seconds #reater than the end-to-end delay for lear .e)t traffic.
b. %pen the result panels by clickin# on '$* / Panel Operations / Arran3e Panels / *,o1 All. c. Load the panels *ith the latest results by clickin# on '$* / Panel Operations / Panel .e#plates / 2oad 4it, 2atest +es&lts. d. %bserve that the packets/second traffic on the t*o links &189_10_1_1 ? rypto 1 and rypto 1 ? ;ate1ay 1( is the same but the bits/sec differs by the e7pected amount &I<11 bits/sec(.
P)g$ *! o+ ,!
e. %bserve that the end-to-end delay for *ec&re .raffic is about 1.+ seconds hi#her than the end-to-end delay for lear .e)t.
%onclusion
"n this lab' you have . !sed the "P address 9P" to parse "P address strin#s' create "P address ran#es and to check *hether a #iven address falls in a #iven ran#e &steps ='B and @(.
P)g$ *- o+ ,!
$. !sed the "P socket 9P" to e7tract source and destination address' port and protocol information from an "P data#ram &step -(. 3. 6een the use of kernel procedures from the packet packa#e to model encryption overheads and delays &steps $ and $$(. +. .erified the correct operation of the encryption device in a simulation &steps $+ > $@(.
&'$ of L(B1
P)g$ *# o+ ,!
Lab ): Building an ad anced encryption de ice "it* routing capabilities ! er ie"

"n this lab' you *ill build an encryption #ate*ay that can perform both routin# and encryption. 9s in the previous lab' encryption delays and size overhead *ill be modeled. Packets *ill be chosen for encryption based on 9ccess )ontrol Lists &9)Ls(. 9lso' ,T! checks *ill be performed to determine *hether the encrypted packet *ill #et fra#mented due to the increase in size.
!b#ecti es
. !se the IP A 2 API to match incomin# packets to 9ccess )ontrol Lists. $. !se the o##on +o&te .a%le API to determine out#oin# interface of a packet. 3. !se the Interface .a%le API to determine the ma7imum transmission unit &,T!( size on the out#oin# interface. +. !se the IP address API to create strin#s from addresses &for display(. -. .erify correct operation by runnin# a simulation.
$escription
The encryption device built in the previous lab had only t*o interfaces and did not have any routin# capability. "n this lab' *e *ill add encryption capability to a router that contains multiple interfaces so that it can act as an 2encryption #ate*ay3. 9lso' *e *ill allo* for more complicated selection criteria for packets to be encrypted. 4ormal routers use various kinds of access lists to enforce security and administrative policies. "n this lab' *e *ill support the use of these 9)Ls to determine *hich packets must be encrypted. 9nother improvement over the previous lab is the detection of packet fra#mentation. 6ince encryption increases the size of the "P data#ram' the packet may #et fra#mented if the out#oin# interface does not support an ,T! of sufficient size. 6ince the model is not equipped to handle packet fra#mentation' *e *ill detect this condition and drop packets that e7ceed the ,T! size.
Instructions
4%T05 "f you do not *ant to do the steps but just follo* alon#' replace the process model ip_rte_central_cp& *ith its _ref version. You can do this by openin# the process model ip_rte_central_cp&_ref in !"op_#odels and savin# it as ip_rte_central_cp& in the same directory.
P)g$ *, o+ ,!
Inspect the parameters for encryption . %pen the node model 1510_crypto_ro&ter. a. !se File / Open (Node Model) / 1510_crypto_ro&ter. b. The model is present in !"op_#odels. $. 07amine the node attribute $ncryption Infor#ation. a. "n the node model' click on Interfaces / Model Attri%&tes. b. "n the model attributes dialo# bo7' double-click on the 'efa&lt (al&e cell of the $ncryption Infor#ation attribute.
c. 9s in the previous lab' notice that the user can specify encryption and decryption delays' as *ell as the byte overhead.
d. 8ouble-click on the (al&e cell of the Pac0et lassification attribute.
e. 4otice that the user can specify multiple 9)L names a#ainst *hich incomin# packets are matched. f. )lose all open dialo# bo7es by clickin# on the ancel button' and close the node model. Read the encryption parameters into the process 3. The encryption #ate*ay is a device that uses central processin#. 9s described in the presentation' the process that handles incomin# packets in a router *ith central processin# is ip_rte_central_cp&. +. %pen the process model ip_rte_central_cp&.
P)g$ *. o+ ,!
a. !se File / Open (Process Model) / ip_rte_central_cp&. b. The file is present in !"op_#odels. -. %pen the function block by clickin# on the F5 icon. <. The function that reads in the confi#uration on the node is called ip_1510_encryption_info_read () and is defined on line <13. =. %bserve the code that reads the delays and overhead &lines <$- > <31(.
@. 9dd the follo*in# code belo* the comment 21510! +ead in A 2 na#e and resolve it3 &line <+ (.
op_ima_obj_attr_get_str (acl_objid, "AC+ ,ame", 64, attr_str); acl_ptr = Inet_Acl_Filter_-et (mod&le_data_ptr, attr_str, I.C_AC+_/0.1_A++); i# (acl_ptr 2= 3.C_,I+) op_prg_list_insert ((ip_4546_in#o_ptr$%acl_list, acl_ptr, 3.C_+I7/.37_/AI+);
Check incoming packets against ACLs B. The control flo* *hen this process model receives a packet is described belo*. a. The packet is first handled by the function ip_rte_central_cp&_pac0et_arrival &defined from line $+ in the function block(. b. "f the router is an encryption #ate*ay' this function calls ip_1510_encryption_process &defined around line <<+(. c. To check if an incomin# packet is eli#ible for encryption' this function calls ip_1510_pac0et_is_eli3i%le_for_encryption. d. To check if an encrypted packet is bi##er than the ,T! size on the out#oin# interface' the ip_1510_encryption_process function calls ip_1510_p0t_si6e_c,ec0. e. You *ill be addin# code to ip_1510_pac0et_is_eli3i%le_for_encryption and ip_1510_p0t_si6e_c,ec0 functions. 1. %pen the function block' and #o to the function. ip_1510_pac0et_is_eli3i%le_for_encryption: defined around line == .
P)g$ */ o+ ,!
. 4otice that this function loops throu#h all defined 9)Ls and matches the packet a#ainst them until a match is found. $. 9dd the follo*in# code belo* the comment 21510! Matc, inco#in3 pac0et a3ainst A 23 &around line =@=(.
matc)_#o&nd = Inet_Acl_Apply_.ac!et (mod&le_data_ptr, acl_ptr, p!ptr, 3.C_,I+, 3.C_,I+, 3.C_,I+, 3.C_,I+); a. The last four ar#uments are necessary only if fire*all filters are bein# used. "n this lab' *e are handlin# only ordinary e7tended 9)Ls. 6o the last four attributes can be set to %P);4"L.
Check size of packet against outgoing interface MT 3. The function that performs this ,T! check is called ip_1510_p0t_si6e_c,ec0 () and is defined around line @1$. +. "n order to determine the out#oin# interface of the packet' a route table lookup is needed. -. 9dd the follo*in# code after the comment 21510! 'o a ro&te ta%le loo0&p to find o&t t,e o&t3oin3 interface.3 &around line @$+(.
<. Crom the out#oin# port information' the ,T! needs to be determined. =. 9dd the follo*in# code after the comment 21510! O%tain M./ of o&t3oin3 interface3 &around line @+3(.
int#_tbl_inde' = ip_rte_int#_tbl_inde'_#rom_port_in#o_get (mod&le_data_ptr, port_in#o); int#_ptr = inet_rte_int#_tbl_access (mod&le_data_ptr, int#_tbl_inde'); int#_mt&_bits = 8 9 ip_rte_int#_mt&_get (int#_ptr);
@. "f the interface ,T! is less than the packet size' *e need to print a messa#e to the console in *hich *e need to display the out#oin# interface name and the "P address of the destination. 9dd the follo*in# code after the comment 21510! O%tain interface na#e and pac0et destination address strin33 &around line @< (.
int#_name = ip_rte_int#_name_get (int#_ptr); inet_address_print (dest_addr_str, p!_#d_ptr$%dest_addr);
B. )lose the function block' and save the chan#es in the process model.
P)g$ *0 o+ ,!
$1. )ompile the process model by clickin# on o#pile / o#pile ode. Verify the correct operation of the encryption device in a simulation $ . Do to the scenario 2a%_= in the project 1510. $$. The net*ork topolo#y and traffic confi#uration is similar to 2a%_1. $3. There are t*o additional traffic flo*s called 5i3 Pac0ets and *#all Pac0ets' confi#ured from @5_100_=0_1 to 189_1A0_@0_1. You can e7amine these flo*s by openin# the flo*s bro*ser from the .raffic menu. $+. )onfi#ure the encryption information on ;ate1ay 1. a. ?i#ht-click on ;ate1ay 1 and select $dit Attri%&tes. b. 8efine an e7tended 9)L to match packets destined to 3-. 11.$1. port $111 and protocol !8P. . Do to the attribute IP / IP +o&tin3 Para#eters / $)tended A 2 onfi3&ration and double-click on the (al&e cell.
$. 9dd a ro* *ith the list name *ec&re .raffic and double-click on the 2ist onfi3&ration cell.
P)g$ *1 o+ ,!
3. 9dd a ro* to the 2ist onfi3&ration table and set the Action to Per#it and the protocol to !8P.
+. 8ouble-click on the *o&rce field and set the source address and *ildcard &inverse of subnet mask(' and click on O> to close the bo7.
-. 8ouble-click on the 'estination field and set the destination address and *ildcard' and click on O> to close the bo7.
<. 8ouble-click on the Port onfi3&ration field and confi#ure a destination port of $111' and click on %J to close the bo7.
P)g$ !" o+ ,!
=. )lick on O> to close the 2ist onfi3&ration and the $)tended A 2 onfi3&ration tables. c. 4o*' refer to this 9)L in the $ncryption Infor#ation table. d. 07pand the $ncryption Infor#ation attribute by clickin# on the &H( si#n. . 8ouble-click on the (al&e cell of the $ncryption Infor#ation / Pac0et lassification attribute.
$. 9dd a ro* to the A 2 Na#e table and type in the strin# *ec&re .raffic.
e. )lose the Pac0et lassification dialo# bo7 by clickin# O>. $-. 6et the encryption delay to 1.$ seconds and the encryption overhead to =- bytes &same values as in Lab; (.
P)g$ !* o+ ,!
$<. )lose the ;ate1ay 1 Attri%&tes dialo# bo7 by clickin# on O>. $=. 6imilar confi#uration is present on ;ate1ay = and can be e7amined by editin# its attributes. $@. 07amine the traffic specification of the t*o flo*s from 3-; 11;$1; to B+; =1;31; . a. ?i#ht-click on each flo*' select $dit Attri%&tes: and e7amine .raffic (%its/second) and .raffic (pac0ets/second). b. *#all Pac0ets is confi#ured to send $11 bits/sec at the rate of c. 2ar3e Pac0ets is confi#ured to send <11 bits/sec at the rate of packet/sec. packet/sec.
d. The encryption overhead on ;ate1ay = is also equal to <11 bits &=- bytes(. e. Takin# the encryption overhead into account' the size of one small packet *ill be @11 bits' *hereas the size of one lar#e packet *ill be $$11 bits. f. The ,T! of all interfaces on ;ate1ay = is equal to -11 bytes & $111 bits(. . To verify this' ri#ht-click on ;ate1ay =: and select $dit Attri%&tes. $. Do to IP / IP +o&tin3 Para#eters / Interface Infor#ation and click on the (al&es field. 3. %bserve that the M./ column for all interfaces is set to $t,ernet or IP. +. )lick on any of the M./ cells and then click the 'etails button at the bottom left corner of the bo7. -. Koth $t,ernet and IP symbols have a value of -11 bytes & $111 bits(. #. Crom the above information' it is clear that the lar#e packets *ill #et dropped due to insufficient ,T!. $B. )lose all open dialo# bo7es. 31. ?un the simulation by clickin# on '$* / +&n 'iscrete $vent *i#&lation. 3 . 9 console *indo* *ill open up and you should see a messa#e indicatin# that encrypted packet *ill be dropped since the ,T! on the out#oin# interface is less than the packet size. 3$. 9fter the simulation ends' hit $nter in the console *indo* to close it. 33. )lose the simulation sequence dialo# bo7. 3+. Krin# up all the result panels by clickin# on '$* / Panel Operations / Arran3e Panels / *,o1 All. 3-. Load the panels *ith latest results by clickin# on '$* / Panel Operations / Panel .e#plates / 2oad 4it, 2atest +es&lts. 3<. Crom the #raph for packets/second' you can see that the link ;ate1ay = ? @5_100_=0_1 has a traffic of $ packets/second' *hereas the link Internet ? ;ate1ay = has only one packet/second. This is e7pected because all traffic from the 5i3 Pac0ets flo* is dropped.
P)g$ !! o+ ,!
3=. Crom the #raph for bits/second' it can be seen that the link ;ate1ay = ? @5_100_=0_1 has traffic from both the flo*s & $111H bits/sec( *hereas the link Internet ? ;ate1ay = has traffic from only one of the flo*s' *ith encryption overhead & $11 H <11 L @11 bits/sec(.
3@. You can verify that the results for *ec&re .raffic and lear .e)t flo*s are the same as the previous scenario by #oin# to '$* / (ie1 +es&lts and e7aminin# the results of interest.
%onclusion
"n this lab' you have
P)g$ !- o+ ,!
. !sed the "P 9)L 9P" to read in 9)L specification' and use this 9)L specification to match packets based on various criteria like source/destination address' source/destination ports and protocol &steps @' $(. $. !sed the "P ?oute Table 9P" to obtain the out#oin# interface for a packet &step -(. 3. !sed the "P interface table 9P" to retrieve information about an interface' such as interface ,T! and name &steps =' @(. +. !sed the "P address 9P" to create strin#s from "P address structures &step @(. -. .erified the correct operation of the encryption #ate*ay by runnin# a simulation &steps $ > $@(.
&'$ of L(B )
P)g$ !# o+ ,!
(dditional Labs
The follo*in# t*o labs have been added to the proceedin#s in order to illustrate the tasks involved in interfacin# custom lo*er and hi#her layers to "P. These labs *ere not present in session - 1 durin# %P40T:%?J $11+. The files related to these labs are present in the 2"nterfacin#3 sub-folder in the session - 1 folder. You *ill need to copy the files from this folder to )5Mop;models in order to run these labs.
Lab 1: Interfacing a %ustom Lo"er Layer to IP

! er ie"
The %P40T "P model has an open 9P" that allo*s any custom ,9) layer to interface *ith "P. "n this lab *e *ill interface a simple ,9) layer to "P.
!b#ecti es
. "nterface the simple;mac ,9) model to "P. $. !se a test net*ork to verify proper operation.
Instructions
+andling a pac,et from IP Aandlin# a packet from "P involves the follo*in# steps "dentify an "P packet 8etermine the destination ,9) address to *hich the packet needs to be sent 0ncapsulate the "P data#ram in a ,9) packet *ith the appropriate header 6end the ,9) packet to the transmitter
P)g$ !, o+ ,!
Identifying an IP pac,et
:hen the simple;mac process model receives a stream interrupt' it needs to decide *hether the packet is from the 9?P layer or from the receiver. This is done based on the input stream inde7. ?efer to the transition macros .AC:1/_F;3<_I. and .AC:1/_F;3<_,/=: defined in the Aeader block of the process model. The relevant lines are reproduced belo*.
>99999 /ransition <acros 999999> (in_strm == 7<C_I,_7/;<_I,@1A_F;3<_A;.)
?de#ine .AC:1/_F;3<_I.
?de#ine .AC:1/_F;3<_,/=: (in_strm == 7<C_I,_7/;<_I,@1A_F;3<_;CB) >9 <acro corresponding to stream indices ?de#ine 7<C_3 /_7/;<_I,@1A_/3_A;. ?de#ine 7<C_3 /_7/;<_I,@1A_/3_A</ ?de#ine 7<C_I,_7/;<_I,@1A_F;3<_A;. ?de#ine 7<C_I,_7/;<_I,@1A_F;3<_;CB 6 4 6 4 9>
4ote5 The stream indices do not have to hard coded like this. "nstead the ,9) process can perform a #raph *alk at initialization and determine these values and store them as state variables. This approach *as not used for this lab for the sake of simplicity.
$etermining t*e destination M(% address
0very packet from the 9?P layer *ill have an ")" of type ip;mac;req associated *ith the stream interrupt. The destination address of the packet *ill be specified in the dest;addr;field of the ")". 4ote that since the 9?P module reuses the ")"' the ,9) layer 6A%!L8 4%T destroy the ")" after handlin# the packet.
P)g$ !. o+ ,!
%oding c*anges
Make the necessary coding changes to handle a packet from I! 3. %pen the function block of the simple;mac process model +. 6croll do*n to the si#ple_#ac_pac0et_fro#_ip_,andle function &line 1-( -. 0dit the function as follo*s. &Lines to be added are in %old( FI, (simple_mac_pac!et_#rom_ip_)andle (ip_p!ptr)); >9 -et t)e ici associated "it) t)e interr&pt* /)e >9 destination address o# t)e pac!et "ill be speci#ied >9 in t)e ici* arp_ici_ptr = op_intrpt_ici (); 9> 9> 9>
>9 -et t)e destination address #rom t)e ici* 9> op_ici_attr_get (arp_ici_ptr, "dest_addr", &dest_addr); >9 .rint a trace <essage 9> i# (7<C_+/;AC1_AC/IB1) C sprint# (msg, "@estination AddressD Ed", dest_addr); op_prg_odb_print_major (";eceiFed a .ac!et #rom I.", msg, 3.C_,I+); G >9 Create t)e <AC .ac!et* mac_pkptr = op_pk_create_fmt ("simple_mac"); 9>
>9 7et t)e so&rce and dest addresses in t)e pac!et 9> op_pk_nfd_set (mac_pkptr, "source address", my_address); op_pk_nfd_set (mac_pkptr, "dest address", dest_addr); >9 1ncaps&late t)e I. @atagram in t)e <AC .ac!et op_pk_nfd_set (mac_pkptr, "data", ip_pkptr); >9 7end t)e pac!et o&t to t)e transmitter* op_pk_send (mac_pkptr, SMC_O !_S!"M_#$%&'_!O_'M!); F3 /; 9> 9>
P)g$ !/ o+ ,!
-ending a pac,et to IP The ,9) process receives a packet from the net*ork' it decapsulates the "P packet from the ,9) packet and sends it to the 9?P module. 4o ")"s are involved here. "n the simple;mac process model this is performed in the function simple;mac;packet;from;nt*k;handle. &4o need to make any codin# chan#es( FI, (simple_mac_pac!et_#rom_nt"!_)andle (mac_p!ptr)); >9 @ecaps&late t)e I. datagram #rom t)e pac!et* op_p!_n#d_get (mac_p!ptr, "data", (ip_p!ptr); >9 .rint a trace <essage i# (7<C_+/;AC1_AC/IB1) C >9 -et t)e so&rce address #rom t)e pac!et op_p!_n#d_get (mac_p!ptr, "so&rce address", (so&rce_address); sprint# (msg, "7o&rce AddressD Ed", so&rce_address); op_prg_odb_print_major (";eceiFed a .ac!et #rom t)eH I,et"or!", msg, 3.C_,I+); G >9 7end t)e pac!et to t)e )ig)er layer* op_p!_send (ip_p!ptr, 7<C_3 /_7/;<_I,@1A_/3_A;.); >9 @estroy t)e <AC pac!et* op_p!_destroy (mac_p!ptr); F3 /;
-a e and compile t*e process model
9> 9> 9>
9> 9>
<. 6ave and compile the process model "f you are havin# problems in compilation' you may a. )lose the process model b. %pen the simple;mac;ref process model c. 6ave it as simple;mac d. ?ecompile
P)g$ !0 o+ ,!
.est net"or,
!pen t*e test pro#ect
:e *ill no* use a simple net*ork to make sure that the ,9) layer is *orkin# correctly. %pen the project *ession_1510_la%_1. "f you did not make the codin# chan#es to the simple;mac process model' you may use the *ession_1510_la%_1_ref project. The project should open up in the scenario named simple;pin#;net*ork.
'et"or, $escription
The net*ork consists of t*o nodes of type simple;mac;*kstn connected to each other. 9 pin# demand has also been confi#ured from *kstn; to *kstn;$. Koth the ,9) and the "P addresses on both the nodes are set to 9uto 9ssi#ned. The simulation "P auto addressin# packa#e *orks *ith custom *ireline ,9) layers also.
P)g$ !1 o+ ,!
Run the simulation in odb =. )lick on the onfi3&re/+&n si#&lation action button @. "n the tree vie* on the left' #o to $)ec&tion/OPN$. 'e%&33er B. )heck the N/se OPN$. *i#&lation 'e%&33er (O'5)O checkbo7 in the ri#ht panel 1. )lick +&n Change the debug "indo" properties . 9 debu# console should appear *ith 2odbP3 prompt after initialization $. ?i#ht-click on the title-bar of the console' edit properties and chan#e N6creen Kuffer 6izeO settin# 3. 9pply the chan#e in properties for all future *indo*s
P)g$ -" o+ ,!
P)g$ -* o+ ,!
Inspect trace messages :e *ill run the simulation *ith a trace on the label simple;mac so that *e can see the debu# messa#es printed out by the simple;mac process model. +. 9t the odb prompt' type the follo*in# a. 2tstop 1053 &Then hit 0nter( o o o 6ets a breakpoint for 1-s 0nables trace for the label 2simple;mac3 07ecutes simulation till breakpoint b. 2ltrace si#ple_#ac3 &Then hit 0nter( c. 2cont3 &Then hit 0nter( -. 07amine the trace messa#es a. "llustration #iven belo* <. )omplete the simulation a. 2cont3 &Then press 0nter(
=. )lick the lose button in the 6imulation 6equence *indo* after the simulation is finished.
P)g$ -! o+ ,!
Ping results
The record route option *as enabled for the pin# demand. 6o an output table entry *ill be created correspondin# to each successful pin# demand. .erify that there is an entry correspondin# to the pin# demand. Verify ping results @. )lick on the N(ie1 +es&ltsB action button to open up the vie* results dialo# bo7 B. "n the *indo* that opens up click on the N'iscrete $vent .a%lesB tab $1. 6elect the pin# report and click *,o1 $ . 4ote that the pin# demand *as successful
P)g$ -- o+ ,!
Larger net"or, scenario
The project also contains a second scenario named Lar#er;net*ork that consists of several simple;mac and ppp;*kstns connected usin# routers. Pin# demands have been confi#ured bet*een many nodes. #"itch to the scenario named Larger$net"ork $$. 6elect *cenario / *1itc, to *cenario / 2ar3er Net1or0
P)g$ -# o+ ,!
Run the simulation $3. 6elect '$* / +&n 'iscrete $vent *i#&lation $+. )lick lose to close the simulation sequence *indo* once the simulation completes Verify !ing results $-. )lick on the (ie1 +es&lts action button to open up the vie* result dialo# bo7 $<. )lick on the 'iscrete $vent .a%les tab $=. 4ote that there are pin# reports correspondin# to all the pin# demands in the net*ork $@. This sho*s that "P can route bet*een different interface types
&'$ !/ L(B
P)g$ -, o+ ,!
Lab ): Interfacing a %ustom +ig*er Layer to IP ! er ie"

The %P40T "P model has an open 9P" that allo*s any custom hi#her layer to interface *ith "P. "n this lab *e *ill interface a simple traffic #enerator to "P.
!b#ecti es
$B. "nterface the simplified;rp#;dispatcher model to "P. 31. !se a test net*ork to verify proper operation.
Instructions
-ending a pac,et to IP 0ach hi#her layer packet sent to ip;encap must be accompanied by an ")" of format ip;encap;req;v+ Q6ee fi#ure belo*R. The destination address of the packet must be specified in the dest;addr field of the ")". 9ll other fields are optional.
4ote that ip;encap *ill not destroy the ")" after handlin# the packet. 6o the hi#her layer must retain a handle to the ")"' say by storin# it as a state variable' and re-use it for subsequent packets. "n the simple;rp#;dispatcher process model' the ")" is created and stored as a state variable in the rp#;dispatcher;sv;init function.
P)g$ -. o+ ,!
-teps in ol ed
The steps involved in sendin# a packet to "P are listed belo*. 3 . 6et the destination address in the ")" 3$. "nstall the ")" 33. 6end the packetS 3+. !ninstall the ")" S 4ote that since *e are reusin# the ")"' *e should use op;pk;send;forced rather than op;pk;send to send the packet to "P. %ther*ise' if t*o packets are #enerated at e7actly the same time' the second packet mi#ht over*rite the ")" before ip;encap can handle the first packet.
%oding c*anges
:e *ill no* make the necessary chan#es to the rp#;#enerate;packet function so that it sends packets to "P correctly. %pen the function block of the simplified;rp#;dispatcher process model and #o to line T <. )han#e the function as sho*n belo*. &Lines to be added are sho*n in %old.( >9 .rint o&t a trace message* 9> i# (+/;AC1_;.-_AC/IB1) C ip_address_print (dest_address_str, rpg_#lo"_in#o_arrayJro"_n&mK*dest_address); op_prg_odb_print_major ("7ending a pac!et to t)eH Iaddress", dest_address_str, 3.C_,I+); G >9 7et t)e destination address in t)e ici* 9> op_ici_attr_set (ip_encap_re(_ici_ptr, "dest_addr", rpg_flo)_info_array*ro)_num+,dest_address); >9 Install t)e ici op_ici_install (ip_encap_re(_ici_ptr); 9>
>9 7end t)e pac!et* 7ince "e are re&sing t)e ici "e 9> >9 s)o&ld &se op_p!_send_#orced* 3t)er"ise i# t"o #lo"s 9> >9 generate a pac!et at t)e same time, t)e second pac!et9> >9 generation "ill oFer"rite t)e ici be#ore t)e #irst 9> >9 pac!et is processed by ip_encap* 9> op_pk_send_forced (pkt_ptr, -); >9 ninstall t)e ici* op_ici_install (O.C_$#/); F3 /; 9>
P)g$ -/ o+ ,!
0ecei ing a pac,et from IP
:hen "P sends a packet to the hi#her layer' the stream interrupt *ill have an ")" of format ip;encap;ind;v+ associated *ith it. This ")" contains information related to the packet such as the source "P address' the interface on *hich the packet *as received etc. 6ince ip;encap creates a ne* ")" for each packet it sends to the hi#her layer' this ")" must be destroyed after handlin# the packet. "n the simple;rp#;dispatcher process model a packet from "P is handled in the function rp#;packet;destroy. This function does the follo*in#. 3-. Dets the packet and the associated ")" 3<. Prints out a trace messa#e 3=. 8estroys the packet and the ")" 9n e7cerpt from this function is #iven belo*. 4o codin# chan#es are required in this function. >9 -et t)e ip_encap_ind_F4 accompanying t)e pac!et ip_encap_ind_ici_ptr = op_intrpt_ici (); 9>
>9 .rint a trace message 9> i# (+/;AC1_;.-_AC/IB1) C >9 -et t)e so&rce address #rom t)e ici* 9> op_ici_attr_get (ip_encap_ind_ici_ptr, "src_addr", (src_address); ip_address_print (src_address_str, src_address); op_prg_odb_print_major (";eceiFed a pac!et #rom", src_address_str, 3.C_,I+); G >9 @estroy t)e ici* op_ici_destroy (ip_encap_ind_ici_ptr); >9 -et t)e pac!et and destroy it pac!et_ptr = op_p!_get (6); op_p!_destroy (pac!et_ptr); 9> 9>
P)g$ -0 o+ ,!
Compile the process model 3@. 6ave and compile the process model "f you are havin# problems in compilation' you may a. )lose the process model b. %pen the simplified;rp#;dispatcher;ref process model c. 6ave it as simplified;rp#;dispatcher d. ?ecompile Using t*e test net"or,
!pen t*e test pro#ect
:e *ill no* use a simple net*ork to make sure that the packet #enerator is *orkin# correctly. %pen the project *ession_1510_la%_=. "f you did not make the codin# chan#es to the simplified;rp#;dispatcher process model' you may use the *ession_1510_la%_=_ref project. The project should open up in the scenario named e7ample;net*ork.
'et"or, description
The net*ork consists of four ppp;simplified;rp# *orkstations connected usin# routers. :kstn 9 is sendin# 1 pkts/sec of traffic to the each of the other three *orkstations.
P)g$ -1 o+ ,!
P)g$ #" o+ ,!
Run the #imulation 3B. 6elect C'$* / +&n 'iscrete $ventB 6imulation to run the simulation +1. )lick C loseB in the simulation sequence *indo* after the simulation completes Verify that traffic is flo"ing across the net"ork + . )lick on the CDide/*,o1 ;rap, PanelsB action button to open the stored templates +$. 6elect '$* / Panel Operations / Panel .e#plates / 2oad 4it, 2atest +es&lts +3. 9s e7pected there is 31 pkts/sec of traffic from *kstn 9 to ?outer 9 and 1 pkts/sec from ?outer 9 to each of the other routers.
&'$ !/ L(B
P)g$ #* o+ ,!
(ppendi1
(ppendi1 1: %reating 'ode Models "it* %ustom Lo"er and +ig*er Layers
$e ice %reator 8evice )reator is an %P40T utility that allo*s users to create custom node models. 4ode model types that can be created usin# device creator include routers' s*itches and multihomed clients and servers. The number of interfaces/ports of each type in the node model is confi#urable.
P)g$ #! o+ ,!
'ode models "it* custom process models %ne of the limitations of device creator is that it cannot be used to create node models *ith custom process models. This section describes a fe* thin#s to keep in mind *hile creatin# nodes *ith your o*n models. The first section lists some #eneral tips to keep in mind *hen creatin# any node model. The subsequent sections talk about node models *ith custom hi#her and lo*er layer respectively. 2eneral tips . )han#in# the model of a node in a project can lead to errors. 6o al*ays create node models *ith more interfaces than you actually need. The "P model *ill i#nore any unused interfaces. $. 4ever add/remove interfaces from an "P node model. The attribute chan#es required for this are too many. 3. 8o not make any chan#es to a standard node model directly. 6ave it in your op;models directory under a different name first. +. 8o not save any custom models under the opnet installation directory. They mi#ht #et over*ritten if the soft*are is re-installed. !se your op;models directory for this purpose. 'ode model "it* a custom *ig*er layer 9ddin# a custom hi#her layer to a node model is relatively simple as a node typically has only one instance of the hi#her layer. . 6tart *ith an appropriate standard or 8evice )reator node model &?efer to tips T and T3 under Deneral tips( $. 9dd the modules correspondin# to your custom hi#her layer to the node model. 3. 8o not remove any of the e7istin# modules even if they *ill not be used in your net*ork.
P)g$ #- o+ ,!
'ode model "it* custom lo"er layers )reatin# node models *ith custom lo*er layers is sli#htly more difficult because a multi-homed node can have several interfaces and each of these interfaces *ill have to be modified individually. . !se 8evice )reator to create a node model that has enou#h interfaces $. !se an appropriate standard interface type instead of the custom ,9) layer. 0.#. if the custom ,9) layer interface structure is similar to that of 0thernet' use 0thernet interfaces instead of the custom ,9) layer interfaces 3. %pen the node model in the node editor and chan#e each interface manually. ?emember' do not add/remove interfaces. +. !pdate the default value of the ,T! under "P ?outin# Parameters "nterface "nformation ,T! for each custom interface if necessary. To identify the ro* correspondin# to a particular interface' check the value of the 2ip addr inde73 attribute on the streams connectin# it to the ip module. The value of this attribute is the ro* number &4ote that ro* numbers start at 1(. -. "f you follo* the interfacin# procedure described in this session and use the standard 9?P layer for interfacin#' there is nothin# more to be done. <. "f you have to remove the arp module' here are a fe* additional thin#s to keep in mind The packet streams connectin# the ip module to an interface have an e7tended inte#er attribute named Nip addr inde73. The value of this attribute *ill be unique for each interface. 4ote the value of this attribute on the streams that are bein# removed and add this attribute *ith the same value to the ne* streams that are used to connect the ,9) layer to the "P module.
P)g$ ## o+ ,!
(ppendi1 ): Interfacing to t*e IP 3 Model

8urin# the session' *e sa* ho* lo*er and hi#her layers can be interfaced to the %P40T "P model. Kut the session discussed models that use "Pv+ only. This section describes interfacin# custom hi#her and lo*er layers to handle "Pv< packets. Interfacing a custom lo"er layer to IP 3 6ince 9?P performs the translation bet*een "P and ,9) addresses' the ,9) layer does not have to deal *ith "P addresses directly. 6o any custom ,9) layer that is interfaced to "P usin# the steps described in lab $ *ill also be able to handle "Pv< packets *ithout any chan#es. Inet.4(ddress structure Kefore discussin# interfacin# of hi#her layers to "Pv<' it is necessary to familiarize ourselves *ith a ne* structure' named "netT;9ddress that *as introduced in the "P model. "netT;9ddress is a data structure that can represent either an "Pv+ address or an "Pv< address. ,ost of the 9P" functions that *ere available *ith the older "pT;9ddress structure are available for "netT;9ddress also. 6ome of the most commonly used functions are listed belo*. Cor a more comprehensive list' refer to the header file ip;addr;v+.h. The correspondin# function definitions are in ip;addr;v+.e7.c inet;address;create inet;address;copy inet;address;print inet;address;destroy
4ote that unlike the "pT;9ddress structure' *hich is typedefed to an unsi#ned int' "netT;9ddress is an actual structure *ith internal pointers. This means that functions like inet;address;copy and inet;address;destroy should be used correctly to avoid memory errors and leaks. Interfacing a custom *ig*er layer to IP 3 The steps involved in interfacin# a custom hi#her layer to "Pv< are similar to those for interfacin# to "Pv+. The hi#h-level steps are reproduced here for your reference. . ?e#ister *ith "P and the oms process re#istry. $. The destination address of packets sent to "P must be specified in an ")". 3. Packets from "P *ill have an associated ")" containin# additional information.
P)g$ #, o+ ,!
The main differences in these steps from the one described in Lab 3 are #iven belo*. 4ote that since the "netT;9ddress structure can support both "Pv+ and "Pv<' this approach *ill *ork for both "Pv+ and "Pv<. 6o even if your hi#her layer model has to handle both "Pv+ and "Pv< packets' the steps listed belo* alone are adequate.
0egistration
The function that needs to be used to re#ister *ith "P is "net;Ai#her;Layer;Protocol;?e#ister. The ar#uments to this function are the same as those of "p;Ai#her;Layer;Protocol;?e#ister. ?e#istration in the oms;process;re#istry as described in Lab 3 is still required.
-ending a pac,et to IP
The ")" format to be used is inet;encap;req. The fields in this ")" are similar to that of ip;encap;req;v+ e7cept for the fact that the address fields should be set to pointers to "netT;9ddress. The note about the reusin# of ")" and the need to use op;pk;send;forced still apply. The hi#her layer is also responsible for mana#in# the memory allocated to the "netT;9ddress structures. "p;encap does not free this memory after handlin# the packet. ?efer to the 0nter 07ecs of the 6048 state in the rip;udp;v3 process model for an e7ample.
P)g$ #. o+ ,!
+andling a pac,et from IP
"f a hi#her layer re#istered *ith "P usin# "net;Ai#her;Layer;Protocol;?e#ister' packets sent to that hi#her layer from "P *ill have an ")" of type inet;encap;ind associated *ith the stream interrupt. The fields in this structure are similar to that of inet;encap;ind;v+ e7cept for the fact that the address fields &src;addr' interface;received and dest;addr( are no* pointers to "netT;9ddress structures. The hi#her layer is responsible for freein# the memory associated *ith the "netT;9ddress structures and the ")" itself. 4ote that this is true even for fields that are not actually used by the hi#her layer. ?efer to the 0nter 07ecs of the 9??".0 state in the rip;udp;v3 process model for an e7ample.
P)g$ #/ o+ ,!
(ppendi1 3: Interfacing 5ireless M(% Layers to IP

Lab $ described the interfacin# of any custom ,9) layer to the "P model. This section describes some additional thin#s to keep in mind *hen interfacin# a *ireless ,9) layer. Use of radio transcei ers There are t*o main approaches that model developers use to model a *ireless link. . !se radio transceivers and thus use the %P40T radio module. $. !se op;pk;deliver to send packets bet*een nodes. "f you use approach T ' you can i#nore this section and move on the section titled N9uto 9ddressin#O. Kut if you are usin# approach T$' note that "P e7pects every interface to have a transmitter and a receiver associated *ith it. 6o you should connect a radio transmitter and receiver to the ,9) layer to make sure that "P reco#nizes it to be an interface. 6ince no packets *ill ever be sent to these transmitters' they *ill not affect your simulations in any *ay. (uto (ddressing The simulation "P auto addressin# code cannot handle custom *ireless interfaces. This section describes some of the codin# chan#es required to make the "P auto addressin# code *ork *ith your custom *ireless ,9) layer. The simulation "P auto-addressin# packa#e depends on the ability to #roup connected "P interfaces into subnets. 6ince "P cannot #roup custom *ireless interfaces into "P subnets' it assumes that all of them are part of the same "P subnet and assi#ns them "P addresses accordin#ly. "n the case of standard *ireless interface types like *ireless L94 &@1$. ( and !,T6' additional code has been added to the "P auto addressin# packa#e to look at attributes like K66 "8 &in the case of *ireless L94( and 8omain "8 &in the case of !,T6( of the *ireless interface to #roup them into subnets. The codin# chan#es described in this section *ould essentially make the "P auto-addressin# packa#e do the same for your custom ,9) layer 4ote 5 "P #roups all custom *ireless ,9) layers into a sin#le "P subnet. 6o codin# chan#es are required only if your net*ork *ill have more than one "P subnet containin# custom *ireless ,9) layers. 4ote $5 The codin# chan#es that are described in this section are quite comple7. 6o try this approach only if you feel that none of the alternative approaches described in the section titled N9lternative 9pproachesO are adequate in your case. 4ote 35 The %,6 auto addressin# packa#e for assi#nin# ,9) addresses' described in Lab T$' is not related to the "P auto-addressin# packa#e. %,6 auto addressin# *ill *ork fine for *ireless ,9) layers also.
P)g$ #0 o+ ,!
The hi#h level steps to be follo*ed for addin# this functionality are listed belo*. . Pick a criterion that can be used to #roup the *ireless interfaces into "P subnets. The attribute used for this purpose should be published in the %,6 process re#istry as 2domain;id3. Possibilities include5 6ome kind of ,9) attribute. 9ll interfaces that are in the same "P subnet should have the same value for this attribute. %ne problem *ith this approach is that it mi#ht be necessary to manually confi#ure this attribute on each node. %P40T subnet "8. "f you construct your net*ork in such a *ay that all *ireless interfaces that belon# to an "P subnet are in the same %P40T subnet' you can use the subnet "8 as a criterion for #roupin# interfaces. This approach *ill fail if you have a multihomed node *ith interfaces in more than one *ireless "P subnet.
$. :hile re#isterin# in the %,6 process re#istry' the attribute 2mac;type3 should be set to an appropriate value to distin#uish these interfaces from other types of interfaces. 3. "f multiple custom ,9) layer interfaces on a node are to be supported' the object "8 of the *ireless transmitter connected to the ,9) layer should be published as an attribute named 2rat7;objid3 in the %,6 process re#istry. +. ,odify the function named ip;radio;address;resolve in ip;auto;addr;sup;v+.e7.c to handle your custom ,9) layer. (lternati e approac*es The codin# chan#es required to make "P auto addressin# *ork over a custom *ireless ,9) layer are very comple7. This section describes some alternative approaches throu#h *hich you can avoid them. . !se manual addressin#5 "f the net*ork that you are modelin# is not very lar#e' manually assi#nin# addresses to each node mi#ht be the best option. $. !se F,L e7port/import. %P40T has a feature by *hich all the nodes in a net*ork and the attributes on each of them can be e7ported to an F,L file. 6o another *ay of assi#nin# addresses *ould be to use a script to set the addresses in the F,L file and then re-import the net*ork from the F,L file. 07portin# of a net*ork to an F,L file can be done by selectin# .opolo3y / $)port .opolo3y / .o EM2F "mportin# a net*ork from an F,L file can be done by selectin# .opolo3y / I#port .opolo3y / Fro# EM2F
P)g$ #1 o+ ,!
(ppendi1 6: .ips on $ebugging

"P provides several traces' reports' statistics etc. that can be used to isolate errors that are occurrin# in the net*ork. This section describes some of them that you mi#ht find useful in debu##in# any problems that could occur in a net*ork containin# "P. These tips are not listed in any particular order. 6o the only *ay to use this document is to read throu#h it completely once' understand the functionalities available' and refer back to this document for details if you need a specific feature. IP traces "P model has several traces that can be used to dia#nose its functions. These traces may be enabled on per process' per module or #lobally dependin# on *hat you are tryin# to debu#. !se the odb command Nlmap ipO for a more complete list of available ip traces. 2ip;addresses35 This trace can be used to troubleshoot problems *ith the simulation auto addressin# packa#e. 9 trace messa#e is printed out every time an interface is assi#ned an address. %nce addressin# is complete' a table containin# all addresses is also printed out. 2ip;cmn;rte;table35 9 trace messa#e *ill be printed out correspondin# to any chan#es to the "P common route table if a trace on this label is enabled. 4ote that if this trace is bein# enabled either #lobally or on the dynamic routin# protocol module/process that is actually insertin# the entry. 2ip;cmn;rte;table;lookup35 0very time a lookup for a destination address is performed in the "P common route table' a trace messa#e can be printed out enablin# the trace on this label. 2ip;rte35 "f the trace on ip;rte is enabled' "P *ill print out a trace messa#e every time it handles the packet. The trace messa#e printed out *ill include the destination address of the packet' the interface on *hich the packet *as received' the ne7t hop to *hich the packet is bein# for*arded and the output interface. 2ip;fra#35 This trace can be used to #enerate a trace messa#e every time a packet is fra#mented/reassembled at the "P layer.
$iagnostic bloc, traces 9 lot of useful information can be obtained by e7ecutin# the dia#nostic block of the ip;dispatch process model *ith traces on specific labels enabled. The various labels available and their purposes are #iven belo*. 2ip;interfaces35 9 table containin# the list of connected interfaces and the addresses assi#ned to each interface *ill be printed out.
P)g$ ," o+ ,!
2ip;rte;table35 The "P for*ardin# table of the node *ill be printed out. 9 more user-friendly *ay to access this information is to look at the ip route table reports. This is covered in the section titled ?eports. 2ip;table35 Print out the contents of the #lobal table used by 9?P to map bet*een "P and ,9) addresses. This can be very useful to debu# problems arisin# durin# the interfacin# of a custom lo*er layer to "P. 2ip;fra#35 Prints out the list of incomplete "P fra#ments at a node. "f a packet had to be fra#mented at the "P layer' the destination node *ill for*ard it to the hi#her layer only after it receives all the fra#ments.
0eports The "P module can be confi#ured to #enerate several useful reports in the output table. To access these reports' click on the .ie* ?esults action button and select the 8iscrete 0vent Tables tab. "P Cor*ardin# table report5 9 node can be confi#ured to e7port its "P routin# table at specified times durin# the simulation. This confi#uration is done under the ?eports "P Cor*ardin# Table attribute. Pin# record route report5 "f the ?ecord route option is enabled in the pin# parameters confi#uration' a report containin# the route chosen by the pin# demand *ill be #enerated. !se Protocols / IP / 'e#ands / onfi3&re Pin3 traffic on selected nodesF to confi#ure pin# demands easily.
!t*er useful tools ?eachability 9nalysis5 "f a node in a net*ork does not have a route to a particular destination as e7pected' it *ill be useful to kno* *hich all nodes in the net*ork do have a route to that destination. ?eachability analysis makes it easy to obtain this information. ?eachability 9nalysis is described in #reater detail in the "P model user #uide. ?ecord route for traffic demands5 The record route feature of traffic demands can be used to determine the route chosen by traffic bet*een a pair of nodes in the net*ork. The main advanta#e of this approach over the pin# record route approach is that an option is available to visualize the routes usin# path objects. This feature also displays the route chosen by the traffic throu#h lo*er layer net*orks. !se .raffic / reate IP .raffic Flo1s to create traffic demands. The record route feature for the demand is enabled by default. !se Protocols / IP / 'e#ands / 'isplay ro&tes for confi3&red de#ands to visualize the route chosen by each demand. "nterface table e7port5 0nablin# the e7port option in the simulation attribute IP Interface Addressin3 Mode *ould make the simulation #enerate a #df file titled UprojectP-UscenarioPip;addresses.#df. This can be very useful to make sure that "P does not mistakenly think that an interface is not connected.
P)g$ ,* o+ ,!
P)g$ ,! o+ ,!

1510 LabManual OPNK2004

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

1510 LabManual OPNK2004

Загружено:

Авторское право:

Доступные форматы

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

d. 8ouble-click on the (al&e cell of the 'estination Infor#ation attribute.

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

addr = inet_address_create (addr_str, InetC_Addr_Family_ n!no"n);

. 6ave the chan#es. a. )lick on File / *ave.

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

+. 6et the fields of 'estination Infor#ation as follo*s5

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

Lab ): Building an ad anced encryption de ice "it* routing capabilities ! er ie"

1510 Understanding IP Model Internals and Interfaces Lab

d. 8ouble-click on the (al&e cell of the Pac0et lassification attribute.

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

Lab 1: Interfacing a %ustom Lo"er Layer to IP

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

9> 9> 9>

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

Larger net"or, scenario

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

Lab ): Interfacing a %ustom +ig*er Layer to IP ! er ie"

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

0ecei ing a pac,et from IP

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

(ppendi1 ): Interfacing to t*e IP 3 Model

1510 Understanding IP Model Internals and Interfaces Lab

1510 Understanding IP Model Internals and Interfaces Lab

+andling a pac,et from IP

1510 Understanding IP Model Internals and Interfaces Lab

(ppendi1 3: Interfacing 5ireless M(% Layers to IP