Tags

, ,

Junos_sw_logo

Here is a quick reminder on what the lab looks like:

RIP Lab Topology

Ok, time to get some routing.  First up, Routing Information Protocol, RIP!

 

So, first up we will configure the Cisco router, R4 for RIP.

 

R4(config)#router rip

R4(config-router)#ver 2

R4(config-router)#net 192.168.14.0

R4(config-router)#net 4.0.0.0

R4(config-router)#no auto-summary

 

Now onto the Juniper configuration. 

J1 is up first.

To configure rip, we need to be under the Protocols stanza

 

[edit]

jfry@J1# edit protocols

 

Once there we configure the Interfaces that we want to participate in RIP.  In IOS you configure the networks, in Junos you tell the router what interfaces will participate in RIP.  Also, you need to give the process an identifier, here I called it FryguyRIP

 

[edit protocols]                       

jfry@J1# set rip group FryguyRIP neighbor fe-0/0/7.0   

 

[edit protocols]

jfry@J1# set rip group FryguyRIP neighbor ge-0/0/0.0

 

[edit protocols]

jfry@J1# set rip group FryguyRIP neighbor fe-0/0/2.0

 

[edit protocols]

jfry@J1# show | compare

[edit protocols]

+ rip {

+     group FryguyRIP {

+         neighbor fe-0/0/7.0;

+         neighbor ge-0/0/0.0;

+         neighbor fe-0/0/2.0;

+     }

+ }

 

[edit protocols]

jfry@J1#

 

Time to commit that and see if R4 has routes to R1 interfaces.

jfry@J1# commit and-quit

commit complete

Exiting configuration mode

 

jfry@J1>

 

Now for J2:

 

jfry@J2> edit 

Entering configuration mode

 

[edit]

jfry@J2# edit protocols

[edit protocols]

jfry@J2# set rip group FryguyRIP neighbor ge-0/0/0.0

 

[edit protocols]

jfry@J2# set rip group FryguyRIP neighbor ge-0/0/1.0

 

[edit protocols]

jfry@J2# commit and-quit

commit complete

Exiting configuration mode

 

jfry@J2>

 

and finally J3:

 

jfry@J3> edit

Entering configuration mode

 

[edit]

jfry@J3# edit protocols

 

[edit protocols]

jfry@J3# set rip group FryguyRIP neighbor fe-0/0/1.0

 

[edit protocols]

jfry@J3# set rip group FryguyRIP neighbor fe-0/0/2.0 

 

[edit protocols]

jfry@J3# commit and-quit

commit complete

Exiting configuration mode

 

jfry@J3>

 

Ok, that should be RIP configured.  Let’s take a look at R4 and see what routes we now have.

R4#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

       E1 – OSPF external type 1, E2 – OSPF external type 2

       i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

       ia – IS-IS inter area, * – candidate default, U – per-user static route

       o – ODR, P – periodic downloaded static route

 

Gateway of last resort is not set

 

C    192.168.14.0/24 is directly connected, Ethernet0

     4.0.0.0/32 is subnetted, 1 subnets

C       4.4.4.4 is directly connected, Loopback0

R4#

 

Hmm, no routes.  Does J1 have a route?

 

 

The way to check the routing table on Junos is with show route table inet.0 (for IPv4)

jfry@J1> show route table inet.0   

 

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

+ = Active Route, – = Last Active, * = Both

 

1.1.1.1/32         *[Direct/0] 02:12:04

                    > via lo0.0

4.4.4.4/32         *[RIP/100] 00:10:08, metric 2, tag 0

                    > to 192.168.14.4 via fe-0/0/7.0

192.168.12.0/24    *[Direct/0] 02:07:48

                    > via ge-0/0/0.0

192.168.12.1/32    *[Local/0] 02:11:25

                      Local via ge-0/0/0.0

192.168.13.0/24    *[Direct/0] 02:08:16

                    > via fe-0/0/2.0

192.168.13.1/32    *[Local/0] 02:11:24

                      Local via fe-0/0/2.0

192.168.14.0/24    *[Direct/0] 02:11:20

                    > via fe-0/0/7.0

192.168.14.1/32    *[Local/0] 02:11:24

                      Local via fe-0/0/7.0

224.0.0.9/32       *[RIP/100] 00:10:09, metric 1

                      MultiRecv

 

