RE: A lab loopback strategy

From: Rahmlow, Howard F. (howard.rahmlow@xxxxxxxxxx)
Date: Fri Jan 05 2001 - 11:42:55 GMT-3


   
Make sure you check with the proctor before you create any loopbacks that
are not called for in the test document. Also make sure you read, and
re-read the part of the test, that may or may not state that all interfaces
must be pingable from any other interface. I got burned on this during one
test. I had created a loopback, for a specific protocol, and got the ok from
the proctor. But I forgot to make sure I could ping it, from anywhere on the
network. Lost those points.

Howard.

-----Original Message-----
From: Curtis Phillips [mailto:phillipscurtis@netscape.net]
Sent: Friday, January 05, 2001 9:22 AM
To: ccielab@groupstudy.com
Subject: A lab loopback stategy

Hello,

I was thinking about a loopback addressing atategy for the lab and wondered
whether others had developed a specific plan. I consider loopbacks essential
for OPSF adjacency development, BGP internal peering sessions,and probably
for
the introduction of network segments into the configuration.

I think it would be nice to create loopbacks that identify the router of
origin, For example 1.1.1.1 for router 1, 2.2.2.2 for router 2 etc.

As any OSPF RIDs would be altered by addition of higher numbered loopback
addresses, is there a strategy the anticipates this?

Although real-world practice may be to use loopbacks to source BGP updates
for
IBGP, does anyone see any problems with using physical interfaces in the lab
environment?

Anything else I am missing here?

Thanks,

Curtis



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:27:22 GMT-3