Re: Vint Cerf & Interplanetary Internet

[Mark Andrews]

It wouldn’t be NANOG.  Perhaps LUNOG or MOONOG.

> On 22 Oct 2020, at 14:07, scott weeks  wrote:
> 
> 
> *From:* NANOG  on behalf of Rod 
> Beck 
>> https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
> 
> 
> On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:
> 
> Right. This means we are going to catch a spaceship for a future nanog / have
> interplanetary governance federation debates with space aliens from Andromeda,
> and we will finally run out of v6 and ipv9 will rule the roost while there’s a
> substantial aftermarket + hijack scene going on for the last remaining v6 
> blocks.
> 
> 
> 
> More like IP to Nokia's new cell network on the moon:
> 
> https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
> (Everyone on the moon will want to have access to LOL cats!)
> 
> Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to reach Mars and 
> other
> planets by being relayed through communications relay satellites similar to 
> the
> Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
> Reconnaissance Orbiter spacecraft.
> 
> Or... IP to robots visiting other non-planet objects in the solar system like
> comets/asteroids:
> https://spacenews.com/osiris-rex-touches-down-on-asteroid
> https://www.bbc.com/news/science-environment-47293317
> 
> Or... 
> 
> The IPI idea has been around for a long time now:
> https://en.wikipedia.org/wiki/Interplanetary_Internet
> 
> The main question is will NANOG On The Road meet on the moon?  I missed
> the only Hawaii one, so maybe I could make the moon one!
> 
> scott

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Vint Cerf & Interplanetary Internet

[scott weeks]

*From:* NANOG  on behalf of 
Rod Beck 

https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/



On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:

Right. This means we are going to catch a spaceship for a future nanog / 
have
interplanetary governance federation debates with space aliens from 
Andromeda,
and we will finally run out of v6 and ipv9 will rule the roost while 
there’s a
substantial aftermarket + hijack scene going on for the last remaining 
v6 blocks.




More like IP to Nokia's new cell network on the moon:

https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
(Everyone on the moon will want to have access to LOL cats!)

Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to reach 
Mars and other
planets by being relayed through communications relay satellites similar 
to the

Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
Reconnaissance Orbiter spacecraft.

Or... IP to robots visiting other non-planet objects in the solar system 
like

comets/asteroids:
https://spacenews.com/osiris-rex-touches-down-on-asteroid
https://www.bbc.com/news/science-environment-47293317

Or... 

The IPI idea has been around for a long time now:
https://en.wikipedia.org/wiki/Interplanetary_Internet

The main question is will NANOG On The Road meet on the moon?  I missed
the only Hawaii one, so maybe I could make the moon one!

scott

Re: Vint Cerf & Interplanetary Internet

[Joly MacFie]

It should be mentioned that the IPN SIG is lately revitalized, had
elections, and is actively forming Working Groups.

http://ipnsig.org/

On Wed, Oct 21, 2020 at 7:20 PM Rod Beck 
wrote:

>
> https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
>
> Roderick Beck
> VP of Business Development
>
> United Cable Company
>
> www.unitedcablecompany.com
>
> New York City & Budapest
>
> rod.b...@unitedcablecompany.com
>
> Budapest: 36-70-605-5144
>
> NJ: 908-452-8183
>
>
> [image: 1467221477350_image005.png]
>


-- 
--
Joly MacFie  +2185659365
--
-

Re: Circuit ordering software

[Yardiel Fuentes]

I know of 2 Cloud Providers nicely offer URLs and APIs to their users for
circuit ordering, provisioning and some circuit changes...So, customers
have the convenience of tapping into APIs from their own systems
infrastructure...(so, no circuit ordering software clients needed -- just
API scripting would be sufficient)...

Yardiel Fuentes

On Wed, Oct 21, 2020 at 4:39 PM Oliver Rothschild 
wrote:

> For those that have circuit ordering mechanisms in their environment, what
> sort of software do you use?
>
> respectfully,
> OIiver
> Network Engineer
>


-- 
Yardiel Fuentes

AS203 (CenturyLink/Qwest/Level3/Lumen) hijack report

[Töma Gavrichenkov]

