Re: IGP protocol

[Mark Tinka]

On 18/Nov/18 18:00, Saku Ytti wrote:

> In 7600 it is simply not possible because of hardware limitation. I'd
> be surprised if 7600 was alone here.

I've never ran the 7600 (the 6500 was as close as I got, but that was
just purely for Ethernet switching).

While it wouldn't surprise me that shops were still running this
platform in 2018, it's starting to show its age...


> But does this actually matter? Probably not. I assume we have
> functional market, and if there was business case in having secure
> control-planes we would have them. Networks work because no one is
> motivated to attack the infrastructure, not because we can or have
> protected it.
> I expect in time of crisis all state actors can disable the
> infrastructure in matter of minutes, as they likely have collection of
> these problems that control-plane protection has. But we will probably
> fix the infrastructure in matter of days, so probably even then not a
> big deal.

Fair point.

Mark.

Re: IGP protocol

[Saku Ytti]

On Sun, 18 Nov 2018 at 21:07, Grant Taylor via NANOG  wrote:

> Is it not possible to protect (just) the eBGP with IPsec?

Not on all gears SPs are deploying. But people doing this.

> I would think that IPsec would provide the desired protection and that
> tuning filters to the proper ports would reduce the overhead that MACsec
> might incur with all traffic being encrypted.

Correct and more important being control-plane only feature, it's
significantly cheaper.

Personally I do trust HMAC-MD5 to offer sufficient security today.

-- 
  ++ytti

Re: IGP protocol

[Grant Taylor via NANOG]

Warning:  n00b level question, ignore at your own discretion.

On 11/18/18 3:59 AM, Saku Ytti wrote:
Not arguing that MacSec isn't superior feature, it's just cost of MacSec 
is non-trivial compared to cost of HMAC-MD5, and it seems HMAC-MD5 
for certain attacks is strong guarantee. Ideally we'd implement TCP-AO 
(RFC5925) to replace BGP HMAC-MD5, just to get derived secret instead 
of static (how many change their MD5 secret periodically?)  but it looks 
like ship may have sailed on that one.


Is it not possible to protect (just) the eBGP with IPsec?

I would think that IPsec would provide the desired protection and that 
tuning filters to the proper ports would reduce the overhead that MACsec 
might incur with all traffic being encrypted.


Does anyone have any real world experience to offer this n00b?

Thank you in advance.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IGP protocol

[Saku Ytti]

On Sun, 18 Nov 2018 at 17:35, Mark Tinka  wrote:

> I've found my fair share of IS-IS bugs since I began using it back in 2007 
> (when SRC ruled the roost on 7200/7600). What matters is that stuff gets 
> fixed.

In 7600 it is simply not possible because of hardware limitation. I'd
be surprised if 7600 was alone here.

But does this actually matter? Probably not. I assume we have
functional market, and if there was business case in having secure
control-planes we would have them. Networks work because no one is
motivated to attack the infrastructure, not because we can or have
protected it.
I expect in time of crisis all state actors can disable the
infrastructure in matter of minutes, as they likely have collection of
these problems that control-plane protection has. But we will probably
fix the infrastructure in matter of days, so probably even then not a
big deal.

-- 
  ++ytti

Re: IGP protocol

[Mark Tinka]

On 18/Nov/18 13:13, Nick Hilliard wrote:

>  
>
> one of the few uses for tcp/md5 protection on bgp sessions can be
> found at IXPs where if you have an participant leaving the fabric,
> there will often be leftover bgp sessions configured on other routers
> on the exchange.  Pre-configuring MD5 on BGP sessions will ensure that
> these cannot be used to spoof connectivity to the old network.

Except that exchange point members are notorious for not liking session
MD5 protection in the interest of keeping deployment simple. We made it
mandatory for peers 6 years ago. We had to loosen our stance a year
later :-).

Mark.

Re: IGP protocol

[Mark Tinka]

On 18/Nov/18 11:58, Saku Ytti wrote:

> Should. OSPF you can protect in edge with ACL. In ISIS you hope it's 
> protected.
>
> 7600 punts it in every interface, if one interface speaks ISIS,
> because it doesn't have per-interface punt masks.
>
> MX:
> 2012-10-18 0002096778/2012-1018-0446 (test13nqe3) (11.4R5) ++ytti
>   * ISIS gets to control-plane, even when only family inet is configured
>
> This was fixed on later releases.

While this isn't cool, I don't see this as a major issue when put up
against any other nasty's you find in vendor implementations. Find a
problem, report it to the vendor, work with them to fix it, close the hole.

I've found my fair share of IS-IS bugs since I began using it back in
2007 (when SRC ruled the roost on 7200/7600). What matters is that stuff
gets fixed.

>
> My point is, perhaps in theory ISIS is more secure, but in practice
> OSPF is, because  OSPF can be protected perfectly in iACL,  feature
> which is available in HW in cheapest L3 switches. Only reason people
> think different, is because they don't test it.

I would not be opposed to spending some time with you to hit IS-IS on
vendor platforms with known bugs fixed to prove this point.

Mark.

Re: IGP protocol

[Nick Hilliard]

Saku Ytti wrote on 18/11/2018 10:59:

AFAIK there are no known attacks against HMAC-MD5. eBGP I don't care
about. But for iBGP I consider this a problem:


one of the few uses for tcp/md5 protection on bgp sessions can be found 
at IXPs where if you have an participant leaving the fabric, there will 
often be leftover bgp sessions configured on other routers on the 
exchange.  Pre-configuring MD5 on BGP sessions will ensure that these 
cannot be used to spoof connectivity to the old network.


Nick

Re: IGP protocol

[Saku Ytti]

On Sun, 18 Nov 2018 at 12:15, Alfie Pates  wrote:

> There's a school of thought which suggests MD5 security on single-hop BGP is 
> absolute theatre with no security benefit and that MACsec is the route you 
> should be taking.

AFAIK there are no known attacks against HMAC-MD5. eBGP I don't care
about. But for iBGP I consider this a problem:

Someone goes to random forest where fibre is trenched, digs it up,
taps fibre until correct fibre+wave is found, then injects BGP UPDATE
to change L3 MPLS VPN labels, and diverts traffic through their device
while returning it safely. Seems quite cheap attack, maybe <5k, and
entirely compromises MPLS security model. iBGP MD5 should protect well
from this.

Not arguing that MacSec isn't superior feature, it's just cost of
MacSec is non-trivial compared to cost of HMAC-MD5, and it seems
HMAC-MD5 for certain attacks is strong guarantee. Ideally we'd
implement TCP-AO (RFC5925) to replace BGP HMAC-MD5, just to get
derived secret instead of static (how many change their MD5 secret
periodically?)  but it looks like ship may have sailed on that one.

-- 
  ++ytti

Re: IGP protocol

[Alfie Pates]

> or MacSec

There's a school of thought which suggests MD5 security on single-hop BGP is 
absolute theatre with no security benefit and that MACsec is the route you 
should be taking. 

~ a

Re: IGP protocol

[Saku Ytti]

On Sun, 18 Nov 2018 at 11:15, Mark Tinka  wrote:

> Yes, IS-IS is designed to speak to connected hosts, but will only do so if 
> you enable IS-IS on the interface facing that host.
> The scope of the exposure, while present, is limited to the radius between 
> your device and the connected host, vs. OSPF which can be attacked from much 
> farther away.

Should. OSPF you can protect in edge with ACL. In ISIS you hope it's protected.

7600 punts it in every interface, if one interface speaks ISIS,
because it doesn't have per-interface punt masks.

MX:
2012-10-18 0002096778/2012-1018-0446 (test13nqe3) (11.4R5) ++ytti
  * ISIS gets to control-plane, even when only family inet is configured

This was fixed on later releases.


Those are only two devices I've specifically tested for this. I don't
think people know what happens to ISIS in their platform, if vendor
doesn't know. I wonder what these nice BRCM kit do? I know that one of
the more popular entrant can't be protected against ANY protocol until
2019Q1, and two of the networks I know running it in the edge, were
entirely unaware of it.

My point is, perhaps in theory ISIS is more secure, but in practice
OSPF is, because  OSPF can be protected perfectly in iACL,  feature
which is available in HW in cheapest L3 switches. Only reason people
think different, is because they don't test it.

