| CATV 研究所 navi_bar トップ | ページ |
総合情報 | 全国版／エリア版 | エリア版 | エリア版・過去ログ(書き込み不可) | 運営室 | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
総合 掲示板 |
旧総合板 過去ログ |
J:COM [コ][板] |
その他 [コ][板] |
iTSCOM [コ][板] |
Mediatti [コ][板] |
M-NET [コ][板] |
CNO [コ][板] |
MCat [コ][板] |
連絡 掲示板 |
各掲示板 の趣旨 |
||
| 現在位置 | ↑ | |||||||||||
| 一括表示 |
|---|
断続的にネットの接続が途切れるようになり、 |
こんにちは。 ＤＨＣＰ環境なのに固定ＩＰを設定するという方、今でも時た まいらっしゃるのですね。意図的にやるのか、それとも間違って やるのか、良くわからないのですが。これは企業内のＯＡ−ＬＡ Ｎ環境でも、時たま騒ぎになると思います。 こんな対応で正しいのか確証は無いのですが、固定ＩＰを設定 している方を特定できたならば、該当モデムを強制停止にしてそ の方からの申告を待つ方法が有ると思うのですが。しかし固定Ｉ Ｐを設定している方も、自分では「間違っている」という認識が 無いので事業者は何かクレームを言われる筈なので、難しい所な のではないでしょうか？ 別の対策方法は、ルーターのＷＡＮ側ポートやＰＣのＭＡＣア ドレスを事業者が加入者から申告してもらい、フィルタリングを かける方法も有ると思うのですが、加入者が機器を交換した場合 には新たにＭＡＣアドレスを申告し、事業者から承認してもらう まで使えないという欠点も有ると思います。どんな対策方法が良 いのでしょうか。ＰＰＰｏＥとは異なり、ＤＨＣＰ環境では何ら かの認証をかけるには、こんな方法しか無いように思えます。 もうＩＰの知識という物は、動作原理がわからない方にとりま しては大変厄介な物ですね。これだけインターネットが普及した 時代でもまだ駄目なのだという事を、あらためて認識しました。 余談なのですが、ネット関係の話題は、最近この掲示板では珍 しいと思います。以前は、ネットの話題の方が主流でしたが。Ｃ ＡＴＶインターネットの初期段階の１０年ぐらい前の話です。 竹内＠ふじみ野.東上 |
ネットゲームかサーバーを立ち上げていて、固定IPにしたい人が、たまたまDHCPで割り振られたIPを、固定IPにして使っていたんじゃないですかね？ |
こんにちは。 カスタマーセンター対応、顧客満足といった事に、どの程度の お金や手間をかけているのか？という課題が有ると思っています。 それも、ハイエンドからローエンドのニーズまで、バランス良く 対応できているのか、私にはわからないのです。 現在のＪ：ＣＯＭの実力は、ハイエンドのマニアックな層、先 進的な層、ＩＴに詳しい層にはうまく対応できておらず、問題が 有ると私は考えています。市場というのはピラミッド構造を形成 していると思うのですが、どこをターゲットにしているのか、Ｊ ：ＣＯＭのマーケティングの考え方は良くわからないのです。 イノベーター理論 http://www.jmrlsi.co.jp/mdb/yougo/my02/my0219.html ＣＡＴＶの普及率というのは、「アーリーマジョリティ」を対 象と出来る所まで進んでいると思うのですが（それが、Ｊ：ＣＯ ＭがＴＶ−ＣＦを出すようになった理由のようにも思えますが）、 ハイエンドに近い１６％の層を大切にしてもらっているのか、私 には良くわかりませんでした。個人的な感想では、その１６％は まともに相手をしてもらえていないように見えています。クレー マーかウルサイ顧客と見なされて、邪魔者扱いされているような 印象を受ける訳です。 イノベーター理論の中では、上位１６％の人を敵にまわすと駄 目だという話が示されていると思うのですが。 竹内＠ふじみ野.東上 |
は？って感じですね。 |
こんにちは。 私の投稿内容がいかなる解釈を受けようとも、さして気にする 物ではないのですが、それにしてもＪ：ＣＯＭからの回答がこの 掲示板に対して付く訳ではありませんから、結局はノーソリュー ションだと思います。 やはり「うるさい」層に対してはＪ：ＣＯＭは放置、という事 なのでしょうかね。 竹内＠ふじみ野.東上 |
> ネットゲームかサーバーを立ち上げていて、固定IPにしたい人が、たまたまDHCPで割り振られたIPを、固定IPにして使っていたんじゃないですかね？ |
こんにちは。 > J:COM in my roomで契約していなければ、恐らくそう > していると思います。 > いずれにせよ大家さんに迷惑が掛からない様にしたい > ので・・・ この場合ですが、間に「不動産屋」という利害関係者も存在 するかも知れませんね。不動産屋の役割も確認した方が良いと 思われます。大家さんが、不動産屋に全て対応を任せている可 能性も有りますし（管理委託契約）。遠隔地居住の大家さんで すと、特にそうですね。 光をどうしてもという話になれば、バルク契約をしてあるＣ ＡＴＶを無視しての個別配線の許可が出るのか、エアコン穴の 使用、若しくは壁に穴を空けるといった事はどうなのか、確認 する必要が有ると思います。配線した場合には、退去する場合 の原状復旧工事とか、そのような事も検討対象になるだろうと 思います。 持ち家（特に戸建て）ならばどのようにでも配線できるので すが（自分が納得すれば、穴でも露出配線でも自由自在）、賃 貸住宅ではなかなか自由になりませんよね。しばしば「事業者 を乗り換えれば？」というご意見が出るのですが、このような 配線問題とか関係者との面倒な説得交渉まで考慮したご意見な のか、私には良くわからないです。一般社会の辛い点を知って しまうと、そのように見えるのです。 竹内＠ふじみ野.東上 |
対応の是非は分かりかねますが、厳しいですね。 |
こんにちは。 > Bフレッツ これはＰＰＰｏＥ環境なので、比較する相手としては適切では ないと思います。ＤＨＣＰ環境同士で対応方法を比較しないとい けないと思うのですが。 RFC2516「A Method for Transmitting PPP Over Ethernet （PPPoE）」を参照。 ＤＨＣＰですと、企業のＯＡ−ＬＡＮとかではしばしば見られ る方法だと思います。 竹内＠ふじみ野.東上 |
早速のコメント有難うございます。 |
確かにサポートとしていかがなものかという対応ですね。 |
こんにちは。 Ｊ：ＣＯＭ環境において手動での固定ＩＰ設定が厳禁なので あれば、それはＪ：ＣＯＭ側でもっとはっきりとアナウンスし て、技術的対応もやった方が良いかも知れないです。 ＤＨＣＰサーバーの実装は色々な物が有ると思われるのです が、たとえばＤＨＣＰサーバーが新しいＩＰを割り当てる前に それが既に使用されていないか何らかの方法で確認し（ＤＨＣ Ｐのリーステーブル確認はもとより、実際にＰＩＮＧをかけて みて反応が無い事を確認してみるとか）問題が無い場合に初め て割り当てるといった方法を考えうると思います。 しかしながら、サーバー側がそのようなチェックを行う場合、 固定ＩＰで不適切な設定をされているマシンが、その瞬間に電 源が入っていて稼動しているという保障はありませんし、そう なりますと手作業でおかしなクライアントＰＣを検知して対応 する必要が有ると思うのです。そうなると、監視システムの充 実であるとか、そういった事に対応する監視センター要員、あ るいはカスタマーセンター要員の増強といった話であろうと思 います。そのような人は定型的な話しか出来ない素人では役に は立たないのですから、エンジニアとして徹底的に鍛えられた 人、しかも顧客対応についても経験を重ねた人が対応する必要 が有るだろうと思います。 また、おかしな設定のクライアントＰＣ（ケーブルモデム） は、事業者側の操作で停止できるのだと、契約約款で定める必 要も有るでしょうね。いきなりケーブルモデムを強制停止する のでは問題が有るようならば、「検疫ＶＬＡＮ」のような物を 設定して、おかしなＰＣはそちらに接続してしまい、Ｊ：ＣＯ Ｍからの警告画面しか出ないようにするとか、そんな事も考え うると思うのですが。 竹内＠ふじみ野.東上 |
> > Bフレッツ |
こんにちは。 元投稿の内容ですと、具体的な絶対金額としてどの程度まで ＯＫなのか、わかりませんでした。そのために、まず技術的な 話から入りました。 フレッツ光ネクストとかフレッツ光ですと月額料金は相当な 金額になると思うのですが、それでもＯＫなのかは不明でした。 あとＶＤＳＬ方式とかですと、その部分での速度低下とか不 安定さに悩まされる可能性も有りますし、戸建か集合住宅かの 区別もわかりませんでした。 それからこのツリーでもＪ：ＣＯＭのＣＳ（顧客満足度）の 話が出ていますから、その問題を何度も起こすＪ：ＣＯＭの対 応には問題ありと指摘をしておきたいと思います。ＮＴＴのよ うな明白な競争相手が有るのに、その状態ではまずいと思う訳 です。 竹内＠ふじみ野.東上 |
私はサポートセンタではないので、答えのない問題に対しては |
発生する可能性を認めておきながら防止策や |
こんにちは。 > ・５戸のアパートなので光は不利 > ・大家さんが引込み、割引も有るのでコスト的には有利 > がJ:COMに決めたポイントでした。 お住まいの場所が、J:COM in My Room対応物件なのでしょう か？ それであれば、料金面では特別待遇になっていますね。 光を自分で契約して変更すると相当な料金アップになる筈なの で、「家計」という点では重要検討項目になると思います。 > あと、私は8Mの契約ですが今は受け付けていない様です。 > いつの間にかバンドが広がった様ですが、 > これは他のユーザーの方へは周知済みでしょうか？ これは、東上局の場合には連絡がありました。なお重要な連 絡はＪ：ＣＯＭの「連絡専用メールアドレス」に到着する場合 が有るのですが、それの閲覧はされているでしょうか？（メー ルソフトには、通常利用するメールアドレスのみならず、連絡 専用メールアドレスも設定しておく等の対応。）放送サービス の場合には、デジタル放送の「放送メール」も確認しないとい けないです。メンテナンスのお知らせなどが届く場合が有りま す。（知らないと録画を失敗したりします。） 現在は８Ｍサービスは廃止で、１２Ｍになっているように思 います。 カスタマーセンターでは、「マニュアルに書いてある事」の 回答しか認められていないのでしょうね。もっと高度な事は、 長年の経験を重ねた上席（管理職）の方が対応する事なのだろ うと思います。設備投資とか、技術開発、サポート体制の変更、 営業対応など、経営面の判断まで出来る事が必要なのですから。 下らない事かも知れないのですが、社内で飲み会などは定期的 に開催されているのであろうかとか、社内の風通しといった社 風とか、そんな事まで影響してしまうと私は思っています。サ ラリーマン稼業の経験の中では、そういった事は個別の会社に よってかなり違うと感じています。Ｊ：ＣＯＭの場合は、どう でしょうか。 竹内＠ふじみ野.東上 |
こんにちわ。 |
> モデムの電源は日頃どうしているのか(常時電源は付けたまま？) |
こんにちは。 > > アパートへのケーブルの引き込みは戸別なのか > > 同軸ですので恐らく個別です。HFC（でしたっけ？）の > 筈なので、どこか電柱の上で何本かが一本の光に集約 > されているのかと・・・ これなのですが、おそらく意味が違っていて幹線ではなくて 宅内配線に関する議論だと思うのです。 J:COM in My Room（バルク契約）との事なので、おそらくで すがＪ：ＣＯＭが費用を出して配線工事を行い、双方向通信の 行えるＣＡＴＶ専用配線が賃貸の全部屋に分配されて導入され ている筈ですね。基本的には、賃貸の全ての部屋で同じ条件だ と思います。おそらく、目視で追いかける事が可能な構造だと 思います。 バルク契約では、基本は戸別配線という事は「無い」と思わ れます。電柱からの同軸の引込み線は１本だけで、建物の中で 分配していると思われます。 竹内＠ふじみ野.東上 |
こんにちわ |
こんにちは。 > マンションによっては、大家さんの所にルーターを置いて〜と言う > 場合も有るので確認した次第です。 バルク契約の場合なのですが、この構成方法を採用している 事例をまだ見た経験が無いです。仮にこの構成方法を採用し、 かつルーターのような共用機器を大家さんの専用部分に設置し た場合には、大家さんが旅行などで不在、深夜などの場合に大 家さんの自宅に立ち入って修理する事が出来ないので、この構 成を採用している可能性は少ないのでは？と思いました。 ブースターのような共用機器やＡＣ電源の共用ブレーカーを 大家さんの自宅に設置してある場合にも、同じような問題点が 有ると思います。ですから「共用機器の設置場所」というのは、 結構シビアな問題だと思います。 おそらくですが、建物の構造はksdu様が把握されているだろ うと思うのですが、如何でしょうか。 ＤＨＣＰの問題とは直接関係無いのですが、こんな所が気に なりました。 竹内＠ふじみ野.東上 |
> おそらくですが、建物の構造はksdu様が把握されているだろ |
こんにちは。 > 同軸ケーブルをたどると、外壁の高い位置に大き目の > 樹脂ＢＯＸが有り、そこへ他の部屋からもケーブルが > 集まっている様です。電源も引き込まれていますから > 恐らくブースター等はこの中に入っているのでしょう > か。 これはバルク契約では、しばしば採用されている工事方法だ と思います。その箱はＰ−ＢＯＸ、またはプラボックスだと思 うのですが、おそらくその中にはＣＡＴＶ用の双方向ブースタ ー、分配器、渡りケーブル、共用電源から配線した電源コンセ ント等が入っていると思います。大家さんや住人が不在でも、 メンテナンス可能な位置についている筈ですね。 同軸ケーブルなので、Ｐ−ＢＯＸの中に「ルーター」が入っ ているという可能性は排除されたと思います。 竹内＠ふじみ野.東上 |
再度、こんにちは。 > 接続障害と言う点では私がJcom時代に苦労したケースに症状は似て > います。 ただ私の場合はIPの貸出不能ではなくて、メタルケーブ > ルが季節の温度差で抵抗値が変わり、幹線上の機器で吸収しきれな > くなった事によるリンクの確立不能でした。時間帯とかでモデムの > リンクランプが消灯したり、瞬いたりと大忙しでしたね。 上記現象は、ＤＨＣＰとは無関係だと思います。これは金属 は温度変化で抵抗値が変化する性質が元から有るのと（物理の 法則）、熱膨張でコネクタ部分の寸法変化などが有るので、そ の部分での接触不良、あるいはケーブル自体の損傷といった事 でＲＦがレベル変動する場合が有ると思うのです。ＣＡＴＶの 幹線増幅器はパイロット信号などを観察してレベルを自動調整 する機能（ＡＧＣ回路）が有るのですが、その調整範囲を超え てしまうと通信異常になるという現象ですね。ケーブルモデム には所定の送受信レベルが定められていますから、その範囲に 収まるように維持管理をしないと、正常な通信は出来ない訳で す。 最近は、こういった事の常時監視技術がかなり進歩していま すので、そのようなトラブルは減少したであろうと思います。 竹内＠ふじみ野.東上 |
再度、こんにちは。 > 他の端末から固定にてIPを要求されても、ksduさんが先に取得して > 保持すれば特殊な事をしない限り横取りされる事は有りません。 固定ＩＰなのですが、あくまでも端末は手動設定になってい ると思うのです。ですから、誤って設定されている端末が出現 すると、ＤＨＣＰ端末の側は何をやっても対抗できないと思う のですが、如何でしょうか。 技術的に対抗できる可能性は、固定ＩＰになっている加入者 のケーブルモデムを事業者の操作により強制停止する方法だろ うと思うのですが、この方法を採用して固定ＩＰをやっている 人から逆ギレされないかは、懸念をする部分になります。事業 者のＣＭＴＳ（センターモデム）では、加入者の端末同士が直 接通信できないように止めてある筈なので、加入者の端末の機 能で重複ＩＰを発見する事もできず、加入者は首をひねるばか りという状態になると思うのです。 またＤＨＣＰ端末の側が逆に固定ＩＰにして対抗するといっ た方法は、さらに別の加入者に対して被害を与える可能性が有 るので、私は良くないと思います。 実際問題として、事業者の側がこの手の問題の抜本対策をす る場合には、何を考えうるのでしょうか。企業内のＬＡＮとか であれば「検疫ＶＬＡＮ」といった方法が有って、ウイルス感 染の恐れのあるマシン、未承認のマシン、設定の誤っているマ シンなどを断固として接続拒否する事も可能だと思います。し かし電気通信事業用のネットワークではどうなのであろうか？ とも思います。ネットワーク運用ポリシーが異なる可能性が有 りますし。憲法や電気通信事業法に定めの有る「通信の秘密」 や「検閲の禁止」とも関係してしまいますね。この定めのため に、Ｊ：ＣＯＭのような事業者には、対応可能な事と出来ない 事とが有ると思うのです。そのために、「重複ＩＰアドレスで 被害を受けている方からの連絡を待つ。」といった消極的な対 応方法しか無いのかも？と思ったりもします。 竹内＠ふじみ野.東上 |
元の記事の投稿者ではありませんが、失礼します。 |
こんにちは。 事象と提案されている解決案が頭の中で整理できました。あり がとうございます。 Ｊ：ＣＯＭ側が何か解決策を考えようとしても、発生確率を勘 案して費用対効果の問題になってしまいそうですね。 ＤＨＣＰ利用者の側は、重複ＩＰアドレスでやられている事を 発見した場合にはルーターのＷＡＮ側ポート、もしくはＰＣのＭ ＡＣアドレスを変更するしかなく、本来はハードのＲＯＭに焼か れているＭＡＣアドレスを変更するのはイーサネットの運用上は グレーだと思うので、それも決定的な解にはならないと思うので す。いずれにしても、出たとこ勝負のようですね。 カスタマーセンターの対応は、もうトークの内容を工夫するし か無いとか、そんな印象を私は受けました。納得性の問題が有り ますから。 残るは、ＭＡＣアドレスを加入者からの申告制にし、それ以外 のＭＡＣは一切受け付けない設定にするとか、ＳＭＳ（加入者管 理システム）とも連携して異常な設定を発見した場合にはすぐに 対応できるようにするとかが有りそうですが、ＭＡＣ申告制は加 入者に負担がかかりますね。装置の入れ替えとかも、自由にがき きませんし。 竹内＠ふじみ野.東上 |
専門的な話は正直なところ私には難しすぎるので、あまり |
> 今回の場合、ルーターがアドレスを貰えなかった訳ですから、 |
> ＤＨＣＰ利用者の側は、重複ＩＰアドレスでやられている事を |
再度、こんにちは。 > DHCPが配給するアドレスのうち、どれが固定IPに使われてい > るのかを、DHCPサーバーで特定する方法は無いと思うのですが？ これは、判定を自動化するのは確かに困難そうですね。一つの 可能性は、疑わしい事象が報告された時にＤＨＣＰサーバーのリ ーステーブルとＣＭＴＳのＡＲＰテーブルの内容を手作業で比較 するしか無いと思うのです。はっきりしない場合には、ＬＡＮア ナライザやログで観測して最終的に特定という話でしょうか。 ＤＨＣＰサーバーのログを見ると、固定で設定されているマシ ンに対してはリース更新関係のパケットが飛ばない筈なので、そ れを利用して発見する事も可能だと思われます。 ですから、カスタマーセンターの対応が「異常がある場合には 報告して下さい。」という話になるのだと思われます。ＣＭの通 信異常など、別の故障との切り分けも必要ですしね。このあたり の事情がわからなくて、加入者とカスタマーセンターとの関係が ギクシャクするのも、ちょっと不幸な状態かな？と感じました。 竹内＠ふじみ野.東上 |
> これは、判定を自動化するのは確かに困難そうですね。一つの |
こんにちは。 > 固定IPの端末はDHCPサーバーと通信しません。 確かにその通りですね。ＡＲＰテーブルで複数のエントリを 発見した場合に、ＤＨＣＰサーバーと通信していない方が怪し いと判定する方法です。怪しい方のケーブルモデムを強制停止 して、その加入者からの連絡を待つといった方法が有ると思い ます。その加入者から逆ギレされないようにするのはカスマタ ーセンターの腕前の見せ所で、Ｊ：ＣＯＭの若手が処理できる 話かはわからないです。ＣＲＭにもその加入者からの連絡に対 しては警告が出るようにするとか、色々と対策をする事になる のでしょうね。 あとＡＲＰキャッシュの寿命を手動で延長するのは、禁じ手 でしょうか。（ＤＨＣＰのリースタイムとの調和が必要そうで すが。）これは、人間が目で見て判定する作業時間を作るため の措置です。 Ｊ；ＣＯＭの場合、そこまでの対応を全て取ったかは、少し 疑問点となっていました。 竹内＠ふじみ野.東上 |
これ読んでおいてください。そろそろ・・・になってきました。 |
こんにちは。 ＲＦＣの紹介を、ありがとうございました。ケーブルインター ネットの環境ではＣＭＴＳを経由して端末同士が直接相互には見 えない（直接通信は止めてある。隠れ端末の問題。）、またＤＨ ＣＰリレーを経由してＤＨＣＰサーバーと通信していると思うの ですが、技術的な解決がつく物なのか少し考えてみたいと思いま す。 英文のＲＦＣを主に当たるので、少しお時間を下さい。 竹内＠ふじみ野.東上 |
再度、こんにちは。 そもそも固定ＩＰを設定したマシンが、ARP PROBE などの手順 で重複ＩＰの検知に向かうのかな？とも感じました。このあたり の通信手順実装の「お作法」みたいな物は、私には良くわかりま せんでした。 固定はあくまでも固定なのであって、たとえば事業者のルータ ーやサーバーのＩＰアドレスが勝手に変化してはまずい訳ですし。 それでもＩＰアドレス重複環境において、ＤＨＣＰ端末が一方的 に負ける結果になるのは、不都合が有るように思えます。 竹内＠ふじみ野.東上 |
再度、こんにちは。 無線端末では 「隠れ端末」の問題がしばしば発生していると 思います。ＣＭＴＳの環境でも隠れ端末やＡＲＰ汚染の問題が 起きる可能性が在ると思うので、下記のような文書を併用して 考えてみたいと思っております。 http://www.ishilab.net/publication/ipsj/mbl200511shijo.pdf かなり時間がかかるかも知れないです。 それにしても IP ARP PROBE を使う場合、「アドレスを奪っ た物勝ち」「早い者勝ち」にならないか、いささか心配なので すが．．．。（人間は悪い事をするかも知れないと仮定をした 場合。）IP ARP PROBE を利用してアドレス重複の検出を実装 する場合、たとえ後から来た人（ＡＰＲ汚染の原因になった人） が意図的に固定ＩＰを使っていても、ＤＨＣＰ端末の人はその ＩＰを諦めて遠慮しないといけないという運営ポリシーなのか、 私にはその設計思想がわかりませんでした。技術的には、相互 に自分のＩＰアドレス所有権を主張し、一歩も譲らないという 選択肢は無いと思いますが。 Ｊ：ＣＯＭさんは、このような問題をどのように処理するの でしょうかね。 竹内＠ふじみ野.東上 |
再度、こんにちは。 前述の論文の中に「重複したＭＡＣを持ったＮＩＣが出荷され ていた実例が有る。」と書いてあります。私の経験上も、これを 見た事が有るのですが、「メーカーにおける製造ミス」などで発 生する場合が有ると思います。利用者もＭＡＣアドレスを設定変 更する事が可能なので、重複ＭＡＣの可能性も常に存在していま すね。（発生確率は無視できる程度に小さいかも知れませんが。） ＤＨＣＰサーバーが存在する場合のアドレス重複検出でもＡＲ Ｐを利用する方法が存在すると思いますが、重複ＭＡＣが有る場 合にはＡＲＰを使う方法では駄目なので、さらに別の方法を検討 する必要が有ると思われます。ＰＩＮＧを投げる方法も併用すれ ば、重複ＩＰの検出がより確実になるでしょうか。でも、余計な パケットが、ネットワーク内にどんどん増えてしまいますね。そ のあたりも考慮して、どこまで厳重な対策をするのか決定される のだと思います。端末に実装すべき通信手順の変更を伴いそうな ので、実現はそう簡単ではないと思われます。 あとＣＭＴＳの設定により、他の加入者の端末に対してはＰＩ ＮＧがかからないような気がします。この事も、重複ＩＰの検知 に採用できる方式に制約を与えると思います。ケーブルモデムの 設定ファイルの機能で止めてある可能性も有りますし。 これだけ面倒な問題が存在するので、Ｊ：ＣＯＭカスタマーセ ンターのような対応になるのが実情なのかな？とも思うのですが。 結局は重複ＩＰが発生した場合には、ネットワークエンジニアが 苦労をして発見するという事になりそうですから。「常時監視」 「自動検知」が現実的な費用と手間で可能なのか、いよいよわか らなくなりました。余計なパケットをネットワーク内に増やすの も駄目ですしね。 竹内＠ふじみ野.東上 |
> これ読んでおいてください。 |
> 固定ＩＰになっている加入者 |
こんにちは。 > ケーブルモデム > もIPアドレスを持っているのでしょうか？ はい、持っております。しかしそれは、ＣＭＴＳ（センターモ デム）やプロビジョニングシステム、ネットワーク監視システム 等と通信をする「裏方」の役割をしてる物なので、通常は表舞台 に登場するような物ではないです。 ＤＯＣＳＩＳの説明を真剣にやっている日本語の記事をあまり 見た経験が無いのですが、ネット上でこんな物を発見しましたの で、参考になると思います。ケーブルモデムというのは、割と複 雑な原理で動作しております。高周波技術（無線技術）とＩＰ技 術との美しいコラボレーションだと思うのですが。 http://suteteko.org/docsis/index.html http://suteteko.org/ http://www.heart-pot.co.jp/ubr.html http://www.heart-pot.co.jp/ 一般的なルーターやスイッチの類と比較をしますと、こういっ た物と格闘している人は少ないのだろうと思います。情報システ ム関連の技術認定試験でも、これに関する試験問題は出ないでし ょうし。現物は、ＣＡＴＶ関係の技術展示会で見る事が可能かと 思います。 竹内＠ふじみ野.東上 |
> 半固定みたいな振り出しをしていました。 |
こんにちは。 |
こんにちは。 > 本来なら、MACは手持ちのネットワーク機器から回収しないとダメです。 故障している機器でも良いので、何か別の機器からＭＡＣを 持って来られるのであればベターですね。ただ、事業者の側は ＭＡＣのベンダーコードを人が見て障害解析作業で混乱するか も知れないですね。たとえば加入者端末は「ＰＣ」だと思って いたのに、実際には「ルーター」であったとか、そのような話 です。世間のネットワーク監視システムでは、ベンダーコード を観測して機器のメーカー名を自動表示させている例がしばし ば有ると思います。 あと落とし穴になるのが「メーカーの製造ミスによる、重複 したＭＡＣを持つ機器の存在」なのですが、この問題に当たる 可能性は相当少ないでしょうね。 竹内＠ふじみ野.東上 |
再度、こんにちは。 技術論から顧客満足度、カスタマーサポートのあり方まで議 論が広がったのですが、結局のところ暫定対策は、 ・ルーターの電源を切らない。 ・再発した場合にはルーターのＷＡＮ側ポートのＭＡＣアド レスを変更してみる。（ＭＡＣ重複の可能性は殆ど無いと 仮定する。） といった感じでしょうか。ご検討下さい。 事業者側の対応の話は、まだまだ続く可能性が有ると思って います。そもそも、ＩＰｖ４の世界において抜本的対策が困難 なのが良くないのでしょうね。昔はＩＰは専門家だけの物であ り、間違った設定をする人は殆どいないという前提で成立して いたと思うのですが、その前提が崩れてから久しいと思います。 事業者は、素人に何をされるかわからないという前提の上で、 仕事をする必要が有ると思います。 竹内＠ふじみ野.東上 |