Thanks Steve, That makes sense what you are doing. Labbing it up as we speak. As far as multiple proces id's on the same router, i'm thinking i should think about it as we would with a VRF instance? I.e. you would set another proces up to interface with a different, separate router process. So as you said, proces 1 and proces 100 on 2 separate routers would communicate, now if i would want to setup a new proces id to communicate with a new different network and keep them separate for various reasons that's why we would setup a new ospf process. And if we wanted then to interface with the multiple processes on the same router we'd need to use redistribution ofcourse.
The more i think about it the more i get it. Your explanation took me some time but i think the penny dropped :-) However, with the risk of sounding stupid, proces id's still don't seem different to me from instances. What can i do with instances i cannot do with processes ? I could run 10 ospf process on router a which i would interface with 10 on router b, how is that different from using instances? Best, Alef On Jul 2, 2011, at 6:02 AM, Di Bias, Steve wrote: > Hey Alef, > > I just labbed this up and it makes perfect sense now. The documentation > states that you can run multiple instances on a single link, not a single > interface. This would explain why you can only configure one instance per > interface :) > > I'm using the example given in my previous post that's modified for what I > just labbed up. > > Let's say we have four routers (R4, R5, R6, and R7) that are connected to a > common link (VLAN 567) R4 and R6 belong to an AS different from the one to > which R5 and R7 belong. To exchange OSPF packets, R4 and R6 will use a > different Instance ID from R5 and R7. If the receiving router does not > recognize the Instance ID, it discards the packet and a neighbor adjacency > will not form. If we wanted to do this for OSPFv2 we would have had to use > the authentication field, which no longer exists in OSPFv3. > > Lab Config > > On the VLAN 567 links > > R4 > ipv6 unicast-routing > inter fa0/0 > ipv6 address FD00:5:6:7::4/64 > ipv6 ospf 1 area 0 instance 2 > > R5 > ipv6 unicast-routing > inter eth0/0 > ipv6 addr fd00:5:6:7::5/64 > ipv6 ospf 1 area 0 instance 1 > > R6 > ipv6 unicast-routing > inter eth0/0 > ipv6 addr fd00:5:6:7::6/64 > ipv6 ospf 1 area 0 instance 2 > > R7 > ipv6 unicast-routing > inter eth0/0 > ipv6 addr fd00:5:6:7::7/64 > ipv6 ospf 1 area 0 instance 1 > > > When I did this the behavior seen was fully expected. > > R4 peered with R6 but not with R5 or R7 > R6 peered with R4 but not with R5 or R7 > R5 peered with R7 but not with R4 or R6 > R7 peered with R5 but not with R4 or R6 > > R5#sh ipv6 osp ne > Neighbor ID Pri State Dead Time Interface ID Interface > 200.0.0.7 1 FULL/DR 00:00:30 4 Ethernet0/0 > > R6(config-if)#do sh ipv ospf ne > > Neighbor ID Pri State Dead Time Interface ID Interface > 200.0.0.4 1 FULL/BDR 00:00:35 4 > Ethernet0/0 > > > One thing I that baffled me was that I couldn't see anything in my debugs > about a mismatched OSPF instances. I was running the following debugs on all > routers: > > Debug ipv6 packet detail > Debug ipv6 ospf adj > Debug ipv6 ospf hello > > Not sure why this would be, but there was nothing in there about mismatch > instances at all. > > Lab it up using IPv4 and IPv6 OSPF when you can to see what you find. > > Cheers! > > Thank you, > > Steve E. 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 Di Bias, Steve > Sent: Friday, July 01, 2011 9:09 AM > To: Alef > Cc: [email protected] IE > Subject: Re: [OSL | CCIE_RS] ospfv3 instances vs ospf proces id's ? > > 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 > > > 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
