Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Datakom høsten 20021 Datakommunikasjon høsten 2002 Forelesning nr 4, mandag 9. september Chapter 4, Network Layer and Routing.

Liknende presentasjoner


Presentasjon om: "Datakom høsten 20021 Datakommunikasjon høsten 2002 Forelesning nr 4, mandag 9. september Chapter 4, Network Layer and Routing."— Utskrift av presentasjonen:

1 Datakom høsten 20021 Datakommunikasjon høsten 2002 Forelesning nr 4, mandag 9. september Chapter 4, Network Layer and Routing

2 Datakom høsten 20022 Øvingsoppgaver zChapter 2, Review questions y1, 2, 3, 6, 7, 8, og 13 zGjennomgås torsdag 12. september kl 12

3 Datakom høsten 20023 Kommunikasjonslagene (referert til OSI) ApplicationPresentationSession Ethernet IP ARP ICMP TCPUDP NetworkTransportData LinkPhysicalApplicationTransportNetworkData Link PPP FTPHTTP DNS OSI Internet-TCP/IP SMTP RFC871

4 Datakom høsten 20024 Innkapsling IP Header Data TCP Header Data

5 Datakom høsten 20025 Innkapsling IP Header Data TCP Header Data

6 Datakom høsten 20026 Innkapsling IP Header Data TCP Header Data Ethernet Header Ethernet Checksum Data

7 Datakom høsten 20027 Ethernet Header Ethernet Checksum Data Innkapsling IP Header Data TCP Header Data ‘Protocoll type’ identifiserer neste protokoll som IP (=0800) ‘Protocol’ definerer neste protokoll som TCP (=6) ‘Destination port’ definerer applikasjon, f.eks. HTTP (=80)

8 Datakom høsten 20028 zRuting yIP adresser yVeivalg zFragmentering zOverføring(‘best effort’) yUpålitelig yForbindelsesløs Pakker kan: xmistes xdupliseres xkomme i feil rekkefølge IP rydder ikke opp i dette IP - Internet Protocol RFC791

9 Datakom høsten 20029 IP Header VersionIHLType of ServiceTotal length Source Address Destination Address Options Version -Hvilken verson av IP som benyttes, her vil det stå 4, siden dette er en IPv4 header IHL -Internetwork Header Length - headerens lengde i 32-bits ord (er 5 for header uten opsjoner) Type of Service -Precedence (3 bit), Delay (low/normal), Throughput (normal/high), Reliability (normal/high), Cost (normal/maximize) Total Length -Totalt antall oktetter (IP-header + data) Identification 0 DFDF MFMF Fragment Offset Identification -Benyttes for å identifisere sammenhørende fragmenter (når opprinnelig IP-pakke var for stor for link-laget). DF -Don’t Fragment - settes hvis det ikke ønskes at pakker skal fragmenteres.0 - Null - Alltid satt til 0MF - More-flag;1 hvis flere fragmenter, 0 hvis siste fragment (eller hvis ikke fragmentert). Fragment Offset -Offset i antall 64-bits ord; plassering av dette fragmentet i opprinnelig pakke (= 0 for første fragment eller hvis ikke fragmentert) Time to LiveProtocolHeader Checksum Time To Live -Maxverdi for søkets levetid. Angis i sekunder, men blir i praksis antall ruterhopp; telles ned i hver ruter det passerer inntil det når 0, da sendes det ikke videre. Protocol -Angir det overliggende lags protokoll, f.eks. TCP. RFC791 Eksempel

10 Datakom høsten 200210 IP-adresser 0 NettLokal Klasse A (0-127): 01 NettLokal Klasse B (128-191): 011 NettLokal Klasse C (192-223): RFC791

11 Datakom høsten 200211 IP-adresser zHvordan angis en IP-adresse? yfire desimale nummer, et pr. byte i adressen, separert med punktum yKalles for “dotted decimal notation” yEksempel 193.69.136.36

12 Datakom høsten 200212 IP-adresser zSpesielle adresser yBroadcast - en til alle Lokaladresse har alle bit satt til 1 yLoopback (tilgang til tjenester på egen maskin) 127.0.0.1 yAlle bit 0; ukjent IP-adresse (eller default rute) zMåter å adressere yUnicast - en til en yBroadcast - en til alle yMulticast - en til mange

