from:"Bob Vance"

RE: redundant NICs

2001-01-25 Thread Bob Vance


What I really want is one NIC, the "active" one, connected to Switch-A.
The other NIC, "standby", is hooked to switch-B.
If Switch-A fails (or the NIC fails), the software on the NT server
notices that there is a loss of connectivity on this NIC.  Then the
"standby" NIC takes over with the same IP (doing a Gratuitous ARP to
inform local-net devices of the change) and now traffic is going thru
Switch-B
Client PCs will never know (we'll have redundant switches and paths
in the core).  If an edge switch is lost, then those PCs will lose
connectivity, of course, unless manual patching is done.


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: Windows NT/2000 Discussion List
[mailto:[EMAIL PROTECTED]]On Behalf Of Ali
Sent: Thursday, January 25, 2001 1:53 PM
To: [EMAIL PROTECTED]
Subject: Re: redundant NICs


They way you do it is you install two Intel nics and there is a software
that's loaded into your tray by your clock. u go into the Intel software
and
you can group those two or more nics to together. they will operate on
the
same ip and be redundant and give you more throughput.

-Original Message-
From: Windows NT/2000 Discussion List
[mailto:[EMAIL PROTECTED]]On Behalf Of Bob Vance
Sent: Thursday, January 25, 2001 5:25 AM
To: [EMAIL PROTECTED]
Subject: Re: redundant NICs


Thanks, Denis.
Someone else (off the list) mentioned "Intel", as well.
So, is the standby/failover simply built into the driver or is there
some kind of higher-level code that must also be installed?
Does Intel's site give good enough info on this product?

-
Tks| <mailto:[EMAIL PROTECTED]>
BV | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: Denis A. Baldwin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 24, 2001 4:53 PM
To: [EMAIL PROTECTED]
Subject: RE: redundant NICs


Intel makes a product like this.  We use several of them on our networks
and
they work great.  It's called Intel PRO 100+ Dual Port Server NIC.

Denis

Denis A. Baldwin - A+ / MCP / I-Net+ / Network+
Network Administrator, CAE INC.
810-231-9546, ext. 229




-Original Message-----
From: Windows NT/2000 Discussion List
[mailto:[EMAIL PROTECTED]]On Behalf Of Bob Vance
Sent: Wednesday, January 24, 2001 4:16 PM
To: [EMAIL PROTECTED]
Subject: redundant NICs


Does NT (4 or 2k) support, or is there some product support for, having
2 NICs in a failover, high-availability mode on one box.
E.g., for HP-UX Unix, HP has a product called MC/ServiceGuard which
includes this feature (among many others).  IP address is on one NIC
while the other NIC is in "standby" mode.  If network connectivity is
lost on primary NIC (either card failure or network/switch problem),
the IP address moves to the other NIC.  A Gratuituos ARP is done so
that everyone that has the old ARP entry will clear it, and current
connections aren't even lost.  Of course, the paths from the NICs into
the network must be thru different switches to avoid single point of
failure loss at a switch.


-
Tks| <mailto:[EMAIL PROTECTED]>
BV | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=


--
The WINNT-L list is hosted on a Windows NT(TM) machine running L-Soft
international's LISTSERV(R) software.  For subscription/signoff info
and archives, see http://peach.ease.lsoft.com/archives/winnt-l.html .


--
The WINNT-L list is hosted on a Windows NT(TM) machine running L-Soft
international's LISTSERV(R) software.  For subscription/signoff info
and archives, see http://peach.ease.lsoft.com/archives/winnt-l.html .


--
The WINNT-L list is hosted on a Windows NT(TM) machine running L-Soft
international's LISTSERV(R) software.  For subscription/signoff info
and archives, see http://peach.ease.lsoft.com/archives/winnt-l.html .

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Docs CD - where is it?

2001-01-25 Thread Bob Vance


Has Cisco discontinued the Docs CD?
   (I used to get one quarterly as part of the consultant program --
I still have access to the Web site and the online doco there.
   )
If not, how do you get it?

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=




_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: redundant NICs - theory question

2001-01-26 Thread Bob Vance


I finally found some info at Intel that discusses it a little.
The product looks really good.
As Allen (and others -- thanks) said, Automatic Load Balancing and
Failover -- just what I wanted.
The Intel site is missing low-level technical details, though, which
I'd like to have.

E.g., I notice that the load balancing is on output only (when
connecting to ports on separate switches or without FEC) -- only the
"primary" NIC is used on input, but no technical reason was given.

This implies that only the "primary" NIC responds to ARP requests, at
least until the standby takes over after a primary link failure.

But, I'm wondering why this is so.
Let's suppose that there are redundant paths thru the switching fabric
and that the 2 NICs in the NT server are connected to 2 different
switches.

ISTM that if both NICs responded to ARP requests that you could achieve
some load sharing on the input side, as well.  When a client makes an
ARP request, both NICs see it and respond.  Client uses first one it
sees.  Some clients would get Mac-A, others Mac-B, so input could flow
in on both NICs.
Now, this would require some driver code to handle this, but I don't see
why this is any more technically difficult than doing the outbound
balancing.

I must be missing something simple (like the last time :), but I'm tired
of thinking about it, so I thought that I'd just ask ;>)


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: Allen May [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 25, 2001 3:35 PM
To: Bob Vance
Subject: Re: redundant NICs


That's what the Intel Adapter Teaming does.  Very kewl software.  It
detects
when connectivity goes down and will fail over to the other nic if
either
the switch or nic slot fails.  You can also set them up where they are
both
live and sharing bandwidth and if one fails the other takes all of the
traffic as well.  I think intel.com has all the documentation there.
I've
used it before and didn't have any problems with it.

- Original Message -
From: "Bob Vance" <[EMAIL PROTECTED]>
To: "CISCO_GroupStudy List (E-mail)" <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2001 1:49 PM
Subject: RE: redundant NICs


> What I really want is one NIC, the "active" one, connected to
Switch-A.
> The other NIC, "standby", is hooked to switch-B.
> If Switch-A fails (or the NIC fails), the software on the NT server
> notices that there is a loss of connectivity on this NIC.  Then the
> "standby" NIC takes over with the same IP (doing a Gratuitous ARP to
> inform local-net devices of the change) and now traffic is going thru
> Switch-B
> Client PCs will never know (we'll have redundant switches and paths
> in the core).  If an edge switch is lost, then those PCs will lose
> connectivity, of course, unless manual patching is done.
>
>
> -
> Tks | <mailto:[EMAIL PROTECTED]>
> BV | <mailto:[EMAIL PROTECTED]>
> Sr. Technical Consultant, SBM, A Gates/Arrow Co.
> Vox 770-623-3430 11455 Lakefield Dr.
> Fax 770-623-3429 Duluth, GA 30097-1511
> =
>
>
>
>
>
> -Original Message-
> From: Windows NT/2000 Discussion List
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ali
> Sent: Thursday, January 25, 2001 1:53 PM
> To: [EMAIL PROTECTED]
> Subject: Re: redundant NICs
>
>
> They way you do it is you install two Intel nics and there is a
software
> that's loaded into your tray by your clock. u go into the Intel
software
> and
> you can group those two or more nics to together. they will operate on
> the
> same ip and be redundant and give you more throughput.
>


_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Subnet question

2001-01-28 Thread Bob Vance


My contrarian $.02 :)

>Typically the first and last subnet are not used,

This might be true, but

>toss out 176 and 191,

is a non-sequitur :)

The 0 and -1 subnet restriction only apply to classful considerations.

We're already out of classful thinking here, because we were given a
non-/16 block (a /20) out of the Class B network, 172.16.0.0, and are
extending the prefix 4 bits to /24.

The only subnet addresses that would be considered problematic in our
general area would be 172.16.0.0/24 and 172.16.255.0/24 (classful
subnets 0 and -1).
Of course, neither of those prefixes fall within the block that we were
given, so it's not *our* problem :)

>this leaves 177 through 190, each with a 24 bit mask.

Thus, *all* "subnets" 172.16.[176-191].0/24 are valid.
I.e., no host or router would object to being given an address

172.16.176.1/24
or  172.16.191.1/24

and 172.16.191.255/24

would not be an all-subnets broadcast (just a simple directed
broadcast).

Thus, if additional choices had been:

G)    172.16.191.0/24
H)    172.16.176.0/24

Then the answer would have been

C, F, G, H

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Ed Moss
Sent: Saturday, January 27, 2001 10:50 PM
To: [EMAIL PROTECTED]
Subject: Re: Subnet question


The 20 bit prefix extends four bits into the third octet (176).
176 in binary is 1011, so with the mask the address ends at 1011.
You want to use the next four bits for subnetting (last four 0's)
This gives the range of 1011 (176) through 1011 (191)
providing 16 subnets with 256 addresses in each subnet.
Typically the first and last subnet are not used, toss out 176 and 191,
this leaves 177 through 190, each with a 24 bit mask. (We started with
20 bits, and we added four bits for our own subnets).

Looking at the possible answers, the following fall in this range.
 C) 172.16.183.0/24
 F) 172.16.190.0/24

Ed

ORIGINAL:

Can anyone please explain to me how to derive the answer of this
question?

A company has been assigned a subnet of 172.16.176.0/20, and wants the
next four available bits to create 14 subents, each containing an equal
number of hosts.  Which of the following could represent one of these
subnets?

A)    172.16.255.0/24
B)    172.16.193.0/24
C)    172.16.183.0/24
D)    172.16.16.0/24
E)    172.16.0.0/24
F)    172.16.190.0/24

Answer is C and F


_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: redundant NICs

2001-01-29 Thread Bob Vance


>Why do they believe that a redundant NIC will provide them any
>redundancy?
>to Quote Howard. "what problem are they trying to solve" with this
>scenario.

Well, maybe I'm missing something.>)

It's actually *my* idea.

They already are spending beaucoups ducats for a redundant switch mesh
and have several NT servers.
I say,
"Look. If a switch goes down, then *all* the NT servers
 connected to it will lose network connectivity.  A cheap
 answer to that would be to add an Intel NIC to each NT server
 and connect it to a *different* switch.  The ALB/failover
 stuff will keep connectivity to those servers.
"
What am I missing?
Of course, it the server goes down ...

-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=====


-Original Message-
From: Bob Vance [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 25, 2001 1:50 PM
To: CISCO_GroupStudy List (E-mail)
Subject: RE: redundant NICs


What I really want is one NIC, the "active" one, connected to Switch-A.
The other NIC, "standby", is hooked to switch-B.
If Switch-A fails (or the NIC fails), the software on the NT server
notices that there is a loss of connectivity on this NIC.  Then the
"standby" NIC takes over with the same IP (doing a Gratuitous ARP to
inform local-net devices of the change) and now traffic is going thru
Switch-B
Client PCs will never know (we'll have redundant switches and paths
in the core).  If an edge switch is lost, then those PCs will lose
connectivity, of course, unless manual patching is done.


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=


-Original Message-
From: Windows NT/2000 Discussion List
[mailto:[EMAIL PROTECTED]]On Behalf Of Ali
Sent: Thursday, January 25, 2001 1:53 PM
To: [EMAIL PROTECTED]
Subject: Re: redundant NICs


They way you do it is you install two Intel nics and there is a software
that's loaded into your tray by your clock. u go into the Intel software
and
you can group those two or more nics to together. they will operate on
the
same ip and be redundant and give you more throughput.

-Original Message-
From: Windows NT/2000 Discussion List
[mailto:[EMAIL PROTECTED]]On Behalf Of Bob Vance
Sent: Thursday, January 25, 2001 5:25 AM
To: [EMAIL PROTECTED]
Subject: Re: redundant NICs


Thanks, Denis.
Someone else (off the list) mentioned "Intel", as well.
So, is the standby/failover simply built into the driver or is there
some kind of higher-level code that must also be installed?
Does Intel's site give good enough info on this product?

-
Tks| <mailto:[EMAIL PROTECTED]>
BV | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=


-Original Message-
From: Denis A. Baldwin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 24, 2001 4:53 PM
To: [EMAIL PROTECTED]
Subject: RE: redundant NICs


Intel makes a product like this.  We use several of them on our networks
and
they work great.  It's called Intel PRO 100+ Dual Port Server NIC.

Denis

Denis A. Baldwin - A+ / MCP / I-Net+ / Network+
Network Administrator, CAE INC.
810-231-9546, ext. 229


-Original Message-
From: Windows NT/2000 Discussion List
[mailto:[EMAIL PROTECTED]]On Behalf Of Bob Vance
Sent: Wednesday, January 24, 2001 4:16 PM
To: [EMAIL PROTECTED]
Subject: redundant NICs


Does NT (4 or 2k) support, or is there some product support for, having
2 NICs in a failover, high-availability mode on one box.
E.g., for HP-UX Unix, HP has a product called MC/ServiceGuard which
includes this feature (among many others).  IP address is on one NIC
while the other NIC is in "standby" mode.  If network connectivity is
lost on primary NIC (either card failure or network/switch problem),
the IP address moves to the other NIC.  A Gratuituos ARP is done so
that everyone that has the old ARP entry will clear it, and current
connections aren't even lost.  Of course, the paths from the NICs into
the network must be thru different switches to avoid single point of
failure loss at a switch.


-
Tks| <mailto:[EMAIL PROTEC

RE: AIX route add

2001-01-29 Thread Bob Vance


add route to network 10 out the 10 interface and then default
out the other

route add net 10.0.0.0 netmask 255.0.0.0 10.1.1.1   1

route add net default 192.168.1.11

The above are HP-UX specific so make your AIX changes.
As to making it permanent -- I know nuttin' 'bout AIX, but you
*could* put in startup scripts (HP-UX has a network config file that
gets parsed during startup).

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, January 29, 2001 12:24 PM
To: [EMAIL PROTECTED]
Subject: OT: AIX route add


Okay, way off topic, as far as Unix configs might apply to Cisco, but at
least it's about network-layer stuff.

On an AIX box, how can I add static route statements, directing traffic
to a
specific interface?  And, once added, can I make them applicable after
an
IPL/reboot?

My Problem:  An AIX server is connected to two LANs, with NIC0 connected
to
10.1.1.0/24, and NIC1 connected to 192.168.1.0/24.  These LANs are
connected
to each other via routing at the core, but a layer 8 protocol demands
"quicker access" by connecting both networks.

I'd prefer not to run a routing protocol that might affect neighboring
routers and create more traffic on the links (and open the whole STP
can-o-worms).  I want traffic destined for 10.1.1.0/24 (or 10.0.0.0/8)
to
transit NIC0, and all other traffic (see Howard's email for the proper
term)
to exit via NIC1.

One of my colleague, trying very hard to be the Unix gooroo, suggested
configuring routed or gated -- but I suspect he doesn't really know WTF
he's
talking about, since further questioning of configs and routing effects
resulted in a blank stare.

-jon-

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Zero for a host address

2001-01-31 Thread Bob Vance


Believe it or not, I did once see (a bug) where the OS didn't allow a
zero in a byte of the host portion of the IP address, even though the
*total* host portion was not zero!! (I can't remember which OS, though
-- I'm thinking an early HP-UX, but possibly Windoze).

E.g., something like,
10.10.10.10 / 16   was valid
but 10.10.10.0 / 16   was *invalid* !

However, this was just in assigning the address -- i.e., it wouldn't
even let me assign it to the interface.


I don't see how this could affect you, though.

>I believe that the problem lies with the zero being used as a third
>octet

ACLs don't have any intelligence.
They don't care about broadcast addresses, subnet masks, DOS or hack
attacks, or anything -- just simple bit matching.
The only intelligence involved is in the ACL's creator :)

Thus

access-list 1  permit  host 10.130.0.24
  ...
ip access-group 1 in

should allow in *only* traffic from that host (assuming that there *is*
any) -- of course that may not be what you *really* want ;>)
The ACL doesn't care about any value of any byte in that address -- he
only matches bits (of course, in this case, the statement told him to
*care* about *every* bit, however :)

More specifically,

access-list 101  permit tcp  10.130.0.24  0.0.0.0 any eq telnet
access-list 101  deny   ip   10.130.0.0   0.143.255.255  any
access-list 101  permit ip   any any

would
  permit telnet in from that host,
  deny all other ip traffic from the 10.128.0.0 /12 subnet
  permit all other traffic

Of course, it all depends on the details of what you're trying to do.

What's the exact problem?
Is it that *no* traffic is blocked or is it that that host is blocked,
even though you think that you've let it thru?
Let's see the ACLs.

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Randy Witt
Sent: Wednesday, January 31, 2001 8:58 AM
To: <
Subject: Zero for a host address


Have an issue, hope many of you don't feel this is too off topic.  Many
of =
you have helped me in the past with certification questions, perhaps you
=
can assist with this one as well.

I am trying to establish a connection to the City of Greenville's
network. =
 What should be a simple connection is giving me fits.

I'm currently using 2 Cisco 1601 routers, routing RIPv2.  From my
network =
to the city's, I pass through a total of 5 routers (2 our mine, 3 belong
=
to the city).  Currently I can communicate with each router and vice
versa =
via Telnet or ping.  However, the city of Greenville's network has the =
following IP address 10.128.0.0/12 (or 255.240.0.0).  The interface =
attached to the city of Greenville's network is 10.130.0.1/12.
Everything =
within this network has  3'd octet of zero. =20

Originally, from his network he could not ping us, however I could ping
=
him (him being the net admin using a PC with an address of
10.130.0.24/12).=
  I added a default route on one of my Cisco's pointing back to his =
network and that problem went away.  Now I'm trying to add an ACL on our
=
router blocking all but Telnet traffic coming from a host on his network
=
to a host within our network.  In testing I can get the ACL's to work
for =
every system except one on the 10.128.0.0 subnet.  By work I mean on the
=
networks in between my network and the city's I can setup ICMP or Telnet
=
ACL's permitting traffic and they can get in.  This was done for testing
=
purposes only.  My goal is to lock everyone out but the host w/ an IP =
address of 10.130.0.24/12.

I believe that the problem lies with the zero being used as a third
octet =
.  However I've seen Cisco documentation using zero's as host addresses.
=
I'm a bit confused for I've found plenty of documentation stating that =
zero's in the network/subnet address aren't recommended, however I can =
find nothing stating zero's in the "host" portion aren't recommended.

Any ideas?  Has anyone come across a problem like this before?

Simple answer would be to tell the city of Greenville to remove the zero
=
in the third octet and replace it with a one or higher.  The answer from
=
them is that it would be too much trouble.  This is their default
gateway =
for over 450 machines.  So I'm looking for help to see if there's
anything =
else I can try.

Thanks for any and all advice,
rtw






Have an issue, hope many of you don't feel this is too
off
topic.  Many of you have helped me in the past with certification
questions, perhaps you can assist with this one as well.
 
I am trying to establish a connection to the City of
Greenville's network.  What should be a simple connection is giving
me
fits.
 
I'm currently us

RE: Ethernet switching

2001-01-31 Thread Bob Vance


Before an ARP is done, however, the PC would see if the other host is
on the same subnet.  If not, it would look for a route to the other's
network.
In the case of /24 mask, they are on different subnets, so no ARP would
be done.

However, IIRC, there is a trick that can work, at least on PCs -- if
both PCs have their default route set to their own interface IP address,
then the ARP *is* done and they can talk.
Someone else'll remember the details better than I.



-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Sheahan, Ryan
Sent: Wednesday, January 31, 2001 11:24 AM
To: 'Fowler, Joey '; '[EMAIL PROTECTED] '
Subject: RE: Ethernet switching


These are my thoughts,

If the switch was right out of the box, the stations could ping each
other
no matter what subnet mask you were using.  The reason being, they are
located in the same broadcast domain, vlan1.  This is the default vlan
for
all switched ports at this time.  The first station would arp for the
other,
it would get a response because they are on the same layer 2 broadcast
domain and they could speak directly using the switch.

Switches by default with no mls, are layer two devices.  They have no
concept of IP.  They make decision based on layer 2 MAC addresses and
the
ports they are connected to.  If these stations were in different vlans,
the
situation would change.  You then have created two broadcast domains and
in
order for the devices to talk, a router or mls entry would be needed.

Someone please correct me if I am wrong.




-Original Message-
From: Fowler, Joey
To: [EMAIL PROTECTED]
Sent: 1/31/01 10:52 AM
Subject: RE: Ethernet switching

Depends on the subnet mask you are using, for instance

142.102.3.1 with a subnet mask of 255.255.0.0
142.102.2.1 also with a subnet of 255.255.0.0

The 2.1 and 3.1 would be on the same subnet, however if you have a
different
subnet mask I don't think it would work.

Joey

-Original Message-
From: alexs [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 09, 2000 7:42 AM
To: [EMAIL PROTECTED]
Subject: Ethernet switching


Hello everyone,

I have a question that probably will sound silly but here it is:
Suppose that you take a new 2924 out of the box and you plug in two
PC's.
You assign address, for example, 142.102.2.1 to the first one and
142.102.3.1 to the second one.There is not any router in this small
network.142.102.2.1 tries to ping 142.102.3.1.The question is: will
142.102.2.1 get a reply and why?
Thanks
alexs


_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: NT Routing Problems

2001-02-01 Thread Bob Vance


In order to talk (e.g., 'ping'), the sender must have a route to the
receiver *and* the receiver must have a route back to the sender (for
the replies!!) :)

If you are on 1.x and have a route to 2.0

route -p add 192.168.2.0 mask 255.255.255.0 192.168.1.3 metric 1

then your packets can get *to* any 2.x box.
*But*, that 2.x box, *itself*, must have route to the 192.168.1.0/24
network (or at least its default route must lead toward someone that
has such a route).
The reason that you can ping 2.3 is because that box *does* have route to
1.0 -- his own NIC, 192.168.1.3, on that network !!

You conveniently left out the routing tables from any 2.x box :)

Let's suppose that the 2.x boxes are defaulting to the other NT box,
192.168.2.2.
Then on *that* NT box, add a specific route back to 1.0.

route -p add 192.168.1.0 mask 255.255.255.0 192.168.2.3 metric 1

It should then work (even though it would be more efficient for each 2.x
box to have that route, itself).

---
Tks  |  [EMAIL PROTECTED]
BV   |  [EMAIL PROTECTED]
Sr. Tech. Consultant,SBM
Vox 770-623-3430 11455 Lakefield Dr.
Fax 770-623-3429 Duluth, GA 30097-1511
===

-Original Message-
From: Windows NT/2000 Discussion List
[mailto:[EMAIL PROTECTED]]On Behalf Of Clark, Pete
Sent: Thursday, February 01, 2001 2:08 PM
To: [EMAIL PROTECTED]
Subject: Re: NT Routing Problems


I believe that your gateway setting for the .2.0 network is misconfigured.

You have:
192.168.2.0 255.255.255.0   192.168.2.2 192.168.2.3

>From your description, it should be:
192.168.2.0 255.255.255.0   192.168.2.3 192.168.2.3

- Pete Clark

