[c-nsp] iBGP overriding IGP - ?

Mon Nov 8 23:52:30 EST 2010

The original post was about "why an ibgp-learned prefix(AD 200) was being preferred over a eigrp-External (AD 170).
bgp-cost-community as applicable to EIGRP has to do with EIGRP-INTERNAL(AD 90) being re-created at the far-end. It has nothing to do with poster's question.

Jeff, feel free to reply offline with eigrp and bgp configs.
./Randy

--- On Sun, 11/7/10, Chris Evans <chrisccnpspam2 at gmail.com> wrote:

> From: Chris Evans <chrisccnpspam2 at gmail.com>
> Subject: Re: [c-nsp] iBGP overriding IGP - ?
> To: "Jeff Bacon" <bacon at walleyesoftware.com>
> Cc: cisco-nsp at puck.nether.net
> Date: Sunday, November 7, 2010, 4:56 PM
> 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/
> _______________________________________________
> 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/
> 