เมื่อวันศุกร์ ที่ 31 กรกฏาคม 2552 เวลา 15:55 น. อุปกรณ์ Wireless Controller ที่ควบคุม Access Point ทั้งหมดของ มทร.ล้านนา ภาคพายัพเชียงใหม่ (เจ็ดยอด เจ็ดลิน) ไม่สามารถใช้งานได้
ขณะกำลังดำเนินการแก้ไขปัญหาที่เกิดขึ้น และยังไม่ทราบสาเหตุที่แท้จริง

สาเหตุเกิดจาก มีเครื่องลูกข่ายบางเครื่อง ส่งข้อมูลที่เป็นลักษณะของ UDP Scan ผ่านตัวคอนโทรลเลอร์ จึงทำให้ ระบบป้องกัน (AQE) เข้าใจผิดว่าตัวคอนโทรลเลอร์ มีตัวส่งข้อมูลออกมา จึงกักกันคอนโทรลเลอร์ให้อยู่ใน AQE

ขณะนี้ได้ทำการแก้ไขโดยระบุตัวตนของคอนโทรลเลอร์ให้กับ AQE รู้จัก (ไม่ต้องแบน) จึงทำให้ระบบกลับมาใช้งานได้ตามปกติ

วันพฤหัสบดีที่ 30 กรกฏาคม 2552 เวลา 09:35 – 10:35 น. เกิดเหตุระบบเครือข่ายขัดข้องที่ node 2 เชียงใหม่ ส่งผลกระทบต่อสมาชิกที่เชื่อมต่อกับ node2 ทั้งหมด คือ แผนกเทคนิคคอมพิวเตอร์ แผนกไฟฟ้า แผนกอิเล็กทรอนิกส์ และอาคารศึกษาทั่วไป

รวมระยะเวลา 1 ชั่วโมง – นาที

จากการตรวจสอบพบว่า มีการส่งแพ็คเก็จจำนวนมากจากหมายเลขไอพี 10.2.4.119  (มาจากพอร์ต 1/22)จึงทำให้โหลดของ Switching ขึ้นสูง จนไม่สามารถใช้งานได้

การแก้ไขปัญหาเฉพาะหน้า ด้วยการปิดพอร์ต 1/22 ชั่วคราว เมื่อหาเครื่องต้นเหตุเจอแล้ว จะดำเนินการเชื่อมต่อให้ตามปกติ

ซึ่งจะทำให้ การใช้งานระบบเครือข่ายของ อาคารศึกษาทั่วไป ทั้งอาคาร ไม่สามารถใช้งานได้

ขณะนี้ได้ดำเนินการแก้ไขเป็นที่เรียบร้อยแล้ว สาเหตุมาจาก การเชื่อมต่อฮับ ทำให้เกิดลูปขึ้นในระบบเครือข่าย

รูปแบบแพ็คเก็จที่ถูกส่งมาจากเครื่องต้นเหตุ มีดังนี้

1 R 1/24 (001d60139ba7)->(ffffffffffff) ARP Request 10.2.4.119->10.2.4.254
1 S 1/24 00e0b1a31240->001d60139ba7 ARP Reply 10.2.4.254->10.2.4.119
1 R 1/24 (001d60139ba7)->(ffffffffffff) ARP Request 10.2.4.119->10.2.4.254
1 S 1/24 00e0b1a31240->001d60139ba7 ARP Reply 10.2.4.254->10.2.4.119
1 R 1/24 (001d60139ba7)->(ffffffffffff) ARP Request 10.2.4.119->10.2.4.254
1 S 1/24 00e0b1a31240->001d60139ba7 ARP Reply 10.2.4.254->10.2.4.119
1 R 1/24 (001d60139ba7)->(ffffffffffff) ARP Request 10.2.4.119->10.2.4.254
1 S 1/24 00e0b1a31240->001d60139ba7 ARP Reply 10.2.4.254->10.2.4.119
1 R 1/24 (001d60139ba7)->(ffffffffffff) ARP Request 10.2.4.119->10.2.4.254
1 S 1/24 00e0b1a31240->001d60139ba7 ARP Reply 10.2.4.254->10.2.4.119
1 R 1/24 (001d60139ba7)->(ffffffffffff) ARP Request 10.2.4.119->10.2.4.254
1 S 1/24 00e0b1a31240->001d60139ba7 ARP Reply 10.2.4.254->10.2.4.119

