Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think? -- CJ http://convergingontheedge.com <http://www.convergingontheedge.com>
Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3. The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 11, 2011, at 8:57 AM, CJ <cjinfantino@gmail.com> wrote:
Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think?
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
I'm totally in concurrence with Stephan's point. Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation). -Tony On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant <sfouant@shortestpathfirst.net> wrote:
Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3.
The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant
Sent from my iPad
On Aug 11, 2011, at 8:57 AM, CJ <cjinfantino@gmail.com> wrote:
Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think?
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else. -jim On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant <sfouant@shortestpathfirst.net> wrote:
Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3.
The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant
Sent from my iPad
On Aug 11, 2011, at 8:57 AM, CJ <cjinfantino@gmail.com> wrote:
Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think?
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
On Thu, 11 Aug 2011, jim deleskie wrote:
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
Agreed. I did an OSPFv3 vs. IS-IS bake-off in my lab several months ago as part of an IPv6 rollout, and one of the key deciding factors in going with OSPFv3 over IS-IS was that our ops folks are much more familiar with OSPFv2. While there are difference between OSPFv2 and OSPFv3 in how they work, the learning curve is a lot less steep than going from OSPFv2 to IS-IS. jms
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant <sfouant@shortestpathfirst.net> wrote:
Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3.
The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant
Sent from my iPad
On Aug 11, 2011, at 8:57 AM, CJ <cjinfantino@gmail.com> wrote:
Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think?
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
On Thu, Aug 11, 2011 at 11:04 AM, Justin M. Streiner < streiner@cluebyfour.org> wrote:
On Thu, 11 Aug 2011, jim deleskie wrote:
Having run both on some good sized networks, I can tell you to run
what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
Agreed. I did an OSPFv3 vs. IS-IS bake-off in my lab several months ago as part of an IPv6 rollout, and one of the key deciding factors in going with OSPFv3 over IS-IS was that our ops folks are much more familiar with OSPFv2. While there are difference between OSPFv2 and OSPFv3 in how they work, the learning curve is a lot less steep than going from OSPFv2 to IS-IS.
jms
Do not underestimate the power of ops engineers. Really is not that difficult to learn ISIS and they can add it to their resume.
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com>
wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant <sfouant@shortestpathfirst.net**> wrote:
Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3.
The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.**net <http://www.shortestpathfirst.net> http://www.twitter.com/sfouant
Sent from my iPad
On Aug 11, 2011, at 8:57 AM, CJ <cjinfantino@gmail.com> wrote:
Hey all,
Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think?
-- CJ
http://convergingontheedge.com <http://www.**convergingontheedge.com<http://www.convergingontheedge.com>
On 08/16/2011 12:55 PM, Tomas Lynch wrote:
On Thu, Aug 11, 2011 at 11:04 AM, Justin M. Streiner< streiner@cluebyfour.org> wrote:
On Thu, 11 Aug 2011, jim deleskie wrote:
Having run both on some good sized networks, I can tell you to run
what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
Agreed. I did an OSPFv3 vs. IS-IS bake-off in my lab several months ago as part of an IPv6 rollout, and one of the key deciding factors in going with OSPFv3 over IS-IS was that our ops folks are much more familiar with OSPFv2. While there are difference between OSPFv2 and OSPFv3 in how they work, the learning curve is a lot less steep than going from OSPFv2 to IS-IS.
jms
Do not underestimate the power of ops engineers. Really is not that difficult to learn ISIS and they can add it to their resume.
What would you rather rely on at 3am in the morning when things are breaking? Someone who has just learned IS-IS or someone who already has good experience with OSPF? I would tend towards the latter in my decision making, unless there is significant enough advantage to be gained by the other. Paul
What would you rather rely on at 3am in the morning when things are breaking? Someone who has just learned IS-IS or someone who already has good experience with OSPF?
what would you rather rely on at three in the morning when things are breaking, someone who has just learned OSPF or someone who already has good experience with IS-IS? this seems a silly reversal until you realize that OSPF is significantly more complex and thus harder. randy
On Wed, 17 Aug 2011, Randy Bush wrote:
What would you rather rely on at 3am in the morning when things are breaking? Someone who has just learned IS-IS or someone who already has good experience with OSPF?
what would you rather rely on at three in the morning when things are breaking, someone who has just learned OSPF or someone who already has good experience with IS-IS?
this seems a silly reversal until you realize that OSPF is significantly more complex and thus harder.
And if the person who is involved at 3 AM is well versed in OSPF, this all becomes a non-issue. jms
On Aug 17, 2011 6:58 AM, "Justin M. Streiner" <streiner@cluebyfour.org> wrote:
On Wed, 17 Aug 2011, Randy Bush wrote:
What would you rather rely on at 3am in the morning when things are breaking? Someone who has just learned IS-IS or someone who already has good experience with OSPF?
what would you rather rely on at three in the morning when things are breaking, someone who has just learned OSPF or someone who already has good experience with IS-IS?
this seems a silly reversal until you realize that OSPF is significantly more complex and thus harder.
And if the person who is involved at 3 AM is well versed in OSPF, this all
becomes a non-issue.
And if the person at 3am ..... no. What's sad is that there are only 2 real options and they are both imperfect yet there is really no innovation I know of going on in this area Cb
jms
On 8/17/11 9:50 AM, Randy Bush wrote:
What would you rather rely on at 3am in the morning when things are breaking? Someone who has just learned IS-IS or someone who already has good experience with OSPF? what would you rather rely on at three in the morning when things are breaking, someone who has just learned OSPF or someone who already has good experience with IS-IS?
this seems a silly reversal until you realize that OSPF is significantly more complex and thus harder.
randy
That's like asking whether you want someone who speaks english (as it's regarded as one of the more complex languages for all it's exceptions) or (pick a "simpler" langauge).... If everyone you work with already speaks english, it would seem rather silly to get them to change to something else just because it's simpler! Business needs should rule the choice. What does one offer (for your network) that the other does not. What constraints do you work with that may affect the viability of the choice. Nobody doubts that high-end Mercedes are great cars. However, too many of us have constraints that don't allow that to be a good decision when looking to purchase a car! Just because it is superior doesn't make it the right choice. Scott
-----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: 17 August 2011 14:52 To: Paul Cc: nanog@nanog.org Subject: Re: OSPF vs IS-IS
What would you rather rely on at 3am in the morning when things are breaking? Someone who has just learned IS-IS or someone who already has good experience with OSPF?
what would you rather rely on at three in the morning when things are breaking, someone who has just learned OSPF or someone who already has good experience with IS-IS?
this seems a silly reversal until you realize that OSPF is significantly more complex and thus harder.
randy
Indeed. Does it really take that long to become familiar enough with IS-IS to support it in most situations? It really is not that difficult. I brought our ops people suitable up to speed with IS-IS over about one week of some lab work in their spare time and a few chats over a whiteboard. A couple of times perhaps they called me over an issue, but since then, I have not heard anything from any of them about it. I guess it comes down to the quality of people you employ. But really, if they get OSPF then IS-IS is not hard to grasp. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Awesome, I was thinking the same thing. Most experience is OSPF so it only makes sense. That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3. Thanks, -CJ On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie <deleskie@gmail.com> wrote:
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
-jim
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant <sfouant@shortestpathfirst.net> wrote:
Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3.
The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant
Sent from my iPad
On Aug 11, 2011, at 8:57 AM, CJ <cjinfantino@gmail.com> wrote:
Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think?
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
-- CJ http://convergingontheedge.com <http://www.convergingontheedge.com>
On 12/08/2011, at 12:08 AM, CJ <cjinfantino@gmail.com> wrote:
Awesome, I was thinking the same thing. Most experience is OSPF so it only makes sense.
That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3.
Thanks,
-CJ
On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie <deleskie@gmail.com> wrote:
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
-jim
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
This topic is a 'once a month' on NANOG, I'm sure we could check the archives for some point-in-time research but I'm curious to learn if anyone maintains statistics? It would be interesting to see statistics on how many service providers run either protocol. IS-IS has, for some years, been the de facto choice for SP's and as a result the vendor and standardisation community 'used to' develop SP features more often for IS-IS. IS-IS was, therefore, more 'mature' than OSPF for SP's. I wonder if this is still the case? For me, designing an IGP with IS-IS is much easier than it is with OSPF. Mesh groups are far easier to plan (more straightforward) easier to change than OSPF areas. As for junior noc staff touching much of anything to do with an ISP's IGP at 2am, wake me up instead. jy
If a network is big enough big / complex enough that you really need to worry about performance of mesh groups or tweaking areas then its big enough that having a noc eng page you out at 2am when there is an issue doesn't really scale. I'm all for ISIS, if I was to build a network from scratch I'd likely default to it. I'm just say, new features or performance aside the knowledge of your team under you will have much more impact on how your network runs then probably any other factor. I've seen this time and time again when 'new tech' has been introduced into networks, from vendors to protocols. Most every time with engineers saying we have smart people they will learn it / adjust. Almost every case of that turned into 6 mts of crap for both ops and eng while the ops guys became clueful in the new tech, but as a friend frequently says Your network, your choice. -jim On Thu, Aug 11, 2011 at 7:12 PM, Jeffrey S. Young <young@jsyoung.net> wrote:
On 12/08/2011, at 12:08 AM, CJ <cjinfantino@gmail.com> wrote:
Awesome, I was thinking the same thing. Most experience is OSPF so it only makes sense.
That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3.
Thanks,
-CJ
On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie <deleskie@gmail.com> wrote:
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
-jim
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
This topic is a 'once a month' on NANOG, I'm sure we could check the archives for some point-in-time research but I'm curious to learn if anyone maintains statistics?
It would be interesting to see statistics on how many service providers run either protocol. IS-IS has, for some years, been the de facto choice for SP's and as a result the vendor and standardisation community 'used to' develop SP features more often for IS-IS. IS-IS was, therefore, more 'mature' than OSPF for SP's. I wonder if this is still the case?
For me, designing an IGP with IS-IS is much easier than it is with OSPF. Mesh groups are far easier to plan (more straightforward) easier to change than OSPF areas. As for junior noc staff touching much of anything to do with an ISP's IGP at 2am, wake me up instead.
jy
You guys are making a lot of good points. I will check into the Doyle book to formulate an opinion. So, I am completely new to the SP environment and OSPF is what I have learned because I have ever only had experience in the enterprise. It seems that from this discussion, IS-IS is still a real, very viable option. So, IS-IS being preferred...realistically, what is the learning curve? CJ On Fri, Aug 12, 2011 at 7:57 AM, jim deleskie <deleskie@gmail.com> wrote:
If a network is big enough big / complex enough that you really need to worry about performance of mesh groups or tweaking areas then its big enough that having a noc eng page you out at 2am when there is an issue doesn't really scale. I'm all for ISIS, if I was to build a network from scratch I'd likely default to it. I'm just say, new features or performance aside the knowledge of your team under you will have much more impact on how your network runs then probably any other factor. I've seen this time and time again when 'new tech' has been introduced into networks, from vendors to protocols. Most every time with engineers saying we have smart people they will learn it / adjust. Almost every case of that turned into 6 mts of crap for both ops and eng while the ops guys became clueful in the new tech, but as a friend frequently says Your network, your choice.
-jim
On Thu, Aug 11, 2011 at 7:12 PM, Jeffrey S. Young <young@jsyoung.net> wrote:
On 12/08/2011, at 12:08 AM, CJ <cjinfantino@gmail.com> wrote:
Awesome, I was thinking the same thing. Most experience is OSPF so it
makes sense.
That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3.
Thanks,
-CJ
On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie <deleskie@gmail.com> wrote:
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
-jim
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
This topic is a 'once a month' on NANOG, I'm sure we could check the archives for some point-in-time research but I'm curious to learn if anyone maintains statistics?
It would be interesting to see statistics on how many service providers run either protocol. IS-IS has, for some years, been the de facto choice for SP's and as a result the vendor and standardisation community 'used to' develop SP features more often for IS-IS. IS-IS was, therefore, more 'mature'
only than OSPF
for SP's. I wonder if this is still the case?
For me, designing an IGP with IS-IS is much easier than it is with OSPF. Mesh groups are far easier to plan (more straightforward) easier to change than OSPF areas. As for junior noc staff touching much of anything to do with an ISP's IGP at 2am, wake me up instead.
jy
-- CJ http://convergingontheedge.com <http://www.convergingontheedge.com>
I would not say ISIS is the prefered protocol. Most service providers I have worked with use OSPF. Most networks outside of the US use it from what I have seen and the larger SPs in the US do too. There must be a reason for that. Sent from my iPhone On Aug 12, 2011, at 8:23 AM, CJ <cjinfantino@gmail.com> wrote:
You guys are making a lot of good points.
I will check into the Doyle book to formulate an opinion. So, I am completely new to the SP environment and OSPF is what I have learned because I have ever only had experience in the enterprise.
It seems that from this discussion, IS-IS is still a real, very viable option. So, IS-IS being preferred...realistically, what is the learning curve?
CJ
On Fri, Aug 12, 2011 at 7:57 AM, jim deleskie <deleskie@gmail.com> wrote:
If a network is big enough big / complex enough that you really need to worry about performance of mesh groups or tweaking areas then its big enough that having a noc eng page you out at 2am when there is an issue doesn't really scale. I'm all for ISIS, if I was to build a network from scratch I'd likely default to it. I'm just say, new features or performance aside the knowledge of your team under you will have much more impact on how your network runs then probably any other factor. I've seen this time and time again when 'new tech' has been introduced into networks, from vendors to protocols. Most every time with engineers saying we have smart people they will learn it / adjust. Almost every case of that turned into 6 mts of crap for both ops and eng while the ops guys became clueful in the new tech, but as a friend frequently says Your network, your choice.
-jim
On Thu, Aug 11, 2011 at 7:12 PM, Jeffrey S. Young <young@jsyoung.net> wrote:
On 12/08/2011, at 12:08 AM, CJ <cjinfantino@gmail.com> wrote:
Awesome, I was thinking the same thing. Most experience is OSPF so it
makes sense.
That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3.
Thanks,
-CJ
On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie <deleskie@gmail.com> wrote:
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
-jim
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
This topic is a 'once a month' on NANOG, I'm sure we could check the archives for some point-in-time research but I'm curious to learn if anyone maintains statistics?
It would be interesting to see statistics on how many service providers run either protocol. IS-IS has, for some years, been the de facto choice for SP's and as a result the vendor and standardisation community 'used to' develop SP features more often for IS-IS. IS-IS was, therefore, more 'mature'
only than OSPF
for SP's. I wonder if this is still the case?
For me, designing an IGP with IS-IS is much easier than it is with OSPF. Mesh groups are far easier to plan (more straightforward) easier to change than OSPF areas. As for junior noc staff touching much of anything to do with an ISP's IGP at 2am, wake me up instead.
jy
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
On 8/12/2011 8:40 AM, James Jones wrote:
I would not say ISIS is the prefered protocol. Most service providers I have worked with use OSPF. Most networks outside of the US use it from what I have seen and the larger SPs in the US do too. There must be a reason for that.
Actually, i strongly disagree with this statement. A good majority of the Tier-1 Service Providers that I have worked with in the past used IS-IS, I think in large part due to the points mentioned earlier. I know for a fact that in the late 90s, when we were transitioning from an ATM core to an MPLS core at UUnet, we selected IS-IS largely due to the fact that it supported MPLS Traffic Engineering extensions before comparable support was available in OSPF, and the main reason for this was due to the fact that IS-IS was TLV based. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant
That's interesting and if true would represent a real change. Can you list the larger SPs in the US that use OSPF? jy On 12/08/2011, at 10:40 PM, James Jones <james@freedomnet.co.nz> wrote:
I would not say ISIS is the prefered protocol. Most service providers I have worked with use OSPF. Most networks outside of the US use it from what I have seen and the larger SPs in the US do too. There must be a reason for that.
Sent from my iPhone
On Aug 12, 2011, at 8:23 AM, CJ <cjinfantino@gmail.com> wrote:
You guys are making a lot of good points.
I will check into the Doyle book to formulate an opinion. So, I am completely new to the SP environment and OSPF is what I have learned because I have ever only had experience in the enterprise.
It seems that from this discussion, IS-IS is still a real, very viable option. So, IS-IS being preferred...realistically, what is the learning curve?
CJ
On Fri, Aug 12, 2011 at 7:57 AM, jim deleskie <deleskie@gmail.com> wrote:
If a network is big enough big / complex enough that you really need to worry about performance of mesh groups or tweaking areas then its big enough that having a noc eng page you out at 2am when there is an issue doesn't really scale. I'm all for ISIS, if I was to build a network from scratch I'd likely default to it. I'm just say, new features or performance aside the knowledge of your team under you will have much more impact on how your network runs then probably any other factor. I've seen this time and time again when 'new tech' has been introduced into networks, from vendors to protocols. Most every time with engineers saying we have smart people they will learn it / adjust. Almost every case of that turned into 6 mts of crap for both ops and eng while the ops guys became clueful in the new tech, but as a friend frequently says Your network, your choice.
-jim
On Thu, Aug 11, 2011 at 7:12 PM, Jeffrey S. Young <young@jsyoung.net> wrote:
On 12/08/2011, at 12:08 AM, CJ <cjinfantino@gmail.com> wrote:
Awesome, I was thinking the same thing. Most experience is OSPF so it
makes sense.
That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3.
Thanks,
-CJ
On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie <deleskie@gmail.com> wrote:
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
-jim
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote: > I'm totally in concurrence with Stephan's point. > > Couple of things to consider: a) deciding to migrate to either ISIS or > OSPFv3 from another protocol is still migrating to a new protocol > and b) even in the case of migrating to OSPFv3, there are fairly > significant changes in behavior from OSPFv2 to be aware of (most > notably > authentication, but that's fodder for another conversation). > > -Tony
This topic is a 'once a month' on NANOG, I'm sure we could check the archives for some point-in-time research but I'm curious to learn if anyone maintains statistics?
It would be interesting to see statistics on how many service providers run either protocol. IS-IS has, for some years, been the de facto choice for SP's and as a result the vendor and standardisation community 'used to' develop SP features more often for IS-IS. IS-IS was, therefore, more 'mature'
only than OSPF
for SP's. I wonder if this is still the case?
For me, designing an IGP with IS-IS is much easier than it is with OSPF. Mesh groups are far easier to plan (more straightforward) easier to change than OSPF areas. As for junior noc staff touching much of anything to do with an ISP's IGP at 2am, wake me up instead.
jy
>
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
On 13/08/2011, at 10:48 PM, Randy Bush <randy@psg.com> wrote:
That's interesting and if true would represent a real change. Can you list the larger SPs in the US that use OSPF?
at&t
is-is in ntt, sprint, verizon, ...
randy
AT&T's backbone is the old SBC backbone? Finding OSPF here doesn't surprise me. If Level3 is really OSPF I would be pretty surprised, most of the clue @L3 came from iMCI (a big IS-IS shop). jy
On (2011-08-13 22:44 +1000), Jeffrey S. Young wrote:
That's interesting and if true would represent a real change. Can you list the larger SPs in the US that use OSPF?
AT&T, L3? Anyhow I fully agree with the sentiment that in eu/us markets most SP rock ISIS. At one time when I was shopping for testing gear, one box I tested was Anritsu, which is pretty nice box for its price range, but I couldn't use it due to lack of ISIS emulation. Anritsu sales guy asked their engineers why they didn't do ISIS, answer was because no one uses ISIS. But I guess their focus is asia. -- ++ytti
On Fri, 2011-08-12 at 08:23 -0400, CJ wrote:
So, IS-IS being preferred...realistically, what is the learning curve?
Low, IMO. If you know EIGRP/OSPF, you'll have no trouble picking-up IS-IS. Took me a few hours in a Cisco lab @ Uni to have it all worked-out (interestingly that was about all the CCNP labs covered at the time!) Of course, knowing how the protocol works at a level suitable for implementation in a critical network takes a bit longer, but you shouldn't have any issue bootstrapping your test networks for that purpose. Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The learning curve isn't that big IMHO. However, it's all about comfort. You should never design a network because "someone else does it this way". While you can certainly take ideas into account about the WHY their network looks that way, you need to look at your own needs and desires to figure out if they line up. If everyone in your organization knows OSPF. Why force the change? if you can't come up with a good reason, then that's a great reason not to do it, unless there is something missing from OSPF that you need. The funny thing is that most people learn ISIS in conjunction with what you already know (OSPF) and what the similarities/differences are in terms of thinking. Look at your current design. I'll assume that you have a reason for the aspects of your network design that you currently have (as opposed to someone else did it this way!). What are they? How will they translate to ISIS? Will they translate? Do you care? THAT kind of thing makes a good design for your company. HTH, Scott On 8/12/11 8:23 AM, CJ wrote:
You guys are making a lot of good points.
I will check into the Doyle book to formulate an opinion. So, I am completely new to the SP environment and OSPF is what I have learned because I have ever only had experience in the enterprise.
It seems that from this discussion, IS-IS is still a real, very viable option. So, IS-IS being preferred...realistically, what is the learning curve?
CJ
On Fri, Aug 12, 2011 at 7:57 AM, jim deleskie <deleskie@gmail.com> wrote:
If a network is big enough big / complex enough that you really need to worry about performance of mesh groups or tweaking areas then its big enough that having a noc eng page you out at 2am when there is an issue doesn't really scale. I'm all for ISIS, if I was to build a network from scratch I'd likely default to it. I'm just say, new features or performance aside the knowledge of your team under you will have much more impact on how your network runs then probably any other factor. I've seen this time and time again when 'new tech' has been introduced into networks, from vendors to protocols. Most every time with engineers saying we have smart people they will learn it / adjust. Almost every case of that turned into 6 mts of crap for both ops and eng while the ops guys became clueful in the new tech, but as a friend frequently says Your network, your choice.
-jim
On Thu, Aug 11, 2011 at 7:12 PM, Jeffrey S. Young <young@jsyoung.net> wrote:
On 12/08/2011, at 12:08 AM, CJ <cjinfantino@gmail.com> wrote:
Awesome, I was thinking the same thing. Most experience is OSPF so it
makes sense.
That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3.
Thanks,
-CJ
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
-jim
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony This topic is a 'once a month' on NANOG, I'm sure we could check
On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie <deleskie@gmail.com> wrote: the archives for some point-in-time research but I'm curious to learn if anyone maintains statistics?
It would be interesting to see statistics on how many service providers run either protocol. IS-IS has, for some years, been the de facto choice for SP's and as a result the vendor and standardisation community 'used to' develop SP features more often for IS-IS. IS-IS was, therefore, more 'mature'
only than OSPF
for SP's. I wonder if this is still the case?
For me, designing an IGP with IS-IS is much easier than it is with OSPF. Mesh groups are far easier to plan (more straightforward) easier to change than OSPF areas. As for junior noc staff touching much of anything to do with an ISP's IGP at 2am, wake me up instead.
jy
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJORSMRAAoJEBbNvH35lSOhZm0H/jzo0n3xOhH6Kk5wwjEwlJHB nw0GAmeiCr16JCd/o4/rdS0ASMHDfMceY8peFaOKFpW5g++PPHfnhSEEBn0KFqZg mlq3/6cuYAcHMH032K3wcGlFH+/YPjIyoaoCbTS0tZLVTbred7AskG3DryMIJaCI zeAT0JZFsxj/JUIKvFEX5Bxs+KuOlazfpfGzbJE8pqSb+OMEjxhjUbIJj7NFxvPk 7CzSSqBQV7r1e2RUoI86QcCa35sxEJ3nC+TfS5qaaYzzw1XW1a19eytzcA122kjR zPEdiFPxb7wY1sZ4uM76vLP1q+5g2NeaZKHfHvU0FhqsznJV7YS6AJ3inoLgt5o= =BDQe -----END PGP SIGNATURE-----
I know we are just talking about the core, but out of curiosity will you have any MPLS/BGP VPNS that you may want to run the IGP over. In this case, OSPF may make a little more sense. However if you are really just talking the core, I would agree with the rest of the list, as the decoupling of IP has some advantages and does the TLV structure. Doug Marschke Chief Operating Officer JNCIE-ER #3, JNCIE-M #41, JNCI (415) 704-5005 (office) (415) 902-5702 (cell) (415)-358-4059 (fax) www.proteus.net -----Original Message----- From: CJ [mailto:cjinfantino@gmail.com] Sent: Friday, August 12, 2011 5:24 AM To: jim deleskie Cc: nanog@nanog.org; Jeffrey S. Young Subject: Re: OSPF vs IS-IS You guys are making a lot of good points. I will check into the Doyle book to formulate an opinion. So, I am completely new to the SP environment and OSPF is what I have learned because I have ever only had experience in the enterprise. It seems that from this discussion, IS-IS is still a real, very viable option. So, IS-IS being preferred...realistically, what is the learning curve? CJ On Fri, Aug 12, 2011 at 7:57 AM, jim deleskie <deleskie@gmail.com> wrote:
If a network is big enough big / complex enough that you really need to worry about performance of mesh groups or tweaking areas then its big enough that having a noc eng page you out at 2am when there is an issue doesn't really scale. I'm all for ISIS, if I was to build a network from scratch I'd likely default to it. I'm just say, new features or performance aside the knowledge of your team under you will have much more impact on how your network runs then probably any other factor. I've seen this time and time again when 'new tech' has been introduced into networks, from vendors to protocols. Most every time with engineers saying we have smart people they will learn it / adjust. Almost every case of that turned into 6 mts of crap for both ops and eng while the ops guys became clueful in the new tech, but as a friend frequently says Your network, your choice.
-jim
On Thu, Aug 11, 2011 at 7:12 PM, Jeffrey S. Young <young@jsyoung.net> wrote:
On 12/08/2011, at 12:08 AM, CJ <cjinfantino@gmail.com> wrote:
Awesome, I was thinking the same thing. Most experience is OSPF so it
makes sense.
That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3.
Thanks,
-CJ
On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie <deleskie@gmail.com> wrote:
Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else.
-jim
On Thu, Aug 11, 2011 at 10:29 AM, William Cooper <wcooper02@gmail.com> wrote:
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation).
-Tony
This topic is a 'once a month' on NANOG, I'm sure we could check the archives for some point-in-time research but I'm curious to learn if anyone maintains statistics?
It would be interesting to see statistics on how many service providers run either protocol. IS-IS has, for some years, been the de facto choice for SP's and as a result the vendor and standardisation community 'used to' develop SP features more often for IS-IS. IS-IS was, therefore, more 'mature'
only than OSPF
for SP's. I wonder if this is still the case?
For me, designing an IGP with IS-IS is much easier than it is with OSPF. Mesh groups are far easier to plan (more straightforward) easier to change than OSPF areas. As for junior noc staff touching much of anything to do with an ISP's IGP at 2am, wake me up instead.
jy
-- CJ http://convergingontheedge.com <http://www.convergingontheedge.com>
I thought I'd chime in from my perspective, being the head router jockey for a bunch of relatively small networks. I still find that many routers have support for OSPF but not IS-IS. That, plus the fact that most of these networks were based on OSPF before I took charge of them, in the absence of a compelling reason to change to another IGP, keeps me from taking advantage of IS-IS. I'd like to, but not so badly that I am willing to work around those routers without IS-IS, or weight that feature more heavily when purchasing new equipment. There are many routers with OSPF but no IS-IS. I haven't seen any with IS-IS but no OSPF. I don't think such router would be very marketable to most non-SP networks. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On 8/12/11 8:29 AM, Jeff Wheeler wrote:
I thought I'd chime in from my perspective, being the head router jockey for a bunch of relatively small networks. I still find that many routers have support for OSPF but not IS-IS. That, plus the fact that most of these networks were based on OSPF before I took charge of them, in the absence of a compelling reason to change to another IGP, keeps me from taking advantage of IS-IS. I'd like to, but not so badly that I am willing to work around those routers without IS-IS, or weight that feature more heavily when purchasing new equipment.
There are many routers with OSPF but no IS-IS. I haven't seen any with IS-IS but no OSPF. I don't think such router would be very marketable to most non-SP networks. TRILL supports IS-IS. It seems it may play a role beyond the router. http://tools.ietf.org/html/rfc6326
-Doug
I'll go with that... And one other thing... Traditionally it has been easier for developers to add new features to IS-IS because of the structure and flexibility of TLVs, whereas OSPF required the design of entirely new LSA types to support similar capabilities... I guess this has become less of an issue over the last few years however... Nonetheless, if I was building a greenfield network today, I would personally go with IS-IS, but that is largely because of my many years working with the protocol... Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 11, 2011, at 6:19 PM, Randy Bush <randy@psg.com> wrote:
The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
how about simpler and more stable?
randy
On Thu, Aug 11, 2011 at 5:19 PM, Randy Bush <randy@psg.com> wrote:
how about simpler and more stable?
ISIS is also decoupled from IP making it more robust and flexible/future-proof, as in adaptible to new protocols -- IP connectivity is not required for ISIS nodes to discover and associate with L2 connected neighbors. At the fundamental level, there are plenty of reasons to exclude OSPF from running in a SP core; when a technically superior choice is available and usable. The IP decoupling is a good example. As in, ISIS topology is independent from (non-tunneled) IP topology, which is more flexible. There is less complexity, and basic troubleshooting is facilitated favorably to OSPFv2/v3, due to the larger amount of baggage OSPF carries with it. If you need to renumber your network, including IS-IS routers', you will impact the contents of IPv4 routes transmitted and forwarding table contents, but your adjacencies do not rely on the IP protocol, and aren't dependant on neighbor IP addressing. Need to support IPv6 addresses? ISIS was trivially extended to do it. Need to support routing to MAC addresses? Again... just a new type field. OSPF requires... shall we say, more fundamental changes to attempt to extend it. More fundamental changes to a more complex protocol = more opportunities for bugs. I would encourage you to ask the opposite question: " Is there any reason to run OSPF over IS-IS in the SP core?" And the answer would be... probably not. There is not really a good technical reason to run OSPF over IS-IS in the SP core. You might have some aesthetic considerations such as wanting the SP core to run the same protocol as something else, despite its limitations. Then you will have to ask yourself if the aesthetic considerations outweigh the technical benefits. -- -JH
On 8/11/2011 8:16 PM, Jimmy Hess wrote:
I would encourage you to ask the opposite question: " Is there any reason to run OSPF over IS-IS in the SP core?" And the answer would be... probably not. There is not really a good technical reason to run OSPF over IS-IS in the SP core. You might have some aesthetic considerations such as wanting the SP core to run the same protocol as something else, despite its limitations.
Just to add to everything that Jimmy said, if you've got the time to do an in-depth side-by-side analysis of the two protocols, I strongly recommend the book "OSPF and IS-IS: Choosing an IGP for Large-Scale Networks" by Jeff Doyle. I can't speak highly enough of this book... Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant
On Aug 11, 2011, at 3:19 PM, Randy Bush wrote:
The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
how about simpler and more stable?
not rooted to a particular area. supports more than one AFI at the same time isn't dependent on ip addressing to form an adjacency etc
randy
On Thu, Aug 11, 2011 at 8:57 AM, CJ <cjinfantino@gmail.com> wrote:
Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think?
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
Granted, we're not a service provider, so we operate on a different scale here, but one interesting trick that can be done with ISIS (at least on Cisco) is this: router a ----------- router isis advertise passive-only interface loopback0 ip address 10.1.1.1 255.255.255.255 interface vlan2 ip unnumbered loopback0 ip router isis isis network point-to-point router b ----------- (copy router isis definition from router a) interface loopback0 ip address 10.1.1.2 255.255.255.255 (copy vlan2 definition from router a) ----------- This removes the associated headaches with /30s or /31s in having to keep track of their allocation, as well as having them clog the your routing table. -waits for replies stating why this is a bad idea- Now, if I could just get isis-per-vrf-instance support on the Catalyst 6500. Jason
On 8/11/2011 10:19 AM, Jason Duerstock wrote:
On Thu, Aug 11, 2011 at 8:57 AM, CJ <cjinfantino@gmail.com> wrote:
Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think?
-- CJ
http://convergingontheedge.com <http://www.convergingontheedge.com>
Granted, we're not a service provider, so we operate on a different scale here, but one interesting trick that can be done with ISIS (at least on Cisco) is this:
router a ----------- router isis advertise passive-only
interface loopback0 ip address 10.1.1.1 255.255.255.255
interface vlan2 ip unnumbered loopback0 ip router isis isis network point-to-point
router b ----------- (copy router isis definition from router a)
interface loopback0 ip address 10.1.1.2 255.255.255.255
(copy vlan2 definition from router a)
-----------
This removes the associated headaches with /30s or /31s in having to keep track of their allocation, as well as having them clog the your routing table.
-waits for replies stating why this is a bad idea-
Now, if I could just get isis-per-vrf-instance support on the Catalyst 6500.
Jason One of my favorite features in IS-IS is the ability to set the overload bit during maintenance. The effect is the router on which you set it isn't seen by any other devices in the topology as a transit path, but you can still reach the router itself. I'm not as familiar with OSPF so I'm unsure if there is a similar feature, but I thought it was exclusive to IS-IS. Being able to easily limit the IGP size via the above technique is also a great benefit. You can basically get away with just your loopbacks.
-Vinny
On Sat, Aug 13, 2011 at 21:11, Vinny Abello <vinny@abellohome.net> wrote:
One of my favorite features in IS-IS is the ability to set the overload bit during maintenance. The effect is the router on which you set it isn't seen by any other devices in the topology as a transit path, but you can still reach the router itself. I'm not as familiar with OSPF so I'm unsure if there is a similar feature, but I thought it was exclusive to IS-IS. Being able to easily limit the IGP size via the above technique is also a great benefit. You can basically get away with just your loopbacks.
-Vinny
Cisco and Juniper both support this (overload) in OSPFv2 using the process described in RFC 3137. Juniper use the familiar 'overload' command under the OSPF configuration, Cisco use the 'max-metric router-lsa' [1] command under the OSPF config. Both should give similar results to ISIS overload. ~Matt 1: http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800ad...
participants (23)
-
Cameron Byrne -
CJ -
Doug Marschke -
Douglas Otis -
James Jones -
Jason Duerstock -
Jeff Wheeler -
Jeffrey S. Young -
jim deleskie -
Jimmy Hess -
Joel Jaeggli -
Justin M. Streiner -
Leigh Porter -
Matt Addison -
Paul -
Randy Bush -
Saku Ytti -
Scott Morris -
Stefan Fouant -
Tom Hill -
Tomas Lynch -
Vinny Abello -
William Cooper