fpc1 vlan-id(32768) to bd-id mapping doesn’t exist in itable

If you are getting this message appearing repeatedly on a Juniper switch (e.g. an EX4300), check you don’t have an IRB interface that is not attached to a VLAN. Alternatively, check your IRBs all have IP addresses.

Restoring data to Netbox Docker

Having just shot myself in the foot by deleting docker and losing a container I had been working on, here is the command to restore data to netbox-docker’s Postgres database:

sudo docker exec -i netbox-docker_postgres_1 psql --username netbox netbox < /path/to/backup/file.sql

Phew…

DHCP Relay Issues With Microsoft Surface Pro Docks and Junos

After deploying some new Juniper EX4600 core switches, my customer complained that he was experiencing about 45 seconds of delay in getting an IP address on a Surface Pro connected to a dock. The second time of connecting, it took about 8 seconds which was more acceptable. The 45 second delay came back every time they moved the Surface Pro to a new dock.

Testing notes: simulating link failure by filtering BFD packets

In some testing I am doing, I need to prove that BFD can be used with iBGP to tell the BGP protocol when there is an interruption.  This will enable BGP to be brought down much faster than if regular BGP timers are used.

To make this easier to do, I used a firewall filter on one of the two routers to filter out BFD but accept all other packets:
Single-hop BFD (i.e. across a link) uses UDP 3784, while multi-hop BFD uses 4784.  Since my BFD sessions are configured between loopbacks, it is this latter type I need to filter.

In the example below, CORE1 is a BGP client of CORE2, which is the route-reflector.

The following was configured on the routers to bring up the BFD session (I am only showing one side – you can figure out the mirror of this yourself I think):

[edit protocols bgp group CORE neighbor 10.0.0.6]
      bfd-liveness-detection {
          minimum-receive-interval 300;
          multiplier 3;
          transmit-interval {
              minimum-interval 100;
          }
      }

When the remote side was done, the session came up:

axians@CORE1> show bfd session
Dec 28 17:17:10
                               Detect Transmit
Address       State Interface  Time   Interval  Multiplier
10.0.0.6      Up              0.900     0.300        3

To bring down the BFD session, apply the following filter outbound on the core-facing interface(s):

axians@CORE1# show | compare rollback 2
Dec 28 17:23:33
[edit interfaces ae1 unit 0 family inet]
  filter {
    output BLOCK-BFD;
  }
[edit firewall family inet]
  filter BLOCK-BFD {
    term T1 {
      from {
        protocol udp;
        port 4784;
      }
      then {
        discard;
      }
    }
    term T2 {
      then accept;
    }
}

As soon as the filter is applied, BFD times-out and brings down the BGP session:

Dec 28 17:39:13 CORE2 bfdd[1935]: %DAEMON-4: BFD Session 10.0.0.2 (IFL 0) state Up -> Down LD/RD(16/23) Up time:00:06:07 Local diag: CtlExpire Remote diag: None Reason: Detect Timer Expiry.

Dec 28 17:39:13 CORE2 bfdd[1935]: %DAEMON-4-BFDD_TRAP_MHOP_STATE_DOWN: local discriminator: 16, new state: down, peer addr: 10.0.0.2

Shrubbery.net TACACS+ daemon and Junos

Axians Professional Services normally recommends using RADIUS authentication to our customers, but one of our customers uses TACACS.  We did some type-approval testing of new Junos release for them recently and had to set up a TACACS+ daemon in the lab to make sure authentication still worked following the upgrade.

Shrubbery.net very helpfully provide a TACACS+ implementation that you can download to a Linux host for this purpose, but the documentation is a bit light on their website, and what you find using Google is naturally somewhat Cisco-specific.  So here are some notes on getting a basic setup going with Shrubbery’s tac_plus daemon and Junos.  Maybe this will help someone else.

Restoring Space 15.2 data to 16.1

The upgrade from Space platform 15.2 to 16.1 is one of the worst procedures I’ve seen in quite a while.   It is complicated because the underlying CentOS is being upgraded at the same time, so I guess that’s part of the reason, but still, it could be a lot slicker and better tested.

In summary, you have to apply a couple of patches, the second of which backs your 15.2 data up somewhere else – ideally over SCP to a remote server.  You then shut down your 15.2 VM, install a fresh 16.1 VM with the same IP addresses, and restore the data to it.

Sounds easy, but the 16.1 installation part can generally only be done by the customer’s VMware admin because it needs console access.  So you’ve got to rely on them following lots of instructions quite well.

Segment Routing on JUNOS – The basics

Anybody who’s been to any seminar, associated with any major networking systems manufacturer or bought any recent study material, will almost certainly have come across something new called segment routing &…

Source: Segment Routing on JUNOS – The basics

Issuing Junos Commands Using Ansible raw Module

If you want to issue something quick on a lot of devices, you don’t need to write a whole Ansible playbook to do that.  In fact you don’t really need the Junos module installed.

Ansible expects there to be Python on the managed device.  As you can read in this PacketPushers blog, it pushes the module out to the device and tries to execute it there.  Junos is going to get on-box Python at some point, but right now that’s roadmap (or SOPD if you must).

Ansible and Junos Notes

I’m working on a project to push out configs to Juniper devices and upgrade them if necessary. Ultimately it will be vendor-independent.  In the first instance I thought about writing it all in Python, but there’s really no need because quite a lot of legwork has already been done for you in the form of ‘PyEz’ and the Junos Ansible core modules.

Juniper give you a few examples to get you started, but don’t really explain what each of the lines in the YAML file does, but I guess they expect you to figure that out.  Below are a few notes on things I discovered – perhaps obvious to some, but they might help someone else.

Setting up vSRX and Space in VMware Fusion

I’m going to be travelling a bit in the near future and wanted an easy, laptop-based Juniper device and Junos Space instance to mess with. I’ve recently made some headway with CLI configlets and wanted to build on what I’ve got working.

I already run VMware Fusion on the Mac in order to run Ubuntu and Windows, so I figured that was the best thing to use. What I wanted was two VMs that could see each other and be accessed from the host machine, but without them being dependent on the host’s interfaces being up. Wifi access would be chargeable, and wired impossible – without making an ethernet loopback plug to bring the Mac’s interface up artifically, that is. So that ruled out both bridged and NAT type connections. What I needed was some kind of internal network within the host – Fusion seems to call this a ‘Private to my Mac’ connection.