Then, a few months later, when I had to configure STP priority again, I’d do the same thing all over again. 😆

One day, someone told me;
"A lower value means higher priority."

That made sense—after all, if something is #1 priority, it means it's the top priority, right? But then, I suddenly realized:
"Wait, what about VRRP? In VRRP, a higher priority value is preferred!"

That contradiction got me thinking. So, I started digging through IEEE documentation and finally found something that cleared up my confusion:

IEEE 802.1D Standard: The IEEE 802.1D standard specifies that the root bridge is the switch with the lowest Bridge ID, which is a combination of bridge priority and MAC address. This ensures a deterministic and consistent selection process.

I couldn’t find the exact document again while writing this—maybe the link got moved—but you can search for it. The key takeaway here is "deterministic and consistent selection process."

This makes perfect sense. The default STP priority is 32768, and if we don’t explicitly configure it, the switch with the lowest MAC address becomes the root bridge.

Why does using the lowest value make STP more consistent?

Because hardware vendors increment MAC addresses over time as they manufacture new products. If we buy switches from the same vendor, rack them, and leave the priority at default, the root bridge will remain unchanged. This means we avoid unnecessary recalculations of the STP topology—no sudden changes in root ports, designated ports, or blocked ports.

Now, imagine if STP used the highest MAC address instead. Every time we added a newer switch, the root bridge would change (unless we manually set the priority). That would be a complete disaster!

What about VRRP?

VRRP, on the other hand, prefers higher priority values because a higher number represents greater capability, better specs, and so on. If there’s a tie, VRRP uses the highest IP address as the tiebreaker. This makes sense because we can assign IP addresses manually, meaning we control the outcome during the design phase.

This is different from STP, which relies on MAC addresses pre-assigned by hardware vendors. Yes, we can change a MAC address, but in practice, we usually don’t.

Other Protocols That Follow the "Higher is Preferred" Rule

The same logic applies to:

• OSPF DR (Designated Router) Election

• PIM DR (Designated Router) Election

• IS-IS DIS (Designated Intermediate System) Election

All of these protocols prefer higher values, just like VRRP, because priority and IP addresses can be set during design, rather than relying on factory-assigned MAC addresses.

Understanding why STP selects the lowest priority while protocols like VRRP prefer the highest helps eliminate confusion and makes network design more intuitive. STP relies on MAC addresses, which are fixed by hardware vendors, ensuring a stable and predictable root bridge selection. On the other hand, VRRP and other protocols prioritize higher values because they allow manual control over election processes.

By remembering these distinctions, we can make better design choices and avoid unexpected behavior in our networks. So, next time you configure STP or VRRP, you won’t need to Google it again—you’ll already know why! 🚀

🚀 My Journey in Tech

Over the past nine years, I’ve worked as a network engineer, software engineer, and cloud engineer. In this field, change is constant, and to keep up, I’ve had to learn new skills quickly. Whether through online courses like Udemy and Coursera, YouTube tutorials, or official technical documentation, continuous learning has been a necessity.

Technology moves fast, and businesses must keep up to stay competitive. That means professionals in IT need to be proactive about updating their knowledge. For example, when a new programming language or cloud service becomes popular, learning it keeps you relevant in the job market. Cybersecurity, automation, and cloud computing trends are constantly evolving, and staying informed gives an edge in career growth.

Throughout my career, I’ve faced situations where I had to learn new technologies quickly to meet deadlines or solve complex problems. These experiences reinforced three key principles I always follow:

✅ Know Your Weaknesses
✅ Bounce Back from Failures
✅ Stay Adaptable

🎯 1. Know Your Weaknesses

Acknowledging weaknesses is one of the hardest but most rewarding aspects of self-improvement. It requires honesty and self-awareness, which can be uncomfortable but necessary for growth. Weaknesses are not flaws; they highlight areas for development.

For example, if someone struggles with public speaking, avoiding presentations won’t help. Instead, acknowledging the weakness and working on it—taking courses, practicing, and getting feedback—turns it into a strength.

🔹 Identify weak areas
🔹 Set specific goals
🔹 Actively improve

🔥 2. Bounce Back from Failures

Resilience is about recovering from setbacks. Failures are part of the journey. What matters is how you respond.

Successful people don’t see failures as the end; they see them as learning experiences. For example, if an engineer’s solution doesn’t work, they analyze what went wrong, adjust, and try again. Entrepreneurs who fail in their first business use that experience to build something better.

🔹 Maintain a positive mindset
🔹 Learn from mistakes
🔹 Stay motivated even in tough times

💡 Failures aren’t roadblocks—they’re stepping stones.

🌟 3. Stay Adaptable

Change is constant, and adaptability is what keeps professionals relevant. Being adaptable means being open to new ideas, technologies, and ways of thinking.

Adaptability isn’t just reacting to change—it’s actively seeking opportunities for growth. This could mean learning a new programming language, staying updated with industry trends, or experimenting with new tools.

For example, a software engineer who continuously learns new frameworks stays competitive in the industry. Similarly, a network engineer who explores automation tools like Python or Ansible gains an advantage in modern networking environments.

🔹 Stay curious
🔹 Keep learning
🔹 Embrace change

🧠 The Mindset of Lifelong Learning

