[c-nsp] iBGP overriding IGP - ?

Jeff Bacon bacon at walleyesoftware.com
Sun Nov 7 18:58:01 EST 2010


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



More information about the cisco-nsp mailing list