[c-nsp] iBGP overriding IGP - ?

[Chris Evans]

Looking at it more the eigrp route doesn't have a successor so it does mark
it as a valid route. As ibgp is the only available path it gets installed.
I don't know eigrp enough to tell you why though.
On Nov 7, 2010 7:23 PM, "Chris Evans" <chrisccnpspam2 at gmail.com> wrote:
> I just skimmed your email as I'm on my phone but. Eigrp superbackbone
comes
> to mind for your scenario... cisco supports Eigrp and ospf superbackbone
> concepts across an mpls infrastructure...
>
> Chris
> On Nov 7, 2010 7:04 PM, "Jeff Bacon" <bacon at walleyesoftware.com> wrote:
>> Maybe a dumb question, but I can't determine the right place to look for
>> the answer and my brain is swimming.
>>
>> Scenario:
>> - mesh of cat6500s (SXH/SXI) linked by gig fiber; effectively there are
>> 4 sites, pair of switches at each site...
>>
>> /---B----\
>> / | \
>> A | C
>> \ | /
>> \---D----/
>>
>> - most traffic lives in global domain at the moment. Not really dealing
>> with that right now.
>> - VRF "wmain" is defined, and is meant as the replacement for the
>> current "one big EIGRP domain" form of routing; the goal is to have
>> sites using EIGRP for local routing on local dist devices which uplink
>> to the 6500s via interfaces in VRF wmain then redist from EIGRP into
>> BGP/VRF-wmain
>> - however, it doesn't work that way right now:
>> - EIGRP is running in VRF wmain at site A and at site C.
>> - however, EIGRP is NOT redisted into BGP.
>> - instead, there is a GRE tunnel running between a switch at site A
>> and a switch at site C which links the EIGRP instances.
>> - there is another EIGRP path between site A and site C which isn't
>> part of this ring. (Eventually it will go away.)
>>
>> What I'm having trouble understanding:
>>
>> I set up a test to redistribute a single route from EIGRP into
>> BGP/VRF-wmain at site A. No other redist happening anywhere else between
>> EIGRP and BGP - just injecting the one route.
>>
>> It redists, and all of the BGP/VRF-wmain instances on all the switches
>> get the route.
>>
>> However, on the switch at site C which also has the EIGRP instance, the
>> BGP-learned route is preferred over the EIGRP route. OK, but...
>> - it's an external-EIGRP, admin distance 170
>> - it's also learned via IBGP, admin distance 200
>>
>> WHY is it preferring the IBGP route? Isn't admin distance supposed to
>> define which routing protocol to prefer/believe? At least that's what
>> the books tell me. What am I missing?
>>
>>
>> ch4-sw1#show ip route vrf wmain 10.97.64.0
>> Routing entry for 10.97.64.0/24
>> Known via "bgp 36193", distance 200, metric 133632, type internal
>> Last update from 172.30.192.10 00:46:59 ago
>> Routing Descriptor Blocks:
>> * 172.30.192.10 (Default-IP-Routing-Table), from 172.30.192.11,
>> 00:46:59 ago
>> Route metric is 133632, traffic share count is 1
>> AS Hops 0
>> MPLS label: 299
>> MPLS Flags: MPLS Required
>>
>>
>> ch4-sw1#show ip eigrp vrf wmain top 10.97.64.0 255.255.255.0
>> IP-EIGRP (AS 10): Topology entry for 10.97.64.0/24
>> State is Passive, Query origin flag is 1, 0 Successor(s), FD is
>> 4294967295
>> Routing Descriptor Blocks:
>> 10.200.32.97 (GigabitEthernet2/3.411), from 10.200.32.97, Send flag is
>> 0x0
>> Composite metric is (441344/441088), Route is External
>> Vector metric:
>> Minimum bandwidth is 20000 Kbit
>> Total delay is 12240 microseconds
>> Reliability is 255/255
>> Load is 1/255
>> Minimum MTU is 1500
>> Hop count is 6
>> External data:
>> Originating router is 0.0.0.0
>> AS number of route is 0
>> External protocol is Unknown protocol, external metric is 0
>> Administrator tag is 0 (0x00000000)
>>
>> ch4-sw1#show ip bgp vpnv4 vrf wmain 10.97.64.0
>> BGP routing table entry for 36193:101:10.97.64.0/24, version 2608
>> Paths: (1 available, best #1, table wmain)
>> Not advertised to any peer
>> Local
>> 172.30.192.10 (metric 5) from 172.30.192.11 (172.30.192.11)
>> Origin incomplete, metric 133632, localpref 100, valid, internal,
>> best
>> Extended Community: RT:36193:101 Cost:pre-bestpath:129:133632
>> 0x8800:0:0 0x8801:10:5632 0x8802:65283:128000 0x8803:65281:1500
>> 0x8804:0:0 0x8805:0:0
>> Originator: 172.30.192.10, Cluster list: 172.30.192.11,
>> 172.30.192.21,
>> mpls labels in/out nolabel/299
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/