[c-nsp] iBGP overriding IGP - ?

[Chris Evans]

And I email again...   It is from the mpls superbackbone feature.  Research
"bgp cost community" and you will understand.

Hope this helps.
On Nov 7, 2010 7:49 PM, "Chris Evans" <chrisccnpspam2 at gmail.com> wrote:
> 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/