Re: EIGRP as PE-CE RP, design question

Imran Moulvi · ‎09-21-2012

Hi,

I am looking for some guidance related to the EIGRP Site of Origin.

We are setting up a network for an enterprise(acting as a service provider).

The Topology looks like below-

CE1

/ \

PE1----PE2 We have control over routers PE1-PE4 but not the CE routers. EIGRP used as CE-PE routing protocol.

| \/ |

| /\ |

PE3----PE4

\ /

CE2

CE1 and CE2 are two sites for a single customer VPN. What I am seeing is that PE1 is getting the routes for CE2 advertised back from CE1 and that is causing a loop. I understand that we can use Site of Origin to fix this problem. We dont want to use any distribute lists or other conventional filtering.

Does anyone have an expeience on this and can advise as to what would be the best way to set the SOO, which interfaces, what values etc.

Much appreciate any inputs on this.

Thank You.

Reza Sharifi · ‎09-21-2012

Hi,

Here is document with examples for using EIGRP and SOO.

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_mvesoo.html

HTH

Imran Moulvi · ‎09-23-2012

Thank You Reza for the link.

Peter Paluch · ‎09-23-2012

Hello Imran,

As Reza pointed out, there are good documents already on the Cisco website that do a great job in describing how the SoO for EIGRP works and how it should be configured. Please note that the SoO functionality for EIGRP actually encompasses several features and it's behavior is not entirely trivial. This is my attempt to summarize what's going on.

First of all, the SoO is expressed as a TLV (Type-Length-Value) tag in EIGRP that is added to individual advertised routes. In BGP, the SoO is expressed as an extended community attribute. Assuming we're discussing pure EIGRP PE-CE scenario in MPLS L3 VPNs, the value of the SoO is first determined by the ip vrf sitemap command on the PE interface towards the CE but the first time this value actually appears somewhere is in the moment of EIGRP-to-BGP redistribution when the redistributed routes in BGP will be equipped with the appropriate SoO community attribute. On the far PE, the SoO community is rewritten into SoO TLV during BGP-to-EIGRP redstribution.

With respect to EIGRP operation:

The SoO TLV will be assigned to an EIGRP route by redistributing the route from BGP if the BGP route already has the SoO extended community set. The value of the SoO community will be copied to the EIGRP SoO TLV. The ip vrf sitemap command does not directly influence the SoO TLVs of EIGRP-learned routes, i.e. routes received via EIGRP on an interface with ip vrf sitemap configured will not be assigned the SoO TLV. The EIGRP topology table will store these networks without any SoO TLVs. However, during redistribution of these routes from EIGRP to BGP, the appropriate SoO extended BGP community will be added to redistributed routes in the BGP database.
EIGRP will not advertise a route tagged with SoO TLV out an interface if the SoO value of the route matches the SoO value set by the ip vrf sitemap command configured on that interface
- This behavior prevents multiple PEs towards the same site to create an EIGRP--->BGP between PEs--->EIGRP routing loop. Typically, this automatic filtering occurs on PE routers
EIGRP will ignore a received update on an interface about a route tagged with SoO TLV if the SoO value of the route matches the SoO value set by the ip vrf sitemap command configured on that interface
- This behavior prevents a routing loop created by a site advertising a prefix via the MPLS backbone to another site (through the EIGRP-to-BGP-to-EIGRP redistribution) and the another site advertising the same prefix back to the original site via a separate, independent backdoor link. Typically, this automatic filtering occurs on CE routers that terminate the backdoor link.

With respect to BGP operation:

The SoO community will be assigned to a BGP route by redistributing the route from EIGRP. The value of the SoO community will be set according to the ip vrf sitemap command on the next hop interface of these EIGRP-learned routes, assuming these routes do not have any SoO TLVs yet. If the EIGRP route already has a SoO TLV, this TLV will be used instead of the ip vrf sitemap when creating the corresponding BGP SoO community.
During EIGRP-to-BGP redistribution, BGP will also add additional extended communities that identify the type of the original EIGRP route, the EIGRP process number it came from, its state, its metric components (bandwidth, delay, reliability, load, MTU), and a cost community describing its current total EIGRP metric
When BGP performs its bestpath algorithm, thanks to the pre-bestpath point of insertion (POI) of the cost community, the EIGRP total metric carried by this community will be evaluated before any other BGP bestpath step
During BGP-to-EIGRP redistribution, EIGRP will reconstitute the original metric and type from the extended communities if the AS number of the remote EIGRP process is identical to this EIGRP process number. As a result, if both sites run the same EIGRP process number, the routes appear as internal, not as external, even though they are redistributed from BGP into EIGRP.

