Talktalk Business VDSL Configuration for Juniper SRX110H

I've recently upgraded my broadband internet connection from a consumer grade connection with Talktalk "residential" to a business grade connection with Talktalk Business. The primary reason for this is because I want a number of static IP addresses to run applications, such as remote access VPN and a number of Unified Comms features. Plus I've always been curious about how it all works with multiple public IPs. I know you can do quite a lot with dynamic DNS, such as DYNDNS or noip, but there are quite a few advantages from a small number of static IPs for me so I'm giving it a go.

The router supplied with the broadband is a standard "budget" router, a Huawei HG633, which is ok but it's not intuitive and there's almost no assistance available. Plus as an IT professional I feel I should be using something a little more "real" anyway :) Traditionally I've used a Cisco 867VAE for ADSL / VDSL but I've run into a few issues, hopefully more in another post coming soon, so I'm decided to have a crack with a Juniper SRX110V-HA. And I have to say it's working brilliantly and it was easier than I thought to set up. So I wanted to write up a post with my configuration and a few experiences in case it helps anyone else in the future.

Talktalk Business Settings:
So starting off the TalkTalk Business VDSL settings for Simply Fibre as of April 2018:

Encapsulation Type: PPPoE
MTU: 1492
VDSL VLAN tag: 101
PPP Authentication mode: Chap
Internet Account username: phonenumber@talktalkbusiness.net
Internet Account Password: contact talktalk support for this
IP Address: negotiated