Peace,

Following up on the today's massive partial network outage, here's the
analysis of what actually happened with the AS203's hijack, which is
the first one for the newly founded Lumen Technologies.

https://blog.qrator.net/en/lumen-aka-centurylink-generating-routing-incidents_101/

--
Töma

Re: Vint Cerf & Interplanetary Internet

[Suresh Ramasubramanian]

Right. This means we are going to catch a spaceship for a future nanog / have 
interplanetary governance federation debates with space aliens from Andromeda, 
and we will finally run out of v6 and ipv9 will rule the roost while there’s a 
substantial aftermarket + hijack scene going on for the last remaining v6 
blocks.

--srs

From: NANOG  on behalf of Rod Beck 

Sent: Thursday, October 22, 2020 4:50:25 AM
To: nanog@nanog.org 
Subject: Vint Cerf & Interplanetary Internet

https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/


Roderick Beck

VP of Business Development

United Cable Company

www.unitedcablecompany.com<http://www.unitedcablecompany.com>

New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183


[1467221477350_image005.png]

Re: A study on community-triggered updates in BGP

[Jeff Tantsura]

Hi Thomas,

We had a similar discussion on FRR slack, there are some duplicates indeed.
Are you planing to test FRR at some point in time?

Cheers,
Jeff
On Oct 21, 2020, 3:58 PM -0700, Jakob Heitz (jheitz) via NANOG 
, wrote:
> Thomas,
>
> I confirmed your case and took a look at the code.
> The outbound duplicate suppression function tries to detect
> duplicates without actually storing or recreating the
> previously sent update, so it misses some cases.
>
> Your use case is a good one. We will check to see if we can
> detect it without compromising significantly on resource usage.
> Thank you for raising the issue.
>
> Regards,
> Jakob.
>
> -Original Message-
> Date: Tue, 20 Oct 2020 04:48:37 -0700
> From: Thomas Krenc 
>
> Hi Jakob.
>
> The simple configuration below allows communities to be forwarded
> (send-community-ebgp), but are cleaned at egress (using route-policy and
> community-set).
>
> In the experiment, the router receives announcements with altering
> community attributes only, from the internal peer. After the filter is
> applied, the router sends duplicates to the external peer.
>
> Also, In a slightly different setup, the router sends duplicates due to
> changes in the next-hop only.
>
> best regards
> Thomas
>
> ---
>
> RP/0/0/CPU0:ios(config)#show running-config
> Tue Oct 20 02:56:24.230 UTC
> Building configuration...
> !! IOS XR Configuration 6.0.1
> !! Last configuration change at Tue Oct 20 02:56:02 2020 by cisco
> !
> interface MgmtEth0/0/CPU0/0
> ?shutdown
> !
> interface GigabitEthernet0/0/0/0
> ?ipv4 address 10.12.0.2 255.255.255.252
> !
> interface GigabitEthernet0/0/0/1
> ?ipv4 address 10.20.0.1 255.255.255.252
> !
> community-set all
> ? *:*
> end-set
> !
> route-policy nofilter
> ? pass
> end-policy
> !
> route-policy egressfilter
> ? delete community in all
> ? pass
> end-policy
> !
> router bgp 65002
> ?bgp router-id 10.12.0.2
> ?address-family ipv4 unicast
> !
> ?neighbor 10.12.0.1
> ? remote-as 65001
> ? address-family ipv4 unicast
> ?? send-community-ebgp
> ?? route-policy egressfilter out
> !
> ?neighbor 10.20.0.2
> ? remote-as 65002
> ? address-family ipv4 unicast
> !
> end
>
> On 10/17/20 3:59 PM, Jakob Heitz (jheitz) via NANOG wrote:
> > IOS-XR has duplicate update suppression logic for EBGP sessions,
> > not for IBGP sessions.
> >
> > If you are using EBGP and seeing a fault in the duplicate update
> > suppression logic in IOS-XR, please let me know configs and details
> > of the experiment.
> >
> > Regards,
> > Jakob.
> >
> > -Original Message-
> > Date: Thu, 15 Oct 2020 18:35:58 -0700
> > From: Thomas Krenc 
> >
> > Dear NANOG,
> >
> > As a team of researchers from NPS and TU Berlin, we are investigating
> > the impact of BGP community attributes on the update behavior between ASes.
> >
> > We find that when a route is associated with multiple distinct community
> > attributes it does not only lead to multiple announcement at the tagging
> > AS, but also at neighboring ASes, if communities are not filtered
> > properly. This behavior is wide-spread.
> >
> > In order to better understand our observations, we have performed a
> > series of laboratory experiments using Cisco IOS, Junos OS, as well as
> > the BIRD daemon.
> >
> > We find that - by default - all tested routers generate announcements
> > with changing community attributes, even when other attributes do not
> > change. In addition, when communities are filtered at egress, Cisco und
> > BIRD send duplicate announcements (Juniper does not).
> >
> > Since our findings are limited to observations in public data as well as
> > few router implementations, we would like to share our research and
> > kindly ask you to have a look at:
> >
> > ??? https://www.cmand.org/communityexploration/
> >
> > There, we provide some resources documenting our research, as well as
> > open questions. We greatly appreciate any feedback and insights you can
> > offer. Also, please don't hesitate to contact us directly:
> >
> > ??? communityexploration AT cmand DOT org
> >
> > best regards
> >
> > Thomas Krenc
> > Postdoctoral Researcher
> > Naval Postgraduate School

Vint Cerf & Interplanetary Internet

[Rod Beck]

https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/


Roderick Beck

VP of Business Development

United Cable Company

www.unitedcablecompany.com<http://www.unitedcablecompany.com>

New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183


[1467221477350_image005.png]

Re: A study on community-triggered updates in BGP

[Jakob Heitz (jheitz) via NANOG]

Thomas,

I confirmed your case and took a look at the code.
The outbound duplicate suppression function tries to detect
duplicates without actually storing or recreating the
previously sent update, so it misses some cases.

Your use case is a good one. We will check to see if we can
detect it without compromising significantly on resource usage.
Thank you for raising the issue.

Regards,
Jakob.

-Original Message-
Date: Tue, 20 Oct 2020 04:48:37 -0700
From: Thomas Krenc 

Hi Jakob.

The simple configuration below allows communities to be forwarded
(send-community-ebgp), but are cleaned at egress (using route-policy and
community-set).

In the experiment, the router receives announcements with altering
community attributes only, from the internal peer. After the filter is
applied, the router sends duplicates to the external peer.

Also, In a slightly different setup, the router sends duplicates due to
changes in the next-hop only.

best regards
Thomas

---

RP/0/0/CPU0:ios(config)#show running-config
Tue Oct 20 02:56:24.230 UTC
Building configuration...
!! IOS XR Configuration 6.0.1
!! Last configuration change at Tue Oct 20 02:56:02 2020 by cisco
!
interface MgmtEth0/0/CPU0/0
?shutdown
!
interface GigabitEthernet0/0/0/0
?ipv4 address 10.12.0.2 255.255.255.252
!
interface GigabitEthernet0/0/0/1
?ipv4 address 10.20.0.1 255.255.255.252
!
community-set all
? *:*
end-set
!
route-policy nofilter
? pass
end-policy
!
route-policy egressfilter
? delete community in all
? pass
end-policy
!
router bgp 65002
?bgp router-id 10.12.0.2
?address-family ipv4 unicast
!
?neighbor 10.12.0.1
? remote-as 65001
? address-family ipv4 unicast
?? send-community-ebgp
?? route-policy egressfilter out
!
?neighbor 10.20.0.2
? remote-as 65002
? address-family ipv4 unicast
!
end

