thảo luận Cộng đồng người dùng MikroTik Router

Cám ơn bác đã chia sẻ, đúng là nhà em có con robot khi cho nó làm việc chạy qua các điểm AP thì Mik lại có tình trạng hủy - cấp ip nhiều hơn các client khác.
Hiện tại hệ thống của em mặc định đã tắt tính năng "Client Device Isolation" và bật các chuẩn 802.11r/k/v.
Em đang nghi ngờ vấn đề do thiết bị, nhưng chưa khoanh vùng là còn Mik hay con aruba.

* Chắc đành chạy lại cấu hình mấy con để giảm tình trạng này, nhưng lại gặp tình trạng khác
em nhờ các bác giúp chút:
  • Em quay lại cấu hình: để Aruba cấp hết dhcp cho tất cả thiết bị không dây (tạo local vlan, network: 192.168.10.0/24);
  • Gán IP tĩnh cho các AP, Mik chỉ cấp dchp cho các AP (dải IP là 192.168.1.0/24); Ko tạo Vlan trên Mik.
  • Hiện em đang dùng Home Assistant (HASS), dùng AdGuard home nên toàn bộ DNS server chạy qua IP AdGuard home.
  • Tình trạng là một số thiết bị IoT ko thể liên lạc với HASS, (nếu setup qua local ip như máy in, cam yoosee), còn các thiết bị IoT setup qua cloud như Tuya, xiaomi thì vẫn có hiệu lực.
Các bác cho hỏi cách em setup trên dẫn đến tính trạng hai dải IP ko liên lạc được với nhau ko? và em nên setup rules ở đâu để cho hai dải đó liên lạc đc.
(Các bác thông cảm em toàn tự mày mò, em yêu khoa học nên câu từ kỹ thuật mạng ko chuẩn).
Ôi là trời.

Aruba thím để nó làm acess point thôi.

Thím cho nó cấp ip là nó ngáo ngơ mà, ae bàn cái này lâu lắm rồi .

Mik cấp dhcp, cấp vlan( nếu muốn phát ssid trên 1 vlan nào đó). Cấp ip cho clients.

Aruba chỉ nhận Ip để joint cluster. Rồi nó làm AP là nuột nà.
 
Ôi là trời.

Aruba thím để nó làm acess point thôi.

Thím cho nó cấp ip là nó ngáo ngơ mà, ae bàn cái này lâu lắm rồi .

Mik cấp dhcp, cấp vlan( nếu muốn phát ssid trên 1 vlan nào đó). Cấp ip cho clients.

Aruba chỉ nhận Ip để joint cluster. Rồi nó làm AP là nuột nà.
Vâng đúng, trc em làm một vài lần rồi đúng là nó kém ổn định. Hiện tại thì mạng của em đang để mik cấp dhcp, aruba làm ap. Ngoài cái log bị kiểu huỷ - cấp lại dhcp thì mạng chạy ngon lành, kết nối tốt, khổ nỗi cứ có thói quen thi thoảng ngó cái log của mik.
Chắc em sống chung với lũ, đặt chế độ khởi động lại mik sau 2-3 ngày. Nhìn cái log đỡ ngứa mắt.
 
Vâng đúng, trc em làm một vài lần rồi đúng là nó kém ổn định. Hiện tại thì mạng của em đang để mik cấp dhcp, aruba làm ap. Ngoài cái log bị kiểu huỷ - cấp lại dhcp thì mạng chạy ngon lành, kết nối tốt, khổ nỗi cứ có thói quen thi thoảng ngó cái log của mik.
Chắc em sống chung với lũ, đặt chế độ khởi động lại mik sau 2-3 ngày. Nhìn cái log đỡ ngứa mắt.
Này là đồng chí bị bệnh rồi, mặc kệ nó đi, chả ảnh hưởng gì đâu. :go:

Capture.PNG
 
Em đang nghi ngờ vấn đề do thiết bị, nhưng chưa khoanh vùng là còn Mik hay con aruba.

