Policy and filter. Как это работает на оборудовании Juniper

В данной статье будет рассмотрено два механизма для обработки трафика, средствами Junos OS на оборудовании Juniper.
Первое это firewall filter, второе Policy.
Фильтры и политики широко применяются в процессе управления трафиком в сетях, служат различным целям, и подходят для разных ситуаций.
Фильтр это механизм применимый для фильтрации пакетов, на входе в маршрутизатор, и выполнения определённых действий. Чаще всего это пустить, не пустить ( отбросить ) пакет, в зависимости от выбранных свойств пакета, также для применения механизмов называемых filter based routing (fbr) посредством которого представлен механизм policy based routing в Junos.
Политики используются для управления маршрутами на сети, изменения стандартного поведения протоколов динамической маршрутизации.

Приведем простейший пример фильтра, дабы можно было представить как выглядит его структура.
!
lab@mxA-1# show firewall filter test
interface-specific;
term 1 {
from {
protocol udp;
}
then {
count test;
discard;
}
}
term 2 {
then accept;????
}

[edit]
lab@mxA-1#
!

в приведенном примере показан фильтр, который считает и отбрасывает все пакеты, полученные по протоколу udp, но принимает все другие пакеты. Все фильтры делятся на части, называемые term. Каждый term имеет свое название (например 1,2,3 или protocol_UDP ), содержит свой набор действий, применимых к пакету. Сначала, после параметра from, выставляется условие, в нашем случае это prtocol udp. Потом указывается действие, которое необходимо выполнить при выполнении заданного условия, т.е. посчитать ( count test ) и отбросить ( discard ). В фильтре так же содержится второй term, который вступает в действие, в случае невыполнения условий, заданных в первом term.
Об этом надо сказать подробнее. Все фильтры и политики состоят из частей, называемых term. Каждый терм содержит условия совпадения и действия, которые надо выполнить в результате совпадения условий. Все term выполняются строго по порядку, до выполнения одного из действий. Как только у нас сработал один из term фильтр или политика прекращает свою работу. Для того что бы выполнить несколько term подряд, необходимо добавить специальное действие: «next term»
!
nagru# show firewall filter test
term 1 {
from {
source-address {
192.168.1.230/32;
}
protocol udp;
}
then {
count test;
next term;
}
}
term 2 {
then accept;
}

[edit]
nagru#
!
В данном случае у нас будут работать оба term даже в случае выполнения условия в первом term.
Если более детально рассмотреть команду from то можно получить список условий, соответствие которым ставить фильтр:
!

nagru# set firewall filter test term 1 from ?
Possible completions:
> address Match IP source or destination address
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> destination-address Match IP destination address
+ destination-port Match TCP/UDP destination port
+ destination-port-except Do not match TCP/UDP destination port
> destination-prefix-list Match IP destination prefixes in named list
+ dscp Match Differentiated Services (DiffServ) code point
+ dscp-except Do not match Differentiated Services (DiffServ) code point
+ esp-spi Match IPSec ESP SPI value
+ esp-spi-except Do not match IPSec ESP SPI value
first-fragment Match if packet is the first fragment
+ forwarding-class Match forwarding class
+ forwarding-class-except Do not match forwarding class
fragment-flags Match fragment flags (in symbolic or hex formats) — (Ingress only)
+ fragment-offset Match fragment offset
+ fragment-offset-except Do not match fragment offset
+ icmp-code Match ICMP message code
+ icmp-code-except Do not match ICMP message code
+ icmp-type Match ICMP message type
+ icmp-type-except Do not match ICMP message type
> interface Match interface name
+ interface-group Match interface group
+ interface-group-except Do not match interface group
> interface-set Match interface in set
+ ip-options Match IP options
+ ip-options-except Do not match IP options
is-fragment Match if packet is a fragment
+ packet-length Match packet length
+ packet-length-except Do not match packet length
+ port Match TCP/UDP source or destination port
+ port-except Do not match TCP/UDP source or destination port
+ precedence Match IP precedence value
+ precedence-except Do not match IP precedence value
> prefix-list Match IP source or destination prefixes in named list
+ protocol Match IP protocol type
+ protocol-except Do not match IP protocol type
service-filter-hit Match if service-filter-hit is set
> source-address Match IP source address
+ source-port Match TCP/UDP source port
+ source-port-except Do not match TCP/UDP source port
> source-prefix-list Match IP source prefixes in named list
tcp-established Match packet of an established TCP connection
tcp-flags Match TCP flags (in symbolic or hex formats)
tcp-initial Match initial packet of a TCP connection
+ ttl Match IP ttl type
+ ttl-except Do not match IP ttl type
[edit]
!

Можно заметить что мы можно сделать отбор по широкому спектру параметров ip пакета, на которые можно настроить наш фильтр, для выполнения определенных действий. Таким образом можно очень гибко настроить фильтрацию трафика на порту устройства, задав необходимые критерии отбора. Останавливаться на каждом подробно нет смысла, каждый инженер сам знает какие критерии ему нужны.

Теперь рассмотрим возможные варианты действий над выбранными нами пакетами:
!
nagru# set firewall filter test term 1 then ?
Possible completions:
accept Accept the packet
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
count Count the packet in the named counter
> discard Discard the packet
forwarding-class Classify packet to forwarding class
log Log the packet
loss-priority Packet's loss priority
next Continue to next term in a filter
packet-mode Bypass flow mode for the packet
policer Name of policer to use to rate-limit traffic
port-mirror Port-mirror the packet
> reject Reject the packet
> routing-instance Packets are directed to specified routing instance
sample Sample the packet
service-accounting Count the packets for service accounting
service-filter-hit Marked when packet processing by the current type of chained filters is done, the packet is directed to the next type of filters
syslog System log (syslog) information about the packet
topology Packets are directed to specified topology
virtual-channel Set the output interface virtual channel
[edit]
!

Как видно из примера, возможных действий меньше чем возможных критериев отбора. Остановимся на основных из них:
discard — отброс пакета, без отсылки ICMP уведомления.
reject — отброс пакета с отсылкой ICMP уведомления
count filename — посчитать пакет с записью в специально создаваемый файл.
log — залогировать пакет в файл логирования
policer policer name — данная функция используется для ограничения полосы пропускаемого трафика на интерфейсе. Может применяться как на входящий трафик так и на исходящий. Для этого необходимо создать специальный параметр policer:
!
nagru# show firewall policer test
if-exceeding {
bandwidth-limit 1024000000;
burst-size-limit 10k;
}
then discard;

[edit]
!

В данном случае мы поставили ограничение на 1 Гбит/с. Данный синтаксис показывает пример настройки, ограничивающей полосу пропускания.
forwarding-class — данный параметр применяется при использовании механизмов шейпинга трафика на порту и настройки QoS политик. Этот материал не рассматривается в этой статье.
syslog — данный параметр дает возможность произвести запись в syslog о выбранном нами пакете.
port-mirror - позволяет произвести обработку механизма зеркалирования трафика на порту.

Теперь рассмотрим механизмы filter based routing.
Приведем пример настройки функционала fbr:
!
nagru# show firewall filter fbr
term 1 {
from {
address {
10.10.10.1/30;
}
}
then {
routing-instance fbr;
}
}
term 2 {
then accept;
}

[edit]
nagru#

nagru# show routing-instances fbr
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.10.15.1;
}
}

[edit]
nagru#

nagru# show routing-options
interface-routes {
rib-group fbr;
}
rib-groups {
fbr {
import-rib [ inet.0 fbr.inet.0 ];
}
}

[edit]
!


В данной конфигурации мы изменили маршрутизацию пакетов,приходящих с источника 10.10.10.1.
По умолчанию все пакеты приходящие на маршрутизатор от источника 10.10.10.1 проходят через общие правила маршрутизации настроенные на коробке.
Допустим мы хотим изменить движение трафика от данного источника направив его через оборудование с адресом: 10.10.15.1.

