CCIE R&S EIGRP Insights

Unanswered Question
Feb 7th, 2008

I'm currently studying for my CCIE written, which I plan to take with in the next month. I would like to share some concerns or points, that I've been pondering over the last few days, about EIGRP neighbor relationships and DUAL computations. I've attached the diagram for the Lab I've been working on, to try to understand better these behaviors.

1) In a hub spoke topology - The spokes (R1 and R2) will not form a neighbor relationship through the hub, unless the neighbor command is entered at each point of the PVC's. Only then it seems the spokes will form a relationship.

-Is this because when entering the neighbor, the Hello messages become unicast, instead of multicast? How does it compensate for TTL?

-R3 is configured with point-to-point sub-interfaces, thus they break the broadcast domain; if configured as multipoint with broadcast enabled, will it still need the neighbor command, or will it forward the broadcast and allow the spokes to become neighbors?

- Will it work if authentication is configured?

2) Bandwidth - how to calculate the correct BW and percentage in each subinterface, and the ip bandwidth-percent.

- On Frame Relay point-to-point subinterfaces BW should reflect the CIR of the PVC assigned to the subinterface. If you only have access to the DTE device and are unaware of the CIR, is there a way to show what is the CIR (Clock Rate) assigned to that PVC?

-On Frame Relay Multipoint in a hub spoke topology, BW should be calculated by ( Lowest CIR * # of PVC ). If the BW calculated exceeds the CIR of the Hub, BW should be calculated by ( Hub CIR / # of PVC ); and the (ip bandwidth-percent eigrp) command should be used to ensure 50% cap link utilization of EIGRP?

3) EIGRP Updates:

- In a Frame Relay, even if the PVC is in active or deleted, if the interface has an ip address assigned and the command no shut has been issued, the interface will show as it is in the up and up status when you issue the command #show ip int brief.

- EIGRP will start advertising those networks automatically, even if the the remote end is not active. How can this be avoided? End-to-end keepalive configuration?

Example: In the diagram if R3 is down, R1 will still advertise network 10.0.2.0, and R2 will still advertise 10.0.3.0, even though R3 is down.

All comments and insights are welcomed!

Attachment: 
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
swmorris Tue, 02/26/2008 - 18:59

1. Spokes aren't supposed to form peers because of the TTL issue. If they do, you may have "magic reachability" from discovered PVCs.

- unicast won't change this. Hello messages are still multicast, routing updates are unicast.

- point-to-point won't change this either. It'll change some settings in the EIGRP negotiation that may lead to weird results though in terms of looking at active queries.

- Authentication is part of the packet, so shouldn't have any separate influence (e.g. not changing above observations one way or the other)

2. bandwidth is based off of what the interface shows. (show interface | include is up|BW)

EIGRP uses up to 50% of that by default. So whatever change you make with the "bandwidth" or "ip bandwidth-percent eigrp" commands will influence that!

- The relationship to CIR or not is nothing constant. I'd first ask you exactly how much bandwidth using a hybrid link-state protocol you are really tying up! Then I'd say you need to consider using EIGRP Stub configuration.

- Again, these calculations are not the result of a quick/easy formula. If this is a CCIE lab type question, the lab exam should give you enough information to make a choice. If not asked, leave it alone!

3. If it's deleted it'll show up/up? I suppose it depends on whether we're talking about physical interfaces or subinterfaces. Subinterfaces will not show up/up if all PVCs tagged to it are inactive or deleted.

- End-to-end keepalive would seem the most sane route here. Or routes to null0 statically set.

HTH,

Scott

[email protected]

jorgenolla Wed, 02/27/2008 - 09:25

Hi Scott,

1) Spokes are able to form an adjacency in an EIGRP topology. Here is the configuration that I've worked on to have the spokes form adjacencies:

Hub Router:

interface Serial1/0

ip address 10.0.2.2 255.255.255.0

encapsulation frame-relay

serial restart-delay 0

frame-relay map ip 10.0.2.3 302 broadcast

frame-relay map ip 10.0.2.1 301 broadcast

end

router eigrp 100

network 10.0.2.0 0.0.0.255

no auto-summary

neighbor 10.0.2.3 Serial1/0

neighbor 10.0.2.1 Serial1/0

Spoke Router 1:

interface Serial0/0

ip address 10.0.2.1 255.255.255.0

encapsulation frame-relay

frame-relay map ip 10.0.2.3 103

frame-relay map ip 10.0.2.2 103 broadcast

no frame-relay inverse-arp IP 102

router eigrp 100

network 10.0.2.0 0.0.0.255

no auto-summary

neighbor 10.0.2.3 Serial0/0

neighbor 10.0.2.2 Serial0/0

Spoke Router 2:

interface Serial0/0

ip address 10.0.2.3 255.255.255.0

encapsulation frame-relay

frame-relay map ip 10.0.2.2 203

frame-relay map ip 10.0.2.1 203

no frame-relay inverse-arp IP 201

router eigrp 100

network 10.0.2.0 0.0.0.255

no auto-summary

neighbor 10.0.2.1 Serial0/0

neighbor 10.0.2.2 Serial0/0

As you can see I ensured that the circuit between R1 and R2 will not inarp for each other. The adjacencies stay up, and both spoke routers are receiving the hello packets from each other through the hub. I'm working on the authentication; I'm pretty sure it will work.

Here is R1 debug eigrp packets output, that shoe the spokes receiving the hellos:

R1#

EIGRP: Received HELLO on Serial0/0 nbr 10.0.2.2

AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

EIGRP: Received HELLO on Serial0/0 nbr 10.0.2.3

AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Sending HELLO on Serial0/0 nbr 10.0.2.3

3) If it's deleted it'll show up/up?

Yes I was talking about the physical interface. I understand that if sub-interfaces are used the protocol will come down if the DLCI is down.

Thanks again Scott

Actions

This Discussion