|
|
|
|
|
Posted by Peter Grandi on June 10, 2007, 3:21 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Hi I am looking at a relatively simple setup: a dozen networks,
each with its own switch and /24 IP subnet are linked to one
router which has a link to the campus net. The root router is an
8600 and the leaves are 5530s or 5520s.
The idea is that the 8600 is configured as a pure router, and
the 5530s/5520s as pure switches. So the 8600 has N+1 addresses,
where N addresses are the gateway addresses used by nodes in the
N leaf subnets, and the last one is the address on the link to
the campus net. Therefore I also need N+1 routes, N routes to
the leaf subnets, and 1 default route to the campus net.
To give some numbers, let's assume:
* The link to the campus net has the 192.168.0.0/30 subnet, the
8600 end is 192.168.0.2, the campus net gateway (which is
another 8600) is 192.168.0.1.
* The leaf subnets are 10.0.1.0/24 to 10.0.12.0/24, and the
gateway address each subnet expects is to be the .1 address in
each subnet.
* The 8600 then must have N ports with addresses 10.0.1-12.1,
and one port with the 192.168.0.2 address.
* The internet gateway must two routes back to the 8600, one
to 192.168.0.2/32 via 192.168.0.1 and the other to 10.0.0.0/8
via 192.168.0.2 (or similar).
* One of the leaf networks should be connectable with a MLT
connection between the 8600 and its 5530.
So far so good. My questions are:
* What address to give to the real or virtual management port?
Possibilities: 192.168.0.2, something like 10.0.0.1, something
arbitrary, ...
* User IP based brouter ports or port based VLANs to bind the
10.0.1-12.1 addresses (and related routes) to the ports to
which the leaf switches are connected?
* Assuming that this has to be done, how to relay DHCP queries
from the 10.0.1-12.0/24 subnets to the campus subnet and
responses back to them?
Ideally the choices would satisfy these constraints:
* Minimal use of VLANs, in particular avoid on-wire VLAN tags
(VLANs entirely internal to the 8600 are sort of OK).
* Other then DHCP, no relaying of broadcasts outside the network
they originated from. In other words, traffic among the leaf
networks (very little is expected anyhow) should be purely
routed, and so should traffic between the campus net and the
leaf networks, with the exception of DHCP.
* The config should be done with CLI commands. In particular the
config should be saveable to a text file and checked into a
version control system...
Any suggestions and example warmly welcomed, as while I am very
familiar with networking configuration in the UNIX/Linux/...,
rather less so with the Nortel CLI.
|
  | |
