14 August 2012 Karim Elatov

1. Vnic Mac Addresses Manualquotesdigital Outlook
2. Vnic Mac Addresses Manualquotesdigital Shortcut
3. Vendor Mac Addresses
4. Vnic Mac Addresses Manualquotesdigital White Pages

VMWARE ESXi 5 - Changing the VNIC virtual mac address. K10ee asked on 2012-05-03. VMware; Networking; 10 Comments. Last Modified: 2012-06-22. In case of vNIC upgrade it can be simply done from edit VM settings(can be done only for VMware reserved MAC address range i.e. 00:50:56:XX:YY:ZZ, where XX is a valid hexadecimal number between 00 and 3F, and YY and ZZ are valid hexadecimal numbers between 00 and FF) however to replicate the MAC address in case of P2V, you will have to edit the vmname.vmx file (as the physical server's NIC. How does a vNIC get a MAC address? Each vNIC is automatically assigned its MAC address. Subnetting operates at Layer while VLANs function at Layer. Layer 3 and Layer 2. Which VLAN on a switch manages untagged frames? Native VLAN manages untagged frames. How does STP work? It shuts down certain ports on a switch to prevent loops. MAC address assignment failed for a vNIC, possibly illegal MAC address or no available MACs in the pool. It's quite intresting error, because there are 20 free mac-address in MAC-POOL. Service Profile contains 2 vNIC: vNIC, iSCSI vNIC. Hardwire NIC is 1240. The Scripts are gathering the MAC Address Pool of VMM to grant an available MAC address to the host’s management vNIC. The MAC is then pushed to the management vNIC, meaning the existing duplicate is overwritten. Be aware that changing the management vNIC’s MAC address will disrupt the management network communications for some seconds up.

I was recently using the UCS Manager CLI and I wanted to share my findings. You can SSH to the UCSM (UCS Manager) and then run commands to figure out information about your hardware configuration. Whenever working with Cisco UCS Servers, the first thing we need to figure out is how Service Profiles are used in a UCS Environment. Cisco has an excellent article about this entitled “Cisco UCS Manager CLI Configuration Guide, Release 2.0”, I like their definition:

Service profiles are the central concept of Cisco UCS. Each service profile serves a specific purpose: ensuring that the associated server hardware has the configuration required to support the applications it will host.

The service profile maintains configuration information about the server hardware, interfaces, fabricconnectivity, and server and network identity. This information is stored in a format that you can manage through Cisco UCS Manager. All service profiles are centrally managed and stored in a database on the fabric interconnect.

Every server must be associated with a service profile.

Service Profiles consist of Policies:

Policies determine how Cisco UCS components will act in specific circumstances. You can create multiple instances of most policies. For example, you might want different boot policies, so that some servers can PXE boot, some can SAN boot, and others can boot from local storage.

Policies allow separation of functions within the system. A subject matter expert can define policies that are used in a service profile, which is created by someone without that subject matter expertise. For example, a LAN administrator can create adapter policies and quality of service policies for the system. These policies can then be used in a service profile that is created by someone who has limited or no subject matter expertise with LAN administration.

You can create and use two types of policies in Cisco UCS Manager:

• Configuration policies that configure the servers and other components
• Operational policies that control certain management, monitoring, and access control functions

So first find out what is the name of the server that you are working with. You can either look at the UCSM Web Page or if you know the name of the server you can find out what chassis your blade is in. To see all the available servers you can do the following:

Each Server has a Service Profile Attached to it. I will be working with p2-b200-1 Service Profile, which corresponds to Chassis 1, Server 2. So let’s check out the HBAs that are available for this server:

We can see we have two HBAs on the server and their corresponding WWPNs. We can also check out the available NICs:

You can see that there are different MACs and WWPNs assigned for this server. To see the distinguished name of you adapters you can run the following:

The WWPNs and the MACs are assigned to the devices, this is actually defined in the pools. From the config guide:

Pools are collections of identities, or physical or logical resources, that are available in the system. All pools increase the flexibility of service profiles and allow you to centrally manage your system resources.

You can use pools to segment unconfigured servers or available ranges of server identity information into groupings that make sense for the data center. For example, if you create a pool of unconfigured servers with similar characteristics and include that pool in a service profile, you can use a policy to associate that service profile with an available, unconfigured server.

If you pool identifying information, such as MAC addresses, you can pre-assign ranges for servers that will host specific applications. For example, all database servers could be configured within the same range of MAC addresses, UUIDs, and WWNs.

To see what pool your vHBA belongs to, you can run the following:

You can see that vHBA1 (fc0) is from WWPN_Pod2_A and vHBA2 (fc1) is from WWPN_Pod2_B. To see a list of defined pools you can run the following:

We are using the bottom two. Just to see the pattern of the pool let’s check out one of them:

So our range is defined as follows; 20:00:00:25:B5:02:0A:00 to 20:00:00:25:B5:02:0A:02. To get a list of all the WWPNs assigned from this pool in a concise manner you can run the following:

You can check similar setting for the mac pools as well. If you have two IO Modules in the enclosure/chassis then you define two fabrics; a and b. We had two modules:

You can also check if the server is connected to both IOMs:

We can see our connection path is to A and B, both of our fabrics. For each Fabric we usually have a fabric-interconnect:

Usually you setup “pinning” to pin you HBAs and NICs to a certain IO module, for load balancing. From the Config Guide:

Pinning in Cisco UCS is only relevant to uplink ports. You can pin Ethernet or FCoE traffic from a givenserver to a specific uplink Ethernet port or uplink FC port.

When you pin the NIC and HBA of both physical and virtual servers to uplink ports, you give the fabricinterconnect greater control over the unified fabric. This control ensures more optimal utilization of uplink port bandwidth.

Cisco UCS uses pin groups to manage which NICs, vNICs, HBAs, and vHBAs are pinned to an uplink port. To configure pinning for a server, you can either assign a pin group directly, or include a pin group in a vNIC policy, and then add that vNIC policy to the service profile assigned to that server. All traffic from the vNIC or vHBA on the server travels through the I/O module to the same uplink port.

To check which HBA goes to which fabric we can run the following:

Each Fabric usually has a vSAN defined for it. To see the definition of each fabric we can check out the settings for each vHBA:

To check the NIC pinning we can run the following:

For each of the interfaces you can define a set of allowed VLANs, to see what they are you can run the following:

That is a list of allowed VLANs for that Nic.

To see how the physical ports correspond to the virtual ports on the Fabric Interconnect we can run the following:

So let’s connect to FI (Fabric Interconnect) A and see if we can confirm the virtual port of fc0 (remember the WWPN of that vHBA is the following 20:00:00:25:B5:02:0A:02). There are two ways to go about it. First we can find the interface our self and make sure it corresponds with 720:

That actually looks good, we see that it corresponds to vfc720 and it’s on vSAN 205. We can go further and make sure the config matches our server and the interface is up:

That all looks good and we can see that it’s actually bound to Vethernet8912, so let’s check out that interface to make sure it’s good:

We can see that the description matches our port “server 1/2, VHBA fc0” which is what we were trying to track down.

We can do a similar thing for eth0 (vNic1) as well.

The description fits and the appropriate VLANs are allowed.

We can also check out the local disk policy:

You can also check the boot order defined for the host:

We can see that the boot order is the following:

1. CD-ROM
2. Boot From SAN, first fc0 then fc1
3. PXE Boot from eth0

If you want to see what WWPNs are used for the boot from SAN you can run the following:

Now we can see that we will connect to first “50:0A:09:83:8D:1F:72:B5” using fc0 and then to “50:0A:09:84:8D:1F:72:B5”. If that doesn’t work we will use fc1 to either connect to “50:0A:09:83:8D:1F:72:B5” or “50:0A:09:84:8D:1F:72:B5”. To see the available boot-order policies you can run the following:

Then you can drill further down to see what the policy is made up of:

If I find any more interesting commands, I will definitely update this post.

More stuff I found, here is how you can check what LUNs an HBA is connecting to:

First list the available adapters on a blade:

Then Connect to the adapter and confirm the model and do the rest

This topic describes how to manage the virtual network interface cards (VNICs) in a virtual cloud network (VCN).

Overview of VNICs and Physical NICs

The servers in Oracle Cloud Infrastructure data centers have physical network interface cards (NICs). When you launch an instance on one of these servers, the instance communicates using Networking service virtual NICs (VNICs) associated with the physical NICs. The next sections talk about VNICs and NICs, and how they're related.

About VNICs

A VNIC enables an instance to connect to a VCN and determines how the instance connects with endpoints inside and outside the VCN. Each VNIC resides in a subnet in a VCN and includes these items:

• One primary private IPv4 address from the subnet the VNIC is in, chosen by either you or Oracle.
• Up to 31 optional secondary private IPv4 addresses from the same subnet the VNIC is in, chosen by either you or Oracle.
• An optional public IPv4 address for each private IP, chosen by Oracle but assigned by you at your discretion.
• An optional hostname for DNS for each private IP address (see DNS in Your Virtual Cloud Network).
• A MAC address.
• A VLAN tag assigned by Oracle and available when attachment of the VNIC to the instance is complete (relevant only for bare metal instances).
• A flag to enable or disable the source/destination check on the VNIC's network traffic (see Overview of VNICs and Physical NICs).
• Optional membership in one or more network security groups (NSGs) of your choice. NSGs have security rules that apply only to the VNICs in that NSG.
• Up to 32 optional IPv6 addresses. IPv6 addressing is currently supported only in the US Government Cloud. For more information, see IPv6 Addresses.

Each VNIC also has a friendly name you can assign, and an Oracle-assigned OCID (see Resource Identifiers).

Each instance has a primary VNIC that is automatically created and attached during launch. That VNIC resides in the subnet you specify during launch. The primary VNIC cannot be removed from the instance.

How VNICs and Physical NICs Are Related

This section is relevant to bare metal instances.

The OS on a bare metal instance recognizes two physical network devices and configures them as two physical NICs, 0 and 1. Whether they're both active depends on the underlying hardware:

• Oracle X5 servers (also called first-generation): Only NIC 0 is active.
• Oracle X6 servers: Only NIC 0 is active.
• Oracle X7 servers (also called second-generation): Both NIC 0 and NIC 1 are active. Each physical NIC has 25 Gbps bandwidth.

Vnic Mac Addresses Manualquotesdigital Outlook

NIC 0 is automatically configured with the primary VNIC's IP configuration (the IP addresses, DNS hostname, and so on).

If you add a secondary VNIC to a second-generation instance, you must specify which physical NIC the secondary VNIC should use. You must also configure the OS so that the physical NIC has the secondary VNIC's IP configuration. For Linux instances, see Linux: Configuring the OS for Secondary VNICs. For Windows instances, see Windows: Configuring the OS for Secondary VNICs.

About Secondary VNICs

You can add secondary VNICs to an instance after it's launched. Each secondary VNIC can be in a subnet in the same VCN as the primary VNIC, or in a different subnet that is either in the same VCN or a different one. However, all the VNICs must be in the same availability domain as the instance.

Vnic Mac Addresses Manualquotesdigital Shortcut

• Use your own hypervisor on a bare metal instance: The virtual machines on the bare metal instance each have their own secondary VNIC, giving direct connectivity to other instances and services in the VNIC's VCN. For more information, see Installing and Configuring KVM on Bare Metal Instances with Multi-VNIC.
• Connect an instance to subnets in multiple VCNs: For example, you might set up your own firewall to protect traffic between VCNs, so the instance needs to connect to subnets in different VCNs.

Here are more details about secondary VNICs:

• They're supported for these types of instances:

  • Linux: Both VM and bare metal instances. Also see Linux: Configuring the OS for Secondary VNICs.
  • Windows: Both VM and bare metal instances, but only on X7/second-generation shapes shapes with '2' in the name, such as VM.Standard 2.16 and BM.Standard2.52). For bare metal, secondary VNICs are supported only on the second physical NIC. Remember that the first physical NIC is NIC 0, and the second is NIC 1. Also see Windows: Configuring the OS for Secondary VNICs.

