How to enable the ap image preload on aruba controller ?

This article explains how to trigger the AP image preload on the controller to minimize the downtime during the controller upgrade.

Feature Notes : The AP image preload allows the Access points (AP) to download the new image from the controller where it is terminated before the controller actually starts running the new version, hence reduces the downtime for the controller upgrade.

We can allow all the APs terminated on the controller or custom list of AP groups or individual APs to preload the image.

If a new AP associates to the controller when the preload feature is active, based on the AP group or AP name if it appears in the preload list the AP will start preload its image.

Environment : This feature is only supported on the 3600, 7200 Series and M3 controllers and applies to controllers running OS version 6.3 or later.

Network Topology : Standalone Master, Master-local

Configuration Steps :

Steps to trigger the AP image preload:

1. The controller should be upgraded first and before reboot, we need to trigger the AP image preloading in the same partition where the controller is upgraded.

(Aruba7240) #show image version
———————————-
Partition                : 0:0 (/dev/usb/flash1) **Default boot**
Software Version  : ArubaOS 6.3.1.3 (Digitally Signed – Production Build)
Build number        : 42233
Label                     : 42233
Built on                 : Tue Feb 11 12:31:53 PST 2014
———————————-
Partition                : 0:1 (/dev/usb/flash2)
Software Version  : ArubaOS 6.3.1.2 (Digitally Signed – Production Build)
Build number         : 41362
Label                     : 41362
Built on                  : Wed Dec 18 17:12:20 PST 2013
(Aruba7240) #show ap image-preload-status

AP Image Preload Parameters
—————————
Item    Value
—-    —–
Status  Inactive

——————

-To enable the AP image preload using the CLI, use the following command on the enable mode:

(Aruba7240) #ap image-preload activate ?
all-aps                 Activate image preload for all registered APs.
specific-aps          Activate image preload for specific APs as specified
by ‘ap image-preload ap-group’ and/or ‘ap
image-preload ap-name’

(Aruba7240) #ap image-preload activate all-aps partition 0

2. Once the controller is rebooted, the APs will reboot along with the controller and come up with less downtime as the image is already preloaded.
The ap image-preload will go to inactive state automatically after the controller reboots.

3.   For the controller’s next upgrade, again we need to upgrade the controller first and then need to trigger the AP image preload.

Note: The ap image preload must be inactive and should be triggered only after the controller image upgrade.

 

 

Verification : The same can be verified using the following commands:

(Aruba7240) #show ap image-preload-status

AP Image Preload Parameters
—————————
Item                            Value
—-                                —–
Status                          Active
Mode                           All APs
Partition                      1
Build                             41362
Max Simultaneous     Downloads  10
Start Time                   2014-03-18 12:05:04

AP Image Preload AP Status Summary
———————————-
AP Image Preload State  Count
———————-  —–
Preloaded               1
TOTAL                      1

AP Image Preload AP Status
————————–
AP Name   AP Group  AP IP         AP Type  Preload State  Start Time           End Time             Failure Count  Failure Reason
——-   ——–  —–         ——-  ————-  ———-           ——–             ————-  ————–
MasterAP  Master    10.10.10.252  105      Preloaded      2014-03-18 12:05:04  2014-03-18 12:06:15  0

(Aruba7240) #show ap image-preload-status-summary

AP Image Preload Parameters
—————————
Item                             Value
—-                                 —–
Status                           Active
Mode                            All APs
Partition                       1
Build                              41362
Max Simultaneous      Downloads  10
Start Time                    2014-03-18 12:05:04

AP Image Preload AP Status Summary
———————————-
AP Image Preload State  Count
———————-  —–
Preloaded               1
TOTAL                      1

(Aruba7240) #show ap image version
AP Image Versions On Controller
——————————-
6.3.1.2(p4build@corsica.arubanetworks.com)#41362 Wed Dec 18 16:16:17 PST 2013
Access Points Image Version
—————————
AP            Running Image Version String                                                   Flash (Production) Image Version String                         Flash (Provisioning/Backup) Image Version String                    Matches  Num Matches  Num Mismatches  Bad Checksums  Bad Provisioning Checksums  Image Load Status
—            —————————-                                                   —————————————                         ————————————————                    ——-  ———–  ————–  ————-  ————————–  —————–
10.10.10.252  6.3.1.2(p4build@corsica.arubanetworks.com)#41362 Wed Dec 18 16:16:17 PST 2013 6.3.1.3(p4build@port-royal)#42233 Tue Feb 11 11:29:58 PST 2014  6.1.3.4-3.1.0.0(p4build@cyprus)#35320 Sat Sep 15 13:43:44 PDT 2012  Yes      1            0               0              0                           Done
Total APs:1

Juniper SRX – Minimal Downtime Upgrade of an HA Cluste

Please note that this describes the process to upgrade an HA pair at JunOS code pre-11. Newer versions of the JunOS code allow for upgrading without corrupting the policy of the peer devices.

!! Note: interface names are the physical and not logical names
!! The following assumes node0 is master and node1 is backup
01.) download package to /var/tmp on both devices
02.) Disable node1\'s interfaces by running the following on node0. Commit will replicate to node1
  set interfaces ge-8/0/0 disable        [-- Should be node1's interfaces, NOT node0's
  set interfaces ge-8/0/1 disable
  set interfaces ge-8/0/2 disable
  set interfaces ge-8/0/3 disable
  set interfaces ge-8/0/4 disable
  set interfaces ge-8/0/5 disable
  set interfaces ge-8/0/6 disable
  set interfaces ge-8/0/7 disable
  set interfaces ge-8/0/8 disable
03.) Disable requiring three way handshake for session on node 0 (primary)
  set security flow tcp-session no-syn-check
  set security flow tcp-session no-sequence-check
04.) Save on node 0 (primary)
  commit
05.) Disconnect the fiber link (fab# interfaces) and the control interface cables
06.) Commit on both devices
07.) Upgrade node 1 (Backup)
  request system software add /var/tmp/junos-srx1k3k-10.4R3.4-domestic.tgz no-validate no-copy
  request system reboot
08.) Perform the following on node 1 (currently backup and now newly upgraded) to verify
  show version
  show chassis cluster status
  show chassis fpc pic-status
09.) After running "show chassis fpc pic-status," wait for the slots to come online, not Present before going to step 10
10.) Node 0 then Node 1, perform ALL the following commands
  delete interfaces ge-8/0/0 disable
  delete interfaces ge-8/0/1 disable
  delete interfaces ge-8/0/2 disable
  delete interfaces ge-8/0/3 disable
  delete interfaces ge-8/0/4 disable
  delete interfaces ge-8/0/5 disable
  delete interfaces ge-8/0/6 disable
  delete interfaces ge-8/0/7 disable
  delete interfaces ge-8/0/8 disable
  set interfaces ge-0/0/0 disable
  set interfaces ge-0/0/1 disable
  set interfaces ge-0/0/2 disable
  set interfaces ge-0/0/3 disable
  set interfaces ge-0/0/4 disable
  set interfaces ge-0/0/5 disable
  set interfaces ge-0/0/6 disable
  set interfaces ge-0/0/7 disable
  set interfaces ge-0/0/8 disable
11.) Save on both devices at same time  !! IMPORTANT TO BE DONE AT THE SAME TIME !!
  commit
12.) Verify that node1 has correctly taken over as master (if input increasing on monitor command, it has taken over)
  show security flow session summary
  run monitor interface traffic
13.) On node 0:
  request system software add /var/tmp/junos-srx1k3k-10.4R3.4-domestic.tgz no-validate no-copy
  request system reboot
14.) On node 0, after upgrade:
  show version
  show chassis cluster status
  show chassis fpc pic-status
