Hi Aseem,
On Wed, Dec 26, 2018 at 6:42 PM Aseem Choudhary wrote:
> Hi Christian,
>
> Discontinuous mask for IPv6 was supported in IOS-XR in release 5.2.2.
>
> You can refer below link for details:
>
>
ent.html
<https://mailman.nanog.org/pipermail/nanog/attachments/20181220/cfd683a3/attachment.html>>
--
- Previous message (by thread): Stupid Question maybe?
<https://mailman.nanog.org/pipermail/nanog/2018-December/098410.html>
- Next message (by th
When I first started working with Cisco products (around 1999) I came upon
a router doing NAT for internet access that used a discontiguous mask to
determine which address to PAT the hosts against as they were doing some
creative load balancing. It worked really well, no matter what part of the
> On 18 Dec 2018, at 22:30, Joel Halpern wrote:
>
> History of non-contiguous network masks, as I observed it. [snip]
>
> When we were done, other folks looked at the work (I don't know if the
> Internet Drafts are still in repositories, but they shoudl be.) And
> concluded that while this
* Baldur Norddahl:
> 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.
Some also drop the prefix length in diagnostic output if it matches
that of the address
On Thu, 20 Dec 2018 at 21:06, Grant Taylor via NANOG wrote:
> Do you have /24 cover prefixes advertised to the Internet?
Yes, just it drops at the peering edge as more specific is not found.
> $EMPLOYER requires globally routable access to the link net IP on our
> equipment for specific
On 12/20/2018 10:55 AM, Saku Ytti wrote:
Correct.
Do you have /24 cover prefixes advertised to the Internet?
What is that use-case? Do notice that I propose opt-in static host/32
route pointing to the link, giving far-end INET reachability, if they
so want, without adding attack surface on
On Thu, 20 Dec 2018 at 20:07, William Allen Simpson
wrote:
> Then there were the fine vendors that conflated the link and IP headers.
> That fell apart when IEEE started assigning OUIs that began with 0x4xxx.
There is no way to know in-transit what MPLS carries. Vendors have
implemented
On Thu, 20 Dec 2018 at 18:22, Grant Taylor via NANOG wrote:
> Are you advocating not advertising customer linknetworks within your own
> organization?
Correct.
> I know of a use cases where linknetworks must be globally accessible.
> At least the customer's linknetwork IP address. So, not
On 12/19/18 2:47 PM, valdis.kletni...@vt.edu wrote:
So at one show, the Interop show network went to a 255.255.252.0 netmask, and
of course a lot of vendors had issues and complained. The stock response was
"Quit whining, or next show it's going to be 255.255.250.0".
Ha, I remember!
Let us
On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti wrote:
> 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
On 19/12/2018 16:24, Naslund, Steve wrote:
It has ALWAYS been the only correct way to configure equipment and is
a requirement under CIDR. Here were your commonly used netmasks
before CIDR/VLSM :
255.0.0.0 255.255.0.0 255.255.255.0
Which one is not contiguous?
There is an example in RFC950
On Wed, 2018-12-19 at 14:54 +, Naslund, Steve wrote:
> I am wondering how a netmask could be not contiguous when the network
> portion of the address must be contiguous. I suppose a bit mask
> could certainly be anything you want but a netmask specifically
> identifies the network portion of
intervening
0 bits and there was always someone who tested it out on a production network
just to prove a point (usually only once)
Dave
- -Original Message-
From: NANOG On Behalf Of Naslund, Steve
Sent: Tuesday, December 18, 2018 3:37 PM
To: nanog@nanog.org
Subject: RE: Stupid Question ma
On 12/20/2018 02:47 AM, Saku Ytti wrote:
Aye. I'd recommend not advertise your linknetworks at all, and let
customers either opt-in or out-out from creating /128 and /32 static
route towards interface. Achieving mostly same result, except for in
local device where edge interfaces can reach
On Thu, 20 Dec 2018 at 10:32, Christian Meutes wrote:
> And unfortunately is still not supported by IOS-XR for IPv6, which could mean
> not having a scaleable way on your edge to protect your internal network.
Aye. I'd recommend not advertise your linknetworks at all, and let
customers either
Just wanted to say thanks to all for responses about the information on
this! Extremely informative and helpful.
Have a great holiday and happy new year!
-Joe
>
>
>
>
I remember working on a SGI Unix workstation, where you simply could not
specify netmask. It was implicated by the class of address. This meant that
there were only three possible netmasks.
If that was how the first IP implementations started out, we had contiguous
netmasks at the
:47 PM
To: Thomas Bellman
Cc: nanog@nanog.org
Subject: Re: Stupid Question maybe?
> On Dec 19, 2018, at 12:11 , Thomas Bellman wrote:
>
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
>
>> There was indeed a fairly long stretch of time (until the CID
On Wed, 19 Dec 2018 21:11:39 +0100, Thomas Bellman said:
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
> > There was indeed a fairly long stretch of time (until the CIDR RFC came out
> > and
> > specifically said it wasn't at all canon) where we didn't have an RFC that
> >
> On Dec 19, 2018, at 12:11 , Thomas Bellman wrote:
>
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
>
>> There was indeed a fairly long stretch of time (until the CIDR RFC came out
>> and
>> specifically said it wasn't at all canon) where we didn't have an RFC that
>>
On 2018-12-19 21:28 MET, William Herrin wrote:
> Easy: .97 matches neither one because 64 & 97 !=0 and 32 & 97 != 0.
> That's a 0 that has to match at the end of the 10.20.30.
D'oh! Sorry, I got that wrong. (Trying to battle 10+% packet loss at
home and a just upgraded Thunderbird at the same
On Wed, Dec 19, 2018 at 12:12 PM Thomas Bellman wrote:
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
> > There was indeed a fairly long stretch of time (until the CIDR RFC came out
> > and
> > specifically said it wasn't at all canon) where we didn't have an RFC that
> > specifically
On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
> There was indeed a fairly long stretch of time (until the CIDR RFC came out
> and
> specifically said it wasn't at all canon) where we didn't have an RFC that
> specifically said that netmask bits had to be contiguous.
How did routers
On Tue, 18 Dec 2018 17:12:45 -0500, "David Edelman" said:
> 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
>
>Why do you think the network portion needs to be contiguous?
Just because some equipment at one time let you configure a non-contiguous mask
does not make it correct configuration. Please come up with any valid use case
for a non-contiguous network (note NETWORK, not any other purpose) mask.
Why do you think the network portion needs to be contiguous?
Well, it does now. But that was not always the case.
https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid/answer/Patrick-W-Gilmore
https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid
--
TTFN,
patrick
>
On 12/18/18 8:38 PM, Fred Baker wrote:
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
I am wondering how a netmask could be not contiguous when the network portion
of the address must be contiguous. I suppose a bit mask could certainly be
anything you want but a netmask specifically identifies the network portion of
an address.
Steve
> I seem to remember that before the
On Tuesday, 18 December, 2018 22:43, "Brandon Martin"
said:
> This is a favorite interview type question of mine, but I won't
> disqualify a candidate if they can't come up with the reason. It's more
> of a probe for historical domain knowledge (one of many I'll slip in).
It's an
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,
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
Message-
From: NANOG On
Behalf Of Grant Taylor via NANOG
Sent: Wednesday, 19 December 2018 10:27 AM
To: nanog@nanog.org
Subject: Re: Stupid Question maybe?
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 requi
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
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
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:
a point (usually only once)
Dave
- -Original Message-
From: NANOG On Behalf Of Naslund, Steve
Sent: Tuesday, December 18, 2018 3:37 PM
To: nanog@nanog.org
Subject: RE: Stupid Question maybe?
It is a matter of machine readability vs human readability. Remember the IP
was around when routers
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
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
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
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
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
--- 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
/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
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
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
--- 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)
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
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
Class A,B,C represent the position of the first 0 bit in the address and a
corresponding natural netmask. A=1st bit (/8), B=2nd bit (10xx, /16), and
C=3rd bit (110x, /24).
The confusion you seem to be experiencing related to the number of A,B, and C
networks defined in RFC-1918
You may find this helpful in your search for knowledge:
https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
"Classful" networking is rarely useful other than for understanding How We
Got Here.
There's a handy table in the linked article which expresses each IPv4 mask
length in relation
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 that a class "A" was indeed a
/8 and
55 matches
Mail list logo
