Day One: Junos for IOS Engineers download

BGP version 4, remote router ID 1. Once our BGP session is in the Established state, we must test our configuration. Lets do that now. Lets create a policy that matches R1s loopback interface, which can then be applied to the BGP process:.

Configure the BGP process on R2 to advertise its loopback address: R2 configure terminal R2 config router bgp R2 config-router network 2. Also, a quick check of the routing table should confirm that our prefixes are being installed. BGP table version is 3, local router ID is 2.

The ability to configure a simple BGP peering with only two commands setting the autonomous system number and the peering itself is a clear advantage with Junos. While it is handy to be able to configure route advertisement directly under the BGP process in IOS, there is no question that this is where Junos policy configuration can really shine for you. Having a consistent framework for policy configuration is a clear example of where Junos can excel in your network.

As your network grows, or requires new services, these advantages will grow as well. Another thing worth mentioning is the concept of synchronization, which in IOS states that a route must be actively in the routing table from an IGP before it will be announced via BGP.

Typically this is disabled. Junos has no such criteria. The IBGP peering will be configured to peer between loopback addresses, which will require us to add a static route in order for the remote loopback address to be reachable. This section will use two routers directly connected in a single AS, as shown in the diagram of the topology in Figure 3.

R2 config-if ip address 2. R2 config-if ip address Static routes to the neighbors loopback address are unnecessary in this case, since OSPF is running on the network and there is already full reachability. In this case, well configure static routes anyway as doing so demonstrates the syntax required to do so. Configure a static route to R2s loopback address on R1, pointing to R1. R2s physical interface as the next-hop: R1 configure terminal R1 config ip route 2.

Entering configuration mode [edit] cjones R1 set routing-options static route 2. Configure a static route to R2s loopback address on R1, pointing to R2s physical interface as the next-hop:. Entering configuration mode [edit] cjones R2 set routing-options static route 1. R2 config router bgp R2 config-router no auto-summary R2 config-router no synchronization. Entering configuration mode [edit] cjones R2 set routing-options autonomoussystem [edit].

BGP neighbor is 1. The main differences are that type internal is used, and the peer-as matches the local AS, however the peer-as command is not required and the peer AS and local AS are implied to be the same whenever the type is internal. One of the advantages of Junos is being able to group BGP peering sessions together. This can provide logical separation of IBGP and EBGP peering sessions, separation of service provider connections, or whatever purpose you can come up with.

Also notice that Junos does not require an equivalent to the no auto summary command in IOS. This is because Junos doesnt have the concept of classful or classless networking. CIDR is used exclusively. The topology for this section is a single layer 3 switch, so a diagram is unnecessary.

And our task list in this section is to:. Note that in either case, the ethernet-switching family must be configured on the interface. This method will seem more familiar to IOS engineers. It doesnt matter which method you choose, but the important thing is to be consistent in your approach.

So lets configure an interface as an Junos uses a single VLAN interface, with a unit number. While this is not a requirement, it is certainly a best practice. To Verify the Layer 3 Interface 1. And to finish the verification process, show the list of interface IP addresses on the switch:.

Show the list of interface IP addresses on the switch and you can see the verification:. The two OSes are equally paired in this match, so its simply a matter of the process the IOS Engineer should pay attention to. This is true for most of the book, which should put to bed the rumor that Junos is somehow more complicated than IOS.

It isnt. This section will use two routers directly connected in a single AS, as shown in the topology of Figure 4. Now lets configure Junos with the same criteria, but in order to configure NAT as shown in this book, the device must be in flow-mode, which is the default on branch SRX devices. While in flow-mode, firewall security policies must be configured in order for traffic to flow.

Configuring security policies is beyond the scope of this book. Total port number usage for port translation pool: 0 Maximum port number for port translation pool: Show the security flow session for R1 configure terminal R1 config ip nat inside source static tcp Destination NAT in Junos is very simple and straightfoward.

The creation of a destination pool is essential for destination NAT in Junos. The pool specifies the internal IP address that the external request will be sent to, once translated. A destination NAT policy simply specifies match criteria, and then an action to perform on any matches. Show the security session for the destination NAT flow to In this chapter, you will learn how many of the configuration examples in this book fit together.

A small-scale version of a typical enterprise network will be built and configured using the building blocks from earlier chapters. Lets use a simple three-router topology, configured as a single-area OSPF network, with EBGP to two service providers who will each be sending a default route. The diagram of the topology can be seen in Figure 5. R1 config-if ip address Set IP addresses on the interfaces on R2: 3. Set IP addresses on the interfaces on R R3 config interface loopback 0 R3 config-if ip address 3.

Configure the loopback interface as passive. Also, manually set the OSPF router-id:. R1 config-router router-id 1. And the same for R3. Configure R1 to inject a default route into the OSPF process: R1 configure terminal R1 config router ospf 1 R1 config-router default-information originate. Next, we need to add the exact same configuration to R2: Lets try something new here. Instead of re-typing everything, lets configure R2 using the patch syntax in step 4.

But this? It made no sense to me. Then, at the start of , I started a new job and used Junos properly for the first time. I was very lucky to work with two people in particular who taught me why Junos works the way it does — and when it clicked, it was a revelation. It made so much sense! I thought I loved networking when I only knew Cisco. But as soon as Junos clicked for me, going back to standard IOS seemed not only clunky, but unforgivable. I always point them in the direction of some resources I found useful during my studies.

They say that although they can kind of read a configuration file, they still find it difficult, and often they say they find it more complicated than IOS.

Conclusion Are you getting used to the change of appearance between the two OSes? Remember that you can use display set after show configuration in Junos to show Junos is similar to something you might be used to.