> Running MD5 on your IGP (and iBGP) should be sold at birth.

Yes, or MacSec.

-- 
  ++ytti

Re: IGP protocol

[Mark Tinka]

On 16/Nov/18 15:04, Victor Kuarsingh wrote:

> 3. Based on your vendor preference / selection, how well does each
> fair on your platform of choice ? (Most major vendors do a good job on
> both, but there are considerations)

IS-IS is notoriously bad in Quagga.

I met with some of the developers of FRRouting and was happy to learn
that they've made plenty of strides with pushing IS-IS for production.
I'm going to install and test it, as it would be good to stop having to
redistribute from OSPF into IS-IS for my Anycast name servers.

Mark.

Re: IGP protocol

[Mark Tinka]

On 14/Nov/18 02:24, im wrote:

> Thanks for all to letting me know.
>
> I have operating OSPF/iBGP backbone for 10+ years, now my brain has
> entrenched to OSPF.
> Now, I beginning to learn IS-IS for more knowledge.

More power to you :-).

Mark.

Re: IGP protocol

[Mark Tinka]

On 13/Nov/18 17:30, Saku Ytti wrote:

> Do you know connected host can't talk ISIS to you?
>
> ISIS is false security. In modern platforms OSPF almost always can be
> protected (iACL), ISIS in many times cannot. I'd run MD5 in either
> case.

Yes, IS-IS is designed to speak to connected hosts, but will only do so
if you enable IS-IS on the interface facing that host.

The scope of the exposure, while present, is limited to the radius
between your device and the connected host, vs. OSPF which can be
attacked from much farther away.

Running MD5 on your IGP (and iBGP) should be sold at birth.

Mark.

Re: IGP protocol

[Victor Kuarsingh]

IM,

Some good comments on this thread so far.

Having chosen between OSPF and IS-IS more then once over the past 20 years
for various networks and have chosen differently in some cases.  I have a
general preference for IS-IS in very large networks, but OSPF has performed
well for me in larger nertowrks as well.  I would say at this point, they
both can do the same basic job with a few benefits attributable to each of
them.  With OSPFv3 now more mature, I am sure there may have been a few
classic selections of IS-IS that may no longer go that way (+10 years ago,
many with OSPFv2 networks turned on IS-IS since OSPFv3 implementations were
quite new and IPv6 was staring to come online on backbones).

Anyone turning on either IGP today, the major considerations (in my mind
would be).

1. Which protocol do you have the operational staff to support? (Someone
has to fix things when broken, so what talent do you have in ops?)
2. What protocol design capabilities do you have? (Good designers can learn
either protocol, but historical experience can help in some cases)
3. Based on your vendor preference / selection, how well does each fair on
your platform of choice ? (Most major vendors do a good job on both, but
there are considerations)
5. Some people like that IS-IS is not based on IP and operates directly
over Layer-2 (some arguable benefits in security domain - but you can
secure both)
6. You running IPv4 and/or IPv6 on your underlay? (If you are running v4
only and use overlay for v4/v6 - some like the maturity of the OSPFv2
implementation)
7. Considerations for how you want your areas to run (some key differences
in how L1/L2 areas work in IS-IS along with how boundaries work vs. OSPF
areas and boundaries).
8. Route types.  In some networks, folks want to import routes from other
protocols (sometimes incoming protocols running at edges of networks etc).
If you have that, you may want to consider how you want routes to operate.

Regards,

Victor K






On Mon, Nov 12, 2018 at 2:45 PM im  wrote:

> goodmorning nanog,
>
> I heard that OSPF is only famous in asia region...
> So that, please could you explain me
>
>   1. what is your backbone's IGP protocol?
>   2. why you choose it?
>
>
> thanks,
>

Re: IGP protocol

[Job Snijders]

Let’s please stay on topic.

Re: IGP protocol

[Matt Erculiani]

X11 forwarding -> WINE -> notepad.exe

On Fri, Nov 16, 2018, 06:06 Jay Nugent  On Fri, 16 Nov 2018, Randy Bush wrote:
>
> >> I heard that OSPF is only famous in asia region...
> >> So that, please could you explain me
> >>
> >>   1. what is your backbone's IGP protocol?
> >
> > emacs
> >
>
> vi
>
>
>

