On Wed, 19 Dec 2018 at 02:55, Philip Loenneker
wrote:
> I had a heck of a time a few years back trying to troubleshoot an issue where
> an upstream provider had an ACL with an incorrect mask along the lines of
> 255.252.255.0. That was really interesting to talk about once we discovered
> it,
In general I agree with the idea here but I would also be interested in the
possibility of running the local route policy engine against routes that
are locally detected to meet a damping condition (user configureable of
course). This would potentially yield the ability to change local_pref as
well
On Dec 19, 2018, at 3:50 AM, Brian Kantor wrote:
> /24 is certainly cleaner than 255.255.255.0.
>
> I seem to remember it was Phil Karn who in the early 80's suggested
> that expressing subnet masks as the number of bits from the top end
> of the address word was efficient, since subnet masks wer
I had a heck of a time a few years back trying to troubleshoot an issue where
an upstream provider had an ACL with an incorrect mask along the lines of
255.252.255.0. That was really interesting to talk about once we discovered it,
though it caused some loss of hair beforehand...
-Original
On 12/18/2018 03:12 PM, David Edelman wrote:
I seem to remember that before the advent of VLSM and CIDR there was
no requirement for the 1 bits in the netmask to be contiguous with no
intervening 0 bits and there was always someone who tested it out on a
production network just to prove a point
On 12/18/18 5:52 PM, James R Cutler wrote:
I am certain that I read the RFC years ago, but I can’t remember it. Which RFC?
RFC796 defines the address formats for classes A, B, and C. A starts
with a 0 bit, B starts with 10, and C starts with 110 according to said RFC.
--
Brandon Martin
> On Dec 18, 2018, at 5:43 PM, Brandon Martin wrote:
>
> On 12/18/18 2:58 PM, Scott Weeks wrote:
>> You can safely say that 72.234.7.0/24 is a
>> Class C/sized/ network.
>> --
>> But most don't say that. They just say it's
>> a Class C, which it most assuredl
On 12/18/18 2:58 PM, Scott Weeks wrote:
You can safely say that 72.234.7.0/24 is a
Class C/sized/ network.
--
But most don't say that. They just say it's
a Class C, which it most assuredly is not.
I heckle them until they can give the correct
answer: leading
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I seem to remember that before the advent of VLSM and CIDR there was no
requirement for the 1 bits in the netmask to be contiguous with no intervening
0 bits and there was always someone who tested it out on a production network
just to prove a poin
I will grant you that no customer ever asked for route dampening. I also
realize that RFD is much less important now than in the past. I come from the
ARPANET/DDN ages of the Internet and can tell you that RFD was absolutely
critical in the days of very under powered routers and very unstable
I think you will find that very hard to evaluate since the value of RFD will be
different in different network regions. For example, it is probably good
practice to run RFD toward a customer on an unstable access link. It might not
be a good idea to run it on a major backbone link that could p
I see it more used in terms of firewall operations on what are normally network
routing devices. I suppose someone with Cisco IOS architecture inside
knowledge could tell us why they use that notation with ACLs primarily.
I have never seen a computer want or accept an inverse mask so it is
Dear Steve,
No worries, I have not forgotten the transitive properties of the
LOCAL_PREF BGP Path Attribute! :-) You are right that any LOCAL_PREF
modifications (and the attribute itself), are local to the Autonomous
System in which they were set, but the effects of such settings can
percolate fur
On Tue, Dec 18, 2018 at 1:30 PM Naslund, Steve wrote:
> 2. The inverse mask is indeed a pain in the neck but is technically
> correct.
Hi Steve,
That's like saying the inverse mask is technically correct when the
computer wants to decide whether to arp for the next hop. No sale man.
A AND
It is an interesting article but confirms a few things to me.
1. There are only a very small percentage of flapping routes causing an
inordinate amount of BGP processing. Would it be more effective to implement
this route damping mechanism world wide or try to eliminate the source of the
in
What would really be of interest to me would be for those that run RFD
to measure its impact to their network (positive or otherwise) so we
have something scientific to base on.
The theory (and practice of old) tells us that RFD is either very good,
or very bad. There are probably more folk that h
Two reasons :
1. Legacy configuration portability, people learned a certain way and all
versions of code understand a certain way. The best way to correct that issue
it to accept either of them.
2. The inverse mask is indeed a pain in the neck but is technically
correct. The subne
--- snasl...@medline.com wrote:
From: "Naslund, Steve"
Mainly because propagating a flapping route across
the entire Internet is damaging...
https://www.researchgate.net/publication/220850232_Route_Flap_Damping_Made_Usable
scott
Remember always that the local pref is just that, YOUR local preference.
Sending that flapping route upstream does not give your peer the option to
ignore it. In any case, the downside is that you have to process that route
and then choose whether or not to use it. It’s like saying “now that
Why do we still have network equipment, where half the configuration
requires netmask notation, the other half requires CIDR and to throw you
off, they also included inverse netmasks.
tir. 18. dec. 2018 20.51 skrev Brian Kantor :
>
> /24 is certainly cleaner than 255.255.255.0.
>
> I seem to rem
Hi Steve,
Lowering the LP would achieve the outcome you desire, provided there are
(stable) alternative paths.
What you advocate results in absolute outages in what may already be
precarious situations (natural disasters?) - what Saku Ytti suggests like a
less painful alternative with desirable p
Mainly because propagating a flapping route across the entire Internet is
damaging to performance of things other your own equipment and that of your
customer. It is just "bad manners" to propagate a flapping route to your peers
and it helps maintain a minimum level of stability that it require
It is a matter of machine readability vs human readability. Remember the IP
was around when routers did not have a lot of horsepower. The dotted decimal
notation was a compromise between pure binary (which the equipment used) and
human readability. VLSM seems obvious now but in the beginning
On Tue, 18 Dec 2018 at 21:52, Brian Kantor wrote:
> of the address word was efficient, since subnet masks were always
> a series of ones followd by zeros with no interspersing, which
> was incorporated (or independently invented) about a decade later
>From protocol POV there is no reason to make
--- nanog@nanog.org wrote:
From: Grant Taylor via NANOG
You can safely say that 72.234.7.0/24 is a
Class C /sized/ network.
--
But most don't say that. They just say it's
a Class C, which it most assuredly is not.
I heckle them until they can give the
/24 is certainly cleaner than 255.255.255.0.
I seem to remember it was Phil Karn who in the early 80's suggested
that expressing subnet masks as the number of bits from the top end
of the address word was efficient, since subnet masks were always
a series of ones followd by zeros with no intersp
On 12/18/2018 11:44 AM, Scott Weeks wrote:
It's good to have at least a passing understanding of the old terminology
simply because documentation for newer stuff likes to reference it...
Agreed.
I seldom see people actually talking about class {A,B,C,D,E} networks as
such. It's almost always
On 12/18/2018 10:00 AM, Rabbi Rob Thomas wrote:
We'd be happy to make that happen, if folks are keen.
I'm keen.
We're fine with Git, as we use it regularly.
How big is the bogon list? (I can't look at the moment.) Is it
something that you can store the entire list periodically, or as it
On Mon, Dec 17, 2018 at 9:36 PM Joe wrote:
> Apologizes in advance for a simple question. I am finding conflicting
> definitions of Class networks. I was always under the impression
> that a class "A" network was a /8 a class "B" network was a /16
> and a class "C" network was a /24. Recently, I w
> On Dec 18, 2018, at 1:45 PM, Mark Tinka wrote:
>
>
>
> On 18/Dec/18 19:40, Randy Bush wrote:
>
>> do you have rfd on? with what parms?
>
> We don't do it (SEACOM, AS37100).
Similarly 20940 does not use it. I find it hard to see a case where we would
turn it on.
- jared
I always wondered why does it have to be so binary.
I don't want to decide for my customers if partial visibility is
better than busy CPU, but I do appreciate stability. Why can't we have
local-pref penalty for flapping route. If it's only option, keep
offering it, if there are other, more stable
On 18/Dec/18 19:40, Randy Bush wrote:
> do you have rfd on? with what parms?
We don't do it (SEACOM, AS37100).
Mark.
On 18/Dec/18 19:40, Randy Bush wrote:
> do you have rfd on? with what parms?
We don't do it (SEACOM, AS37100).
Mark.
--- beec...@beecher.cc wrote:
From: Tom Beecher
It's good to have at least a passing understanding of
the old terminology simply because documentation for
newer stuff likes to reference it...
--
Plus it's fun (and informative about a netgeek's skill)
wh
That's a great example. Thank you James for sharing. I have done so many
"GROUND TRUTH" visits where randomly selected certain physical points to
validate physical diversity. Have seen several places where dual risers in
the building were present or multiple building entries were available but
not
Route Flap Damping via https://tools.ietf.org/html/rfc2439 for everyone.
On Tue, Dec 18, 2018 at 11:42 AM Randy Bush wrote:
> do you have rfd on? with what parms?
>
> randy
>
--
- Andrew "lathama" Latham -
On Tue, Dec 18, 2018 at 6:40 PM Randy Bush wrote:
>
> do you have rfd on? with what parms?
I assume rfd in this context means "Route Flap Dampening".
NTT / AS 2914 does *not* have Route Flap Dampening configured, as is
documented here
https://us.ntt.net/support/policy/routing.cfm#routedampening
do you have rfd on? with what parms?
randy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Tom,
> I wonder if there's value in having the lists that Team Cymru
> generates auto pushed to a public Git repo. Covers historical
> changes for folks who want that, and also provides a more modern
> ingestion method for automation around tha
I can't stress enough the importance of controlling your own route and even
cable diversity. Require KMZs of the routes for any services you take
(especially single path Wave type services). Put them in the contracts if you
can.
I've had at least 1 situation where we had vendor diversity and w
I wonder if there's value in having the lists that Team Cymru generates
auto pushed to a public Git repo. Covers historical changes for folks who
want that, and also provides a more modern ingestion method for automation
around that info. (Not that I'm hating on wget / curl ... :) )
On Mon, Dec 17
Sent from my iPhone
> On Dec 17, 2018, at 9:36 PM, Joe wrote:
>
> Recently, I was made aware that a class "A" was indeed a /8 and a class "B"
> was actually a /12 (172.16/172.31.255.255) while a class "C" is actually a
> /16.
You had it right to start with.
A is (was) /8, B is /16, C is
If you want the full historical definition, blow the dust off RFC791, and
open your hymnals to section 2.3.
"Addresses are fixed length of four octets (32 bits). An address
begins with a network number, followed by local address (called the
"rest" field). There are three formats or class
On Mon, 17 Dec 2018, Joe wrote:
Apologizes in advance for a simple question. I am finding conflicting
definitions of Class networks. I was always under the impression that a
class "A" network was a /8 a class "B" network was a /16 and a class "C"
network was a /24. Recently, I was made aware tha
44 matches
Mail list logo
