EIGRP SOO Question
Hello All,
I am going through the MPLS section of the workbook and am at the EIGRP SOO task. My EIGRP configuration is stable from PE-CE but after reading through the solution it seems unclear to me. Basically how I understand this is that if you have the same SOO the route should be discarded. I tested this by configuring the same SOO value and the route is still accepted. Therefore maybe my understanding isn't clear. Below is the output from R6. As you can see both networks have the same SOO configured.
(For this task R7 and R8 have a backdoor link through Gig1.78 as well as an EIGRP connection through their VPN interfaces (Gig1.67))
R6#show bgp vpnv4 unicast vrf VPN_A 155.1.67.7
BGP routing table entry for 100:1:155.1.67.0/24, version 23
Paths: (1 available, best #1, table VPN_A)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (150.1.6.6)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Extended Community: SoO:100:16 RT:100:1 Cost:pre-bestpath:128:281600
0x8800:32768:0 0x8801:100:25600 0x8802:65280:256000 0x8803:65281:1500
0x8806:0:2516664898
mpls labels in/out 21/nolabel(VPN_A)
R6#show bgp vpnv4 unicast vrf VPN_A 155.1.67.0
BGP routing table entry for 100:1:155.1.67.0/24, version 23
Paths: (1 available, best #1, table VPN_A)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (150.1.6.6)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
Extended Community: SoO:100:16 RT:100:1 Cost:pre-bestpath:128:281600
0x8800:32768:0 0x8801:100:25600 0x8802:65280:256000 0x8803:65281:1500
0x8806:0:2516664898
mpls labels in/out 21/nolabel(VPN_A)
R6#show bgp vpnv4 unicast vrf VPN_A 155.1.58.0
BGP routing table entry for 100:1:155.1.58.0/24, version 80
Paths: (1 available, best #1, table VPN_A)
Not advertised to any peer
Refresh Epoch 1
Local
150.1.5.5 (metric 21) from 150.1.4.4 (150.1.4.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: SoO:100:16 RT:100:1 Cost:pre-bestpath:128:281600
0x8800:32768:0 0x8801:100:25600 0x8802:65280:256000 0x8803:65281:1500
0x8806:0:2886731013
Originator: 150.1.5.5, Cluster list: 150.1.4.4
mpls labels in/out nolabel/20
R6#
Now when I go to look at R7's routing table I shouldn't see the 155.1.58.8 route in the routing table. But I do.
R7#show ip route 155.1.58.8
Routing entry for 155.1.58.0/24
Known via "eigrp 100", distance 90, metric 2841600, type internal
Redistributing via eigrp 100
Last update from 155.1.78.8 on Ethernet0/0.78, 00:11:44 ago
Routing Descriptor Blocks:
* 155.1.78.8, from 155.1.78.8, 00:11:44 ago, via Ethernet0/0.78
Route metric is 2841600, traffic share count is 1
Total delay is 101000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R7#show ip route eigrp
Codes: L - local, 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, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
150.1.0.0/32 is subnetted, 4 subnets
D 150.1.8.8 [90/2944000] via 155.1.78.8, 00:11:49, Ethernet0/0.78
D EX 150.1.55.55 [170/2560025856] via 155.1.67.6, 00:11:49, Ethernet0/0.67
D EX 150.1.66.66 [170/2560025856] via 155.1.67.6, 00:11:49, Ethernet0/0.67
155.1.0.0/16 is variably subnetted, 13 subnets, 2 masks
D 155.1.8.0/24 [90/2841600] via 155.1.78.8, 00:11:49, Ethernet0/0.78
D 155.1.58.0/24 [90/2841600] via 155.1.78.8, 00:11:49, Ethernet0/0.78
D 155.1.108.0/24 [90/2841600] via 155.1.78.8, 00:11:49, Ethernet0/0.78
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D 172.16.8.0/24 [90/2944000] via 155.1.78.8, 00:11:49, Ethernet0/0.78
D EX 192.168.6.0/24 [170/2562585856] via 155.1.78.8, 00:11:49, Ethernet0/0.78
D EX 192.168.7.0/24 [170/2562585856] via 155.1.78.8, 00:11:49, Ethernet0/0.78
R7#
R7#show route-map
route-map SOO, permit, sequence 10
Match clauses:
Set clauses:
extended community SoO:100:16
Policy routing matches: 0 packets, 0 bytes
R7#show run int e0/0.78
Building configuration...
Current configuration : 145 bytes
!
interface Ethernet0/0.78
encapsulation dot1Q 78
ip vrf sitemap SOO
ip address 155.1.78.7 255.255.255.0
ip ospf cost 9999
delay 10000
end
R7#
Comments
What version of code are you using? I've had varied results with this feature depending on the code version used. Some version plain don't work as expected. It seems that older code worked well, but newer code doesn't. I tasted this using csr1000v 3.11 and it works as expected. The labs were written using this code version too.
I'm using version 15.2. I haven't had the time or the resources to build the CSR environment yet, so I'm using other methods in the meantime. As long as my understanding of it is correct then I will move on. I just wanted to mainly make sure my understanding of this feature is correct and that I was configuring it correctly.
Did you also set SoO on the PEs? (int facing each CE)
Yes, I set the ip vrf sitemap command on each interface facing the CE routers from the PE routers. I know it was getting the SoO community as you can see from the show output. Was just confused as to why the route was being accepted.
Hi,
You could also set SOO on the backdoor link between CE devices and the route would not be accepted on the BD link. But this would prevent traffic rerouting in case mpls link fails.
I tried doing that as well. Basically I configured 100:16 on the PE to CE links and the Backdoor links. So 100:16 was configured on every possible link. Still no change. I would think it's safe to assume this is a bug then?
Kinda sounds like it, if your configs all checkout.
FYI EIGRP SoO is legacy after EIGRP vector attributes are encoded in BGP VPNv4 metrics, which is as of 12.0S versions. In other words EIGRP can’t cause a loop over MPLS in any recent version because the feasibility condition extends over MPLS L3VPN.
Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13
[email protected]
Internetwork Expert, Inc.
http://www.INE.com
From: [email protected] [mailto:[email protected]] On Behalf Of ukwill
Sent: Tuesday, July 15, 2014 3:30 PM
To: Brian McGahan
Subject: Re: [CCIE R&S] EIGRP SOO Question
Kinda sounds like it, if your configs all checkout.
INE - The Industry Leader in CCIE Preparation
http://www.INE.com
Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx
Petr wrote a nice blog post about potential issues that can occur when you don't use the SoO community is special scenarios, even when using the cost community and "extend" the EIGRP domain over the L3VPN.
Read his paper here:
http://blog.ine.com/2010/04/29/understanding-eigrp-soo-and-bgp-cost-community/
Thank you for the information guys. I will make sure I know how to configure it, and it sounds like I understand it, and it's function so I will move on. Sounds like this is legacy and would not normally be used in production anyways.
Cdt
On Jul 16, 2014, at 0:11, "ext Brian McGahan" <[email protected]> wrote:
Did you try it on the CLI? Does the query domain terminate on the PE or does it extend over MPLS? Who needs to agree on the vector attribute weightings? If your vector weights are 0 0 0 0 0 are the values still encoded in the VPNv4 updates? I can answer this but I would recommend you research on your own first and report back.
Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13
[email protected]
Internetwork Expert, Inc.
http://www.INE.com
From: [email protected] [mailto:[email protected]] On Behalf Of Kayssar
Sent: Wednesday, July 16, 2014 7:49 PM
To: Brian McGahan
Subject: Re: [CCIE R&S] EIGRP SOO Question
Even in case k-vector is different between sites ?
Cdt
Kayssar
On Jul 16, 2014, at 0:11, "ext Brian McGahan" <[email protected]> wrote:
INE - The Industry Leader in CCIE Preparation
http://www.INE.com
Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx