X

【Love Affair】携帯からのアクセスに対する考察・次の一手 Part4

■ このスレッドは過去ログ倉庫に格納されています
1root▲ ★
垢版 |
NGNG
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。

たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、

Love Affair 作戦。
Part4 (タイトル)募集中

前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/operate/kako/1075/10758/1075887465.html
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
http://qb5.2ch.net/test/read.cgi/operate/1088657713/
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part3
http://qb5.2ch.net/test/read.cgi/operate/1095146311/

Wikiページ http://info.2ch.net/wiki/pukiwiki.php?Love%20Affair
NGNG
ということで、いったん >>18 やるです。
これから squid をリスタート。
NGNG
store を rebuild 中。

2005/05/29 07:57:32| Store rebuilding is 9.7% complete
2005/05/29 07:57:49| Store rebuilding is 10.8% complete
2005/05/29 07:58:05| Store rebuilding is 11.8% complete
...

rebuild が終わったら、観察へと。
NGNG
ちなみに memory_pools_limit は、未設定の状態。
NGNG
各サーバとも、BlackGoatから「漏れて出た」分、転送量が増えちゃってますね。
やはり「何としても漏らさないようにする」必要があると。

http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/
NGNG
rebuildはだいぶすすんだけど、もうしばらくかかる模様。

2005/05/29 08:16:34| Store rebuilding is 63.5% complete
2005/05/29 08:16:59| Store rebuilding is 64.6% complete
2005/05/29 08:17:23| Store rebuilding is 65.6% complete
NGNG
効果あるかも。軽くなってきたきがする。
NGNG
今 store の rebuild おわた。
これから、観察。

とりあえず 1:00 まで。
NGNG
2005/05/29 08:30:06| Beginning Validation Procedure
2005/05/29 08:31:17| 262144 Entries Validated so far.
2005/05/29 08:32:30| 524288 Entries Validated so far.
2005/05/29 08:32:54| Completed Validation Procedure
2005/05/29 08:32:54| Validated 601874 Entries
2005/05/29 08:32:54| store_swap_size = 25528592k

Validation もおわた。
本格観察開始。
NGNG
さっきより、はるかにうまくHDDの性能を出せている気がする。

Disks da0 da1 pass0 pass1
KB/t 22.65 20.06 0.00 0.00
tps 283 287 0 0
MB/s 6.25 5.61 0.00 0.00
% busy 87 86 0 0
NGNG
重い(待たされる)ことは、かわらないっすね。

あとは「どっちがよりましか」か。
NGNG
一瞬軽くなったけど、また外からみた重さが重くなったですね。
HDD待ちかなぁ、やっぱ。
NGNG
で、>>27 は実はかんちがいで、それだけ HDD を「使ってしまう」
状態らしい。

やはり巷間言われているように、memory_pools は off のほうがいいのか。
いずれにせよ、我慢してしばらくこのまま。
NGNG
いまいちっすね。< memory_pools off

http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/

1:00にBG3の設定戻します。
それが終わったらここに書きますので、、BG3/BG4の配分を元に戻していただけますか。> できる方々
NGNG
こうすけさんに戻していただきました。
ぼちぼち、今回わかったことをだらだらと。
NGNG
○ 今回(2005/5/29)のBG負荷試験でわかったことをだらだら

今のBG3/4は、現在のピーク値(約10,000access/min)の約1.7〜1.8倍ぐらい、
つまり17,000〜18,000access/minぐらいが、限界値らしい。

つまり、今の1.8倍のアクセスがフロントエンドから来ると、何かしないと早晩破綻する。
今の伸び率のグラフから推測すると、、、ざっくり言って、もって今年中か。
auががんがってるから(企業努力してるってことなので念のため)、ことによるともっと早いかも。

限界値ではI/Oが限界に達するらしい。
ただ、HDDのアクセスはまだハードウェアの限界ぎりぎりではなく、50%程度らしい。
つまり、squidをもっとチューニングするとか、1台で2つ動かすとかすれば、
もっとHDDの性能を使える可能性がある。

CPU資源は、まだ使い切られていなかった

