Skip to main content

Planet vlan

Planet Switch Configuration


Step 1: Log into the Planet Switch
Planet switch default IP address is 192.168.0.100. Default password is “admin
Once you have logged into the switch you can change the default IP address to match the IP subnet for LAN1. Here we have used the IP address 192.168.10.100.


Step 2: Configure VLAN Membership
Go to VLAN Membership configuration menu and create VLAN ID’s and port association.
  • Enter new VLAN ID and click Add
  • On the next page that appears select the ports to be associated with the VLAN
  • Click Apply to save. (We have assigned 6 ports for each VLAN as shown in the screen shots below)
  • Repeat the steps for each VLAN (VLAN’s 1 to 4)
  • Ensure port 1 is associated with all VLANs as this will be the trunk port
Note: VLAN1 is enabled by default and all ports are associated with VLAN1

Note: Port 1 must be a member of all VLAN ID’s since this will be used as the 802.1Q VLAN Trunk (uplink) from the Vigor3200 router

Step 3: Configure VLAN Port Configuration
Go to VLAN Port configuration menu and assign VLAN ID’s for each port
  • For Port 1, set this to be a Tagged port as shown below. This is required to allow the 802.1Q trunk from the Vigor3200 to work.
  • For other ports configure them as Untagged
  • Set PVID for each port as the vlan id
  • Click Apply to save
 

Comments

Popular posts from this blog

Cisco SG300 CLI Commands

Cisco SG300 CLI Commands Other parts were obtained using the CLI PDF provided by Cisco Remove a Trunk and switch to access config t int gi44 switchport trunk allowed vlan remove 2 switchport mode access switchport access vlan 2 or config t int gi44 switchport mode general switchport general allowed vlan remove 2 switchport mode access switchport access vlan 2 Change CDP Device ID Format to Hostname opposed to default MAC address s-sg300#sh cdp Global CDP information:         CDP is globally enabled         CDP log duplex mismatch is globally enabled         CDP log voice VLAN mismatch is globally enabled         CDP log native VLAN mismatch is globally enabled         Mandatory TLVs validation is disabled         Sending CDPv2 advertisements is enabled         Sending Appliance TLV is enabled       ...

Branches, Part II

Now that we’ve covered the mechanics behind Git branches, we can discuss the practical impact that they have on the software development process. Instead of introducing new commands, this module covers how the typical Git user applies this workflow to real projects, as well as some of the problems that arise in a branched environment. To Git, a branch is a branch, but it’s often useful to assign special meaning to different branches. For example, we’ve been using master as the stable branch for our example project, and we’ve also used a temporary branch to add some CSS formatting. Temporary branches like the latter are called topic branches because they exist to develop a certain topic, then they are deleted. We’ll work with two types of topic branches later in this module. Amid our exploration of Git branches, we’ll also discover that some merges cannot be “fast-forwarded.” When the history of two branches diverges, a dedicated commit is required to combine the branches. This ...

Distributed Workflows

Now that we know how to share information via a centralized workflow, we can appreciate some of the drawbacks of this collaboration model. While it may be convenient, allowing everyone to push to an “official” repository raises some legitimate security concerns. It means that for anyone to contribute content, they need access to the entire project. This is fine if you’re only interacting with a small team, but imagine a scenario where you’re working on an open-source software project and a stranger found a bug, fixed it, and wants to incorporate the update into the main project. You probably don’t want to give them push-access to your central repository, since they could start pushing all sorts of random snapshots, and you would effectively lose control of the project. But, what you can do is tell the contributor to push the changes to their own public repository. Then, you can pull their bug fix into your private repository to ensure it doesn’t contain any undeclared code. If y...