On 10/17/20 3:59 PM, Jakob Heitz (jheitz) via NANOG wrote:
> IOS-XR has duplicate update suppression logic for EBGP sessions,
> not for IBGP sessions.
>
> If you are using EBGP and seeing a fault in the duplicate update
> suppression logic in IOS-XR, please let me know configs and details
> of the experiment.
>
> Regards,
> Jakob.
>
> -Original Message-
> Date: Thu, 15 Oct 2020 18:35:58 -0700
> From: Thomas Krenc 
>
> Dear NANOG,
>
> As a team of researchers from NPS and TU Berlin, we are investigating
> the impact of BGP community attributes on the update behavior between ASes.
>
> We find that when a route is associated with multiple distinct community
> attributes it does not only lead to multiple announcement at the tagging
> AS, but also at neighboring ASes, if communities are not filtered
> properly. This behavior is wide-spread.
>
> In order to better understand our observations, we have performed a
> series of laboratory experiments using Cisco IOS, Junos OS, as well as
> the BIRD daemon.
>
> We find that - by default - all tested routers generate announcements
> with changing community attributes, even when other attributes do not
> change. In addition, when communities are filtered at egress, Cisco und
> BIRD send duplicate announcements (Juniper does not).
>
> Since our findings are limited to observations in public data as well as
> few router implementations, we would like to share our research and
> kindly ask you to have a look at:
>
> ??? https://www.cmand.org/communityexploration/
>
> There, we provide some resources documenting our research, as well as
> open questions. We greatly appreciate any feedback and insights you can
> offer. Also, please don't hesitate to contact us directly:
>
> ??? communityexploration AT cmand DOT org
>
> best regards
>
> Thomas Krenc
> Postdoctoral Researcher
> Naval Postgraduate School

Re: cheap MPLS router recommendations

[Brandon Martin]

On 10/21/20 4:27 PM, adamv0...@netconsultings.com wrote:

Just to clarify what cheap means, ideally  -$2000 to $4000 new

-new is preferred as buying used kit on second hand market one is at the 
mercy of the price fluctuations and availability.




Do you want SFP or BASE-T on the 1Gb ports?
--
Brandon Martin

RE: cheap MPLS router recommendations

[Tony Wicks]

Right, well in that price/performance range you either “roll your own” or this 
is your best option IMHO - https://mikrotik.com/product/CCR1072-1G-8Splus  and 
I’d pick the Mikrotik every time.

 

 

 

From: NANOG  On Behalf Of 
adamv0...@netconsultings.com
Sent: Thursday, 22 October 2020 9:28 am
To: 'Colton Conor' ; t...@pelican.org
Cc: 'NANOG' 
Subject: RE: cheap MPLS router recommendations

 

Just to clarify what cheap means, ideally  -$2000 to $4000 new 

-new is preferred as buying used kit on second hand market one is at the mercy 
of the price fluctuations and availability.

 

And the likes of the M2400 looks good 4x10G plus some 1G, unfortunately there 
are no details on the webpage (and the datasheet can’t be downloaded… ) 

 

Are there more folks out there bundling open NOS and white-box HW along with 
the support for the whole thing?

 

 

adam

Re: cheap MPLS router recommendations

[Colton Conor]

https://www.multicominc.com/wp-content/uploads/DZS-M3000_M.pdf

On Wed, Oct 21, 2020 at 4:08 PM Colton Conor  wrote:

> Well then Adam I would say the Dasan Zhone fits the budget. The M3000
> seems like a real beast for the price point with 100G ports.
>
> Yes, other whitebox vendors are doing this, but they seem to want 2-4k for
> the whitebox, and even more for the operating system, making it more
> expensive that Juniper from what I have seen.
>
> On Wed, Oct 21, 2020 at 3:27 PM  wrote:
>
>> Just to clarify what cheap means, ideally  -$2000 to $4000 new
>>
>> -new is preferred as buying used kit on second hand market one is at the
>> mercy of the price fluctuations and availability.
>>
>>
>>
>> And the likes of the M2400 looks good 4x10G plus some 1G, unfortunately
>> there are no details on the webpage (and the datasheet can’t be downloaded…
>> )
>>
>>
>>
>> Are there more folks out there bundling open NOS and white-box HW along
>> with the support for the whole thing?
>>
>>
>>
>>
>>
>> adam
>>
>>
>>
>> *From:* NANOG  *On
>> Behalf Of *Colton Conor
>> *Sent:* Monday, October 19, 2020 4:51 PM
>> *To:* t...@pelican.org
>> *Cc:* NANOG 
>> *Subject:* Re: cheap MPLS router recommendations
>>
>>
>>
>> I haven't tried one myself, but Dasan Zhone has the M2400 and M3000.
>> Basically, a whitebox with IP Infusion code on it. New, I think the price
>> point is sub $2000 to $4000 new. That's a ton of ports for that price
>> point. Anyone tried these yet?
>> https://dzsi.com/product-category/mobile-xhaul/
>>
>>
>>
>>
>>
>> On Mon, Oct 19, 2020 at 3:38 AM t...@pelican.org  wrote:
>>
>> On Saturday, 17 October, 2020 00:41, "Tony Wicks" 
>> said:
>>
>> > Well, there is always the MX104 (if you want redundancy) or MX80 if you
>> > don’t. That will give you 80gig wire speed just don’t load it up with
>> > more than one full table.
>>
>> Bear in mind that the MX80 is now in the EoL process, you have <4 years
>> of support left.  Depending on your expected life-time / depreciation
>> rules, buying one new right now might be unwise.
>>
>> Do *not* throw a full table at it (or any of the PowerPC Junipers) unless
>> you have a lot of patience for reconvergence, and black-holes while you
>> wait.
>>
>> MX104 is a nice box for getting dual-RE in something relatively compact
>> and cheap, and has environmental hardening if that matters to you, but is
>> still not best pleased with full tables.
>>
>> OP could do with clarifying "cheap" :)
>>
>> Regards,
>> Tim.
>>
>>

Re: cheap MPLS router recommendations

[Colton Conor]

Well then Adam I would say the Dasan Zhone fits the budget. The M3000 seems
like a real beast for the price point with 100G ports.

Yes, other whitebox vendors are doing this, but they seem to want 2-4k for
the whitebox, and even more for the operating system, making it more
expensive that Juniper from what I have seen.

On Wed, Oct 21, 2020 at 3:27 PM  wrote:

> Just to clarify what cheap means, ideally  -$2000 to $4000 new
>
> -new is preferred as buying used kit on second hand market one is at the
> mercy of the price fluctuations and availability.
>
>
>
> And the likes of the M2400 looks good 4x10G plus some 1G, unfortunately
> there are no details on the webpage (and the datasheet can’t be downloaded…
> )
>
>
>
> Are there more folks out there bundling open NOS and white-box HW along
> with the support for the whole thing?
>
>
>
>
>
> adam
>
>
>
> *From:* NANOG  *On
> Behalf Of *Colton Conor
> *Sent:* Monday, October 19, 2020 4:51 PM
> *To:* t...@pelican.org
> *Cc:* NANOG 
> *Subject:* Re: cheap MPLS router recommendations
>
>
>
> I haven't tried one myself, but Dasan Zhone has the M2400 and M3000.
> Basically, a whitebox with IP Infusion code on it. New, I think the price
> point is sub $2000 to $4000 new. That's a ton of ports for that price
> point. Anyone tried these yet?
> https://dzsi.com/product-category/mobile-xhaul/
>
>
>
>
>
> On Mon, Oct 19, 2020 at 3:38 AM t...@pelican.org  wrote:
>
> On Saturday, 17 October, 2020 00:41, "Tony Wicks"  said:
>
> > Well, there is always the MX104 (if you want redundancy) or MX80 if you
> > don’t. That will give you 80gig wire speed just don’t load it up with
> > more than one full table.
>
> Bear in mind that the MX80 is now in the EoL process, you have <4 years of
> support left.  Depending on your expected life-time / depreciation rules,
> buying one new right now might be unwise.
>
> Do *not* throw a full table at it (or any of the PowerPC Junipers) unless
> you have a lot of patience for reconvergence, and black-holes while you
> wait.
>
> MX104 is a nice box for getting dual-RE in something relatively compact
> and cheap, and has environmental hardening if that matters to you, but is
> still not best pleased with full tables.
>
> OP could do with clarifying "cheap" :)
>
> Regards,
> Tim.
>
>

Circuit ordering software

[Oliver Rothschild]

For those that have circuit ordering mechanisms in their environment, what
sort of software do you use?

respectfully,
OIiver
Network Engineer

Level3/CenturyLink/Lumen in Denver, CO

