Single domain two IP subnets

C

chetan.kamra

Hi All,

I have a single Domain DC and DNS is on same server
Server name = DC.domain.com = 192.168.1.5

The users are divided in to four IP subnets:

Subnet A - 192.168.1.1-62
Subnet B - 192.168.1.65-126
Subnet C - 192.168.1.129-190
Subnet D - 192.168.1.193-254

I have to finish following tasks:

Task1: All the domain machines need to communicate with each other
accept Subnet C
Task2: DNS and DC will be on Subnet A
Task3: How il routing happen?

Please help me i needed to finish this tasks ASAP.


Thanks
CK
 
L

Lanwench [MVP - Exchange]

In
Hi All,

I have a single Domain DC and DNS is on same server
Server name = DC.domain.com = 192.168.1.5

The users are divided in to four IP subnets:
Subnet A - 192.168.1.1-62
Subnet B - 192.168.1.65-126
Subnet C - 192.168.1.129-190
Subnet D - 192.168.1.193-254

Those are not different subnets - they're different IP address 'ranges' in
the same 192.168.1.0 one.

What's the actual business/technical goal here? Knowing that might help
someone give you good advice.
I have to finish following tasks:

Task1: All the domain machines need to communicate with each other
accept Subnet C

Presuming that C were actually a subnet, what is it supposed to have *in*
it, and what's its purpose?

Task2: DNS and DC will be on Subnet A

If you're going to have multiple subnets, you probably ought to have a DC &
DNS & DHCP server in each subnet.
Task3: How il routing happen?

No routing is required with the description you've provided, but if you were
going to set up separate subnets, you could use routers, or switches
configured with VLANs.
Please help me i needed to finish this tasks ASAP.

Again, what's the ultimate goal here?
 
G

Guest

One assumes that you are using a 26 bit subnet mask, 255.255.255.192, for you
"subnets". I use that word loosely because, I think, what your trying to
achive is a VLAN. If this is the case then you are best creating the VLANs on
the nertwork switches, again assuming that your switches are
manageable/configureable. That is something that you will have to check in
the hardware handbook. This again maybe the wrong forum.
 
K

Kurt

This sounds like a homework question. But assuming these are actually
subnets separated by VLANs or something, you'd need a layer-3 switch or
router between them. Router setup would be something like this:

Subnet A
| Subnet B
Router <
| Subnet C
Subnet D

Router interface A 192.168.1.1/26
Router interface B 192.168.65/26
Router interface C 192.168.129/26
Router interface D 192.168.193/26

Computers in each subnet would point to the local router interface as their
default gateway. Assuming the DC/DNS server is 192.168.1.2 then you'd have
to create an access-list and apply it to interface A, something like

access-list 101 permit ip 192.168.128.0 0.0.0.191 host 192.168.1.2
access-list 101 deny ip 192.168.1.128 0.0.0.191 192.168.1.0 0.0.0.255
access-list 101 permit ip any any

line 1 permits subnet C to route to the server
line 2 prevents routing to any other host on the 192.168.1.0/24 network
(access to the local subnet is not routed, so local traffic would still
communicate).
line 3 permits all other routing (assuming the router also has a default
gateway for Internet).

.....kurt
 
C

chetan.kamra

Thanks Guys

It helped alot to me.

I am Difining my current network to all of you may be that will help
you understanding my goals.


ISP----> Gateway Router -->LAN

In lan LAN>> IP are 192.168.1.2 - 192.168.1.254

192.168.1.5 DC/DNS
192.168.1.50-75 >> Special Team

Goals to achive.
1. Special team have to be isolated from Other network +have to be
logged on DC at same time.
2. DNS wil host all IP request to all for whole network.

Thanks
CK
 
H

Herb Martin

"Lanwench [MVP - Exchange]"
In


Those are not different subnets - they're different IP address 'ranges' in
the same 192.168.1.0 one.

Lanwench MIGHT not be incorrect on this one, since
those are probably subnets based on a 255.255.255.192
subnet mask.