13 Datakom høsten 200213 Subnett zKlasseinndelingen er lite fleksibel, og gir mange ubrukte adresser zBedre utnyttelse av adresseområdet oppnås ved bruk av subnettmasker. zEn subnettmaske angir hvor stor del av adressen som er nettprefikset (nett+subnett) og dermed også hvor stor del lokaladressen er RFC950

14 Datakom høsten 200214 Subnett, eksempel RFC791 01 NettLokal Opprinnelig klasse B (1 nett med 65.536 lokaladresser) Nå: 64 subnett, hvert med 1022 lokaladresser 01 NettSubnettLokal Subnettmaske: 255.255.252.0 eller /22

15 Datakom høsten 200215 Subnett zVariabel Length Subnet Mask yMan kan ha subnett av forskjellig størrelse yMer effektiv utnyttelse av organisasjonens adresseområde. zMåter å angi subnettmasker: y193.69.136.36, subnettmaske 255.255.255.0 y193.69.136.36/24 y/24 betyr at 24 bit benytttes til å angi nettadressen yTotalt tilgjengelig 32 bit y32 – 24 = 8 bit til host adresser RFC950

16 Datakom høsten 200216 Subnett - variable subnettmasker, eksempel RFC950 011 NettLokal Opprinnelig klasse C nett, 1 nett med 254 lokaladresser 011 NettLokal 4 subnett, hvert med 30 lokaladresser Subnett xx0 011 NettLokal 4 subnett, hvert med 14 lokaladresser Subnett 0x1x Pluss: 011 NettLokal 8 subnett, hvert med 6 lokaladresser Subnett x1x1x NÅ:

17 Datakom høsten 200217 Adresseoversetting zBedre kjent som NAT (Network Address Translator) zIP-adresser innenfor et nettverk yikke er gyldige for bruk utenfra yskal skjules for utenverdenen zEn organisasjon har færre eksterne adresser enn størrelsen på det interne nettverket tilsier  Noen adresseområder er reservert til privat bruk y10.0.0.0 - 10.255.255.255 y172.16.0.0 - 172.31.255.255 y192.168.0.0 - 92.168.255.255  Disse adressene kan fritt benyttes bak en brannmur uten å komme i konflikt med andre sine IP-adresser på Internett. RFC2663

18 Datakom høsten 200218 ICMP - Internet Control Message Protocol zBrukes for feilmeldinger, rutinginformasjon og test zBenytter IP for å sende pakker (på samme måte som TCP og UDP), men er samtidig en nødvendig del av IP zEksempler: yICMP redirectICMP redirect yICMP echoICMP echo yICMP time exceededICMP time exceeded RFC792

19 Datakom høsten 200219 ICMP message types Type FieldMessage Type 0Echo Reply (Svar på Ping) 3Destination Unreachable 4Source Quench (Flyt kontroll) 5Redirect 8 Echo Request (Ping) 11Time Exceeded for a Datagram (Traceoute) 12Parameter Problem on a Datagram 13Timestamp Request 14Timestamp Reply 15Information Request 16Information Reply 17Address Mask Request 18Address Mask Reply

20 Datakom høsten 200220 ICMP eksempel PC Internett Ruter 193.69.136.54 193.69.136.56 193.69.136.8 Fefault GW =193.69.136.56 WEB-server ICMP redirect Intranett

21 Datakom høsten 200221 Tracert kommando zTraceroute, lister opp hvilke rutere som passeres på vei til mottaker zBenytter TTL (Time To Live) feltet i ICMP Echo Request zFår svar i form av ICMP Time Exceeded melding zTTL settes til 1 for så og økes med 1 hver gang

22 Datakom høsten 200222 Tracert

23 Datakom høsten 200223 PING program zBenyttes for å finne ut om en maskin er på lufta. zSender ICMP Echo Request zForventer å få ICMP Echo Reply som svar

24 Datakom høsten 200224 PING ping www.vg.no Pinging www.vg.no [195.139.5.245] with 32 bytes of data: Reply from 195.139.5.245: bytes=32 time=140ms TTL=126 Reply from 195.139.5.245: bytes=32 time=10ms TTL=126 Ping statistics for 195.139.5.245: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 10ms, Maximum = 140ms, Average = 42ms