• There's a limit to how many VNICs can be attached to an instance, and it varies by shape. For those limits, see Compute Shapes.
• They can be added only after the instance is launched.
• They must always be attached to an instance and cannot be moved. The process of creating a secondary VNIC automatically attaches it to the instance. The process of detaching a secondary VNIC automatically deletes it.
• They are automatically detached and deleted when you terminate the instance.
• The instance's bandwidth is fixed regardless of the number of VNICs attached. You can't specify a bandwidth limit for a particular VNIC on an instance.
• Attaching multiple VNICs from the same subnet CIDR block to an instance can introduce asymmetric routing, especially on instances using a variant of Linux. If you need this type of configuration, Oracle recommends assigning multiple private IP addresses to one VNIC, or using policy-based routing as shown in the script later in this topic.

Source/Destination Check

By default, every VNIC performs the source/destination check on its network traffic. The VNIC looks at the source and destination listed in the header of each network packet. If the VNIC is not the source or destination, then the packet is dropped.

If the VNIC needs to forward traffic (for example, if it needs to perform Network Address Translation (NAT)), you must disable the source/destination check on the VNIC. For instructions, see To update an existing VNIC. For information about the general scenario, see Using a Private IP as a Route Target.

VNIC Information in the Instance Metadata

The instance metadata service (IMDS) includes information about the VNICs at these URLs:

• IMDS version 2:

• Legacy IMDS version 1:

Here's an example response that shows the VNICs that are attached to an instance:

Required IAM Policy

Vendor Mac Addresses

To use Oracle Cloud Infrastructure, you must be granted security access in a policy by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment you should work in.

For administrators: see IAM Policies for Networking.

Monitoring VNICs

You can monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring Overview and Notifications Overview.

Vnic Mac Addresses Manualquotesdigital White Pages

For information about monitoring the traffic coming in and out of VNICs, see VNIC Metrics.