[c-nsp] Route Redistribution Problem (static route into OSPF into MBGP)

[Chris Cappuccio]

The proper way to do this is to setup OSPF sham links (inside the vrf
obviously) between your PE routers rather than try to redistribute OSPF
into BGP.

Sam Stickland [sam_mailinglists at spacething.org] wrote:
> Hi,
> 
> I've got a strange route distribution issue. The router setup is this:
> 
> Cust Network 1
> |           |
> |           |
> R1 ------- R2
> |           |
> |           |
> R3 ------- R4
> |           |
> |           |
> Cust Network 2
> 
> MPLS links are in use between all four routers, and all of them are in a
> full MBGP mesh. This is a pretty standard MPLS VPN setup with the customer
> running OSPF as their IGP.
> 
> The routers R1 and R2, (and R3 and R4) run OSPF with the customer network,
> inside of a VRF "vrf-one". The customer routes are transported via MBGP over
> the MPLS network (all inside "vrf-one"). The interfaces into the customer
> network are in VRF vrf-one.
> 
> On R1 and R2 static routes (to a management network) are redistributed into
> the customers OSPF (130).
> 
> The problem is that this route is getting distributed into Cust Network 1's
> OSPF, but the route from there isn't getting redistributed into BGP, so that
> Cust Network 2 never learns the route.
> 
> A sample configuration from R1 is:
> 
> ip vrf vrf-one
>  rd 64513:1
>  route-target export 64513:1
>  route-target import 64513:1
> 
> router ospf 130 vrf vrf-one
>  router-id 172.16.25.253
>  log-adjacency-changes
>  redistribute static metric 50 subnets
>  redistribute bgp 64513 subnets
>  network 172.16.25.128 0.0.0.3 area 0
>  network 172.16.25.253 0.0.0.0 area 0
> 
> router bgp 64513
>  no synchronization
>  bgp router-id 172.16.26.254
>  bgp cluster-id 167838050
>  bgp log-neighbor-changes
>  neighbor 172.16.26.252 remote-as 64513
>  neighbor 172.16.26.252 update-source Loopback100
>  neighbor 172.16.26.253 remote-as 64513
>  neighbor 172.16.26.253 update-source Loopback100
>  neighbor 172.16.26.255 remote-as 64513
>  neighbor 172.16.26.255 update-source Loopback100
>  no auto-summary
> 
>  address-family ipv4 vrf vrf-one
>  redistribute ospf 130 vrf vrf-one match internal external 1 external 2
>  no auto-summary
>  no synchronization
>  exit-address-family
> 
> ip route 10.200.20.0 255.255.255.0 172.16.27.129
> ip route vrf vrf-one 10.200.20.0 255.255.255.0 172.16.27.129 global
> 
> The prefix 10.200.20.0/24 is the management network. Logging into one of the
> routers on "Cust Network 1" shows that the route has been distributed into
> the customers OSPF process (130).
> 
> However, from there the route doesn't make it into BGP and across the
> network.
> 
> R1#sh ip bgp vpnv4 all nei 172.16.26.253 advertised-routes | inc 10.200.20
> 
> R1#sh ip route vrf vrf-one 10.200.20.0
> Routing entry for 10.200.20.0/24
>   Known via "static", distance 1, metric 0
>   Redistributing via ospf 130
>   Advertised by ospf 130 metric 50 subnets
>   Routing Descriptor Blocks:
>   * 172.16.27.129 (Default-IP-Routing-Table)
>       Route metric is 0, traffic share count is 1
> 
> Why doesn't this route end up inside the BGP table?
> 
> Sam
> 
> _______________________________________________
> 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/

-- 
There is no certainty, there is only opportunity