Для этого необходимо создать специальный фильтр, который выполняет действие:
!
}
then {
routing-instance fbr;
}
!

т.е. при выполнении условия, наш трафик помещается в специальный vrf, который используется для форвардинга пакетов.
Далее в данном vrf создается статический маршрут по умолчанию, используемый для маршрутизации пакетов к другому получателю, т.е. 10.10.15.1.

Теперь самое интересное. В нашем vrf отсутствует маршрут до 10.10.15.1, и соответственно маршрутизатор не знает куда направлять пакеты. Для того что бы исправить ситуацию мы осуществим последнюю настройку с помощью функционала rib-groups.

Что бы понять смысл конфигурации, надо объяснить что такое функционал rib-groups.

Каждое устройство под управлением Junos OS ведет несколько таблиц маршрутизации, таких как например inet.0 inet.3 vrf.inet.0. В разных таблицах содержатся различная маршрутная информация.Например:

  • в inet.0 содержится основная (глобальная) информация о маршрутах на устройстве.
  • в таблице inet.3 содержится информация о маршрутах используемых протоколом BGP для передачи информации о MPLS метках внутри сети.
  • под каждый vrf создается своя таблица маршрутизации vrf.inet.0.

С помощью функционала rib-groups возможно осуществить перенос маршрутов из одной таблицы маршрутизации в другую.
В нашем примере мы взяли все маршруты локально назначенные на наших интерфейсах, и поместили их в таблицу маршрутизации vrf fbr.
!
nagru# show routing-options
interface-routes {
rib-group fbr;
}
rib-groups {
fbr {
import-rib [ inet.0 fbr.inet.0 ];
}
}
!

Теперь наш маршрут по умолчанию сможет направить пакеты по заданному пути.

Существует еще одна функция при настройке фильтров:
!
interface-specific;
!

Данная команда включает режим, при котором каждый фильтр будет вести учет относительно того интерфейса, на который его применили, динамически создавая отдельные счетчики для него, а не используя один счетчик для всех интерфейсов.

Это все что касается фильтров и механизмов fbr на оборудовании Juniper Network.

Теперь перейдем к рассмотрению механизмов работы policy на оборудовании Juniper Network.

покажем общую структуру policy:
!
nagru# show policy-options
policy-statement test {
term 1 {
from community 65400:2000;
then as-path-prepend 65400;
}
term 2 {
from {
prefix-list list1;
}
then {
community add 65400:3000;
}
}
}

[edit]
nagru#
!

Как видно из примера, policy так же как и фильтр состоит из частей, называемых term. Каждый term содержит условия совпадения и действия, выполняемые в результате совпадения условий.
Политики являются очень гибким механизмом для осуществления маршрутизации пакетов, и применяются уже не на интерфейс, а в самых различных местах в конфигурации оборудования Juniper Network. Например целиком к таблице forwarding table, или к какому либо протоколу, на входе или выходе из vrf.
В приведенном выше примере политика состоит из двух term, в случае выполнения условия в основном term, перехода к следующему не будет осуществлено, так же обстоит дело и в цепочке политик.
Если в каком либо разделе конфигурации присутствует цепочка политик, состоящая из двух или трех штук, к примеру, то при выполнении одной из политик перехода к следующей не будет осуществлено если не указать специальное действие:
!
policy-statement test {
term 1 {
then next policy;
}
}
!

тогда при выполнении нашей политики, произойдет переход к следующей политике в цепочке.

Наша политика, показанная вначале, проверяет, отмечен ли маршрут специальным community или нет, если да то она выполняет установку в параметр AS-PATH протокола BGP один препенд значением 65400. Если же это условие не выполняется тогда мы переходим ко второй части политики, которая, отбирая маршруты по prefix-list назначает им определенное community.

