Re: Sufficient Buffer Sizes

[Dale W. Carder]

Thus spake Mike Hammett (na...@ics-il.net) on Tue, Jan 02, 2024 at 05:02:22PM 
-0600:
> While attempting to ascertain how big of switch buffers I needed in a 100G 
> switch, I rediscovered this article where I first learned about switch 
> buffers.
> 
> https://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/#:~:text=Optimum%20Buffer%20Size=The%20general%20rule%20of%20thumb,1G%20host%20across%20the%20WAN.
> 
> It suggests that 60 meg is what you need at 10G. Is that per interface? Would 
> it be linear in that I would need 600 meg at 100G?

We've tried to be clear about the use cases where these guidelines
apply.  In these sets of articles, we are primarily describing issues
prevalent between many scientific research and education environments
where traffic can be dominated by multiplexing a low number of high-BDP
machine-machine flows, such as from a telescope array to a supercomputer
one continent away.  

Numbers here are not one-size-fits all, and are not necessarily
characteristic of what you would want to do for multiplexing say a
bazillion flows from cdns to homes all within ~10ms rtt.  That said, if
you dig in and understand where the numbers are coming from, the
principles apply.

Dale

Re: Generally accepted BGP acceptance criteria?

[Dale W. Carder]

Thus spake Tom Samplonius (t...@samplonius.org) on Mon, Nov 20, 2023 at 
07:02:52PM -0800:
> > On Nov 17, 2023, at 6:58 AM, Christopher Morrow  
> > wrote:
> > IRR filters provide control over whom is provided reachability through
> > a particular peering/path.
> 
>   How does that work?  IRR import: and export: parameters are poorly 
> implemented.  Is anyone actually validating more than the origin with IRR?

I think "validating" is the wrong verb for IRR.  "Provisioning" may
be more accurate.  

As an example, my AS293 peers with AS6509.  In the AS-SET that they
publish, AS6509:AS-CANARIE, the "members:" field for instance lists
AS271:AS-BCNET-MEMBERS which then lists AS271 in it's members.  An
inverse query to an IRR whois server from such a tool as 'bgpq4' walks
this tree to generate a list of prefixes applicable to in effect, a
given path presuming you know what IRR object to start with.  That is
where import/export typically comes into play.

RPSL's 'import:' and 'export:' (and the mp-variants) are problematic
at best to use programmatically.  Our provisioning system for example
doesn't bother and uses the IRR object specified in PeeringDB for 
filter generation by default. 

Dale

Re: Generally accepted BGP acceptance criteria?

[Dale W. Carder]

Thus spake Tom Samplonius (t...@samplonius.org) on Thu, Nov 16, 2023 at 
04:54:17PM -0800:
> 
>   In the world of IRR and RPKI, BGP route acceptance criteria is important to 
> get right.
> 
>   DE-CIX has published a detailed flow chart documenting their acceptance 
> criteria:  https://www.de-cix.net/en/locations/frankfurt/route-server-guide
> 
>   But I don’t see a lot of operators publishing their criteria.

An example another IX: https://www.seattleix.net/route-servers

Here's at least one provider example: https://routing.he.net/algorithm.html

>  I imagine there is a some sort of coalescing industry standard out there, 
> but so far I can’t find it.  Of the upstreams I use, just one publishes a 
> flowchart.  Another is basically refusing to explain anything other than they 
> “use” IRR and RPKI, ad that RPKI is “good”.

I don't think there is a standard as there is a pretty wide range of
variance, ranging from "nothing" to static lists to `bgpq4` to whatever
you call what Hurricane is doing.

>   I assumed that everyone implementing RPKI validation, would skip IRR route 
> object validation if the route is RPKI-valid.

Not at all.  While an ROA provides an attestation about the originating
ASN for a prefix, there are no claims made as to the path or that all
prefixes for an ASN have ROAs.

>  I assumed that everyone is doing this now, or would do this when they 
> implement RPKI validation.  But I spoke to an operator today, which still 
> expects all routes to pass IRR as well (and while they perform 
> RPKI-validation, they effectively do nothing with the result).  To me, this 
> seems like a different direction than most operators are going.  Or is it?
> 
>   The most surprising thing in the DE-DIX flow chart, was that they check 
> that the origin AS exists in the IRR as-set, before doing RPKI, and if the 
> set existence fails, they reject the route.  I don’t see a problem with this, 
> as maintaining as-sets is easy, but it does prevent an eventual 100% RPKI 
> future with no IRR at all.

There are some possible things in the works you should consider, as
OTC, ASPA, rpki-prefixlist (essentially like an irr route-set), and
even partial deployment of bgpsec are emerging tools in the toolbox.  

Before embarking too far, we must also consider this from an ecosystem
perspective.  With RPKI ROA's, the integration with IRRd v4 elegantly 
sunsets blatantly invalid prefixes.  Additional tooling (IRRd v5?
bgpq5?) would need to be considered to further transition our way out
out of the IRR system, assuming an analog in RPKI.  

Would we even want to?  Dropping non-RIR IRR source databases might go
much further to get to very similar goals with much less work than for
example reimplementing as-sets (I think essentially the inverse of
ASPA's ASProviderAttestation) in RPKI.

Dale

Re: Acceptance of RPKI unknown in ROV

[Dale W. Carder]

Thus spake Randy Bush (ra...@psg.com) on Thu, Oct 19, 2023 at 03:16:21PM -0700:
> > For legacy resource holders it is a problem but then it’s a
> > bureaucratic issue rather technical and technology has a solution
> > called SLURM.
> 
> has arin not made it easier, lowering the legal insanity, for legacy
> holders to obtain services?

Yes, and the process is pretty straightforward now even for public 
entities.

We (AS293) recently updated our RSA and LRSA to the latest language
and also are cleaning up some ~40yrs of not-quite-accurate-enough 
record keeping between multiple govt entities.  If "we" can do it,
"you" can do it (probably a heck of a lot easier) ;-)

Dale 

Re: maximum ipv4 bgp prefix length of /24 ?

[Dale W. Carder]

Thus spake Delong.com (o...@delong.com) on Wed, Oct 11, 2023 at 12:44:35PM 
-0700:
> 
> 
> > On Oct 11, 2023, at 11:50, Dale W. Carder  wrote:
> > 
> > Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 
> > 04:52:07PM -0700:
> >> However, IF YY is paying attention, and YY wants to advertise 
> >> 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, 
> >> I would expect AS YY would generate ROAs for
> >>2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36
> >>2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
> >>2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
> >>2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
> >>2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
> >>2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
> >>2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
> >>2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
> > 
> > Double check, but offhand I believe in this case you do not need all 
> > these AS0 ROA's.  Any validated ROA payload fully matching should be
> > all you need for it to be valid, and anything that is covered by a vrp
> > but not matching is invalid.
> > 
> > So, I think you can do
> > 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=32
> > 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
> > 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
> > 
> > Dale
> 
> My understanding is that the 2001:db8::/32 max=32 would block the /36s from 
> being considered valid (in order to prevent someone with trust anchor B 
> overriding the policy of someone with trust anchor A).
> 
> Since all the trust anchors are ::/0, I think that was deemed important.
> 
> I could be wrong, like you, I would need to double check the details.

