Hi Garry, Seems you are struggling with the Type-1 vs Type-3 LSAs problem that we dealt with on the list a few weeks back.
Consider the below from a view point of CoreR1. It's because intra-area LSAs are preferred compared to inter-area LSAs. The super-backbone(MP-BGP->OSPF) introduces LSAs from the remote site as Type-3 into the LSDB of a local PE and if the local PE happens to have a Type-1 LSA from a directly connected link than that one is preferred (even though it has a higher metric). So you can either make both LSAs to appear as Type-1 using sham-link or you can make both to be type-3 using different areas on each site. adam > -----Original Message----- > From: cisco-nsp [mailto:[email protected]] On Behalf Of > Garry > Sent: Tuesday, September 23, 2014 12:37 PM > To: [email protected] > Subject: [c-nsp] Traffic engineering in mixed OSPF/iBGP environment > > Hi, > > I've been trying to figure this out for a while now, but can't get a grasp on > how to get this to work the way I want to ... > > In essence, here's the relevant part as a small drawing: > > CPR1------CPR2 > | | > PER1 VSwitch > | |\ > PR1 | \ > : | CPR3..CPR6 > PRn | > \ /\___DSLGW-----CPR7..CPR12 > \ / > CoreR1---CustomerFW--Internet > > > We have a customer network with a redundant connectivity, running as a > distinct MPLS VRF in our backbone. Both links are terminated with a separate > router (CPR1 & 2). Link 1 at CPR2 goes to a virtual WAN switch with additional > sites as well as a link to our backbone (CoreR1). We have OSPF running in that > broadcast domain, as well as between the two > CPR1/2 routers, distributing the different subnets that are reachable. > Link 2 between CPR1 and PER1 is also running OSPF, though in the MPLS > backbone, routes from the VRFs are learned through a route reflector; > PER1 redistributes the RR routes to CPR1 via OSPF. > Additionally, there are some DSL locations which are also terminated through > another router at the CoreR1 location. Again, locally the routes are learned > through OSPF and redistributed to the BGP RR. > > At this point, all routing and redundancy is working fine. If links go down, > routing is recalculated and converges in satisfactory time. > > As for the problem I have: the customer is running applications at a service > provider that is connected to the network via CPR3. Traffic from > CPR1/CPR2 as well as the other customer locations correctly take the route > through the VSwitch. Now, traffic to the Internet (in essence everything that > is not a connected destination inside the VRF but the default route) from > CPR1/CPR2 is supposed to be routed via the PER1... > connection, utilizing the otherwise unused backup link. This is where I'm > having trouble. If the whole network were running on OSPF, putting a higher > OSPF cost on the CoreR1 towards the VSwitch link would more or less ensure > that the link would only be used as a backup, otherwise CPR1 has PER1 as > lower cost towards the CustomerFW, while the traffic to CPR3 is still cheaper > towards the VSwitch. But with the BGP-redistributed routes at the PER1- > CPR1 link, the OSPF cost metrics do not help. I've already tried messing > around with the redistribute statements a bit, but even with altering the > BGP-learned routes to be imported to OSPF as E2 routes, the routing still > kept the vswitch routing up. I'm somewhat out of ideas on how to > implement this while still keeping redundancies operational (with either > traffic able to be routed via either link) and not using error-prone hacks ... > any pointers? > > Thanks, -garry > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