Рассмотрим варианты условий в политике:
!
nagru# set policy-options policy-statement test from ?
Possible completions:
aggregate-contributor Match more specifics of an aggregate
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
area OSPF area identifier
+ as-path Name of AS path regular expression (BGP only)
+ as-path-group Name of AS path group (BGP only)
color Color (preference) value
color2 Color (preference) value 2
+ community BGP community
> community-count Number of BGP communities
+ condition Condition to match on
> external External route
family
instance Routing protocol instance
+ interface Interface name or address
level IS-IS level
local-preference Local preference associated with a route
metric Metric value
metric2 Metric value 2
metric3 Metric value 3
metric4 Metric value 4
> multicast-scope Multicast scope to match
+ neighbor Neighboring router
+ next-hop Next-hop router
next-hop-type Next-hop type
origin BGP origin attribute
+ policy Name of policy to evaluate
preference Preference value
preference2 Preference value 2
> prefix-list List of prefix-lists of routes to match
> prefix-list-filter List of prefix-list-filters to match
+ protocol Protocol from which route was learned
rib Routing table
> route-filter List of routes to match
route-type Route type
> source-address-filter List of source addresses to match
state Route state
+ tag Tag string
tag2 Tag string 2
[edit]
nagru# set policy-options policy-statement test from
!

Мы видим что выбор условий для работы политики довольно большой, что, как я уже и говорил дает очень гибкий инструмент для операций над маршрутами. Описывать подробно каждый атрибут не имеет смысла, все зависит от целей нашей политики и от уровня знаний каждого специалиста. Лучше рассмотреть какие действия можно совершить после отбора.
!
nagru# set policy-options policy-statement test then ?
Possible completions:
accept Accept a route
> aigp-originate Originate a BGP AIGP attribute
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> as-path-expand Prepend AS numbers prior to adding local-as (BGP only)
as-path-prepend Prepend AS numbers to an AS path (BGP only)
class Set class-of-service parameters
> color Color (preference) value
> color2 Color (preference) value 2
> community BGP community properties associated with a route
cos-next-hop-map Set CoS-based next-hop map in forwarding table
damping Define BGP route flap damping parameters
default-action Set default policy action
> external External route
forwarding-class Set source or destination class in forwarding table
> install-nexthop Choose the next hop to be used for forwarding
label-allocation Set label allocation mode
> load-balance Type of load balancing in forwarding table
> local-preference Local preference associated with a route
> map-to-interface Set output logical interface
> metric Metric value
> metric2 Metric value 2
> metric3 Metric value 3
> metric4 Metric value 4
next Skip to next policy or term
> next-hop Set the address of the next-hop router
origin BGP path origin
> preference Preference value
> preference2 Preference value 2
priority Set priority for route installation
reject Reject a route
+ ssm-source List of Sources for SSM mapping
> tag Tag string
> tag2 Tag string 2
trace Log matches to a trace file
!

Рассмотрим по порядку:

accept — самое важное действие: принять маршрут, после выпонения какого либо условия необходимо установить маршрут в таблицу машрутизации. Для этого и нужен accept.
as-path-expand — установить препенды в параметр AS-PATH до того как добавить собственный номер AS.
as-path-prepend — добавить препенды в параметр AS-PATH
class параметры QOS
community совершить какое либо действие над BGP community
default-action — установить действие по умолчанию.
external пометить маршрут как внешний. Данная функция помечает маршрут как внешний, что дает возможность изменить ход алгоритмов выбора активного маршрута, не в пользу данного маршрута, так как внутренний маршрут более приоритетен по отношению к внешнему.
install-nexthop изменить параметры аттрибута next-hop для маршрута, что позволить изменить направление маршрутизации трафика на устройстве. В качестве next-hop можно выбрать адрес next hop, который нужно использовать, или который нельзя использовать, так же можно указать определенную MPLS LSP например для балансировки трафика.
load-balance установить тип балансировки трафика: пакетная ( per packet ). В случае осуществления балансировки трафика по двум и более линкам/маршрутам будет осуществляться балансировка случайным образом каждый пакет в свой линк/ свой маршрут.
local-preference - изменить параметр Local Preference который влияет на выбор активного маршрута на маршрутизаторе. Чем выше параметр тем больше вероятность выбора данного маршрута активным.
map-to-interface — поменять интерфейс назначения, в который будет передаваться маршрут.
next-hop поменять значение next-hop маршрутизатора в маршруте. Часто используется для создания политики next-hop-self для BGP. В качестве next-hop мы можем указать как адрес маршрутизатора, так и сказать что пакеты надо отбросить, так же можно указать что next-hop lookup находится в определенной таблице маршрутизации.
reject — отбросить маршрут, так же как и в фильтре.
forwarding-class, source-class, destination-class — варианты используемые для подсчета статистики пакетов по тем или иным критериям.

