PyRIFier-Auto: Helpful automation script to keep your JunOS prefix-lists up-to-date based on RIPE database content

 I completely forgot to publish this update! Fixing it now. Two months ago I made a PyEZ script for my friends from ISP where I was working in the past. This script is based on script from JUNOS Automation Cookbook by Adam Chappell.  PyEZ RIPE Filter Automation, hence I gave it a name "PyRIFier-Auto". This is a simple Python RIPE database parsing tool that finds all routes for AS or AS-SET object and updates JunOS prefix list. It can be useful as cron based tasks to update your filters automatically. Below you can find example of usage:

usage: pyrifier-auto_0.1.3.py [-h] -t router -l prefix-list [-p port]

                              [-u username] [-k keyfile] -n as-set [-d]

Python RIPE Database Parsing Tool That Finds All ROUTES for AS or AS-SET and

Updates JUNOS Prefix Lists

optional arguments:

  -h, --help      show this help message and exit

  -t router       Target router to connect

  -l prefix-list  prefix-list name

  -p port         NETCONF TCP port, default is 830

  -u username     Remote username

  -k keyfile      Path to ssh key file, default is ~/.ssh/id_rsa

  -n as-set       BGP AS or AS-SET to resolve into corresponding routes

  -d              clear/delete prefix list before updating with new data

user@scripts:~$ ./pyrifier-auto.py -t 172.16.1.253 -l PL_TEST -n AS51144

[edit policy-options]

    prefix-list PL_SOME { ... }

+   prefix-list PL_TEST {

+       91.216.167.0/24;

+   }

The only supported authentication method so far is SSH key-based authentication. 

Repository is published on github: https://github.com/enk37/PyRIFier-Auto

Hope it helps somebody, will be happy to know this.

Mikrotik RouterOS BGP peer processing serialization

 I've been testing Mikrotik RouterOS BGP implementation recently and noticed very interesting and behavior. Unlike other common network operation systems like Cisco IOS-XE, IOS-XR or Juniper JunOS, RouterOS establishes BGP peering with it's peers one by one every 5 seconds and this timer can not be adjusted. It does not depend on BGP keepalive/hold timers, number of prefixes advertised from the peers or number of peers according to my testing. It does not depend on number of CPUs allocated for VM (or available on hardware router) at least in the current 6.x versions. For example:

[admin@R1] /routing bgp peer> print status interval=10

Flags: X - disabled, E - established 

 0 E name="peer1" instance=default remote-address=192.168.100.2 remote-as=65000 tcp-md5-key=">

     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default 

     in-filter="" out-filter="" address-families=ip default-originate=never 

     remove-private-as=no as-override=no passive=no use-bfd=no remote-id=192.168.100.2 

     local-address=192.168.100.1 uptime=2m5s prefix-count=5000 updates-sent=0 

     updates-received=5000 withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m 

     used-hold-time=3m used-keepalive-time=1m state=established 

 1 E name="peer2" instance=default remote-address=192.168.100.3 remote-as=65000 tcp-md5-key=">

     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default 

     in-filter="" out-filter="" address-families=ip default-originate=never 

     remove-private-as=no as-override=no passive=no use-bfd=no remote-id=192.168.100.3 

     local-address=192.168.100.1 uptime=2m prefix-count=5000 updates-sent=0 

     updates-received=5000 withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m 

     used-hold-time=3m used-keepalive-time=1m state=established 

 2 E name="peer3" instance=default remote-address=192.168.100.4 remote-as=65000 tcp-md5-key=">

     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default 

     in-filter="" out-filter="" address-families=ip default-originate=never 

     remove-private-as=no as-override=no passive=no use-bfd=no remote-id=192.168.100.4 

     local-address=192.168.100.1 uptime=1m55s prefix-count=5000 updates-sent=0 

     updates-received=5000 withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m 

     used-hold-time=3m used-keepalive-time=1m state=established 

 3 E name="peer4" instance=default remote-address=192.168.100.5 remote-as=65000 tcp-md5-key=">

     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default 

     in-filter="" out-filter="" address-families=ip default-originate=never 

     remove-private-as=no as-override=no passive=no use-bfd=no remote-id=192.168.100.5 

     local-address=192.168.100.1 uptime=1m50s prefix-count=5000 updates-sent=0 

     updates-received=5000 withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m 

     used-hold-time=3m used-keepalive-time=1m state=established 

 4 E name="peer5" instance=default remote-address=192.168.100.6 remote-as=65000 tcp-md5-key=">

     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default 

     in-filter="" out-filter="" address-families=ip default-originate=never 

     remove-private-as=no as-override=no passive=no use-bfd=no remote-id=192.168.100.6 

     local-address=192.168.100.1 uptime=1m45s prefix-count=5000 updates-sent=0 

     updates-received=5000 withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m 

     used-hold-time=3m used-keepalive-time=1m state=established

All peers are the same traffic generator advertising 5000 prefixes. BGP instance on RouterOS is enabled and then it starts to process peers one by one. Note exact 5 second difference between peers in the uptime field.

This was tested with 6.45.9 and 6.47 software versions. Unfortunately, I was not able to try 7.1beta2 currently available (apparently, there were some improvements in BGP for multi-core/CPU systems according to release notes). 

7.1beta2 I've installed as CHR and requested 60 day trial with unlimited functionality, but unlike 6.x, I cannot enable any other packages except routeros itself, hence BGP is not available for testing there. If you have any idea on how to enable BGP on 7.0beta7 or never, let me know. Appreciate in advance.

How to solve ISE "Application Server not running" problem in EVE-NG

Sometimes you may face with situation when ISE Application Server fails to start and you may see the following situation when checking show application status ise output:

Usual tricks like application stop ise followed by application start ise safe or application reset-config ise won't help.  What's next? Re-image? No, not yet. No matter how many times you reload the ISE or wipe/redeploy your instance, state will persist. 

So, how to fix? First of all, check interface status first with show interface and you may see that interface does not have address assigned for some reason despite that it is presented in the configuration and interface is not shutted down:

Note that for me it happened only in case if ISE connected to network type "Cloud". So your fix will typical "shutdown/no shutdown":

After this, just execute usual application start ise and ISE will start normally:

Finally check the status again after few couple of minutes with command show application status ise and you will see that ISE processes are running:

I'll be glad to know if it helped somebody, leave comments please.

Cheers!