Re: Routing Metrics - Redistributing from MP-BGP VPNv4 into

For example if you try on PE1 router to match source-protocol BGP then have
a set metric operation it would never work as the PE-CE routing is EIGRP
......the match statement is looking for BGP as the source protocol in the
EIGRP TLV update message, but the problem is this only happens post
redistribution and the route-map looks for this match prior, this would be
possible on the CE router if you we're running multiple EIGRP AS numbers
and redistribute between the two....

So PE-CE AS100 and CE-CE AS200 (and any subsequent CE devices thereafter
running AS200)

then something like

route-map test permit 10
 match source-protocol bgp 65001
 set metric 1000000 1 255 1 1500

But it's too messy when you can just use an offset list matching an ACL in
the first place with the PE-CE running the same EIGRP AS number.

--
BR
Tony
On 30 August 2014 15:27, Billy Singh <billysingh_at_ipanyany.com> wrote:
> Good evening all.
>
> Doing labs on PE-CE (namely EIGRP).
>
> I have a PE router (PE-1) which has an EIGRP adjacency (within a VRF)
> with a downstream CE router.
>
> PE-1 is receiving MP-BGP VPNv4 routes from another PE (PE-2) sitting
> across an MPLS network. PE-2 is advertising routes from two difference
> VRFs, both of which are running different routing protocols (let's say
> the customer has one floor in a building running EIGRP as the PE-CE and
> another floor running OSPF as the PE-CE). Not a real world scenario,
> just a twisted and messed up way of doing things, i.e. preparation for
> the CCIE lab. ;)
>
> PE-1 needs to accept both of these routes into the EIGRP topology table
> and advertise them down to the CE router. Obviously the routes which
> were originally EIGRP routes will appear as EIGRP internal routes and
> the OSPF routes will appear as EIGRP external routes in the CE's routing
> table.
>
> After setting the correct RT's (route-targets), the routes do appear to
> be learned via MP-BGP VPNv4, which is good:
>
> sh bgp vpnv4 uni vrf CA | b Net
>       Network          Next Hop            Metric LocPrf Weight Path
> Route Distinguisher: 1:10 (default for vrf CA)
>   *>i 5.0.0.0          4.4.4.4           13556702 100      0 ?
>   *>i 6.0.0.0          4.4.4.4                 11 100      0 ?
>
> You can tell which is the internal EIGRP and which is the external EIGRP
> based on the metric values.
>
> The 5.0.0.0/8 route will have no problems with metrics when
> redistributed back into EIGRP because of the extended community values
> which get propagated along with the VPNv4 route, i.e. we don't have to
> specify metrics:
>
> sh bgp vpnv4 uni vrf CA 5.0.0.0/8
> BGP routing table entry for 1:10:5.0.0.0/8, version 8
> Paths: (1 available, best #1, table CA)
>    Not advertised to any peer
>    Refresh Epoch 2
>    Local, imported path from 1:50:5.0.0.0/8 (global)
>      4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)
>        Origin incomplete, metric 13556702, localpref 100, valid,
> internal, best
>        Extended Community: RT:1:105
>          Cost:pre-bestpath:128:13556702 (default-2133926945) 0x8800:32768:0
>          0x8801:100:512032 0x8802:65281:1657856 0x8803:65281:1500
>          0x8806:0:84215045
>        mpls labels in/out nolabel/403
>        rx pathid: 0, tx pathid: 0x0
>
> The 6.0.0.0/8 route however will need to have a EIGRP metric set for it,
> due to the fact that its VPNv4 extended community values (OSPF) mean
> nothing to EIGRP:
>
> sh bgp vpnv4 uni vrf CA 6.0.0.0/8
> BGP routing table entry for 1:10:6.0.0.0/8, version 14
> Paths: (1 available, best #1, table CA)
>    Not advertised to any peer
>    Refresh Epoch 3
>    Local, imported path from 1:60:6.0.0.0/8 (global)
>      4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)
>        Origin incomplete, metric 11, localpref 100, valid, internal, best
>        Extended Community: RT:1:600 RT:1:615
>          OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0
>          OSPF ROUTER ID:10.1.46.4:0
>        mpls labels in/out nolabel/406
>        rx pathid: 0, tx pathid: 0x0
>
> My goal is to continue to use the EIGRP metrics for the EIGRP internal
> routes, and set new EIGRP metrics for the external routes. I only seem
> to be able to use one redistribute command under the EIGRP process
> running within the VRF on PE-1. So I need to use a route-map along with
> the redistribution back into EIGRP.
>
> My question is what on earth do I match on for the EIGRP external routes
> (ACL is too easy, I want to use some of the other match options in the
> route-map)?
>
> router eigrp AS100
>   address-family ipv4 unicast vrf CA autonomous-system 100
>    topology base
>     redistribute bgp 65001 route-map REDIS-EIGRP
>
>
> route-map REDIS-EIGRP permit 10
>   match ?????
>   set metric 1500 1 1 1 1500
>
> route-map REDIS-EIGRP permit 20
>
> The sensible options appear to be "match source-protocol" or "match
> route-type", but I can't get either to work properly.
>
> If I do "match route-type external" it drops the external routes
> completely, but keeps the EIGRP ones.
> If I do "match source-protocol ospf 2" it appears to match both the
> internal and external ones and sets the metrics on both types of routes???
>
> The other option is for me to TAG the OSPF routes on PE-2 as they get
> redistributed into MP-BGP VPNv4 and then match on that when they get
> redistributed back on PE-1. But I want to understand the route-map
> options better.
>
> Thanks.
>
> Billy
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net