[Matt Riffle]

Hello,

If anybody has a circuit from Level3 (aka CenturyLink or, I guess, Lumen, now) 
in Denver, CO — particularly if you’re in the Iron Mountain facility on 
Brighton Blvd — and you are willing to briefly give me an iperf3 target, please 
contact me off-list.  I’m trying to triangulate some throughput issues.

Thanks,

Matt

RE: cheap MPLS router recommendations

[adamv0025]

Just to clarify what cheap means, ideally  -$2000 to $4000 new 

-new is preferred as buying used kit on second hand market one is at the mercy 
of the price fluctuations and availability.

 

And the likes of the M2400 looks good 4x10G plus some 1G, unfortunately there 
are no details on the webpage (and the datasheet can’t be downloaded… ) 

 

Are there more folks out there bundling open NOS and white-box HW along with 
the support for the whole thing?

 

 

adam

 

From: NANOG  On Behalf Of 
Colton Conor
Sent: Monday, October 19, 2020 4:51 PM
To: t...@pelican.org
Cc: NANOG 
Subject: Re: cheap MPLS router recommendations

 

I haven't tried one myself, but Dasan Zhone has the M2400 and M3000. Basically, 
a whitebox with IP Infusion code on it. New, I think the price point is sub 
$2000 to $4000 new. That's a ton of ports for that price point. Anyone tried 
these yet?  https://dzsi.com/product-category/mobile-xhaul/ 

 

 

On Mon, Oct 19, 2020 at 3:38 AM t...@pelican.org   
mailto:t...@pelican.org> > wrote:

On Saturday, 17 October, 2020 00:41, "Tony Wicks" mailto:t...@wicks.co.nz> > said:

> Well, there is always the MX104 (if you want redundancy) or MX80 if you
> don’t. That will give you 80gig wire speed just don’t load it up with
> more than one full table.

Bear in mind that the MX80 is now in the EoL process, you have <4 years of 
support left.  Depending on your expected life-time / depreciation rules, 
buying one new right now might be unwise.

Do *not* throw a full table at it (or any of the PowerPC Junipers) unless you 
have a lot of patience for reconvergence, and black-holes while you wait.

MX104 is a nice box for getting dual-RE in something relatively compact and 
cheap, and has environmental hardening if that matters to you, but is still not 
best pleased with full tables.

OP could do with clarifying "cheap" :)

Regards,
Tim.

Re: Linux router network cards

[Marinos Dimolianis]

Hi micah,

I think this was shared in the past and may be useful with regards to 
what you expect in terms of performance: 
https://blog.apnic.net/2020/04/30/how-to-build-an-xdp-based-bgp-peering-router/ 
.


BR,

Marinos

On 21-Oct-20 6:37 AM, micah anderson wrote:

I'm looking around for networking cards to build a linux based
router. It needs to be able to do XDP, multiqueues, have good in-kernel
driver support and be able to handle 10Gbe with good offloading for
dealing with high packets per second.

What features should I be looking for to really optimize things for a
three transit setup, with full tables.

Something like the Intel XL710-QDA2 card maybe?

Re: Linux router network cards

[james jones]

I wonder if they are going to get CUDA cores on the next version since they
are owned by NVIDIA now. That would be a powerful little package.


On Wed, Oct 21, 2020 at 1:42 AM Raymond Burkholder 
wrote:

> On 2020-10-20 22:37, Philip Loenneker wrote:
> > Take a look at the Mellanox ConnectX 5 series of cards. They handle
> DPDK, PVRDMA (basically SR-IOV that allows live migration between hosts),
> and can even process packets within the NIC for some models. They did a
> fantastic presentation at AusNOG 2019 which showed off a lot of the
> features. We tried some out with Vmware and could get 20Gbps throughput
> (limited by the 2x 10G NICs we had configured) to a VM running Linux with
> DPDK+VPP.
>
> Plus Mellanox introduced the SwitchDev capability which provides for
> offloading flow management to the hardware.
>

Re: Juniper configuration recommendations/BCP

[Sebastian Wiesinger]

