A Network Artist : August 2010

Generic Routing Encapsulation (GRE) is a tunneling protocol
that can encapsulate a wide variety of network layer protocol
packet types inside an IP tunnels, creating a virtual point-to
-point link to various brands of routers at remote points over
an Internet Protocol (IP) internetwork.

It always kind of amazed me but in the beginning of my career in network I had lot of problems in understanding and configuring GRE tunnels. Maybe the reason is that this topic is not very well documented on Cisco DOC cd - Atleast that's what I think.

The problem for me was never to configure the tunnel itself but rather understanding how to choose tunnel source vs tunnel destination, how GRE tunnels works from technology point of view, their benefits, their drawbacks, understanding GRE keep-alive mechanism & what things can potentially cause problems with tunnels etc.

Some Tiny details before getting deeper:

GRE refers to IP protocol number type 47

RFC - 1702

Types - P2P, P2M (eg. - DMVPN - More Of a Security Topic)

So let's begin with it and let me explain each of these things one by one.

1.) Why we need GRE tunnels in First place -

GRE tunnels are helpful for a network administrator in many ways actually. For example if you are running a routing protocol or may be static routing with your ISP. But you don't want ISP to see your internal network. So in that case with the help of Static Routing or IGP (that ISP is running too with you) you will establish basic connectivity between your branches with help of ISP. Now later you can create tunnels between all branches with help of basic connectivity you had established earlier and then you can run routing protocol over the tunnel & can exchange routes. Now technically once GRE tunnel is established between your branch offices then ISP can't see what data is traveling inside the tunnel....or in other words..your routes & data.

Another situation where we can probably use GRE tunnel is to pass OSPF LSAs through Stub/Totally Stub Area. For example once Area is configured as stub, by default it will not allow you to create virtual link over it or to pass LSAs which it is supposed to block as Stub area but some how you need do these things....I mean you get the idea...there are many other twists in Real world and CCIE lab exam where you can think of using tunnels...so basically a bandage which you can use in many situations. There are many more reasons but these are most common one

2.) Requirements to Setup the tunnel:

The requirement to setup tunnel is very simple. All you need is the reach-ability between the two end points of the tunnel. Usually you will see people using loopback interface as tunnel source address but technically you can choose any interface as source at your side but destination will always be some ip address of other side and can't be interface...that actually makes sense too as Local Router don't know about what interfaces we have on the other side.

But one thing you should keep in mind while choosing any interface as source address is that by default it will pick the primary IP of the interface, so in case you want to choose secondary IP then mention Secondary IP address specifically as source ip address.

3.) Drawbacks Of GRE tunnels :

There is only one major drawback of GRE tunnel and that is - it adds two extra headers to our original IP packet. So those guys who are concerned with Bandwidth may have some issues.

However if you change the tunnel mode to "IPIP" then you can reduce some overhead as "IPIP" tunnel adds 1 header instead of 2 compare to "GRE". So that makes it more efficient.

Here is how process occurs for GRE

You can also use other method to prevent bandwidth like traditional TCP compression techniques or modern MQC based techniques.

Another drawback is that GRE tunnels are not very scalable solution. The default BW for GRE tunnels is just 9 Kbps with MTU size 1514 byes, so your routing protocol may not follow the path you desire to, so watch out for such things in that case.

Enough theory I guess :-)

For rest of theoretical details I'll post some URL for further reference.

Now lets create a GRE tunnel.

Here is the quick topology Diagram:-> Click on Image for better view

Step 1:

Establish the basic connectivity between tunnel source and destination points. In our case we will use R1's Lo0 interface as tunnel source and R3's interface Lo0 (It's IP Address) as our tunnel destination point.

To establish the reach-ability between these two end point we will be running OSPF with our ISP Router(R2).

So lets first establish basic connectivity between end point:

################

***R1***

!
en
!
conf t
!
no ip domain-lo
!
ho R1
!
int lo0
ip add 10.0.0.1 255.255.255.255
exit
!
int lo1
ip add 100.100.100.100 255.255.255.0
exit
!
int s0/0
ip add 12.12.12.1 255.255.255.0
no sh
exit
!
router ospf 1
router-id 1.1.1.1
net 10.0.0.1 0.0.0.0 a 0
net 12.12.12.1 0.0.0.0 a 0
exit
!

##########################

***R2***

!
en
!
conf t
!
no ip domain-lo
!
ho R2
!
int s0/0
ip add 12.12.12.2 255.255.255.0
ip ospf 1 a 0
no sh
exit
!
int s0/1
ip add 23.23.23.2 255.255.255.0
ip ospf 1 a 0
no sh
exit
!

##########################

***R3***

!
en
!
conf t
!
no ip domain-lo
!
int lo0
ip add 20.0.0.1 255.255.255.255
exit
!
int lo1
ip add 200.200.200.200 255.255.255.0
exit
!
int s0/0
ip add 23.23.23.3 255.255.255.0
no sh
exit
!
router ospf 1
router-id 3.3.3.3
net 20.0.0.1 0.0.0.0 a 0
net 23.23.23.3 0.0.0.0 a 0
exit
!

----

So by this time our OSPF should be working fine and R1/R3's Interface Lo0 should have reach-ability to each other.

Step 2:

In second step we will create a virtual tunnel interface and will assign it following things:

1. IP address

2. Tunnel Source

3. Tunnel Desitnation

Here is the quick config now:

***R1***

!
int tu 0
ip address 13.13.13.1 255.255.255.0
tunnel source Loopback0
~~tunnel destination 13.13.13.3~~
tunnel destination 20.0.0.1
keepalive 1 3 -> Optional
exit
!

***R3***

!
int tu 0
ip address 13.13.13.3 255.255.255.0
keepalive 1 3 -> Optional
tunnel source Loopback0
tunnel destination 10.0.0.1
exit
!

So by now your tunnel should have come up :-)

Step 3:

Now once tunnel is up and running we can can RUN our Organizational IGP over the tunnel to establish complete connectivity among all locations.

In our case Lo1 interface over R1/R3 represents their LAN segment and IGP we are running inside organization is EIGRP AS 100.

Lets configure EIGRP for Interface Lo1 on both routers along with enabling it over Tunnel interface.

***R1***

!
router eigrp 100
no au
net 100.100.100.100 0.0.0.0
net 13.13.13.1 0.0.0.0
exit
!

***R3***

!
router eigrp 100
no au
net 200.200.200.200 0.0.0.0
net 13.13.13.3 0.0.0.0
exit
!

################

Lets verify the routing tables as see if it's working as expected:

R1(config-router)#do sh ip ro
Gateway of last resort is not set

D    200.200.200.0/24 [90/297372416] via 13.13.13.3, 00:01:38, Tunnel0
     100.0.0.0/24 is subnetted, 1 subnets
C       100.100.100.0 is directly connected, Loopback1
     20.0.0.0/32 is subnetted, 1 subnets
O       20.0.0.1 [110/129] via 12.12.12.2, 00:10:24, Serial0/0
     23.0.0.0/24 is subnetted, 1 subnets
O       23.23.23.0 [110/128] via 12.12.12.2, 00:10:24, Serial0/0
     10.0.0.0/32 is subnetted, 1 subnets
C       10.0.0.1 is directly connected, Loopback0
     12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial0/0
     13.0.0.0/24 is subnetted, 1 subnets
C       13.13.13.0 is directly connected, Tunnel0

***********************************

R2(config-router)#do sh ip ro -> ISP Router Dont's have info about Client's EIGRP subnets
Gateway of last resort is not set

     20.0.0.0/32 is subnetted, 1 subnets
O       20.0.0.1 [110/65] via 23.23.23.3, 00:11:33, Serial0/1
     23.0.0.0/24 is subnetted, 1 subnets
C       23.23.23.0 is directly connected, Serial0/1
     10.0.0.0/32 is subnetted, 1 subnets
O       10.0.0.1 [110/65] via 12.12.12.1, 00:12:01, Serial0/0
     12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial0/0

************************************

R3(config-router)#do sh ip ro
Gateway of last resort is not set

C    200.200.200.0/24 is directly connected, Loopback1
     100.0.0.0/24 is subnetted, 1 subnets
D       100.100.100.0 [90/297372416] via 13.13.13.1, 00:03:33, Tunnel0
     20.0.0.0/32 is subnetted, 1 subnets
C       20.0.0.1 is directly connected, Loopback0
     23.0.0.0/24 is subnetted, 1 subnets
