A Free and Hands-On Approach to Learning Kubernetes

November 14, 2018 at 10:03 pm

Kubernetes

Containers running on a cluster (Kubernetes) has become the rage for application deployment. In the CBT Nuggets course I am working on right now (CCIE RS Evolving Technologies), I teach you all about containers and Kubernetes.

If you already know all about containers and want to get your hands on Kubernetes – there is an excellent (and free) interactive course here:

https://kubernetes.io/docs/tutorials/kubernetes-basics/

I did not have time to go through the whole thing – but I certainly liked what I did see.

Enjoy!

CCIE DC – 1.1.a Link Aggregation – Virtual Port Channel Example

October 2, 2018 at 11:18 pm

This post examines a sample configuration of a virtual port channel. This port channel is created between two Nexus 7K systems and downstream Nexus 5K systems. This is part of the link aggregation section of the exam requirements in CCIE Data Center. Below is the diagram you can use for reference in this example. We will only demonstrate the config of a single VPC peer since the other peer is simply a mirror of this configuration.

Virtual Port Channel

Our previous post on this subject focused on the configuration steps. You can find it here: https://www.ajsnetworking.com/ccie-dc-1-1-a-link-aggregation-configure-virtual-port-channels/

The Configuration

First, we will prepare the vPC keepalive link for this scenario. Do not be thrown off by the name of our VRF. This configuration does not technically fall under the vPC config (yet!).

N7K-A# configure terminal
N7K-A(config)#  vrf context VPC-KEEPALIVE
N7K-A(config-vrf)# interface ethernet 3/18
N7K-A(config-if)# no switchport
N7K-A(config-if)# vrf member VPC-KEEPALIVE
Warning: Deleted all L3 config on interface Ethernet3/18
N7K-A(config-if)# ip addr 209.165.200.225/24

Next, we will configure the vPC domain (after enabling the feature of course) and configure the peer-keepalive link we prepped.

N7K-A(config)# feature vpc
N7K-A(config)# vpc domain 10
N7K-A(config-vpc-domain)# peer-keepalive destination 209.165.200.226 source 209.165.200.225 vrf VPC-KEEPALIVE

Now, we configure a port channel between our vPC peers and configure it as the vPC peer link.

N7K-A(config-vpc-domain)# interface ethernet 3/16-17
N7K-A(config-if)# channel-group 10
N7K-A(config-if)# interface port-channel 10
N7K-A(config-if)# vpc peer-link

Next, we will head down to the N5K and configure a “plain ole” LACP port channel.

N5K-A# config t
N5K-A(config)# feature lacp
N5K-A(config)# int e 1/1-2
N5K-A(config-if-range)# channel-group 201 mode active

Now, it is time to configure the vPC on the N7K.

N7K-A(config-if)# feature lacp
N7K-A(config)# interface e 3/21
N7K-A(config-if)# channel-group 201 mode active
N7K-A(config-if)# int port-channel 201
N7K-A(config-if)# vpc 201

The Verification

You should note that you can and should perform verifications as you go along here. For example, you can verify reachability, check the port channels that are configured, and watch the progress of the vPC as you configure it. For brevity here, we will just end this post and this example with our critical show vpc command.

N7K-A(config-if)# show vpc brief
Legend:
     (*) - local vPC is down, forwarding via vPC peer-link

vPC domain id                          : 10
Peer status                            : peer adjacency formed ok
vPC keep-alive status                  : peer is alive
Configuration consistency status       : success
Per-vlan consistency status            : success
Type-2 consistency status              : success
vPC role                               : secondary
Number of vPCs configured              : 1
Peer Gateway                           : Disabled
Dual-active excluded VLANs and BDs     : -
Graceful Consistency Check             : Enabled
Auto-recovery status                   : Enabled (timeout = 240 seconds)
Operational Layer3 Peer-router         : Disabled
Self-isolation                         : Disabled

vPC Peer-link status
--------------------------------------------------------------------------------
id Port Status  Active vlans Active BDs
-- ---- ------ -------------------------------------------------------------
1  Po10 up      1,12 -