Vấn đề này thì trừ trường hợp bác để thời gian lease siêu ngắn (< 1 phút) còn lại 100% con MikroTik vô can bác ạ. DHCP server không có làm nhiệm vụ ngồi rình xem client có bị mất kết nối hay không (bác thử rút dây đột ngột của thiết bị dùng dây mà xem, trên bảng lease của DHCP server vẫn sẽ hiện bound cho đến khi thời gian lease kết thúc). Cái log message "dhcp deassigned ..." nó chỉ ghi khi hoặc là thời gian lease kết thúc mà trước đó server không nhận được message DHCPREQUEST nào của client để xin gia hạn (thường client sẽ xin gia hạn khi thời gian lease còn một nửa, sẽ thử nhiều lần cho đến khi hết lease, đầu tiên là unicast, vài lần không được thì sẽ gửi broadcast luôn), hoặc client gửi message DHCPRELEASE xin hủy lease. Chứ router không ngồi thử thỉnh thoảng ping hay ARP các thiết bị trong bảng lease bác nhé. Chỉ khi ban đầu server nhận được message DHCPDISCOVER với khi nhận được DHCPREQUEST thì server mới thử dùng ARP để kiểm tra không có thiết bị khác đang chiếm địa chỉ trước rồi thôi, và DHCP server của MikroTik cũng không làm điều này nếu có cái static lease ứng với cái client ID sẵn trong bảng lease rồi. DHCP server của MikroTik không hỗ trợ DHCPFORCERENEW nên cũng không phải là nó gửi message ép client phải renew địa chỉ ạ.

Thời gian lease cấu hình chỗ DHCP server của bác là bao nhiêu phút ạ. Bác có thể dò tìm trong log, xem giữa lúc xuất hiện "assigned" với một địa chỉ IP nào đó trong đống thiết bị bị ảnh hưởng kia, với lúc xuất hiện "deassigned" với đúng địa chỉ đó xem sao ạ? Nếu nó gần bằng thời gian lease trong cấu hình thì tức là DHCP server vì lý do nào đó không nhận được message gửi xin gia hạn lease (message mà client lẽ ra phải bắt đầu gửi khi thời gian lease chỉ còn ít hơn một nửa), dẫn đến việc lease hết hạn và bị bỏ khỏi trạng thái bound.

Còn nếu nó nhỏ hơn hẳn thời gian lease cấu hình thì sẽ là do client tự gửi message đòi release. Mà theo log của bác thì thường deassigned xong địa chỉ đó được assigned lại ngay trong cùng một phút, như vậy càng nhiều khả năng là client tự release rồi xin cấp lại hơn. Và nguyên nhân nhiều khả năng là thiết bị chuyển sang access point khác và không hỗ trợ các chuẩn fast roaming nhắc đến ở trên.

Thực ra để biết rõ xem có đúng là bị deassigned do chính client yêu cầu hay không bác chỉ việc tạm thời bật log dhcp lên thôi. Trong System -> Logging bác thêm 1 mục với topic "dhcp",

1715200732383.png


Khi này trong log sẽ có từng packet dhcp, cũng nhưng từng sự kiện, bao gồm cả các request (Msg-Type = request) yêu cầu gia hạn lease (server sẽ gửi packet ack đáp lại cũng như ghi thêm dòng lease bound, extending vào log trong trường hợp này), cũng nhưng các yêu cầu release từ phía client. Yêu cầu release sẽ có Msg-Type = release và sẽ có chuỗi log dạng như này:

1715201594188.png


Và nếu client xin cấp lại luôn thì sẽ có chuỗi message client discover, rồi server offer, client request, server ack.

Còn nếu client bị deassigned vì hết hạn lease mà không thấy gửi gia hạn (thí dụ do bị rút dây hay cắt WiFi đột ngột) thì trong log sẽ không có packet DHCP nào gửi đi gửi lại, mà chỉ có các dòng như này:

1715202476995.png


Nếu không giải quyết được vấn đề thiết bị không roam được giữa các AP mà không ngắt DHCP, thì bác có thể ẩn quách đống log "dhcp, info" trên router đi. Bằng cách chỗ System -> Logging, edit cái entry "info" sẵn có rồi thêm topic !dhcp vào:

1715202735404.png


Nếu có warning hay error với dhcp bác sẽ vẫn thấy trong log, chỉ không thấy các message info kiểu "assigned" với "deassigned" kia thôi.
 