> -Original Message-
> From: Scott Daves [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 01, 2001 12:00 PM
> To: [EMAIL PROTECTED]
> Subject: NT Routing Problems
>
>
> Hi all - pardon the "brief" background ... have a subnet
> routing problem,
> here's my configuration.  I have two separate networks A & B
> - the primary
> server in each lan has two NICs, one of which is connected up
> to a cable
> modem to the internet.  I am not only routing but providing
> NAT also.  The
> two networks are 192.168.1.0 and 192.168.2.0.  I also have another NT
> server (.1.3) that was providing DHCP, File & Print Sharing
> for my A lan.
> I have since tackled converting my B lan to DHCP also, so I
> installed a
> second NIC (.2.3) in my NT DHCP server, created a new scope and it's
> working great.  I then decided I wanted to route between
> networks up so I
> could administer remotely from my workstation.  So I added
> some default
> routes for each network to my common NT box ... see below.
>
> Destination Netmask Gateway Interface
> 0.0.0.0 0.0.0.0 192.168.1.2 192.168.1.3
> 192.168.1.0 255.255.255.0   192.168.1.3 192.168.1.3
> 192.168.1.3 255.255.255.255 127.0.0.1   127.0.0.1
> 192.168.1.255   255.255.255.255 192.168.1.3 192.168.1.3
> 192.168.2.0 255.255.255.0   192.168.2.2 192.168.2.3
> 192.168.2.3 255.255.255.255 127.0.0.1   127.0.0.1
> 192.168.2.255   255.255.255.255 192.168.2.3 192.168.2.3
>
> From my A lan primary server (.1.2), I send all traffic destined to
> the .2.0 subnet to the common NT server (.1.3), otherwise all
> traffic goes
> out to the cable modem gateway and to the internet.
>
> From my NT DHCP Server, I can ping anybody on either network - no
> problems.  However, from my .1.x workstation I can ping to
>   .1.3   The NIC in the NT Server on my network
>   .2.3   The other NIC in the same NT server
> but not to any other .2.x addresses, to include my server.  I
> feel it must
> be a simple routing issue on my common NT box but it is
> eluding me.  The
> fact I can ping the other network's NIC in the NT box confuses me - it
> indicates to me that I am successfully sending .2.0 traffic
> to that box but
> that that box isn't properly routing then on.
>
> And yes, I have Enable IP Forwarding checked and have loaded
> RIP.  Could
> RIP be overriding my static routes?  Are both needed?
>
> HELP!?!?
>
> TIA
>
> Scott

--
The WINNT-L list is hosted on a Windows NT(TM) machine running L-Soft
international's LISTSERV(R) software.  For subscription/signoff info
and archives, see http://peach.ease.lsoft.com/archives/winnt-l.html .

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Ethernet switching

2001-02-01 Thread Bob Vance

>a station doesn't send an ARP for a station not on its subnet. 
>(There are workarounds to this, such as not configuring a default
>gateway

I don't believe that this is correct.
If there is no route, default or better, to the other (sub)network, then
you'll get something like 

"network unreachable"
or
"host unreachable"

>or making the default gateway your own address.)

This is the trick that I was talking about -- more specifically, adding
a route to the *particular* (sub)network of the other node, rather than
the disruptive default route.
... and I've actually used it, but, I never thought too deeply about how
it works.

I (the PC with default-to-self) still have to get the packet to the
other node, whose destination IP address is on another IP subnet (even
though we're "on the same wire").

So, ISTM, I have 2 choices:

   1: put the packet out as a local MAC broadcast
or
   2. Do an ARP for the other IP address, even though it's not in my
  logical IP (sub)network.

   (I'm certainly *not* going to ARP for own address (which is now the
default gateway).
   )
Either choice is non-normal (or, at least, non-familiar :) behavior, so
I'm wondering whether this is defined somewhere in an RFC?
Actually, is this trick discussed *anywhere* ?

OTOH, maybe I'm just being dense and it's not a "trick" at all, but
dunangme if I can figger out how it works :|

---
Tks  |  [EMAIL PROTECTED]
BV   |  [EMAIL PROTECTED]
Sr. Tech. Consultant,SBM
Vox 770-623-3430 11455 Lakefield Dr.
Fax 770-623-3429 Duluth, GA 30097-1511
===

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Priscilla Oppenheimer
Sent: Wednesday, January 31, 2001 8:48 PM
To: [EMAIL PROTECTED]
Subject: RE: Ethernet switching

At 04:32 PM 1/31/01, Fred Danson wrote:
>Ok, now from my understanding, each port on a switch is its own collision
>domain. As far as broadcast domains go, if a switch is not setup for
>multiple VLANs, then everything on the switch is considered to be in the
>same broadcast domain, no matter what is running at layer 3.

You are right. The original reply that brought collision domains into the 
picture muddied the waters.

You make an important point about broadcasting. I think people forget that 
all devices on a switched network (regardless of IP subnetting or other 
layer-3 issues) hear each other's broadcasts, unless VLANs are configured.

The other thing that was missing, though, (as many people have mentioned), 
was that a station doesn't send an ARP for a station not on its subnet. 
(There are workarounds to this, such as not configuring a default gateway 
or making the default gateway your own address.)

Priscilla

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Require a jury's opinion as to the correctness.

2001-02-01 Thread Bob Vance


When you copy to NVRAM or TFTP, the only reason to so is so that
you've saved the current, running config in case the system goes down.
After all, if the system never went down, you'd not need a config in
NVRAM :)

Thus it does *not* merge, in that direction -- it makes an exact *copy*.



---
Tks  |  [EMAIL PROTECTED]
BV   |  [EMAIL PROTECTED]
Sr. Tech. Consultant,SBM
Vox 770-623-3430 11455 Lakefield Dr.
Fax 770-623-3429 Duluth, GA 30097-1511
===

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Reel, JohnX
Sent: Thursday, February 01, 2001 3:51 PM
To: [EMAIL PROTECTED]
Subject: Require a jury's opinion as to the correctness.


Hello Group,

I have pulled this information from two different CNNA books to prepair for
my test... basically my study notes.  One book arrees with this information
and the second book disagrees.   I leave it to a jury of many to resolve or
provide some new insight.

The information that is in conflict is whether the "merge" and 'replace'
statements are correct.
===

- show running-config or write term
[not required on switches as NVRAM automatically updated]
- show startup-config or show config
- erase startup-config or write erase
- copy running-config tftp
[router prompts for information; cmd not used for switches]
- copy nvram tftp:///filename.cfg
[cmd does not prompt for information

--mergereplace  ---
|ram |<>|nvram|
--  ---
 /\   /\
 merge \ / replace
  \   /
   \ /
\   /
 \ replace     replace /
  \>| tftp |<-/
  
Note: "ram" is only one that is "merge"
===


_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: loadbalancing with NIC's

2001-02-09 Thread Bob Vance


> Otherwise, the 802.1D spanning tree algorithm will block more
>than one card;

I don't think that this is correct (yikes !! :)
If the server is not acting as a bridge how could the two connections
matter, vis-a-vis STP.

In fact, Intel touts just a solution with their NIC "teaming" concept,
without FEC (although they also support that).  They support their
2-port adapters as well as separate adapters -- in fact, IIRC, they
don't even have to be the same speed !.  In their solution, though, the
load balancing is on output only, implying that the "primary" NIC is the
only one that answers ARPs.  The "teaming" also supports automatic
failover upon NIC port failure.

This relates to a scenario I described a short while back, the only
difference being that the 2 ports on the (NT) server were connected
to different switches (which addresses your concern about the single
point of failure at the switch).

I had raised a question as to why both NICs couldn't answer and get some
kind of load balancing on the input, as well.  I got no response from
the list.  But, upon reflection, I'm thinking that devices seeing the
ARP reply are supposed to clear or update their cache if they have a
different MAC cached (I'm too lazy to go look at the RFC).  Thus there
could be a wholotta ARPing going on.

Comments?



-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Howard C. Berkowitz
Sent: Friday, February 09, 2001 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: loadbalancing with NIC's


>We are planning to connect a server with a single   NIC that supports
>faultolerance , redudndancy and load balancing.  How does a C6509 treat
a
>Nic that is connected to two of its ports (same vlans)
>Mo Durrani


Multiple Fast EtherChannel aware NICs can load-share on the same
VLAN.  Otherwise, the 802.1D spanning tree algorithm will block more
than one card; you will get failover but no load distribution.

By putting them into different VLANs, you can get load-sharing,
assuming, of course, that the higher layers know how to distribute
the load.   The ideal situation is that your clients could be
configured with primary and secondary server addresses.

At some point, you need to consider, in your fault tolerance model,
what to do if either the server or the 6509 itself fails.  Frankly,
I'd consider isolated NIC failures less likely than either of these
cases. Other people may have different experience.

If you are going to have different NICs, do consider running them to
different wire closets, or otherwise maximizing cable plant
diversity. Never underestimate the power of a less than clueful
wiring technician.

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: loadbalancing with NIC's

2001-02-10 Thread Bob Vance


>But, upon reflection, I'm thinking that devices seeing the
>ARP reply are supposed to clear or update their cache if they have a
>different MAC cached (I'm too lazy to go look at the RFC).

Actually, this makes no sense -- the ARP reply isn't a broadcast :|

So I wonder why it wouldn't work for both NICs to reply.

What happens when a requestor sees two replies to an ARP request ?
Does he accept the first and drop the second?
Accept the first, use it for his original IP packet, then update his ARP
cache with the second reply and subsequent packets use the second
MAC address?


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Friday, February 09, 2001 5:27 PM
To: CISCO_GroupStudy List (E-mail)
Subject: RE: loadbalancing with NIC's


> Otherwise, the 802.1D spanning tree algorithm will block more
>than one card;

I don't think that this is correct (yikes !! :)
If the server is not acting as a bridge how could the two connections
matter, vis-a-vis STP.

In fact, Intel touts just a solution with their NIC "teaming" concept,
without FEC (although they also support that).  They support their
2-port adapters as well as separate adapters -- in fact, IIRC, they
don't even have to be the same speed !.  In their solution, though, the
load balancing is on output only, implying that the "primary" NIC is the
only one that answers ARPs.  The "teaming" also supports automatic
failover upon NIC port failure.

This relates to a scenario I described a short while back, the only
difference being that the 2 ports on the (NT) server were connected
to different switches (which addresses your concern about the single
point of failure at the switch).

I had raised a question as to why both NICs couldn't answer and get some
kind of load balancing on the input, as well.  I got no response from
the list.  But, upon reflection, I'm thinking that devices seeing the
ARP reply are supposed to clear or update their cache if they have a
different MAC cached (I'm too lazy to go look at the RFC).  Thus there
could be a wholotta ARPing going on.

Comments?



-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Howard C. Berkowitz
Sent: Friday, February 09, 2001 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: loadbalancing with NIC's


>We are planning to connect a server with a single   NIC that supports
>faultolerance , redudndancy and load balancing.  How does a C6509 treat
a
>Nic that is connected to two of its ports (same vlans)
>Mo Durrani


Multiple Fast EtherChannel aware NICs can load-share on the same
VLAN.  Otherwise, the 802.1D spanning tree algorithm will block more
than one card; you will get failover but no load distribution.

By putting them into different VLANs, you can get load-sharing,
assuming, of course, that the higher layers know how to distribute
the load.   The ideal situation is that your clients could be
configured with primary and secondary server addresses.

At some point, you need to consider, in your fault tolerance model,
what to do if either the server or the 6509 itself fails.  Frankly,
I'd consider isolated NIC failures less likely than either of these
cases. Other people may have different experience.

If you are going to have different NICs, do consider running them to
different wire closets, or otherwise maximizing cable plant
diversity. Never underestimate the power of a less than clueful
wiring technician.

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]


_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: A inquiry about ARP behavior, vendors, and differences

2001-02-11 Thread Bob Vance

>because sometimes removing the default
>gateway didn't cause a problem.

That's interesting.  I've never run across an OS implementation like
that (that I know of :), but I've been pretty much limited to Windoze
and various Unices.  Can you remember some specific examples.

Now that I think about it, though, I believe that I *do* vaguely
remember configuring some kind of network device that asked something
like "ARP for addresses?" -- and maybe it was "ARP for non-local
addresses?".  I would guess that I said "No", not really knowing what
it was asking and always using a default route :)

I know that Windoze does *not* default to ARP for non-local, as RAJ just
also showed, but it *does* support the "route-to-self".
Linux behaves the same way.

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Priscilla Oppenheimer
Sent: Saturday, February 10, 2001 6:20 PM
To: [EMAIL PROTECTED]
Subject: Re: A inquiry about ARP behavior, vendors, and differences

At 05:35 PM 2/10/01, Raj Singh wrote:
>NOTE: Long email / question ... regarding ARP and Proxy ARP behavior
with
>different vendors OS.
>
>A inquiry about ARP behavior, vendors, and differences.
>
>Does the way a host machine behave during the ARP process differ
amongst
>different OS manufacturers, in relationship to when Proxy ARP can be
>implement and when it can't be.

Yes. You would have to do some testing to determine which ones ARP for
non-local stations and which don't. (It sounds like you already did some
testing.) When I used to teach the CIT class, one of the "bugs" we
inserted
was to remove the default gateway in the PC. The goal was to make it
impossible for the PC to reach non-local stations. We also had to insert
"no proxy arp" in the router config, because sometimes removing the
default
gateway didn't cause a problem. We were at the mercy of whatever TCP/IP
implementation happened to be on the PC. Different vendors, different
OSs,
different versions worked differently.

One other trick is to set the default gateway to the station's own
address.
For some strange reason, on some OSs this causes the station to ARP for
non-local addresses.

Priscilla

>This inquiry should not be mistaken with "is proxy ARP a good idea or
bad
>idea" question. I just want to find some behavior facts out. Thanks.
>
>Given the following situation:
>
>  ClientA   ClientB
>   |  |
>||
>  |
>  |
>  X
>  {ROUTER}
>  Y
>   |
>   |
>|-|
> |
>  ClientC
>
>Settings:
>
>ClientA: 192.168.12.5 /24
>ClientB: 192.168.12.6 /24
>ClientC: 192.168.20.101 /24
>
>Interface X on Router: 192.168.12.1 /24
>Interface Y on Router: 192.168.20.1 /24
>Proxy ARP enabled on both router interfaces
>
>None of the clients have been configured with a default gateway
setting.
>
>The operating systems are Windows 98. (Though if you prefer you can say
it
>is NT 4.0)
>
>The basic statement that I have a question about:
>
>According to Jeff Doyle's Routing TCP/IP vol. 1, book on page 69-70 in
>quotes below -
>
>"... For example, a host 192.168.12.5/24 needs to send a packet to
>192.168.20.101/24, but is not configured with default gateway
information
>and therefore does no know how to reach a router. It may issue an ARP
>request for 192.168.20.101; the local router, receiving the request and
>knowing how to reach network 192.168.20.0, will issue an ARP reply with
it's
>own data link identifier in the hardware address field. In effect, the
>router has tricked the local host into thinking that the router's
interface
>is the interface of 192.168.20.101. All packets destined for that
address
>will be send to the router. ..."
>
>The question itself:
>
>The question I have with this is that under a Windows environment at
least
>in my experience, The decision making process is as follows when trying
to d
>o an address resolution (ARP Request).
>
>Sender looks at it's own IP address and Subnet Mask compares it to the
>target machines IP address to determine if on the same subnetwork. If
it is
>so . an ARP request is issued. But if the Sender's IP address and the
Target
>'s IP address are not part of the same subnetwork . the sending machine
>looks for it's default gateway and does an ARP request for it.
>
>Thus the problem is . if there is no default gateway setup for the
sender .
>It won't even attempt to do an ARP request . it will IMMEDIATELY say .
>Destination host unreachable.
>
>Demonstration 1:
>
>ClientA: 192.168.12.5 /24 PINGSClientC: 192.168.20.101 /24
>
>Notice in the PING results below, where Client A pinging Client C

RE: A inquiry about ARP behavior, vendors, and differences

2001-02-11 Thread Bob Vance


Actually, rather than "route-to-self", as I used in my other post, I
would be more correct to say "route-to-interface".
When the IP stack sees that the default route is the interface, it
ARPs for non-addresses as well as local.


>would it behave the same way if the default gateway was set to a
>loopback address of 127.x.x.x also

Pointing to 127.0.0.1 would not be the same as pointing to an interface.
It means more "me, myself, and I".

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Raj Singh
Sent: Saturday, February 10, 2001 6:28 PM
To: [EMAIL PROTECTED]
Subject: Re: A inquiry about ARP behavior, vendors, and differences


Thanks for confirming my suspicions, though one question on the  part
about
setting the default gateway on a host to point to it's own ip address
...
would it behave the same way if the default gateway was set to a
loopback
address of 127.x.x.x also. Or did that change the behavior ?

Thanks again.

- raj

"Priscilla Oppenheimer" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> At 05:35 PM 2/10/01, Raj Singh wrote:
> >NOTE: Long email / question ... regarding ARP and Proxy ARP behavior
with
> >different vendors OS.
> >
> >A inquiry about ARP behavior, vendors, and differences.
> >
> >Does the way a host machine behave during the ARP process differ
amongst
> >different OS manufacturers, in relationship to when Proxy ARP can be
> >implement and when it can't be.
>
> Yes. You would have to do some testing to determine which ones ARP for
> non-local stations and which don't. (It sounds like you already did
some
> testing.) When I used to teach the CIT class, one of the "bugs" we
inserted
> was to remove the default gateway in the PC. The goal was to make it
> impossible for the PC to reach non-local stations. We also had to
insert
> "no proxy arp" in the router config, because sometimes removing the
default
> gateway didn't cause a problem. We were at the mercy of whatever
TCP/IP
> implementation happened to be on the PC. Different vendors, different
OSs,
> different versions worked differently.
>
> One other trick is to set the default gateway to the station's own
address.
> For some strange reason, on some OSs this causes the station to ARP
for
> non-local addresses.
>
> Priscilla
>
>
>
>
> >This inquiry should not be mistaken with "is proxy ARP a good idea or
bad
> >idea" question. I just want to find some behavior facts out. Thanks.
> >
> >Given the following situation:
> >
> >  ClientA   ClientB
> >   |  |
> >||
> >  |
> >  |
> >  X
> >  {ROUTER}
> >  Y
> >   |
> >   |
> >|-|
> > |
> >  ClientC
> >
> >Settings:
> >
> >ClientA: 192.168.12.5 /24
> >ClientB: 192.168.12.6 /24
> >ClientC: 192.168.20.101 /24
> >
> >Interface X on Router: 192.168.12.1 /24
> >Interface Y on Router: 192.168.20.1 /24
> >Proxy ARP enabled on both router interfaces
> >
> >None of the clients have been configured with a default gateway
setting.
> >
> >The operating systems are Windows 98. (Though if you prefer you can
say
it
> >is NT 4.0)
> >
> >The basic statement that I have a question about:
> >
> >According to Jeff Doyle's Routing TCP/IP vol. 1, book on page 69-70
in
> >quotes below -
> >
> >"... For example, a host 192.168.12.5/24 needs to send a packet to
> >192.168.20.101/24, but is not configured with default gateway
information
> >and therefore does no know how to reach a router. It may issue an ARP
> >request for 192.168.20.101; the local router, receiving the request
and
> >knowing how to reach network 192.168.20.0, will issue an ARP reply
with
it's
> >own data link identifier in the hardware address field. In effect,
the
> >router has tricked the local host into thinking that the router's
interface
> >is the interface of 192.168.20.101. All packets destined for that
address
> >will be send to the router. ..."
> >
> >The question itself:
> >
> >The question I have with this is that under a Windows environment at
least
> >in my experience, The decision making process is as follows when
trying
to d
> >o an address resolution (ARP Request).
> >
> >Sender looks at it's own IP address and Subnet Mask compares it to
the
> >target machines IP address to determine if on the same subnetwork. If
it
is
> >so . an ARP request is issued. But if the Sender's IP address and the
Target
> >'s IP address are not part of the same subnetwork . the sending
machine
> >looks for it's default gateway and does an ARP request for it.
> >
> >Thus the problem is . if there is no default gateway setup for the
sender

RE: loadbalancing with NIC's

2001-02-11 Thread Bob Vance


Thanks, Howard.
(at least this means that my posts *are* being seen on the list :)


>Loadsharing and failover aren't always the same problem, although
>they often are related.

Right.  Originally, I was just looking for a failover solution and found
that Intel supported *both* "Automatic Load Balancing" *and* failover
-- out of the box, so to speak (note the term "Balancing" vs. "sharing"
:)

HP supports failover, but not sharing (except with aggregation, like
FEC), so this was an unexpected bonus.


-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 11, 2001 9:27 AM
To: [EMAIL PROTECTED]
Subject: RE: loadbalancing with NIC's


>Howard,
>Did you see either of my posts on this issue.
>I think that they hit the list, but I heard nary a peep.  In fact, this
>has happened on my last few posts to the list -- I see them, but *no*
>one responds.  I'm starting to get paranoid :)


My fault.  I was just somewhat swamped and wanted time to think about
your reply.

Credit where credit is due -- feel free to post this directly to the
list.

>
>
>>  Otherwise, the 802.1D spanning tree algorithm will block more
>>than one card;
>
>I don't think that this is correct (yikes !! :)
>If the server is not acting as a bridge how could the two connections
>matter, vis-a-vis STP.

I suppose I was thinking more of the server acting as a bridge.  If
it does so, it has the potential to autodetect a spanning tree
failure.

Other than a vague suspicion that somewhere, somehow, some servers
will screw up their ARP tables this way, I can't see any objection.
Not being a server person, I don't have detailed familiarity with the
Intel teaming approach, but your description doesn't cause me to
relax about the possibility of ARP problems.

