Tag Archives: Count

Notas estudo JNCIA-Junos parte 5

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