Monthly Archives: October 2016

31 Oct

Cisco ASA REST API – Part II: How it’s really working?

First published: 31/Oct/2016
Last update: 31/Oct/2016
ASA REST API version: 1.3.2

In previous chapter we configured ASA to support REST API interface and executed simply query. It was nice to see something in action but let’s now think how it’s working and how we can use it.

Every operation you can do using REST API you can also execute via traditional CLI commands or simplifying your life a little by using ASDM. Many of parameters you can fetch using SNMP or from syslog. So is it just another way to manage your device? Answer is both yes and no. Yes, because it is way of managing the device. No, because using REST API you have to stop thinking that you configure service but you are programming it usually as a part of bigger script or application.

REST API on ASA

REST API on ASA side is small plugin loaded into device flash memory and then activated using CLI.

 

rest-api-diagram

Read More →

24 Oct

Cisco ASA REST API – Part I: Getting started

First published: 24/Oct/2016
Last update: 31/Oct/2016
ASA REST API version: 1.3.2

REST is an acronym of Representational State Transfer (REST) API. This API provide administrators an option to perform CRUD operations which is Create, Read, Update, Delete. It fully rely on HTTPS as transport protocol and requires programming skills from administrators. But if you gain some experience its a good way of learning and getting familiar with whole new world when you more program devices than configure it.

Read More →

21 Oct

Juniper error messages that says nothing

I wrote in the past that sometimes error messages are completely misleading and not connected to the problem that is blocking changes commit. Here is another example, I’m leaving it here because Google was not helpful on this 😉

I’ve been trying to configure DHCP server on SRX, firmware 12.1X46-D60.4, using the new approach that support both IPv4 and IPv6. DHCP parameters are now defined under access section

user@SRX# show access address-assignment pool LAN 
family inet {
    network 192.168.100.0/24;
    range Dynamic {
        low 192.168.100.101;
        high 192.168.100.140;
    }
    dhcp-attributes {
        maximum-lease-time 86400;
        domain-name lan;
        name-server {
            192.168.100.1;
        }
        router {
            192.168.100.1;
        }
    }
    host HOST1 {
        hardware-address d1:51:99:37:4d:79;
        ip-address 192.168.1.2;
    }
    host HOST2 {
        hardware-address 2d:f0:e2:51:74:55;
        ip-address 192.168.1.10;
    }
    host HOST3 {
        hardware-address d1:51:99:37:4d:79;
        ip-address 192.168.1.5;
    }
}

Attempt to commit the change result in error message

user@SRX# commit check 
error: Check-out failed for General authentication process (/usr/sbin/authd) without details
error: configuration check-out failed

Hmm.. yes, so the problem is…. no, that’s not the right guess.

The error message is not really helpful because the problem is that for two static assignments same MAC address was specified. Yes, error message was really helpful in this case….