Your SlideShare is downloading. ×
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Virtual Network Emulation Tools
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Virtual Network Emulation Tools

827

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
827
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • The most important thing I have to say today is “THANKS!” Thank you Dr. Straight for giving me the opportunity to be a graduate teaching assistant and thereby arrive at this point. I am very happy that I was able to give you something in return. The software is being used in Dr. Straight’s Unix Network Programming class and it actually seems to work!! A special thanks also to Kim Buckner who is generous with his knowledge to anyone who asks and who is a GTA and friend par excellence. Thank you Dr. Plank for your wonderful notes especially those concerning threads. Your printer simulation and dining philosopher examples are great! What does he get out of this—no hassle! Last, but certainly not least, a thousand thanks to Dr. Dunigan who helped me take a few very broad specifications and come up with some specifics. I am grateful beyond that I can express for his knowledge and willingness to help. What did he get out of this—nothing but hassle!
  • Transcript

    • 1. Virtual Network Emulation Tools A Master’s Project Presented by Florence M Fowler November 15, 2000
    • 2. Proposal Specifications
      • Emulate the link/physical layers of the TCP/IP protocol stack
      • Take packets handed off from the student-designed TCP/UDP/IP layers and deliver them to the desired destination
      • Facilitate the setting up of student subnets and the routing of packets within a subnet and from one subnet to another
      • Create an environment that is as realistic as possible in which the students can work
      A tool is needed which will:
    • 3. Huh? How’s this going to work? vnet link layer Application Socket Library UNIX domain sockets IP UDP TCP Socket layer Socket Library Application
    • 4. Huh? How’s this going to work? vnet link layer Socket Library UNIX domain sockets IP UDP TCP Socket layer Client Application vnet link layer Socket Library IP UDP TCP Socket layer Server Application Real UDP/IP ProtocolStack Real UDP/IP ProtocolStack UNIX domain sockets
    • 5. Justification Students learn Better by Doing! Exploring Routing Protocols Using UNIX Domain Sockets Writing a Socket Layer Interfacing the Protocol layers Writing Applications Writing “ UDP” Working in Groups Writing a Socket Library Writing “ IP”
    • 6. Problems to Solve:
      • How should hosts and subnets be identified?
      • How will you find out what a host’s identifier is?
      • How will you connect a vnet identifier to an IP address?
      • How should port numbers be advertised?
      • What kind of design will allow for subnets to be connected?
      • How should a packet be constructed?
      • How should network characteristics be implemented:
      • -reliability? -delay?
      • How should asynchronous I/O be handled?
      • What structures are needed?
      • The end product needs to be a self-contained module with easy-to-use interface.
      • Remember—try to create a realistic environment!
    • 7. Some Solutions:
      • vnet host and subnet addresses are modeled on IP host and subnet addresses (even broadcast)
      • vnet functions like gethostbyname(), etc. are provided to supply vnet names and addresses and convert from one to another
      • port numbers are assigned by subnet and included in the configuration file
      • host “interfaces” are configured to allow subnets to be connected
      • the real ip and udp headers are filled in using htons() and htonl() when appropriate
      • random number generation combined with an algorithm and checked against the subnet reliability determine if a packet is corrupted or lost
      • select() is used to simulate delay
      • threads and condition variables are used to handle asynchronous input
      • structures are used for interfaces, “arp cache”, IP queue and interface statistics
    • 8. What Structures are Needed? net 10.10.1.0 255.255.255.0 5056 55 90.0 hydra3b alpha1 10.10.1.1 hydra3c alpha2 10.10.1.6 default 10.10.1.1 net 10.10.2.0 255.255.255.0 5067 45 95.0 hydra3b beta1 10.10.2.1 hydra2c beta2 10.10.2.7 default 10.10.2.7 default 10.10.2.1 net 10.10.3.0 255.255.255.0 5078 45 95.0 hydra2c bravo1 10.10.3.1 hydra2b bravo2 10.10.3.8 default 10.10.3.1 net 10.10.4.0 255.255.255.0 5089 45 95.0 hydra3b gamma1 10.10.4.1 hydra4b gamma2 10.10.4.5 default 10.10.4.1 route 10.10.5.0 10.10.4.5 net 10.10.5.0 255.255.255.0 5090 45 95.0 hydra4b delta1 10.10.5.1 hydra4c delta2 10.10.5.4 hydra4d delta3 10.10.5.6 default 10.10.5.1 trace tracefile
      • Interface Structure
      • one interface structure is “configured” for each subnet a host is on
      • Stats structure
      • each interface structure contains a Stats structure to hold statistics for that interface
      • Arp structure
      • an arp structure is set up for each host in the configuration file
      • IP queue
      • all packets received are placed in the “ip” queue
      Configuration file:
    • 9. Designing and Connecting up Subnets 10.10.5.6 10.10.5.4 10.10.5.1 hydra4c hydra4b hydra4d
    • 10. Designing and Connecting up Subnets 10.10.1.6 10.10.1.1 10.10.4.5 10.10.5.6 10.10.5.4 10.10.4.1 10.10.5.1 hydra4c hydra4b hydra3c hydra4d 10.10.1.7 hydra3d hydra3b
    • 11. Designing and Connecting up Subnets 10.10.3.8 10.10.1.6 10.10.3.1 10.10.1.1 10.10.4.5 10.10.5.6 10.10.5.4 10.10.4.1 10.10.2.1 10.10.2.7 10.10.5.1 hydra3b hydra2b hydra2c hydra4c hydra4b hydra3c hydra4d 10.10.1.7 hydra3d
    • 12. vnet Interface Students call 3 primary, easy-to-use functions to access vnet: int vn_SystemInit(char *ConfigFile) int vn_SendPkt(void *pkt, int pktsize, struct in_addr nexthop, int interface) int vn_RecvPkt(void *buf, int bufsize) 4 additional functions are provided to be used as needed: int vn_gethostname(char *myname, int len) struct in_addr vn_gethostbyname(char *vnetname) int vn_gethostbyaddr(struct in_addr vnetaddr, char *vnetname, int len) int vn_Stats(int *ifaces, Stats *buf)
    • 13. vnet Interface int vn_SystemInit(char *ConfigFile) - Opens and reads the configuration file configuring the “interfaces” for a host and creating an “arp cache” to cross reference the vnet name & address with the IP name & address for each host in the file - Mallocs and initializes the “IP” queue - Creates a thread for each “interface” to wait for packets - If the configuration file has a trace entry, the tracefile is opened and a pcap file header is written
    • 14. vnet Interface int vn_SendPkt(void *pkt, int pktsize, struct in_addr nexthop, int interface) - takes a packet, packet size, next-hop address and outgoing interface from the ip layer - checks for a valid interface and packet size - appends an “ethernet” header to the packet - uses the “arp cache” to look up the “physical address” (ip address) of the next hop - calls vn_Corrupt() to simulate corruption, loss and delay of packets as specified in the configuration file - sends the packet out the specified “interface” to the next hop address - if TRACE is enabled, a pcap pkthdr and the packet are written to the tracefile
    • 15. vnet Interface int vn_RecvPkt(void *buf, int bufsize) - blocks until receiving a signal that a packet has been placed in the “IP” queue - copies “bufsize” characters into “buf” both of which are provided by the caller - returns the number of characters actually received - packets are dropped by vnet if “IP” does not call this function in a timely fashion and the queue fills up
    • 16. vnet Interface int vn_gethostname(char *myname, int len) - matches one of the IP names found in the “arp cache” with the name returned from the gethostname() (ex. hydra1a) struct in_addr vn_gethostbyname(char *myname) - matches “myname” (ex. delta1) with one of the vnet names found in the “arp cache” and returns the vnet address as a struct in_addr Int vn_gethostbyaddr(struct in_addr nexthop, char *nhopname, int len) - matches “nexthop” with a vnet address found in the “arp cache” and returns the vnet name Int vn_Stats(int *ifaces, Stats *buf) - stores the number of interfaces for this host into “ifaces” and stores the statistics for all interfaces in the list of Stats structures passed to it by the calling function
    • 17. Packet Corruption and Loss 10.10.1.6 host1 10.10.1.1 10.10.2.1 10.10.2.7 host 3 Reliability: 85% Reliability: 50% Reliability Test host 1 and host 3 are each sending 5700 1000 byte packets to host 2 while host 2 is sending 5700 1000 byte packets to host 1 host 2 Host Corrupted Lost Reliability /host Reliability/network host 1 2016 573 54.5 host 2 1961 564 55.7 55.1 host 3 562 152 87.4 87.4 * test was performed in the hydra lab with host1=hydra5f, host2=hydra5c, host3=hydra5d
    • 18. Performance Performance tests were conducted on 2 hydra machines sending and receiving 1000 byte packets. Repetitions time kilobits/sec echo_client, echo_server 100 0.063 25427.103 (using UDP and sockets) 500 0.320 24965.593 1000 0.629 25447.761 5000 3.301 24235.140 vnet_client, vnet_server 100 0.082 19436.324 (using the vnet interface 500 0.390 20529.771 functions) 1000 0.814 19664.451 5000 4.017 19916.342
    • 19. Error Handling Reworked error handling routines from software by Brian Davis 3/13/95
      • Modeled on the actual system error reporting and uses:
        • An structure containing a vnet error number and a system error number
        • set_error(int, int) which allows the setting of either or both members of the structure where an error occurs
        • can return 0 on success and –1 or an error code on failure
        • vnet_perror() which may be called to print vnet and system error messages
        • #defined errors are coupled with error messages that the student can expand as needed
    • 20. The Student Gets:
      • VNET.README containing a full description of the interface, error reporting, a detailed description of the configuration file and a tutorial to use with the sample executable
      • sample executable
      • composed of an “ip” layer implementing static routing and compiled in with the vnet library
      • vnet_link.a
      • the vnet library routines to be compiled in with ip, udp, tcp and a socket layer to produce a “vnet kernel”
      • vnet_ip.h
      • containing pertinent #defines and #includes, the Stats structure and function prototypes for the interface
      • sample configuration files
      • echo client and server code
      • both for internet sockets and UNIX domain sockets
      • vnet_error.h and vnet_error.c
      • for use and possible expansion
    • 21. Additional Components Completed:
      • “ ip ” layer which includes the ip header checksum and static routing
      • “ udp ” layer using PCBs
      • “ socket layer “ using socket buffers
      • “ socket library “ including Socket(), Bind(), Sendto() and Recvfrom()
      • vnet trace capability produces files tcpdump can read
    • 22. Future Enhancements?
      • vnet link layer:
      • * Optimization of vnet code
      • * Multicast
      • * Arp requests
      • vnet ip layer
      • * ICMP messaging
      • * Active routing
      • add a vnet tcp layer
      • expand the application socket library
    • 23. I Learned:
      • How the Internet protocol layers actually work by closely examining the code and explanations contained in Richard Stevens books, “TCP/IP Vol 1” and “TCP/IP Vol 2”
      • How threads and semaphores work
      • How to use threads and buffers to create a realistic network simulation
      • Some of the intricacies involved in various routing protocols
      • Just a glimpse of how much there is to know
    • 24. What Structures Are Needed? One interface structure is “configured” for each subnet that a host is on: Net 10.10.5.0 5099 10 85.0 hydra4b delta1 10.10.5.1 hydra4c delta2 10.10.5.2 hydra4d delta3 10.10.5.3 vnet configures one interface for hydra4b : VnetIFace: 10.10.5.1 SubNet: 10.10.5.0 BroadCast: 10.10.5.255 Port: 5099 Sockaddr_in: AF_INET 5099 128.69. RecvSocket: 6 SendSocket: 5 CrossTraffic: 10 Reliability: 85.0 Statistics: Packets sent, received, lost, corrupted, dropped Using subnet.config :
    • 25. What Structures Are Needed? Statistics are kept by and may be printed out for each interface: Stats: PktsLost 1 PktsCorrupted 2 PktsSent 992 PktsRecv 991 PktsDropped 0 A Stats structure is included within each interface structure: PktsLost and PktsCorrupted keep count of packets that are corrupted or lost Packets are counted after they are successfully sent out Each thread counts the packets as they come in Packets are dropped if the IP queue is full
    • 26. Designing a Subnet subnet.config net 10.10.4.0 5089 45 95.0 cetus2e alpha1 10.10.4.1 cetus2d alpha2 10.10.4.2 cetus3a alpha3 10.10.4.3 cetus4b alpha4 10.10.4.4 cetus2e interface: 10.10.4.1; 10.10.4.0; 10.10.4.255; 5089; sockaddr_in: AF_INET, 5089, 128.169.xx.xx; 6; 5; 45; 95.0; Stats cetus2d interface: 10.10.4.2, etc. cetus3a interface: 10.10.4.3, etc. cetus4b interface: 10.10.4.4, etc. Network 10.10.4.0 uses port 5089 has traffic delay of 45 milliseconds and reliability of 95%
    • 27. Connecting up Subnets vnet.config: net 10.10.1.0 5056 55 90.0 hydra3b alpha1 10.10.1.1 hydra3c alpha2 10.10.1.6 default 10.10.1.1 net 10.10.2.0 5067 45 95.0 hydra3b beta1 10.10.2.1 hydra2c beta2 10.10.2.7 route 10.10.3.0 10.10.3.1 default 10.10.2.1 net 10.10.3.0 5078 45 95.0 hydra2c bravo1 10.10.3.1 hydra2b bravo2 10.10.3.8 default 10.10.3.1 net 10.10.4.0 5089 45 95.0 hydra3b gamma1 10.10.4.1 hydra4b gamma2 10.10.4.5 default 10.10.4.1 route 10.10.5.0 10.10.4.5 net 10.10.5.0 5090 45 95.0 hydra4b delta1 10.10.5.1 hydra4c delta2 10.10.5.4 hydra4d delta3 10.10.5.6 default 10.10.5.1 10.10.3.8 10.10.1.6 10.10.3.1 10.10.1.1 10.10.4.5 10.10.5.6 10.10.5.4 10.10.4.1 10.10.2.1 10.10.2.7 10.10.5.1 hydra3b hydra2b hydra2c hydra4c hydra4b hydra3c hydra4d
    • 28. What Structures Are Needed? An Arp structure is set up for each host in the configuration file: Net 10.10.5.0 5099 10 85.0 hydra4b delta1 10.10.5.1 hydra4c delta2 10.10.5.2 hydra4d delta3 10.10.5.3 vnetname: delta1 delta2 delta3 struct in_addr: 10.10.5.1 10.10.5.2 10.10.5.3 realname: hydra4b hydra4c hydra4d vnetport: 5099 5099 5099 sockaddr_in: AF_INET AF_INET AF_INET 5099 5099 5099 128.69.92.45 128.69.94.45 128.69.92.35 Using this subnet.config: vnet sets up 3 Arp structures for the delta subnet:
    • 29. What Structures Are Needed? RQ: IPrecv *pktin: msg size head tail pkts pthread_mutex_t *RQ_lock pthread_cond_t *empty All packets received are placed in the ip queue…….. recvq = (RQ *) malloc(sizeof(RQ)) recvq->pktin = (IPrecv *) malloc(sizeof(IPrecv) * QSIZE space for QSIZE packets next empty space next packet to be removed from the q Packets are dropped if the IP queue is full: pkts = QSIZE vn_RecvPkt() is signalled when a packet has been put on the queue

    ×