 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Technical Field
The invention relates to Local Area Networks (LAN). More particularly, the
invention relates to the monitoring and control of network packet traffic
resulting in the reduction of unnecessary traffic across LANs without the
use of bridges or routers.
2. Description of the Prior Art
When LAN networks first started growing in the 1980's, a physical limit was
quickly reached due to the LAN cable limitations. To solve this problem,
LAN bridges were introduced to tie these physical cables together to form
larger networks. The bridge would transparently pass packets between LAN
segments. In addition, these bridges also could also eavesdrop on the
packets and learn which MAC addresses were on each LAN segment. In this
way they could keep unicast traffic on the appropriate LAN segment. This
increased the overall network throughput so long as the users set up their
topology to keep hosts that frequently talked to each other on the same
LAN segment.
At some point however, MAC level broadcasts become an intolerably large
percent of the network traffic (when accidental bridge loops occurred at
set up, broadcast storms could completely disable a network). Broadcasts
not only use up network bandwidth but also use up processing power on
every host system that the broadcast is passed to (the processor must
analyze every broadcast packet up through the network layer to see if the
packet is addressed to it). To solve this problem, routers were introduced
to segment the network into separate broadcast domains.
At the router boundary, all broadcasts were intercepted and the router
would decide which LANs the broadcast would be propagated on (if any).
Routers performed this function by looking into level 3 headers and forced
the network to be segmented into network level broadcast domains. Although
this solved the problem of excessive broadcasts within the network, it
introduced an expensive device that would add latency, limit throughput
between these broadcast domains and add complexity to the network. To
limit the throughput loss across a router, users were forced into
topologies where servers and clients needed to remain within the same
broadcast domain.
Switches were introduced to allow the creation of Virtual Local Area
Networks (VLAN), allowing users to segment their networks without the high
costs of routers or low port count of bridges. The problems associated
with switches are typified by U.S. Pat. No. 5,521,913 issued to Gridley on
May 28, 1996, which teaches an ethernet switch using cut-through
switching. This technique merely forwards packets through the VLAN without
examining the packet validity until after the packet has been forwarded.
This technique and the current methodologies implemented in ethernet
switches do not prevent the occurrence of unnecessary and excessive
traffic across the VLAN.
Note: This technique can be applied to either cut through or store and
forward switches.
Unnecessary and excessive traffic across the VLAN not only slows down the
network but, additionally, requires each end node and computer connected
to the network to receive and analyze those packets. The result is the
overall loss of network bandwidth. The major cause of this loss is
broadcast traffic. The present invention achieves what the prior art does
not, that is, reduce the traffic across the VLANs and thereby allow the
VLAN bandwidth to be used more efficiently.
SUMMARY OF THE INVENTION
The invention provides a solution to the problem of VLAN flooding by
implementing broadcast isolation and level 3 switching at the switch level
and yet maintaining the high level of media speed required for network
applications. The invention thereby provides a solution to the problem
solved with bridges and routers, but without the cost/performance impacts
and topology constraints they introduced.
The preferred embodiment of the invention comprises a switching Application
Specific Integrated Circuit (ASIC) and a Virtual Switching Engine (VSE)
connected to a plurality of ports. The switching ASIC has a high-speed
memory table which enables it to look up addresses that it has previously
obtained and to forward unicast packets to said addresses. When the ASIC
discovers a packet that is a broadcast or unknown address packet, the
packet is forwarded to the VSE. The VSE is a CPU that makes switching
decisions outside of the ASIC. The VSE keeps track of any unknown
addresses and forwards the packet out the appropriate ports. While waiting
for an answer to the packet, the VSE marks the ASIC's table to indicate
that the originator host of the packet exists and to what port it is
connected. Once the VSE sees the response to the packet, it again marks
the ASIC's table, indicating what port the answering host is on. The VSE
answers broadcast packets by proxy for all known addresses without
forwarding any of the packets down the VLANs. This frees the VLAN
bandwidth from excessive traffic.
The preferred embodiment requires no user configuration because the
switching methodology is self-adaptive to the network in which it is
inserted. In addition, the functions of the switching ASIC may also be
performed in software.
The present invention has the ability to replace router functions such as
level 3 switching and broadcast control. It is also compatible with
Internetwork Packet (IP) and Internetwork Packet Exchange (IPX) networks.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a functional representation of a switch according to the
invention;
FIG. 2 is a flow diagram of the ASIC packet switching function according to
the invention;
FIG. 3 illustrates a single switch implementing broadcast isolation using
IP protocol according to the invention;
FIG. 4 is a switch infrastructure connected to a router using multi-netting
according to the invention;
FIG. 5 illustrates a single switch having multiple VLANs using IP protocol
according to the invention;
FIG. 6 illustrates a multi-switch environment with a segmented VLAN
according to the invention;
FIG. 7 illustrates a switch in an IPX network according to the invention;
FIG. 8 illustrates an IP switch to router connection according to the
invention;
FIG. 9 illustrates an IPX switch to router connection according to the
invention;
FIG. 10 illustrates an illegal switch/router configuration according to the
invention;
FIG. 11 illustrates broadcast protection across a VLAN according to the
invention;
FIG. 12 illustrates a use of a spanning tree protocol in a loop according
to the invention; and
FIG. 13 illustrates a loop without a spanning tree protocol according to
the invention.
DETAILED DESCRIPTION OF THE INVENTION
Referring to FIGS. 1 and 2, the invention comprises a switching Application
Specific Integrated Circuit (ASIC) 101 and a Virtual Switching Engine
(VSE) 102 connected to a plurality of ports 105. The switching ASIC 101
performs level 3 201 and unicast (level 2) switching 203. The ASIC 101 has
a high-speed memory lookup table 104 which enables it to look up Media
Access Control (MAC) addresses that it has previously obtained and to
forward unicast packets to said addresses 204. When the ASIC 101 discovers
a packet that is a broadcast or unknown address packet 203, the packet is
forwarded to the VSE 102. The VSE 102 is a CPU that makes switching
decisions outside of the ASIC 101 and looks at the level 3 address of a
packet. The VSE 102 keeps track of any unknown addresses in a cache 103
and forwards the packet back to the ASIC 101 for delivery out the
appropriate ports 202. While waiting for an answer to the packet, the VSE
102 marks the ASIC's 101 lookup table 104 to indicate that the originator
host of the packet exists and to what port it is connected. Once the VSE
102 sees the response to the packet, it again marks the ASIC's 101 lookup
table 104, indicating what port the answering host is on. The VSE 102
answers broadcast packets by proxy for all known addresses without
forwarding any of the packets down the VLANs.
Protocols such as IP and IPX will use broadcast packets so that end nodes
can discover where other nodes are. This enables the nodes to send unicast
traffic directed to the appropriate end node. The present invention tracks
those broadcasts and once it has learned where the end nodes are, it will
proxy respond to any subsequent broadcast packets to prevent that
broadcast from going any farther out into the network. The broadcast
packets therefore stay on the single segment that is directly connected to
the switch. This is a vast improvement over what a normal bridge can do.
Although the network concepts described herein refer to Ethernet
protocols, one skilled in the art can readily appreciate that these
concepts are readily applicable to other types of networks.
The ASIC has a high-speed memory table that contains the specific values of
the type of packets that are sent to the VSE. The flexibility of the
system allows the ASIC to be configured to identify other types of packets
as well as broadcast packets.
Although the switching functions of the invention have been described in
the form of an ASIC, one skilled in the art can readily appreciate that
the switching ASIC functions may also be implemented in software using a
high-speed CPU.
The operation of the present invention is further illustrated through the
following descriptions and scenarios.
Broadcast Isolation
IP ARP
Address Resolution Protocol (ARP) packets are broadcast packets in IP
protocol and used to directly find the MAC address of a target host. The
broadcast ARP contains a MAC address of the source and the level 3 address
of the target. When the target receives the ARP packet, it responds with a
unicast packet directed at the initiator of the request. Both hosts then
know each other's MAC address and can send unicast packets to each other.
The following scenario will explain how a switch that intercepts these
broadcast packets can reduce the overall network broadcast traffic. This
first scenario assumes that the switch and Hosts have just been booted and
none of the network elements knows about the other.
Turning to FIG. 3, assume that HOST A 301 wishes to talk with HOST B 302.
To learn HOST B's 302 MAC address, HOST A 301 will send out a broadcast
ARP. This packet contains the source MAC address of HOST A 301, a
broadcast destination MAC address and level 3 addresses for the source and
destination. The switch 306 will then learn that HOST A 301 is on Port 1
and can save all the level 2 and 3 information about HOST A 301 in its ARP
cache. Since the switch 306 does not know where HOST B 302 is at this time
it must flood the ARP packet out all ports. HOST B 302 will receive the
packet (as will all other hosts connected to the switch), it will respond
to the ARP request with a unicast packet directed to HOST A 301 via the
switch 306. When this reply is received by the switch 306 it will forward
it directly to HOST A 301. This first packet from HOST B 302 will be
monitored by the switch 306 VSE so that it can fill in the ARP cache
information about HOST B 302. HOST A 301 can now send unicast packets to
HOST B 302 and vice versa. From the switch's 306 point of view, only the
switching ASIC is involved, (the switch 306 VSE is freed up for other
tasks). At this point no reduction in broadcasts has occurred, this would
be true for a router also. HOST C 303 now attempts to talk with HOST B
302. As with HOST A 301, HOST C 303 will send out a broadcast ARP request
and, as before, the switch 306 will learn the level 2 and 3 information
about HOST C 303. However this time when the switch 306 analyzes the ARP
broadcast it will find that it already knows about HOST B 302 and can
proxy reply for HOST B 302. Unlike a router proxy reply, the reply from
the switch 306 will carry the MAC address of HOST B 302, not the MAC
address of the switch 306. From HOST C's 303 point of view it will appear
as though HOST B 302 issued the reply. Host C 303 can now send unicast
packets directed to HOST B 302 who in turn can reply since the unicast
packet carried HOST C's 303 MAC address. The network overhead for the
broadcast packet has been removed.
Note that Host A does not receive the ARP request from HOST C, and,
depending on HOST A's IP implementation, may not learn HOST C's MAC
address from the unicast packet it does receive. In this case, HOST A
sends an ARP request out for HOST C. The switch proxies a reply and HOST A
is then able to send unicast packets back to HOST C. This detail is not
repeated in all subsequent examples but is raised here for completeness.
In this scenario, assume that the switching ASIC sends all broadcast
packets up to the switch VSE and nowhere else. The switch VSE is then
responsible for forwarding the broadcast. Assume also that a copy of the
unicast reply gets sent to the VSE for learning purposes, but the
switching ASIC can also forward the unicast reply and remove the need for
the switch VSE to perform this function. This method does have a problem
when the host system has a dual stack (e.g. IP and IPX). If the host MAC
address had already been learned from previous IPX packets then the
switching ASIC would not know to pass the ARP reply back up to the switch
VSE if it only looks at MAC addresses. The switching ASIC could pass all
ARPs up to the switch VSE or the switch VSE could receive the ARP
broadcast, but instead of forwarding out the ARP request as is, the switch
could send out the broadcast ARP with its IP and MAC address as the
source. In this manner the switch is assured of receiving the ARP reply
and thereby learns the information in the ARP reply.
In practice, a switch could forward the ARP request as is and mark the
cache entry for the target of the ARP request as unresolved. If a reply to
the ARP is not seen by the VSE before another ARP request for the same
host is received by the switch, then the switch could send out its own ARP
request as described. This removes the need for the switch always sending
out its own ARP request. Note: By waiting for a subsequent ARP to the same
HOST, no timeout is needed for an entry in the unnresolved state. The
switch would need to keep track of the pending ARP request from the
original source so that it could construct the appropriate response when
the reply is received. The proxy responses when addresses are known, work
as described above. This also solves the problem of needing to send out an
ARP request with a new encapsulation type if the host was already known,
but only with a different encapsulation. For the rest of this document the
term forwarding the ARP will be used to refer to either generating a new
ARP, or to just forward the original ARP request with the understanding
that generating a new ARP can solve the problems described above.
This particular mechanism works very well in the server client scenario
where clients initiate a conversation to a server. After the first client
initiates a conversation with the server, all future client broadcasts can
be replied to by the switch and although a given client's ARP cache may
time out, the chances are good that sufficient traffic has occurred to
prevent the server ARP cache entry in the switch from timing out. If it
did, then the traffic was probably very light and the occasional broadcast
will not matter.
The switch must keep track of the encapsulations used in its ARP cache. If
the encapsulations do not match, the switch should NOT proxy reply if it
knows the target host, instead it should ARP for the target host with the
new encapsulation. If the target host understands the encapsulation it
will reply accordingly. Although the broadcast was not blocked in this
case it was limited to only going out the port that the host was on.
The ARP cache built up by the switch should time out (in the same manner as
hosts and routers) if packets are not passed to the host within some fixed
time. The timeout needs to be tied to the MAC address time out mechanism
used with the switching ASIC because the switch VSE does not see any
unicast traffic after the initial exchange. Note: A long fixed timeout may
be needed for the ARP timeouts of hosts that are on the far side of a
router relative to the switch. The MAC address timeout should not be used
in this case, since all the hosts would appear to have the same MAC
address (the router's MAC address) from the switch's point of view.
IP RIP and other Routing Protocols
When routers are connected to the network they typically use MAC level
broadcast packets to distribute their routing information. These packets
are required between routers and are sent periodically. Routing
information protocol (RIP) packets are transmitted every 30 seconds, but
typically hosts do not need to see them. If the switch can determine the
ports where routers are connected then it can send this type of packets
only out those ports and thus reduce this type of broadcast. The switch
can use RIP packets to determine which ports routers are on (because RIP
packets are sent out periodically) and only flood those packets on ports
they were received on. This same technique can be used to reduce OSPF
(Open Shortest Path First, another type of routing protocol) packets (OSPF
packets are actually multicast on 0.times.01005E000005 and
0.times.01005E000006 and not broadcasts; however, directing them out
router ports only can also help reduce excess network traffic).
If these packets are blocked, a switch would need to know when another
switch is connected to the port. If a switch does not know, then RIPs
could be blocked when they should not be. If each switch waits for the
other to send a RIP before it sends a RIP, then a catch 22 occurs and
neither switch would send RIP packets to each other and could break
connectivity within the network. To overcome this problem either switch to
switch ports must be configured or some type of switch to switch protocol
needs to occur. A broadcast General Server Query (GSQ) would be sent on
all ports of a switch, the reception of this packet could be used to
indicate that RIPs should be forwarded (or a simple switch-to-switch
protocol can be used, e.g., a unicast packet with a unique MAC address
known to all the switches could convey this information periodically).
In some cases there may be a need to flood these packets out ports where
routers have not been detected. For example, security requirements may
prevent some routers from sending out RIPs but they still may want to
receive routing information from other routers. There are also some cases
where hosts will eavesdrop on routing protocol packets to learn where
gateways exist. Therefore some configuration options will be required to
override the blocking of these packets. The default with IP should be to
forward these packets and have an option to block them on ports where the
system administrator knows they are not needed.
BOOTP and DHCP
Both BOOTP and DHCP use broadcast packets so that clients that do not know
their IP address can access servers that do. BOOTP and DHCP have the same
format for broadcast requests and replies in those parts of the packet a
switch would need to examine. Therefore, what will work for BOOTP will
work for DHCP. In some cases the initial BOOTP broadcast will contain the
IP address of the target server. The switch could direct the BOOTP
broadcast out the correct port if it has previously learned the location
of the server. If either the server location is not known or the BOOTP
packet does not contain a specific server IP address (i.e. IP
destination--255.255.255.255), then the switch will be forced to broadcast
the packet out all ports of the VLAN. To reply, the server can either send
a unicast packet or a broadcast packet. A server that responds to a BOOTP
(or DHCP) request can send a broadcast response. To be able to recognize
which client this is for would require the switch to keep track of the
transaction ID in the BOOTP request and watch for it in the broadcast
reply. This added effort may not be worthwhile to stop this one extra
broadcast. If the transaction ID was kept it would need to be cleared when
either the broadcast reply came through, the reply could be a unicast
however and the switch VSE would not see the packet if the server had
previously been found. A timer would be needed to clear the transaction
ID. Once the initial packets have been exchanged, further traffic should
continue via unicast messages.
IP Router Connections
IP broadcast isolation works within a single IP subnet in the simple case.
Hosts within this subnet must go through a router to communicate outside
the subnet. However, if multiple IP subnets are put in the same VLAN
domain (i.e. the domain is multi-netted), it is possible to avoid using
routing to communicate between the subnets. As in the simple case,
broadcasts can be limited using the broadcast isolation already described.
The hosts in this domain must be aware of multi-netting if they are to
take advantage of the performance offered by a switching infrastructure.
The term multi-net aware is used here to mean that a host must be able to
send an ARP packet out on its network interface and direct it towards the
target host even if that host is on another subnet (i.e. it must not look
for an external gateway to send the packet to). For a host to do this it
must either treat all subnets the same (i.e. it assumes that a router will
proxy for the target if necessary), or it must be its own default gateway.
To be its own gateway either requires the user to reconfigure the host to
perform this function or else it must receive an internet control message
protocol (ICMP) redirect from the gateway it tries to use, and the
redirect must indicate the host as its own default gateway. Here the
switch could be configured to be the default gateway and it could pass the
ICMP redirect. If the host is not multi-net aware then it would still need
to send off subnet packets to a router. This router in turn would send the
packets back into the switching infrastructure using the router's MAC
address as the source MAC address in the packet. Doing this removes the
benefit of the switching infrastructure since all packets must now pass
through the router, connectivity is retained however and this allows
non-multi-net aware hosts to co-exist with multi-net aware hosts.
A router connected to this infrastructure must have its interface
multi-netted with all the subnets in the switching domain, this router
must also be able to proxy ARP for hosts that are on the other side of the
router from the switching network. In the level 3 switching section, an
alternative is discussed if the router does not support multi-netting.
Using this multi-netting method it should be possible to eliminate routers
except where firewalling or WAN connectivity is needed. Broadcast
isolation will provide the reduction in broadcasts even in the
multi-netted environment. The only slight advantage a router may have is
that its routing protocol could indicate which ports to send an initial
ARP out on to locate a host for the first time. The switch will broadcast
the initial ARP out on all ports. FIG. 4 shows how a switch infrastructure
might connected to a router using multi-netting. The router 401 is
directly connected to switch 402 and is multi-netted with IP addresses
10.1.8.x, 10.2.8.x, 11.1.8.x and 11.2.8.x. Switch 402 is connected to
switches 403 and 404. Switch 403 has IP addresses 10.1.8.x and 10.2.8.x
and switch 404 has IP addresses 11.1.8.x and 11.2.8.x.
Tunneling through VLANs
Without doing full level 3 switching, it is possible to do some limited
level 3 switching within a single switch configured with multiple VLANs
and broadcast isolation. Broadcast isolation is performed as described
above within each VLAN. When an IP ARP broadcast is for an IP address in
another VLAN, the switch CPU can send the appropriate ARP on the other
VLAN. When the ARP response is received, the source VLAN mask for both the
initiator and responder includes the port number of responder and
initiator, respectively. This allows unicast traffic between the two
systems to be switched via the switching ASIC. Although this technique
requires some manual configuration of the IP addresses (and subnet masks)
of the VLANs, it preserves the VLAN boundaries for unknown and non IP
addresses (i.e. the default VLAN mask for the port only includes ports in
the VLAN). Software filtering can be done on the broadcast packets to
disallow VLAN tunneling of specific subnets configured by the user. This
technique requires no switch to switch protocol and only a small amount of
additional code added to the broadcast isolation code. As with the
multi-netted case above, the hosts that are allowed to do VLAN tunneling
will need to be their own default gateway so that they can directly ARP
for the host they are looking for. Connected routers will also need to be
multi-netted since no Router interface is defined in the switch at this
point.
Summary of Broadcast Isolation with IP
The following is a summary of the switch function needed to accomplish IP
broadcast isolation. The term VSE is used below and means the CPU that
makes switching decisions outside of the Switching ASIC. This VSE may be a
CPU on board the switch or an external card plugged into the switch.
The switch VSE must intercept all broadcast packets and analyze ARP
packets. (Non-ARP IP broadcasts should be flooded within the VLAN as
before. This may or may not be done automatically by the switching ASIC,
if a great number of non-ARP broadcasts are expected using the switching
ASIC to pass only ARPs to the VSE could greatly off-load the VSE)
The VSE must keep an ARP cache that stores a table relating host MAC
address, IP address, supported encapsulation types and port number.
The VSE must be able to direct packets out a given port or ports (e.g.
broadcast packets that are flooded or forwarded).
The first time a new source is heard from (i.e. ARP request and reply) the
switching ASIC must pass the packet up to the switch VSE, in the case of a
unicast destination the switching ASIC can also forward the packet so the
VSE won't need to.
When a target host issues a unicast reply with a new encapsulation type,
the switching ASIC should pass the packet up to the VSE as in the case of
a new source address so that the ARP cache can be updated with the
additional encapsulation type. As with the new source scenario the ASIC
can also forward the packet. Another way to handle this would be to allow
all ARP requests, unicast or broadcasts, to be sent to the VSE, this would
solve the problem and not require the ASIC to keep track of encapsulation
types. Another solution, using software only, would be to have the VSE
test for a new encapsulation type. To do this the VSE would send out an
ARP request using its IP and MAC address, in this way the switch VSE is
guaranteed to receive the ARP response and can then pass the information
to the requesting host.
The VSE must be able to proxy ARP for a host if the encapsulations match,
if not it must test for the allowed encapsulation type. The switch must
not proxy reply if the target host is on the same port as the initiator of
the ARP.
When RIP packets and other types of multicast and routing protocol packets
are received, they should only be flooded out ports that these type of
packets have been received on (of course a given packet should never go
out a port it was received on). Override configuration options for this
feature need to be provided for some special cases.
For BOOTP and DHCP broadcast requests, the switch can examine the packet
for a destination IP address and, if found, send it out the correct port.
Optionally the switch could keep track of the transaction ID in the BOOTP
request and use this to direct a broadcast BOOTP reply.
If multi-netted switch domains are supported, the switch must be able to
send ICMP redirects to the host that sent a packet for a host on another
subnet but directed to the switch MAC address (i.e. the host used the
switch as a default gateway and the switch redirects the host to be its
own default gateway, which could possibly reduce the amount of host
reconfiguration necessary in a multi-netted environment).
The ARP cache timeout should be tied to the MAC address timeout of the
switching ASIC with the exception mentioned previously of a Host on the
far side of a router relative to the switch.
On a unicast packet were the source is known but the destination is not
known the switching ASIC should flood the packet out the VLAN and not
inform the VSE. This is should be a temporary condition that only exists
when a switch has been rebooted and the end host systems still know about
each other from before the switch was rebooted.
Within a switch VLAN to VLAN tunneling can be done for additional
flexibility.
Broadcast Isolation with IPX
Client Server interactions with Broadcast Isolation
In the broadcast isolation, the switch will send out a GSQ on each port and
cache the responses. The switch will cache all the service advertising
protocol (SAP) information (comparable to a router). However, unlike a
router, the switch will not consolidate SAPs. The switch will rebroadcast
the individual SAP packets. The source mac address will be left unchanged
(i.e. the source MAC address will be the original server's MAC address).
This allows all the switches to learn server MAC addresses needed for
broadcast isolation. When a switch responds to a GSQ, it will need to send
out a series of SAPs. From the sender's point of view it will look as if
several individual servers responded.
When a client issues a Nearest Server Query (NSQ), the switch will cache
the client MAC address in the switch table and respond assuming no local
servers exist on the switch port. Unlike the router however, at this point
the switch will not reply with the switch MAC address, the switch will put
in the actual MAC address of the server (It could just as well respond
with the VLAN MAC address since the clients seem to ignore this
information anyway). The client then sends the broadcast RIP request and
the switch will respond using the MAC address of the server (the server's
MAC address was learned from the SAP response). Now all unicast packets to
and from the client and server will take place via normal switching.
Neither the internal network number of the server nor the IPX address of
the client will be used by the switch to determine how to get the unicast
packets to the client or server. If multiple equivalent servers exist, the
switch should probably use a round robin scheme, or count of client server
connections or current traffic load to a given server to decide which
server to tell the clients about, in this way one server won't get all the
client connections. The user could also configure different VLANs within
the switch to isolate specific clients with specific servers.
The switch responding to the broadcast NSQ and RIP is one of the ways that
broadcast isolation reduces the amount of broadcast traffic as compared to
a pure bridged environment.
The switch will send periodic SAPs (in the same manner as a router)
whenever they are received and no actual SAP and/or RIP timer in the
switch is required. These packets are only used by other broadcast
isolation switches, routers and servers. Therefore, further broadcast
reduction occurs if the switch only sends SAPs out ports from which it
received SAPs or a GSQ. Broadcast RIP response packets only need to be
sent out ports that have routers connected (i.e. ports where broadcast RIP
responses have been received). An override may be needed to allow RIPs and
SAPs to be propagated out ports that did not send them out, should a
listen-only router/server exist on those ports (e.g. old jet direct cards
would need this information passed).
Other possible ways to reduce IPX broadcast traffic includes server
configuration to use triggered SAPs rather than sending them out ever 60
seconds, using filtering in the switch to limit some servers/server types
to specific portions of the network (this is also a security enhancement)
or the reduction of the number of encapsulations required in the network
(a duplicate SAP would be sent out for each supported encapsulation).
For devices such as print servers, the device acts as a client to the file
server. It connects to the file server at boot up just as a client would.
When a regular client wants to access the print server, it sends its
request to the file server that it connected to. In some cases the file
server is also the print server.
A timeout is needed for the client/server addresses if no packets are
received from them for an extended time period. The timeout should be tied
to the MAC address timeout using the timeout mechanisms supported by the
switching ASIC because the unicast packets are not seen by the switch VSE.
Multi-netting in IPX
Multi-netting is allowed in IPX, but each multi-netted network must use a
different encapsulation type. This limits the number of multi-netted
networks to four. The allowed encapsulation types are sub-network access
protocol (SNAP), Ethernet, 802.2 and Novell (also called 802.3 Raw). The
switch cannot do encapsulation translation on any unicast packets.
Therefore, if multiple IPX networks are configured in the same switch
domain (multi-netted), the switch must only respond to an NSQ if the
server it is proxy responding for supports the correct encapsulation type.
In a router situation, a client could be using 802.2 encapsulation and the
server could be using SNAP encapsulation. The router would translate all
unicast packets between the two systems and allow them to talk. However,
in the switch situation, this cannot be done because unicast packets are
sent via level 2 switching. The best choice is to send a GSQ for each
encapsulation type out all ports when the switch first comes up. The VSE
would then cache the internal network number, MAC address and
encapsulation types in the responses from each server, and respond to
client NSQ's and RIPs only with servers that have the same encapsulation
type as the client. Most modern servers understand all the encapsulation
types and this should not be much of a limitation. This will require the
users to either configure all their clients/preferred server combinations
with the same encapsulation or to allow their servers to support all the
needed encapsulation types.
If all four encapsulations are supported on a given server, then the port
that server is on will need to be multi-netted with four IPX addresses.
The periodic SAPs are also encapsulated, and a given SAP packet can only
include SAPs with the same encapsulation as that SAP. For example, if
server A had all four encapsulations and server B only responded to the
GSQ with the 802.2 encapsulation, then all four encapsulations can be used
for SAP packets including server A, but only SAP packets with 802.2
encapsulation can include server B. In general, multi-netting IPX networks
is not a good idea because it will increase the amount of broadcast
traffic passed throughout the network (the same would be true for a
router).
IPX Router Connections
As with IP, IPX broadcast isolation works within a single VLAN. This makes
broadcast isolation completely transparent to router connections. Although
it is possible to have multiple IPX networks within the VLAN it is very
limited since a maximum of four IPX addresses could be configured since
each one would need a different encapsulation. Since no encapsulation
translation can be done, server client communication will be limited to
those that support like encapsulations. In general if multiple IPX
networks are needed the communication between them will require a router.
On the brighter side, IPX clients don't know or care about the IPX network
number. The IPX network number is only used to determine the best path to
pass packets from a server to a client through a routed environment. The
network number is determined by routers/servers. From a broadcast
reduction point of view there is no real advantage to putting servers in
different IPX networks. Therefore if the user is willing to configure all
the servers to use the same IPX network the switch could limit broadcast
throughout the entire domain. Router broadcast limitation requires the
network boundaries, the switch does not.
However, there still may be reasons to use a router. For example, if
security is required, the router will look at all broadcast and unicast
traffic and can filter those packets based on the policies configured in
the router. When Wan connectivity is required, a router will be needed
because the remote site should be on another IPX network. By using
different network numbers, groups of clients can be associated with
specific servers (to some extent the switch with broadcast isolation can
do the same thing using multi-netting and different encapsulations to
group clients and servers). Another way for clients to group with specific
servers is for clients to request a specific server, if the client is
configured to do so.
IPX Packet Type 20
For some protocols (such as NetBIOS) a method is needed to propagate
broadcasts throughout the entire IPX network. IPX packet type 20 is used
for this purpose and should be flooded throughout the VLAN. It may be
desirable to add a configuration option that allows the user to block
their propagation on some ports.
Summary of Broadcast Isolation with IPX
The following is a summary of the switch functions needed to accomplish IPX
broadcast Isolation.
The switch VSE must intercept all broadcast packets. The packets to analyze
will include GSQs, NSQs, RIPs and SAPs.
The VSE must issue a GSQ at boot up to learn about the available servers.
The information in SAP packets passed back must be cached. This
information includes the server internal network number, encapsulation
type and server MAC address.
The switch must respond to NSQ packets from clients with the internal
network number and MAC address of the nearest server whose encapsulation
types match unless a server with the appropriate encapsulation type exists
on the port that the request came in on (servers with equal cost should
probably be chosen in fashion such that the same server is to not always
used).
The switch must be able to respond to a broadcast RIP request with the MAC
address of the server returned in the response to a previous NSQ.
The VSE must be able to direct packets out a given port or ports in the
same manner as with IP (e.g. broadcast packets that are flooded or
forwarded).
The first time a new source is heard from (e.g. NSQ request) the switching
ASIC must pass the packet up to the switch VSE. In the case of a unicast
destination, the switching ASIC can also forward the packet and bypass the
VSE.
RIP and SAP packets should only be flooded out ports that these type of
packets have been received on (of course a given packet should never go
out a port it was received on). Override configuration options for this
feature need to be provided for some special cases. A port that has
received a GSQ should also send out SAP packets.
SAP packets must be sent out when received. However, unlike a router, these
packets cannot be consolidated into a single packet containing up to seven
SAPs. This is necessary because the MAC addresses for the individual
servers must be maintained. Possible configuration options may be added to
send out SAPs infrequently or on a triggered update basis. The switch will
need to send out a sequence of SAPs when a GSQ is received because it
cannot consolidate them, the only exception occurs with SAPs from the same
MAC address which could be consolidated.
The client and server address timeouts should be tied to the MAC address
timeout mechanism.
Diagnostic packets should be responded to and flooded.
IPX Type 20 packets should be flooded.
If multi-netted switch domains are supported, the switch must be able to
send a GSQ with all encapsulation types to learn which encapsulations the
different servers support. Only clients with the same encapsulation type
as the servers can connect. For a unicast packet where the source is known
but the destination is not known, the switching ASIC should flood the
packet out the VLAN and not inform the VSE. This is should be a temporary
condition that only exists when a switch has been rebooted and the end
host systems knew about each other before the switch was rebooted.
Passive verses Active Broadcast Isolation
The switch must first know the MAC address of the target host to perform
the proxy functions and limit the broadcast packets. A switch learns the
MAC addresses of all hosts connected to a given port by eavesdropping on
the packets received on that port. This requires no protocol and a given
switch will only learn about MAC addresses that it has seen go by. This
passive method of learning is very easy to implement and is completely
transparent to the user. However, if several switches exist in the
network, it is quite possible for one switch to learn about MAC addresses
that another switch has not. In these cases it is possible for broadcasts
to be forwarded that would not necessarily be needed if the switches had
passed around their information. However, as time progresses and more MAC
addresses are passively learned by the switches, these excess broadcasts
would become less and less frequent (because ARP caches would time out,
the active passing of ARP information would always have fewer ARP
broadcasts | | |
