• Home
  • About Fryguy
  • Published Workbooks
  • Nexus 7000 Training
  • Reading List
  • Resume/CV
  • Disney

Fryguy's Blog

~ A Network Blog by a Network Engineer

Fryguy's Blog

Monthly Archives: January 2013

Junos – RIP

31 Thursday Jan 2013

Posted by fryadmin in How To, Junos

≈ Leave a comment

Tags

junos, rip, Workbook

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!!


Share this:

  • Twitter
  • Facebook
  • Reddit
  • Google
  • LinkedIn
  • More
  • Print
www.pdf24.org    Send article as PDF   

Cisco Live US – Keynote Information

26 Saturday Jan 2013

Posted by fryadmin in Cisco Live

≈ 2 Comments

Tags

cisco live, CLUS, CLUS13

DSC07671

Well it seems that once the tap has been opened, information starts to flow!

Recently Tom (@networkingnerd) and I posted some information around Journey being the band at the Customer Appreciation Event, that is again being held at Universal Studios.  Well, we have just gotten some more news around the keynotes and schedules and I wanted to make sure I shared what I have with you as soon as I could.

Journey

So, here is what we know…

Your host with the most…

It would not be Cisco Live without our wonderful host, Carlos Dominguez!  I believe that this year will mark his 5th  year for hosting this event.  And to be honest, I cannot remember who hosted it before, he just does it so well and naturally!  Glad to have you back, Carlos!

2carlos

Continue reading →

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Google
  • LinkedIn
  • More
  • Print

Starting the Universal posts and Journey to Cisco Live US – Orlando

24 Thursday Jan 2013

Posted by fryadmin in Cisco Live

≈ 7 Comments

Tags

cisco live, CLUS, CLUS13

DSC07671

Well, it is getting to be that time of year when we start talking and getting ready for Cisco Live.  When I say WE –  I am referring to Tom (@networkingnerd) and John (@mrtugs) as we have done this for the past few years.

I just wanted to get this information out to you, so my Why you should go and the Venue information posting will come soon.

So, let us get to the part that everyone wants to know, where is the CAE and who is the band?  Well, if you looked at the title of this post you might have figured it out.

First up –  the band we chose in the voting poll is…..

Continue reading →

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Google
  • LinkedIn
  • More
  • Print
← Older posts

Paying the hosting fees.

Archives

  • January 2019
  • November 2018
  • October 2018
  • May 2018
  • April 2018
  • March 2018
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • April 2016
  • October 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • October 2014
  • September 2014
  • August 2014
  • June 2014
  • May 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • October 2013
  • September 2013
  • August 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010

Commercial

  • INE All Access INE All Access
  • SolarWinds Thwack
  • Tech Field Day

Networking

  • Amy Engineer
  • Broken Network
  • CCIE Flyer
  • CCIE In 3 Months
  • CCIE Journey
  • CHesapeake Netcraftsman Blogs
  • Ethereal Mind
  • Firewall.cx
  • Gestlalt IT
  • Herding Packets
  • INE All Access INE All Access
  • IP Space (Ivan Pepelnjak)
  • Lame Journal
  • Marko's Blog
  • Networking Nerd
  • Orhan Ergun – CCDE
  • Packet Life
  • Packet Queue
  • Tech Field Day
  • The Data Center Overlords

Podcast

  • No Strings Attached
  • Packet Pushers

Proudly powered by WordPress Theme: Chateau by Ignacio Ricci.