web-dev-qa-db-ja.com

GCPでのVPNから共有VPCへの誤ったBGPルートが最適なものとして選択されている

2つのサイト（合計4つのルーター）のそれぞれにあるCiscoルーターのペアから同じ共有VPC（XPN）内の2つの異なるVPNゲートウェイに向かうルートベースのVPNトンネルがあります。 BGPを介して単一のクラウドルーターへのルートを共有します。私たちの側の2つのサイトにはそれぞれ異なるASがあり、各ペアはペア内の同じASを介してピアリングしますが、ペア間のピアリングはEIGRPです。ルートマップと特定のメトリックを使用して、eigrpをBGPに再配布しています（またはその逆）。一方のサイトでは、OSPFに入出力を再配布し、もう一方のサイトは静的から再配布しています。各サイトの各サイトへの「ローカル」ルートはospf/staticから取得され、「リモート」ルートはeigrpから取得されます。

例として...

AS 65001は、メトリックが50の10.1.1.0/24（OSPFからのローカルルートrdis）、およびメトリックが100の172.16.1.1/24（EIGRPから学習したリモートルート）を発表しています。

AS 65002は、メトリックが50の172.16.1.1/24（ローカルルート、静的からのrdis）、およびメトリックが100の10.1.1.0/24（EIGRPから学習したリモートルート）を発表しています。

実際には62のルートが発表されていますが、全体像はわかります。 62のルートのリストは、メトリックのみが異なります。

今私の問題...クラウドルーターは65001からのすべてのルートを取得し、メトリックに関係なくプライマリ/アクティブにし、トンネル/ピアリングを65001にドロップしない限り、65002からのより低いメトリックルートを無視します。

そのため、私のトラフィックは常に必要な場所に到達しますが、最適ではないルートを使用しています。

これは約2週間前は正常に機能していましたが、それ以降のある時点で期待どおりに機能しなくなりました。

AS 65002ルーターの1つを65001に変更しました（neighborステートメントlocal-asを使用し、それらのルーターからAzureをピアリングするためにAS 65002も使用しているため、GCP側も更新します）が、変更されませんでしたこの動作を変更するようです。

networkingvpngoogle-cloud-platformgoogle-compute-enginebgp
1
Bryan Vukich

この問題を回避するには、アウトバウンドルートマップの「リモート」ルートに単純なASを追加します。これは、おおよそ次のとおりです。

router bgp 65001
 neighbor 169.254.x.y route-map DISTtoBGP out
!
route-map DISTtoBGP permit 10
 match ip address prefix-list LOCtoBGP
!
route-map DISTtoBGP permit 20
 match ip address prefix-list REMtoBGP
 set as-path prepend 65001
!
ip prefix-list LOCtoBGP seq 10 permit 10.1.0.0/16 le 24
!ip prefix-list LOCtoBGP ...
!
ip prefix-list REMtoBGP seq 10 permit 172.16.0.0/16 le 24
!ip prefix-list REMtoBGP ...

それは扱いにくいので、手動で保守する必要がありますが、機能します。

ナビさん、ありがとうございます。ASパスの長さについての質問で、簡単な回避策が指摘されました。

1
Bryan Vukich