Let the festive cheer of labbing begin!

Let the festive cheer of labbing begin!

I’m on holiday for the next 9 days! Translation: over the next days I’m going to be in the lab doing a heap of practice for my upcoming JNCIE-ENT exam! I’ve been banned from being in the lab today (Christmas) by my better half, but for the next 8 days after that I plan to do a heap of practice, but I’ll be focusing on Multicast and Layer2 technologies!

I’m also going to have my first crack at the InetZero JNCIE-ENT practice exam on Saturday, which should be a good gauge to see how I am going so far with my studies.

Merry Christmas everyone!

JNCIE-ENT study discovery – ssm-map-policy

While fiddling in the lab with multicast today in preparation for my JNCIE-ENT, I discovered a useful new(ish) way to deal with (*,G) multicast joins for SSM (source specific multicast). Note that I say “ish” because this was actually introduced in 11.4, however it hasn’t made it’s way into any of the official (or third party) Juniper course material or JNCIE study guides yet.

Normally in order to deal with this you would configure a ssm-map on the IGMP interface, then in the ssm-map refer to a policy to distinguish the groups to apply to, plus a source to map them too. This ends up being a little bit config-heavy and hard to read;

routing-options {
    multicast {
        ssm-map map1 {
            policy map1-policy;
            source 172.30.2.2;
        }
    }
}
protocols {
    igmp {
        interface vlan.1000 {
            ssm-map map1;
        }
    }
}
policy-options {
    policy-statement map1-policy {
        from {
            route-filter 232.255.0.3/32 exact;
        }
        then accept;
    }
}

What I discovered today was a the “ssm-map-policy” parameter in the IGMP interface, which allows you to define everything in a single policy rather than using a ssm-map which then refers to a policy and a source. It’s really nice being able to drive this all out of a single policy.

protocols {
    igmp {
        interface vlan.1000 {
            ssm-map-policy ssm-policy;
        }
    }
}
policy-options {
    policy-statement ssm-policy {
        term G3 {
            from {
                route-filter 232.255.0.3/32 exact;
            }
            then {
                ssm-source 172.30.2.2;
                accept;
            }
        }
    }
}

To confirm this works just the same (and that having this on without a catchall “accept” policy doesn’t kill the other joins), I configured a few static joins to test it;

[edit protocols igmp interface vlan.1000]
+     static {
+         group 232.255.0.3;
+         group 239.192.0.1;
+         group 239.192.0.2;
+     }

And it seems to all work well – note that the other joins are fine, and the (*,G) joins for (*,232.255.0.3) gets mapped to a (S,G) for (172.30.2.2,232.255.0.3) as expected!

[email protected]# run show pim join 
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 232.255.0.3
    Source: 172.30.2.2
    Flags: sparse
    Upstream interface: ge-0/0/10.0           

Group: 239.192.0.1
    Source: *
    RP: 172.30.15.66
    Flags: sparse,rptree,wildcard
    Upstream interface: ge-0/0/10.0           

Group: 239.192.0.2
    Source: *
    RP: 172.30.15.66
    Flags: sparse,rptree,wildcard
    Upstream interface: ge-0/0/10.0           

Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

The other benefit of this is that instead of being limited to one source (or set of sources) per IGMP interface, you can now specify a source (or set of sources) per multicast group, which is handy if you have multiple multicast sources…

Hope this helps!

Confirming IPv6 GRE ToS copy behaviour

One of the fairly simple topics in the JNCIE-ENT syllabus is GRE tunnelling. Or so you would think. When configuring GRE tunnels in JUNOS, there is a nifty little flag which you can enable which copies the contents of the payload’s IP ToS field to the outer header’s IP ToS field;

set interfaces gr-0/0/0 unit 0 copy-tos-to-outer-ip-header

However after doing a bit of googling I found some conflicting sets of documentation on weather this would work for IPv4 payload only or IPv4 & IPv6 payload. I quickly whipped up a lab to prove this out either way (using SRX240’s running 11.4R5.5). I’m documenting this here as I imagine this is a question others may have while preparing for this exam (or for production purposes).

First, it’s worth noting that this lab has been done using 3x SRX240 and 1x EX4200 (configurations for which can be found here). The “VR” devices are two virtual routers on one SRX240.

Image

The GRE tunnel interfaces are configured as below (example from the R2 end);

[edit interfaces gr-0/0/0]
[email protected]# show 
unit 0 {
    tunnel {
        source 192.168.10.1;
        destination 192.168.6.1;
    }
    family inet {
        address 10.0.12.2/24;
    }
    family inet6 {
        address 2001:face:12::2/64;
    }
    copy-tos-to-outer-ip-header;
}

Let’s then configure two firewalls on each of R2 & the EX and apply them inbound on ge-0/0/3.0 of R2 and ge-0/0/10.0 of the EX;

