EIGRP SoO in the lab

Folks, looking for an opinion on SOO. I understand what it's for and how it works (read Petrs doc an all) but I'm thinking how best to implement in the lab where we have this kind of topology, single 'site' with dual CE homed to single PEs. I've been playing around with it this morning and I'm thinking no nonsense is the best approach, kill all potential loops.

 

PE1              PE2

|                   |

|                   |

CE1-----------CE2

 

Are people of the opinion that you set the extcomm to the same on both PEs, removing the possibiliy of resilience should the backdoor link fail? Not great for real world implementation but the last thing you need in the lab is a loop to wreck your head.

 

PE_1#
ip vrf SOO
interface FastEthernet0/1
 ip vrf forwarding SOO
 ip vrf sitemap SOO

route-map SOO permit 10
 set extcommunity soo 125:125

 

PE_2#
ip vrf SOO
interface FastEthernet0/0
 ip vrf forwarding SOO
 ip vrf sitemap SOO
route-map SOO permit 10
 set extcommunity soo 125:125

Comments

  • Basically by doing the above you'd drop all intra-as EIGRP routes learned from the PE's.  That would certainly kill a loop, but not sure how practical it would be.  I suppose it would be acceptable if you didn't want to provide intra-AS VPN over the MPLS network.

  • Yes, I realise the problems it would cause but this is specific to the lab, if they don't state you must provide resilience, or keep in line with the physical resilience.

    I guess if the site is a CSC customer carrier then you dont want to block the backdoor link from being used by doing this, woudl be even more impractical to isolate your entire geograpic SP core :D

    I'm just having problems simulating a loop is all, seems any tests that I run, ,the order of operations is ok to ensure BGP/EIGRP remain stable.

  • Well there are a few ways to avoid the loops and still allow traffic and path selection over the MPLS network and the backdoor link.  (ie:  metrics and AD)  But I guess it really comes down to the do's and more imortantly the "don't" of the lab task.

    -v10d

  • I'm just having problems simulating a loop is all, seems any tests that I run, ,the order of operations is ok to ensure BGP/EIGRP remain stable.

    Hey Keith,

    I beleive that this SOO feature between EIGRP and BGP is obsolete now. The reason being that when dealing with EIGRP in PE-CE environments, EIGRP encodes all of the vectors into the BGP update. This allows for the EIGRP network to be "end to end" in calculating loop free best paths, seeing the MPLS/BGP cloud as "transparent".  

    The SOO community, from my understanding, is only really useful when dealing with sites that run BGP as PE/CE.  I am sure it used to be useful for EIGRP before these extended communities existed! 

    Pablo

     

     

  • Yeah I suggested as much in a post a few weeks ago but apparently not. Petr's blog post relates to eigrp as the PECE protocol

  • I think configuring different EIGRP SoO values on PEs would make more sense in order to prevent routing loops.

    Regards,

    AB.

  • Thanks for the feedback guys, curious if anyone has a theory on how to test this without relying on chance. Much more P routers in the path woud increase serialization, processing latencies through the core.  You would think the CE-CE-PE link would be updated sooner that.

  • The SOO community, from my understanding, is only really useful when dealing with sites that run BGP as PE/CE.  I am sure it used to be useful for EIGRP before these extended communities existed! 

    I take this back! I just re-read the Petr article and saw that there is a good use for this. Preventing the race condition

     

  • You mean it prevents temporary routing loops. Race conditions cant be prevented using EIGRP SOO.

    Petr's article has one mistake when he describes use of EIGRP SOO.

    Cheers,

    AB.

  • Petr's article has one mistake when he describes use of EIGRP SOO.

    I have spotted a couple of errors that make it hard to understand. He mixed "PE1" for "PE2" or vise versa when explaining something. Is this what you mean, or do you mean that he's actually technically wrong about something?

    You mean it prevents temporary routing loops. Race conditions cant be prevented using EIGRP SOO.

    Right, this is what I meant. 

     

  • Nothing can prevent a race condition right? Yes cant stop propagation, transmission delay etc one direction over another.  The only thing you can do is to prevent the impact of a race condition.

  • Okay, just so that I can answer to this post properly, I went and quickly re-read Petr's article. There are a couple of mistakes I can highlight here.

    1. He describes MP_REACH_NLRI and MP_UNREACH_NLRI as "transitive" but in fact they are non-transitive, optional path-attributes.

    2. When he describes the first deployement use case of EIGRP SoO. The correct explanation would be -

    In stable state (with "BGP Bestpath cost-community ignore" NOT enabled) i.e. PE2 router prefers BGP route for CE1's Loopback (172.16.1.1/32) since the backdoor link metric is too high. Hence, CE2 prefers the route from PE2, rather than backdoor link.

    NOTE that CE2 has the path to CE1 via backdoor link as feasible successor.

    Now, when CE1's Loopback is not available, and assuming EIGRP wins the race condition with BGP (as per the article), the following occurs-

    1. CE1 sends a Query message to PE1 and CE2 for 172.16.1.1/32 with Infinite metric.

    2. Since PE1 learnt the route from CE1 (Successor), and having received the Query message from CE1, PE1 sends a Reply message with Infinite metric (basically means unreachable) and removes 172.16.1.1/32 from its routing table. It has no other EIGRP neighbors and hence cannot do any querying. However, it sends a BGP Withdraw message (actually, BGP Update message with MP_UNREACH_NLRI for 172.16.1.1/32) to PE2.

    3. On the other hand, CE2 having learnt the route from PE2 (remember this route has EIGRP SoO as attached by PE1, not PE2), sends a Reply message for 172.16.1.1/32 with a Finite metric (means reachable). CE2 also removes CE1 as feasible successor.

    4. If CE1 sends an Update message to PE1, PE1 discards it due to SoO Filtering.

    4. Meanwhile, PE2 learns from PE1 that 172.16.1.1/32 is not available through PE1 via a BGP Withdraw message.

    5. This causes PE2 to send Query message to CE2 for 172.16.1.1/32 and gets a Reply message with Infinite metric. PE2 removes the route.

    6. CE2 then sends a Query message to CE1 and gets a Reply message with Infinite metric. CE2 and CE1 removes the route.

     

    This looks silly considering CE1 queries for its local interface to its peers but that's how EIGRP works.

    I may have missed few things here and there but this is what I have noticed during testing. The "debug eigrp fsm" command shows some great output.

     

    Cheers,

    AB.

     

     

  • In some workbook exercizes, it states that the SoO is set both ways: When redistributing from BGP into EIGRP, as well as when redistributing from EIGRP to BGP. 

    I have found that this is not necesarily the case. 

    From all of the Cisco Docs and books that I've read, what I've seen is that the SoO is only set when prefixes are RECEIVED (when a CE sends routes to a PE, and the PE as the sitemap applied on its CE facing interface). 

    Wha I've seen in testing is that if a route does not originate from the EIGRP domain (lets say it comes from an OSPF site that is a member of the same VPN), and its redistributed by the PE from BGP into EIGRP, this will NOT have the SoO applied.

    Anyone else observe this?

  • I think the workbooks are right - if you have vrf sitemap configured on the PE interface to CE, the PE will set SoO in EIGRP Updates when it sends a remote prefix to CE, and when it receives the prefix from CE which is the redistributed into BGP. The SoO is carried in BGP.

    Cheers,

    AB.

  • SoO is not set in OSPF. When you learn routes from OSPF, there is no way that interface SOO can be applied to them that is why you dont see SOO carried in BGP when you redistribute OSPF routes into BGP.

    AB.

  • Hello Amit, thanks for your reply. That's what I thought too, but when I tested it out I am seeing different behavior. I have tested this out on 12.4 T, 12.2 SRE, and 15.2 S. 

    There is a really crazy loop that occurs precicely because of this behavior.  I can send you a .net file with the topology I'm testing this out on if youd like. 

    Another interesting behavior is that after the count to infinity' loop stops, the eigrp route being redistributed into bgp stops including all of eirgp attributes ubun the bgp update. While the count to infinity loop is occurring, the eigrp route does include all of the eigrp attributes in the bgp update (including the hop count) but as soon as it stops, the pe router still keeps the route as eigrp, but the redistribution doesn't include the attributes. 

     

    This scenario is driving me nuts! I know how to solve it with tags or via other filtering, but whats interesting is how eigrp behaves with bgp. The introduction of external, non eigrp routes into the dual homed site really screws things up. 

  • Dear All,

    I went through this interested topic and discussion and would like to clarify two points

    1.The SOO is carried only on the eigrp learned route when it is received from EIGRP interface applied on it SiteMap ,that's why this isn't in the case of OSPF

    2.I think it is better to have different values of SOO and not the same value ,because having different SOO will serve the same purpose of same SOO avoiding race condition since th PE router preserve the set value when the route is sent on the interface of new SOO so it won;t change  the old value beside having resilliency option.
    When configuring the same SOO value , CE1 won't be able to ping CE2 in case of having  CE1-CE2 link down

  • Dear All,

    I went through this interested topic and discussions and would like to clarify the below two points

    1.Only the EIGRP routes learned from EIGRP interface will be set SOO value configured on the received interface accordingly in OSPF case ,no SOO will be set

    2.I think it will be better to have different SOO values than same value since this will serve the same purpose of configuring same SOO values by avoiding race condition since the remote PE router won't set the route with new value while preserving the old value so no change beside achieving resillience condition.

    When the link between two CE goes down in case of having same SOO ,CE1 won;t be able to learn CE2 route through Backbone according isolation will happen which will be solved during configuring different SOO.As a conclusion it is better to configure  different SOO

Sign In or Register to comment.