[c-nsp] iBGP overriding IGP - ?

Chris Evans chrisccnpspam2 at gmail.com
Sun Nov 7 19:23:11 EST 2010


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/


More information about the cisco-nsp mailing list