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,
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/prese... https://www.nanog.org/meetings/nanog49/presentations/Sunday/Shamim_Which_Rou... https://www.nada.kth.se/kurser/kth/2D1490/03/papers/Comparitive_Study_of_OSP... -- Mikael Abrahamsson email: swmike@swm.pp.se
On Nov 9, 2018, at 10:03 AM, im <nanog@netfront.jp> 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
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 <nanog@netfront.jp> 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,
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 <nanog-bounces@nanog.org> 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,
Yeah there are those. Steve -----Original Message----- From: Valdis Kletnieks <valdis@vt.edu> On Behalf Of valdis.kletnieks@vt.edu Sent: Monday, November 12, 2018 2:29 PM To: Naslund, Steve <SNaslund@medline.com> Cc: nanog@nanog.org Subject: Re: IGP protocol On Mon, 12 Nov 2018 20:21:26 +0000, "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. :)
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/
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
On 13 Nov 2018, at 6:34 pm, Aled Morris via NANOG <nanog@nanog.org> wrote:
On Tue, 13 Nov 2018 at 05:54, Brandon Martin <lists.nanog@monmotha.net <mailto:lists.nanog@monmotha.net>> 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
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.
On Tue, 13 Nov 2018 at 12:37, Mark Tinka <mark.tinka@seacom.mu> 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
On Tue, 13 Nov 2018 at 12:09, Saku Ytti <saku@ytti.fi> wrote:
On Tue, 13 Nov 2018 at 12:37, Mark Tinka <mark.tinka@seacom.mu> 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.
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 <jwbensley@gmail.com>:
On Tue, 13 Nov 2018 at 12:09, Saku Ytti <saku@ytti.fi> wrote:
On Tue, 13 Nov 2018 at 12:37, Mark Tinka <mark.tinka@seacom.mu> 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.
Hello all. We also run a small network (sub 50 PEs) It looks pretty similar to Baldurs except we run IS-IS instead of OSPF. IPV4 only in the global table with VPNV4 and VPNv6 services running on top of it. We do run a separate OBM network to handle management without being dependent on service infrastructure for management. Only real difference we notice is that Cisco seem to roll out service provider features and knobs for IS-IS first and then eventually for OSPF. Good or bad is the question. //Gustav Från: NANOG <nanog-bounces@nanog.org> För Baldur Norddahl Skickat: den 15 november 2018 02:51 Till: nanog@nanog.org Ämne: Re: IGP protocol 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 <jwbensley@gmail.com<mailto:jwbensley@gmail.com>>: On Tue, 13 Nov 2018 at 12:09, Saku Ytti <saku@ytti.fi<mailto:saku@ytti.fi>> wrote:
On Tue, 13 Nov 2018 at 12:37, Mark Tinka <mark.tinka@seacom.mu<mailto:mark.tinka@seacom.mu>> 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.
On 15 November 2018 01:51:28 GMT, Baldur Norddahl <baldur.norddahl@gmail.com> 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 <jwbensley@gmail.com>:
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.
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 Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 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.
On Tue, 13 Nov 2018 at 16:27, Alain Hebert <ahebert@pubnix.net> 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
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.
On Sun, 18 Nov 2018 at 11:15, Mark Tinka <mark.tinka@seacom.mu> 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
On Sun, 18 Nov 2018 at 12:15, Alfie Pates <alfie@fdx.services> 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
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
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.
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
On Sun, 18 Nov 2018 at 21:07, Grant Taylor via NANOG <nanog@nanog.org> 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
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.
On Sun, 18 Nov 2018 at 17:35, Mark Tinka <mark.tinka@seacom.mu> 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
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.
From Asia region (Bhutan):
On 10 Nov 2018, at 1:03 am, im <nanog@netfront.jp> 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
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 <nanog@netfront.jp> 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,
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 <nanog@netfront.jp> 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,
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.
participants (24)
-
Alain Hebert -
Aled Morris -
Alfie Pates -
Baldur Norddahl -
Brandon Martin -
Grant Taylor -
Gustav Ulander -
im -
James Bensley -
Jared Mauch -
Jay Nugent -
Job Snijders -
Job Snijders -
Mark Tinka -
Matt Erculiani -
Mikael Abrahamsson -
Naslund, Steve -
Nick Hilliard -
Randy Bush -
Ryan Kearney -
Saku Ytti -
Tashi Phuntsho -
valdis.kletnieks＠vt.edu -
Victor Kuarsingh