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.
I'd go with port based VLANs. Using VLANs everywhere gives you a lot of flexability.
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.
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.
Routers don't forward broadcasts outside of subnets.
Luckily, the 8600 is configured primarily through a CLI. For doing change control on it, check out rancid:
formatting link
It's primarily geared towards cisco devices, but should be adaptable to 8600 without too much difficulty.
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.
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.
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.
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. [ ... ]
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>
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.
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.
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.
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.
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.
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.
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.)
Every interfaces of VLANs on ERS8600 can be the management IP addresses. The IP address of management port on CPU module is a out of band IP address. Which means you can't assign any IP addresses currently used in your campus on it. Which address can be used for management? It depends on your security policy.
Brouter port or port based VLAN? It depends on the Spanning Tree design on the campus. The benefit of brouter port is preventing Spanning Tree but we can use MLT or SMLT to solve it. The port based VLAN will be a better idea for ERS8600 because of the scalability of network.
Simply setup DHCP relay and DHCP server on every interfaces. DHCP response can reach each subnet as long as the routing is correct.
802.1Q is useful for LAN management and traffic control.
Broadcast never crosses different VLANs.
No matter you use Device Manager or CLI, the configuration is always as a text file in ERS8600.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.