ネットワーク備忘録

アラフォーエンジニアのネットワーク系の備忘録。twitter:@deigo25374582

ECMPでの負荷分散（CEF）

cisco

CEFの整理

 

f:id:klock_3rd:20150311010155p:plain

上記構成で、ループバックIF＆Faの全てでOSPFを有効にすると、対向先のループバックIFへの経路はOSPFによるECMPとなる。
R1→loop0(1.1.1.1/32),loop1(1.1.1.2/32)

R2→loop0(2.2.2.1/32),loop1(2.2.2.2/32)

＜R1のルーティングテーブル＞

R1#sho ip route ospf
2.0.0.0/32 is subnetted, 2 subnets
O 2.2.2.2 [110/2] via 10.1.2.2, 00:19:14, FastEthernet0/1
　　　　 [110/2] via 10.1.1.2, 00:19:14, FastEthernet0/0
O 2.2.2.1 [110/2] via 10.1.2.2, 00:19:14, FastEthernet0/1
　　　　 [110/2] via 10.1.1.2, 00:19:14, FastEthernet0/0

R1→R2へPingを打った後、IFのカウンタを確認

R1#ping 2.2.2.2 source 1.1.1.1 repeat 50
R1#sho int stats
FastEthernet0/0
　Switching path Pkts In Chars In Pkts Out Chars Out
　Processor 　　52 　　　5888 　54 　　　308
　Route cache 　0 　　　　0 　　0 　　　0
　Total 　　　　52 　　　5888 　54　　　308
FastEthernet0/1
　Switching path Pkts In Chars In Pkts Out Chars Out
　Processor 　　2 　　　188 　　4 　　6265
　Route cache 　0 　　　0 　　　0 　　　0
　Total 　　　　2 　　　188 　　4 　　6265

→Fa0/1に偏っているのがわかる。

show ip routeの結果では、等コストロードバランスになっているが送出IFがFa1に偏っているのはCEFの機能によるもの。

R1#show ip cef exact-route 1.1.1.1 2.2.2.2
1.1.1.1 -> 2.2.2.2 : FastEthernet0/0 (next hop 10.1.1.2)

送信元が1.1.1.1、あて先2.2.2.2の場合はFa0/0から送出することがわかる。
実際、Pingコマンド実施時、loop0(1.1.1.1)を指定して実施している。

では、この状態であて先を2.2.2.1に変えてみる。
R1#show ip cef exact-route 1.1.1.1 2.2.2.1
1.1.1.1 -> 2.2.2.1 : FastEthernet0/1 (next hop 10.1.2.2)
→おそらくFa0/1側のカウンタがUpすると想定

R1#ping 2.2.2.1 source 1.1.1.1 repeat 50
R1#sho int stats
FastEthernet0/0
　Switching path Pkts In Chars In Pkts Out Chars Out
　Processor 　　　2 　　　188 　　4 　　　308
　Route cache 　　0 　　　0 　　　0 　　　0
　Total 　　　　　2 　　　188 　　4 　　　308
FastEthernet0/1
　Switching path Pkts In Chars In Pkts Out Chars Out
　Processor 　　　51 　　5794 　　54 　　6008
　Route cache 　　0 　　　0 　　　0 　　　0
　Total 　　　　　51 　　5794 　　54 　　6008
→想定どおり


CEFでの負荷分散は、フロー単位ではなく、パケット単位でも分散可能だけどその場合はパケット追い越しが発生する可能性もあるため、今回は省略


Proxy ARP

cisco

たまに、他のベンダが構築したCiscoをみると、Proxy ARPが有効なままの機器があったりするけど、個人的にはあんまりProxy ARPは使いたくない。

 以下で確認

f:id:klock_3rd:20150222184234p:plain

上記構成で検証

PCのIPが 「/24のネットマスク ＆ デフォルトGW未設定」
R1のPC側IF()が「10.1.1.127/25」
R2のloop0を「10.1.1.129/25」
R1&R2の全IFでOSPFを有効

⇒PC側のサブネットマスクの設定誤り


本来であれば、10.1.1.129は上図からもわかるとおり、PCとは別セグメントにいるため、デフォルトGWを設定していないPCからは通信は出来ないはずなんだけど、Proxy ARPの設定が有効な場合はこの場合でも通信できてしまう。

 

＜PCのipconfig結果＞
接続固有の DNS サフィックス . . . :
IPv4 アドレス . . . . . . . . . . : 10.1.1.1
サブネット マスク . . . . . . . . : 255.255.255.0
デフォルト ゲートウェイ . . . . . :


＜Ping結果＞
10.1.1.129 に ping を送信しています 32 バイトのデータ:
10.1.1.129 からの応答: バイト数 =32 時間 =1ms TTL=254
10.1.1.129 からの応答: バイト数 =32 時間 =1ms TTL=254

＜trace結果＞
10.1.1.129 へのルートをトレースしています。経由するホップ数は最大 30 です

1 <1 ms <1 ms <1 ms 10.1.1.126
2 1 ms <1 ms <1 ms 10.1.1.129

 

これは、R1のIFでProxy ARPが有効になっていることが原因

R1のPC側IF（Fa0）でProxy ARPを無効にしてから、再度Ping確認

 

interface FastEthernet1
ip address 10.1.1.126 255.255.255.128
no ip proxy-arp
ip ospf 1 area 0
duplex auto
speed auto
end

 

＜Ping結果＞
10.1.1.129 に ping を送信しています 32 バイトのデータ:
10.1.1.1 からの応答: 宛先ホストに到達できません。
10.1.1.1 からの応答: 宛先ホストに到達できません。

 

設計にもよるだろうけど、Proxy ARPは上記のようなケースがあったりするから、あんまり個人的には使いたくない機能・・・・というかデフォルトで無効になってて欲しい。

 

EIGRPのスプリットホライズン

cisco

OSPFと比べ、EIGRPは仕事で触る事が少ないのでメモ

EIGRPはsplit horizonに注意

f:id:klock_3rd:20150220232655p:plain

EIGRPはRIP同様ディスタンスベクタ型プロトコルなのでMBMAネットワークでは、スプリットホライズンに注意

上記構成にてハブ接続セグメントを192.168.1.0/24とし、それぞれ下記IPを振りEIGRPを有効化

R2→vlan1 192.168.1.1/24
R3→fa0 192.168.1.3/24
R4→fa0 192.168.1.4/24

（フレームリレーのネットワーク環境を用意できなかった為、EIGRPのneighborコマンドで代用）

それぞれのEIGRPのConfigは以下のとおり

＜R2＞
router eigrp 1
network 2.2.2.2 0.0.0.0
network 192.168.1.0
neighbor 192.168.1.3 Vlan1
neighbor 192.168.1.4 Vlan1

 

＜R3＞
router eigrp 1
network 3.3.3.3 0.0.0.0
network 192.168.1.0
neighbor 192.168.1.2 FastEthernet0

 

＜R4＞
router eigrp 1
network 4.4.4.4 0.0.0.0
network 192.168.1.0
neighbor 192.168.1.2 FastEthernet0

 

上記の設定投入後、R3、R4でのsho ip routeにて、それぞれR4、R3のloop0のアドレスが広告されているか確認

＜R3＞
2.0.0.0/32 is subnetted, 1 subnets

D 2.2.2.2 [90/156160] via 192.168.1.2, 00:32:20, FastEthernet0

＜R4＞
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/156160] via 192.168.1.2, 00:32:43, FastEthernet0

 

いずれも、R2の経路しか知らない

 

ここでR2にてスプリットホライズンを無効化

 

＜R2＞

interface Vlan1
no ip split-horizon eigrp 1
end

 

その後、再びR3,R4のshow ip route結果

＜R3＞
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/156160] via 192.168.1.2, 00:34:34, FastEthernet0
4.0.0.0/32 is subnetted, 1 subnets
D 4.4.4.4 [90/158720] via 192.168.1.2, 00:00:44, FastEthernet0

 

＜R4＞
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/156160] via 192.168.1.2, 00:35:53, FastEthernet0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/158720] via 192.168.1.2, 00:01:07, FastEthernet0

 

ちゃんと、R3,R4のloop0のアドレスを受信している

 

EIGRPはOSPFと比べると仕事で触る機会が少ないから、注意だなぁ

EIGRPの確認

cisco

EIGRPでちょっと気になったので確認

 

