How to control EIGRP traffic in hub-spoke

[yangfrank]

Dear All

I run into a issue of eigrp traffic control in hub-spoke environment. Please see the picture in attachment. R1 headquarter office. and R3 and R4 are remote office. R1 connect R3 and R4 through MPLS vpn- R2. All of routers run eigrp. I want R1 can reach all of routers R3 and R4, but R3 and R4 cannot reach each other. Do you have any suggestion ? I think ACL is a way, but it is a not good one. Do you think so ? Note the link are not frame relay, it is Ethernet cable. Thank you

FRANK

[nspasov]

Can you:

- Post EIGRP and Interface configs from your routers

- Post "show ip route" from all routers

Thank you for rating helpful posts!

[yangfrank]

Thanks for your reply. This is to desire the topology, and I have not have the detail for it yet

[nspasov]

Ok so can you confirm: If R3 wants to talk to R4 the communication must flow through R1? Meaning R1 is the one that is advertising R3's routes to R4 and vice versa?

[yangfrank]

R2 is MPLS cloud, which might have some routers inside. R1, R2, R3 have similar configuration for eigrp. If we do not use ACL, The three routers can reach other. R3 and R4 also can reach other, but this is not what we want. What we want is R3 and R4 can reach R1 and vice verse, but we do not want R3 and R4 can reach each other no matter through R2 or R1. R1 is headquarter and R3 and R4 are remote branch office network. we do not want branch office talk to each other. 

I do not know if we can solve it using eigrp stub. If layer 2 link is frame relay, it should be easy to solve it. but it is ethernet instead of frame relay

[houtan haddadlarijani]

Hi,

can u use some eigrp debug command on R1 to capture some traffic from eigrp neighbours? based on debug logs its easier to find a solution.

HTH

Houtan

[yangfrank]

After I debug it, i can use some message of eigrp to block it with ACL. This is one way to do that. 

Maybe this is only way to do that, I guess

[Jose Jara]

Hi,

The MPLS cloud is providing L3 VPN Service and EIGRP is the CE-PE protocol ? If this is the case, then I see some options to avoid the spoke-to-spoke communication:

1. If you have control over the MPLS PE´s or you may request to the provider to do this:

SPOKE-PEs

- Export the Spoke Prefixes with RT SPOKES

- Import the Hub Prefixes with RT HUB

HUB- PE

- Export the Hub Prefixes with RT HUB

- Import the Spoke Prefixes with RT SPOKES

Advertise the default route from the Hub to force the traffic from the Spokes to go through the Hub

2. Put the Spokes in different VRFs. Then, in the Hub, use Multi-VRF and do the leaking between VRFs.

3. Use EIGRP over the Top, using the Headquarters as Route Reflector. Remember to disable split horizon and also do next-hop-self that is the default.

4. Use DMVPN Phase-1.

If the MPLS cloud is providing L2 VPN Service, such as VPLS, then I see this option:

1. Run EIGRP between spokes and the Hub, no directly between the Spokes. Disable split horizon in the Hub and maintain the next-hop-self in the Hub.

Hope this helps,

Jose.

[yangfrank]

Hi Jose

Thank you so much. You gave a excellent explanation. Now I still have questions on it.

First,  "3. Use EIGRP over the Top, using the Headquarters as Route Reflector. Remember to disable split horizon and also do next-hop-self that is the default."  The "Headquarters as Reflector" and "next-hop-self" mentioned is in PE or CE ? If these are in CE, then the CE should use BGP, right ? 

Second, from the perspective of configuration on customer site, the difference between MPLS Layer 2 and Layer3 mentioned by you is that the customer need to configure Layer 3 on the Layer 2 if the customer is provided with Layer 2 ?

Third, the PE usually is placed in ISP side. sometimes PE also could be in customer site, right ? which means customer can configure their own MPLS on their side. Thank you

[Jose Jara]

Hello Yangfrank,

