マルチホームの非トランジットでのBGP

今回BGPでマルチホーム接続をすることになったので、メモ

構成はこんな感じで、今回はR1を自ASとする。

R1→AS1、R2→AS2、R３→AS3、R4→AS4

何も考えずに適当にBGPのConfigを作るとたぶんこんな感じ。

R1#sho run | sec router bgp
router bgp 1
no synchronization
bgp log-neighbor-changes
network 10.1.1.1 mask 255.255.255.255
neighbor 192.168.1.254 remote-as 2
neighbor 192.168.1.254 soft-reconfiguration inbound
neighbor 192.168.2.254 remote-as 3
neighbor 192.168.2.254 soft-reconfiguration inbound
no auto-summary
R1#
 

そうすると、当然R2のルータにはR4のloop0への経路が分かる。 

R2#sho ip bgp

Network 　　　　Next Hop 　Metric LocPrf Weight Path
*> 10.1.1.1/32 　192.168.1.1 　0 　　　　　　　0 　1 i
*> 10.1.2.1/32 　192.168.1.1 　　　　　　　　　0 　1 3 4 i
R2#

今回はR1はマルチホーム接続だけど、非トランジットにしたいからR4の経路は流したくない。　なので、AS-pathを使う。

router bgp 1

no synchronization
bgp log-neighbor-changes
network 10.1.1.1 mask 255.255.255.255
neighbor 192.168.1.254 remote-as 2
neighbor 192.168.1.254 soft-reconfiguration inbound
neighbor 192.168.1.254 filter-list 1 out
neighbor 192.168.2.254 remote-as 3
neighbor 192.168.2.254 soft-reconfiguration inbound
neighbor 192.168.2.254 filter-list 1 out
no auto-summary
!
ip as-path access-list 1 permit ^$

再び、R2での確認

 R2#show ip bgp

Network 　　　Next Hop 　　Metric LocPrf Weight 　Path

*> 10.1.1.1/32 192.168.1.1 　　0 　　　　　　　0 　　1 i
R2#

とりあえず確認おわり

・・・と思ったけど、prefix-listの方が楽な気がした。

router bgp 1
no synchronization
bgp log-neighbor-changes
network 10.1.1.1 mask 255.255.255.255
neighbor 192.168.1.254 remote-as 2
neighbor 192.168.1.254 soft-reconfiguration inbound
neighbor 192.168.1.254 prefix-list origin out
neighbor 192.168.2.254 remote-as 3
neighbor 192.168.2.254 soft-reconfiguration inbound
neighbor 192.168.2.254 prefix-list origin out
no auto-summary
!
ip prefix-list origin seq 5 permit 10.1.1.1/32

R2の結果は同じなので、略

正規表現に抵抗なければ気にはならないだろうけど、マルチホームで非トランジットってだけなら、逆にprefix-listの方が分かりやすい気がするな。

とりあえずおわり

続・NAT-PT検証

とりあえず、前回の検証ではIPv6⇔IPv4のアドレス変換は確認できた。

前回の内容は以下。

klock-3rd.hatenablog.com

今度は、R1配下に192.168.1.0/24のセグメントを用意して、そのアドレスをNAT-PTさせてみる。

R1のFa1に192.168.1.0/24のセグメントを用意し、そこにぶら下がるPCをR2でのNAT-PT対象とする。　当然、R2は192.168.1.0/24の経路も知らないため、Staticルートも追加。

結果は前回同様疎通は確認できた。

検証おわり 

CiscoのIPv6⇔IPv4のNAT検証 NAT-PT

普通のIPv4でのNATは経験あるけど、IPv6⇔IPv4のNATについては未経験だったのでちょっと勉強

＜構成＞

　　　　　

必要そうなConfigのみ記載

なお、機器は全てCisco 1812J

 ＜R1＞

 interface FastEthernet0
ip address 192.168.30.9 255.255.255.0
duplex auto
speed auto

ip route 0.0.0.0 0.0.0.0 192.168.30.10

 ＜R2＞

no ip cef
ipv6 unicast-routing
no ipv6 cef
!

