Hi, David is right .. Best practice is EBGP at PE-CE level technically and commercially :)
I have come across very less OSPF implementation over PE-CE link. But I guess below text might help you in figuring out ur issue. ( It is referenced from the point of view of provider ) but still I guess it shud give u some pointers ? Cheers Raj ------------------------------------------ Selection of the OSPF process-id for each VPN client is important because it determines how routes received from CE routers at this site are advertised into the OSPF topology of other sites. By default, the process-id must be the same on all PE routers; otherwise, the OSPF routes transported across the MPLS VPN backbone will be inserted as external routes (type 5 LSAs) in the local OSPF domain, instead of interarea (type 3 LSAs) routes. This process is described in more detail in the later section "Controlling LSA Type Generation at PE Routers." You can control the process through the use of a domain-id. NOTE Using the same process-id for a given VPN can be problematic because more than one VRF might want to use the same process-id on the PE router. This is not possible; therefore, the domain-id becomes an important tool. The OSPF process-id was not taken into account in early Cisco IOS implementations of OSPF on the PE-CE links, and all intra-area OSPF routes were advertised as interarea routes into the OSPF topology database at other PE routers. The processid value became important only with the introduction of support for OSPF domains in IOS releases 12.1(4.4)T, 12.1(4.4), and 12.0(16.3)ST. Take special care when upgrading your IOS software to a release that supports OSPF domains inside an MPLS VPN; the upgrade might break your customer's OSPF routing due to the different method of PE router link-state advertisement (LSA) generation -------------------------------------------------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 29 March 2007 09:37 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [c-nsp] OSPF Router ID I think best practices recommend the use of EBGP at PE-CE level . Doing this will avoid mutual redistribution between MBGP (in the mpls core). So may be migrating from OSPF to EBGP will be a good idea later on . Which IGP are you using in your Core ? Rgds David Internet [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 29/03/2007 09:07 To kwbales cc cisco-nsp Subject Re: [c-nsp] OSPF Router ID Kurt Bales wrote: > Hey Guys, > > We are migrating our services to a MPLS VPN (on our providers network). We > are using OSPF to route between the remote sites and the providers VRF. We > can only seem to get the OSPF sessions to establish if we use the same OSPF > process ID as our provider, but all the docs I can find suggest that > the process ID only has context within the local router, and does not propogate > outside of the router? > > Does anybody have any suggestions as to why this might be? > you are right, as far as I can recall, the RFC specs say it is local only, but I seem to remember that in a MPLS context Cisco do use it. I can't seem to find why at the moment, but >From http://www.ciscopress.com/articles/article.asp?p=391649&seqNum=2&rl=1 NOTE If you want all the sites in the VPN to be in the same OSPF autonomous system, the process ID configured for the VRF on all PE routers must be the same. Alternatively, use the domain-id command to configure a consistent domain ID number (by default, the domain ID corresponds to the OSPF process ID). -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison, nplusone or lightershade ltd. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison, nplusone and lightershade ltd accepts no liability for any damage caused by any virus transmitted by this email. -- -- Virus scanned by Lumison. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. ************************************************************************ ********************** BNP Paribas Private Bank London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Securities Services London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Fund Services UK Limited is authorised and regulated by the Financial Services Authority _______________________________________________ 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/