jfry@J1>

 

Yeah, it has a route to R4 loopback.

 

Here is a difference with Junos and IOS, Junos requires the use of policy-statements to advertise routes.  You can think of them as Cisco route-maps to advertise and filter routes in certain protocols.  Why is this required, well it has to do with the default import and export polices for the protocols. The default for RIP is to accept all learn routes from neighbors, but reject exporting them to neighbors unless there is a policy that permits it.   This is definitely a more secure way to approach routing! 

 

As a bonus to this, this is also how you advertise the loopback interfaces on the Junos router.  So, let’s create a policy to export RIP routes as well as our loopback address.  The use of the direct keyword is analogous to connected in IOS. 

 

J1 up first!

We will create a policy called RIP_Routes and allow routes from the RIP protocol to be passed

[edit]

jfry@J1# set policy-options policy-statement RIP_Routes term 1 from protocol rip 

 

As well as let Direct attached networks (loopback) be passed

[edit]

jfry@J1# set policy-options policy-statement RIP_Routes term 1 from protocol direct                

 

And finally this is the term that means that they can pass

[edit]

jfry@J1# set policy-options policy-statement RIP_Routes term 1 then accept                   

 

Ok, lets take a look at our statement so far

jfry@J1# show | compare

[edit]

+  policy-options {

+      policy-statement RIP_Routes {

+          term 1 {

+              from protocol [ rip direct ];

+              then accept;

+          }

+      }

+  }

 

[edit]

jfry@J1#

 

Ok, now that we have a policy-statement, we now need to apply that to the protocol RIP and to our RIP group, FryguyRIP.

First we will change stanza to the rip protocol

[edit]

jfry@J1# edit protocols rip

 

And then configure our export statement:

 [edit protocols rip]

jfry@J1# set group FryguyRIP export RIP_Routes

 

Now we can look at our configuration

[edit protocols rip]

jfry@J1# top

 

[edit]

jfry@J1# show | compare

[edit protocols rip group FryguyRIP]

+    export RIP_Routes;

[edit]

+  policy-options {

+      policy-statement RIP_Routes {

+          term 1 {

+              from protocol [ rip direct ];

+              then accept;

+          }

+      }

+  }

 

[edit]

jfry@J1#

 

And then commit and it and check R4 for a route to J1 loopback. I have a debut on R4 for ip routing, this way I can see changes.

R4#

*Mar  1 03:44:03.419: RT: SET_LAST_RDB for 1.1.1.1/32

  NEW rdb: via 192.168.14.1

 

*Mar  1 03:44:03.423: RT: add 1.1.1.1/32 via 192.168.14.1, rip metric [120/1]

*Mar  1 03:44:03.423: RT: NET-RED 1.1.1.1/32

*Mar  1 03:44:03.423: RT: NET-RED queued, Queue size 1

R4#

 

Yup, the route to J1 Loopback is in the routing table.  Wonder if anything else is there?

R4#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

       E1 – OSPF external type 1, E2 – OSPF external type 2

       i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

       ia – IS-IS inter area, * – candidate default, U – per-user static route

       o – ODR, P – periodic downloaded static route

 

Gateway of last resort is not set

 

R    192.168.12.0/24 [120/1] via 192.168.14.1, 00:00:08, Ethernet0

     1.0.0.0/32 is subnetted, 1 subnets

R       1.1.1.1 [120/1] via 192.168.14.1, 00:00:08, Ethernet0

R    192.168.13.0/24 [120/1] via 192.168.14.1, 00:00:08, Ethernet0

C    192.168.14.0/24 is directly connected, Ethernet0

     4.0.0.0/32 is subnetted, 1 subnets

C       4.4.4.4 is directly connected, Loopback0

R4#

 

Nice, we now have routes to J2 and J3 interfaces – but not their loopbacks.
Time to grab the changes from J1 and apply the same ones to J2 and J3.

 

Here is what we are merging into J2 and J3 configs

protocols {

    rip {

        group FryguyRIP {

            export RIP_Routes;

        }

    }

}

policy-options {

    policy-statement RIP_Routes {

        term 1 {

            from protocol [ rip direct ];

            then accept;

        }

    }

}

 

Time to get these loaded so we have full reachability in this network!

 

J2:

jfry@J2> edit