15.) Wait for all interfaces to come "online" after "show chassis fpc pic-status" command
16.) Node 1 then Node 0 (this will failover so node0 is now master again)
  delete interfaces ge-0/0/0 disable
  delete interfaces ge-0/0/1 disable
  delete interfaces ge-0/0/2 disable
  delete interfaces ge-0/0/3 disable
  delete interfaces ge-0/0/4 disable
  delete interfaces ge-0/0/5 disable
  delete interfaces ge-0/0/6 disable
  delete interfaces ge-0/0/7 disable
  delete interfaces ge-0/0/8 disable
  set interfaces ge-8/0/0 disable
  set interfaces ge-8/0/1 disable
  set interfaces ge-8/0/2 disable
  set interfaces ge-8/0/3 disable
  set interfaces ge-8/0/4 disable
  set interfaces ge-8/0/5 disable
  set interfaces ge-8/0/6 disable
  set interfaces ge-8/0/7 disable
  set interfaces ge-8/0/8 disable
17.) Save on both devices at same time
  committ
18.) Reconnect control plane cable
19.) Veryify node0 is primary
  run show chassis cluster status
20.) Reboot Node1 and connect fab# interface cables between nodes while device is rebooting
21.) Verify node0 is still passing traffic
  run monitor interface traffic
22.) Wait for all interfaces to come "online"
  show chassis fpc pic-status
23.) Verify group 2 failover shows priority
24.) Re-enable interfaces on node1 and check for proper tcp sequence checks (run on node0, commit will replicate to node1)
  delete interfaces ge-8/0/0 disable
  delete interfaces ge-8/0/1 disable
  delete interfaces ge-8/0/2 disable
  delete interfaces ge-8/0/3 disable
  delete interfaces ge-8/0/4 disable
  delete interfaces ge-8/0/5 disable
  delete interfaces ge-8/0/6 disable
  delete interfaces ge-8/0/7 disable
  delete interfaces ge-8/0/8 disable

  delete security flow tcp-session no-syn-check
  delete security flow tcp-session no-sequence-check
25.) commit
26.) Verify failover group (group 0 and 1 should show primary or secondary and priorities)
  run show chassis cluster status
    26.a) If group 2 is not showing with priorities and status on node1 is "disabled", another reboot may be necessary. This is related to the fab# interfaces
    26.b) When node1 comes back online, verify fab interfaces are showing up and give a minute or 2 for "show chassis cluster status" to show priorities and status
    26.c) May take time due to sessions being synchronized
27.) Run on node0 to download and install IDP updates if needed. Status is for verifying progress of download or install
  run request security idp security-package download full-update
  run request security idp security-package download status

  run request security idp security-package install
  run request security idp security-package install status
28.) Verify versions match on both nodes and verify they are up to date
  run show security idp security-package-versionrun show
  run request security idp security-package download check-server
    28.a) Failover may be required to download IDP if no internet access on node0 (Per Juniper) or versions do not match

Transparent Proxy Redirection with JunOS

Transparent Proxy Redirection with JunOS

I have to say, I love proxy servers. Transparent proxy is my preference. Of all the Proxy servers in the world, the best in my opinion is Blue Coat’s ProxySG appliance. With the Blue Coat ProxySG as your proxy in transparent mode, this allows us to inspect content, without the need for user input, and to direct the traffic to a proxy so you get all the benefits of Web Pulse, Web Filter, ProxyAV, Wan Optimisation and Flash Caching. Plus the use of CPL (Content Policy Language) to decide whether users should be allowed access to a site or not. With transparent proxy that responsibility is dealt with by the network, and quite right too. There are some applications which don’t, however, respond well to transparent proxy, especially those which don’t understand authentication (are you reading this Google, Apple and Adobe!!!) so they have to be handled on the ProxySG with some custom CPL, however these little issues shouldn’t’ stop you considering transparent proxy as an option if you are planning a Blue Coat deployment or any other proxy which supports transparent redirect.

As both EX and SRX use JunOS, the implementation on each is exactly the same and this is one of the great reasons to love JunOS. In order to do WCCP-like transparent redirect on EX switches or SRX firewalls, there are several configuration items to consider:

  • The Filter Based Forwarding entry
  • A Virtual Routing Instance
  • A RIB group entry to combine the routing-instances
  • Some failover monitoring in-case the proxy fails such as an RPM probe with Event Monitoring

In the PoC lab, the following subnets/VLANs were used:

  • VLAN1 – 10.11.20.0/24 – Egress route subnet (an SRX firewall is connected and the EX switch has a default route to it)
  • VLAN2 – 10.11.30.0/24 – Proxy subnet used for the routing-instance configuration. PROXYSG ip is 10.11.30.2. PROXYSG2 ip is 10.11.30.3
  • VLAN3 – 10.11.40.0/24 – Client subnet

 

 

First off, we setup a firewall filter to assign to an interface. The interface can be either family inet interface, or a virtual (VLAN) interface. This filter redirects anything from source subnet 10.11.40.0/24 (the client subnet) destined for anywhere on port 80, 443 or 21 to the proxy on routing-instance ‘PROXYSG’.