Re: IGP protocol

[Jay Nugent]

On Fri, 16 Nov 2018, Randy Bush wrote:


I heard that OSPF is only famous in asia region...
So that, please could you explain me

  1. what is your backbone's IGP protocol?


emacs



   vi

Re: IGP protocol

[Randy Bush]

> I heard that OSPF is only famous in asia region...
> So that, please could you explain me
> 
>   1. what is your backbone's IGP protocol?

emacs

Re: IGP protocol

[James Bensley]

On 15 November 2018 01:51:28 GMT, Baldur Norddahl  
wrote:
>Also not true that the management network is the last thing to boot. In
>contrary, everything else depends on that being ready first. And that
>would
>also be true if we used is-is.

It is when you out management in a VRF...

>ons. 14. nov. 2018 14.55 skrev James Bensley :
>
>>  Several networks I've seen place
>management
>> in a VRF / L3 VPN, which means that by the time you have remote
>> management access, everything else is already working, it's like the
>> last thing to come up when there's been a problem


Cheers,
James.

Re: IGP protocol

[Baldur Norddahl]

We run a MPLS enabled network with internet in a VRF. Management is in VRF
default (no VRF). The IGP is OSPFv2. IPv6 is handled by the L3VPN
functionality of MPLS. So is IPv4.

The IPv4 that is controlled by OSPF is totally separate from everything
except management and could really be any protocol. For a small network
like ours, with everything in area 0 and VRF/L3VPN to handle dual stack,
there is zero differences between is-is and OSPF. The IPv4 management
network is not any more reachable than the is-is protocol. There are no raw
IPv6 packets on the wire and no need for the IGP to handle IPv6.

Also not true that the management network is the last thing to boot. In
contrary, everything else depends on that being ready first. And that would
also be true if we used is-is.

We chose OSPF because it was one less protocol to learn and one less
ethernet type on the wire. But really it could be toss a coin.

Regards

Baldur


ons. 14. nov. 2018 14.55 skrev James Bensley :

> On Tue, 13 Nov 2018 at 12:09, Saku Ytti  wrote:
> >
> > On Tue, 13 Nov 2018 at 12:37, Mark Tinka  wrote:
> >
> > > Main reasons:
> > > - Doesn't run over IP.
> >
> > Why is this upside? I've seen on two platforms (7600, MX) ISIS punted
> > on routers running ISIS without interface having ISIS.  With no
> > ability to limit it, so any connected interface can DoS device with
> > trivial pps rate, if ISIS is being ran.
>
> I guess the OPs original question wasn't clear enough because, I think
> most people are talking about IS-IS vs OSPF2/3 from a theoretical
> protocol perspective, and you're talking from a practical vendor
> implementation perspective.
>
> From a purely theoretical perspective I see IS-IS not running over IP
> as an advantage too. No mater what routes I inject into my IGP, IS-IS
> won't stop working. I may totally fsck my IP reachability but IS-IS
> will still work, which means that when I fix the issue, service should
> be restored quite quickly. Several networks I've seen place management
> in a VRF / L3 VPN, which means that by the time you have remote
> management access, everything else is already working, it's like the
> last thing to come up when there's been a problem. I like the
> "management in the IGP + IS-IS" design.
>
> However, in reality the vendor implementation blows the protocol
> design out of the water. You need to consider both when evaluating a
> new IGP. Cisco nearly implemented a handy feature with
> prefix-suppression, whereby in IOS for OSPF only one would prevent
> p-t-p links being advertised into the IGP database. But they didn't
> implement this for IS-IS. Then in IOS-XR they removed this feature
> from OSPF and implemented it for IS-IS ?!?! So yeah, vendors
> implementations are just as important and the theoretical potential of
> the protocol.
>
> Oh yeah, forgot to answer the original question. For a greenfield
> deployment I'd be happy with either OSPFv3 or IS-IS as long as it's
> well designed I don't see much between them, it would come down to
> vendor support then.
>
> Cheers,
> James.
>

Re: IGP protocol

[Tashi Phuntsho]

From Asia region (Bhutan):

> On 10 Nov 2018, at 1:03 am, im  wrote:
> 
> I heard that OSPF is only famous in asia region…