วันเสาร์ที่ 4 กรกฎาคม 2552 เวลา 17.45 น. ไฟฟ้า(น่าจะ)ขัดข้องที่ node 1 เชียงใหม่ ทำให้ระบบเครือข่ายขัดข้อง และเนื่องจากเป็นวันหยุดยาว จึงไม่สามารถดำเนินการเปิดใช้/ตรวจสอบสาเหตุที่แท้จริงได้

แผนก/ตึก/อาคาร ที่ได้รับผลกระทบจากเหตุการณ์ดังกล่วคือ

อาคารอำนวยการ,โรงอาหาร,อาคารบริหารธุรกิจ (ทั้งหมด),โรงหล่อ,เทคนิคอุตสาหกรรม,วิศวอุตสาหกรรม,อาคารแม่พิมพ์

จากการตรวจสอบพบว่า สาเหตุเกิดจาก เครื่องสำรองไฟฟ้าขัดข้อง เมื่อเปิดทิ้งไว้นาน ๆ ความร้อนจะขึ้นสูง และจะปิดตัวเองอัตโนมัติ ขณะนี้ได้ทำการแก้ไขโดยต่อระบบไฟฟ้าตรงกับอุปกรณ์ Surge Protect เท่านั้น

UniNet จัดฝึกอบรมเชิงปฏิบัติการ “วิธี การเพิ่มความปลอดภัยให้กับระบบโดเมนเนม” (Domain Name System Security Enhancement Workshop) ระหว่างวันที่29-31 กรกฎาคม 2552 ณ อาคารจามจุรี 9  ชัน้ 4 จุฬาลงกรณ์มหาวิทยาลัย รับจำนวนจำกัดเพียง 26  ท่านเท่านั้น ไม่มีค่าใช้จ่าย (มหาวิทยาลัย/สถาบันละ 1 ท่าน) โดยสามารถตอบรับเข้าร่วมสัมมนาได้ที่ e-mail address: staff@uni.net.th ภายในวันที่ 24 กรกฏาคม 2552 สามารถสอบถามข้อมูลเพิ่มเติมได้ที่คุณเกรียงศักดิ์ เหล็กดี โทรศัพท์ 02 3545678 ต่อ 5006

อ่านรายละเอียดเพิ่มเติมได้ที่นี่ (pdf file) [download id=”20″]

ช่วง 2 สัปดาห์ที่ผ่านมา ที่บริหารธุรกิจ (Node1 เชียงใหม่) มีการแจ้งจากสมาชิกผู้ใช้บริการว่า ใช้งานระบบเครือข่ายไม่ได้ หรือมีอาการติด ๆ ดับ ๆ อยู่ตลอดเวลา จากการตรวจสอบพบว่า ที่ Switching มี log บอกว่า

THU JUL 02 08:46:43 IP(15) Data: 1/0 duplicate IP address 10.1.4.x from port 1/16 eth addr 001c25:3e4c90

และมีพฤติกรรมสม่ำเสมอ คือจะเกิดขึ้นทุก ๆ 30 วินาที จึงได้ตรวจสอบย้อนกลับถึงการร้องขอไอพีแอดเดรสของเครื่องลูกข่าย พบว่า มีการสร้างไอพีแอดเดรส ที่เป็นลักษณะการเรียงตามลำดับ เช่น

10.1.4.100 จนถึง gateway จาก mac address เพียงชุดเดียว (และมีการเปลี่ยน mac เอง เมื่อมีการปิดกั้นจากส่วนกลาง) จึงเป็นสาเหตุการเกิด Duplicate gateway และเมื่อไอพีรันมาจนถึงไอพี gateway แล้ว จะทำให้ระบบดาวน์ชั่วขณะ ทำให้ลูกข่ายในซับเน็ตนี้ใช้งานไม่ได้ นอกจากนั้น เมื่อไอพีรันไปชนกับไอพีของเครื่องลูกข่ายด้วยกัน จะทำให้เครื่องนั้น ใช้งานไม่ได้ด้วย

