VRFでのローカルアプリケーションバインディング

VRFでのローカルアプリケーションバインディング

loLinuxには、デフォルトでIPアドレスを127.0.0.1/8ローカルアプリケーションにバインドできるループバックインターフェースがあります。

VRF内のローカルアプリケーションをこのループバックインターフェイスにバインドすることはできません。たとえば、次のようになります。

ip link add vrf100 type vrf table 100
ip vrf exec vrf100 python3 -m http.server --bind 127.0.0.1
OSError:[Errno 99]要求されたアドレスを割り当てることができません。

問題は、VRFで別のIPアドレス(127.0.0.2など)を使用してループバックインターフェイスを作成する方法です。ここでは、ローカルアプリケーションを次のようにバインドできます。

ip vrf exec vrf100 python3 -m http.server --bind 127.0.0.2???これを行う方法

ありがとう

答え1

正直言って、私はVRFに初めて触れましたが、会員登録するだけでいいと思います。注:

Linux VRFでループバックアドレスを割り当てる方法は?

しかし、私の考えはこんな感じです。

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

このインターフェイスはループバックインターフェイスであり、転送インターフェイスではなく、独自のテーブルがあります。local

ip route show table local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 
local 192.168.1.12 dev wlp114s0 proto kernel scope host src 192.168.1.12 
broadcast 192.168.1.255 dev wlp114s0 proto kernel scope link src 192.168.1.12 

ここに私の2つのコメントがあります。聞いている場合は、実際には127.0.0.1どこにも行かないので、VRFに割り当てる必要はありません。

一方、VRFはip ruleVRFテーブルを照会するルールを作成しない限り完全に分離されているため、実際にVRFにインターフェイスを割り当ててアドレスを割り当てることができ、そのVRFにルーティングするルールがない限り、ルーティングテーブルは隔離されます。 VRFに割り当てるすべてのインターフェイスにはそのルートがそのテーブルに移動しますが、ホスト/プライマリgwインターフェイスをVRFに割り当てると、そのルートもそのテーブルになります。代替案は、次の間にルーティング設定を使用することです。ip rule

私の視点を提示することができれば:

sudo ip netns exec _netcrave ip route show table 130
192.0.0.4/30 dev vma130 proto kernel scope link src 192.0.0.5 
local 192.0.0.5 dev vma130 proto kernel scope host src 192.0.0.5 
broadcast 192.0.0.7 dev vma130 proto kernel scope link src 192.0.0.5 

sudo ip netns exec _netcrave ip route show
10.0.0.0/16 dev docker0 proto kernel scope link src 10.0.0.1 linkdown 
10.254.0.0/30 dev igwsl127 proto kernel scope link src 10.254.0.2 

ip route show
default via 192.168.1.1 dev wlp114s0 proto dhcp src 192.168.1.12 metric 600 
169.254.0.0/16 dev wlp114s0 scope link metric 1000 
192.168.1.0/24 dev wlp114s0 proto kernel scope link src 192.168.1.12 metric 600 

通常、テーブルルックアップルールを作成する方法は次のとおりです。

ip netns exec _netcrave ip rule add to 192.0.0.4/30 table 130これにより、次のような結果が得られます。

sudo ip netns exec _netcrave ip rule show
0:      from all lookup local
999:    from all to 192.0.0.4/30 lookup 130
1000:   from all lookup [l3mdev-table]
32766:  from all lookup main
32767:  from all lookup default

通常、ip vrf execソースアドレスにバインドする場合は、たとえば、ip vrf exec red130 ping 192.0.0.6192.0.0.5のインターフェイスが実際にそのVRFに割り当てられている場合は、192.0.0.5でpingを実行していることを確認してください。それ以外の場合は、vrf execを使用する必要はなく、インターフェイスが表示されます。しかし、ルーティングテーブルはそうではありません。ただし、NetNSを使用している場合は必ずインターフェイスが必要ですip netns exec。そうしないと、インターフェイスが見つかりません。

心に浮かんだもう一つのことは次のとおりです。

sudo ip netns exec _netcrave ip route show table local
local 10.0.0.1 dev docker0 proto kernel scope host src 10.0.0.1 
broadcast 10.0.255.255 dev docker0 proto kernel scope link src 10.0.0.1 linkdown 
local 10.254.0.2 dev igwsl127 proto kernel scope host src 10.254.0.2 
broadcast 10.254.0.3 dev igwsl127 proto kernel scope link src 10.254.0.2 
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 

別のローカルテーブルがあることがわかります。

local 192.168.1.12 dev wlp114s0 proto kernel scope host src 192.168.1.12 
    broadcast 192.168.1.255 dev wlp114s0 

理論的には、ループバックパスを独自に作成してこのテーブルに追加できます。実際に私が間違っているかもしれませんが、これが意図されているようです。

https://community.cisco.com/t5/switching/vrf-loopback-interface-into-global-table/td-p/3192007

答え2

したがって、最初の要件は、VRF上で実行されるアプリケーションがあり、管理インターフェイスがあり、それをローカルホストにバインドしたいということです。

ip vrf exec vrf100 myapp --adminif <localhost in vrf100> --userif <physical interface in vrf100>

次のような動作するソリューションを見つけました。

ip link add vrf100 type vrf table 100 #create vrf with table 100
ip link add lo-vrf100 type dummy      #add dummy interface that will serve as our loopback
ip link set lo-vrf100 master vrf100   #enslave the interface to vrf100
ip addr add 127.0.0.2/8 dev lo-vrf100 #add ip to this interface
ip link set vrf100 up
ip link set lo-vrf100 up

ポリシールーティングテーブルを見ると、次のようになります(ルール0は1000より前に処理される式です)。

ip rule show
0:      from all lookup local
1000:   from all lookup [l3mdev-table]
32766:  from all lookup main
32767:  from all lookup default

ローカルルーティングテーブルを見てみましょう。

ip route sh table local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1

その後、IP範囲はここで処理されますが、127.0.0.0/8vrfは後で処理される特別なテーブル[l3mdev-table]で処理されることがわかります。

ip route sh table 100
127.0.0.0/8 dev lo-vrf100 proto kernel scope link src 127.0.0.2
local 127.0.0.2 dev lo-vrf100 proto kernel scope host src 127.0.0.2
broadcast 127.255.255.255 dev lo-vrf100 proto kernel scope link src 127.0.0.2

from all lookup localしたがって、解決策は、ポリシールーティングエントリの前にIP 127.0.0.2を処理するルールを作成することです。

ip rule add table local priority 100 #have an identical entry but with a higher prio
ip rule add from 127.0.0.2 table 100 prio 50
ip rule add to 127.0.0.2 table 100 prio 51
ip rule del priority 0 #delete the original local rule

最終的なポリシールーティングテーブルは次のとおりです。

ip rule sh
50:     from 127.0.0.2 lookup 100
51:     from all to 127.0.0.2 lookup 100
100:    from all lookup local
1000:   from all lookup [l3mdev-table]
32766:  from all lookup main
32767:  from all lookup default

私の最初の投稿のPython httpサーバーの例はうまくいきます。

ip vrf exec vrf100 python3 -m http.server --bind 127.0.0.2
Serving HTTP on 127.0.0.2 port 8000 (http://127.0.0.2:8000/) 
ip vrf exec vrf100 wget http://127.0.0.2:8000 #downloads file sucessully

関連情報