squid の memory_pools の設定は、off (squidではなくFreeBSDにまかせる)のほうが
効率よく動くらしい。
NGNG
HDDのI/O性能からすると、今の1.7倍のアクセスでI/O性能の50%強ぐらいだったから、
仮にsquidが理想のプログラムの動作をするようになったとすると、1.7倍の1.8倍ぐらいまでは
いける可能性があるということか。つまり、約3倍と。

ただ、ここまで性能をしぼり出すことはたぶんいろいろな理由によりできないから、
現在のシステムにおけるハードウェアの性能は、
めいっぱいまでがんがったとしても、やはり今の2倍とか2.5倍あたりまでかなと。
NGNG
…といったところか。

とりあえず今すぐにBGが破綻するわけではなそう(ちょっとだけ時間に余裕がある)、
というのは、少しだけいい情報だったかも。
NGNG
BG3 disk I/O (read)
http://mumumu.mu/mrtglog/2005/05/30/io/blackgoat3ior.html (*1)
同じく、(write)
http://mumumu.mu/mrtglog/2005/05/30/io/blackgoat3iow.html (*2)

1) たくさんの板のリクエストに答えなければいけなくなり、メモリのヒット率が悪くなり、
結果としてHDDを読む率がどばっと増えた。(*1)
それでもまだ、ラッシュが起こる20:00まではなんとかなってた。

2) ラッシュを迎えると、HDDのキャッシュヒット率も下がり、外のサーバにデータを思い切り
取りにいきはじめた。また、HDDにもしょっちゅう書き込む事態が発生した。(*2)
これにより、破綻状態になった。

squidは、
a) メモリキャッシュ => リクエスト元に内容返す
b) HDDキャッシュ => HDD読む => メモリキャッシュに置く => リクエスト元に内容返す
c) いずれもだめ => 外へとりにいく => HDDに書く => メモリにキャッシュする => リクエスト元に内容返す

という動作をするので、まず a) が1台になった時点でパンク状態になり、
ラッシュを迎えた時点で b) もパンクしたということか。
NGNG
(妄想)

これなら、tiny tigerのフロントエンドそれぞれでメモリキャッシュモードだけののsquidを立ち上げて、
BlackGoatと多段にすれば、さらに1段得をするような気が、しないでもない。
NGNG
あと、せっかくsquidなんだから、BG3とBG4を「兄弟｣にしてみるか。
NGNG
あと、

# cache_mem 8 MB
cache_mem 80 MB

に現在変更してあるけど、

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
13755 squid 20 0 269M 265M kserel 1 446:13 0.29% 0.29% squid

だから、もっと増やす道もあるかも。
NGNG
BG3 で、ためしに 256MB にしてみた。

# cache_mem 8 MB
#cache_mem 80 MB
cache_mem 256 MB
NGNG
しばらく動いてsquidが肥大していって、

FATAL: xcalloc: Unable to allocate 1 blocks of 4104 bytes!

と言って落ちました。

もうちょっと小さくするか。128MBあたりで。
NGNG
# cache_mem 8 MB
#cache_mem 80 MB
cache_mem 128 MB

これで、しばらく観察。
BG4はとりあえずそのまま(比較のため)。
NGNG
>>42
それほどかわらなそうなので、将来とか緊急時を考えると
キャッシュメモリを大きく与えたほうがよかろうということで、
BG4 もこれにした。

で、「親子実験」ができそうなので、
もうしばらくしたら、c-au系で実験しようかなと。
NGNG
準備できました。実験開始します。

依頼は、c.2ch 不具合報告スレにて。
NGNG
squid的設定内容:

1) c-au4 c-au5 c-au6 のsquidは、HDDにファイルをキャッシュしない(メモリキャッシュのみ)
2) c-au4 c-au5 c-au6 はお互いに sibling (兄弟姉妹)
3) blackgoat3 blackgoat4 を parent (親) ラウンドロビン設定

c-au4での設定例

1)
cache_dir null /dev/null

2)
cache_peer 192.168.0.162 sibling 8080 3130
cache_peer 192.168.0.163 sibling 8080 3130

