Using Same Loopback Interface for building a Sham-Link and a Virtual-Link

Hi Guys,

Is there any restriction for using the same loopback
for building an OSPF Sham-Link with a peering PE and a Virtual-Link
with a customer router for the purpose of solving the split area 0
problem? I.e. Your PE connects to a CE in Area X, then that CE connects
to another router in Area 0 and that other router connects to another
router in Area Y. Since the MPLS SuperBackbone appears like Area 0 to
the PE and there is also another Area 0 in the customer network, a
Virtual-Link must be configured between the PE and the ABR in Area 0 in
order to solve this problem. Now let's say that the customer OSPF
network extends to another CE connecting to another PE in a different
site and we need to setup a Sham-Link between PEs. Is it possible to use
the same Loopback interface -assuming it is an /32 and is currently
being used as the OSPF RID in the PE- for both the Sham-link and the VL?
Is this recommended/discouraged? Any implications this setup may pose?


Also regarding Sham-Links, and I beg your pardon here because I know
this topic has been beaten up to death pretty much, since we create an
/32 loopback interface under the VRF we want to set the SL up, then
advertise this address in MP-BGP address family (we never advertise it
in the IGP used in the MPLS core), and pretty much we are redistributing
MP-BGP into the OSPF VRF process (and we redistribute the other way
around too), I was wondering how come the VRF OSPF learned route for
this loopback interface doesn't preempt the MP-BGP route learned for
this same prefix at the remote PE. I would expect the PE learning this
route via MP-BGP from the remote PE with an AD of 200 (assuming it is
iBGP) and via VRF OSPF over the backdoor link with AD 110, thus the OSPF
learned route would preempt the BGP route. I have never seen that this
route is filtered out when redistributing from BGP into OSPF, and I know
Sham-links just sit there fat, dumb and happy without the need of
filtering this out, but this just picked me and I would really
appreciate if anyone could provide some insight into this.


Thanks in advance,
Jorge

Comments

  • The virtual-link will be using the router-ids as its endpoints - the router-id does not need to be advertised through OSPF for a virtual-link to work. I hadn't tried such a design, but it could work, maybe. If I have time I may try it on the SP racks this weekend...

  •  sure   complications in configuring as if i was facing it alot ::))) .. using the same loopbacks ... big time yes ( they are part of differnt routing table which is not related to any other VRFs)...   u can use as long as they are in VRFs of required sham-links.... and redistributed in MP-BGP

     

    and why MP-bgp route si prefered in PE..u might need to check this...u ll get an idea..:))

    http://ieoc.com/forums/t/12422.aspx

  • Hi Guys,

    Thank you for taking the time for looking into this.

    Fragilemohi - Thanks for sharing that link, however, I don't think that explains my concern as that is related to Cost Community, which is for DV protocols, and mainly used with EIGRP, however, this explanation does not apply to LS protocols, like OSPF.

    Regards,

    Jorge

  • Hi Guys,

    Thank you for taking the time for looking into this.

    Fragilemohi - Thanks for sharing that link, however, I don't think that explains my concern as that is related to Cost Community, which is for DV protocols, and mainly used with EIGRP, however, this explanation does not apply to LS protocols, like OSPF.

    Regards,

    Jorge

    Hi Jorge,

    The MPLS backbone acts as area 0 when ospf is use on the PE-CE links, and it's called Super-Backbone and is transparent to the CEs.

    HTH

    - Mohammad

  • Someone correct me if I'm way off-base on this, but I think we're missing the bigger picture here.  You should never need to create BOTH a virtual-link and a sham-link, because the two are for two very different scenarios.

     

    A quick overview:  A sham-link is designed to trick OSPF (hence "sham") into believing that two MPLS VPN sites are in the same area.  A sham-link is not needed when the two sites are isolated, as inter-area links don't provide a problem for us.  However, the situation changes when you create a backup link between the two sites.  Assuming the two sites are in the same area, the backup link now provides a path for OSPF to resolve routes as INTRA-area.  The MPLS backbone path will continue to advertise routes as INTER-area, and due to the OSPF selection process, intra-area routes are always preferred over inter-area routes, independent of cost.

     

    Once we understand that, we should never need to create both a virtual-link and a sham-link between the same two sites.  If the two areas are both Area 0, then connecting them via the backup-link will de-segment them, and thus no virtual-link is required.  Simply configure the sham-link to handle the path selection and you're good!  Now, in the other scenario, we have two area 0s with no back-up link, and now a sham-link is not needed.

     

    All that said, I'll admit that all my MPLS practice has involved NOT using area 0, seeing as the MPLS backbone is supposed to act as the super-backbone.  So I'm curious as to whether you'd even need a virtual-link between the two, since LSAs aren't propagated between the two "ABRs", but instead are redistributed into BGP, I'm guessing that two Area 0s wouldn't need a virtual-link.  Definitely something I intend to test!

     

    Jeff

  • Someone correct me if I'm way off-base on this, but I think we're missing the bigger picture here.  You should never need to create BOTH a virtual-link and a sham-link, because the two are for two very different scenarios.

     

    A quick overview:  A sham-link is designed to trick OSPF (hence "sham") into believing that two MPLS VPN sites are in the same area.  A sham-link is not needed when the two sites are isolated, as inter-area links don't provide a problem for us.  However, the situation changes when you create a backup link between the two sites.  Assuming the two sites are in the same area, the backup link now provides a path for OSPF to resolve routes as INTRA-area.  The MPLS backbone path will continue to advertise routes as INTER-area, and due to the OSPF selection process, intra-area routes are always preferred over inter-area routes, independent of cost.

     

    Once we understand that, we should never need to create both a virtual-link and a sham-link between the same two sites.  If the two areas are both Area 0, then connecting them via the backup-link will de-segment them, and thus no virtual-link is required.  Simply configure the sham-link to handle the path selection and you're good!  Now, in the other scenario, we have two area 0s with no back-up link, and now a sham-link is not needed.

     

    All that said, I'll admit that all my MPLS practice has involved NOT using area 0, seeing as the MPLS backbone is supposed to act as the super-backbone.  So I'm curious as to whether you'd even need a virtual-link between the two, since LSAs aren't propagated between the two "ABRs", but instead are redistributed into BGP, I'm guessing that two Area 0s wouldn't need a virtual-link.  Definitely something I intend to test!

     

    Jeff

     

    Jeff,

     

    You are right but what Jorge wants is to join two sites with areas x and y, that are already joined through area 0, through the MPLS backbone. Hence he will have a disjoint area 0 (the original and the super-backbone), and to fix this he's using a virtual link.

     

    - Mohammad

     

  • But the MPLS backbone isn't actually an Area 0.  It's just treated as such in the sense that you can operate an MPLS-backed OSPF domain without an Area 0.  Since BGP does the transport, and OSPF parameters are passed via communities, it doesn't create a disjointed Area 0.  

     

    Again, correct me if I'm wrong, as this is my understanding of how it works.  This is a great discussion, it definitely makes you think hard about these things.

  • Hi Guys,

    Thanks for taking the time for looking into this. Although you are correct regarding your statement that the MPLS backbone isn't actually Area 0, the PEs are considered ABRs because they advertise Type3 LSAs to the CEs. This is an excerpt from the book MPLS Fundamentals, Chapter 7:

    "The PE routers function as ABRs as they advertise type 3 LSAs to the CE routers. The CE routers
    can be in area 0 or any other area. If, however, a site has more than one area, the PE routers must
    be in area 0 because they are ABRs. If they are not, a virtual link between the PE router and the
    nearest ABR in the customer site must bring area 0 up to the PE router"

    Now you might need to create a Sham Link as well to make the MPLS backbone preferred over your backup link. Refer to this thread for a scenario where both are required:

    http://ieoc.com/forums/p/11483/109830.aspx

    Having said that, my question is if there are any problems by using the loopback interface used for the Sham Links as the OSPF RID and thus for the VL.

    Regards,

    Jorge

  • OSPF RID is just a number that just happens to be defined in some interface IP configuration (unless defined manually). It does not matter where that interface is used. Thus there cannot be any problems using the sham-link loopback IP address for the OSPF RID.

     

    Markku

Sign In or Register to comment.