Hey Steve, Sorry for the delay, but I finally got some time away from 4th of July visitors to drop in some config in Junos. Junos seems to be able to do multiple instances of OSPFv3 (and v2 for that matter) with no issues. The config I used worked as expected.
RFC 2740 - 2.4. Explicit Support for Multiple Instances per Link In IOS we have the interface commands for ospfv3 that actually makes use the "instance" syntax. In Junos, it's quite different in how you would accomplish having an interface exist in multiple areas. There's no "instance" syntax on the interface. You have to create forwarding instances for the areas and import/export routes to and from those tables to achieve the wanted prefix (or link) to be added to the main or global routing table. This is done through a series of policy and protocol statements that would be similar to configuring route-maps in IOS. I was able to get this working with no issues in ospfv2 and ospfv3. I wanted to get a wireshark trace to make sure that the ospfv3 headers actually have the "instance ID" field as specified in the RFC, but did not have time. Since everything seemed to work, I would have to assume that it does conform to the RFC, even though there's no "instance" syntax. Here's a link that describes how to accomplish multi-area ospfv2. http://www.juniper.net/techpubs/en_US/junos10.1/topics/usage-guidelines/routing-configuring-multiarea-adjacency-in-ospfv2.html Another link that shows multiple instances of ospf (v2 or v3). http://www.juniper.net/techpubs/en_US/junos10.1/topics/usage-guidelines/routing-configuring-multiple-instances-of-ospf.html And lastly, a link that shows supported RFC's in the version of Junos I used. http://www.juniper.net/techpubs/software/junos/junos93/swconfig-routing/frameset.html The only thing I was not quite able to understand is why RFC 5340 is not listed anywhere in the Juniper docs. Since it obsoletes RFC 2740, I figured it would be implemented instead of 2740 in the "ospf standards" link above. I cannot find it listed anywhere at the moment, but now that has me curious. It could be possible that the "draft-ietf-ospf-af-alt-10" support for address families plus RFC 2740 covers everything in RFC 5340, but I am still reading up on the draft and comparing it to the current RFC to see if that is the case, which I do not believe it is. Long story short, I was able to get this working in Junos. So either we're missing something here about how to get a "link" in ospfv3 configured for multi-areas, or something in IOS isn't allowing for that to happen. I'm am updating some code on my Cisco lab routers to see if it's an IOS issue or an operator issue :) Maybe Marko or someone that's actually gotten this working before can chime in with some clue for us. I've even searched for config examples in IOS, but all I could find was NX-OS examples. regards, max On Sun, Jul 3, 2011 at 12:45 AM, Di Bias, Steve <[email protected]>wrote: > Roger that Max, and please post your findings for us > > Max Pierson <[email protected]> wrote: > > > Hey Steve, > > That's a good idea. I have an M10 I can fire up to see if it exhibits the > same behavior. I'm mobile at the moment, but will test when possible and > reply back with my findings. > > max > > On Sat, Jul 2, 2011 at 1:14 PM, Di Bias, Steve <[email protected]>wrote: > >> Hey Max, >> >> Isn't that strange? Do you have any Juniper routers laying around to test >> on? Maybe its a Cisco thing??? >> >> Max Pierson <[email protected]> wrote: >> >> >> Hi Steve, >> >> My mistake. That's what I get for skimming through threads lol. I missed >> that part in your second post. >> >> That is strange indeed. I got the same when I added a second instance as >> well. It just overwrites the previous instance config. >> >> Would be nice if they gave an example in the docs. Not finding >> any examples where it shows it, or as you stated, i'm missing something. >> >> m >> >> On Sat, Jul 2, 2011 at 11:59 AM, Di Bias, Steve >> <[email protected]>wrote: >> >>> Max in mhy testing its not possible to configure multiple instances on a >>> single interface, give it a try... >>> >>> Max Pierson <[email protected]> wrote: >>> >>> >>> >What can i do with instances i cannot do with processes ? >>> >>> Hi Alef, >>> >>> I believe it's to allow multiple instances of ospf to run on a single >>> interface. OSPF for ipv4 does not allow for this if i'm not mistaken. >>> >>> Here's the comparison of the two versions in the doc cd (not sure why >>> we're still calling it doc "cd" lol). >>> >>> >>> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-ospf_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1069821 >>> >>> I'm sure Marko will correct me if i'm wrong here :) >>> >>> - >>> m >>> >>> >>> On Sat, Jul 2, 2011 at 6:30 AM, Alef <[email protected]> wrote: >>> >>>> 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 >>>> >>> >>> >>> >>> >>> 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, and may >>> be punishable by law. 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, and may >> be punishable by law. 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, and may be > punishable by law. 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