I found a working example from within our customer cone:
https://rpki-validator.ripe.net/ui/2620%3A6a%3A%3A%2F48/3152


Dale

Re: maximum ipv4 bgp prefix length of /24 ?

[Dale W. Carder]

Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 
04:52:07PM -0700:
> However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 
> as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS 
> YY would generate ROAs for
>   2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36
>   2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
>   2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36

Double check, but offhand I believe in this case you do not need all 
these AS0 ROA's.  Any validated ROA payload fully matching should be
all you need for it to be valid, and anything that is covered by a vrp
but not matching is invalid.

So, I think you can do
2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=32
2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36

Dale

Re: Seeing a lot of ROUTING-FIB-3-UPD_MSG_TOO_BIG messages today

[Dale W. Carder]

Thus spake Drew Weaver (drew.wea...@thenap.com) on Mon, Apr 25, 2022 at 
04:21:53PM +:
> Hello everyone,
> 
> I've seen this a bit in the past with 1-2 routes, but today it's been 
> happening basically all morning with several different routes.
> 
> ROUTING-FIB-3-UPD_MSG_TOO_BIG
> 
> I've chased it down from a vendor level and they implied that it is just 
> informational, my question is why do these sort of updates seem to be sent to 
> the Internet's routing table in bursts?
> 
> Is that a testing thing?
> 
> Is anyone else seeing this today as well?

103.139.18.0/23   139009 139009 139009 139009 139009 ...

Dale

Re: SRv6 Capable NOS and Devices

[Dale W. Carder]

Thus spake Sander Steffann (san...@steffann.nl) on Wed, Jan 12, 2022 at 
06:21:25PM +0100:
> Hi,
> 
> > No SRv6 is MPLS labeling where label is carried inside IP instead
> > before the IP header. Layering violation which increases complexity
> > and cost for no other purpose except dishonest marketing about 'it is
> > IP, you already understand it, MPLS is hard'.
> 
> What worries me more is the opportunity for adversaries to inject SRv6 
> packets. MPLS is not enabled by default on most router interfaces, so an 
> adversary would have to have access to an interface where MPLS processing is 
> explicitly enabled. IPv6 packet processing on the other hand… Unless an 
> operator has airtight protection on every interface to block unwanted SRv6 
> headers I see some interesting opportunities to cause havoc :)

You are not alone, see for example the thread at
https://mailarchive.ietf.org/arch/msg/v6ops/GbWiie-bjQ_Bp1JKB1PlDh_fPdc/ 
this is more pronounced with respect to the various SRv6 compression scheme 
proposals.

Dale

Re: question about enabling RPKI using Hosted mode

[Dale W. Carder]

Thus spake Edvinas Kairys (edvinas.em...@gmail.com) on Tue, Oct 26, 2021 at 
10:11:14AM +0300:
> 
> Also, about ROA expirations is it possible to configure an automatic ROA
> extension after it's expires ?

Well, you probably hit one of the next biggest operational issues, 
so congrats ;-).  

If you are in the ARIN region you might want to track the process
for ACSP Suggestion 2021.15 

https://www.arin.net/participate/community/acsp/suggestions/2021/2021-15/

If you are in another regions you can see the differences here:
https://rpki.readthedocs.io/en/latest/rpki/implementation-models.html?highlight=renew#functional-differences-across-rirs

Dale
 
> On Tue, Oct 26, 2021 at 12:35 AM Job Snijders  wrote:
> 
> > Dear Edvinas,
> >
> > On Mon, Oct 25, 2021 at 11:49:09PM +0300, Edvinas Kairys wrote:
> > > We're thinking of enabling BGP ROA, because more and more ISPs are using
> > > strict RPKI mode.
> > >
> > > Does enabling Hosted Mode (where it doesn't requires any additional
> > > configuration on client end) on RPKI could for some reason could cause a
> > > traffic loss ?
> > >
> > > The only disasterious scenario i could think of, is if we would enable
> > ROA
> > > with incorrect sub prefixes, maximum prefix length. Am i Right ?
> >
> > I think you correctly identified most of the potential pitfalls. Another
> > pitfall might be when a typo in the Origin AS value slips into the RPKI
> > ROA.
> >
> > For example, I originate 2001:67c:208c::/48 in the DFZ from AS 15562.
> > Should I'd accidentally modify the covering ROA to only permit AS 15563,
> > the planet's connectivity towards 2001:67c:208c::/48 would become
> > spotty.
> >
> > So... - BEFORE - creating RPKI ROAs, I recommend setting up a BGP/RPKI
> > monitoring tool. NTT's excellent BGPAlerter might be useful in this
> > context: https://github.com/nttgin/BGPalerter
> >
> > Don't deploy things without monitoring! :-)
> >
> > Kind regards,
> >
> > Job
> >

Re: Setting sensible max-prefix limits

[Dale W. Carder]

Thus spake Chriztoffer Hansen (c...@ntrv.dk) on Wed, Aug 18, 2021 at 12:03:51PM 
+0200:
> On Wed, 18 Aug 2021 at 11:33, Lars Prehn  wrote:
> > I guess for long standing peers one could just eyeball it, e.g., current
> > prefix count + some safety margin. How does that work for new peers?

sadly, this is the state of the art.
 
> If you have automation in place. Another approach is to count the
> received prefix. Store the counted value in a database. Based on the
> avg prefix count over X (time period). Add e.g. 10 - 25 % headroom
> over the avg prefix count and use the calculated value as the
> max-prefix limit?
> 
> PeeringDB data (sometimes or often?) be somewhat misleading (in
> contrast to actual avg prefix count) in the sense 'some' networks will
> input a value with headroom percentages already included.
> 

Our code tries all 3:

a) using the max values in peeringdb
b) expand all the routes in the IRR record from peeringdb
b.1) if no object is specified, try to guess if it's named ASn
c) count the currently received prefixes

Many times the values in peeringdb can be off, or increasingly this is a good 
warning not to peer with a negligent operator.  For some peers 'b' can expand 
to a huge, unrealistic set (not always their fault), so if it's substantially 
larger than 'a' we throw it out.  (c) has proven the most reliable.

The count chosen then fits in the appropriate sized bin and given 30% headroom.
The code compares all this and gives the user a warning that in proactive gets 
ignored for option 'c'.  (For example we can override 'b' with a more 
appropriate 
object record in our provisioning db)

Dale

Re: IPv6 and multicast listener discovery

[Dale W. Carder]

Are your links or hosts limited in some way or broadcast domains
of some unreasonable size?  Most of the competent switching or 
managed wireless products will snoop or otherwise handle this 
overhead in a sane manner.  Otherwise this at best would seem to 
be an over-optimization.

>From my days on a giant campus network the current pps rate of MLD
chatter was much lower than the IPX/SAP broadcasts we had from 
20-25 yrs earlier.

Dale

Thus spake William Herrin (b...@herrin.us) on Fri, Jun 04, 2021 at 02:01:19PM 
-0700:
> Howdy,
> 
> Question for those more versed in IPv6 than I: Is there any harm from
> dropping ICMPv6 multicast listener discovery reports in a network
> which does NOT use any multicast routing (i.e. only uses multicast
> which stays within the local link). I see a LOT of idle node chatter
> in the form of these reports which, of course, flood every station
> since they are themselves multicast. As far as I can tell they are
> used only to tell a multicast router whether to repeat a particular
> set of multicast packets to the instant link. Which in my network is
> -never- because there are no routed multicast packets to be repeated.
> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: OVH datacenter SBG2 in Strasbourg on fire 

[Dale W. Carder]

Thus spake Matt Harris (m...@netfire.net) on Thu, Mar 11, 2021 at 05:06:46AM 
-0600:
> 
> There are plenty of effective options besides environmentally-destructive
> Halon, dangerous-to-equipment water sprinkler, or dangerous-to-personnel
> CO2 for fire suppression these days. Some of the most common today are foam
> systems like FM-200 or 3m's Novec.

Sadly, the foams are not without environmental impact either with
respect to PFAS.

Dale

Re: 100G over 100 km of dark fiber

[Dale W. Carder]

You may also find that 100G PAM4 could work.  There are some vendors that
sell the optic, and an outboard EDFA + DCF pizza box.

Dale

Thus spake Tarko Tikan (ta...@lanparty.ee) on Fri, Oct 30, 2020 at 04:25:58PM 
+0200:
> hey,
> 
> > I need to push 100G over 100 km of dark fiber. Since there are no 100G 
> > pluggable optics with this reach (~25 dB), I have been offered coherent 
> > transport systems to solve my problem. This is all good and well, except 
> > total system costs start from high five figures.
> 
> 100G-ZR4 QSFP28 is on the market and works. Just watch out for power
> limitations, your typical DC switch might not support it but proper stuff
> has no problems providing 6.5W of power.
> 
> -- 
> tarko

Re: Cogent Layer 2

[Dale W. Carder]

Thus spake Mike Hammett (na...@ics-il.net) on Wed, Oct 14, 2020 at 12:36:39PM 
-0500:
> 
> Are any legitimate beefs with Cogent limited to their IP policies, BGP 
> session charges, and peering disputes? Meaning, would using them for layer 2 
> be reasonable? 

Be sure to ask if your circuit will face a 2G/flow cap, and examine if such
a limitation would affect your expected traffic mix.  

https://www.reddit.com/r/networking/comments/iv0job/2gb_traffic_flow_cap_on_single_sourcedestination/

Dale

Re: AS hijacking (Philosophy, rants, GeoMind)

[Dale W. Carder]

Thus spake Justin Wilson (Lists) (li...@mtin.net) on Fri, May 29, 2020 at 
11:39:46AM -0400:
> One of the companies I work for recently had an issue with AS 2 (University 
> of Delaware) hijacking a prefix.  Due to Origin AS, good upstreams, and the 
> like this has not really affected the traffic to the legit blocks.  However, 
> GeoMind picked this up almost immediately it seems.  The IP blocks when you 
> go to speedtest.net come back to the university of Delaware. This seems to be 
> the only issue at the moment so we are working through contacting the peers 
> of AS2 and asking them to look into this.  We had also contacted University 
> of Delaware.
> 
> Here is where the philosophy comes into play.  The very terse e-mail we 
> received back was basically “As2 gets hijacked a lot and it’s not our 
> problem”. 

Given the ASN, have you ruled out that this is hijacking vs a case of 
prepending gone wrong.  We see this happen quote a bit with ASN 16, 
and sometimes even with 50.  Typically, ASN's 43, 44, and 45 usually 
get spared from this class of misconfiguration.

> So my question for the NANOG folks.  At what point do you say “it’s not your 
> problem” when it involves your ASN?

Interdomain routing continues to be a community effort, but this
certainly could be in the class of problems of which they had no 
hand in.

Dale

Re: Cisco Crosswork Network Insights - or how to destroy a useful service

[Dale W. Carder]

Thus spake Job Snijders (j...@ntt.net) on Wed, May 15, 2019 at 12:16:06PM +0200:
> 
> I recognise the issue you describe, and I'd like to share with you that
> we're going down another road. Nowadays, RIPE NCC offers a streaming API
> ("RIS Live") which has the data needed to analyse and correlate BGP
> UPDATES seen in the wild to business rules you as operator define.
> 
> NTT folks are working on https://github.com/nlnog/bgpalerter/ - which
> relies on "RIPE RIS Live", this software should become a competitive
> replacement to current BGP monitoring tools. Stay tuned, the software
> will be more useful in the course of the next few weeks.

Similarly, one can integrate CAIDA's BGPStream Broker Service[1] into
their own tools.  Like bgpalerter above, working with open source or
rolling your own tools is increasingly straightforward[2] due to these
community projects.  

Another viable project to keep an eye on is ARTEMIS[3] for monitoring.

Dale

[1] https://bgpstream.caida.org/data
[2] https://github.com/dwcarder/bgpwatch
[3] https://www.inspire.edu.gr/artemis/

Re: Pinging a Device Every Second

[Dale W. Carder]

Thus spake Christian Meutes (christ...@errxtx.net) on Fri, Dec 21, 2018 at 
02:41:23PM +0100:
> Depending on your requirements and scale - but I read you want history -
> it's probably less a demand on CPU or network resources, but more on IOPS.
> 
> If you cache all results before writing to disk, then it's not much of a
> problem, but by just going "let's use RRD/MRTG for this" your IOPS could
> become the first problem. So you might look into a proper timeseries
> backend or use a caching daemon for RRD.

Having once written a caching daemon for mrtg/rrdtool, the advent of SSD
arrays has made iops largely irrelevant.  (I had ~ 1.2M targets in mrtg
on that machine)

Dale
 
 
> On Sat, Dec 15, 2018 at 4:48 PM Colton Conor  wrote:
> 
> > How much compute and network resources does it take for a NMS to:
> >
> > 1. ICMP ping a device every second
> > 2. Record these results.
> > 3. Report an alarm after so many seconds of missed pings.
> >
> > We are looking for a system to in near real-time monitor if an end
> > customers router is up or down. SNMP I assume would be too resource
> > intensive, so ICMP pings seem like the only logical solution.
> >
> > The question is once a second pings too polling on an NMS and a consumer
> > grade router? Does it take much network bandwidth and CPU resources from
> > both the NMS and CPE side?
> >
> > Lets say this is for a 1,000 customer ISP.
> >
> >
> >
> 
> -- 
> Christian Meutes
> 
> e-mail/xmpp: christ...@errxtx.net
> mobile: +49 176 32370305
> PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318
> Toulouser Allee 21, 40211 Duesseldorf, Germany

Re: Confirming source-routed multicast is dead on the public Internet

[Dale W. Carder]

Thus spake Mankamana Mishra (mankamis) via NANOG (nanog@nanog.org) on Wed, Aug 
01, 2018 at 02:43:10AM +:
> other than billing problem, is there any other reasons why multicast would 
> not be viable for public internet ? 
 
Hi Mankamana,

You can find a reasonable overview here with respect to ASM:
https://tools.ietf.org/html/draft-acg-mboned-deprecate-interdomain-asm-02

Dale

Re: Blockchain and Networking

[Dale W. Carder]

Traceroute or any other path diagnostics comes to mind.

Dale