It's funny, but in many of my internal discussions with primarily
optical networking folks, "Ethernet" and "bridging" get ignored a lot
with the hype of "Ethernet everywhere."  Questions about broadcast
propagation, ARP, etc., get blank looks.
>.
>
>This relates to a scenario I described a short while back,
>  [which I never got a response to]
>the only
>difference being that the 2 ports on the (NT) server were connected
>to different switches (which addresses your concern about the single
>point of failure at the switch).
>
>I had raised a question as to why both NICs couldn't answer and get
some
>kind of load balancing on the input, as well.  I got no response from
>the list.  But, upon reflection, I'm thinking that devices seeing the
>ARP reply are supposed to clear or update their cache if they have a
>different MAC cached (I'm too lazy to go look at the RFC).  Thus there
>could be a wholotta ARPing going on.

There's a grand question:  when does load balancing actually buy you
anything and where should it be applied?  My intuition tells me that
for the ordinary sorts of servers, it is unlikely to buy much in
performance.  If you are concerned with throughput on the server
interface(s), going to faster connectivity -- FastEtherchannel,
Gigabit Ethernet, etc., may help more than independent interfaces in
the same subnet.  Most servers are going to max out at 200-300 Mbps
of traffic from a network; it would be rare to find one that actually
could use 400-1000 Mbps.

Loadsharing and failover aren't always the same problem, although
they often are related.

>
>...
>Actually, this makes no sense -- the ARP reply isn't a broadcast :|
>
>So I wonder why it wouldn't work for both NICs to reply.
>
>What happens when a requestor sees two replies to an ARP request ?
>Does he accept the first and drop the second?
>Accept the first, use it for his original IP packet, then update his
ARP
>cache with the second reply and subsequent packets use the second
>MAC address?


Without delving into the RFCs, I suspect it's implementation dependent.

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: loadbalancing with NIC's

2001-02-11 Thread Bob Vance


Interesting.

Intel supports load balancing ("adapter teaming"), but it says that it
only does so on output, implying that only the "primary" adapter
responds to ARP requests (until a failure, when the "secondary" takes
over all functions, providing for failover as well as load sharing).

I had earlier posted a question as to why the Intel would work this way,
wondering why both NICs couldn't respond to ARPs.  I hadn't thought
about the NICs alternating in ARP responses, which, it seems, would also
work -- and make more sense.

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Kenneth
Sent: Sunday, February 11, 2001 8:53 AM
To: [EMAIL PROTECTED]
Subject: Re: loadbalancing with NIC's


The 6509 will see it as 2 separate MAC addresses. Based on my
conversation
with Ipmetrics engineer (i think it was them) the way it functions is
this:

Server A has ip 192.168.1.5

The NIC that is capable of loadbalancing maintains two unique MAC
addresses.

Everytime a client generates an arp request, it gives out MAC Address 1
When Another client generates an arp request, it gives out MAC address 2
It does this by doing a round-robin

Based on this, incoming requests are done via static load-balancing,
meaning, there is a static mapping of client-MAC to server-MAC. In case
of a
large network, statistically, this will provide an equal load on both
ports.

The switch will not use STP to block ports since there are two different
MAC
address on two different ports.

Hope this helps!

Kenneth Lorenzo

Moahzam Durrani <[EMAIL PROTECTED]> wrote in message
ED49D16A9BE4D41189C000104B2E399864C08D@sj-exchange">news:ED49D16A9BE4D41189C000104B2E399864C08D@sj-exchange...
>
> We are planning to connect a server with a single   NIC that supports
> faultolerance , redudndancy and load balancing.  How does a C6509
treat a
> Nic that is connected to two of its ports (same vlans)
> Mo Durrani
> IS&T
> WYSE\EDS
> phone:408-473 1246
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
> _
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>


_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

VLANs - 2 subnets, ARPing

2001-02-14 Thread Bob Vance

I was reviewing some old stuff and came across this one.

>The only exception to this is if you define the DG [default gateway]
for a
>device as its own IP.  In this case, the machine will issue an arp
request
>for all destinations. ...
>If the destination being arped for is on the same physical
>LAN/VLAN, it will see the arp request for its MAC,
>   but will ignore the request since it will recognize that the
>   requesting station is on a different IP subnet.
>   (I've done this in the lab, and this is what happens)

That's interesting, since I've done this to configure network devices
that
start with some funky, initial IP address like 192.0.0.192.
I simply (on my Win95 PC)
 . remove my DG
 . add new DG to my IP address
 . then I can connect to 192.0.0.192

There is no Proxy ARP going on.
I've also tested it on Linux and works the same way.

RFC826 does not mention any matching of addresses.
Further, how could it really know whether it were on a different
subnet? --
there is no subnet mask being passed in ARP packets.  The best it could
do
would be to make some kind of classful assumption, which would be bad.

So it seems to me that, if your device "ignore[ed] the request", then it
appears to have been an implementation bug.

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Kent Hundley
Sent: Friday, July 21, 2000 2:55 PM
To: 'Karen E Young'; 'jeongwoo park'; [EMAIL PROTECTED]
Subject: RE:

Actually, the IP addresses matter very much.

It doesn't matter if you have 2 devices on the same LAN/VLAN, if their
IP
addresses are not in the same IP subnet, they will need a router to talk
to
each other.  For example, if you have a station with IP address 10.1.1.1
and
another station with IP address 192.168.1.1, those 2 devices would need
a
router to talk to each other.

When an IP device needs to reach another IP device, it makes a
determination
based on its IP address and its subnet mask as to whether or not the
other
device is on the same subnet it is on.  If it is, it will issue an arp
request.  If it is not, it will send the packets to its DG.

If you have contiguous subnet ranges, you could play some games with the
masks, but then all you are doing is putting your devices on the same
subnet
for an IP address/subnet mask perspective, which doesn't change the fact
that a device will only issue an arp for a destination that is on its
own
subnet.

The only exception to this is if you define the DG for a device as its
own
IP.  In this case, the machine will issue an arp request for all
destinations.  If the router has proxy-arp turned on, it will respond
with
its MAC address.  If the destination being arped for is on the same
physical
LAN/VLAN, it will see the arp request for its MAC, but will ignore the
request since it will recognize that the requesting station is on a
different IP subnet. (I've done this in the lab, and this is what
happens)

It would be possible to hard-code mappings in each devices arp table and
install static routes for each others subnet and get them to talk to one
another without an intervening router, but this is beyond the scope of
the
original question.

The bottom line is that under normal operating circumstances you need a
router for 2 IP devices that are not in the same IP subnet to talk to
one
another, regardless if they are physically on the same LAN/VLAN.

-Kent

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Karen E Young
Sent: Friday, July 21, 2000 6:57 AM
To: jeongwoo park; [EMAIL PROTECTED]
Subject: Re:

No, you don't need a router. A node is determined to be a member of a
VLAN
by their MAC address. Layer 2 rather than Layer 3 remember? The router
is
only needed to deal with packets destined for anything outside the VLAN.
The
IP addresses don't matter.

Karen E Young

*** REPLY SEPARATOR  ***

On 7/20/2000 at 2:53 PM jeongwoo park wrote:

:HI all
:I have a question.
:Cisco recommends that there be one-to-one relationship
:between ip subnets and Vlans.
:When the number of devices on a Vlan exceeds the
:number of host ip addresses per configured subnet,
:more than one subnet can exit on a Vlan.
:Having said that, my question;
:There are two subnets in a Vlan. Do we need a router
:to interconnect these two subnets?
:I know that we need a router to interconnect two
:different Vlans.
:
:Thanks.
:
:jeongwoo
:
:
:__
:Do You Yahoo!?
:Get Yahoo! Mail  Free email you can access from anywhere!
:http://mail.yahoo.com/
:
:___
:UPDATED Posting Guidelines: http://www.groupstudy.com

HSRP and UDP forwarding.

2001-02-18 Thread Bob Vance


I was told this in another venue:

>It is the nature of HSRP. Both routers listen to broadcast traffic.
Both
>routers are configured as a DHCP and BOOTP relay agent in order to get
>redundancy. So all DHCP and BOOTP broadcast traffic is sent twice to
the
>central server.

Is there some reason for this to be true?
It does not seem right to me.

My understanding is that, normally, HSRP does not depend on multiple
routers in the group to forward traffic.  The HSRP group appears as one
router to the side where it is being redundant, with the primary router
forwarding all traffic.  The standby doesn't participate, except
possibly
on reply traffic

I think that you would agree that it is not normal nor good (maybe not
necessarily bad, but certainly not good :) for a router arbitrarily to
send duplicate packets onto a subnet and this is, in effect, what would
be happening here.

In single-group HSRP mode, I can see no reason for this to be
required --
I would think that it would be sufficient for the UDP forwarding simply
to follow the primary router.

Multi-group HSRP seems to present some other possibilities/problems that
I haven't explored in depth yet.  One point is that it would appear that
having MHSRP primary routers forwarding DHCP (at least the broadcasts)
would require extraordinary configuration on the DHCP server.  For
example, if the clients are in the same subnet, then which default
gateway should it send to the client?  Thus, MHSRP *with* DHCP
forwarding
would seem to require, practically, multiple subnets and broadcast
domains -- i.e., VLANs.

Comments?

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=




_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: HSRP and UDP forwarding.

2001-02-19 Thread Bob Vance

Thanks, Erick.
It seems that you have basically said,
   "Yes, UDP forwarding is not part of HSRP."

But you also apparently agree that there is no technical reason why this
must be true :)

>Maybe they need to add a feature, like standby helper or something so
>when HSRP is being used it will only forward UDP broadcast traffic on
>the device that has the HSRP IP active.
>Example: if such a feature existed, then you wouldn't use ip-helper on
>HSRP interfaces - you would use standby-helper if you just wanted UDP
>forwarded on device with active HSRP IP address.

ISTM that it would be easy to simply add a command like

   [no] standby-helper

Everything else, including "ip-helper" is the same, and this flag simply
tells a router in standby or monitor mode not to forward, but when in
primary mode to do so.

I guess the effort is not worth the gain.  UDP's being an unreliable and
connection-less transport requires the protocols to be robust enough to
handle the duplicate packets.

The problem arising from this duplicate forwarding with DHCP occurs when
the 2nd DHCPDISCOVER is delayed enough so that the client has already
received its lease and IP address in response to the 1st DHCPDISCOVER.
When the server sees the 2nd DHCPDISCOVER, it will try to give the same
address again.  But, prior to doing so, it MAY (RFC2131) ping the
address to see whether it's in use.  Well, the client will respond,
because it just got the IP address :)  The server will then try to give
another IP address and abandon the first lease.

Of course, that's a contrived and highly unlikely case -- the packet
would probably never be delayed that long, but it just came to my mind
when thinking about this.

-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: Erick B. [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 18, 2001 5:43 PM
To: Bob Vance; CISCO_GroupStudy List (E-mail)
Subject: Re: HSRP and UDP forwarding.

Look at this way. HSRP (and VRRP) share a virtual IP
address among the devices participating. Hosts point
their default-gateway to this Virtual IP address. This
allows the hosts to still forward traffic when the
primary router/switch interface goes down and the
standby router/switch changes over to active. This is
the function of HSRP/VRRP - to provide a shared IP
address among multiple interfaces on the same network.

If the interface is in standby mode for HSRP then the
standby IP address isn't active on this interface, but
the primary IP is active and ip-helper, routing, and
all other IP features you have configured are active
unless the interface is down, etc.

Currently, there isn't a way to stop ip-helper from
forwarding when the HSRP address is in standby mode
since ip-helper isn't part of HSRP. Maybe they need to
add a feature, like standby helper or something so
when HSRP is being used it will only forward UDP
broadcast traffic on the device that has the HSRP IP
active. Example: if such a feature existed, then you
wouldn't use ip-helper on HSRP interfaces - you would
use standby-helper if you just wanted UDP forwarded on
device with active HSRP IP address.

The only way to get around forwarding UDP broadcasts
from both routers would to remove the ip-helper from
one of the interfaces. The problem here is when the
other interface goes down you're not going to forward
the UDP broadcasts anymore. The other solution would
to be make the DHCP server local so ip-helper wasn't
needed.

If you search on cisco.com for HSRP and IP-helper
you'll get a document on UDP Flooding which involves
bridge-groups and using spanning-tree to block.

Erick

--- Bob Vance <[EMAIL PROTECTED]> wrote:
> I was told this in another venue:
>
> >It is the nature of HSRP. Both routers listen to
> broadcast traffic.
> Both
> >routers are configured as a DHCP and BOOTP relay
> agent in order to get
> >redundancy. So all DHCP and BOOTP broadcast traffic
> is sent twice to
> the
> >central server.
>
> Is there some reason for this to be true?
> It does not seem right to me.
>
> My understanding is that, normally, HSRP does not
> depend on multiple
> routers in the group to forward traffic.  The HSRP
> group appears as one
> router to the side where it is being redundant, with
> the primary router
> forwarding all traffic.  The standby doesn't
> participate, except
> possibly
> on reply traffic
>
> I think that you would agree that it is not normal
> nor good (maybe not
> necessarily bad, but certainly not good :) for a
> router arbit

RE: Creating Multiple Interfaces on an Ethernet Port

2001-02-20 Thread Bob Vance

I would swear that I read that "secondary" was eventually going away
and the sub-interfaces would replace it.

Am I dreaming?

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Priscilla Oppenheimer
Sent: Monday, February 19, 2001 10:33 PM
To: [EMAIL PROTECTED]
Subject: Re: Creating Multiple Interfaces on an Ethernet Port

At 04:47 PM 2/19/01, Chris Wornell wrote:
>Hello,
>
>I've found out you can't create multiple interfaces on an ethernet port
>apparently.  I was wondering why this is exactly?  I know you can
accomplish
>the same on serial lines using pvc's but it seems odd you can't do it
on
>ethernet.

Why do you want to create multiple interfaces on your Ethernet port?
Ethernet was designed as a connectionless, packet-switched shared
network.
Serial links, on the other hand, are more often used for
connection-oriented virtual circuits. Subinterfaces let you associate a
single physical link with multiple virtual circuits.

>   I know there are ethernet only networks and the ip secondary
>command doesn't seem right compared to creating a new interface.

Sure there are Ethernet-only networks. Each physical Ethernet port on a
router is usually associated with an IP subnet. If you happen to have
two
IP subnets on the LAN to which a physical port is attached, you could
use a
secondary IP address as a workaround to this problem. Traffic between
subnets would still go through the router usually.

If you're using your Ethernet port as a "trunk port," and you use ISL or
802.1q VLAN encapsulation, then you can configure subinterfaces. In this
case, subinterfaces let you associate a single physical link with
multiple
VLANs. Inter-Switch Link (ISL) and IEEE 802.1q maintain VLAN
identification
information as traffic travels between connected switches.

Maybe you can give us a better idea of what you are trying to accomplish
and we can provide more tailored information, but I hope this info was
somewhat useful.

Priscilla

>Chris Wornell
>Technical Support
>MM Internet http://mminternet.com
>888-654-4971
>CCNA, CCDA, CSE
>
>_
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Priscilla Oppenheimer
http://www.priscilla.com

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Reverse DNS

2001-02-20 Thread Bob Vance


It's a good idea to have reverse entries for forward names that are
visible to the Internet -- some mail servers do a reverse lookup to
"verify" that you are valid and won't receive your mail without the
reverse lookup.

Typically, your ISP will be authoritative for the zone from which your
IP space is allocated (although not always).
But, I think that it's better for you to be the master for both the
forward and reverse zones, and let the ISP be slave (secondary) for
both.

If you have an entire /24 block of addresses, then they would just
delegate that entire zone to you.

If you have a partial Class C (/n where n>24), then the ISP will
remain authoritative for the full zone, but there are several ways that
they can give you control.

One way is for them to delegate to you a sub-zone of the full reverse
zone and then put CNAMEs pointing into the new sub-zone for which you
will be authoritative -- you put the 'real" PTRs in this new sub-zone.

IMHO, better is for them simply to replace their current PTR records
with CNAME records pointing to names into your current *forward* zone.
You would then insert PTR records with those names into your current
forward zone and then you can change them at will.
Two benefits to this method are:
  . there are no new zones nor NS records
  . your forward "A" records and the corresponding reverse PTR
records are right in the same zone.

The ISP would normally have the PTRs thusly:

$ORIGIN zz.yy.xx.in-addr.arpa.
   ...
num   IN  PTR  name.in.your.domain.

But every time you make a change, the ISP has to get involved.
In the second method I described above, the ISP replaces that record
thusly:


$ORIGIN zz.yy.xx.in-addr.arpa.
   ...
;;del;; num   IN  PTR  name.in.your.domain.
num  IN  CNAME  num.in.you.domain.

Then, in your forward zone you simply add the "real" PTRs:

$ORIGIN in.your.domain.
   ...
name  IN  A  num.xx.yy.zz
num   IN PTR name
   ...




-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Roan, Wayne
Sent: Tuesday, February 20, 2001 5:18 PM
To: '[EMAIL PROTECTED]'
Subject: Reverse DNS


Group,

Question, if you are maintaining the DNS zones for your domains, do
you need reverse zones with entries for each of your domains the
Internet
needs to get to?  Let's say your ISP is providing secondary DNS for you,
will they host reverse DNS for you? or do you still need to provide for
reverse DNS regardless?

Thanks,

Wayne

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Reverse DNS

2001-02-21 Thread Bob Vance


I should clarify that the ISP will add CNAMEs for the *entire* partial
IP range assigned to you, regardless of whether you have a matching PTR
record -- you add/modify the PTRs as needed.
Then the ISP will never have to make another change.

Suppose you have 1.2.3.16/28.
Then the ISP's reverse will look like:

$ORIGIN 3.2.1.in-addr.arpa.
   ...
16  IN  CNAME  16.in.your.domain.
17  IN  CNAME  17.in.your.domain.
   ...
31  IN  CNAME  31.in.your.domain.

Of course, he'll probably really use a single line in his config:

$GENERATE 16-31  $ CNAME  $.in.your.domain.

(or maybe  17-30  :)


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Tuesday, February 20, 2001 7:39 PM
To: CISCO_GroupStudy List (E-mail)
Subject: RE: Reverse DNS


It's a good idea to have reverse entries for forward names that are
visible to the Internet -- some mail servers do a reverse lookup to
"verify" that you are valid and won't receive your mail without the
reverse lookup.

Typically, your ISP will be authoritative for the zone from which your
IP space is allocated (although not always).
But, I think that it's better for you to be the master for both the
forward and reverse zones, and let the ISP be slave (secondary) for
both.

If you have an entire /24 block of addresses, then they would just
delegate that entire zone to you.

If you have a partial Class C (/n where n>24), then the ISP will
remain authoritative for the full zone, but there are several ways that
they can give you control.

One way is for them to delegate to you a sub-zone of the full reverse
zone and then put CNAMEs pointing into the new sub-zone for which you
will be authoritative -- you put the 'real" PTRs in this new sub-zone.

IMHO, better is for them simply to replace their current PTR records
with CNAME records pointing to names into your current *forward* zone.
You would then insert PTR records with those names into your current
forward zone and then you can change them at will.
Two benefits to this method are:
  . there are no new zones nor NS records
  . your forward "A" records and the corresponding reverse PTR
records are right in the same zone.

The ISP would normally have the PTRs thusly:

$ORIGIN zz.yy.xx.in-addr.arpa.
   ...
num   IN  PTR  name.in.your.domain.

But every time you make a change, the ISP has to get involved.
In the second method I described above, the ISP replaces that record
thusly:


$ORIGIN zz.yy.xx.in-addr.arpa.
   ...
;;del;; num   IN  PTR  name.in.your.domain.
num  IN  CNAME  num.in.you.domain.

Then, in your forward zone you simply add the "real" PTRs:

$ORIGIN in.your.domain.
   ...
name  IN  A  num.xx.yy.zz
num   IN PTR name
   ...




-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Roan, Wayne
Sent: Tuesday, February 20, 2001 5:18 PM
To: '[EMAIL PROTECTED]'
Subject: Reverse DNS


Group,

Question, if you are maintaining the DNS zones for your domains, do
you need reverse zones with entries for each of your domains the
Internet
needs to get to?  Let's say your ISP is providing secondary DNS for you,
will they host reverse DNS for you? or do you still need to provide for
reverse DNS regardless?

Thanks,

Wayne

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: wildcard in access-list

2001-03-04 Thread Bob Vance


>Why?

Less processing.
Elegance :)
Cleverness :)
More documentation ~%[

I love that sort of stuff --
hmm, I guess this means that you wouldn't hire me, eh, Howard?


-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Howard C. Berkowitz
Sent: Saturday, March 03, 2001 1:31 PM
To: [EMAIL PROTECTED]
Subject: Re: wildcard in access-list


>I have two parts of a large network, the first part using 141.120.0.0
>thru 141.120.7.255 and the second part using 141.120.128.0 thru
>141.120.135.255. At the router connecting to Internet I want access
from
>outside limited only to these subnets and not to other addresses used.
I
>know that the following will work for TCP:
>
>access-list 101 tcp permit any 141.120.0.0 0.0.7.255
>access-list 101 tcp permit any 141.120.128.0 0.0.7.255
>
>I want to condesnse this to a single statement as follows:
>
>access-list 101 tcp permit any 141.120.0.0 0.0.135.255


Why?

Or, to put in other terms, how would you like to find that access
list statement in an undocumented configuration you've just been
asked to troubleshoot?

A good rule of thumb:  suspect any mask octet that doesn't have
contiguous bits,
unless you are EXACTLY sure why it's being done:

   Subnet   Wildcard
   --   
  255   0
  254   1
  252   3
  248   7
  240  15
  224  31
  192  63
  128 127
0 255

>
>Will this work?
>For example 141.120.9.2 should not be allowed.
>In binary 141.120.9.2 is 10001101.0000.1001.0010.
>
>My understanding of the steps of how the access-list works is :
>
>1) perform a NOT the mask, which gives in binary
>   ..0000.
>2) perform an AND between this and the IP address, which gives in
binary
>   10001101.0000.1000.
>3) compare the result with the original IP address in the access-list
>   the comparison fails
>4) if successful, allow, otherwise drop.
>   so the packet is dropped.
>
>Is the above correct?
>I don't have a lab to test this. I would appreciate any help. Thanks.
>
>Nelluri

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: wildcard in access-list

2001-03-04 Thread Bob Vance


Let's see...
You don't care whether bit 16 (or is that 17 :?) is a 0 or a 1, right?
Then the wildcard bit can be 1 :)

A general statement would be:
If you have two otherwise identical ACL statements with
addresses that differ only in one bit position, then you
can combine the ACLs into one with the mask having that
bit position set to 1 (don't care).
You can then iterate the above for more consolidation.



>3) compare the result with the original IP address in the access-list

The actual logical compare that must be done is:

  Do the care bits of the ACL address
  match the care bits of the processed address.

(obviously :)

So, technically, the ACL address must also be ANDed with the mask
complement, in case the ACL address, as entered, doesn't have all the
don't-care bits set to 0.  Of course, this would only be done once, at
initialization, and the value stored.

IIRC, at least stating at some IOS version level, this is being done
automatically for you by IOS when it stores the ACL in the
configuration.  Thus, if you typed:

  access-list 101 tcp permit any 141.120.128.0 0.0.135.255

it would actually show up via a  'sh run'  as

  access-list 101 tcp permit any 141.120.0.0 0.0.135.255

I'm not sure about this, though --
I'm sure that someone else will confirm/debunk it.



> the comparison fails

Still correct :)



-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Nelluri Reddy
Sent: Saturday, March 03, 2001 12:56 PM
To: [EMAIL PROTECTED]
Subject: wildcard in access-list


I have two parts of a large network, the first part using 141.120.0.0
thru 141.120.7.255 and the second part using 141.120.128.0 thru
141.120.135.255. At the router connecting to Internet I want access from
outside limited only to these subnets and not to other addresses used. I
know that the following will work for TCP:

access-list 101 tcp permit any 141.120.0.0 0.0.7.255
access-list 101 tcp permit any 141.120.128.0 0.0.7.255

I want to condesnse this to a single statement as follows:

access-list 101 tcp permit any 141.120.0.0 0.0.135.255

Will this work?
For example 141.120.9.2 should not be allowed.
In binary 141.120.9.2 is 10001101.0000.1001.0010.

My understanding of the steps of how the access-list works is :

1) perform a NOT the mask, which gives in binary
  ..0000.
2) perform an AND between this and the IP address, which gives in binary
  10001101.0000.1000.
3) compare the result with the original IP address in the access-list
  the comparison fails
4) if successful, allow, otherwise drop.
  so the packet is dropped.

Is the above correct?
I don't have a lab to test this. I would appreciate any help. Thanks.

Nelluri

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: wildcard in access-list

2001-03-04 Thread Bob Vance


>>hmm, I guess this means that you wouldn't hire me, eh, Howard?

>Well, can you phrase this as "full employment for consultants?"

All seriousness aside, I actually meant as an employee -- not as a
consultant :)


> With a tired, triumphant,
>  yet demented look, he announced: "Yes, it is obvious."

LOL.
You've been eavesdropping on some of my math sessions with my children,
haven't
you.  I've learned more about the foundations of arithmetic since I had
kids than I
did studying math in school :)


>There is a poorly documented corollary of Murphy's Law that establishes
>that idiots inherit the work of the clever.

Right.
But I would assume that that doesn't mean that you are deprecating
cleverness,
per se (after all, cleverness is the Aunt of invention) but, maybe just
want to
leave cleverness where it belongs -- in the lab :)


I tend to go for the clever first and, then, after proving that it
works, start to
worry about the potential obfuscation (not to mention the phone calls)
and change to
a more "self-documenting" route.

So, one moment I might code the single ACL;
the next I would change it to the "self-documenting" two-statement ACL.

   (In fact, I would agree that you could easily argue that the second
is the more
elegant since it kills two birds with one stone:
 functionality
and no   extra documentation  :)
   )


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Howard C. Berkowitz
Sent: Sunday, March 04, 2001 11:35 AM
To: [EMAIL PROTECTED]
Subject: RE: wildcard in access-list


>  >Why?

To which Bob Vance responded,

>
>Less processing.

  CPU power is cheaper than brainpower, downtime through errors,
etc.

>Elegance :)

  I've always regarded an elegant solution as one that is necessary
  and sufficient for all criteria. Maintainability is a criterion.

  A professor, in his* Tuesday class, droned on "it is obvious that
XXX
  is ZZZ."

  A student responded, "Professor, are you sure it is obvious?"

  A look of professorial alarm. "Class dismissed."

  On Thursday, the class returned to find their professor still at
the
  board, fairly obviously unwashed and unshaven since Tuesday,
perhaps
  nourished only by incessant cups of coffee.  With a tired,
triumphant,
  yet demented look, he announced: "Yes, it is obvious."

* choice of pronoun gender deliberate.  This is a guy thing**,  the
academic version of refusing to ask for directions.
** a female professor, however, might want to share the experience of
confusion.

>Cleverness :)

  There is a poorly documented corollary of Murphy's Law that
establishes
  that idiots inherit the work of the clever.

  Military organizations have much folklore about this.  In working
with
  US Navy personnel, I learned the valid distinctions between
idiot-proofing
  and sailor-proofing.  Or, as it is said, the five most dangerous
things
  in the Canadian Navy:
 -- Ordinary Seamen saying: "I learned this in Boot Camp"
 -- Petty Officers saying "Trust me, sir"
 -- Sublieutenants saying "Based on my experience"
 -- Lieutenants saying "I was just thinking"
 -- Chiefs saying "Watch this [output traffic from male cow]"

>More documentation ~%[
>
>I love that sort of stuff --


>hmm, I guess this means that you wouldn't hire me, eh, Howard?

Well, can you phrase this as "full employment for consultants?"

In all fairness, there is a regrettable Cisco tendency to teach and
test for obscurity.

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Discontiguous networks

2001-03-15 Thread Bob Vance


>The binary mask for last octet would be 1010.

Actually, it's worse than that!!

1010  =  128 + 32  = 160, not 148  :|

148 = 128 + 20 = 128 + 16 +4  = 1001 0100

I'll let you fill the rest in :)


-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Thursday, March 15, 2001 12:41 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Discontiguous networks


ouch!  Please do not attempt this at home.  Heck, please do not attempt
this anywhere!  :-)

The binary mask for last octet would be 1010. If you assume the use
of subnet zero, your host address go from 1 to 31, then skip to 64-94.
The next subnet in binary is 0010 so the network address is
192.10.3.32 and host address are 33-63 and 95-126.  This is painful,
it's making my head hurt

Okay then, the next subnet in binary is 1000, or .128 in decimal,
and your host addresses are 129-159 and 192-223.  The final subnet is
1010, or .148 and the host addresses are 149-180 and 224-254.

I think.  That is really painful to think through and I was interrupted
multiple times while trying to write this.  Please forgive me if these
numbers aren't correct.

