何事もなく無事でありますように
○ auto last hop
Big-IP でTMOS v10以降から、"auto last hop" が default enableになっていた。
□auto last hop virtual serverに着信したトラフィックの戻りパケットを L3のnext-hopであて先をルーティングするのではなく、着信時のソースMACに転送する仕組み。 詳しくは、F5の解説がある。 リンクの解説を読んでみてもいまいち、利用用途がわからない。 ・自発パケットもあるので、L3ルーティング設定は必須 ・Next-HopがVRRPだと、ソースMACはreal macになって、問題となるケースにまず当たる。 ⇒メリットなし！！ と結論付けてしまいました。 (追記) netapp でも "fast path" といっていますが、同じように、 TCP,NFS-over-UDPで同じようにソースMACに転送する設定がデフォルトenableになっているようなので、 NFSサーバをL3-Hopして使用している方は覚えておいたほうがいい。
いさびさに小ネタで更新。
○ Spanning-tree portfast trunk
いつのまにか、Cisco cataylstで(IOS12.2以降 ?) dot1qのtrunk portでも、portfastが設定できるようになっていた
□spanning-tree portfast エッジportでSTPの遷移を省略してFWDするために、portfastの設定をいれると以下のメッセージがでる。(config-if)# spanning-tree portfast %Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION %Portfast has been configured on GigabitEthernet0/1 but will only have effect when the interface is in a non-trunking mode.
non-trunking modeのみで有効で、trunk portだと効きません。 bradeswitchや、VMHostのVswitchでdot1q渡ししたいときに困った。 で、表題の件。 □spanning-tree portfast trunk(config-if)# spanning-tree portfast trunk %Warning:portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION
loopするから気をつけてください、のWarningMessageがでましたが、trunk portでportfastが有効になりました。 portfastを設定するIFには(config-if)# spanning-tree bpdufilter enable
を設定して、bpduを送受信しないようにしておくとおもいます。 (追記) Trill(Cisco:Nexus/FablicPath,Brocade:VDX/VCS)、Virtul lag(筐体またぎのlag)がこなれてきて、 STPはどんどん現場から減っているのではないかとおもいますが、 Cisco:NexusのVirtual Lag(vPC)のloop検知用にBPDUがつかわれていて、エッジに、BPDUがながれてくることが必須です。 なので、流れてきたBPDUをどうあつかうか？という点で、結局STPの知識が必要・・・・・。 non-STPから始まったtrillなのに、(ほぼ)trill実装のCisco:NexusでBPDUを流すのは、 いけてないなーと感じます。 FablicPathと、vPCの開発部隊の違いとか、 独自実装でも、既存のframe formatを流用するが流行のようだとか、その辺がこの矛盾の要因かも。
○ VDX/VCSのMTUについて
仮想化プラットフォームのStorageをiSCIS or NFS(notSAN)で構成して、
VDX/VCS(Eth Fabric)のうえにのせる場合、
jamboFrame対応のためMTUは大きく変更すると思います。
VDXのMTUは最大 9216(byte)まで設定できますが、そのあたりのメモです。
□ MTUの設定
１．ISL portはデフォルト9216で変更できない。
２．switch portはIF単位で設定可能
(config-if) # mtu 9216
○マニュアルからの抜粋
----------------
Selecting the MTU
Always set the switch MTU to the maximum host MTU plus 100 bytes. This method is recommended because
the definition of MTU sometimes varies among different vendors. If the switch MTU is set to the same as the
connected host MTU, packets could be dropped.
----------------
switchのMTUはhostのMTUから100byteくらい多めに設定しとかないと、dropするかも？
ってかいてますが、どういうことなのか？
□ VDXでのMTUは範囲がちょっと違う
の前に、VCSmodeで動作させるとき、trillになるため、ISLportでは、
Outer transport header = 18byte
trill header = 6byte
が付与されます。
*trillのframe format
<- outer transport header -> <- trill header ->
+-------+-------+------+-----+-------+-------+-------+----------+
|outer |Outer |Outer |E- |V,R,M |Egress |Ingress|User |
|dst-mac|src-mac|V-tag |type |OL,HC |Rbridge|Rbridge|Ethframe |
+-------+-------+------+-----+-------+-------+-------+----------+
<- 6 -> <- 6 -> < 4 > < 2 > <- 2 -> <- 2 -> <- 2 -> <- 1522 ->
＊VDX独自実装で、さらに8byteが付与されているらしい。
で、VDXのMTUが指す範囲は
< -ここ!!->
+-------+-------+------+-----+-------+-------+-------+----------+
|outer |Outer |Outer |E- |V,R,M |Egress |Ingress|User |
|dst-mac|src-mac|V-tag |type |OL,HC |Rbridge|Rbridge|Ethframe |
+-------+-------+------+-----+-------+-------+-------+----------+
<- 9216 ->
なのである。
User Ethframの中身は、
+-------+-------+------+-----+------------------+-----+
|dst-mac|src-mac|V-tag |type | data | FCS |
+-------+-------+------+-----+------------------+-----+
<- 6 -> <- 6 -> < 4 > < 2 > <- variable -> < 4 >
なのでHostがいうMTUは上記のdata 部分なので、
9216 - (6+6+4+2+4) = 9194
がhostに設定できる最大MTUとなる。
□注意点
HostからUntagではいってきても、trill時に、Innerのframeにもtag(4byte)が追加されます。
(追記)
BrocadeのEth Fabricは特に、Userに設定させることなく、究極はconfig-lessまでめざしてる？と思うくらいです。
けど、この辺ではまったら、もろサーバ屋さんは気づくの難しいんじゃないかと。
○ NSF (Non Stop Forwarding/Graceful Restart)、NSR(Non Stop Routing)
Cisco/Nexusでは、OSPF Graceful Restartがdefault enableという事実を知ってしまったので、
NSF/NSRについてまとめておこうと思います。
□ Non Stop Forwarding/Graceful Restart
Graceful Restartの手順概略は、
１．ルーティングプロセス(OSPF,BGP)を再起動するルータが隣接に対して、事前に通知パケットを投げる。
２．隣接ルータは再起動ルータとのピアが切れても直近のFIBにしたがってForwardingを続ける。
３．再起動が終わったら、ルーティング情報を再開し、stateな状態に戻る。
＊ IS-ISなどセッションレスの場合は事前通知がありませんが、TCPベースのようなものであれば、事前通知
□条件
上記の動作をするためには、
１.) 再起動するルータと、隣接ルータがGraceful Restart対応であること
＊ほとんどの機器はdefaultがdisable
２.) ピアが切れてもFIBが残っているということは、control-planeとdata-planeが分離されている機器であること
です。
□注意点
１．導入するルータの隣接がHelper-modeに対応している必要がある
２．運用中であれば、設定するためにピアが切れる
３．Localルータがrestart中に隣接がrestartしてしまうと成立しない
* graceful restartはcontrol-planeとdata-planeが分離されている機器であれば実装されているはずなので、
比較的導入ハードルはひくいと思います。
□ Non Stop Routing
こちらはプロトコルがどうのという話ではなくて、
機器実装で、updateをstatefulに同期するアーキテクチャで実装しているかどうか
ということになります。
こちらはハードルがたかい（らしく）キャリアグレードな機器でないと実装していないでしょう。
なぜ難しいのか、実装上の問題点などは、MPLS2004での発表資料
こちらがわかりやすいです。
* NexusのHigh Availability and Redundancy Guideで確認すると
-------------------
○Scenarios where a stateful restart is used:
・First recovery attempt after a process experiences problems.
・ISSU
・User-initiated switchover using the system switchover command.
○Scenarios where graceful restart is used:
・Second recovery attempt after a process experiences problems within a 4 minute interval.
・Manual restart of the process using the restart ospfv3 command.
・Active supervisor removal.
・Active supervisor reload using the reload module command.
-------------------
どのパターンでstateful,graceful restartが成立するか確認できます。
実装パターンは機器によるので、ドキュメント等でキチンと確認する必要があるでしょう。
(追記)
AlaxalAのマニュアルは日本語だし、初心者向きで親切です。(graceful restartについて)
ただ、フォルト・トレランスをうたっているのですが、Non Stop Routingはsupportしてなさそうです。
○ UDLD (Uni-Directional Link Detection)
UDLDなんて、聞いたことあるくらいだったのですが、
業務で登場してきたので、ちょっとまとめ。
最後の考察で書きますが、最近のネットワークデザインでは使うことはないかも。
プロトコルの詳細な内容は以下がすごくまとまっているので、確認してください。
UDLDまとめ
□ UDLDとは UDLD (Uni-Directional Link Detection)は、Ethernetの単一リンク(片Link)障害 をL2で検出するためのプロトコルです。 Auto-Negtiationで片リンク障害(RemoteFault)検出ができますが、あくまでも、PHYレベルでの検出です。 UDLDはL2Frameを送受信して検出するので、Linkがあがってるけど、送受信できない=サイレント故障 を検出できます。 □ UDLDの基本動作 LinkUpすると、UDLD PDUの送受信して、ネイバーを検出を検出します。 ネイバーが確立されると、Helloパケット(プローブ)を送信して、隣接状態を、確認しあいます。 Helloが受信できなくなると、障害とみなして、err-disableとなり、対向スイッチのLinkがDownします。 □ UDLDの設定 by cisco＊ デフォルトではdisable # グローバルconfigで設定 (config)# udld [ enable | agressive ] (config)# udld messeage time "秒" # interface modeで設定 (config-if)# udld port [ agressive ] * normal-modeでは 対向が、受信できていない情報が入ったPDUを受信すると、err-disable * agressive-modeでは、対向からのPDUが受信できないのみの条件でerr-disable # UDLDのdisable化 (config)# no udld [ enable | agressive ] (config-if)# no udld port [ agressive ] * noコマンドでdisableした際に、flashのnotifyを投げて、ネイバーに隣接関係の解除させます。 なので、noコマンドでdisableをしたから、隣接がerr-disableに落ちることはありません。
□ UDLD フレーム UDLDはL2フレームフォーマットです。 Ciscoだと、Dst-MacにCDPと同じMAC"01-00-0c-cc-cc-cc"を使用しています。 L2Frameに直接Dataをのせるため、LLCにSNAPヘッダをつけて、L3フレームを模擬します。 通過する機器は、あくまでもL2フレームで、forwadingされます。 Dataで付与されるパラメータは以下です。 Device ID TLV・・・・・・・自身の機器ID Port ID TLV・・・・・・・・自身の送信port Echo TLV・・・・・・・・・ネイバーのDatabase Message Interval TLV・・・送信間隔 Timeout Interval TLV・・・ディクションウインドウの長さ Device Name TLV・・・・・host name Sequence Number TLV・・・シーケンス番号# show udld neighbor
でこのあたりの情報が確認できます。 □ UDLDはいつ使うのか ここからが本題。 サイレント障害で、該当Linkを落としたい場合は、 迂回路があるので、Linkダウンさせて経路迂回させたい時かと。 考えられる迂回路は？ ○L2 ・LinkAggregation → LACPでサイレント障害回避 ○L3 ・OSPF → keepaliveしてる ・BGP → keepaliveしてる です。 OSPF,BGPはそもそも上位Layer(L3)で動作しているので、 わざわざUDLDしなくてもいいように思う(というか無駄)。 (コンバージェンスに関してもそのプロトコルにあわせてtimerなどを調整するべきかと。) 別vlanにstaticで2経路みたいな構成だと、(間にスイッチかんでたりとか？)意味あるかも。 でもそれって、デザインが悪いじゃないかと思います。 □ UDLDの注意 UDLDは対向機器同士で設定するものですが、フレームのとおり、L2で透過してしまいます。# R1 1/1 routed-port/udld aggresive/vrrp # R2 1/1 routed-port/udld aggresive/vrrp # L2 設定なし(native vlan) +------+ +------+ | R1 |-------| R2 | +------+ +------+ (1/1) (1/1) | | +------+ +------+ | L2 |-------| L2 | +------+ +------+ * こんなことすると、1/1 同士で、UDLD neigbhorがはれてしまいます。 R1/R2の1/1どちらかが落ちると、UDLDで対向もdownして、 VRRPの両系がおちるという悲惨な事故になるじゃないかと(検証してませんが)
(追記) 以降出会うことがないかもしれない。UDLD。貴重でした。 妄想ですが、あんまり運用されてない・枯れてない 異種ベンダ間で使用する場合は、検証MUSTのような気がします。