Alef, that's not what I'm saying...

Remember that process ID's are locally significant, so in the event I'm running 
R1 as process ID 1 (router ospf 1) and R2 as process ID 2 (router ospf 2)will 
they peer up and share routes with each other? The answer here is yes, because 
the process ID is only "locally" significant, so in this case we do share 
routes. 

Now in the event we are running two process ID's (1 and 2) on the same router 
(e.x. R1), will the routes be shared between the two process ID's? Nope! If you 
want to share routes in this case you have to redistribute between the two 
routing processes.

So why run separate process ID's on the same router? Remember that OSPF rule 
about routers within the same area having identical LSDB's? So what happens if 
we need to peer up with some other entity and wanted to share some, but not all 
of our OSPF routes? Exactly, we could just run another process and redistribute 
ONLY the routes we need to share with them.

For RIPng I don't think they call them instances, but process ID's (I think).

R1(config-if)#ipv6 rip ?
  WORD  User selected string identifying this RIP process

R1(config-if)#do sh ipv6 proto
IPv6 Routing Protocol is "rip IPexpert"
  Interfaces:
    FastEthernet0/0
  Redistribution:
    None
IPv6 Routing Protocol is "rip CCIE"
  Interfaces:
    FastEthernet0/1
  Redistribution:

Now back to OSPFv3...

In the reference material and links I posted below there are some discrepancies 
I'm finding during my testing of this. 

For example, the documentation states that you can run more than one instance 
per interface, but is this really true? Nope! Not in my testing. 

For example, if I configure F0/0 to run in instance 1 and instance 2 the latter 
will overwrite the former. 

interface FastEthernet0/0
ipv6 address FD00:BAD:BEEF:BABE::1/64
ipv6 address FE80::1 link-local
ipv6 ospf 1 area 0 instance 1
ipv6 ospf 1 area 0 instance 2

R1(config-if)#do sh run int fa0/0
Building configuration...

Current configuration : 458 bytes
!
interface FastEthernet0/0
 ip address 150.100.12.1 255.255.255.0
 ipv6 address FD00:BAD:BEEF:BABE::1/64
 ipv6 address FE80::1 link-local
 ipv6 ospf 1 area 0 instance 2

So either I don't understand or the documentation is wrong?? 

If anyone has any insight please let me know.

HAPPY 4TH of July everyone!!!


Thank you,
 
Steve Di Bias
Network Engineer - Information Systems
Valley Health System - Las Vegas
Office - 702- 369-7594
Cell - 702-241-1801
[email protected] 

-----Original Message----- 
From: Alef [mailto:[email protected]] 
Sent: Thursday, June 30, 2011 11:17 AM
To: Di Bias, Steve
Cc: [email protected] IE
Subject: Re: [OSL | CCIE_RS] ospfv3 instances vs ospf proces id's ?

I guess i am. Are you saying that different proces id's have access to the same 
routes? i.e. if i would advertise one thing in one routing process would it be 
available in the other?

I always thought the opposite. I knew they were different routing processes, 
but i also told a aspect of that would be that they would not have access to 
eachother's databases. If not, what exactly is actually the point of having 
multiple routing processes if there is no particular difference?

In RIPng, is 
ipv6 router rip cisco12 

also a instance ?
On Jun 30, 2011, at 7:02 PM, Di Bias, Steve wrote:

> Hey Alef,
> 
> I think you're confusing process ID's with instances, they are different. 
> 
> For example in OSPFv2 you could run multiple processes like "router ospf 1" 
> and "router ospf 2" but with IPv6 you can run different instances, for 
> example:
> 
> Inter s0/0/0
> Ipv6 addr fd00:BAD:BEAF:BABE::2/64
> ipv6 ospf 100 area 1 instance 2
> 
> So here the process ID is "100" the area is "1" and the instance is "2"
> 
> This might help!
> 
> "The Instance ID Identifies the OSPF instance to which this packet belongs. 
> The Instance ID is an 8-bit number assigned to each interface of the router. 
> The default value is 0. The Instance ID enables multiple OSPF protocol 
> instances to run on a single link. If the receiving router does not recognize 
> the Instance ID, it discards the packet. For example, routers A, B, C, and D 
> are connected to a common link n. A and B belong to an AS different from the 
> one to which C and D belong. To exchange OSPF packets, A and B will use a 
> different Instance ID from C and D. This prevents routers from accepting 
> incorrect OSPF packets. In OSPF for IPv4, this was done using the 
> Authentication field, which no longer exists in OSPF for IPv6."
> 
> From the IETF
> 
>   OSPFv3 [OSPFV3] includes a mechanism for supporting multiple
>   instances on the same link.  OSPFv2 [OSPFV2] could benefit from such
>   a mechanism in order to support multiple routing domains on the same
>   subnet.  The OSPFv2 instance ID is reserved for support of separate
>   OSPFv2 protocol instances.  This is different from OSPFv3 where it
>   could be used for other purposes such as putting the same link in
>   multiple areas.  OSPFv2 supports this capability using a separate
>   subnet or the OSPF multi-area adjacency capability [MULTI-AREA].
> 
> http://tools.ietf.org/html/draft-ietf-ospf-multi-instance-04 
> 
> More from the IETF
> 
> OSPFv3  
> 
>     Most of the checks for OSPFv3 are similar to that of OSPFv2. The  
>     main points of differences are: -  
> 
>     - OSPFv3 runs on a per link basis instead of a per subnet basis.  
>       The check for network mask is not done.  
> 
>     - Instance ID field (non-existent in OSPFv2) on the link is  
>       matched with the incoming ID in Hellos. Only if the Instance- 
>       Id's match do we actually form adjacencies. This allows multiple  
>       instances of OSPF to run on a single link.
> 
> Also check out the following RFC's 
> 
> http://www.ietf.org/rfc/rfc5340.txt 
> 
> http://www.faqs.org/rfcs/rfc2740.html 
> 
> 2.4.  Explicit Support for Multiple Instances per Link
> 
>   OSPF now supports the ability to run multiple OSPF protocol instances
>   on a single link.  For example, this may be required on a NAP segment
>   shared between several providers.  Providers may be supporting
>   separate OSPF routing domains that wish to remain separate even
>   though they have one or more physical network segments (i.e., links)
>   in common.  In OSPF for IPv4, this was supported in a haphazard
>   fashion using the authentication fields in the OSPF for IPv4 header.
> 
>   Another use for running multiple OSPF instances is if you want, for
>   one reason or another, to have a single link belong to two or more
>   OSPF areas.
> 
>   Support for multiple protocol instances on a link is accomplished via
>   an "Instance ID" contained in the OSPF packet header and OSPF
>   interface structures. Instance ID solely affects the reception of
>   OSPF packets.
> 
> 
> HTH
> 
> Thank you,
> 
> Steve Di Bias
> Network Engineer - Information Systems
> Valley Health System - Las Vegas
> Office - 702- 369-7594
> Cell - 702-241-1801
> [email protected] 
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Alef
> Sent: Thursday, June 30, 2011 8:27 AM
> To: [email protected] IE
> Subject: [OSL | CCIE_RS] ospfv3 instances vs ospf proces id's ?
> 
> I used to think that you can define as many ospf processes as you like, 
> however on the cisco site it states that "unlike ospf v2, with ospv3 you can 
> have multiple instances", as if ospv3 is the first to allow this possibility?
> 
> is there a difference?
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please 
> visit www.ipexpert.com
> 
> Are you a CCNP or CCIE and looking for a job? Check out 
> www.PlatinumPlacement.com
> 
> 
> UHS Confidentiality Notice:  This e-mail message, including any attachments, 
> is for the sole use of the intended recipient (s) and may contain 
> confidential and privileged information.  Any unauthorized review, use, 
> disclosure or distribution of this information is prohibited.  If this was 
> sent to you in error, please notify the sender by reply e-mail and destroy 
> all copies of the original message.



UHS Confidentiality Notice:  This e-mail message, including any attachments, is 
for the sole use of the intended recipient (s) and may contain confidential and 
privileged information.  Any unauthorized review, use, disclosure or 
distribution of this information is prohibited.  If this was sent to you in 
error, please notify the sender by reply e-mail and destroy all copies of the 
original message.
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

Reply via email to