Destination NAT (port forwarding, PAT, NAPT) on Juniper SRX series

There will be cases when a static 1:1 NAT from an external IP to an Internal IP is not applicable, for instance when there is only one IP available for your Juniper SRX device or when there are more internal servers to expose than external IPs available. Then static NAT and source NAT wont do the trick for you to expose your service. Then comes the destination NAT method into play (also called by other vendors under the names port forwarding, PAT and NAPT).

In this example we have a typical branch office having only one external IP available and a Juniper SRX100, but still the need to expose a web server (172.16.0.80) and a SMTP server (172.16.0.25). The SRX device will be configured with external IP is 193.221.119.254/24 and internal IP 172.16.0.1/24. Then we will build destination nat pools for each server with the trick that we only have one member per pool. Also needed is of course address book entries, security policies and destination nat policies.

First out configure the interfaces, internal vlan, zones, base policies and base source NAT:

set interfaces fe-0/0/0.0 family inet address 193.221.119.254/24
set interfaces vlan.1 family inet address 172.16.0.1/24
set vlans internal vlan-id 1
set vlans internal l3-interface vlan.1
set interfaces fe-0/0/1.0 family ethernet-switching port-mode access
set interfaces fe-0/0/1.0 family ethernet-switching vlan members internal
set interfaces fe-0/0/2.0 family ethernet-switching port-mode access
set interfaces fe-0/0/2.0 family ethernet-switching vlan members internal
set interfaces fe-0/0/3.0 family ethernet-switching port-mode access
set interfaces fe-0/0/3.0 family ethernet-switching vlan members internal
set interfaces fe-0/0/4.0 family ethernet-switching port-mode access
set interfaces fe-0/0/5.0 family ethernet-switching vlan members internal
set interfaces fe-0/0/6.0 family ethernet-switching port-mode access
set interfaces fe-0/0/6.0 family ethernet-switching vlan members internal
set interfaces fe-0/0/7.0 family ethernet-switching port-mode access
set interfaces fe-0/0/7.0 family ethernet-switching vlan members internal

set security zone security-zone trust interface vlan.1
set security zone security-zone trust host-inbound-traffic protocols all
set security zone security-zone trust host-inbound-traffic system-services all
set security zone security-zone untrust interface fe-0/0/0.0

set security policies from-zone trust to-zone untrust policy AllowAll match source-address any destination-address any application any
set security policies from-zone trust to-zone untrust policy AllowAll then permit
set security policies from-zone trust to-zone untrust policy DenyAll match source-address any destination-address any application any
set security policies from-zone trust to-zone untrust policy DenyAll then log session-init
set security policies from-zone trust to-zone untrust policy DenyAll then deny

set security policies from-zone untrust to-zone trust policy DenyAll match source-address any destination-address any application any
set security policies from-zone untrust to-zone trust policy DenyAll then log session-init
set security policies from-zone untrust to-zone trust policy DenyAll then deny

set security zone security-zone trust address-book address Webserver 172.16.0.80/32
set security zone security-zone trust address-book address Mailserver 172.16.0.25/32

set security nat source rule-set trust-to-untrust from zone trust
set security nat source rule-set trust-to-untrust to zone untrust
set security nat source rule-set trust-to-untrust rule HideAll match source-address 0.0.0.0/0
set security nat source rule-set trust-to-untrust rule HideAll then source-nat interface

Now create the destination NAT pools:

set security nat destination pool Webserver address 172.16.0.80/32
set security nat destination pool Webserver address port 80
set security nat destination pool Mailserver address 172.16.0.25/32
set security nat destination pool Mailserver address port 25

The we create the necessary destination nat policies:

set security nat destination rules-set dst-nat from zone untrust
set security nat destination rules-set dst-nat to zone trust
set security nat destination rules-set dst-nat rule Webserver match destination-address 193.221.119.254/32
set security nat destination rules-set dst-nat rule Webserver match destination-port 80
set security nat destination rules-set dst-nat rule Webserver then destination-nat pool Webserver
set security nat destination rules-set dst-nat rule Mailserver match destination-address 193.221.119.254/32
set security nat destination rules-set dst-nat rule Mailserver match destination-port 25
set security nat destination rules-set dst-nat rule Mailserver then destination-nat pool Mailserver

Lastly we need security policies to allow the traffic through the firewall. Please note that NAT takes place before security policy application, so security policies are written for the actual real internal IP addresses:

set security policies from-zone untrust to-zone trust policy Webserver match source-address any destination-address Webserver application junos-http
set security policies from-zone untrust to-zone trust policy Webserver then permit
set security policies from-zone untrust to-zone trust policy Mailserver match source-address any destination-address Mailserver application junos-smtp
set security policies from-zone untrust to-zone trust policy Mailserver then permit

