BGP FlowSpecはRFC5575で定義されています。
RFCでは フロー情報(IPsrc, dst, portなど..)とアクション/ルール(帯域制限、リダイレクト、リマーク)
を表す(フロースペック拡張のための)NLRIが示されています。
FlowSpecはIPv4をサポートしています。(AFI=1 SAFI=133)。
フロー情報とアクション/ルール情報を運ぶために２つのBGPの"コンテナ"を用います。
BGP FlowSpec is defined within the RFC 5575: “Dissemination of Flow Specification Rules”. This RFC describes a new NLRI that allows to convey flow specifications (@IP src ; DST ; proto ; port number …) and traffic Action/Rules associated (rate-limiting, redirect, remark …). For IPv4 purposes, RFC defines the following AFI/SAFI value: AFI=1 SAFI=133. FlowSpec uses two existing BGP “containers” to convey both Flow specifications and rules associated.
実装として、Flow情報情報はMP_REACH_NLRIとMP_UNREACH_NLRIの属性で伝達されます。
アクションと結びついたルールは拡張コミュニティとして伝達されます。
Indeed, FLOW specifications are encoded within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. Rules (Actions associated) are encoded in Extended Community attribute.
MP_REACH_NLRIに書かれるフロー情報はいくつかのコンポーネントのセットで成り立っています。
各コンポートネントはAND条件で評価されてフローを識別します。
本文中でいくつかのフローの例となるコンポーネントを示します。(NLRIの値として)
尚、RFC5575ではNext-Hopの長さと値は"0"にセットされていなければなりません。
※draft-simpson-idr-FlowSpec-redirect-02.txtでは、IP Next-Hopを用いたリダイレクションの時には0以外の値となります。
Within the MP_REACH_NLRI a flow specification is made of a set of components, each component of the flow is combined with each other with an AND operator. Below we describe the different components we have to describe a specific flow (encoded on the NLRI variable field). The Next-Hop length and Next-hop value should be set to 0 (in case of the RFC 5575). Note is should be set other than 0 in this case: BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop (draft-simpson-idr-FlowSpec-redirect-02.txt)
ルータはFlowSpec BGPのUpdateメッセージを受信した際には、
フロー情報をAdj-RIB-INテーブルからLOC-RIBテーブルにインストールする前に
バリデーションチェックをすべきです。(RFC 5575)
少なくとも、RFC5575ではNext-Hopの値は0のためバリデーションチェックには考慮しません。
しかし、他の値に関してはチェックを行ったのちにLOC-RIBにインストールしなければなりません。
FlowSpec BGP update received should pass Validation Steps before their installation from the Adj-RIB-IN to LOC-RIB. Next-Hop validation must not be taken into account, because NH FlowSpec (RFC 5575) is always set to 0. But other Validations have to be done before installation (extracted from RFC):
条件A: このバリデーションは
フロー情報のオリジネータがフロー情報に埋め込まれた宛先プレフィックス向けの(best-matchする)ユニキャスト経路のオリジネータと一致するかをチェックします。
a) The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification.
条件B: フローの宛先プレフィックスと比較するときに,
他のASからよりベストなパスとなる他のユニキャストルートが存在しないこと。
b) There are no more specific unicast routes, when compared with the flow destination prefix, that have been received from a different neighboring AS than the best-match unicast route, which has been determined in step a).
RFCで述べられているバリデーションは他の連携システムのからFlowSprec経路をインストールしようとする際の障壁となります。
このため、実際にはバリデーションチェック機能は無効にされることがあります。
These validations can cause some problems when you use for example external Server to inject FlowSpec updates. Implementations may de-activate these validation steps
RFC上の表記より:
フロー情報のコンポーネントは条件の順序が厳密でないとならりません。
これから述べるタイプはすべて指定しなければならないわけではありません。
ただし、そのタイプの値は他のものより前に配置されないとなりません。
(つまり、昇順にしようということ)
Notice from the RFC: “Flow specification components must follow strict type ordering. A given component type may or may not be present in the specification, but if present, it MUST precede any component of higher numeric type value.”
Type 1: Destアドレス(Destination prefix component)
Type 2: Srcアドレス(Source prefix component)
Type 3: IP Protocol component
各オプションバイトの定義は以下の通り
- E bit: オプションの終わり(最後のオプションは1にセットされていなければならない)
- A bit: ANDビット。このビットがオプションあるいは値の間にある場合、これをANDでつなぐ。もし、これがないのであればORでつなぐ。尚、最初のオプションとして指定してはならない。
- Len: 0である場合、次の値は1byteとして解釈される。もし1である場合、次の値は2byteとして解釈される。
- Lt: Less-Than 以下ビット
- Gt: Greater-Than 以上ビット
- Eq: Equal 等しいビット
The option byte is defined as following:
- E bit: end of option (Must be set to 1 for the last Option)
- A bit: AND bit, if set the operation between several [option/value] is AND, if unset the operation is a logical OR. Never set for the first Option
- Len: If 0 the following value is encoded in 1 byte ; if 1 the following value is encoded in 2 bytes
- Lt bit: less than comparison between the Data and the given value
- Gt bit: greater than comparison between the Data and the given value
- Eq bit: equal comparison between the Data and the given value
Type 4: ポート番号(Port number component)
Type 5: 宛先ポート(Destination port number component)
Type 6: 送り元ポート(Source port number component)
Type 7: ICMPタイプ(ICMP Type component)
Type 8: ICMPコード(ICMP Code component)
Type 9: TCPフラグ(TCP Flags component)
各オプションバイトの定義は以下の通り
- E bit: オプションの終わり(最後のオプションは1にセットされていなければならない)
- A bit: ANDビット。このビットがオプションあるいは値の間にある場合、これをANDでつなぐ。もし、これがないのであればORでつなぐ。尚、最初のオプションとして指定してはならない。
- Len: 0である場合、次の値は1byteとして解釈される。もし1である場合、次の値は2byteとして解釈される。
- Not: 与えられたデータと値が等しくない条件
- m bit: 与えられたデータと値が等しい条件
The option byte is defined as following:
- E bit: end of option (Must be set to 1 for the last Option)
- A bit: AND bit, if set the operation between several [option/value] is AND, if unset the operation is a logical OR. Never set for the first Option
- Len: If 0 the following value is encoded in 1 byte ; if 1 the following value is encoded in 2 bytes
- NOT bit: logical negation operation between Data and the given value
- m bit: match operation between the Data and the given value
Type 10: パケット長(Packet Length component)
Type 11: DSCP(DSCP Value component)
Type 12: フラグメント(Fragment component)
フロー定義のあと、アクション(ルール)が拡張コミュニティ(RFC4360)が続きます。
After the flow definition, Traffic Actions (rules) are encoded as Extended Community Attribute (see RFC 4360)
拡張コミュニティのTYPEフィールドに入れる値により4つのアクションが定義されています。
以下に現在有効なアクションを示します。
There are 4 types of “Action”, each of them has a dedicated Extended Community TYPE. The tab below lists the current Actions available:
帯域制御アクション(Traffic-rate action)
このアクションはトラフィックの破棄あるいは帯域制御に用いられます。
破棄は帯域制御のレートを0にします。
4オクテットのレート情報はIEEEの浮動小数点フォーマットにより指定します。
このフォーマット変換には
http://www.h-schmidt.net/FloatConverter/IEEE754.html
が役に立つでしょう。
Used for discard or rate-limit a specific flow. Discard action is actually a rate equal to zero. The remaining 4 octets carry the rate (in Bytes/sec) information in IEEE floating point [IEEE.754.1985] format. A nice link to troubleshoot encoded rate can be find here: http://www.h-schmidt.net/FloatConverter/IEEE754.html
Traffic-action
特定のフロー時を受け取った際の処理を定義します。
現在は6バイト(48ビット)中、2ビットのアクションだけが定義されています。
Used to trigger specific processing the corresponding flow. Only the last 2 Bits of the 6 bytes are currently defined as following:
- Terminalアクション(47ビット目): このビットがセットされていると
トラフィックフィルタリングエンジンはそれに従った処理を行います。
(この処理ルールは順序だった処理が行われます)
これがセットされていない場合、このルールが適応された処理をそのトラフィックフィルタは行いません。
- Sampleアクション(46ビット目): トラフィックのサンプリングとロギングを行います。
- Terminal Action (bit 47): When this bit is set, the traffic filtering engine will apply any subsequent filtering rules (as defined by the ordering procedure). If not set, the evaluation of the traffic filter stops when this rule is applied.
- Sample (bit 46): Enables traffic sampling and logging for this flow specification.
リダイレクト(Redirect action)
ルータにて特定のVRFにリダイレクトするための
トラフィックを指定したRoute Target情報を含みます。
Traffic redirection allows to specify a “route-target” community which will be handled by the router to redirect a Flow to a specific VRF.
マーキング(Traffic-marking action)
マッチするフローのDSCP値を書き換えます。
Used to force a flow to be re-writted with a specific DSCP value when it leaves the routers.
JUNOSは２つの種類のフロー経路をサポートします。
1)静的なフロー経路は以下のように書きます。
Junos allows 2 kind of Flow Routes. First of all, static flow routes which are configured like this:
#Example: Rate-limiting flow (@IP source 10.1.1.1/32 DNS traffic) at 15Kbits/s
sponge@bob# show routing-options flow
route static-flow1 {
match {
source 10.1.1.1/32;
protocol udp;
port 53;
}
then rate-limit 15k;
}
2)BGPでフローのファミリ(= inetflow.0)を伝達するには以下のように設定します。
この際、バリデーションチェックの無効化をpolicy-statementに記載できます。
(これでLOC-RIBに経路をバリデーションなしに直接インストールすることができます)
BGP flow routes family is configured as following. Associated to the flow family you can add a policy-statement to disable the validation process of the route (allows direct installation of FlowSpec routes in the BGP LOC-RIB and bypass the FLOW SPEC routes validation process described in chapter 1)
[edit protocols bgp]
group FLOWSPEC {
type internal;
local-address 10.1.1.3;
family inet {
unicast;
flow {
no-validate NO-VAIDATION;
}
}
neighbor 10.1.1.2 {
description FS-SERVER;
}
}
[edit policy-options]
policy-statement NO-VAIDATION {
term 1 {
then accept;
}
}
BGPから受信したフロー経路あるいは静的に定義したフロー経路はinetflow.0にインストールされます。
Flow routes (BGP or static) are installed within the table “inetflow.0”.
sponge@bob> show route table inetflow.0 detail
inetflow.0: 1 destinations, 1 routes (2 active, 0 holddown, 0 hidden)
*,10.1.1.1,proto=17,port=53/term:2 (1 entry, 1 announced)
*Flow Preference: 5
Next hop type: Fictitious
Address: 0x904d5e4
Next-hop reference count: 2
State: Active
Local AS: 65000
Age: 38
Validation State: unverified
Task: RT Flow
Announcement bits (2): 0-Flow 1-BGP_RT_Background
AS path: I
AS path: Recorded
Communities: traffic-rate:0:1875
前述のとおり、Next-Hopは常にFictitiousとなります(0がセットされるから)。
フローはn個のタプルで成り立つフロー定義と拡張コミュニティのルールでなっています。
上の例では、ルールは帯域制御であり、この値としてrate=0(つまり破棄)となっています。
As I said previously, Next-Hop is always Fictitious (because it is set to 0). The Flow Specification is encoded in an n-turple (the BGP FLOW routes) and rules as an extended-community. Here, the rule type is traffic-rate used for rate-limiting or discarding (rate=0) a specific flow.
JUNOSはこの経路を firewall-filter(__FlowSpec_default_inet__)にプッシュします。
このフィルタは各PFEにおいてIn/Out方向にインストールされます。
Junos then converts this route on a well-known firewall-filter and pushes the filter update on every PFE in both directions (Input / Output). This Firewall Filter is called “__FlowSpec_default_inet__”.
これはhidden属性フィルタではないのでコマンドで確認することができます。
This is not an hidden filter and you can have access to it via the cli command:
set routing-options flow route test-3 match destination 192.168.101.0/24
set routing-options flow route test-3 match protocol icmp
set routing-options flow route test-3 then discard
set routing-options flow route test-5 match destination 192.168.96.0/22
set routing-options flow route test-5 match protocol icmp
set routing-options flow route test-5 then discard
sponge@bob> show firewall filter __FlowSpec_default_inet__
Filter: __FlowSpec_default_inet__
Counters:
Name Bytes Packets
*,10.1.1.1,proto=17,port=53 0 0
Policers:
Name Bytes Packets
15K_*,10.1.1.1,proto=17,port=53 0 0
フロースペックファイアウォールフィルタの実体は
Firewallフィルタにおける動的なフロー定義とアクションです。
termのfromとして定義されたフローがthenとして定義されたアクションを行うルールとして表示されます。
Actually, flow spec firewall filter is a dynamic FW filter which combines in one FW filter all the Flow Specification routes (as a “from” criteria) and their associated rules (as a “then” criteria). Each route can be view as a term.
FlowSpecファイアウォールフィルタはもっとも最初に適応されるファイアウォールフィルタです。
ですが、定義した別のフィルタをin/out毎にこれより前に適応することもできます。
(set interface xxx family inet filter [input|input-list|output|output-list]を使います。)
FlowSpec firewall filter is always the first Firewall Filter analysed. But, you can use after your own Firewall Filter(s) applied in both directions via the command “set interface xxx family inet filter [input|input-list|output|output-list]”. Your FW filter will be always analyzed first before the flow spec FW filter.
※__FlowSpec_default_inet__をバイパスすることはできません。
また、PFEレベルではinput方向で適応されることに注意してください。
Notice: you can never bypass the “__FlowSpec_default_inet__” filter. Also remember that FLOW SPEC Firewall Filter is applied in input direction at PFE level.
PFE上の__FlowSpec_default_inet__は以下のコマンドで見ることができます。
At PFE Level you can use this command to check how the “__FlowSpec_default_inet__” is programed.
ADPC0(bob vty)# show filter
Program Filters:
---------------
Index Dir Cnt Text Bss Name
-------- ------ ------ ------ ------ --------
[…]
17000 52 0 4 4 __default_arp_policer__
57008 104 288 16 16 __cfm_filter_shared_lc__
65024 104 144 36 36 __FlowSpec_default_inet__
65280 52 0 4 4 __auto_policer_template__
65281 104 0 16 16 __auto_policer_template_1__
[…]
16777216 104 288 36 36 fnp-filter-level-all
ADPC0(bob vty)# show filter index 65024 program
Program Filters:
---------------
Index Dir Cnt Text Bss Name
-------- ------ ------ ------ ------ --------
65024 104 144 36 36 __FlowSpec_default_inet__
Action directory: 2 entries (104 bytes)
0: accept counter 0 policer 0
-> 7:
1: accept
-> 8:(bss location 3:)
Counter directory: 1 entry (144 bytes)
0: Counter name "*,10.1.1.1,proto=17,port=53": 1 reference
Policer directory: 1 entry (176 bytes)
0: Policer name "15K_*,10.1.1.1,proto=17,port=53": 1 reference
Bandwidth Limit: 1875 bytes/sec.
Burst Size: 15000 bytes.
discard
Program instructions: 9 words
0: match protocol != 17 -> 8:
set icmp-type
match source-port == 53 -> 5:
set destination-port
match destination-port != 53 -> 8:
5: match source-address != 0x0a010101 -> 8:
terminate -> action index 0
8: terminate -> action index 1
次のアクションはリダイレクトです。
JUNOSでは、VRFを特定のリダイレクトを実現するためにこのコミュニティを用います。
リダイレクトはIDPと連携した帯域軽減に非常に有用です。
As presented in chapter 1 ; the second useful Action type is “redirect”. A redirect action is also encoded in a specific extended community. In Junos you can then use this specific community to redirect a specific traffic within a VRF. Very useful for traffic mitigation or traffic inspection (IDP).
A flow route with the redirect action example:
sponge@bob> show route 10.1.1.0/30 detail
inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
10.1.1.0,*,proto=17/term:1 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Fictitious
Address: 0x9041484
Next-hop reference count: 1
State: Active Int Ext
Local AS: 65000 Peer AS: 65000
Age: 48
Validation State: unverified
Task: BGP_65000.81.253.192.94+31919
Announcement bits (1): 0-Flow
AS path: ?
AS path: Recorded
Communities: redirect:65000:123456
Accepted
Localpref: 100
Router ID: 81.253.192.94
JUNOSにおける唯一の制限は、トラフィックを軽減/調査するリダイレクト先のサーバが"同じルータ"に接続されていてはならないことです。
なぜなら、JUNOSの実装において、リダイレクトは全てのPFEに対してインストールされます。
トラフィック処理のためにトラフィックがサーバにリダイレクトされ、
再びルータに戻ってくると、(PFEによって再度トラフィックはサーバに戻っていき)トラフィックはloopしてしまいます。
The only limitation on Junos when you redirect traffic is that the server which will be in charge of mitigation or inspection or anything else must not be directly connected to the same router attached to the VRF. Indeed, Junos pushes FlowSpec routes towards all PFE. So if you dynamically redirect a traffic to a server to perform “traffic processing”, the “coming back” traffic will be again redirect and so on… In this configuration you will experience a forwarding loop.
以下の図にこの様子と２つの設計的な回避策を示します。
The diagram below shows this limitation and 2 workarounds (design based).
On Junos traffic redirection is configured as following:
リダイレクションのコンフィグ例:
[edit protocols bgp]
group FLOWSPEC {
type internal;
local-address 10.1.1.3;
family inet {
unicast;
flow {
no-validate NO-VAIDATION;
}
}
neighbor 10.1.1.2 {
description FS-SERVER;
}
}
[edit policy-options]
policy-statement NO-VAIDATION {
term 1 {
from community redirect;
to instance PROCESSING-VRF;
then accept;
}
term 2 {
then accept;
}
}
community redirect members redirect:65000:123456;
[edit routing-instances]
PROCESSING-VRF {
instance-type vrf;
interface ge-2/2/1.0;
route-distinguisher 12.2.2.2:1234;
vrf-target target:65000:123456;
routing-options {
static {
defaults {
resolve;
}
# サーバがVRFに直接接続されている場合の宛先(DEFAULT)
# DEFAULT route if Server in charge of processing traffic is directly attached
# to the VRF
route 0.0.0.0/0 next-hop 10.128.2.10;
}
}
}