จากการตรวจสอบอย่างละเอียด พบว่า ต้นเหตุเกิดจากเครื่องลูกข่ายเพียงเครื่องเดียว ที่มีไวรัสจำนวนมาก (หลากหลายสายพันธ์) จึงได้ปิดการเชื่อมต่อเครือข่ายของเครื่องลูกข่ายดังกล่าว จึงทำให้การใช้งานกลับมาเป็นปกติ

ขอเรียนเชิญเข้าร่วมงาน 3Com-No-Compromise Networking: One Company 3 Brands วันศุกร์ที่ 17 กรกฎาคม พ.ศ. 2552 (ห้องดอยสุเทพ ชั้น 1,โรงแรมแคนทารี่ ฮิลล์ เชียงใหม่) ตั้งแต่เวลา 08.30 – 12.00 น.
สอบถามข้อมูลเพิ่มเติม
ติดต่อ: คุณชนัญชิดา นันทกิจดำรง โทรศัพท์ 02-238-1881 Ext. 301 แฟกซ์ 02-238-3325 อีเมล์ chananchida@mice.co.th

หรือ ลงทะเบียนออนไลน์ ได้ที่นี่ http://www.educatecenter.net/3com/seminar/1company3brands/signup.php

วันเสาร์ที่ 27 มิถุนายน 2552 เวลา 13:30 น. ระบบเครือข่ายของ มทร.ล้านนา เขตพื้นที่ตากขัดข้อง สาเหตุเนื่องจากไฟเบอร์ออฟติคที่เชื่อมต่อจากชุมสาย TOT จังหวัดตาก ไปยัง มทร.ล้านนา เขตพื้นที่ตาก ขาด จึงทำให้ไม่สามารถใช้งานระบบอินเตอร์เน็ตได้เลย แต่ระบบคอนเฟอร์เร้นทร์ยังคงใช้งานได้ตามปกติ

จนถึงวันจันทร์ที่ 29 มิถุนายน 2552 เวลา 15.05 น. ทางฝ่ายเทคนิคของ TOT จึงได้ทำการแก้ไขปัญหาจนสามารถกลับมาใช้งานได้ตามปกติ

รวมระยะเวลา 2 วัน 1  ชั่วโมง 35 นาที

* หมายเหตุ ระยะเวลาของการแก้ไขปัญหา ที่นานผิดปกติเกิดจาก

– เกิดขึ้นในวันเสาร์-อาทิตย์  ซึ่งเขตพื้นที่ไม่มีการแจ้งการขัดข้องของวงจร (อาจจะไม่มีการปฏิบัติงานของเจ้าหน้าที่หรือเหตุสุดวิสัยอื่น ๆ)

– สำนักฯ รับทราบข้อมูลตอนเช้าวันจันทร์ และได้แจ้งทาง Call Center 1477  และการแก้ไขปัญหาเสร็จสิ้นตอนบ่าย

อ้างถึงจดหมายเวียน ของสำนักงานบริหารเทคโนโลยีสารสนเทศเพื่อพัฒนาการศึกษา (uninet) ดังนี้

เรียนสมาชิก UniNet (ด่วน)

เนื่องด้วยสำนักงานบริหารเทคโนโลยีสารสนเทศเพื่อพัฒนาการศึกษา มีความจำเป็นต้องดำเนินการบำรุงรักษา (M.A) ระบบเครื่องคอมพิวเตอร์แม่ข่าย (Server) ทั้งหมด ในช่วงเวลา วันเสารร์ที่ 20 มิ.ย. 2552  เวลา 20.00 น เป็นต้นไปจนกว่าจะเสร็จ ดังนั้นทางฝ่ายระบบเครือข่าย สำนักงานบริหารเทคโนโลยีสารสนเทศเพื่อพัฒนาการศึกษา จึงมีความจำเป็นแจ้งว่าในช่วงเวลาดังกล่าวสมาชิกอาจจะไม่ได้รับความสะดวกในใช้งานเคื่องคอมพิวเตอร์แม่ข่าย ThaiLIS, DNS เป็นต้น ทางฝ่ายระบบเครือข่าย สำนักงานฯ ต้องขออภัยมาใน ณ ที่นี้ด้วย หากมีข้อสงสัยประการใดโปรดติดต่อมีที่โทรศัพท์ 02-3545678 ต่อ 5003-5010 หรือ E-mail: noc@uni.net.th

