So I’ve had been spending some time playing around with a juniper EX4200T from a management standpoint.
This post is just a place to put some observations and questions. Hopefully, some Junos Peeps will be able to shed a little light on some of these questions.
First, as both a criticism and a defence; Juniper does not use SNMP as their primary interface. I get that SNMP has it’s problems, but it’s what we have and if you want to bring Juniper into a network where there is already a network management system in place, I would think that they should at least do the minimum to improve their SNMP support to at least meet the bar.
I have to say; as an operationally focused network engineer, it does disturb me that I can’t even set the sys location from a simple SNMP set command.
ifIndex
One of the first things I noticed about the Juniper box is that the seem to have some strangeness, at least compared to other vendors, around the number of interfaces. Specifically, I’ve got a 48 port switch with more than twice that many interfaces. Upon a closer look, it seems that the Juniper switches, or at the very least the EX 4200t, seems to have two index values for every physical port.
One of the interesting questions that come up here is ” What ifIndex value do I poll?”. I’d like to get interface stats on this device, but do I poll the ethernet port, or the prop virtual port? And if both return the same values; Why would I chose one over the other?
Anyone have a good explanation of WHY they went this direction? @steve did suggest to think of this like a sub interface in Cisco terms. I’ve been trying to figure this out, but the most common reason I’ve used a sub-interface has been to create dot1q routing on a stick configurations. I don’t see how that applies here?
MIB Walking
Another strange thing is that it seems that the EX4200 cannot return all the interfaces when reading the ifTable by SNMP. It may be that this is an issue with my MIB browser, but it’s definitely a pain in the butt.
Junos-peeps: Anyone have a MIB browser that works here? Suggestions on code? Possibly a bug?
VLAN 0
One of the other things I noticed is that the default VLAN of the EX4200 is 0. Huh? VLAN 0? All of the interfaces on the switch belong to VLAN 0 initially. I did find this article from the Juniper website says that ” Some attached devices may not accept 802.1q-tagged frames, and therefore can reside only in VLAN 0.”
Coming from a Cisco and HP background, I’ve always seen the native VLAN initially on a interface listed as VLAN 1. Anyone able to explain this to me?
VLAN-Range: Anyone able to explain this to me? Now I checked the Juniper documentation . But I wasn’t able to find an article which explained what exactly the function is for.
If anyone has comments, I’d love to learn here. I freely admit I haven’t had time to get far enough into this to understand the benefits and I do bring the baggage of history to my perspective on this. If someone has made the jump to Junos, I’d love to hear from you!
@netmanchris
kontrolissues 
Hey Bud,
I had the same questions when I first came to Junos. A couple of points:
ifIndex – Junos keeps a clear separation between the physical interface and the addresses that interfaces that run across it. ge-0/0/0 is the physical interface, and the ge-0/0/0.0 is the logical interface that traffic is assigned against. By keeping this separation regardless of interface configuration actually *improves* scalability and “templatability” from a monitoring perspective.
Re the VLANs you need to seperate the difference between default VLAN and the native VLAN when you work with Junos. VLAN 0 is in fact a valid id used to allow 802.1p marking without implying an actual vlan id.
These a just a couple of quick notes, but Im happy to spend more time with you to work through these points 🙂
Kurt
Hey Kurt,
Yeah.. trying to keep an open mind. @ipv6freely gave me the “Cisco is an interface based OS and Juniper is a protocol based OS” and that’s helped a bit. But the more I scratch, the stranger things get. 🙂
For the seperation of the ifindex. How does this improve scalability and templatability? After spending a lot of time lately reading SDN, I can see how abstractions can definitely be useful, but I’m not sure how the logical interface here helps if it’s permanently bound to the physical interface?
re the Vlan; I have been reading and almost that exact explanation around VLAN 0. I guess I’ve just spent so much time in a Cisco world that it never occurred to me that someone would actually use VLAN 0 on purpose. Seems like a strange design choice considering that Cisco already had market dominance when Juniper switches started coming up.
Still having trouble with the ” We’ll ignore the existing paradigm” attitude. Might be that Game of Thones still has me in a bad mood though. 🙂
Haha – I wont ask which part of Game of Thrones cos he kills main characters on every other page! 🙂
re interface heirarchy, its less obvious when you look at an EX switch but a lot more apparent on a router such as an MX series with lots of sub interfaces each with multiple address families (Remember its the same OS across the product range).
Juniper Interface Heirarchy, each is nested:
(Note Im stealing a lot of this directly from “Juniper MX Series” by Doug Hanks)
-IFD (Interface Device)
-> IFL (Interface Logical)
-> IFF (Interface Family)
-> IFA (Interface Address)
IFD – Physical interface details
IFL – Logical sub-interface
IFF – An Address family such as inet (IPv4), inet6(IPv6), ethernet-switching(switching on an EX) etc. Examples here would be uniq L3 MTU which is separate to the physical MTU
IFA – Attributes directly related to the address.
In this way you make a template for how to represent each level, then you walk the mib and create a set of data that takes all this nested goodness and displays it in a pretty way.
This way, regardless of the configuration of the port or number of protocols and addresses it can be structured in a simple way to extrapolate.
It did my head in for a long time!
K.
Both of these are issues I struggled with at first with Junos. The whole default vlan is not actually a numbered vlan was odd. But as time goes you will learn to appreciate things like the logical unit as you get more complex in what you deploy.
Why I said sub interfaces is right now you have just ge-0/0/0.0 which is just the untagged vlan. But you could have ge-0/0/0.100 tagged vlan 100 and ge-0/0/0.200 tagged vlan 200 much like you would on frame relay or setting up a Cisco router port to tag ethernet frames. Same thing applies to se-* and other types of interfaces, they all get logical units.
If I was not sitting on a island in the sun I could get you some config examples but not happening right now 😀
(You could have ge-0/0/0.100 be vlan 500 or ge-0/0/0.0 be tagged vlan 100 if you just want to confuse people, best practice is unit number = vlan on ethernet interfaces)
@steve
seriously? Island in the sun? Step AWAY from your web browser!
What can I say, I am addicted to tech. Have to force myself to not use the laptop at times.
Okay let’s cover these questions in order.
Re: Interfaces. As others have said, in Junos there is a clear separation between physical and logical interfaces. You can have more than one unit on an interface (usually…) but you aways must have at least one (and if you only have one, it should be unit 0, just to be consistent).
The physical interface heirarchy will have things like speed and duplex. You know, physical settings. The logical heirarchy will have things like IP addresses. See:
ge-0/0/20 {
mtu 9000;
ether-options {
speed {
10m;
}
}
unit 0 {
family ethernet-switching;
}
}
family ethernet-switching could be replaced by, say, family inet address x.x.x.x/xx.
It begins to make even more sense when you do something like a LAG interface. As you know, LAG interfaces bundle multiple physical interfaces into one logical interface. Sooo…
ge-0/0/21 {
ether-options {
802.3ad ae0;
}
}
ge-0/0/22 {
ether-options {
802.3ad ae0;
}
}
ae0 {
unit 0 {
family ethernet-switching;
}
}
Easy, huh? Obviously you dont put the 802.3ad info under the logical unit.
It also makes sense for VLANs. If you have two VLANs 10 and 20, you then have vlan.10 and vlan.20 for your RVI (routed virtual interface), if you need L3 between the VLANs.
What ifindex value do you poll? That depends on what you need. If you want to poll EVERYTHING on the interface, then poll the physical interface. If you only want to poll one unit, then poll at the unit level. This is no different from Cisco. If you have subinterface 10 (10.10.10.1) and sub 20 (10.20.20.1), do you want to poll the physical interface, or just one of the subnets? (I’m not sure if Cisco will let you poll a subinterface, I’m assuming they do… would be silly if they dont)
Okay, next we cover SNMP. I’m not sure in what regard you think SNMP is lacking. Location is easily added with a set command:
snmp {
location Myhouse;
contact Chris;
}
No idea on MIB walking, I don’t do much SNMP.
VLAN 0: Kurt nailed it. You need to separate the idea of default vlan and native vlan.
VLAN Range: Do not compare this to interface range on Cisco. That’s basically just a macro. This is a new named interface that can be used in most ways any interface can. An example:
If you have 10 ports that need to be in vlan 100, you could either fill up your config with ten of these:
ge-0/0/x {
unit 0 {
family ethernet-switching {
vlan {
members 100;
}
}
}
(or omit the vlan stanza, and add “interface ge-0/0/x” under the vlan{} stanza like this, either way its up to you):
cjones@EX2200# show vlans
VLAN100 {
vlan-id 100;
interface {
ge-0/0/10.0;
}
}
Or you could do something like:
interface-range VLAN100_INTS {
member-range ge-0/0/10 to ge-0/0/19;
unit 0 {
family ethernet-switching {
vlan {
members VLAN100;
}
}
}
}
(or if you went for doing interface under the vlan{} stanza, itd look like this):
interfaces {
interface-range VLAN100_INTS {
member-range ge-0/0/10 to ge-0/0/19;
unit 0 {
family ethernet-switching;
}
}
}
vlans {
VLAN100 {
vlan-id 100;
interface {
VLAN100_INTS;
}
}
}
So at this point, its basically just a shortcut. But AH-HA! it has other uses also!
Lets say we take this range of ge-0/0/10-19, all in VLAN 100, and we want to run dot1x on just ports 10, 14 and 17. Add ANOTHER interface range.
interface-range VLAN100_INTS {
member-range ge-0/0/10 to ge-0/0/19;
unit 0 {
family ethernet-switching;
}
}
interface-range DOT1X_INTS {
member ge-0/0/10;
member ge-0/0/14;
member ge-0/0/17;
}
protocols {
dot1x {
authenticator {
interface {
DOT1X_INTS;
}
}
}
}
vlans {
VLAN100 {
vlan-id 100;
interface {
VLAN100_INTS;
}
}
}
Lets say you only want to run LLDP on interfaces 12 and 13:
interface-range LLDP_INTS {
member-range ge-0/0/12 to ge-0/0/13;
}
protocols {
lldp {
interface LLDP_INTS;
}
}
So as you can see, the interface range has a lot more uses than simply macro-ing some config.
Hope this is helpful.
hey @ipv6freely
That actually helps a lot. It’s still a mostly foreign concept, but at least it’s starting to come a little bit clearer. as mentioned in the comments, I’m also finding it helpful also to remember that Junos was originally developed for routers, not switches.
From an SNMP standpoint, it’s lacking in that I can’t perform SNMP writes. the fact that I can perform a CLI command to perform the same task is irrelevant. Having to create scripts to login and perform CLI actions to perform a task is inefficient at best. It would be SO much easier to just send a SNMP set command or two.
especially when you look at the overhead of having to create all those sessions on a large network.
Imagine having to bulk change the admin password. To balance this out, Obviously Juniper understands this as they’ve got a good API structure, but this doesn’t help when 99% of the legacy NMS’s use SNMP.
Add to that the fact that they decided to create private MIBs to perform tasks that are well defined in public MIBs… ( example. juniper Chassis MIB vs. the standard Entity MIB )
I’ve got no issue with private MIBS if they add value, but if the public MIB exists, I think vendors should populate them.
again to balance this out, I would guess that all vendors will be guilty of this last one to some extent. It’s just Juniper who gets the blame at the moment because I’m I the box,
Thanks very much for the comment! This is social media at its best!
@netmanchris
Whoops, I had assumed when you said “set command” you meant CLI. I had no idea that you cant set values w/ SNMP in Junos – I don’t really use SNMP very often.
No problem at all. I understood the confusion as soon as I saw the comment. Yup. No SNMP write on a Junos box. When I was a pure CLI guy, I never would have noticed this.
It’s really amazing how much I’ve learned about devices since getting more operationally focused.
Loved reading tthis thanks