DOC PREVIEW
Stanford CS 144 - Lecture Notes

This preview shows page 1-2-21-22 out of 22 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Slide 1Lab 4 InfoIP Addresses and MAC AddressesIP Within EthernetNecessity of ARPARP Packet FormatGenerating ARP RequestHandling ARP RequestHandling ARP ReplyLab 4 ARP FunctionalityICMPBasic Lab 4 Flow DiagramMore Lab 4 ThoughtsMAC Address UniquenessArbitration of Shared ResourcesCSMA/CD in the ClassroomCSMA/CD in EthernetLength Limitation of CSMA/CDCSMA/CD Network Size RestrictionSwitching vs. Point to PointManchester EncodingManchester Encoding QuestionLab 4 and Link LayerCS144 Review Session 6May 9, 2008Ben NhamLab 4 Info•It takes a while, so start now•Watch the first two screencasts to get started•Today: talk about ICMP and ARP for the lab•Due Wednesday, with extension to Saturday at 5 PMIP Addresses and MAC Addresses•Each IP address is associated with a single interface•Each interface has a MAC address•Therefore, each IP address is associated with a single MAC address•Router with 4 interfaces has 4 IPs and 4 MAC addresses!–eth0 has some IP0–eth1 has some IP1–eth2 has some IP2–eth3 has some IP3•Conclusion: An IP address names an interface, not a hosteth0eth1eth2eth35.10.1.112.1.1.20012.1.1.112.1.0.1IP1IP2IP0IP3IP Within Ethernet•In a router, we operate on raw Ethernet frames, with an IP or ARP packet as payload•To forward a packet one hop, must know:–Destination IP address–Next-hop MAC address of the next-hop IP addressByte 0 Byte 1 Byte 2 Byte 3Dest MAC AddressDest MAC Address (continued) Source MAC AddressSource MAC Address (continued)Ethertype PayloadNecessity of ARPIP Address Netmask Gateway Interface0.0.0.0 0.0.0.0 5.10.1.1 eth012.1.0.0 255.255.0.0 12.1.0.1 eth112.1.1.0 255.255.255.0 12.1.1.1 eth212.1.1.200 255.255.255.255 12.1.1.200 eth3•Suppose I get a packet destined for 128.12.94.3–Matches default route only (first entry)•Need to send raw Ethernet frame to the MAC address of 5.10.1.1•But our routing table has only IP addresses, not MAC addresseseth0eth1eth2eth35.10.1.112.1.1.20012.1.1.112.1.0.1ARP Packet Format•Corresponds to struct sr_arphdr–HTYPE = ar_hrd = htons(ARPHDR_ETHER)–PTYPE = ar_pro = htons(ETHERTYPE_IP)–HLEN = ar_hln = # bytes in MAC address–PLEN = ar_pln = # bytes in IP address–OPER = ar_op = htons(ARP_REQUEST) or htons(ARP_REPLY)–SHA/SPA = sender MAC/IP address (copy from sr_if of outgoing IF)–THA/TPA = target MAC/IP addressGenerating ARP Request•Request: Who has IP 192.168.1.3? Create ARP request with fields:–Source HW addr: MACsrc–Source protocol addr: IPsrc–Target HW addr: all 0s–Target protocol addr: 192.168.1.3•ARP requests are sent to the Ethernet broadcast addressHandling ARP Request•Get request: Who has 192.168.1.3•If one of the IPs of my router is 192.168.1.3, send an ARP reply: I have IP of 192.168.1.3 with MAC address of 00-11-22-33-44-55-66 (six bytes in hex, or 48 bits)–Source HW addr: 00-11-22-33-44-55-66–Source protocol address: 192.168.1.3–Target HW addr: MACsrc–Target protocol addr: IPsrc•ARP reply is sent directly to MACsrcHandling ARP Reply•Reply: I have IP of 192.168.1.3 with MAC address of 00-11-22-33-44-55-66•If the target IP of the ARP reply is the IP of the interface this came in on:–Add the IP to MAC mapping to the ARP cache–Send off any packets that were waiting on this ARP replyLab 4 ARP Functionality•Generate ARP requests if a next hop MAC is not in the ARP cache•Process ARP replies that target us and place them into the ARP cache•Process ARP requests that target us and generate an appropriate ARP reply•Go through ARP request queue every second and send off ARP requests every second (edit sr_arpcache_sweepreqs in sr_arpcache.c)ICMP•Used to send control messages back to sending host•Must process ICMP Echo Request•Must generate–ICMP Echo Reply–ICMP Destination Host Unreachable–ICMP Destination Port Unreachable•Check Network Sorcery pages on details of how to generate the messageBasic Lab 4 Flow DiagramReceive Raw Ethernet FrameReceive Raw Ethernet FrameProcess IP PacketProcess IP PacketProcess Packet Sent to SelfProcess Packet Sent to SelfForward PacketForward PacketProcess ARP Request/ReplyProcess ARP Request/ReplyIf ICMP echo req, send ICMP echo replyIf IP+TCP/UDP, send ICMP port unreachableIf ICMP echo req, send ICMP echo replyIf IP+TCP/UDP, send ICMP port unreachableDo LPM on routing tableDo LPM on routing tableSee previous slidesSee previous slidesSend ICMP host unreachableSend ICMP host unreachableCheck ARP cacheCheck ARP cacheSend frame to next hopSend frame to next hopAdd request to ARP queue, sending if necessaryAdd request to ARP queue, sending if necessaryNo matchIf already sent 5 timesMatchNo hitHitNot sent to selfSent to selfMore Lab 4 Thoughts•Organize your code–Sticking everything sr_router.c will probably give you a headache–Make some new files (suggestions):•sr_arp.c/h for handling/generating ARP packets•sr_icmp.c/h for handling/generating ICMP packets•sr_ip.c/h for to handle generating IP packets•Add the sources and headers to the Makefile•Do one thing at a time–Need ARP to send anything at all–If you just do the forwarding path without ICMP, should be able to route packets to the app servers–Can add ICMP support lastMAC Address Uniqueness•IPs should be globally unique across all hosts–Except for multicast IPs and private IPs used by NATs•MAC addresses only have to be locally unique–If a node is directly connected to other nodes over a shared Ethernet (or switched/hubbed Ethernet), MAC addresses on this shared medium must be unique or we couldn’t address a frame to just one frame–But two nodes on opposite sides of the world don’t need unique MAC addresses, since as we’ve seen we’re only using the MAC address to forward the frame one hop–Network cards come from the factory with a unique MAC address anyway, but users can set their MAC address in software, so duplicate MACs can occurArbitration of Shared Resources•General systems problem–I have a shared resource that only one person can use at a time–How do I arbitrate access to it?•Shared CPU, multiple processes need it – OS scheduler•Shared radio spectrum, multiple broadcasters – frequency division multiplexing•One Ethernet coax, multiple clients connected to it – CSMA/CD–Other ways of sharing a medium, e.g. Token Ring, Aloha, etc. in bookCSMA/CD in the Classroom•We are students sharing the air in this room, and develop the following protocol to arbitrate access to it:–Before I


View Full Document

Stanford CS 144 - Lecture Notes

Documents in this Course
IP Review

IP Review

22 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?