จึงเรียนมาเพื่อทราบโดยทั่วกัน

เกรียงศักดิ์ เหล็กดี

วิศวกรระบบเครือข่าย ( noc UniNet)

########################################

คาดว่า จะกระทบกับการใช้งานฐานข้อมูลอ้างอิงงานวิจัยด้วยนะครับ เพราะข้อมูลจะถูกส่งไปยัง thailis ทั้หมด แต่การใช้งานระบบเครือข่าย ฯ ไม่น่าจะเกิดผลกระทบกับ มทร.ล้านนา มากนัก เพราะ เราไม่ได้อาศัย DNS ของทาง Uninet ครับ

ได้เวลาเขียนบทความเกี่ยวกับ Alcatel ซะที ซึ่งก่อนหน้านี้เกริ่นหลายรอบแล้วว่าจะเขียน แต่ก็ไปเขียนเกี่ยวกับ 3Com ซะหมด รอบนี้ขอเขียน เป็นจุดเริ่มต้นสำหรับบทความอื่น ๆ ที่จะตามมาก็แล้วกันครับ

NTP ย่อมาจาก Network Time Protocol คือโปรโตคอลสำหรับการปรับค่าเวลาของนาฬิกาในระบบคอมพิวเตอร์ โดย NTP ใช้พอร์ต 123 ของโปรโตคอล UDP เป็นพื้นฐาน ทำให้เวลาที่ใช้งานมีความเทียงตรง และเท่ากันทุก ๆ เครื่องที่ใช้แม่ข่ายเดียวกัน โดยความผิดพลาดจะน้อยมาก อยู่ในระดับ 1/100 วินาที เป็นอย่างต่ำ หากตั้งค่า NTP แล้ว จะสามารถสื่อสารกับเครื่องแม่ข่ายในการปรับเปลี่ยน ปี เดือน วัน วันที่ และเวลา ให้เป็นไปตามเครื่องแม่ข่าย (ยกเว้นระบบปฏิบัติการวินโดว์ทุกตระกูล ที่ปรับเปลี่ยนเวลาได้เท่านั้น และไม่เกิน 864000 วินาที หรือ 1 วัน ถ้าเกินนั้น จะทำให้ วันที่ผิดเพี้ยน) การตั้งค่าของ NTP ให้กับอุปกรณ์ระบบเครือข่าย จะช่วยให้การตรวจสอบข้อมูล ทำได้ง่ายขึ้น และไม่ต้องคอยตั้งค่าเวลาทุก ๆ เครื่อง ทุก ๆ ครั้ง ที่เวลาผิดเพี้ยนไป

สำหรับ Alcatel Switch 6850, 9700 นั้น สามารถดำเนินการได้ตามนี้

ตรวจสอบว่า วันและเวลาที่อุปกรณ์ มีค่าเท่าไหร่

Alcatel-9700-> show system
System:
Description:  6.3.1.1042.R01 Service Release, November 20, 2008.,
Object ID:    1.3.6.1.4.1.6486.800.1.1.2.1.8.1.1,
Up Time:      162 days 0 hours 56 minutes and 6 seconds,
Contact:      Alcatel-Lucent, http://alcatel-lucent.com/wps/portal/enterprise,
Name:         Alcatel-9700,
Location:     network,
Services:     72,
Date & Time:  THU JUN 18 2009  14:27:13 (LOCAL)

กำหนดเครื่องแม่ข่ายหรือ ntp server ดังนี้ ในที่นี้ ntp server คือไอพี 192.168.10.200

Alcatel-9700->ntp server 192.168.10.200

Alcatel-9700->ntp client enable

ทำการตรวจสอบว่า เวลาที่เราได้ชี้ไปหาเครื่องแม่ข่ายนั้นถูกต้องหรือไม่