Thus spake Tom Beecher (beec...@beecher.cc) on Thu, Jan 11, 2018 at 12:22:43PM 
-0500:
> "Blockchain is great at proving chain of custody, but when do you need to do
> that in computer networking?"
> 
> This is the most important question to ask. Everything else is just
> buzzwordy shenanigans.
> 
> On Mon, Jan 8, 2018 at 12:52 AM, William Herrin  wrote:
> 
> > On Mon, Jan 8, 2018 at 12:26 AM, Glen Kent  wrote:
> >
> > > Do folks on this list see blockchain technology making inroads into the
> > > networking? I can see blockchain being used to secure the SDN environment
> > > where blockchain will allow encrypted data transfers between nodes (ones
> > > hosting different applications, the SDN controller, the data plane
> > devices)
> > > regardless of the network size or its geographical distribution.
> > >
> >
> > Hi Glen,
> >
> > I'm having trouble envisioning a scenario where blockchain does that any
> > better than plain old PKI.
> >
> > Blockchain is great at proving chain of custody, but when do you need to do
> > that in computer networking?
> >
> > Regards,
> > Bill Herrin
> >
> >
> > --
> > William Herrin  her...@dirtside.com  b...@herrin.us
> > Dirtside Systems . Web: 
> >

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Dale W. Carder]

Thus spake Patrick W. Gilmore (patr...@ianai.net) on Sun, Sep 25, 2016 at 
05:57:42PM -0400:
> On Sep 25, 2016, at 5:50 PM, ryan landry  wrote:
> > On Sun, Sep 25, 2016 at 9:07 PM, Mark Andrews  wrote:
> 
> >> This is such a golden opportunity for each of you to find compromised
> >> hosts on your network or your customer's network.  The number of
> >> genuine lookups of the blog vs the number of botted machine would
> >> make it almost certain that anything directed at the blog is a
> >> compromised machine.  A phone call to the customer / further analysis
> >> would reduce the false positive rate.
> >> 
> >> Mark
> >> 
> >> 
> > i wish you luck with that. explaining to grandma that her samsung smart tv
> > has been rooted and needs to be updated should be good fun.
> > 
> > for isp's it's a resourcing vs revenue problem. always has been. always
> > will be. far more inclined to hold liable the folks that are churning out
> > terribly dangerous cpe / IoT(shit). surely some regulatory body is looking
> > into this.
> 
> Yeah, ‘cause that was so successful in the past.
> 
> Remember University of Wisconsin vs. D-Link and their hard-coded NTP server 
> address?

Interestingly, this was just recently looked at again for the Internet of 
Things 
Software Update Workshop (IoTSU).  See:
http://pages.cs.wisc.edu/~plonka/iotsu/IoTSU_2016_paper_25.pdf

3,564 devices still remain.

best,
Dale

Re: collectd as alternative to RTG for high-resolution polling and long term storage?

[Dale W. Carder]

Thus spake Eric Kuhnke (eric.kuh...@gmail.com) on Wed, Mar 16, 2016 at 
11:45:26AM -0700:
> Would anyone care to share their experience using collectd as an
> alternative to rtg for high-resolution polling of interface traffic and
> long term storage?
> 
> I am investigating the various options for large data set size, lossless
> long term traffic charting (not RRAs which lose precision over time).

No, the storage interval is configurable and so are the (optional) 
consolidation functions.  You may want to look tuning at the defaults 
your application is choosing.

Dale

Re: Internet Exchanges supporting jumbo frames?

[Dale W. Carder]

Thus spake Jakob Heitz (jheitz) (jhe...@cisco.com) on Fri, Mar 18, 2016 at 
09:29:44PM +:
> What's driving the desire for larger packets?

In our little corner of the internet, it is to increase the performance
of a low number of high-bdp flows which are typically dataset transfers.
All of our non-commercial peers support 9k.  

Dale

Re: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability

[Dale W. Carder]

Thus spake Andrew (Andy) Ashley (andre...@aware.co.th) on Thu, Feb 11, 2016 at 
02:35:51PM +:
> Is a control-plane ACL to limit isakmp traffic (UDP/500) to an affected ASA 
> from desired sources enough to mitigate this attack, until upgrades can be 
> performed?

It's worth noting that is not listed as a workaround (they typically use
branding like "infrastructure acl's" or some such) to mitigate it on the
affected box.  Upstream, yes that would seem to be intuitive.

Perhaps because you are corrupting the heap with fragments you are
outside of where the ACL is applied?

Dale

Re: SNMP - monitoring large number of devices

[Dale W. Carder]

Thus spake Dan White (dwh...@olp.net) on Tue, Sep 29, 2015 at 03:37:51PM -0500:
> On 09/29/15 22:20 +0200, Pavel Dimow wrote:
> >recently I have been tasked with a NMS project. The idea is to pool about
> >20 OID's from 50k cable modems in less then 5 minutes (yes, I know it's a
> >one million OID's). Before you say check out some very professional and
> >expensive solutions I would like to know are there any alternatives like
> >open source "snmp framework"? To be more descriptive many of you knows how
> >big is the mess with snmp on cable modem. You always first perform snmp
> >walk in order to discover interfaces and then read the values for those
> >interfaces. As cable modem can bundle more DS channels, one time you can
> >have one and other time you can have N+1 DS channels = interfaces. All in
> >all I don't believe that there is something perfect out there when it comes
> >to tracking huge number of cable modems so I would like to know is there
> >any "snmp framework" that can be exteded and how did you (or would you)
> >solve this problem.
> 
> I've done about ~60,000 OID queries (over a few dozen devices) per 5
> minutes using OpenNMS, which is Java based. At the scale you're looking at,
> disk I/O would be a major performance issue (if using rrdtool). Google for
> 'Tuning RRD' for some tips that can make a significant difference.

These days all you need is SSD.  We have about 800,000 active rrd files
(in MRTG, for that matter) on one old server.

Otherwise the various techniques we proposed in 2007 are now largely
implemented, particularly rrdcached beginning in version 1.4.
https://www.usenix.org/legacy/event/lisa07/tech/full_papers/plonka/plonka_html/index.html

Dale

Re: Android (lack of) support for DHCPv6

[Dale W. Carder]

Thus spake Paul B. Henson (hen...@acm.org) on Mon, Jun 08, 2015 at 08:14:54PM 
-0700:
 We're in the beginning steps of bringing up IPv6 at the fairly large
 university where I work. 

Ditto.

 We plan to use DHCPv6 rather than SLAAC for a variety of reasons. 

Those reasons should probably be reviewed.  The reality is that you will
probably need to support slaac, dhcpv6, and rfc6106. 

The nice thing about standards is that there are so many to choose from.

Dale

Re: Routing Insecurity (Re: BGP in the Washington Post)

[Dale W. Carder]

