EIGRPの確認
EIGRPでちょっと気になったので確認
EIGRPはASが異なれば、ネイバーを張れないので経路交換はできないはず。
ただ、EIGRPの境界となるルータのIFが二つASに属する場合はどうなるのか気になったので検証。
上記構成で、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の設定
割と忘れがちなので、メモ
【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系コマンドでも確認できないかなぁ・・・
Net-SNMPへの拡張MIBインポート
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ファイルを下記に作成
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) が確認できるようになる。
LISP検証
仕事で使うかもしれないので簡易検証
構成
[RT-B]-------(10.0.1.0/30)-------[RT-A]-------(10.0.2.0/30)-------[RT-C]
.2 .1 .1 .2
# 構成図のPPTを作るのを忘れたので、上で代用
上記の構成でのconfig
[RT-A]-------------------------------------------
interface FastEthernet0
ip address 10.0.1.1 255.255.255.252
!
interface FastEthernet1
ip address 10.0.2.1 255.255.255.252
----------------------------------------------------
[RT-B]-------------------------------------------
interface FastEthernet0
ip address 10.0.1.2 255.255.255.252
!
interface Loopback0
ip address 192.168.1.1 255.255.255.255
!
ip route 0.0.0.0 0.0.0.0 10.0.1.1
----------------------------------------------------
[RT-C]-------------------------------------------
interface FastEthernet0
ip address 10.0.2.2 255.255.255.252
!
interface Loopback0
ip address 192.168.2.1 255.255.255.255
!
ip route 0.0.0.0 0.0.0.0 10.0.2.1
----------------------------------------------------
この状態だと、RT-B、RT-C上で作成したloop0への経路がRT-Aのルーティングテーブルには存在しないため、RT-B〜RT-Cのloop0同士の通信は出来ない。
これを、LISPを使用して通信できるようにする。
【LISP関連Config】
[RT-A]-------------------------------------------
vrf definition lisp
!
address-family ipv4
exit-address-family
!
router lisp
site sitea
description sitea
authentication-key sitea
eid-prefix 192.168.1.0/24
!
site siteb
description siteb
authentication-key siteb
eid-prefix 192.168.2.0/2
!
ipv4 map-server
ipv4 map-resolver
ipv4 alt-vrf lisp
!
----------------------------------------------------
[RT-B]-------------------------------------------
router lisp
database-mapping 192.168.1.0/24 10.0.1.2 priority 1 weight 100
ipv4 itr map-resolver 10.0.1.1
ipv4 itr
ipv4 etr map-server 10.0.1.1 key sitea
ipv4 etr
----------------------------------------------------
[RT-C]-------------------------------------------
router lisp
database-mapping 192.168.2.0/24 10.0.2.2 priority 1 weight 100
ipv4 itr map-resolver 10.0.2.1
ipv4 itr
ipv4 etr map-server 10.0.2.1 key siteb
ipv4 etr
----------------------------------------------------
【確認】
[RT-A]-------------------------------------------
#sho lisp site
LISP Site Registration Information
Site Name Last Up Who Last EID Prefix
Register Registered
sitea 00:00:51 yes 10.0.1.2 192.168.1.0/24
siteb 00:00:23 yes 10.0.2.2 192.168.2.0/24
----------------------------------------------------
RT-CからのPing
#ping 192.168.1.1 source 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
考え方的にはDNSにちょっと近いような印象。
ただ、LISPで使われる用語の意味や仕組みがまだ自分の中で消化できていないので要勉強
OSPF SPF Delay
上記でRT1、RT2、RT3でOSPFを構成。(各ルータのHello-intervalは1秒に設定)
この状態でRT3からRT1へPingを打ちながらRT1〜RT2のリンクを抜線
192.168.1.1→RT上のLoop0
RT3#ping 192.168.1.1 repeat 10000 timeout 1
Success rate is 99 percent (9992/10000), round-trip min/avg/max = 1/1/24 ms
→８パケロス
断時間を短くするため、全ルータのSPF計算の待時間を１秒に変更
router ospf 1
timers throttle spf 1000 10000 10000
そして、Pingで確認
RT3#ping 192.168.1.1 repeat 10000 timeout 1
Success rate is 99 percent (9995/10000), round-trip min/avg/max = 1/1/24 ms
→5パケロス
試しに、10秒に変更した場合は・・・
router ospf 1
timers throttle spf 10000 10000 10000
RT3#ping 192.168.1.1 repeat 10000 timeout 1
Success rate is 99 percent (9986/10000), round-trip min/avg/max = 1/1/20 ms
→14パケロス
MTU長不一致でOSPFのネイバーが張れない
他システムと接続する際にOSPFを使う事はあんまりないので、他システム担当者と会話する際に意識していないと忘れてしまうのでメモ
以下で検証（左、RA 右,RB）
まずは、普通にOSPFで隣接関係を構築
RA#sho ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 1 FULL/DR 00:00:03 192.168.1.1 FastEthernet0
→まぁ、普通
今度は↑図の左のルータのMTU長を1000に変更&OSPFプロセス再起動
RA(config-if)#ip mtu 1000
RA#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
・・・・再起動後のOSPFの状態は・・・
*Oct 18 13:30:38.439: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
*Oct 18 13:31:38.439: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0 from DOWN to DOWN, Neighbor Down: Ignore timer expired
#sho ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 1 EXSTART/BDR 00:00:03 192.168.1.1 FastEthernet0
→OSPFのStateがEXSTARTのままFULLにならない
解決策は２つ
・MTU長を揃える
・ip ospf mtu-ignore コマンドを使う
<ip ospf mtu-ignore の場合>
RA(config-if)#ip ospf mtu-ignore
*Oct 18 13:39:21.107: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0 from LOADING to FULL, Loading Done
→コマンド投入後にFULLに変わった
RA#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 1 FULL/BDR 00:00:03 192.168.1.1 FastEthernet0
おわり
