Routing Policy
| (Routes/Protocols) Import Policies | —–> Routing table —–> | Export Policies (Routes/Protocols) |
| | | | v Forwarding |
| Protocol |
Import Policy | Export Policy |
| BGP | Aceita/importa todas as rotas BGP para inet.0 | Aceita todas as rotas BGP activas |
| OSPF | Aceita/importa todas as rotas OSPF para inet.0 | Rejeita tudo (protocol floods by default) |
| IS-IS | Aceita/importa todas as rotas IS-IS para inet.0 | Rejeita tudo (protocol floods by default) |
| RIP | Aceita todas as rotas do neighbors explicitamente confgiurados e importa para inet.0 | Rejeita tudo |
Não é possível no OSPF através de uma policy parar o advertisement de LSAs, ou mesmo filtrar as rotas internas (incluindo inter-area) da tabela de routing. Mas é possível filtrar rotas externas.
Apesar de “rejeita tudo” na Export Policy o router continua a enviar LSAs, a policy não permite o envio de rotas adicionais com origem em outras sources.
Permite config import/export policys ao nível do protocolo ou neighbor
As routing policys contem um conjuntos de terms, estes são analisados sequencialmente. Quando e feito o match (from) são executadas as instruções em “then” e a policy termina de ser analisada com a “terminating action” não analisando o seguinte “term“.
As Control Actions para aceitar/rejeitar rotas são:accept/reject ambas são “terminating actions”
Ẽ possível usar o comando insert para alterar a ordem de um “term”
insert policy-options policy-statement OUT-RIP term ospf-to-rip-1 {after|before} term ospf-to-rip
policy-options {
policy-statement OUT-RIP {
term ospf-to-rip-1 {
from protocol ospf;
then accept;
}
term ospf-to-rip {
from protocol ospf;
then accept;
}
}
Caso seja omitido o “from” da policy ẽ aplicado a todas as rotas a action do respectivo “then” subsequente
prefix-list – faz o match exacto do prefix
prefix-list-filter – permite match de types e actions. Match types: exact, longer,orlonger
No polic2 após match ẽ executada a ação (opcionalmente se configurada, não sendo usado o “then“)
policy-options {
prefix-list filter-rfc1918 {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/24;
}
policy-statement polic {
from {
prefix-list filter-rfc1918;
}
then reject;
}
policy-statement polic2 {
from {
prefix-list-filter filter-rfc1918 longer reject;
}
}
}
Router Filters
Os route filters não são passiveis de reutilizar ao contrario dos prefix-list, estes permitem uma maior granularidade por prefix
Match Type:
exact
from route-filter 192.168.1.0/24
longer
from route-filter 192.168.1.0/24 longer
orlonger
from route-filter 192.168.1.0/24 orlonger
upto
from route-filter 192.168.1.0/24 upto /29
prefix-length-range
from route-filter 192.168.1.0/24 prefix-length-range /27-/30
Common Actions
O accept e reject são considerados “terminating actions” porque permitem a paragem do evaluate da policy
Os “nonterminating” default-action accept e default-action reject não causam a paragem do evaluate da policy, mas prevalecem sob a default policy accept/reject
Outros termos comuns são o “next term” e “next policy“, designados de Flow-control
Firewall Filters
Os filtros são stateless, não guardam os estado das ligações
Discard explicito by default
Common Actions
Terminating actions: accept,discard,reject
Flow control: next term
Action modifiers:
count.log e syslog – hits
forwarding-class e loss-priority – especificar Class of service (CoS)
policer – policiamento
O next term ẽ útil caso seja necessário definir um policer ou valor DiffServ code point (DSCP), não existe a ação “next filter”
Caso seja especificado uma action modifier, está implícito a action accept
interfaces {
em5 {
vlan-tagging;
unit 121 {
vlan-id 121;
family inet {
filter {
input IN;
output OUT;
}
address 10.10.121.4/24;
}
}
}
}
firewall {
family inet {
filter IN {
term ACCEPT_ALL {
then {
log;
accept;
}
}
}
filter OUT {
term ACCEPT_ALL {
from {
icmp-type echo-reply;
}
then accept;
}
term ACCEPT_ALL_ {
from {
icmp-type echo-request;
}
then {
log;
discard;
}
}
term ACCEPT_ALL_2 {
then accept;
}
}
}
}
Filtering Local
Os filtros influenciam o tráfego do Control plane, portanto cuidado!
Policing
Os firewall filters permitem policing ou rate-limit. Se o primeiro termo não tiver a clausula “from” todos os pacotes da interface (input output) são alvo de policing
Ẽ possível aplicar policers diretamente nas interfaces
O policing usa o algoritmo token bucket, que faz o enforcing de um limite na average bandwidth enquanto permite burst atẽ um valor máximo especificado
São configurados 2 rate-limits, bandwidth/maximum burst size
The preferred method for determining the maximum burst size is to multiply the speed of the interface by the amount of time
bursts that you want to allow at that bandwidth level. For example, to allow bursts on a Fast Ethernet link for 5 milliseconds (a reasonable value), use the following calculation:
burst size = bandwidth (100,000,000 bits per sec) x allowable burst time (5/1000s)
This calculation yields a burst size of 500,000 bits. You can divide this number by 8 to convert it to bytes, which gives you a
burst size of 62500 bytes.
bandwidth-limit bandwidth-in-bits
burst-size-limit burst-in-bytes
Quando ẽ feito o evaluate da police, caso não exceda e executada a ação “then” do firewall filter. Caso exceda é executada a ação da police
set firewall family inet filter rate-limit-subnet term match-subnet from source-address 192.100.1.0/24
set firewall family inet filter rate-limit-subnet term match-subnet then policer p1
set firewall family inet filter rate-limit-subnet term else-accept then accept
set firewall policer p1 if-exceeding bandwidth-limit 100k
set firewall policer p1 if-exceeding burst-size-limit 20k
set firewall policer p1 then discard
firewall {
family inet {
filter rate-limit-subnet {
term match-subnet {
from {
source-address {
192.100.1.0/24;
}
}
then policer p1;
}
term else-accept {
then accept;
}
}
}
policer p1 {
if-exceeding {
bandwidth-limit 100k;
burst-size-limit 20k;
}
then discard;
}
}
show firewall counter filter filter-name counter-name
show firewall log
clear firewall filter filter-name
A filter name or a blank space appears if the RE handles the packet. Otherwise, a dash ( – ) or pfe appears instead of the filter name to indicate
that the packet was handled by the PFE. The contents in the firewall log clear when the system reboots.
Automated Antispoofing Filters
Reverse Path-Forwarding
Ẽ possível combinar RPF checks a firewall filters na mesma interface. Activando esta feature o PFE aumenta o consumo de memoria
Strict vs Loose modes
by default usa strict
By default o JunOS verifica apenas active path para o prefix, causando drops quando existem multiplos paths (asymmetric routing). Ẽ possível permitir múltiplos usando set routing-optinos forwarding-table unicast-reverse-path feasible-paths
Fail Filters
By default o RPF faz discard ao tráfego que falha o RPF check, de qualquer forma pode ser especificado um fail filter opcional. Neste filter ẽ possível definir todas as ações e incluindo aceitar o tráfego embora falhe o RPF check. (Para ver o log destes pacotes (RPF check failed) ẽ necessário configurar o log no fail filter)
set interfaces em0 unit 0 family inet rpf-check fail-filter rpf-dhcp
set interfaces em0 unit 0 family inet address 10.1.12.1/24
set interfaces lo0 unit 0 family inet address 10.2.2.2/32
set firewall family inet filter rpf-dhcp term dhcp from source-address 0.0.0.0/32
set firewall family inet filter rpf-dhcp term dhcp from destination-address 255.255.255.255/32
set firewall family inet filter rpf-dhcp term dhcp then accept
Referências:
Notas estudo JNCIA-Junos parte 1
Notas estudo JNCIA-Junos parte 2
Notas estudo JNCIA-Junos parte 3
Notas estudo JNCIA-Junos parte 4