* Forrest Christian (List Account)  [2020-10-08 11:39]:
> I've done a bit of googling and am either finding stuff that is largely
> Cisco-specific or which is generic - all of which I'm rather familiar with
> based on my past history.   Is there anything I should worry about which is
> Juniper-specific?

Some things that come to mind:

* Juniper has a default ARP policer that is _shared_ between all
interfaces. This will bite you if you attach the box to a large L2
segment (*cough* DE-CIX *cough*). So you should either:
 - configure a non-shared policer:
set firewall policer my-arp-policer if-exceeding 
set interface xe-0/0/0.0 family inet policer arp my-arp-policer

 - disable default ARP policer for the interface (this is not recommended
   and a hidden command)
set interface xe-0/0/0.0 family inet policer disable-arp-policer


* If you do Aggregated Ethernet (Port-Channel interfaces) you need to
  reserve resources for the ae interface by declaring:
set chassis aggregated-devices ethernet device-count X
  "device-count 3" would give you ae0 to ae2 as possible interfaces


* For all modern MX boxes you should normally set network-services
  mode to enhanced-ip (this requires a reboot of the box):
   set chassis network-services enhanced-ip

* Groups (set groups some-group ... / set  apply-group 
some-group)
  are your friend

  Want to see stuff that gets applied to the config trough groups?
   show  | display inheritance
   (add "no-comments" for just the config without additional information)

* It is kind of hard sometimes to figure out the right encapsulation /
  vlan-tagging config for an interface. For most flexible use of a
  port (this might differ depending on your configuration) on MX you
  can use:
   set interface xe-0/0/0 encapsulation flexible-ethernet-services
   set interface xe-0/0/0 flexible-vlan-tagging

* Physical interface MTU for Juniper includes Ethernet overhead
  (standard MTU is 1514, 1518 with VLAN tag). So basically coming from
  Cisco its Cisco-MTU+14. You can configure a separate MTU per
  protocol family (set interface ... family inet mtu 1500). Handy for
  OSPF and co.

* You need to enable every protocol family on an interface that you
  wish to accept. So for example if you want to do IPv4(OSPF) + IPv6(ISIS) + 
MPLS
  (with LDP) you need on the interface:

   set interface .. family inet ...
   set interface .. family inet6 ...
   set interface .. family iso
   set interface .. family mpls

  After that you need to enable the interface separately under the
  relevant protocols (set protocol mpls interface ..., set protocols
  ldp interface ...)

  Yes this is a bit much but I always try to remember that the first
  part enables the receiving of the protocol packets on the interface
  and the second part enables the processing of the received packets.

* I love that Juniper shows you all routes for a destination, so if a
  destination is reachable via BGP, OSPF and direct route a 'show
  route ' will show that information for all protocols. The
  active route is marked with a star. Routes that are hidden (for
  example BGP routes that are rejected by import filters) can be shown
  by 'show route hidden'.

* You can set standard BGP parameters for the whole box under
  'routing-options':

set routing-options router-id 1.2.3.4
set routing-options route-distinguisher-id 1.2.3.4
set routing-options autonomous-system 65500

* You need to enable ECMP by binding a filter to the forwarding-table:
   set policy-options policy-statement ecmp term 10-ecmp then load-balance 
per-packet
   set routing-options forwarding-table export ecmp

  (Yes, per-packet means per-flow ECMP, don't ask)

* Sometimes if you change config and don't see a change in behaviour a
  'commit full' will fix the problem (this shouldn't be necessary
  normally).

* Some global BGP settings I would use:
   set protocols bgp precision-timers (Helps with very low BGP timers to avoid 
timeouts)
   set protocols bgp log-updown
   set protocols bgp always-compare-med (Depends on your routing policy)

* Want to look under the hood? Go to the linecard:
   > start shell pfe network fpcX (fpc0 only for MX204)
  Danger Zone: There are many commands on the linecard that can mess
  stuff up. I even managed to crash stuff with some 'show ..' commands
  there.

* Change things and want to apply it later? Save and load the patch
  later:

# show | diff | tee patch.txt
# rollback
# exit

# configure
# load patch patch.txt
# commit


Sebastian


-- 
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant