Tuesday, July 29, 2008
Movie Quotes : ဖဲ၀ုိင္း
ေသခ်ာနားေထာင္၊ ဖဲ၀ုိင္းတ၀ုိင္းမွာ၀င္ထုိင္ျပီး ပထမနာရီ၀က္အတြင္းမွာ အခ်ဥ္တစ္ေယာက္ကုိရွာမေတြ႔ရင္ ခင္ဗ်ားကုိယ္တုိင္က အခ်ဥ္ျဖစ္သြားျပီ။
Listen, here's the thing. If you can't spot the sucker in the first half hour at the table, then you ARE the sucker.
- Rounders (၁၉၉၈) ရုပ္ရွင္မွ
Sniffer Appliance (1)
One of the interesting projects that I worked on recently is - to capture and store packets going across the network on a really large storage device and perform analysis later on. I started out building a home-grown PC with a few hard drives in it and run wireshark to capture data. I couldn't use tcpdump because it does not have an option to wrap the number of files it writes.
(tshark -b filesize:50000 -b files:9999 -w capture-files) was the command that I used.
-b filesize:50000 - save each file at 50MB
-b files:9999 - do not create more than 9,999 files
So it nicely fits into 750GB hard-drive.
I did not have much problem with capturing and storing files. Captured packets are saved in native libpcap format which can be read with almost all the sniffer program.
Problems arose when I tried to extract data from it.
1. Lets say I want to see some packets from certain data and time. When there are lots of traffic on the network, the files are created very quickly. Sometimes, 10 files in 1 minute which equates to 500MB of packet data. Now I have to run query against the file using the time stamp of the file (remember there are about 10 files in that approximate time range) and hope I get the right one.
2. Statistical analysis tools and graphing tools are not very good with wireshark client software, especially when working with large amount of data. It is slow and painful to merge those files. It is almost impossible to generate daily traffic report from the captured files.
3. libpcap file format is not really optimized for database task and hence I cannot create index nor use SQL-ish query against it.
Wireshark is a great program for ad-hoc sniffing. It is just not designed to handle the way I want to use it, capturing and analyzing large amount of packets.
So, I gave up the idea of home-grown solution and started looking for a vendor who will solve the problems that I have. I found following three vendors/products and they all sound promising.
1. Network General's Infinistream
2. Network Instrument's GigaStor
3. Niksun's NetVCR
I contacted them and asked for an evaluation unit. I put their units in our lab and started testing out. I will write my experience with my lab in the next entry.
I am just wondering if
1. it there any open-source solution
2. how difficult would it be to write an application which store packets into a SQL or similar database
(tshark -b filesize:50000 -b files:9999 -w capture-files) was the command that I used.
-b filesize:50000 - save each file at 50MB
-b files:9999 - do not create more than 9,999 files
So it nicely fits into 750GB hard-drive.
I did not have much problem with capturing and storing files. Captured packets are saved in native libpcap format which can be read with almost all the sniffer program.
Problems arose when I tried to extract data from it.
1. Lets say I want to see some packets from certain data and time. When there are lots of traffic on the network, the files are created very quickly. Sometimes, 10 files in 1 minute which equates to 500MB of packet data. Now I have to run query against the file using the time stamp of the file (remember there are about 10 files in that approximate time range) and hope I get the right one.
2. Statistical analysis tools and graphing tools are not very good with wireshark client software, especially when working with large amount of data. It is slow and painful to merge those files. It is almost impossible to generate daily traffic report from the captured files.
3. libpcap file format is not really optimized for database task and hence I cannot create index nor use SQL-ish query against it.
Wireshark is a great program for ad-hoc sniffing. It is just not designed to handle the way I want to use it, capturing and analyzing large amount of packets.
So, I gave up the idea of home-grown solution and started looking for a vendor who will solve the problems that I have. I found following three vendors/products and they all sound promising.
1. Network General's Infinistream
2. Network Instrument's GigaStor
3. Niksun's NetVCR
I contacted them and asked for an evaluation unit. I put their units in our lab and started testing out. I will write my experience with my lab in the next entry.
I am just wondering if
1. it there any open-source solution
2. how difficult would it be to write an application which store packets into a SQL or similar database
Sunday, July 27, 2008
အင္တာနက္ ၁၀ ႏွစ္ ခရီး
၂၀၀၈ ခုႏွစ္ ဇြန္လထုတ္ IP Journal မွာပါတဲ့ "A Decade of Internet Evolution" ဆုိတဲ့ေဆာင္းပါးထဲက ေကာင္းႏုိးရာရာေလးေတြ ေရးသြားပါမယ္။ Vint Cerf ေရးတဲ့ ေဆာင္းပါးျဖစ္ပါတယ္။
"၁၉၉၈ ခုႏွစ္ - အင္တာနက္အသုံးျပဳတဲ့သူ လူ သန္း ၅၀ေလာက္ရွိျပီး၊ web နဲ႔ e-mail server ၂၅ သန္း ခန္႔ရွိပါတယ္။ အင္တာနက္ ကုပၼဏီေတြျဖစ္တဲ့ Netscape, Amazon, Yahoo!, eBay တုိ႔က ၃၊ ၄ ႏွစ္သား အရြယ္ေလာက္ ရွိပါေသးတယ္။"
"၂၀၀၈ ခုႏွစ္ - အင္တာနက္ေပၚမွာ server ၅၄၂ သန္းခန္႔ရွိျပီး၊ အင္တာနက္သုံးစြဲသူ သန္း ၁၃၀၀ ခန္႔ရွိေနပါျပီ။ မုိဘုိင္ဖုံး သုံးစြဲသူ အေရအတြက္ သန္း ၃၀၀၀ ခန္႔ရွိျပီး၊ အဲဒီလူေတြထဲက ၁၅% ခန္႔က အင္တာနက္ကုိ မုိဘုိင္ဖုံးကေန သုံးစြဲၾကပါတယ္။ ဆုိေတာ့ သန္း ၄၅၀ ခန္႔ရွိတာေပါ့။ "
"၁၉၇၉ ခုႏွစ္မွာ ေဒၚလာ ၁၀၀၀ သုံးျပီး 10MB ခန္႔ရွိတဲ့ disk storage ကုိ၀ယ္ခဲ့တာ မွတ္မိပါတယ္။ မၾကာေသးခင္က (၂၀၀၈ ခုႏွစ္) 2TB disk storage ကုိ၀ယ္တာ ေဒၚလာ ၆၀၀ ေပးရပါတယ္။ တကယ္လုိ႔ ၁၉၇၉ ခုႏွစ္က 2TB disk storage ကုိ ၀ယ္မယ္ဆုိရင္ ေဒၚလာ သန္း ၂၀၀ ေလာက္ ေပးရမယ္ထင္ပါတယ္။ ဒါ့အျပင္ disk လုပ္ေရာင္းသူ အေနနဲ႔လည္း မႏုိင္၀န္ ထမ္းရသလုိျဖစ္ပါလိမ့္မယ္။"
(အေမရိကမွာ DVD ရုပ္ရွင္ေတြကုိ စာတုိက္ကေနတဆင့္ ငွားတဲ့ စီးပြားေရးလုပ္ငန္း ထြန္းကားပါတယ္။ Netflix ဆုိတဲ့ကုပၼဏီ က အေအာင္ျမင္ဆုံးပါ။ DVD တစ္ခ်ပ္ရဖုိ႔ ၃ ရက္ခန္႔ ေစာင့္ရပါတယ္။) ဒါနဲ႔ပတ္သက္လုိ႔ Vint Cerf က -
"ဆုိပါစုိ႔ Netflix က DVD တစ္ခ်ပ္ကုိ ၃ ရက္အတြင္းေရာက္ေအာင္ ပုိ႔ေပးတယ္။ DVD တစ္ခ်ပ္က 4.7GB ဆုိေတာ့
145 Kbps bandwidth ႏွုံးေလာက္ရွိမယ္။ လြန္ခဲ့တဲ့ ၂ ႏွစ္ေလာက္က Netflix ရဲ့ CEO Reed Hastings က - တစ္ေန႔ DVD အခ်ပ္ ၁.၉ သန္းခန္႔ ပုိ႔ေပးရတယ္လုိ႔ ကြ်န္ေတာ့ကုိ ေျပာတာ မွတ္မိပါတယ္။ တြက္ၾကည့္ရင္ 275Gbps ႏွုံးနဲ႔ ပုိ႔းေပးသလုိ ရွိေနပါတယ္။"
"သတင္း အခ်က္အလက္ေတြကုိ ရယူဖုိ႔ ဘယ္ေလာက္လြယ္ကူမလဲဆုိတာ ေမးစရာရွိပါတယ္။ ကၽြန္ေတာ္ေမးခ်င္တာက အင္တာနက္မွာ သတင္းအခ်က္အလက္ေတြေပ်ာက္သြားမယ္လုိ႔ မဆုိလုိပါဘူး။ အင္တာနက္မွာရွိတဲ့ အခ်က္အလက္ေတြကုိ ဘာသာျပန္ မေပးႏုိင္တဲ့အေခ်အေန ေရာက္လာမယ္လုိ႔ ဆုိခ်င္တာပါ။ အင္တာနက္ေပၚမွာရွိတဲ့ တခ်ဳိ႔ ပုံေတြရဲ့ format ကုိ နားလည္တဲ့ software ကုိရွာမရတာ မၾကာေသးခင္က ၾကဳံခဲ့ရပါတယ္။ ...........
တခါတေလ ဒီျပသနာကုိ 'ႏွစ္ ၃၀၀၀ ျပသနာ' လုိ႔ယူဆမိပါတယ္။ ျပသနာက ဒီလုိပါ။ ၃၀၀၀ ခုနွစ္မွာ ကၽြန္ေတာ္ Google လုပ္ရင္းနဲ႔ PowerPoint 97 ဖုိင္တစ္ခုကို ရွာေတြ႔ပါတယ္။ ဆုိပါစုိ႔ အဲဒီအခ်ိန္မွာ ကၽြန္ေတာ္က Windows 3000 ကုိသံုးေန တယ္ေပါ့။ PowerPoint 97 format ကုိ Windows 3000 မွာပါတဲ့ Software က ဘာသာျပန္ႏုိင္ပါ့မလားဆုိတာ ေမးစရာရွိပါတယ္။ ဒီျပသနာက Open Source application ေတြမွာလည္း ရွိႏုိင္တာပါဘဲ။
Application software တစ္ခုဟာ ႏွစ္ ၁၀၀၀ ခံဖုိ႔လုိ႔ဆုိတာ ေတာ္ေတာ္ မျဖစ္ႏုိင္ပါဘူး။ ေသေသခ်ာခ်ာ စဥ္းစား ျပင္ဆင္မထားခဲ႔ရင္ Digital content ေတြဟာ သံုးမရဘဲ ေပ်ာက္ဆုံး၊ ပုတ္သုိး ေဆြးေျမ့သြားပါလိမ္မယ္။"
Excerpts -
"It seems fair to ask how long accessibility of this information is likely to continue. By this question I do not mean that it may be lost from the Internet but, rather, that we may lose the ability to interpret it. I have already encountered such problems with image files whose formats are old and whose interpretation by newer software may not be possible. Similarly, I have ASCII text files from more than 20 years ago that I can still read, but I no longer have operating software that can interpret the formatting instructions to produce a nicely formatted page. I sometimes think of this problem as the "year 3000" problem: It is the year 3000 and I have just finished a Google search and found a PowerPoint 1997 file. Assuming I am running Windows 3000, it is a fair question whether the format of this file will still be interpretable. This problem would arise even if I were using open-source software. It seems unlikely that application software will last 1000 years in the normal course of events unless we deliberately take steps to preserve our ability to interpret digital content. Absent such actions, we will find ourselves awash in a sea of rotting bits whose meaning has long since been lost.
This problem is not trivial because questions will arise about intellectual property protection of the application, and even the operating system software involved. If a company goes out of business or asserts that it will no longer support a particular version of an application or operating system, do we need new regulations that require this software to be available on the public Internet in some way? "
မူရင္းေဆာင္းပါး အစအဆုံးကုိ
ဒီမွာ ဖတ္ၾကည့္ႏုိင္ပါတယ္။
Saturday, July 19, 2008
Path MTU Discovery
အရင္ေခါင္းစဥ္မွာေျပာခဲ့တဲ့အတုိင္း Network တစ္ခုမွာရွိတဲ့ အငယ္ဆုံး MTU ကုိ အလုိအေလ်ာက္ ရွာတဲ့နည္းလမ္းကုိ Path MTU Discovery (RFC 1191) လုိ႔ေခၚပါတယ္။ Network ထဲမွာရွိတဲ့ Router ေတြ fragmentation အလုပ္ပုိ မလုပ္ရေအာင္ ျဖစ္ပါတယ္။ IP Packet ရဲ့ Header မွာ DF (don't fragment) ဆုိတဲ့ flag bit တစ္ခု ပါပါတယ္။ Don't Fragment ဆုိတဲ့အတုိင္း၊ Packet မွာပါတဲ့ DF bit ရဲ့တန္ဖုိး ၁ ျဖစ္ေနရင္ လမ္းခုလပ္မွာရွိတဲ့ router က အဲဒီ packet ကုိ အပုိင္းပုိုင္းျဖတ္ခြင့္မရွိပါဘူး။
အရင္းေခါင္းစဥ္က ပုံကုိဆက္သုံးၾကရေအာင္။ Host0 ကေန Host2 ဆီကုိ DF bit တန္ဖုိး ၁ ရွိတဲ့ packet တစ္ခုကုိ ပုိ႔ေပးလုိက္တယ္ဆုိပါစို႔။ ပုံမွန္ဆုိရင္ Router0 ရဲ့ အထြက္ interface MTU က အ၀င္ interface MTU ထက္ ငယ္တယ္ဆုိရင္၊ Router က Packet ကုိ အပုိင္းပုိင္း ျဖတ္ေပးရပါမယ္။ Packet ထဲမွာပါတဲ့ DF bit ရဲ့ တန္ဖုိး ၁ ျဖစ္ေနခဲ့ရင္ ေတာ့ Route က Packet ကုိ အပုိင္းပုိင္းျဖတ္ရမဲ့အစား၊ Packet ကုိလည္း ဆက္ပုိ႔မေပးေတာ့ပါဘူး။ ဒါ့အျပင္ Router0 ပုိ႔ေပးတဲ့ ကြန္ပ်ဴတာ (Host0) ဆီကုိ ICMP destination unreachable (type 3) fragmentation needed and DF set (code 4) (လုိရာကုိပုိ႔မေပးႏုိင္ဘူး၊ အပုိုင္းပုိင္းျဖတ္ဖုိ႔လုိေပမယ့္ DF bit က လုပ္ခြင့္မေပးဘူး) packet တစ္ခုျပန္ပုိ႔ေပးပါတယ္။ အဲဒီ ICMP Packet ထဲမွာဘဲ Router0 Output interface ရဲ့ MTU အရြယ္အစားကုိ ထည့္ေပးလုိက္ပါတယ္။
Host0 က ICMP Packet ကုိ ရတဲ့အခ်ိန္ကစျပီး၊ Host0 ကေန Host2 ကုိ ေနာက္ထပ္ပုိ႔ေပးတဲ့ Packet အားလုံးရဲ့ အရြယ္အစားက ICMP မွာပါလာတဲ့ MTU အရြယ္အစားထက္ ပုိၾကီးျပီး မပုိ႔ေတာ့ပါဘူး။ တနည္းေျပာရရင္ Router0 က ပုိ႔ေပးလုိက္တဲ့ MTU တန္ဖုိးကုိ Host0 က လက္ခံလုိက္ျပီး၊ ေရွ.ေရွာက္ Host0 က Host2 ကုိ ပုိ႔ေပးတဲ့ packet တုိင္းဟာ အဲဒီ MTU ထက္မၾကီးေတာ့ဘူးေပါ့။
Path MTU-D ျပသနာအခ်ဳိ.
Path MTU-D အလုပ္လုပ္ဖုိ႔အတြက္ Router ကေန စပုိ႔ေပးတဲ့ကြန္ပ်ဴတာ (source host) ကုိ ျပန္ပုိ႔ေပးတဲ့ ICMP သတင္း ျပန္ေရာက္ဖုိ႔လုိအပ္ပါတယ္။ လက္ေတြ႔မွာ firewall ေတြ၊ router မွာရွိတဲ့ access control list ေတြက ICMP ကုိတားျမစ္ထားတဲ့အတြက္ေၾကာင့္ Path MTU-D ပုံမွန္ အလုပ္မလုပ္ႏုိင္ေတာ့ပါဘူး။
ဒီျပသနာကုိ ေျဖရွင္းဖုိ႔အတြက္ firewall rule ၊ router access control list မွာ ICMP type 3, code 4 ကုိ ခြင့္ျပဳေပးဖုိ႔လုိပါတယ္။
Path MTU-D အလုပ္မလုပ္ေတာ့ရင္ ကြန္ပ်ဴတာ တစ္ခုနဲ႔ တစ္ခု ဆက္သြယ္လုိ႔မရႏုိင္ပါဘူး။ ကၽြန္ေတာ္ ၾကဳံဖူးသေလာက္ Path MTU-D ျပသနာ အတက္ဆုံးေနရာေတြကေတာ့ IPSec နဲ႔ GRE tunnel ေတြပါတဲ့ ရုံးတြင္း network ေတြမွာ မ်ားပါတယ္။ အင္တာနက္ေပၚမွာေတာ့ PPPoE ကုိသုံးတဲ့ DSL network ေတြမွာ ျဖစ္တာေတြ႔ဖူးပါတယ္။
အိမ္က Windows ကြန္ပ်ဴတာက MTU ကုိ အလြယ္တကူ ျပင္ခ်င္ရင္ Dr. TCP ဆုိတဲ့ program ကုိ သုံးျပီး စမ္းၾကည့္ပါ။
စာညြန္း
IPSec/GRE ေၾကာင့္ Path MTU-D ျပသနာျဖစ္လ်င္ Cisco router ေတြမွာ ဘယ္လုိေျဖရွင္းရမယ္ဆုိတာ ဒီမွာ ဖတ္ၾကည့္ပါ။
အရင္းေခါင္းစဥ္က ပုံကုိဆက္သုံးၾကရေအာင္။ Host0 ကေန Host2 ဆီကုိ DF bit တန္ဖုိး ၁ ရွိတဲ့ packet တစ္ခုကုိ ပုိ႔ေပးလုိက္တယ္ဆုိပါစို႔။ ပုံမွန္ဆုိရင္ Router0 ရဲ့ အထြက္ interface MTU က အ၀င္ interface MTU ထက္ ငယ္တယ္ဆုိရင္၊ Router က Packet ကုိ အပုိင္းပုိင္း ျဖတ္ေပးရပါမယ္။ Packet ထဲမွာပါတဲ့ DF bit ရဲ့ တန္ဖုိး ၁ ျဖစ္ေနခဲ့ရင္ ေတာ့ Route က Packet ကုိ အပုိင္းပုိင္းျဖတ္ရမဲ့အစား၊ Packet ကုိလည္း ဆက္ပုိ႔မေပးေတာ့ပါဘူး။ ဒါ့အျပင္ Router0 ပုိ႔ေပးတဲ့ ကြန္ပ်ဴတာ (Host0) ဆီကုိ ICMP destination unreachable (type 3) fragmentation needed and DF set (code 4) (လုိရာကုိပုိ႔မေပးႏုိင္ဘူး၊ အပုိုင္းပုိင္းျဖတ္ဖုိ႔လုိေပမယ့္ DF bit က လုပ္ခြင့္မေပးဘူး) packet တစ္ခုျပန္ပုိ႔ေပးပါတယ္။ အဲဒီ ICMP Packet ထဲမွာဘဲ Router0 Output interface ရဲ့ MTU အရြယ္အစားကုိ ထည့္ေပးလုိက္ပါတယ္။
Host0 က ICMP Packet ကုိ ရတဲ့အခ်ိန္ကစျပီး၊ Host0 ကေန Host2 ကုိ ေနာက္ထပ္ပုိ႔ေပးတဲ့ Packet အားလုံးရဲ့ အရြယ္အစားက ICMP မွာပါလာတဲ့ MTU အရြယ္အစားထက္ ပုိၾကီးျပီး မပုိ႔ေတာ့ပါဘူး။ တနည္းေျပာရရင္ Router0 က ပုိ႔ေပးလုိက္တဲ့ MTU တန္ဖုိးကုိ Host0 က လက္ခံလုိက္ျပီး၊ ေရွ.ေရွာက္ Host0 က Host2 ကုိ ပုိ႔ေပးတဲ့ packet တုိင္းဟာ အဲဒီ MTU ထက္မၾကီးေတာ့ဘူးေပါ့။
Path MTU-D ျပသနာအခ်ဳိ.
Path MTU-D အလုပ္လုပ္ဖုိ႔အတြက္ Router ကေန စပုိ႔ေပးတဲ့ကြန္ပ်ဴတာ (source host) ကုိ ျပန္ပုိ႔ေပးတဲ့ ICMP သတင္း ျပန္ေရာက္ဖုိ႔လုိအပ္ပါတယ္။ လက္ေတြ႔မွာ firewall ေတြ၊ router မွာရွိတဲ့ access control list ေတြက ICMP ကုိတားျမစ္ထားတဲ့အတြက္ေၾကာင့္ Path MTU-D ပုံမွန္ အလုပ္မလုပ္ႏုိင္ေတာ့ပါဘူး။
ဒီျပသနာကုိ ေျဖရွင္းဖုိ႔အတြက္ firewall rule ၊ router access control list မွာ ICMP type 3, code 4 ကုိ ခြင့္ျပဳေပးဖုိ႔လုိပါတယ္။
Path MTU-D အလုပ္မလုပ္ေတာ့ရင္ ကြန္ပ်ဴတာ တစ္ခုနဲ႔ တစ္ခု ဆက္သြယ္လုိ႔မရႏုိင္ပါဘူး။ ကၽြန္ေတာ္ ၾကဳံဖူးသေလာက္ Path MTU-D ျပသနာ အတက္ဆုံးေနရာေတြကေတာ့ IPSec နဲ႔ GRE tunnel ေတြပါတဲ့ ရုံးတြင္း network ေတြမွာ မ်ားပါတယ္။ အင္တာနက္ေပၚမွာေတာ့ PPPoE ကုိသုံးတဲ့ DSL network ေတြမွာ ျဖစ္တာေတြ႔ဖူးပါတယ္။
အိမ္က Windows ကြန္ပ်ဴတာက MTU ကုိ အလြယ္တကူ ျပင္ခ်င္ရင္ Dr. TCP ဆုိတဲ့ program ကုိ သုံးျပီး စမ္းၾကည့္ပါ။
စာညြန္း
IPSec/GRE ေၾကာင့္ Path MTU-D ျပသနာျဖစ္လ်င္ Cisco router ေတြမွာ ဘယ္လုိေျဖရွင္းရမယ္ဆုိတာ ဒီမွာ ဖတ္ၾကည့္ပါ။
Thursday, July 17, 2008
IP Fragmentation
ပုံမွာပါတဲ့ Host0 နဲ႔ Router0 ကုိ Ethernet နဲ႔ ဆက္သြယ္ထားျပီး၊ Router0 နဲ႔ Router1 ကုိ X.25 နဲ႔ဆက္ထားတယ္ဆုိပါစုိ႔။ ၁၉၉၅ ခုႏွစ္ေလာက္က ဗမာျပည္မွာရွိတဲ့ Network တစ္ခုေပါ့။ :)
Ethernet ေပၚမွာ သြားလုိ႔ရတဲ့ အၾကီးဆုံး Frame အရြယ္အစားက ၁၅၀၀ bytes ျဖစ္ျပီး၊ X.25 ေပၚမွာ သြားလုိ႔ရတဲ့ အၾကီးဆုံး Frame အရြယ္အစားက ၅၇၆ bytes ျဖစ္ပါတယ္။ ဒီအရြယ္အစားကုိ အၾကီးဆုံးပုိ႔ေပးႏုိင္တဲ့ယူနစ္ (Maximum Transfer Unit or MTU) လုိ႔ေခၚပါတယ္။ MTU ဆုိတာ OSI 2nd Layer မွာရွိတဲ့ Framing ကေန သတ္မွတ္ထားတဲ့ တန္ဖုိးျဖစ္ျပီး၊ တန္ဖုိး အမ်ဳိးမ်ဳိး ရွိပါတယ္။
၀ီကီပီးဒီးယားက ဇယားမွာ ၾကည့္ၾကည့္ပါ။
Host0 ကေန Host2 ဆီကုိ IP packet ေတြပုိ႔တာကုိစဥ္းစာၾကည့္ရေအာင္။ Host0 က Ethernet နဲ႔ တုိက္ရုိက္ခ်ိတ္ထားတာဆုိေတာ့ ၁၅၀၀ bytes အရြယ္ packet ကုိ ပုိ႔ေပးလုိက္တယ္။ Router0 ဆီေရာက္ေတာ့ အဲဒီ packet ကုိ Router1 ပို႔တဲ့ေနရာမွာ MTU အရြယ္မတူတဲ့ အတြက္ေၾကာင့္ packet ကုိ အပုိင္းပုိင္း ျဖတ္ျပီးမွ ပုိ႔ေပးလုိ႔ရပါတယ္။ အဲလုိ အပုိင္းပုိင္းျဖတ္တာကုိ fragment လုပ္တယ္လုိ႔ေခၚပါတယ္။ ကၽြန္ေတာ္ေပးတဲ့ ဥပမာမွာဆုိရင္ Host0 က ၁၅၀၀ bytes packet ကုိ ၃ ပုိင္း ျဖတ္ျပီးမွ Router0 ကေန Router1 ဆီကုိပုိ႔ေပးလုိ႔ ရပါမယ္။
Router1 က packet ၃ ခုကုိရတဲ့အခါမွာ ၁၅၀၀ bytes packet ျဖစ္ေအာင္ ျပန္ျပီး မတြဲေပးပါဘူး။ Packet ၃ ခုကုိ ဒီအတုိင္းဘဲ Host1 ဆီကုိ ပုိ႔ေပးလုိက္ပါတယ္။ Host1 ကမွ ရတဲ့ packet ၃ ခုကုိ နဂုိအတုိင္းျပန္ျဖစ္ေအာင္ ျပန္တြဲေပးပါတယ္။ အဲလုိလုပ္တာကုိ packet reassembly လုပ္တယ္လုိ႔ ေခၚပါတယ္။
IP packet fragmentation နဲ႔ reassembly ဆုိတာ လုိအပ္လုိ႔ တီထြင္ခဲ့တာျဖစ္ေပမယ့္၊ တတ္ႏုိင္သေလာက္ ေရွာင္ၾကဥ္သင့္ပါတယ္။ ဘာေၾကာင့္လဲဆုိရင္
၁၊ Router ေတြဟာ packet ကုိျမန္ျမန္ပုိ႔ေပးရမည့္အစား၊ fragmentation အလုပ္ ပုိလုပ္ေနရတယ္၊
၂၊ Packet ေတြကုိ လက္ခံတဲ့ကြန္ပ်ဴတာကလည္း၊ data ကုိ ခ်က္ျခင္းသုံးလုိ႔မရဘဲ reassembly လုပ္ေနရတယ္၊
Fragmentation လုပ္တဲ့ Router မွာေရာ၊ လက္ခံတဲ့ကြန္ပ်ဴတာမွာ ရွိတဲ့ CPU နဲ႔ Memory ကုိ ပုိသုံးရတယ္။
ကြန္ပ်ဴတာ သုံးစြဲသူအတြက္ကေတာ့ Host0 ကေန Host1 ကုိ ဖုိ္င္တစ္ခုပုိ႔ရင္ လုိတာထက္ပုိေႏွးမွာျဖစ္ျပီး၊ email ဖတ္တာ၊ web browse လုပ္တာေတြ ပုိေႏွးေစမွာျဖစ္ပါတယ္။
ဒီျပသနာကုိ ေျဖရွင္းဖုိ႔ အလြယ္ဆုံးနည္းကေတာ့ Network မွာရွိတဲ့ အငယ္ဆုံး MTU အရြယ္အစားကုိ သိေအာင္လုပ္ျပီး၊ ကြန္ပ်ဴတာေတြ အားလုံးရဲ့ default MTU တန္ဖုိးကုိ လုိက္ျပင္ဖုိ႔ျဖစ္ပါတယ္။ Linux မွာ MTU ကုိ configuration ဖုိင္မွာျပင္လုိ႔ရျပီး၊ Windows မွာေတာ့ Registry တန္ဖုိးကုိျပင္ရပါတယ္။ Linux မ်ဳိးစုံ၊ Windows မ်ဳိးစုံဆုိေတာ့ file နာမည္ နဲ႔ registry key value ေတြက အမ်ဳိးမ်ဳိး ကြဲေနပါတယ္။ Windows မွာ အလြယ္တကူျပင္လုိ႔ရတဲ့ Dr. TCP ဆုိတဲ့ program ကုိ http://www.dslreports.com/drtcp မွာ download လုပ္ႏုိင္ပါတယ္။
ဒီမွာ ခင္ဗ်ားတုိ႔ေမးစရာ ေမခြန္းအခ်ဳိ.ရွိမယ္။
၁၊ MTU ေသးသြာေတာ့ packet ေတြပုိမ်ားလာျပီး Router ေတြနဲ႔၊ လက္ခံရတဲ့ကြန္ပ်ဴတာ ပုိအလုပ္မရွုပ္ဖူးလား ?
၂၊ Network ခပ္ေသးေသးဆုိရင္ ထားပါေတာ့၊ အင္တာနက္ေပၚမွာရွိတဲ့ Router ေသာင္းေျခာက္ေထာင္ ရဲ့ MTU တန္ဖုိးေတြကုိ ဘယ္လုိလုပ္ သိႏုိင္ပါ့မလဲ?
အေျဖ ၁၊
ပုိအလုပ္ရွုပ္တယ္ဆုိတာမွန္ပါတယ္။ ဒါေပမယ့္ Router ေတြက Packet ေတြအျမန္ဆုံးပုိ႔ႏုိင္ေအာင္ တီထြင္ထားတာျဖစ္လုိ႔ fragment လုပ္ရရင္ အားလုံးေႏွးသြားပါမယ္။ MTU တန္ဖုိးကုိ ေရြးတဲ့အခါမွာ အေသးဆုံး ဂဏန္းထက္ ပုိမေသးေအာင္ေရြးဖုိ႔ အေရးၾကီးပါတယ္။ အထက္ကေျပာခဲ့တဲ့ ဥပမာမွာ MTU ကုိ ၅၇၆ bytes အစား၊ ၁၀၀ bytes လုုိ႔ေရြးခဲ့မယ္ဆုိရင္ - fragment အလုပ္ခံရတဲ့ packet 3 ခု အစား packet 15 ခုျဖစ္သြားမယ္။ ဒီလုိဆုိရင္ေတာ့ ေတာ္ေတာ္မုိက္မဲတဲ့ အင္ဂ်င္နီယာ ျဖစ္သြားျပီ။
အေျဖ ၂၊
Network ၾကီးၾကီး သုိ႔မဟုတ္ အင္တာနက္မွာ အေသးဆုံး MTU ကုိ အလုိေလ်ာက္ လုိက္ရွာတာ ကုိ လြန္ခဲ့တဲ့ ၁၉၉၀ မွာ အၾကံျပဳ တီထြင္ခဲ့ ပါတယ္။ အဲဒီ နည္းလမ္းကုိ Path MTU Discovery လုိ႔ေခၚပါတယ္။ RFC-1191 မွာဖတ္ၾကည့္ႏုိင္ပါတယ္။ Path MTU-D အေၾကာင္းကုိ မၾကာခင္ ေရးသြားပါမယ္။
Wednesday, July 16, 2008
အေမရိက ရဲ့ ပထမဦးဆုံးသမၼတ အခ်ဳိ.
၁၇၇၆ ခု၊ ဇူလုိင္လ ၄ ရက္ေန႔မွာ အေမရိကန္လြတ္လပ္ေရးကုိ ေၾကျငာခဲ့ပါတယ္။ အဂၤလန္ ဘုရင္ ရဲ့လက္ေအာက္မွာ အခြန္ေပးရတာ ကုိမေၾကနပ္တဲ့အေၾကာင္းက အေျခခံျပီး ၁၇၇၅ ခုႏွစ္ကစျပီး စစ္ျဖစ္ခဲ့ပါတယ္။ အဂၤလန္နဲ႔ အေမရိကန္ စစ္ဟာ ၁၇၇၅ က ၁၇၈၃ ခုႏွစ္အထိ ၾကာခဲ့ျပီး၊ အေမရိကန္ စစ္တပ္ကုိ ေဂ်ာ့၀ါရွင္တန္ (၁ ေဒၚလာတန္ စကၠဴေပၚကပုံ) က ဦးေဆာင္ခဲ့ပါတယ္။
၁၇၈၃ ခု စက္တင္ဘာလ ၃ ရက္ေန႔မွာ ျပင္သစ္ႏုိင္ငံ ပဲရစ္ျမဳိ.မွာ ခ်ဳပ္ဆုိခဲ့တဲ့စာခ်ဳပ္အရ၊ အေမရိကန္နဲ႔ အဂၤလန္ စစ္ရပ္စဲျပီး၊ အဂၤလန္က အေမရိကန္ လြတ္လပ္ေရးကုိ အသိျပဳခဲ့ပါတယ္။
အေမရိကန္လြတ္လပ္ေရးအတြက္ ဦးေဆာင္ခဲ့သူေတြထဲက
၁၊ ေဂ်ာ့၀ါရွင္တန္ (George Washington)
၂၊ ဘင္ဂ်မင္ ဖရင္ကလင္ (ေဒၚလာ ၁၀၀ တန္ စကၠဴေပၚကပုံ) (Benjamin Franklin)
၃၊ ေသာမတ္ ဂ်က္ဖာဆင္ (Thomas Jefferson)
၄၊ ဂၽြန္ အက္ဒမ္စ္ (John Adams)
တုိ႔ က အဓိက အက်ဆုံးလူေတြလုိ႔ ဆုိရပါမယ္။
၁၊ ေဂ်ာ့၀ါရွင္တန္ - အေမရိကန္စစ္တပ္ရဲ့ ပထမဦးဆုံးေခါင္းေဆာင္ျဖစ္ျပီး၊ အေမရိက ရဲ့ ပထမဦးဆုံး သမၼတျဖစ္ပါတယ္။ ၁၇၈၉ ကေန၊ ၁၇၉၇ ခုႏွစ္အထိ သက္တန္းျပည့္ သမၼတတာ၀န္ ယူခဲ့ပါတယ္။
၂၊ ဘင္ဂ်မင္ ဖရင္ကလင္ - ကေတာ့ စြယ္စုံရတဲ့ အေတြးအေခၚပညာရွင္ ေခါင္းေဆာင္ျဖစ္ပါတယ္။ ရူပေဗဒ၊ လ်ွပ္စစ္၊ ဂီတ စတဲ့ ပညာရပ္နဲ႔ ပတ္သက္တဲ့ ပစၥည္း ကိရိယာ မ်ားစြာကုိ တီထြင္ခဲ့ပါတယ္။ (ဥပမာ - ဘုိင္ဖုိကယ္မ်က္မွန္၊ မုိးၾကဳိးလြဲ) ။ အေမရိကန္ လြတ္လပ္ေရး အတြက္ ထမ္းေဆာင္ခဲ့တဲ့တာ၀န္ေတြထဲက တစ္ခုကေတာ့ - ျပင္သစ္အစုိးရရဲ့ ေငြေၾကးနဲ႔ ႏုိင္ငံေရး အေထာက္အကူကုိ ရေအာင္ ေအာင္ျမင္စြာ ညွိႏွုိင္းခဲ့တာမုိ႔ ၁၇၈၃ မွာ အေမရိကန္ႏုိင္ငံကုိ အသိအမွတ္ျပဳတဲ့ စာခ်ဳပ္ ခ်ဳပ္ႏုိင္ခဲ့တာ ျဖစ္ပါတယ္။
၃၊ ေသာမတ္ ဂ်က္ဖာဆင္ - အေမရိကန္ရဲ့ တတိယ သမၼတျဖစ္ပါတယ္။ ၁၈၀၁ ကေန၊ ၁၈၀၉ ခုႏွစ္အထိ သက္တန္းျပည့္ သမၼတတာ၀န္ ယူခဲ့ပါတယ္။ ဘင္ဂ်မင္ ဖရင္ကလင္လုိ စြယ္စုံရ ပညာရွင္ ျဖစ္ပါတယ္။ အေမရိကန္ လြတ္လပ္ေရး ေၾကျငာစာတမ္းကုိ ဦးေဆာင္ျပီး ေရးခဲ့သူ ျဖစ္ပါတယ္။ သူက တစ္ေယာက္တည္း စေရးျပီး အျခားလူေတြက ေနာက္ပုိင္းမွာ ၀င္ျပင္ၾကတယ္လုိ႔ ဆုိပါတယ္။
၄၊ ဂၽြန္ အက္ဒမ္စ္ - အေမရိကန္ရ့ဲ ဒုတိယ သမၼတ ျဖစ္ပါတယ္။ အဲဒါမတုိင္ခင္ ေဂ်ာ့၀ါရွင္တန္ လက္ထက္မွာလဲ ဒု-သမၼတ တာ၀န္ကုိ ယူခဲ့ပါတယ္။ ၁၇၈၉ ကေန၊ ၁၈၀၁ ခုႏွစ္အထိ သမၼတတာ၀န္ ယူခဲ့ပါတယ္။ မန္ဆာခ်ဳးဆက္ ျပည္နယ္က ေရွ.ေနျဖစ္ျပီး၊ အဂၤလန္အစုိးရနဲ႔ ပထမဦးဆုံး စစ္စျဖစ္တဲ့ နယ္ေျမျဖစ္ပါတယ္။ အေမရိကန္လြတ္လပ္ေရးေၾကျငာဖုိ႔ အခ်ဳိ.ျပည္နယ္ေတြက မလုိလားေပမယ့္၊ ဂၽြန္ အက္ဒမ္စ္ က အေမရိကန္ လြတ္လပ္ေရးအတြက္ ဦးစီး ဦးေဆာင္ ခဲ့တဲ့သူ ျဖစ္ပါတယ္။
၁၈၂၆ ဇူလုိင္လ ၄ ရက္၊ လြတ္လပ္ေရး ေၾကျငာျပီး အႏွစ္ ၅၀ ႏွစ္ပတ္လယ္ေန႔မွာ ေသာမတ္ ဂ်က္ဖာဆင္ နဲ႔ ဂၽြန္ အက္ဒမ္စ္ တုိ႔ တရက္ထဲမွာ ကြယ္လြန္သြားၾကပါတယ္။ ဂ်က္ဖာဆင္က နာရီ နည္းနည္းေစာျပီး ဆုံးသြားတာျဖစ္ပါတယ္။ ဂၽြန္ အက္ဒမ္စ္ နဲ႔ မေသခင္ ေနာက္ဆုံးစကားက "ဂ်က္ဖာဆင္ အသက္ရွင္ေသးတယ္" ("Jefferson lives") လုိ႔ ဆုိၾကပါတယ္။
သူတုိ႔ ၾကိဳးစား ရယူခဲ့တဲ့ လြတ္လပ္ေရးကုိ အႏွစ္ ၅၀ ေစာင့္ၾကည့္ျပီးမွာ စိတ္ခ်သြားၾကတယ္ လုိ႔ေျပာရမလားဘဲ။
ကၽြန္ေတာ္တုိ႔ႏုိင္ငံရဲ့ လြတ္လပ္ေရး ဗိသုကာ ဗုိလ္ခ်ဳပ္ေအာင္ဆန္းကေတာ့ ဗမာျပည္လြတ္လပ္ေရးရတာ သိမသြား၊ ျမင္မသြားရရွာပါဘူး။
Tuesday, July 15, 2008
Traceroute
Computer Network မွာ အလုပ္လုပ္ဖူးသူတုိင္း traceroute command ကုိ တၾကိမ္မက အသုံးျပဳဖူးၾကမွာပါ။ Traceroute command အလုပ္လုပ္ပုံကုိ ေဆြးေႏြးသြားပါမယ္။
TTL and ICMP
Traceroute အေၾကာင္း မစခင္၊ TTL နဲ႔ ICMP ကုိ စေျပာဖုိ႔ လုိပါတယ္။
IP Packet ရဲ့ Header မွာ TTL (Time To Live) ဆုိတဲ့ Field တစ္ခု ပါ၀င္ပါတယ္။ IP Packet တစ္ခုဟာ Router တစ္ခုကုိ ျဖတ္သြားတုိင္း TTL ရဲ့တန္ဖုိး တစ္ခု ေလ်ာ့သြားပါတယ္။ တနည္းေျပာရလ်င္ Router တစ္ခုက ျဖတ္သြားတဲ့ Packet တုိင္းရဲ့ TTL တန္ဖုိးကုိ တစ္ခုႏွုတ္ေပးပါတယ္။ TTL တန္ဖုိး သုည ျဖစ္သြားခဲ့လ်င္ Router က အဲဒီ Packet ကုိ ဖ်က္ဆီးျပစ္လုိက္ျပီး၊ Packet ကုိ လုိရာေရာက္ေအာင္ မပုိ႔ေပးႏုိင္တဲ့အေၾကာင္း စတင္ပုိ႔ေပးတဲ့ ကြန္ပ်ဴတာ (source computer) ကုိျပန္ျပီး သတင္းပုိ႔ေပးပါတယ္။ ဒီလုိ TTL သုည ျဖစ္သြားလုိ႔ Packet မပုိ႔ေပးႏုိင္တဲ့အေၾကာင္းကုိ ICMP (Internetwork Control Message Protocol) ကုိအသုံးျပဳျပီး အေၾကာင္းၾကားပါတယ္။ ဒီလုိလုပ္ရတဲ့ အေၾကာင္းရင္းကေတာ့ အင္တာနက္ထဲမွာ လမ္းစေျပာက္ေနတဲ့ Packet ေတြ မျပီးႏုိင္ မစီးႏုိင္ သြားေနမွာကုိ တားျမစ္ဖုိ႔ ျဖစ္ပါတယ္။
ICMP ရဲ့တာ၀န္က IP Packet ေတြကုိ အမွားျပင္တဲ့ေနရာမွာ အကူအညီေပးဖုိ႔ျဖစ္ပါတယ္။ ICMP မွာ Type နဲ႔ Code ဆုိျပီး IP Packet တစ္ခု ဘယ္လုိ ျပသနာတက္ေနတယ္ဆုိတာ ခြဲျခားေပးထားပါတယ္။ TTL သုညျဖစ္သြားခဲ့လ်င္ -
ICMP Type 11 - Time Exceeded (အခ်ိန္ကုန္သြားျပီ၊)
Code 0 - Time To Live Exceed In Transit (လမ္းခုလတ္မွာ TTL တန္ဖုိး သုည ျဖစ္သြားျပီ၊)
ဆုိျပီး မူလ ကြန္ပ်ဴတာကုိ ျပန္ပုိ႔ ေပးပါတယ္။
Time To Live ဆုိေပမယ့္ အခ်ိန္ (မိနစ္၊ စကၠန္႔) ကုိ ဆုိလုိတာ မဟုတ္ပါဘူး၊ Network မွာ ျဖတ္သြားရမယ့္ Router တစ္ခုတိုင္း (Layer 3 hop to be more specific) ကုိ Time Unit တစ္ခုလုိ႔ တြက္ခ်က္ပါတယ္။ TTL ဆုိတာ ကြန္ပ်ဴတာ တစ္ခုက ထုတ္လုိက္တဲ့ IP Packet တစ္ခု ဘယ္ေလာက္ေ၀းေ၀ သြားလုိ႔ရတယ္ ဆုိတာကုိ သတ္မွတ္ထားတဲ့ နံပါတ္တစ္ခုျဖစ္ပါတယ္။
Traceroute in action
ကၽြန္ေတာ့အိမ္က ကြန္ပ်ဴတာက www.google.com ကုိ traceroute လုပ္ထားတာကုိၾကည့္ၾကည့္ရေအာင္၊
[kyaw31@bart ~]# traceroute www.google.com
traceroute to www.google.com (64.233.169.103), 30 hops max, 40 byte packets
1 homer (10.19.184.1) 8.737 ms 8.946 ms 13.098 ms
2 vl4.aggr1.nyw.ny.rcn.net (208.59.246.1) 15.053 ms 15.461 ms 15.724 ms
3 tge1-2.border1.nyw.ny.rcn.net (207.172.19.110) 15.278 ms 15.547 ms 15.807 ms
4 core1-0-2-0.lga.net.google.com (198.32.160.130) 16.070 ms 16.189 ms 15.887 ms
5 72.14.236.215 (72.14.236.215) 18.521 ms 18.744 ms 216.239.49.34 (216.239.49.34) 28.942 ms
6 66.249.94.235 (66.249.94.235) 24.129 ms 16.170 ms 209.85.248.216 (209.85.248.216) 18.162 ms
7 64.233.175.111 (64.233.175.111) 17.986 ms 18.260 ms 72.14.236.200 (72.14.236.200) 17.688 ms
8 216.239.49.149 (216.239.49.149) 20.581 ms 216.239.49.145 (216.239.49.145) 24.182 ms 25.188 ms
9 yo-in-f103.google.com (64.233.169.103) 21.938 ms 22.055 ms 22.462 ms
[kyaw31@bart ~]#
အဆင့္ ၁။
(က) ကၽြန္ေတာ့ကြန္ပ်ဴတာက TTL တန္ဖုိး ၁ ပါတဲ့ IP Packet တစ္ခုကုိ www.google.com ပုိ႔လုိက္တယ္။
(ခ) ကၽြန္ေတာ့အိမ္က Router (homer / 10.19.184.1) က TTL ကုိ ၁ ႏွုတ္လုိက္တဲ့အခါ၊ TTL သုညျဖစ္သြားတယ္။ ဒါေၾကာင့္ အိမ္က Router က ICMP Time Exceeded (Type 11), Time To Live Exceed In Transit (0) ဆုိတဲ့သတင္းကုိ ကၽြန္ေတာ့ ကြန္ပ်ဴတာကုိ ျပန္ပုိ႔ေပးတယ္။
အဆင့္ ၂။
(က) ကၽြန္ေတာ့ကြန္ပ်ဴတာက TTL တန္ဖုိး ၂ ပါတဲ့ IP Packet တစ္ခုကုိ www.google.com ပုိ႔လုိက္တယ္။
(ခ) ကၽြန္ေတာ့အိမ္က Router က TTL ကုိ ၁ ႏွုတ္လုိက္တဲ့အခါ၊ TTL ၁ ျဖစ္သြားတယ္။ ဒါေၾကာင့္ ေနာက္တဆင့္မွာရွိတဲ့ ကၽြန္ေတာ့ ISP ရဲ့ Router (vl4.aggr1.nyw.ny.rcn.net / 208.59.246.1) ဆီကုိ လက္ဆင့္ကမ္းေပးလုိက္တယ္။
(ဂ) ISP Router က TTL ကုိ ၁ ႏွုတ္လုိက္တဲ့အခါ၊ TTL သုညျဖစ္သြားတယ္။ ဒါေၾကာင့္ ISP Router က ICMP Time Exceeded (Type 11), Time To Live Exceed In Transit (0) ဆုိတဲ့သတင္းကုိ ကၽြန္ေတာ့ ကြန္ပ်ဴတာကုိ ျပန္ပုိ႔ေပးတယ္။
.
.
အဆင့္ ၈။
(က) ကၽြန္ေတာ့ကြန္ပ်ဴတာက TTL တန္ဖုိး ၈ ပါတဲ့ IP Packet တစ္ခုကုိ www.google.com ပုိ႔လုိက္တယ္။
(ခ) 216.239.49.149 က Google ရဲ့ Router ျဖစ္ျပီး၊ အထက္မွာေရးျပတဲ့အတုိင္း TTL ႏွုတ္၊ ICMP ျပန္ပုိ႔ထပ္ျဖစ္ပါမယ္။
အဆင့္ ၉။
(က) ကၽြန္ေတာ့ကြန္ပ်ဴတာက TTL တန္ဖုိး ၉ ပါတဲ့ IP Packet တစ္ခုကုိ www.google.com ပုိ႔လုိက္တယ္။
(ခ) ဒီအဆင့္မွာေတာ့ google.com ရဲ့ server ဆီကုိေရာက္သြားပါတယ္။ Google server မွာ traceroute က ေတာင္းဆုိတဲ့ UDP Port မွာ နားေထာင္မေနတဲ့အတြက္ေၾကာင့္ ICMP Destination Unrechable (Type 3), Port Unrecheable (code 3) ကုိ ကၽြန္ေတာ့ ကၽြန္ပ်ဴတာဆီ ျပန္ပုိ႔ေပးပါတယ္။
Traceroute options
Linux မွာ Default အေနနဲ႔ UDP ကုိသုံးပါတယ္။
ICMP သုံးခ်င္လ်င္ -I option နဲ႔သုံးလုိ႔ရပါတယ္။ (traceroute -I www.google.com)
ေနာက္ပုိုင္းထြက္တဲ့ Linux မွာ TCP ကုိ -T Option နဲ႔သုံးလုိ႔ရပါတယ္။ ဘယ္ Linux version က စခဲ့တယ္မသိပါဘူး။ ဥပမာ (Red Hat 4.1.2-33) မွာ TCP option သုံးလုိ႔ရျပီး၊ (Ubuntu 4.1.2-0ubuntu4) မွာ မရပါဘူး။ (traceroute -T www.google.com)
Windows မွာ Default အေနနဲ႔ ICMP ကုိသုံးပါတယ္။ UDP သုိ႔မဟုတ္ TCP ေျပာင္းသုံးလုိ႔မရပါဘူး။
Cisco IOS မွာ Default အေနနဲ႔ UDP ကုိသုံးပါတယ္။ တျခားေျပာင္းသုံးလုိ႔မရပါဘူး။
Firewall တုိ႔၊ Packet filtering device တုိ႔ ၾကားထဲမွာ ခံေနခဲ့ရင္ TCP နဲ႔ Traceroute လုပ္မွရႏုိင္ပါမယ္။ မ်ားေသာအားျဖင့္ firewall ေတြဟာ UDP နဲ႔ ICMP ကုိ တားျမစ္ထားေလ့ရွိပါတယ္။
တကယ္တမ္း RFC-1393 အလုိအရဆုိလ်င္ ICMP ကုိသံုးရမွာပါ။ Microsoft က ႏုိင္ငံတကာ Standard ကုိတေသြမတိမ္းလုိက္နာျပီး၊ Linux Community က ထင္ရာလုပ္ေနတာ ေတြ႔ရခဲပါတယ္။
Traceroute မွာ Default အေနနဲ႔ UDP ကုိသုံးျပီး UDP Port Number 33434 ကစျပီး 33534 အထိ နံပါတ္ တစ္ခုစီ တက္သြားပါတယ္။ Google.com ကုိ traceroute လုပ္စဥ္မွာ Sniffer မွာ ေတြ႔ရမယ့္ UDP Packet ေတြကုိၾကည့္ရင္သိႏုိင္ပါတယ္။
[kyaw31@bart ~]# tcpdump -i eth0 udp
20:10:15.394884 IP 172.16.31.66.41753 > yo-in-f147.google.com.33434: UDP, length 40
20:10:15.394913 IP 172.16.31.66.43257 > yo-in-f147.google.com.33435: UDP, length 40
20:10:15.394936 IP 172.16.31.66.45438 > yo-in-f147.google.com.33436: UDP, length 40
20:10:15.394956 IP 172.16.31.66.41551 > yo-in-f147.google.com.33437: UDP, length 40
20:10:15.394977 IP 172.16.31.66.51521 > yo-in-f147.google.com.33438: UDP, length 40
20:10:15.394998 IP 172.16.31.66.58529 > yo-in-f147.google.com.33439: UDP, length 40
20:10:15.395019 IP 172.16.31.66.59242 > yo-in-f147.google.com.33440: UDP, length 40
20:10:15.395043 IP 172.16.31.66.41370 > yo-in-f147.google.com.33441: UDP, length 40
Traceroute History
Traceroute program ကုိ ၁၉၈၇ ႏွစ္မွာ Van Jacobson က C နဲ႔ ေရးခဲ႔ပါတယ္။ ပထမဦးဆံုး ICMP ကုိသံုးျပီးေရးပါတယ္။ ဒါေပမယ့္ အဲဒီအခ်ိန္က Router ေတြမွာ ICMP Echo Request ကုိ TTL တန္ဖုိး သုညေရာက္တဲ့အခါမွာ ICMP Time Exceeded သတင္းျပန္ပုိ႔တဲ့ အလုပ္ မလုပ္ၾကပါဘူး။ ဒါေၾကာင့္ Van က Traceroute ကုိ UDP နဲ႔ျပန္ေရးခဲ့ပါတယ္။ ၁၉၉၉ ခုႏွစ္မွာ Van ကုိဒါနဲ႔ပတ္သက္လုိ႔ေမးတာ ျပန္ေျဖထားတဲ့ e-mail ကုိ ေအာက္မွာဖတ္ၾကည့္ပါ။
From: van@ee.lbl.gov (Van Jacobson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: traceroute history: why UDP?
Date: 8 Feb 1999 08:36:20 GMT
Organization: Lawrence Berkeley National Laboratory, Berkeley CA
Message-ID: <79m7m4$reh$1@dog.ee.lbl.gov>
References: <79lub9$8e81@oberon.sweden.hp.com>
In article <79lub9$8e81@oberon.sweden.hp.com>,
stevesk@sweden.hp.com (Kevin Steves) writes:
> Were ICMP probes considered in 1988 when Van wrote traceroute?
The very first traceroute (never released) used icmp echo. RFC792 (the
icmp spec) contains the words:
The ICMP messages typically report errors in the processing of
datagrams. To avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages.
During the first night of testing I found that more than half the
router vendors of the time had taken this at face value & would not
return an ICMP Time Exceeded for an ICMP Echo. That's when I changed
to UDP.
- Van
စာႂကြင္း
traceroute ရဲ့ source code ကုိဖတ္လုိသူမ်ား၊ compile လုပ္လုိသူမ်ား Lawrence Berkeley National Laboratory ကေန FTP download လုပ္ယူလုိ႔ရပါတယ္။
FTP site က ftp.ee.lbl.gov ျဖစ္ျပီး၊ ေနာက္ဆုံး update လုပ္ထားတာက ဒီဇင္ဘာ ၁၈၊၂၀၀၀ ေန႔ကျဖစ္ပါတယ္။ Filename က ေတာ့ traceroute-1.4a12.tar.gz ျဖစ္ျပီး၊ Filesize က 74917 bytes ျဖစ္ပါတယ္။ Download လုပ္လုိ႔မရလ်င္ Blog မွာ e-mail ေပးခဲ့ပါ၊ ကၽြန္ေတာ္ e-mail attachment ျပန္ပုိ႔ေပးပါမယ္။
Monday, July 7, 2008
အင္တာနက္ သမုိင္း တပုိင္းတစ
ကၽြန္ေတာ္ဖတ္ခဲ့ဖူူးတဲ့ "Where Wizards Stay Up Late : The Origins of the Internet" စာအုပ္ထဲက ေကာင္းႏုိးရာရာေလးေတြေရးသြားပါမယ္။
အင္တာနက္ကုိပထမဦးတီထြင္ခဲ့တဲ့သူေတြကုိစာရင္းျပဳရလ်င္ အနည္းဆုံး လူ ၃၀၊ ၄၀ ေလာက္ရွိပါမယ္။ သူတုိ႔ေတြထဲက ကၽြန္ေတာ္ မွတ္မိသေလာက္၊ စုေဆာင္းမိသေလာက္ ေျပာသြားပါမယ္။
အင္တာနက္ရဲ့ ပထမဦးဆုံးအစကေတာ့ အေမရိကန္စစ္တပ္ သုေတသနဌာန (ARPA - Advanced Research Project Agency) ရဲ့ ARPANet ျဖစ္ပါတယ္။ ARPANet ကုိဦးေဆာင္ခဲ့သူေတြထဲမွာ Joseph Licklider, Larry Roberts နဲ႔ Bob Taylor တို႔က အဓိကလူေတြျဖစ္ပါတယ္။ ARPANet ရဲ့ရည္ရြယ္ခ်က္က Hardware, Operating Systems အမ်ဳိးမတူတဲ့ ကြန္ပ်ဴတာေတြ အခ်င္းခ်င္း ဆက္သြယ္လုိ႔ရေအာင္ Network တစ္ခု တည္ေဆာက္ဖုိ႔ျဖစ္ပါတယ္။ ဒီလုိ အေတြးအေခၚေတြစခဲ့တာကေတာ့ ၁၉၆၅ ခုႏွစ္၀န္းက်င္မွာ ျဖစ္ပါတယ္။
အဲဒီအခ်ိန္မွာ Stored and Forward Packet Switched Network ဆုိတဲ့ အေတြးအေခၚကုိ စာတန္းေတြေရးျပီး စတင္ေဆြးေႏြးခဲ့ပါတယ္။ Stored and Forward Packet Switched Network ဆုိတဲ့ အေတြးအေခၚကုိ တည္ထြင္ခဲ့သူေတြကေတာ့ Paul Baran, Donald Davies နဲ႔ Leonard Kleinrock တို႔ျဖစ္ပါတယ္။ ၁၉၆၀ ဆုိေတာ့ Alexander Graham Bell ၁၈၇၀ ခုႏွစ္ကတည္ထြင္ခဲ့တဲ့ Circuit Switched Phone Network ကႏွစ္ ၉၀ ေက်ာ္အေျခက်ေနျပီဆုိတာ သတိျပဳေစခ်င္ပါတယ္။ Stored and Forward Packet Switched Network ဆုိတာ ၁၉၆၅ မွာ ဘယ္သူမွမၾကားဖူးတဲ့ အထူးအဆန္းနည္းပညာေပါ့။
ARPANet ကလူေတြနဲ႔ Packet Switched Network ကုိစာတန္းေရးတဲ့သူေတြေပါင္းျပီး မ်ဳိးမတူတဲ့ ကြန္ပ်ဴတာေတြ စကားေျပာဖုိ႔ စက္တစ္ခုထြင္ဖုိ႔ Design ျပင္ဆင္ၾကပါတယ္။ အဲဒီတုံးက ကြန္ပ်ဴတာဆုိတာ DEC PDP တုိ႔၊ IBM 360 တုိ႔လုိ mainframe ေတြျဖစ္ပါတယ္။ ကၽြန္ေတာ္ တစ္ခါမွ မသုံးဖူးပါဘူး၊ စာအုပ္ေတြနဲ႔၊ ျပတုိက္ေတြမွာဘဲျမင္ဘူးပါတယ္။ (ရန္ကုန္ ကြန္ပ်ဴတာ တကၠသုိလ္မွာ DEC PDP တစ္ခုရွိပါတယ္၊)။ သူတုိ႔တည္ထြင္တဲ့စက္ကုိ IMP (Interface Message Processor) လုိ႔ေခၚျပီး၊ စက္တည္ေဆာက္ဖုိ႔အတြက္ BBN (Bolt, Beranek and Newman) ဆုိတဲ့ကုမၸဏီက Contract အႏုိင္ရသြားပါတယ္။ BBN မွာ IMP တည္ေဆာင္တဲ့သူေတြထဲမွာ Bob Kahn နဲ႔ Frank Heart တုိ႔က အဓိကျဖစ္ပါတယ္။ ပထမဦးဆုံးအေနနဲ႔ IMP ၄ ခု တည္ေဆာက္ဖုိ႔ ဆုံးျဖတ္ခဲ့ပါတယ္။ IMP ဆုိတာကေတာ့ ဒီေန႔ေခတ္ Router ေတြရဲ့ ေရွ႔ေျပးျဖစ္တယ္လုိ႔ေျပာရပါမယ္။
ဒီမွာ စိတ္၀င္စားစရာေကာင္းတာတစ္ခုက - စစ္တပ္ကေပးတဲ့ပုိက္ဆံနဲ႔လုပ္တဲ့သုေတသနအလုပ္ဆုိေတာ့၊ ဦးေဏွာက္ရွိတာ၊ မရွိတာ အသာထား စစ္တပ္မွာဘဲ စစ္တပ္ထဲကလူေတြနဲ႔ IMP စက္အသစ္ေတြကုိ တပ္ဆင္၊ စမ္းသပ္၊ သုံးစြဲမယ္လုိ႔ - မဆုံးျဖတ္ခဲ့ပါဘူး။ သုေတသန အလုပ္အတြက္ အေကာင္းဆုံးေနရာဟာ တကၠသုိလ္ေက်ာင္းေတြမွာျဖစ္တဲ့ အတြက္ေၾကာင့္ IMP ေတြကုိ
၁၊ UCLA (University Of California, Los Angeles)
၂၊ SRI (Stanford Research Institute)
၃၊ UCLA (University of California, Santa Babara)
၄၊ University Of Utah
တကၠသုိလ္ ၄ ခုမွာ တပ္ဆင္၊ စမ္းသပ္၊ သုံးစြဲ ခဲ့ပါတယ္။
ေက်ာင္းတစ္ခုနဲ႔တစ္ခုၾကားကုိ ဆက္သြယ္ေပးတာက ေတာ့ AT&T ရဲ့ 50Kbps ဖုံးလုိင္းျဖစ္ပါတယ္။ IMP က Honeywell ကထုတ္လုပ္တဲ့ DDP-516 minicomputer ျဖစ္ျပီး Memory 12KB ပါ ပါတယ္။ ေက်ာင္းေတြမွာ ရွိတဲ့ကြန္ပ်ဴတာေတြက ေတာ့ ေအာက္ပါအတုိင္းျဖစ္ပါတယ္။
Node 1: UCLA (1969 2nd September)
* System,OS: SDS SIGMA 7, SEX
Node 2: Stanford Research Institute (SRI) (1969 1st October)
* SDS940/Genie
Node 3: University of California Santa Barbara (UCSB) (1969 1st November)
* IBM 360/75, OS/MVT
Node 4: University of Utah (December)
* DEC PDP-10, Tenex
ပထမဦးဆံုး IMP ကုိ UCLA မွာ ၁၉၆၉ ခု စက္တင္ဘာလ ၂ ရက္ေန႔မွာ တပ္ဆင္ခဲ့ပါတယ္။ UCLA ရဲ့ ကြန္ပ်ဴတာအခန္းက တတိယထပ္မွာပါ။ IMP ကၾကီးလြန္းလွတဲ့အတြက္ ဓါတ္ေလွခါးထဲကုိထဲ့လုိ႔မရပါဘူး။ ဒါေၾကာင္း IMP ကုိ ခက္ရင္းခြမစက္ နဲ႔ မျပီး ကြန္ပ်ဴတာခန္း ျပတင္းေပါက္တစ္ခုကေန သြင္းခဲ့ရတယ္လုိ႔ေျပာၾကပါတယ္။ UCLA က ကြန္ပ်ဴတာသိပၸံဆရာေတြ၊ ေက်ာင္းသားေတြထဲမွာ အဓိက ေခါင္းေဆာင္ခဲ့သူေတြကေတာ့ Vint Cerf, Steve Crocker နဲ႔ Jon Postel တုိ႔ျဖစ္ပါတယ္။ အဲဒီေန႔က အစိုးရ၊ စစ္တပ္၊ ဖံုးကုမၸဏီ နဲ႔ တကၠသုိလ္ကလူ ၂၀ ေလာက္ mainframe ကြန္ပ်ဴတာကေန IMP ကုိ ႀကဳိးညဳိညဳိ တုပ္တုပ္ၾကီးနဲ႔ ဆက္ထားျပီး Packet ေတြသြားေနတာကုိ အားရ၀မ္းသာၾကည့္ေနခဲ့ၾကသတဲ့။ "အဲဒီအခုိက္အတန္႔ဟာ သမုိင္းမွာအေရးၾကီးမယ္လုိ႔မထင္ခဲ့မိဘူး၊ တစ္ေယာက္မွလဲ ကင္မရာမပါလုိ႔ ဓါတ္ပုံရုိက္ဖုိ႔သတိမရခဲ့ၾကဖူး" လုိ႔ Leonard Kleinrock ကေနာက္ပုိင္းမွာျပန္ေျပာပါတယ္။ ကြန္ပ်ဴတာ နဲ႔ Router ခ်ိတ္ျပီးသြားျပီ၊ Network ေတာ့မျဖစ္ေသးဘူးေပါ့။
၁၉၆၉ ေအာက္တုိဘာလ ၂၉ ရက္ေန႔မွာ ဒုတိယ IMP ကုိ SRI မွာစတင္တပ္ဆင္ခဲ့ပါတယ္။ SRI ကအဓိကလူေတြကေတာ့ Elizabeth Feinler နဲ႔ Don Nielson တုိ႔ျဖစ္ပါတယ္။ IMP နဲ႔ ကြန္ပ်ဴတာကုိ ၾကဳိးေတြခ်ိတ္၊ IMP ကုိ ဖုံးလုိင္းနဲ႔ခ်ိတ္၊ ျပီးတာနဲ႔ ပထမဦးဆုံးအင္တာနက္ကုိ စတင္စမ္းသပ္ဖုိ႔ျပင္ပါတယ္။ စမ္းတဲ့ေက်ာင္းသားကေတာ့ UCLA က Charley Kline ျဖစ္ျပီး၊ Leonard Kleinrock ကေနာက္ကေန ေစာင့္ၾကည့္ေနပါတယ္။ Charley Kline က UCLA ကြန္ပ်ဴတာကေန SRI ကြန္ပ်ဴတာကုိ Login လုပ္ဖုိ႔အတြက္ L-O-G-I-N ဆုိျပီး တစ္လုံးစီရုိက္မွာျဖစ္ပါတယ္။ SRI က လူတစ္ေယာက္က သူ႔ဘက္မွာ ေပၚလာတာကုိ ျပန္ဖတ္ေပးဖုိ႔ ဖုံးေပၚမွာေစာင့္ေနပါတယ္။
UCLA : "Did you get the L?"
SRI : "Yes, I got the L"
UCLA : "Did you get the O?"
SRI : "Yes, I got the O."
UCLA : "Did you get the G?"
Both : Crash!
အင္တာနက္အစ Crash ကလုိ႔ေျပာရမလုိျဖစ္ေနပါတယ္။ ဘာျဖစ္တာလဲဆုိေတာ့ - ေရးထားတဲ့ Program က Log ဆုိတာကုိ ရတာနဲ႔ in ဆုိတာကုိ UCLA ဘက္ အလုိေလ်ာက္ေပၚလာေအာင္ ေရးခဲ့ပါတယ္။ IMP မွာပါတဲ့ memory က 12KB ဘဲဆုိေတာ့ Buffer Overrun ျဖစ္သြားတာျဖစ္ပါတယ္။ နာရီပုိင္းအတြင္းမွာ Program ကုိ ျပန္ျပင္ေရးျပီးတဲ့ေနာက္ အားလုံး အဆင္ေျပသြားတယ္လုိ႔ ဆုိပါတယ္။
ဒီပုံထဲက Network ကအလုပ္လုပ္မွာ မဟုတ္ပါဘူး၊ စကားေျပာခြက္နဲ႔ နားေထာင္တာတဲ့ လြဲေနပါတယ္။ Transmit က Transmit နဲ႔ ခ်ိတ္ထားျပီး Receive က Receive နဲ႔ခ်ိတ္ထားပါတယ္။
Vint Cerf ေျပာတဲ့အတုိင္း ျပန္ေရးရလ်င္ -
"This photo was published in the August 8, 1994 issue of Newsweek and commemorates the 25th anniversary of the ARPANET. Jon Postel, Steve Crocker and I spent hours helping the photographer prepare for this shot.
Jon drew all the pictures, Steve and I strung the zucchini and the yellow squash. I think we must have collectively spent about 8 hours on this.
Note that this network can't work - there is no mouth/ear link anywhere!!!
Such was the state of networking in the primitive 1960s....."
အင္တာနက္ကုိ စတင္တီထြင္ခဲ့ၾကသူေတြရဲ့ ဓါတ္ပုံနဲ႔ ဘ၀အက်ဥ္းခ်ဳံးကုိ http://www.chick.net/wizards/pioneers.html မွာ ဖတ္ၾကည့္ႏုိင္ပါတယ္။
My man Roger . . . . . . Lost . . . :(
It was a great match .. 2008 Wimbledon Mens' Final. I spent all day, from 9AM to 4PM to watch the match, and it was fantastic even though the result sadden me.
Here is my take how Nadal beats The Mighty Fed -
1. When rallies turn into Federer's backhand and Nadal's forehand, Nadal wins most of the exchanges.
2. To neutralize the deficit, Federer has to move out of the court to take a forehand. That leaves the whole tennis court wide open for Nadal. At this point, Federer is in do-or-die situation and he tried to hit a down-the-line forehand winner - which goes to Nadal's backhand. Nadal take the power from Federer's forehand and hit a cross-court backhand winner. And that happens alot. We have seen Federer scrambling to his forehand side of the court after he hit his forehand winner.
3. Federer 42 of 75 = 56% vs. Nadal 22 of 31 = 71% (Net Point won). It is true that Federer approached to the net more than Nadal but the winning percentage is low. Most of the time, Federer approached to the net in desperate situation. In other words, Federer went to the net when he exhausted other options and he was doing based on Nadal's term.
If I have to pick a game that made Fed lost the 2008 Championship, it will be 4-3 in the second set. Not sure it was a lapse of concentration - but Fed played a very loose game.
Of all the mistakes, that mid-court forehand drive volley that sailed well behind baseline was the shot that lost the championship.
But .. Rafa played a great match and he deserved the championship. Congratulations Rafa.
Here is my take how Nadal beats The Mighty Fed -
1. When rallies turn into Federer's backhand and Nadal's forehand, Nadal wins most of the exchanges.
2. To neutralize the deficit, Federer has to move out of the court to take a forehand. That leaves the whole tennis court wide open for Nadal. At this point, Federer is in do-or-die situation and he tried to hit a down-the-line forehand winner - which goes to Nadal's backhand. Nadal take the power from Federer's forehand and hit a cross-court backhand winner. And that happens alot. We have seen Federer scrambling to his forehand side of the court after he hit his forehand winner.
3. Federer 42 of 75 = 56% vs. Nadal 22 of 31 = 71% (Net Point won). It is true that Federer approached to the net more than Nadal but the winning percentage is low. Most of the time, Federer approached to the net in desperate situation. In other words, Federer went to the net when he exhausted other options and he was doing based on Nadal's term.
If I have to pick a game that made Fed lost the 2008 Championship, it will be 4-3 in the second set. Not sure it was a lapse of concentration - but Fed played a very loose game.
Of all the mistakes, that mid-court forehand drive volley that sailed well behind baseline was the shot that lost the championship.
But .. Rafa played a great match and he deserved the championship. Congratulations Rafa.
Subscribe to:
Posts (Atom)