[edit firewall]
[email protected]# show 
family inet {
    filter tos-count {
        term 255 {
            from {
                dscp 63;
            }
            then {
                count 255;
                accept;
            }
        }
        term 0 {
            from {
                dscp 0;
            }
            then {
                count 0;
                accept;
            }
        }
    }
}
family inet6 {
    filter tos6-count {                 
        term 255 {
            from {
                traffic-class 63;
            }
            then {
                count 6-255;
                accept;
            }
        }
        term 0 {
            from {
                traffic-class 0;
            }
            then {
                count 6-0;
                accept;
            }
        }
    }
}

Now for the testing. First we’ll send 1x ICMPv4 and 1x ICMPv6 request with a ToS value of 0 to confirm that nothing too funky is happening;

[email protected]> ping 2001:face:1::2 source 2001:face:2::2 routing-instance VR2 tos 0 count 1
PING6(56=40+8+8 bytes) 2001:face:2::2 --> 2001:face:1::2
16 bytes from 2001:face:1::2, icmp_seq=0 hlim=62 time=4.625 ms

--- 2001:face:1::2 ping6 statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 4.625/4.625/4.625/0.000 ms

[email protected]> ping 10.0.1.2 source 10.0.2.2 routing-instance VR2 tos 0 count 1                 
PING 10.0.1.2 (10.0.1.2): 56 data bytes
64 bytes from 10.0.1.2: icmp_seq=0 ttl=62 time=3.021 ms

--- 10.0.1.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.021/3.021/3.021/0.000 ms

Right, now let’s confirm what the devices along the way are seeing the outermost ToS value as in the encapsulated and unencapsulated versions of this traffic;

[email protected]> show firewall   

Filter: __default_bpdu_filter__                                

Filter: tos-count                                              
Counters:
Name                                                Bytes              Packets
0                                                      84                    1
255                                                     0                    0

Filter: tos6-count                                             
Counters:
Name                                                Bytes              Packets
6-0                                                   128                    2
6-255                                                   0                    0
[email protected]> show firewall 

Filter: tos-count                                              
Counters:
Name                                                Bytes              Packets
0                                                     224                    2
255                                                     0                    0

We can see that at both points IPv4 and IPv6 traffic is marked with a ToS value of 0 as expected. Now to set a ToS value of 255 (DSCP 63) and confirm what happens when we set the ToS to a non default value;

[email protected]> ping 2001:face:1::2 source 2001:face:2::2 routing-instance VR2 tos 255 count 1
PING6(56=40+8+8 bytes) 2001:face:2::2 --> 2001:face:1::2
16 bytes from 2001:face:1::2, icmp_seq=0 hlim=62 time=4.897 ms

--- 2001:face:1::2 ping6 statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 4.897/4.897/4.897/0.000 ms

[email protected]> ping 10.0.1.2 source 10.0.2.2 routing-instance VR2 tos 255 count 1                 
PING 10.0.1.2 (10.0.1.2): 56 data bytes
64 bytes from 10.0.1.2: icmp_seq=0 ttl=62 time=2.466 ms

--- 10.0.1.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.466/2.466/2.466/0.000 ms

Now let’s have another look to see what ToS value these had at each point;

[email protected]> show firewall    

Filter: __default_bpdu_filter__                                

Filter: tos-count                                              
Counters:
Name                                                Bytes              Packets
0                                                      84                    1
255                                                    84                    1

Filter: tos6-count                                             
Counters:
Name                                                Bytes              Packets
6-0                                                    56                    1
6-255                                                  56                    1
[email protected]> show firewall         Filter: tos-count                                              
Counters:
Name                                                Bytes              Packets
0                                                     224                    2
255                                                   224                    2

And it would seem that the IPv6 traffic is indeed having the ToS values copied to the outer header (note that I didn’t clear this between the ToS 0 and ToS 255 ICMPs).

Hope this helps clear up any confusion!

A time-saving trick for the JNCIE lab exam

When I did my JNCIE-SP, there were countless times where I wanted to do something that referred a group of interfaces such as “all of the core-facing interfaces”. In my practice for the JNCIE-ENT I’m finding this is no different. Whether it is whacking on “family mpls”, or applying a CoS rewrite rule, gathering a list all of your core interfaces (especially if there is some anomaly making it difficult to use wildcards in configuration-groups to do this) to use to text-process into a bunch of set commands can be a time-consuming task.

I came upon something quite obvious (when I thought about it for a moment) as a way to solve this; gathering the output of a show command in XML then matching the parameter I wanted to text-process.

Here’s an example – I wanted to apply the DSCP classifier JNCIE to all core interfaces;

Start by checking that the command has what you want. This looks fine (presents a list of all the core interfaces).

