Unix技術者のネットワークの知識

1 ：名無し ：01/10/07 11:18

Unix技術者って一般的にいってどの程度ネットワークの知識を
もってるのかな？ルータとかL3スイッチ、ロードバランサー、
VPNとかいろいろあるけど。
どんなもんでしょ？

2 ：にょ ：01/10/07 11:37

やってる仕事による

3 ：名無しさん＠お腹いっぱい。 ：01/10/07 13:26

ここと通信技術板がメインの巡回ルート。

4 ：名無し ：01/10/07 19:57

pingとtracerouteさえ知ってればOK。
sshなんか使わない。telnetでしょ。
scpなんか使わない。rcpでしょ。

5 ：名無しさん＠お腹いっぱい。 ：01/10/07 22:10

社内にあやしいバスハブを見つけてから
telnetは使っていない・・・

6 ：書籍代月一万！！ ：01/10/07 22:38

>>1

>>4
pingとtracerouteさえ知ってればOK。

と言うレベルの人が多いです

7 ：untitled ：01/10/07 22:46

>>5
バスハブってなんですか。

8 ：名無しさん＠お腹いっぱい。 ：01/10/07 23:38

ネットワーク層までは肉体に実装しています。
それが、Unix技術者です。

9 ：名無しさん＠お腹いっぱい。 ：01/10/07 23:49

とりあえず、プログラマ系の奴で
レイヤ2のトラブルシュートができる奴は見たこと無い

SEでもルーティングプロトコルを理解できてない奴は結構いる

10 ：名無しさん＠お腹いっぱい。 ：01/10/07 23:59

ディスタンスベクタルーティングプロトコル
リンクステートルーティングプロトコル