Alcatel-9700-> show ntp server status
IP address         = 192.168.10.200,
Host mode          = client,
Peer mode          = server,
Prefer             = no,
Version            = 4,
Key                = 0,
Stratum            = 2,
Minpoll            = 6 (64 seconds),
Maxpoll            = 10 (1024 seconds),
Delay              = 0.016 seconds,
Offset             = 0.058 seconds,
Dispersion         = 1.952 seconds
Root distance      = 0.027,
Precision          = -20,
Reference IP       = 203.185.69.59,
Status             = configured : reachable : rejected,
Uptime count       = 13894301 seconds,
Reachability       = 7,
Unreachable count  = 0,
Stats reset count  = 13894136 seconds,
Packets sent       = 3,
Packets received   = 3,
Duplicate packets  = 0,
Bogus origin       = 0,
Bad authentication = 0,
Bad dispersion     = 0,
Last Event         = peer changed to reachable,

ตรวจสอบการเชื่อมต่อกับเครื่อง ntp server โดยใช้คำสั่งดังนี้

Alcatel-9700-> show ntp client server-list
IP Address        Ver   Key    St     Delay        Offset         Disp
—————–+—+——-+—-+———-+—————–+———-
*192.168.10.200        4       0    2      0.016             0.133      0.016

ตรวจสอบการอัพเดทเวลาว่า มีการอัพเดทล่าสุดเมื่อไหร่ และเวลาปัจจุบันตรงกับเครื่องแม่ข่ายหรือไม่ โดยใช้คำสั่ง

Alcatel-9700-> show ntp client
Current time:                   Thu, Jun 18 2009  8:38:44.619 (UTC), –> ตรงนี้เป็น UTC นะครับเวลาดูก็ +7 เอาเองนะครับ
Last NTP update:                Thu, Jun 18 2009  8:38:24.385 (UTC),
Server reference:               192.168.10.200,
Client mode:                    enabled,
Broadcast client mode:          disabled,
Broadcast delay (microseconds): 4000,
Server qualification:           synchronized

ลองตรวจวันและเวลาอีกครั้งด้วยคำสั่ง

Alcatel-9700-> show system
System:
Description:  6.3.1.1042.R01 Service Release, November 20, 2008.,
Object ID:    1.3.6.1.4.1.6486.800.1.1.2.1.8.1.1,
Up Time:      162 days 1 hours 4 minutes and 58 seconds,
Contact:      Alcatel-Lucent, http://alcatel-lucent.com/wps/portal/enterprise,
Name:         Node3Library,
Location:     Library,
Services:     72,
Date & Time:  THU JUN 18 2009  14:36:05 (LOCAL)

หรือตรวจสอบด้วยคำสั่ง

Node 3 Library-> system time
16:01:00 (LOCAL)

Node 3 Library-> system date
THU JUN 18 2009

เพียงเท่านี้ ก็เรียบร้อยครับ คราวนี้ ก็ไม่ต้องกังวลว่า เวลาจะคลาดเคลื่อนกันแล้ว

อย่าลืมบันทึกก่อนออกด้วยนะครับ

Alcatel-9700->write memory

Alcatel-9700->copy working certified

หรือถ้ามี cmm 2 ชุด ก็เพิ่ม flash-synchro เข้าไปด้วยครับ

Alcatel-9700->copy working certified flash-synchro

วันนี้น้องที่สำนักวิทยฯ ได้อัพเดทเฟิร์มแวร์ของ switching 3com 4500 ใหม่ อัพเสร็จแล้ว รีบูต มันบังคับให้เปลี่ยนพาสเวิร์ดใหม่ พอน้องใส่รหัสผ่านเดิมเข้าไป มันก็ไม่ยอม จำใจต้องใช้รหัสผ่านที่ยาวถึง 10 ตัว มันถึงจะยอม เรื่องนี้ผมไม่ค่อยได้แตะต้องมันเท่าไหร่นัก ก็มักจะลืม ๆ เหมือนกัน เพราะเซ็ตครั้งเดียวมันก็ใช้งานได้ตลอด เอาละ ในเมื่อมันเกิดปัญหา (ความจริงมันสร้างมาเพื่อความปลอดภัย) เราก็ต้องแก้ไข

