MPLS VPN (MP-BGP)客戶收到routing時的優先順序

 BPG選路徑有它的演算法，https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
或者參考這一篇：
https://supportforums.cisco.com/t5/network-infrastructure-documents/understanding-bgp-best-path-selection-manipulation/ta-p/3150576

我們遇到有趣的問題，就是如果一個客戶在IMPORT不同的route target時，都有一樣的網段，那要怎麼選？試了一下，是第10個規則，routing age。

When both paths are external, prefer the path that was received first (the oldest one).
但是這邊寫說是選最舊的 (因為它最穩定)，但實做起來確實是選擇最新的，也許IOS版本也有差異吧。

簡單驗證一下，在clear ip route vrf F9412016 * 之前，best path是 從F9999999 import進來的。
 

接著clear ip route vrf F9412016 *，之後best path就變成了往F9412016送。

測出來的結果竟然與思科官網相反...是最新的才是best。
我不能接受，所以又做了下面這個lab (本來的架構沒有辦法調整route age)
R1跟R2建mpbpg，然後r2與r3,r2與r5，r2與r4都跑rip。然後r2有三個vrf，收到三筆default route。

結果測試的結果還是一樣。只要我清哪一個vrf的routing，等他收斂之後，R1就會把它視為best path。

無解，先做個記錄也許過幾年再看看吧。

FreeBSD IPF 針對Remote shell (RSH) 的規則設定

這個問題研究了兩天，稍微有點心得。記錄一下。

Remote shell是很有趣的協定，在IPF的開法跟一般的協定不同。
Remote shell會有兩個流程。第一段是三向交握的階段 ，第二段才是正確的身份驗證和下達指令的部份。

 在我測試的架構中，10.100.33.15是rsh的client，而10.100.33.16是rsh的server。

其實ipf這樣開就好了：
pass in quick proto tcp from 10.100.33.15 to 10.100.33.16 port = 514 flags S keep state
pass in log quick proto tcp from 10.100.33.15 port 511 >< 1024 to 10.100.33.16 port 511 >< 1024 flags AS keep state

下面是驗證的結果：你可以看到10.100.33.15會使用512至1023的port去跟server發起連線 (目的port似乎也是512~1023 port)。但這個session並不包含在一開始發起rsh的session中，因此要另起規則放行。(視為不同的session來處理)
27/09/2017 22:02:37.002734 fxp0 @0:4 p 10.100.33.15,772 -> 10.100.33.16,997 PR tcp len 20 64 -AS K-S IN
27/09/2017 22:02:37.002756 fxp0 @0:4 p 10.100.33.16,997 -> 10.100.33.15,772 PR tcp len 20 52 -A K-S OUT
27/09/2017 22:02:37.116048 fxp0 @0:4 p 10.100.33.15,772 -> 10.100.33.16,997 PR tcp len 20 52 -A K-S IN
27/09/2017 22:02:37.116529 fxp0 @0:4 p 10.100.33.15,772 -> 10.100.33.16,997 PR tcp len 20 52 -AF K-S IN
27/09/2017 22:02:37.116538 fxp0 @0:4 p 10.100.33.16,997 -> 10.100.33.15,772 PR tcp len 20 52 -A K-S OUT

但Remote shell很有趣，因為第二個階段用的TCP flag並不是S，所以ipf如果要放行的時候，用預設的S是不會通的。要用的是AS (我用紅包強調)。或者你也可以不做TCP flag的檢查，只保留keep state就好了。

至於為何客戶的規則只開flags S還能通呢，因為他們最後有補一個flags A/A的規則
pass in quick proto tcp from 10.100.33.15 to 10.100.33.16 port = 514 flags S keep state
pass in log quick proto tcp from 10.100.33.15 port 511 >< 1024 to 10.100.33.16 port 511 >< 1024 flags S keep state
pass in log quick proto tcp from any to any flags A/A

至於其它沒有設定 pass in log quick proto tcp from any to any flags A/A
的設備是怎麼通過的呢？

原因是他們有設定另一條policy：
pass out quick proto tcp from 10.100.33.16 to any flags S keep state
這個作法就是把10.100.33.16發起的session視為獨立的另一條session
所以你去錄封包，會看到它長這樣：
29/09/2017 18:27:33.369510 fxp0 @0:1 p 10.100.33.16,967 -> 10.100.33.15,721 PR tcp len 20 64 -S K-S OUT
29/09/2017 18:27:33.369676 fxp0 @0:1 p 10.100.33.15,721 -> 10.100.33.16,967 PR tcp len 20 64 -AS K-S IN
29/09/2017 18:27:33.369695 fxp0 @0:1 p 10.100.33.16,967 -> 10.100.33.15,721 PR tcp len 20 52 -A K-S OUT
29/09/2017 18:27:33.482540 fxp0 @0:1 p 10.100.33.16,967 -> 10.100.33.15,721 PR tcp len 20 52 -AF K-S OUT
29/09/2017 18:27:33.482817 fxp0 @0:1 p 10.100.33.15,721 -> 10.100.33.16,967 PR tcp len 20 52 -A K-S IN
29/09/2017 18:27:33.483126 fxp0 @0:1 p 10.100.33.15,721 -> 10.100.33.16,967 PR tcp len 20 52 -AF K-S IN
29/09/2017 18:27:33.483133 fxp0 @0:1 p 10.100.33.16,967 -> 10.100.33.15,721 PR tcp len 20 52 -A K-S OUT

第一條符合TCP-SYN，所以後面就都過了。

這兩者好像有點衝突對吧？究竟第二條session中，是client先發起還是server先發起？為何兩種開法都會通？

我們再回頭看一下完整的封包：

第八條是client發起的A，就是一開始講的any to any flags A/A，所以它會通 (並不是一開始的那一條any to 514喔，那一條是S)

第九條是server發起的S，就是剛剛講的的10.100.33.16 to any flags S keep state，所以它也會通。

至於為何同一客戶的兩台機器有不同的開法，推想是兩台設備是不同時期或不同人維護的，所以解決問題的辦法有所不同。

xargs的取代字串功能

最近發現xargs有一個很好用的取代功能。

ls | grep firewall.backup | tail -1 | xargs -iz scp z root@firewallbk:./firewall/

這是一個簡單的程式，取出最新的檔案，然後把它用scp複製到遠端。
重點是xargs：-i指的是replace後面的字串，z是指取代後的名稱。

簡單來說，就是把前面ls取出的檔名取代為z (算是一個代號吧)，後面的scp z做的其實是
scp 該檔名