family inet {
filter proxysg-fbf {
term t1 {
from {
source-address {
10.11.40.0/24;
}
destination-address {
0.0.0.0/0;
}
destination-port [ http ftp https ];
}
then {
count redirected;
routing-instance PROXYSG;
}
}

In display set form, that looks like;

set firewall family inet filter proxysg-fbf term t1 from source-address 10.11.40.0/24
set firewall family inet filter proxysg-fbf term t1 from destination-address 0.0.0.0/0
set firewall family inet filter proxysg-fbf term t1 from destination-port http
set firewall family inet filter proxysg-fbf term t1 from destination-port ftp
set firewall family inet filter proxysg-fbf term t1 from destination-port https
set firewall family inet filter proxysg-fbf term t1 then count redirected
set firewall family inet filter proxysg-fbf term t1 then routing-instance PROXYSG
set firewall family inet filter proxysg-fbf term default then accept

Next, we need to have some way of redirecting the traffic ‘off-path’ to the proxy server. This is handled by a routing-instance, in this case to proxy server 10.11.30.2.

PROXYSG {
instance-type virtual-router;
routing-options {
static {
route 0.0.0.0/0 {
qualified-next-hop 10.11.30.2 {
metric 5;
}
}
}
}
}
set routing-instances PROXYSG instance-type virtual-router
set routing-instances PROXYSG routing-options static route 0.0.0.0/0 qualified-next-hop 10.11.30.2 metric 5
set routing-instances PROXYSG routing-options static route 0.0.0.0/0 qualified-next-hop 10.11.20.2 metric 20

Next, in order to combine the two routing-instances, we create a rib-group entry.

interface-routes {
rib-group inet PROXYSG;
}
static {
route 0.0.0.0/0 next-hop 10.11.20.2;
}
rib-groups {
PROXYSG {
import-rib [ inet.0 PROXYSG.inet.0 ];
}
}
set routing-options interface-routes rib-group inet PROXYSG
set routing-options static route 0.0.0.0/0 next-hop 10.11.20.2
set routing-options rib-groups PROXYSG import-rib inet.0
set routing-options rib-groups PROXYSG import-rib PROXYSG.inet.0

Finally, the filter we created earlier is assigned to an interface, in this case, the ingress interface which client traffic appears from.

vlan {
unit 3 {
family inet {
filter {
input proxysg-fbf;
}
address 10.11.40.1/24;
}
}
}

In order to have some failover capabilities, were the proxy to fail, we can use event monitoring probes on the EX switch to force a configuration change on the forwarding filter in the event the proxy fails. This is done using a custom monitoring script which was originally designed for use with Juniper WXC appliances.

The WXC-Healthcheck.slax file can be downloaded from here

The script should be uploaded to the EX switch using FTP or SCP and placed into /config/db/scripts/event/ (or whichever is relevant to the JunOS version you are running – tested on 11.4R2.14). Once loaded, you can create the RPM probe and event policy actions.

The event probe is setup as follows under the ‘services’ stanza within the configuration.

rpm {
probe proxysg {
test proxy-ping {
probe-type icmp-ping;
target address 10.11.30.2;
probe-count 3;
probe-interval 1;
test-interval 10;
thresholds {
total-loss 1;
}
}
}
set services rpm probe proxysg test proxy-ping probe-type icmp-ping
set services rpm probe proxysg test proxy-ping target address 10.11.30.2
set services rpm probe proxysg test proxy-ping probe-count 3
set services rpm probe proxysg test proxy-ping probe-interval 1
set services rpm probe proxysg test proxy-ping test-interval 10
set services rpm probe proxysg test proxy-ping thresholds total-loss 1

This will log either ‘PING_TEST_COMPLETED’ or ‘PING_TEST_FAILED’ in the ‘messages’ log on the switch.

Next, we create the event-options section to tell the switch what to do in the event of it seeing the ‘PING_TEST_COMPLETED’ or ‘PING_TEST_FAILED’ in the messages system log. The following two configuration options show what the EX switch will do in the event of each.

* In the event of a failure, disable the firewall filter.

policy rpm_down {
events PING_TEST_FAILED;
within 10 {
trigger on 1;
}
attributes-match {
PING_TEST_FAILED.test-owner matches "^proxysg$";
PING_TEST_FAILED.test-name matches "^proxy-ping$";
}
then {
event-script WXC-Healthcheck.slax {
arguments {
filter proxysg-fbf;
term t1;
action inactive;
}
}
}
}

* When the failure is fixed, re-enable the filter.

policy rpm_up {
events PING_TEST_COMPLETED;
within 20 {
trigger on 1;
}
attributes-match {
PING_TEST_COMPLETED.test-owner matches "^proxysg$";
PING_TEST_COMPLETED.test-name matches "^proxy-ping$";
}
then {
event-script WXC-Healthcheck.slax {
arguments {
filter proxysg-fbf;
term t1;
action active;
}
}
}
}
event-script {
file WXC-Healthcheck.slax;
}
traceoptions {
file wxc.out;
}

In display set for, that looks like;

set event-options policy rpm_down events PING_TEST_FAILED
set event-options policy rpm_down within 10 trigger on
set event-options policy rpm_down within 10 trigger 1
set event-options policy rpm_down attributes-match PING_TEST_FAILED.test-owner matches "^proxysg$"
set event-options policy rpm_down attributes-match PING_TEST_FAILED.test-name matches "^proxy-ping$"
set event-options policy rpm_down then event-script WXC-Healthcheck.slax arguments filter proxysg-fbf
set event-options policy rpm_down then event-script WXC-Healthcheck.slax arguments term t1
set event-options policy rpm_down then event-script WXC-Healthcheck.slax arguments action inactive
set event-options policy rpm_up events PING_TEST_COMPLETED
set event-options policy rpm_up within 20 trigger on
set event-options policy rpm_up within 20 trigger 1
set event-options policy rpm_up attributes-match PING_TEST_COMPLETED.test-owner matches "^proxysg$"
set event-options policy rpm_up attributes-match PING_TEST_COMPLETED.test-name matches "^proxy-ping$"
set event-options policy rpm_up then event-script WXC-Healthcheck.slax arguments filter proxysg-fbf
set event-options policy rpm_up then event-script WXC-Healthcheck.slax arguments term t1
set event-options policy rpm_up then event-script WXC-Healthcheck.slax arguments action active
set event-options event-script file WXC-Healthcheck.slax
set event-options traceoptions file wxc.out

If the proxy fails, the EX switch ‘event-options’ setting will see and act upon the following message log entry;

Apr 16 08:14:06 rmopd[992]: PING_TEST_FAILED: pingCtlOwnerIndex = proxysg, pingCtlTestName = proxy-ping

Every 20 seconds, it will re-check the message log, looking for the fail or success. If it sees a PING_TEST_COMPLETED, it will re-enable the filter.

Apr 16 08:21:13 rmopd[992]: PING_TEST_COMPLETED: pingCtlOwnerIndex = proxysg, pingCtlTestName = proxy-ping

You can view the filter counters to see traffic being redirected as we added a counter to the firewall filter term.

root> show firewall filter proxysg-fbf
Filter: proxysg-fbf
Counters:
Name Bytes Packets
redirected 68424 479

FAILOVER TO A SECOND PROXY
You can add failover to a second proxy by adding a second routing-instance and firewall filter term quite easily in order to ensure that traffic is always proxied (thus, your corporate AUP is always enforced).

For example, here term t2 is added after term t1 on the forwarding filter –

filter proxysg-fbf {
term t1 {
from {
source-address {
10.11.40.0/24;
}
destination-address {
0.0.0.0/0;
}
destination-port [ http ftp https ];
}
then {
count redirected;
routing-instance PROXYSG;
}
}
term t2 {
from {
source-address {
10.11.40.0/24;
}
destination-address {
0.0.0.0/0;
}
destination-port [ http ftp https ];
}
then {
count redirected2;
routing-instance PROXYSG2;
}
}
term default {
then accept;
}
}

The new routing instance looks like the following –

PROXYSG2 {
instance-type virtual-router;
routing-options {
static {
route 0.0.0.0/0 {
qualified-next-hop 10.11.30.3 {
metric 5;
}
qualified-next-hop 10.11.20.2 {
metric 20;
}
}
}
}
}

The RIB group is amended to add the second PROXYSG2 routing-instance.

rib-groups {
PROXYSG {
import-rib [ inet.0 PROXYSG.inet.0 PROXYSG2.inet.0 ];
}
}

Once this is done, the EX switch will continue to monitor the PROXYSG ip (10.11.30.2) and set it as inactive should it fail. If it does, the second term of the firewall filter (term t2) will become active.

family inet {
filter proxysg-fbf {
inactive: term t1 { <<<<<<<<<<<<<<<<<<<<<<<<<<<
from {
source-address {
10.11.40.0/24;
}
destination-address {
0.0.0.0/0;
}
destination-port [ http ftp https ];
}
then {
count redirected;
routing-instance PROXYSG;
}
}
term t2 {
from {
source-address {
10.11.40.0/24;
}
destination-address {
0.0.0.0/0;
}
destination-port [ http ftp https ];
}
then {
count redirected2;
routing-instance PROXYSG2;
}
}
term default {
then accept;
}
}
}

You can, of course, setup a second event-option monitor to monitor the second PROXYSG2 proxy (10.11.30.3) so that it also is set as inactive were the proxy to fail.

Conclusion
So there it is, transparent redirect in a WCCP-like manner using JunOS. The implementation above has worked on both a test EX switch and an SRX. I’m still working on whether we can emulate the load-balancing functions available from WCCP, via JunOS but for now the above configuration would certainly give you failover if you were to have two proxies.

FULL SWITCH CONFIG

set version 11.4R2.14
set system root-authentication encrypted-password "REMOVED"
set system name-server 208.67.222.222
set system scripts op traceoptions file wxc.out
set system scripts op file WXC-Healthcheck.slax
set system services ssh protocol-version v2
set system syslog user * any emergency
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system ntp server 194.164.127.6
set interfaces ge-0/0/0 description EXTERNAL_INTERFACE
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members VLAN1
set interfaces ge-0/0/1 description INTERNAL_PROXY_INTERFACE
set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members VLAN2
set interfaces ge-0/0/2 description INTERNAL_CLIENT_INTERFACE
set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members VLAN3
set interfaces ge-0/0/3 description INTERNAL_PROXY2_INTERFACE
set interfaces ge-0/0/3 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/3 unit 0 family ethernet-switching vlan members VLAN2
set interfaces ge-0/0/4 unit 0 family ethernet-switching
set interfaces ge-0/0/5 unit 0 family ethernet-switching
set interfaces ge-0/0/6 unit 0 family ethernet-switching
set interfaces ge-0/0/7 unit 0 family ethernet-switching
set interfaces ge-0/0/8 unit 0 family ethernet-switching
set interfaces ge-0/0/9 unit 0 family ethernet-switching
set interfaces ge-0/0/10 unit 0 family ethernet-switching
set interfaces ge-0/0/11 unit 0 family ethernet-switching
set interfaces ge-0/0/12 unit 0 family ethernet-switching
set interfaces ge-0/0/13 unit 0 family ethernet-switching
set interfaces ge-0/0/14 unit 0 family ethernet-switching
set interfaces ge-0/0/15 unit 0 family ethernet-switching
set interfaces ge-0/0/16 unit 0 family ethernet-switching
set interfaces ge-0/0/17 unit 0 family ethernet-switching
set interfaces ge-0/0/18 unit 0 family ethernet-switching
set interfaces ge-0/0/19 unit 0 family ethernet-switching
set interfaces ge-0/0/20 unit 0 family ethernet-switching
set interfaces ge-0/0/21 unit 0 family ethernet-switching
set interfaces ge-0/0/22 unit 0 family ethernet-switching
set interfaces ge-0/0/23 unit 0 family ethernet-switching
set interfaces ge-0/1/0 unit 0 family ethernet-switching
set interfaces xe-0/1/0 unit 0 family ethernet-switching
set interfaces ge-0/1/1 unit 0 family ethernet-switching
set interfaces xe-0/1/1 unit 0 family ethernet-switching
set interfaces ge-0/1/2 unit 0 family ethernet-switching
set interfaces ge-0/1/3 unit 0 family ethernet-switching
set interfaces me0 unit 0 family inet
set interfaces vlan unit 0 family inet
set interfaces vlan unit 1 family inet address 10.11.20.1/24
set interfaces vlan unit 2 family inet address 10.11.30.1/24
set interfaces vlan unit 3 family inet filter input proxysg-fbf
set interfaces vlan unit 3 family inet address 10.11.40.1/24
set event-options policy rpm_down events PING_TEST_FAILED
set event-options policy rpm_down within 10 trigger on
set event-options policy rpm_down within 10 trigger 1
set event-options policy rpm_down attributes-match PING_TEST_FAILED.test-owner matches "^proxysg$"
set event-options policy rpm_down attributes-match PING_TEST_FAILED.test-name matches "^proxy-ping$"
set event-options policy rpm_down then event-script WXC-Healthcheck.slax arguments filter proxysg-fbf
set event-options policy rpm_down then event-script WXC-Healthcheck.slax arguments term t1
set event-options policy rpm_down then event-script WXC-Healthcheck.slax arguments action inactive
set event-options policy rpm_up events PING_TEST_COMPLETED
set event-options policy rpm_up within 20 trigger on
set event-options policy rpm_up within 20 trigger 1
set event-options policy rpm_up attributes-match PING_TEST_COMPLETED.test-owner matches "^proxysg$"
set event-options policy rpm_up attributes-match PING_TEST_COMPLETED.test-name matches "^proxy-ping$"
set event-options policy rpm_up then event-script WXC-Healthcheck.slax arguments filter proxysg-fbf
set event-options policy rpm_up then event-script WXC-Healthcheck.slax arguments term t1
set event-options policy rpm_up then event-script WXC-Healthcheck.slax arguments action active
set event-options policy rpm1_down events PING_TEST_FAILED
set event-options policy rpm1_down within 20 trigger on
set event-options policy rpm1_down within 20 trigger 1
set event-options policy rpm1_down attributes-match PING_TEST_FAILED.test-owner matches "^proxysg1$"
set event-options policy rpm1_down attributes-match PING_TEST_FAILED.test-name matches "^proxy1-ping$"
set event-options policy rpm1_down then event-script WXC-Healthcheck.slax arguments filter proxysg-fbf
set event-options policy rpm1_down then event-script WXC-Healthcheck.slax arguments term t2
set event-options policy rpm1_down then event-script WXC-Healthcheck.slax arguments action inactive
set event-options policy rpm1_up events PING_TEST_COMPLETED
set event-options policy rpm1_up within 20 trigger on
set event-options policy rpm1_up within 20 trigger 1
set event-options policy rpm1_up attributes-match PING_TEST_COMPLETED.test-owner matches "^proxysg1$"
set event-options policy rpm1_up attributes-match PING_TEST_COMPLETED.test-name matches "^proxy1-ping$"
set event-options policy rpm1_up then event-script WXC-Healthcheck.slax arguments filter proxysg-fbf
set event-options policy rpm1_up then event-script WXC-Healthcheck.slax arguments term t2
set event-options policy rpm1_up then event-script WXC-Healthcheck.slax arguments action active
set event-options event-script file WXC-Healthcheck.slax
set event-options traceoptions file wxc.out
set routing-options interface-routes rib-group inet PROXYSG
set routing-options static route 0.0.0.0/0 next-hop 10.11.20.2
set routing-options rib-groups PROXYSG import-rib inet.0
set routing-options rib-groups PROXYSG import-rib PROXYSG.inet.0
set routing-options rib-groups PROXYSG import-rib PROXYSG2.inet.0
set protocols igmp-snooping vlan all
set protocols rstp
set protocols lldp interface all
set protocols lldp-med interface all
set firewall family inet filter proxysg-fbf term t1 from source-address 10.11.40.0/24
set firewall family inet filter proxysg-fbf term t1 from destination-address 0.0.0.0/0
set firewall family inet filter proxysg-fbf term t1 from destination-port http
set firewall family inet filter proxysg-fbf term t1 from destination-port ftp
set firewall family inet filter proxysg-fbf term t1 from destination-port https
set firewall family inet filter proxysg-fbf term t1 then count redirected
set firewall family inet filter proxysg-fbf term t1 then routing-instance PROXYSG
set firewall family inet filter proxysg-fbf term t2 from source-address 10.11.40.0/24
set firewall family inet filter proxysg-fbf term t2 from destination-address 0.0.0.0/0
set firewall family inet filter proxysg-fbf term t2 from destination-port http
set firewall family inet filter proxysg-fbf term t2 from destination-port ftp
set firewall family inet filter proxysg-fbf term t2 from destination-port https
set firewall family inet filter proxysg-fbf term t2 then count redirected2
set firewall family inet filter proxysg-fbf term t2 then routing-instance PROXYSG2
set firewall family inet filter proxysg-fbf term default then accept
set routing-instances PROXYSG instance-type virtual-router
set routing-instances PROXYSG routing-options static route 0.0.0.0/0 qualified-next-hop 10.11.30.2 metric 5
set routing-instances PROXYSG routing-options static route 0.0.0.0/0 qualified-next-hop 10.11.20.2 metric 20
set routing-instances PROXYSG2 instance-type virtual-router
set routing-instances PROXYSG2 routing-options static route 0.0.0.0/0 qualified-next-hop 10.11.30.3 metric 5
set routing-instances PROXYSG2 routing-options static route 0.0.0.0/0 qualified-next-hop 10.11.20.2 metric 20
set services rpm probe proxysg test proxy-ping probe-type icmp-ping
set services rpm probe proxysg test proxy-ping target address 10.11.30.2
set services rpm probe proxysg test proxy-ping probe-count 3
set services rpm probe proxysg test proxy-ping probe-interval 1
set services rpm probe proxysg test proxy-ping test-interval 10
set services rpm probe proxysg test proxy-ping thresholds total-loss 1
set services rpm probe proxysg1 test proxy1-ping probe-type icmp-ping
set services rpm probe proxysg1 test proxy1-ping target address 10.11.30.3
set services rpm probe proxysg1 test proxy1-ping probe-count 3
set services rpm probe proxysg1 test proxy1-ping probe-interval 1
set services rpm probe proxysg1 test proxy1-ping test-interval 10
set services rpm probe proxysg1 test proxy1-ping thresholds total-loss 1
set ethernet-switching-options storm-control interface all
set vlans VLAN1 vlan-id 1
set vlans VLAN1 l3-interface vlan.1
set vlans VLAN2 vlan-id 2
set vlans VLAN2 l3-interface vlan.2
set vlans VLAN3 vlan-id 3
set vlans VLAN3 interface ge-0/0/2.0
set vlans VLAN3 l3-interface vlan.3
set vlans default l3-interface vlan.0
set poe interface all

Những nguyên nhân có thể gây ra lỗi cho hệ thống cáp mạng

Khi tiến hành đo kiểm chất lượng một hệ thống mạng, chúng ta thường bắt gặp các thông số về lỗi như lỗi đấu dây ( wiremap), suy hao, nhiễu,… Xác định nguyên nhân gây ra lỗi để có cách khắc phục hiệu quả, kịp thời thì tiêu tốn khá nhiều thời gian của người thi công. Bảng tóm tắt dưới đây sẽ giúp người đọc tiết kiệm thời gian cho việc xác định nguyên nhân gây ra một số lỗi phổ biến cho hệ thống cáp mạng.

Lỗi về đấu dây:

Kết quả Những nguyên nhân có thể gây ra lỗi
Lỗi hở mạch – Open
  • Dây dẫn bị hư hỏng do uốn cong tại những điểm kết nối.
  • Thao tác bấm đầu chưa chính xác.
  • Đầu connector bị hư.
  • Cáp bị đứt ( cáp không đạt tiêu chuẩn).
  • Dây dẫn kết nối sai chân tại đầu connector.
  • Sử dụng sai đôi dây cho ứng dụng cụ thể ( Ethernet chỉ sử dụng 2 cặp là 12 và 36)
Lỗi ngắn mạch – Short
  • Bấm đầu không đúng cách.
  • Đầu connector bị hư.
  • 2 dây dẫn đưa vào cùng 1 khe trong đầu connector khi thực hiện thao tác bấm đầu.
  • Cáp bị đứt ( cáp không đạt tiêu chuẩn).
  • Sử dụng sai đôi dây cho những ứng dụng cụ thể.
Lỗi đảo ngược đôi dây – Align Reversed Pair
  • Dây dẫn kết nối sai chân tại đầu connector ( hai dây dẫn trong cùng một đôi dây được kết nối nhầm vị trí tại đầu connector).
Lỗi chéo đôi dây – Cross Pair
  • Nhầm lẫn giữa bấm đầu theo hai chuẩn 568A và 568B.
  • Vị trí đôi dây 12 và 36 bị chéo nhau.
Lỗi tách đôi dây – Split Pair
  • Một dây của đôi dây này nhầm vị trí với một dây của đôi dây khác

Lỗi về chiều dài cáp – Length:

Kết quả Những nguyên nhân có thể gây ra lỗi
Lỗi về chiều dài cáp – Length Exceeds Limits
  • Cáp sử dụng cho một đường truyền quá dài ( ví dụ giới hạn cho chiều dài 1 đường cáp ngang là không vượt quá 90m, để đảm bảo việc truyền tín hiệu trên đường dây).
  • Việc cài đặt thông số NVP trước khi tiến hành đo kiểm không chính xác. ( NVP là tốc độ danh định của tín hiệu truyền trên một sợi cáp. Với mỗi loại cáp thì có một thông số NVP nhất định)
Lỗi về chiều dài cáp đo được ngắn hơn chiều dài cáp thực tế kéo khi thi công
  • Cáp bị đứt ở đoạn giữa trên đường kéo cáp.
Một hoặc nhiều đôi dây có chiều dài ngắn hơn chiều dài cáp
  • Cáp bị đứt trên đường đi cáp.
  • Kết nối xấu.

Chú ý: Chiều dài của cáp sẽ được tính bằng chiều dài của đôi dây có chiều dài ngắn nhất trong cáp. Thông số NVP là khác nhau với mỗi đôi dây.

Lỗi Trễ Truyền – Delay Skew

Kết quả Nguyên nhân có thể gây ra lỗi
Vượt quá giới hạn cho phép – Exceeds Limits
  • Đường đi cáp quá dài.
  • Cáp không đạt tiêu chuẩn ( chất liệu cấu tạo nên sợi cáp không nguyên chất và khác nhau giữa từng đôi dây)

Suy Hao – Attenuation

Kết quả Nguyên nhân có thể gây ra lỗi
Vượt quá giới hạn cho phép – Exceeds Limits
  • Đường đi cáp quá dài.
  • Cáp không đạt tiêu chuẩn ( độ xoắn của các đôi dây không đạt,..)
  • Sử dụng loại cáp không phù hợp ( ví dụ dùng cáp cat3 cho ứng dụng dành cho cáp cat5 trở lên)
  • Việc cài đặt các thông số trước khi tiến hành đo kiểm không chính xác.

Lỗi về Nhiễu Đầu Gần và Tổng Nhiễu Đầu Gần ( NEXT and PSNEXT)

Kết quả Nguyên nhân có thể gây ra lỗi
Fail, *fail or *pass
  • Tháo xoắn quá mức khi thực hiện thao tác bấm đầu.
  • Patch Cord không đạt tiêu chuẩn.
  • Đầu connector không đạt chuẩn.
  • Cáp giả.
  • Lỗi tách đôi dây trong quá trình bấm đầu cáp..
  • Các đôi dây bị nén quá chặt do lớp vỏ bọc nhựa của cáp.
  • Cáp đặt cạnh nguồn gây nhiễu lớn

Suy Hao Phản Xạ Ngược ( Return Loss)

Kết quả Nguyên nhân có thể gây ra lỗi
Fail, *fail or *pass
  • Trở kháng của Patch Cord không đạt/ vượt quá 100 Ohm.
  • Patch Cord sử dụng không đúng cách làm cho trở kháng vượt quá/ không đạt 100 Ohm.
  • Thao tác khi tiến hành thi công cáp ( việc tháo xoắn các đôi dây).
  • Chừa đoạn dây dư quá dài tại outlet ( khuyến cáo nên chỉ để lại đoạn dây dư khoảng 30 cm).
  • Đầu connector không đạt chuẩn.
  • Trở kháng trên sợi cáp không đồng đều.
  • Trở kháng của sợi cáp vượt quá/ không đạt 100 Ohm.
  • Trở kháng khác nhau giữa patch cord và cáp ngang tại điểm đấu nối.
  • Tính tương thích giữa đầu connector và jack kém
  • Sử dụng cáp có trở kháng 120 Ohm.
  • Lựa chọn chế độ test tự động không chính xác.
  • Sai sót trong việc lựa chọn adapter.

Nhiễu Đầu Xa, Tổng Nhiễu Đầu Xa ( ACR-F & PS ACR-F hoặc ELFEXT & PSELFEXT)

Kết quả Nguyên nhân có thể gây ra lỗi
Fail, *fail or *pass
  • Qui tắc chung: phải khắc phục lỗi về NEXT trước. Vì NEXT thường là nguyên nhân gây ra FEXT
  • Cáp bị bó chặt trong quá trình thi công.

Điện Trở ( Resistance)

Kết quả Nguyên nhân có thể gây ra lỗi
Fail, *fail or *pass
  • Đường đi cáp vượt quá giới hạn cho phép.
  • Đầu connector kém vì bị oxy hóa.
  • Sự tiếp xúc giữa các đôi dây và đầu connector kém vì dây dẫn quá bé.
  • Cáp không đạt chuẩn ( độ dày cáp không đạt chuẩn).
  • Lựa chọn sai loại patch cord.

Nắm được những nguyên nhân có thể gây ra lỗi cho hệ thống mạng không những giúp người thi công tiết kiệm được thời gian trong khâu giải quyết, khắc phục lỗi hệ thống mạng mà ngoài ra còn hạn chế được những sai sót trong quá trình thi công để có một hệ thống mạng hoàn chỉnh, đạt tiêu chuẩn.

Aruba – AP Troubleshooting

In order to make the WLAN function, the access points need connectivity to the controller.  Let’s review what an AP does during the boot process

Acquire IP address (can be static or acquired from DHCP)

  • IP address is required for communication with the controller using PAPI and GRE
  • To verify the access point properly acquires an IP you will need console access to the AP

Discover Controller

  • The AP goes through the following process in trying to discover a controller
  1. Statically assigned
  2.  DHCP Vendor Option 43
  3. ADP Multicast: Group Address 239.0.82.11 (requires multicast routing to be enabled on infrastructure)
  4. ADP L2 Broadcast
  5. DNS (aruba-master.<localsuffix>
  • The AP will follow the sequence exactly as above.  Once the AP learns a controller address, it terminates the discovery process and attempts to communicate with the learned address.  If the AP doesn’t receive a response from the learned address, then the AP will initiate a full reboot and start the process again

Update Code if necessary

  • AP Compares the code level to the controller’s code level
  • If the code revision matches the AP will continue the boot process
  • If the code revision does not match the AP will obtain the new code from the controller using FTP (TFTP is used on the initial join or if the AP is purged
  • The AP will automatically reboot after the code upgrade/downgrade
  • “show ap database” shows the current status of each AP (will list if upgrading, rebooting, etc)

Obtain Configuration Information

  • Once an AP connects to a controller and has compatible code, it will receive its configuration over PAPI
  • “show ap config ap-name <ap-name>” will show the AP configuration being pushed to the AP

Build GRE Tunnel

  • GRE is used to carry all of the wireless traffic between the AP and the local controller
  • A GRE tunnel is created per SSID per AP
  • The AP System Profile Controller LMS-IP setting tells the AP which controller the AP should terminate with
  • Be sure to allow Protocol 47 between the controllers and APs
  • “show ap debug system-status ap-name <ap-name>” – shows the communication status between the controller and AP
  • “show datapath tunnel table”shows the GRE tunnels established with the controller (look for prt 47)
  • “show ap debug counters”shows how many times an AP has rebooted or bootstrapped

Enable Radio

  • Once the GRE tunnel has been established the Radios will become enabled
  • “show profile-errors” – shows the list of invalid user created profiles.  An invalid user profile could cause the AP not to broadcast its assigned SSIDs.

Add a Local Controller to an Existing Master

Once a network has scaled up beyond a single controller capacity, a master/local architecture is recommended.  This allows the master controller to handle configuration and correlation while the locals can be responsible for handling the user traffic.

Steps to Add a local controller to an existing Master:

From the Master GUI:

Configuration -> Network -> Controller -> System Settings

–          Click New Local Controller IPSec Keys

–          Enter the IP Address of the local controller that you are adding

–          Enter an IPSec key

–          Re-Enter the IPSec key

–          Click Add

–          Click Apply (don’t forget)

–          Save Configuration

Or From the Master CLI:

localip <local ip address> ipsec <ipsec key>

From the Local GUI:

Configuration -> Network -> Controller -> System Settings

–          Select Controller Role Drop-Down and select Local

–          Enter the Master Controller IP (VRRP address if using master redundancy)

–          Enter IPSec Key  (Same key you entered on Master)

–          Click Apply

–          Reboot Controller

Or From the Local CLI:

masterip <master ip address> ipsec <ipsec key>

Master Controller Redundancy – Configuration

I’m going to walk through the steps for configuring master redundancy.  Here is my scenario:

Primary Master – 10.10.10.11 (should always be the master if up)

Backup Master – 10.10.10.12

VRRP IP – 10.10.10.15

VRRP ID – 10

VLAN – 10

First let’s start with the VRRP configuration on the Primary Master.

config t

vrrp 10

vlan 10

ip address 10.10.10.15

priority 110

preempt

description Preferred-Master

tracking master-up-time 30 add 20

no shut

Now let’s configure the Backup-Master

config t

vrrp 10

vlan 10

ip address 10.10.10.15

priority 100

preempt

description Backup-Master

tracking master-up-time 30 add 20

no shut

Once VRRP is up I need to associate the VRRP instance with master controller redundancy:

On the Primary:

config t

master-redundancy

master-vrrp 10

peer-ip-address 10.10.10.12 ipsec aruba123

On the Backup:

config t

master-redundancy

master-vrrp 10

peer-ip-address 10.10.10.11 ipsec aruba123

Once the VRRP instance is associated with master redundancy then I need to synchronize the WMS and local user database between the two controllers:

config t

database synchronize period <minutes> – defines the scheduled time to sync the databases (minimum should be 20 minutes)

Controller Redundancy

For my first technical deep dive let’s get into controller redundancy. During this post I will define the different types of redundancy in the Aruba system.  Please no controller vs controller-less rants!

Let’s begin by defining redundancy.  According to Wikipedia, redundancy is the duplication of critical components or functions of a system with the intention of increasing reliability of the system.  Unfortunately redundancy is left off a lot of wireless network designs due to cost.  In today’s mobility first environments redundancy needs to be implemented properly to ensure the reliability of the mission critical WLAN.

In Aruba world we have four levels of controller redundancy:

1)      Fully redundant – includes both master and local redundancy

2)      Redundancy aggregation – local redundancy

3)      Hot Standby – Local access points fail-over to Master

4)      No Redundancy – self-explanatory (far too common)

Master Redundancy:

The first controller redundancy model we will look at is Master redundancy.  The master controller is the control plane of the centralized WLAN.  The master controller is responsible for handling the global configuration of the WLAN system, location tracking, IDS event correlation and alerting.  The first question we should ask ourselves is what happens if the master controller is unavailable?  If the master becomes unavailable all master functions are lost (configuration, location tracking, and IDS) but the WLAN itself will continue to function.  New and existing clients will still be able to access the WLAN while the master controller is down.

To provide redundancy for the master controller we will setup a master/standby relationship with two controllers.  The Standby Master is a hot standby controller.  The Standby Master will not terminate AP sessions while it is the backup unit.  Updates on the state of the network are sent from the active Master to the Backup.  The two controllers sync the databases (WMS and local user) at a configured interval (typically 30 minutes).

VRRP (Virtual Router Redundancy Protocol) is used as the redundancy mechanism between the two controllers.  VRRP requires Layer2 adjacency.  The two master controllers will use a shared VRRP interface address.  The VRRP address is used by local controllers, access points, and mobility access switches to discover the master controller on the network.  The VRRP address can also be used by network administrators to access the management interface for the current master controller.

Local Redundancy:

Next we will look at Local Controller Redundancy.  The Local Controllers in an Aruba WLAN are responsible for AP termination, user authentication, and policy enforcement.  If a local controller fails and there is no backup the WLAN will become unavailable.

Local controllers have three methods for redundancy

Active-Active

  • two locals share a set of APs,  divide the load, acts as a backup for each other
  • if the two controllers are L2 adjacent, run two instances of VRRP with each controller acting as a primary for one instance and backup for the other instance
  • if the two controllers are not L2 adjacent then you will need to setup a LMS/Backup LMS IP address in the AP System Profile
  • You can also combine VRRP and LMS/Backup LMS for a more robust redundancy design, the VRRP addresses can be used as the LMS/Backup LMS IP addresses

Active-Standby

  • similar to Active-Active except one controller sits idle while the primary controller supports the full loads of APs and users
  • this model has a larger failure domain (increases latency because the full load must failover to the backup
  • typically this model utilizes the LMS/Backup LMS configuration
  • you could also use a single VRRP instance if the controllers are L2 adjacent

Many to One

  • typically used in remote networks where branch offices have local mobility controllers but redundancy onsite is not feasible
  • a large controller is deployed as the +1 controller at the data center
  • failure typically occurs across a WAN link
  • preemption should be enabled in this scenario due to the possible delay introduced by failing over to a remote site

No Redundancy

  • if the local goes down, no users can connect
  • Any AMs associated go down

Now that we know the different types of redundancy options we need to be aware of a few rules to ensure our network stays up according to plan.  There are four major rules in dealing with controller redundancy:

  1. Make sure the redundant controller can support the additional AP load during a failover event
  2. Make sure the same VLANs exist on both controllers and that named VLANs are mapped on the redundant controller
  3. Make sure the controllers are running the same OS version
  4. Make sure the redundant controller has the same license features enable and ensure you have enough license capacity to support the additional AP load during a failover event (AOS 6.3 will address this previous limitation)

In my next post I will begin configuring each of the different redundancy methods.

SSL VPN configuration on SRX running 15.1X49-D80.4 or higher

Starting with version 15.1X49-D80.4 the Juniper SRX supports dialup vpn over a connection to port 443 with the NCP client. It needs some specific configuration to get that working and we found out the hard  way. So, we have decided to share it here.  Thank you Valentijn and Jasper for helping me.

The situation we want to achieve is this one:

To prepare for configuring a demo setup you need two things: A gateway running a Junos version that supports this feature and a NCP client. You should know how to get and install the SRX software, you can get the client here: https://www.ncp-e.com/en/resources/download-vpn-client/

The configuration we’re about to make gives us a dialup vpn where the client tries to connect to with standard IPsec. If that fails it will try to move the connection to SSL, which in many networks is allowed to travel freely…

Two profiles are configured to authenticate the user:
1)             lpdap-users: to authenticate against the AD control on 172.27.72.10, domain wsa.local

2)             local-users: In which two local users are defined.