Unfortunately, IOS does not have a reciprical to display Junos hierarchy. Okay, these were basic concepts that you can now build upon in the coming chapters. You opened the Juniper device, established user accounts, and even upgraded the software. Now, lets do a basic configuration walk-through.

And this chapter doesnt beat around the bush. It shows you how to build configurations that are usable in a real network. Each example details a specific technology, and a summary at the end of the example draws comparisons and conclusions about the differences between the IOS and Junos configurations. Using the configurations to study going from IOS to Junos, compare sequences, match commands, and get accustomed to the output. Figure 2. To configure the IOS routers for initial connectivity In order for the routers to be able to communicate, IP addressing must be configured on connected interfaces.

Set IP addresses on the interfaces on R1: R1 configure terminal R1 config interface loopback 0 R1 config-if ip address 1. Set IP addresses on the interfaces on R3: R3 configure terminal R3 config interface loopback 0 R3 config-if ip address 3. To Verify the IOS Routers for Initial Connectivity In order to verify that IP addresses have been configured correctly, a simple ping can test to see if the remote end of a link is reachable and active.

Ping R1 to R2: R1 ping Ping R1 to R3: R1 ping Ping R2 to R3: R2 ping In a production network, the loopback interfaces are often advertised into the OSPF network so that the router-id of the device is a reachable address. Including the passive-interface command simply tells the software to advertise the link as a Type-1 LSA, but it does not attempt to form an adjacency over that interface.

Include the passive-interface command since there will never be an OSPF neighbor via the loopback: R1 configure terminal R1 config router ospf 1 R1 config-router network 1. R3 configure terminal R3 config router ospf 1 R3 config-router network 3. To Verify Loopback Interfaces in OSPF Verification of the loopback interfaces is done simply by checking that the loopback interface is indeed running OSPF, and then by checking the RIB on the other routers to make sure the loopback interfaces are being learned on the other devices.

Alternately, a simple check of the LSDB on any router within the area should give similar information. Ensure the loopback on R1 1. Ensure the loopback on R2 2. Ensure the loopback on R3 3. Routing entry for 3. An example of this is if a router-id that is not an IP address assigned to any interface on the router is desired.

It is also sometimes desirable to ensure deterministic entries in the OSPF link-state database LSDB as opposed to allowing the system to arbitrarily choose the router-id.

Use show commands to view the current router-id for R1. Then, configure R1 to use router-id Use show commands to view the current router-id for R2.

Then, configure R2 to use router-id Use show commands to view the current router-id for R3. Then, configure R3 to use router-id To Verify OSPF Router-id Has Been Manually Assigned You can verify that the router-id has been correctly assigned by checking the output of show ip protocol, and can further verify its correct by checking that the router ID of the adjacencies has been changed.

Junos Configuration Now lets configure the same topology in Junos. Pay attention to the logical structure of the configuration, and the placement of interface and protocol configuration. The advantages of such a simple and standardized structure should be easily apparent. To Configure the Junos Routers for Initial Connectivity Here youll use the knowledge you gained in Chapter 1, and apply interface addressing for each of the routers being configured, including the loopback interface.

This is significantly less complex than the archaic network commands that are used in IOS. This output should. This is the first time that youve seen the routing table in Junos in this book. As there is no concept of classful networking in Junos, notice that there are no statements similar to the x. To Configure the OSPF Router-id Manually The Junos software will assign a router-id from the first interface that is detected with a non-martian address when rpd starts typically at boot.

This almost always results in the router choosing the address assigned to the loopback interface to be used as the router-id. This is essentially the same behavior that youd be used to with IOS. Summary The task in this section was a simple OSPF network configuration, but it contrasted the almost-archaic network commands for dictating which interfaces on which to run OSPF in IOS with how Junos simplifies the process by allowing an administrator to specify which interfaces will run OSPF under the Junos protocol hierarchy.

And again, these small magnifications would magnify in a much larger network as well. Comparing the two OSes you should be able to learn not only the Junos methodology but its consistent framework for policy configuration. Lets just use two routers that are directly connected. The EBGP peering will use the physical interfaces. The following is the diagram of the topology:. Use physical interfaces to peer. Advertise loopback interfaces to neighbor. Set IP addresses on the interfaces on R2: R2 configure terminal R2 config interface loopback 0 R2 config-if ip address 2.

To Verify Initial Connectivity 1. Configure the BGP process on R1 to advertise its loopback address: R1 configure terminal R1 config router bgp R1 config-router network 1. Configure the BGP process on R2 to advertise its loopback address: R2 configure terminal R2 config router bgp R2 config-router network 2.

Junos Configuration Okay, now lets configure this same network using Junos routers and watch the difference. And commit the configuration: [edit] cjones R1 commit and-quit commit complete Exiting configuration mode. Commit the configuration: [edit] cjones R1 commit and-quit commit complete Exiting configuration mode. Lets do that now. Like most routing manipulation in Junos, this is accomplished using policy.

Now lets create a policy that matches R2s loopback interface, which can then be applied to the BGP process:. If you do not require vSRX to run in flow mode, you can disable the flow mode. Above snippet should be self explanatory. Most of the configuration will comes as default factory settings.

Pay attention to this config if you find something is not working in your environment. Loopback address will be the router-id. Deploying Basic QoS. North Star Controller Up and Running. Dynamic Subscriber Management. Junos Space Security Director Poster. MACsec Up and Running. VPN Poster. Automating Junos with Ansible.

Junos PyEZ Cookbook. Hardware Defined Networking. Finishing Junos Deployments.