Page 261 / 998 Scroll up to view Page 256 - 260
VLAN command reference
VLAN
2-111
iMG/RG Software Reference Manual (Switching)
VLAN information
---------------------------------------------
Name: default
Identifier
1
Status
static
802.1p Priority
7
Untagged port(s)
lan3, lan2
Tagged port(s)
cpu
Name: voip
Identifier
10
Status
static
802.1p Priority
7
Untagged port(s)
lan2
Tagged port(s)
lan1
---------------------------------------------
See also
VLAN ADD PORT
VLAN ADD VID
2.4.4.1.25 VLAN TRANSLATE
Syntax
VLAN TRANSLATE<vlanname> <vlanid>
Description
This command will create a software base VLAN translation. This process can be CPU
intensive and should not be used for video:
VLAN Name: The name of the VLAN.
VLAN ID: The numerical VLAN identifier of the VLAN (VID).
Untagged port(s): A list of untagged ports that belong to the VLAN.
Tagged port(s): A list of tagged ports that belong to the VLAN.
Example
--> vlan create wan_net 20
--> vlan create lan_net 20
--> vlan add interface wan_net
wan frame tagged
--> vlan add interface lan_net
lan1 frame untagged
--> vlan add interface wan_net
cpu frame tagged
--> vlan add interface lan_net
cpu frame tagged
--> vlan translate lan_net 20
--> vlan translate wan_net 10
This command defines a new VLAN and specifies the corresponding VLAN identifier
(VID).
Page 262 / 998
VLAN
VLAN command reference
iMG/RG Software Reference Manual (Switching)
2-112
The VLAN name can be 16 characters length; it cannot start with a digit and cannot con-
tain dots '.' or the slash symbols '/'.
Options
The following table gives the range of values for each option that can be specified with
this command and a default value (if applicable).
Name
Description
Default Value
Vlanname
An arbitrary name that identifies the VLAN. The name
must not be already in use for another VLAN. The VLAN
name can be at most 16 chars long.
N/A
Vlanid
The VLANID parameter specifies a unique VLAN Identi-
fier (VID) for the VLAN.
If tagged ports are added to this VLAN, the specified VID
is used in the VID field of the tag in outgoing frames.
If untagged ports are added to this VLAN, the specified
VID only acts as an identifier for the VLAN in the For-
warding Database. The default port based VLAN has a VID
of 1.
N/A
Page 263 / 998
Multicasting overview
IGMP snooping
3-1
iMG/RG Software Reference Manual (IGMP)
3. IGMP
3.1
IGMP snooping
3.1.1
Multicasting overview
Multicasting is a technique developed to send packets from one location in the Internet to many other locations,
without any unnecessary packet duplication. In multicasting, one packet is sent from a source and is replicated as
needed in the network to reach as many end-users as necessary.
The concept of a group is crucial to multicasting. Every multicast stream requires a multicast group; the sender
(or source) transmits to the group address, and only members of the group can receive the multicast data. A
group is defined by a Class D address.
Multicasting is useful because it conserves bandwidth by replicating packets as needed within the network,
thereby not transmitting unnecessary packets. Multicasting is the most economical technique for sending a
packet stream (which could be audio, video, or data) from one location to many other locations on the Internet
simultaneously.
Of course, multicasting has to be a connectionless process. The server simply sends out its multicast UDP pack-
ets, with no idea of whom will be receiving them, and whether they get received. It would be quite impossible
for the server to have to wait for ACKs from all the recipients, and remember to retransmit to those recipients
from whom it does not receive ACKs. Apart from anything else the server does not know who the recipients
are, or how many there are.
3.1.1.1
Multicast Group addresses
A multicast stream is a stream of data whose destination address is a multicast address – i.e. an IP address with
the first byte having a value of 224 to 240. The destination address used by a stream is referred to as its Group
address. These Group Addresses, like all IP addresses, are a limited resource, and there are all sorts of rules
about who may use addresses from which address ranges.
A server sends out a multicast stream to a group multicast address but the way it is routed to the hosts that
actually want to receive it is a very different process to routing unicast packets. With unicast packets, the desti-
nation address of the packet uniquely identifies the host who should receive the packet and all the routers along
the path just need to look in their routing tables to work out which is the correct route to send the packet
down.
However, in the case of multicast, the stream is simply being sent out, with no particular knowledge of who
wants to receive it, and where the recipients are. One approach would be for every router that receives a mul-
ticast stream on one interface to just retransmit that stream out ALL its other interfaces. In that way it would
be guaranteed to eventually reach every host that might be interesting in receiving it. However, that would be an
inefficient use of bandwidth, as a lot of the time the routers would sending the streams out along paths that do
Page 264 / 998
IGMP snooping
Multicasting overview
iMG/RG Software Reference Manual (IGMP)
3-2
not contain any hosts that want to receive them. Given that the main reason for having multicasting is to make
efficient use of bandwidth, this would not be a good approach.
So, a more efficient approach is needed. This is where IGMP comes in.
3.1.1.2
IGMP protocol
IGMP (
Internet Group Management Protocol
) is the protocol whereby hosts indicate that they are interested in
receiving a particular multicast stream. When a host wants to receive a stream (in multicast jargon, this is called
joining a group
’) it sends to its local router an IGMP packet containing the address of the group it wants to join
– this is called an IGMP Membership report (sometimes called a
Join packet
).
Now, the local router is generally going to be a long way from the server that is generating the stream. So, hav-
ing received the IGMP join packet, the router then knows that it has to forward the multicast stream onto its
LAN (if it is not doing so already). However, if the router is not already receiving the multicast stream from the
server (probably many hops away) what does the router do next in order to ensure that the multicast stream
gets to it? This is achieved by elaborate process involving multicast routing protocols like PIM, DVMRP, and
MOSPF.
The IGMP packet exchange works as described in the following paragraphs.
At a certain period (default is 125 seconds), the router sends an IGMP query message onto the local LAN. The
destination address of the query message is a special ‘
all multicast groups
’ address. The purpose of this query is
to ask, “Are there any hosts on the LAN that wish to remain members of Multicast Groups?”
Hosts on the LAN receive the query, if any given host wishes to remain in a Multicast group; it sends a new
IGMP Membership report (Join message) for that group (of course some hosts may be members of more than
one group – so they will send join messages for all the groups that they are members of).
The router looks at the responses it receives to its query, and compares these to the list of Multicast streams
that it has currently registered to receive. If there are any items in that list for which it has not received query
responses, it will send a message upstream, asking to no longer receive that stream – i.e. to be ‘pruned’ from
the tree through which that stream is flowing.
In IGMP version 2, the IGMP leave message was added. So, a host can now explicitly inform its router that it
wants to leave a particular multicast group. So, the router keeps a table of how many hosts have joined particu-
lar groups, and removes hosts from the table when it receives leave messages, then it can know straight away
when there are no hosts on its LAN that are still members of a given group. So, it can ask to be pruned from
that tree straight away, rather than having to wait until the next query interval.
3.1.1.3
Multicast MAC addresses
Multicast IP addresses are Class D IP addresses. So, all IP addresses from 224.0.0.0 to 239.255.255.255 are mul-
ticast IP addresses. They are also referred to as
Group Destination Addresses
(GDA).
For each GDA there is an associated MAC address. This MAC address is formed by 01-00-5e, followed by the
last 23 bits of the GDA translated in hex. Therefore:
Page 265 / 998
IGMP snooping Functional Overview (Includes New Functionality)
IGMP snooping
3-3
iMG/RG Software Reference Manual (IGMP)
230.20.20.20 corresponds to MAC 01-00-5e-14-14-14
224.10.10.10 corresponds to MAC 01-00-5e-0a-0a-0a
Consequently, this is not a one-to-one mapping, but a one-to-many mapping:
224.10.10.10 corresponds to MAC 01-00-5e-0a-0a-0a
226.10.10.10 corresponds to MAC 01-00-5e-0a-0a-0a, as well.
It is required that when an IP multicast packet is sent onto an Ethernet, the destination MAC address of the
packet must be the MAC address that corresponds to the packet’s GDA. So, it is possible, from the destination
MAC address of a multicast packet, to know the set of values that its GDA must fall within.
3.1.2
IGMP snooping Functional Overview (Includes New Functionality)
IGMP snooping is a filtering process performed at layer 2 to reduce the amount of multicast traffic on a LAN.
It is designed to solve the problem when a multicast traffic is received from a layer 2 switch due to join requests
performed by hosts connected to some of the switch ports.
If individual hosts on the LAN (i.e. hosts connected to ports on the switches) wish to receive multicast streams,
then they will send out IGMP joins, which will get up to the multicast router; and the router will join into the
appropriate multicast trees; and the multicast flows will then reach the router, and it will forward them into the
LAN.
By default, when a switch receives a multicast packet, it must forward it out all its ports (except the port upon
which it was received). So, considering the example where only host number 1 actually requests to join a partic-
ular multicast group, what will happen is that all the hosts on the LAN will start receiving the multicast packets,
as all the switches will forward the multicast packets to all their ports.
This is rather a waste of bandwidth, and the purpose of multicasting is to make efficient use of bandwidth.
The solution to this problem is to make the layer-2 switch aware of the IGMP packets that are being passed
around. That is, although the IGMP packets are destined for the router, the layer-2 switch needs to ‘snoop’ them
as they go past. Then the layer-2 switch can know which hosts have asked to join which multicast groups, and
only forward the multicast data to the places where it really needs to go.
Because the uplink interface can be connected to the network through an ADSL port, the igmp snooping fea-
ture is extended to include also the ADSL port when it is used on RFC1483 (bridged) connections.
IGMP snooping is designed
to work in a network environment where both multicast router(s) and multicast
host(s) are present.
Note:
Multicast packets having as destination IP the following range: 224.0.0.[0-255] and 224.0.1.[0-255] will
NOT be blocked in the upstream direction since belonging to reserved traffic (OSPF, RIPv2, PIM etc…)
The goal is to construct an internal view of the multicast network based on the IGMP messages received both
from multicast router(s) and multicast host(s).

Rate

4 / 5 based on 3 votes.

Popular Allied-Telesis Models

Bookmark Our Site

Press Ctrl + D to add this site to your favorites!

Share
Top