Both profiles hand out IP addresses and DNS servers from the address assignment pool dyn-vpn-address-pool.
Please note we use rather weak proposals, just for testing purposes, in real life adjust them to your (companies) policy!

Phase 1 config
set security ike proposal my_ncp_proposals authentication-method pre-shared-keys

set security ike proposal my_ncp_proposals dh-group group2

set security ike proposal my_ncp_proposals authentication-algorithm md5

set security ike proposal my_ncp_proposals encryption-algorithm aes-128-cbc

set security ike proposal ncp-client authentication-method pre-shared-keys

set security ike proposal ncp-client dh-group group2

set security ike proposal ncp-client authentication-algorithm md5

set security ike proposal ncp-client encryption-algorithm aes-128-cbc

set security ike policy ike_ncp_client mode aggressive

set security ike policy ike_ncp_client proposals my_ncp_proposals

set security ike policy ike_ncp_client pre-shared-key ascii-text <key>

set security ike gateway ncp_test ike-policy ike_ncp_client

set security ike gateway ncp_test dynamic user-at-hostname “vpnuser@wsa.local”

set security ike gateway ncp_test dynamic ike-user-type shared-ike-id

set security ike gateway ncp_test external-interface ge-0/0/0.0

set security ike gateway ncp_test aaa access-profile ldap-users   *