Thus spake Roland Dobbins (rdobb...@arbor.net) on Tue, Jun 02, 2015 at 
03:05:13PM +0700:
 
 On 2 Jun 2015, at 11:07, Mark Andrews wrote:
 
 If you have secure BGP deployed then you could extend the authenication
 to securely authenticate source addresses you emit and automate
 BCP38 filter generation and then you wouldn't have to worry about
 DNS, NTP, CHARGEN etc. reflecting spoofed traffic
 
 This can be and is done by networks which originate routes and which
 practice good network hygiene, no PKI required.
 
 But then we get into the customer of my customer (of my customer, of my
 customer . . .) problem, and this aren't quite so clear.
 
 There are also potentially significant drawbacks to incorporating PKI into
 the routing space, including new potential DoS vectors against PKI-enabled
 routing elements, the potential for enumeration of routing elements, and the
 possibility of building a true 'Internet kill switch' with effects far
 beyond what various governmental bodies have managed to do so far in the DNS
 space.
 
 Once governments figured out what the DNS was, they started to use it as a
 ban-hammer - what happens in a PKIed routing system once they figure out
 what BGP is?
 
 But nobody seems to be discussing these potential drawbacks, very much.

Start here:
 https://www.cs.bu.edu/~goldbe/papers/hotRPKI_full.pdf

Dale

Re: Fwd: Interesting problems with using IPv6

[Dale W. Carder]

Thus spake Scott Weeks (sur...@mauigateway.com) on Sun, Sep 07, 2014 at 
12:17:18PM -0700:
 --- fergdawgs...@mykolab.com wrote:
 From: Paul Ferguson fergdawgs...@mykolab.com
 
 There's been a lot of on-and-off discussion about v6, 
 especially about security and operational concerns 
 about some aspects of IPv6 deployment, specifically 
 regarding neighbor discovery (although there are other 
 operational security concerns, as well).
 
 I'd like to provide this as an example of those 
 concerns, without any additional commentary. :-)
 
 See also:
 
 http://www.ietf.org/mail-archive/web/ietf/current/msg89517.html
 --
 
 
 I read the article and Tim Warnock on ipv6.org.au gave 
 a pretty good and very brief summary.  Pasted here for
 those that don't have time to read it.  :-)
 
 large L2 domain + ipv6 windows privacy extensions + some 
 intel card bug + some mention of igmp snooping = multicast 
 flood w/ high switch/router cpu...


This is well known. see: draft-pashby-magma-simplify-mld-snooping-01

About 4-5 years ago there was CSCtl51859.

Vendor implementations that treat v6 neighbor discovery like it's IGMPv2
are doomed to fail.

Dale

Re: Multicast Internet Route table.

[Dale W. Carder]

Thus spake Mikael Abrahamsson (swm...@swm.pp.se) on Tue, Sep 02, 2014 at 
06:05:42PM +0200:
 On Tue, 2 Sep 2014, Octavio Alvarez wrote:
 
 I have never used interdomain multicast but I imagine the global m-routing
 table would quickly become large.
 
 I have set up interdomain routing connecting both to a few peers and a Tier1
 transit provider. Not many non-research networks to be seen.
 
 Also, since we didn't use it it kept breaking and I had to fix it every two
 years or so, where it probably had been down for months.
 
 I don't believe in Internet-wide multicast happening in current incarnation,
 it's just too fragile and too few people are using it. It wouldn't scale
 either due to all the state that needs to be kept.
 
Inter-domain multicast was largely replaced in practice by CDN's.

In addition to scale issues in keeping state, large wireless L1 environments
are hostile to functioning multicast.

Dale

Re: ASR9K xml agent vs netconf

[Dale W. Carder]

Thus spake Jeremy (jba...@gmail.com) on Fri, Aug 01, 2014 at 03:07:19PM -0700:
 
 I'm currently working on writing some automation around the ASR9K platform
 and I've been looking at both the netconf and xml interfaces. Anyone have
 experience with either?
 
 It looks like the XML interface is much more feature rich, supporting both
 config and operational state objects where netconf is limited to config
 only.
 
 Currently I'm leaning towards the xml interface,

I wasted a week of my life trying to get xml interface on n9k to work
correctly.  I would never use it again, as it obviously gets no QA.  

There is likely a fundamental design flaw in that the cli is not itself 
an xml client like you see on other platforms.  The XML interface, and
CLI (presumably netconf) may all be distinct clients to sysdb.  I did 
get (3) ddts' assigned, related to missing data compared to cli, endian 
issues, etc.  My recommendation is DO NOT USE IT.  

I went back to screen scraping for ios-xr.  Related to this and other
issues, all of our subsequent purchases have been MX.

Dale
AS{59,2381,3128}

Re: ARIN Enters Phase Four of the IPv4 Countdown Plan

[Dale W. Carder]

Thus spake Paul S. (cont...@winterei.se) on Wed, Apr 23, 2014 at 11:35:20PM 
+0900:
 Am I the only one who thinks this 'clench' is rather absurd
 especially right after one company pretty much got 1/4th of all
 remaining address space when there's such an insane crunch looming?

Deck Chairs.

Dale

Re: Managing IOS Configuration Snippets

[Dale W. Carder]

Thus spake Ryan Shea (ryans...@google.com) on Thu, Feb 27, 2014 at 09:38:33AM 
-0500:
 
 Now, I hand you the 'show run' output and ask you if version 77 of the vty
 config is on this device. Can you answer the question? Now I hand you the
 'show run' from 10,000 more device configs - and 100 more configuration
 chunks from revision control. Can you still answer the question? Assume a
 magical revision-history-aware configuration cross reference parser (while
 a noble and lovely goal) is not available.

Hi Ryan,

If I'm understanding what you're trying to do, you could script around 
our rather unsophisticated 'sgrep' (stanza grep) tool combined with 
scripting around rancid  rcs to do what I think you are looking for.

http://net.doit.wisc.edu/~dwcarder/scripts/sgrep

sgrep can dump out a stanza of ios-like config, then you can rcsdiff
that to your master, per 'chunk' of config.  

ex:
 sgrep -s vty r-cssc-b280c-1-core.conf
Found stanza in r-cssc-b280c-1-core.conf size:9
line vty 0 4
 access-class G-A-AdminAccess in
 exec-timeout 30 0
 ipv6 access-class G-A-v6AdminAccess in
line vty 5 24
 access-class G-A-AdminAccess in
 exec-timeout 30 0
 ipv6 access-class G-A-v6AdminAccess in
!

See the -s and -e options for our sgrep.

Add 'xargs -P' around your glue, and I think you'd be in luck.  If you 
were building configs around this model, you could use m4.

Dale

Re: Managing IOS Configuration Snippets

[Dale W. Carder]

Thus spake Keegan Holley (no.s...@comcast.net) on Fri, Feb 28, 2014 at 
09:49:19AM -0500:
 I wasn’t saying just fix it.  I was saying that router configs don’t lend 
 well to versioning.  

Um, what?

$ rlog r-cssc-b280c-1-core.conf | grep 'total revision'
total revisions: 2009;  selected revisions: 2009

 When it’s a router config chances are someone fat-fingered something.  Most 
 of the time the best thing to do is to fix or at least alert on the error, 
 not to record it as a valid config version. 

We have our operators manually check in revisions (think in rcs terms:
co -l router, go do work, verify it, ci -u router) rather than
unsolicited / cron-triggered checkins.  Then the check-in message
contains the operator's description text of the change and often a
ticket number.  So there slightly fewer fat-finger configs checked in.

Dale

Re: turning on comcast v6

[Dale W. Carder]