3)
cache_peer 192.168.0.3 parent 8080 3130 round-robin
cache_peer 192.168.0.4 parent 8080 3130 round-robin
NGNG
4) c-au4 c-au5 c-au6 のsquidは、とりあえず遅延なしに設定

refresh_pattern . 0 0% 60 override-lastmod reload-into-ims
NGNG
ICP (ひらたくいえば、squid同士がお話しするための部分)のアクセスコントロールを
あけていませんでした。

icp_access allow private
icp_access deny all

を、BG3/4とc-au4/5/6のsquidに追加し、再起動。
NGNG
で、この際に、上記の親の部分の round-robin オプションがない状態になりました。
今、au4/5/6 とも、オプションがない状態。
まずはこれで実験してみて、あとで復活するかんじで。
NGNG
で、never_direct を、c-au4/5/6系にいれておけば、だいじょうぶかな。
これも、あとで。
NGNG
round_robin 復活させました。

never_direct allow all を c-au4/5/6 に入れました。
これで、BG3/4からとれない時に直接とりにいってしまう(さっきの状態)ことは、ないはず。
NGNG
恥ずかしい統計情報(c-au4/5/6からだだ漏れ)を、手で消しました。
普段はこういうことはしないんですが、これが残っていると
今後の傾向がつかめないので、やむを得ず。ううむ。
2005/05/30(月) 23:31:02ID:u+WT0kTqO
こんなもんなのか？と思っていたが
感覚が麻痺していたのか＠だだ漏れ
NGNG
帰宅後、失敗談を告白するです。
今は正常に動いているはず。

ローカルsquidの様子をとりはじめた。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/
NGNG
squid がメモリを食っていくので、cache_mem を 32 MB まで減少。< c-au4/6
# c-au5 は、リブート要請へと。
NGNG
さすがに 32 MB は少ないようなので(ヒット率減少)、
64 MB に戻した。
NGNG
こんどは、FDを使い果たし。
「マイルド(前のc-au1 bananaと同じ)」を、tigerと同じに戻した。

kern.maxfiles=32768
kern.maxfilesperproc=16384
↓
kern.maxfiles=131072
kern.maxfilesperproc=65536
NGNG
＜今日のミス＞

1) 親・仲間に対し、ICPを許可していなかった

まぬけなことに、ICP (他のsquidサーバと、
キャッシュが存在するかどうか通信するためのプロトコル)を、
それぞれのサーバに対して許可していませんでした。
つまり、親子、兄弟との間での会話が、一切できない状態になっていました。

→ ICPを許可して、解決。

2) 親や仲間とうまく通信できなかった場合に、
自分でとりにいってしまう設定を殺していなかった
このため、1) の影響で２ちゃんねるの掲示板サーバに、
大量の「トラフィック漏れ」が起こった。

→ 1) の問題解決後、squid.conf で never_direct allow all を設定。

3) FDがsquidを動かすには小さすぎた

→ /etc/sysctl を修正・システム変数を再設定したうえで、squidをインストールしなおし。
NGNG
また、squid が CPU 使いまくりな状況に。

原因切り分けのため、いったん c-au[456] をリブート。
NGNG
「マイルド設定」を全面的にやめ、

# increase listen queue
kern.ipc.somaxconn=8192
kern.ipc.maxsockbuf=2097152

を復活。< c-au4/5/6
NGNG
# none
cache_peer 192.168.0.3 parent 8080 3130 round-robin
cache_peer 192.168.0.4 parent 8080 3130 round-robin
cache_peer 192.168.0.162 sibling 8080 3130
#cache_peer 192.168.0.163 sibling 8080 3130

sibling (仲間)の設定を1つだけにしてみた。

c-au1 => c-au2
c-au2 => c-au3
c-au3 => c-au1

を設定。
NGNG
あとは、

・設定的にディスクキャッシュを作ることにするけど、それは md にする

あたりかなと。
NGNG
2005/05/30 15:40:35| WARNING! Your cache is running out of filedescriptors
2005/05/30 15:40:51| WARNING! Your cache is running out of filedescriptors
2005/05/30 15:41:07| WARNING! Your cache is running out of filedescriptors
2005/05/30 15:41:23| WARNING! Your cache is running out of filedescriptors