login เข้าสู่ตัวอุปกรณ์ และเรียกใช้งาน system-view และผมได้กำหนดให้ ความยาวของรหัสผ่าน อย่างน้อย 6 ตัวอักษร (ในส่วนนี้มีความสำคัญครับ หากรันคำสั่งแบบผม จะส่งผลกับ user ทั้งหมด แต่ถ้าต้องการแก้ไขเฉพาะ user นั้น ๆ ต้องเข้าไปที่ user นั้นก่อนครับ โดยเรียกใช้คำสั่ง local-user xxxx แล้วถึงจะใช้คำสั่งนี้)

ในที่นี้ เป็น switching 3com รุ่น 4500 เฟิร์มแวร์ s3n03_03_02s56.app รุ่นอื่น ๆ หรือเฟิร์มแวร์อื่น อาจจะได้ผลลัพธ์แตกต่างออกไป

<4500>sys
System View: return to User View with Ctrl+Z.
[4500]]password-control length 6
[4500]local-user admin
[4500-luser-admin]

เมื่อเปลี่ยนความยาวของรหัสผ่านแล้ว ทีนี้เราจะมาเปลี่ยนรหัสผ่านกัน ซึ่ง จะมีอยู่ 2 รูปแบบคือ

cipher = การเข้ารหัสของรหัสผ่าน ซึ่งเราจะไม่รู้ว่ารหัสผ่านที่แท้จริงคืออะไร

simple = แสดงรหัสผ่านที่แท้จริง ใส่ยังไง ก็แสดงออกอย่างนั้น **ไม่แนะนำให้ใช้ครับ

[4500-luser-admin]password ?
cipher  Display password with cipher text
simple  Display password with plain text

เอาละ ได้เวลาเปลี่ยนรหัสผ่านกันแล้ว โดยจะเปลี่ยนรหัสผ่านของ admin ให้เป็น abcdef ก็ทำได้ตามคำสั่งด้านล่าง

[4500-luser-admin]password cipher abcdef
The system failed to assign password. It has been used previously.

เจอปัญหาอีกแล้วครับ ครั้งนี้ระบบแจ้งว่า รหัสผ่านที่เรากำลังป้อนนั้น ถูกใช้ไปก่อนหน้านี้แล้ว (ก็คือ ตอนที่มันบังคับให้เปลี่ยนตอนแรกไง)

เราสามารถดูได้ว่า มันมี policy อะไรบ้าง ดังนี้

[4500]password-control ?
aging                   Specify password aging time –> การนำพาสเวิร์ดเดิมกลับมาใช้
alert-before-expire     Specify the alert time before password expired –> การแจ้งเตือนก่อนรหัสผ่านหมดอายุ
authentication-timeout  Specify the authentication timeout –> เวลาที่ใช้ในการกรอกรหัสผ่าน
composition             Specify composition of password –> องค์ประกอบของรหัสผ่าน เช่น ตัวเลข ตัวอักษร อักขระ
history                 Specify maximum history record –> รหัสผ่านที่ผ่านมา (ที่เคยใช้มา)
length                  Specify minimum length of password –> ความยาวของรหัสผ่าน
login-attempt           Specify the local user’s login attempts –> จำนวนครั้งในการ login (ไม่ผ่านติดต่อกัน)
super                   The super user’s password controls –> รหัสผ่านของ super user

เมื่อรู้ว่า แต่ละอย่างคืออะไรแล้ว เราสามารถตรวจสอบว่า ค่าต่าง ๆ นั้น ถูกตั้งค่าเป็นอะไรบ้าง ดังนี้

[4500]display  password-control
Global password settings for all users:
Password aging:                 Enabled
Password length:                Enabled(6 Characters)
Password composition:           Enabled(1 type(s),  1 character(s) per type)
Password history:               Enabled(Max history record:4)
Password alert before expire:   7 days
Password authentication-timeout:60 seconds
Password attempt times:         3 times
Password attempt-failed action: Lock for 120 minutes