interface FastEthernet0
ip address 192.168.30.10 255.255.255.0
duplex auto
speed auto
ipv6 enable
ipv6 nat
!
interface FastEthernet1
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:3002::9/64
ipv6 enable
!

ipv6 route ::/0 2001:DB8:3002::10
ipv6 nat v4v6 source 192.168.30.9 2000::960B:202
ipv6 nat v6v4 source 3001:11:0:1::1 150.11.3.1
ipv6 nat prefix 2000::/96

＜R3＞

interface Loopback0
no ip address
ipv6 address 3001:11:0:1::1/64 
!
interface FastEthernet1

no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:3002::10/64

ipv6 route ::/0 2001:DB8:3002::9

この状態で、R1のFa0から、150.11.3.1（R3のLoopback 0）へPingを実行

R1#ping 150.11.3.1 source fa0 repeat 50

→OK

今度は逆にR3のloopbakから、2000::960B:202（R1のFa0）へPingを実行

R3#ping 2000::960B:202 source loop0 repeat 50

→OK

注意点としてはNAT－PTを実装するルータではCEFを無効化する必要がある。

でないと、パケットDropが発生するっぽい。

※R2で「ip cef 」、「ipv6 cef」を有効化した場合

R3#ping 2000::960B:202 source loop0 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 2000::960B:202, timeout is 2 seconds:
Packet sent with a source address of 3001:11:0:1::1
!.!.!.!.!.
Success rate is 50 percent (5/10), round-trip min/avg/max = 0/0/4 ms

R1#ping 150.11.3.1 source fa0 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 150.11.3.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.9
!.!.!.!.!.
Success rate is 50 percent (5/10), round-trip min/avg/max = 1/1/4 ms
R1#

2回に一回は応答がない状況。　調べると、VRFなどの使用も制限されちるっぽいのでNAT-PTを使う際は要注意

続・LVS検証（DSR）

前回の検証からちょっと追加で確認

↓が前回のやつ

klock-3rd.hatenablog.com

前回は、Web1、Web2にWRRで分散していたけど、以下の2点が気になった
１．普段はWeb1のみにアクセスさせ、Web1が死んだ時のみWeb2へアクセスさせる。

２．DSR方式でLeast Connectionしたらどういう風になるんだろ？

１．普段はWeb1のみにアクセスさせ、Web1が死んだ時のみWeb2へアクセスさせる。

Active/Standby方式をLVSでやる場合をちょっと調べてみた。
Big-IPとかだと、PriorityGroup機能、NetScalerだとBackupServer機能が↑に近い事を実現させられそうだけど、LVSではどうなんだろう・・・と

まず、単純にWeb2の重みを0にすればいいんじゃね？　という発想
ただし、この場合は、Web1が死ぬとWeb1＆Web2が0になるため、クライアントからのアクセスがエラーになる可能性大

web_servers.conf

virtual_server_group web_servers {
192.168.10.110 80
}

virtual_server group web_servers {
delay_loop 3
lvs_sched wrr
lvs_method DR
protocol TCP

real_server 192.168.10.103 80 {
weight 1
inhibit_on_failure
HTTP_GET {
url {
path /health_check.html
status_code 200
}
connect_port 80
connect_timeout 3
}
}
real_server 192.168.10.104 80 {
weight 0
inhibit_on_failure
HTTP_GET {
url {
path /health_check.html
status_code 200
}
connect_port 80
connect_timeout 3
}
}
}

 この状態でLVSの状態確認

[root@LVS1 ]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port              Forward Weight ActiveConn InActConn
TCP 192.168.10.110:80 wrr
-> 192.168.10.103:80 　　　　　Route     1         0                  9
-> 192.168.10.104:80 　　　　　Route     0         0                  0

これは想定どおり。　実際Weightを0にしたところには振り分けられず。
そして、「.103」のサーバのhttpdをstopして確認。

[root@LVS1 keepalived]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port 　　　　Forward Weight ActiveConn InActConn
TCP 192.168.10.110:80 wrr
-> 192.168.10.103:80 　　　　　Route 　　0 　　　0 　　　0
-> 192.168.10.104:80 　　　　　Route 　　0 　　　0 　　　0

この状態でWebでアクセスすると・・・・・やはりアクセスできない。
一応、前回と同様にCiscoのshow ip arpで確認したら、ARPテーブルにはVIPがいたから、やはりLVSでDropしてるっぽい。

そこで、sorryでやってみる。

web_servers.conf

virtual_server_group web_servers {
192.168.10.110 80
}

virtual_server group web_servers {
delay_loop 3
lvs_sched wrr
lvs_method DR
protocol TCP

sorry_server 192.168.10.104 80

real_server 192.168.10.103 80 {
weight 1
inhibit_on_failure
HTTP_GET {
url {
path /health_check.html
status_code 200
}
connect_port 80
connect_timeout 3
}
}
#real_server 192.168.10.104 80 {
#weight 1
#inhibit_on_failure
#HTTP_GET {
#url {
#path /health_check.html
#status_code 200
#}
#connect_port 80
#connect_timeout 3
#}
#}
}

この設定で、LVSの状態を確認

[root@LVS1 keepalived]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port　　　　　 Forward Weight ActiveConn InActConn
TCP 192.168.10.110:80 wrr
-> 192.168.10.103:80 　　　　　　Route 　1 　　　0 　　　　0

勿論、これだと「.103」にしかパケットは転送されない。
この状態もう一度「.103」のhttpdを落とす。

[root@LVS1 keepalived]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port 　　　　　Forward Weight ActiveConn InActConn
TCP 192.168.10.110:80 wrr
-> 192.168.10.103:80 　　　　　　Route 　0　　　 0 　　　　0
-> 192.168.10.104:80 　　　　　　Route　 1 　　　0 　　　　0

Sorry_serverで設定した項目が浮上してきた。
一応これだと、Active/Standbyチックな動きは出来る。
（ただ、Standby側についてはLVSでは監視していないことになる。）

２．DSR方式でLeast Connectionしたらどういう風になるんだろ？

F5や、CitrixでのLB構築がほとんどだったので、大体負荷分散方式といえばLeast Connectionだった。　ただし、これらアプライアンスはセッションを管理できたから実現できるけど、LVSのDSR方式だとサーバからの戻りのパケットがLVSを経由しないため、セッション管理は出来ないのではないか？という想定

そんなわけで、「lvs_sched lc」に変えて、別PCからWeb1の実IPアドレス宛てにHTTPアクセス（F5連打）しつつ、HTTPのVIPにアクセスしてみた。

[root@LVS1 keepalived]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port 　　　　Forward Weight ActiveConn InActConn
TCP 192.168.10.110:80 lc
-> 192.168.10.103:80 　　　　　Route 　　1 　　　0 　　　19
-> 192.168.10.104:80 　　　　　Route 　　1 　　　0 　　　20
[root@LVS1 keepalived]#

検証に作ったのは静的ページという点と、HTTPはコネクションを張りっぱなしというわけではないから、検証としては完璧ではないにしろ、VIPへのアクセスが均等に割り振られている事も考えると、DSR方式ではセッション管理は出来ていないような雰囲気。　

とりあえず検証おわり

LVS(DSR) 検証

LVS（DSR）の動作検証

LinuxでLVSでのロードバランサを構築することになったので、メモ
Keepalivedで冗長構成したLVSで、DSR（Direct Server Return）方式での負荷分散を構築

• 検証構成
  今回は、WebサーバをLVSで負荷分散させる。
  LVS1&2はKeepalivedで冗長構成を実施し、Webサーバ用VIPを保持
  PCからは「http://192.168.10.110/」へアクセス
  　※各サーバのIP(第4オクテットは下記図へ記載)

     

• 通信の流れ
  PCからLVS上のVIP（110）へアクセス
  →LVSにて負荷分散先のリアルサーバへ転送
  　→LVSから受信したリアルサーバは、LVSを経由することなく直接PCへ返送
  
• 各サーバの設定
  LVS1&2
  　1.keepalived.conf
  

  global_defs {
  notification_email {
  }
  router_id LVS_DEVEL
  }

  vrrp_instance VI_1 {
  state BACKUP
  interface eth0
  virtual_router_id 51
  priority 120
  advert_int 1
  authentication {
  auth_type PASS
  auth_pass 1111
  }
  virtual_ipaddress {
  192.168.10.110
  }
  }

  include web_servers.conf

   2.web_servers.conf
  

  virtual_server_group web_servers {
  192.168.10.110 80
  }

  virtual_server group web_servers {
  delay_loop 3
  lvs_sched wrr
  lvs_method DR
  protocol TCP

  real_server 192.168.10.103 80 {
  weight 1
  inhibit_on_failure
  HTTP_GET {
  url {
  path /health_check.html
  status_code 200
  }
  connect_port 80
  connect_timeout 3
  }
  }
  real_server 192.168.10.104 80 {
  weight 1
  inhibit_on_failure
  HTTP_GET {
  url {
  path /health_check.html
  status_code 200
  }
  connect_port 80
  connect_timeout 3
  }
  }
  }

   3.sysctl.conf　を編集してカーネルパラメータ変更

  # Controls IP packet forwarding
  net.ipv4.ip_forward = 1

   Web1&2
  1.loopbackインターフェースを作成し、VIP用のアドレスを割り当てる
  2.sysctl.conf　を編集してカーネルパラメータ変更

  net.ipv4.conf.all.arp_ignore = 1
  net.ipv4.conf.all.arp_announce = 2 

 
まぁ、LVSのDSRは割と良くある方式らしいので、他を調べればいいのがあるはず。

個人的にはこっからが本当に気になる点
自分が気になったのはルータのARPテーブルがどうなっているかという点。

１、KeepalivedのVRRPパケットは仮想MAC？
２、リアルサーバのループバックIPはARPテーブルに載るのか？

そんなわけで、ルータをCiscoで確認
Router#sh ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.10.110 30 000c.293e.???? ARPA Vlan10
→これは、LVS1のMACアドレス

どうやら、KeepalivedのVRRPパケットはCiscoのVRRPとはちょっと違い、仮想MACを作らない模様。　となると、Keepalivedでの切り替わりはGARPを送出する事で代用しているっぽい。

IPsecトンネル間でのダイナミックルーティング（IPsec VTI）

IPsecトンネル間はユニキャスト通信しか通さないためダイナミックルーティングを使う場合は、GRE over IPsecでGREトンネルを必ず使うと思ってたけどそれ以外の方法でも出来ると知ったのでメモ

構成は上記ケースで検証（1812J）

まずは、GRE over IPsecの場合のConfig
#R1&R2のループバックアドレスのセグメントの広告で確認

R1
fa0→10.1.1.1/24
tun0→172.16.1.1/24
loop0→192.168.1.1/24

R2

fa0→10.1.1.2/24
tun0→172.16.1.2/24
loop0→192.168.2.1/24

＜R1＞
crypto isakmp policy 1
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.1.2
!
!
crypto ipsec transform-set TRANSFORM esp-des esp-sha-hmac
!
crypto map MAP 1 ipsec-isakmp
set peer 10.1.1.2
set transform-set TRANSFORM
match address 100!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
!
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
ip ospf 1 area 0
tunnel source FastEthernet0
tunnel destination 10.1.1.2
crypto map MAP
!
interface FastEthernet0
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
crypto map MAP
!
access-list 100 permit gre host 10.1.1.1 host 10.1.1.2

＜R2＞ crypto isakmp policy 1
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.1.1
!
!
crypto ipsec transform-set TRANSFORM esp-des esp-sha-hmac
!
crypto map MAP 1 ipsec-isakmp
set peer 10.1.1.1
set transform-set TRANSFORM
match address 100
!
interface Loopback0
ip address 192.168.2.1 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
!
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
ip ospf 1 area 0
tunnel source FastEthernet0
tunnel destination 10.1.1.1
crypto map MAP
!
interface FastEthernet0
ip address 10.1.1.2 255.255.255.0
duplex auto
speed auto
crypto map MAP
!
access-list 100 permit gre host 10.1.1.2 host 10.1.1.1

 ↑でGRE over IPsecのトンネルを張りOSPFの経路がやり取りされる。
これはWebで調べれば色々見つかる

IPsec VTIを使う場合
#R1&R2のループバックアドレスのセグメントで広告を確認

R1
fa0→10.1.1.1/24
tun0→172.16.1.1/24
loop1→192.168.1.1/24
R2
fa0→10.1.1.2/24
tun0→172.16.1.2/24
loop1→192.168.2.1/24

＜R1＞
crypto isakmp policy 1
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.1.2
!
!
crypto ipsec transform-set TRANSFORM esp-des esp-sha-hmac
!
crypto ipsec profile VTI
set transform-set TRANSFORM
!
interface Loopback1
ip address 192.168.1.1 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
!
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
ip ospf 1 area 0
tunnel source FastEthernet0
tunnel mode ipsec ipv4
tunnel destination 10.1.1.2
tunnel protection ipsec profile VTI
!
interface FastEthernet0
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 Tunnel0

＜R2＞
!
crypto isakmp policy 1
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.1.1
!
!
crypto ipsec transform-set TRANSFORM esp-des esp-sha-hmac
!
crypto ipsec profile VTI
set transform-set TRANSFORM
!
interface Loopback1
ip address 192.168.2.1 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
!
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
ip ospf 1 area 0
tunnel source FastEthernet0
tunnel mode ipsec ipv4
tunnel destination 10.1.1.1
tunnel protection ipsec profile VTI
!
interface FastEthernet0
ip address 10.1.1.2 255.255.255.0
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 Tunnel0

 確認

R1>show ip ospf neighbor

Neighbor ID 　Pri　 State 　　Dead Time 　　Address 　　Interface
172.16.1.2 　　0 　FULL/ - 　　00:00:37 　　172.16.1.2 　Tunnel0
→ちゃんとネイバーを認識できてる。

R1>sho ip route ospf

O     192.168.2.0/24 [110/1001] via 172.16.1.2, 01:35:20, Tunnel0

→R2のLoop1のアドレスを受理している。

IPsec VTIのConfigが個人的にはとっつきやすいかなぁ・・・
とはいえ、GRE over IPSecも必須だろうけど。

Catalyst QoS（cos）

備忘

PC1-----(fa0/24)3550(fa0/23)-----PC2

上記、構成で3550のPC1&2を収容しているポートのConfigは以下の状態

interface FastEthernet0/23
switchport trunk encapsulation dot1q
switchport mode trunk
end

interface FastEthernet0/24
switchport trunk encapsulation dot1q
switchport mode trunk
end

この状態で、PC1から「cos=6」の値のパケットを送出し、PC2でキャプチャしてみた結果は以下の通り
＜Wireshark抜粋＞
110. .... .... .... = Priority: Voice, < 10ms latency and jitter (6)
# cosが「6」のままで、PC2で受信している。

ここで、QoSを有効化し、再度パケットを送出

Switch(config)#mls qos

＜Wireshark抜粋＞
000. .... .... .... = Priority: Best Effort (default) (0)
# cosが「0」に書き換わり、PC2で受信している。

fa0/24のIFにて、cosを信頼する

Switch(config)#int fa0/24
Switch(config-if)#mls qos trust cos
＜Wireshark抜粋＞
110. .... .... .... = Priority: Voice, < 10ms latency and jitter (6)
# cosが「6」のままで、PC2で受信している。

fa0/24のIFにて、IP Precedenceを信頼する
Switch(config)#int fa0/24
Switch(config-if)# mls qos trust ip-precedence
＜Wireshark抜粋＞
000. .... .... .... = Priority: Best Effort (default) (0)
# cosが「0」に書き換わり、PC2で受信している。
# 因みに、IP PrecedenceをTrust状態で、「mls qos cos 3」等でcosの書き換えを
# 行っても同様の結果

今回はこれまで