25 Datakom høsten 200225 ARP - Address Resolution Protocol zFinne fysisk adresse fra IP-adresse zBenyttes i lokale nett zARP request sendes som broadcast zSvar på denne lagres (og kan benyttes senere) zEn host kan svare på vegne av en annen (proxy ARP) zEksempler yARP request, ARP replyARP requestARP reply RFC826

26 Datakom høsten 200226 The Internet Network layer routing table Host, router network layer functions: Routing protocols path selection RIP, OSPF, BGP IP protocol addressing conventions datagram format packet handling conventions ICMP protocol error reporting router “signaling” Transport layer: TCP, UDP Link layer physical layer Network layer

27 Datakom høsten 200227 IP Addressing: introduction zIP address: 32-bit identifier for host, router interface zinterface: connection between host, router and physical link yrouter’s typically have multiple interfaces yhost may have multiple interfaces yIP addresses associated with interface, not host, router 223.1.1.1 223.1.1.2 223.1.1.3 223.1.1.4 223.1.2.9 223.1.2.2 223.1.2.1 223.1.3.2 223.1.3.1 223.1.3.27 223.1.1.1 = 11011111 00000001 00000001 00000001 223 111

28 Datakom høsten 200228 IP Addressing zIP address: ynetwork part (high order bits) yhost part (low order bits) zWhat’s a network ? ( from IP address perspective) ydevice interfaces with same network part of IP address ycan physically reach each other without intervening router 223.1.1.1 223.1.1.2 223.1.1.3 223.1.1.4 223.1.2.9 223.1.2.2 223.1.2.1 223.1.3.2 223.1.3.1 223.1.3.27 network consisting of 3 IP networks (for IP addresses starting with 223, first 24 bits are network address) LAN

29 Datakom høsten 200229 IP Addressing How to find the networks? zDetach each interface from router, host zcreate “islands of isolated networks 223.1.1.1 223.1.1.3 223.1.1.4 223.1.2.2 223.1.2.1 223.1.2.6 223.1.3.2 223.1.3.1 223.1.3.27 223.1.1.2 223.1.7.0 223.1.7.1 223.1.8.0223.1.8.1 223.1.9.1 223.1.9.2 Interconnected system consisting of six networks

30 Datakom høsten 200230 IP Addresses 0 network host 10 network host 110 networkhost 1110 multicast address A B C D class 1.0.0.0 to 127.255.255.255 128.0.0.0 to 191.255.255.255 192.0.0.0 to 223.255.255.255 224.0.0.0 to 239.255.255.255 32 bits given notion of “network”, let’s re-examine IP addresses: “class-full” addressing:

31 Datakom høsten 200231 IP addressing: CIDR zclassful addressing: yinefficient use of address space, address space exhaustion ye.g., class B net allocated enough addresses for 65K hosts, even if only 2K hosts in that network zCIDR: Classless InterDomain Routing ynetwork portion of address of arbitrary length yaddress format: a.b.c.d/x, where x is # bits in network portion of address 11001000 00010111 00010000 00000000 network part host part 200.23.16.0/23

32 Datakom høsten 200232 IP addresses: how to get one? Hosts (host portion): zhard-coded by system admin in a file zDHCP: Dynamic Host Configuration Protocol: dynamically get address: “plug-and-play” yhost broadcasts “DHCP discover” msg yDHCP server responds with “DHCP offer” msg yhost requests IP address: “DHCP request” msg yDHCP server sends address: “DHCP ack” msg

33 Datakom høsten 200233 IP addresses: how to get one? Network (network portion): zget allocated portion of ISP’s address space: ISP's block 11001000 00010111 00010000 00000000 200.23.16.0/20 Organization 0 11001000 00010111 00010000 00000000 200.23.16.0/23 Organization 1 11001000 00010111 00010010 00000000 200.23.18.0/23 Organization 2 11001000 00010111 00010100 00000000 200.23.20.0/23... ….. …. …. Organization 7 11001000 00010111 00011110 00000000 200.23.30.0/23

