Archive for the ‘juniper’ Category
I was lucky enough to be one of the first APAC partner engineers to get my hands on Juniper's new QFabric gigantic scalable switch technology. I have even beat some of Juniper's own SEs. In general, it rocks, but does have some features and fine tuning, this will come. This post is an introduction to QFabric, with my likes, dislikes and feature wish-list.
I would like to thanks Juniper APAC and Yeu Kuang Bin for this excellent opportunity and very knowledgable training.
What is QFabric?
The most simple explanation of QFabric I can explain is that it is basically a Juniper EX Virtual Chassis on steroids. The internal workings of the switch have been broken apart to be MUCH MORE scalable and Juniper have insured that there are no single points of failure, only selling the design with fully redundant components.
The QFabric components are:
- Director Group - 2 x QFX3100 (Control Plane)
- Interconnects - 2 x QFX3008-I (Backplane / Fabric)
- Nodes (Data Plane)
- Server Groups - 1 - 2 per group
40GE DAC cable (1m,3m,5m lengths)
40GB - QSFP+ (quad small form-factor pluggable plus) - 40 gig uses MTP connector
QFabric Node Discovery
Control Plane
The control plane is discovered automatically, it depends on being configured with a pre-defined Juniper configuration in order to discover the nodes via a pre-defined method when you turn the QFX3500 into fabric mode.
Data/Fabric Plane
The fabric plan is what makes QFabric as scalable as it is. Once again a predefined HA design is supplied and the directors perform the following tasks:
- Discovers, builds & Maintains Topology of the Fabric
- Assembles the entire topology
- Propagates path information to all entities
NOTE: Interconnects DO NOT interconnect to each other
Node Aliasing
Node aliasing allows administrators to give nodes a meaningful name and is used when talking about specific interfaces for specific nodes or node groups
- Id the nodes via beaconing (the LCD screen) or serial number on chassis.
- e.g. set fabric aliases node-device P6969-C NODE-0
- This name is used to reference ports and assign the node to a group (discussed next)
Logical Node Groups
Node groups are used to allow the infrastructure to be divided up and allow the director to know what type of cofiguration to push to a nodes routing-engine. The local routing engine still performs some tasks, predominately to allow scale. A group can contain a maximum of 2 nodes. A group with 2 nodes is know as a redundant server group (It is a 2 node virtual chassis under the covers). Due to this, a redundant server group can have multi-chassis ae (aggregated ethernet) interfaces. There is one other type of group known as the Network node group. This group looks after all routing and l2 loop information, such as OSPF and spanning tree. All vlan routing etc. is done by these nodes.
Group Summary
- Network Node Group (1 per QFabric - Max 8 nodes)
- Server Group (Redundant Server Group optional - 2 nodes)
- Qfabric automatically creates a redundant server group if two nodes exist in a server group (via a form of virtual chassis).
Port Referencing
Now cause each node has an 'alias' (discussed above) to reference a port in configuration you now use:
- NODE_ALIAS:INT_TYPE-x/x/x.x
- e.g. NODE-0:xe-0/0/1.0
Aggregated interfaces can be deployed - Across chassis in a redundant server group or on one chassis in a server group:
- GROUP_NAME:ae0.0
- e.g. RACK-42-1:ae0.0
QFabric can also function with port in FC and FCoE mode. There are some limitations to this feature today, but can provide an excellent mechanism to create redundant paths back through the Fabric to the SAN FC based network. This will be discussed in a dedicated post in my QFabric series.
Summary
QFabric, for a Data Center is ready today and works extremely well. It can allow a HUGE number of 10gb (and soon to be 40gb) ports to allow huge data movement around a DC at low latency. It is also effectively one single point of management for all your nodes, unless something goes wrong of course. For a campus, with end users, QFabric does not have many key features that we use today either with the MX or EX range. It could be used for large campuses as the aggregation or core (especially when more IPv4 and IPv6 routing is supported) and feed 10gb out to EX switches to provide the 'edge'. The coming 'micro' fabric is also interesting, which will allow for a more compelling footprint within a smaller data center.
Key Likes
- Single switch in regards to management and functionalty
- No TRILL or other L2 bridging redundancy protocols required
- Ultra redundant design - Enforced by Juniper
- No half way deployment, people can't go in half assed !
- The simple well thought out HA deployment/design - Common install = easier to debug for JTAC / Engineers like myself
- Scalability - Can see how big DCs could benefit from having 1 gigantic switch
- Road map looks good - Key features and hardware are coming
Key Dislikes
- AFL (Advanced Feature License) required for IPv6 (when it arrives)
- PLEASE Juniper - Can we have IPv6 for free or I will never get customers to deploy it
- This really frustrates me ... You may be able to tell 🙂
- Limitation of 1 unit per interface
- No vlan tagging and multiple units in Network Groups
- Can work around by turning port into trunk and assigning multiple L3 interfaces
- The need for legacy SAN infrastructure in order to use FC/FCoE (discussed in part 3)
- No ability to have a full 48 Copper SFP 1gb interfaces in a node for legacy non 10gig equipment
- The QFX3500 can not fit physically the SFPs in top and bottom rows
- This could be handy to keep legacy equipment and as it's replaced change the SFP to a 10g SFP+
Wish List
- The Micro Fabric - will allow more use cases
- Full SNMP interface statistics for all nodes through the director
- Currently testing this with Zenoss in the Juniper Lab - Has not worked so far
- The ability to ensure node's RE's and PSU etc. are also a plus (have not tested / read the MIBs yet - so could be possible)
- Be able to downgrade and system wide request system rollback from the director
- Full Q-in-Q Support
- Fully self contained FC/FCoE support
To Come in this series:
Part 2 - Deploying and Configuring
Part 3 - FCoE and SAN with QFabric
Part 4 - QFabric eratta (possibly - not sure yet ...)
Please note: The information presented here is from my own point of view. It is no way associated with the firm beliefs of Juniper Networks (TM) or ICT Networks (TM).
Tags: groups, independent, junos, node, qfabric, review, server
Posted in g33k, juniper |
So when I was googiling around looking for working configurations of Junos (EX in this case) AE working with a Cisco vPC (Virtual Port Channel) I could not find any examples ... So I said that I would post one. I will not be covering how to set up a VPC, if you're interested in that side visit Cisco's guide here. I will also not discuss how to configure a Juniper Virtual Chassis (more info here). The devices used in this example are 2 x Cisco 7k (running NX-OS 4) and 2 x Juniper EX4500 switches (running Junos 11.4R1) in a Mixed Mode virtual chassis with 2 x ex4200s.
The goal, as network engineers is to use all bandwidth when it's available (if feasible) and avoid legacy protocols to stop layer 2 loops such as Spanning-Tree. vPC from Cisco and VC technologies allow LACP (Link Control Aggregation Protocol) links to span physical chassis, allow the network engineer to avoid single points of failure and harness all available bandwidth. If a physical chassis was lost, you would still be operation in a degraded fashion, e.g. 1/2 the available bandwidth until the second chassis returned.
To configure the Cisco Nexus side you would require the following configuration on each vPC configured chassis. I found that VLAN pruning can be happily done and a Natvie VLAN1 is not needed if CDP is not mandatory (I did not test making CDP able to traverse the trunk through the Juniper - Would love to hear if someone does!).
[plain]
conf t
interface port-channel69
description Good practice
switchport mode trunk
vpc 69
mtu 9216
switchport trunk allowed vlan 69
interface Ethernetx/x
channel-group 69 mode active
[/plain]
Handy Cisco Debug Commands:
- show vpc
- show run interface port-channel69 member
- show vpc consistency-parameters int port-channel 69
- show port-channel summary
The Juniper side would only require the following, this configuration is identical (you just choose different member interfaces) even if you don't have a Virtual Chassis configuration.
[plain]
set interfaces xe-0/0/39 ether-options 802.3ad ae0
set interfaces xe-1/0/39 ether-options 802.3ad ae0
set interfaces ae0 description "Good Practice"
set interfaces ae0 mtu 9216
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members pr0nNet
set vlans pr0nNet vlan-id 69
set vlans pr0nNet l3-interface vlan.69 #If a L3 RVI is required
[/plain]
Handy Juniper Debug Commands:
- show interface terse ae0
- show lacp interfaces (you want your interfaces to be collecting and distributing)
- show interface ae0 extensive
Please let me know if I have done anything that is not optimal - always eager to learn, I am definitely not (and proud of it) a Cisco expert.
Tags: 11.4R1, channel, chassis, ex, junos, lacp, nexus, nx-os, port, port-channel, vc, vcp, virtual
Posted in cisco, g33k, juniper |
Little tip with SRX Dynamic VPNs and 'security screens' on the VPN's ingress zone I stumbled across during my JNCIE-SEC study.
UPDATE (20120401): Seems Juniper has addressed and fixed this bug ...
More info:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB21713&actp=RSS
It seems you can not have the 'IP Spoofing' screen enabled when sending IPSec Dynamic VPN traffic ingressing into the zone with the screen set. This traffic is dropped by the screen which can be seen via a 'security flow traceoption flag basic-datapath':
- 'packet dropped, drop by spoofing check.'
So removing (or deactivating) the ip spoofing check solved the problem:
- deactivate security screen ids-option from-Internet ip spoofing
Kind of lame, the spoofing screen sounds a good idea on your Internet facing interfaces, but seems a no no if you want dynamic VPNs. That is all. Hopefully eventually Juniper make this check smarter.
Tags: all, block, dynamic, ipsec, junos, screen, spoofing, srx, traffic, vpn
Posted in g33k, juniper |
Awesome - This would get the chicks ...
Tags: day, junos, policy, security, valentines
Posted in g33k, juniper |
@cooperlees is yours truely
[youtube https://www.youtube.com/watch?v=al71G4Isunc]
Tags: 5, 5 in 5, cooperlees, in, qfabric, question
Posted in g33k, juniper |
EX VC tip of the moment: Use apply-groups to add specific config to each node.
For example:
[plain]
set groups member0 system host-name member0
set groups member1 system host-name member1
set groups member2 system host-name member2
set apply-groups member0
set apply-groups member1
set apply-groups member2
[/plain]
Tags: apply-group, chassis, config, configuration, vc, virtual
Posted in g33k, juniper |
What IPv6 system user output looks like ...
[plain]
cooper@noona-gw> show system users
9:15AM up 13:29, 1 user, load averages: 0.36, 0.28, 0.23
USER TTY FROM LOGIN@ IDLE WHAT
cooper p0 2001:470:1f05:78b:224:1dff:fe71:9f70 9:15AM - -cli (cli)
[/plain]
Posted in g33k, juniper |
So work was awesome this year and bought me an SRX110 for Xmas. I thought that I would share, to configure it's vDSL interface to use adsl (with Australian VPI and VCI), you just configure the interface as if it was an ADSL PIM.
Here is the config:
[plain]
set interfaces at-1/0/0 description "ADSL Interface"
set interfaces at-1/0/0 mtu 1540
set interfaces at-1/0/0 encapsulation atm-pvc
set interfaces at-1/0/0 atm-options vpi 8
set interfaces at-1/0/0 dsl-options operating-mode auto
set interfaces at-1/0/0 unit 0 description PPPoA
set interfaces at-1/0/0 unit 0 encapsulation atm-ppp-llc
set interfaces at-1/0/0 unit 0 vci 8.35
set interfaces at-1/0/0 unit 0 ppp-options chap default-chap-secret "PASSWORD"
set interfaces at-1/0/0 unit 0 ppp-options chap local-name "username@ISP"
set interfaces at-1/0/0 unit 0 ppp-options chap passive
set interfaces at-1/0/0 unit 0 family inet address x.x.x.x/32
[/plain]
Tags: 110, adsl, adsl2+, australia, australian, srx, srx110, vci, vdsl, vpi
Posted in g33k, juniper |
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.
Tags: accounts, attributes, junos, microsoft, network, nps, policy, server, specific, template, vendor, vsa
Posted in g33k, juniper |
Here are two handy firewall filters to apply to any internet facing interface on your JUNOS network device.
BOGON List
- Apply as input on Internet facing interface
- You should also add any Public Address space that you have inside your network
[plain]
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 10.0.0.0/8
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 127.0.0.0/8
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 169.254.0.0/16
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 172.16.0.0/12
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 192.0.0.0/24
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 192.0.2.0/24
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 192.168.0.0/16
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 198.18.0.0/15
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 198.51.100.0/24
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 203.0.113.0/24
set firewall family inet filter BOGON-DENY term discard-bogon-net from source-address 224.0.0.0/3
set firewall family inet filter BOGON-DENY term discard-bogon-net then count BOGONS
set firewall family inet filter BOGON-DENY term discard-bogon-net then discard
set firewall family inet filter BOGON-DENY term allow-everything-else then accept
[/plain]
Private Address Reject
- Apply as output on Internet facing interface
[plain]
set firewall family inet filter PRIVATE-REJECT term reject-rfc-1918 from destination-address 10.0.0.0/8
set firewall family inet filter PRIVATE-REJECT term reject-rfc-1918 from destination-address 172.16.0.0/12
set firewall family inet filter PRIVATE-REJECT term reject-rfc-1918 from destination-address 192.168.0.0/16
set firewall family inet filter PRIVATE-REJECT term reject-rfc-1918 then count RFC-1918
set firewall family inet filter PRIVATE-REJECT term reject-rfc-1918 then reject
set firewall family inet filter PRIVATE-REJECT term allow-everything-else then accept
[/plain]
Tags: address, bogan, filter, firewall, junos, list, private, rfc-1918
Posted in g33k, juniper |
