Archive

Category Archives for "The Data Plumber"

QFX5100 default config

Just for reference, here’s the config a QFX5100 comes with out of the box.  

Notes:

Initially the switch tries to get an IP address on the vme0 and irb interfaces so that it can do an auto-image-upgrade, but that failed in the lab since no server (nor the appropriate DHCP options) were available.   The result was an irritating repeated message on the console about this.  To get rid of that, “deactivate chassis auto-image-upgrade”.   This is probably for use if the QFX switch is part of a Q-Fabric – presumably it is trying to upgrade itself over the management network to the version the rest of the QFabric is running.

All interfaces are in the default VLAN, even though their membership is not reflected in the config.

All interfaces have RSTP enabled.

Unfortunately all interfaces are listed twice if they’re  dual-mode (i.e. SFP or SFP+).  This makes the initial config very long.  Obviously this can be deleted.

version 13.2X51-D20.2;
system {
    host-name QFX5100-4;
    arp {
        aging-timer 5;
    }
    root-authentication {
        encrypted-password "REMOVED"; ## SECRET-DATA
    }
    login {
        user imtech {
            uid 2000;
 Continue reading

Imtech’s SDN and NFV demo

This is a pretty cool demo of SDN (Software-Defined Networking) and NFV (Network Function Virtualization) by our SDN Consultant.  I’ve seen a lot of slideware on Contrail and NFV, but they don’t really help understanding very well.  Seeing it actually happen makes a world of difference.

Watch the demo trailer here.


Node and Link Protection

Node and link protection is a mechanism for protecting LSPs from (you guessed it) the failure of nodes and links.   It differs from fast re-route in that you have to specify node and link protection on the interfaces of all the downstream routers as well as on the LSP at its source.

My network looks like this at the moment, with an LSP running from R5 to R1 using the shortest path determined by the IGP:

Path of LSP R5-to-R1

Path of LSP R5-to-R1

So on R5, I configure node-link-protection on the LSP:

root@R5> show configuration protocols mpls
no-propagate-ttl;
label-switched-path R5-to-R1 {
    to 10.0.6.1;
    node-link-protection;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;

This has the effect of signalling to the downstream routers that link and node protection is desired, as you can see here:

root@R5> show mpls lsp name R5-to-R1 detail
Ingress LSP: 6 sessions

10.0.6.1
  From: 10.0.3.5, State: Up, ActiveRoute: 0, LSPname: R5-to-R1
  ActivePath:  (primary)
  Node/Link protection desired                        <===== Node Link Protection 
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
 Continue reading

Protocol Next-hops in a Junos Route-Reflection Cluster

I’ve finally had time to do some proper studying for JNCIE, and I noticed something that I may have been getting wrong for a looong time.  It is minor, but could have bad consequences in a route-reflection environment.

I have a lab topology set up that looks like this:

Route-reflection in JNCIE study lab

Route-reflection in JNCIE study lab

R1 is advertising a direct network of 10.0.5.0 to the route reflectors R3 and R4.   When I looked at R5 I was expecting to see R1 as the “protocol next-hop” but instead I was seeing R3 and R4.  That didn’t look right to me.

Some explanation first:  When you look at a route using “extensive” you get quite a lot of information but in there are two types of next hop.  The “forwarding next hop” is (literally) the next IP hop to get to the “protocol next-hop” which is the BGP speaker that is advertising the route.   The forwarding next hop is derived from the IGP, but the protocol next hop comes from iBGP.    I was expecting to see the forwarding next hop to be the other end of one of the circuits to R3 or R4 Continue reading

Suppressing contributors to an aggregate route

This was a new one on me – in the past I have always advertised an aggregate route and then written policy to match the contributing routes so that they can be suppressed.  It turns out there’s an easier way to do this:

root@R3# show policy-options policy-statement AGG
term T1 {
    from protocol aggregate;
    then accept;
}
term T2 {
    from aggregate-contributor;
    then reject;
}

Calculating burst size for class-of-service

Burst sizes need to be calculated if you are implementing policers or shapers on Junos devices so that the policer or shaper can control the flow of traffic appropriately.  Too small a burst size and TCP applications will have terrible throughput.  Too large a burst size and the policer won’t be very effective – the bursts are so large they cancel out the effect of the policing because as one burst ends another one is just about to begin.

The situation is described reasonably well on the Juniper site here, and also in O’Reilly’s excellent MX book.  But in both places the mathematics of the calculation is hidden in a paragraph of text – not written out properly and showing the workings.  That makes for confusion in my mind.

It’s actually a fairly easy calculation, but isn’t presented well.  I finally sat down to work out what it meant.

The easy way to calculate burst size for low bandwidth (i.e. T1/E1 etc) interfaces is 10 times the MTU of the interface.   The problem with this is (as you see in figure 3 in the Juniper link above) that on 1500-byte Ethernet this Continue reading

Junosphere Bugbears

I’ve always thought Junosphere was great, and it certainly makes setting up test scenarios really really easy.  However there are a few things that really niggle when using it.  They don’t seem to be getting much better, which makes me wonder if there’s much development work going on with the platform.  Messages to the “junosphere-contactme” email address given get no reply.

Anyway, here’s the list of niggles:

1. Sometimes MXes start up with their management IP address in the wrong place – see this post.

2. If you have a saved set of configs for Junosphere which you import from your hard disk, it doesn’t create a network diagram.

3. Topmost annoyance: every time you start up your topology the routers get different IP addresses.  Argh.

4. To edit a predefined config for a device, you have to stop the whole topology.   This makes setting up topologies for training courses quite a laborious process because the routers take such a long time to start up and shut down while you try to get the base config right.

5. It would be really nice to have the IP addresses and console addresses as hyperlinks you could Continue reading

MXes in Junosphere

MXes in Junosphere are unsupported, but I tend to use them because I want something a bit closer to the real thing somehow.  The VJX is ok, but I like the way the MX doesn’t come with any security-related stuff, and the interfaces start at ge-0/0/0 rather than ge-0/0/1!

The only downside with the virtual MX is that it is a non-supported image, unlike the VJX.

Sometimes when usign an VMX, you find that the topology starts up but you can’t SSH to one or two of the nodes.   So you console onto it and discover that (for some reason) the management IP address has been put onto em0 rather than being where it should be in the member0 group applied to fxp0:

root@S1> show configuration groups member0
system {
    host-name S1;
    backup-router 10.233.255.254;
}
interfaces {
    fxp0 {
        unit 0 {
            family inet;    <=== IP address missing!
        }
    }
}

root@S1> show configuration interfaces em0
unit 0 {
    family inet {
        address 10.233.248.46/20;  <== Here it is.
    }
}

The solution to this is to console onto the device and move Continue reading

Simple bridging on MX

I’m doing some studying using Junosphere at the moment, but unfortunately Junosphere can’t emulate a LAN at the moment.  Basically the same problem that GNS3 has and (as far as I know) Cisco’s VIRL/CML has as well.  So you’ve got to bodge it with Integrated Routing and Bridging (IRB).   What I needed topology-wise was this:

LAN segment between S1, R1 and R2

LAN segment between S1, R1 and R2

I find Junos a bit counter-intuitive when creating bridge domains.  Here I need something quite simple – two ports in a bridge group (no VLANs or anything), but I need to give a VLAN tag value to identify the bridge domain.

Anyway, the process for doing this is as follows:

1. Give the physical interfaces the right encapsulation type – ethernet-bridge

2. Create a bridge domain which has a VLAN-ID and references these two interfaces

3. Create an IRB interface (irb.10) with family inet and an IP address on it

4. In the bridge domain, use “routing-interface irb.10″ to tie the bridge domain and the IP interfaces together.

The result is this:

IRB solution for LAN

IRB solution for LAN

The configuration I used was this:

root@S1# show interfaces
ge-0/0/0 {
    description "to R1 0/0/1";
 Continue reading

JNCIE study lab setup.

Boom – you’ve got to love Junosphere.  I just created the Proteus JNCIE study lab in 35 minutes flat.   I made the topology of 13 routers, gave everything a hostname, loopback and interface descriptions and then just fired it up.   When I did my CCIE I was there for >weeks< trying to get the right kit plugged together!

Have a look below:

proteus


Protecting Junos config

In the middle of a migration, and I just discovered the ability to protect parts of the Junos configuration from modification by other users. Could be quite useful!

[edit]
root@VMX1# show system services
[edit]
root@VMX1# protect interfaces
[edit]
root@VMX1# show interfaces
##
## protect: interfaces
##
ge-0/0/0 {
description "LINK TO VMX0";
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
unit 10 {
vlan-id 10;
family inet {
address 10.1.1.2/30;
}
}
}
[edit]
root@VMX1# set interfaces ge-0/0/1 description "LINK TO NOWHERE"
warning: [interfaces] is protected, 'interfaces ge-0/0/1' cannot be created
[edit]
root@VMX1#


“This account is locked. You can’t log in” for super user in Junos Space

After a few fat-fingered attempts to get the password entered, i realised I had locked myself out of a new Space installation.  There’s only one user at that stage – ‘super’.  And now I’ve locked the account.  Damn.

To unlock this, you will need to go on the console and enter debug mode.  This means you need to know the admin and maintenance mode passwords.  Assuming you do, do the following:

 

mysql> use build_db
Database changed
mysql> select * from USER_IP_ADDRESS;
+--------+--------------+---------------------+--------------+----------+---------+
| id     | ipAddress    | ipLockedTime        | failureCount | isLocked | user_id |
+--------+--------------+---------------------+--------------+----------+---------+
| 229377 | 172.20.45.85 | 2014-06-11 16:29:07 |            0 |        1 |     610 |
+--------+--------------+---------------------+--------------+----------+---------+
1 row in set (0.00 sec)

Update the table to make isLocked 0:

mysql> update USER_IP_ADDRESS set isLocked=0;
Query OK, 1 row affected (0.08 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from USER_IP_ADDRESS;
+--------+--------------+---------------------+--------------+----------+---------+
| id     | ipAddress    | ipLockedTime        | failureCount | isLocked | user_id |
+--------+--------------+---------------------+--------------+----------+---------+
| 229377 | 172.20.45.85 | 2014-06-11 16:29:07 |            0 |        0 |     610 |
+--------+--------------+---------------------+--------------+----------+---------+
1 row in set (0.00 sec)

mysql> quit

 

SRX – “VPN monitoring” causes IPSec to bounce

Just making a note here because this will probably trip me up again in the future:   I have a customer with a VPN running from an SRX650 on 11.4R9.4 to a variety of other devices.  One of these is some kind of Huawei device, and the other a Vyatta router.  I’ve no idea what versions or models these are because they’re not under the customer’s control.

I noticed that these two VPNs didn’t appear to be staying up.  You could tell because of the lifetime of the IPSec security association.  It is set in the configuration to 1800 seconds and counts  down – when it gets near zero, the SA is re-negotiated.   In this case however, the SA never dropped much below 1400 seconds remaining before being renegotiated. 

You can see this by issuing the command “show security ipsec sa” and looking at the fourth column to see the lifetime remaining.  If you specify the index number you get more detail as can be seen below:

user@LON-SRX650> show security ipsec sa index 12
ID: 12 Virtual-system: root, VPN Name: VPN-1
Local Gateway: x.x.x.x, Remote Gateway: y.y.y. Continue reading

Conduit.com search browser hijack on OSX

Just spent a half hour sorting out some irritating search toolbar and browser hijack that my mum’s Mac seemed to have got from somewhere.  Most of what I read on the internet seemed to be out of date or inaccurate maybe, so I’m posting my steps to getting rid of this here in case it is of use.

Environment:  OSX 10.6.8 with Firefox 25.0.1

Symptoms:  Normal home page has been replaced by some odd search engine. URL box shows “search.conduit.com/?ctid=CT3299872&SearchSource=13″.
The search box to the right of the URL box is showing “Installl [sic] converter customized web search” instead of Google.
Setting home page back to normal is overridden next time Firefox starts.

Resolution steps:  Clicked Tools | Add-Ons and removed something not expected called “Youtube video downloader”.  Clicked the top-right box’s dropdown and removed the search provider, setting it back to Google.

Home page was reset back to conduit.com on restarting Firefox still, so this needed further investigation.  In the end, I removed the following two directories (the path may not be quite the same on your Mac):
Users/<user>/Library/Application Support/Firefox/Profiles/4ka1hno1.default/conduitCommon
Users/<user>/Library/Application Support/Firefox/Profiles/4ka1hno1.default/CT3299872

Restarted Firefox Continue reading

Making an E1 circuit on a Nortel TN4XE

Lovely user interface this isn’t.  Here’s the command to make an E1 circuit on a Nortel TN4XE where the E1 card is in slot 13.  (The first character should be a tilde rather than a hyphen):

~C N C S6-1-J1-K111&S8-1-J1-K111 S13-1

 

S6 and S8 are the slots where the aggregate cards are.  J1 says to use the first VC4.  K111 tells it to use the first VC3, the first TUG2 and the first VC12.

Within an STM-4 there are four STM-1s which equate roughly to VC4s.  Within each VC4 are three VC3s. Within each VC3 are 7 x TUG2s.  Within each TUG2 are 3 x VC12. 

Confusing…


Juniper PTX3000 – thin is in…

Juniper just launched the PTX3000, which has some nice features – such as being small enough to be installed by one technician, and pushing 0.5Gbps per cubic inch.  The thing is, we still can’t work out who is going to buy these things…

Anywhoo, here’s the info on the Juniper website, with a nice side-view so you can marvel at its 10 inches:

http://www.juniper.net/us/en/dm/ptx-3000/?utm_source=promo&utm_medium=home_page&utm_content=carousel&utm_campaign=ptx3000