なんていうかんじで転んで、

2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.3, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.4, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.162, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.4, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.3, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.3, port 3130: (55) No buffer space available
2005/05/30 15:51:47| comm_udp_sendto: FD 12, 192.168.0.4, port 3130: (55) No buffer space available

というかんじになり、あとはだめだめな状態に。< c-au4

とりあえず、子供同士の兄弟関係(sibling)を全部やめて、
親だけを参照するようにしてみた(効果があるかは不明)。
2005/05/31(火) 20:18:38ID:RT9Y7UpV0
ichiou hosyu
NGNG
まだ「話だけ」の状態みたいだけど、ブレイクすると(以前のYBBの時のように)世の中変わるかも。

携帯電話の参入、１２年ぶり受け入れへ・総務省方針
http://www.nikkei.co.jp/news/main/20050602AT1F0100Y01062005.html
NGNG
で、au系でやっているローカルキャッシュ実験ですが、
いいときで30%ぐらい、平均すると2割ぐらいヒットしているみたい。
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/loveaffair/c-au4-hits.html

もうちょっと実験して、うまいようなら他のやつにも。
NGNG
>>65 の比率は前に「ミニ雪だるま」をex7でやったときとほぼ同じなので、
やはりsubject.txtとかが、かなり効いているみたい。

あとで、ログ解析とかしてみるか。
NGNG
今晩サッカーがあるけど、時間帯が微妙に遅いかな？
2005/06/06(月) 23:41:35ID:Gh1i/34o0
hosyu
2005/06/10(金) 02:26:26ID:aGPAzdx40
sage
2005/06/12(日) 15:19:58ID:H8nsS6+dO
test
2005/06/20(月) 00:20:54ID:TBNuSRbE0
てすと
2005/06/22(水) 14:31:33ID:i2KAdWjC0
けいたいねぇ
2005/06/22(水) 14:39:03ID:qg1u1aRV0
youjo ita
2005/06/22(水) 14:58:21ID:OuirBcdL0
なんだかんだいってvodafoneがお得
2005/06/22(水) 21:38:15ID:Sr4wrO5M0
test
2005/06/23(木) 11:17:57ID:Y/SaG3Bn0
人多なのか？
2005/06/23(木) 15:12:46ID:2jWiHWWB0
>>74 docomoにしる。
2005/06/23(木) 17:54:07ID:oloqvSVA0
iyada yo
2005/06/23(木) 18:48:55ID:KlgkVLKh0
アステル最強伝説
80denpa
垢版 |
2005/06/27(月) 13:41:51ID:Pyy/peUe0
denpa waruiyo
NGNG
海底、、
82root▲ ★
垢版 |
NGNG
p2.2ch.net不具合報告スレ４
http://qb5.2ch.net/test/read.cgi/operate/1118316599/551-552

c-au4 で以下のように設定を変えてみた。
問題なさそうなら、全部に入れてみるか。

;session.cache_limiter = nocache
; changed by mumumu, 2005/6/28
; http://qb5.2ch.net/test/read.cgi/operate/1118316599/551-552
session.cache_limiter = private_no_expire
NGNG
http://qb5.2ch.net/test/read.cgi/operate/1118316599/556-557

ちと難しそうなので、いったん元に戻したです。
必要なら、PHP側でやったほうがいいの鴨。
2005/06/28(火) 19:29:13ID:o9xMth8eO
>>83
c.2chというかclAssIcは
前からキャッシュ出来ていた気がする。
現在も効いてます。
NGNG
p2のスレで、キャッシュについて興味深い話が続いているわけですが、
c-docomo系とc-au系で、キャッシュの効き方の相違? なのか、
トラフィックの出方に、相当違いがあります。

ここ見てもらうとわかるのですが、
概ね同じ設定をしているDoCoMo系とau系ですが(台数も同じ)、
アクセス数や２ちゃんねるから出て行くトラフィックは概ね比例しているのですが、
携帯側から「入ってくる」トラフィックに、大幅な違いがあります。
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/traffic/