Not necessarily :-)

>  1. what is your backbone's IGP protocol?

IS-IS

>  2. why you choose it?

OSPFv3 was quite flaky (could have been OS bugs), and there wasn’t v4 support 
until rfc5838, so migrated to IS-IS when deploying v6 (with Philip Smith’s 
help).

But preferred multi topology to allow for incremental v6 deployment (without 
affecting v4).

—
Tashi

Re: IGP protocol

[Tashi Phuntsho]

> On 13 Nov 2018, at 6:34 pm, Aled Morris via NANOG  wrote:
> 
> On Tue, 13 Nov 2018 at 05:54, Brandon Martin  > wrote:
> I was of the impression that there was a draft or similar for 
> single-topology (IPv4+IPv6) OSPF.  Did anything ever come of that?
> 
> 
> Juniper support IPv4 families ("realms") in OSPFv3.

Available on IOS too.

Problem for an ISP (OSPFv3 with AFs): if v6 breaks, v4 breaks too since OSPFv3 
runs over v6 (even when carrying v4 AF)? Better with separate OSPFv2 and v3 
instances.

—
Tashi

Re: IGP protocol

[im]

Thanks for all to letting me know.

I have operating OSPF/iBGP backbone for 10+ years, now my brain has
entrenched to OSPF.
Now, I beginning to learn IS-IS for more knowledge.

thanks!
On Sat, Nov 10, 2018 at 12:03 AM im  wrote:
>
> goodmorning nanog,
>
> I heard that OSPF is only famous in asia region...
> So that, please could you explain me
>
>   1. what is your backbone's IGP protocol?
>   2. why you choose it?
>
>
> thanks,

Re: IGP protocol

[James Bensley]

On Tue, 13 Nov 2018 at 12:09, Saku Ytti  wrote:
>
> On Tue, 13 Nov 2018 at 12:37, Mark Tinka  wrote:
>
> > Main reasons:
> > - Doesn't run over IP.
>
> Why is this upside? I've seen on two platforms (7600, MX) ISIS punted
> on routers running ISIS without interface having ISIS.  With no
> ability to limit it, so any connected interface can DoS device with
> trivial pps rate, if ISIS is being ran.

I guess the OPs original question wasn't clear enough because, I think
most people are talking about IS-IS vs OSPF2/3 from a theoretical
protocol perspective, and you're talking from a practical vendor
implementation perspective.

>From a purely theoretical perspective I see IS-IS not running over IP
as an advantage too. No mater what routes I inject into my IGP, IS-IS
won't stop working. I may totally fsck my IP reachability but IS-IS
will still work, which means that when I fix the issue, service should
be restored quite quickly. Several networks I've seen place management
in a VRF / L3 VPN, which means that by the time you have remote
management access, everything else is already working, it's like the
last thing to come up when there's been a problem. I like the
"management in the IGP + IS-IS" design.

However, in reality the vendor implementation blows the protocol
design out of the water. You need to consider both when evaluating a
new IGP. Cisco nearly implemented a handy feature with
prefix-suppression, whereby in IOS for OSPF only one would prevent
p-t-p links being advertised into the IGP database. But they didn't
implement this for IS-IS. Then in IOS-XR they removed this feature
from OSPF and implemented it for IS-IS ?!?! So yeah, vendors
implementations are just as important and the theoretical potential of
the protocol.

Oh yeah, forgot to answer the original question. For a greenfield
deployment I'd be happy with either OSPFv3 or IS-IS as long as it's
well designed I don't see much between them, it would come down to
vendor support then.

Cheers,
James.

Re: IGP protocol

[Saku Ytti]

On Tue, 13 Nov 2018 at 16:27, Alain Hebert  wrote:

> For those that got involved in fixing a network that goes down due to 
> OSPF spoofed packets...  (Before OSPFv2|3)
> + Security for IS-IS

Do you know connected host can't talk ISIS to you?

ISIS is false security. In modern platforms OSPF almost always can be
protected (iACL), ISIS in many times cannot. I'd run MD5 in either
case.

-- 
  ++ytti

Re: IGP protocol

[Alain Hebert]

    Hi,

    For those that got involved in fixing a network that goes down due 