ในที่นี้ จะขอปิดระบบทั้งหมดเพื่อให้ใช้งานรหัสผ่านที่ง่ายต่อการจดจำของเรา (ไม่ควรตั้งง่ายเกินไป) ย้ำอีกทีว่าในส่วนนี้มีความสำคัญครับ หากรันคำสั่งแบบผม จะส่งผลกับ user ทั้งหมด แต่ถ้าต้องการแก้ไขเฉพาะ user นั้น ๆ ต้องเข้าไปที่ user นั้นก่อนครับ โดยเรียกใช้คำสั่ง local-user xxxx แล้วถึงจะใช้คำสั่งนี้

[4500]undo password-control aging enable
Password aging disabled for all users.
[4500]undo password-control composition enable
Password composition is disabled for all users.
[4500]undo password-control history enable
Password history disabled for all users.

ต่อไปก็ถึงเวลาที่จะเปลี่ยนรหัสผ่านกันแล้วครับ ผมเข้าไปที่ local-user admin เพื่อจะเปลี่ยนรหัสผ่านของ admin ดังนี้

[4500]local-user admin
[4500-luser-admin]password cipher abcdef
Updating user password, please wait……….

***เมื่อใช้ cipher รหัสผ่านที่เราพิมพ์ว่า  abcdef  อาจจะกลายเป็นแบบนี้  R9E#&=!H6Q_QxT77=^Q`MAF4<1!!

[4500-luser-admin]quit
[4500]save
[4500]quit
<4500>quit

ลองทดสอบเข้าระบบอีกครั้ง ก็จะสามารถใช้งานรหัสผ่านใหม่ได้แล้วครับ

รูปแบบการเชื่อมต่อระบบเครือข่ายคอมพิวเตอร์ขององค์กรต่าง ๆ มักจะมีรูปแบบเป็น tree คือ มีการเชื่อมต่อเป็นชั้น ๆ โดยชั้นสูงสุดที่เรียกว่า root นั้น จะเป็นตัวสำคัญ ที่จะทำหน้าที่เก็บเส้นทาง (Routing Table) ไปยังลูกข่ายทั้งหมด  ซึ่งบ่อยครั้งที่เกิดปัญหา loop ในเครือข่าย เพราะมีการเชื่อมต่อในรูปแบบวงกลม (โดยตั้งใจ และไม่ได้ตั้งใจ) จึงทำให้อุปกรณ์ระบบเครือข่ายต้องพิจารณาตัวเอง ว่าสมควรจะส่งข้อมูลให้กับใคร หรือใครที่จะทำหน้าที่เป็น root นั่นเอง

ความสำคัญอยู่ที่ค่าของ stp ที่เรียกว่า cost นั้น ปกติจะมีค่าเท่ากัน คือ 32768 ดังนั้น หากมีลูปเกิดขึ้นในระบบจริง อุปกรณ์จะไม่รู้ว่าใครที่สมควรจะเป็น root จึงทำให้มันต้องผลัดกันเป็น root ส่งผลกับระบบเครือข่ายโดยตรงคือ ไม่สามารถใช้งานได้ (เพราะ root เปลี่ยนไปเรื่อย ๆ )

ดังนั้น จึงควรมีการตั้งค่า cost ให้แตกต่างกันออกไป โดยกำหนดให้ root มีค่าน้อยสุด (ค่าน้อยสุดมีความสำคัญมากสุด) และเพิ่มค่าขึ้นเรื่อย ๆ ตามจำนวนของ hop ที่เชื่อมต่อ (ค่อยว่ากันอีกทีในวันอื่นครับ)

แต่ถ้าหากมีจำนวนของอุปกรณ์ไม่มากนักเช่น 3-5 ตัว และเราเห็นได้ชัดเจนว่ารูปแบบที่เชื่อมต่อ ไม่ได้ซับซ้อนอะไร ก็สามารถที่จะปิด stp ทิ้งได้เลย เพราะไม่ต้องเสียเวลามาแก้ไขค่า cost ต่าง ๆ (แต่เกิด loop ไม่รู้ด้วยนะ)

ที่อุปกรณ์ switching 3com 4500,5500,9700

หากเจอ log ที่มีข้อความแบบนี้ ที่เยอะมาก ๆ  จะสังเกตุเห็นว่า interface up/down สลับกันไปเรื่อย ๆ นั่นเพราะ มีการโหวตให้ตัวอื่นเป็น root จึงต้องตัดเส้นทางอื่นออกไป (อาการนี้อาจจะเจอในการ loop ด้วยครับ)