Embracing lifelong learning means continuously improving, setting goals, and staying curious. Learning isn’t just about formal education—it’s about everyday experiences, problem-solving, and self-reflection.

This journey requires patience and persistence but leads to professional success and personal fulfillment.

🎯 Conclusion

Lifelong learning is built on three principles:

🔹 Know Your Weaknesses – Identify areas for growth and work on them.
🔹 Bounce Back from Failures – Learn from setbacks and keep moving forward.
🔹 Stay Adaptable – Embrace change and new opportunities.

By following these principles, we can develop a mindset that promotes continuous growth. The journey never ends, but each step forward brings us closer to becoming the best version of ourselves.

In the realm of multicast networking, two essential protocols play distinct but complementary roles: IGMP (Internet Group Management Protocol) and PIM (Protocol Independent Multicast). Understanding how these protocols work together is crucial for managing multicast traffic effectively across networks.

The Role of IGMP

IGMP is a protocol used for managing multicast group memberships within a local network. It allows devices to signal their interest in receiving multicast traffic, ensuring that multicast data is only sent to devices that have explicitly requested it. IGMP operates within a single network segment or subnet, making it highly effective for managing multicast traffic locally. Key Functions of IGMP:

• Group Membership Management: IGMP helps routers and switches determine which devices (hosts) are part of a multicast group.

• Efficient Multicast Distribution: By informing network devices of which groups are active, IGMP helps to minimize unnecessary multicast traffic and optimize bandwidth usage.

The Role of PIM

PIM is designed to extend multicast traffic beyond the boundaries of a single local network. While IGMP handles group membership within a network, PIM is responsible for routing multicast traffic between different networks, enabling it to traverse routers and various network segments. Key Functions of PIM:

• Multicast Routing: PIM creates and maintains multicast distribution trees that span multiple networks, facilitating the delivery of multicast traffic to devices across different network segments.

• Protocol Independence: PIM operates independently of the underlying unicast routing protocol (e.g., OSPF, EIGRP, BGP), allowing it to work with various network setups.

How IGMP and PIM Work Together

The interaction between IGMP and PIM is crucial for effective multicast communication. Within a local network, IGMP ensures that multicast traffic is only sent to interested devices. When multicast traffic needs to be sent to or from devices across different networks, PIM takes over, routing the traffic between networks and ensuring that it reaches its intended destination. In summary:

• IGMP is essential for managing multicast group memberships locally, ensuring efficient multicast traffic distribution within a single network segment.

• PIM complements IGMP by enabling multicast traffic to traverse multiple networks, allowing multicast communication to extend beyond local boundaries.

Multicast PIM - Neighbor discovery

In a PIM domain, each PIM interface on a router periodically multicasts PIM hello messages to all other PIM routers (identified by the address 224.0.0.13) on the local subnet. Through the exchanging of hello messages, all PIM routers on the subnet determine their PIM neighbors, maintain PIM neighboring relationship with other routers, and build and maintain SPTs.

Multicast PIM - Reverse Path Forwarding (RPF)

Reverse Path Forwarding (RPF) is a fundamental mechanism in multicast routing that ensures data packets are forwarded along the correct path back to the source. RPF uses the existing unicast routing table to determine the preferred path for incoming multicast packets, ensuring that data is only accepted and forwarded if it arrives on the expected interface. This mechanism prevents loops and ensures that multicast traffic is efficiently routed through the network.

Image Source: RPF check mechanism (hpe.com)

RPF Mechanism The RPF process works as follows:

1. When a multicast packet arrives at a router, the router checks its unicast routing table to determine the preferred path to the packet's source.

2. If the packet arrives on the interface that matches the preferred path, it is accepted and forwarded to the next hop.

3. If the packet arrives on a different interface, it is discarded to prevent routing loops and inefficiencies. This mechanism ensures that multicast traffic flows along the most efficient path, leveraging the existing unicast routing infrastructure to maintain optimal performance. RPF Example Consider a multicast packet with a source IP address of 10.1.1.1 and a destination multicast address of 239.1.1.1. If this packet arrives at a router on both port1 and port2, the router uses the unicast routing table to determine the best path to reach 10.1.1.1. If the unicast route indicates that the preferred path to 10.1.1.1 is through port1, the packet arriving on port1 is accepted and forwarded, while the packet arriving on port2 is discarded. This ensures that the multicast traffic follows the most efficient route, minimizing unnecessary load on the network.

PIM Dense Mode (PIM-DM)

Characteristics of PIM-DM PIM Dense Mode (PIM-DM) is a multicast routing protocol that operates under the assumption that multicast receivers are densely distributed throughout the network. In PIM-DM, multicast traffic is initially flooded to all PIM-enabled routers. This approach ensures that all potential receivers have access to the multicast data, but it can result in significant overhead if many routers do not have interested receivers. Flood and Prune Mechanism

PIM-DM Flooding: When multicast traffic is first introduced into the network, it is flooded to all PIM-enabled routers. This ensures that all potential receivers receive the multicast data. PIM-DM Pruning: Routers that do not have any interested multicast receivers send a prune message upstream, instructing the upstream router to stop sending multicast traffic to them. This process continues until multicast traffic is only sent to routers with interested receivers. This mechanism helps to reduce unnecessary traffic and optimize the use of network resources, but it can be inefficient in networks with sparse multicast receivers. PIM-DM Draft is used to facilitate the process of rejoining a multicast group that was previously pruned. When a network segment or router has been pruned (i.e., multicast traffic was stopped), if a new receiver expresses interest in that multicast group, the network needs a way to handle this rejoining. Benefits and Drawbacks of PIM-DM Benefits:

• Simple to implement and configure.

• Ensures all potential receivers initially receive the multicast data. Drawbacks:

• Inefficient in networks with sparse receivers, leading to excessive flooding and pruning.

• Higher bandwidth consumption due to initial flooding.

PIM Sparse Mode (PIM-SM)

Characteristics of PIM-SM PIM Sparse Mode (PIM-SM) operates under the assumption that multicast receivers are sparsely distributed throughout the network. Unlike PIM-DM, PIM-SM uses a more controlled approach to multicast traffic distribution, relying on a central Rendezvous Point (RP) to manage group memberships and traffic forwarding.

Shared Tree (RPT) In PIM-SM, the initial multicast traffic is sent to a Rendezvous Point (RP), which maintains a shared tree (RPT) connecting all routers with interested receivers. The steps are as follows:

• A router interested in receiving multicast traffic for a group sends a join message towards the RP.

• The RP builds a shared tree connecting all receivers.

• Multicast traffic from the source is sent to the RP, then distributed to all receivers via the shared tree. Source Tree (SPT) After the initial multicast traffic is delivered via the shared tree, routers can transition to a Source Tree or Short Path Tree (SPT) for more efficient delivery. The steps are as follows:

• Once a receiver router receives multicast traffic from the RP, it learns the source's IP address.

• If there is a more efficient path to the source, the router builds a source tree specific to that source.

• Future multicast traffic is received directly from the source via the source tree, optimizing the delivery path.

PIM Sparse Mode use Register and Register Stop to handle multicast source registration PIM Register: Used to inform the RP about the source and to forward multicast traffic to the RP. PIM Register-Stop: Tells the local router to stop sending Register messages once the RP confirms there are interested receivers.

Transition from Shared Tree to Source Tree This transition from the shared tree to the source tree enhances efficiency by ensuring that multicast traffic follows the shortest possible path to each receiver. This reduces latency and conserves bandwidth, particularly in large networks with diverse multicast sources and receivers.

PIM Sparse Mode Auto-RP

In PIM multicast routing, the Rendezvous Point (RP) is a crucial component that facilitates the distribution of multicast traffic to receivers. Auto-RP automates the process of discovering and advertising RP information, making it easier to deploy and manage multicast routing. Note: Auto-RP is applicable only to PIM-SM.

Mapping Agents: These are routers that listen for RP announcements and distribute RP information to the rest of the network.
Candidate RPs: These are routers that volunteer to act as RPs and advertise their willingness to serve as an RP to the network.

Auto-RP Components: Candidate RP (CRP): A router that wants to be an RP will use Auto-RP to advertise itself as a candidate. This advertisement includes information such as the multicast groups it is willing to support. Mapping Agent (MA): A router that listens for Candidate RP advertisements and distributes RP information throughout the network. Rendezvous Point (RP): Once elected, the RP is responsible for managing multicast groups and forwarding multicast traffic.

PIM Source-Specific Multicast (PIM-SSM)

Overview of PIM-SSM PIM Source-Specific Multicast (PIM-SSM) is a variant of PIM designed to enhance the efficiency and security of multicast traffic delivery. In PIM-SSM, multicast receivers specify both the source and the group they are interested in, allowing for more precise and efficient routing of multicast traffic. Notes:

• Its Required IGMPv3 enabled within networks. PIM SSM relies on the capability of IGMPv3 to handle source-specific multicast group memberships. IGMPv3 enables the receiver to explicitly specify the source addresses it wants to receive traffic from, which is a fundamental requirement for PIM SSM.

• (*;G) are not exist on PIM-SSM

• 

  Advantages of PIM-SSM

• Increased Security: By allowing receivers to specify the source, PIM-SSM reduces the risk of unwanted or malicious multicast traffic.

• Improved Efficiency: PIM-SSM optimizes the delivery of multicast traffic by ensuring it only flows from the specified source to interested receivers, reducing unnecessary traffic.

• Simplified Management: PIM-SSM simplifies the management of multicast groups by reducing the complexity of group membership and traffic forwarding.

PIM Bidirectional (PIM-BIDR)

Overview of PIM-BIDR In PIM BIDIR, the RP serves as the central point through which all multicast traffic is exchanged. It plays a key role in bidirectional multicast communication, ensuring that multicast traffic can flow in both directions—between sources and receivers. Multiple RPs can be manually configured. The network can be set alternate RP if the primary RP fails.

PIM BIDIR is a variant of PIM-SM, similar to SSM, and is particularly useful when most receivers are also senders, such as in videoconferencing scenarios. In PIM BiDir, all participants join a single distribution tree rooted at the RP. Unlike the unidirectional trees in PIM-SM, BiDir allows traffic to flow both up and down the tree. When a source sends multicast packets, they travel up to the RP and then down to all receivers.

To establish the bidirectional tree, PIM elects Designated Forwarders (DFs) for each link. The DF is selected based on the shortest metric to the RP, similar to the PIM Assert procedure. PIM Assert Procedure is Mechanism that optimizes multicast traffic by stopping the forwarding of multicast traffic on specific interfaces where there are no interested receivers. DFs are the only routers allowed to forward traffic upstream towards the RP.