Механизм использования функционала community.
Community — специальный аттрибут используемый протоколом BGP, который передается между AS при маршрутизации, т.е. соответственно может быть передан между сетями разных организаций, для управления маршрутизацией между этими организациями.
Существует два наиболее часто применимых общепринятых community:
no-export — не анонсировать данный маршрут всем eBgp соседям
no-advertize — не анонсировать данный маршрут никаким BGP соседям.

Так же любой провайдер услуг, может создать список своих личных community которые при назначении на маршрут будут выполнять определенные действия. Например не анонсироваться определенным upstream или анонсироваться только определенным upstream, будет производиться определенный подсчет статистики согласно этим значениям, или например применять специализированный механизм CoS для определенного типа трафика, когда сам провайдер не хочет вмешиваться в процесс маршрутизации а оставляет все на откуп клиенту.
Community можно:
!
nagru# set policy-options policy-statement test then community?
Possible completions:
<community_name> Name to identify a BGP community
+ Add BGP communities to the route
- Remove BGP communities from the route
= Set the BGP communities in the route
add Add BGP communities to the route
delete Remove BGP communities from the route
set Set the BGP communities in the route
[edit]
nagru# set policy-options policy-statement test then community
!

Добавить, удалить и соответственно установить. Например на входе можно удалить все лишние community которые клиент вам анонсирует. Так же параметр community может упростить конфигурацию оборудования, путем назначения данного параметра на новых подключениях клиентов, например, а политика обработки не будет изменяться, и через нее будет проходить все новый и новый трафик.

Так же хотелось бы в конце описать простую политику которая очень часто применяется в маршрутизации: экспорт, импорт маршрутов между протоколами. Часто необходимо отдать статический маршрут куда нибудь в BGP или IGP или передать маршруты между BGP и IGP.
Для этого в условии соответствия выбирается необходимый протокол:
!
set policy-options policy-statement test from protocol?
Possible completions:
[ Open a set of values
access Access server routes
access-internal Internal routes to directly connected clients
aggregate Aggregate routes
bgp BGP
direct Directly connected routes
dvmrp Distance Vector Multicast Routing Protocol
esis End System-to-Intermediate System
isis Intermediate System-to-Intermediate System
l2circuit Layer 2 circuits
l2vpn Layer 2 MPLS virtual private networks
ldp Label Distribution Protocol
local Local system addresses
msdp Multicast Source Discovery Protocol
ospf Open Shortest Path First
ospf2 Open Shortest Path First Version 2
ospf3 Open Shortest Path First Version 3
pim Protocol Independent Multicast
rip Routing Information Protocol
ripng Routing Information Protocol next generation
rsvp Resource Reservation Protocol
rtarget Local route target VPN membership
static Statically defined addresses
[edit]
!

Выбор протоколов довольно большой. Когда мы указали откуда будет импортироваться маршрут например: static. Далее следует просто выбрать действие: accept и присвоить эту политику на импорт или на экспорт к протоколу, в который следует произвести импорт маршрутов, или экспорт.
!
show policy-options
policy-statement test {
from protocol static;
then {
accept;
}
[edit]
!

На этом можно закончить базовые знания по политикам и фильтрам на оборудовании Juniper Network.