#Jun 14 09:41:23:116 2009 4500 L2INF/2/PORT LINK STATUS CHANGE:- 1 – Trap 1.3.6.1.6.3.1.1.5.3(linkDown): portIndex is 4227706, ifAdminStatus is 1, ifOperStatus is 2

%Jun 14 09:41:23:118 2009 4500 L2INF/5/PORT LINK STATUS CHANGE:- 1 – Ethernet1/0/11 is DOWN

ตรวจสอบการทำงานของ stp ด้วยคำสั่ง (ในที่นี้ดูพอร์ตที่ 11 แต่ถ้าต้องการดูทั้งหมดก็ใช้ display stp ก็ได้ครับ)

[3Com-sw]display stp interface Ethernet 1/0/11

—-[CIST][Port11(Ethernet1/0/11)][DISCARDING]—-
Port Protocol       :enabled
Port Role           :CIST Designated Port
Port Priority       :128
Port Cost(Dot1T)    :Config=auto / Active=200000
Desg. Bridge/Port   :32768.001e-c17d-7580 / 128.11
Port Edged          :Config=disabled / Active=disabled
Point-to-point      :Config=auto / Active=true
Transmit Limit      :10 packets/hello-time
Protection Type     :Loop
MSTP BPDU format    :Config=auto / Active=legacy
Port Config
Digest Snooping     :disabled
Num of Vlans Mapped :1
PortTimes           :Hello 2s MaxAge 20s FwDly 15s MsgAge 1s RemHop 20
BPDU Sent           :14
TCN: 0, Config: 0, RST: 0, MST: 14
BPDU Received       :0
TCN: 0, Config: 0, RST: 0, MST: 0

ทำการปิด stp ด้วยคำสั่ง (คำสั่งนี้ จะปิด stp ทุกพอร์ต ถ้าอยากปิดบางพอร์ต ต้องเข้าไปที่ interface นั้น ๆ ก่อน แล้วค่อยใช้ stp disable)

[3Com-sw]stp disable

%Jun 14 09:41:24:623 2009 4500 MSTP/3/STPSTOP:- 1 -STP is now disabled on the de
vice.

ตรวจสอบดูอีกครั้งด้วยคำสั่ง

[3Com-sw]display stp interface Ethernet 1/0/11
Protocol Status    :disabled
Protocol Std.      :IEEE 802.1s
Version            :3
CIST Bridge-Prio.  :32768
MAC address        :001e-c17d-7580
Max age(s)         :20
Forward delay(s)   :15
Hello time(s)      :2
Max hops           :20

[3Com-sw]save

เพียงเท่านี้ ก็จะไม่มีการโหวตการเป็น root อีกแล้วครับ

วันพุธที่ 3 มิถุนายน 2552 เวลา 09:15 น. ระบบเครือข่ายของเชียงรายขัดข้อง สาเหตุเบื้องต้นน่าจะเกิดจากการลูปของวงจร ซึ่งทำให้ทุกโหนด ยกเว้น Core Switch กับ โยธา ที่สามารถใช้งานได้ ซึ่งได้ทำการตรวจสอบและแก้ไขปัญหาเบื้องต้นจนสามารถกลับมาใช้งานได้ตามเดิม ในเวลา 10:50 น.

รวมระยะเวลา 1 ชั่วโมง 35 นาที

จนถึงเวลา 11.30 น. โหนดโยธา ไม่สามารถใช้งานได้ ขณะนี้กำลังตรวจสอบ และยังไม่ทราบสาเหตุที่เกิดขึ้น (อาจจะเกิดจาก Mini Gbic ขัดข้อง) ซึ่งจะส่งผลให้ สมาชิกที่เชื่อมต่อกับโหนดดังกล่าว ไม่สามารถใช้งานระบบเครือข่ายได้เลย

จนกระทั่งเวลา 19:15 น. จึงสามารถกลับมาใช้งานได้ตามปกติ

รวมระยะเวลา 7 ชั่วโมง 45 นาที