Entering configuration mode

 

[edit]

jfry@J2# load merge terminal

[Type ^D at a new line to end input]

protocols {

    rip {

        group FryguyRIP {

            export RIP_Routes;

        }

    }

}

policy-options {

    policy-statement RIP_Routes {

        term 1 {

            from protocol [ rip direct ];

            then accept;

        }

    }

}

^D load complete

 

[edit]

jfry@J2# commit and-quit

commit complete

Exiting configuration mode

 

jfry@J2>

 

and J3

jfry@J3> edit

Entering configuration mode

 

 

[edit]

jfry@J3# load merge terminal

[Type ^D at a new line to end input]

protocols {

    rip {

        group FryguyRIP {

            export RIP_Routes;

        }

    }

}

policy-options {

    policy-statement RIP_Routes {

        term 1 {

            from protocol [ rip direct ];

            then accept;

        }

    }

}

^D load complete

 

[edit]

jfry@J3# commit and-quit

commit complete

Exiting configuration mode

 

jfry@J3>

 

Now we can check the routing table on R4:

R4#sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

       E1 – OSPF external type 1, E2 – OSPF external type 2

       i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

       ia – IS-IS inter area, * – candidate default, U – per-user static route

       o – ODR, P – periodic downloaded static route

 

Gateway of last resort is not set

 

R    192.168.12.0/24 [120/1] via 192.168.14.1, 00:00:00, Ethernet0

     1.0.0.0/32 is subnetted, 1 subnets

R       1.1.1.1 [120/1] via 192.168.14.1, 00:00:00, Ethernet0

R    192.168.13.0/24 [120/1] via 192.168.14.1, 00:00:00, Ethernet0

     2.0.0.0/32 is subnetted, 1 subnets

R       2.2.2.2 [120/2] via 192.168.14.1, 00:00:00, Ethernet0

C    192.168.14.0/24 is directly connected, Ethernet0

     3.0.0.0/32 is subnetted, 1 subnets

R       3.3.3.3 [120/2] via 192.168.14.1, 00:00:00, Ethernet0

     4.0.0.0/32 is subnetted, 1 subnets

C       4.4.4.4 is directly connected, Loopback0

R    192.168.23.0/24 [120/2] via 192.168.14.1, 00:00:01, Ethernet0

R4#

 

Looks great!  Let’s check J1 to make sure:

                                       

jfry@J1> show route table inet.0

 

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

+ = Active Route, – = Last Active, * = Both

 

1.1.1.1/32         *[Direct/0] 03:52:17

                    > via lo0.0

2.2.2.2/32         *[RIP/100] 00:01:37, metric 2, tag 0

                    > to 192.168.12.2 via ge-0/0/0.0

3.3.3.3/32         *[RIP/100] 00:01:26, metric 2, tag 0

                    > to 192.168.13.3 via fe-0/0/2.0

4.4.4.4/32         *[RIP/100] 00:08:44, metric 2, tag 0

                    > to 192.168.14.4 via fe-0/0/7.0

192.168.12.0/24    *[Direct/0] 03:48:01

                    > via ge-0/0/0.0

192.168.12.1/32    *[Local/0] 03:51:38

                      Local via ge-0/0/0.0

192.168.13.0/24    *[Direct/0] 03:48:29

                    > via fe-0/0/2.0

192.168.13.1/32    *[Local/0] 03:51:37

                      Local via fe-0/0/2.0

192.168.14.0/24    *[Direct/0] 03:51:33

                    > via fe-0/0/7.0

192.168.14.1/32    *[Local/0] 03:51:37

                      Local via fe-0/0/7.0

192.168.23.0/24    *[RIP/100] 00:01:37, metric 2, tag 0

                    > to 192.168.12.2 via ge-0/0/0.0

                      to 192.168.13.3 via fe-0/0/2.0

224.0.0.9/32       *[RIP/100] 00:04:13, metric 1

                      MultiRecv

                                       

jfry@J1>

 

Yup, we have all the routes.

 

 

Since R4 is the furthest away, we can test all our PINGs from its loopback

 

R4#p 3.3.3.3 so l0

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms

R4#p 2.2.2.2 so l0

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R4#p 1.1.1.1 so l0

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms

R4#

 

Nice! Full reachability!!


[AMAZONPRODUCT=1449316638]