EIGRP in Framerelay with Split Horizon

Unanswered Question
Aug 17th, 2009

Hi experts,

I am trying to configure EIGRP in FRAME RELAY. I have 3 Routers (R1, R2, R3) where

R1 is spoke - 192.168.1.1

R2 is hub - 192.168.1.2

R3 is hub - 192.168.1.3

EIGRP Split Horizon is enabled in R1. I have configured EIGRP in all the routers. As we know R1 will not advertise R2 routes to R3 and vice versa due to split Horizon. I should not disable Split horizon. As a workaround, I have configured neighbour statement in all the routers as follows:

R1#show running-config | section eigrp

router eigrp 420

network 192.168.1.1 0.0.0.0

no auto-summary

neighbor 192.168.1.3 Serial0/0

neighbor 192.168.1.2 Serial0/0

R2#show running-config | section eigrp

router eigrp 420

network 2.2.2.2 0.0.0.0

network 192.168.1.2 0.0.0.0

no auto-summary

neighbor 192.168.1.3 Serial0/0

neighbor 192.168.1.1 Serial0/0

R3#show running-config | section eigrp

router eigrp 420

network 3.3.3.3 0.0.0.0

network 192.168.1.3 0.0.0.0

no auto-summary

neighbor 192.168.1.2 Serial1/0

neighbor 192.168.1.1 Serial1/0

It is working fine. But what is eating my head is, my understanding about NEIGHBOR command is it UNICAST instead of MULICAST to find the neighbors. It finds the neighbours statically.

If so, I know the TTL value of multicast packet 224.0.0.10 (EIGRP) is 1. If it uses NEIGHBOR command WHAT IS THE TTL VALUE? How it is able to form neighbor with a Router that is one Hop away (R2 forming neighbor with R3 crossing R1)

Hope I managed to express the doubt I have. Please help me

sairam

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Giuseppe Larosa Mon, 08/17/2009 - 07:02

Hello Sairam,

>> If so, I know the TTL value of multicast packet 224.0.0.10 (EIGRP) is 1. If it uses NEIGHBOR command WHAT IS THE TTL VALUE? How it is able to form neighbor with a Router that is one Hop away (R2 forming neighbor with R3 crossing R1)

It is one hop away from the Frame-relay point of view but they are in the same IP subnet.

I guess you have additional frame-relay map commands that for example on R3 say neigh 192.168.1.2 is reachable via DLCI x that is the same DLCI to reach router R1.

I mean you are not relying on inverse ARP that should give you only the device at the other end of the PVC.

the neighbor ip address is resolved with static FR mapping and this allows to send the EIGRP hello packet.

Or you have a full mesh and inverse ARP is giving you a direct DLCI to R2 from R3?

do sh frame-relay map to check this.

This is probably the likely reason.

Hope to help

Giuseppe

snarayanaraju Mon, 08/17/2009 - 07:31

Hi Giuseppe,

Thanks and Happy to see you online after some gap. Nice moments

Yes, you correctly identified. I am using "frame-relay map ip" command in both R2 & R3 because to have communication of R2 & R3 interface.

But I am surprised how it relates to TTL value and subnet. Can you give your few moments to explain this .

Also I tried to capture the packets using wireshark. Below is my observation

I read that Time To Live value of EIGRP is 1. This makes sure HELLO and UPDATE packets do not leak to other router.

But when i caputed the traffic using wireshark I see as below

Time to live: 2

"Time to Live" > 1 for a packet sent to the local network control Block

Had you noticed it before or I misunderstood this?

Thankfully looking for your feedback

sairam

Giuseppe Larosa Mon, 08/17/2009 - 07:46

Hello Sairam,

I took a two weeks vacation thanks for your kind remarks.

may I put a question?

Are you using real routers or GNS3 / dynamips ?

I ask this because you say you are able to capture traffic on FR serial interface with wireshark:

are you using embedded packet capture or is an emulated environment

In any case this TTL=2 could explain how the packet can reach R2 from R3 via R1.

R1 can receive the packet decrease TTL and resend to R2 on the other DLCI.

if TTL=1 the packet cannot make this travel it cannot exit from hub R1.

Hope to help

Giuseppe

snarayanaraju Mon, 08/17/2009 - 08:36

Hi Giuseppe,

I am using GNS3. Moreover for testing I connected 2 routers directly and captured the packet to know the TTL value.

Is the TTL differ in the real routers?

How it is related to the actual case I explained in the initial post

sairam

Giuseppe Larosa Mon, 08/17/2009 - 09:25

Hello Sairam,

it is not related to the issue sorry it it was just curiosity.

However, the answer should be TTL=2 because no direct DLCI between R3 and R2 exists.

The interesting point would be how the router decided to increase TTL. (if there is a search with increasing TTL like traceroute until an answer is received from other side)

I think that when I tried this I was not able to have it working but I had also one DLCI between the FR switch and one of the routers that is slightly different and no neighbor command.

Hope to help

Giuseppe

Peter Paluch Mon, 08/17/2009 - 11:55

Hello Giuseppe and Sairam,

Giuseppe, welcome back from your vacation! I'm glad you're back with us again.

I have just tested the EIGRP TTL. It seems that regardless of running the EIGRP using multicasts or having the neighbors defined statically, the TTL of all EIGRP packets (Hello, Update, Query, Reply, Ack) is set to 2. So the router did not actually increase its TTL. It rather seems that the value is hard-coded in the IOS.

By the way, I have done further experiments with OSPF and RIPv2. The RIPv2 also uses the TTL 2 with or without statically defined neighbors. The OSPF behaves differently - it uses the TTL 1 in all its packets, with or without statically defined neighbors.

I am not quite sure what is the logic behind this - but this is how the Cisco routers do it.

Best regards,

Peter

snarayanaraju Mon, 08/17/2009 - 22:03

Hi Peter & Giuseppe,

Thanks for continuing this post.

But till a day before I was in impression that TTL value of all ip routing protocols is 1 to avoid crossing the router. Even Cisco documents and Cisco press books says TTL = 1.

Accidently while checking another parameter I noticed this Value as 2.

Any advice please

Peter Paluch Mon, 08/17/2009 - 22:15

Hello Sairam,

Using TTL=1 is a fine method of preventing routing updates from crossing a router. But also the multicast addresses used by routing protcols are selected from the link-local multicast scope. A router would never forward a packet going to 224.0.0.x address to another segment.

Regarding the discrepancy between the implementation and what is written in books - I am confused myself. But we cannot deny what we see in Wireshark - indeed, the distance-vector routing protocols use the TTL of 2. Any Cisco engineer to shed some light on this?

Best regards,

Peter

Actions

This Discussion