[email protected]# run show ospf neighbor
Address Interface State ID Pri Dead
172.30.0.65 ge-0/0/10.0 Full 172.30.15.3 128 35
172.30.0.81 ge-0/0/12.0 Full 172.30.15.7 128 35
172.30.0.77 ge-0/0/6.0 Full 172.30.15.4 128 38

Now verify how it looks in XML form. Looks like it’ll do the trick nicely.

[email protected]# run show ospf neighbor | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.2R1/junos">
<ospf-neighbor-information xmlns="http://xml.juniper.net/junos/11.2R1/junos-routing">
<ospf-neighbor>
<neighbor-address>172.30.0.65</neighbor-address>
<interface-name>ge-0/0/10.0</interface-name>
<ospf-neighbor-state>Full</ospf-neighbor-state>
<neighbor-id>172.30.15.3</neighbor-id>
<neighbor-priority>128</neighbor-priority>
<activity-timer>32</activity-timer>
</ospf-neighbor>
<ospf-neighbor>
<neighbor-address>172.30.0.81</neighbor-address>
<interface-name>ge-0/0/12.0</interface-name>
<ospf-neighbor-state>Full</ospf-neighbor-state>
<neighbor-id>172.30.15.7</neighbor-id>
<neighbor-priority>128</neighbor-priority>
<activity-timer>32</activity-timer>
</ospf-neighbor>
<ospf-neighbor>
<neighbor-address>172.30.0.77</neighbor-address>
<interface-name>ge-0/0/6.0</interface-name>
<ospf-neighbor-state>Full</ospf-neighbor-state>

Okay, lets now filter out the kludge.

[email protected]# run show ospf neighbor | display xml | match interface-name
<interface-name>ge-0/0/10.0</interface-name>
<interface-name>ge-0/0/12.0</interface-name>
<interface-name>ge-0/0/6.0</interface-name>

Finally, lets find and replace <interface-name> for set class-of-service interfaces and .0</interface-name> for unit 0 classifiers dscp JNCIE in a text editor.

set class-of-service interfaces ge-0/0/10 unit 0 classifiers dscp JNCIE
set class-of-service interfaces ge-0/0/12 unit 0 classifiers dscp JNCIE
set class-of-service interfaces ge-0/0/6 unit 0 classifiers dscp JNCIE

And now we have the text in the form we want it to paste back onto the Juniper. This is probably obvious to most of you, but for those of you who hadn’t thought of this yet hopefully this is a huge time saver compared doing it manually (while letting you avoid the blunt sledgehammer approach that wildcards in groups can be)!

Time based ALL OF THE THINGS on JUNOS

I had the CEO here chasing me today to be able to sell a customer a time-based shaper where they had XGbit during the day and XGbit during the night. This is done in a fairly easy manner on Ciscos, but I’ve never figured out how to do it on a Juniper (and neither had anyone I work with or a bunch of friends I asked). Anyway, after a bit of digging, I found this feature which looks like it was introduced in version 12.1;

[email protected]# set groups ABC when ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
  model                Model name
  routing-engine       Routing Engine
> time                 Time at which group should be effective

For my uses, the model and routing-engine options are fairly irrelevant – you would hope that on most routers these are pretty static! But what’s useful for me is that not only does the time flag let me do time based shaping, it opens up a world of possibility to do any number of other things based on time-of day type conditions that you could never do on a Cisco.

I’ve had a quick play with this in the lab with the following config, and it’s working successfully;

[edit groups]
[email protected]# show 
night-shape {
    when {
        time 00:00 to 06:59;
    }
    interfaces {
        ge-1/0/3 {
            unit 123 {
                family inet {
                    policer {
                        input cust-police-3g;
                    }
                }
            }
        }
    }
    class-of-service {
        interfaces {
            ge-1/0/3 {
                unit 123 {
                    output-traffic-control-profile cust-shape-L3-3g;
                }
            }
        }
    }
}
day-shape {
    when {
        time 07:00 to 23:59;
    }
    interfaces {
        ge-1/0/3 {
            unit 123 {
                family inet {
                    policer {
                        input cust-police-1g;
                    }
                }
            }
        }
    }
    class-of-service {
        interfaces {
            ge-1/0/3 {
                unit 123 {
                    output-traffic-control-profile cust-shape-L3-1g;
                }
            }
        }
    }
}

Another possible use for this could be the ability to change an OSPF cost at X time during the day if you were buying certain capacity on a time-of-day basis from your transit provider. With the way this has been implemented the world is our oyster!

If you are interested in using it, the full documentation is here; http://www.juniper.net/techpubs/en_US/junos12.1/topics/topic-map/junos-cli-using-conditions-config-groups-example.html

Developing my study techniques – slowly learning!

