[c-nsp] OSPF Router ID

Thu Mar 29 04:09:26 EST 2007

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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
david.ponsdesserre at uk.bnpparibas.com
Sent: 29 March 2007 09:37
To: ian.mackinnon at lumison.net
Cc: cisco-nsp-bounces at puck.nether.net; cisco-nsp at puck.nether.net
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
ian.mackinnon at lumison.net

Sent by: cisco-nsp-bounces at puck.nether.net
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  cisco-nsp at puck.nether.net
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  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/