Each router in a PIM BIDIR network maintains a (*, G) state for each bidirectional group, with an Outgoing Interface List (OIL) based on PIM Join messages from neighbors, representing the downstream part of the tree.

PIM BIDIR does not use the PIM Register/Register-Stop mechanism for source registration. Sources can start sending multicast traffic at any time; packets will travel upward to the RP and then be either dropped if there are no receivers or forwarded down the BIDIR tree. The RP cannot instruct the source to stop sending traffic.

Use Cases for PIM-BIDR

• Video Conferencing: PIM-BIDR is ideal for video conferencing applications where participants need to send and receive video streams simultaneously.

• Collaborative Work: In collaborative environments, PIM-BIDR allows for efficient sharing of data and resources among multiple users.

Comparing PIM Modes

PIM-DM vs PIM-SM

• PIM-DM: Suitable for networks with densely distributed receivers, but can result in excessive flooding and pruning.

• PIM-SM: More efficient for networks with sparsely distributed receivers, using a central RP to manage group memberships and traffic.

PIM-SSM vs PIM-BIDR

• PIM-SSM: Focuses on source-specific multicast traffic, enhancing security and efficiency by allowing receivers to specify both the source and the group.

• PIM-BIDR: Optimized for bidirectional traffic flows, ideal for applications requiring simultaneous send and receive capabilities.

Implementing PIM in Networks

PIM Configuration Steps

1. Enable PIM on Interfaces: Configure PIM on the interfaces of routers that will participate in multicast routing.

2. Configure Rendezvous Points (RP): For PIM-SM, designate and configure RPs to manage group memberships and traffic forwarding.

3. Establish Multicast Routing Policies: Define policies to control the flow of multicast traffic and manage group memberships. Common Challenges and Solutions

• Challenge: Managing multicast group memberships in large networks. Solution: Use automated tools and protocols like IGMP to simplify membership management.

• Challenge: Ensuring efficient routing of multicast traffic. Solution: Leverage RPF checks and transition to source trees for optimized delivery.

Use Cases and Applications of PIM

Real-World Examples

• Live Streaming: PIM is used to efficiently distribute live video streams to large audiences. Live streaming mean user stream the video at same time without have any control to video playback such as Forward, Backward, Timestamp slider and so on.

• Online Gaming: Multicast traffic optimizes the delivery of real-time game data to multiple players.

Industry Applications

• Finance: Real-time stock ticker updates and financial news distribution.

• Education: Distance learning and virtual classrooms benefit from efficient multicast traffic delivery.

Switch Role as IGMP Snoop

Snoop Multicast Information between host and router. Overview of IGMP Snooping IGMP (Internet Group Management Protocol) Snooping is a network switch feature that allows the switch to listen in on IGMP conversations between hosts and routers. By doing so, the switch can intelligently forward multicast traffic only to ports that are part of the multicast group, preventing unnecessary traffic from being sent to all ports. Benefits of IGMP Snooping

• Traffic Optimization: IGMP Snooping significantly reduces multicast traffic by ensuring that multicast packets are only sent to ports with interested receivers.

• Enhanced Performance: By limiting unnecessary traffic, IGMP Snooping improves the overall performance and efficiency of the network.

• Bandwidth Conservation: By preventing multicast packets from flooding the entire network, IGMP Snooping conserves valuable bandwidth, particularly in large and complex networks.

FAQs on Protocol Independent Multicast (PIM)

What is Protocol Independent Multicast (PIM)? PIM is a multicast routing protocol that operates independently of specific unicast routing protocols, enabling efficient distribution of multicast traffic across IP networks.

How does Reverse Path Forwarding (RPF) work? RPF ensures that multicast packets are accepted only if they arrive on the correct interface, as determined by the unicast routing table, preventing loops and optimizing traffic flow.

What are the differences between PIM-DM and PIM-SM? PIM-DM assumes densely distributed receivers and uses a flood and prune mechanism, while PIM-SM assumes sparsely distributed receivers and uses a Rendezvous Point to manage traffic.

What is the purpose of PIM-SSM? PIM-SSM allows receivers to specify both the source and the group for multicast traffic, enhancing security and efficiency by reducing unnecessary traffic.

When is PIM Bidirectional (PIM-BIDR) used? PIM-BIDR is used in scenarios with bidirectional traffic flows, such as video conferencing and collaborative work, enabling efficient routing in both directions.

What are the benefits of multicast routing? Multicast routing optimizes bandwidth use, improves scalability, and enhances network performance by delivering data to multiple recipients simultaneously.

Conclusion

Summary of Key Points Protocol Independent Multicast (PIM) is a versatile and efficient multicast routing protocol that operates independently of specific unicast routing protocols. It offers various modes, including PIM-DM, PIM-SM, PIM-SSM, and PIM-BIDR, each suited to different network environments and requirements. Understanding and implementing PIM can significantly enhance the efficiency and performance of multicast traffic in IP networks. Final Thoughts on PIM PIM remains a critical component of modern IP networks, providing the scalability, efficiency, and flexibility needed to support a wide range of multicast applications. As networks continue to evolve, the ongoing development and integration of PIM with emerging technologies will ensure its relevance and effectiveness in meeting future multicast routing challenges.