C       23.23.23.0 is directly connected, Serial0/0
     10.0.0.0/32 is subnetted, 1 subnets
O       10.0.0.1 [110/129] via 23.23.23.2, 00:12:13, Serial0/0
     12.0.0.0/24 is subnetted, 1 subnets
O       12.12.12.0 [110/128] via 23.23.23.2, 00:12:13, Serial0/0
     13.0.0.0/24 is subnetted, 1 subnets
C       13.13.13.0 is directly connected, Tunnel0

So congratulations on building GRE P2P tunnel successfully :-)

#####################################

Now One Important thing you should always remember while building GRE tunnels is that - Tunnel Source and Destination should always be learned outside the tunnel and not from inside the tunnel....confused ?

Let me show it to you guys.

Right now Tunnel Source and Destinations (Which are Lo0 of R1/R3) are learned via ospf and inside the tunnel we are running EIGRP. But say if I enable EIGRP on Lo0 over R1 & R2 then by means of Basic routing fundamental, EIGRP will start advertising the Lo0 interfaces on both routers and soon router will update it's routing table and will install EIGRP routes for Lo0s. Because EIGRP has less AD compare to OSPF. Now we are learning Tunnel Source & Destination From Tunnel itself which leads us to chicken & egg problem. :-)

so lets first introduce this problem and see how we can fix it.

#####################################################

!
router eigrp 100
net 10.0.0.1 0.0.0.0
exit
!

#####################################################

R3

!
router eigrp 100
net 20.0.0.1 0.0.0.0
exit
!

As soon as we do this, we will start seeing following error messages on screen:

#####################################################

R3(config-router)#
*Mar 1 00:19:47.735: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive
routing
*Mar 1 00:19:48.735: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, change
d state to down
*Mar 1 00:19:48.875: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 13.13.13.1 (Tunnel
0) is down: interface down!

####################################################

soon after:

*Mar 1 00:20:49.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, change
d state to up
*Mar 1 00:20:54.131: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 13.13.13.1 (Tunnel
0) is up: new adjacency
*Mar 1 00:20:55.747: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive
routing
*Mar 1 00:20:56.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, change
d state to down
*Mar 1 00:20:56.851: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 13.13.13.1 (Tunnel
0) is down: interface down
######################################################

So basically what you will notice is tunnel is coming up and going down , up and down.....

Also you will notice that it's telling you about route recursion issue. Earlier route for tunnel source and destination was re-cursing to OSPF next hop but now it sees as EIGRP next hop pointing to tunnel itself...so it recognizes Chicken and Egg problem and bounce the tunnel assuming that there is a routing issue and bouncing tunnel may solve it :-)

To solve this problem there are many ways actually.

e.g. - Roll back to previous config, Filter tunnel source & destination IPs from the protocol running over tunnel using AD or ACL or Prefix-List etc.

Here is how I fixed it by filtering tunnel Source & Destination IPs using a distribute list:

!
access-list 100 deny ip ho 13.13.13.3 20.0.0.0 0.255.255.255 log
access-l 100 permit ip any any log
!
router eigrp 100
distribute-list 100 in Tunnel0
exit
!

######################################################

!
access-list 100 deny ip ho 13.13.13.1 10.0.0.0 0.255.255.255 log
access-l 100 permit ip any any log
!
router eigrp 100
distribute-list 100 in Tunnel0
exit
!

And sure enough this will solve the problem:

Just as a side note in case you are new with distribute list - In the ACL, the first portion defined after host keyword is next hop IP address from which we are assuming to receive update and second portion is actual network which we need to filter. In my example I filter the entire network though of that range but can go as much specific as you want.

Friday, August 20, 2010

OSPF Mock Lab - Another Challenge To Solve

So here I am with Another Challenge today. This time...on OSPF.

Last Week I was trying to test my OSPF skills, so I created a scenario myself and tried to put as much restriction I possibly can to make it tough for myself. So today I am sharing it with you in the form of another challenge and another chance to WIN some great CCIE notes from a Major CCIE vendor.

Here is the quick Diagram you need to focus on. Personally...it took me over an hour to fix it in my way...not so fast ofcourse , but from this I learned about one of gap in my preparation...lack of speed to configure complex scenarios. But on the other hand it's good to be little obnoxious some times :-)

Diagram:- Click on it for better view...just in case

***Requirements***

+ All OSPF routers should be able to reach each others loop-back addresses. For example R3 should be able to reach R6's loopback address.

***Restrictions***

List of things not allowed to use -

1. No GRE tunnel
2. No Redistribution
3. No Virtual Link
4. No PBR
5. No New Routing Protocol (e.g. RIP, EIGRP, OSPF, BGP)
6. No IPv6 Addressing

List of things allowed to use -

1. You are allowed to create a Single Static Route
Entry on one router among all.

Example - If you use one static route on R6, you cannot
                  use static route on any of other 5 routers.

***Loopback Interface Details***

R1:-> Lo0 - 11.11.11.11/24 (AREA 0)

R2:-> Lo0 - 22.22.22.22/24 (AREA 0)

R3:-> Lo0 - 33.33.33.33/24 (AREA 0)

R4:-> Lo0 - 44.44.44.44/24 (RIPv2)

             Lo1 - 144.144.144.144/24 (AREA 1)

R5:-> Lo0 - 55.55.55.55/24 (AREA 2)

             Lo1 - 155.155.155.155/24 (RIPv2)

R6:-> Lo0 - 66.66.66.66/24 (AREA 2)

OSPF RID on each Router should be : x.x.x.x -> x= Router Number

Note:-> You are allowed to create and use additional
                 Virtual/Logical interfaces if Required.

Here are the initial configs - Just have the rack ready for you :-)

R1

en
!
conf t
!
ho R1
!
int s0/0
ip add 123.123.123.1 255.255.255.0
en f
no frame inv
no arp fr
frame map ip 123.123.123.2 102 b
frame map ip 123.123.123.3 103 b
frame map ip 123.123.123.1 102
ip ospf net point-to-m
no sh
exit
!
int f0/0
ip add 14.14.14.1 255.255.255.0
no sh
exit
!
router ospf 1
router-id 1.1.1.1
net 123.123.123.1 0.0.0.0 a 0
net 14.14.14.1 0.0.0.0 a 1
exit
!
int lo0
ip add 11.11.11.11 255.255.255.0
ip ospf net point-to-p
ip ospf 1 a 0
exit
!
------------------------------------

R2

en
!
conf t
!
ho R2
!
int s0/0
ip add 123.123.123.2 255.255.255.0
en f
no frame inv
no arp fr
frame map ip 123.123.123.1 201 b
frame map ip 123.123.123.2 201
ip ospf net point-to-m
no sh
exit
!
int lo0
ip add 22.22.22.22 255.255.255.0
ip ospf net point-to-p
ip ospf 1 a 0
exit
!
router ospf 1
router-id 2.2.2.2
net 123.123.123.2 0.0.0.0 a 0
exit
!
-------------------------------------

R3

en
!
conf t
!
ho R3
!
int s0/0
ip add 123.123.123.3 255.255.255.0
en f
no frame inv
no arp fr
frame map ip 123.123.123.1 301 b
frame map ip 123.123.123.3 301
ip ospf net point-to-m
no sh
exit
!
int lo0
ip add 33.33.33.33 255.255.255.0
ip ospf net point-to-p
ip ospf 1 a 0
exit
!
router ospf 1
router-id 3.3.3.3
net 123.123.123.3 0.0.0.0 a 0
exit
!
--------------------------------------

R4

en
!
conf t
!
ho R4
!
int f0/0
ip add 14.14.14.4 255.255.255.0
no sh
exit
!
int f0/1
ip add 45.45.45.4 255.255.255.0
no sh
exit
!
router ospf 1
router-id 4.4.4.4
net 14.14.14.4 0.0.0.0 a 1
exit
!
int lo0
ip add 44.44.44.44 255.255.255.0
exit
!
int lo1
ip add 144.144.144.144 255.255.255.0
ip ospf 1 a 1
exit
!
router rip
v 2
no au
net 44.0.0.0
net 45.0.0.0
exit
!
-----------------------------------------

R5

en
!
conf t
!
ho R5
!
int f0/0
ip add 45.45.45.5 255.255.255.0
no sh
exit
!
int lo0
ip add 55.55.55.55 255.255.255.0
ip ospf net point-to-p
ip ospf 1 a 2
exit
!
int lo1
ip add 155.155.155.155 255.255.255.0
exit
!
int f0/1
ip add 56.56.56.5 255.255.255.0
no sh
!
router ospf 1
router-id 5.5.5.5
net 56.56.56.5 0.0.0.0 a 2
exit
!
router rip
net 45.0.0.0
net 155.155.0.0
v 2
no au
exit
!
--------------------------------------------

R6

en
!
conf t
!
ho R6
!
int f0/0
ip add 56.56.56.6 255.255.255.0
no sh
exit
!
int lo0
ip add 66.66.66.66 255.255.255.0
ip ospf 1 a 2
ip ospf net point-to-p
exit
!
router ospf 1
router-id 6.6.6.6
net 56.56.56.6 0.0.0.0 a 2
exit
!
----------------------------------------------

Tuesday, August 17, 2010

CCDA Passed - Scored 936

So I am happy to share that I passed my CCDA test yesterday. It was a great experience indeed. Specially when you find that exam was less focused on Technology side and much more focused on Design side where you have to think like a real world designer and how you fit all design pieces together to meet the customer requirements.

Rest of the story and details I posted at IEOC

http://ieoc.com/forums/p/12751/114850.aspx#114850

HTH...

Deepak Arora

Friday, August 13, 2010

RIP Challenge 1 - Solution

So welcome back everybody and lets talk about the solution of RIP challenge 1.

So back to the results first - if someone solved entire puzzle correctly ? And the big answer is "NO".

Some were actually closer and solved the first half of the puzzle but some how no one was able to solve the second half.

Anyways Did I tell you that there were actually two challenging tasks to handle in this puzzle? :-)

Although it looks like only one challenge but actually there were two of them. And If I am recalling it correctly thats what some Mock Lab vendors called as "Spot The ISSUEs" part of real/mock lab.

Yes...actually there was also a configuration twist between R2 & R3. Which I guess no body got correctly :-)

Without saying further lets get back to command line and solve the first requirement of the puzzle.

Lets start with taking a look if initial configuration are in place to begin with:

***Basic Configuration & Verification***

Now lets configure the basic RIPv2 on each router & verify our configuration:

So far everything looks good with basic configuration now.

Now lets talk about solution of first task which says - ***The RIP Updates from R1 over network 12.12.12.0/24 should not be send as "Multicast" or "Broadcast" packets.***

Hmmm. so speaking about RIPv2 we all know that it sends it's update packets out every interface it's configured on in every 30 second (+ - a jitter timer value in case you care about that :-) ). The destination address it uses is a well known multicast address of "224.0.0.9" ( Which belongs to Permanent Multicast Group range out of full range of Multicast addresses) and the port it uses is "UDP" port "520". So basically it relies on UDP for transport and does not have it's own protocol number.

just to add a little more info - A RIP update packet can carry at max 25 destinations information inside a single update packet.

Ok...So the task say we need to send updates to R2 but we shouldn't be sending it as "Multicast" or "Broadcast". Which pretty much leaves us with option of sending "Unicast" updates. By the way we can change RIPv2's "Multicast" update behavior into "Broadcast" with command "ip rip v2-broadcast" at interface level.

Now lets talk about UNICAST. To send RIPv2 updates as "UNICAST" lets see what options do we have apart from configuring "neighbor command" which essentially allow RIPv2 router to send it's updates as "UNICAST" but keep this in mind that you have to configure an extra command "passive interface {default}" in conjunction to make it work properly because without this second command although RIPv2 will send UNICAST updates to configured neighbors but will also keep sending MULTICAST updates too . But we are not allowed to use these commands here :-(

Now Lets navigate DOC CD to IOS 12.4 RIP command reference guide and see what information we can find there in this regard.

http://www.cisco.com/en/US/docs/ios/iproute_rip/command/reference/irr_rip.html

Hmmm...That's ugly...at-least in my opinion because even if we navigate to the command reference guide then press "ctrl+f" to find keyword "unicast" we can't find anything.

Okay...now DOC CD can't help us more then that. So basically if we are in lab then we can pretty much say that our Best Friend DOC CD has rejected to help us :-(
Worst nightmare during lab...

Now lets think little outside the box and think what we can do to make RIP sending "UNICAST" updates but without configuring "NEIGHBOR" command ?

How about "NAT" ?... Hmm...Good Idea

Because with help of NAT we can translate One Address into Another and the other side don't know about this translation of Addresses at our side....simply Unaware.

Lets put the Static NAT configuration and see if it's working for us.

So all we are doing here is translating an "inbound" Multicast packet to a "Unicast".
So what actually happening here is that when incoming RIPv2 update destined for address 224.0.0.9 hits R1 sent by R2, R1 translates it the 224.0.0.9 into 12.12.12.2

Now because STATIC NAT is bidirectional in nature, So after the first packet comes "IN", the next outbound packet will check the translation table and build off that.

Lets verify if everything we just configured is working correctly and as expected.

So looks like everything is working fine and we are done with Task 1 completely fine.

Now before moving to second "GOTCHA" lets verify the routing tables of all 3 routers.

so routing between R1 & R2 seems to be working fine. But somehow R2 and R3 can't exchange routing information. Any guesses ?

Lets verify even if RIP has been enabled properly on R3.

Everything looks OK here. Hmmm... lets check RIB aka Routing Information Base for RIPv2 which is configured here in our case here.

By the way there is a majority of people who thinks "RIB" and Router's "Routing Table" is one/same thing. But actually it's NOT.

Lets take a look at RIP's RIB

so again not much of information to help us with.

Lets check debugs and see if we can find something interesting in there.

Never mind...Here is the information you need to look upon to fix this issue.

http://deepakarora1984.blogspot.com/2009/01/does-ripv2-support-cidrsupernet.html

http://deepakarora1984.blogspot.com/2009/01/does-ripv2-support-cidrsupernet_25.html

http://deepakarora1984.blogspot.com/2009/01/reply-from-brian-mcghan-internetowk.html

So after reading all this, we know now that all we need is to perform following steps to fix this issue.

HTH...

Deepak Arora

Monday, August 9, 2010

RIP Challenge 1 - Solve The Puzzle

So here we are with another Challenge 1 for this week. I am sure that coming up with 2 exiting challenges is not a bad idea either. Anyways...Let's talk about RIP challenge as most of the networks guys (specially experienced ones) gonna say...."ehhh.....that should be simple" coz it's RIP. RIP...hmmm....RIP is very simple and straight forward kind of stuff...at least that's what most of people think.

Anyways let's me show the RIP diagram with all details and the requirement to full fill :-)

Requirements: My Favorite Part :-)
1. The RIP Updates from R1 over network 12.12.12.0/24
should not be send as "Multicast" or "Broadcast" packets.

2. Establish Full Connectivity/reachability among
loopback interfaces of all three routers.

Restrictions:
1. "neighbor" command shouldn't be used anywhere.
2. Redistribution is not allowed anywhere.
3. PBR, Static Routing, Default Routing, Tunnels are not allowed.

Best Of Luck...
Deepak Arora

Friday, August 6, 2010

Frame-Relay Challenge 2 - Solution

So welcome back and now it's time to reveal the solution for challenging Frame-Relay challenge.

Today I am little short of time so just going to show up the configuration, verification and troubleshooting part in sequence without much of explanation. Also I believe that the all three parts(configuration, verification & troubleshooting) are very much self explanatory and most of the people won't be having problem to understand it. But in-case someone has some doubt or want to discuss something in this regards, please feel free to drop me an email at - deepakarora.1984@gmail.com

and have a nice weekend :-)

Also no lucky winner so far with right configs (both challenges) :-(

Will post one RIP challenge on Monday morning as someone recently asked me for it --- Watch out for that on monday Manish :-)

Here we are with configs now :

****************
*CONFIGURATION*
****************

The only way to meet the first objective is using concept of PPP Over FR.

*************

*VERIFICATION*

*************

Here you are looking at magic of PPP Peer Neighbor Route Feature.

Lets verify Spoke To Spoke Reachability.

******************

TROUBLESHOOTING

******************

The config shown in notepad has to be done on R2, R3 & R4 in order to establish full reachability. The reason I showed notepad config here to share the fact that when we are supposed to do similar configs like this on multiple routers, in that case notepad can be very handy and can save a lot of time during configuration section of Lab.

HTH...
Deepak Arora