ipv6hackのブログ一覧

pi400だったのでキーボードが最初からついているので簡単
F8を押すとスクショになり、画面左上にその時のスクショが数秒出る

保存場所は
/opt/retropie/configs/all/retroarch/screenshots/

WinSCP等でSFTPでアクセス
ID　pi
PASS raspberry

でアクセスして持ってこれます

個人的備忘録かねてバグ報告です
Amazon　Fire7タブレット　第7世代ですが、
IPv6がマルチホーム環境のWIFIでIPv4へもインターネットアクセス可能な状態でもAmazon Prime VideoやなぜかAbema　TVが視聴できませんでした
ただし、第9世代　Fire7タブレットは視聴可能でした
IPv6マルチホーム環境を一つなくしてIPv6一つだけとIPv4だけの状態にしてから端末を再起動するとAmazon Prime VideoやAbema　TVは視聴可能になりました

Amazonにこの件をフィードバックするために連絡しましたが、回答が
「IPv6がある環境ではいかなる世代のFireタブレットでも動作が不安定になります。FireタブレットはIPv4のみの環境前提でしか動作を保証していません」
とのことでした・・・・・・・( ﾟДﾟ)
コールセンターの人も、いまどきIPv6インターネットがあるのは我々も技術組織に報告しているが、決まってこのような回答しか返ってこないためこうとしか言えませんと、現場レベルも困っているようでした

https://minkara.carview.co.jp/userid/354569/blog/48912964/


で記載したトラブル、本日HGWを交換してもらったが事象は即座に再現
（そりゃそうだろうとおもってたよ）

一応、資料作ってパケットキャプチャーのスクショも貼り付けて
不具合改修してもらえるようにエスカレーションを現地にきたかたに
お願いをしたが、結果の返答はもらえないといことでどうなることやら

最近、ゼロトラストのソリューションとしてZscalerがよくつかわれるが、
アクセスに利用されるIPアドレスは回線のIPアドレスではなくクラウド上の
ZscalerのPROXY経由のIPアドレスになるためルータのフィルターには
注意が必要である
利用者が増えたのかIPアドレスの範囲が大幅に増えていた

Zscalerで2026/2/12で利用されるIPアドレスの範囲は下記である
58.220.95.0/24
64.215.22.0/24
87.58.64.0/18
94.188.131.0/25
94.188.139.64/26
94.188.248.64/26
98.98.26.0/24
98.98.27.0/24
98.98.28.0/24
101.2.192.0/18
104.129.192.0/20
112.137.170.0/24
124.248.141.0/24
128.177.125.0/24
136.226.0.0/16
137.83.128.0/18
140.210.152.0/23
147.161.128.0/17
154.113.23.0/24
165.225.0.0/17
165.225.192.0/18
167.103.0.0/16
170.85.0.0/16
185.46.212.0/22
194.9.96.0/20
194.9.112.0/22
194.9.116.0/24
196.23.154.64/27
196.23.154.96/27
197.98.201.0/24
197.156.241.224/27
198.14.64.0/18
199.168.148.0/23
209.55.128.0/18
209.55.192.0/19
211.144.19.0/24
220.243.154.0/23
221.122.91.0/24
2605:4300::/32
2a03:eec0::/32
2400:7aa0::/32
205.220.0.0/17
167.106.0.0/16
103.215.126.0/24
159.254.0.0/16
98.98.186.0/24
98.98.187.0/24
98.98.169.0/24
175.107.128.0/18
137.31.0.0/16

ご参考に・・・・

現在HGWの単体故障含めて切り分け中のメモです

【原因】
不具合か実装上の制限なのか単体故障かはわからないが
HGWのLAN側のLANポート間では、マルチキャストのレートリミットが
存在するような動きをしているのが原因

【経緯】
NTＴの１０Ｇ　クロス回線のＨＧＷ　XG-100NEのLAN側に
ルータを2台設置し、VRRPを組むとなぜかVRRPのパケットがバックアップ側が
受信できない事象が発生

　　　|
　　　|
　　HGW
　　|　　|
　　R1　R2

というHGW直結構成の場合でR1はRTX1300
R2はRTX1200ですが、なぜかVRRPが最初はいいが、マスターのR1をリブート等して
バックアップ側R2に切り替わった後にR1が復帰後、切戻るはずなのに
R2側のVRRP状態がMASTERのままである
パケットキャプチャーでHGWのLAN側ポートのマルチキャストの状態をみると
R1側が再起動完了してもR1側のVRRPパケットが流れてこない

さらに
　　　|
　　　|
　　HGW
　　|　|
　　|　R2
　SW
　　|
　　R1

としてSWとHGWのLANポートにそれぞれキャプチャーを設置して
マルチキャストの状態を確認
するとR1リブートするとR1のVRRPパケットが停止し
R2のVRRPパケットが送信される
その後、R1が再起動完了するとSWの部分のキャプチャーには
R1のVRRPが流れてきているのがキャプチャーできていたが、
（この時、R2のVRRPパケットも来ていた）
なぜかHGWのキャプチャーにはR2のVRRPしか着ていない
そのためR2にR1のVRRPパケットが到達していないから
切戻らないという動きになっていることが判明
ここでR2のVRRPの送出を止めるとHGWにキャプチャーにR1のVRRPがでてくる動きが見えた
いろいろ試すと一定のレート以上のマルチキャストの入力がHGWのLAN側にあると別ポートへ転送しない（もしくは入力時に破棄している）ようである

YAMAHAのVRRPのインターバルタイマーはデフォルト１秒であるが、一定以上間隔を開けるとVRRPが正常動作するようになった
ただし、例えばR1が再起動して復帰してVRRPパケット送出のタイミングとR2のインターバルとタイミングが合ってしまうと永久に２パケットが短い間隔でバースト入力されてとなり、これもVRRP切戻らない状況になってしまった
ただ、R1、R2ともに同じインターバル感覚に設定しないといけないが、内部時計の精度のためか微妙に一定間隔といってもずれてくることも分かった
そのため、試行錯誤した結果
インターバル　50秒　　ダウンインターバル　60秒
だと切り替え試験を１０回やって１０回切戻った
ちなみに例えば
インターバル　15秒　　ダウンインターバル　20秒
とした場合、
１０回中２回成功、８回は５分以上切戻らなかった

余談ではあるが
　　　|
　　　|
　　HGW
　　|
　　|
　SW
　|　|
R1　R2
この構成であればHGWの変なレートリミットの影響が受けないので
インターバル　1秒　　ダウンインターバル　3秒
でも１００％動作する
が、SWの電気代がもったいないので正直避けたい