1. Creating a New VM Instance

To start, create a new VM instance in your destination project. Here’s how:

gcloud compute instances create rama_test_vm_move \
    --image-project rama_lab \
    --image machine-images-sf-sa \
    --subnet default

In this command:

• rama_test_vm_move is the name of the new VM instance.

• --image-project specifies the project where the image is located.

• --image indicates the name of the image to use.

• --subnet assigns the instance to a subnet (in this case, the default subnet).

For consistency, if you need to create another instance with similar parameters, you can use:

gcloud compute instances create ramatestvmmove \
    --image-project rama-lab \
    --image machine-images-sf-sa \
    --subnet default

2. Creating and Managing Snapshots

Source Project:

1. Create a Snapshot: To snapshot a disk from a VM in your source project, use:

    gcloud compute snapshots create sasnapshoot \
        --source-disk instance-2 \
        --snapshot-type STANDARD \
        --source-disk-zone asia-southeast2-a
   

   • sasnapshoot is the name of the snapshot.

   • --source-disk specifies the disk you want to snapshot.

   • --snapshot-type defines the type of snapshot (STANDARD).

   • --source-disk-zone is the zone where the source disk is located.

2. Create an Image from the Snapshot:

   After creating the snapshot, convert it into an image:

    gcloud compute images create serviceassuranceimages \
        --source-snapshot=sasnapshoot
   

   • serviceassuranceimages is the name of the new image created from the snapshot.

3. Grant Access to the Image:

   Ensure that the new user or project has the necessary permissions to access the image. Assign the user.image role via IAM.

3. Creating VM Instances in the Destination Project

Destination Project:

To create a VM instance in a new project using the image from the source project:

gcloud compute instances create ramatest \
    --image-project rama-lab \
    --image serviceassuranceimages

In this command:

• ramatest is the name of the new VM instance.

• --image-project specifies the project where the image is stored.

• --image refers to the image created from the snapshot.

4. Example Implementation: A Full Migration

Here’s a complete example of migrating a VM from one project to another:

Source Project:

1. Create Snapshot:

    gcloud compute snapshots create exportedsnapshoot \
        --source-disk newvmsa-instance \
        --snapshot-type STANDARD \
        --source-disk-zone asia-southeast2-a
   

2. Create Image from Snapshot:

    gcloud compute images create exportedserviceassuranceimages \
        --source-snapshot=exportedsnapshoot
   

Destination Project:

1. Create VM Instance:

    gcloud compute instances create serviceassurancevm \
        --image-project zeta-crossbar-371709 \
        --image exportedserviceassuranceimages
   

Conclusion

Migrating VMs across Google Cloud projects involves creating snapshots, converting them to images, and deploying new VM instances using these images. By following these steps, you can efficiently manage and transfer your VMs while ensuring they retain their configurations and data. This process is essential for maintaining a flexible and scalable cloud infrastructure, allowing you to optimize resource utilization and project management.

Step 1: Creating the Custom Ansible Module

We'll start by creating a Python script for our custom Ansible module. This module will interact with Huawei devices to show the IP routing table.

Script: yourorganization_module_huawei_display_ip_routing_table.py

#!/usr/bin/python3

# Copyright: (c) 2021, Hidayah Ramadlana <hidayah.ramadalana@org.com>
# GNU General Public License v3.0+ (see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt)

from __future__ import (absolute_import, division, print_function)
__metaclass__ = type

from ansible.module_utils.basic import AnsibleModule

# all logic function
def run_module():
    # SOP:1 Change this: 
    # param input
    module_args = dict(
        command=dict(type='str', required=True),
        ansible_host=dict(type='str', required=False),
        ansible_network_os=dict(type='str', required=False),
        ansible_user=dict(type='str', required=False),
        ansible_ssh_pass=dict(type='str', required=False),
        ansible_platform=dict(type='str', required=False),
    )

    # SOP: 2 Change this
    # result prototype
    result = dict(
        changed=False,
        return_from_devices=""
    )

    # [do not change] create new AnsibleModule instance called (module)
    module = AnsibleModule(
        argument_spec=module_args,
        supports_check_mode=True
    )

    # [do not change] checkmode if true, only return the result immediately, all bellow code after this block cannot executed
    if module.check_mode:
        result['message_from_user'] = "this is check mode enable message"
        module.exit_json(**result)

    # SOP: 3 Change this
    # ALL LOGIC FOR RETURN MESSAGE IS DO IN HERE
    # change result value using module params or bussiness logic
    from netmiko import ConnectHandler

    def call_huawei(command,device_type, device_ip, device_username, device_password, device_port):
        # all platform or device_type can be see in here:
        # https://github.com/ktbyers/netmiko/blob/develop/PLATFORMS.md

        huawei = {
        'device_type': device_type,
        'host':   device_ip,
        'username': device_username,
        'password': device_password,
        'port' : device_port
        }

        net_connect = ConnectHandler(**huawei)
        return net_connect.send_command(command)

    proposed_args = {
        'command': module.params['command'],
        'device_type': module.params['ansible_network_os'],
        'device_ip':   module.params['ansible_host'],
        'device_username': module.params['ansible_user'],
        'device_password': module.params['ansible_ssh_pass'],
        # hardcode port
        'device_port': 22
    }
    device_cli_output = call_huawei(**proposed_args)

    # ~~~~~~~~~~~~~~~~~~~~~~~~~~~ NTC TEMPLATE PARSER ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    """ntc_templates.parse."""
    import os

    try:
        from textfsm import clitable

        HAS_CLITABLE = True
    except ImportError:
        HAS_CLITABLE = False

    def _get_template_dir():
        template_dir = os.environ.get("NTC_TEMPLATES_DIR")
        if template_dir is None:
            package_dir = os.path.dirname(__file__)
            template_dir = os.path.join(package_dir, "templates")
            if not os.path.isdir(template_dir):
                project_dir = os.path.dirname(os.path.dirname(os.path.dirname(template_dir)))
                template_dir = os.path.join(project_dir, "templates")

        return template_dir


    def _clitable_to_dict(cli_table):
        """Convert TextFSM cli_table object to list of dictionaries."""
        objs = []
        for row in cli_table:
            temp_dict = {}
            for index, element in enumerate(row):
                temp_dict[cli_table.header[index].lower()] = element
            objs.append(temp_dict)

        return objs


    def parse_output(platform=None, command=None, data=None):
        """Return the structured data based on the output from a network device."""

        if not HAS_CLITABLE:
            msg = """
    The TextFSM library is not currently supported on Windows. If you are NOT using Windows
    you should be able to 'pip install textfsm' to fix this issue. If you are using Windows
    then you will need to install the patch referenced here:

    https://github.com/google/textfsm/pull/82

    """
            raise ImportError(msg)

        template_dir = _get_template_dir()
        cli_table = clitable.CliTable("index", template_dir)

        attrs = {"Command": command, "Platform": platform}
        try:
            cli_table.ParseCmd(data, attrs)
            structured_data = _clitable_to_dict(cli_table)
        except clitable.CliTableError as e:
            raise Exception(
                'Unable to parse command "{0}" on platform {1} - {2}'.format(
                    command, platform, str(e)
                )
            )
            # Invalid or Missing template
            # module.fail_json(msg='parsing error', error=str(e))
            # rather than fail, fallback to return raw text
            # structured_data = [data]

        return structured_data

    # ~~~~~~~~~~~~~~~~~~~~~~~~~~~ END OF TEMPLATE PARSER ~~~~~~~~~~~~~~~~~~~~~~~~~~~

    # NTC TEMPLATE LOCATION PLEASE CHANGE THIS TO UPDATED NTC TEMPLATES DIRECTORY
    os.environ["NTC_TEMPLATES_DIR"] = "/opt/ntc-templates/ntc_templates/templates"


    parsed = parse_output(platform=module.params['ansible_platform'], command=module.params['command'], data=device_cli_output)

    # RESULT MODIFICATION
    result['return_from_devices'] = parsed

    # SOP: 3 END OF LOGIC FOR RETURN MESSAGE 

    # [do not change] is Changed Logic
    # if its True, then changed will be true with yellow text
    # result['changed'] = True

    # [do not change] Fail Condition Logic
    if module.params['command'] == 'fail me':
        module.fail_json(msg='You requested this to fail', **result)

    # [do not change]in the event of a successful module execution
    module.exit_json(**result)


def main():
    run_module()


if __name__ == '__main__':
    main()

Dont worry about that long script, We'll break down the module into its three primary functional components: Input, Process, and Output.

Input: Handling Module Arguments

The input function is responsible for receiving and validating arguments passed to the module. It defines the parameters that the module will use to interact with the network device.

Code Snippet: Input Handling

def run_module():
    # Define module arguments
    module_args = dict(
        command=dict(type='str', required=True),
        ansible_host=dict(type='str', required=False),
        ansible_network_os=dict(type='str', required=False),
        ansible_user=dict(type='str', required=False),
        ansible_ssh_pass=dict(type='str', required=False),
        ansible_platform=dict(type='str', required=False),
    )

    # Initialize result prototype
    result = dict(
        changed=False,
        return_from_devices=""
    )

    # Create AnsibleModule instance
    module = AnsibleModule(
        argument_spec=module_args,
        supports_check_mode=True
    )

    # Handle check mode
    if module.check_mode:
        result['message_from_user'] = "Check mode enabled."
        module.exit_json(**result)

In this section, we define the module's expected parameters using the module_args dictionary. This includes the command to execute, device details, and authentication credentials. We also initialize the result dictionary to hold the output of the command.

Process: Interacting with the Device

The process function handles the actual interaction with the network device. It uses the parameters provided in the input to connect to the device, execute commands, and parse the results.

Code Snippet: Processing and Parsing

from netmiko import ConnectHandler
import os
from textfsm import clitable

def call_huawei(command, device_type, device_ip, device_username, device_password, device_port):
    huawei = {
        'device_type': device_type,
        'host': device_ip,
        'username': device_username,
        'password': device_password,
        'port': device_port
    }
    net_connect = ConnectHandler(**huawei)
    return net_connect.send_command(command)

def parse_output(platform=None, command=None, data=None):
    template_dir = os.getenv("NTC_TEMPLATES_DIR", "/opt/ntc-templates/ntc_templates/templates")
    cli_table = clitable.CliTable("index", template_dir)

    attrs = {"Command": command, "Platform": platform}
    try:
        cli_table.ParseCmd(data, attrs)
        structured_data = _clitable_to_dict(cli_table)
    except clitable.CliTableError as e:
        raise Exception(
            'Unable to parse command "{}" on platform {} - {}'.format(
                command, platform, str(e)
            )
        )
    return structured_data

Here, the call_huawei function connects to the Huawei device using Netmiko and executes the specified command. The parse_output function handles the parsing of the command output using TextFSM. This function ensures that the raw data is converted into a structured format suitable for further processing.

Output: Delivering Results

The output function formats the results and sends them back to the Ansible playbook. It ensures that the output is presented in a way that is easy for users to understand and utilize.

Code Snippet: Output Handling

def run_module():
    # (Previous code remains unchanged)

    # Process and Parse
    device_cli_output = call_huawei(**proposed_args)
    parsed = parse_output(platform=module.params['ansible_platform'], command=module.params['command'], data=device_cli_output)

    # Set Result
    result['return_from_devices'] = parsed

    # Handle Result
    module.exit_json(**result)

def main():
    run_module()

if __name__ == '__main__':
    main()

In the output handling section, we call the call_huawei and parse_output functions to retrieve and format the data. We then update the result dictionary and use module.exit_json() to return the structured data to the Ansible playbook.

Step 2: Placement and Usage

In development, We can create modules on /usr/share/ansible/plugins/modules and call from playbook using yourorganization_module_huawei_display_ip_routing_table:

In Production And then, after being finished, we create our own collection in

/usr/share/ansible/collections/ansible_collections/yourorganization/vrp/plugins/modules

• yourorganization for workspace name

• vrp for OS for system name

• and put modules on plugins or modules

and call on playbook and put module using this format yourorganization.vrp.display_ip_routing_table:

Example:

mv multipolar_module_huawei_display_ip_routing_table.py /usr/share/ansible/collections/ansible_collections/yourorganization/vrp/plugins/modules/display_ip_routing_table.py

ansible-playbook -i inventory_host_huawei.yml playbook_for_module_huawei_display_ip_routing_table_using_collection.yml

Conclusion

Creating and managing custom Ansible modules allows you to tailor automation to your specific network needs. By following these steps, you can efficiently manage Huawei VRP devices and integrate their functionalities into your Ansible automation workflows. This guide should provide a solid foundation for developing and deploying your custom network modules.

In the past, whenever I made API calls in TypeScript, whether on the frontend or backend, I would painstakingly create type definitions by hand. This process involved examining the structure of the API response and then writing out the corresponding TypeScript types. For instance, if the response looked like this:

{
  "id": 1,
  "name": "John Doe",
  "email": "john.doe@example.com"
}

I would manually define a TypeScript interface to match this response:

interface User {
  id: number;
  name: string;
  email: string;
}

This manual approach was not only time-consuming but also prone to errors, especially when dealing with complex or nested data structures. Additionally, any changes in the API response required updating the type definitions, which could easily be overlooked, leading to potential bugs and inconsistencies in the codebase.

Fortunately, there are now tools and libraries available that can automate this process, generating type definitions directly from the API responses. This not only saves time but also ensures that the types are always in sync with the actual data being returned by the API. By leveraging these tools, developers can focus more on building features and less on the repetitive task of writing type definitions.:

{
    "products": [
        {
          "id": 59,
          "title": "Spring and summershoes",
        },
        {
          "id": 88,
          "title": "TC Reusable Silicone Magic Washing Gloves",
        }
}

then sure, I will create definitions like this way:

export interface IProduct {
    "products": Array<{
        id: number;
        title: string;     
    }>
}

okay, it's easy because the return of the JSON string from the API Server is not complex enough. but how about this:

{
  "products": [
    {
      "id": 7,
      "title": "Samsung Galaxy Book",
      "description": "Samsung Galaxy Book S (2020) Laptop With Intel Lakefield Chip, 8GB of RAM Launched",
      "price": 1499,
      "discountPercentage": 4.15,
      "rating": 4.25,
      "stock": 50,
      "brand": "Samsung",
      "category": "laptops",
      "thumbnail": "https://i.dummyjson.com/data/products/7/thumbnail.jpg",
      "images": [
        "https://i.dummyjson.com/data/products/7/1.jpg",
        "https://i.dummyjson.com/data/products/7/2.jpg",
        "https://i.dummyjson.com/data/products/7/3.jpg",
        "https://i.dummyjson.com/data/products/7/thumbnail.jpg"
      ]
    },
    {
      "id": 8,
      "title": "Microsoft Surface Laptop 4",
      "description": "Style and speed. Stand out on HD video calls backed by Studio Mics. Capture ideas on the vibrant touchscreen.",
      "price": 1499,
      "discountPercentage": 10.23,
      "rating": 4.43,
      "stock": 68,
      "brand": "Microsoft Surface",
      "category": "laptops",
      "thumbnail": "https://i.dummyjson.com/data/products/8/thumbnail.jpg",
      "images": [
        "https://i.dummyjson.com/data/products/8/1.jpg",
        "https://i.dummyjson.com/data/products/8/2.jpg",
        "https://i.dummyjson.com/data/products/8/3.jpg",
        "https://i.dummyjson.com/data/products/8/4.jpg",
        "https://i.dummyjson.com/data/products/8/thumbnail.jpg"
      ]
    },
... and thousands more
}

Maybe you can manually type that definition, but what if maybe the API response is more complex than above ? or maybe you have hundreds of API endpoints with different structures?

Create it automatically

To save your precious time and effort, I recommend using a tool called Thunder Client, which is available as a free extension for VS Code. Thunder Client is my favorite alternative to Postman and Insomnia because it is lightweight, fast, and easy to use. One of its standout features is its ability to generate code and types automatically, which can be a huge time-saver, especially when dealing with complex API responses or multiple API endpoints with different structures.

Let's go ahead and install Thunder Client and give it a try:

1. Open VS Code and navigate to the Extensions view by clicking on the Extensions icon in the Activity Bar on the side of the window.

2. In the search bar, type "Thunder Client" and press Enter.

3. Click the Install button next to the Thunder Client extension.

4. Once installed, you can open Thunder Client by clicking on its icon in the Activity Bar.

With Thunder Client, you can easily create and manage your API requests, and it will automatically generate the necessary code and types for you. This makes it an invaluable tool for developers who need to work with APIs efficiently.

URL endpoints: https://dummyjson.com/products/search?q=Laptop

Then in the right upper corner, we can see small {} bracket icons. click it

Now we got fetch the javascript code, and the next step is to click generate Types

Viola! now we have a typescript interface definition without manually creating it.

Here are a few ways to import external js on SvelteKit

Using {@html} decorator

For me, it's commonly used to import js template files and put them on +layout.svelte

</div>
...
    {@html '<script src="/tabler.min.js"></script>'}
...
</div>

Using svelte head

its mainly used if we want to import external js files and we wanna call a function after these external js loaded to DOM

First let see what our code if we code using vanilla js

// Form
<form id="payment-form">
     ... your form things
</form>

<script src="https://js.stripe.com/v3/"></script>
// Create a Stripe client.
var stripe = Stripe('ourkeysecret1234567789zzz');

// Create an instance of Elements.
var elements = stripe.elements();

lets convert that to SvelteKit Components.

<script>
    import { onMount } from 'svelte';
        let stripeReady = false;
        let mounted = false;

        onMount(() => {
            // onMount always call after Components mounted.
            mounted = true;
            // if stripe altready mounted load stripe element imediately
            if (stripeReady) {
                loadStripeElements();
            }
        });

        function stripeLoaded() {
            // if stripeReady -> load Stripe Element.
            stripeReady = true;
            if (mounted) {
                loadStripeElements();
            }
        }

        function loadStripeElements() {
            // create stripe elements
            const stripe = tripe('ourkeysecret1234567789zzz');
            var elements = stripe.elements();
            // etc..
        }
    }
</script>

<svelte:head>
    <script src="https://js.stripe.com/v3/" on:load={stripeLoaded}</script>
</svelte:head>

<div>
    <form id="payment-form">
         ... your form things
    </form>
</div>

That is. we successfully added an external (legacy) JS library into our Svelte Components.

Step 1: Locate User-Defined Services

Systemd services are typically stored in specific directories based on their scope. For user-defined services, you’ll usually work within /etc/systemd/system/ on Ubuntu. This directory is where you should place your custom service files.

cd /etc/systemd/system/

Step 2: Create Your Service File

Using your preferred text editor, create a new service file. You can name this file anything you like, but it must end with .service. For example, let’s name it metabase.service.

sudo nano whatever_you_want.service

Step 3: Define Your Service Configuration

Add the following template to your service file. This configuration is designed for a hypothetical Metabase daemon, but you can customize it for any service you need.

[Unit]
Description=Metabase Daemon

[Service]
PIDFile=/var/tmp/metabase.pid
WorkingDirectory=/usr/local/bin/metabase/
User=ubuntu
Group=ubuntu

# Run command here
ExecStart=/usr/bin/java -jar -Xmx512m /usr/local/bin/metabase/metabase.jar

Restart=on-failure
RestartSec=30
PrivateTmp=true

StandardOutput=metabase
StandardError=metabase_err
SyslogIdentifier=metabase

[Install]
WantedBy=multi-user.target

Explanation:

• [Unit]: Provides metadata about the service, including its description.

• [Service]: Defines how the service runs, including the command to start it (ExecStart), user and group under which it runs, and how to handle failures.

• [Install]: Configures how the service should be installed and started.

Step 4: Manage Your Service

Once you’ve created and saved your service file, you need to reload systemd to recognize your new service and then manage it using systemctl.

Start the Service:

sudo systemctl start whatever_you_want.service

Enable Auto-Start at Boot:

sudo systemctl enable whatever_you_want.service

Disable Auto-Start:

sudo systemctl disable whatever_you_want.service

Stop the Service:

sudo systemctl stop whatever_you_want.service

Restart the Service:

sudo systemctl restart whatever_you_want.service

View Service Logs:

journalctl -e -u whatever_you_want.service

This command shows the most recent log entries for your service, which is useful for troubleshooting and monitoring.

Conclusion

Creating and managing a systemd service on Linux is a powerful way to handle background tasks and system daemons. By following these steps, you can easily set up your services to run automatically at boot and manage them with simple commands. Whether you’re running a web application, a background process, or any other service, systemd provides the tools you need to keep things running smoothly and efficiently.