What's the actual business/technical goal here? Knowing that might help
someone give you good advice.


Presuming that C were actually a subnet, what is it supposed to have *in*
it, and what's its purpose?

It sounds like a homework or (very STUPID) test prep question.

And it makes no sense for Subnet C to be part of the domain
and NOT communicate.

Not an issue, even which makes it sound even more
like some homework or test prep question:

Just put a router in between with 3 NICs and have all
the machines use it as default gateway.

Why 3 NIC in the router? No point in even connecting Subnet
C if it is NOT going to communicate. said:
If you're going to have multiple subnets, you probably ought to have a DC
& DNS & DHCP server in each subnet.

There is no particular reason for recommending this. Neither
DCs NOR DNS are required on a per subnet basis, unless WAN
lines are involved.

One might expect a second DC and DNS in a real life scenario
though -- merely for fault tolerance.
No routing is required with the description you've provided, but if you
were going to set up separate subnets, you could use routers, or switches
configured with VLANs.

No, if they are four subnets then a router with (at least) 3 NICs
is required.

Chances are it is an attempt for us to do your homework.
Again, what's the ultimate goal here?

Homework is my bet.
 
L

Lanwench [MVP - Exchange]

In
Herb Martin said:
"Lanwench [MVP - Exchange]"
In


Those are not different subnets - they're different IP address
'ranges' in the same 192.168.1.0 one.

Lanwench MIGHT not be incorrect on this one, since
those are probably subnets based on a 255.255.255.192
subnet mask.

Yep - you're right. I saw that in someone else's reply as well. Would've
been helpful if the OP had included the subnet mask.
It sounds like a homework or (very STUPID) test prep question.


And it makes no sense for Subnet C to be part of the domain
and NOT communicate.


Not an issue, even which makes it sound even more
like some homework or test prep question:

Just put a router in between with 3 NICs and have all
the machines use it as default gateway.

Why 3 NIC in the router? No point in even connecting Subnet


There is no particular reason for recommending this. Neither
DCs NOR DNS are required on a per subnet basis, unless WAN
lines are involved.

One might expect a second DC and DNS in a real life scenario
though -- merely for fault tolerance.

Yes, and I was presuming a real-life scenario, I guess.
No, if they are four subnets then a router with (at least) 3 NICs
is required.

Why not VLANs? I admit this isn't my strongest area, but I thought that was
one thing VLANs could do... I bow to your expertise.
 
H

Herb Martin

No, if they are four subnets then a router with (at least) 3 NICs
Why not VLANs? I admit this isn't my strongest area, but I thought that
was one thing VLANs could do... I bow to your expertise.


A VLAN switch is a form of (configuarable) router.

Each individual VLAN is effectively on a separate NIC;
VLAN switches include the ability to DEFINE by the admin
which ports are BRIDGED (same VLAN) and which are
ROUTED (different VLAN and different broadcast domain).

A VLAN Switch is essentially a "routed group of bridges"
but all contained within one box and configurable in software.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

"Lanwench [MVP - Exchange]"
In
Herb Martin said:
"Lanwench [MVP - Exchange]"
In (e-mail address removed) <[email protected]> typed:
Hi All,

I have a single Domain DC and DNS is on same server
Server name = DC.domain.com = 192.168.1.5

The users are divided in to four IP subnets:


Subnet A - 192.168.1.1-62
Subnet B - 192.168.1.65-126
Subnet C - 192.168.1.129-190
Subnet D - 192.168.1.193-254

Those are not different subnets - they're different IP address
'ranges' in the same 192.168.1.0 one.

Lanwench MIGHT not be incorrect on this one, since
those are probably subnets based on a 255.255.255.192
subnet mask.

Yep - you're right. I saw that in someone else's reply as well. Would've
been helpful if the OP had included the subnet mask.
It sounds like a homework or (very STUPID) test prep question.


And it makes no sense for Subnet C to be part of the domain
and NOT communicate.


Not an issue, even which makes it sound even more
like some homework or test prep question:

Just put a router in between with 3 NICs and have all
the machines use it as default gateway.

