[c-nsp] Traffic engineering in mixed OSPF/iBGP environment

[Vitkovský Adam]

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:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Garry
> Sent: Tuesday, September 23, 2014 12:37 PM
> To: cisco-nsp at puck.nether.net
> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/