EIGRPはASが異なれば、ネイバーを張れないので経路交換はできないはず。
ただ、EIGRPの境界となるルータのIFが二つASに属する場合はどうなるのか気になったので検証。

f:id:klock_3rd:20150216225934p:plain

上記構成で、R2のルータでR1向き側のIFをAS2側のEIGRPの設定にも投入
　単純にネイバーが異なれば経路のやり取りはできないはずだけど、何となく出来そうな気がしなくもない。

R2のEIGRPの設定
router eigrp 1
network 192.168.1.0
network 192.168.3.0
router eigrp 2
network 192.168.3.0

上記を入れた後、R3側で、10.1.1.0の経路があるか確認
R3>show ip route | inc 10.
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.100.100.0/24 is directly connected, Loopback0
L 10.100.100.1/32 is directly connected, Loopback0

やっぱ経路は受け取れず。　知識が曖昧だったなぁ

 

 

MSSの設定

cisco

割と忘れがちなので、メモ

f:id:klock_3rd:20150203224310p:plain

【ip tcp adjust-mss】
TCP通信は最初に３wayハンドシェイクでコネクションを確立する。
その3wayハンドシェイク時にデータ長（MSS）のやり取りも行う。

PCは一般的にMTU 1500byteだから、3wayハンドシェイク時にはMSSを1460byteとして通知する。

「ip tcp adjust-mss」は、その3wayハンドシェイク時のmss長を変更する。

 

以下は、Ciscoルータで上記環境を検証

１、ルータにMSSの設定なし
PC-A → PC-BにTCP接続（今回はFTP）際のPC-B側のパケットキャプチャ結果

～～抜粋～～

Options: (20 bytes), Maximum segment size, No-Operation (NOP), Window scale, SACK permitted, Timestamps
Maximum segment size: 1460 bytes
　→MTU1500byeからIPヘッダ&TCPヘッダの40byteを引いた値「1460byte」になってる

 

２、ルータにMSSの設定投入

　a) PC-A側のIFに対し、「ip tcp adjust-mss 1400」を投入
　b) PC-A → PC-Bに1同様の方法でのキャプチャ結果

～～抜粋～～

Options: (20 bytes), Maximum segment size, SACK permitted, Timestamps, No-Operation (NOP), Window scale
Maximum segment size: 1400 bytes 

　→「ip tcp adjust-mss 1400」で投入した1400byteに変更されている。

 

これ、Ciscoのshow系コマンドでも確認できないかなぁ・・・

 

 

LACP

cisco

LACPで対向機器と接続する際、ネゴシエーション時はSwitchのシステムIDを使用する。

 

f:id:klock_3rd:20150101051132p:plain

　普段利用だと余り意識する必要はないけど、対向先CiscoのStack構成を組んだ機器とLACP組む際はStack側の設定に注意。

Net-SNMPへの拡張MIBインポート

Linux

Net-SNMPに拡張MIBを登録する場合はMIBファイルをインポートした上で、snmp.confも設定しないといけないんだけど、snmp.confを毎度忘れてしまうのでメモ。

"2016/09 一部修正"

 

今回は以下の環境で確認

CentOS release 6.5 (Final)

net-snmp-5.5-50.el6_6.1.i686
net-snmp-libs-5.5-50.el6_6.1.i686
net-snmp-utils-5.5-50.el6_6.1.i686

CISCOのMIBを例にインポートしてみる。
# mibファイルは保持済

 

MIBをインポートしない状態で上記サーバにて

snmptranslate -Tpのコマンド結果を確認すると、

Private(4)の enterprises(1) 配下に cisco(9) は存在しない。

 

MIBファイルを下記フォルダ配下に格納すると仮定

/usr/share/snmp/mibs/auto/mibs/v2

この場合snmp.confファイルを下記に作成

/etc/snmp/snmp.conf

snmp.confファイルにはMIB格納ディレクトリを定義する

#cat /etc/snmp/snmp/snmp.conf
MIBDIRS /usr/share/snmp/mibs:/usr/share/snmp/mibs/auto/mibs/v2
MIBS all

 

その後、再度snmptranslate -Tpで確認すると、

Private(4)の enterprises(1) 配下に cisco(9) が確認できるようになる。