RE: OT: MPLS VPNV4 routes not making it to EIGRP top

It's even more frustrating when you can't tell if it's a Dynamips bug, an IOS
bug, or if it's a bug in your config ;)

Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com>

Internetwork Expert, Inc.
http://www.INE.com

From: ospf cloud [mailto:ospfcloud_at_gmail.com]
Sent: Wednesday, April 04, 2012 2:13 PM
To: Brian McGahan
Subject: Re: OT: MPLS VPNV4 routes not making it to EIGRP top

I was thinking in this direction Brian, and yes doing a variant of that lab
you posted on Dynamips. Guess it's about time to switch to Cisco-IOU! Dynamips
looks pretty light for some heavy weight SP tasks.

I thought I should ask to make sure I'm on the right path as per
configurations et all.
On Wed, Apr 4, 2012 at 1:48 PM, Brian McGahan
<bmcgahan_at_ine.com<mailto:bmcgahan_at_ine.com>> wrote:
It depends on the IOS version. If it's pre BGP Cost Community for EIGRP then
yes you need to manually set it. Newer IOS versions no you don't need to set
it because the individual vectors of the EIGRP metrics are automatically
encoded.

This is why if you have an EIGRP internal route on one customer site,
redistribute EIGRP into VPNv4 BGP, then redistribute VPNv4 BGP back into EIGRP
on the remote customer site the route can still appear as EIGRP internal,
because the EIGRP Feasibility Condition is end-to-end. Before this you had to
treat inter-site EIGRP routing as if the other sites were External EIGRP
prefixes.

Petr did a really good write-up on this a few years back. You can see it
here: http://goo.gl/5zYeb

HTH,

Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com>

Internetwork Expert, Inc.
http://www.INE.com

-----Original Message-----
From: nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com>
[mailto:nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com>] On Behalf Of marc
edwards
Sent: Wednesday, April 04, 2012 12:58 PM
To: ospf cloud
Cc: ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>
Subject: Re: OT: MPLS VPNV4 routes not making it to EIGRP top

You sure about that? Why don't you try adding the metric and see what
happens...

On Wednesday, April 4, 2012, ospf cloud wrote:

> Actually, the two customer facing PEs are running EIGRP with
> respective CPEs at customer sites. This worked, but suddenly stopped
> working. I'm aware that there is no need to specify metrics because
> the EIGRP costs get encoded within vpnv4 routes.
>
> On Wed, Apr 4, 2012 at 11:28 AM, ospf cloud
<ospfcloud_at_gmail.com<mailto:ospfcloud_at_gmail.com>> wrote:
>
> > Gurus,
> >
> > I'm trying to redistribute vpnv4 routes into a vrf on my PE, the
> > vpnv4 routes are showing up in the vrf's BGP table, but not making
> > it to EIGRP top. I cleared ip route *, cleared ip bgp *, and
> > reloaded to no avail,
> but
> > the routes are still getting stuck. Any ideas?
> >
> >
> > ########################################################
> > R02#show ip eigrp vrf vrf01 top
> > EIGRP-IPv4 Topology Table for AS(65534)/ID(10.1.2.2) VRF(vrf01)
> > Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
> > r - reply Status, s - sia Status
> >
> > P 10.1.2.0/24<http://10.1.2.0/24>, 1 successors, FD is 28160
> > via Connected, FastEthernet0/1 P 1.1.1.1/32<http://1.1.1.1/32>, 1
successors,
> > FD is 156160
> > via 10.1.2.1 (156160/128256), FastEthernet0/1
> >
> > R02#show ip bgp vpnv4 vrf vrf01
> > BGP table version is 13, local router ID is 2.2.2.2 Status codes: s
> > suppressed, d damped, h history, * valid, > best, i - internal,
> > r RIB-failure, S Stale, m multipath, b backup-path, x
> > best-external Origin codes: i - IGP, e - EGP, ? - incomplete
> >
> > Network Next Hop Metric LocPrf Weight Path
> > Route Distinguisher: 65000:1 (default for vrf vrf01)
> > *> 1.1.1.1/32<http://1.1.1.1/32> 10.1.2.1 156160
32768 ?
> > *> 10.1.2.0/24<http://10.1.2.0/24> 0.0.0.0 0
32768 ?
> > *>i10.1.20.0/24 19.19.19.19 5138944
100<tel:5138944%20%20%20%20100> 0 ?
> > *>i10.4.10.0/24 4.4.4.4 0 100 0 ?
> > *>i10.10.10.10/32 4.4.4.4 156160 100 0 ?
> > *>i10.19.20.0/24 19.19.19.19 0 100 0 ?
> > *>i20.20.20.20/32 19.19.19.19 146944 100 0 ?
> > R02#show ip bgp vpnv4 vrf vrf01 10.19.20.0/24<http://10.19.20.0/24> BGP
routing table
> > entry for 65000:1:10.19.20.0/24<http://10.19.20.0/24>, version 12
> > Paths: (1 available, best #1, table vrf01)
> > Not advertised to any peer
> > Local
> > 19.19.19.19 (metric 50) from 3.3.3.3 (3.3.3.3)
> > Origin incomplete, metric 0, localpref 100, valid, internal, best
> > Extended Community: RT:65000:1 Cost:pre-bestpath:128:18944
> > 0x8800:32768:0 0x8801:65534:2560 0x8802:65280:16384
> > 0x8803:65281:4470
> > 0x8806:0:169022483
> > Originator: 19.19.19.19, Cluster list: 3.3.3.3
> > mpls labels in/out nolabel/19016 R02#show run | b router eigrp
> > router eigrp 65000 !
> > address-family ipv4 vrf vrf01 autonomous-system 65534
> > redistribute bgp 65000
> > network 10.1.2.2 0.0.0.0
> > exit-address-family
> > !
> > router bgp 65000
> > no synchronization
> > bgp router-id 2.2.2.2
> > bgp log-neighbor-changes
> > neighbor 3.3.3.3 remote-as 65000
> > neighbor 3.3.3.3 update-source Loopback0 no auto-summary !
> > address-family vpnv4
> > neighbor 3.3.3.3 activate
> > neighbor 3.3.3.3 send-community extended
> > neighbor 3.3.3.3 next-hop-self
> > exit-address-family
> > !
> > address-family ipv4 vrf vrf01
> > no synchronization
> > redistribute eigrp 65534
> > neighbor 10.1.2.1 remote-as 65534
> > neighbor 10.1.2.1 shutdown
> > neighbor 10.1.2.1 activate
> > neighbor 10.1.2.1 as-override
> > exit-address-family

Blogs and organic groups at http://www.ccie.net
Received on Wed Apr 04 2012 - 14:14:55 ART