Why 3 NIC in the router? No point in even connecting Subnet


There is no particular reason for recommending this. Neither
DCs NOR DNS are required on a per subnet basis, unless WAN
lines are involved.

One might expect a second DC and DNS in a real life scenario
though -- merely for fault tolerance.

Yes, and I was presuming a real-life scenario, I guess.
 
K

Kurt

Why not VLANs? I admit this isn't my strongest area, but I thought that
was one thing VLANs could do... I bow to your expertise.

IMHO, VLANs would be the way to go. Otherwise the separation between subnets
is purely logical. Anybody could just change their IP address, or introduce
a laptop with an IP address on another subnet and be connected. VLANs
contain broadcasts and prevent any kind of connection between subnets other
than through the router (which can be locked down as tightly as local
management sees fit). If I were designing this for a client, I would
probably sell them managed layer-2 switches for subnets B-D and a layer-3
switch for Subnet A. Traffic from the other subnets could be trunked through
the uplink port and routed at the L-3 switch. Quick to set up, central
management, fewer devices to configure, plus L-3 switches will forward
gigabit traffic at wire-speed unlike plain vanilla routers.

....kurt
 
H

Herb Martin

Kurt said:
IMHO, VLANs would be the way to go. Otherwise the separation between
subnets is purely logical.

No, subnets in IP are far more than purely logical.

They practically always represent a distinct "Broadcast
domain" (area in which a broadcast will freely propagate.

If two machines are on the same broadcast domain they
are (practically*) always on the same subnet, and conversely
if they are not on the same broadcast domain then they are
not in the same broadcast domain.

[* It is theorectically possible to have multiple subnets on
the same 'wire' or 'broacast domain' but this is not a common
practice in modern networks -- and still requires some special
configuration.]

The real problem is many the incomplete understand of of
VLANs switches, and switches in general, by many people.

One cannot understand VLANs (or any switches) completely
without first understanding the differences and features of
both Routers and Bridges -- we can call the features something
else but switches are merely "switching" combined with either
the Bridge or Router concept, or in modern devices a hybrid
of all three concepts.

VLANs switches allow the admin to (easily) redefine each
bridged segment to include arbitrary connections to the switch,
and thus map a "set of computers" to either one bridged
broadcast domain OR another to which routing is required.

Routed segments REQUIRE different IP subnets while EACH
bridged segment typically (and all modern networks) place all
of the machines on the same subnet.
Anybody could just change their IP address, or introduce a laptop with an
IP address on another subnet and be connected.

This really has nothing specific to do with VLANs per se.

It is a feature of whether that wiring segment is either Bridged or
Routed.

The KEY to a VLAN switch is the "area" or the "component
network cables" which are BRIDGED vs. ROUTED can be
configured by the Admin using switch-commands.
VLANs contain broadcasts and prevent any kind of connection between
subnets other than through the router (which can be locked down as tightly
as local management sees fit). If I were designing this for a client, I
would probably sell them managed layer-2 switches for subnets B-D and a
layer-3 switch for Subnet A. Traffic from the other subnets could be
trunked through the uplink port and routed at the L-3 switch. Quick to set
up, central management, fewer devices to configure, plus L-3 switches will
forward gigabit traffic at wire-speed unlike plain vanilla routers.

The above has little to do with understanding the basic concepts that
are being confused here -- and detracts from keeping the explanation
simple and accurate.
 
K

Kurt

No, subnets in IP are far more than purely logical.
They practically always represent a distinct "Broadcast
domain" (area in which a broadcast will freely propagate).

Not if they're on the same wire. Although IP broadcasts will be discarded at
the layer-3 level, Ethernet broadcasts propogate to every node in the
broadcast domain (not to be confused with collision domain), regardless of
IP subnet.
If two machines are on the same broadcast domain they
are (practically*) always on the same subnet, and conversely
if they are not on the same broadcast domain then they are
not in the same broadcast domain.


Once again, does not apply if they are on the same wire.


