How to Create Non-Routable Isolated (but not Private) Vlans on a Cisco Catalyst Layer 3 Switch

data_sheet_c78-530976-1

First off let’s start out by saying that Isolated VLANs and Private VLANs are two completely different things… they are not at all the same. To a network administrator, this should make perfect sense. However, a Server or Virtualization Administrator may or may not know the different. Because of this, I hear many non-network Administrators toss around the term “Private VLAN“, when they actually mean to say “Isolated Vlan“, or more specifically what they are referring to is a “Non-Routable” VLAN.

What’s confusing is that the networks that we plan to use over our newly commissioned Non-Routable VLANs can correctly be refereed to as Private networks. They are private because no traffic can get in our out without a direct lP link to this network. However the VLANs themselves are not private, just isolated, or non-routable.

I believe that you can see where the confusion comes from.

So allow me to provide a bit of context before we go any further.

In my specific case, I need to create what are commonly (however incorrectly) referred to as Private VLANs to act as a back-end network for an OpenStack deployment. I cannot tell you how often I have heard someone make this mistake. This new VLAN, or network, needs to remain isolated from the outside world, meaning that it does not need to be able to route to any other network, or out to the internet. Rather, this new VLAN needs to send isolated traffic back and forth between network nodes deployed as part of my OpenStack Deployment. What I am describing here is not a “Private VLAN”, it is a “Non-Routable”, or “Isolated VLAN”

So please let’s make sure that we are using the correct terms.

So here is how you do it.

In my case I want to create two isolated VLANS for isolated traffic between my OpenStack nodes. Note that I am using nested virtualization, so my OpenStack nodes are themselves VMs.

First lets create what I will refer to as NR-1 (non-routable-1). We will use the VLAN id 666 as its easy to remember.

s3560#conf t
Enter configuration commands, one per line. End with CNTL/Z.
s3560(config)#vlan 666
s3560(config-vlan)#name NR-1
s3560(config-vlan)#end

Now lets create what I will refer to as NR-2. (non-routable-2)

s3560#conf t
Enter configuration commands, one per line. End with CNTL/Z.
s3560(config)#vlan 667
s3560(config-vlan)#name NR-2
s3560(config-vlan)#end

How lets check out our vlans, starting with 666

s3560#show vlan id 666

VLAN Name Status Ports
—- ——————————– ——— ——————————-
666 NR-1 active

…trunc…

Now let’s take a look at 667

s3560#show vlan id 667

VLAN Name Status Ports
—- ——————————– ——— ——————————-
667 NR-2 active

…trunc…

Note, that if I wanted to make these VLANs routable, I would need to add a layer3 interface. We are obviously not going to do that here.

Now lets add these new VLANs to our existing virtualization server trunks. We are going to do this to a range of interfaces to save time. Note that I was already allowing VLANS 101-104 and 192 on these trunks.

s3560#conf t
Enter configuration commands, one per line. End with CNTL/Z.
s3560(config)#interface range GigabitEthernet0/15 -18
s3560(config-if-range)#switchport trunk allowed vlan 101-104,192,666,667
s3560(config-if-range)#end

Now don’t forget to save our config.

s3560#copy run start
Destination filename [startup-config]?
Building configuration…
[OK]
0 bytes copied in 1.443 secs (0 bytes/sec)

Yum: Under the Covers with GPG Keys

Skeleton_key_1_keychain_sculpture_photo_cut_outs-r558fef9b275d4609b522ac07970a6af6_x7sa6_8byvr_324Hey look at this spooky key. Don't be frightened little one. Nothing scary is going to happen to you here. This is a safe place. As a matter of fact, if you stick around you might just learn a thing or two. A thing or two about GPG!

First off do any of us really know what GPG stands for? Well yes we do! It stands for GNU Privacy Guard. RPM Package creators use GPG to apply a digital signature to their packages. If a package was tampered with, then its GPG signature will no longer match what was placed in the original package.

First off to check what keys you have installed on your Linux server you can run the following rpm command as show in the example below.

[root@ip-172-31-22-45 ~]# rpm -qa gpg-pubkey
gpg-pubkey-0608b895-4bd22942
gpg-pubkey-fd431d51-4ae0493b
gpg-pubkey-2fa658e0-45700c69

 

Neet I have three keys installed. But lets say want to install another one. Well I can do so with the command below. In this example I have navigated to /etc/pki/rpm-gpg and am going to install the redhat beta key on my server.

[root@ip-172-31-22-45 rpm-gpg]# rpm –import RPM-GPG-KEY-redhat-beta

Hey that was fun. Now lets get our hands a bit dirtier.

Want to get more information on a specific key. Then this command is your huckleberry. Here you can see that this is the pubkey for the EPEL repo.

[root@ip-172-31-22-45 rpm-gpg]# rpm -qi gpg-pubkey-0608b895-4bd22942
Name        : gpg-pubkey                   Relocations: (not relocatable)
Version     : 0608b895                          Vendor: (none)
Release     : 4bd22942                      Build Date: Sat 14 Jun 2014 09:13:58 AM EDT
Install Date: Sat 14 Jun 2014 09:13:58 AM EDT      Build Host: localhost
Group       : Public Keys                   Source RPM: (none)
Size        : 0                                License: pubkey
Signature   : (none)
Summary     : gpg(EPEL (6) <epel@fedoraproject.org>)
Description :

 

To verify signature of a downloaded package, use the rpm command as shown below. In this example I have highlighted the key that was used to sign this package.

# rpm -vK nautilus-dropbox-1.6.0-1.fedora.i386.rpm
nautilus-dropbox-1.6.0-1.fedora.i386.rpm:
    Header V3 RSA/SHA1 Signature, key ID 5044912e: OK
    Header SHA1 digest: OK (a4d51906633f92913db075ba33946f50999c245e)
    V3 RSA/SHA1 Signature, key ID 5044912e: OK
    MD5 digest: OK (1b8ff7abc18f68bf274e24fc57fd3a87)

 

Using the bolded information in the example above, I can then use this information to track down the exact key that was used to sign the package.

[root@localhost Downloads]# rpm -qa | grep 5044912e
gpg-pubkey-5044912e-4b7489b1

 

Is this awesome, well not really, but you never know when you might need to use this information. Like on a test. Wink Wink.

Related articles

Using Yum Update to Apply Security Patches Only
How to Enable EPEL Repository on CentOs for Yum
Signing rpm packages with GPG