set security ike gateway ncp_test version v1-only

set security ike gateway ncp_test tcp-encap-profile ssl-vpn

* You can change this to profile local-users to authenticate the users locally instead of against LDAP.

The last line of configuration tells the device to accept TCP encapsulated traffic according the mentionedprofile. Here is how to configure that profile:

set security tcp-encap profile ssl-vpn log

Since ike and tcp encapsulated traffic will arrive at the external interface, both should be accepted as host inbound traffic:

set security zones security-zone untrust host-inbound-traffic system-services ike

set security zones security-zone untrust host-inbound-traffic system-services tcp-encap

Because we want ssl vpn traffic on the interface no other listener should be enabled on the interface: make sure system service web-management https is not enabled on the external interface. Enabling it   on that interface would be a bad idea anyway.

Let’s take a look at the authentication profiles, starting with the ldap profile:

set access profile ldap-users authentication-order ldap

set access profile ldap-users authentication-order password

set access profile ldap-users domain-name-server 172.27.72.16

set access profile ldap-users domain-name-server 172.27.72.17

set access profile ldap-users client mtepper firewall-user password “$9$.PQ30ORSyK36pB1hKv4aJ”

set access profile ldap-users address-assignment pool dyn-vpn-address-pool

set access profile ldap-users ldap-options base-distinguished-name DC=wsa,DC=local