[* It is theorectically possible to have multiple subnets on
the same 'wire' or 'broacast domain' but this is not a common
practice in modern networks -- and still requires some special
configuration.]

requires no special configuration at all. Get a switch, plug 4 computers
into it. Put 2 on one IP subnet and two on another. Computers on the same IP
subnet can talk, computers on disparate IP subnets cannot (at layer-3). But
if you sniff the wire at any computer, you'll see arp broadcasts and such
from every computer.

The real problem is many the incomplete understand of of
VLANs switches, and switches in general, by many people.
One cannot understand VLANs (or any switches) completely
without first understanding the differences and features of
both Routers and Bridges -- we can call the features something
else but switches are merely "switching" combined with either
the Bridge or Router concept, or in modern devices a hybrid
of all three concepts.

True, but I must say that I don't fall into that category. As the senior
engineer/primary designer of a metro ring infrastructure, I live and breathe
VLANs and routers every day of my life. They are what make shared ethernet
infrastructures work.
VLANs switches allow the admin to (easily) redefine each
bridged segment to include arbitrary connections to the switch,
and thus map a "set of computers" to either one bridged
broadcast domain OR another to which routing is required.

VLANS can exist as port based, protocol based even application based on
really sophisticated multi-layer switches. They can live on a single switch,
or span multiple switches, indeed multiple cities and service providers
(although the latter is uncommon). Switches create separate collision
domains. VLANs create separate broadcast domains. Communication between
VLANS is not possible unless it is routed (OK, you could bridge it, but that
would defeat the whole purpose).
Routed segments REQUIRE different IP subnets while EACH
bridged segment typically (and all modern networks) place all
of the machines on the same subnet.

That's the way it usually works, but the OP does not mention anything but IP
subnets - purely logical separation.
This really has nothing specific to do with VLANs per se.

It has nothing to do with a VLAN at all as a standalone statement.
Incoroprating VLANS into a single physical infrastructure enhances the
security and prevents broadcast traffic between virtual segments. It really
comes down to what the OP was driving at.

A
| | | |
------- ROUTER -------
| |

Those are two physical segments (and must be configured as different logical
subnets in order to route traffic between).

B
| | | 192.168.1.x /24
---------------
| | | 192.168.2.x/24

If a plain 'ole $99 switch is used, you have two logical subnets but one
broadcast domain. I could still stick a 2 port router on there and route
traffic between logical subnets. But if I use a managed switch and create
two VLANs, I effectively have the same separation as "A".



It is a feature of whether that wiring segment is either Bridged or
Routed.

Or virtually segmented and routed.

The KEY to a VLAN switch is the "area" or the "component
network cables" which are BRIDGED vs. ROUTED can be
configured by the Admin using switch-commands.



The above has little to do with understanding the basic concepts that
are being confused here -- and detracts from keeping the explanation
simple and accurate.

Perhaps, but the OP only mentioned IP subnets, no physical separation.
Still, none of the answers provided a workable solution .

"Why 3 NIC in the router? No point in even connecting Subnet
C if it is NOT going to communicate. <GRIN>"

Subnet C DOES have to communicate - With the DNS server / DC in subnet A -
but not with computers in other subnets.

If this is a homework question it is , like most, poorly written. The
"right" answer is probably to put a rotuer between Subnets A, B, and D and
leave subnet C all to itself. Of course the domain would not function on
subnet C because it couldn't contact the DC or DNS server. So I proposed a
solution that would allow subnet C to talk to the DC/DNS server but not
communicate with other computers. The VLAN thing was in response to
Lanwrench's post and took it a bit further.

But I stand my ground on these points: IP subnets are purely logical things.
They can be configured without regard to the physical device or how it is
cabled. Routers can route between IP subnets on the same physical segment or
on separate physical segments, or on separate virtual segments.

....kurt
 
H

Herb Martin

Kurt said:
Not if they're on the same wire.

That is precisely WHERE broadcasts propagate freely without
any assistance: On the same wire.
Although IP broadcasts will be discarded at the layer-3 level, Ethernet
broadcasts propogate to every node in the broadcast domain (not to be
confused with collision domain), regardless of IP subnet.

You keep introducing irrelevant issues that have little or
(absolutely) nothing to do with understanding the issues
under discussion, especially bridges, switches, routers,
VLANs, and IP Subnets.
Once again, does not apply if they are on the same wire.

Which "they"? Multi-nets are discussed below if that
is your quibble (although still largely irrelevant) but otherwise
the above has no meaning here.
[* It is theorectically possible to have multiple subnets on
the same 'wire' or 'broacast domain' but this is not a common
practice in modern networks -- and still requires some special
configuration.]

requires no special configuration at all. Get a switch, plug 4 computers
into it. Put 2 on one IP subnet and two on another. Computers on the same
IP subnet can talk, computers on disparate IP subnets cannot (at layer-3).
But if you sniff the wire at any computer, you'll see arp broadcasts and
such from every computer.

I was trying to help you but you apparently have a very poor
true understanding of switches yet do not wish to learn.

See next paragraphs...
True, but I must say that I don't fall into that category. As the senior
engineer/primary designer of a metro ring infrastructure, I live and
breathe VLANs and routers every day of my life. They are what make shared
ethernet infrastructures work.

You really would benefit -- if only in explaining it to others -- if
you understood the basics better then.

I will help you if you wish to learn....
 
K

Kurt

You really would benefit -- if only in explaining it to others -- if
you understood the basics better then.

I will help you if you wish to learn....

I understand the basics extremely well. I think you need to pick up a Cisco
book and re-read if your understanding is different. Here's a very basic
tutorial (for anyone who cares to know) on how VLANs work:

First, let's all agree to use the standard, which is now 802.1q. Old Cisco
ISL VLANS are history. Newer Cisco switches don't even support ISL anymore.
Some cheapo switches also support local "port-based" VLANs, but those do not
use tagging, nor are they trunkable to other switches. The following
explains "port-centric" 802.1q VLANs, by far the most widely used
application. Also let's pre-define "traffic", "communication", etc as TCP/IP
on an ethernet network.

1. A switch is configured with one vlan or many vlans. Ports are added to
those VLANs as either "tagged" or "untagged" (this is RFC language. Cisco
uses their own terminology "Access port" = untagged and "trunk port" =
tagged - they always have to be different). Yes, there are variations, but
this will stick to the very basics.

2. An "untagged" port accepts only ethernet frames that do not already carry
a VLAN tag. When frames enter untagged ports, they are given a tag with the
VLAN ID of that port's membership.

3. A "tagged" port accepts only frames that already have a tag. A tagged
port can be configured to be a member of 1 or more vlans, and are typically
used for inter-switch VLAN "trunking", where traffic from multiple VLANS can
travel across a single uplink (This is how my traffic from many clients is
carried.across a single metro-ring infrastructure. It is also how multiple
T1, Voice and other telecom traffic travels across a single pair of fiber
optic cables. Telephone terminology is different, but the concept is exactly
the same).

4. When a frame is to be delivered, it may only exit the switch (egress) on
a port that is a member of the VLAN that it is tagged with. If that port is
an "untagged" port, then the VLAN tag is stripped from the frame on egress -
this is normally for delivery to an end user station. If that port is a
"tagged" port, the VLAN tag stays with the frame to it's next destination -
usually another switch, and once again will only be accepted by another
tagged port with membership in that vlan.

5. All types of ethernet frames are tagged, including broadcast frames. That
is how broadcasts are contained within a single VLAN infrastructure. All
hosts on the VLAN hear broadcasts on that VLAN. Hosts on other VLANS do not.

6. Since frames do not propogate onto ports that are members of other VLANs,
communication is impossible between hosts on different VLANS, regardless of
the logical network (ip subnet) they are configured for.

7. If traffic is to be exchanged between VLANs, a router is required, and
different logical subnets must be defined for each VLAN because that is what
routers do - they route between subnets. (actually my devices are
multi-layer Foundry Networks BI-4000s, so they handle the routing as well).

Here are a couple of examples:

192.168.1.1 192.168.1.2
Computer A Computer B
| |
VL1 VL1
---------------------------
| SWITCH |
---------------------------
VL2 VL2
| |
Computer C Computer D
192.168.1.3 192.168.1.4

Better diagram here : http://65.243.151.82/a.html

In the example above, computer C can ping computer D and Computer A can ping
computer B (and vice versa of course). But computers A and B cannot ping
computers B or C even though they are in the same IP subnet (all have /24
netmask), because they are on different VLANS.
-----------------------------------------------------------------

192.168.1.1 192.168.1.2
Computer A Computer B
| |
VL1 VL1
---------------------------
| SWITCH |
---------------------------
VL2 uplink VL2
| tag VL 1 & 2 |
| | |
Computer C | Computer D
192.168.1.3 | 192.168.1.4
|
192.168.1.5 | 192.168.1.6
Computer E | Computer F
| | |
| tag VL1 & 2 |
VL1 | VL1
---------------------------
| SWITCH |
---------------------------
VL2 VL2
| |
Computer G Computer H
192.168.1.7 192.168.1.8
Better diagram here : http://65.243.151.82/b.html

Going a little further (2 switches) in the above example, in addition to the
connectivity (or lack thereof) in the first example, Computers G and H can
communicate with computers C & D, but not A, B, E or F. Computers E and F
can communicate with A and B, but not C, D, E or F. This is all true, even
though all computers are on the same IP (logical) subnet.

-----------------------------------------------------------------

192.168.1.1 192.168.1.2
Computer A Computer B
| |
---------------------------
| Dumb switch no Vlans |
---------------------------
| |
Computer C Computer D
192.168.2.1 192.168.2.2
Better diagram here : http://65.243.151.82/c.html

Here Computers A and B can ping each other, but not C or D, because even
though they are connected to the same switch (broadcast domain), they are in
different IP subnets.


-----------------------------------------------------------------

192.168.1.1 192.168.1.2 G/W 1.10
Computer A Computer B
| |
--------------------------- ---------------
| |--|-192.168.1.10 |
| Dumb switch no Vlans | | Router |
| |--|-192.168.2.10 |
--------------------------- ----------------
| |
Computer C Computer D
192.168.2.1 192.168.2.2 G/W 2.10
Better diagram here : http://65.243.151.82/e.html

Now, with the gateways pointed at the router which has an IP interface on
each subnet, all computers can contact each other. Here computers A and B
will communicate directly and Computer A will, for instance, communicate
with C through the router. But if you changed computer C's IP address to
192.168.1.3, it would no longer have to communicate with A via the router.
You could take the router away and A-C would still communicate in the same
manner as A-B.

-----------------------------------------------------------------

192.168.1.1 192.168.1.2 G/W 1.10
Computer A Computer B
| |
VL1 VL1
--------------------------- ---------------
| |--|-192.168.1.10 |
| SWITCH | | Router |
| |--|-192.168.2.10 |
--------------------------- ----------------
VL2 VL2
| |
Computer C Computer D
192.168.2.1 192.168.2.2 G/W 2.10
Better diagram here : http://65.243.151.82/d.html

And lastly, as with the previous example with the gateways set to a router
the has an IP interface on each subnet, all computers can contact each
other. Here computers A and B will communicate directly and Computer A will,
for instance, communicate with C through the router. The difference is that
if you changed computer C's IP address to 192.168.1.3, you could block
communication with VLAN 1 at the router with an access-list. And, if you
took the router away A-C communication is no longer possible.


Believe me, I know what I'm talking about here. I've spent the last 5 years
building this exact type of infrastructure from the ground up, albeit a tad
more complex. But the fundamentals are the same. If you think I'm wrong, set
it up and give it a try. I have - hundreds of times.

Here are some links to some vlan info and basic layer-2 stuff.

http://www.inetdaemon.com/tutorials/lan/vlan/index.shtml

http://www.wi-fiplanet.com/tutorials/article.php/3577261

http://www.enterasys.com/support/manuals/hardware/2599_03.pdf#search="802.1q vlan tutorial"