These facts are derived from the following documents:

http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_eigrp/configuration/guide/ire_mpls_vpn_xe.html

http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_bgp/configuration/guide/irg_cost_comm_xe.html

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/fteipece.html

Regarding the SoO attribute itself, I had a marvellous discussion about this with Mohamed Sobair and Luc de Ghein here:

https://supportforums.cisco.com/message/3536081

Please feel welcome to ask further!

Best regards,

Peter

Imran Moulvi · ‎09-23-2012

Excellent explaination Peter. Thank You.

Although I am still struggling to figure out what SOO values I should set at the PE1 and PE2 to prevent a loop at the PE3 and PE4 and vice versa.

I did some testing in the lab, please see the attachment at the below link. Not sure if I am missing something here. If you can throw some ideas, I'd really appreciate that.

https://docs.google.com/open?id=0B8al1Rz1KBI2NHlaMHpNT05Td2s

Thanks again.

Peter Paluch · ‎09-24-2012

Hello Imran,

I have went over your configuration and although I do not have experiences with NX-OS, the configuration seems to be correct.

The Nexus 7000 MPLS Configuration Guide at

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/mpls/configuration/guide/mp_vpn_l3vpn.html#wp1057302

says:

For Cisco NX-OS releases prior to 5.2(5), EIGRP site of origin requires an MPLS license and enablement of the MPLS Layer 3 VPN feature. Beginning with Cisco NX-OS Release 5.2(5), the EIGRP site of origin feature does not require an MPLS license.

Could this perhaps be your case?

Best regards,

Peter

Imran Moulvi · ‎09-24-2012

Hi Peter,

Its not a licencing issue.

What I am wondering is if the SOO rules still apply if the route is learnt as a result of the EIGRP QUERY/REPLY process, which is my case here. The PE router in question is learning the route after it sends out a QUERY and recieves the route in REPLY from CE. I dont see this documented anywhere though.

Peter Paluch · ‎09-25-2012

Hello Imran,

I tested this on IOS-based routers, and I can confirm that the SoO applies also to received EIGRP REPLY packets.

Here, I have a directly attached network 192.0.2.0/24 on R4 where EIGRP is running in a VRF. The R4's interface towards a different router R3 is configured with ip vrf sitemap command that associates the interface with the SoO of 1:1. When I disconnect the 192.0.2.0/24 from R4, its sends queries to R3. R3 is configured to advertise the same network 192.0.2.0/24 with the SoO TLV aready set to 1:1, and the R4 drops it. Please observe for yourself:

R4#show run int s1/0
Building configuration...
Current configuration : 169 bytes
!
interface Serial1/0
 description => Interface towards R3 <=
 ip vrf forwarding V1
 ip vrf sitemap SoO
 ip address 10.0.34.4 255.255.255.0
 serial restart-delay 0
end
R4#show ip route vrf V1
Routing Table: V1
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
     10.0.0.0/24 is subnetted, 2 subnets
D       10.0.23.0 [90/2681856] via 10.0.34.3, 00:15:14, Serial1/0
C       10.0.34.0 is directly connected, Serial1/0
C    192.0.2.0/24 is directly connected, Loopback0
R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int lo0
R4(config-if)#shut
R4(config-if)#
*Mar  1 00:41:11.839: IP-EIGRP(V1:1): 192.0.2.0/24 - not in IP routing table
*Mar  1 00:41:11.839: IP-EIGRP(V1:1): Int 192.0.2.0/24 metric 4294967295 - 0 4294967295
*Mar  1 00:41:11.859: IP-EIGRP(V1:1): Processing incoming REPLY packet
*Mar  1 00:41:11.863: IP-EIGRP(V1:1): Int 192.0.2.0/24 M 2809856 - 1657856 1152000 SM 2297856 - 1657856 640000- SoO Loop
*Mar  1 00:41:11.915: IP-EIGRP(V1:1): Processing incoming UPDATE packet
*Mar  1 00:41:11.915: IP-EIGRP(V1:1): Int 192.0.2.0/24 M 2809856 - 1657856 1152000 SM 2297856 - 1657856 640000- SoO Loop

So it seems that the SoO protects also the Query/Reply process.

However, can you specify in more detail the routing loop or the redistribution loop your are trying to solve? Perhaps we're approaching the problem from a wrong end. Can you in detail explain what redistribution loop or suboptimal routing you have observed? Thank you!

Best regards,

Peter