Juniper Configuration:
Now the Juniper specific Configuration.
The PT interface is the Physical VDSL Interface and the "unit 0" is default subinterface.

 pt-1/0/0 {
        vlan-tagging;
        mtu 1492;
        vdsl-options {
            vdsl-profile auto;
        }
        unit 0 {
            encapsulation ppp-over-ether;
            vlan-id 101;
        }

The PP interface is the Logical VDSL interface, similar to a dialer on a Cisco Box. This interface is linked to the Physical interface using the "underlying-interface" command:

 pp0 {
        unit 0 {
            ppp-options {
                chap {
                    default-chap-secret "xxxxxxxxxxxxx";
                    local-name "xxxxxxxxxxx@talktalkbusiness.net";
                    passive;
                }
            }
            pppoe-options {
                underlying-interface pt-1/0/0.0;
                auto-reconnect 10;
                client;
            }
            family inet {
                mtu 1492;
                negotiate-address;
            }
        }
    }

Set your local DHCP scope:
vlan {
        unit 0 {
            family inet {
                address 192.168.1.1/24;

And your default route and your done:
routing-options {
    static {
        route 0.0.0.0/0 next-hop x.x.x.x (ISPs next hop address);

You will have to setup NAT and security zones but it is done by default in the SRX so that's nice and easy, although for completeness here is the config below.

NAT:
 nat {
        source {
            rule-set trust-to-untrust {
                from zone trust;
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }

Security Zones:

        security-zone untrust {

            screen untrust-screen;

            host-inbound-traffic {

                system-services {

                    all;

                }

                protocols {

                    all;

                }

            }

                 pp0.0 {

                    host-inbound-traffic {

                        system-services {

                            all;

                        }

                        protocols {

                            all;

                        }

                    }

                }

                pt-1/0/0.0 {

                    host-inbound-traffic {

                        system-services {

                            all;

                        }

                        protocols {

                            all;

                        }

                    }

                }

            }

   screen untrust-screen;

            host-inbound-traffic {

                system-services {

                    all;

                }

                protocols {

                    all;

                }

            }

            interfaces {

    pp0.0 {

                    host-inbound-traffic {

                        system-services {

                            all;

                        }

                        protocols {

                            all;

                        }

                    }

                }

                pt-1/0/0.0 {

                    host-inbound-traffic {

                        system-services {

                            all;

                        }

                        protocols {

                            all;

                        }

                    }

                }

Please note you can't just paste the above config into your device you have to edit and set the commands, this is how JunOS works, it's actually a great OS and I'd be happy to lend a hand if anyone is new and wants a pointer. I'm no master but I'm enjoying the OS and the way it works.

Lessons Learned:
One gotcha I learned on the way. JunOS doesn't support VLAN tagging on the VDSL interface until Release 12.1. Originally my SRX shipped with 11.x and I had to upgrade this in order to get it working.

Juniper References:
SRX110 Software Config Guide (see the tabs on the left hand side):
https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/services-gateway-srx110-configuration-preparing.html

Configuring PPPoE Interfaces:
https://www.juniper.net/documentation/en_US/junos/topics/example/pppoe-security-interface-configuring.html

Configuring Ethernet Switch Ports:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB16667&actp=METADATA

Configuring a static route:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB16572&actp=METADATA

Configuring OSPF:
https://www.juniper.net/documentation/en_US/junos/topics/example/ospf-single-area-configuring.html

Juniper Part number confusion

So this is another one which should be very obvious but again I'd never questioned it until recently, so I'm jotting it down for reference.

For Juniper's larger routers (MX etc) there are a number of items which are redundant - PSU, RE, SCB etc. Now when looking through the price list these items each have 3 different part code options: -BB, -R, -S

Here are the differences:
-BB = Base Bundle - This item is purchased when buying a new chassis and is often discounted because of this. You cannot purchase this item with the complete chassis.

-R = Redundant - This item is purchased with a complete chassis when you want a redundant item. For example, if you require a chassis with 2 SCB then you would purchase 1 -BB and 1-R.

-S = Spare - This item is purchased often if you are upgrading an existing chassis - I.E. replacing an item in an existing chassis with a new item, or adding a redundant component to an existing chassis.

Juniper EX4550 Switches Airflow Confusion

So this is a quick note to clear up some confusion I had regarding the airflow on Juniper EX4550 switches.

The airflow on these switches is either front-to-back or back-to-front however this is not immediately apparent from the datasheet, and this is always my quick go-to place for information. I think this is mainly my fault for not reading this properly but it is also written in a confusing way.

The datasheet states:
"port side to PSU side airflow" which if you are reading this quickly looks suspiciously like "side-to-side"

To be sure I've had this checked with Juniper, and it is verified in the tech doc below, but the airflow is definitely front-to-back, back-to-front PSUs are also available.

References
EX4550 PSU Tech Doc:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/cooling-system-ex4550.html

EX4550 Datasheet:

http://www.juniper.net/us/en/local/pdf/datasheets/1000414-en.pdf

Juniper WLC2 / MXR2 & WLC8 / MX8 different revisions and MSS

Here is an issue I bumped into whilst working on Juniper WLAN implementations. The scenario is that a customer has multiple Juniper WLC2 Wireless LAN Controllers, many of which they purchased before Juniper acquired Trapeze networks. This means they are actually MXR2s and some were quite old.

Now the WLC has now been called EOL (as of 4th October 2013) so it is not the best platform for use going forward, however at the time it was still a current product, and in honesty how many customers do you know who throw away hardware as soon as it's called EOL? Not many that I know, hardware is sweated until the end of support date gets too close for comfort and then the upgrade happens.

Back to the story, the newest Juniper APs, such like the WLA322 require a minimum of MSS 7.7 to work. The WLC2 technically supports MSS up to version 9.0, however the gotcha here, which is stated in the release notes, is that the Hardware revision must be at least "revision P". Here is the note from Juniper:

Warning: This release of MSS no longer supports older MXR-2, MX-8, and MX-8R WLAN controller platforms
that were initially built with 32MB of flash. Newer models support 128MB or 256MB. The best method for
determining if your controller can support MSS 7.7 is by checking the revision label on the unit:

• Models MX-8 and MX-8R controller - Revision "P" and above
• Model MXR-2 controller - Revision "N" and above
• All Juniper-branded equivalents will support MSS 7.7.

Please note this appliease to the WLC8 /  MX8, as above.

There is a free upgrade program with Juniper, as long as your device has a valid support contract, whereby you can RMA your older revision with Juniper and they will send you a newer version, however this is an RMA so can take a good amount of time, be aware.

To help myself I've put together a quick table showing WLA, WLC and the various MSS version supported:

	7.0	7.1	7.3	7.5	7.6	7.7	8.0	9.0
	Access Points
WLA632	N	N	Y*	Y	Y	Y	Y	Y
WLA532E	N	N	N	N	N	N	Y	Y
WLA532	N	N	N	N	Y	Y	Y	Y
WLA522	N	N	Y	Y	Y	Y	Y	Y
WLA322	N	N	N	N	N	Y*	Y	Y
WLA321	N	N	N	N	N	Y*	Y	Y
MP-432	Y	Y	Y	Y	Y	Y	Y	Y
MP-422B	Y	Y	Y	Y	Y	Y	Y	Y
MP-371	Y	Y	Y	Y	Y	Y	N	N
MP-372	Y	Y	Y	Y	Y	Y	N	N
MP-352	N	N	N	N	N	N	N	N
MP-341	N	N	N	N	N	N	N	N
MP-262	N	N	N	N	N	N	N	N
MP-252	N	N	N	N	N	N	N	N
MP-241	N	N	N	N	N	N	N	N
MP-82	Y	Y	Y	Y	Y	Y	Y	Y
MP-71	Y	Y	Y	Y	Y	Y	N	N

7.0

7.1

7.3

7.5

7.6

7.7

8.0

9.0

	WLC
vWLC	N	N	N	N	N	N	N	Y
WLC2800R	Y	Y	Y	Y	Y	Y	Y	Y
WLC880R	N	N	N	Y	Y	Y	Y	Y
WLC800R	N	N	Y	Y	Y	Y	Y	Y
WLC200	N	N	Y	Y	Y	Y	Y	Y
WLC100	N	N	N	N	N	N	N	Y
WLC8	N	N	Y*	Y	Y	Y	Y	Y
WLC2	N	N	Y*	Y	Y	Y	Y	Y
MX8R	Y	Y	Y	Y	Y	Y*	Y*	Y*
MXR2	Y	Y	Y	Y	Y	Y*	Y*	Y*

The Stars here show where minimum software versions or hardware revisions are required. Check the release notes for full details.

References:
Juniper MSS 7.7.4.4 release Notes:
http://www.juniper.net/techpubs/en_US/release-independent/wireless/information-products/topic-collections/wireless-lan/software/7.7/mss-rn-77-mr4.pdf

Juniper Dynamic VPN and Pulse

There are couple of different types of VPN which can be configured with Juniper products. The MAG and SA products configure SSL VPNs and there are different ways of doing this but this quick post is just to mention Dynamic VPN using the SRX.

Dynamic VPN is an IPSec type VPN but it's not a site-to-site VPN it is a remote access VPN for endpoints. The client used is still Pulse.

The below document is a great reference for Dynamic VPN and Junos Pulse.

References:

[Dynamic VPN] Using Junos Pulse to connect Dynamic VPN client to SRX

http://kb.juniper.net/InfoCenter/index?page=content&id=KB17641

Juniper WLC Licensing + Cluster - Update

So Juniper wireless licensing as I know it has changed! Previous I thought it was the same as Cisco where you had to have enough licenses per controller to handle all APs should a single controller fail but this is no longer the case.

The way that AP licensing now works on Juniper WLC is that WLC can burst up to double their current installed license count as long as they have installed the HA license: WLCXXX-HA-RTU

Therefore if you have 100 APs, each WLC can have 50APs licensed and the HA license, this allows up to 100 APs in the event of a single AP failure.

One note on this is that you do not require the HA-RTU license in order to cluster Juniper WLCs. The only thing that the HA-RTU license grants you is the ability to burst to double the installed license capacity. Clustering is configurable without it, but each WLC will be limited to the number of AP licenses is currently has installed.

Here is a great description of Juniper WLC Clustering I was given:
A cluster is something you create inside a mobility domain which enhances the reliability and redundancy features in a mobility domain. A mobility domain does provide controller redundancy but an AP needs to reboot in order to find the redundant controller. If you enable A/A clustering it provides stateful peering between controllers therefore the APs do not need to reboot during controller failure. This is a powerful feature specific to Juniper which clients like for ISSU and unplanned outages. A mobility domain supports up to 64 WLCs from which a maximum of 32 can participate in a A/A cluster (currently max size of a cluster is 4096 APs) . Clustering provides the following benefits:

o   Hitless Failover (AP switches to secondary AP manager subsecond)

o   Hitless software failover

o   AP load balancing (automatic balancing of all APs across all clustered WLCs in your mobility domain)

o   Cluster configuration - you define your complete wireless configuration once on the seed

Juniper Clustering is great because of the truly hitless failover, the WLC are configured in a A/A cluster and when controllers are clustered each AP maintains connectivity with it's Primary AP Manager (PAM) and Secondary AP Manager (SAM), the PAM propagates client sessions to the SAM. For voice, once a call is setup, local switching would occur to avoid any issues with latency caused by tromboning traffic via a controller. Data can also be locally switched which is great because you can choose how extensively you want to implement local switching choosing when to use either local or central switching. An AP failure is not even considered as 'system failure’, it is seen as a roaming event. The nearby AP taking over the session will not distinguish between ‘nearby AP failure’ or ‘user approaching AP with better signal strength’.

ISSU works in a similar fashion when running a virtual controller cluster. APs without sessions are targeted first and those with sessions take neighbouring APs into consideration allowing session roaming to neighbours before updating the now session free AP.

Juniper Line Card Types (DPC, MPC Etc)

I'm going to build on this post as I come across each of the different types but it can get very confusing talking about the different types of Juniper Line Cards, so here is a reference:

DPC - Dense Port Concentrator
ichip based cards which are available for the MX series routers
They come in 3 variations:
DPCE-R - Routing and Switching, operate as complete L3 router or Full L2 switch
DPCE-X - Limited Scale L3. Cost optimized line case
DPCE-Q - Enhanced Queueing, up to 64,000 queues per card. Per VLAN queueing.

MPC - Modular Port Concentrator
trio based cards for the MX series routers. They support full LS, L2 and application services. MICs are used inside MPCs to provide interfaces.
MPC1 - 32k IFL, port queues, 30Gbps
MPC2 - 64k IFL, port queues, 60Gbps
MPC1-Q - 32k IFL, VLAN queues, 128k I/E queues, 30Gbps
MPC2-Q - 64k IFL, VLAN queues, 256k I/E queues, 60 Gbps
MPC2-E-Q - 64k IFL, VLAN queues, 512k queues, 60Gbps

MX-FPC - MX Flexible Port Concentrator
These are used to add non-Ethernet interfaces to an MX series chassis. They take up 2 slots and have reduced performance (2.5 Gbps Type 2 or 10Gbps Type 3)

More to come as I come across them...

Juniper WLC Cluster Licensing - How does this work!

THIS IS NOW INCORRECT. SEE THE NEW POST - ThWh 26/04/2013
http://twhittle1.blogspot.co.uk/2013/04/juniper-wlc-licensing-cluster-update.html

I've left this here for the sake of keeping previous information, this may even apply if you are running old code but as above, please note there is an updated post on Juniper WLAN licensing

So I'm working with some WLC controllers and a thought strikes, if I cluster these together, how does the licensing work? Is it one big pool? Is it individual? Or something different? Well I've done a bit of research and here is the answer:

Each WLC in a cluster has it's own license count. There is no shared pool. If a WLC has licenses for up to 96 WLAs this is how many it will be able to manage. Therefore to achieve redundancy you need to ensure that if an WLC was to fail there would be enough licenses left between the remaining WLC to pick up the load.

For example:
A 3 WLC880R cluster has to support 192 WLA access points. You cannot just divide 192 by 3 (=64) and license each controller for 64 APs because you would not have a redundant WLAN. If a single controller failed then there would only be 128 total licenses remaining between the 2 remaining controllers. This means that you need at least 96 licenses on each controller so that if any single WLC failed the remaining 2 would have 192 licenses between then, enough for each WLA.

The formula that Juniper gives to work it out is:
Maximum Redundancy Capacity == total cluster MP license - largest MX capacity

However I prefer to think of it as:
Min No. Licenses per controller = No. Total APs / (Number of Controllers -1)