And always remember:  Friends don't let friends use discontiguous
subnet masks!

>>> "Arthur Simplina" <[EMAIL PROTECTED]> 3/15/01 10:04:17 AM >>>
I know that there was an earlier posting and a very good explanation on

this. So, kindly bear with me.

I am trying to figure out the subnets (and hosts) for this address:

192.10.3.0 with subnet mask 255.255.255.148.

I am asking this out of curiosity and to learn how to go about this.

Thanks for any help.

Arthur


_
Get your FREE download of MSN Explorer at http://explorer.msn.com

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]



_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Discontiguous networks

2001-03-15 Thread Bob Vance


>it was with two mask bits.

I think that Howard would say that it was a 2-bit mask  :)



-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: John Neiberger [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 15, 2001 2:25 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Discontiguous networks


Oops!  I knew I should have learned how to add at some point in my life!
 :-)

I'm glad you caught that.  The calculations I made were bad enough as
it was with two mask bits.  I'm not going to do it again with three!

Thanks,
John


_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Sample CCNA test question..bogus?

2001-03-15 Thread Bob Vance


"D" is the only possible answer to give on a test, since it's pretty
clear what the tester meant :)

I guess the question could have been worded:

  "Given the Class B network 172.16.0.0, using a prefix length
   of 19, which of the following is a valid address?
  "

Or much more simply and clearly:

Q. Which one of the following is a valid host address?

a. 172.16.32.0 /19

b. 172.16.64.0 /19

c. 172.16.63.255 /19

d. 172.16.80.255 /19



-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Adam Hickey
Sent: Thursday, March 15, 2001 1:40 PM
To: Lowell Sharrah; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Sample CCNA test question..bogus?


Amen!

Thank You
Adam Hickey
Cable & Wireless
Network Engineer, IOPS
[EMAIL PROTECTED]
___
"And One!"

- Original Message -
From: "Lowell Sharrah" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 15, 2001 10:10 AM
Subject: Re: Sample CCNA test question..bogus?


> this is assuming vlsm.  when you have a class network with varibale
bits
in the subnet mask that is different than the default subnet mask, you
have
multiple subnets and multiple host on each subnet.  This question is
telling
us that there are 3 bits as subnet bits (since the default for class B
networks is 16) and the remaining 13 are host bits.  This arnagement
(172.16.0.0/19) calculates out to be more than one subnet and answer d
falls
in one of the valid subnet ranges.  If thew question was worded
differently
with a particular subnet such as 172.16.30.x/19, then it would not be
true.
>
> >>> "John Neiberger" <[EMAIL PROTECTED]> 03/15/01 12:04PM
>>>
> How could the wording be correct?  172.16.80.255 is a host address in
> 172.16.64.0/19, *not* 172.16.0.0/19.   There is no correct answer
> provided to that specific question as worded. I agree that it is
trying
> to be a trick question, but it fails because of poor wording or a
typo.
> Perhaps one of the answers should have been 172.16.15.255 or something
> like that.  That would have been tricky yet also correct given the
> question that was being asked.
>
> John
>
> >>> "Arthur Simplina" <[EMAIL PROTECTED]> 3/15/01 9:51:53 AM >>>
> I think the trick part of question here is that the answer d.
> 172.16.80.255
> seems like a broadcast address because of the 255 (all 1's in the last
>
> octec.) So now the test taker faces the dilemna of choosing between
two
>
> subnetwork addressess and two "broadcast" addresses.
>
> Cisco would want to know if you really know subnetting. Hence, the
> wording
> of the question (which to my opinion is still correct).
>
> Arthur
>
>
> >From: "John Neiberger" <[EMAIL PROTECTED]>
> >Reply-To: "John Neiberger" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Sample CCNA test question..bogus?
> >Date: Thu, 15 Mar 2001 09:19:53 -0700
> >
> >I think I'll side with those who say there is no correct answer, but
> >there is an answer that's closer to being correct than the others.
> :-)
> >
> >The question is asking for a valid host in the 172.16.0.0/19 range.
> >Answer D is not in that range!  It is in the 172.16.64.0/19 network.
> >Valid host addresses in the 172.16.0.0/19 range are:
> >
> >172.16.0.1 through 172.16.31.254
> >
> >I would agree that by making a subtle adjustment to the question,
> >answer D is the only answer possible.  Given a /19 prefix length, the
> >only possible host address given in the answers is D, which forces us
> to
> >change the question to fit the answer.
> >
> >This just appears to be a poorly worded question that not only allows
> >you to figure out the most-correct answer eventually but also forces
> you
> >to deduce what the actual question is in the first place.In
> other
> >words, it's a typical Cisco test question!
> >
> >Regards,
> >John
> >
> > >>> "Arthur Simplina" <[EMAIL PROTECTED]> 3/15/01 8:46:27 AM
> >>>
> >d. 172.16.80.255
> >
> >This belongs to subnet 172.16.64.0 with host range of 172.16.64.1 -
> >172.16.95.254.
> >
> >Arthur
> >
> >
> > >From: "Bruce" <[EMAIL PROTECTED]>
> > >Reply-To: "Bruce" <[EMAIL PROTECTED]>
> > >To: [EMAIL PROTECTED]
> > >Subject: Sample CCNA test question..bogus?
> > >Date: Thu, 15 Mar 2001 15:11:07 +1100
> > >
> > >Q. Which one of the following is a valid host using the address of
> > >172.16.0.0 /19?
> > >
> > >a. 172.16.32.0
> > >
> > >b. 172.16.64.0
> > >
> > >c. 172.16.63.255
> > >
> > >d. 172.16.80.255
> > >

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct

why is routing needed with VLANs

2001-01-16 Thread Bob Vance


OK.
I must be brain dead, today.
   (and, yes, Chuck, I *have* had my morning dose of Diet Coke :)
and, yes, I know, "What's so special about 'today' "?
   )
As far I can understand it so far, about the only benefit that I see
from VLANs is reducing the size of broadcast domains.

Suppose that I have a switch in the closet with one big flat address
space (well, it couldn't be that big with only one switch, now, could
it ?>).  Then someone says,
  "You know, we're getting a lot of blah-blah broadcast traffic.
   Let's VLAN.
  "
OK, fine.  We VLAN and put whatever services in each VLAN that are
required to handle the broadcasts (e.g., DHCP service).  So, now the
switch doesn't send broadcasts outside a particular VLAN.

But, what's so magic about a VLAN that the switch also decides not to
send unicasts outside a VLAN.   Before the VLANs, the switch maintained
a MAC table and knew which port to go out to get to any unicast address
in the entire space.  So, why can't it continue to do that after we
arbitrarily implement some constraint on broadcast addresses?
It seems to me that the same, exact MAC table, with an additional VLAN
field would not require that restriction.  If it's a broadcast, send the
packet only out ports with a VLAN-id that matches the source port's
VLAN-id.  If it's a unicast, handle it just like we used to.


Similarly, even if we have 5 switches, I just don't see the requirement
that we (as switch-code designers) must block unicasts and resort to a
routing requirement.

Even with 500 switches ... well, let's not get ridiculous :)


I feel that there is a simple point that I've overlooked, so I will
continue to RTFM while I await your responses.>)


-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=




_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: why is routing needed with VLANs - ARP?

2001-01-16 Thread Bob Vance


What I'm saying is that, before we implement VLANs, we have a flat
address space, with obviously, no routing.
Now, suppose that I arbitrarily decide not to forward broadcasts out
ports 6-10 through some IOS command.
Everything will still work quite happily (except anything relying on
those broadcasts, of course).
...
Ooops.   I think that I just saw the answer.

One of those broadcast thingys is lil' ole ARP.
So, how does a client find the IP address of a destination if the
destination is outside the VLAN?

It's funny that this wasn't pointed out in any of my VLAN reading
(admittedly limited to ICND coursebook and Caslow).
It just arbitrarily says unicasts are blocked or routing is
required without giving a reason.

Oh, well.


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Tuesday, January 16, 2001 11:35 AM
To: CISCO_GroupStudy List (E-mail)
Subject: why is routing needed with VLANs


OK.
I must be brain dead, today.
   (and, yes, Chuck, I *have* had my morning dose of Diet Coke :)
and, yes, I know, "What's so special about 'today' "?
   )
As far I can understand it so far, about the only benefit that I see
from VLANs is reducing the size of broadcast domains.

Suppose that I have a switch in the closet with one big flat address
space (well, it couldn't be that big with only one switch, now, could
it ?>).  Then someone says,
  "You know, we're getting a lot of blah-blah broadcast traffic.
   Let's VLAN.
  "
OK, fine.  We VLAN and put whatever services in each VLAN that are
required to handle the broadcasts (e.g., DHCP service).  So, now the
switch doesn't send broadcasts outside a particular VLAN.

But, what's so magic about a VLAN that the switch also decides not to
send unicasts outside a VLAN.   Before the VLANs, the switch maintained
a MAC table and knew which port to go out to get to any unicast address
in the entire space.  So, why can't it continue to do that after we
arbitrarily implement some constraint on broadcast addresses?
It seems to me that the same, exact MAC table, with an additional VLAN
field would not require that restriction.  If it's a broadcast, send the
packet only out ports with a VLAN-id that matches the source port's
VLAN-id.  If it's a unicast, handle it just like we used to.


Similarly, even if we have 5 switches, I just don't see the requirement
that we (as switch-code designers) must block unicasts and resort to a
routing requirement.

Even with 500 switches ... well, let's not get ridiculous :)


I feel that there is a simple point that I've overlooked, so I will
continue to RTFM while I await your responses.>)


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=




_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: why is routing needed with VLANs

2001-01-16 Thread Bob Vance


Thanks.

>A VLAN is, by definition, a separate subnet.

Well, not by any definition that I've yet read :)

But, I was essentially asking *why* it has to be a different subnet.
That is not discussed anywhere that I've read.
But, anyway, as I posted, I think that the answer is ARP.
If ARP broadcast is not forwarded then we'll not be able to find the MAC
address of a destination IP outside our own VLAN (at least not without
Proxy ARP -- and we've just introduced a router, again !!!


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: John Neiberger [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 16, 2001 12:48 PM
To: Bob Vance; [EMAIL PROTECTED]
Subject: Re: why is routing needed with VLANs


A VLAN is, by definition, a separate subnet.  If you decided to separate
a
single LAN into two VLANs, you'll have to change your addressing scheme.
Once you've done that, you have to route to get from one subnet to the
other.  I don't even like the term "VLAN".  The very term seems to cause
a
lot of conceptual problems.

For example, let's say you have one LAN and you decide to create a new
VLAN
for a total of two VLANs.  This is absolutely no different than having
two
normal LANs on different ports on a router: you have two separate IP
subnets
and you must route to get from one to the other.  The only difference is
that you can use trunking to pass data for both subnets down the same
wire,
and you can then let a switch split that traffic up and send it to the
correct ports.

Imagine the router with two separate ethernet interfaces, each in its
own
subnet, and these are connected to two separate switches.  There is no
topological difference between that scenario and a router doing ISL or
802.1q trunking to a switch that is configured for two VLANs.  The
requirements for connectivity are the same:  you must have a router to
get
from one subnet to the other.  Even though they are physically on the
same
switch, topologically speaking they are on different networks.

I hope this makes sense.  I had three people stop by my cube to talk and
I
had three phone calls while trying to write this.  :-)

Regards,
John

>  OK.
>  I must be brain dead, today.
> (and, yes, Chuck, I *have* had my morning dose of Diet Coke :)
>  and, yes, I know, "What's so special about 'today' "?
> )
>  As far I can understand it so far, about the only benefit that I see
>  from VLANs is reducing the size of broadcast domains.
>
>  Suppose that I have a switch in the closet with one big flat address
>  space (well, it couldn't be that big with only one switch, now, could
>  it ?>).  Then someone says,
>"You know, we're getting a lot of blah-blah broadcast traffic.
> Let's VLAN.
>"
>  OK, fine.  We VLAN and put whatever services in each VLAN that are
>  required to handle the broadcasts (e.g., DHCP service).  So, now the
>  switch doesn't send broadcasts outside a particular VLAN.
>
>  But, what's so magic about a VLAN that the switch also decides not to
>  send unicasts outside a VLAN.   Before the VLANs, the switch
maintained
>  a MAC table and knew which port to go out to get to any unicast
address
>  in the entire space.  So, why can't it continue to do that after we
>  arbitrarily implement some constraint on broadcast addresses?
>  It seems to me that the same, exact MAC table, with an additional
VLAN
>  field would not require that restriction.  If it's a broadcast, send
the
>  packet only out ports with a VLAN-id that matches the source port's
>  VLAN-id.  If it's a unicast, handle it just like we used to.
>
>
>  Similarly, even if we have 5 switches, I just don't see the
requirement
>  that we (as switch-code designers) must block unicasts and resort to
a
>  routing requirement.
>
>  Even with 500 switches ... well, let's not get ridiculous :)
>
>
>  I feel that there is a simple point that I've overlooked, so I will
>  continue to RTFM while I await your responses.>)
>
>
>  -
>  Tks??? ??? | <mailto:[EMAIL PROTECTED]>
>  BV???  | <mailto:[EMAIL PROTECTED]>
>  Sr. Technical?Consultant,? SBM, A Gates/Arrow Co.
>  Vox 770-623-3430???11455 Lakefield Dr.
>  Fax 770-623-3429?? Duluth, GA 30097-1511
>  =
>
>
>
>
>  _
>  FAQ, list arch

RE: why is routing needed with VLANs - ARP? - follow-up

2001-01-17 Thread Bob Vance


I think that Peter Van Oene hit the nail on the head (and confirmed my
conclusion :) , so I thought that I'd share a couple of his thoughts.

   " ...  More specifically, which applications can work in a unicast
only
world?  Do you intend on statically mapping all your IP to MAC
relationships on node by node basis since ARP no longer works as a
discovery mechanism?

Thinking about this stuff leads to the understanding that
broadcasting
is a fundamental communication tool in today's networks and one
cannot
eliminate its use without creating a major disturbance.

Your understanding of VLAN'ing as a very simple technology is on the
money however.  Its simply a way to create two broadcast domains
where
there was previously one without additional replication of hardware
and
cabling.
   "

You know, it seems that broadcasting is a lot like friction --

We spend a lot of time trying to reduce it, but we can't live without it
!


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Tuesday, January 16, 2001 12:50 PM
To: CISCO_GroupStudy List (E-mail)
Subject: RE: why is routing needed with VLANs - ARP?


What I'm saying is that, before we implement VLANs, we have a flat
address space, with obviously, no routing.
Now, suppose that I arbitrarily decide not to forward broadcasts out
ports 6-10 through some IOS command.
Everything will still work quite happily (except anything relying on
those broadcasts, of course).
...
Ooops.   I think that I just saw the answer.

One of those broadcast thingys is lil' ole ARP.
So, how does a client find the IP address of a destination if the
destination is outside the VLAN?

It's funny that this wasn't pointed out in any of my VLAN reading
(admittedly limited to ICND coursebook and Caslow).
It just arbitrarily says unicasts are blocked or routing is
required without giving a reason.

Oh, well.


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Tuesday, January 16, 2001 11:35 AM
To: CISCO_GroupStudy List (E-mail)
Subject: why is routing needed with VLANs


OK.
I must be brain dead, today.
   (and, yes, Chuck, I *have* had my morning dose of Diet Coke :)
and, yes, I know, "What's so special about 'today' "?
   )
As far I can understand it so far, about the only benefit that I see
from VLANs is reducing the size of broadcast domains.

Suppose that I have a switch in the closet with one big flat address
space (well, it couldn't be that big with only one switch, now, could
it ?>).  Then someone says,
  "You know, we're getting a lot of blah-blah broadcast traffic.
   Let's VLAN.
  "
OK, fine.  We VLAN and put whatever services in each VLAN that are
required to handle the broadcasts (e.g., DHCP service).  So, now the
switch doesn't send broadcasts outside a particular VLAN.

But, what's so magic about a VLAN that the switch also decides not to
send unicasts outside a VLAN.   Before the VLANs, the switch maintained
a MAC table and knew which port to go out to get to any unicast address
in the entire space.  So, why can't it continue to do that after we
arbitrarily implement some constraint on broadcast addresses?
It seems to me that the same, exact MAC table, with an additional VLAN
field would not require that restriction.  If it's a broadcast, send the
packet only out ports with a VLAN-id that matches the source port's
VLAN-id.  If it's a unicast, handle it just like we used to.


Similarly, even if we have 5 switches, I just don't see the requirement
that we (as switch-code designers) must block unicasts and resort to a
routing requirement.

Even with 500 switches ... well, let's not get ridiculous :)


I feel that there is a simple point that I've overlooked, so I will
continue to RTFM while I await your responses.>)


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
===

RE: why is routing needed with VLANs - ARP? - follow-up

2001-01-17 Thread Bob Vance


I think that Peter Van Oene hit the nail on the head (and confirmed my
conclusion :) , so I thought that I'd share a couple of his thoughts.

   " ...  More specifically, which applications can work in a unicast
only
world?  Do you intend on statically mapping all your IP to MAC
relationships on node by node basis since ARP no longer works as a
discovery mechanism?

Thinking about this stuff leads to the understanding that
broadcasting
is a fundamental communication tool in today's networks and one
cannot
eliminate its use without creating a major disturbance.

Your understanding of VLAN'ing as a very simple technology is on the
money however.  Its simply a way to create two broadcast domains
where
there was previously one without additional replication of hardware
and
cabling.
   "

You know, it seems that broadcasting is a lot like friction --

We spend a lot of time trying to reduce it  ...
but we can't live without it !


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Tuesday, January 16, 2001 12:50 PM
To: CISCO_GroupStudy List (E-mail)
Subject: RE: why is routing needed with VLANs - ARP?


What I'm saying is that, before we implement VLANs, we have a flat
address space, with obviously, no routing.
Now, suppose that I arbitrarily decide not to forward broadcasts out
ports 6-10 through some IOS command.
Everything will still work quite happily (except anything relying on
those broadcasts, of course).
...
Ooops.   I think that I just saw the answer.

One of those broadcast thingys is lil' ole ARP.
So, how does a client find the IP address of a destination if the
destination is outside the VLAN?

It's funny that this wasn't pointed out in any of my VLAN reading
(admittedly limited to ICND coursebook and Caslow).
It just arbitrarily says unicasts are blocked or routing is
required without giving a reason.

Oh, well.


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Tuesday, January 16, 2001 11:35 AM
To: CISCO_GroupStudy List (E-mail)
Subject: why is routing needed with VLANs


OK.
I must be brain dead, today.
   (and, yes, Chuck, I *have* had my morning dose of Diet Coke :)
and, yes, I know, "What's so special about 'today' "?
   )
As far I can understand it so far, about the only benefit that I see
from VLANs is reducing the size of broadcast domains.

Suppose that I have a switch in the closet with one big flat address
space (well, it couldn't be that big with only one switch, now, could
it ?>).  Then someone says,
  "You know, we're getting a lot of blah-blah broadcast traffic.
   Let's VLAN.
  "
OK, fine.  We VLAN and put whatever services in each VLAN that are
required to handle the broadcasts (e.g., DHCP service).  So, now the
switch doesn't send broadcasts outside a particular VLAN.

But, what's so magic about a VLAN that the switch also decides not to
send unicasts outside a VLAN.   Before the VLANs, the switch maintained
a MAC table and knew which port to go out to get to any unicast address
in the entire space.  So, why can't it continue to do that after we
arbitrarily implement some constraint on broadcast addresses?
It seems to me that the same, exact MAC table, with an additional VLAN
field would not require that restriction.  If it's a broadcast, send the
packet only out ports with a VLAN-id that matches the source port's
VLAN-id.  If it's a unicast, handle it just like we used to.


Similarly, even if we have 5 switches, I just don't see the requirement
that we (as switch-code designers) must block unicasts and resort to a
routing requirement.

Even with 500 switches ... well, let's not get ridiculous :)


I feel that there is a simple point that I've overlooked, so I will
continue to RTFM while I await your responses.>)


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
===

RE: why is routing needed with VLANs

2001-01-17 Thread Bob Vance


And, I suppose (more idle speculation, Bob??) ...

If you had two sets of devices and no need for communication between
those sets, you could theoretically create 2 VLANs with addresses all
within the same subnet (ignoring any possible restrictions in a
particular piece of switch code).

Even then, you *would* be able even to talk TCP/IP between those VLANs,
if unicasts were forwarded by the switch outside the VLAN (and you were
willing to create manual, permanent ARP entries where needed) --
but, they're not.  BTW, is this a CISCO-specific implementation
or are there VLAN RFCs that prescribe necessary behavior.


-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Peter Van Oene
Sent: Wednesday, January 17, 2001 12:26 PM
To: [EMAIL PROTECTED]
Subject: RE: why is routing needed with VLANs


Just for clarity, VLAN's are a layer 2 concept and IP is of course a
layer 3 (please do not start with the "but what layer is arp again" :)

Despite subnets and VLAN's generally happening on a 1:1 basis in a lot
of theoretical and practical discussions, the two concepts are totally
unrelated and altogether unaware of each others presence.  An IP host
will not detect a node is on another VLAN and hence send to the gateway,
it will detect a node is on another subnet.  It doesn' t really care if
the node is in the same broadcast domain or halfway around the world, if
its not on the network, its sent via the gateway.  This is very strict
behavior.  Nodes on different IP subnets do not communicate directly in
any case without the use of an intermediary, layer 3 device.

VLANs as a concept are of trivial complexity.  VLAN membership,
particularly dynamic membership along with protocols like 802.1q, ISL,
PVST etc that leverage and support VLANs do offer some element of
challenge and opportunity for best practise designs.

I just felt that the line between VLANs (broadcast domains) and IP
subnets was getting somewhat blurry when it really shouldn't be.


_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: why is routing needed with VLANs

2001-01-17 Thread Bob Vance

Right.  It all depends on how the tables are managed and the particular
code implementing VLAN.  The ICND book specifically says unicasts are
*not* forwarded outside of the VLAN, so I conclude that my little
scenario obviously wouldn't work on a CISCO.

But, if the MAC tables *were* VLAN-commingled and forwarding outside
VLAN were permitted, it seems that it *could* work on a single switch.

E.g., if I, in VLAN2, send a packet with a destination MAC in VLAN3,
the switch *could* see which port the target MAC is on and forward it.
Now, if the target MAC weren't in the table at all, then it might
forward only out VLAN2 ports, so I couldn't initiate a conversation
until the switch actually learned which port this particular target is
on.  But if the switch *did* forward unknown-destination-MAC packets to
*all* unknown ports, even VLAN3, then 

Now, let's think about the above scenario with multiple switches and
trunking.

No.  Let's not ;>)

-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Peter Van Oene
Sent: Wednesday, January 17, 2001 3:59 PM
To: [EMAIL PROTECTED]
Subject: RE: why is routing needed with VLANs

In my experience, there exist some bridge table variations from vendor
to vendor that might impact on your unicast forwarding idea.  I'm not
positive what Cisco does and maybe someone can comment, but I have seen
many implementations that build separate MAC - Interface tables per
VLAN, thus fully isolation traffic from one VLAN to the other(s).

In theory, VLAN technology should involve complete separation of traffic
from VLAN to VLAN and not simply isolation of all 1's broadcasts.  I
expect this is exactly the case in most vendors implementations but
never really tried to verify it.  Keep in mind that again, VLAN
technology was not solely designed for IP networks.

To you point below, the 802.1d compliant switch is a layer 2 device and
does not decode layer 3 headers and thus it doesn't matter what
addresses (be they IP or otherwise) you assign to whatever devices you
chose to attach to it.  As far as documentation goes, I haven't seen
much outside of 802.1q document ion which exists I believe as a subset
of a revised 802.1d spec out of the IEEE.  The basic functionality to me
isn't reflective of something one would need a document for, given RFC's
and such are designed to enable multi vendor inter operability among
other things.

-pete

*** REPLY SEPARATOR  ***

On 1/17/2001 at 1:33 PM Bob Vance wrote:

>And, I suppose (more idle speculation, Bob??) ...
>
>If you had two sets of devices and no need for communication between
>those sets, you could theoretically create 2 VLANs with addresses all
>within the same subnet (ignoring any possible restrictions in a
>particular piece of switch code).
>
>Even then, you *would* be able even to talk TCP/IP between those VLANs,
>if unicasts were forwarded by the switch outside the VLAN (and you were
>willing to create manual, permanent ARP entries where needed) --
>but, they're not.  BTW, is this a CISCO-specific implementation
>or are there VLAN RFCs that prescribe necessary behavior.
>
>
>-
>Tks        | <mailto:[EMAIL PROTECTED]>
>BV     | <mailto:[EMAIL PROTECTED]>
>Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
>Vox 770-623-3430   11455 Lakefield Dr.
>Fax 770-623-3429   Duluth, GA 30097-1511
>=
>
>
>
>
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Peter Van Oene
>Sent: Wednesday, January 17, 2001 12:26 PM
>To: [EMAIL PROTECTED]
>Subject: RE: why is routing needed with VLANs
>
>
>Just for clarity, VLAN's are a layer 2 concept and IP is of course a
>layer 3 (please do not start with the "but what layer is arp again" :)
>
>Despite subnets and VLAN's generally happening on a 1:1 basis in a lot
>of theoretical and practical discussions, the two concepts are totally
>unrelated and altogether unaware of each others presence.  An IP host
>will not detect a node is on another VLAN and hence send to the
gateway,
>it will detect a node is on another subnet.  It doesn' t really care if
>the node is in the same broadcast domain or halfway around the world,
if
>its not on the network, its sent via the gateway.  This is very strict
>behavior.  Nodes on different IP subnets

RE: why is routing needed with VLANs - ARP?

2001-01-19 Thread Bob Vance


>What is the traditional
>way of moving 1 packet from a lan segment to
>another that doesnt share the same broadcast
>domain? (i.e. Not just connected by a bridge or
>layer 2 switch)
>Answer: Routing.

I know that you're speaking practically, but,
it's not evident, a priori, that
   " moving 1 packet from a lan segment to another
 that doesn't share the same broadcast domain ..
   "
*requires* routing.  And, in fact, it *doesn't* (at least in the sense
of IP routing.  Let's not get too far into the semantics of the word
"routing" ;>).

The whole point of my noodling, was "*Why* do we need the router."
It would certainly be a lot cheaper (cost and process) if we didn't
need one.


The answer is that limiting broadcasts limits practical communication
at the IP level because of IP address discovery (forgetting about all
other protocols), as you point out.  But, I contend that this is a
practical consideration, not theoretical.

For example, we *could*, of course, still have the possibility of
entering static ARP entries into two clients on different VLANs pointing
to each other in the same flat address space.
Then *if* the switch commingled VLAN MAC addresses *and* forwarded
inter-VLAN unicasts, *then* the 2 clients *could* talk.

In fact, it seems that if there were some kind of server process in each
VLAN that handled various broadcast requests, then the scenario *could*
work, generally, without a router.
Of course, we've just introduced another box/process, so what has been
gained ?>)

I dunno.  Just seems to me that the text books ought to point this out
and make the router requirement clearer.  Then, again, maybe I'm the
only one that didn't see the issue right away :)

This may be all just angels dancing on a pin, but thinking about the
why always makes me learn more.

One of my aphorisms is;

"If you learn the *why* of something, you'll never
 forget the *how* of it.
"

Oh, boy.  My kids, eyes are a-rollin', again :)


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-----Original Message-
From: Baety Wayne A1C 18 CS/SCBD [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 19, 2001 6:11 AM
To: 'Bob Vance'
Cc: CISCO_GroupStudy List (E-mail)
Subject: RE: why is routing needed with VLANs - ARP?


Because VLANs are what they are, virtual lans,
in other words many lan segments (self contained
broadcast domains).  We're trying to accomplish
something in software, which was traditionally
implemented physically.

The Question 2 you is...  What is the traditional
way of moving 1 packet from a lan segment to
another that doesnt share the same broadcast
domain? (i.e. Not just connected by a bridge or
layer 2 switch)

Answer: Routing.

Clients don't find IP address of other clients in
different broadcast domains.  To them, they simply
don't exist.  Only the common Router between them exists.
(Layer 2 is completely Ignorant of Layer 3). They only
ARP the IP address of the Router. Or should I say RARP.
They're usually configured with the gw IP already.

Wayne

-Original Message-
From: Bob Vance [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 17, 2001 2:50 AM
To: CISCO_GroupStudy List (E-mail)
Subject: RE: why is routing needed with VLANs - ARP?


What I'm saying is that, before we implement VLANs, we have a flat
address space, with obviously, no routing.
Now, suppose that I arbitrarily decide not to forward broadcasts out
ports 6-10 through some IOS command.
Everything will still work quite happily (except anything relying on
those broadcasts, of course).
...
Ooops.   I think that I just saw the answer.

One of those broadcast thingys is lil' ole ARP.
So, how does a client find the IP address of a destination if the
destination is outside the VLAN?

It's funny that this wasn't pointed out in any of my VLAN reading
(admittedly limited to ICND coursebook and Caslow).
It just arbitrarily says unicasts are blocked or routing is
required without giving a reason.

Oh, well.


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Tuesday, January 16, 2001 11:35 AM
To: CISCO_GroupStudy List (E-mail)
Subject: why is routing needed with VLANs


OK.
I mus

RE: How to configure bind with less than a block of ip's?

2001-01-20 Thread Bob Vance


It's helpful to realize that there's really nothing different between a
"forward" zone and a "reverse" zone.

The former *generally* contains A (address records) and latter
*generally* contains PTR records, but, both zones can and do carry other
record types (SOA and NS, obviously, but CNAMEs, etc., also) -- it's
all just DNS data.

The magic is in what the DNS clients do when they request a lookup.
Viz.:

To get an IP address, when presented with a "name", a DNS client does an
"A"-record lookup on the name given, and this causes the nameserver to
look in what we call the "forward zone" for an "A" record, but it's only
because that's what the client asked for.  E.g., when a client asks for
"a.b.c.com", the server ultimately looks in his "b.c.com" zone data and
we happen to call this the "forward zone".

But, when trying to look up a *name*, when presented with an IP address,
say "a.b.c.d", (which we call "reverse" lookup)
   (e.g., an 'rlogin' server trying to find out the name of the
client machine from which the login is occurring so that he,
the 'rlogin' server, can check that name in the ".rhosts" file
   ),
the DNS client (which is the 'rlogin' server code in this example :)
requests a lookup for a "PTR" record, "d.c.b.a.in-addr.arpa." .
   (Note that the above is generally hidden in library calls, e.g.,
gethostbyname and gethostbyaddr on Unix.
   )


All of that should pretty well be known, even by a newbie.


But, two major, non-obvious-to-the-newbie things, I think, that help
clear up the non-octet-reverse delegation are:

 1. valid CNAMEs can point to records *outside* the current zone
 foo.bar.com. IN A 1.2.3.4
 fubar.bar.com. CNAME yyy.yahoo.com.

 2. PTRs can have CNAMEs as well !
 4.3.2.1.in-addr.arpa.  IN  PTR  foo.bar.com.
 5.3.2.1.in-addr.arpa.  CNAME  fandoo.bar.com.
 6.3.2.1.in-addr.arpa.  CNAME  6.subxx.3.2.1.in-addr.arpa.
   (where fandoo.bar.com. and 6.subxx.3.2.1.in-addr.arpa.
would be PTR records in the bar.com and
subxx.3.2.1.in-addr.arpa zones, respectively.
   )

Your ISP is generally authoritative for the class C from which he has
parsimoniously given you a few addresses.
So he can handle the reverse PTRs for you -- if he wants to!!

If you are hosting your DNS, even though your ISP's kindly agreed to be
a secondary for your "forward" domain, he's not gonna want to be
bothered changing or adding PTR records while you can't decide on a good
name for one of your boxes.  So you really want to handle the reverse
yourself.  However, the ISP doesn't want to delegate to you the *whole*
class C in-addr.arpa domain (since there are other clients therein :).
However, he *can* delegate a *sub-domain* of the class C
in-addr.arpa to you, (since he's authoritative for the parent).

Then he can put CNAMEs in his parent pointing to the PTRs in
the sub-domain he delegated to you!

So, he is still authoritative for 3.2.1.in-addr.arpa, but has delegated
to you, say "hoohah.3.2.1.in-addr.arpa", which is a valid sub-domain of
"3.2.1.in-addr.arpa" .

Then he has
  1.3.2.1.in-addr.arpa.  CNAME  1.hoohah.3.2.1.in-addr.arpa.
 ...
  6.3.2.1.in-addr.arpa.  CNAME  6.hoohah.3.2.1.in-addr.arpa.

(or
  1CNAME  1.hoohah.3.2.1.in-addr.arpa.
 ...
  6CNAME  6.hoohah.3.2.1.in-addr.arpa.
since the ORIGIN, ".hoohah.3.2.1.in-addr.arpa. " will be appended to
those non-dot-terminated names.
And, probably done with a
  $GENERATE 1-6 $  CNAME $.hoohah.3.2.1.in-addr.arpa.
)

You are authoritative for "hoohah.3.2.1.in-addr.arpa" (since the ISP
delegated it to you) and in the zone master file for that domain, you
have:
  1.hoohah.3.2.1.in-addr.arpa.IN  PTR  www.bar.com.
  4.hoohah.3.2.1.in-addr.arpa.IN  PTR  foo.bar.com.
(or
  1IN  PTR  www.bar.com.
  4IN  PTR  foo.bar.com.
)
or whatever.
It doesn't really matter that you don't have the other records.

When a DNS client wants to do a reverse lookup on 1.2.3.4, he will
do a PTR request for 4.3.2.1.in-addr.arpa.
It will be found that the ISP is authoritative for 3.2.1.in-addr.arpa
and he will be queried for 4.3.2.1.in-addr.arpa.
But the CNAME will point to 4.hoohah.3.2.1.in-addr.arpa for which
you are authoritative and you'll be queried for it and will return
"foo.bar.com".
Voila!

Of course, the ISP will probably not call the sub-domain "hoohah", but
"0-7" or "sub-0-7" or "subnet-0" or "0/29" or something more meaningful.


I'm sure that the gurus will find and fill holes in the above, but
it should clarify things for you a bit.


-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Alexandra
Sent: Friday, January 19, 2001 9:50

CCNA 2 and subnets

2001-01-22 Thread Bob Vance


Sorry for the lame question, but I gotta know :|

We know that subnet -1 (all ones) is valid to config in IOS and that 0
is OK with

ip subnet-zero.

For purposes of CCNA 2, do we assume that subnet 0 and -1 are valid,
vs. CCNA 1 (where they were not) for questions like,
   "How many subnets can we have with this mask?
   "
?
Does the test make it clear in preliminary text?

The archives seem to have conflicting answers.

The Cisco Press ICND book (McQuerry, 1-57870-111-2) doesn't address the
issue head on, but simply shows tables with (2^(n-1))-2 subnets.

The Cisco Press 640-507 Cert Guide (Odom, 0-7357-0971-8) clearly says
that 2^(n-1) is correct and yet points out that 0 is only valid with
"ip subnet-zero" !

Does anyone know the *definitive* answer for CCNA 2.0 ?


-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=




_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: CCNA 2 and subnets

2001-01-23 Thread Bob Vance


Yarrggh!
Of course, that's

   (2^n)   (*not*   2^(n-1) )

Maybe there *is* something to that aspartame story ;>)

-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bob Vance
Sent: Monday, January 22, 2001 10:35 PM
To: CISCO_GroupStudy List (E-mail)
Subject: CCNA 2 and subnets


Sorry for the lame question, but I gotta know :|

We know that subnet -1 (all ones) is valid to config in IOS and that 0
is OK with

ip subnet-zero.

For purposes of CCNA 2, do we assume that subnet 0 and -1 are valid,
vs. CCNA 1 (where they were not) for questions like,
   "How many subnets can we have with this mask?
   "
?
Does the test make it clear in preliminary text?

The archives seem to have conflicting answers.

The Cisco Press ICND book (McQuerry, 1-57870-111-2) doesn't address the
issue head on, but simply shows tables with (2^(n-1))-2 subnets.

The Cisco Press 640-507 Cert Guide (Odom, 0-7357-0971-8) clearly says
that 2^(n-1) is correct and yet points out that 0 is only valid with
"ip subnet-zero" !

Does anyone know the *definitive* answer for CCNA 2.0 ?


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: But isn't that the routers job???

2001-01-23 Thread Bob Vance


LOL.
You're right, it *is* an interesting way to phrase it.

>"... doing route lookups for every packet that comes in the router."
>Correct me if I'm wrong but isn't that what a routers supposed to do???

Actually, metaphysically speaking, I'd say, "No!"
The router's main job is to send the packet to the next hop in the best
path to the destination.  So, "doing route lookups" is not his *job*,
but if that's what he has to do, then it happens as a by product.  If he
can do his job without a route-table lookup, then so much the better,
freeing him up to handle other packets that do need a lookup, or
maintain the route table in a timely manner -- or make that new pot of
coffee.

Maybe,
   "... the RP is free to use valuable CPU time on more important
things than doing route-table lookups for packets that don't
need a lookup; like doing lookups for packets that *do* need
a lookup :)
   "


-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, January 22, 2001 11:05 PM
To: [EMAIL PROTECTED]
Subject: But isn't that the routers job???


Hey Group,
 Me again. I'm reading for my CIT and am at the section where it
goes
into detail of the various switching methods in the router (i.e.,
silicon,
CEF, autonomous, etc.) I understand how all this works and understand
how the
SP takes a lot of the stress away from the RP and this is good because
your
avoiding bogging the RP/CPU down. I have a problem with these statements
though and want some clarification...

Taken form the book (Lammle's CIT p. 173):

 "This is just another reason why switching is such a good practice.
Why
burden the RP with every packet if it's not necessary? By using
switching
methods, the RP is free to use valuable CPU time on more important
things
than doing route lookups for every packet that comes in the router."

Correct me if I'm wrong but isn't that what a routers supposed to do???
What
else does the RP have to do that is more important than ROUTING? I may
be
overanalyzing this but it just seems that he's saying that the RP has
better
things to do like make coffee, rather than route.

Basically, could somebody give me a list of some other things the RP/CPU
has
to do other than route lookups...(I know there are access-lists and
other CPU
things here, I just would like a solid list to remember). Thanks team,

Mark Zabludovsky ~ CCNA, CCDA, 3/4-NP
[EMAIL PROTECTED]

 "Even if I knew I had only 1 more week to live, I would still
schedule
my CCIE lab. I would just have to work a little harder I guess. After
all,
without any goals in life, I'm dead already."
   ~Mark
Zabludovsky~

_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: CCNA 2 and subnets

2001-01-23 Thread Bob Vance


Thanks.
I think that I pretty well understand the technical aspects.
I know that I can use subnet -1 and subnet 0 in a Cisco environment
(with "ip subnet-zero").

My question was of a practical nature:

   Does the CCNA 2.0 certification test assume that we can use 0 and -1
   or does it assume that we cannot.

E.g., if encountered on the CCNA 2.0 cert test, what is the answer to
the following question:

   Given the Class C network, 192.168.1.0, what mask is needed to
   provide for 7 subnets?

The "real" answer (in the sense of what could be configured on the Cisco
routers and irrespective of any restrictions that hosts on those subnets
might have) would be 255.255.255.224, even without "ip subnet-zero".

The CCNA 1.0 answer would have been

255.255.255.240

What is the answer expected by CCNA 2.0 ? (Or maybe they scrupulously
avoid those particular questions :)

And, as I said, the ICND book still subtracts 2.

-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Brian Lodwick
Sent: Tuesday, January 23, 2001 1:17 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: CCNA 2 and subnets


Bob,
  Howard answered this question for me a while back so I'll try to
answer it
for you now. This question is probobaly more in depth than you realize,
but
the question comes down to why did they used to say the equation for
finding
the amount of valid subnets is 2^#of hosts -2? And why now do we not -2?
Well the short answer is -we used to use Classfull addressing. With
classfull the reason we used the -2 was because it was a bad idea to use
the
all 0's or all 1's subnets(highly discouraged is I believe the
terminology)When an all 0's subnet update was sent to a classfull router
it
would not be able to decipher it from the entire network. This is
because in
clasfull the masks aren't sent with the updates therefore when the
classfull
mask is placed on say 192.168.0.0/28 it would change it to /24 because
again
the mask wasn't sent. Which would end up causing some issues obviously.
The
other one was the all 1's subnets. I'll just make an example. If you
think
along the same lines as the all 0's. Again in a classfull environment a
broadcast for a particular subnet would be interpreted as a broadcast
for
the entire network. 192.168.0.255/28 has different meaning than
192.168.0.255/24.
3Coms website has the best explaination I have found The article is
called:
Understanding IP addressing: Everything You Ever Wanted To Know by Chuck
Semeria.
Cisco, Microsoft, and the RFC's seem to dance around the topic.

>>>Brian


>From: "Bob Vance" <[EMAIL PROTECTED]>
>Reply-To: "Bob Vance" <[EMAIL PROTECTED]>
>To: "CISCO_GroupStudy List \(E-mail\)" <[EMAIL PROTECTED]>
>Subject: RE: CCNA 2 and subnets
>Date: Tue, 23 Jan 2001 08:24:37 -0500
>
>Yarrggh!
>Of course, that's
>
>(2^n)   (*not*   2^(n-1) )
>
>Maybe there *is* something to that aspartame story ;>)
>
>-
>Tks        | <mailto:[EMAIL PROTECTED]>
>BV     | <mailto:[EMAIL PROTECTED]>
>Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
>Vox 770-623-3430   11455 Lakefield Dr.
>Fax 770-623-3429   Duluth, GA 30097-1511
>=
>
>
>
>
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Bob Vance
>Sent: Monday, January 22, 2001 10:35 PM
>To: CISCO_GroupStudy List (E-mail)
>Subject: CCNA 2 and subnets
>
>
>Sorry for the lame question, but I gotta know :|
>
>We know that subnet -1 (all ones) is valid to config in IOS and that 0
>is OK with
>
> ip subnet-zero.
>
>For purposes of CCNA 2, do we assume that subnet 0 and -1 are valid,
>vs. CCNA 1 (where they were not) for questions like,
>"How many subnets can we have with this mask?
>"
>?
>Does the test make it clear in preliminary text?
>
>The archives seem to have conflicting answers.
>
>The Cisco Press ICND book (McQuerry, 1-57870-111-2) doesn't address the
>issue head on, but simply shows tables with (2^(n-1))-2 subnets.
>
>The Cisco Press 640-507 Cert Guide (Odom, 0-7357-0971-8) clearly says
>that 2^(n-1) is correct and yet points out that 0 is only valid with
>"ip subne

RE: CCNA 2 and subnets - Yikes

2001-01-23 Thread Bob Vance


Yikes !!!

>For CCNA 2.0 exam x^2 -1 is the correct answer.

So, you're saying that subnet -1 (all ones) is assumed to be allowed
(which is true for Cisco routers), and subnet 0 is *not*, in the absence
an explicit "ip subnet-zero".

That's worse than I thought (or better, since it's correct ;>) !!!


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Gopinath Pulyankote
Sent: Tuesday, January 23, 2001 6:01 PM
To: [EMAIL PROTECTED]
Subject: Re: CCNA 2 and subnets


For CCNA 2.0 exam x^2 -1 is the correct answer. I did get a question on
the
similar lines & I answered it based on this, it must be correct since I
got
a 100% for that topic.


""Bob Vance"" <[EMAIL PROTECTED]> wrote in message
002d01c08573$2af4e680$[EMAIL PROTECTED]">news:002d01c08573$2af4e680$[EMAIL PROTECTED]...
> Thanks.
> I think that I pretty well understand the technical aspects.
> I know that I can use subnet -1 and subnet 0 in a Cisco environment
> (with "ip subnet-zero").
>
> My question was of a practical nature:
>
>Does the CCNA 2.0 certification test assume that we can use 0
and -1
>or does it assume that we cannot.
>
> E.g., if encountered on the CCNA 2.0 cert test, what is the answer to
> the following question:
>
>Given the Class C network, 192.168.1.0, what mask is needed to
>provide for 7 subnets?
>
> The "real" answer (in the sense of what could be configured on the
Cisco
> routers and irrespective of any restrictions that hosts on those
subnets
> might have) would be 255.255.255.224, even without "ip subnet-zero".
>
> The CCNA 1.0 answer would have been
>
> 255.255.255.240
>
> What is the answer expected by CCNA 2.0 ? (Or maybe they scrupulously
> avoid those particular questions :)
>
> And, as I said, the ICND book still subtracts 2.
>
> -
> Tks | <mailto:[EMAIL PROTECTED]>
> BV | <mailto:[EMAIL PROTECTED]>
> Sr. Technical Consultant, SBM, A Gates/Arrow Co.
> Vox 770-623-3430 11455 Lakefield Dr.
> Fax 770-623-3429 Duluth, GA 30097-1511
> =
>
>
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Brian Lodwick
> Sent: Tuesday, January 23, 2001 1:17 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: CCNA 2 and subnets
>
>
> Bob,
>   Howard answered this question for me a while back so I'll try to
> answer it
> for you now. This question is probobaly more in depth than you
realize,
> but
> the question comes down to why did they used to say the equation for
> finding
> the amount of valid subnets is 2^#of hosts -2? And why now do we
not -2?
> Well the short answer is -we used to use Classfull addressing. With
> classfull the reason we used the -2 was because it was a bad idea to
use
> the
> all 0's or all 1's subnets(highly discouraged is I believe the
> terminology)When an all 0's subnet update was sent to a classfull
router
> it
> would not be able to decipher it from the entire network. This is
> because in
> clasfull the masks aren't sent with the updates therefore when the
> classfull
> mask is placed on say 192.168.0.0/28 it would change it to /24 because
> again
> the mask wasn't sent. Which would end up causing some issues
obviously.
> The
> other one was the all 1's subnets. I'll just make an example. If you
> think
> along the same lines as the all 0's. Again in a classfull environment
a
> broadcast for a particular subnet would be interpreted as a broadcast
> for
> the entire network. 192.168.0.255/28 has different meaning than
> 192.168.0.255/24.
> 3Coms website has the best explaination I have found The article is
> called:
> Understanding IP addressing: Everything You Ever Wanted To Know by
Chuck
> Semeria.
> Cisco, Microsoft, and the RFC's seem to dance around the topic.
>
> >>>Brian
>
>
> >From: "Bob Vance" <[EMAIL PROTECTED]>
> >Reply-To: "Bob Vance" <[EMAIL PROTECTED]>
> >To: "CISCO_GroupStudy List \(E-mail\)" <[EMAIL PROTECTED]>
> >Subject: RE: CCNA 2 and subnets
> >Date: Tue, 23 Jan 2001 08:24:37 -0500
> >
> >Yarrggh!
> >Of course, that's

RE: Zone Delegation/Reverse Delegation

2000-09-18 Thread Bob Vance


The reverse delegation is done by whomever has been delegated authority
for the parent of the reverse domain, just like for the forward
domains.
E.g., whoever has authority for xxx.yyy (yyy.xxx.in-addr.arpa domain)
will delegate authority for any xxx.yyy.nnn.
After all,
nnn.yyy.xxx.in-addr.arpa
is simply a sub-domain of
yyy.xxx.in-addr.arpa
just like
foo.bar.com
is a sub-domain of
bar.com.
Once you have authority for a domain, you can delegate sub-domains
at your whim.
Typically, your ISP would have authority for your reverse parent.
If the ISP is hosting your DNS, then they would retain authority
for both the forward and the reverse domains.
You say that *you* created a sub-domain.  That means that you have the
ability to change the zone data on their server.  But you cannot
arbitrarily start using a new range of IP addresses.  You have been
assigned a range of IPs by your ISP, and you must stay within that
range.  Thus, whoever is authoritative for that range would have to
add the PTR records for your host.  Most likely it's the ISP, and it
would seem that you should also have the ability to set up the reverse
PTRs yourself.


-
Tks        | 
BV     | 
Senior Tech. Consultant,   SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Benny Leong (HTHK - Senior Engineer II - iServices Development, NNSD)
Sent: Monday, September 18, 2000 1:55 AM
To: '[EMAIL PROTECTED]'
Subject: FW: Zone Delegation/Reverse Delegation


It seems that I cannot post message.  This is to re-send the same mail
message.

I have 2 T1 connected to 2 separate ISPs.   The DNS is being hosted on one
ISP.  Now, I have created a subdomain.  Is the zone delegation done at the
ISP and the reverse delegation done at the APNIC ?

**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Zone Delegation/Reverse Delegation

2000-09-20 Thread Bob Vance


Did you ever get this reply?

-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-----
From: Bob Vance
Sent: Tuesday, September 19, 2000 12:00 AM
To: clst
Cc: Benny Leong (HTHK - Senior Engineer II - iServices Development,
NNSD)
Subject: RE: Zone Delegation/Reverse Delegation


