Limit device traffic to only one MX uplink

Hi all

The Meraki MX devices gives you an easy way of automaticly use 2 uplinks. It works seamlessly but it’s hard to do some configuration that is possible on other Cisco devices.

One of those is to deny specific devices to connect over only 1 of the uplinks. Let’s say that WAN 1 is a fiber connection. You got enogh capacity to send and receive all kind of traffic. WAN 2 on the other hand is a sattelite connection. The 2 big drawbacks with sattelite is latency and speed. Sometimes even the cost per MB transferred. Often the guaranteed bandwith on a satelite connection could be as low as 64 kb/s. It’s not much bandwith for other devices then.
wanmeraki

Then the big question is, how do you limit the connection to only use WAN 1. This could be a device that sync data every hour and would generate traffic or a whole subnet with guest wifi users. You don’t want these devices use your costly satelite connection. You do most likely need it for business critical applications.

I spent a few good hours trying to find a solution to this. I asked help from Meraki and various forums. I always got told that traffic shaping should help etc. But the only thing it does is giving me the preferred uplink, it never blocks the traffic from going online if the other WAN connection is down.

The solution I came up with was to turn off NAT when you use the interface that should be blocked. All the devices behind the Meraki that should be blocked does need to be in a seperate VLAN. In version 15 you can exclude specific VLAN from the NAT policy on the uplinks. The traffic will then stop since there is no return route for the traffic (as long as youo don’t add a static route).

So in the above example we want VLAN 20 to only have access over WAN 1 and not WAN 2. You start by finding the network you want to do the change on in the Meraki Dashboard. Then go to Security & SD-WAN and Adressing and VLAN’s on the left side. In the bottom of the page you have NAT exceptions where you can choose to disable NAT on the different uplinks. In my screenshot I have excepted Crew network from the NAT policy. With this config the devices on Crew VLAN can’t use WAN 2/Uplink 2.
NAT meraki

Advertisements

Backup and restore config of Mobility Express.

Hi all

Lately I have been working with the mobility express AP’s from Cisco.  One of the important things to do when you set up new equipment is to have a backup and restore policy for the config.. I chose the easy way out using tftp, it’s the quickest and easiest way to transfer files as long as you have the tftp server secured. The other option you have is ftp.

transfer upload mode tftp
Sets the mode to tftp, you can also choose ftp but then you need to add in username and password too.

transfer upload datatype config
Choose config as the information to store on the server

transfer encrypt enable
Turns on encryption for the file

transfer encrypt set-key supersecret
Gives the encryption a password

transfer upload serverip 10.10.10.10
Gives the ME an IP to the server where to store the config

transfer upload filename MEconfig.cfg
Filename for the config.

transfer upload start
Start the upload.

transfer upload mode tftp
transfer upload datatype config
transfer encrypt enable
transfer encrypt set-key supersecret
transfer upload serverip 10.10.10.10
transfer upload filename MEconfig.cfg
transfer upload start

You should then get the following output.

Mode……………………………………… TFTP
TFTP Server IP…………………………….. 10.10.10.10
TFTP Path………………………………….
TFTP Filename……………………………… MEconfig.cfg
Data Type…………………………………. Config File
Encryption………………………………… Enabled

Are you sure you want to start? (y/N) y

File transfer operation completed successfully.

So far you have done the backup. Then the second most important thing comes, do the restore. It’s almost the same, but you swap out upload with download.

transfer download datatype config
transfer download mode tftp
transfer encrypt enable
transfer encrypt set-key supersecret
transfer download serverip 10.10.10.10
transfer download filename MEconfig.cfg
transfer download start

After the commands have been entered you should see the following output.

Mode............................................. TFTP
Data Type........................................ Config
TFTP Server IP................................... 10.10.10.10
TFTP Packet Timeout.............................. 6
TFTP Max Retries................................. 10
TFTP Path........................................
TFTP Filename.................................... MEconfig.cfg
Encrypt/Decrypt Flag............................. Enabled

Warning: Downloading configuration will cause the controller to reset...

This may take some time.
Are you sure you want to start? (y/N) y

TFTP Config transfer starting.

TFTP receive complete... updating configuration.

CCO Username & Password will NOT be imported. Please Re-Configure the Credentials 'transfer download ap-images cco-username '
'transfer download ap-images cco-password ' after bootup for Image Download

TFTP receive complete... storing in flash.

Sync config to peers.

System being reset.

 

Cisco and python programming

I have decided I want to try to program cisco switches and devices using python. At the moment my programming skills are limited to simple if and else. I now have a plan to configure a linux server with python on to do all my scripting.

The plan is to try to upload the different scripts I create here as I go along. Hopefully it will get useful for others too in the end and not just something for me. I will try to use various youtube videos and pages to learn me the diffferent things with oython and will link them from my upcoming posts as I go along.

If you have something you want me to write about or create a script it’s greatly apreciated!

Problems with NSM after schema upgrade.

The other day we upgraded the schema on our NSM server from 327 to 329. After the upgrade the devices was not able to connect to our NSM anymore. In the deviceDeamon I got the following error:

[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.

I didn’t know that a simple schema upgrade could do something to the NSM that would not allow the devices to connect so I ended up contacting JTAC support. When I got a support engineer and explained him the issue he found another error message in the guiDaemon. The error was “DC not connected”.

After a while with troubleshooting the engineer discovered that the issue was the RSA key that is responsible for the communication between the NSM services  and the guiDaemon and devDaemon. The engineer then navigated to devSvr.cfg under /usr/netscreen/DevSvr/var and deleted the RSA keys (ourRsaPrivateKey and theirRsaPublicKey).

After that all the devices in some magical way connected again!

Secondary node locked when commiting

The other day I got a problem with one of my SRX clusters when I was running a commit. The commit was not able to complete and I got the following error:

{primary:node0}[edit]
srx1400# commit
node1:
error: configuration database modified
node0:
error: remote lock-configuration failed on node1

The reason for this error is some uncommited configuration on the secondary node. Earlier the same day I changed the primary for redundancy-group 0 and I guess that I didn’t commit all the config on node1 before changing to node0.

To solve this I had to go into the secondary node (node1) and rollback the uncommitted configuration. Normally you can use OOB to connect to the secondary node but I dont have it at this location. So I have to connect to the secondary node trough the primary node. This is done with the following command on branch devices (SRX650 and below):  request routing-engine login node 1
On High end devices like the one I’m working on (SRX1400 and above) you use: rlogin -T node1

{secondary:node1}% rlogin -T node1
root@srx1400>
--- JUNOS 11.4R9.4 built 2013-08-22 06:24:21 UTC
{secondary:node1}
root@srx1400> configure
warning: Clustering enabled; using private edit
error: shared configuration database modified

Please temporarily use 'configure shared' to commit
outstanding changes in the shared database, exit,
and return to configuration mode using 'configure'

As you can see from the error I have to use configure shared to be able to edit the configuration.

root@srx1400> configure shared
Entering configuration mode
The configuration has been changed but not committed

Before entering the rollback command you can check the uncommitted configuration by running show | compare. This will display all the uncommited configuration

{secondary:node1}[edit]
root@srx1400# show | compare
[edit access profile unos clientjunos]
- pap-password "$9$2V4GDikP5T3fTrvLXwsz36C0B"; ## SECRET-DATA
+ pap-password "$9$jhHP5QF/CA09AxdsYGUp0BRyl"; ## SECRET-DATA

Now you can rollback the uncommited config, check that there is any uncommited config left and exit the configuration mode.

{secondary:node1}[edit]
root@rx1400# rollback
load complete

{secondary:node1}[edit]
root@srx1400# show | compare

{secondary:node1}[edit]
root@srx1400# exit
Exiting configuration mode

{secondary:node1}
root@srx1400>

Now you can close the session and try to commit the configuration from the primary node again. It worked for me! 🙂

As a note I also know that alot of people has had a success of using just the command commit synchronize force on the primary node but it does not work for everyone.

dst-port error in NSM

I got a new error while updating a SRX650 from the Juniper Network and Security Manager. The error started after I upgraded the SRX650 to 12.1X47-D30. The error I got is shown below:

Error Code: 

Error Text:
   Update fails UpdateDevice Results
sanityCheckCmd Success.
lock Success.
GenerateEditConfig Failed .
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/12.1X47/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
   <rpc-error>
      <error-severity>error</error-severity>
      <error-info>
         <bad-element>dst-port</bad-element>
      </error-info>
      <error-message>syntax error</error-message>
   </rpc-error>
   <rpc-error>
      <error-severity>error</error-severity>
      <error-info>
         <bad-element>dst-port</bad-element>
      </error-info>
      <error-message>syntax error</error-message>
   </rpc-error>
</rpc-reply>


unlock  Success .


Error Details:
   

Logs:
<configuration>
  <version>12.1X47-D25.4</version>
  <system>
    <host-name>casur-srx650-cluster</host-name>
  </system>
  <security>
    <nat>
      <destination>
        <rule-set>
          <name>ca-camera</name>
          <rule>
            <name>camera-01-8200</name>
            <dest-nat-rule-match>
              <destination-port operation="delete">
                <name>8200</name>
              </destination-port>
              <destination-port operation="create">
                <dst-port>8200</dst-port>
              </destination-port>
            </dest-nat-rule-match>
          </rule>
        </rule-set>
      </destination>
    </nat>
  </security>
</configuration>

It’s saying that the destination nat section has problems setting the dst-port. For some reason it was deleting the value and creating it with a new command (dst-port).

I then checked the supported Junos versions on the NSM and I discovered that the last supported version was 12.1X47-D25. Did the downgrade and updated the OS in the NSM. Still the same error as before.

Spoke to JTAC and they informed me that this error was known and that it would help downgrading to D15. This was due to a changed command in Junos. I downgraded to D15 but still the same issue. Researched a bit myself and discovered that it was introduced between X46 and X47.

Earlier it had not been possible to downgrade the versions in NSM. But for some reason I was able to do it now. First from D30 to D25, and after that from X47D15 to X46D40. When I reached  X46D40 I was able to run the update and everything was working.

1121 not registering to WLC

I was converting AP’s from Autonomous to Lightweight AP’s yesterday when I ran into issues with a couple of old 1121G. I only saw the AP register to the controller for 3-4 seconds before it disconnected. While pinging the AP it responded for 1 minute before it did go into a reboot.

I then logged into the WLC to do a debug. I used the following debug command:

(Cisco Controller) >debug capwap errors enable

The output from this repeated itself every time the AP was up and running.

Dec 03 11:26:02.616: 00:1e:4a:a8:b1:88 Join Priority Processing status = 0, Incoming Ap's Priority 0, MaxLrads = 100,joined Aps =1
*spamApTask0: Dec 03 11:26:12.645: Could not find BoardDataPayload
*spamApTask0: Dec 03 11:26:14.685: 00:1e:4a:a8:b1:88 Refusing image download to AP 00:1e:4a:a8:b1:88 - unable to open image file /bsn/ap//c1100
 Error:No such file or directory(2)
*spamApTask0: Dec 03 11:26:14.685: 00:1e:4a:a8:b1:88 Number of open file descriptors for spam process is: 97
*spamApTask0: Dec 03 11:26:14.685: 00:1e:4a:a8:b1:88 Decoding of Image Data failed from AP 00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:15.683: 00:1e:4a:a8:b1:88 Error decrypting packet from AP 00:1e:4a:a8:b1:88
 sessionId 2367ed6d, recvNonce 2367ed6e, sendNonce 2367ed6d
 key b9.87.16.0b.97.72.4e.e8
 c4.c5.ee.e1.d4.c7.f3.62

*spamApTask0: Dec 03 11:26:15.683: 00:1e:4a:a8:b1:88 rxN 00.23.67.ed.6e.00.00.00
 00.00.00.00.00
 txN 00.00.00.00.00.00.00.00
 00.00.00.00.00

*spamApTask0: Dec 03 11:26:15.683: 00:1e:4a:a8:b1:88 Decryption of message from AP failed00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:15.683: 00:1e:4a:a8:b1:88 Security processing of Image Data failed for AP 00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:16.687: 00:1e:4a:a8:b1:88 Error decrypting packet from AP 00:1e:4a:a8:b1:88
 sessionId 2367ed6d, recvNonce 2367ed6e, sendNonce 2367ed6d
 key b9.87.16.0b.97.72.4e.e8
 c4.c5.ee.e1.d4.c7.f3.62

*spamApTask0: Dec 03 11:26:16.687: 00:1e:4a:a8:b1:88 rxN 00.23.67.ed.6e.00.00.00
 00.00.00.00.00
 txN 00.00.00.00.00.00.00.00
 00.00.00.00.00

*spamApTask0: Dec 03 11:26:16.687: 00:1e:4a:a8:b1:88 Decryption of message from AP failed00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:16.687: 00:1e:4a:a8:b1:88 Security processing of Image Data failed for AP 00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:17.686: 00:1e:4a:a8:b1:88 Error decrypting packet from AP 00:1e:4a:a8:b1:88
 sessionId 2367ed6d, recvNonce 2367ed6e, sendNonce 2367ed6d
 key b9.87.16.0b.97.72.4e.e8
 c4.c5.ee.e1.d4.c7.f3.62

*spamApTask0: Dec 03 11:26:17.686: 00:1e:4a:a8:b1:88 rxN 00.23.67.ed.6e.00.00.00
 00.00.00.00.00
 txN 00.00.00.00.00.00.00.00
 00.00.00.00.00

*spamApTask0: Dec 03 11:26:17.686: 00:1e:4a:a8:b1:88 Decryption of message from AP failed00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:17.686: 00:1e:4a:a8:b1:88 Security processing of Image Data failed for AP 00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:18.687: 00:1e:4a:a8:b1:88 Error decrypting packet from AP 00:1e:4a:a8:b1:88
 sessionId 2367ed6d, recvNonce 2367ed6e, sendNonce 2367ed6d
 key b9.87.16.0b.97.72.4e.e8
 c4.c5.ee.e1.d4.c7.f3.62

*spamApTask0: Dec 03 11:26:18.687: 00:1e:4a:a8:b1:88 rxN 00.23.67.ed.6e.00.00.00
 00.00.00.00.00
 txN 00.00.00.00.00.00.00.00
 00.00.00.00.00

*spamApTask0: Dec 03 11:26:18.687: 00:1e:4a:a8:b1:88 Decryption of message from AP failed00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:18.687: 00:1e:4a:a8:b1:88 Security processing of Image Data failed for AP 00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:19.690: 00:1e:4a:a8:b1:88 Error decrypting packet from AP 00:1e:4a:a8:b1:88
 sessionId 2367ed6d, recvNonce 2367ed6e, sendNonce 2367ed6d
 key b9.87.16.0b.97.72.4e.e8
 c4.c5.ee.e1.d4.c7.f3.62

*spamApTask0: Dec 03 11:26:19.690: 00:1e:4a:a8:b1:88 rxN 00.23.67.ed.6e.00.00.00
 00.00.00.00.00
 txN 00.00.00.00.00.00.00.00
 00.00.00.00.00

*spamApTask0: Dec 03 11:26:19.690: 00:1e:4a:a8:b1:88 Decryption of message from AP failed00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:19.690: 00:1e:4a:a8:b1:88 Security processing of Image Data failed for AP 00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:20.733: Unable to find deleted AP 00:1e:4a:a8:b1:88
*spamApTask0: Dec 03 11:26:20.733: 00:1e:4a:a8:b1:88 Join Priority Processing status = 0, Incoming Ap's Priority 0, MaxLrads = 100,joined Aps =1
*spamReceiveTask: Dec 03 11:26:32.658: b4:b6:76:c3:56:db Unable to get RadId. Sending of PMK cache entry to all APs in flexconnect group failed :: bssid 00:00:00:00:00:00

Security processing of Image Data failed for AP was a message in the output that I thought was strange and also other references to the image. I then checked the Cisco Wireless Controller Compability Matrix, to my dissapointment the AP was no longer supported. It ended up with a long and slow process of having one of the local guys in Chile downgrading from Controllerbased AP to a Standalone….