Let’s set up a basic OSPF adjacency between JunOS and IOS. I’ve got the following simple topology:
The good thing here is that the configs shown will show the difference between JunOS and IOS as the actual configuration goal is the same for both.
The Cisco config is as follows:
Router>conf t #int fa0 #ip address 192.168.1.2 255.255.255.0 #int lo100 #ip address 172.16.10.1 255.255.255.0 #router ospf 1 #network 192.168.1.0 0.0.0.255 area 0 #network 172.16.10.0 0.0.0.255 area 0 #exit
Now onto JunOS:
root@Olive>configure # set interfaces em1 unit 0 family inet address 192.168.1.2/24 # set interfaces lo0 unit 100 family inet address 172.16.20.1/24 # edit protocols ospf area 0 # set interface 192.168.1.1 # set interface 172.16.20.1
Let’s see what we see on the Cisco:
Router#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.16.20.1 128 FULL/BDR 00:00:34 192.168.1.1 FastEthernet0
Router#sh ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
O 172.16.20.0/24 [110/1] via 192.168.1.1, 00:00:25, FastEthernet0
O 172.16.20.1/32 [110/1] via 192.168.1.1, 00:00:25, FastEthernet0
C 172.16.10.0/24 is directly connected, Loopback100
C 192.168.1.0/24 is directly connected, FastEthernet0
What about the Olive?
root@Olive> show ospf neighbor
Address Interface State ID Pri Dead
192.168.1.2 em1.0 FULL 172.16.10.1 1 36
root@Olive>show route
172.16.10.1/32 *[OSPF/10] 00:09:05, metric 2
> to 192.168.1.2 via em1.0
And yes, both routers can ping both loopbacks :)
Right, it’s really time I get cracking on with my JNCIA. I’m going to do the EX track first, then maybe ER as well.
I’ve set up an Olive quickly and connected it to a 1721 via dynamips. I want to start off with the basics of getting around the cli of JunOS. Yes it’s different to IOS, but it’s really not that difficult.
When the Olive first boots up, it’ll be a blank slate. If you logged in as root, you’ll need to enter cli to actually get to the cli:
root@O%cli root@O>
Right, now we are at the CLI. Let’s start configuring!
First go into configure mode:
root@O> configure Entering configuration mode [edit] root@O#
Let’s start with a few basics. These few are all intuitive:
#set system host-name Olive #set system time-zone Europe/London #set system domain-name test.com #set system name-server 4.2.2.1
Note that JunOS won’t make these changes live straight away. All changes go into a ‘candidate configuration’ – Only when you actually commit the changes will they actually happen. You can commit straight away or do a syntax check beforehand:
#commit check configuration check succeeds
This means all looks good, so let’s commit the changes!
#commit commit complete [edit] root@Olive#
There is something to note here. JunOS’s config mode is hierarchical. This means that if I was going to do a lot of commands in the same sub-section – I could go into that sub-section first.
For example, the above 4 commands were all in the system sub-section. Instead of the above, I could’ve done this:
root@O> configure Entering configuration mode [edit] root@O#edit system [edit system] root@O#set host-name Olive #set time-zone Europe/London #set domain-name test.com #set name-server 4.2.2.1
This would give me exactly the same configuration as the above. If I need to get out of a sub-section I just type ‘up’
#up [edit] root@O#
If I’m in pretty deep, you can type ‘top’ to get right to the top of the tree
Now we need to set up an IP address on an interface. To see what interfaces you have, you can type:
Olive> show interfaces terse
This command is similar to show ip int brief on a Cisco
I want to configure the em1 interface and I do so like this:
Olive# set interfaces em1 unit 0 family inet address 10.1.1.1/28
So quite a bit longer than on a Cisco, but it’s really not that difficult. There is an important note here. When you assign an IP address to a Cisco, it becomes the ‘first’ IP. You can add secondary addresses on that interface but you need to specify secondary when entering the IP address. The same thing happens on JunOS, but you HAVE to specify a logical unit at all times, even if it is only EVER going to have 1 IP. Therefore Unit 0 is the first IP, unit 1 the second, unit 2 the third and so on. If I wanted to add a second IP to this interface, I’d do it like so:
Olive# set interfaces em1 unit 1 family inet address 10.2.2.2/28
To set up a default route, we do it like so:
Olive# set routing-options static route 0.0.0.0/0 next-hop 10.1.1.2
There’ll be plenty more JunOS stuff coming very shortly!
STP works extremely well, but you lose operational links with it. i.e. you lose bandwidth. There are also quite a few other problems with STP (convergence speed being 1 of them)
TRILL seems to be the new technology coming in to resolve this. I’ve gone through the RFC: http://tools.ietf.org/html/rfc5556 and it looks pretty awesome stuff. I particularly like the following:
3.2. Zero Configuration and Zero Assumption
Both bridges and hubs are zero configuration devices; hubs having no
configuration at all, and bridges being automatically self-
configured. Bridges are further zero-assumption devices, unlike
hubs. Bridges can be interconnected in arbitrary topologies, without
regard for cycles or even self-attachment. Spanning tree protocols
(STPs) remove the impact of cycles automatically, and port
autolearning reduces unnecessary broadcast of unicast traffic.A TRILL solution should strive to have a similar zero-configuration,
zero-assumption operation. This includes having TRILL solution
components automatically discover other TRILL solution components and
organize themselves, as well as to configure that organization for
proper operation (plug-and-play). It also includes zero-
configuration backward compatibility with existing bridges and hubs,
which may include interacting with some of the bridge protocols, such
as spanning tree.VLANs add a caveat to zero configuration; a TRILL solution should
support automatic use of a default VLAN (like non-VLAN bridges), but
would undoubtedly require explicit configuration for VLANs where
bridges require such configuration.Autoconfiguration extends to optional services, such as multicast
support via Internet Group Management Protocol (IGMP) snooping,
broadcast support via serial copy, and support of multiple VLANs.
and
3.4. Spanning Tree Management
In order to address convergence under reconfiguration and robustness
to link interruption (Section 2.2), participation in the spanning
tree (STP) must be carefully managed. The goal is to provide the
desired stability of the TRILL solution and of the entire Ethernet
link subnet, which may include bridges using STP. This may involve a
TRILL solution participating in the STP, where the protocol used for
TRILL might dampen interactions with STP, or it may involve severing
the STP into separate STPs on ‘stub’ external Ethernet link subnet
segments.A requirement is that a TRILL solution must not require modifications
or exceptions to the existing spanning tree protocols (e.g., STP,
RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree
Protocol)).
Basically, even though TRILL sounds complicated, it very well could be plug and play (well about as plug and play as current STP mind you)
Now that my CCIP has been completed, I’d like to dive a bit into Juniper. We have a few Junipers in our network and I’d like to learn more about them. The few times I’ve used JunOS already I’ve been impressed.
I might do either the JNCIA-ER or the JNCIS-ER. I’ll see how much time I have.
Juniper do a great job of giving LOTS of free study material on their site, so I suggest you take a look as well.
I’ve gone and configured myself a Juniper Olive (google it) for actual labbing and so on. I might just put up a couple of Juniper labs!
I’ll put up a few things here and there as I go along.
Comments