If the ISP is authoritative for "bar.com", then you cannot create the
sub-domain "foo.bar.com".  The administrator of whichever system is
authoritative for "bar.com" would create it and delegate authority for
it to your local DNS host.


>I don't understand why the DNS delegation is done by ISP but the
>reverse delegation is done by APNIC.

That's just the way delegation works.  Only the authority for a
domain can create a sub-domain of that domain (reverse domains are
valid domains just like "forward" ones are) and then, possibly,
delegate authority for it to some other nameserver.

Perhaps looking at the details will help:

I am "ns1.bar.com" and am the primary (the source data files for the
zone are most likely on me) nameserver for bar.com.
Here is the data for bar.com (the authority for this zone was delegated
to me by the authority for ".com"):

$ORIGIN bar.com.
@IN SOA ..
 IN NS ns1.bar.com. ; these records match
 IN NS ns.xyz.isp.com.  ; the records in .com
ns1  IN A  206.222.111.11   ; that delegate bar.com to me
www  IN A  206.222.111.17
ftp  IN A  206.222.111.18
$ORIGIN foo.bar.com.  ; here is a sub-domain that I create
pluto   IN A  206.222.166.31  ; but I'm still the authority for it
goofy   IN A  206.222.166.31  ; so I create the records and maintain
donald  IN A  206.222.166.31  ; the zone data for it

At some point there are just too many hosts and too much work to
maintain the sub-domain data, so I decide to *delegate* authority
to another server in our company and let them do the work.

The sub-domain data changes thusly:

$ORIGIN foo.bar.com.  ; here is a sub-domain that I create
IN NS pluto   ; but "pluto" will be the authority for it
pluto   IN A  206.222.166.31  ;  the appearance of the NS record is the
  ; delegation and this is known as a
  ; "zone cut"

Now, "pluto" can be the primary nameserver for foo.bar.com and have zone
data for it.


OK.
The *same* hold true for the reverse delegation.
If "ns1.bar.com" is to be authoritative for
111.222.206.in-addr.arpa
then whoever is authoritative for
222.206.in-addr.arpa
would have a zone cut at
111.222.206.in-addr.arpa
and delegate authority for it to "ns1.bar.com"

$ORIGIN 111.222.206.in-addr.arpa   ; here is the sub-domain
IN NS ns1.bar.com  ; and I'm now the authority

Normally, you ISP would be authoritative for 111.222.206.in-addr.arpa,
but maybe not.  In any case, only that authority can delegate
authority for 111.222.206.in-addr.arpa to you.

Talk to your ISP about this -- they should be able to tell you whom to
contact to get the reverse sub-domain delegated to you.




-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Senior Tech. Consultant,   SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: Benny Leong (HTHK - Senior Engineer II - iServices Development,
NNSD) [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 18, 2000 10:29 PM
To: 'Bob Vance'
Subject: RE: Zone Delegation/Reverse Delegation


Hi Bob,

I need further explanation from you :

The DNS of the domain, bar.com, is hosted by an ISP.
We have applied a range of IP address and AS# from APNIC.
We have created our sub-domain, say, foo.bar.com.   The DNS server of
this
subdomain is hosted by ourselves.

I don't understand why the DNS delegation is done by ISP but the reverse
delegation is done by APNIC.

Regards, Benny

--
From:  Bob Vance [SMTP:[EMAIL PROTECTED]]
Sent:  Monday, September 18, 2000 8:41 PM
To:  CISCO_GroupStudy List (E-mail)
Cc:  'Benny Leong (HTHK - Senior Engineer II - iServices
Development, NNSD)'
Subject:  RE: Zone Delegation/Reverse Delegation

The reverse delegation is done by whomever has been delegated
authority
for the parent of the reverse domain, just like for the forward
domains.
E.g., whoever has authority for xxx.yyy (yyy.xxx.in-addr.arpa
do

RE: IP Classless Revisited (More info)

2001-03-26 Thread Bob Vance


Bug? -- or "feature" as you say :)
What was really telling to me was when you added the static default
route on top of the OSPF-installed default.  The higher admin distance
made the static route be preferred and the routing process behaved
"normally" ("classfully").

Perhaps the feature is :
   Hmmm. I see this OSPF installed route.  I guess he *really* wants to
run
   classlessly, else he'd be running some older protocol !

But you'd think that the code never even gets to any the supernet of
10.5.0.0.
It would really have to be written in to look for OSPF routes before
behaving classfully.

I wonder what would happen if you advertised 8.0.0.0 (being a "supernet
of 10.0.0.0)  from C instead of 0.0.0.0 :)  -- to see if it's a general
behavior or specifically looking for 0.0.0.0.

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Sunday, March 25, 2001 1:32 PM
To: Vincent
Cc: [EMAIL PROTECTED]
Subject: Re: IP Classless Revisited (More info)


Metric shouldn't have anything to do with it.  Whether I'm using RIP or
OSPF
the default route is being added to the routing table of the hub router.
The issue is that with no ip classless configured, the hub router should
NOT
ever pick the default route when trying to reach unknown subnets of the
10.x.x.x network.

In my case, when RIP installed the default route it behaves correctly.
When
OSPF installed the route it behaved as if 'ip classless' were
configured.

Very odd.

John

>  I guess in faovour of metric.
>
>  "John Neiberger" <[EMAIL PROTECTED]> ¼¶¼g©ó¶l¥ó
>  [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>  > Okay, I just tried this with RIP advertising the default route and
I'm
>  even
>  > more confused!  Now, it behaves as I would expect.  With no ip
classless,
>  > pings to unknown 10.x.x.x subnets are unroutable even though there
is a
>  > default route in the routing table.
>  >
>  > With no ip classless, why does my router take the default route
when it
>  was
>  > installed by OSPF but not when it was installed by RIP?  I would
expect
it
>  > to never take the default route for 10.x.x.x addresses with no ip
>  classless.
>  >
>  > This really concerns me because I was taking a practice CCIE
written
exam
>  a
>  > few days ago and ran across a question like this and I answered the
>  question
>  > assuming normal behavior of no ip classless and got it right.  Now
I'm
>  > thinking there are some more twists to its behavior that i'm not
aware
of.
>  >
>  > John
>  >
>  > >  Sure, I'll try that but I don't see why it should matter.  As I
>  > understand
>  > >  it, ip classless affects routing table lookups only and it
doesn't
care
>  > how
>  > >  those routes were installed into the table.
>  > >
>  > >  Although, given this behavior, my assumption might be wrong.
>  > >
>  > >  Thanks,
>  > >  John
>  > >
>  > >  >  John,
>  > >  >  Interesting.  I think this is due to OSPF, not redistribution
>  problem.
>  >
>  > >  Can you try running RIP instead of OSPF ?
>  > >  >
>  > >  >  Cheers,
>  > >  >  YY
>  > >  >
>  > >  >
>  > >  >
>  > >  >  -Original Message-
>  > >  >  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf
>  Of
>  > >  >  John Neiberger
>  > >  >  Sent: Sunday, March 25, 2001 5:28 AM
>  > >  >  To: [EMAIL PROTECTED]
>  > >  >  Subject: IP Classless Revisited (this is just odd...)
>  > >  >
>  > >  >
>  > >  >  Ok, just when you thought it was safe to go back in the
water
Or
>  > >  should
>  > >  >  I say, just when I thought I understood the behavior of 'ip
>  classess'
>  > and
>  > >  >  'no ip classless'  Let me summarize my lab setup.
>  > >  >
>  > >  >  RouterA-RouterB--RouterC
>  > >  >
>  > >  >  Pretty simple.  AtoB is 10.1.1.0/24, BtoA is 10.1.2.0/24.
OSPF
is
>  > >  running
>  > >  >  on both links.  'ip classless' is on A and C, but not B
initially.
>  On
>  > B
>  > >  I
>  > >  >  see these routes:
>  > >  >
>  > >  >   10.0.0.0/24 is subnetted, 2 subnets
>  > >  >  C   10.1.2.0 is directly connected, Serial1
>  > >  >  C   10.1.1.0 is directly connected, Serial0
>  > >  >
>  > >  >  That's what I expect to see.  Then I add a default route on
B,
'ip
>  > route
>  > >  >  0.0.0.0 0.0.0.0 10.1.1.2'.  With no ip classless configured,
any
>  > packets
>  > >  to
>  > >  >  unknown subnets of 10.0.0.0/8 should be dropped.  I tested it
and
>  that
>  > is
>  > >  >  the case.  With 'ip classless' configured, and unknown
packets
>  > regardless
>  > >  of
>  > >  >  major network get routed to 10.1.1.2.
>  > >  >
>  > >  >  Now here is what I don't understand.  Let's turn off ip
classless
on
>  B
>

RE: OSPF overrides "no ip classless"

2001-03-28 Thread Bob Vance


John, did you ever try distributing route for 8.0.0.0 instead of 0.0.0.0
to see whether it was true for all routes or just the clammy "normal",
"default" default route :)  ?

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Tuesday, March 27, 2001 11:19 PM
To: [EMAIL PROTECTED]
Subject: OSPF overrides "no ip classless"


If you recall our recent thread on this, I was noticing that when ospf
would
advertise a default route to another router, the receiving router would
start to behave classlessly even if 'no ip classless' was in the
configuration.  This behavior was not seen with eigrp, rip v1, rip v2,
igrp,
or eigrp; only with ospf.  This goes against everything I've read about
the
differences between 'ip classless' and 'no ip classless'.

I initially came to the conclusion that it was a 'feature' of that
particular IOS release.  Well, I've done some testing with two different
features sets of 11.2(25) on a 4000, and I just tested it again on a
2500
running 12.0(16).  The same thing happened!

Someone out there, puhleez explain to me why OSPF is overriding that
command.  Shouldn't we be able to leave 'no ip classless' configured if
we
feel like it?  I'm not sure why I'd feel like it, I'm just wondering.

Try this out.  Connect two routers back to back, A to B.  Run anything
but
OSPF between them at first, and set 'no ip classless' on router B.
Configure A to originate a default route.  When you see that the gateway
of
last resort is set on B, try to ping A.  That should work just fine.
Now
try to ping some other unknown subnet of whatever address space you're
using.  For instance, if your A to B link is 10.1.1.0/24, try to ping
10.50.1.1.  You should see five timeouts.  If you turn on ip packet
debugging, you'll see that the packets were unroutable.

Now configure 'ip classless' on router B and try the ping again.  You
will
receive destination unreachable messages from A instead of the timeouts.
Debugging will report that they were forwarded to A, as expected.  Now
configure 'no ip classless' on B again.

Remove that routing protocol and run OSPF.  When you see the GOLR set on
router B, try to ping an unknown subnet again.  This time it will behave
as
if 'ip classless' were configured.  Debugging will show that it WAS
routable, even though 'no ip classless' will still be in the
configuration.

Why is this happening?  I don't recall seeing this behavior documented.
Someone please confirm my findings (and my sanity) or at least point out
where my thinking is flawed.  

Thanks!

John





___
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/


_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: OSPF overrides "no ip classless"

2001-03-28 Thread Bob Vance


And 8.0.0.0 is in that magic "in-between" place of being a supernet but
not the "normal" default route.


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: John Neiberger [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 28, 2001 5:06 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: OSPF overrides "no ip classless"


Now that I think about it, I believe I did try 10.0.0.0/8 and it still
behaved classfully, even running OSPF.  I'll try it again to make sure,
though.  I'm only 30 and my memory is already failing me.  

John

>>> "Bob Vance" <[EMAIL PROTECTED]> 3/28/01 8:34:49 AM >>>
John, did you ever try distributing route for 8.0.0.0 instead of
0.0.0.0
to see whether it was true for all routes or just the clammy "normal",
"default" default route :)  ?

-
Tks| <mailto:[EMAIL PROTECTED]>
BV | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Tuesday, March 27, 2001 11:19 PM
To: [EMAIL PROTECTED]
Subject: OSPF overrides "no ip classless"


If you recall our recent thread on this, I was noticing that when ospf
would
advertise a default route to another router, the receiving router
would
start to behave classlessly even if 'no ip classless' was in the
configuration.  This behavior was not seen with eigrp, rip v1, rip v2,
igrp,
or eigrp; only with ospf.  This goes against everything I've read
about
the
differences between 'ip classless' and 'no ip classless'.

I initially came to the conclusion that it was a 'feature' of that
particular IOS release.  Well, I've done some testing with two
different
features sets of 11.2(25) on a 4000, and I just tested it again on a
2500
running 12.0(16).  The same thing happened!

Someone out there, puhleez explain to me why OSPF is overriding that
command.  Shouldn't we be able to leave 'no ip classless' configured
if
we
feel like it?  I'm not sure why I'd feel like it, I'm just wondering.

Try this out.  Connect two routers back to back, A to B.  Run anything
but
OSPF between them at first, and set 'no ip classless' on router B.
Configure A to originate a default route.  When you see that the
gateway
of
last resort is set on B, try to ping A.  That should work just fine.
Now
try to ping some other unknown subnet of whatever address space you're
using.  For instance, if your A to B link is 10.1.1.0/24, try to ping
10.50.1.1.  You should see five timeouts.  If you turn on ip packet
debugging, you'll see that the packets were unroutable.

Now configure 'ip classless' on router B and try the ping again.  You
will
receive destination unreachable messages from A instead of the
timeouts.
Debugging will report that they were forwarded to A, as expected.  Now
configure 'no ip classless' on B again.

Remove that routing protocol and run OSPF.  When you see the GOLR set
on
router B, try to ping an unknown subnet again.  This time it will
behave
as
if 'ip classless' were configured.  Debugging will show that it WAS
routable, even though 'no ip classless' will still be in the
configuration.

Why is this happening?  I don't recall seeing this behavior
documented.
Someone please confirm my findings (and my sanity) or at least point
out
where my thinking is flawed.  

Thanks!

John





___
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/


_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]


_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]




_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: UPDATE: OSPF overriding 'no ip classless'

2001-03-29 Thread Bob Vance


Interesting :)
And, of course, if it were a designed feature, it should be documented.
Someone should call this in.



-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Thursday, March 29, 2001 12:23 AM
To: [EMAIL PROTECTED]
Subject: UPDATE: OSPF overriding 'no ip classless'


Okay, here are my latest findings.  Bob and others wanted me to try
various
supernet routes to see how the routers reacted.  Well, I did, and the
router
with 'no ip classless' is definitely behaving classlessly when OSPF is
running.

First, a recap.  I have router A connected to router B and am running
OSPF.
Router A is originating a default route, and Router B has 'no ip
classless'
configured.  The prefix for the link is 10.1.1.0/24.

By all official explanations of 'no ip classless', in this scenario if I
tried to ping an unknown subnet of 10.0.0.0/8, it would fail and
debugging
would show that the packets were unroutable.  This is true when I used
RIP
v1, RIP v2, IGRP, and EIGRP.  However, when I use OSPF it's a whole
'nuther
story!  It shouldn't matter how the routes are installed, but for some
reason, Router B behaves as if 'ip classless' were configured if I run
OSPF.

Tonight, I first tried the original experiment and originated 0.0.0.0/0.
Router B behaved classlessly and would route packets for ANY destination
to
Router A.

Next, I tried redistributing the static route for 10.0.0.0/8.  Packets
for
any subnet of 10.0.0.0/8 would be routed, all other destinations would
fail.
Again, classless behavior.

Thirdly, I redistributed a route for 8.0.0.0/5 just for grins.  Packets
destined for anything in that range were routed (8.0.0.0/8 throught
11.0.0.0/8) but all other unknown subnets failed.

Ah!!  I've tried this on two different routers and three different
IOS
versions and I get the same results.  Where is it written that when OSPF
is
running that the router will now behave classlessly in spite of 'no ip
classless' being in the configuration?

I guess I have no problem with this, I just wish they would document it
somewhere.  If someone would like to try these tests to verify the
results
I'd appreciate it.  I'd love to get some verification so I know I'm not
just
losing my mind.

Thanks!
John





___
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/


_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: FW: UPDATE: OSPF overriding 'no ip classless'

2001-03-29 Thread Bob Vance


Excellent !!
This is like the Energizer Bunny!

Hmmm.
You already tested adding a static default route (with lower admin
distance) and it changed the classless behavior, right?
Then you deleted the static and classless returned.

Just for completeness :) , it might be mildly interesting to add the
static with a higher admin than OSPF -- it won't show up in the routing
table and thus it shouldn't change the classless behavior like the lower
admin one did -- or would it ;>)
Also, allow OSPF also to advertise the default, along with RIP, and see
that since the OSPF route is in the table, it still subverts to
classless even though it knows that it also received a RIP route that it
is currently ignoring.

-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Thursday, March 29, 2001 10:16 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: FW: UPDATE: OSPF overriding 'no ip classless'


Well, there are two different issues.  You're talking about the way the
routing protocols themselves behave: whether they pass subnet mask
information or not.  The issue here is routing table lookups, not how
those routes are installed.

With 'no ip classless' configured, even if there is a valid supernet
route in the routing table--including a 0.0.0.0/0 default route--the
router should not choose it.  For some reason, at least on my routers,
if OSPF is running it changes this behavior.

This is pretty odd.  To be consistent Cisco should cause the
configuration to change to 'ip classless' when an OSPF process is
configured.

Hey, here's something I didn't try!  Someone should do this during the
day since I won't be able to do it until tonight.  Run OSPF *and*
another routing protocol, let's say RIP, but use RIP to advertise the
default route, not OSPF.  That would be an interesting test to see if
the router is behaving classlessly only for OSPF-learned routes or if it
really makes the router become completely classless.

Okay, I need to get started on my coffee.  

John

>>> "Stull, Cory" <[EMAIL PROTECTED]> 3/29/01 7:50:04 AM >>>
John,

I haven't followed this as closely as I should have before answering
but I
hope I am guessing correctly here...  OSPF sends the subnet
information
along with it when it does its routing updates, the only way to have
it
behave classfully is to manually summarize.  The reason the other
protocols
were working the way they were is because they either A) don't send
subnet
information in the updates or B) were autosummarizing at the classful
network boundary like EIGRP does.

Am I way off base here?   I'm working on an OSPF type lab right now too
so
let me know.

Cory

-Original Message-
From: Bob Vance [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 29, 2001 8:22 AM
To: CISCO_GroupStudy List (E-mail)
Subject: RE: UPDATE: OSPF overriding 'no ip classless'


Interesting :)
And, of course, if it were a designed feature, it should be
documented.
Someone should call this in.



-
Tks| <mailto:[EMAIL PROTECTED]>
BV | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Thursday, March 29, 2001 12:23 AM
To: [EMAIL PROTECTED]
Subject: UPDATE: OSPF overriding 'no ip classless'


Okay, here are my latest findings.  Bob and others wanted me to try
various
supernet routes to see how the routers reacted.  Well, I did, and the
router
with 'no ip classless' is definitely behaving classlessly when OSPF is
running.

First, a recap.  I have router A connected to router B and am running
OSPF.
Router A is originating a default route, and Router B has 'no ip
classless'
configured.  The prefix for the link is 10.1.1.0/24.

By all official explanations of 'no ip classless', in this scenario if
I
tried to ping an unknown subnet of 10.0.0.0/8, it would fail and
debugging
would show that the packets were unroutable.  This is true when I used
RIP
v1, RIP v2, IGRP, and EIGRP.  However, when I use OSPF it's a whole
'nuther
story!  It shouldn't matter how the routes are installed, but for some
reason, Router B behaves as if 'ip classless' were configured if I run
OSPF.

Toni

RE: The Finale: OSPF and IP Classless (partial retraction)

2001-03-30 Thread Bob Vance


Actually, John my treatises :) on this subject a year ago showed this.

   ip classless
*only* affects the lookups *outside* the classful aggregate.  Any
supernet *within* the classful aggregate *will* be used, even with
   no ip classless
set.
Thus, a learned route,  10.1.0.0/16 , will be used for address 10.1.1.1
, but not 10.2.2.2 .
(*if* I still understand what I wrote below ;>).


Here is part of my original work on the subject for those who are
feeling drowsy, but just can't nod off completely ;>)



Thanks to the lab of
Ding So
I was able to pound the last nail in the coffin of how

[no] ip classless

affects route lookups (the doco makes no mention of route installation,
so we would guess that it has no effect.  Further investigation will be
required to confirm/debunk this).

I will do a little write up, here, that can be challenged by anyone with
a dash of temerity:

   (Note that I've tried several times and I just can't seem to
find a clear, yet succinct way to describe this.
   )
==

Under old, classful routing it was assumed that all local networks would
be subnets of one or a couple of classful networks and that all the
subnets of a particular classful network, say "X" (e.g., X=172.16.0.0),
would be "connected" to each other.

What this means is that, for each and every pair of subnets of classful
network "X", there would be an interconnecting path among 1 or more
routers, that could be traversed *entirely* on segments whose IP network
addresses are subnets of classful network "X".

If the above requirement does not obtain, i.e., if the network path
*must* include a subnet of a *different* classful network, say "Y", then
we call this situation
"a discontiguous network".
or  "X has discontiguous subnets"
or  "X has disconnected subnets"
.

Another assumption in this environment is that, if we (a router) know
about any particular subnet of "X", then we should know about *all*
subnets of "X" that actually exist; either by our having one or more
interfaces within a subnet of X, an admin giving us proper static
routes,
or by information received from a routing protocol.

With the above in mind, the router will not entertain a route to a
subnet of network "Y" that isn't a route to a network address *within*
network "Y" (it can be that actual network aggregate, itself; e.g., a
route to 172.16.0.0/16, in the above example) -- that would mean
discontiguity.
In particular, it will *not* consider the "default" route
0.0.0.0/0
for any address within classful Y, if it has information about at least
one subnet of Y.
In addition (and this is the one always left out of the textbooks), it
will not consider *any* *supernets* routes of Y.  The 0.0.0.0/0 is just
a particular case of this rule (0.0.0.0/0 is always a supernet of
*every*
network address -- it contains *0* bits that do not match).

If you look at a

show ip route

you'll notice that the table is broken up into sections at *classful*
network boundaries, *even* if

ip classless

is set.
Note that supernet routes, including 0.0.0.0/0, are not listed within
any
classful section -- they are listed separately, on their own.

What the router does, with

no ip classless

set, is to first check to see if the target address in question falls
within one of these "known" sections -- i.e., in one of the "known"
classful networks.  If so, he will use the *longest* match for the
target
address that he can find in that section.
   (Note that this is a point also often left out of the text books.
Remember: a router will *always* try to do a longest-prefix match,
except for the constraint mentioned here, for 'no ip classless.
   )
*But*, he will *not* look *outside* that section (classful network),
when
no ip classless
is set.

With the advent of the Internet and CIDR and "prefixes", the above logic
may not be good enough.  When considering a given prefix and because of
the vagaries of the way addresses were handed out in the beginning, it
is very possible that "subnets" of that prefix (addresses with a longer
prefix, but yet still matching the original prefix in question) may
be disconnected.  Of course, this is a situation that is trying to be
remedied, but it is still possible.

So, now, it is very desirable to try "supernet" routes, in particular
the ever-hopeful "default" route, 0.0.0.0/0.
   (Actually, in this "prefix" environment, the concept of "supernet"
and "subnet" disappear.  Every route is simply a summary or
aggregate route to a bunch of possible addresses.
   )

This is what

ip classless

does.  It allows the router look *outside* the classful "section"
   (It can "think outside the lines", if you just *have* to use
that terminology:>)
   )
In fact, the router doesn't care about the "sections" (classful
networks) anymore.
He simply uses the longest match that he can find anywhere in the table,
inc

RE: The Finale: OSPF and IP Classless (partial retraction)

2001-03-30 Thread Bob Vance


>it is now  'ip clueless'.  :-)

LOL

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: John Neiberger [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 1:40 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: The Finale: OSPF and IP Classless (partial retraction)


Geez, you're right.  I'm starting to miss the forest because I've looked
at too many trees!

Yes, even in my experiments, I now remember seeing that the router
would pick a supernet route for a specific major network.  Others
pointed this out to me and I had completely forgotten that particular
point.

The moral of the story is:  always use 'ip classless' and then quit
worrying about it.

>From here onward I will no longer refer to 'ip classless'.it is now
'ip clueless'.  :-)

_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Job Opening Senior Network Engineer

2001-04-04 Thread Bob Vance


To me, the only thing that looked a little out line was the programming
stuff.

However, I believe that anyone that calls hermself ( :-) a CCIE should
be able to do the rest, at least with several years of experience.  Most
of the stuff would be satisfied in the natural course of CCIE
experience, I would hope.

