Applying Routing Policies

protocols {
     rip {

          import [ policy1 policy2 …];

          group test {
               export [ policy1 policy2 …];

               neighbor fe-0/0/2.0 {
                    import [ policy1 policy2 …];
               }
          }
     }
}

protocols {
     isis {

          export [ policy1 policy2 … ];

     }

     ospf {

          export [ policy1 policy2 … ];

     }

}

OSPF configuration

 Example

[edit protocols ospf]
       user@Chablis# set area 0 interface all
       user@Chablis# set area 0 interface fxp0 disable

[edit protocols ospf]
user@Chablis# show
       area 0.0.0.0 {
              interface all;
              interface fxp0.0 {
                     disable;
       }
}

или на каждый интерфейс

protocols {
    ospf {
        area 0.0.0.0 {
            interface em0.0;
            interface em4.0;
        }
        area 0.0.0.1 {
            interface em1.0;
        }
    }
}

OSPF theory concept

Common Packet Header

RIP configuration

Таймеры протокола

• Update timer — частота отправки обновлений протокола, по истечению таймера отправляется обновление. По умолчанию равен 30 секундам.
• Invalid timer — Если обновление о маршруте не будет получено до истечения данного таймера, маршрут будет помечен как Invalid, то есть с метрикой 16. По умолчанию таймер равен 180 секундам.
• Flush timer (garbage collection timer) — По умолчанию таймер равен 240 секундам, на 60 больше чем invalid timer. Если данный таймер истечет до прихода обновлений о маршруте, маршрут будет исключен из таблицы маршрутизации. Если маршрут удален из таблицы маршрутизации то, соответственно, удаляются и остальные таймеры, которые ему соответствовали.
• Holddown timer — Запуск таймера произойдет после того, как маршрут был помечен как не достижимый. До истечения данного таймера маршрут будет находиться в памяти для предотвращения образования маршрутной петли и по этому маршруту передается трафик. По умолчанию равен 180 секундам. Таймер не является стандартным, добавлен в реализации Cisco.

Routing Policy basic concept

 Composing a Routing Policy

The application of a routing policy is always performed from the perspective of the routing table. Routes being placed into the routing table are said to be “inbound.” 

Routes being extracted from the routing table are said to be “outbound.”

Policy Processing

Each policy contains three possible results:

• accept
• reject
• next policy

Preference Values and Load Balancing

Load Balancing

Hierarchical concept

Routing tables

JUNOS software Routing Tables

The JUNOS software provides multiple routing tables that are used to store routes for your network. Each table is represented within the output of the show route command. The software provides default tables that the operating system builds on an as-needed basis. Each of the default tables contains separate route information.

inet.0
inet.1
inet.2
inet.3
inet.4
inet6.0
mpls.0
bgp.l3vpn.0
bgp.l2vpn.0

Configured Routes. Aggregated, Generated, Martians.

Static Routes

A static route within the JUNOS software is a route to a destination with an assigned next hop.
If we want to place the route into the routing table, the next hop must be valid. This means that the router is able to forward packets using the next hop.

Иерархический концепт

routing-options {
   static {
      defaults {
         static-options;
      }
      route destination-prefix {
         next-hop next-hop;
         qualified-next-hop address {
            metric metric;
            preference preference;
         }
         lsp-next-hop lsp-name {
            metric metric;
            preference preference;
         }
         static-options;
      }
   }
}

Standart Commands, debug, show and test

QSG for work with junipers at cli:

Приводим  cli в привычный рабочий формат

root> set cli terminal vt100

Переходим в конфигурационный режим

root> configure