Archive for the ‘junos’ tag
JNCIS – Epic Win (Again)
I spent the last of my Juniper exam vouchers on the JNCIS-SEC exam and passed by the skin of my teeth today. Since I took a new job last month that’s 100% Cisco, this is the last Juniper exam I’ll take for the foreseeable future. Too bad, too. I really like the Juniper exams.
At my previous job, we were 90% Juniper with a whole mess of SRX firewalls around the world. Since this exam is really about that platform, it was pretty logical that I should do alright on it. Of course, a large part of the blueprint was on IDS and UTM, and I have no experience there. For my entire career, those type of devices have been handled by other groups, so I had some studying to do. That’s where I ran into problems. I have absolutely no interest in IDS. I have no interest in UTM. There’s nothing about content scanning and analysis that interests me at all. I promise you all that I tried my best to read up on these topics, but I was asleep after 10 words every time I tried. After rescheduling the exam twice to try and study a bit more, I finally decided it wasn’t worth the trouble and just took the exam…and passed.
The exam was typical Juniper with clearly-worded questions and perfectly-clear exhibits all around. A near-perfect exam yet again from Juniper. I was disappointed by three questions, though. The problem wasn’t with the technical details; they were just worded terribly. I’m definitely not shy about commenting on questions during the exam, so hopefully the exam team can use my comments to improve those bad apples. I’ll miss these exams; Cisco surely doesn’t produce any exam of this quality.
Send any Final Four tickets questions my way.
Junos – Logical Tunnel Interfaces with Virtual Routers
There are a few ways to leak routes in and out of virtual routers in Junos. On the list is a cool feature called the logical tunnel interface.
So, what am I talking about? One way to separate traffic on a router is to use virtual routers (VRs) so that you wind up with multiple routing tables on the same router. This separate traffic, but you will usually (read: always) have a demand to get traffic from one VR to another. There are a few different way to do that (see rib-group, instance-import, next-table, et al.), but one really cool way to do it is through logical tunnel interfaces.
The logical tunnel (lt-0/0/0) interface is a special little guy that allows you to connect its units to each other. The result is similar to connecting an Ethernet cable from one physical interface to another. With a little configuration, these guys provide a point-to-point interface that you can include in your routing setup. Let’s look at an example.
set interfaces lt-0/0/0 unit 100 encapsulation ethernet set interfaces lt-0/0/0 unit 100 peer-unit 200 set interfaces lt-0/0/0 unit 100 family inet address 192.168.0.100/24 set interfaces lt-0/0/0 unit 200 encapsulation ethernet set interfaces lt-0/0/0 unit 200 peer-unit 100 set interfaces lt-0/0/0 unit 200 family inet address 192.168.0.200/24
The encapsulation lines are pretty straightforward. In this case, I want the link to appear as an Ethernet interface, but you can choose frame-relay, vlan, bridging, and others.
The peer unit lines tell what unit is connected to what other unit. Each lt-0/0/0 unit is a point-to-point link, so you have to tell the router what’s on the other end of the link (sorry…no multiaccess here). In this case, I want unit 100 to connect to unit 200, so I configure both units with the appropriate peer unit.
Of course, we can all figure out that we’re using IPv4 on these new units as well. In this case, I’ve put both interfaces on the 192.168.0.0/24 network (how original!).
Now that we have our interfaces configured, we need to put these interfaces into the correct VR. Don’t forget the security zone, too, if you’re running in flow mode. That’s beyond the scope here, though.
set routing-instances VR100 instance-type virtual-router set routing-instances VR100 interface lt-0/0/0.100 set routing-instances VR100 interface lo0.100 set routing-instances VR200 instance-type virtual-router set routing-instances VR200 interface lt-0/0/0.200 set routing-instances VR200 interface lo0.200
I put lo0.100 and lo0.200 in there to have something to advertise. You’ll see that in a second.
Now, let’s see if we can ping across.
root@TestSRX# run ping 192.168.0.100 routing-instance VR200 PING 192.168.0.100 (192.168.0.100): 56 data bytes 64 bytes from 192.168.0.100: icmp_seq=0 ttl=64 time=1.879 ms 64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=3.480 ms <SNIP>
Woot! It works. Now we can treat these new interaces as if they are regular ole Ethernet. Since I’m not ready to try and blog about IS-IS, let’s just use the standard OSPF. I’m not going to go through the steps to configure OSPF, but here’s the routing table after all the interfaces are included.
root@TestSRX# run show route
VR100.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.100/32 *[Direct/0] 00:41:33
> via lo0.100
10.0.0.200/32 *[OSPF/10] 00:00:28, metric 1
> to 192.168.0.200 via lt-0/0/0.100
192.168.0.0/24 *[Direct/0] 00:38:21
> via lt-0/0/0.100
192.168.0.100/32 *[Local/0] 00:38:21
Local via lt-0/0/0.100
224.0.0.5/32 *[OSPF/10] 00:01:18, metric 1
MultiRecv
VR200.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.100/32 *[OSPF/10] 00:00:28, metric 1
> to 192.168.0.100 via lt-0/0/0.200
10.0.0.200/32 *[Direct/0] 00:41:33
> via lo0.200
192.168.0.0/24 *[Direct/0] 00:38:21
> via lt-0/0/0.200
192.168.0.200/32 *[Local/0] 00:38:21
Local via lt-0/0/0.200
224.0.0.5/32 *[OSPF/10] 00:01:18, metric 1
MultiRecv
Look! OSPF routes! Sweet. Just to keep my OCD at bay, let’s ping from the loopback of one VR to the loopback of the other.
root@TestSRX# ping source 10.0.0.100 routing-instance VR100 10.0.0.200 PING 10.0.0.200 (10.0.0.200): 56 data bytes 64 bytes from 10.0.0.200: icmp_seq=0 ttl=64 time=1.463 ms 64 bytes from 10.0.0.200: icmp_seq=1 ttl=64 time=1.443 ms <SNIP>
Well, look at that. It works again.
Let’s look back at the topic we’re discussing, though. If we use OSPF between the VRs, we need to make sure our routing design allows us to filter routes between the VRs; the risk is that you may wind up having all the routes from each VR advertised to the other. Kind of defeats the purpose, eh? Running BGP between the VRs might be an option that allows you to control what routes go in and out. Statics might be the answer, as well. As long as you can filter the advertisements, you wind up with a pretty elegant solution for sharing routes between VRs.
Send any Marshmallow Peeps questions my way.
JNCIS – Epic Win!
I quit my job…by design. I start a new gig on Tuesday and am getting back to the world of Cisco. As a last nod to Juniper, I decided to use an exam voucher I had and take the JNCIS-ENT exam. Easy pass.
The content was right along with the exam objectives, so there were no surprises. Most of the topics are things I’ve done a thousand times on the job. There were some things, though, that were beyond my experience. IS-IS was the big one. The very first question I got was about IS-IS metrics, and I had absolutely no clue what the answer was. Nor did I have any clue about the other IS-IS questions. I went 0-for-3 on those guys. The only other problematic topic was HA, which didn’t really surprised me. I was able to answer the VRRP questions, but I’ve never done any GRES, ISSUe, RTG, etc., at any point in my career. It wasn’t surprising that I didn’t do too well on those. Everything else was cake, and I only missed 6 questions in my comfort zone.
The exam was yet another top-notch effort from Liz and the group, but there was one questions that didn’t meet the standard set by the others. It was a VRRP question, but it used some awkward wording that that I read over and over. I just used the context of the questions to give an answer and moved on.
There was really nothing else to report. It was a great exam, so don’t be afraid to take it if it’s next on your list.
Send any Cisco refresher courses questions my way.
Junos Basics – Routing Instances
Here’s one that I use every day at work. We have multiple customers coming into the same router, and, as luck would have it, they all use 192.168.1.0/24 (OK…not really but it might happen). That means we have to separate them into their own routing instance, or virtual router, so pass traffic to their firewall. Think VRF lite on a Cisco router. Let’s conflagrate.
First, we configure the instance as a virtual-router.
set routing-instances CUST1 instance-type virtual-router
There are a handful of instance types, and, to tell the truth, I’ve never cared to really look into them all. Let’s use the good ol’ “beyond the scope of this document” excuse on that one so I look a little more prepared.
In practice, the virtual-router type creates a new routing table to isolate traffic on the same router. It’s pretty worthless to just create it and not do anything with it, so let’s take some of our interfaces and shove them into the new routing instance.
set routing-instances CUST1 interface ge-0/0/0.100 set routing-instances CUST1 interface ge-0/0/0.150 set routing-instances CUST1 interface vlan.200
Not hard. So, let’s add some static routes and some OSPF config to make it even more functional. With the base routing table, you just configure those under routing-options and protocols. It’s the same here, but you just shove that config under the routing instance tree. Something like this.
set routing-instances CUST1 routing-options static route 192.168.0.0/16 \
next-hop 10.1.100.1
set routing-instances CUST1 protocols ospf export REDIST-INTO-OSPF
set routing-instances CUST1 protocols ospf area 0.0.0.0 interface ge-0/0/0.100
set routing-instances CUST1 protocols ospf area 0.0.0.0 interface vlan.200
set routing-instances CUST1 protocols ospf area 0.0.0.150 interface ge-0/0/0.150
Now we have a new routing instance with 3 interfaces in it along with a static routes and OSPF. Great. Let’s see what the routing table looks like now. A show route does that job.
inet.0: 6 destinations, 6 routes (3 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
...SNIP...
CUST1.inet.0: 15 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.1.0/24 *[OSPF/150] 1w5d 14:49:47, metric 0, tag 0
> to 10.1.100.1 via ge-0/0/0.100
...SNIP...
Now the CUST1 table shows up. Looks like we already have an OSPF route, too. That turned out better than I thought.
With routing instances, you’ll have to look at adding instance or routing-instance to your show commands to limit output to just a single instance. For example, show ospf neighbor instance X and show interfaces terse routing-instance X. Contextual help for the win!
NOTE: I’m going to leave it at that, but you may have to add more to this config to make it work. For example, on the SRX platform in flow-based processing mode (the default), you’ll have to create security zones for each interface along with appropriate policies and host-inbound-traffic. This is twice in one post that I’m claiming this is beyond the scope of this document. :)
Send any Halloween candy questions to me.
Junos Basics – Configuring BGP
I’m stuck deep in Junos these days. I mean deep. I have an F5 load balancer and an ASA 5520; the rest of my stuff is Juniper. That means I have some learning to do.
Here’s one of the basics in Junos – configuring BGP. I guess I’ve always said that BGP is BGP. How much different can it be from IOS? Well, the end result is the same, but it’s different enough to have to look up how to do it. :) The first difference is the fact that all BGP configuration is done with groups just like peer groups in IOS. You can act like you’re configuring neighbors, but there’s no way around using groups. After going back and forth, I just settled with an group for eBGP neighbors and another for iBGP neighbors. If settings are different, I just set them in the neighbor. Here’s an example of that.
routing-options {
autonomous-system 65001;
}
protocols {
bgp {
group EBGP {
type external;
peer-as 65021;
neighbor 192.0.2.1;
}
group IBGP {
type internal;
neighbor 192.0.2.100;
}
}
}
You noticed that your own ASN isn’t configured in the BGP section, didn’t you? It’s actually configured in the routing-options configuration. Also notice the type directive there. For some reason (can someone speak to why?), you declare a group as either internal or external neighbors. If the type is external, you obviously have to declare the peer’s ASN.
This configuration won’t do very much. Actually, it pretty darn pointless. All it does is peer up with the two neighbors and accept their routes. We’re not sending them anything or doing anything funky with their routes as they come in. To do something cool, you’ll need to look at seemingly endless configuration items. Those are beyond scope here, though.
Did we configure BGP correctly? Let’s find out.
root@ROUTER> show bgp summary Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 494478 431927 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.0.2.1 65021 3819628 58226 0 3 1w2d21h 401542/415727/415727/0 0/0/0/0 192.0.2.100 65001 3554056 3457157 0 1 2w4d6h 30385/78751/78751/0 0/0/0/0
That’s horrible output, but you can see that we have two neighbors. You can also see their ASNs, how many routes we’re getting from them, how many we’re dampening, etc. One cool thing to notice is the routing table that is being used. We’re not running routing instances on this router, so we only see “inet.0″ in the list. That’s the base routing table. If we did indeed have BGP neighbors on a configured routing instance, you’d see it listed here as well. One more thing to notice – the 431k active paths. That’s a lot of routes!
How do I know what I’m sending to my BGP neighbors? Like I said, you’re sending nothing here. The default behavior of BGP in Junos is to not send anything; you’ll have to configure a policy-statement if you want to actually advertise something. If you put in a little more config (again, beyond scope here), you can see something like this. A single route for 199.199.199.0/24 coming from our external peer. Success!
root@ROUTER> show route advertising-protocol bgp 192.0.2.1 inet.0: 431634 destinations, 494173 routes (431634 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 199.199.199.0/24 Self I
That’s good enough for now. We’ll have to fill in the gaps over time.
Send any canoe rental vouchers questions to me.
Junos Configuration Groups
It has been quite a spring so far. I’ve spent the last two months at our data center racking, railing, mounting, cabling, extending, labeling, and documenting a whole pile of switches, routers, and firewalls for our new environment. I won’t and can’t go into the details, but it’s a huge project for the company that I’m proud to be trusted with. Anyway, now that the physical build is finished (for definitions), I’m finally getting really deep into the configuration. Since we’re a Juniper shop, I’m finding all sorts of stuff that’s fun to explore.
One cool thing I’ve found is the configuration group, which is a way to create a configuration template. The classic example is to use a config group to create a default-deny template for all security policies. No one wants to have to remember to create the deny policy every time they create a new security zone. Or, even better, let’s say that the security team now wants us to log every time a connection is denied. Instead of having to modify a dozen or more security policies ( it’s an n(n-1) thing usually), we could just modify the group, and everything gets updated.
I’m doing this on an SRX240 running 11.4R2.14. First, we create the template through groups at the top of the hierarchy. We’ll create one called “DEFAULT_DENY_TEMPLATE” for the example. Inside that group, we just configure a new security policy with the settings we want. If you’ve ever done security policies, though, you’ll know that you should specify both a from and to security zone. Luckily, we’re able to use wildcards in certain parts including the security zones ( don’t ask me what the rules of wildcard are; I don’t know. :) ). Instead of a zone name, you can just use “<*>” to signify all zones. To finish the details out, we’ll do a deny from all to all on all ports and log the session initiation.
groups {
DEFAULT_DENY_TEMPLATE {
security {
policies {
from-zone <*> to-zone <*> {
policy LOG_DENY_ALL {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
}
}
}
}
}
Now we have to apply the group properly. We can apply it at any number of spots in the hierarchy. In my limited experience, I’ve just applied them at the top of the config. I’m sure there are strategies that would say to apply them elsewhere, but it works there.
apply-groups DEFAULT_DENY_TEMPLATE;
Easy enough. Let’s check our work by looking at the security policy config.
aconaway@SRX> show configuration security policies from-zone UNTRUST to-zone TRUST
policy ANY {
match {
source-address any;
destination-address any;
application junos-http;
}
then {
permit;
count;
}
}
Wait. What? Where did the template go? We just added another policy, right? One of the things that drives me crazy with Junos is that any config that is inherited is not shown unless you tell it to do so with “| display inherited”. I’s way too much output to include here, but you’ll see a whole mess of annotate config that shows the inherited policy. Of course, we can just do a “show security policy” to see what’s actually applied.
aconaway@SRX> show security policies from-zone UNTRUST to-zone TRUST
From zone: UNTRUST, To zone: TRUST
Policy: ANY, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: junos-http
Action: permit
Policy: LOG_DENY_ALL, State: enabled, Index: 19, Scope Policy: 0, Sequence number: 2
Source addresses: any
Destination addresses: any
Applications: any
Action: deny, log
Any changes you make to the group will be applied to all security policies when you commit. Pretty cool stuff. I’m sure I’ll wind up using it more down the road.
Send any BBQ tips questions to me.
Juniper to Get Deep in the Consumer Market
My Juniper account exec let some news slip yesterday. We were on the phone talking about how great the SRX platform was and that I wanted to put one in my house instead of my ASA 5505. Of course, I don’t want to spend too much on a new gateway device, so I asked if there was anything below the $100 mark. He said there wasn’t anything on the books but there was something in the works. I think he had a little too much to drink at dinner. :)
It turns out that Juniper is in talks to buy D-link – one of the big names in home networking. The idea is that D-link already has some large, medium, and small business offerings, so the catalog is very wide. The big money, though, is in the consumer market. My account exec went on to tell me that they’re already working on a new consumer-level product based on the SRX; it will be marketed as a D-link device with the Juniper name on it somewhere. I can’t wait to see a home router with Junos on it. Think about running the Pulse client to connect back home. Awesome!
I also learned that Juniper is going to buy the EasyShare line from Kodak. Kodak just announced that they have already lost $200 million in the first two months of the year, so they are definitely hurting and looking to get some help after their Chapter 11 bankruptcy filing. The EasyShare line provides a way for Juniper to get themselves positioned in the video market with the rest of the big hitters. There is no word on why they want to get into video, but the logical next step would be an enterprise video solution or maybe it’s a building block for another larger product. We’ll have to see.
I’ll have to get my account exec a few more drinks in him the next time he’s in town. Maybe he’ll tell me when Juniper is going to have a voice solution. LOL
Send any similar stories questions to me.
JNCIA – Epic Win!
Maybe not epic, but a win nonetheless.
My boss is over all the network guys in the company, and that includes guys that support different divisions and departments. He told me he was tired of waking up at 2am every morning to fix a problem the other groups can’t handle, so he’s working to get the junior guys motivated to learn for themselves. One technique he’s implemented is to force them to get their CCNAs and JNCIAs by June. Since he made it part of the job description, that means that everyone above the Analysts has to meet those requirements, too. I made the deadline with plenty of time to spare.
Do you remember the full day off of work I had to take to sit the CCNP exams? The 2-hour drive to a prison town, lunch, a 2-hour exam, and 2 hours back? That sucked. I live in a major metropolitan area now, so my travel time to the nearest testing center is 45 seconds. I mean, literally 45 seconds. It’s right across the street from my apartment complex. Easy walk if it wasn’t so cold. That’s good, too, because I showed up this morning, and the center didn’t have any power! Someone plugged in a coffee maker in the break room, and power went out in a whole wing of the building. Since I always get there early, I was actually able to drive home, wait for them to fix the problem, and still be there at my scheduled time. Convenient for sure.
I must say that the exam was pretty darn good. It may, in fact, be the best IT exam I’ve ever taken. The breadth of material was awesome; it had questions from the absolute basics to some of the stuff I saw on the CCIE R&S written. Since I’ve been doing networking for so many years and have my string of certs, the exam was pretty easy to me, but I’m sure an absolute network newb would find the material’s scope a little overwhelming. The exam scores very high on the fairness meter, as well. The questions were clearly written; the exhibits were legible and well-marked. Best of all, there were no real trick questions. They asked what they wanted you to answer and provided the answer to you. There were no assumptions or judgments involved in trying to figure out what was being asked.
Overall, I was very impressed with the exam. Two thumbs up. I can only hope the rest of the exam in the track are this good. I won’t know until after I pass my CCIE lab, though. :)
Send any certification delays questions my way.
Junos Basics – OSPF
Oh, my. Another Junos post. Somebody stop me before I get my JNCIA!
This isn’t hard stuff at all. I’m sure there are a couple of cool tricks I don’t know yet, but let’s try anyway. I”m working on an SRX240 here running 11.1 and some change.
Let’s put interfaces ge-0/0/0.0 and lo0.0 in OSPF area 0. If you know the Junos configuration hierarchy, this will be very easy to you. Even if you don’t, you can stare at the config for a little bit and see what we’re doing.
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0
This is the only OSPF configuration you need, but guess what? It won’t work. Since a Junos device is also a firewall, it will drop OSPF packets as they come into the interface; you have to declare that you do indeed want to accept OSPF packets. You do this by creating a security zone, putting the right interfaces in the right zone, and then enabling OSPF on that zone.
We’ll create a zone called INSIDE for our purposes here. Note that there are about billion more steps (I counted) to fully configure your security zones, but that’s way beyond our scope here.
set security zones security-zone INSIDE
interfaces ge-0/0/0.0
set security zones security-zone INSIDE
interfaces lo0.0
set security zones security-zone INSIDE
host-inbound-traffic protocols ospf
You can also allow OSPF on specific interfaces like this. These commands will also put those interfaces in the right security zone.
set security zones security-zone INSIDE
interfaces ge-0/0/0.0 host-inbound-traffic protocols ospf
set security zones security-zone INSIDE
interfaces lo0.0 host-inbound-traffic protocols ospf
I’m not sure if you need to do this to lo0.0, but it won’t hurt.
Now you can see your OSPF neighbors come up and start exchanging routing information. That is, of course, assuming you did everything else right.
Send any blog deadlines questions my way.
Junos – VPN Hierarchy
Wow! A Junos post! Amazing.
We all know that the configuration on a Junos box is very hierarchical. Sometimes it doesn’t make a lot of sense, but it’s all a pretty cascade of code. One of the big messes that I’ve found is the VPN configuration hierarchy; there are way more items to configure than on an IOS device. To reinforce the stpes in my head, I thought I’d get some of the pieces into a post. These aren’t all the options, but it’s all you need to get a static IPSec tunnel up and running.
That’ll do, pig. I’ll fire off a real configuration post later. Feel free to add your pair of pennies since I’m a total Junos n00b.
Send any stocking stuffers questions my way.