Thus spake Jamie Bowden (ja...@photon.com) on Fri, Dec 20, 2013 at 01:07:27PM 
+:
  From: Lee Howard [mailto:l...@asgard.org]
  On 12/20/13 7:36 AM, Jamie Bowden ja...@photon.com wrote:
   From: Owen DeLong [mailto:o...@delong.com]
 
 
   I'm almost afraid to ask about the phrase add-default-route=yes in the
   dhcp-client configuration. That seems wrong on the face of it since you
   should be getting your routing information from RA and not DHCP.
 
  No, no, no, a thousand times no.  I'm sure RA is great for small SOHO
  networks and for ISPs as a means to hand out resources, but in a
  corporate environment, we hate you.  How many times do the IPv6 people
  have to hear that until DHCPv6 reaches feature parity with DCHPv4, IPv6
  is dead to enterprise networks?
 
Strange, I have an enterprise network with some segments running ipv6 for 
over a decade ;-)
 
  Parity isn't enough information; what features are missing?  RA is part
  of IPv6, but you don't have to use SLAAC.
  I'd say it's the DHC people who need to hear it, not the IPv6 people, but
  YMMV.
 
 I have a question.  Why does DHCP hand out router, net mask, broadcast 
 address, etc. in IPv4; why don't we all just use RIP and be done with it?

I think you mean IRDP/rfc1256.  We used to run quite a bit of that, too.

Dale

Re: Wiki for people doing IPv6-only testing

[Dale W. Carder]

Thus spake Jason Fesler (jfes...@gigo.com) on Wed, Jun 19, 2013 at 04:55:01PM 
-0700:
 On a recent IPv6 providers call, there was a desire for participants
 to share information with each other on what works and what breaks in
 an IPv6-only environment.  I offered to set that up.   It was further
 suggested I should share this with more than just that small
 community; to anyone who might be doing work to test out IPv6-only
 scenarios.
 
 http://wiki.test-ipv6.com
 

You may also want to check out the work Ron Broersma has done at DREN.

Dale

Re: ipp.gov and Google DNS (8.8.8.8)

[Dale W. Carder]

Thus spake Casey Deccio (ca...@deccio.net) on Thu, May 30, 2013 at 11:17:03AM 
-0700:
 On Thu, May 30, 2013 at 9:22 AM, Yunhong Gu g...@google.com wrote:
  Google resolvers got no response (i.e. timeout) for ipp.gov/dnskey from its
  authoritative name servers. If there is anyone on this list who manages
  ipp.gov DNS servers, please take a look. Our resolver IPs can be found at
  https://developers.google.com/speed/public-dns/faq#locations.
 
 
 
 I get a response for DNSKEY just fine*.  However, the payload of the
 response is 1279 bytes, and Google's resolvers set the maximum UDP
 receive payload to 1232, which results in the truncated response.
 Unfortunately, the ipp.gov servers don't respond over TCP, so the
 resolvers aren't able to retrieve ipp.gov/DNSKEY.
 
 The problem here is that the ipp.gov servers aren't responding on
 TCP/53.  But of curiosity, why a max payload size of 1232 for the
 Google resolvers?  

I would guess that it is to fit inside tunnels?  You will also see
smaller than usual MSS (ex: 1416) from some (all?) google tcp services.

Dale

Re: APC In-row Units

[Dale W. Carder]

Thus spake Morgan Miskell (morgan.misk...@caro.net) on Tue, May 21, 2013 at 
09:49:14AM -0400:
 I realize this topic is semi off point so feel free to reply to the list
 or to me personally.  I am wondering if anyone has any experience using
 the APC In-row cooling units in their data centers.  I am specifically
 looking at the ACRD501.
 
 Do they work well?  How long have you run them?  Any maintenance issues?

We have lots of the apc units, including the 500 or 501 IIRC.  In general they
are great except for finding skilled enough labor to install  maintain them.
They are capable of getting your equipment mighty wet.

Also pay attention to your water quality during the design process.

Dale

Re: Big day for IPv6 - 1% native penetration

[Dale W. Carder]

Thus spake Dobbins, Roland (rdobb...@arbor.net) on Tue, Nov 27, 2012 at 
03:16:27PM +:
 
 On Nov 27, 2012, at 9:50 PM, Randy Bush wrote:
 
  the cause is netflix and youtube, with a bit of help from fb and 
  non-youtube gobble.
   
 Just because their users can reach popular content-rich/high-bandwidth 
 endpoint sites via IPv6 *that they can also reach via IPv4* doesn't seem to 
 provide much of an incentive in and of itself for IPv6 deployment.  

I would consider 40% offload from your expensive CGN to be incentive in and of 
itself.

Dale

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)

[Dale W. Carder]

Thus spake Chuck Church (chuckchu...@gmail.com) on Wed, Jun 06, 2012 at 
10:58:05AM -0400:
 Does anyone know the reason /64 was proposed as the size for all L2 domains?

Some day eui-48 will run out.  So, just assume eui-64 now and map into it.

Also, as you point out below, not all L2 is ethernet.

 I've looked for this answer before, never found a good one.  I thought I
 read there are some L2 technologies that use a 64 bit hardware address,
 might have been Bluetooth.  Guaranteeing that ALL possible hosts could live
 together in the same L2 domain seems like overkill, even for this group.
 /80 would make more sense, it does match up with Ethernet MACs.  Not as easy
 to compute, for humans nor processors that like things in 32 or 64 bit
 chunks however.  Anyone have a definite answer?

A good history lesson for this addressing model would be to look at IPX.
(And maybe also IRDP for ipv4).  When we did our first trial ipv6
deployments here in the early 2000's we were still running IPX, so I guess
SLAAC wasn't hard to grasp.

Dale

Re: http://www.moduletek.com/ SFP's anyone using them

[Dale W. Carder]

Hey James,

On Mar 22, 2012, at 4:49 PM, James Braunegg wrote:
 http://www.moduletek.com/
 Just wondering if anyone has used  moduletek 10gbit SFP's+ and what has your 
 experience been like ?


We've used a variety of what they have for 4-5 years now in
in lots of flavors of sfp, sfp+, x2, xfp, xenpak, lr  cwdm, 
etc, in vendors C, J, and what is now D gear. 

Cost effective and reliable.  Lead times depend on stock / fab /
shipping / customs.  I have heard they might do paypal now in
addition to wire xfer.  

Dale
as59 / as2381

Re: Switch designed for mirroring tap ports

[Dale W. Carder]

Thus spake Jeff Kell (jeff-k...@utc.edu) on Thu, Mar 01, 2012 at 10:22:29AM 
-0500:
 How about splitting up a heavy stream (10G) into components (1G) to run 
 through an
 inline device and reassemble the pieces back to an aggregate afterward?

Sounds like a perfect job for a commodity switch that supports OpenFlow.

Dale

Re: Choice of address for IPv6 default gateway

[Dale W. Carder]

Hi Daniel,

On Jan 25, 2012, at 8:41 AM, Daniel STICKNEY wrote:
 I'm having trouble finding authoritative sources on the best common
 practice (if there even is one) for the choice of address for an IPv6
 default gateway in a production server environment (not desktops). For
 example in IPv4 it is common to chose the first or last address in the
 subnet (.1 or .254 for example) as the VIP for VRRP/HSRP. I'm interested
 in input from production environments and or ARIN/RIPE/IANA/etc or top
 vendors.