set access profile ldap-users ldap-options search search-filter sAMAccountName=

set access profile ldap-users ldap-options search admin-search distinguished-name CN=administrator,CN=Users,DC=wsa,DC=local

set access profile ldap-users ldap-options search admin-search password “$9$Cze7uIheK87NbM8ZUDjq.uOB1SreKM”

set access profile ldap-users ldap-server 172.27.72.10 port 389

set access profile ldap-users ldap-server 172.27.72.11 port 389

As you can see the administrator account is used here for a lookup. In real life you might want to create an account with just the necessary rights in the Active Direcory domain. Also note that you need to adjust the base-distinguished-name to your own domain.

For a simple test you could use a profile with local users like this:

set access profile local-users client jverdonk firewall-user password “$9$m5nCOBESlMz3EyeW-dZUjkmTQFn/Ap”

set access profile local-users client mtepper firewall-user password “$9$xXNNbYDjqf5FYgGiHmF3cyr”

set access profile local-users address-assignment pool dyn-vpn-address-pool

Both profiles use the same address pool for address assignment configuring this pool isn’t a hard task as well:

set access address-assignment pool dyn-vpn-address-pool family inet network 192.168.3.0/24

set access address-assignment pool dyn-vpn-address-pool family inet xauth-attributes primary-dns 172.26.72.16/32

