JUNOS
JUNOSはFree BSD baseの要はUNIXサーバーである。なのでいきなり電源を抜いたりしてその時にIO wirte中とかだったりすると最悪死ぬ。
用語
インタフェース名
Routing Process architecture
次の二つで構成されている。
RoutingEngine
PacketForwadring Engine
routing-engine(RE)
junosはRoutingEngine(RE)と呼ばれるプロセス群がOS上で稼働している。このプロセス群はネットワークインターフェース、ルーティングの管理をしている。REはOS領域とは保護されたメモリモジュールで動作した複数のプロセスの集合である。RE自体が実はOS的な動きもしているのでよくわからん。REは100MbsのインターコネクションでPacket Frowarding Engineと接続していて直接の接続はしていない。これによりREが落ちてもPacketForwarding自体は止まらないようにしている。
物理的にはREはモジュールとして提供されていて、モジュールごとに個々のCPU,メモリ、ストレージを使ってREが動いているっぽい。REモジュールを一つの筐体に複数さすことで、一つの筐体で物理的にREをactive, standbyの形で冗長化できる。
Packet Forwarding Engine
ASIC処理によるL2,L3パケットフォワーディング、スイッチングと経路探索をする。
故障率
体感的にはCiscoよりもJuniperのほうが故障が多いとかなんとか(?)
ControlBoard(CB)
シャーシ全体（電源、BIOS)のコントロールやラインカードとREの間のデータ転送の制御もしている。
これも冗長に２つモジュールを搭載可能。ほぼREとセットで使われることになる。
route-engine redundancy
VirtualChassisがらみの冗長化機構
JUNOSはrouting deamon processを二つ走らせて冗長系を保つような仕組みがあるらしい。
切り替え時にはパケットロスはほとんどないらしい。
route preference
Cisco系でいうadministratie distanceに相当。ルーティングプロトコルの優先度。
ADは値が低いほうが優先だが、RPは値が大きいほうが優先。まだCiscoではADが最小のものしか確認できないが、JUNOSでは全て確認できる。実際に利用するのはPRが小さいもの。
route table
junosは次のようなroute tableを持つ。普通はinet.0だけみてれば十分か。
inet.0 IPv4ユニキャストルーティングテーブル
inet.1 マルチキャスト用のフォワーディングキャッシュ
inet.2 RPFチェック用のMBGPルーティングテーブル
inet.3 MPLSパス情報, BGPが利用。Egress IP addressとLSPが紐づいている
inet.4 MSDPルートエントリー
inet6.0 IPv6ユニキャストルーティングテーブル
mpls.0 MPLSのネクストホップ Label Switching用
bgp.l2vpn.0 BGPで受信したL2VPN経路
[INSTANCE-NAME.l2vpn.0 RTに基づいたbgp.l2vpn.0の経路を各インスタンスごとに割り振ったもの
bgp advertise-inactive
CiscoはRIBに乗っていない経路(inactive route)も広報する。しかしJuniperでは デフォルトはinactive routeは広報しない。このadvertise-inactiveを設定するとCiscoと同様にinactive routeも経路広報をする。
具体例
OSPF、BGPで同じprefix Aを学習したときにRPのpriorityの関係でOSPFの経路をRIBに乗せる。この時BGP側からみるとBGPで学習したprefix AがRIBに乗っていない(OSPFのprefixAが採用されている都合)のでBGPでprefix Aをadvertiseしない。
この時にadvertise-inactiveを設定するとinactive routeでもadvertiseするようになる。なお別の解決手段として次もある。
OSPF経路をBGPでredistributeする。
OSPFより強いiBGPを別途使う。
RPの値を変えてBGPをOSPFよりも優先させるようにする
RoutingPolicy
JUNOSでルーティング情報を取り扱う場合はRoutingPolicyというものを利用する。経路フィルター、BGP attributeの変更はこのRoutingPolicyを利用する。CiscoでいうRoute-mapに相当する機能。RoutingPolicyは経路情報がRoutingTableにはいるImportと経路情報を広告するExportのタイミングに対して適用できる。RoutingPolicyはtermという単位で扱われる。
termにはfrom,thenというif-thenの条件とアクションを複数設定できる。fromがなく、thenだけ書くことで無条件のアクションの実行もできる。雰囲気としてはiptablesに近い。
条件マッチした場合の動作として次がある。
accect, 残りのpolicyは評価せず、即座に対象を受け入れる。
reject, 即座に対象をドロップ
next-policy 次のpolicy評価にうつる。
https://gyazo.com/27aca4b2d536a2a51755da6a9088e7ed
Recursive lookup
例えばstatic route で次のような状態だったとする。
1. 0.0.0.0/0 next hop 192.168.0.1 ,
2. 192.168.0.1/32 next hop 172.16.32.1/32
Ciscoでは0.0.0.0はきちんとルーティングテーブルにのって動作するが、これはRecursive lookupという機能によって再帰解決されるからである。上記の例ではnext hop192.168.0.1が再帰解決されることで、192.168.0.1へ送る際のnext hopが判明して0.0.0.0/0がきちんとルーティングテーブルに乗る。
CiscoではRecursive Lookupがデフォルト有効なのでうまく動作する。しかしJUNOSでは明示的に設定しないとRecursive lookupは動作しない。 Recursive lookupを動作させたいstatic routeを設定するときに末尾にresolveを付与すればよい。これはstatic routeにかぎらずBGPのnexthopのアドレスをOSPFで解決するときにもrecursive lookupが必要になる。
Group
groupはコンフィグレーションのグループ機能
groupで定義してapply-groupsで適用
backup-router
junosはそれぞれのルーティングプロトコルはデーモンプロセスとして独立して起動する。
junos起動直後はまたデーモンは立ち上がりきっておらず、起動直後はルーターの管理IPにアクセスできるようになるまでに時間がかかる。backup-routerはデーモンが立ち上がり切るまでの間のstatic routeのような設定をできる。これで起動直後にすぐに管理IPへのアクセスを担保できる。
syslog
junosは指定するsyslogサーバーに正規表現マッチしたログだけを転送する設定ができる。
routing-instance
routing-instanceはinterface, routing table, routing protocol parametarをひとまとめにしたもの。これを使うとルーター内で仮想ルータを疑似的に立ち上げたりもできる。routing-instanceにはtype がある。 typeでvrf,virtul-router,forwarding`などを指定して初めて具体的なプロセスが決定する。
ちなみにvrfとvirtual-routerは似ているがVPN routing回りの対応の差がある。具体的にはvrfじゃないとroute-distingusher,vrf-import,vrf-exoprtができない。virtual-routerはciscoでいうvrf-liteに近い。つまりルーティングテーブルをただわける使い方をしたいだけならvirtual-routerがよい。
logical-systems
routing-instanceと同様にvrfを分けるのに使われる仕組み。routing-instanceとかなり近い機能だが、virtual-routerがあくまでルーティングテーブルを分けるだけなのと違い、logical-systemsはrouting protocol processそのものを別にする。つまり完全に独立した仮想ルータを作成できる機能といえる。そういった意味ではrouting-instanceよりはlogical-systemsで分離してしまったほうがrouting processのクラッシュが発生しても、被害を最小化できるのでvirtual-routerより手堅い。
ただしlogical-systemsは機種によってはサポートしてないケースもある。
syntax checker
なんかチェックしてくれるらしい。
default policyer
注意事項
ddos protection チューニング
暗黙でかかっている。運用箇所によってはこれでドロップされる恐れあり。
arp policer
暗黙で全てのI/Fにdefaultのarp policerがかかっている
このpolicerが一部のI/Fで反応すると、ほかのI/Fにまで影響する
個別のarp policerを作成してI/Fに適用することで影響範囲を変えられる。
RE交換
冗長しているREを落とすに場合は、gresなどの冗長化機構をoffに。switch overしないように確認しておく
直接対象REにログイン後にhaltを実行。consoleまたはLEDで出力確認
upgaread
gracefull routing engine switchover(GRES)を切る。
non stop routingをきる
pad-to-minimum-frame-size
Ether frameはnot tag vlanの場合はフレームサイズは64-1518としてIEEEで決まっている。(プリアンブル8byte除く)
Data部分がmin 46byteでほかのもろもろを合計すると64byteが最小のframe size
https://www.gatevidyalay.com/wp-content/uploads/2018/10/Ethernet-Frame-Format-IEEE-802.3.png
tag vlan frame の場合は単純にtag vlan 4byte追加されてMinは68byte
またはData部分のMinを46byteから42byteにして合計Min 64byte。
tag vlanの場合はベンダーによってこのtag vlan frameのmin sizeは変わる。
64byte派
junos?
alaxla
NEC
68byte派
Cisco
tag vlanが64 byteでも68byteでも問題はない。どちらの実装もおかしいというわけではない。
この時の問題として64 byteのtag vlan frameでtag vlanが除去されると60byte長のnot tag vlan frameになる点。
このtag vlanを外したframeを別の機器にフレームを転送する際に60byte frameを不正なframeとして破棄する機器がある。
具体例としてtag vlanで収容するキャリア線で終点側はnot tag vlanとして接続させるケースでこの問題はでる。
キャリア内でtag vlanを外す処理を内部でして対向にframeを渡すことになる。
送信元がjunosでtag vlanを利用して64byteでframe送出
キャリア網内のどこかでtagを外して60byteに、この時点でキャリア内スイッチ網で不正なframeとして破棄される。
終点側の最後でtag vlanを外しても終点側の機器では60byte frameでくるので終点側でframe破棄されるかも。
実際に影響を受けるものとしてarp frameがこの問題の影響をうけてしまう。
arp frameが落とされるので全通信が成立しない
この問題の対策としてjunosにあるのがpad-to-minimum-frame-size
68byte未満のtag vlan frameのDataに追加で4byteのpaddingをしてくれるようになる。
結果としてDataのminが46byteとなり、フレームが最小68byteになる。
tag vlanを外されても64byteになるため問題なくなる。
68byte以上のframeには何もしない。
up I/Fに適用しても通信影響はなし。
tag vlan収容のキャリア線を経由するI/Fでは設定しておいたほうが無難か。
IXとか。スイッチ網で構築されたL2線とか。
junosの挙動として空いていないポートへのsynが来た場合にもresetパケットを返すためにREへパケットフォワードされる
CPUを消費してresetを返すので、ただいなポートスキャンが来るとcpu負荷が上昇して影響がでるおそれあり
ACLでおとしておけるとよい。
defaultは無効
primary と呼ばれるsnmpdとsubと呼ばれるsnmp agentに分かれる。
いわゆるjunosで確認できるsnmpdはprimary
subは担当MIBごとに分かれている。
primaryはsnmp request を受けたMIB に応じて適切なsub agentに委任。
sub agentがMIBに対しての応答を生成する。
https://gyazo.com/1c00ce40eb1a6b8da8e98c7123fab608
trouble shoot