Mình chả cheat choác gì nhưng cũng nâng con RB760igs lên bản mới nhất 7.14 gì đó. Kết quả là speed khi pppoe giờ chỉ max tầm 250Mbps. Nay chắc tìm cách hạ xuống v6 hoặc chuyển qua openwrt luôn

Nếu hEX S còn max 250Mbps thì có vẻ đúng giới hạn khi Fasttrack không còn hoạt động. Bác kiểm tra xem counter của mấy rule liên quan đến Fasttrack trong tường lửa nó còn đếm được gì không. Ngoài ra nếu vớ phải speedtest server IPv6 thì con của bác cũng chỉ được tầm đó là max vì IPv6 không có Fasttrack.
 
Last edited:
Con AC2 vs 750GR3 đều bị tình trạng chung : speed bị giảm kinh hồn, thậm chí 1 số web ko vô đc, đã thử vs cả 2 case cheat và ko cheat nhưng đều bị … mình có lội page thì thấy có 2,3 bác bị giống y vậy, ko biết là hiện tại có bác nào biết nguyên nhân vụ này ko nhỉ

Bác reset về cấu hình mặc định của MikroTik hay cấu hình trắng tinh ạ? Bác thử cấu hình mặc định của MikroTik xem sao ạ, với đừng restore backup từ bản cũ ạ, sẽ nhiều vấn đề lắm. Em có cả 2 con này và nếu cấu hình dựa trên cấu hình mặc định. ROS7 mới nhất, vẫn giữ được fasttrack thì IPv4 vẫn > 900Mbps được ạ. Tất nhiên nếu bác cheat PPPoE thì sẽ phải tắt fasttrack thì không còn được tốc độ đó nữa. hEX sẽ còn tầm 250-280Mbps còn hAP ac² tầm 500-600 ạ.
 
em là người dùng phổ thông, định mua con gr3 về rồi chuyển con của nhà mạng 4 chữ thành bridge, liệu nó có giảm ping và tốc độ ổn định hơn chút nào không các bác nhỉ

Tùy con nhà mạng của bác đang là con gì, nếu là mấy con đời mới có hỗ trợ WiFi ax rồi thì có khi con hEX còn không bằng bác ạ. Con hEX nó chỉ mang lại cho bác nhiều tính năng với khả năng cấu hình linh động, nhưng mà càng thử nhiều tính năng nó càng chậm bác ạ, vì nó cũng cao tuổi rồi. Chỉ giữ cấu hình đơn giản sát với default mới tải được đường truyền Gbps. Thậm chí nếu dùng con hEX và modem nhà mạng không rởm quá (dùng được đường Gbps như nhà mạng quảng cáo) thì em còn khuyên bác là nếu muốn dùng con hEX để có tính năng mở rộng thì bác để con modem nhà mạng quay PPPoE cơ, rồi tắt stateful firewall trên đó, đưa con Mik vào DMZ của modem nhà mạng, dùng DHCP client, chứ không bridge và quay PPPoE trên con Mik. Bởi vì như thế sẽ giảm tải cho con Mik (không còn mạnh mẽ gì nữa) vì nó không phải quay PPPoE. Còn con nhà mạng cũng không phải xử lý tường lửa phức tạp, chỉ phải NAT với PPPoE. Và để vào DMZ thì bị double NAT cũng không ảnh hưởng cho lắm (vẫn port forwarding được trên con Mik).

Còn nếu được thì bác sắm con ax² trở lên thì tốt ạ. Hoặc RB4011 trở lên nếu đồ cũ.
 
Tùy con nhà mạng của bác đang là con gì, nếu là mấy con đời mới có hỗ trợ WiFi ax rồi thì có khi con hEX còn không bằng bác ạ. Con hEX nó chỉ mang lại cho bác nhiều tính năng với khả năng cấu hình linh động, nhưng mà càng thử nhiều tính năng nó càng chậm bác ạ, vì nó cũng cao tuổi rồi. Chỉ giữ cấu hình đơn giản sát với default mới tải được đường truyền Gbps. Thậm chí nếu dùng con hEX và modem nhà mạng không rởm quá (dùng được đường Gbps như nhà mạng quảng cáo) thì em còn khuyên bác là nếu muốn dùng con hEX để có tính năng mở rộng thì bác để con modem nhà mạng quay PPPoE cơ, rồi tắt stateful firewall trên đó, đưa con Mik vào DMZ của modem nhà mạng, dùng DHCP client, chứ không bridge và quay PPPoE trên con Mik. Bởi vì như thế sẽ giảm tải cho con Mik (không còn mạnh mẽ gì nữa) vì nó không phải quay PPPoE. Còn con nhà mạng cũng không phải xử lý tường lửa phức tạp, chỉ phải NAT với PPPoE. Và để vào DMZ thì bị double NAT cũng không ảnh hưởng cho lắm (vẫn port forwarding được trên con Mik).