vPC status
------------------------------------------------------
id     Port        Status Consistency  Active VLANs
----- ------------ ------ ----------- ----------------
201    Po201       up      success     1,12

For even more information – check out this Cisco documentation at https://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/design_guide_c07-625857.html
Pearson Education (InformIT)

CCIE DC – 1.1.a Link Aggregation – Configure Virtual Port Channels

September 30, 2018 at 7:14 pm

This post examines the limitations you should be aware of when configuring virtual port channels. It also examines the configuration steps. This is part of the link aggregation section of the exam requirements in CCIE Data Center.
Aggregation

Our previous post on this subject focused on the control plane. You can find it here: https://www.ajsnetworking.com/ccie-dc-written-1-1/

Limitations

Before you dive right into the configuration steps, you should be aware of the limitations when it comes to your virtual port channels. These include:

  • In the “standard” virtual port channel – you use exactly two vPC peer switches – no more than that are supported. A later post here will cover the extended vPC technology, but this post does not consider that.
  • It is not possible for one of your peer vPC devices to participate in more than one vPC.
  • All ports for a given vPC must exist in the same VDC (Virtual Device Context). You cannot span a vPC across multiple VDCs.
  • A 10 Gbps link is required for the vPC peer link. Typically, you should use at least two links in a port channel for this component.
  • A vPC is a Layer 2 construct. There is no support for the creation of Layer 3 vPCs.

The Configuration Steps

As you might guess, you should double-check all of your physical connections before launching into the vPC configuration. Ensure that your physical link(s) for the peer link are in place and healthy. Also, keep in mind that you make these configurations on each of the vPC peer devices.

Step 1. First, you must enable the vPC feature – you do this with the command: feature vpc

Step 2. Create the vPC using the vpc domain <domain_id> command

Step 3. Next, specify your peer keepalive link – this link can be in any VRF (including Management); use the command – peer-keepalive destination <remote_peer_ip> source <local_peer_ip> vrf <vrf_name>

Step 4. Configure your peer link. This is typically done with a port channel (as described above) as follows:

interface port-channel <port_channel_id>
switchport mode trunk
vpc peer-link

Step 5. Configure a port channel that leads to the downstream device; use the command vpc <domain_id> under the port channel

In the next post, I will walk you through a configuration on live equipment. We will also walk through the important vPC verifications you would want to perform at that time. As always, thanks for reading.

For even more information – check out this Cisco documentation at https://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/design_guide_c07-625857.html
Pearson Education (InformIT)

CCIE DC – 1.1.a Link Aggregation – vPC Control Plane

September 29, 2018 at 9:53 pm

Enjoy this latest post on the control plane functions of the vPC. This is part of the link aggregation section of the exam requirements in CCIE Data Center.
Aggregation

Our previous post on this subject focused on the data plane. You can find it here: https://www.ajsnetworking.com/ccie-dc-written-1-1-a-link-aggregation-vpc-data-plane/ 

The vPC Control Plane

The vPC peer link between your vPC peers is the workhorse for the control plane messages (BPDUs, LACP, CFSoE) that must flow between them. The control plane is responsible for the following:

  • Exchange of Layer 2 forwarding tables for the vPC peers – MAC addresses learned on one switch are instantly synced to the other switch using CFSoE; this reduces traffic on the vPC peer link
  • Consistency and compatibility checks – CFSoE exchanges information to ensure both peer support vPC and that he member ports are in a compatible state
  • Sync IGMP snooping information – inbound IGMP traffic triggers synchronization much like MAC address learning
  • Monitor the status of vPC member ports – orphan port behavior may occur due to failure conditions
  • Sync the ARP tables of the vPC peers – again CFSoE is used to keep these important tables in sync; this speeds convergence if one of the vPC peers must reload
  • Determine the primary and secondary vPC peer devices – the primary is responsible for the processing of BPDUs; the election is non-preemptive
  • Agree on LACP and STP parameters – this is needed because the vPC announces itself to the downstream switch as a single logical switch