They need the right person and will pay 200K for herm.
That's a lot of money (at least here, in lil' ol' Gawga :)

You guys are obviously not the right person ;>) , but when I have 5+
years CCIE experience I would hope to be able to meet those criteria
because of my Unix and programming background.

Call it serendipity -- or just a wise choice of change in career
direction :)

BTW, I'm sure that someone with more than 5 years experience as a CCIE
will be considered ;>)

Maybe I'm way off base, though.
Maybe CCIEs longer than 5 years expect to get paid more than that.

I *would* be interested in a serious answer to that question, although I
think that most of the CCIEs listen on that *other* list :)


-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Michael Linehan
Sent: Wednesday, April 04, 2001 11:03 AM
To: CiscoStudyGroup
Subject: Re: Job Opening Senior Network Engineer


C'mon guys this is a joke right. You took like three job postings and
made them one,
right.. If a guy like this exists I may have to kiss his feet. I don't
think my religous
beliefs would allow that however.

Mike Linehan
Whatever certs I have I'm not even close to this guy. Whoever he is.


Circusnuts wrote:

> Man- I wanna meet this person... C++, Viso proficient, CCIE with 5
years,
> deals directly with customers, possible masters degree candidate &
travels
> over half the time.
>
> - Original Message -
> From: "Butler, Gary" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, April 03, 2001 9:15 PM
> Subject: RE: Job Opening Senior Network Engineer
>
> > 200K   ;-) - Even at that money I would wager they will have a hard
time
> > filling that position.  Do I have my head where the sun don't shine
or do
> > they?  ;-)
> > Gary Butler
> >
> >
> > -Original Message-
> > From: Lisa Marie Belong [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 03, 2001 5:40 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: Job Opening Senior Network Engineer
> >
> >
> > Hello,
> >
> > We are a company located in Pleasanton, CA. (near Silicon Valley).
We have
> > an opening for Senior Network Engineer. Please see the following job
> > description. If you are interested please contact
> > [EMAIL PROTECTED]
> >
> > Position: Senior Network Engineer
> >
> > Position Description: Provide engineering services and support for
> Federal,
> > State, and Commercial customers, engineering and designing network
> > migrations, upgrades that include complex routing, and intranet &
extranet
> > security designs.
> >
> > Job Requirements:
> > * Must have CCIE Cisco Certification
> > * BA or BS degree preferred
> > * Ability to document and provide in-depth reporting and
> > analysis
> > * 5 years of industry experience
> > * 50-75% travel
> > * Ability to work with a varied range of customer skill levels
> > and knowledge
> >
> > Projects - Scope/Task
> > * Assist with resolution of design issues and document
> > accordingly
> > * Assist with implementation plan
> > * Identify risks and issues of conversion from existing design
> > to new production design and document accordingly
> > * Provide migration assistance to minimize or alleviate risks,
> > where applicable
> > * Identify the required maintenance testing and monitoring
> > plan tools required to adequately monitor and maintain the
implemented
> > configuration
> > * Assist in the disaster recovery design issues, as identified
> > * Assist in implementing Core production enhancement
> > * Assist with network diagrams and appropriate documentation
> > identifying the physical and logical network paths and connections
> > * Assist with technical network equipment design and
> > implementation as necessary
> > * Hands-on experience with IP, SNA, EGIP, RIP, BGP4
> > * Hands-on experience with e-business, high availability
> > design
> > * Proficient with VOIP, FOIP, and ATM
> >
> > Leadership/Supervision/ Project Management
> > * Team leader-engineering programs recognized as one of the
> > two top in country
> > * Ability to Supervise and direct as necessary
> > * Enterprise Management project
> > * Network Reconfiguration
> > * Create successful team relationships
> >
> >
> >
> >
> >
> > Network and Computer Skills
> > Proficient in Software programming
> > * Sun Net Manager, HP overview and other enterprise softwar

RE: CCIE Lab Report - unsuccesful

2001-04-08 Thread Bob Vance


Well, this news is certainly a blow -- I felt as if *I* had failed :|

Of course, if it weren't hard, who'd want it?
When you pass the next time, it will be just that much more special :)

Thanks for sharing your thoughts.

You still da man, in my book!


-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Chuck Larrieu
Sent: Saturday, April 07, 2001 9:34 PM
To: Cisco Mail List
Subject: CCIE Lab Report - unsuccesful


Hey, everyone, how you all been?

The short story is I did not make it to day 2. The rest of this is a bit
long winded, and easily skipped.

First of all, I was quite pleased to find upon reading through my Day 1
scenario that there was nothing I couldn't do, given time. There are
plenty
of practice labs from several different sources which cover all the core
topics, so there were no surprises for me.

Secondly, I was quite pleased when during my review of Day 1 results
with
the proctor,  he told me they were going to change the written
instruction
on a particular section because of the solution I used. I'm actually
quite
surprised it hasn't been done before. I was grudgingly given points,
although I was told my solution was definitely not what they had in
mind.

However, in the end,  it was a few simple omissions that cost me the
points
I would have needed to squeak into Day 2.

Only one of the six of us who began together was invited to the second
day.

Things I learned:

1) having the core topics down cold is CRUCIAL. No kidding!

2) Time is crucial, but not, I believe, in the way I have seen it
discussed
in many places. I highly doubt that typing 80 words a minute versus my
20
WPM was the difference. Not when I spent as much time as I did
contemplating. You  can't think it. You have to know it.

By 2:00 p.m. I knew I didn't have a prayer of hitting all the
requirements.
At that point I started counting points, putting myself in a defensive
mode.
By quitting time, if I got full credit for everything I thought I
deserved,
I would have had 31 points. As I found out in my review, I missed a few
simple things, and blew myself out of the water. This leads back to the
internalization of the core topics. You can't be thinking about how to
configure anything. You have to just bang them out, the same way you
bang
out shaving or washing your hands or eating your lunch.

3) Methodology is crucial. You have to have a good methodology that is
internalized and is habitual. You can't be thinking "what's next?" I
don't
believe it matters what your methodology is, so long as you are
consistent
and quick. My own methodology failed me because I was constantly
adjusting,
rather than banging it out.

4) I spent a good two hours last night in my hotel room debriefing
myself. I
have six pages of notes regarding my day one experience. This will form
the
basis of my study plan for my second attempt.  I know that it is highly
unlikely I will have a scenario like the one I just worked on next time
through. But I will focus on methodology and speed.

5) Good rapport with the proctor is helpful. I was able to get the
information I needed by carefully wording my questions and making sure
that
my desired result was understood. The proctor is under a bit of stress
himself, with so many folks vying for his attention. He may think you
are
asking something you are not. I made sure that if I was not getting an
answer that made sense that I clarified my request, so that the answer
was
one that helped me understand.  I will say also that the test I saw was
reasonably clear. The questions I had tended to be the result of outputs
from various show and debug commands, to clarify what the expectation
was.

A few other comments:

I was far too aggressive in scheduling my lab date.  Should have pushed
it
out 60 days. Don't be in a hurry. Those without a lot of hands on need
to
spend several months of several hours a day practicing. No two ways
about
it.

There has been a lot of discussion about the patch panels used in the
lab.
All I can say is that the panels are clearly labeled. IMHO you have
nothing
to worry about. That said, I did have to revisit the rack twice, in
order to
make a cabling change. This was purely the result of a chicken or egg
situation, and not due to any difficulty with the rack itself. People
with
home labs know well the issue with hooking up routers back to back.

I sat next to a guy this morning ( a day 1 candidate ) who was getting
up
every few minutes and going to the back of the rack to move cables
around.
Completely unnecessary and driving the proctor nuts. There is no need
for
any candidate to touch the back of the rack.

You can't let litt

RE: Venting about another employee [was Re: Cisco Certs Becoming Paper CCXX - Senior Citizen Reply]

2001-04-08 Thread Bob Vance


What he said.
:)
I was about to fire off a missive, when I noticed that everything that I
wanted to say was contained herein(after, as well :), hereinafter
referred to as "content", said content solely the property of Greg,
hereinafter referred to, both on and off the "list" (see section 6.2.1,
subsection 3.b, paragraph 1) as "Old Guy", said content being wholly
derived, thunk up, and maintained by Old Guy.  All rights to content
remain with Old Guy, with no liability incurred by Old Guy for any
misuse, misunderstanding, or misrepresentation of said content.


-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=


> -Original Message-
> From: Greg Macaulay [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 03, 2001 9:30 AM
> To: The.Rock; [EMAIL PROTECTED]
> Subject: RE: Cisco Certs Becoming Paper CCXX - Senior Citizen Reply
>
>
> "certs don't prove anything" ??? I'm not sure that I can agree with
that
> statement. Certs IMHO represent an interest by the individual in the
subject
> matter, and a determined effort to undertake studies necessary to
become
> more knowledgeable.
>
> Certainly, obtaining a cert. does not make one a guru.  But it usually
> (albeit not all the time) indicates a person who has shown some
willingness
> to learn.  I view the knowledge I gained by studying for my certs as a
> foundation to be built upon over the coming years. Perhaps I have only
a
> passing or introductory knowledge of some subjects at this juncture --
but
I
> assume -- and I certainly hope that as every year passes, I will build
upon
> that foundation knowledge and at some point I will undergo a slow, but
> steady metamorphosis into a guru of sorts!  But at this juncture with
my
> certs, I would certainly agree that I have just enough knowledge to be
> dangerous! 
>
> I would compare the cert study to obtaining academic and professional
> degrees.  Certainly upon graduation, grads are not experts in any
area,
but
> they possess the fundamentals upon which to build.  A lawyer, for
example,
> may indeed represent any survivors of a plane crash is his/her back
yard
on
> the day he/she is admitted to the Bar, but law school graduation and
passing
> a Bar Examination DOES NOT indicate an expertise -- but it does
indicate
the
> individual has the foundational knowledge and the potential to become
an
> expert at some point in the future.  I would submit that the same goes
for
> physicians, accountants, architects, etc.
>
> I think that the real problem is how these certs. have been marketed.
> Instead of promising IMMEDIATE big bucks, the certs, should be an
entry
> ticket into this career.  Individuals who possess these certs should
be
> respected for the time, effort and interest they have shown in
studying
for
> and obtaining a cert.  But whether they are PAPER CERTS is truly a
> mischaracterization.  As I put forth above, every academic or
professional
> degree is indeed initially a paper cert -- but with potential.  IT
folks
who
> obtain these certs by and large have the potential to succeed.  Just
as
> there are bright, average and incompetent lawyers, doctors and others,
the
> same would hold true in our field.  Some individuals in inately
intuitive,
> without certs, and others -- the majority -- will become the average
IT
> Joe/Jane who work day-to-day in this field.  Certainly there will
always
be
> the small numbers who are totally incompetent.  But it is not because
the
> certs are merely paper.
>
> That's my 2 cents.
>
> Greg Macaulay, CCNP, CCDP, MCSE
> Attorney/Law Professor (Retired)
> Lifetime member of AARP
> Oldest CCNP/CCDP in existence
_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: IP Classless [7:616]

2001-04-14 Thread Bob Vance


>10.10.32.0 is network address if the 10.0.0.0 network is masked with
> 255.0.0.0

Of course, you meant  mask 255.255.255.0   :)
Which is a common mask, even with network 10.0.0.0 .

To KISS it, I would guess that the mask being used is  255.255.0.0 ,
also a common mask for 10.0.0.0 .

One of the router's interfaces is probably

  ip address   10.10.x.y  255.255.0.0


> ip route 10.0.0.0 255.0.0.0 10.10.32.0

simply says that for all unknown addresses within 10.0.0.0/8 to send
them  to the router at 10.10.32.0, which he can get to because this is
on his (probable) 10.10.x.y link.

Note that this will "work" for all addresses within all, even unknown,
subnets of 10.0.0.0/8, even with

   no ip classless

set.

However, neither

  no ip classless
  ip route 8.0.0.0 128.0.0.0 10.10.32.0

nor

  no ip classless
  ip route 0.0.0.0 0.0.0.0 10.10.32.0  !(the "classic" default route)

would work -- in the sense that any unknown subnet (that is, there are
no specific routes that are known to that subnet) address destinations
within 10.0.0.0/8 would *not* be sent to 10.10.32.0 .

This is because

   ip classless

says do not look at *any* **supernet** routes of the classful network
aggregate  -- any form of route *within* the classful network *will* be
used in the normal "longest-match" way.

Unless, of course, as we learned from John, when you're running OSPF,
wherein IOS converts to  "ip classless"  anyway :)

(Good, God!
 I know way too much about "no ip classless" == "ip clueless"
   (or at least I think I do :)
Remember my motto:  "Often wrong, but never in doubt."
   )
)

-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
EA Louie
Sent: Monday, April 09, 2001 3:22 AM
To: John Brandis; [EMAIL PROTECTED]
Subject: Re: IP Classless


no ip classless means route IP over classful boundaries - you'll have to
do
your homework to learn the Class A, Class B, and Class C network
prefixes
though, mate   ;-)  However, 10.0.0.0 is a private (RFC 1918),
non-Internet-routeable Class A network

the route statement means that the route to network 10.0.0.0 is through
IP
address 10.10.32.0 (which is kind of weird, because 10.10.32.0 is
network
address if the 10.0.0.0 network is masked with 255.0.0.0, but with some
other subnet masks it would be a network rather than host address)  This
is
a classful static route, which is consistent with the no ip classless
command.

-e-

- Original Message -
From: "John Brandis" 
To: 
Sent: Sunday, April 08, 2001 8:07 PM
Subject: IP Classless


> no ip classless
> ip route 10.0.0.0 255.0.0.0 10.10.32.0
>
> Whats this mean
>
> Thanks




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=616&t=616
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Simpl-er way to explain Default Gateways [7:792]

2001-04-16 Thread Bob Vance


A long time ago, in a galaxy far, far away (or whatever -- and,
actually, it was in Wright's "IP Routing Primer"), I learned that IGRP
does not advertise network 0.0.0.0 as a default candidate (even with
"redistribute static".
So, you have to define some other network to flag as a default candidate
and to advertise if you want IGRP to propagate it.

That's about all I will say --
except that I *highly* recommend that book.
It will make you think longer and harder about topics that you consider
simple and that you thought you knew than you ever wanted to.

-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Kane, Christopher A.
Sent: Monday, April 16, 2001 2:11 PM
To: [EMAIL PROTECTED]
Subject: RE: Simpl-er way to explain Default Gateways [7:792]


IP route 0.0.0.0 0.0.0.0 = setups up a default route to either an IP
address
or an active interface. Used when no known route exists via a routing
protocol. I often use this when a customer is not getting any routes
from me
(not running BGP with me) and only needs a route out of their router
(access
layer) pointed to my gateway. (distribution layer).

IP default-gateway = setups up a default gateway to use if/when routing
dies. This comes in handy if the IOS happens to get corrupted. The
router
can still route to a directly connected gateway. Generally used while
troubleshooting the IOS problem. I've used it when a router's IOS has
gotten
corrupted which you'll usually know when you look at the hostname of
your
router and it shows "router-name(boot)>" This way, if need be, I can put
a
new IOS image on the gateway and then TFTP it do the crippled router.

IP default-network = I've seen this before but have never used it
myself.
CCO states:

"The argument network-number is a network number.
If the router has a directly connected interface onto that network, the
dynamic routing protocols running on that router will generate or source
a
default route. In the case of RIP and HELLO, this is the mention of the
pseudo-network 0.0.0.0. In the case of IGRP, it is the network itself,
flagged as an exterior route.
A router that is generating the default for a network may also need a
default of its own. This may be done by specifying a static route to the
network 0.0.0.0 via the appropriate router."

I'm not sure when/why you would use "default-network."

Anyone know?


Christopher A. Kane, CCNP
Senior Network Control Tech
Router Ops Center/Hilliard NOC
UUNET
(614)723-7877



-Original Message-
From: Circusnuts [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 16, 2001 1:25 PM
To: [EMAIL PROTECTED]
Subject: Simpl-er way to explain Default Gateways [7:792]


I have a friend going through the CCNA classes & the questions he asks
always
dig up topics I have either forgotten or do not use consistantly.

Is there a simple way to explain when to you use:

IP Route 0.0.0.0 0.0.0.0
IP Default-Gateway
IP Default-Network

Thanks
Phil
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=814&t=792
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: ARP versus Proxy-arp [7:5664]

2001-05-24 Thread Bob Vance


>Why would it think it can get to 10.0.0.0 (that ones a little
>easier) or 138.1.0.0 (unlikely) when the client computer ARPs for its
>default gateway?

Well, now.
Does a DG of its own count as "knowing how to get there"?>)


-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Priscilla Oppenheimer
Sent: Thursday, May 24, 2001 6:24 PM
To: [EMAIL PROTECTED]
Subject: RE: ARP versus Proxy-arp [7:5664]


You missed the point. I know what Proxy ARP is.

I assume the goal is that the traveller doesn't need to do any
reconfiguration and can leave the default gateway set to the home office
setting of 10.0.0.32, or 138.1.80.193 in my second example. A router
doesn't just blindly respond to ARPs. It only responds if it thinks it
can
get there. Why would it think it can get to 10.0.0.0 (that ones a little
easier) or 138.1.0.0 (unlikely) when the client computer ARPs for its
default gateway?

The design of the hotel network must be quite interesting. I was hoping
the
original poster had more details.

Priscilla

At 12:35 PM 5/24/01, Cornell Manea wrote:
>Proxy-arp is used to find a router and get by on a
>segment when you don't know the IP address of the
>default gateway...
>
>
>--- Priscilla Oppenheimer  wrote:
> > Hmm... That's interesting. I'm trying to figure it
> > out. Say, on my office
> > network, my default gateway is something like
> > 10.0.0.32 because we're using
> > private addresses and NAT. When I travel, would the
> > router in the hotel
> > respond to my ARP for 10.0.0.32?? Would the router
> > think that it can reach
> > network 10.0.0.0?
> >
> > And, let's say that I don't use private addresses on
> > my office network
> > (which I don't). Let's say the default gateway is
> > 138.1.80.193. Would the
> > hotel router respond to my ARP for 138.1.80.193?
> > Would the router think
> > that it can reach network 138.1.0.0?
> >
> > I would hate to be the desk clerk responding to
> > questions about this! ;-)
> >
> > Priscilla
> >
> > At 10:56 AM 5/24/01, [EMAIL PROTECTED] wrote:
> > >Proxy-Arp Lives!
> > >
> > >I have to add that as I understand it proxy arp and
> > nat are how hotels offer
> > >internet connectivity.  Take a laptop with any ip
> > address configured plug it
> > >in and it will arp for its default gateway.  The
> > router with proxy arp will
> > >answer as the default gateways mac address.  Then
> > using a wide scope for nat
> > >(the scope would be the entire ip address range)
> > the hotel can provide
> > >internet connectivity to a client with any
> > configured ip address and
> > >gateway.
> > >
> > >Dean Whitley
> > >
> > >-Original Message-
> > >From: Hire, Ejay [mailto:[EMAIL PROTECTED]]
> > >Sent: Thursday, May 24, 2001 10:32 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: RE: ARP versus Proxy-arp [7:5664]
> > >
> > >
> > >Proxy arp isn't dead, it is still in use very
> > frequently on dial-up links.
> > >If you get a chance, dial-up to earthlink and run
> > winipcfg.  You'll see that
> > >your default gateway is actually set to yourself.
> > Their is a reasonable
> > >explanation of this behavior in the Sybex CCNP
> > switch 2.0 chapter on
> > >redundancy.
> > >
> > >-EH
> > >
> > >-Original Message-
> > >From: Chuck Larrieu [mailto:[EMAIL PROTECTED]]
> > >Sent: Wednesday, May 23, 2001 10:37 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: ARP versus Proxy-arp [7:5664]
> > >
> > >
> > >At the risk of becoming another Bob Vance..
> > >
> > >I'm reading Doug Comer's TCP/IP reference, on the
> > assumption that it can't
> > >hurt to really get into how TCP/IP works.
> > >
> > >Proxy-arp versus normal  arp.
> > >
> > >A host does not know the physical address of
> > another host so it sends out an
> > >ARP request. If the host in question lies on
> > another network, a router
> > >responds to that request. Proxy ARP, correct?
> > >
> > >A host through it's TCP stack does the XOR and
> > determines that a

RE: ARP versus Proxy-arp [7:5664]

2001-05-24 Thread Bob Vance

I've never understood why setting DG to itself causes an ARP request for
the *target* IP address?
Normally, for non-local addresses, the ARP would be for the appropriate
gateway, (in this case, itself, which would be somewhat ridiculous), not
the target.
This must be a special hack to the lookup code -- at least I didn't find
it in the RFCs -- and as such, not necessarily universally supported.
Although, it makes as good sense as any as a way to cause an ARP for a
non-local address, which must be somehow configurable in the clients for
Proxy ARP to work in this case (the subnet mask thingy works because the
client thinks that the target is a local address, anyway).

-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, May 24, 2001 6:05 PM
To: [EMAIL PROTECTED]
Subject: Re: ARP versus Proxy-arp [7:5664]

Chuck,

Proxy-arp is also useful for cases where you have multiple
candidate DG's on the same segment and for whatever reason you
can't or don't want to use HSRP/VRRP, IRDP or passive RIP.

You can achieve a certain amount of load-balancing and failover
using proxy-arp by pointing a hosts DG to its own address and
setting the timeout for arp entries very low on the end-stations.

Course, this increases the amount of ARP bcasts on the segment
and is, essentially, a "cool hack", but it does work.

Regards,
Kent

On 23 May 2001, at 22:36, Chuck Larrieu wrote:

> At the risk of becoming another Bob Vance..
>
> I'm reading Doug Comer's TCP/IP reference, on the assumption that it
> can't hurt to really get into how TCP/IP works.
>
> Proxy-arp versus normal  arp.
>
> A host does not know the physical address of another host so it sends
> out an ARP request. If the host in question lies on another network, a
> router responds to that request. Proxy ARP, correct?
>
> A host through it's TCP stack does the XOR and determines that a host
> lies on another network. The host therefore sends the packet to the
> device indicated as its default gateway in its configuration. It sends
> an ARP request for the MAC of the default gateway. Normal ARP?
>
> So in other words, proxy arp may be viewed as something of an obsolete
> protocol / operation in that most modern TCP stacks contain the
> mechanisms for doing the network XOR determination, and then using the
> default gateway. A modern stack would recognize that a host is on a
> different network and go the default gateway route, so to speak.
>
> In other words, the necessity for proxy arp is eliminated for the most
> part because of the default gateway concept and the modern TCP stack.
>
> Has it sunk through this thick head finally?
>
> PS Comer states that proxy arp is aka arp hack. :->
>
> Chuck
>
> One IOS to forward them all.
> One IOS to find them.
> One IOS to summarize them all
> And in the routing table bind them.
>
> -JRR Chambers-
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html Report misconduct and
> Nondisclosure violations to [EMAIL PROTECTED]
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=5839&t=5664
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: ARP versus Proxy-arp [7:5664]

2001-05-25 Thread Bob Vance

Of course network 10 isn't special as far as "normal" routing code
goes -- otherwise internal networks using private addressing wouldn't
work.
I'm guessing that only "Internet routers" care about not forwarding the
"reserved/private" networks and that it is special code or ACLs that
handle this.

Any normal router, out of the box, and turning on Proxy ARP, wouldn't
treat the reserved nets any differently.  In any case, of course, the
router wouldn't have to worry about actually forwarding packets for net
10, because ultimately the client is trying to get to Yahoo, not a
private node.  Once the Proxy ARP answers the client's request for his
DG on net 10, then all the other packets will be to "real" Internet
addresses.

-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Priscilla Oppenheimer
Sent: Friday, May 25, 2001 3:04 PM
To: [EMAIL PROTECTED]
Subject: RE: ARP versus Proxy-arp [7:5664]

If a router running Proxy ARP didn't have a "route of last resort" or
"default route" would it still respond to an ARP for some random
non-local
network? It would cause problems if it responded to the ARP when it
couldn't really route packets to the destination. I suppose it usually
works because this router or the DG as you mention below has a default
route to the rest of the world.

And how about network 10.0.0.0? The hotel router in the scenario
wouldn't
respond to a customer's ARP for a DG of 10.0.0.1 unless the hotel
network
was configured with a 10.0.0.0 network, would it? Or maybe the default
route would cover this too, but maybe not since it's a private address.

I realize I'm being brain damaged about the whole topic, but I think the
issues are more subtle than people realize.

Priscilla

At 09:14 PM 5/24/01, Bob Vance wrote:
> >Why would it think it can get to 10.0.0.0 (that ones a little
> >easier) or 138.1.0.0 (unlikely) when the client computer ARPs for its
> >default gateway?
>
>Well, now.
>Does a DG of its own count as "knowing how to get there"?>)
>
>
>-
>Tks|
>BV |
>Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
>Vox 770-623-3430   11455 Lakefield Dr.
>Fax 770-623-3429   Duluth, GA 30097-1511
>=
>
>
>
>
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Priscilla Oppenheimer
>Sent: Thursday, May 24, 2001 6:24 PM
>To: [EMAIL PROTECTED]
>Subject: RE: ARP versus Proxy-arp [7:5664]
>
>
>You missed the point. I know what Proxy ARP is.
>
>I assume the goal is that the traveller doesn't need to do any
>reconfiguration and can leave the default gateway set to the home
office
>setting of 10.0.0.32, or 138.1.80.193 in my second example. A router
>doesn't just blindly respond to ARPs. It only responds if it thinks it
>can
>get there. Why would it think it can get to 10.0.0.0 (that ones a
little
>easier) or 138.1.0.0 (unlikely) when the client computer ARPs for its
>default gateway?
>
>The design of the hotel network must be quite interesting. I was hoping
>the
>original poster had more details.
>
>Priscilla
>
>At 12:35 PM 5/24/01, Cornell Manea wrote:
> >Proxy-arp is used to find a router and get by on a
> >segment when you don't know the IP address of the
> >default gateway...
> >
> >
> >--- Priscilla Oppenheimer  wrote:
> > > Hmm... That's interesting. I'm trying to figure it
> > > out. Say, on my office
> > > network, my default gateway is something like
> > > 10.0.0.32 because we're using
> > > private addresses and NAT. When I travel, would the
> > > router in the hotel
> > > respond to my ARP for 10.0.0.32?? Would the router
> > > think that it can reach
> > > network 10.0.0.0?
> > >
> > > And, let's say that I don't use private addresses on
> > > my office network
> > > (which I don't). Let's say the default gateway is
> > > 138.1.80.193. Would the
> > > hotel router respond to my ARP for 138.1.80.193?
> > > Would the router think
> > > that it can reach network 138.1.0.0?
> > >
> > > I would hate to be the desk clerk responding to
> > > questions about this! ;-)
> > >
> >

RE: DNS and ISP question [7:5898]

2001-05-26 Thread Bob Vance


still there:

http://www.acmebw.com/askmrdns/


-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
ElephantChild
Sent: Friday, May 25, 2001 1:36 PM
To: [EMAIL PROTECTED]
Subject: Re: DNS and ISP question [7:5898]


On Fri, 25 May 2001, Scott Meyer wrote:

> I have a question about changing ISP's when a domain name(s) is
registered
> to an IP address(s) owned by the ISP.
>
> Obviously, we need to get the DNS registration changed to an address
owned
> by the new ISP. I have had some transitions that have not been real
smooth,
> and would like the current best practice for doing this.
>
> Any input is apprectiated.

ObWhereDidItGo: Does anyone know where the "Ask Dr. DNS" web site went?
I wanted to point the poster to it, but couldn't find it. Oh well...




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=6024&t=5898
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: Meaning of a gateway [7:5918]

2001-05-26 Thread Bob Vance


I'm sure that Howard would have a good perspective on this :)

Generally, "gateway" and "router" are used interchangeably, especially
in this context of Cisco routing Cert preparation, just meaning sending
off this network onto another network.  E.g., "default gateway" or
"gateway of last resort"

I've seen definitions that basically say that if the box is dedicated to
routing, then it's a router.  If it's a server doing other things and
happens to have more than one NIC and does routing, then it's called a
gateway.

However, I've seen other definitions that make (I think, reasonably) a
clear distinction:

 . routers convert packets at level 3 and don't change underlying data.

 . gateways convert packets at higher levels of the OSI model, e.g.,
switching between protocols -- some say at all 7 layers.  Like say a
Gator box.

When Dorothy is wending thru the paths on the farm, she's routing.
When she clicks her heels, she's going thru a gateway :)

Again, I'm sure that Howard can give us the entire etymology of the
terms :)

