L2TPv3 Inter Working - PPP To Frame-Relay

 

 

 

 

 

 

Incase Interworking Is Not Enabled On One Side

HTH...
Deepak Arora

Evil CCIE

 

Best CCNA Training In Market For Free - Till 31st December 2011

Yet again INE surprises their customer with Free Access to best CCNA Training in Industry till 31st December, 2011. Since the product is executed and compiled by Brian McGahan so you guys just don't worry at all about quality of material you gonna get. IMHO there will be no match. Here are the URLs :

http://www.ine.com/all-access-pass/training/playlist/ccna-routing-switching-exam-course/introduction-10021222.html

http://www.ine.com/flashcards/

More Details : http://blog.ine.com/2011/11/17/ccna-rs-exam-course-and-ccna-rs-video-flashcards-free-streaming-video-access/

HTH...

Deepak Arora

Evil CCIE

RIP Configuration Mock Lab - Final Version Completed

Today I proudly announce Completion of my RIP Mock Lab. It was part of an effort to bring free knowledge to people who can't afford to buy costly CCIE Lab preparation material. I started off this effort around 2 years back as an independent Technical blogger and will continue with that as long as possible.

But it's definitely not an effort against any CCIE Vendor. I truly respect them and their work. It's just my effort to bring something for people from developing countries like India where salaries don't match with Global Standards which makes life pretty tough in-case someone want to go for CCIE.

Hopefully every blog reader will like and Enjoy it. Here is the quick URL for download Lab - Tasks, Diagrams, GNS Topology for Windows & Initials.

http://www.4shared.com/file/QWaUSEhL/RIP_Mock_Lab_-_By_Deepak_Arora.html 

OR 

http://hotfile.com/dl/76776402/93ff2ff/RIP_Mock_Lab_-_By_Deepak_Arora.rar.html 
  
However for Solution Guide, I would request you spend little time to write an email to me (@ - deepakarora.1984@gmail.com) with your comments on RIP mock lab and about my blog and efforts (Good or bad).

All files are in secure pdf format with password as - deepakarora (same password for RAR file). Make sure you guys use Primo PDF Viewer software(http://www.primopdf.com/download.aspx)  to open pdf file to avoid any format issue which you may have with Adobe pdf Reader.

HTH...
Deepak Arora 

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

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

Does RIPv2 Support CIDR/SUPERNET Networks?...Continued

Ok Friends...it's time to continue the mysterious RIPv2's CIDR/Supernet support issue. It took me a while to solve this issue but more time I spent was to understand the logic behind it.

In the first look most of the people I know thought that RIPv2 will work fine in this scenario. They said: just configure RIPv2 than disable classful summarization behavior using "no auto-summary" key-word and that is pretty much enough to make this scenario work.

But I had already tried those things and I knew it's not gonna work in that way. So I though lets go through rfc for RIP and also I went through Routing TCP/IP Vol 1 by Jeff Doyle. But more I read more I got confused. RFC clearly says that RIP flavors do not support supernet ip addressing at all, on the other hand Jeff Doyle was mentioning that Classless and CIDR support is there in RIPv2.

Hmmmm.....pretty confusing :-( isn't it......

Anyways...I spoke one of my very close friend who is also preparing for CCIE Lab exam Mr. Mrityunjay Rai....he was also not sure why RIPv2 was not working but anyhow we discussed the issue and then decided to run PPP as encapsulation on WAN interfaces of both R1 and R2. As soon as we did that the RIP started working :-)

Wow..........We made it work :-)

But the next question in my mind was how RIP started working by just configuring PPP as encapsulation on WAN interfaces of both routers...I mean come on we all know that PPP is just a Layer 2 encapsulation and how come it can change the behavior of Layer 3 routing protocol's behavior.

So one journey ended and another begin...

So again I started working on the new issue about how PPP made RIPv2 work in this scenario.

I check the routing table prior and after setting encapsulation as ppp and finally I found the clue with help of my CCIE Security friend Mr. Deptanshu Singh CCIE#20679. Again the clue was our very old friend PPP peer neighbor route feature. Here is the routing table of R1 before and after changing encapsulation to PPP:

Before:

R1#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.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0


After:

R1#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

192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.2 is directly connected, Serial0/0
C 192.168.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0
R 192.168.2.0/23 [120/1] via 192.168.4.2, 00:00:09, Serial0/0


So if you look closely at the routing tables you will see that before setting encapsulation as ppp the WAN subnet 192.168.4.0 was appearing in routing table with /23 prefix as 192.168.4.0/23; but as soon as we changed the encapsulation to ppp, the ppp peer neighbor route feature installed a /32 prefix for the same WAN subnet and now it appears in routing table as 192.168.4.0/32. So with /32 prefix it is not a supernet network anymore and became subnetted network and we all know that RIPv2 does support subnetting and vlsm.

So finally we found the reason why ppp made this scenario working. But......still But? :-(

Still I wanted to figure out the difference between the statement of RIP rfc and statement of respected Mr. Jeff Doyle about CIDR/Classless support.

After working on while on this new mystery I conclude that rfc and Jeff's statements are right I mean both of them are right......Huhh.....don't worry.....You need not to panic :-)

The final conclusion is RIP routers won't exchange routes on WAN links which contain supernet ip addresses by default or in other words no supernet support. On the other hand if we are receiving a supernet route on a RIP router through some other routing protocol or may be even through static routing, in that case after redistributing that supernet route learned through other routing protocol into RIP routing process, RIP will forward this supernet route information to other routers running RIP in the same domain.

To test this thing I added one more router in our existing topology and run EIGRP on R3 and R1's S0/1 interface. After that I assigned a supernet ip address 172.16.100.1 on R3's F0/0. Later I saw that router R1 was able to see this supernet network. See below the routing table of R1 :

R1(config)#do 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

1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Serial0/1
192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.2 is directly connected, Serial0/0
D 172.0.0.0/10 [90/2195456] via 1.1.1.1, 00:00:41, Serial0/1
C 192.168.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0
R 192.168.2.0/23 [120/1] via 192.168.4.2, 00:00:03, Serial0/0

And after redistributing EIGRP 100 process into RIP Process; R2 was also able to see the 172.0.0.0/10 supernet route :-)

R1(config)#do sh run | be router rip
router rip
version 2
redistribute eigrp 100 metric 1
network 192.168.0.0
network 192.168.4.0
no auto-summary

R2(config)#do 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

1.0.0.0/30 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.1 is directly connected, Serial0/0
R 172.0.0.0/10 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
C 192.168.4.0/23 is directly connected, Serial0/0
R 192.168.0.0/23 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
C 192.168.2.0/23 is directly connected, FastEthernet0/0

I hope you enjoyed this topic... If you have any opinions or suggestions on this please feel free to drop an email to me @ deepakarora.1984@gmail.com

Best Regards,
Deepak Arora
CCIE#2XXXX...Oops that number is still missing

PPP Peer Neighbor Route Feature

Have you ever come across an issue where you have got two Cisco routers, connected through back to back serial cable and are configured with two different IP subnets over the WAN link.

Lets take an example:

R1 is connected to R2 through back to back DCE/DTE cable. On R1's Serial0/0 we have ip address configured as 1.1.1.1 255.255.255.252; on R2's Serial0/0 we have configured ip address as 2.2.2.2 255.255.255.252. Now what you think ....will R1 be able to ping R2 address ?

Weird Situation :-O

Lets fix it using PPP peer neighbor route feature...trust me...not many people know this cool ppp feature :-)

PPP peer neighbor route feature discover the peer router's ip address and install a /32 host route for that address. Below is the sample config.
----------------------------------------------------------------------------------------
R1(config)#do sh ip int brief
Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 unassigned YES unset administratively down down

Serial0/0 1.1.1.1 YES manual up up

-----------------------------------------------------------------------------------------
R2(config)#do sh ip int brief
Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 unassigned YES unset administratively down down

Serial0/0 2.2.2.2 YES manual up up

-------------------------------------------------------------------------------------------
R1(config)#do ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
-------------------------------------------------------------------------------------------
R1(config)#int s0/0
R1(config-if)#encapsulation ppp
R1(config-if)#exit
-------------------------------------------------------------------------------------------
R2(config)#int s0/0
R2(config-if)#encapsulation ppp
R2(config-if)#exit
-------------------------------------------------------------------------------------------
R1(config)#do ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/47/112 ms
--------------------------------------------------------------------------------------------
R1(config)#do 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

1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Serial0/0
--------------------------------------------------------------------------------------------

Enjoy...

Best Regards,
Deepak Arora