Eigrp neighbor command

[astoffel1]

                  -----R9

R8---SW<

                 -----R7 

So lets say I would like to to form static neighbors with eigrp in the above topology where R8 neighbors with R7 and R9(but R7 and R9 do not). In ospf its pretty straight forward, set the interface to PtM non broadcast. This is where I see a difference, I am force to put the neighbor command  on both side of the connection, when in OSPF you can put it on one side and adj will form. Is there a way to set an interface to no broadcast foe eigrp? I would like it so I would only need the neighbor command on R7 and R9 for scaling purposes. 

[acampbell]

Hi,

From what you are describing, I thinkk sounds
similar to a hub (Router 8) and spoke (Routers 7  & 9) design.
 
EIGRP hs a useful design called EIGRP-STUB.
Have a read at thi link -may be it will help

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/eigrpstb.html#wp1021949

Reagards
Alex

[paul driver]

Hello

Not sure this is possible unless you filter eigrp multicast between the two spokes , it looks like your network on  a broadcast medium and as such all rtrs are on the same subnet. so they will all receive the multicast queries.

Using the neighbor command negates multicast  in favor of unicast hence as you have stated this command is required on both side of the peering.

Remembering - When using uncast and hub/spoke like in your topology - traffic coming in /out the same interface will be negated by eigrp split horizon rule, so this also needs to be disabled to allow traffic to be advertised between the spokes.

res

Paul

[Peter Paluch]

Dear friends,

Please allow me to join.

As Paul has mentioned, as soon as you use the neighbor neighbor-ip interface command in EIGRP, you completely deactivate the use of EIGRP multicasts on that interface. Even if that interface received a multicasted EIGRP packet, it would drop it - and most certainly, it will never send a multicasted EIGRP packet itself. This behavior renders it impossible to do a scenario similar to OSPF where it is sufficient to define a neighbor just on one side of the connection. In other words, on a common network, either all EIGRP neighbors use multicast, or all EIGRP neighbors use the neighbor commands to each other. There is no alternative.

This being said, Paul has voiced an interesting - and workable - solution: Instead of limiting the visibility of EIGRP peers using predefined neighbor commands, limit the visibility using an ACL. If R7 and R9 were configured to drop all EIGRP packets except those sourced by R8, you would effectively have achieved what you requested. There would be some other issues to take care of, such as maintaining or replacing the next hop IP address by R8, the issue of direct R7<->R9 data flows (whether you want them allowed or denied), but the ACL appears to be truly a solution worth considering.

Paul: When using uncast and hub/spoke like in your topology - traffic coming in /out the same interface will be negated by eigrp split horizon rule, so this also needs to be disabled to allow traffic to be advertised between the spokes.

I am sure it's just me being picky for words, but to put it clearly: The split horizon rule does not affect data traffic. Split horizon affects the contents of routing updates, where a network must not be advertised out the interface used to reach that network. Deactivating split horizon will allow R8 to advertise networks received from R7 and R9 out the same interface, so that R9 will know about R7's networks and vice versa. Split horizon does not prevent a router from receiving a traffic and forwarding it out the same interface.

However, if this is truly required in the original poster's topology (that is, all traffic flows through R8), and the interfaces used are Ethernet interfaces, then additional configuration would be needed for this traffic hairpinning to work seamlessly.

Perhaps the original poster would explain why needs to deply this particular scenario and what is the means of interconnection between the routers.

Best regards,
Peter

[astoffel1]

I guess the main reason is to scale  adjacencies , lets say I have 100 routes and only wanted one to form neighbors between them. The problem I am facing is they all are connected via the same interface. I know in OSPF it is straight forward, the hub simply puts its interface facing the spokes in to Point-to-multi non-broadcast. When the spokes just add the hub with the neighbor command.

I will take a look at the hub and spoke reading acampbell posted and hopefully that is what I am looking for.

Thanks all for the quick responds 

[Peter Paluch]

Hi,

Alex's (acampbell's) suggestion about EIGRP Stub does not influence how adjacencies are formed. EIGRP Stub feature affects sending Queries and readvertising learned routes, but it does not has no impact on the number of router-to-router adjacencies. EIGRP Stub can be a very reasonable addition to your deployment but it is not the tool to achieve a hub-and-spoke style of adjacencies. I believe that Paul's suggestion is the easiest way to go.

Best regards,
Peter

[astoffel1]

Thanks Peter,

You were correct the stub doesn't limit adj, I will give Paul's suggestion a try. It does looks like eigrp might not be the best thing to use in this scenario might just go back to ospf PtM non broadcast.

[Peter Paluch]

Hi,

To be perfectly honest - and this is just a private opinion - no internal routing protocol was truly optimized for a deployment with a huge Layer2 domain and tens or thousands of routers being connected to it. RFC 2328 OSPF does not recognize anything like PtMP-NB. This network type - the most generic network type, by the way - is Cisco's "proprietary" invention (proprietary in the way of 'not being covered by any standard' but its inner workings are obvious). IS-IS and EIGRP are similar - they do not have any specific offloading support for such deployments. The need for any-to-any visibility and resulting adjacencies are, for the most part, well-meant: If you wanted any-to-any connectivity while running your IGP in an hub-and-spoke fashion, you are always making a leap of faith in that if two spokes can reach a hub then they can also reach themselves. As you surely know, this is not always the case, and it's one of reasons why IGPs like to create an adjacency between all routers that can mutually hear their Hellos.

It should be mentioned that if the number of routers on a common Layer2 segment is relatively small (tens of routers at most), the situation with full adjacencies is not that critical. However, as the number goes up over, say, 50 (a rule of thumb), the overhead with so many adjacencies and Hellos and stuff starts to be significant. However, this design is questionable in itself: Is it a sensible design choice to have so many routers on a common Layer2 segment? I would dare to express my uncertainty here.

Oh, by the way, Paul's approach with ACLs is in fact extremely simple. If you apply an identical ACL on all spoke routers allowing only EIGRP packets from the hub's IP, you do not need any more static configuration. This ACL - which is going to be identical on all spokes - will alone limit the EIGRP visibility into a hub-and-spoke model

Best regards,
Peter

[astoffel1]

Yes the design is questionable it was an example. It more of a cloud with Routers on the outside. It seems the more digging I do the more EIGRP does not fit for this topology  

[Peter Paluch]

Hello,

It seems the more digging I do the more EIGRP does not fit for this topology  

Perhaps so. But the message I wanted to leave in my previous post is that in fact, no routing protocol fits this topology, not even vanilla OSPF.

RIP, EIGRP, IS-IS - these have no concept of a point-to-multipoint network types. OSPF itself has no concept of point-to-multipoint non-broadcast network type - this specific network type was brought in by Cisco and it is not guaranteed that the same network type will be recognized by other vendors. You cannot generalize advantages or disadvantages of a protocol just based on specific vendor support. No doubt could EIGRP be modified to support a point-to-multipoint non-broadcast-like operation as it already has the prerequisities - the ability to configure static neighbor, the ability to accept dynamic neighbors (although this is only supported for OTP at the time but the code exists already), the ability to keep the original next hop address instead of hub asserting itself. It is just a matter of having this particular feature coded. So is EIGRP truly unfit for this scenario? With today's features, yes, but there is nothing fundamentally inherent to EIGRP that would prevent this from ever being supported. But you see, this boils down to what features a vendor has implemented, not what the protocol principially can or cannot do.

Currently, you may achieve what you need by using the ACL suggested by Paul. It is not exactly clean setup, and you accomplish the goal by other means than EIGRP's own toolset, but in the end, the result is the same and the difference or overhead is negligible.

Best regards,
Peter