具体的にはau系のほうが、圧倒的に「入り」が多い。
これは、なぜなんでしょうか。
NGNG
>>85
proxy\d+.docomo.ne.jp というくらいだから実はキャッシュしているとかとか。
NGNG
>>86
２ちゃんねる(c)から見た「出」じゃなくて「入り」なんですよね。
「出」だったら、そうかなと思うんですが。

つまり、auのほうがDoCoMoよりも、「携帯側から」何かがたくさん来るんですよ。

こんど、tcpdumpでもしてみるか。
NGNG
>>87
http://mumumu.mu/mrtglog/2005/05/18/traffic/

このグラフを見ると、「c-docomo2.2ch.net/c-docomo.2ch.net」の入りも多いですよね？
たしか、ａｕだけラウンドロビンしてませんでしたっけ？
あと、それから、ローカルキャッシュの分かと。思います。
NGNG
>>88
その頃は、c-docomo2と同じサーバで動いていたロードバランサを経由していたからです。
なので、そのデータは参考になりませんです。

いまはDoCoMo/auとも、ラウンドロビンです。
ロードバランサ経由なのは、others系だけ。
NGNG
>>89
pekoスレ見てきました。はい。そうでした。
あと思いつくのはローカルキャッシュだけか、、

tcpdumpの内容にワクテカです。
NGNG
セキュリティのためにbpf切ってるから、
いっぺん、リブートしないといかんですね。

機を見て、やってみるです。
2005/06/30(木) 04:12:08ID:fMp6rTlw0
>>85
普通に考えればHeaderのサイズの違いかな。
http://specters.net/cgipon/labo/c_env.cgi?c=i
http://specters.net/cgipon/labo/c_env.cgi?c=e

auのほうはAccept(HTTP_ACCEPT)がやたら大きいとかX-なんとかを送ってくるとかで
サイズが大きくなりがちみたい。
NGNG
>>92
あー、そっかぁ。そうですね。