I liked this onethe best

http://www.networkworld.com/news/tech/2001/0305tech.html



...kurt
 
H

Herb Martin

Kurt said:
First, let's all agree to use the standard, which is now 802.1q. Old Cisco
ISL VLANS are history. Newer Cisco switches don't even support ISL
anymore. Some cheapo switches also support local "port-based" VLANs, but
those do not use tagging, nor are they trunkable to other switches. The
following explains "port-centric" 802.1q VLANs, by far the most widely
used application. Also let's pre-define "traffic", "communication", etc as
TCP/IP on an ethernet network.

No, none of that complication is necessary IF you had really
understood the basics, not made several mistakes, overcomplicated
it, tried to brag about how experienced you are, and then tried to
hide behind obfuscation.

I am never impressed when someone tries to justify their technical
inadequacy by giving their resume:

"True, but I must say that I don't fall into that category. As the
senior
engineer/primary designer of a metro ring infrastructure, I live and breathe
VLANs and routers every day of my life."

You are wasting my time at this point and you have already confused
the issue for those trying to learn and understand networking correctly.
 
K

Kurt

I wasn't trying to hide behind anything, herb. I just can't abide when
someone tries to make me out to be some kind of loser who doesn't know my
business. I'll go head to head with you any day in a real-life
set-it-up-and-make-it-work situation. I've never claimed to be the sharpest
pencil in the box, and I've learned a lot from your posts in the past. But I
DO know networking from the root and fundamental levels up. I'm not a
hardware engineer, so I can't tell you how the circuitry inside the routers,
NICs and switches do their magic. But as far as designing, installing, and
configuring a network, I know my stuff ! I'm sure you have a better handle
on many things than I do, but not on this subject. Yes, I did make some cut
and paste errors in the post. They are corrected on the links. Come th rhink
of it, that's something I really COULD use some help with - writing (typing
too).

Cheers,
....kurt


Herb Martin said:
Kurt said:
First, let's all agree to use the standard, which is now 802.1q. Old
Cisco ISL VLANS are history. Newer Cisco switches don't even support ISL
anymore. Some cheapo switches also support local "port-based" VLANs, but
those do not use tagging, nor are they trunkable to other switches. The
following explains "port-centric" 802.1q VLANs, by far the most widely
used application. Also let's pre-define "traffic", "communication", etc
as TCP/IP on an ethernet network.

No, none of that complication is necessary IF you had really
understood the basics, not made several mistakes, overcomplicated
it, tried to brag about how experienced you are, and then tried to
hide behind obfuscation.

I am never impressed when someone tries to justify their technical
inadequacy by giving their resume:

"True, but I must say that I don't fall into that category. As the
senior
engineer/primary designer of a metro ring infrastructure, I live and
breathe
VLANs and routers every day of my life."

You are wasting my time at this point and you have already confused
the issue for those trying to learn and understand networking correctly.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
H

Herb Martin

Kurt said:
I wasn't trying to hide behind anything, herb. I just can't abide when
someone tries to make me out to be some kind of loser who doesn't know my
business.

Does that happen to you a lot?

I certainly wasn't trying to make you out a loser (only you
can do that yourself) but I will correct you if you make technical
errors AND in the process are confusing those trying to learn.

So don't do that anymore.
I'll go head to head with you any day in a real-life
set-it-up-and-make-it-work situation. I've never claimed to be the
sharpest pencil in the box, and I've learned a lot from your posts in the
past. But I DO know networking from the root and fundamental levels up.

Then you have no excuse for such elementary errors -- whether
you truly misunderstand or were just unable to explain how things
work. You claimed experience suggests you SHOULD know better.

I am always much tougher on those who are beginners than those
who claim they know what they poorly understand.
I'm not a hardware engineer, so I can't tell you how the circuitry inside
the routers, NICs and switches do their magic.

And that was always PART of my major point: You do not need
to be a "hardware engineer" to understand IP, nor to understand
routing and bridging.