Well, you're not going to find anything authoritative per se, but
we are using fe80::1 with HSRP on every LAN with v6 enabled.  More recent
HSRP implementations also support prefix::1, but that doesn't seem to 
make any sense to me since link-local is where your gateway lives.

 What about using RAs to install the default route on the servers? The
 'priority' option (high/medium/low) easy fits with an architecture using
 an active/standby router setup where the active router is configured
 with the 'high' priority and the standby 'medium'. With the timeout
 values tuned for relatively rapid (~3 seconds)  failover this might be
 feasible. Anyone use this in production?

Our servers are statically assigned with prefix::1000 and counting up,
and fe80::1%int for the gateway.  Some servers are doing an IP per
service / customer.

In some initial deployments I did, RA Priority did not seem to be 
observed.  That was 8 or 9 years ago so maybe that has changed, but it
was not comforting.  

We were more worried about unintentional  rogue RA vs active/standby
routers.  Now that we have RA Guard deployed on  100,000 edge ports, 
that doesn't really matter anymore.

Dale

Re: using ULA for 'hidden' v6 devices?

[Dale W. Carder]

On Jan 25, 2012, at 9:51 AM, Justin M. Streiner wrote:
 Is anyone using ULA (RFC 4193) address space for v6 infrastructure that does 
 not need to be exposed to the outside world?  I understand the concept of 
 having fc00::/8 being doled out by the RIRs never went anywhere, and using 
 space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood 
 of many organizations that do so not following the algorithm for picking a 
 /48 that is outlined in the RFC.
 
 There would appear to be reasonable arguments for and against using ULA. I'm 
 just curious about what people are doing in practice.

Our site would be in the against ULA camp.  For that matter we had
survived until very recently in the anti-1918 camp, too.  So, take
that as an inherent bias.

We have one customer in particular with a substantial non-publicly 
reachable v6 deployment with globally assigned addresses.  I believe
there is no need to replicate the headaches of rfc1918 in the next 
address-family eternity. 

Dale

Re: Polling Bandwidth as an Aggregate

[Dale W. Carder]

Hi Keegan,

On Jan 19, 2012, at 9:50 PM, Keegan Holley wrote:
 Has anyone had to aggregate bandwidth data from multiple interfaces
 for billing.  For example I'd like to poll with an open source tool
 and aggregate data from multiple interfaces connected to the same
 customer or multiple customers for the purpose of billing and capacity
 management.  Is there an easy way to do this with cacti/rrd or another
 open source kit?

With the rrdtool backend, you can certainly define and add multiple 
sources from different files together.  Using 'AREA' first and 
subsequently 'STACK' to view multiple data sources is particularly 
nice for visualization.

Otherwise, the RRDs and Statistics::Descriptive libraries in Perl can 
probably go a long way towards what you might be wanting for reporting.

Dale

Re: IPv6 NPT and NAT for Linux

[Dale W. Carder]

On Nov 30, 2011, at 2:14 PM, Ray Soucy wrote:

 For those who missed it, Linux is adding NAT for IPv6 to netfilter:
 
 http://www.spinics.net/lists/netfilter-devel/msg19979.html
 
 Along with tradition SNAT, and DNAT targets most of us are familiar
 with, a new NETMAP target is included that implements NPT (network
 prefix translation).
 
 I for one am happy to see this; despite not wanting to see people NAT
 IPv6 as the norm, having the NETMAP target will largely replace the
 use of SNAT and MASQUERADE for many deployments, while keeping those
 tools for the times when traditional NAT is desirable.


Regardless of what one thinks of v6 NAT, having a v6 REDIRECT target
in linux is long overdue.  (trying to do it with tproxy hackery is 
really a mess)

Dale

Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days

[Dale W. Carder]

Thus spake Leigh Porter (leigh.por...@ukbroadband.com) on Thu, Aug 18, 2011 at 
11:47:19AM +:
 
 It seems that any IPv6 efforts by organisations are best effort at most with 
 of course some notable exceptions who seem to offer a really very good 
 service (HE for example). It's starting to get to a point now, I think, that 
 some end users have IPv6 (Andrews and Arnold have offered IPv6 for years) and 
 issues such as these are just going to start to give IPv6 a bad name in the 
 eyes of consumers.
 
 It'd really suck for end users to start actively avoiding IPv6 connectivity 
 because it keeps breaking and for organisations that have active  records 
 to break peoples connectivity to their resources.

This, as Frank points out is why getting Happy Eyeballs support into
applications like web browsers is so important.  I think modern versions
of Chrome  Firefox do this.  Safari does something similar, but
arguably more naive.  I don't know about IE.

Dale

Re: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol)

[Dale W. Carder]

Thus spake Owen DeLong (o...@delong.com) on Tue, Jun 07, 2011 at 05:37:00AM 
-0700:
  
  Things like happy-eyeballs diminish it even with perfect IPv6
  connectivity.  100ms rtt doesn't cover the world and to make
  multi-homed servers (includes dual stack) work well clients will
  make additional connections.
 
 Is happy eyeballs actually running code ANYWHERE?

Very similar, but with a static 300ms timer:
http://code.google.com/p/chromium/issues/detail?id=81686

Dale

Re: Ipv6 for the content provider

[Dale W. Carder]

Thus spake Jack Carrozzo (j...@crepinc.com) on Wed, Jan 26, 2011 at 01:38:48PM 
-0500:
 As I understand it, when a client requests a particular domain of yours and 
 gets
 an A and an , the client will default to the  (assuming it's on a v6
 network) and attempt to communicate as such. Failing that, it will fall back
 to the v4 A record.

This is true for now.  

See http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6
for a proposal on how this could change.

Dale

Re: Ipv6 for the content provider

[Dale W. Carder]

Thus spake Randy McAnally (r...@fast-serv.com) on Wed, Jan 26, 2011 at 
04:50:22PM -0500:
 On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote
 
  For the most part, I'm a data center/application 
  administrator/content provider kind of guy. As such, I want to 
  provide all my web content over ipv6, and support ipv6 SMTP.  What 
  are folks doing in this regard?
 
 The only issue I've faced is RHEL/CentOS doesn't have stateful connection
 tracking for IPv6 - so ip6tables is practically worthless.

Yep, we ran into this too early on with rhel [4,5].  Have you looked at rhel 6?

Dale

Re: RIP Justification

[Dale W. Carder]

Thus spake Jesse Loggins (jlogginsc...@gmail.com) on Wed, Sep 29, 2010 at 
01:20:48PM -0700:
  This leads to my question. What are your views of when and
 where the RIP protocol is useful? 

I most often see RIPv2 used simply to avoid paying vendor license fees to run 
more sophisticated things such as OSPF.

Dale

Re: 1G/10G options over 130 km of fiber

[Dale W. Carder]

On Mar 5, 2010, at 2:36 PM, Justin M. Streiner wrote:
 My gut tells me that the 2-point loss on the span at 1550nm will be somewhere 
 around 30-35 dB.

What's your measured chromatic dispersion?  You might need 
to budget in the hit from compensation too.  Some of the
super long range optics have wide tolerance of dispersion,
but probably not without a penalty.  