Còn nếu được thì bác sắm con ax² trở lên thì tốt ạ. Hoặc RB4011 trở lên nếu đồ cũ.
DHCP Client của mikrotik có cách nào set được IP tĩnh không nhỉ bác?
Em cần mở port tại modem nhà mạng cho IP cấp cho con Mik
 
DHCP Client của mikrotik có cách nào set được IP tĩnh không nhỉ bác?
Em cần mở port tại modem nhà mạng cho IP cấp cho con Mik

Nếu muốn dùng địa chỉ tĩnh cho interface WAN thì hoặc bác tắt DHCP client trên interface đó đi rồi vào IP -> Address add địa chỉ cố định trong dải LAN (kèm prefix length, thí dụ /24) của modem nhà mạng cho cái interface đó ạ. Sau đó trong bảng route thêm route cho destination 0.0.0.0/0, gateway là địa chỉ IP của modem.

Hoặc vẫn dùng DHCP client nhưng trên modem nhà mạng cho nó vào bảng static lease của modem đó ạ. Mấy con nhà mạng em dùng từ trước tới giờ vẫn luôn có cái bảng cho điền MAC address - địa chỉ IP bằng tay ở chỗ cấu hình LAN.
 
Vấn đề này thì trừ trường hợp bác để thời gian lease siêu ngắn (< 1 phút) còn lại 100% con MikroTik vô can bác ạ. DHCP server không có làm nhiệm vụ ngồi rình xem client có bị mất kết nối hay không (bác thử rút dây đột ngột của thiết bị dùng dây mà xem, trên bảng lease của DHCP server vẫn sẽ hiện bound cho đến khi thời gian lease kết thúc). Cái log message "dhcp deassigned ..." nó chỉ ghi khi hoặc là thời gian lease kết thúc mà trước đó server không nhận được message DHCPREQUEST nào của client để xin gia hạn (thường client sẽ xin gia hạn khi thời gian lease còn một nửa, sẽ thử nhiều lần cho đến khi hết lease, đầu tiên là unicast, vài lần không được thì sẽ gửi broadcast luôn), hoặc client gửi message DHCPRELEASE xin hủy lease. Chứ router không ngồi thử thỉnh thoảng ping hay ARP các thiết bị trong bảng lease bác nhé. Chỉ khi ban đầu server nhận được message DHCPDISCOVER với khi nhận được DHCPREQUEST thì server mới thử dùng ARP để kiểm tra không có thiết bị khác đang chiếm địa chỉ trước rồi thôi, và DHCP server của MikroTik cũng không làm điều này nếu có cái static lease ứng với cái client ID sẵn trong bảng lease rồi. DHCP server của MikroTik không hỗ trợ DHCPFORCERENEW nên cũng không phải là nó gửi message ép client phải renew địa chỉ ạ.

Thời gian lease cấu hình chỗ DHCP server của bác là bao nhiêu phút ạ. Bác có thể dò tìm trong log, xem giữa lúc xuất hiện "assigned" với một địa chỉ IP nào đó trong đống thiết bị bị ảnh hưởng kia, với lúc xuất hiện "deassigned" với đúng địa chỉ đó xem sao ạ? Nếu nó gần bằng thời gian lease trong cấu hình thì tức là DHCP server vì lý do nào đó không nhận được message gửi xin gia hạn lease (message mà client lẽ ra phải bắt đầu gửi khi thời gian lease chỉ còn ít hơn một nửa), dẫn đến việc lease hết hạn và bị bỏ khỏi trạng thái bound.

Còn nếu nó nhỏ hơn hẳn thời gian lease cấu hình thì sẽ là do client tự gửi message đòi release. Mà theo log của bác thì thường deassigned xong địa chỉ đó được assigned lại ngay trong cùng một phút, như vậy càng nhiều khả năng là client tự release rồi xin cấp lại hơn. Và nguyên nhân nhiều khả năng là thiết bị chuyển sang access point khác và không hỗ trợ các chuẩn fast roaming nhắc đến ở trên.

Thực ra để biết rõ xem có đúng là bị deassigned do chính client yêu cầu hay không bác chỉ việc tạm thời bật log dhcp lên thôi. Trong System -> Logging bác thêm 1 mục với topic "dhcp",

View attachment 2482962

Khi này trong log sẽ có từng packet dhcp, cũng nhưng từng sự kiện, bao gồm cả các request (Msg-Type = request) yêu cầu gia hạn lease (server sẽ gửi packet ack đáp lại cũng như ghi thêm dòng lease bound, extending vào log trong trường hợp này), cũng nhưng các yêu cầu release từ phía client. Yêu cầu release sẽ có Msg-Type = release và sẽ có chuỗi log dạng như này:

View attachment 2482966

Và nếu client xin cấp lại luôn thì sẽ có chuỗi message client discover, rồi server offer, client request, server ack.

Còn nếu client bị deassigned vì hết hạn lease mà không thấy gửi gia hạn (thí dụ do bị rút dây hay cắt WiFi đột ngột) thì trong log sẽ không có packet DHCP nào gửi đi gửi lại, mà chỉ có các dòng như này:

View attachment 2482971

Nếu không giải quyết được vấn đề thiết bị không roam được giữa các AP mà không ngắt DHCP, thì bác có thể ẩn quách đống log "dhcp, info" trên router đi. Bằng cách chỗ System -> Logging, edit cái entry "info" sẵn có rồi thêm topic !dhcp vào:

View attachment 2482972

Nếu có warning hay error với dhcp bác sẽ vẫn thấy trong log, chỉ không thấy các message info kiểu "assigned" với "deassigned" kia thôi.
Em cám ơn bác nhiều, em cũng đã thử đi thử lại thay đổi thời gian cấp dhcp (em toàn để 3-5 ngày thôi) nhưng tình trạng diễn ra liên tục trong vòng 1-2h, em cũng đã thử so sánh xem tình trạng diễn ra trên cùng một vài client (qua địa chỉ mac) thì toàn 1-2h đã xảy ra rồi.
Tối qua em đã làm lại theo cách này, có vẻ ổn các bác ạ:
  • Đúng như Bác nói: Mik ko suốt ngày ngồi nghe ngóng, rình mò tín hiệu xin cấp lại dhcp. Có khả năng các thiết bị IoT ko tương thích các chuẩn fast roaming với hệ thống mesh aruba.
  • Để kiểm tra nhận định này em đã mất công tối qua setup lại cấu hình mạng nhà em một chút như sau:
  • Vẫn nguyên cấu hình Router Mikrotik -> Switch Mik - Aruba (4 con 225), trong đó Router Mik cấp dhcp như bình thường cho cả hệ thống;
  • Trên Aruba em đã đặt SSID 2.4Ghz theo từng vùng (zone), cụ thể 4 phòng có 4 con thì em đặt 4 SSID zone1, zone2, zon3, zone4;
  • Em cài lại mạng cho các thiết bị thông minh theo nguyên tắc: thiết bị gần AP zone nào thì bắt nó phải ăn theo SSID zone đó. Giống như giờ mỗi con AP sẽ quản lý trực tiếp các thiết bị gần nó, ko có roaming gì cả.
  • Cách làm này hơi mất công chút để setup lại thiết bị về SSID mới, vả lại em cũng ko lo lắm tình trạng mất điện cục bộ từng AP để mà phải roaming sang AP khác.
- Kết quả sáng nay khả quan các bác ạ, với hơn 30 thiết bị IoT hiện gần như ko còn tình trạng hủy - cấp dhcp nữa, qua một đêm chỉ có 3 thiết bị có bị tình trạng này do em để trên trần nhà nên chưa kịp setup về AP zone riêng.
Có vẻ như tình trạng của em đã cải thiện được rất tốt file log của Mik chỉ còn gần 10 dòng tình trạng này thôi (trước thì có mà cả hơn 200 dòng qua 1 đêm, ko kể các dòng của các đại ca mạng đang rình mò VPN), em sẽ theo dõi cả ngày nay rồi báo lại các bác.
 
Tùy con nhà mạng của bác đang là con gì, nếu là mấy con đời mới có hỗ trợ WiFi ax rồi thì có khi con hEX còn không bằng bác ạ. Con hEX nó chỉ mang lại cho bác nhiều tính năng với khả năng cấu hình linh động, nhưng mà càng thử nhiều tính năng nó càng chậm bác ạ, vì nó cũng cao tuổi rồi. Chỉ giữ cấu hình đơn giản sát với default mới tải được đường truyền Gbps. Thậm chí nếu dùng con hEX và modem nhà mạng không rởm quá (dùng được đường Gbps như nhà mạng quảng cáo) thì em còn khuyên bác là nếu muốn dùng con hEX để có tính năng mở rộng thì bác để con modem nhà mạng quay PPPoE cơ, rồi tắt stateful firewall trên đó, đưa con Mik vào DMZ của modem nhà mạng, dùng DHCP client, chứ không bridge và quay PPPoE trên con Mik. Bởi vì như thế sẽ giảm tải cho con Mik (không còn mạnh mẽ gì nữa) vì nó không phải quay PPPoE. Còn con nhà mạng cũng không phải xử lý tường lửa phức tạp, chỉ phải NAT với PPPoE. Và để vào DMZ thì bị double NAT cũng không ảnh hưởng cho lắm (vẫn port forwarding được trên con Mik).

Còn nếu được thì bác sắm con ax² trở lên thì tốt ạ. Hoặc RB4011 trở lên nếu đồ cũ.
em cũng đang ngắm thử con ax² nhưng không dùng wifi của nó nên sợ phí tính năng wifi của nó, em định wifi mesh riêng bằng đám xiaomi.
à, em thấy có nhiều bác dùng PC Route với cấu hình khá cao , giá cả phải chăng, có nên thử không bác nhỉ
 
em cũng đang ngắm thử con ax² nhưng không dùng wifi của nó nên sợ phí tính năng wifi của nó, em định wifi mesh riêng bằng đám xiaomi.
à, em thấy có nhiều bác dùng PC Route với cấu hình khá cao , giá cả phải chăng, có nên thử không bác nhỉ

Dùng PC (đủ các loại kích thước và cấu hình) rồi chạy RouterOS hoặc trực tiếp trên phần cứng, hoặc ảo hóa, là cách có được router performance ngon lành nhất so với số tiền phải bỏ ra ạ. Như bác nói, nhiều bác trên này áp dụng và hài lòng. MikroTik cũng rất dễ dãi với việc kiểm tra licence nên vẫn thoải mái nâng cấp OS được lên các phiên bản mới nhất, dù bác dùng các biện pháp không chính thức để không phải bỏ tiền ra mua bản quyền :D.

Cái không có so với việc dùng router hãng sản xuất chỉ là không có tính năng cloud (DDNS với subdomain của MikroTik) với Back-to-Home. Ngoài ra cũng không có cấu hình mặc định sẵn như các dòng RB phổ thông (cái này thì dòng CCR cũng không có) nên bác chú ý thiết lập router cho an toàn (cấu hình ban đầu rỗng nên không bật gì bảo vệ).

Việc dùng licence không chính thức cũng có thể ảnh hưởng lúc bác tìm được bug cần report cho MikroTik, vì lúc nào họ cũng đòi upload cái file supout.rif tạo ra từ router, và file này chứa hết thông tin licence nữa ạ. Nên kể ra cũng hơi ái ngại lúc gửi cho họ xong và tiếp tục conversation trong cái support ticket :D.
 
Winbox -> ip -> dhcp server -> tab leased

Ngoài ra nếu có các thiết bị không dùng DHCP nhưng vẫn có liên lạc với router thì chúng cũng sẽ xuất hiện trong bảng IP -> ARP nếu gần đây có nói chuyện với router (thí dụ nếu chúng vào internet).

Nếu trong LAN có dùng IPv6 thì có danh sách các thiết bị dùng IPv6 gần đây trong bảng IPv6 -> Neighbors (liệt kê cả các địa chỉ temporary của các thiết bi đã hết hạn, deprecated).

Bảng Bridge -> Hosts cũng liệt kê đủ các thiết bị nhưng không có địa chỉ IP.

Ngoài ra, nếu thêm mục này vào tính năng IP -> Kid Control:

Code:
/ip kid-control add name=Monitor \
    mon=0s-1d tue=0s-1d wed=0s-1d thu=0s-1d fri=0s-1d sat=0s-1d sun=0s-1d

Thì ở tab Devices bên cạnh cũng liệt kêt tất cả các thiết bị đang sử dụng router để route (thí để vào internet). Tiện ở chỗ là nó group luôn tất cả các địa chỉ IPv4 và IPv6 của thiết bị (cả địa chỉ IPv6 đã deprecated), và đếm traffic. Tuy nhiên hơi tốn tài nguyên một chút để làm nhiệm vụ accounting này nên nêu không cần xem nữa thì disable cái mục ở bảng Kids kia đi.
 
Em cám ơn bác nhiều, em cũng đã thử đi thử lại thay đổi thời gian cấp dhcp (em toàn để 3-5 ngày thôi) nhưng tình trạng diễn ra liên tục trong vòng 1-2h, em cũng đã thử so sánh xem tình trạng diễn ra trên cùng một vài client (qua địa chỉ mac) thì toàn 1-2h đã xảy ra rồi.
Tối qua em đã làm lại theo cách này, có vẻ ổn các bác ạ:
  • Đúng như Bác nói: Mik ko suốt ngày ngồi nghe ngóng, rình mò tín hiệu xin cấp lại dhcp. Có khả năng các thiết bị IoT ko tương thích các chuẩn fast roaming với hệ thống mesh aruba.
  • Để kiểm tra nhận định này em đã mất công tối qua setup lại cấu hình mạng nhà em một chút như sau:
  • Vẫn nguyên cấu hình Router Mikrotik -> Switch Mik - Aruba (4 con 225), trong đó Router Mik cấp dhcp như bình thường cho cả hệ thống;
  • Trên Aruba em đã đặt SSID 2.4Ghz theo từng vùng (zone), cụ thể 4 phòng có 4 con thì em đặt 4 SSID zone1, zone2, zon3, zone4;
  • Em cài lại mạng cho các thiết bị thông minh theo nguyên tắc: thiết bị gần AP zone nào thì bắt nó phải ăn theo SSID zone đó. Giống như giờ mỗi con AP sẽ quản lý trực tiếp các thiết bị gần nó, ko có roaming gì cả.
  • Cách làm này hơi mất công chút để setup lại thiết bị về SSID mới, vả lại em cũng ko lo lắm tình trạng mất điện cục bộ từng AP để mà phải roaming sang AP khác.
- Kết quả sáng nay khả quan các bác ạ, với hơn 30 thiết bị IoT hiện gần như ko còn tình trạng hủy - cấp dhcp nữa, qua một đêm chỉ có 3 thiết bị có bị tình trạng này do em để trên trần nhà nên chưa kịp setup về AP zone riêng.
Có vẻ như tình trạng của em đã cải thiện được rất tốt file log của Mik chỉ còn gần 10 dòng tình trạng này thôi (trước thì có mà cả hơn 200 dòng qua 1 đêm, ko kể các dòng của các đại ca mạng đang rình mò VPN), em sẽ theo dõi cả ngày nay rồi báo lại các bác.
Em xin báo lại các bác tình trạng hệ thống nhà em đến lúc ko còn bị huỷ - cấp lại dhcp cho các thiết bị IoT, ngoại trừ con robot lai nhà lúc làm việc chạy qua các phòng là bị thôi điều này không ngoài dự liệu của các bác vì mỗi lần qua điểm ap nó lại phải khai báo. Em thấy như vậy là rất ổn rồi.
Mạng và liên lạc giữa các client với Home assistant cũng ổn, ko tình trạng dớt mạng nhất thời.
Qua đây tạm thời xác định nguyên nhân hệ thống nhà em bao lâu này là các IoT ko tương thích với hệ thống mesh của aruba, setup để ap quản lý riêng từng khu vực và các IoT là giải pháp khả thi đến lúc này.
Cám ơn các bác đã hỗ trợ, tham gia thảo luận vấn đề của em.
 
Back
Top