Since we already had a DenyAll rule from zone untrust to zone trust, we need to make sure our newly written policies gets added before the DenyAll policy:

insert security policies from-zone untrust to-zone trust policy Webserver before policy DenyAll
insert security policies from-zone untrust to-zone trust policy Mailserver after policy Webserver

And now it should all be working fine!

Try it out!

Posted in Juniper Networking, Juniper Security, Networking, Security | Comments Off on Destination NAT (port forwarding, PAT, NAPT) on Juniper SRX series

Using MF filters to perform CoS based on prefixes in a SRX or J series router

If you have a J series or SRX and have some networks downstream that should equally or unequally share an Internet resource. And you dont care about sorting traffic on layer 4 or using standard DSCP classification. It is enough that the different subnets get the bandwidth you want to divide to them. This how you do it.

The below example is a J/SRX router with ge-0/0/0.0 towards Internet and ge-0/0/1.0 to ge-0/0/4.0 have subnets where ge-0/0/1.0 should have 40 percent of the bandwdith guaranteed and ge.0/0/2.0 – ge-0/0/4.0 should have 20 percent of the bandwidth each. All should share equally if here is unused bandwidth.

If you are using a SRX or J series in flow mode, you also need to make sure you have have configured the security stanza correct with zones, adress-books, nat rules, firewall polices etc correctly for the traffic to flow. The below example is strictly the CoS configuration.

Another limitation is that this method only works for a small number of subnets, you only have 8 queues on an interface.

/*
Make sure each interface do per unit scheduling in case we actually will a single IFD with IFL:s and not several interfaces. Config below will work with both models.
*/

set interface ge-0/0/0 per-unit-scheduler
set interface ge-0/0/1 per-unit-scheduler
set interface ge-0/0/2 per-unit-scheduler
set interface ge-0/0/3 per-unit-scheduler
set interface ge-0/0/4 per-unit-scheduler

/*
Configure default DSCP values. We will anyways override this with MF firewall filters. But CoS demands classifier config…
*/

set class-of-service classifiers dscp MyClassifier import default

/*
The reason for the unlogical mapping of queues to forwarding classes is that queue 0 and 3 have some hard coded traffic sent to them.
*/

set class-of-service forwarding-classes SUBNET1 queue 1
set class-of-service forwarding-classes SUBNET2 queue 2
set class-of-service forwarding-classes SUBNET3 queue 4
set class-of-service forwarding-classes SUBNET3 queue 5

/*
The percentage guarantees bandwidth. If there in fact is bandwidth leftover not used by a scheduler, it will be evenly distributed between schedulers since they all have same prio level.
*/

set class-of-service schedulers SUBNET1 transmit-rate percent 40
set class-of-service schedulers SUBNET1 buffer-size percent 40
set class-of-service schedulers SUBNET1 priority low

set class-of-service schedulers SUBNET2 transmit-rate percent 20
set class-of-service schedulers SUBNET2 buffer-size percent 20
set class-of-service schedulers SUBNET2 priority low

set class-of-service schedulers SUBNET3 transmit-rate percent 20
set class-of-service schedulers SUBNET3 buffer-size percent 20
set class-of-service schedulers SUBNET3 priority low

set class-of-service schedulers SUBNET4 transmit-rate percent 20
set class-of-service schedulers SUBNET4 buffer-size percent 40
set class-of-service schedulers SUBNET4 priority low

/*
Map schedulers for forwarding class
*/

set class-of-service scheduler-maps MyMap forwarding-class SUBNET1 scheduler SUBNET1
set class-of-service scheduler-maps MyMap forwarding-class SUBNET2 scheduler SUBNET2
set class-of-service scheduler-maps MyMap forwarding-class SUBNET3 scheduler SUBNET3
set class-of-service scheduler-maps MyMap forwarding-class SUBNET4 scheduler SUBNET4

/*
Map interfaces to schedulers and classifiers. Can be repeated for several IFL:s unde rome IFD if needed. I assume here we actually can use all interfaces ge-0/0/0 – ge-0/0/3. But config works with a single IFD with IFL:s aswell if configured so below. I totally skip rewrite rules since we actually won’t be using DSCP at all, we just want to map traffic to queues to police them.
*/

set class-of-service interface ge-0/0/0 unit 0 classifiers dscp MyClassifier
set class-of-service interface ge-0/0/0 unit 0 scheduler-map MyMap

set class-of-service interface ge-0/0/1 unit 0 classifiers dscp MyClassifier
set class-of-service interface ge-0/0/1 unit 0 scheduler-map MyMap

set class-of-service interface ge-0/0/2 unit 0 classifiers dscp MyClassifier
set class-of-service interface ge-0/0/2 unit 0 scheduler-map MyMap

set class-of-service interface ge-0/0/3 unit 0 classifiers dscp MyClassifier
set class-of-service interface ge-0/0/3 unit 0 scheduler-map MyMap

set class-of-service interface ge-0/0/4 unit 0 classifiers dscp MyClassifier
set class-of-service interface ge-0/0/4 unit 0 scheduler-map MyMap

/*
Now we need to define MF filters to move traffic into the forwarding-classes. This ties defined forwarding-classes under class-of-service to traffic matched in MF firewall filters with prefix-lists created under policy-options.
*/

set policy-options prefix-list SUBNET1 192.168.1.0/24
set policy-options prefix-list SUBNET2 192.168.2.0/24
set policy-options prefix-list SUBNET3 192.168.3.0/24
set policy-options prefix-list SUBNET4 192.168.4.0/24

set firewall filter MapCoS term SUBNET1 from prefix-list SUBNET1
set firewall filter MapCoS term SUBNET1 then forwarding-class SUBNET1
set firewall filter MapCoS term SUBNET1 then accept

set firewall filter MapCoS term SUBNET2 from prefix-list SUBNET2
set firewall filter MapCoS term SUBNET2 then forwarding-class SUBNET2
set firewall filter MapCoS term SUBNET2 then accept

set firewall filter MapCoS term SUBNET3 from prefix-list SUBNET3
set firewall filter MapCoS term SUBNET3 then forwarding-class SUBNET3
set firewall filter MapCoS term SUBNET3 then accept

set firewall filter MapCoS term SUBNET4 from prefix-list SUBNET4
set firewall filter MapCoS term SUBNET4 then forwarding-class SUBNET4
set firewall filter MapCoS term SUBNET4 then accept

/*
Since we used prefix-list as option in MF filters we can apply these as input filters on all interfaces involved.
*/

set interfaces ge-0/0/0.0 description “Internet”
set interfaces ge-0/0/0.0 family inet address 193.221.119.4/27
set interfaces ge-0/0/0.0 family inet input filter MapCoS

set interfaces ge-0/0/1.0 description “SUBNET1”
set interfaces ge-0/0/1.0 family inet address 192.168.1.1/24
set interfaces ge-0/0/1.0 family inet input filter MapCoS

set interfaces ge-0/0/2.0 description “SUBNET2”
set interfaces ge-0/0/2.0 family inet address 192.168.2.1/24
set interfaces ge-0/0/2.0 family inet input filter MapCoS

set interfaces ge-0/0/3.0 description “SUBNET3”
set interfaces ge-0/0/3.0 family inet address 192.168.3.1/24
set interfaces ge-0/0/3.0 family inet input filter MapCoS

set interfaces ge-0/0/4.0 description “SUBNET4”
set interfaces ge-0/0/4.0 family inet address 192.168.4.1/24
set interfaces ge-0/0/4.0 family inet input filter MapCoS

The distribution of traffic on an interface can be verified from non priviliged mode via:
show interface queue ge-0/0/0.0
show interface queue ge-0/0/1.0
show interface queue ge-0/0/2.0
show interface queue ge-0/0/3.0
show interface queue ge-0/0/4.0

Try it out!

Posted in Juniper Networking, Juniper Security, Networking, Security | 2 Comments

Using SRX and J series as a packet based router instead a flow based firewall

When using SRX or J series in the network it most of the time serves as a firewall or secure router. But sometimes it is used just like a L3 CPE with routing and/or MPLS. Disable flow forwarding and fall back to packet forwarding to gain a few more pps out of a CPU based platform like SRX and J series.

This is how it is done:

set security forwarding-options family mpls mode packet-based
set security forwarding-options family inet6 mode packet-based
set security forwarding-options family iso mode packet-based

Then reboot the SRX/J series. And you are done.

Try it out!

Posted in Juniper Networking, Juniper Security, Networking, Security | Leave a comment

Using apply-path in JUNOS config to create dynamical prefix lists under policy options

Have you faced the problem that you would like to build prefix lists to protect your route engine or CPU in SRX/J-series that consists of elements that also exists elsewhere in the configuration? Would’nt it be nice to actually only have to maintain information in one place? The solution to this problem is apply-path available for instance under prefix-list under policy-option i JUNOS.

So lets get started with an example relating to things you actually might want to do.

I want to create a filter that only let my BGP neighbors, NTP servers, DNS server etc to access my route engine. I also might want to allow some chosen management PCs/Networks be able to access.
So first off lets create some prefix-lists actually fetching information dynamically from other parts of your JUNOS configuration:

set policy-options prefix-list DNSSERVERS apply-path “system name-server <*>”
set policy-options prefix-list NTPSERVERS apply-path “system ntp server <*>”
set policy-options prefix-list SNMPSERVERS apply-path “snmp client-list <*> <*>”
set policy-options prefix-list BGPNEIGHBORS apply-path “protocols bgp group <*> neighbor <*>”
set policy-options prefix-list LOCALIPv4IP apply-path “interfaces <*> unit <*> family inet address <*>”

See how above actually creates lists using reg-exps a from other parts of the JUNOS config?
Then also build a few statically:

set policy-options prefix-list OSPF 224.0.0.5/32
set policy-options prefix-list OSPF 224.0.0.5/32

Also create a list with sources that are supposed to SSH/FTP/TELNET your router:

set policy-options prefix-list MGMT 192.168.142.0/24

Then use these prefix lists in a firewall config, for example:

set firewall filter family inet filter ProtectRE term DNS1 from source-prefix-list DNSSERVERS
set firewall filter family inet filter ProtectRE term DNS1 from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term DNS1 from protocol udp
set firewall filter family inet filter ProtectRE term DNS1 from source-port 53
set firewall filter family inet filter ProtectRE term DNS1 then accept

set firewall filter family inet filter ProtectRE term DNS2 from source-prefix-list DNSSERVERS
set firewall filter family inet filter ProtectRE term DNS2 from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term DNS2 from protocol tcp
set firewall filter family inet filter ProtectRE term DNS2 from source-port 53
set firewall filter family inet filter ProtectRE term DNS2 then accept

set firewall filter family inet filter ProtectRE term NTP1 from source-prefix-list NTPSERVERS
set firewall filter family inet filter ProtectRE term NTP1 from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term NTP1 from protocol udp
set firewall filter family inet filter ProtectRE term NTP1 from port ntp
set firewall filter family inet filter ProtectRE term NTP1 then accept

set firewall filter family inet filter ProtectRE term NTP2 from source-prefix-list NTPSERVERS
set firewall filter family inet filter ProtectRE term NTP2 from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term NTP2 from protocol tcp
set firewall filter family inet filter ProtectRE term NTP2 from port ntp
set firewall filter family inet filter ProtectRE term NTP2 then accept

set firewall filter family inet filter ProtectRE term OSPF from source-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term OSPF from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term OSPF from protocol ospf
set firewall filter family inet filter ProtectRE term OSPF then accept

set firewall filter family inet filter ProtectRE term BGP from source-prefix-list BGPNEIGHBORS
set firewall filter family inet filter ProtectRE term BGP from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term BGP from protocol tcp
set firewall filter family inet filter ProtectRE term BGP from port bgp
set firewall filter family inet filter ProtectRE term BGP then accept

set firewall filter family inet filter ProtectRE term SNMP from source-prefix-list SNMPSERVERS
set firewall filter family inet filter ProtectRE term SNMP from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term SNMP from protocol udp
set firewall filter family inet filter ProtectRE term SNMP from port snmp
set firewall filter family inet filter ProtectRE term SNMP then accept

set firewall filter family inet filter ProtectRE term SSH from source-prefix-list MGMT
set firewall filter family inet filter ProtectRE term SSH from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term SSH from protocol tcp
set firewall filter family inet filter ProtectRE term SSH from port ssh
set firewall filter family inet filter ProtectRE term SSH then accept

set firewall filter family inet filter ProtectRE term ICMP from protocol icmp
set firewall filter family inet filter ProtectRE term ICMP then accept

set firewall filter family inet filter ProtectRE term UDPTracert from destination-prefix-list LOCALIPv4IP
set firewall filter family inet filter ProtectRE term UDPTracert from protocol udp
set firewall filter family inet filter ProtectRE term UDPTracert from destination-port 33435-33450
set firewall filter family inet filter ProtectRE term UDPTracert from ttl 1

set firewall filter family inet filter ProtectRE term DropAll then discard

Apply to loopback:

set interface lo0.0 family inet input filter ProtectRE

The filter above can be expanded with more terms using more prefix lists built by apply path. Also a proper firewall filter for RE/Router protection might want to apply policing to some of the terms. But this was an example of apply-path.

Hope it helps you in yoru day to day JUNOS configuring.

Posted in Device Management, Juniper Networking, Managing Juniper devices, Networking | Leave a comment

Upgrading compact flash cards in Juniper J/SRX routers, EX switches or M/T/TX/MX route engines

Every now and then the JUNOS image grows and Juniper deploys a larger compact flash in their devices like switches, branch routers and route engines. But for the devices already present in the network a need of upgrading the compact flash drive occur. Below is a procedure to make that upgrade a smooth as possible.

Upgrading devices without secondary hard drive
Some Juniper devices are not built with hard drive as complement to the compact flash. Typically this is J series, SRX series and EX series. First requirement is that the Juniper device have a secondary compact flash card slot or that it is possible to open the Juniper device and the compact flash is replaceable. Second requirement is that if the Juniper device is not equipped with a slot for a secondary compact flash card, an USB connected external compact flash drive writer is needed. The safest bet to get one that is supported is SanDisk’s flash writers. The picture below shows one that for certain is supported by JUNOS.
SanDisk Compact Flash Disk writer

First step is to cleanup the compact flash card:
request system storage cleanup

Answer “yes” to all questions.

Next step is to insert the flash drive into the USB port and insert a new compact flash card of proper size to support the new larger JUNOS image into the compact flash card writer. Then simply run:
request system snapshot partition media usb

This formats the compact flash card in the compact flash card writer and then performs a copy from the devices compact flash card complete with boot image and configuration. Then power off your device. Now remove the old compact flash card from the Juniper device and insert the one from the compact flash card writer.

If a removable compact flash card slot is present, insert the new compact flash card of proper size to support the new larger JUNOS image into the slot. Then run:
request system snapshot partition media removable-compact-flash as-primary

This formats the compact flash card in the removable compact flash card slot and then performs a copy from the devices compact flash card complete with boot image and configuration. as-primary also prepares the flash card and device to use the removable compact flash card as primary boot source. To reboot properly then run:
request system reboot media removable-compact-flash

Voila, the device boots on the new compact flash card and an upgrade to the new larger JUNOS image is possible. Keep the old compact flash as backup.

Upgrading devices with a secondary hard drive
Most larger Juniper systems like M,MX,T,TX and PTX have secondary hard drive in their route engine. This makes the compact flash upgrade procedure simpler in the way that a compact flash card writer is not needed. Do remember since that the upgarde procedure includes a reboot of the route engine so that if a non graceful switchover (GRES) strategy is not used, their will be traffic impact. If a GRES and/or GRES-NSR (non-stop routing) strategy is used on the REs, there is NO traffic impact.

First step is to cleanup the compact flash card:
request system storage cleanup

Answer “yes” to all questions.

Then login to the secondary RE. There perform:
request system snapshot partition

This performs a backup of the compact flash to the hard drive.

Then reboot on the disk:
request system reboot media disk

Check so that the secondary RE booted OK on the disk as boot media. Next power off your secondary RE. Perform a flash disk swap to the new compact flash crad with proper size to handle the new larger JUNOS image. Power up the RE. Then run:
request system snapshot partition

This formats the new compact flash card and copies the backup on the hard drive to the flash card. To reboot properly then run:
request system reboot media compact-flash

Now the secondary RE is done. Now move on to the primary RE. First change master ship to the secondary RE so the primary can be manipulated:
request chassis routing-engine master switch

Now repeat the actions for primary RE as performed for secondary RE. When that is done, the new larger JUNOS image can safely be installed.

So a summary:

Upgrading devices without secondary hard drive with removable compact flash card slot
request system storage cleanup
request system snapshot partition media removable-compact-flash as-primary
request system reboot media removable-compact-flash

Upgrading devices without secondary hard drive with external USB compact flash card writer
request system storage cleanup
request system snapshot partition media usb

Remove compact flash card from the device and replace with the new from the compact flash card writer.

Upgrading devices with a secondary hard drive
On the RE that is currently not master:
request system storage cleanup
request system snapshot partition
request system reboot media disk

Check so that the RE booted correctly on disk. Power off the RE. Remove the old compact flash from the RE and insert the new compact flash. Boot up the RE.
request system snapshot partition
request system reboot media compact-flash

Check so the RE booted up correctly.

Now switch master ship:
request chassis routing-engine master switch
On the RE that is currently not master:
request system storage cleanup
request system snapshot partition
request system reboot media disk

Check so that the RE booted correctly on disk. Power off the RE. Remove the old compact flash from the RE and insert the new compact flash. Boot up the RE.
request system snapshot partition
request system reboot media compact-flash

Check so the RE booted up correctly.

Good luck!

Posted in Device Management, Managing Juniper devices | Leave a comment

Upgrading Juniper devices with small flashdrives

Upgrading an EX2200-CO or a SRX100 with small flash drives can be a bit tricky since the upgrade itself may make the device itself run out of flash drive space. So here is a few tricks to get around some of the hurdles.

First issue is that the flash drive itself might have log files, old JUNOS version rollback saves etc. To make sure the flash drive is properly cleaned up, run:
MyDevice> request system storage cleanup

Answer the question with “yes”. Now the flash drive is properly cleaned up.

There are few options when you perform an upgrade which can be omitted if you are certain what you are doing and accept a failure and rather do a system restore with a USB boot flash drive. The following options can be set when doing the upgrade to save flash drive space:
– no-validate
– no-copy
– unlink
– reboot

no-validate means that it wont check the config file vs. new JUNOS version. This wont save you and drive space, but is generally harmless to skip. It also avoids interrupted upgrades due to config file incompatibilities that might result in junk saved on your flash drive.

reboot means that the system should reboot if the system perform a successful upgrade. This can be omitted if the reboot itself needs to be controlled. This option don’t save any drive space.

no-copy means don’t save any copies of the upgrade package (JUNOS install package) while doing the upgrade. Useful both if upgrading from a JUNOS install package from local flash drive or via ftp/http. The upgrade function otherwise actually do copy the install package no matter the method of access. This option really is a flash drive space saver.

unlink means that the upgrade process shouldn’t save any rollback data. When omitted, a rollback to the old JUNOS version cant be done. If a downgrade is desired, it needs to be performed like a normal upgrade. This option also save flash drive space.

A final word is that performing the upgrade via ftp/http saves drive space since a local copy of the install package don’t have to be done.

So best upgrade scenario out of a drive space point of view is:
MyDevice> request system software add ftp://someuser:somepass@ftp.server-somehere.com/jinstall-somepackage.tar.gz unlink no-copy no-validate reboot

Second best scenario is that the JUNOS install package was uploaded to your directory on the router:
MyDevice> request system software add jinstall-somepackage.tar.gz unlink no-copy no-validate reboot

So a command summary:
MyDevice> request system storage cleanup
MyDevice> request system software add ftp://someuser:somepass@ftp.server-somehere.com/jinstall-somepackage.tar.gz unlink no-copy no-validate reboot

Happy upgrading!

Posted in Device Management, Managing Juniper devices | Leave a comment

Secrets of load sharing traffic on Juniper devices with IGP,BGP and MPLS part 1

To have traffic evenly load shared or even in certain scenarios have the traffic unevenly load shared can be little of a secret that now will be demystified and revealed in a series of articles.

Scenario 1, load sharing traffic on multiple directly connected links between two devices using aggregated ethernet (802.3ad)

The simplest form to load share traffic between two devices if they are directly connected with multiple interfaces is to use an aggregated ethernet interface (ae interface). It is simply put a bundle of interfaces which will try to distribute traffic among them evenly. The best hash algorithm to use for this on Juniper devices is “per packet”, which really is per session. Session in this case is defined as a hash built on source and destination IP. More fields in the packet can be used to create the hash which is more relevant in a MPLS scenario for example. But for native IP connectivity L3 and L4 headers is enough to create a statistically well distributed traffic pattern. Please remember it needs a lot of sessions to achieve this statistically. With a low number of sessions, for instance 10 sessions, the load sharing might look less than perfect.

Interfaces bundled needs to be of the same media type, for example. gigabit ethernet dont bundle with fastethernet or 10 gigabit ethernet interfaces. So when creating the bundle, make sure they are all of the same type. Interfaces in the same ae group can be on different FPCs/MPCs and PICs/MICs. The bundling is done on layer2 and if LACP/LAG trunk features are available on the Junuiper platform you use, they can be activated. The bundle interface, ae, can then be addressed as any other interface for different features in protocols stanzas etc etc. Below is a simple example on bundling two gigabit ethernet interface upstream on a branch J series using 802.3ad, i.e. no LACP/LAG features activated.

First we declare how many ae interfaces we want to use on the whole device:
set chassis aggregated-devices ethernet device-count 1

We create the ae interface and define the IP address:
set interface ae0.0 family inet address 192.168.142.254/24

The interfaces used in the bundle cant have any units or protocol families declared, they just should have the following configuration:
set interface ge-0/0/2 gigether-options 802.3ad ae0
set interface ge-0/0/3 gigether-options 802.3ad ae0

Then we need to make sure we have activated the per packet (per session) load sharing method and have a proper hash:
set policy-options policy-statement LB then load-balance per-packet
set routing-options forwarding-table export LB
set forwarding-options hash-key family inet layer-3
set forwarding-options hash-key family inet layer-4

Then the same thing is done in the other end and we have a bundled link between the devices. ae interfaces are available on all JUNOS devices including EX switch series and is configured the same. This method is also compatible between Juniper and most other vendors.

So a configuration summary:
set chassis aggregated-devices ethernet device-count 1
set interface ae0.0 family inet address 192.168.142.254/24
set interface ge-0/0/2 gigether-options 802.3ad ae0
set interface ge-0/0/3 gigether-options 802.3ad ae0
set policy-options policy-statement LB then load-balance per-packet
set routing-options forwarding-table export LB
set forwarding-options hash-key family inet layer-3
set forwarding-options hash-key family inet layer-4

Next article will deal with load sharing of multiple routed links instead of physical bundles.
Stay tuned!

Posted in Juniper Networking, Networking | Leave a comment

Switching on Juniper SRX series

On the Juniper Secure Router series SRX, the X stands for switching. And there is a very good switching feature set implemented on the SRX. It has all the features you need like normal VLAN switching and separation, 802.1Q trunking and RVIs so that a VLAN on the SRX can act like a layer 3 switched VLAN on Junipers EX series. So how could it look like? (Following example is tested with JUNOS 11.x and 12.x)

First of all a VLAN needs to be created and have a vlan-id:
set vlans vlan-trust vlan-id 142

Then it needs members:
set interfaces fe-0/0/6.0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/5.0 family ethernet-switching vlan members vlan-trust

The mode of the ports needs to be set, in this case it is normal untagged access ports:
set interfaces fe-0/0/6.0 family ethernet-switching vlan port-mode access
set interfaces fe-0/0/5.0 family ethernet-switching vlan port-mode access

Since building a VLAN for the trust zone, the routing is going to be handled by an RVI which needs to be created and assigned to the VLAN:
set interfaces vlan unit 142 family inet address 192.168.142.254/24
set vlans vlan-trust l3-interface vlan.142

Dont forget to assign the RVI to the correct security zone so that firewalling etc will operate as intended:
set security zones security-zone trust interface vlan.142

To make a useful example for trunking VLANs, another VLAN is created:
set vlans vlan-lab vlan-id 131
set interfaces fe-0/0/3.0 family ethernet-switching vlan members vlan-lab
set interfaces fe-0/0/4.0 family ethernet-switching vlan members vlan-lab
set interfaces fe-0/0/3.0 family ethernet-switching vlan port-mode access
set interfaces fe-0/0/4.0 family ethernet-switching vlan port-mode access
set interfaces vlan unit 131 family inet address 192.168.131.254/24
set vlans vlan-trust l3-interface vlan.131
set security zones security-zone lab interface vlan.131

If a VLAN trunk is needed to trunk VLAN 142 and VLAN 131 out of the switch on the SRX to a switch infrastruce, a trunk port needs to be created and assigned to the VLANs:
set interfaces fe-0/0/2.0 family ethernet-switching vlan port-mode trunk

To demonstrate the capability to meet future needs of trunking other VLANs out of the SRX with no addition of configuration on the trunk port, an assignment of VLAN all will be used:
set interfaces fe-0/0/2.0 family ethernet-switching vlan members all

An access port can also be tagged and not untagged. This can be used when a SRX is connected to a VLAN/zone where only one VLAN exists and we still want to perform routing and security functions on the traffic:
set vlans vlan-dmz vlan-id 200
set interfaces vlan unit 200 family inet address 192.168.200.254/24
set vlans vlan-dmz l3-interface vlan.200
set security zones security-zone dmz interface vlan.200
set interfaces fe-0/0/1.0 family ethernet-switching vlan members vlan-dmz
set interfaces fe-0/0/1.0 family ethernet-switching port-mode tagged-access

Finally we turn interface fe-0/0/0.0 into a normal untrust routing port:
set interface fe-0/0/0.0 family inet address 10.10.10.1/24
set security zone security-zone untrust interface fe-0/0/0.0

Please note that the exampel above does not cover needed firewall rules under security polices and all zone configuration needed under security zone. It just covers VLAN configuration on the SRX. To make a fully functional firewall with VLANs etc, zone and policy configuration needs to be added.


So a configuration summary:
set vlans vlan-trust vlan-id 142
set vlans vlan-trust l3-interface vlan.142
set vlans vlan-lab vlan-id 131
set vlans vlan-trust l3-interface vlan.131
set vlans vlan-dmz vlan-id 200
set vlans vlan-dmz l3-interface vlan.200

set interfaces fe-0/0/6.0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/5.0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/3.0 family ethernet-switching vlan members vlan-lab
set interfaces fe-0/0/4.0 family ethernet-switching vlan members vlan-lab
set interfaces fe-0/0/2.0 family ethernet-switching vlan members all
set interfaces fe-0/0/1.0 family ethernet-switching vlan members vlan-dmz

set interfaces fe-0/0/6.0 family ethernet-switching vlan port-mode access
set interfaces fe-0/0/5.0 family ethernet-switching vlan port-mode access
set interfaces fe-0/0/3.0 family ethernet-switching vlan port-mode access
set interfaces fe-0/0/4.0 family ethernet-switching vlan port-mode access
set interfaces fe-0/0/2.0 family ethernet-switching vlan port-mode trunk
set interfaces fe-0/0/1.0 family ethernet-switching port-mode tagged-access

set interfaces vlan unit 142 family inet address 192.168.142.254/24
set interfaces vlan unit 131 family inet address 192.168.131.254/24
set interfaces vlan unit 200 family inet address 192.168.200.254/24
set interface fe-0/0/0.0 family inet address 10.10.10.1/24

set security zones security-zone trust interface vlan.142
set security zones security-zone lab interface vlan.131
set security zones security-zone dmz interface vlan.200
set security zone security-zone untrust interface fe-0/0/0.0

Happy S, R & X-ing!

Posted in Juniper Networking, Juniper Security, Networking, Security | Leave a comment

Jumbo frames for L2 and L3 environments on Juniper EX series switches

When there is a need to use jumbo frames for switching and optionally routing on a EX series switch from Juniper there are a few things to observe to make it work correctly. (Follwing example is tested with JUNOS 11.4 and 12.x)

First a few things to consider when thinking about jumbo frames in you layer 2 environment. Within a layer 2 zone there is no problem to have jumbo frames enabled on the switches, as long as all switches are set to forward frames of same size, because the switches acts like a conductor between its attached devices. In fact it is the actual end points (the attached devices to switches) that decides the MTU for its traffic. So each server and client decides the MTU size it will use on its NIC. There is no way for these hosts to peform Path MTU Discovery (PMD) on layer 2, this is a layer 3 function only, so a host will try to use its max MTU within the layer 2 broadcast domain (VLAN) whether the its destination can handle it or not. So if jumbo frames are to be used, all hosts in the same VLAN need to have the same MTU configured on its interfaces.

Also remember that each 802.1Q tag added on top of an ethernet frames when passed on trunk interfaces between switches add 4 bytes, so in an environment with Q and QinQ tags, make sure that the hosts have a MTU set that is at least 8 bytes smaller than the max MTU of the jumbo frames on the switches to allow for these extra bytes. A normal ethernet frame is 1518 bytes with a IP MTU of the IP packet of 1500 bytes. The actual IP packet payload is then 1472 bytes, because IP headers add 20 bytes and layer 4 headers add 8 bytes. So if you have switches that supports the full 9216 bytes of jumbo frames, use a conservative IP MTU of 9000 on your hosts so there are no nasty surprises between your switches with trunk ports.

So when using jumbo frames for layer 2 operations on a EX series switch from Juniper, the MTU needs to be set on the physical interfaces. The command is for example: “set interfaces ge-0/0/0 mtu 9216”. This can be a bit cumbersome since a switch have many interfaces, so here an apply group can be used. Something like:

set groups jumbo-frames interfaces <ge-*/*/*> mtu 9216
set groups jumbo-frames interfaces <xe-*/*/*> mtu 9216
set apply-groups jumbo-frames

This will enable jumbo frames with the size of 9216 on all gigabit and ten gigabit interfaces.

If jumbo frames also want to be used on the routing layer, the switch first need on its global RVI have the maximum MTU set. Then per individual RVI on family inet the actual MTU is set for that RVI. According to documentation so far RVIs can be configured to 9216 bytes. Also when setting the RVI MTU for family inet, remember the dicussion above for IP MTU and layer 2 header additions. So be conservative, dont use IP MTU on the global RVI and family inet  RVI larger than 9000 bytes.

So for example on VLAN 142 and VLAN 131 the vlan.142 resp. vlan.131 is used as RVI, the config would look like this:

set interfaces vlan mtu 9000
set interfaces vlan.131 family inet mtu 9000
set interfaces vlan.142 family inet mtu 9000

Again this is a bit cumbersome, so a addition to the apply group jumbo-frames can be done something like this:

set groups jumbo-frames interfaces vlan mtu 9000
set groups jumbo-frames interfaces vlan unit <*> family inet mtu 1500

Now all the RVIs configured on the switch will automatically adapt to your jumbo frame environment for layer 3 operations aswell. One final note, to adapt the control plane of the switch to perform PMD for control traffic with a TTL larger than 1, also do: “set system internet-options path-mtu-discovery”

So a short quick configuration summary:

set groups jumbo-frames interfaces <ge-*/*/*> mtu 9216
set groups jumbo-frames interfaces <xe-*/*/*> mtu 9216
set groups jumbo-frames interfaces vlan mtu 9000
set groups jumbo-frames interfaces vlan unit <*> family inet mtu 1500
set apply-groups jumbo-frames
set system internet-options path-mtu-discovery

Good luck and happy switching!

Posted in Juniper Networking, Networking | Leave a comment

Ask a Guru!

So here we go! Here there will be posts on useful actual hands-on stuff here soon for Networking, *NIX, CDN and SDN.

If you have any thoughts on what you want to see on this site email ask-a-guru@webkom.se.

Posted in IT technology in general | Leave a comment