34 Datakom høsten 200234 Hierarchical addressing: route aggregation “Send me anything with addresses beginning 200.23.16.0/20” 200.23.16.0/23200.23.18.0/23200.23.30.0/23 Fly-By-Night-ISP Organization 0 Organization 7 Internet Organization 1 ISPs-R-Us “Send me anything with addresses beginning 199.31.0.0/16” 200.23.20.0/23 Organization 2...... Hierarchical addressing allows efficient advertisement of routing information:

35 Datakom høsten 200235 Hierarchical addressing: more specific routes ISPs-R-Us has a more specific route to Organization 1 “Send me anything with addresses beginning 200.23.16.0/20” 200.23.16.0/23200.23.18.0/23200.23.30.0/23 Fly-By-Night-ISP Organization 0 Organization 7 Internet Organization 1 ISPs-R-Us “Send me anything with addresses beginning 199.31.0.0/16 or 200.23.18.0/23” 200.23.20.0/23 Organization 2......

36 Datakom høsten 200236 IP addressing: the last word... Q: How does an ISP get block of addresses? A: ICANN: Internet Corporation for Assigned Names and Numbers yallocates addresses ymanages DNS yassigns domain names, resolves disputes

37 Datakom høsten 200237 Getting a datagram from source to dest. IP datagram: 223.1.1.1 223.1.1.2 223.1.1.3 223.1.1.4 223.1.2.9 223.1.2.2 223.1.2.1 223.1.3.2 223.1.3.1 223.1.3.27 A B E misc fields source IP addr dest IP addr data zdatagram remains unchanged, as it travels source to destination zaddr fields of interest here Dest. Net. next router Nhops 223.1.1 1 223.1.2 223.1.1.4 2 223.1.3 223.1.1.4 2 routing table in A

38 Datakom høsten 200238 Getting a datagram from source to dest. 223.1.1.1 223.1.1.2 223.1.1.3 223.1.1.4 223.1.2.9 223.1.2.2 223.1.2.1 223.1.3.2 223.1.3.1 223.1.3.27 A B E Starting at A, given IP datagram addressed to B: zlook up net. address of B zfind B is on same net. as A zlink layer will send datagram directly to B inside link-layer frame yB and A are directly connected Dest. Net. next router Nhops 223.1.1 1 223.1.2 223.1.1.4 2 223.1.3 223.1.1.4 2 misc fields 223.1.1.1223.1.1.3 data

39 Datakom høsten 200239 Getting a datagram from source to dest. 223.1.1.1 223.1.1.2 223.1.1.3 223.1.1.4 223.1.2.9 223.1.2.2 223.1.2.1 223.1.3.2 223.1.3.1 223.1.3.27 A B E Dest. Net. next router Nhops 223.1.1 1 223.1.2 223.1.1.4 2 223.1.3 223.1.1.4 2 Starting at A, dest. E: zlook up network address of E zE on different network yA, E not directly attached zrouting table: next hop router to E is 223.1.1.4 zlink layer sends datagram to router 223.1.1.4 inside link- layer frame zdatagram arrives at 223.1.1.4 zcontinued….. misc fields 223.1.1.1223.1.2.3 data

40 Datakom høsten 200240 Getting a datagram from source to dest. 223.1.1.1 223.1.1.2 223.1.1.3 223.1.1.4 223.1.2.9 223.1.2.2 223.1.2.1 223.1.3.2 223.1.3.1 223.1.3.27 A B E Arriving at 223.1.4, destined for 223.1.2.2 zlook up network address of E zE on same network as router’s interface 223.1.2.9 yrouter, E directly attached zlink layer sends datagram to 223.1.2.2 inside link-layer frame via interface 223.1.2.9 zdatagram arrives at 223.1.2.2!!! (hooray!) misc fields 223.1.1.1223.1.2.3 data network router Nhops interface 223.1.1 - 1 223.1.1.4 223.1.2 - 1 223.1.2.9 223.1.3 - 1 223.1.3.27 Dest. next


Laste ned ppt "Datakom høsten 20021 Datakommunikasjon høsten 2002 Forelesning nr 4, mandag 9. september Chapter 4, Network Layer and Routing."

Liknende presentasjoner


Annonser fra Google