Tag: template

QFabric Part 2 – Lets get Down and Dirty Deploying and Configuring …

Juniper is selling QFabric as a bundle. Due to this the install has been templated and will be similar in regards to the control plane and getting the fabric up and ready to be configured for each target environment. Every QFabric bundle today must include Juniper Professional Services. Hopefully in the future I (and other partner engineers) will be seen as smart enough to do a QFabric install without Juniper’s assistance. I think I could manage it :). Here is the procedure that you and your friendly Juniper Professional Service engineer will complete to get QFabric up and running.
Building the EX4200 VCs for Control Plane
Juniper have extensive configuration documentation with example configurations for the Control Plane for the QFabric components. Please read Juniper’s article “Configuring the Virtual Chassis for the QFabric Switch Control Plane” for instructions on building the control plane infrastructure. I will not go into specifics in this blog post for the control plane.
Initial QFabric Components Deployment
This is my recollection and notes taken during the demonstration and explanation from Juniper’s current most experienced QFabric installer in APAC of the basic process of getting your QFabric up and running.
  1. Check BOM against what’s been received and power all equipment and test for hardware issues
    1. Also ensure directors and interconnects are the same version (should not be a problem yet but as ‘newer’ builds come old stock might pop up)
  2. Build and power ex4200 VCs for control plane
    1. I would recommended to upgrade to the JTAC recommended version of Junos on your 4200s
  3. Patch Up directors into control plane VCs and boot the desired ‘master director’
  4. Complete the console initialisation and then after ~60 seconds boot the slave and complete it’s initial configuration
  5. Patch directors into correct control ports and boot
  6. Turn each node into ‘fabric mode’
  7. Patch into each interconnect and boot each node
    1. The directors will adjust the version of Junos if required on the QFX3500 node
  8. You now have a functional QFabric and can now beging to alias nodes and add them to network/server groups

Configuration (all centrally from the Director)

To build a new Fabric you need to

Create aliases for nodes

  • set fabric aliases node-device SERIAL ALIAS_NAME
Create node groups
Always have 1 network-domain and 1 server group (max 2 nodes per server group making it a redundant server group)
  • set fabric resources node-group NW-NG-0 network-domain
  • set fabric resources node-group NW-NG-0 node-device ALIAS_NAME_X
  • set fabric resources node-group PRON-NG node-device PRON_SW1
Further configuration is ‘like’ a normal EX style configuration, but using the new interface names, for example:
Interface: NODE_ALIAS:xe-0/0/1.0
Aggregated Interface: NODE_GROUP:ae0.0
Handy Debug Commands
  • show fabric administration inventory director-group status all
    • See the directors status and who is master
  • show fabric administration inventory [terse]
    • Shows all the hardware the directors have found and are including in the QFabric
  • show chassis fabric connectivity
    • Shows the connectivity through the interconnects to each nodes
  • show fabric aliases
    • See the serial to alias mappings
  • show fabric inventory
Checking VLANS, the ethernet-switching table etc. commands are all identical to the Juniper EX Switch family.
Power On Sequence
  1. ex4200 Control Plane VCs
  2. QFabric Interconnects
  3. Director Master
    1. Election of master is based on uptime. Wait for ~60 to boot secondary director node
  4. Nodes
    1. I have not tested this, but I would power the network group first, with the members I would prefer to be the masters of the ‘vc’ first (remember each group with multiple members is an incarnation of VC – same rules apply)
Extra Functions

Node Replacement

Replacing a node, and keeping the configuration is EXTREMELY easy due to the ‘replace pattern’ feature of Junos.

  • Repatch cables
  • replace pattern OLD_SERIAL with NEW_SERIAL
  • commit

Microsoft NPS Server + Juniper JUNOS VSA

A lot of companies run Microsoft’s Active Directory AAA infrastructure. A nice add on to AD (apart from my favorite ‘Services for UNIX’) is the Network and Policy Server (NPS). Using this RADIUS server with any radius speaking client is a nice addon that allows the majority of Network infrastructure to use AD as it’s authoriative authentication source. Using NPS as the souce will allow new users to obtain access to the box without the need for configuration on all the infrastrucutre devices individually, scales and disables users access when they leave the organisation (local accounts tend to be forgotten).

Finding documentation on using NPS with JUNOS was difficult, so here is how I have got it to work:

First we need the Juniper Vedor Code and attribute to send to your JUNOS device:

[plain]
Juniper Vendor ID:
2636
RADIUS Attribute to specify account name (id):
Juniper-Local-User-Name (1)
[/plain]

Then we need to configure a RADIUS client in NPS, then configure the JUNOS side and finally define a ‘Connection Request Policy’ (More information here visit this post)

Once the connection request policy is defined we now need a ‘Network Request Policy’. This will allow the use of AD groups (amoungst other attributes) to define which template account that is defined locally on the JUNOS device to map the user to. Please refer to the previous NPS post for more information on configuring a Network request policy.

To add the custom VSA navigate to the “Network Policies” section in the NPS MMC, go to properties of the policy you wish to add the VSA to and navigate to the ‘Settings’ tab. 
Select ‘Vendor Specific’ under attributes and then click add. Then select ‘Custom’ from the drop down list, select Vendor-Specific and click add:

Now select add and enter the following:

 

The device will now send the defined ‘USERNAME’ that is required to be defined locally on each JUNOS device that speaks to this radius server.

If there is no match, JUNOS will fall back to the default remote authentication server template user ‘remote’. I reccomend setting this to unauthorised so that if a user not in required groups gets authenticated due to bad NPS polices can not obtain any useful access to the JUNOS device.

Please let me know how you go and if I have made any boo boos in my post.
The above was tested with JUNOS 11.2r2.4 and Windows Server 2008 R2.

IPTables Template

So I thought I would share a good IPTables starting template, all tested on Ubuntu 10.10.

[plain]

# Cooper Lees IPTables Rules
# Last Updated 20110409

# Drop by default
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
#ICMP is Good
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
# Only allow 4 new SSH connection per minute from a certain IP address
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –set
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –update –second 60 –hitcount 4 -j DROP
iptables -A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
# Handy if you have a IPv4 to IPv6 Tunnel …
iptables -A INPUT -p 41 -s ${IPv4-Tunnel-Address} -j ACCEPT
# Handy for debuging what is getting blocked …
iptables -A INPUT -j LOG –log-level debug –log-prefix "iptables INPUT: "
iptables -A INPUT -j REJECT –reject-with icmp-host-prohibited

[/plain]
– Load from CLI then use iptables-save > /etc/iptables.up.rules
– In Ubuntu add to /etc/network/interfaces “pre-up iptables-restore < /etc/iptables.up.rules" on to the loopback interface