そういや、Accept: がすんごい長いですね。auって。
でもちゃんと、Accept: */* を送ってくるわけだけど。

某Vo(りゃ。
2005/06/30(木) 12:31:18ID:Duy1vO3hO
診断くんで環境変数しか見たことないけど、
headerはそれ以外も含むのかしら。

アクセス数がほぼ同じなので10倍くらい
違う事になりますねぇ。

誰かにDoCoMo借りてみよう。
そんなに何も送ってないとは。
2005/06/30(木) 22:40:58ID:yoSzbVeGO
ドキュモはリファラ送らないくらいですからね。
96root▲ ★
垢版 |
NGNG
○ Vodafoneの接続用IPアドレスレンジとして、公表しているもの以外も使われている件について

携帯→2ch運用情報スレッド20
http://qb5.2ch.net/test/read.cgi/operate/1117638822/729-742

ということで、結構ショッキングなことが発覚しました。
これからc-othersの接続ログをあさって、実際に接続があったIPアドレスを調べてみるです。

(該当スレの734)
734 名前：root▲ ★[sage] 投稿日：2005/07/05(火) 03:32:06 ID:???0 ?##
うーむ、

これって、
http://whois.nic.ad.jp/cgi-bin/whois_gw?key=210.169.176.0/24

ここのWebに出てないんだけど。
http://www.dp.j-phone.com/dp/tech_svc/web/ip.php

とりあえず、Vodafone用のIPレンジとして追加しておくです。
97root▲ ★
垢版 |
NGNG
昨日のアクセスログを掘って、
UA = Vodafone or J-PHONE なものから、接続先のIPアドレスを抽出しました。

202.228.227.3
202.228.227.4
202.228.227.6
202.228.227.7
202.228.227.8
202.228.227.9
206.223.150.148
210.146.60.199
210.146.60.200
210.154.135.71
210.158.198.62
210.169.193.224
210.169.193.225
210.228.189.56
210.228.189.77
211.127.12.240
211.127.183.55
211.8.159.131
211.8.159.132
211.8.159.133
211.8.159.134
211.8.159.135
211.8.159.136
211.8.159.203
219.118.171.51
221.112.172.235
61.195.194.6
61.195.195.138
64.233.166.136
64.233.178.136
98root▲ ★
垢版 |
NGNG
で、これを >>96 の URL にある、

210.146.7.192/26
210.146.60.192/26
210.151.9.128/26
210.169.193.192/26
210.175.1.128/25
210.228.189.0/24
211.8.159.128/25
211.127.183.0/24

とてらしあわせると、、、。

202.228.227.* これは対応しなくてよさげ
206.223.* なのは、PIE(c-control)ですね。これもOK。
210.154.135.71 これも対応しなくて大丈夫かな。
210.158.198.62 これもとりあえずOK。
211.127.12.240 はちと気になるですね。
219.118.171.51 これも大丈夫そう。
221.112.172.235 これもOKか。
61.195.192.0/22 は、Vodafoneになっているけど、掲載がないじゃん。
http://whois.nic.ad.jp/cgi-bin/whois_gw?key=61.195.192.0/22
64.233.160.0/19 は、Googleか。
99root▲ ★
垢版 |
NGNG
>>98
> 211.127.12.240 は、ODNですね。これも大丈夫か。
2005/07/05(火) 04:16:47ID:UqvQuv6f0
voda公式の情報と違うのはこの２つかな。

◆210.146.60.199
a. [IPネットワークアドレス] 210.146.60.128/25
b. [ネットワーク名] VF-LIVE-K
f. [組織名] ボーダフォン株式会社

◆61.195.194.6
etwork Information: [ネットワーク情報]
a. [IPネットワークアドレス] 61.195.192.0/22
b. [ネットワーク名] VODAFONE
f. [組織名] ボーダフォン株式会社
101root▲ ★
垢版 |
NGNG
61.195.* なIPアドレスからは、Vodafone 702NKが接続してきているですね。
3G用?

でも、Webに記載がないし、
何せ、逆引きが jp-?.ne.jp じゃないんだよなぁ。

%nslookup 61.195.195.138
Server: localhost
Address: 127.0.0.1

Name: ca1.tik.access-internet.ne.jp
Address: 61.195.195.138

%nslookup 61.195.194.6
Server: localhost
Address: 127.0.0.1

Name: dt31caky01.kyo.access-internet.ne.jp
Address: 61.195.194.6
102root▲ ★
垢版 |
NGNG
>>100
> ◆210.146.60.199

は、公式サイトにある、

210.146.7.192/26

に入っているですね。

しかし、あやしいので、210.146.60.128/25 で登録しなおしておくです。

しかしこの 61.* なアドレスは何者だ?
とりあえず、登録はしておこう。

なんかもう、むちゃくちゃ。
103root▲ ★
垢版 |
NGNG
access-internet.ne.jp も、Vodafoneみたいですね。

しかしいきなりこんなふうに変えると、
昔のバージョンのbbs.cgiでも対応できないですね。
Vodafoneの逆引きはJP-?.ne.jp だと決め打っていたし。

今の(私が先日変えた)bbs.cgiも、公式サイトのIPアドレスレンジの情報が不足しているんじゃ、
対応できないっすよ。ぶちぶち。
NGNG
>>102
Googleのキャッシュでみたら、
指定事業者名ボーダフォン株式会社
指定事業者略称J-PHONE
アドレスブロック
61.195.192.0/22
61.195.196.0/22
61.195.200.0/21
202.179.192.0/20
202.179.208.0/20
って、ありましたね。
検索ワードは、【ボーダフォン株式会社】と【61.195.192.0/22】です。
はてさて。
105root▲ ★
垢版 |
NGNG
とりあえず、210.146.60.128/25 61.195.192.0/22 を
VodafoneのCIDRブロックに追加した bbs.cgi を配りました。

>>104
むー。
106root▲ ★
垢版 |
NGNG
>>104
追加しとこう。
で、実害が出たら考えよう。

むぎゅー。
2005/07/05(火) 04:39:37ID:muqKwsM70
とりあえず、蹴りいれとく


　　　∧＿∧ 　＜公表しているIPと違い過ぎるんだよ
　　 （　・∀・）
　と⌒ 　 　 て)　　.人　ｶﾞｯ
　　 （　　______ﾇﾙﾎﾟ　 >_∧∩
　　　 )　　）　　　　 Ｖ｀Д´）/ ←vodafone
　　　 レ'　　　　　　　　　　/

#vodaのIPはすべて地域割りになってるから
210.146.7.192/26
210.146.60.192/26
210.151.9.128/26
210.169.193.192/26
210.175.1.128/25
210.228.189.0/24
211.8.159.128/25
211.127.183.0/24
これも上が北海道で下が九州沖縄
だから表に載ってないIPも使ってる対応地域が存在するはず
108root▲ ★
垢版 |
NGNG
しかし、こんなことでほんとにいいのか?

なんで、2005年6月3日現在の情報が最新じゃない
(というか、間違ってる、に近いと思う、特に >>96)んだ?

みんな、困ってないのかなぁ?
109root▲ ★
垢版 |
NGNG
>>107
そのトリップはVoda使いさんですね。そのせつはどうも。

どっかに、もっと正確な情報はないんかいな。
特に3G方面。
NGNG
>>104
ちなみに、このリストは2004年12月21日の物らしいですけど。
whoisしてみたら、ボーダフォンになってますね。
111root▲ ★
垢版 |
NGNG
で、>>96 の URL は、こっちのほうがいいのかな。
(今は同じ物の模様)
http://developers.vodafone.jp/dp/tech_svc/web/ip.php

いずれにせよ、この数字があてにならなくて、
かつDNSの逆引きも部分的に jp-?.ne.jp じゃなくなってるとしたら、
いったい、どーせいっちゅーねん。
2005/07/05(火) 04:51:23ID:muqKwsM70
＞61.195.* なIPアドレスからは、Vodafone 702NKが接続してきているですね。
3G用?

これは有名なVodafone 702NKがボーダフォンライブ！を経由せずにネットに繋がるとき
の分でしょ、２ちゃんねらはそこそこつかッテルはず
（といっても定額対象外になるからガンガンはつかえないけど）
PCとかに接続せず単体標準でこの機能があるのは702NKだけだから３G用というより事実上７０２K用


＞どっかに、もっと正確な情報はないんかいな。
＞特に3G方面。
それがあれば誰も苦労はしな（ry
2005/07/05(火) 04:52:00ID:ayiZgvoO0
rootﾀﾝ、ガンガレ
114root▲ ★
垢版 |
NGNG
>>112
そうなんですか。< 702NK用
とりあえずVodafone扱いにしておきました。なんだかなぁ。

で、最後の行は、、ねぇ。

ちなみにさっき追加した 210.169.176.0/24 は、
逆引きすると jp-c.ne.jp と vodafone.ne.jp が
混在しているようです。

というか、逆引きもいつの間にか部分的に jp-?.ne.jp じゃなくなってるのね。

なんか、すごいっすね。
わたしゃ趣味100%でやってるから、何の責任もないし義務も発生しないわけだけど、
業務でWebサイト構築している人とか、みなさんどうなっちゃうんだべ。
2005/07/05(火) 04:57:49ID:muqKwsM70
たぶんこんな感じ
ボーダフォンライブ！を通過するもの→定額対象→IP地域割り→ jp-地域番号.ne.jp
ボーダフォンライブ！を通過しないもの→定額対象外→IP地域割りなし→アクセスインターネット扱い
2005/07/05(火) 04:58:43ID:rsFjXdqX0
携帯の機種情報を送らないとボーダから書きこみ出来ないようになってしまったみたいですが、
ボーダのコネクトカードも巻き込まれてしまってます。
これはPDAやノートに刺すタイプの通信カードなので機種情報を送りつけません。
この場合は諦めるしかないでしょうか？
117root▲ ★
垢版 |
NGNG
>>115
ふーむ、そういうかんじなのですか。

逆引きが vodafone.ne.jp になるやつ(例は >>114 のアドレスブロック内にある)は、
どうなるんだべ。
118root▲ ★
垢版 |
NGNG
>>116
コネクトカード、ってのがあるですか。

んじゃ、後で追加した access-internet.ne.jp のやつは、はずしておくです。
702NKとか、コネクトカードだけなのかな。ここは。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況