They are simple subjects if presented simply. No one can fully
understand Switching in general and VLANs in particular with
with an understanding of routing and bridging but it amazes me
how many people seem to try.

These are actually very simple subjects and in fact are better
understood simply without reference to specific network
hardware or any of the complexities of "network hardward
engineering".
But as far as designing, installing, and configuring a network, I know my
stuff ! I'm sure you have a better handle on many things than I do, but
not on this subject. Yes, I did make some cut and paste errors in the
post. They are corrected on the links.

Then when you figure that out -- stop arguiing.

It's only when people argue BEYOND their mistakesm, rather than
admitting and correcting them, that they begin to sound truly foolish.

Everyone has to learn -- and their is no shame in being
uninformed, but anytime we argue despite the facts we
are not helping nor are we learning.
Come th rhink of it, that's something I really COULD use some help with -
writing (typing too).

I never criticize anyone's typing as long as the words can
be decyphered. Seldom their grammar or English either.

I personally type these notes as stream of consciousness,
much like a conversation except we have to wait days or
hours for a response and thus it is very easy to be misunderstood
and for tones to be misinterpreted.

As to typing (serious suggestion): Any good typing tutor works
wonders. Even today I still use one regularly to counteract the
bad habits I would otherwise fall into more deeply.

Mavis Beacon and Tux Typing Tutor are my current favorites.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Cheers,
...kurt


Herb Martin said:
Kurt said:
First, let's all agree to use the standard, which is now 802.1q. Old
Cisco ISL VLANS are history. Newer Cisco switches don't even support ISL
anymore. Some cheapo switches also support local "port-based" VLANs, but
those do not use tagging, nor are they trunkable to other switches. The
following explains "port-centric" 802.1q VLANs, by far the most widely
used application. Also let's pre-define "traffic", "communication", etc
as TCP/IP on an ethernet network.

No, none of that complication is necessary IF you had really
understood the basics, not made several mistakes, overcomplicated
it, tried to brag about how experienced you are, and then tried to
hide behind obfuscation.

I am never impressed when someone tries to justify their technical
inadequacy by giving their resume:

"True, but I must say that I don't fall into that category. As the
senior
engineer/primary designer of a metro ring infrastructure, I live and
breathe
VLANs and routers every day of my life."

You are wasting my time at this point and you have already confused
the issue for those trying to learn and understand networking correctly.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
K

Kurt

My final point on this issue. I have a lot of respect for your knowledge. My
approach is different than yours. As I said, the VLAN thing was not started
by me. It was in response to Lanwrench's question about VLANS.
A VLAN switch is a form of (configuarable) router.

Your statement is just plain wrong. A "VLAN Switch" is not a router at all.
I corrected the error without pointing out that you were in error (I try not
to make a point of bringing attention to other's errors, just post the
correction).
"A VLAN Switch is essentially a "routed group of bridges"
but all contained within one box and configurable in software."

This is fundamentally incorrect. A Layer-3 switch that ALSO has dot1q
capability can do both, but routing is a layer-3 function and VLANs are
layer-2. Each can exist and function on it's own without the other.
It's only when people argue BEYOND their mistakesm, rather than
admitting and correcting them, that they begin to sound truly foolish.

Are you big enough to take your own advice? Can you show me where I made a
technical error (other than improperly edited cut and pastes that I do
apologize for)?
Everyone has to learn -- and their is no shame in being
uninformed, but anytime we argue despite the facts we
are not helping nor are we learning.
Agreed.

Mavis Beacon and Tux Typing Tutor are my current favorites.

Is Tux Linux? I'll Google.

....kurt
 
H

Herb Martin

Kurt said:
My final point on this issue. I have a lot of respect for your knowledge.
My approach is different than yours. As I said, the VLAN thing was not
started by me. It was in response to Lanwrench's question about VLANS.


Your statement is just plain wrong. A "VLAN Switch" is not a router at
all. I corrected the error without pointing out that you were in error (I
try not to make a point of bringing attention to other's errors, just post
the correction).

Then you have thoroughly misunderstood VLANs switches.

There purpose and implementation.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top