EIGRP Over the Top is a feature in some IOS releases that combines EIGRP plus Lisp and the use case for it is to have the control of the routing, where there´s a third party managing part of your network: in an MPLS L3VPN environment, for example. Route-Reflector concept is associated with BGP, but here is a different thing but with the same idea in EIGRP: a device that is going to listen and setup unicast EIGRP sessions with clients. More information about EIGRP over the Top here:

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ip-routing/whitepaper_C11-730404.html

- MPLS Layer 2, AtoM: the provider does not participate in the routing. It will encapsulate ethernet frames or any other layer 2 encapsulation such as PPP, Frame-Relay, HDLC... in MPLS. It is called pseudowires and they are point to point.

- MPLS Layer 2, VPLS: the provider does not participate in the routing. It will provide a Layer 2 ethernet service, emulating a LAN. It is a full-mesh of pseudowires and the topology is multipoint.

- MPLS Layer 3: the provider does participate in the routing. It will receive and advertise the customer routes plus some management addressing for them (loopbacks, possibly WANs). Depending of the provider, it will allow you to setup a routing protocol with them. The most typical are BGP, RIPv2 or static routes.

Finally, the CPE (Customer Premises Equipment) is the device installed in customer´s site. It will be managed by the provider, or unmanaged  from the provider´s perspective (managed by the customer or third party). Typically is like that, but also there can be exceptions where customer´s equipment is co-located in a Point of Presence (rarely). The PE (Provider Edge), is managed and maintained by the provider and will be located in a Point of Presence of the Provider or co-located using housing of others...but anyway, it is responsibility of the provider. The PE will speak MPLS internally with PEs, or Ps, which are internal devices under provider responsibility.

There can be situations where the PE will speak MPLS (Carrier Supporting Carrier) with customers, but this is quite unusual and the majority of the providers they offer the services as I described in their portfolio.

Hope this helps,

Jose.

[paul driver]

Hello

I take from your perspective you only have access to the eigrp process and NOT the PE routers and MPLS vpns which are managed by the SP.

So in reality I guess you can only administer the eigrp routing between sites? - So to keep things simple- you can negate  the routes between R3/R4 the way I have suggestion in my previous post without the SP involvement

res

Paul

[Jose Jara · Accepted solution]

Hello,

I assumed wrongly that the branches would need to talk to each other via the Hub, not directly. Sorry for the confusion.

It is easy to accomplish this with EIGRP filtering as Paul suggests. However, this would work as long as the Hub is not advertising the default route/supernet/or something less specific that includes the prefixes of the branches. In that case, the traffic will go directly between the branches through the PE as this is going to get the specific prefixes from the branches.

Another solution to have complete control of the routing is to use an overlay, for example, DMVPN or EIGRP over the Top as mentioned, assuming the provider is offering to you L3 VPN Service.

Hope this helps,

Jose.

[paul driver · Accepted solution]

Hello Jose

FYI -The solution I provided is based on a hub and spoke setup with the spokes having no eigrp adjacency between each other and each spoke having a different address space towards the hub. ( point-to-point)

However if the hub share the sames address space  or interface ( ie multipoint) another solution would be negate the split horizon rule I guess would be enabled so the hub doesn't advertise R3-R4 routes between each other.

Apologies for the confusion

res

Paul

[yangfrank]

Hi Jose and Paul

It is excellent ideas and explanation. Thank you so much !

yangfrank

[paul driver]

Hello

The easiest way to do this is would be to:

1) Redistribute R3/R4 routes into eigrp

2) Apply the same eigrp router-id to R3/R4)

This way each router (R3/R4) will reject each other external routes as they see the there own Id in the eigrp updates.

Example: R3/R4

access-list 1 permit x.0.0.0
access-list 1 permit xx.0.0.0
access-list 1 permit xxx.0.0.0

route-map R3-4 permit 10
match ip address 1

router eigrp xx
redistribute connected route-map R3-4
eigrp router-id 34.34.34.34

Note: when you change the eigrp router id, the adjacency will be reset
 

res

Paul