For even more information – check out this Cisco documentation at https://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/design_guide_c07-625857.html
Pearson Education (InformIT)

CCIE DC Written – 1.1.a Link Aggregation – vPC Data Plane

September 28, 2018 at 2:40 pm

vPC

Here is an important question about the data plane with your vPC. Is the vPC peer link (typically an EtherChannel) between your vPC peer switches used for forwarding data traffic? In a “normal” network condition, the answer is no. The vPC peer link is not used for the data traffic of the vPC and is considered to be an extension of the control plane between the vPC peer switches. The vPC peer link carries the following type of traffic:

  • vPC control traffic, such as Cisco FSoE, BPDUs, and LACP messages
  • Flooding traffic, such as broadcast, multicast, and unknown unicast traffic
  • Traffic from orphan ports

So we note that the peer link is used specifically for switch management traffic and occasionally for the data packets from failed network ports. This behavior of our vPCs enables the solution to scale because the bandwidth requirement for the vPC peer link is not directly related to the total bandwidth of all vPC ports.

What about loop prevention? One of the most important forwarding rules for a vPC is exactly about that as I have shown in the illustration above. Note this sample traffic flow:

  1. A packet enters the vPC peer switch via a vPC member port.
  2. The packet then goes to the other peer switch via the peer link
  3. The packet is then not allowed to exit the switch on the vPC member port.
  4. This packet can exit on any other type of port, such as an L3 port or an orphan port.

This rule prevents the packets that are received on a vPC from being flooded back onto the same vPC by the other peer switch.

What about this traffic from orphan ports? Understand there are two types of orphan ports for this discussion:

  • The first type of orphan port is the one that is connected to an orphan device and is not part of any vPC configuration. For this type of orphan port, normal switch forwarding rules are applied. The traffic for this type of orphan port can use a vPC peer link as a transit link to reach the devices on the other vPC peer switch.
  • The second type of orphan port is the one that is a member of a vPC configuration, but the other peer switch has lost all the associated vPC member ports. For this type of orphan port, the vPC loop avoidance rule is disabled. In this special case, the vPC peer switch will be allowed to forward the traffic that is received on the peer link to one of the remaining active vPC member ports.

CFSoE is used to synchronize the Layer 2 forwarding tables between the vPC peer switches. Therefore, there is no dependency on the regular MAC address learning between the vPC peer switches. CFSoE-based MAC address learning is applicable only to the vPC ports. This method of learning is not used for the ports that are not part of the vPC configuration.

CCIE DC Written – 1.1.a Link Aggregation – vPC Components

September 24, 2018 at 1:17 am

virtual port channels

Virtual Port Channel master really does begin with a knowledge of the components that make them up. This post assumes you are familiar with the very basics of virtual port channels – knowledge you have gained through CCNA/CCNP Data Center.

Here are the components of the vPC:

  • vPC peers – two switches that act as a single logical switch to the downstream device.
  • vPC peer link – a link between the vPC peers that is used to synchronize state. Consider two physical links in a port channel. MAC address table synchronization, as well as other control plane, functions synchronize over this link.
  • Cisco Fabric Services – this protocol is responsible for synchronization between the peers. CFSoE is run. STP is modified to keep the peer link ports forwarding.
  • vPC peer keepalive link – Layer 3 communication link between the vPC peers to act as a secondary test of connectivity.
  • vPC – the virtual port channel depicts itself to the downstream device as a single logical switch. The downstream device does not need virtual port channel support. It forms its standard port channel configuration.
  • vPC member ports – a member of the vPC on the vPC peer switch.
  • vPC domain – a numeric identifier for the vPC domain.
  • Orphan device – a device that is connected to only one peer in the vPC.
  • Orphan port – the switchport that connects to an orphan device.
  • vPC VLANs – the VLANs permitted to use the vPC. They must be permitted on the peer link.
  • Non vPC VLANs – the VLANs not permitted on the vPC.