A Virtual Local Area Network (VLAN) allows you to logically segment a Local Area Network (LAN) into different broadcast domains. In scenarios where sensitive data may be broadcast on a network, VLANs can be created to enhance security by designating a broadcast to a specific VLAN. Only users that belong to a VLAN are able to access and manipulate the data on that VLAN. VLANs can also be used to enhance performance by reducing the need to send broadcasts and multicasts to unnecessary destinations.
Multicast TV VLANs enable multicast transmissions to subscribers who are not on the same data VLAN without replicating the multicast transmission frames for each subscriber VLAN. Subscribers who are not on the same data VLAN and are connected to the device with different VLAN ID membership can share the same multicast stream by joining the ports to the same Multicast VLAN ID.
Port Multicast VLAN Membership connects a port configured for customer services to a Multicast TV VLAN. Configuration of Customer Port Multicast TV VLAN Membership helps maintain security by separating the transmissions between the source and receiver. Multicast VLAN configuration enables multicast traffic from a source VLAN to be shared with subscriber VLAN.
This article provides instructions on how to configure Customer Port Multicast VLAN Membership on a switch.
Configure Customer Port to Multicast VLAN Membership on the Switch
VLAN Management > Customer Port Multicast TV VLAN > Port Multicast VLAN Membership
When Broadcast, unknown Multicast or unknown Unicast frames are received, they are duplicated, and a copy is sent to all possible egress ports. This means that in practice they are sent to all ports belonging to the relevant VLAN. In this way, one ingress frame is turned into many, creating the potential for a storm.
Storm protection enables you to limit the number of frames entering the switch and to define the types of frames that are counted towards this limit
Click Security > Storm Control.
Configure the following parameters:
Frame Configuration—Select Included (including preamble and IFG 20Bytes)to count the Broadcast, unknown Multicast, or unknown Unicast frames, or select Excluded (excluding preamble and IFG 20Bytes) to not count the Broadcast, unknown Multicast, or unknown Unicast frames.
Storm Control Rate Threshold Mode—Select the mode of the rate threshold: Packets per second or Kbits/sec.
Click Apply. The storm control parameters are defined, and the Running Configuration is updated.
To modify the storm control settings for a port, select the desired port and click Edit.
Enter the following information:
Interface—Select the port to be defined.
Storm Control—Enable or disable storm control on the port.
Unknown Unicast—Enable or disable storm control for unknown Unicast traffic. It will count unknown Unicast traffic towards the bandwidth threshold.
Storm Control Rate Threshold—Enter the maximum rate at which unknown Unicast packets can be forwarded. The default for this threshold is 10,000.
Unknown Multicast—Enable or disable storm control for unknown Multicast traffic. It will count unknown Multicast traffic towards the bandwidth threshold.
Storm Control Rate Threshold—Enter the maximum rate at which unknown Multicast packets can be forwarded. The default for this threshold is 10,000.
Broadcast—Enable or disable storm control for Broadcast traffic. It will count Broadcast traffic towards the bandwidth threshold.
Storm Control Rate Threshold—Enter the maximum rate at which Broadcast packets can be forwarded. The default for this threshold is 10,000.
Action—Select the action when the rate of Broadcast, unknown Multicast, or unknown Unicast frames is higher than the user-defined threshold. The options are:
Drop—Discard the frames received beyond the threshold.
Shutdown—Shut down the port.
Click Apply. The port’s storm control settings are modified, and the Running Configuration is updated.
Whenever changes are made to Cisco SG the running configuration must be copied and saved as the startup configuration or the changes will not persist if the switch is rebooted.
Copy/Save Configuration
Configuring IGMP Snooping
IGMP Snooping must be enabled on the switch to manage the flow of registered multicast traffic. Once IGMP Snooping is enabled multicast groups will be registered on the switch when receivers request to join multicast groups. Multicast traffic destined for registered multicast groups will then be forwarded only to interfaces on which group-member receivers are attached.
1) UnderMulticast > Properties enable the Bridge Multicast Filtering Status setting (disabled by default) and click Apply:
IGMP Snooping
2) Under Multicast > IPv4 Multicast Configuration > IGMP Snooping enable the IGMP Snooping Status setting (disabled by default) and click Apply:
IPv4 Multicast Configuration
3) Under Multicast > IPv4 Multicast Configuration > IGMP Snoopingselect the VLAN you want to enable IGMP Snooping on and click Edit:
VLAN you want to enable IGMP Snooping
4) In the Edit IGMP Snooping Settings popup window (popups need to be enabled in the browser) enable the IGMP Snooping Status setting and click Apply:
IGMP Snooping Status
5) Confirm that the IGMP Snooping Operation Status shown for the VLAN under Multicast > IPv4 Multicast Configuration > IGMP Snoopingnow says “Enabled”:
IGMP Snooping Operation Status
6) Under Multicast > Unregistered Multicastconfigure all interfaces for Filtering (set to Forwarding by default) and click Apply. This prevents unregistered multicast (i.e., streams from encoded that are not being requested by any decoders) from flooding to any interfaces.
Unregistered Multicast
Configuring IGMP Querier
Each VLAN that manages multicast traffic with IGMP Snooping requires an IGMP Querier. The IGMP Querier periodically queries the VLAN to confirm that receivers want to maintain memberships with multicast groups. If multiple Queriers are enabled on the same VLAN an automatic election process will occur – the Querier with the lowest IP will win and all other Queriers will stop sending queries. The position of the Querier in a multi-switch environment should be carefully considered, especially for a high-bandwidth multicast application, as all multicast traffic always flows towards the Querier. Without a Querier the multicast group memberships on IGMP Snooping switches will timeout after a set period of time (typically 260 seconds) requiring the receivers to then rejoin the multicast group in order to start receiving multicast traffic again.
1) Under Multicast > IPv4 Multicast Configuration > IGMP Snooping confirm that the IGMP Querier Status setting is enabled (enabled by default). If it is disabled, enable it:
IGMP Querier Status
2) Under Multicast > IPv4 Multicast Configuration > IGMP Snooping select the VLAN you want to enable IGMP Querier on and click Edit:
IGMP Querier
3) In the Edit IGMP Snooping Settings popup window enable the IGMP Querier Status setting (disabled by default), confirm that the IGMP Querier Version setting is configured for v2 (v2 is default), and click Apply.
Querier Status
Configuring Non-Querier in Multi-Switch Environment
Any Cisco SG switches in a multi-switch IGMP Snooping environment that are not intended to be the Querier should still be configured to enable IGMP Snooping. In addition it is important that the non-Querier switch knows which interface connects to the Querier so multicast traffic can be forwarded appropriately – all multicast traffic needs to flow towards the Querier via the Multicast Router (mrouter) Port. The Multicast Router Port can be dynamically learned (by listening for Queries) or statically assigned. By default, Cisco SG will forward unregistered multicast traffic to all interfaces and the filtering/forwarding of unregistered multicast traffic is a per-interface setting. If the unregistered multicast filtering setting is applied to an interface which is also the Multicast Router Port the Cisco SG will not forward unregistered traffic to the mrouter port. This behaviour of not forwarding all multicast traffic to the Querier is at odds with the requirements defined in the IGMP standard in that all multicast traffic should always flow towards the Querier so can cause issues if sharing multicast traffic between sources and receivers connected to different switches in a multi-switch environment.
1) Under Multicast > IPv4 Multicast Configuration > IGMP Snooping disable the IGMP Querier Status setting (enabled by default) and click Apply. Disabling this global setting overrides the IGMP Querier Status settings of the individual VLAN’s:
IGMP Snooping disable
2) Under Multicast > Multicast Port confirm that the switch has discovered the Querier on one of the interfaces, listed as Dynamic. Note that it may take some time for this multicast router port to be discovered:
Multicast Router Port
The Multicast Router Port can be statically configured by selecting “Static” however this configuration should only be required recommended if switches from different vendors are used in the same network environment and they are not able to auto-discover the IGMP Querier.
If the Multicast Router Port is not able to be dynamically discovered this could indicate that there is no IGMP Querier configured on the network. In a single-switch environment the IGMP Querier feature must be enabled in order to prevent group-membership timeouts but in a multi-switch environment an IGMP Querier is also required in order for multicast traffic to flow from one IGMP Snooping enabled switch to another.
3) Now that the Multicast Router Port has been configured (either dynamically discovered or statically assigned) under Multicast > Unregistered Multicast configure the same interface to Forwarding. All interfaces that are not Multicast Router Ports should be set toFiltering:
Unregistered Multicast
This is done because the Unregistered Multicast setting on the Cisco SG300/SG500 switches overrides the default behaviour of how switches are supposed to handle the flow of multicast traffic to Multicast Router Ports in that all multicast traffic should always be forwarded to the Multicast Router Port (i.e., towards the Querier).
Configuring Immediate Leave
When a receiver leaves a multicast group the traffic flowing to the interface destined for that group does not stop straight away. IGMP allows time for the Querier to confirm that other receivers, possibly attached to the same interface and joined to the same multicast group, do not want to maintain a connection to the group once a receiver leaves the group before the forwarding of traffic for that group on that interface ceases. For high-bandwidth multicast applications, where the stream size can easily exceed half the available bandwidth, the Immediate Leave feature should be enabled to prevent data saturation on interfaces where a receiver leaves one group and then immediately joins another group. If you are in a multi switch environment, Immediate Leave feature should be disabled on the core switch, this will prevent drop outs of video on downstream switches if two end points are on the same stream.
1) Under Multicast > IPv4 Multicast Configuration > IGMP Snooping select the VLAN you want to enable IGMP Snooping on and click Edit:
IGMP Snooping
2) In the Edit IGMP Snooping Settingspopup window enable the Immediate Leave setting and click Apply:
I have the latest version of Ubuntu Linux LTS server. How do I update Ubuntu Linux for security and application fix/upgrades using ssh command line? How can I install updates via command line option?
Ubuntu Linux server – Install updates via apt-get command line
The commands are as follows:
apt-get update: Update is used to resynchronize the package index files from their sources on Ubuntu Linux via the Internet.
apt-get upgrade: Upgrade is used to install the newest versions of all packages currently installed on the Ubuntu system.
apt-get install package-name: Install is followed by one or more packages desired for installation. If package is already installed it will try to update to latest version.
First, open the Terminal application and type following two commands (Application > Accessories > Terminal).
Get updated software list for Ubuntu, enter:
$ sudo apt-get update
$ sudo apt-get upgrade
Please note that above two commands will fetch files from the Internets or local mirrors. The location of update pages is specified in /etc/apt/sources.list (repositories). You need NOT make any changes to this file until and unless you need extra repositories for your setup.
INSTALL KERNEL UPDATES ON A UBUNTU LTS SERVER
Type the following apt-get command:
$ sudo apt-get dist-upgrade
The dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages; apt-get has a “smart” conflict resolution system, and it will attempt to upgrade the most important packages at the expense of less important ones if necessary. So, dist-upgrade command may remove some packages. The /etc/apt/sources.list file contains a list of locations from which to retrieve desired package files.
In this tutorial, we’ll be building a stylish landing page with Elementor. Made 100% in Elementor, in this A to Z tutorial you’ll learn: * Creating a page * Building a WordPress menu * Using sections and columns * Adding widgets * Build a complete landing page!
FAQ Q: Can I dist-upgrade Proxmox VE 5.4 to 6.0 with apt? A: Please follow the upgrade instructions exactly, as there is a major version bump of corosync (2.x to 3.x) https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0
This is (already) the third blog post about Proxmox, and it’s what about you could do on standalone Proxmox instances. When you don’t use Proxmox clustering features, you may want to stop some running services, polluting your system logs.
This has to be considered very experimental and don’t expect replication nor high-availability functionalities to work once you have disabled these services.