ルーティングプロトコルを分類している用語が
すでに長くてキツい X-(

とりあえず、
router rip

11 ：大学関係者 ：01/10/08 00:15

フロアのルータから先は管轄外なので知らない。

12 ：名無しさん＠お腹いっぱい。 ：01/10/08 00:18

↑と、まあ実際はこの程度

13 ：名無しさん＠お腹いっぱい。 ：01/10/08 00:24

>>9
>レイヤ2のトラブルシュートができる奴は見たこと無い
なんでここでデータリンク層の話なのに
>SEでもルーティングプロトコルを理解できてない奴は結構いる
ネットワーク層に話が飛ぶんだ?

14 ：名無しさん＠お腹いっぱい。 ：01/10/08 00:27

>>13
ネタでしょ。

15 ：名無しさん＠お腹いっぱい。 ：01/10/08 00:43

レイヤ2のトラブルシュートってどんなのですか？
私が経験したのは、ファイアーウォールがarpを受け付けなくて
マシンのリプレースに困った。
ルータとTAのインターフェースが違った。
なんぞです。ほかに思いつくのってarpテーブルが壊れたくらいなんすけど。

16 ：名無しさん＠お腹いっぱい。 ：01/10/08 00:51

100BASE-TXのケーブル作れま〜す。

17 ：底名無し沼さん ：01/10/08 00:53

Ethernet addressのconflictも今や滅多にないしな。
Layer 2よりlayer 1のtroubleの方が多いな。

ただ、100Base-TXが流行り出した頃、nego.の失敗によるlink downは多かったな。

18 ：名無しさん＠お腹いっぱい。 ：01/10/08 00:57

>>17
まだ調子悪いときが結構あるよ。autoにすると激遅とか。
ハブとネットワークカードとドライバの相性はもう試すしかない。
ケーブル変えたらIPは通るのに、なぜかNetBEUIが通らないとかさ。
手作りケーブル使ってるせいもあるかな。

19 ：1ですが、 ：01/10/08 01:13

やはりその程度（といったら失礼ですが、）ですか。

いや、実はUNIXのメーカーに中途で入ったんですが、皆あまりにも
ネットワークの事を知らないので驚いた次第です。はい。

20 ：名無しさん＠お腹いっぱい。 ：01/10/08 01:24

>>17
え、そんなんあったんですか？どうしようもないじゃありませんか。
思いつくのはdumpしてarpリクエスト見つけて同じやつから会社名
たぶん、ここでつきます。私。。
>>18
autoにするとつながらないってそういえば経験しました。
100 hulfに固定したらなぜかうまくいった。
arptraceroute見たいなコマンドないんすかね？

21 ：にょ ：01/10/08 01:28

ネットワーク専門の会社でないとみんな知識ないだろね．
それに，全レイヤ詳しい人もそんなにいないと思う．

すべてにおいて，やたら詳しい人は，普通の仕事でなくて，
研究職やってること多いから，普通の人はあまり遭遇できないかも

22 ：名無しさん＠お腹いっぱい。 ：01/10/08 01:34

自分がどのレイヤーの住人か考えなくちゃね。

23 ：名無しさん＠お腹いっぱい。 ：01/10/08 01:43

>>15
arpが通らないってルータでもサーバでも良くあるよね
パケットモニタするとarpはNICまできてるんだけど
どうやらarpテーブルを更新できないってのが多かった
NICやモジュール変えると大抵大丈夫だけど、
止められないからスタティックで運用回避ってのもありがち

>>17
オートネゴは絶対に使わないってのはネットワーク業界では常識

24 ：名無しさん。 ：01/10/08 02:53

>>23
そう？私はオートネゴをoffにすると途端に遅くなるって経験が
多いのでonにするけどな。

25 ：名無しさん＠お腹いっぱい。 ：01/10/08 02:56

オレはネットワーク屋じゃねえんだよ!

26 ：名無しさん＠お腹いっぱい。 ：01/10/08 03:23

>>19
なるほどな。
つーかだからこそ知識のあるアニキが採用されたんだろうな。
いろいろ教えてあげてくれると、助かる。

アプリケーション層、プレゼンテーション層あたりなら、
ここの板には強い人もいるはずだ。
# あ、セッション層もだね。Xあるし。

俺?
…聞くなよ。何も詳しくねぇよ。
すぐ逝ってくるよ。

27 ：名無しさん＠お腹いっぱい。 ：01/10/08 03:25

たとえば、ネットワークは戦争が起きてもまあある程度は
生きてると思うけど、DNSって死なないか？
jpドメイン管理してるところってひとつでしょ？
名前正引きがそのうち不可になるよね？

28 ：底名無し沼さん ：01/10/08 03:31

>>19
って言っても、>>1の内容も大したことねーべ
贋もんじゃないなら何か語ってみれ

29 ：名無しさん＠お腹いっぱい。 ：01/10/08 03:53

jpドメインは6サーバあるけど．

jp nameserver = NS-JP.SINET.AD.jp
jp nameserver = NS.WIDE.AD.jp
jp nameserver = NS0.IIJ.AD.jp
jp nameserver = NS0.NIC.AD.jp
jp nameserver = NS-JP.NIC.AD.jp
jp nameserver = DNS0.SPIN.AD.jp

30 ：名無しさん＠お腹いっぱい。 ：01/10/08 03:55

>>29 それらのうち、大手町にあるのはいくつなんだろうね。

31 ：9 ：01/10/08 04:39

>>15
レイヤ2のトラブルシュートは主にスパツリ
っていうか9割はスパツリ

あとは>>15自身が言ってるようなこと

32 ：ななし ：01/10/08 07:28

自分、network 関連について、技術を習得したいなぁと思って
いたりするんですが、自宅に1台しかパソコン（Solaris 入れている）
がないのですが、どんな風に勉強していったらよいものでしょうか？

33 ：名無しさん＠Ｅｍａｃｓ ：01/10/08 07:50

>>32
秋葉原へ逝って中古のマシンを買えば? 一万円あれば充分お釣がくるよ。

34 ：名無しさん＠お腹いっぱい。 ：01/10/08 08:48

network関連の技術が何を指すのかによる。
WANルータの設定とかって独学で学べるようなもんなの?

35 ：底名無し沼さん ：01/10/08 10:25

>>34
> WANルータの設定とかって独学で学べるようなもんなの?

マニュアルlあれば何でも設定できるだろ。分からないことは調べればいいんだし。

taged VLANがおかしいみたいだけど、ちょっとprotocol analyzerで調べてみるか？
IEEE 802.3*は一通り読んでます、firmwareも書いたことあるよ、
なんてことはないけど、>>1に書いてあることくらいは知ってるだろ。
LANを設計したことある奴なら。

36 ：名無しさん＠お腹いっぱい。 ：01/10/08 12:02

>>31
> スパツリ
その略し方、(･∀･)ｲｲ!!
ってむしろ業界標準略語ですか?

37 ：7誌 ：01/10/08 12:56

>>36
普通にスパツリっていいますよ。

38 ：　 ：01/10/08 13:25

>>34
WANルータの設定方法なんて"技術"とは言わんと思われ

WANプロトコルの知識がちゃんとあれば後はコマンド打つだけ
Unix使いならわかるだろ？

#ただ、経験がないとやっぱトラブルシュートができないんだけどね

39 ：名無しさん＠お腹いっぱい。 ：01/10/08 14:09

>>19
> いや、実はUNIXのメーカーに中途で入ったんですが、
> 皆あまりにもネットワークの事を知らないので驚いた次第です。はい。

どんな所に入ったかのは知らないけど、
プログラミングやUNIXのことあんまり知らない奴もいるだろ。

逆にrouterやHUB作っていたり、
高いlayer 3 swithing HUBを扱っている商社の技術部でも、
滅茶苦茶狭い範囲しかネットワークのこと知らない奴もいるしな。

こういうこと言い出すと切りがない。

>>1はkernelの構造とかhardware architectureとか分かるの?

40 ：1ですが、 ：01/10/08 15:06

いや、別に何も非難しているわけではないんですよ。
現に私自身はUnixに関しては素人のようなものですから。

ただ、SIまがいのこともやっているんでそんなときで
サーバにからんでネットワークの話も出てくることって
多くないですか？

でも私のまわりの人たちってネットワークの話が出てくると
逃げていちゃうんですよね。

というわけで、他はどうなのか聞いてみたかったんです。

41 ：名無しさん＠お腹いっぱい。 ：01/10/08 15:23

>>40
> でも私のまわりの人たちってネットワークの話が出てくると
> 逃げていちゃうんですよね。

やっぱ、networkは抽象的でとっつきにくいだろ。(だから面白いんだが…)

> ただ、SIまがいのこともやっているんでそんなときで
> サーバにからんでネットワークの話も出てくることって
> 多くないですか？

〜な時に、やらない理由にはならんがな。

42 ：名無しさん＠お腹いっぱい。 ：01/10/08 15:24

あ、俺も周りは>>21なんで特殊かも…

43 ：名無しさん＠お腹いっぱい。 ：01/10/08 16:19

>>40
UNIX 屋って言ってもさまざまで、俺みたいに中小向けしかやってない奴だと
ネットワーク機器は高価で、高額商談に巡り合わない限り経験できない。
特に本格的なルータや大規模スイッチはなかなか扱う機会に巡り合わない。メルコですら高級品扱いだよ。
いざという時に備えて本は読んでるし、なんとかなるとは思うのだが、
実機に触った事が無いというのは致命的だから逃げてくのでは?
やっぱ俺も金出して訓練受けないとレベルアップ出来んな。

44 ：名無しさん＠お腹いっぱい。 ：01/10/08 18:01

>>43
今度俺、BGP4触らなければならなさそう。
今まで全部staticで逃げてきただけにびびりまくり。
ちょっと疑問なんだけど他ではRIPやOSPF使っているんですかね？
うちは、defalut gatewayだけDHCPで送って後はgatewayで経路設定してる。
broadcastでびゅんびゅん余計なパケット飛ばされると腹立たしいんですよね。

45 ：にょ ：01/10/08 18:03

BGPなんてプロバイダでもなければ，触ることもない気がするが．
ただ，BGPはむずかしくない．ただヘボすると影響がでかい．

46 ：44 ：01/10/08 18:26

>>44
IP/VPNとかで、static or BGPと聞かれて上司が気に入ってしまったみたい。
ついでに経路の多重化をしようなんて考えだして。。
metricで設定してもいいんですがちょっとかっこよくやってみたいって気
もするんです。
難しくないという言葉を聞いて安心したよ。ありがとう。

47 ：名無しさん＠お腹いっぱい。 ：01/10/08 18:56

関係ないところは見なくていいという発想からOSIモデルができたんだよな。

48 ：名無しさん＠お腹いっぱい。 ：01/10/08 19:07

BGPって RIPとかとはかなりニッチがちがうよねえ。
そういって BGPを知らない言い訳にしてきたんだけど..ダメ?

49 ：ななし ：01/10/08 19:43

情報システム板でやれヴォケ

>>1

50 ：こんな知識ならありますが　何か？ ：01/10/08 20:30

http://cocoa.2ch.net/test/read.cgi/unix/970401931/l50

51 ：名無しさん＠お腹いっぱい。 ：01/10/08 22:03

>>44
>ついでに経路の多重化をしようなんて考えだして。。
>metricで設定してもいいんですが
バックボーン経路をスタティックで2重化するのは不可能だよ
出てくパケットだけ制御しても、インターネットからの戻りパケットはどうするつもり

スタティックじゃ障害時にいちいち設定変えなきゃならないでしょ
普通の中規模異常のネットワークは大抵OSPFだよ(CiscoマンセーだとEIGRPだけど)
ブロードキャストをびゅんびゅん飛ばすのはRIPだけ
OSPFやBGPはマルチキャストの更新確認パケットだけだから、
対したオーバーヘッドにはならないよ

52 ：44 ：01/10/08 22:35

>バックボーン経路をスタティックで2重化するのは不可能だよ
>出てくパケットだけ制御しても、インターネットからの戻りパケットはどうするつもり
そうか、無理ですね。
やっぱりなんらかの動的ルーティングが必要ですね。
rip以外を検討してみます。いろいろご助言ありがとうございました。

53 ：名無しさん＠お腹いっぱい。 ：01/10/08 23:15

ネットワーク系の話してる人ってカッコよく見える。
我ながら技術信仰だ。

54 ：むぅ ：01/10/09 00:32

>> 43
RIP,OSPF,BGPを使ってみたいというだけならzebraを使えば。
PCにNIC4枚さしてやるもよし。OSがFreeBSDやLinuxならVMwareで仮想マシン
をあげて(もちろんHost onlyで)やるという手もある。

55 ：えええろ ：01/10/09 00:34

http://www.himawari.sakura.ne.jp/%7Eloveseat/Adu/index.html

56 ：名無しさん＠お腹いっぱい。 ：01/10/13 22:56

>>53
ネットワーク屋から見れば、奇怪な言語を操るUnix屋さんの方がかっこよく見えるよ
(rubyって何なんだ？)
どっちもお互いの基礎はできるだろうけど、突っ込んだ部分になるとね、、
やっぱお互い棲むレイヤが違うからなんだろうな

ネットワーク屋が作ったサーバはただ動くってだけって感じだし、
Unix屋が作ったネットワークはただつながるだけって感じだもんな

57 ：sage ：01/10/13 23:15

なんかﾏﾀｰﾘで良い感じのスレだね

というわけでageてみる

58 ：名無しさん＠お腹いっぱい。 ：01/10/13 23:18

>>56
> ネットワーク屋が作ったサーバはただ動くってだけって感じだし、
> Unix屋が作ったネットワークはただつながるだけって感じだもんな

ただだけ余計だよ　(藁

59 ：名無しさん＠お腹いっぱい。 ：01/10/13 23:23

シスコのマニュアル積み上げると子供の背丈ぐらいにはなるよね。
全部掌握しているほうが不思議だと思う。

60 ：名無しさん＠お腹いっぱい。 ：01/10/13 23:50

>>27
そういう意味で、p2pなんかのアプリはDNSなんかに依存しない
アプリとして期待できるかもね。XMLの人はURIにべったりみたい
だからあまり考えないんだろうけど。
まぁこれから自分でなんか作ってみたら過剰な期待だったということに
なるのかもしれないけど。

61 ：名無しさん＠お腹いっぱい。 ：01/10/13 23:58

XMLに関して補足。XMLは別にプロトコルや実装と関係ないけど、
w3cでまとめられている仕様にはURIの存在をあまりにも自明視しすぎて
いるような気がしたから言ってみただけ。悪意はありません。

62 ：名無しさん＠お腹いっぱい。 ：01/10/14 00:16

遠隔地のweb サーバの調子がおかしいとき、とりあえず・・・

初級技術者
% netscape

中級技術者
% telnet -l 80 www.xxx.xxx.xxx.jp
GET / HTTP/1.0

オタク
% cat > acc.c　; gcc -o acc acc.c -lsocket ; ./acc
#include <stdio.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
...
---<以下略>---

63 ：UNIX系software屋 ：01/10/14 00:31

うちは、遠隔地のない500台、20subnetくらいの規模だけど、OSPF + RIP2だな。
backbone付近は2重化topologyが生きるようにOSPFで、
末端のsubnetでは、routerがRIP2でbroadcast。
馬鹿なlayer 3 switchはおかしくなる事があるのでstatic。

RIP1はsubnet mask理解しないから気を付けてねー。

このくらいは、network屋じゃなくても設計できる人間の常識の範疇だと思うけど、
layer 2をprotocol analyserで解析してfirmwareのbugを追求、
という領域になるともーお手上げだ。

しかし、OSPFにしてもBGP4にしてもRFC長過ぎ…

read.cgi ver5.26+ (01/10/21-)