Learning a manufactures’ OS is generally not too difficult once you’ve learnt one. After all OSPF is still OSPF. BGP is still BGP etc. Most of the time you just need to learn the configuration syntax for your local device and you’re good to go.
Some things can be quite different though. One of the bigger differences between IOS and JUNOS is how routes are advertised through IGP/BGP as well as redistributing routes from one protocol to another.
I wanted to go over some of the basics. In a later post I can get more complicated because it can start to get VERY complicated. For this mini lab I’ll have my current JUNOS topology and I’ll match it with an identical IOS config.
Juniper:
Cisco:
Each of the routers in the topology have a loopback address with their number in all octets. i.e. R1 is 1.1.1.1/32, R2 is 2.2.2.2/32 and so on.
R1, R2, and R5 are all running OSPF with each other. R5 is running eBGP with R3 and R4. R3 and R4 are in AS numbers 3 and 4 respectively and R3 is in AS3.
The first thing I want to do is advertise R4′s loopback address to R5. In IOS I could either configure a network statement, or I could redistribute connected through a route-map that matched the loopback. Let’s do the second for now and do the same for JUNOS.
IOS (R4):
route-map LOOPBACK permit 10 match interface Loopback0 ! router bgp 4 redistribute connected route-map LOOPBACK neighbor 10.45.45.5 remote-as 5
This route-map will match the address on R4′s loopback, then advertise that loopback to it’s BGP neighbours. The important thing to note is that the route-map has an implicit deny at the end. Hence if you just match something in the route-map, then anything not matching is denied.
Let’s take a quick look on R5 to see that we are seeing R4′s loopback:
R5#sh ip bgp | begin 4.4.4.4
*> 4.4.4.4/32 10.45.45.4 0 0 4 ?
R5#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
1
4
10.45.45.4 from 10.45.45.4 (4.4.4.4)
Origin incomplete, metric 0, localpref 100, valid, external, best
As expected, we are seeing R4′s loopback in our BGP table. We also notice the origin is ? (incomplete)
Let’s now do the same on JUNOS:
JUNOS(J4):
policy-statement ADVERTISE_LOOPBACK {
from interface lo0.4;
then accept;
}
protocols {
bgp {
group EXTERNAL {
export ADVERTISE_LOOPBACK;
local-as 4;
neighbor 10.45.45.5 {
peer-as 5;
In JUNOS I have created a policy statement that matches interface lo0.4 – I then have the action of accept which means to advertise if exported. Under the BGP process I then call this policy via an export statement. Essentially they are doing very similar things. However at this stage there is one BIG difference. In IOS, as noted above, a route-map has an implicit deny at the end of it. A route-policy on the other hand has the default protocol policy. I won’t go into all of the default policies as you can find them right here: http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/default-routing-policies-and-actions.html
Let’s have a look on J5 to ensure we are seeing that loopback though:
USER5:J5> show route protocol bgp
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[BGP/170] 16:38:00, localpref 100
AS path: 4 I
> to 10.45.45.4 via fe-0/0/0.45
USER5:J5> show route 4.4.4.4/32 detail
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
4.4.4.4/32 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 1061
Address: 0x8f9c298
Next-hop reference count: 2
Source: 10.45.45.4
Next hop: 10.45.45.4 via fe-0/0/0.45, selected
State:
Peer AS: 4
Age: 16:38:08
Task: BGP_4_5.10.45.45.4+61939
Announcement bits (2): 0-KRT 3-BGP RT Background
AS path: 4 I
Accepted
Localpref: 100
Router ID: 4.4.4.4
Another difference you’ll see is that JUNOS considers this route an internal route, not an incomplete route like IOS does.
Both OS’ allow you to manipulate attributes through the same route-map/route-policy. Let’s say we wanted to adjust the MED to 500 when advertising the loopback.
IOS:
R4#sh run | sec route-map
route-map LOOPBACK permit 10
match interface Loopback0
set metric +500
R5#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
4
10.45.45.4 from 10.45.45.4 (4.4.4.4)
Origin incomplete, metric 500, localpref 100, valid, external, best
JUNOS:
policy-options {
policy-statement ADVERTISE_LOOPBACK {
from interface lo0.4;
then {
metric add 500;
accept;
USER5:J5> show route 4.4.4.4/32 detail
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
4.4.4.4/32 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 1061
Address: 0x8f9c298
Next-hop reference count: 2
Source: 10.45.45.4
Next hop: 10.45.45.4 via fe-0/0/0.45, selected
State:
Peer AS: 4
Age: 15 Metric: 500
Task: BGP_4_5.10.45.45.4+61939
Announcement bits (2): 0-KRT 3-BGP RT Background
AS path: 4 I
Accepted
Localpref: 100
Router ID: 4.4.4.4
So route-policy is kind of like a route-map, but the same route-policy statement is also used for redistribution. Let’s now say we want to redistribute all OSPF routes into BGP. In IOS we would use redistribution, while in JUNOS we use route-policy again.
Let’s start with IOS again:
R5#sh run | sec router bgp router bgp 5 redistribute ospf 1 R4#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.45.45.5 11 0 5 ? *> 2.2.2.2/32 10.45.45.5 11 0 5 ? *> 4.4.4.4/32 0.0.0.0 500 32768 ? *> 5.5.5.5/32 10.45.45.5 0 0 5 ? *> 10.12.12.0/24 10.45.45.5 11 0 5 ? *> 10.15.15.0/24 10.45.45.5 0 0 5 ? *> 10.21.21.0/24 10.45.45.5 20 0 5 ? *> 10.25.25.0/24 10.45.45.5 0 0 5 ?
In JUNOS there is no redistribute command. Rather we use an export route-policy, and simply match OSPF routes:
policy-options {
policy-statement OSPF2BGP {
from protocol ospf;
then accept;
protocols {
bgp {
local-as 5;
group EXTERNAL {
export OSPF2BGP;
USER4:J4> show route protocol bgp
inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 00:01:54, MED 1, localpref 100
AS path: 5 I
> to 10.45.45.5 via fe-0/0/1.45
2.2.2.2/32 *[BGP/170] 00:01:54, MED 1, localpref 100
AS path: 5 I
> to 10.45.45.5 via fe-0/0/1.45
10.12.12.0/24 *[BGP/170] 00:01:54, MED 2, localpref 100
AS path: 5 I
> to 10.45.45.5 via fe-0/0/1.45
10.21.21.0/24 *[BGP/170] 00:01:54, MED 2, localpref 100
AS path: 5 I
> to 10.45.45.5 via fe-0/0/1.45
I’ll be spending more time on route-policy in future, but for now this should do. In the end it’s really not that difficult, just different.