set access address-assignment pool dyn-vpn-address-pool family inet xauth-attributes secondary-dns 172.27.72.17/32

This makes the configuration complete for phase 1 and phase 1½ (meaning for Xauth, which asks for    authentication between phase 1 and phase 2). Time to look at phase 2 config then. According the documentation about SSL VPN we found a route based VPN with tunnel interface in point to point mode is needed to get things working. So, we configured this:

An interface in the security zone trust (best practice for production is creating a zone called VPN and use that to make clear what happing in your policies) and an intrazone security policy:

set interfaces st0 unit 0 family inet

set security zones security-zone trust interfaces st0.0

set security policies from-zone trust to-zone trust policy default-permit match source-address any

set security policies from-zone trust to-zone trust policy default-permit match destination-address any

set security policies from-zone trust to-zone trust policy default-permit match application any

set security policies from-zone trust to-zone trust policy default-permit then permit

 

Finally for the SRX we can configure the phase 2: (As in phase 1 in real use stronger proposols!)

set security ipsec proposal dialup-ncp protocol esp

set security ipsec proposal dialup-ncp authentication-algorithm hmac-md5-96

set security ipsec proposal dialup-ncp encryption-algorithm aes-128-cbc

set security ipsec proposal dialup-ncp lifetime-seconds 3600

set security ipsec policy ipsec_ncp perfect-forward-secrecy keys group2

set security ipsec policy ipsec_ncp proposals dialup-ncp

set security ipsec vpn Ipsec_ncp bind-interface st0.0

set security ipsec vpn Ipsec_ncp ike gateway ncp_test

set security ipsec vpn Ipsec_ncp ike ipsec-policy ipsec_ncp

set security ipsec vpn Ipsec_ncp traffic-selector test local-ip 0.0.0.0/0

set security ipsec vpn Ipsec_ncp traffic-selector test remote-ip 0.0.0.0/0

The gateway  is ready now, time to move to the client.

After installing the software, start it and go into the configuration of a profile. Configure things like shown here: any tab not shown is left default!

The relevant part of the config of the SRX should look like this:

security {
    ike {
        proposal my_ncp_proposals {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm md5;
            encryption-algorithm aes-128-cbc;
        }
        proposal ncp-client {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm md5;
            encryption-algorithm aes-128-cbc;
        }
        policy ike_ncp_client {
            mode aggressive;
            proposals my_ncp_proposals;
            pre-shared-key ascii-text "$9$MB7WdbUDk5T3P5M8"; ## SECRET-DATA
        }
        gateway ncp_test {
            ike-policy ike_ncp_client;
            dynamic {
                user-at-hostname "vpnuser@wsa.local";
                ike-user-type shared-ike-id;
            }
            external-interface ge-0/0/0.0;
            aaa {
                access-profile ldap-users;
            }
            version v1-only;
            tcp-encap-profile ssl-vpn;
        }
    }
    ipsec {
        proposal dialup-ncp {
            protocol esp;
            authentication-algorithm hmac-md5-96;
            encryption-algorithm aes-128-cbc;
            lifetime-seconds 3600;
        }
        policy ipsec_ncp {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals dialup-ncp;
        }
        vpn Ipsec_ncp {
            bind-interface st0.0;
            ike {
                gateway ncp_test;
                ipsec-policy ipsec_ncp;
            }
            traffic-selector test {
                local-ip 0.0.0.0/0;
                remote-ip 0.0.0.0/0;
            }
        }
    }
    policies {
        from-zone trust to-zone trust {
            policy default-permit {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    tcp-encap {
        profile ssl-vpn {
            log;
        }
    }
    zones {
        security-zone untrust {
            host-inbound-traffic {
                system-services {
                    ike;
                    tcp-encap;
                }
            }
        }
        security-zone trust {
            interfaces {
                st0.0;
            }
        }
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 1.2.3.4/24;
            }
        }
    }
    st0 {
        unit 0 {
            family inet;
        }
    }
}

access {
    profile ldap-users {
        authentication-order [ ldap password ];
        domain-name-server {
            172.27.72.16;
            172.27.72.17;
        }
        client mtepper {
            firewall-user {
                password "$9$.PQ30ORSyK36pB1hKv4aJ"; ## SECRET-DATA
            }
        }
        address-assignment {
            pool dyn-vpn-address-pool;
        }
        ldap-options {
            base-distinguished-name DC=wsa,DC=local;
            search {
                search-filter sAMAccountName=;
                admin-search {
                    distinguished-name CN=administrator,CN=Users,DC=wsa,DC=local;
                    password "$9$Cze7uIheK87NbM8ZUDjq.uOB1SreKM"; ## SECRET-DATA
                }
            }
        }
        ldap-server {
            172.27.72.10 port 389;
            172.27.72.11 port 389;
        }
    }
    profile local-users {
        client jverdonk {
            firewall-user {
                password "$9$m5nCOBESlMz3EyeW-dZUjkmTQFn/Ap"; ## SECRET-DATA
            }
        }
        client mtepper {
            firewall-user {
                password "$9$xXNNbYDjqf5FYgGiHmF3cyr"; ## SECRET-DATA
            }
        }
        address-assignment {
            pool dyn-vpn-address-pool;
        }
    }
    address-assignment {
        pool dyn-vpn-address-pool {
            family inet {
                network 192.168.3.0/24;
                xauth-attributes {
                    primary-dns 172.26.72.16/32;
                    secondary-dns 172.27.72.17/32;
                }
            }
        }
    }
}

Documenting a Network with CDP

In this post I will use the information available from CDP to help me create a logical network diagram.

CDP is the Cisco Discovery Protocol and is enabled on all router and switch interfaces by default. The switch or router sends a CDP packet out of each interface every 60 seconds, any connected device records the delivery of these packets into a CDP table for a holdtime period of 180 seconds. If after 180 seconds the device has not received any more CDP packets on that interface it removes the entry from the table. CDP can be disabled entirely or on any individual interface.

I begin by connecting to my switch and I check the CDP settings.

switch1#sh cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Sending CDPv2 advertisements is enabled

From the output I can see the CDP time settings and the version. Next I look at the connected devices.

switch1#sh cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater

Device ID Local Intrfce Holdtme Capability Platform Port ID
switch2.lab.localFas 0/1 160 S I WS-C2950-2Fas 0/1
switch2.lab.localFas 0/24 160 S I WS-C2950-2Fas 0/24

Here I can see that I have 2 ports (1 & 24) connected to switch2 (also using ports 1 & 24). I can also see that switch2 is a Catalyst 2950.

This is a great summary but for my diagram I could do with knowing the IP address of switch2.

switch1#sh cdp entry *
————————-
Device ID: switch2.lab.local
Entry address(es):
IP address: 10.0.1.211
Platform: cisco WS-C2950-24, Capabilities: Switch IGMP
Interface: FastEthernet0/1, Port ID (outgoing port): FastEthernet0/1
Holdtime : 142 sec

Version :
Cisco Internetwork Operating System Software
IOS ™ C2950 Software (C2950-I6Q4L2-M), Version 12.1(13)EA1, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2003 by cisco Systems, Inc.
Compiled Tue 04-Mar-03 02:14 by yenanh

advertisement version: 2
Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=00000000FFFFFFFF01022505000000000000000CCE3E3EC0FF0000
VTP Management Domain: ‘lab.local’
Native VLAN: 1
Duplex: full

————————-
Device ID: switch2.lab.local
Entry address(es):
IP address: 10.0.1.211
Platform: cisco WS-C2950-24, Capabilities: Switch IGMP
Interface: FastEthernet0/24, Port ID (outgoing port): FastEthernet0/24
Holdtime : 142 sec

Version :
Cisco Internetwork Operating System Software
IOS ™ C2950 Software (C2950-I6Q4L2-M), Version 12.1(13)EA1, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2003 by cisco Systems, Inc.
Compiled Tue 04-Mar-03 02:14 by yenanh

advertisement version: 2
Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=00000000FFFFFFFF01022505000000000000000CCE3E3EC0FF0000
VTP Management Domain: ‘lab.local’
Native VLAN: 1
Duplex: full

This detailed output gives me additional useful information such as the VLAN and the IOS version.

Next I head over to switch2 and look at it’s CDP information.

switch2#sh cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID
switch1 Fas 0/24 168 S I WS-C2950-2Fas 0/24
switch1 Fas 0/1 168 S I WS-C2950-2Fas 0/1
router1.lab.localFas 0/2 175 R Cisco C831Eth 0
router1.lab.localFas 0/23 175 R Cisco C831Eth 1

Here I can see the connections to switch1 and additional connections to router1. Again I look at the detailed information to get the IP address of the router.

switch2#sh cdp entry *
————————-
Device ID: switch1
Entry address(es):
IP address: 10.0.1.210
Platform: cisco WS-C2950-24, Capabilities: Switch IGMP
Interface: FastEthernet0/24, Port ID (outgoing port): FastEthernet0/24
Holdtime : 152 sec

Version :
Cisco Internetwork Operating System Software
IOS ™ C2950 Software (C2950-I6Q4L2-M), Version 12.1(12c)EA1, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Sun 24-Nov-02 23:31 by antonino

advertisement version: 2
Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=00000000FFFFFFFF01022505000000000000000C8582C600FF0000
VTP Management Domain: ‘lab.local’
Native VLAN: 1
Duplex: full

————————-
Device ID: switch1
Entry address(es):
IP address: 10.0.1.210
Platform: cisco WS-C2950-24, Capabilities: Switch IGMP
Interface: FastEthernet0/1, Port ID (outgoing port): FastEthernet0/1
Holdtime : 152 sec

Version :
Cisco Internetwork Operating System Software
IOS ™ C2950 Software (C2950-I6Q4L2-M), Version 12.1(12c)EA1, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Sun 24-Nov-02 23:31 by antonino

advertisement version: 2
Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=00000000FFFFFFFF01022505000000000000000C8582C600FF0000
VTP Management Domain: ‘lab.local’
Native VLAN: 1
Duplex: full

————————-
Device ID: router1.lab.local
Entry address(es):
IP address: 10.0.2.254
Platform: Cisco C831, Capabilities: Router
Interface: FastEthernet0/23, Port ID (outgoing port): Ethernet1
Holdtime : 176 sec

Version :
Cisco IOS Software, C831 Software (C831-K9O3Y6-M), Version 12.4(4)T1, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Thu 22-Dec-05 01:39 by ccai

advertisement version: 2
Duplex: half

————————-
Device ID: router1.lab.local
Entry address(es):
IP address: 10.0.1.254
Platform: Cisco C831, Capabilities: Router
Interface: FastEthernet0/2, Port ID (outgoing port): Ethernet0
Holdtime : 176 sec

Version :
Cisco IOS Software, C831 Software (C831-K9O3Y6-M), Version 12.4(4)T1, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Thu 22-Dec-05 01:39 by ccai

advertisement version: 2
Duplex: full

From the output I am able to determine the IP addresses of the connected router interfaces and I can also see that one interface is configured to half duplex. Now I have some good information to begin populating my diagram with.

From here I would probably move to the router and look at the CDP table. But supposing I want to prevent CDP packets from leaving an interface? After all, quite detailed information is included in CDP that you might not want everyone to view.

I connect to the device that I want to stop sending CDP packets and turn CDP off on that particular interface. In my case I would like to stop router1 from sending CDP packets on interface ethernet 1.

router1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
router1(config)#int ethernet 1
router1(config-if)#no cdp enable
router1(config-if)#end

Now when I check the switch that router1 is connected to I see that the holdtime decreases as the switch receives no CDP packet on the interface until after 180 seconds it reaches 0 and the entry is removed from the table.

switch2#sh cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID
switch1 Fas 0/24 159 S I WS-C2950-2Fas 0/24
switch1 Fas 0/1 159 S I WS-C2950-2Fas 0/1
router1.lab.localFas 0/23 6 R Cisco C831Eth 1
router1.lab.localFas 0/2 126 R Cisco C831Eth 0

switch2#sh cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID
switch1 Fas 0/24 153 S I WS-C2950-2Fas 0/24
switch1 Fas 0/1 152 S I WS-C2950-2Fas 0/1
router1.lab.localFas 0/23 0 R Cisco C831Eth 1
router1.lab.localFas 0/2 179 R Cisco C831Eth 0

switch2#sh cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID
switch1 Fas 0/24 147 S I WS-C2950-2Fas 0/24
switch1 Fas 0/1 147 S I WS-C2950-2Fas 0/1
router1.lab.localFas 0/2 174 R Cisco C831Eth 0