Sorry, the last link about the "ospf standards" was wrong in the last email.
Here's the correct one.

http://www.juniper.net/techpubs/software/junos/junos93/swconfig-routing/ospf-standards.html#id-11626548

max


On Sun, Jul 3, 2011 at 5:32 PM, Max Pierson <[email protected]> wrote:

> 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

Reply via email to