to OSPF spoofed packets...  (Before OSPFv2|3)


    + Security for IS-IS

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 11/13/18 05:34, Mark Tinka wrote:



On 9/Nov/18 17:03, im wrote:


   1. what is your backbone's IGP protocol?


IS-IS.


   2. why you choose it?


Main reasons:

    - Stringy, i.e., no "all must pay taxes to Area 0" decree.
    - Integrated for IPv4 and IPv6.
    - Doesn't run over IP.

Mark.

Re: IGP protocol

[Saku Ytti]

On Tue, 13 Nov 2018 at 12:37, Mark Tinka  wrote:

> Main reasons:
> - Doesn't run over IP.

Why is this upside? I've seen on two platforms (7600, MX) ISIS punted
on routers running ISIS without interface having ISIS.  With no
ability to limit it, so any connected interface can DoS device with
trivial pps rate, if ISIS is being ran. Are you testing this vector?

Also, no one really understands how 802.3+CLNS interact with ISIS.
It's probably globally dozen people, all open source implementations
seem to copy from early Zebra implementation. And implementations are
opportunistic, just enough to make it work, not actually enough to be
standard compliant 802.3+CLNS. Just question of what is ES-IS role in
all this, gives debates with subject matter experts.

To me this is downside, I'd rather have ISIS run over EthernetII and
IP. But at that point, why bother, why not just kill it and run OSPF3.
I'm paying vendor to implement and maintain both protocols, and there
does not seem to have good justification for both to exist.

Disclaimer: all networks I've operated have been ISIS networks, and
I'll continue using ISIS, not because I think it is better, but
because I think the codebase gets more exposure in networks like the
on I need to run.

-- 
  ++ytti

Re: IGP protocol

[Mark Tinka]

On 13/Nov/18 07:52, Brandon Martin wrote:

>  
>
> I was of the impression that there was a draft or similar for
> single-topology (IPv4+IPv6) OSPF.  Did anything ever come of that?

Multiple Address Families in OSPFv3.

But NLRI is conveyed over IPv6, even for IPv4. First saw it in Junos 9,
way back when.

Mark.

Re: IGP protocol

[Mark Tinka]

On 9/Nov/18 17:03, im wrote:

>
>   1. what is your backbone's IGP protocol?

IS-IS.

>   2. why you choose it?

Main reasons:

    - Stringy, i.e., no "all must pay taxes to Area 0" decree.
    - Integrated for IPv4 and IPv6.
    - Doesn't run over IP.

Mark.

Re: IGP protocol

[Aled Morris via NANOG]

On Tue, 13 Nov 2018 at 05:54, Brandon Martin 
wrote:

> I was of the impression that there was a draft or similar for
> single-topology (IPv4+IPv6) OSPF.  Did anything ever come of that?
>
>
Juniper support IPv4 families ("realms") in OSPFv3.

Aled

Re: IGP protocol

[Garrett Skjelstad]

To be fair, Microsoft only just recently added BGP support to RRAS in
2012...



On Mon, Nov 12, 2018, 21:50 Scott Weeks 
>
> --- valdis.kletni...@vt.edu wrote:
> On Mon, 12 Nov 2018 20:21:26 +, "Naslund, Steve"
> said:
>
> > 2.  Most corporate networks will be running OSPF
> and/or EIGRP as an IGP.
>
> And I'm sure there's still some crazies out there
> using RIPv2. :)
> --
>
>
> Yes, there are networks out there on the ragged edges
> doing that.  They've been around since forever.  I've
> worked for them.  Show up on day 1: WTF???  Oh crap,
> what'd I get myself into *this* time?!
>
> scott
>
>

Re: IGP protocol

[Brandon Martin]

On 11/12/18 3:21 PM, Naslund, Steve wrote:

1.  Most large networks (service providers) supporting MPLS will be using ISIS 
as their IGP.  Some will have islands of OSPF because not everything speaks 
ISIS.


Notably, support for OSPF is somewhat common on "layer 3 switch" 
products while IS-IS support is significantly less common.


Most "router" products seem to support either.

I was of the impression that there was a draft or similar for 
single-topology (IPv4+IPv6) OSPF.  Did anything ever come of that?

--
Brandon Martin

Re: IGP protocol

[Scott Weeks]

--- valdis.kletni...@vt.edu wrote:
On Mon, 12 Nov 2018 20:21:26 +, "Naslund, Steve" 
said:

> 2.  Most corporate networks will be running OSPF 
and/or EIGRP as an IGP.

And I'm sure there's still some crazies out there 
using RIPv2. :)
--


Yes, there are networks out there on the ragged edges 
doing that.  They've been around since forever.  I've 
worked for them.  Show up on day 1: WTF???  Oh crap, 
what'd I get myself into *this* time?!

scott

RE: IGP protocol

[Naslund, Steve]

Yeah there are those.  

Steve

-Original Message-
From: Valdis Kletnieks  On Behalf Of valdis.kletni...@vt.edu
Sent: Monday, November 12, 2018 2:29 PM
To: Naslund, Steve 
Cc: nanog@nanog.org
Subject: Re: IGP protocol

On Mon, 12 Nov 2018 20:21:26 +, "Naslund, Steve" said:

> 2.  Most corporate networks will be running OSPF and/or EIGRP as an IGP.

And I'm sure there's still some crazies out there using RIPv2. :)

Re: IGP protocol

[Job Snijders]

The war is over.

In IETF the OSPF and ISIS working groups merged. Now all of it is
“link-state routing”.

https://datatracker.ietf.org/group/lsr/about/

Re: IGP protocol

[valdis . kletnieks]

On Mon, 12 Nov 2018 20:21:26 +, "Naslund, Steve" said:

> 2.  Most corporate networks will be running OSPF and/or EIGRP as an IGP.

And I'm sure there's still some crazies out there using RIPv2. :)


pgpPMFjssCptV.pgp
Description: PGP signature

RE: IGP protocol

[Naslund, Steve]

I don't know where you heard that but it is probably incorrect.  Here is what I 
think you will find.

1.  Most large networks (service providers) supporting MPLS will be using ISIS 
as their IGP.  Some will have islands of OSPF because not everything speaks 
ISIS.
2.  Most corporate networks will be running OSPF and/or EIGRP as an IGP.

Steven Naslund
Chicago IL

-Original Message-
From: NANOG  On Behalf Of im
Sent: Friday, November 9, 2018 9:03 AM
To: nanog@nanog.org
Subject: IGP protocol

goodmorning nanog,

I heard that OSPF is only famous in asia region...
So that, please could you explain me

  1. what is your backbone's IGP protocol?
  2. why you choose it?


thanks,

Re: IGP protocol

[Ryan Kearney via NANOG]

1. IS-IS for loopbacks and iBGP on the loopbacks for everything else.
2. It was much easier to use than OSPF and seems to scale better.
On Mon, Nov 12, 2018 at 1:46 PM im  wrote:
>
> goodmorning nanog,
>
> I heard that OSPF is only famous in asia region...
> So that, please could you explain me
>
>   1. what is your backbone's IGP protocol?
>   2. why you choose it?
>
>
> thanks,

Re: IGP protocol

[Jared Mauch]

> On Nov 9, 2018, at 10:03 AM, im  wrote:
> 
> goodmorning nanog,
> 
> I heard that OSPF is only famous in asia region...
> So that, please could you explain me
> 
>  1. what is your backbone's IGP protocol?

IS-IS

>  2. why you choose it?

Single topology, supported by everything for IPv6 and IP(classic).

- jared

Re: IGP protocol

[Mikael Abrahamsson]

On Sat, 10 Nov 2018, im wrote:


goodmorning nanog,

I heard that OSPF is only famous in asia region...
So that, please could you explain me

 1. what is your backbone's IGP protocol?
 2. why you choose it?


This is a 20+ year old discussion. There are lots of comparisons.

https://nsrc.org/workshops/2017/ubuntunet-bgp-nrens/networking/nren/en/presentations/08-ISIS-vs-OSPF.pdf
https://www.nanog.org/meetings/nanog49/presentations/Sunday/Shamim_Which_Routing_N49.pdf
https://www.nada.kth.se/kurser/kth/2D1490/03/papers/Comparitive_Study_of_OSPF_and_ISIS.txt

--
Mikael Abrahamssonemail: swm...@swm.pp.se