My Home Lab/Testing ground

A few days ago, my buddy, Greg Sowell posted his Mobile Home Lab. I figured I would show off the rack in my home office.

This is a mixture of gear that powers the basic network for the network in my home and for testing, blog posts, support, and videos\. Each floor of our 3 story home currently has a Unifi Access point on it powered by a toughswitch POE.  My top level, which is where my office is has a unifi pro that does both 2.4 and 5GHZ.  The other levels just do 2.4ghz.  This will change once I get a POE switch that does 48volt to power the UNIFI pro.  I have stuck with UNIFI because of the bar in our house.  Any self-respecting geek needs a guest wifi network.  WPA keys are too hard to dish out for those late arriving guests after some rounds of crown and coke.  So a Cloudkey makes guest access an easy venture.

As stated before the UNIFIs are powered by a Toughswitch, and the PRO has a 48VOLT POE and is linked into a port on the tough switch.  This switch is then uplinked into one of the gig links of the active 2950 switch.  Various other devices, some not plugged in at the moment due to need to get to a cubby hole for a roof project, are plugged into the 100 meg ports on this 2950.  Things such as the DVR for the security system, network printers, ethernet to my desk for testing, network drives, etc.  The other gig port is uplinked to our internet router.

Our internet is handled by a workhorse Mikrotik 493AH. This has a Comcast cable and a local WISP connection, which is a backup.  From this router, I am initiating several VPN, EOIP, and other tunnels to various clients and remote networks.  If you notice, this router also has a little rubber duck antenna.  Inside is a r52 card that is usually disabled by default.  This is a backup network for testing if I suspect an issue on the internal wireless network. I can log in, enable the card, and associate to the SSID and see if things are okay, at least as okay for 802.11b/g speeds.

 

Most everything else is for Cisco certification testing and keeping up on those certs as well as labbing up scenarios. As you guys will hear on our latest podcast, GNS3 and packet tracer are great, but sometimes you can’t beat actual hardware.

I too have a console server for turning my devices on and off. I do not have fancy remote access turned on, but I can remote to 6 devices at a time without getting up and moving the 4 feet to move a cable.  Welcome to the future!

Run down of some equipment
Cisco 2950 (one production and one lab)
2x Cisco 3750
Cisco 3640
Cisco 3560-X
Cisco 1841
Various Mikrotik routers
Ubiquiti EdgeRouter Pro
Ubiquiti EdgeSwitch 16
(The infinity is going into production soon at a data center)

The Cisco 2541 at the top is a shelf for the monitor for the DVR.  Make a great shelf!  In the future, I hope to add a Juniper router and some more gear.  As always, if you are a manufacturer I would be glad to review some of your gear and even do some configuration videos on it.

On a side notes, you don’t see much wireless gear.  That is a separate spot in my office.

How I learned to love BGP communities, and so can you

BGP communities can be a powerful, but almost mystical thing.  If you aren’t familiar with communities start here at Wikipedia.  For the purpose of part one of this article we will talk about communities and how they can be utilized for traffic coming into your network. Part two of this article will talk about applying what you have classified to your peers.

So let’s jump into it.  Let’s start with XYZ ISP. They have the following BGP peers:

-Peer one is Typhoon Electric.  XYZ ISP buys an internet connection from Typhoon.
-Peer two is Basement3. XYZ ISP also buy an internet connection from Basement3
-Peer three is Mauler Automotive. XYZ ISP sells internet to Mauler Automotive.
-Peer four is HopOffACloud web hosting.  XYZ ISP and HopOffACloud are in the data center and have determined they exchange enough traffic amongst their ASN’s to justify a dedicated connection between them.
-Peer five is the local Internet exchange (IX) in the data center.

So now that we know who our peers are, we need to assign some communities and classify who goes in what community.  The Thing to keep in mind here, is communities are something you come up with. There are common numbers people use for communities, but there is no rule on what you have to number your communities as. So before we proceed we will need to also know what our own ASN is.  For XYZ we will say they were assigned AS64512. For those of you who are familiar with BGP, you will see this is a private ASN.  I just used this to lessen any confusion.  If you are following along at home replace 65412 with your own ASN.

So we will create four communities .

64512:100 = transit
64512:200 = peers
64512:300 = customers
64512:400 = my routes

Where did we create these? For now on paper.

So let’s break down each of these and how they apply to XYZ network. If you need some help with the terminology see this previous post.
64512:100 – Transit
Transit will apply to Typhoon Electric and Basement3.  These are companies you are buying internet transit from.

64512:200 – Peers
Peers apply to HopOffACloud and the IX. These are folks you are just exchanging your own and your customer’s routes with.

64512:300 – Customers
This applies to Mauler Automotive.  This is a customer buying Internet from you. They transit your network to get to the Internet.

64512:200 – Local
This applies to your own prefixes.  These are routes within your own network or this particular ASN.

Our next step is to take the incoming traffic and classify into one of these communities. Once we have it classified we can do stuff with it.

If we wanted to classify the Typhoon Electric traffic we would do the following in Mikrotik land:

/routing filter
add action=passthrough chain=TYPHOON-IN prefix=0.0.0.0/0 prefix-length=0-32 set-bgp-communities=64512:100 comment="Tag incoming prefixes with :100"

This would go at the top of your filter chain for the Typhoon Electric peer.  This simply applies 64512:100 to the prefixes learned from Typhoon.

In Cisco Land our configuration would look like this:

route-map Typhoon-in permit 20  
match ip address 102  
set community 64512:100

The above Cisco configuration creates a route map, matches a pre-existing access list named 102, and applies community 64512:100 to prefixes learned.

For Juniper you can add the following command to an incoming peer in policy-options:

set community Typhoon-in members 64512:100

Similar to the others you are applying this community to a policy.

So what have we done so far, we have taken the received prefixes from Typhoon Electric and applied community 64512:100 to it.  This simply puts a classifier on all traffic from that peer. We could modify the above example to classify traffic from our other peers based upon what community we want them tagged as.

In our next segment we will learn what we can do with these communities.