-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Circusnuts
Sent: Friday, May 25, 2001 1:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Meaning of a gateway [7:5918]


Assume you are referring to the gateway of last resort, (0.0.0.0 0.0.0.0
E0
or IP Address) meaning... if cannot get where you are looking to go by
any
other means (routing protocol, etc., etc.,) head to E0 for resolution...

Phil

- Original Message -
From: Tan Chee Leong
To:
Sent: Friday, May 25, 2001 12:07 PM
Subject: Meaning of a gateway [7:5918]


> Hi,
>
> I have been thinking abt it and couldn't figure out so hope I can help
some
> pointers from this group.  Sorry if the question sounds silly.
>
> I do understand what a gateway is for but when it is configured in a
router,
> what exactly happens?
>
> Will it do the same if I make an entry in the route table like
0.0.0.0/0
> eth0
>
> Effectively saying that for a particular destination, if it is not
already
> routed (by other entries in the route table) then just push the packet
to
> eth0 (presumably where the gateway is situated).
>
> Thks.
>
> Cheers,
> Chee Leong
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=6025&t=5918
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: The disgusting and useless nslookup [7:6041]

2001-05-26 Thread Bob Vance


Let me rephrase this response:

I didn't mean to imply that I *only* use 'nslookup' or that I use it to
troubleshoot DNS problems.  I use it to resolve :) resolver issues, in
which case it is perfect and 'dig' is useless.

-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: bob vance
Sent: Saturday, May 26, 2001 3:55 PM
To: blst
Subject: RE: The disgusting and useless nslookup


I didn't say that I used it to troubleshoot DNS problems -- only
resolver issues, in which case it is perfect and 'dig' is useless.


-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: Jim Reid [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 26, 2001 3:25 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: The disgusting and useless nslookup


>>>>> "Bob" == Bob Vance  writes:

Bob> That's the main reason that I use it -- in fact I always use
Bob> the vendor's copy so that things like nsswitch are accounted
Bob> for.  The other reason that I use it is laziness -- I'd
Bob> rather type ping bobv than ping bobv.dyn.atl.sbm.com

This is one of the major reasons for *not* using nslookup. If nslookup
is returning answers from other lookup mechanisms on the computer, how
can you expect it to troubleshoot DNS problems? How can you tell which
lookup facility the answer came from? What if that answer differs from
what's in the DNS (which wasn't queried because nsswitch and friends
say "look at /etc/hosts or NIS before going to the DNS")?




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=6041&t=6041
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: another OT: why you UNIX guys look down on we NT guys? [7:6417]

2001-05-30 Thread Bob Vance


Unix guy.
Unix is stick shift; NT is automatic.
Therefore, Unix seems more fun :)
Hmmm. But, I drive an automatic =[
Don't look down upon.
Hat's off to anyone managing 2K rollout :|
Envy $240K/yr. %~/

-
Tks| 
BV | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Jim Bond
Sent: Tuesday, May 29, 2001 8:41 PM
To: [EMAIL PROTECTED]
Subject: another OT: why you UNIX guys look down on we NT guys? [7:6323]


UNIX guys,

I make $240K per year, how much you make? Why you guys
look down on us??? I don't get it...


Jim
NT guy




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=6417&t=6417
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: --- Not own broadcast

2000-08-05 Thread Bob Vance


I found this question interesting.
Maybe, I missed it, but I'm surprised that there wasn't more discussion
on
this one.

> 192.168.1.16/29 - R1 - 192.168.1.32/29
>|
>|192.168.1.252/30
>|
> 192.168.1.48/29 - R1 - 192.168.1.64/29
>
>node at address 192.168.1.18 sends a packet to address
>   192.168.1.255.
>which node or nodes will receive the packet?
> a) All nodes on all subnetworks
> b) Only the node at address 192.168.1.255
> c) Only the nodes on subnetwork 192.168.1.16 that have broadcast
reception
>enabled
> d) All nodes on subnetwork 192.168.1.16
> e) All nodes on subnetworks 192.168.1.16, 192.168.1.32, and
192.168.1.48

My answer is D.


The question says nothing about *accepting* the packet,
so it's reduced to a routing question:

Onto which segments, if any, will the routers send this packet?

I believe that the question, as stated, doesn't have enough information
to
be answered absolutely (but, then which ones do ;>).

Certainly, all nodes on the local segment, 192.168.1.16, will receive
the
packet (whether or not they accept the packet is entirely another
question,
although we hope that the author understands the distinction |>)
So, D) could be a correct answer.
B is out, since it is at a minimum a subnet broadcast address, not a
specific node address.
E and C
(Let's leave out the question of,
 "...what the meaning of "is", is."
)
are also right out.
So, we are left with whether A is correct.

Under classful rules, with subnet prefix length /29, the address
192.168.1.255
is host 7 on  subnet 192.168.1.248/29.

This 7/-3 is a subnet broadcast address, -1.

In addition, 248/5 is the -1 subnet.  So we have the address:
   network=192.168.1  subnet=-1   host=-1
.
This is supposed to be *recognized* as an "all-subnets" broadcast by
hosts
and must be accepted (RFC1122) by all hosts in all subnets of
192.168.1.0/24
network.
But, again, but this is irrelevant to the question of who *receives* the
packet.

Under classless rules, the address
192.168.1.255
is simply host 7 on network prefix 192.168.1.248/29.
Thus, this would simply be a directed broadcast.

The question is what will R1 (and R2) do with the packet?

At least two questions remain for the diagram:
  . are the routers configured to forward directed subnet broadcasts?
  . do they ignore all-subnets broadcast address

Are we to assume
no ip directed-broadcasts
?
Under 11.3, the default is
ip directed-broadcast
.
OTOH, this only has effect when
ip forward-protocol ...
is set.

Presumably, in the absence of facts (I hate those things -- they always
get
me confused), we would assume the lowest possible configuration, so we
would
*not* assume that any broadcasts being forwarded.
Presumably, also the all-subnets broadcast would also be blocked.

So, I have to answer D.


***However***

Now, more interesting, is what if we ***did*** have
ip forward-protocol ...
and ip directed-broadcast
on all interfaces?

*Now*, what would R1 do with the packet?
Will he see it as a directed broadcast to 192.168.1.252/30 only?
Or will he see it as an all-subnets broadcast and put it on
192.168.1.32/29
as well?

I frankly don't know what the behavior of IOS is vis-a-vis the
all-subnets
broadcast issue.

But, the all-subnets broadcast is deprecated as early as RFC1812.
Seeing it as an all-subnets broadcast would require that the routers be
configured for some kind of deprecated classful behavior.

I would therefore think that a classless (for lack of a better term)
router
with no local 192.168.1.0/24 addresses would simply treat the address
192.168.1.255 as any other routable directed broadcast address.

If so, in our case, R1 & R2 know about 192.168.1.252/30, so the packet
would
be put on that segment (ignoring, for the moment, that the connection
between R1 & R2 looks like a point-to-point serial connection).


Now,
All of the above having been said, I tried this on my own network:
   (which consists of 4 segments connected by a 3640 and a few other
segments connected by some 25xx.  The segments have several Unix and
windows hosts on them.
   )

pluto ## ping 10.255.255.255  # network's mask (nonVLSM)= 255.255.252.0
PING 10.255.255.255: 64 byte packets
64 bytes from 10.10.120.12: icmp_seq=0. time=4. ms
64 bytes from 10.10.120.1: icmp_seq=0. time=5. ms
64 bytes from 10.10.120.11: icmp_seq=0. time=6. ms
64 bytes from 10.10.120.10: icmp_seq=0. time=7. ms
64 bytes from 10.10.120.12: icmp_seq=1. time=0. ms
64 bytes from 10.10.120.10: icmp_seq=1. time=2. ms
64 bytes from 10.10.120.11: icmp_seq=1. time=3. ms
64 bytes from 10.10.120.1: icmp_seq=1. time=4. ms
64 bytes from 10.10.124.200: icmp_seq=1. time=58. ms

So all the local hosts responded, as expected (answer D).

But then there was this 10.10.124.200 response.  I have no idea what
this
box is (I no longer have control over the network).
Either it's one of the 3640's interfaces, o

RE: Problem Cleared? Want ot try the Follies Again?

2000-08-05 Thread Bob Vance


Oh, C*sco, who played me?

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Chuck Larrieu
Sent: Saturday, August 05, 2000 3:02 PM
To: Cisco Mail List
Subject: Problem Cleared? Want ot try the Follies Again?


My apologies to everyone for the problems. I think the issue is resolved
now.

You are all most cordially invited to try again

64.220.150.9 password "yahoudi" no quotes

I will leave things public until Sunday morning.

The questions to be answered are:


1) what version of IOS is running?
2) What is the name of the IOS image?
3) What routing protocols are running?
4) Are there any other routers connected? If so, on what ports?
5) If there are other routers connected, what IOS versions are they
running?
What are the names of the flash images on those routers, if there are
routers?
6) Provide every detail you can about any WAN protocols running
7) What is the privilege level password?
8) What model number router are you telneted into?
9) What model number routers are connected, if there are any connected?
10) Who played the Cisco Kid? (  extra credit - how did you find that
answer? )
11) Extra Extra credit - identify all security enabled on the router

I have no prizes to offer. But I do have the sincere hope that you all
will
have some fun taking a peek and finding the answers to these questions

Chuck
--
I am Locutus, a CCIE Lab Proctor. Xx_Brain_dumps_xX are futile. Your
life as
it has been is over ( if you hope to pass ) From this time forward, you
will
study US!
( apologies to the folks at Star Trek TNG )

___
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

___
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: a question about ip connectivity

2000-05-30 Thread Bob Vance


What OS are you running on the desktop?
If Win95, upgrade to MS DUN 1.3.

What does
route print
show, both before and after the dial-up connection.
What is the netmask on your LAN IP address?

You shouldn't have to do anything to have access *to* the Ethernet LAN
*and* the dial-up network at the same time.
You will get a default gateway that will allow access to Internet
sites thru the dial-up, but it shouldn't break access *to* the LAN
side -- you should still be able to access anything on the LAN side.

I do this every day -- in fact that is how I am connected to send this
post.  I am on a PC on the LAN in my house, talking *through* a Win95 PC
(running NAT software) that has a LAN card *and* has made a dial-up
connection to the Internet.  This "NAT" PC talks to both the internal
LAN and the Internet.

The only thing that I see different in your case, is that the LAN is
a subnet of the *same* Class B network as the dial-up.
NIC = 167.65.104.42
PPP = 167.65.107.12
I would assume that both prefixes are /24, but (and I'm not gonna test
it), but perhaps DUN has a problem with using subnets of the same
Classful network for the LAN and the dial-up.
In my case the PPP "network" is 10 and the LAN is 192.168.1 --
totally different and no possibility of confusion.

BTW, how is that your internal LAN has the same Class B network address
as the dial-up?

Now, one final point:
Joe used the word "across" the LAN (while I specifically said, "to"),
and he would obviously be correct.
If you were going to access another "internal" subnet, besides
167.65.104.0/24, say, 167.65.200.0/24, then, of course, you'd need
to have a router on your LAN to that subnet *and* add a static route on
the PC to that subnet (route add ...) thru that router.

>From your post, however, I did not take this last situation to be your
problem.  It seems that you couldn't connect to *other* 167.65.104.X
guys.

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Joe Martin
Sent: Wednesday, May 24, 2000 8:42 AM
To: [EMAIL PROTECTED]
Subject: Re: a question about ip connectivity


When you dial-up, a new default gateway is dynamically added into your
workstation to point to the dialup gateway.  To continue to allow access
across your LAN also, you will need to have routes to your lan segments.
These routes could be added statically or could be learned dynamically
thru
a routing protocol.

JOE
CCNP, CCDP, and a few other things...
CCIE Lab - May 27/28


""Cai, Land"" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Sorry for made a mistake, the IP add of ether Card is 167.65.104.42.
>
>  -Original Message-
> From: Andrew Larkins [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 24, 2000 6:24 PM
> To: Cai, Land
> Subject: RE: a question about ip connectivity
>
> you need a route to the other subnet...
>
> Andrew Larkins
> Usko Communications
> Tel: +2711 236-8000
> Fax: +2711 236-8350
> Cell: +2783-656-7214
> Email: [EMAIL PROTECTED]
>
>
> "This message may contain information which is confidential and
subject to
> legal privilege.  If you are not the intended recipient, you may not
peruse,
> use, disseminate, distribute or copy this message.  If you have
received
> this message in error, please notify the sender immediately by email,
> facsimile or telephone and return and/or destroy the original
message."
>
>
>
>
> -Original Message-
> From: Cai, Land [mailto:[EMAIL PROTECTED]]
> Sent: 24 May 2000 10:57
> To: Cisco (E-mail)
> Subject: a question about ip connectivity
>
>
> Hi,
>
> Supposed to have a desktop, whose ether Card ip is 167.65.107.42
and
> have a smooth IP connectivity with other hosts.  Now I need to dial up
to
> PPP server, and get the IP 167.65.107.12.  But at this time, I can
only do
> ping 167.65.107.X, while can't ping 167.65.104.X.  That's why? And how
to
> enable to ping the both IP segments.  All the mask is 255.255.255.0.
>
> Thanks in advance.
> CCNA, MSCE.
>
> Cai, land
>
> ___
> UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> FAQ, list archives, and subscription info: http://www.groupstudy.com
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
> ___
> UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> FAQ, list archives, and subscription info: http://www.groupstudy.com
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> ---


___
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, an

RE: This officially sucks :)

2000-06-07 Thread Bob Vance


IIRC, there is a 10K limit on posts.
Thus, the "really gooder" you make a post, the more likely it
will be eaten, especially if you're including parts of the thread.

-
Tks        | 
BV     | 
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=



At 08:03 PM 5/31/2000 -0500, Aaron Prather wrote:
>
> I hate when i post a really good response to someone's question, and
the
list
> eats my post and it never gets to everyone Does everyone else have
this
> problem??? What can I/We do to solve this problem?
>  
> Thanks,
>  
> Aaron

___
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

RE: a question about ip connectivity

2000-06-08 Thread Bob Vance


Sorry.  Been away awhile.

>after dial our change to
> 167.65.104.0 255.255.255.0 167.65.104.42 167.65.104.42 2
> 167.65.104.0 255.255.255.0 167.65.107.12 167.65.107.12 1
  ---^
Looks to me like a bug or misconfig somewhere.  This second line could
only be correct if the mask were 255.255.252.0.

Notice that if the dial-in server mask were really /22 (255.255.252.0),
then
167.65.107.12

*would* be in subnet

167.65.104.0 255.255.252.0

Maybe DUN's seeing already a /24 mask for 167.65.104.0 and
has a bug or something.
In that case, I would *expect* the routing table to look like:

167.65.104.0 255.255.255.0 167.65.104.42 167.65.104.42 2
167.65.104.0 255.255.252.0 167.65.107.12 167.65.107.12 1
---^

and the first route to be used, instead of the second (longer prefix).


You didn't answer the question about what OS and, if it's Win95, whether
you're using DUN 1.3 or not.


-
Tks        | <mailto:[EMAIL PROTECTED]>
BV     | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Cai, Land
Sent: Tuesday, May 30, 2000 11:23 PM
To: '[EMAIL PROTECTED]'; CISCO_GroupStudy (E-mail)
Cc: Cai, Land
Subject: RE: a question about ip connectivity


Bob,

Thanks for your detailed posting. The internal LAN segment has same B
class
network  as dial-up, it 's because I dial to our dial in server located
in
the other branch office(not dail to internet).  We set the ip network to
B
class, while use 24 prefix to subnet it.  Now I have resolved this
problem.
I noticed that after dial out, the routing table of the PC be affected,
as
follows:

Before dial out
 167.65.104.0   255.255.255.0 167.65.104.42 167.65.104.42 1
after dial our change to
167.65.104.0 255.255.255.0 167.65.104.42 167.65.104.42 2
167.65.104.0 255.255.255.0 167.65.107.12 167.65.107.12 1

note, 167.65.107.12 is gotten from PPP server IP pool.
  167.65.104.42 is Ethernet Card IP addr.
Can you explain why this route table be updated to this appearance. And
why
this happen?

Thanks,
Cai, land
CCNA...

 -Original Message-
From:   Bob Vance [mailto:[EMAIL PROTECTED]]
Sent:   Tuesday, May 30, 2000 10:27 PM
To: CISCO_GroupStudy (E-mail)
Cc: 'Cai, Land'
Subject:RE: a question about ip connectivity

What OS are you running on the desktop?
If Win95, upgrade to MS DUN 1.3.

What does
route print
show, both before and after the dial-up connection.
What is the netmask on your LAN IP address?

You shouldn't have to do anything to have access *to* the Ethernet LAN
*and* the dial-up network at the same time.
You will get a default gateway that will allow access to Internet
sites thru the dial-up, but it shouldn't break access *to* the LAN
side -- you should still be able to access anything on the LAN side.

I do this every day -- in fact that is how I am connected to send this
post.  I am on a PC on the LAN in my house, talking *through* a Win95 PC
(running NAT software) that has a LAN card *and* has made a dial-up
connection to the Internet.  This "NAT" PC talks to both the internal
LAN and the Internet.

The only thing that I see different in your case, is that the LAN is
a subnet of the *same* Class B network as the dial-up.
NIC = 167.65.104.42
PPP = 167.65.107.12
I would assume that both prefixes are /24, but (and I'm not gonna test
it), but perhaps DUN has a problem with using subnets of the same
Classful network for the LAN and the dial-up.
In my case the PPP "network" is 10 and the LAN is 192.168.1 --
totally different and no possibility of confusion.

BTW, how is that your internal LAN has the same Class B network address
as the dial-up?

Now, one final point:
Joe used the word "across" the LAN (while I specifically said, "to"),
and he would obviously be correct.
If you were going to access another "internal" subnet, besides
167.65.104.0/24, say, 167.65.200.0/24, then, of course, you'd need
to have a router on your LAN to that subnet *and* add a static route on
the PC to that subnet (route add ...) thru that router.

>From your post, however, I did not take this last situation to be your
problem.  It seems that you couldn't connect to *other* 167.65.104.X
guys.

-
Tks| <mailto:[EMAIL PROTECTED]>
BV | <mailto:[EMAIL PROTECTED]>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=





-Original Message-
F

RE: DIGI Port Server

2000-07-12 Thread Bob Vance


The jack pinouts are:
 1 RI
 2 DSR
 3 RTS
 4  GND
 5 TxD
 6 RxD
 7 SG
 8 CTS
 9 DTR
10 DCD

>From this, you can figure out how to make the cable to connect the
PortServer port
to a router console.  These are both DTE's, so you'll want the TxD of the
PortServer
to go to the RxD of the console.

To telnet to the console connected to port N, use

telnet portsrv 200N# (2000 + port #)

As for the config, this is what I have, but I am connecting to Unix-host
consoles.  It should work for a router console, as well, though:

#> set po ra=1-1
tty termtype   dev  sess uid edelay auto  bin group dport dest
  1 vt220  mio40 1   off   on0 0  255.255.255.255

#> set line ra=1-1
tty  baud csize parity stopb  break   error inpck istrip onlcr otab
  1  96008  N 1  ignorenull  offoff   off   off

   (I'm not sure how the "break" parm will affect your being able to
send a break to the router console -- you may have to experiment.
   )

#> set flow ra=1-1
tty  ixon aixon ixoff ixany itoss altpin  rts  dtr  cts  dcd  dsr   ri
  1on   off   off   off   offoff  off  off  off  off  off  off

#> set login ra=1-8
tty cmdprompt  logprompt  passprompt  write  login  passwd  verbose  message
  1 digi>  login: passwd:  off on  on  off none


-
Tks        | 
BV     | 
Senior Tech. Consultant,   SBM, A Gates/Arrow Co.
Vox 770-623-3430   11455 Lakefield Dr.
Fax 770-623-3429   Duluth, GA 30097-1511
=

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
kumar
Sent: Thursday, July 06, 2000 5:02 AM
To: [EMAIL PROTECTED]
Subject: DIGI Port Server


Dear All,

I would like to use Digi Port Server to connect Cisco
Router through reverse telnet. I need your help on the
following :-

1. The cable pinout(both end rj45) between Digi Port
server and Cisco Console Port.

2. Minimal configuration required on the Digi port
Server.

thanks for your time
Regards
Kumar


__
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

___
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

___
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

70 matches

Mail list logo