Almost exactly one year ago today I started a new job – moving from a long history of running (primarily) Cisco based service provider networks to working for an ISP that is also a Juniper partner (with not a whole lot of Cisco to be seen around their network!). One of the catches was that they wanted me to get to at least JNCIP level within a few months (I ended up doing a JNCIE and am now on the road to JNCIE #2), as they had various requirements that they had to furfill with Juniper to meet their partner status. Before starting I had spent a grand total 1 hour in front of any Juniper equipment in my life – so I knew that it was going to be a bit of a learning curve!

While I quickly adjusted to using the same protocols on a new box with a different CLI and some slightly different “mannerisms” (the oddities that every vendor’s hardware/software has) – this was the first time I’d had to study for anything in many years – and to my surprise it actually took me a fair while to get into a good rhythm of studying in an effective manner. Here’s some of the things that I have learned / have been helpful to me on this journey!

Slow and steady wins the race. By the time I was done with my JNCIE-SP, I was well and truly burnt out. I spent most of the “holiday” week that my wife and I had planned following it sleeping in the hotel room and didn’t make very good use of our time in Yosemite & around the SF area with her. I’m making a really conscious effort to limit myself to about 37 hours a week this time (whereas I was doing consistently 40-45hrs/week last time). Being more tired is just going to make it harder to learn. While it’s important to put in the effort required, and this will mean a busy schedule and huge sacrifices in other areas of your life, it’s important to maintain some semblance of balance. Also – you’re never going to learn anything at the last minute, so don’t do a big push at the end. If anything scale it back in the week or two before an exam to be as relaxed as possible. It’s a marathon – not a 100m sprint!

Don’t stress! As long as you make sure you have enough time to get through the material to a decent level you should be fine! And time spent stressing is only going to be time you can’t study in! So put your head down and study, but don’t spend it worrying about anything that’s outside of your control!

Make time for yourself. Even though between work and study I was easily pulling an 80 hour week, I still made a real effort to spend a few hours a week doing what I consider to be downtime – riding my motorbike and watching TV episodes. I also made a real effort to find time to hang out with my wife. While it would have been easy to get a bit more sleep with that time – I found it was really important to have a couple of things to regularly do that weren’t study or work.

Have a plan! When I started towards the JNCIE I came up with a study plan before I even booked the exam. Each week had a set of things that I was going to study, and I (for the most part) stuck to this. What was good about this is it gave me a structured way to approach a range of technologies that I had to have a deep understanding of and ensure that I didn’t miss doing a “deep dive” on any of them.

Study buddies are key! I was very lucky in the JNCIE-SP to have some friends who had either also done (or were doing) JNCIEs or worked in Service Provider environments who were happy for me to bounce things off them. This was really helpful as I was studying some of the topics I found harder – such as Multicast which I had never touched before. Personally – I’ve always found that while there’s a lot you can learn by both reading and fiddling, it’s hugely helpful to have people explain to you that one thing you “just can’t get”.

Understand the technology before you understand the vendor’s implementation. I found was that if there was something I wasn’t 100% sure about, I was always best to read the RFC and other documentation on the technology BEFORE I tried to understand how vendor X had implemented it – therefore meaning I had a far better perspective on what vendor X was doing and why as opposed to doing it in the reverse way.

Break it. There’s nothing like testing out a new feature in the lab, seeing how it works and breaks, and generally having a play to understand it. Often when we read something we will make assumptions we do not even realise we are making, and a few of those assumptions will be incorrect and lead to us doing it wrong. Labbing whatever you are trying to understand ensures that it does what you think it does and that you have first hand experience of configuring, checking & debugging it – always a good thing!

Have a good environment. There’s no point trying to study in a noisy environment with lots of distractions. I personally have my own office at home where I have a couch, desk & all my books. I make a real effort never to let myself get distracted in this environment. If I want a break I physically leave this space, so that the only thing I am ever doing in this space is studying. This really helps because I automatically get into “the zone” when I enter my study and find it easier to get things done in this space. It’s also good that this space is fairly removed from the noisy bits of my house, so i’m in a good position to not be distracted by others.

Don’t get stuck. I’ve always found that if I’m stuck the worst thing I can do is keep on trying for hours to “get” something. I’m often best to move onto something else and come back to it – as the mental block will likely be gone by that point. This actually goes for the JNCIE exams too – one one of the practice exams I got stuck for 2.5 hours on one issue – then missed a whole lot of stuff I should have picked up in my checking due to running out of time! In the actual JNCIE I would never spend more than 5mins debugging one issue – I would instead move on and come back to that issue in a few minutes.

But most of all – the important thing is to experiment and find what works for you. For people like me that’ll mean studying till 3am every night – for others it’ll be better to get up early. Some will prefer to study at work – I prefer my office at home. Try different things – you’ll eventually find something that works well for you!

Hope this helps.