If you don't have a measurement, you can estimate w/ the values 
for that fiber type.

Dale

Re: Alaska IXP?

[Dale W. Carder]

On Mar 4, 2010, at 10:33 AM, Jay Hanke wrote:
 From the looks of the link it looks like there is a bit of traction at the
 MadIX. One of the other interested carriers has talked to the University of
 MN and they showed some interest in participating. The trick is getting the
 first couple of participants to get to critical mass. Is the MadIX using a
 route server or is it strictly layer2?

Just L2 w/ PIM snooping.

Dale

Re: log parsing tool?

[Dale W. Carder]

On Feb 22, 2010, at 4:49 PM, fedora fedora wrote:
 ah, never heard of SEC before and it really looks interesting,


Take a look at SLCT, also by Risto Vaarandi:

http://ristov.users.sourceforge.net/slct/

SLCT can parse huge amounts of logs very fast.  We use it to
crunch firewall logs and also to find ports that are flapping
excessively.

Dale

Re: Using /126 for IPv6 router links

[Dale W. Carder]

On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote:


you face 2 major issues with not using /127 for
PtP-type circuits:

1) ping-ponging of packets on Sonet/SDH links

Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP
interface, and somebody comes along and ping floods 2001:db8::2,
those packets will bounce back and forth between the 2 sides of
the link till TTL expires (since there is no address resolution
mechanism in PtP, so it just forwards packets not destined for
him on).


Following this, IPv4 /30 would have the same problem vs /31?


2) ping sweep of death

Take the same assumption for addressing as above, and now ping
sweep 2001:db8::/64... if the link is ethernet, well, hope you
didn't have any important arp entries that the router actually
needed to learn.


Wouldn't this affect *all* /64's configured on a router, not
just point to point links?  Time for glean rate limiting.

If you were really concerned, you could hard code static NDP
entries, as I think someone else pointed out.

Dale

Re: Juniper M120 Alternatives

[Dale W. Carder]

On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote:

 Having slightly lost track of what everybody is using for peering routers
 these days, what is the consensus about the best alternative to Juniper M
 series routers?

have you looked at the MX series?

Dale

Re: IPv6 Confusion

[Dale W. Carder]

On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote:

On 19/02/2009, at 9:53 AM, Leo Bicknell wrote:


Let me repeat, none of these solutions are secure.  The IPv4/DHCP  
model

is ROBUST, the RA/DHCPv6 model is NOT.


The point I am making is that the solution is still the same -  
filtering in ethernet devices.


Perhaps there needs to be something written about detailed  
requirements for this so that people have something to point their  
switch/etc. vendors at when asking for compliance. I will write this  
up in the next day or two. I guess IETF is the right forum for  
publication of that.


Is there something like this already that anyone knows of?



http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt

This is the last message I recall seeing in v6ops about it:

It seems to me that the L2 devices are welcome to perform
whatever filtering they like regardless of any documents
that might come from the IETF. Therefore, I'd like to see
more pros/cons on this.
http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01733.html

Cheers,
Dale

Re: BCP for Private OUI / address assignments?

[Dale W. Carder]

On Nov 24, 2008, at 11:02 AM, mike wrote:

 I am needing more and more unique mac addresses

...

 it occurs to me that there should be something - ala rfc 1918



You can probably find examples online, but in a nutshell this
does exist.

Set bit b2 to 1, locally assigned.
Default is 0, globally unique (OUI assigned).

Cheers,
Dale

--
Dale W. Carder - Network Engineer
University of Wisconsin / WiscNet
http://net.doit.wisc.edu/~dwcarder

Re: Network topology [Solved]

[Dale W. Carder]

On Oct 15, 2008, at 1:35 PM, Colin Alston wrote:


On 2008/10/15 06:29 PM Colin Alston wrote:
Is there any kind of cunning trick to detect standard layer2  
switches along a path without stuff like STP?


Apparently there isn't. Lots of people mentioned other tools, the  
problem there is they have one thing in common which is polling  
SNMP. I think it scales badly in general.


What is your reasoning behind this claim?  I would claim
quite the opposite compared to CLI or TL1.

Maybe there should be something (I mean like, someone should come  
up with a standard :P) to trace switches in a path


I've written a cruddy script that given a seed bridge, scrapes
L2 information obtained via CDP (I guess it could do LLDP, too)
and does a breadth-first search through a network.  Then I just
dump that into gnuplot format.  Getting the data is easy compared
to visualization.

A coworker of mine has written script to ask Rapid-STP speaking
switches about their current topology and builds a graph again
in gnuplot format.

A more challenging approach would be to scrape the mac forwarding
tables and stitch things together.  This would have to be done
per-vlan.  I think this approach (or similar) might be done by
Openview's L2 featureset.

Dale

--
Dale W. Carder - Network Engineer
University of Wisconsin / WiscNet
http://net.doit.wisc.edu/~dwcarder

Re: SLAAC(autoconfig) vs DHCPv6

[Dale W. Carder]

Hey Scott,

On Aug 18, 2008, at 2:33 PM, Scott Weeks wrote:

From: TJ [EMAIL PROTECTED]

As a general rule, most clients are following the If we gave them  
static
IPv4 addresses we will give them static IPv6  
addresses (infrastructure,
servers, etc).  The whole SLAAC(autoconfig) vs DHCPv6 is a separate  
(albeit

related) conversation ...


I'm still an IPv6 wussie and would like to learn more before moving  
forward, so would anyone care to share info on experiences with this  
decision?


Here's some pro's and con's to both

SLAAC:
- widely implemented in host v6 stacks that have shipped
- widely implemented on v6 routers
- really, really, really broken: it didn't support handing out
  any DNS info until RFC 5006, thus SLAAC still requires human
  intervention on a client to make teh v6 interwebs work.  It
  will probably be a painful wait until 5006 gets more widely
  implemented on hosts (if ever, for some)  routers.
- probably faster than dhcpv6 w/ tuning timers.  Could be
  better for mobile thingys.
- supports RFC 3041 security by obscurity extensions.

DHCPv6
- doesn't ship w/ some OS's
- new (danger code), not all features implemented
- router support for dhcpv6 relay very limited
- advanced things like prefix delegation don't really seem to
  have been ironed out.

In case you weren't confused enough between the two, they are not
mutually exclusive.  You can run both SLAAC and DHCPv6 at the same
time on the same L2.

Links for (2) dhcpv6 implementations:
http://klub.com.pl/dhcpv6/
http://www.isc.org/index.pl?/sw/dhcp/dhcp4_0.php

Cheers,
Dale

Re: [NANOG] DWDM More Details

[Dale W. Carder]

On Apr 25, 2008, at 12:58 PM, Alex Pilosov wrote:
 On Fri, 25 Apr 2008, John Lee wrote:

 I'd be curious to ask reverse question, did anyone *have* real  
 problems
 deploying duct tape systems, or power jitter chromatic dispersion is
 vendor mumbo jumbo designed to make you buy their gear?
 (within the distance limits spec'd, 80km dwdm etc)

What I think you are referring to is known as the
Gordon-Haus effect.  This is related to the length
of a strand to the 3rd power, so I would guess for
modern optics / filters, it is a non-issue for 80k.

Dale



___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog