I do have some confusion about which one is better for IPv6 in Service
Provider networks as far as IP routing and MPLS application is concern!
1. Which protocol should i use to support the IPv6 in network: ISIS or
OSPFv3?
As ISIS has multi-topology feature that can give us capability to run
IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will
be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its
look like resource utilization for both the protocol will be same as they
are going to use separate database for storing the routing or topology
information. ISIS still has advantage over OSPF as it does use the TLV
structure which can help in expanding network to support the new feature!
2. MPLS is not distributing label for IPv6 protocol so again there will not
be any IGP best path calcuated for any MPLS related application for IPv6!
3. what if i have already running OSPFv2 for IPv4 in the network then should
i think for migrating to ISIS?
if yes then what are the advantages that I can look at for migrating my
network to IS-IS?
FWIW, we run OSPF for IPv4 and ISIS for IPv6. We started with ISIS for
v6 because we were routing IPv6 before OSPFv3 was available.
The main reason I prefer ISIS is that it uses CLNS packets for
communications and we don't route CLNS. (I don't think ANYONE is routing
CLNS today.) That makes it pretty secure.
I would hope you have a backbone well enough secured that you don't need
to rely on this, but it does make me a bit more relaxed and makes me
wish we were using ISIS for IPv4, as well. The time and disruption
involved in converting is something that will keep us running OSPF for
IPv4 for a long time, though. I remember the 'fun' of converting from
IGRP to OSPF about 13 years ago and I'd prefer to retire before a
repeat.
The real issue is that you need to run something you understand and can
manage effectively. It that is OSPF, it will certainly do the job. If it
is ISIS, it will, too. The real differences are few and not significant for
most.
We've been happy with IS-IS, having migrated from OSPF
ealrier on in the year. We like it because it lets us
"stretch" the network without worrying about connectivity to
the "backbone" area.
However, as most others have said, go with what you're
comfortable with. The knobs and switches really aren't that
different nowadays, just a few fundamentals that you can
easily use to decide which makes (more) sense to you.
For v6, using a single routing protocol for both address
families is not so bad (although running both OSPFv2 and
OSPFv3 really isn't a big deal, or bad thing, having done it
at my previous employment and so on).
For IS-IS, highly recommend MT to avoid any nasties while
turning up v6 in a dual-stack environment.
For IS-IS, highly recommend MT to avoid any nasties while
turning up v6 in a dual-stack environment.
as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing?
Personally, if my v4 and v6 topologies are not different, I'd run ISIS and not run MT. MT for me is to make v4 and v6 have different control planes (even though it's using the same protocol), thus I see little difference in running OSPFv3+ISIS, or running ISIS-MT for v4+v6.
I argue that it's better to have different control planes for v4 and v6 and make it obvious (OSPv3 / ISIS), than to use ISIS-MT and "obfuscate".
as one who has been burned when topologies are not congruent, i gotta
ask. if i do not anticipate v4 and v6 having different topologies, and
all my devices are dual-capable, would you still recommend mt for
other than future-proofing?
Personally, if my v4 and v6 topologies are not different, I'd run ISIS
and not run MT. MT for me is to make v4 and v6 have different control
planes (even though it's using the same protocol), thus I see little
difference in running OSPFv3+ISIS, or running ISIS-MT for v4+v6.
I argue that it's better to have different control planes for v4 and v6
and make it obvious (OSPv3 / ISIS), than to use ISIS-MT and "obfuscate".
the real control plane is bgp. is-is is for recursive resolution to find bgp's next hop interface, fertig. so the simpler the better. i am annoyed enough that bgp4 and bgp6 peerings and configs are overly divergent. running a different igp for 6 and 4 would not make me happy.
Unless, of course, someone one hop away -- a peer? a customer? an
upstream or downstream? someone on the same LAN at certain exchange
points? -- sends you a CLNP packet at link level...
It's also a potential hassle, where you can have IS-IS up and running, but have IP completely hosed. With OSPF this is harder as it actually runs over IP; no IP, no IGP adjacancy.
There is good reason why neither OSPF nor IS-IS rules the IGP world, they both have their advantages and disadvantages. Differences are usually in what the organisation is used to, not because one is fundamentally better than the other.
Unless, of course, someone one hop away -- a peer? a customer? an
upstream or downstream? someone on the same LAN at certain exchange
points? -- sends you a CLNP packet at link level...
True enough, and mistakenly enabling ISIS on external ports has been
known to happen though in the absence of malice it usually causes no
problems. If it does cause problems, generally the source can be more
easily localized given that it has to be L2-adjacent to one of your
routers.
In practice, we realized that enabling IS-ISv6 on interfaces
already running IS-ISv4 was problematic without MT pre-
configured.
Those links surely lost IS-IS adjacency which threatened
stability of the network.
Things could probably have been easier if all routers
accepted all transition commands at the same time (or if all
routers were pre-configured and powered on at the same
time), but that's not possible.
MT allowed us to bring up individual v6 links on the same
and different routers, at different times, without bringing
down the v4 network, considering that several routers had as
many as 4 - 6 links into the core.
as one who has been burned when topologies are not congruent, i gotta
ask. if i do not anticipate v4 and v6 having different topologies,
and all my devices are dual-capable, would you still recommend mt for
other than future-proofing?
In practice, we realized that enabling IS-ISv6 on interfaces already
running
IS-ISv4 was problematic without MT pre- configured.
Those links surely lost IS-IS adjacency which threatened stability of the
network.
Yup, that is the rub: if rolling out your v6 routing impacts your v4 routing
you are not "winning".
In practice, we realized that enabling IS-ISv6 on interfaces
already running IS-ISv4 was problematic without MT pre-
configured.
Those links surely lost IS-IS adjacency which threatened stability
of the network.
Yup, that is the rub: if rolling out your v6 routing impacts your v4
routing you are not "winning".
this is not very deep.
mark did point out how to avoid it, pointing out why mt was very useful as opposed to just another bell and whistle. during a transition, in fact, topologies are not congruent due to inability to have a flag millisecond, a very very useful observation.
In practice, we realized that enabling IS-ISv6 on interfaces
already running IS-ISv4 was problematic without MT pre-
configured.
Those links surely lost IS-IS adjacency which threatened stability
of the network.
Yup, that is the rub: if rolling out your v6 routing impacts your v4
routing you are not "winning".
this is not very deep.
Is it untrue?
mark did point out how to avoid it, pointing out why mt was very useful
as opposed to just another bell and whistle. during a transition, in
fact, topologies are not congruent due to inability to have a flag
millisecond, a very very useful observation.
Indeed, and not creating the problem is good thing. I don't think we are
disagreeing on anything here ...
Although I don't believe anyone has mentioned "multi-topology" +
"transition" just yet, the goal being that when you go from ST to MT
(assuming you aren't already there, that is) you don't impact ongoing
operations / neighborships.
as one who has been burned when topologies are not
congruent, i gotta ask. if i do not anticipate v4 and v6
having different topologies, and all my devices are
dual-capable, would you still recommend mt for other than
future-proofing?
In practice, we realized that enabling IS-ISv6 on interfaces
already running IS-ISv4 was problematic without MT pre-
configured.
at least in my case, I did turned ISISv6 in one WAN interface where the router on the other side (a Cisco) did not have the "ipv6 unicast routing" general command on and the isis adjacency went down completely. So, yes that was an issue. But if you enabled IPv6 in both ends first and then one interface at the time, it worked.
I used MT to avoid IPv6 black holes during the configuration period, but as some boxes did not implemented it, I needed to use the "transition" option where IPv6 adjacencies are carried in both native and the MT-IPv6. Fortunately the two vendors that were lacking of MT support are up-to-date, however not in time as the migration ended and MT was removed and I left the company.
at least in my case, I did turned ISISv6 in one WAN
interface where the router on the other side (a Cisco)
did not have the "ipv6 unicast routing" general command
on and the isis adjacency went down completely. So, yes
that was an issue.
One of the things I'm hoping Cisco can fix in not-too-
distant future releases of IOS.
But if you enabled IPv6 in both ends
first and then one interface at the time, it worked.
What we saw on our test segment was that v4 adjacencies were
not torn down by merely enabling IS-ISv6 on an interface
(given that JunOS enables IS-ISv6 by default when IS-IS is
enabled on the router; in IOS, you have to explicitly turn
IS-ISv6 on).
v4 adjacencies were torn down *after* an IPv6 address was
added to the interface. We witnessed this issue under both
IOS and JunOS.
I would hope you have a backbone well enough secured that you don't need
to rely on this, but it does make me a bit more relaxed and makes me
wish we were using ISIS for IPv4, as well. The time and disruption
involved in converting is something that will keep us running OSPF for
IPv4 for a long time, though. I remember the 'fun' of converting from
IGRP to OSPF about 13 years ago and I'd prefer to retire before a
repeat.
I did the OSPF --> IS-IS migration some time back and here's some of the info I found at the time.
Vijay did a nice presentation on AOL's migration to IS-IS. IIRC AOL migrated everything in 2 days. Day 1 was to migrate their test POP and hone their script. All remaining POPs were migrated on Day 2. I believe he said it went well. There have been several other documented migrations too:
I migrated my SP from a flat OSPF network (end to end area 0) to IS-IS. The OSPF setup was seriously screwed up. Someone got the bright idea to changes admin distances on some OSPF speakers, introduce a default in some places with static defaults in others, redistributing like it was going out of style, redisting a static for a large customer subnet on P2 instead of P1 which is what PE1 actually connected to (and not advertising the route from PE1 for some unknown reason), etc. The old setup was a nightmare.
The IS-IS migration went fairly well after I got some major bugs worked out on our 7600s. I implemented IS-IS overtop of OSPF. Some OSPF speakers had admin distances of 80 and some were default. IS-IS slipped in over top with no problems. I raised IS-IS to 254 for the initial phase anyway just to be safe. Once I had IS-IS up I verified it learned all the expected routes via IS-IS. Then I lowered its admin distance back to the default and bumped OSPF up to 254. Shortly thereafter I nuked OSPF from each device. It was hitless. I never could get IS-IS to work with multiple areas. The 7600s made a smelly mess on the CO floor every time I tried. In the end I went with a L2-only IS-IS network. Still it works well for the most part. I've had about as much trouble with IS-IS as I have had with OSPF. Occasionally some random router will get a burr under it's saddle and jack up the MTU on the CLNS packets beyond the interface's max. The receiving router will drop the padded frame as too big. Fixing this can sometimes happen with a shut/no shut. Sometimes I can nuke the entire IS-IS config and re-add the config. Other times I simply have to reboot. This doesn't happen too often; it's usually several hours after I rock the IS-IS boat so to speak. Still, I wouldn't go back to OSPF for this SP.