Posted by Frank Sweetser on June 10, 2007, 3:18 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> Hi I am looking at a relatively simple setup: a dozen networks,
> each with its own switch and /24 IP subnet are linked to one
> router which has a link to the campus net. The root router is an
> 8600 and the leaves are 5530s or 5520s.
>
> The idea is that the 8600 is configured as a pure router, and
> the 5530s/5520s as pure switches. So the 8600 has N+1 addresses,
> where N addresses are the gateway addresses used by nodes in the
> N leaf subnets, and the last one is the address on the link to
> the campus net. Therefore I also need N+1 routes, N routes to
> the leaf subnets, and 1 default route to the campus net.
>
> To give some numbers, let's assume:
>
> * The link to the campus net has the 192.168.0.0/30 subnet, the
> 8600 end is 192.168.0.2, the campus net gateway (which is
> another 8600) is 192.168.0.1.
>
> * The leaf subnets are 10.0.1.0/24 to 10.0.12.0/24, and the
> gateway address each subnet expects is to be the .1 address in
> each subnet.
>
> * The 8600 then must have N ports with addresses 10.0.1-12.1,
> and one port with the 192.168.0.2 address.
>
> * The internet gateway must two routes back to the 8600, one
> to 192.168.0.2/32 via 192.168.0.1 and the other to 10.0.0.0/8
> via 192.168.0.2 (or similar).
>
> * One of the leaf networks should be connectable with a MLT
> connection between the 8600 and its 5530.
>
> So far so good. My questions are:
>
> * What address to give to the real or virtual management port?
> Possibilities: 192.168.0.2, something like 10.0.0.1, something
> arbitrary, ...
In the ideal case, you'd have a seperate network dedicated only to out of band
management traffic. Physically seperate fiber, seperate set of switches, etc.
If that's not the case, it's probably not worth using the management ports.
> * User IP based brouter ports or port based VLANs to bind the
> 10.0.1-12.1 addresses (and related routes) to the ports to
> which the leaf switches are connected?
I'd go with port based VLANs. Using VLANs everywhere gives you a lot of
flexability.
> * Assuming that this has to be done, how to relay DHCP queries
> from the 10.0.1-12.0/24 subnets to the campus subnet and
> responses back to them?
You'll need to create a collection of DHCP relay agents on the 8600 acting
as a router. You'll need to configure the relay agents for each subnet with
a list of DHCP servers that requests for that subnet should be routed to.
> Ideally the choices would satisfy these constraints:
>
> * Minimal use of VLANs, in particular avoid on-wire VLAN tags
> (VLANs entirely internal to the 8600 are sort of OK).
Why this requirement? For starters, I hate to break it to you, but you
probably won't find any switches that aren't primarily VLAN based - they just
typically default to all ports on VLAN 1. The more inter-switch links you have
running untagged, the more you're tying your hands to respond to any changing
needs down the road. Obviously you don't want to enable tagged packets on any
end station ports, but the first time you need to port two subnets out to a
single edge switch, you'll have to either a) run multiple uplinks, eating up
ports and fiber links, or b) start tagging the link anyway. It's a lot easier
to just tag all your uplinks in the first place.
> * Other then DHCP, no relaying of broadcasts outside the network
> they originated from. In other words, traffic among the leaf
> networks (very little is expected anyhow) should be purely
> routed, and so should traffic between the campus net and the
> leaf networks, with the exception of DHCP.
Routers don't forward broadcasts outside of subnets.
> * The config should be done with CLI commands. In particular the
> config should be saveable to a text file and checked into a
> version control system...
Luckily, the 8600 is configured primarily through a CLI. For doing change
control on it, check out rancid:
http://www.shrubbery.net/rancid/
It's primarily geared towards cisco devices, but should be adaptable to 8600
without too much difficulty.
--
Frank Sweetser fs at wpi.edu | For every problem, there is a solution that
WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC
|
|
Posted by Peter Grandi on June 10, 2007, 5:42 pm
If you were Registered and logged in, you could reply and use other advanced thread options >>> On Sun, 10 Jun 2007 19:18:20 +0000 (UTC), Frank Sweetser
[ ... ]
>> * What address to give to the real or virtual management
>> port? Possibilities: 192.168.0.2, something like 10.0.0.1,
>> something arbitrary, ...
fs> In the ideal case, you'd have a seperate network dedicated
fs> only to out of band management traffic. Physically seperate
fs> fiber, seperate set of switches, etc. If that's not the
fs> case, it's probably not worth using the management ports.
There will be a separate management network, but some bits of I
have read gave me the impression impression that having a real
or virtual management port IP address important is important,
even if there is no management network; the (real or virtual)
management port is just used to hang an IP address to. I suppose
because of things like using DevManager etc., or simply to give
the node a canonical IP address.
>> [ ... DHCP relay ... ]
fs> You'll need to create a collection of DHCP relay agents on
fs> the 8600 acting as a router. [ ... ]
Ahhh it will be a bit tedious. Thanks for pointing this out.
>> * Minimal use of VLANs, in particular avoid on-wire VLAN tags
>> (VLANs entirely internal to the 8600 are sort of OK).
fs> Why this requirement? For starters, I hate to break it to
fs> you, but you probably won't find any switches that aren't
fs> primarily VLAN based - they just typically default to all
fs> ports on VLAN 1.
Ah yes, so too bad, but that remains within "minimal use".
fs> The more inter-switch links you have running untagged, the
fs> more you're tying your hands to respond to any changing
fs> needs down the road. [ ... ]
>> * User IP based brouter ports or port based VLANs to bind the
>> 10.0.1-12.1 addresses (and related routes) to the ports to
>> which the leaf switches are connected?
fs> I'd go with port based VLANs. Using VLANs everywhere gives
fs> you a lot of flexability.
Our current setup is VLAN based, and we are trying to get rid of
them :-). We need little functional flexibility (thanks to a
fairly functionally homogenous network), but something that is
easier to understand and diagnose, and operates more as an
internet, not a single network with subsets.
fs> [ ... ] the first time you need to port two subnets out to a
fs> single edge switch, you'll have to [ ... ]
Well, I personally think that is in general a bad idea, but I
admit that it is a very seductive one. My style usually is ''one
LAN, one subnet, one router''; the motivation is ease of
understanding and documentation, and separation of trouble and
concerns. The current VLAN based infrastructure I am dealing
with has several dozen switches and thousands of ports over a
dozen VLANs and it seems a bit prone to global accidents, and/or
fossilization of the configuration to minimize them. That's not
too bad for an office infrastructure, but the network subset
that is being reconfigured has very different requirements...
[ ... ]
fs> Routers don't forward broadcasts outside of subnets.
The problem here is that the 8600 is both a switch and a router,
and it configuration system is not totally simple :-), and in
particular it seems to handle routing by using mostly internal
VLANs. I'd like to avoid inadvertently creating a switching
situation where I just really want routing. For example the
description of a ''brouter'' port says that it continues to
route even if it is in a blocked state. In a sense I'd like to
make sure all ports are in a blocked state then :-).
[ ... ]
fs> Luckily, the 8600 is configured primarily through a CLI.
Uhmmm, that's the base level, but most people are seduced by the
DevManager. In my case I really prefer the NNCLI.
fs> For doing change control on it, check out rancid:
fs> http://www.shrubbery.net/rancid/ [ ... ]
Ahhhh interesting.
Thanks a lot for your comments!
|
|
Posted by Frank Sweetser on June 10, 2007, 7:36 pm
If you were Registered and logged in, you could reply and use other advanced thread options >>>> On Sun, 10 Jun 2007 19:18:20 +0000 (UTC), Frank Sweetser
> There will be a separate management network, but some bits of I
> have read gave me the impression impression that having a real
> or virtual management port IP address important is important,
> even if there is no management network; the (real or virtual)
> management port is just used to hang an IP address to. I suppose
> because of things like using DevManager etc., or simply to give
> the node a canonical IP address.
Ah - this is usually more of an issue for 8600s that are acting as a router.
If you're not using a virtual IP address, you have to pick an address
associated with an interface, such as a VLAN. If that interface is down, then
the IP address will be unreachable. A virtual IP address, however, can be used
to contact the router via any interface that's still up. This address should
typically be on a small dedicated subnet for this purpose.
>>> * User IP based brouter ports or port based VLANs to bind the
>>> 10.0.1-12.1 addresses (and related routes) to the ports to
>>> which the leaf switches are connected?
>
> fs> I'd go with port based VLANs. Using VLANs everywhere gives
> fs> you a lot of flexability.
>
> Our current setup is VLAN based, and we are trying to get rid of
> them :-). We need little functional flexibility (thanks to a
> fairly functionally homogenous network), but something that is
> easier to understand and diagnose, and operates more as an
> internet, not a single network with subsets.
>
> fs> [ ... ] the first time you need to port two subnets out to a
> fs> single edge switch, you'll have to [ ... ]
>
> Well, I personally think that is in general a bad idea, but I
> admit that it is a very seductive one. My style usually is ''one
> LAN, one subnet, one router''; the motivation is ease of
Personally, I prefer my routers to have more than one subnet configured,
otherwise it can't talk to very much ;-)
The thing that you have to remember is that a VLAN is a LAN - it's just
one that's virtually defined. It's no different than virtual IP addresses,
or OS virtuallization - except that networks have been doing this kind of
virtualization for 10 years, and it's rock solid.
> understanding and documentation, and separation of trouble and
> concerns. The current VLAN based infrastructure I am dealing
> with has several dozen switches and thousands of ports over a
> dozen VLANs and it seems a bit prone to global accidents, and/or
> fossilization of the configuration to minimize them. That's not
> too bad for an office infrastructure, but the network subset
> that is being reconfigured has very different requirements...
We have 7,748 active ports according to our drop database using this
style setup, and it's worked flawlessly for us.
If anything, I'd be more nervous about potential screwups and losing track
of what's where with a non-VLAN setup.
With VLAN multiple VLANs, I can look at any port in my entire network and
instantly tell you, with no ambiguity, exactly which subnet it belongs to.
Without them, I'd have to trace things back up to the correct router to find
out where I am. Much more of the state of the network is implicitly
configured, rather than explicitly.
Because of this, the network monitoring package we have is able to identify
what network each machine is one when it dumps the FDB and ARP tables
periodically.
With each VLAN explicitly configured on uplink ports, if something gets plugged
in somewhere it doesn't belong, it simply won't work due to the VLAN mismatch.
In our server room, it alows us to have a number of subnets all served off of
the same switch, letting us segregate out different classes of servers without
having to buy a seperate switch for every subnet.
When, eventually, you have to port another subnet out to an existing switch,
it's just five minutes work to do so.
> fs> Routers don't forward broadcasts outside of subnets.
>
> The problem here is that the 8600 is both a switch and a router,
> and it configuration system is not totally simple :-), and in
That's certainly true =) You just have to remember that each VLAN is exactly
what the name implies - a virtual LAN. By configuring an interface on a given
VLAN, you create a logical IP interface from the routing engine to that VLAN.
> particular it seems to handle routing by using mostly internal
> VLANs. I'd like to avoid inadvertently creating a switching
> situation where I just really want routing. For example the
All you have to do is not put two ports on the same VLAN, and there will not be
any switching, only routing. Switching is only done within a VLAN - the only
way to get between two VLANs is via routing.
> description of a ''brouter'' port says that it continues to
> route even if it is in a blocked state. In a sense I'd like to
> make sure all ports are in a blocked state then :-).
Somehow I suspect that wouldn't actually be very useful =)
In the end, I think you're going to find that any new, enterprise class network
device is going to be built from the ground up around VLAN technology.
Non-VLAN netowrks these days are about as common as unpartitioned hard drives,
and even less flexible.
> Thanks a lot for your comments!
Good luck, whichever way you end up going =)
(BTW, for what it's worth, I've only known of one large network that went with
non-VLAN tagged links in their initial deployment. A year later, they were
regretting this, and working on a plan to move to rolling VLANs out to the
edge.)
--
Frank Sweetser fs at wpi.edu | For every problem, there is a solution that
WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC
|
|
Posted by Charles R. Anderson on June 13, 2007, 12:10 am
If you were Registered and logged in, you could reply and use other advanced thread options > Uhmmm, that's the base level, but most people are seduced by the
> DevManager. In my case I really prefer the NNCLI.
The 8600 doesn't support NNCLI (thank god). PPCLI (Passport CLI) is
much better anyway.
|
| Similar Threads | Posted | | Port Monitor setup on a 8600 switch. | February 3, 2006, 3:54 am |
| Routing between VLANs on a baystack 450-24T | September 7, 2005, 9:14 am |
| Configuring vlans on the 470 switches | February 28, 2007, 10:28 pm |
| Simple 802.1Q Trunk Configuration | May 5, 2005, 11:02 am |
| Simple CallPillot Question | January 12, 2006, 4:21 pm |
| MCR setup | September 16, 2005, 12:35 pm |
| Please help with NAM vm setup | April 25, 2006, 12:37 am |
| BCM Skillset Setup | April 6, 2005, 9:43 am |
| MICS Setup | August 1, 2005, 8:38 am |
| IP phone setup remote location | August 2, 2007, 1:06 pm |
|
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map