BGP in the Data Centerを読みました (4/6) : Chapter 4 - Reimagining BGP Configuration
今回はChapter 4についてまとめました。 内容はChapter 3に引き続き、構築を自動化しやすいようなIPv6のBGP設定です。 具体的にはBGP unnumberedおよびRFC 5549です。
データセンタネットワーク全般については、”Cloud-Native Data Center Networking” を読むのがおすすめです。 筆者が同じ方で、 "BGP in the Data Center" に記載されている内容も含まれています。 この本はCumulus Networksにより無償で公開されています。 ぜひ読んでみてください。
Download your copy of latest book by Dinesh Dutt, "Cloud Native Data Center Networking." It's a 400-page must-read for all network architects, developers and operators. Don't miss out! #CumulusResources https://t.co/JwAAiOHh1f pic.twitter.com/nVJUZyw67Z
— CumulusNetworks (@CumulusNetworks) 2020年1月13日
各Chapterまとめ
- Chapter 1 - Introduction to Data Center Networks
- Chapter 2 - How BGP Has Been Adapted to the Data Center
- Chapter 3 - Building an Automatable BGP Configuration
- Chapter 4 - Reimagining BGP Configuration
- Chapter 5 - BGP Life Cycle Management
- Chapter 6 - BGP on the Host
Chapter 4 - Reimagining BGP Configuration
Chapter 3では、BGPの設定からIPアドレスを排除する方法を見てきました。
BGP設定からはインタフェースIPアドレスの記述をなくすことができました。
しかし、依然としてインタフェース自体にはIPアドレス (/30, /31) の設定が必要なままです。
インタフェースIPアドレスはBGP以外で使用されることはありません。 また、FIB (Forwarding Information Base) のサイズを削減するために、インタフェースIPアドレスはBGPで広報しません。
インタフェースIPアドレスを排除できれば、各ノードに固有の値はASNとrouter-id の2つだけになり、 ノードの設定はDCネットワーク構築自動化に適したシンプルなものになります。
インタフェースIPアドレスをBGP設定から排除するために、unnumberedインタフェースの概念をBGPに適用させます。
必要なインタフェースIPアドレスの総数
図のような、4台のspineと32台のleafからなる2層のClosトポロジを考えます。
各spineには32本のリンクがあり、各leafには1本のリンクがあるものとします。
すると、インタフェースIPアドレスは、 32個のインタフェース * 4台のspine * リンクごとに2つ = 256個 必要です。
leafが96台の中規模ネットワークの場合、必要なインタフェースIPアドレスの総数は 96 * 4 * 2 = 768個 です。
更に規模の大きいspineが16台のネットワークでは、必要なインタフェースIPアドレスの総数は 96 * 16 * 2 = 3072個 です。
2層Closトポロジの規模とインタフェースIPアドレス数
| ネットワークの規模 | インタフェースIPアドレスの数 |
|---|---|
| leaf 32台, spine 4台 | 32 * 4 * 2 = 256 |
| leaf 96台, spine 4台 | 96 * 4 * 2 = 768 |
| leaf 96台, spine 16台 | 96 * 16 * 2 = 3072 |
これらのIPアドレスをアルゴリズムで導出することはできますが、そうすると自動化のコードが複雑になってしまいます。
IPアドレスの所属先はノードかインタフェースか
従来のL3ネットワーク設計では、基本的にはインタフェースにIPアドレスを割り当てていきます。 この設計方法では、「IPアドレスはノードとインタフェースのどちらに属する」ものなのでしょうか。
具体的な質問にするなら、「ノードが、受信するインタフェースとは別のインタフェースに割り当てられているIPアドレスに対するARP requestに応答できるか」です。
ルータの場合はARP requestに応答しません。このような動作を有効にしたい場合はproxy-arpを有効化する必要があります。
Linuxの場合は、ARP requestを受信したインタフェースに関係なく、ノードは自身が持つ任意のIPアドレスに対するARP requestに応答できます。 可能な限り通信を有効にしたいという思想があるようです。
Unnumbered Interface
ノードの各インタフェースに固有のIPアドレスを割り当てないL3ネットワーク設計方法があります。
自身が一意のIPアドレスを持つインタフェースをnumbered interfaceと呼ぶのに対し、
自身が一意のIPアドレスを持たないインタフェースを "unnumbered" interface と呼びます。
unnumbered interfaceにIPアドレスが割り当てられていないわけではありません。 他のインタフェースからIPアドレスを借用します。 IPアドレスの借用元インタフェースに障害が発生した場合、そのIPアドレスは使用できなくなってしまいます。 そのため通常は、unnumbered interfaceはループバックインタフェースからIPアドレスを借用します。 ループバックインタフェースはダウンしないためです。
ルータがunnumbered interfaceでARP requestを受信した場合、受信したインタフェースのMACアドレスを使用してARPに応答します。
BGP Unnumbered
リンクステートプロトコルであるOSPFやIS-ISでは、当初からunnumbered interfaceがサポートされています。 （IS-ISはIP上で動作しませんが、unnumbered interfaceでも動作します。）
リンクステートプロトコルでは、link-local multicast addressを使用してメッセージを送信します。 そのため、ルーティングプロトコル自体がピアのIPアドレスを事前に知っている必要はなく、 パケットを送受信するインタフェースのみ知っていればよいです。
一方のBGPはTCPで動作します。 そこで、「ピアへの経路がどのインタフェースにあり、ピアのIPアドレスが何であるか」を事前に知っている必要があります。 TCPでは、マルチキャストでなくユニキャストパケットが利用されるためです。
では、Chapter 3で課題になっていたインタフェースIPアドレスを使用せずに、BGPを利用する方法について見ていきます。 具体的には次のような特徴があります。
- IPv6 link-local address (LLA) を利用
- IPv6 Router Advertisementによってピアのlink-local addressを学習
- RFC 5549を利用し、IPv6 link-local addressをネクストホップとするIPv4アドレスを広報
- RFC 5549のIPアドレス広報を利用して取得した情報を利用するルーティングテーブル設定
IPv6 link-local address
IPv6は、明示的な設定がなくても可能な限り機能するよう設計されています。
IPv6ネットワーク内の全てのリンクには、リンクに固有のIPアドレスが自動で割り当てられます。 このようなIPv6アドレスをlink-local address (LLA) と呼びます。 IPv6 link-local addressは、インタフェースのMACアドレスに基づき自動生成されます。 link-local addressは直接接続されたピアからのみ到達可能であり、一意であることが保証されています。
IPv6 Router Advertisement
ノードが隣接するルータを自動検出するために導入された仕組みをRouter Advertisement (RA) と呼びます。 RAはIPv6のNeighbor Discovery (ND)で使用されるメッセージの1つです。 IPv6のNDは、IPv4のARPに相当します。
インタフェースでRAが有効になっている場合、link-local addressを含むインタフェースのIPv6アドレスを、定期的に隣接ノードに広告します。 したがって、一方のノードが他方のノードのIPv6アドレスを自動で知ることができます。
なお、IPv6 link-local addressはBGPのTCPコネクションでのみ使用されます。 ネットワーク内では、コントロールプレーンでIPv6を使用していますが、 データプレーンでIPv6アドレスを使用する必要はありません。 従来使用していたIPv4を使用可能です。
RFC 5549
コントロールプレーンでIPv6 link-local addressを使用してBGPピアを確立できたとしても、 データプレーンではIPv4の経路への到達性が必要です。
BGPはマルチプロトコル対応 (MP-BGP: Multiprotocol BGP) であり、複数のアドレスファミリの広報を単一のBGPセッションで伝搬できます。 そのため、BGP IPv4 UPDATEメッセージは、IPv6 TCPコネクションを介して送信できます。 経路への到達可能性を通知するBGP UPDATEメッセージには、経路に関連付けられたネクストホップのIPアドレスが含まれています。
BGPは当初IPv4のみに対応しており、ネクストホップのIPv4アドレスは NEXT_HOP attributeに含まれていました。
BGPがIPv4だけでなくIPv6等のマルチプロトコルを扱えるようにするために、
RFC 4760 で導入されたのが次の2つのattributeです。
MP_REACH_NLRI(Multiprotocol Reachable NLRI)MP_UNREACH_NLRI(Multiprotocol Unreachable NLRI)
MP_REACH_NLRI には、ネクストホップや経路情報等が含まれます。
+---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Reserved (1 octet) | +---------------------------------------------------------+ | Network Layer Reachability Information (variable) | +---------------------------------------------------------+
MP_UNREACH_NLRI には、削除される経路情報等が含まれます。
+---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Withdrawn Routes (variable) | +---------------------------------------------------------+
IPv4アドレスのないインタフェースがeBGPセッションでIPv4の経路を広報する場合、 広報するネクストホップのIPアドレスはIPv6 link-local addressです。 そこで必要となるのがRFC 5549です。
RFC 5549は、 IPv6ネットワーク上でIPv4経路の広報およびIPv4パケットのルーティングを可能にすること を目的としたRFCです。 すなわち、IPv4は、IPv6アドレスをネクストホップとしてルーティングされます。
IPv6ネクストホップの情報は、BGP UPDATEメッセージの MP_REACH_NLRI に含まれます。
IPv4経路をIPv6ネクストホップでエンコードするのは、通常のモデルではありません。 BGPピアでRFC 5549を使用するには、RFC 5549を理解する機能を持っていることを双方のルータが広報する必要があります。 RFC 5549の使用をネゴシエーションするために定義されているのが、Extended Next Hop Encoding Capabilityです。
RFC 5549を有効化したBGPノードからのOPENメッセージには、Extended Next Hop Encoding Capabilityが含まれます。
一般的なルーティングの動作の観察
RFC 5549の理解のために、一般的なルーティングの動作を見てみます。
例) 10.1.1.0/24 via 20.1.1.1 dev swp1
- ルータが
10.1.1.1宛のパケットを受信すると、ルータはルーティングテーブル内にある上記のルーティングエントリを使用します。 ネクストホップのIPアドレスが20.1.1.1であり、そしてネクストホップへの送信インタフェースがswp1であると判断します。 - パケットを
20.1.1.1に転送するには、20.1.1.1のMACアドレスが必要になります。 ルータのARPキャッシュに20.1.1.1のARPエントリがない場合は、インタフェースswp1からARP requestを送信します。 - 隣接ルータからのARP replyを受信すると、
20.1.1.1のMACアドレスがARPキャッシュに追加されます。 - ルータは、
20.1.1.1のMACアドレスを宛先MACアドレス、インタフェースswp1のMACアドレスを送信元MACアドレスにして、フレームを転送します。
MACアドレスの学習を除き、ネクストホップのIPアドレスは使用されません。
IPv6の場合も同様で、NDを使用してネクストホップのMACアドレスを取得します。
RFC 5549はこのルーティングの動作の観察に基づいており、 ルータがIPv6ネクストホップでIPv4経路を広告できるようなエンコード方式を提供します。
RFC 5549によるパケット転送
今回、RFC 5549の実験で使用したネットワークトポロジは次のとおりです。 全ノードがESXi 6.7上のCumulusVX 3.7.7です。
ルーティングテーブルは、IPv4経路にIPv4ネクストホップがあり、IPv6経路にはIPv6ネクストホップがあるという前提に基づいて実装されています。
IPv6 RAメッセージには、 インタフェースのlink-local addressだけでなく、MACアドレスを広告するためのフィールド (source link-layer address) もあります。 このRAメッセージを定期的に送信することで、隣接ノードに自身のインタフェースのIPv6 link-local addressおよびMACアドレスを広報できます。
FRRoutingで、インタフェースのRAを有効化する設定は次のとおりです。
interface swp3 ipv6 nd ra-interval 10 # RAメッセージの送信間隔を10秒に設定 no ipv6 nd suppress-ra # RAを有効化 (RAの抑止を無効化)
なお、FRRoutingでBGP unnumberedが有効な場合、明示的に設定しなくとも上記の設定が自動で有効になります。
FRRoutingのBGP unnumberedでは、定期的に送信されるRAメッセージを受信してARP tableにエントリを設定すると、BGPセッションの確立を開始します。 FRRoutingでBGPのExtended Next Hop Encoding Capabilityを有効化する設定は次のとおりです。
router bgp 4210000001 neighbor ISL peer-group # peer-group ISLを定義 neighbor ISL capability extended-nexthop # peer-group ISLでExtended Next Hop Encoding Capabilityを有効化 !
RAと同様に、FRRoutingでBGP unnumberedが有効な場合、明示的に設定しなくとも上記の設定が自動で有効になります。
手順の概略は次の図のとおりです。
検証用ネットワークトポロジにて、leaf-01とspine-01の間のBGP unnumberedの手順で送受信されたパケットを、leaf-01の swp3 インタフェースでキャプチャした結果は次のとおりです。
キャプチャしたパケットの内容は次のとおりです。
- ピアが相互にRAメッセージを相互に定期的に送信
- BGP用のTCPコネクションを3-Way Handshakeにより確立
- TCPコネクションを確立後、ピアが相互にBGP OPENメッセージを送信しKEEPALIVEメッセージを受信することで、BGPセッションを確立
- BGPセッションを確立後に、UPDATEメッセージにより経路情報を交換
余談ですが、実際には両方のピアがそれぞれTCP SYNメッセージを送信し、それぞれがTCPコネクションを確立しています。
1つのBGPセッションに対し2つのTCPコネクションが存在するのは、connection collisionと呼ばれる状態です。 一方のTCPコネクションは、エラーコードを含むNOTIFICATIONメッセージを送信して切断します。
BGPセッションが確立されると、BGPはピアのIPv6 link-local addressを使用して経路広報 (BGP UPDATEメッセージ) を受信します。
BGPが受信した経路をベストパスに選択する場合、BGP UPDATEメッセージで受信したIPv6 link-local addressをネクストホップに設定するという情報を、 RIB (Routing Information Base) に渡します。 RIBは、ノードで実行されている全ルーティングプロトコルから受信した全経路およびstatic routeの集合です。 FRRoutingでは、zebraがRIBに相当します。
IPv6 link-local addressをネクストホップとするIPv4の経路を受信し、RIBがそれをFIB (Forwarding Information Base) のベストパスに選択することを考えます。 FIBはノードがパケット転送で使用する経路情報であり、RIBプロセスにより設定されます。 kernel routing tableがFIBに相当します。
RIBの状態を確認すると、IPv4アドレスのネクストホップが fe80:: で始まるIPv6 link-local addressになっています。
dc-leaf01:~$ sudo vtysh -c 'show ip route'
[sudo] password for cumulus:
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR,
> - selected route, * - FIB route
C>* 10.0.254.1/32 is directly connected, lo, 08:19:16
B>* 10.0.254.2/32 [20/0] via fe80::20c:29ff:fede:9b3c, swp4, 02:28:45
* via fe80::20c:29ff:feee:f3a6, swp3, 02:28:45
B>* 10.0.254.3/32 [20/0] via fe80::20c:29ff:fede:9b3c, swp4, 02:28:45
* via fe80::20c:29ff:feee:f3a6, swp3, 02:28:45
B>* 10.0.254.4/32 [20/0] via fe80::20c:29ff:fede:9b3c, swp4, 02:28:45
* via fe80::20c:29ff:feee:f3a6, swp3, 02:28:45
B>* 10.0.254.253/32 [20/0] via fe80::20c:29ff:fede:9b3c, swp4, 08:19:10
B>* 10.0.254.254/32 [20/0] via fe80::20c:29ff:feee:f3a6, swp3, 02:28:45
C>* 10.1.1.0/26 is directly connected, vlan10, 08:19:16
B>* 10.1.2.0/26 [20/0] via fe80::20c:29ff:fede:9b3c, swp4, 02:28:45
* via fe80::20c:29ff:feee:f3a6, swp3, 02:28:45
B>* 10.1.3.0/26 [20/0] via fe80::20c:29ff:fede:9b3c, swp4, 02:28:45
* via fe80::20c:29ff:feee:f3a6, swp3, 02:28:45
B>* 10.1.4.0/26 [20/0] via fe80::20c:29ff:fede:9b3c, swp4, 02:28:45
* via fe80::20c:29ff:feee:f3a6, swp3, 02:28:45
RIBプロセスは、そのIPv6 link-local addressと関連付けられたMACアドレスの情報があるか確認します。
そしてRIBは、 169.254.0.1 とそのMACアドレスに関するstatic ARPエントリを追加します。
PERMANENT と記載されているのがstatic ARPエントリです。
dc-leaf01:~$ ip neighbor show 169.254.0.1 dev swp4 lladdr 00:0c:29:de:9b:3c PERMANENT 169.254.0.1 dev swp3 lladdr 00:0c:29:ee:f3:a6 PERMANENT fe80::20c:29ff:fede:9b3c dev swp4 lladdr 00:0c:29:de:9b:3c router REACHABLE fe80::20c:29ff:feee:f3a6 dev swp3 lladdr 00:0c:29:ee:f3:a6 router REACHABLE
169.254.0.1 はIPv4 link-local addressですが、これをIPv6 link-local addressの代わりにネクストホップIPv4アドレスのダミーとして利用します。
そのため、FRRoutingでは 169.254.0.1 が予約されていることを前提としています。
なおIPv4 link-local addressは、IPv6 link-local addressのように自動でインタフェースに割り当てられることはありません。
FIBには、 169.254.0.1 をネクストホップとする経路が設定されます。
dc-leaf01:~$ ip route show
10.0.254.2 proto bgp metric 20
nexthop via 169.254.0.1 dev swp4 weight 1 onlink
nexthop via 169.254.0.1 dev swp3 weight 1 onlink
10.0.254.3 proto bgp metric 20
nexthop via 169.254.0.1 dev swp4 weight 1 onlink
nexthop via 169.254.0.1 dev swp3 weight 1 onlink
10.0.254.4 proto bgp metric 20
nexthop via 169.254.0.1 dev swp4 weight 1 onlink
nexthop via 169.254.0.1 dev swp3 weight 1 onlink
10.0.254.253 via 169.254.0.1 dev swp4 proto bgp metric 20 onlink
10.0.254.254 via 169.254.0.1 dev swp3 proto bgp metric 20 onlink
10.1.1.0/26 dev vlan10 proto kernel scope link src 10.1.1.1
10.1.2.0/26 proto bgp metric 20
nexthop via 169.254.0.1 dev swp4 weight 1 onlink
nexthop via 169.254.0.1 dev swp3 weight 1 onlink
10.1.3.0/26 proto bgp metric 20
nexthop via 169.254.0.1 dev swp4 weight 1 onlink
nexthop via 169.254.0.1 dev swp3 weight 1 onlink
10.1.4.0/26 proto bgp metric 20
nexthop via 169.254.0.1 dev swp4 weight 1 onlink
nexthop via 169.254.0.1 dev swp3 weight 1 onlink
これらが設定された時点で、パケット転送が正しく動作します。
なお、リンクがダウンしたり隣接ノードがRAを無効化した場合、 ローカルのRAプロセスは、RIBから該当するlink-local addressとMACアドレスのエントリを削除します。
RIBプロセスは、ネクストホップが到達不可であると判断すると、ピアが到達不可であることをBGPプロセスに通知します。 そして、該当するstatic ARPエントリを削除します。
ピアへ到達不可になったことでBGPセッションがダウンするので、 BGPプロセスは該当するインタフェースに関連する経路を破棄します。
BGP unnumberedおよび RFC 5549の動作まとめ
BGP unnumberedおよびRFC 5549の動作をまとめると、次のとおりです。
- BGP unnumberedは、インタフェースのIPv6 link-local addressを使用してBGPセッションのピアを設定する
- 隣接ノードのIPv6 link-local addressおよびMACアドレスは、IPv6 RAによって提供される
- RIBプロセスは、RAによって学習されたMACアドレスおよび予約されたIPv4 link-local address
169.254.0.1を使用して、static ARPエントリを設定する - RFC 5549により、BGPは、IPv6 link-local adderssを使用してRIBプロセスのIPv4経路を設定する
- RIBプロセスは、RIBにおけるネクストホップのIPv6 link-local addressをIPv4 link-local address
169.254.0.1に変換して、FIBにIPv4経路を設定する
実験用ネットワークトポロジでのBGP unnumberedとRFC 5549の動作確認
FRRoutingの設定
Chapter 3で見てきたBGP設定では、リンク間のインタフェースにIPアドレスを設定する必要がありました。 BGP unnumberedおよびRFC 5549を採用することで、インタフェースのIPアドレス設定を排除し、各ノードに固有の値はASNとrouter-id の2つだけになりました。 Ansible等のツールを利用した自動化が非常に容易です。
実験用ネットワークトポロジでのleaf01とspine01の設定は次のとおりです。spineとleafの設定はほぼ同じです。
FRRoutingでは、BGP unnumberedが有効な場合にRAとcapability extended-nexthopが自動で有効になりますが、capability extended-nexthopの設定のみ明示的に記載しています。
dc-leaf01:~$ sudo cat /etc/frr/frr.conf frr version 4.0+cl3u13 frr defaults datacenter hostname dc-leaf01 ! router bgp 4210000001 bgp router-id 10.0.254.1 no bgp default ipv4-unicast bgp bestpath as-path multipath-relax neighbor ISL peer-group neighbor ISL remote-as external neighbor ISL bfd neighbor ISL timers connect 5 neighbor ISL capability extended-nexthop neighbor swp3 interface peer-group ISL neighbor swp4 interface peer-group ISL ! address-family ipv4 unicast redistribute connected route-map ACCEPT_DC_LOCAL neighbor ISL activate maximum-paths 64 exit-address-family ! ip prefix-list DC_LOCAL_SUBNET seq 5 permit 10.1.0.0/16 ge 26 ip prefix-list DC_LOCAL_SUBNET seq 10 permit 10.0.254.0/24 ge 32 ! route-map ACCEPT_DC_LOCAL permit 10 match ip address prefix-list DC_LOCAL_SUBNET !
spine01の設定
dc-spine01:~$ sudo cat /etc/frr/frr.conf frr version 4.0+cl3u13 frr defaults datacenter hostname dc-leaf01 ! router bgp 4200000000 bgp router-id 10.0.254.254 no bgp default ipv4-unicast bgp bestpath as-path multipath-relax neighbor ISL peer-group neighbor ISL remote-as external neighbor ISL bfd neighbor ISL timers connect 5 neighbor swp1 interface peer-group ISL neighbor swp2 interface peer-group ISL neighbor swp3 interface peer-group ISL neighbor swp4 interface peer-group ISL ! address-family ipv4 unicast redistribute connected route-map ADV_LO neighbor ISL activate maximum-paths 64 exit-address-family ! route-map ADV_LO permit 10 match interface lo !
BGPの状態確認
spine01にてBGPの状態を確認すると、次のとおりです。 leaf4台とBGPピアが確立できていることがわかります。
dc-spine01:~$ net show bgp ipv4 unicast summary BGP router identifier 10.0.254.254, local AS number 4200000000 vrf-id 0 BGP table version 73 RIB entries 17, using 2584 bytes of memory Peers 4, using 77 KiB of memory Peer groups 1, using 64 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd dc-leaf01(swp1) 4 4210000001 62551 62431 0 0 0 03:51:55 2 dc-leaf02(swp2) 4 4210000002 62353 62344 0 0 0 2d03h55m 2 dc-leaf03(swp3) 4 4210000003 62353 62344 0 0 0 2d03h55m 2 dc-leaf04(swp4) 4 4210000004 62356 62347 0 0 0 2d03h55m 2 Total number of neighbors 4
traceroute
leaf01からleaf02のloopback IPアドレス ( 10.0.254.2 ) に traceroute を実行すると、次のように表示されます。
dc-leaf01:~$ traceroute 10.0.254.2 traceroute to 10.0.254.2 (10.0.254.2), 30 hops max, 60 byte packets 1 10.0.254.253 (10.0.254.253) 0.206 ms 0.196 ms 0.189 ms 2 10.0.254.2 (10.0.254.2) 0.312 ms 0.318 ms 0.312 ms
leaf01からspine02 ( 10.0.254.253 ) を経由してleaf02 ( 10.0.254.2 ) に到達していることが確認できます。
途中のノードであるspine02で 10.0.254.253 が使用されていますが、これはLinuxのsource IP address選出の実装に基づいています。
unnumbered interfaceを使用している場合、ifindexが最小のinterface IP addressが利用されます。
ifindexはiproute2でインタフェース名の前に表示される番号です。
dc-spine02:~$ ip -4 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 10.0.254.253/32 scope global lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.20.253/24 scope global eth0
valid_lft forever preferred_lft forever
基本的にはifindex 1であるloのIPアドレスが使用されますが、 loにIPアドレスが割り当てられていない場合には別のinterface IP addressが使用されます。
通常loopback IP addressを削除することはないですが、試しにspine02のloopback IP addressを削除してみます。
dc-spine02:~$ sudo ip -4 address delete 10.0.254.253/32 dev lo
dc-spine02:~$ ip -4 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.20.253/24 scope global eth0
valid_lft forever preferred_lft forever
すると、最小のifindexのinterface IP addressは、ifindex 2であるeth0の 192.168.20.253/24 に変わります。
この状態でleaf01からleaf02 (10.0.254.2 ) 宛に traceroute を再度実行すると、eth0のIPアドレスが表示されます。
(eth0はCumulus Linuxのmanagement interfaceです。)
dc-leaf01:~$ traceroute 10.0.254.2 traceroute to 10.0.254.2 (10.0.254.2), 30 hops max, 60 byte packets 1 192.168.20.253 (192.168.20.253) 0.162 ms 0.143 ms 0.131 ms 2 10.0.254.2 (10.0.254.2) 0.269 ms 0.263 ms 0.253 ms
これは、leaf02のsource IPv4 addressとして 192.168.20.253 が使われるようになったためです。
traceroute では、途中のルータはICMP Time Exceeded messageにより応答します。
この応答に使われるsource IP addressが 192.168.20.253 になったため、表示結果が変わりました。
通常はloopback IP addressを削除することはないため、
loopback IP addressが traceroute で表示されると考えて問題ないと思います。
