The MPLS-OPS Archive

[Nathan <paranoia@phreaker.net>]

On Sun, Mar 12, 2006 at 06:36:50PM +1300, Truman Boyes wrote:
> Hi Nathan,
>
> MP-BGP can attach two new extended communities to routes that are  
> redistributed from OSPF.
> 
> 1. OSPF domain identifier
> 2. OSPF route route type
> 
> So with these attributes and the MED in BGP, you can preserve OSPF
> routing information across MPLS/BGP vpns.
>
> Have you looked at using sham links to tie together your OSPF
> network? Specifically, using a sham link between VRFS on the 2 PE
> routers. OSPF will then create an adjacency between the two VRFs, and
> your ospf network will have metrics that consider the route across
> the two PE's.
    
So it's called "sham" links... google will help... "OSPF
Sham-Link Support for MPLS VPN",
    
        http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ospfshmk.htm

fits the bill perfectly. Specially designed to take care of the
problem I have. Thanks a lot!
    
I've set it up, it works as advertised. For the benefit of
others, some caveats:

    sham-link endpoints should not be redistributed into OSPF
    because the ospf adjacency will flap. I suppose it's that
    the OSPF route will take over, break the adjacency, lose the
    OSPF route, go back to the BGP route, set up the adjacency
    again, etc. To do this I used a distribute-list access-list
    in on all the PEs involved, since simply not redistributing
    bgp into ospf made the sham link go down, see below.

    if the sham-link doesn't go up, check that bgp is
    redistributed into ospf on both sides. Don't know why that
    has to be so.

    all routes must be distributed into mp-bgp, otherwise they
    won't work. OSPF E2 are not distributed by default, so you
    have to specify that explicitly in the redistribute ospf
    command. Routes that exist in OSPF but not in BGP won't get
    a tag:

    $VPN_IP/24, version 7103, epoch 0, cached adjacency $PE2_PUB_MPLS_ITF
    0 packets, 0 bytes
      tag information set
        local tag: VPN-route-head
      via $PE2_PUB_LOOPBACK, 0 dependencies, recursive
        next hop $PE2_PUB_MPLS_ITF, FastEthernet0/0 via $PE2_PUB_LOOPBACK/32
        valid cached adjacency
        tag rewrite with Fa0/0, $PE2_PUB_MPLS_ITF, tags imposed: {}

    (when it works there is a tag number inside the braces on
    the last line, and a line similar to the last line comes
    after the "local tag" line.)

Those three problems and their various twisty combinations and
interactions cost me my Sunday afternoon, so I hope listing them
here will avoid that for someone else.

> Changing admin distance behavior is scary and should be avoided at
> almost all costs. I have seen terrible things happen in networks
> where operators had different ideas on preferred protocols (ie. LDP
> and RSVP routes).

Yes :-) I did say only

> >I looked at modifying the administrative distance, but that's
> >system-wide, which would break loads of things.

but I came away from that looking with a very queasy feeling,
thinking about the many things I'd taken for granted for years
which would just blow up in my face . . .

Thanks again Truman for pointing me in the right direction, I
*think* everything's working fine now :-)

Nathan

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml