DHCP-Snooping and Dynamic Arp Inspection

Q. What is DHCP Snooping?

A.
1. Switch will watch all dhcp requests and build a table of ip-mac bindings for each port.
2. Switch will drop all dhcp RESPONSES from untrusted ports. (eg. If an end user places a dhcp server on their PC or device and connects to your switch, they won't be able to hand out addresses)

Q. What ports should I make trusted or untrusted?

A. Any ports you expect a dhcp response to come from. This includes the port your DHCP server resides on, as well as switch uplink ports. Make everything else untrusted.

Q. What is option 82?

A. Option 82 adds switch and port information to the DHCP request, so that the dhcp server can log information about the exact location of the client. Useful for tracking down malicious end users.

Q. I am on a procurve and there is something about authorized servers.

A. Put in the IP address of any DHCP servers you have in your network as authorized.

Q. So what about the arp inspection stuff?

A.

Malicious use 1. Think of a malicious user who responds to an arp request for the default gateway's IP address with their own mac. Now all the traffic goes to the malicious user rather than the router. (man in the middle attack)

Malicious use 2. A malicious or malfunctioning computer can send out thousands of arp responses filling up arp tables

Malicious use 3. A malicious or malfunctioning computer can send out arp responses (or gratuitous arp) to false mac addresses breaking network communication.

Arp inspection uses the DHCP snooping binding table to ensure that any arp response from an end user is only for the IP and Mac address they have been properly given by the DHCP server.

Q. This sounds like great security enhancements, are there any "Gotcha's I should know about?"

A. Two of them I can think of.

#1 Say you love this idea and go turn on dhcp-snooping and ip arp inspection today. A computer arp's for the DG or another device but their IP is not in the table yet, they still have a day left on their DHCP lease before they need to renew it. Their arp is dropped and they can't talk to that device. Fix#1, enable DHCP-snooping AT LEAST a full DHCP lease time prior to enabling arp inspection.

#2 Similar to number one. So say you have dhcp-snooping going, and you enable arp inspection, and everything is working fantastic. Now your maintenance window comes along and you need to upgrade your ios and reboot the switch. Now you rebooted and the DHCP-binding table cleared and you are stuck with problem #1 again, until the DHCP leases are renewed clients can't ARP. Fix#2 There is a way to save the database to flash before you reload, or even better, store a copy of the DHCP-snooping table off the switch, on a tftp server.


Q. Configurations?

Cisco:

(config)# ip dhcp snooping
(config)# ip dhcp snooping vlan 20,25-28
(config)# ip dhcp snooping verify mac-address
(config)# interface GigabitEthernet 2/2
(config-if)# ip dhcp snooping trust (for DHCP server connected interfaces and switch uplinks *do all of them since spanning tree could re-converge and send requests up alternate paths!*)
(config)# ip dhcp snooping limit rate 10
(config)# ip dhcp snooping database tftp://10.1.1.1/file
(config)# show running-config dhcp
(config)# ip arp inspection vlan 20,25-28


Procurve:
dhcp-snooping
dhcp-snooping authorized-server #.#.#.#
dhcp-snooping authorized-server #.#.#.#
dhcp-snooping vlan 5 10 20 99

interface a4
dhcp-snooping trust

dhcp-snooping database file tftp:///

show dhcp-snooping
show dhcp-snooping stats
show dhcp-snooping binding

arp-protect vlan 5 10 20 99


**dhcp-snooping on many(most?) procurve switches breaks PXE booting/imaging, and as far as I can tell has only been fixed on a few switch models, if you use PXE booting, test this feature before rolling it out to a production environment**


I will look at IP source-guard  soon as it also uses the dhcp-snooping database

Thoughts? Suggestions? Accusations? Comments on my mental health?

Cisco Live Sessions

Cisco allowed virtual sessions free this year, and they are recorded so I am finally getting around to watching a few. I strongly recommend browsing the selection.


Some highlights from the QoS Design clinic I'm watching now.

Uncompressed HD video - 1.5 Gbps
compressed to - 3-5 Mbps (300:1)
Which is why a single packet dropped in 10,000 is visible to watchers.

This makes it 100 times more sensitive than voice and requires sub-millisecond jitter.


Suggests not just marking packets but also policing.

Eg. No voice endpoint will ever send more than 128kps of data, so if traffic is coming in a trusted voice port and getting tagged with your Voice QoS designation, either drop or re-classify it when it exceeds the 128kps threshold.

-Priority Queue should be less than 33% of link but best effort guaranteed 25%

EtherChannel QoS

On a Catalyst 4k and 6k cisco switches, apply INBOUND QoS policies to the Port-channel

On a Catalyst 2k and 3k, ingress policies are applied to the physical ports.

Egress Queuing is always applied to the member interfaces on all types.

Hopefully this will get cleared standardized in the future eh.

HP5400 blade failures

Every so often I find a dead blade or switch... (thanks for the job security HP). And looking back at the logs you'll see tombstone errors:

W 07/28/11 19:55:11 00374 chassis: Slot A Slave ROM Tombstone: 0x13000101
W 07/28/11 19:52:05 00374 chassis: Slot A Failed to boot-timeout-(ROM_ALIVE)
W 07/28/11 19:52:04 00374 chassis: Slot A Slave ROM Tombstone: 0x13000101
W 07/28/11 19:48:58 00374 chassis: Slot A Failed to boot-timeout-(ROM_ALIVE)
W 07/28/11 19:48:56 00374 chassis: Slot A Slave ROM Tombstone: 0x13000101
W 07/28/11 19:45:50 00274 chassis: (84) Slot A: Blade Crash detected - Available

And what is the fix? Well a reboot of course (if you are lucky). But luckily in a blade switch you can just reload that module. Type:

#reload module A (where A is the letter of the blade)


In probably 3/4 the cases this seems to fix it, and you may never have a problem with it again. In the other quarter, you can try this repeatedly but the only thing that works: call up HP and get a replacement.


If you are lucky enough to have it come up, don't expect it to come up right away either, it takes around two minutes to reload the blade, then you will probably still see:

#show log -r
I 07/28/11 21:25:52 00422 chassis: Slot A Ready
I 07/28/11 21:25:36 00376 chassis: Slot A Download Complete
I 07/28/11 21:25:34 00375 chassis: Slot A Downloading
W 07/28/11 21:25:28 00374 chassis: Slot A Failed to boot-timeout-(ROM_ALIVE)
W 07/28/11 21:25:27 00374 chassis: Slot A Slave ROM Tombstone: 0x13000101
W 07/28/11 21:22:21 00374 chassis: Slot A Failed to boot-timeout-(ROM_ALIVE)
W 07/28/11 21:22:20 00374 chassis: Slot A Slave ROM Tombstone: 0x13000101
W 07/28/11 21:19:14 00374 chassis: Slot A Failed to boot-timeout-(ROM_ALIVE)
W 07/28/11 21:19:12 00374 chassis: Slot A Slave ROM Tombstone: 0x13000101
W 07/28/11 21:16:06 00374 chassis: Slot A Failed to boot-timeout-(ROM_ALIVE)
W 07/28/11 21:16:05 00374 chassis: Slot A Slave ROM Tombstone: 0x13000101
I 07/28/11 21:13:00 02756 chassis: Slot A is powered up.
I 07/28/11 21:12:57 02755 chassis: Slot A is powered down.
I 07/28/11 21:12:45 02762 chassis: Request for "reload module A".


You might notice that it took 13 minutes before the switch decided to bring up the blade after the module reload, enough time for you to give up on it and start trekking out with a replacement. Cheers to those of you lucky enough to work with procurve gear!

MRTG for large environments

So, lots of sites try to tell you how to install MRTG to monitor your computer, and a few tell you how to monitor a router or two, but what if you have hundreds or thousands of interfaces you want to see traffic on? I prefer having them show up on multiple organized web pages rather than one giant 5000 graph long page.



Here is my guide to installing MRTG in a large network environment on Debian Linux

Step one - make sure all your target devices (routers switches etc.) have an snmp read only string that does NOT include special characters like ! $ or >. You just need to stick with lowercase uppercase and numbers to get cfgmaker to work.


On a cisco - add
snmp-server community SNMPSTRING123 ro
to add a read only string of SNMPSTRING123





sudo apt-get install apache2
sudo apt-get install snmpd
sudo apt-get install mrtg

make sure you add the snmp string to your /etc/snmp/snmpd.conf file (see some instructions by Clicking Here )


Now for the MRTG part.


mrtg installs into /etc/mrtg.cfg you should move it into /etc/mrtg/mrtg.cfg to keep things neat

Next create a directory at /var/www/mrtg to place your web pages in.

mkdir /var/www/mrtg

Now we need to make a config

gather all the switch or router IPs that you want on a SINGLE web page. This might be one 200 interface switch, or it might be a building worth.

run

sudo cfgmaker --global 'WorkDir: /var/www/mrtg' --global 'Options[_]: bits,growright' --output=/etc/mrtg/mrtgG1.cfg SNMPSTRING123@Router1IPAddress SNMPSTRING123@Router2IPAddress SNMPSTRING123@Router3IPAddress





Notice I called this mrtgG1.cfg for group 1, change this each time you set up a new web page and new group of switches/routers


next, using your favorite editor modify the new file to run as a daemon

vi /etc/mrtg/mrtgG1.cfg

add the lines

RunAsDaemon: Yes
Interval: 5


these set it to run as a daemon, every 5 minutes

next we can build the actual web page.

sudo indexmaker --output=/var/www/mrtg/Group1.html /etc/mrtg/mrtgG1.cfg

This will pull the interface info from the mrtgG1.cfg file and make a web page out of it.


Repeat these steps for group 2 and group 3 etc.

Next you will probably want an index page to link to the individual group pages. Nothing fancy for me, just create

vi /var/www/mrtg/index.html

add the regular html, a title, and a few links like this:
<A HREF="http://serverIP/mrtg/Group1.html"> Routers1-3 Interface Traffic </a>
<p>
<A HREF="http://ServerIP/mrtg/Group2.html"> Switches4-12 in Building ABC Traffic </a>
<p>

You can certainly get fancier but this is just a starting point.


By now you can browse to your index page and click a few of your links. You may or may not have graphs showing up yet. Sometimes MRTG needs to restart a few times to create all the necessary files.

The way most assured to work right now is to type

ps -e

Find the mrtg process, note the number next to it (say 12345) and type

kill 12345

Then start mrtg again with

sudo env LANG=C /usr/bin/mrtg /etc/mrtg/mrtgG1.cfg


*note, you can do this for each mrtg group (process) you created*


Ok, now wait ten minutes (remember it only polls the switches every 5) and see if you have some data showing up. Hopefully you do, if not try kill/restarting the process again.


Now if you do have graphs showing up and a nifty index page to surf to them it might seem like you are done but first you need to add it to init.d and startup. You don't want all mrtg to stop next time you reboot do you?


place the following file in your /home directory

vi /home/mrtgG1

---

(this config file originally created by iceflatline@gmail.com) at iceflatline.com and only slightly modified by me. The credit goes ENTIRELY to him.)





### BEGIN INIT INFO

# Provides: mrtg
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: mrtg init script
# Description: This file is used to start, stop, restart,
# and determined status of the mrtg daemon.
# Author: iceflatline
### END INIT INFO

### START OF SCRIPT

set -e
# PATH should only include /usr/* if it runs after the mountnfs.sh script

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="mrtg"
NAME=mrtgG1
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="/etc/mrtg/mrtgG1.cfg"
PIDFILE=/etc/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the mrtg package is not installed

[ -x "$DAEMON" ] || exit 0

# Load the VERBOSE setting and other rcS variables

. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
# Function that starts the mrtg daemon
start()
{
env LANG=C start-stop-daemon --start --quiet --exec $DAEMON -- $DAEMON_ARGS
}
# Function that stops the mrtg daemon
stop()
{
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE
}
case "$1" in
start)
log_daemon_msg "Starting $DESC"
start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;;
esac
;;
stop)
log_daemon_msg "Stopping $DESC"
stop
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;;
esac
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC"
stop
case "$?" in
0|1)
start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;;
esac
;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME"
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}"
;;
esac
exit 0
### END OF SCRIPT

---

Note the two lines toward the top

NAME=mrtgG1
DAEMON_ARGS="/etc/mrtg/mrtgG1.cfg"

These will have to match whatever you called your .cfg and .pid files.




Now issue the following commands to make it executable and move it to the startup folder

cd /home
sudo chmod +x mrtgG1
sudo mv mrtgG1 /etc/init.d/


issue the following to add it to run levels for startup
sudo update-rc.d mrtgG1 defaults


test with
sudo /etc/init.d/mrtgG1 restart

repeat to make each .cfg file run at startup.



Hooray, you now have mrtg running, graphing the bandwidth used on a slew of switches, with separate groups running in separate daemons so your server can get through them all in the 5 minute window it has before it needs to start again, and they will start up again if you need to reboot the server. Hopefully this helped someone! Let me know any tweaks, if you know how to run the multiple .cfg files out of one startup file, or if I made a mistake somewhere!

RIPv2 passive interfaces

So the only RIP to be encountered on the ROUTE test appears to be passive interfaces.

So in EIGRP and OSPF passive interfaces do not send or receive routing updates, they do not participate in neighborships or the routing protocol.

RIPv2 on the other hand:
A passive interface does not SEND updates out this interface, it will still install RIP updates it receives.


R1#
router rip
version 2
passive interface s0/0/1


Router 1 will now receive routes from s0/0/1 but will not send any information out s0/0/1.

Multicast Vlan Feature

So, after upgrading to a new version of WLC code, 7.0.116.0 you might notice a new feature in your SSID configs, multicast vlan feature. I wasn't sure what it did so I looked it up and best as I can tell it goes like this.


Enabled per ssid (a handy checkbox or config wlan multicast interface wlan_id enable interface_name)

If you use the VLAN select feature, each client will be listening to the multicast stream on a different VLAN, and the upstream router must send a copy for each VLAN, and multiple copies of a multicast stream are sent out over the air. (not very good use of your air time, and negates some of the purpose of multicast).

Multicast optimization lets you create a multicast vlan, and the controller will make sure all multicast streams go out on the multicast vlan so that the upstream router only sees the single multicast entry for all the VLANs in your pool.

So clients on separate vlans will still only have one single multicast stream over the air.


Since I'm not currently using VLAN pooling I'm not 100% solid on how this would look in the real world but certainly seems a strong feature to have enabled if you were.

Layer 2 edge port security

I was asked the question "how I would secure switch ports" in an interview, and of course I blanked on most of it, but thought I would compile a list now that I'm not in the hot seat.

1. Not allow trunking - in cisco terms switchport mode access (if it needs to be a trunk, make sure the native vlan is not vlan 1, and you add switchport trunk allowed vlan x,y,z to only allow necessary vlans on the port.)

2. BPDU guard and/or root guard - do not allow your spanning tree to be hijacked. BPDU guard will block or restrict any port that someone attaches a spanning tree capable device to (eg. anything that sends a BPDU will shut down the port) while root guard will block it if anything off that port attempts to become your spanning tree root. This can be attached to your own switch uplinks/downlinks if you KNOW you never want the neighbor switch or any switches down that branch to ever be root.

3. no cdp enable - no sense broadcasting out to every client what switch, Management IP address, port, IOS version etc. that they are connected to.

4. DHCP snooping/ Dynamic ARP inspection - There are a few commands related to DHCP snooping that will give you a few benefits.
a. You can block any edge port that offers DHCP responses - blocking clients from running a DHCP server on your network.
b. You can tell what IP address has been dynamically assigned out a port, and if an ARP response is sent out not matching that address (eg. IP spoofing) block the port
c. limit how many DHCP requests are sent out per second
d. I think there is another command or two that can go with this for more features but I haven't studied switch since it was the BCMSN so it has been a year+

5. Port Security - limit what mac addresses are allowed to be used on a port
a. options here include statically set addresses, or sticky addresses so you don't have to type them in yourself and the switch saves the address first seen on the port.
b. You can then limit how many addresses are allowed in a port, (limit 1 etc.)
c. Obviously MAC addresses are easy to spoof if they unplugged a different device, but if it is just an open port, they aren't likely to guess a statically assigned mac address

6. shut down unused ports - I know, I'm terrible at this, but shut or disable ports that do not have a computer plugged into them. No sense letting someone walk into your IDF and plugging in any open port without you knowing about it.

7. Network Access Control - Bit more involved here - you can have it fairly simple where the machine and user need to match up with an AD or Radius authentication, to more advanced options where User A on Machine x at Time H is placed on vlan V, but if they are on a different machine or a different time, perhaps they are placed in a more restricted vlan since it isn't their normal working hours.
NAC also has options to verify the machine is up to date on patches and virus definitions before being placed on a vlan. Lots and Lots to think about before implementing NAC.

8. Black Hole Vlan - Just in-case you forget to shut the port down, assign all unused ports to a "Black Hole Vlan" or a vlan that is not routed or trunked so the user can't get anywhere if they do manage to connect.

9. VACLs, I typically do ACLs at the router, but feel free to assign VACLs to limit traffic WITHIN the vlans to further secure INTRA-VLAN traffic. (if for some terrible reason your switch management IP is on the client vlan, make sure you add a VACL and/or vty ACL to keep clients from accessing it!!!)



10. ??? I'm sure there is more, what have I missed? Feel free to comment, argue, or add more for typical edge port security.

EIGRP stub redistribution

Q. Will the following static route be redistributed?

ip route 10.1.1.0 255.255.255.0 10.2.2.1

router eigrp 100
redistribute static 1000 1 255 1 1500
eigrp stub


A. NO - eigrp stub default is summary and connected, redistributed static routes will NOT be advertised based on that stub command. The command eigrp stub static needs to be included as well

EIGRP Stub Networks

A stub router indicates in it's hello packet, to let other routers know it is a stub router.

Q. Why use a EIGRP Stub?

A.
1. Limit amount of convergence traffic sent over links
2. Tell other routers you will NOT be a transit path for any additional networks. (eg. if a router is in active because it lost it's path, do not query me because I won't help you)
3. Avoid possible Stuck-In-Active scenarios

Typically, only remote routers are set as stubs, and only if they are single router sites. When a route goes down, stub routers ARE NOT QUERIED to find an alternate path, hub (regular neighbor routers) answer on behalf of the stub router.

*It is useful to note, stub features do not prevent other routers from advertising routes to the stub router.

Cisco defines a stub router as one which "core transit traffic should not flow"


Configure a router as a stub with the commands

eigrp stub [receive-only|connected|static|summary]

Any combination (other than receive-only) can be placed after the stub command.

The default is both connected and summary.

receive-only restricts the router from sharing any of it's routes with another router. When would you use this? If a router only has one interface in use, perhaps you have a router in place for the sole purpose of providing DHCP, VoIP gateway, or other services.

The connected, static, and summary commands are fairly self explanitory. Note that these must be in place AND the network command or redistribute command must be in use. Adding connected does not automatically add all connected routes to EIGRP, it only allows EIGRP to advertise them to neighboring routers if it is already in the routing table.

If a true stub network is desired, the hub (regular) router is typically configured to send a default route to the spoke (stub) routers so that only a single route is passed to them.

EIGRP passive Interfaces

This may be more of a CCNA topic but lets look at passive interfaces. First we have a router. S0/0/1 is connected to another router, Fa0/0 is connected to a client vlan (no router should ever try to neighbor from here). You have two options, you could redistribute connected networks, (but this may have issues with the administrative distance being labeled as exterior EIGRP and being higher, and it is not as clean a way of doing it) or the preferred way of setting this up is using passive interfaces.

Q. Will a passive interface accept hellos?
A. No, passive interfaces do not send unicast or multicast hellos, and do not accept them either. The router will not neighbor off this interface.

This adds security/stability for your EIGRP domain, and lessens the CPU load on the router as it isn't creating hellos on a silent interface.

Q. How do I make an interface passive?
A. Two ways
Option 1:
router eigrp 1
passive-interface fa0/0

Option 2:
router eigrp 1
passive-interface default
no passive-interface s0/0/1

Unless you know you are going to place a neighbor off an interface, always make it passive. A malicious user (or un-knowledgeable Jr Tech) Could place a router off this interface (eg. off any access layer switch port) and affect your entire routing domain unless you use the passive interface command and prevent it.


It may be easier to use the second option, and make all interfaces passive unless you specifically turn them on, but make sure you make this change while consoled into the router, inputting that command remotely will likely turn your uplink interfaces passive and kill your routing/connection.

Q. How do I check if my interfaces are passive?
A. show ip eigrp interfaces will not show any passive interfaces, or show ip protocols will explicitly list all passive interfaces.

EIGRP Hello & Hold Timers

Lets take a brief look at EIGRP Hello and Hold Timers.

So, R1 and R2 want to form a Neighbor relationship.

Q. Do the timers need to match?
A. No, but if a hello timer is longer than it's hold timer, or slow links cause that you will have flapping links.


Q. How do I change the Hello and Hold Timers?
A. R1:
interface fa0/1
ip hello-interval eigrp 55 2 (where 55 is the AS number, 2 is the timer value in seconds)
ip hold-time eigrp 55 6 (cisco does not force you to make this 3 times the hello, but it is strongly recommended)


Q. So does this mean I need to make sure R2 uses a hello timer less than 6 to keep my links from flapping?
A. No, the hold time of six is sent to R2 to use. The value set on R2 will be sent to R1 to tell R1 how long to hold waiting for hello messages. The hold time set is the value actually used on the neighboring router.
If multiple routers are on this segment, they will all use this hold time while waiting for R1's next hello.

So you can interpret ip hold-time eigrp 55 6 as "tell all my neighbors with eigrp 55 to use a 6 second hold time when they listen for me".

R2 could use 10/30 as it's hello/hold-timers and the nieghborship would stay up.


Q. How can you verify your hello times?
A. show ip eigrp interface detail interface

Q. Does that show the hold timer as well?
A. No, you need to look at the show run or use show ip eigrp neighbors command and watch the countdown until it resets to it's highest value.

Q. How does the router send Hellos?
A. Routers using EIGRP send Hellos to multicast 224.0.0.10 attempting to find potential neighbors.


For general hello packet and neighboring information, read my hello packet post from last year

Prefix List Quiz

Ok, so, think you are a prefix list wiz?

1. ip prefix-list MatchList permit 192.168.0.0/16
192.168.0.0/8 NOT A MATCH
192.168.0.0/24 NOT A MATCH
192.168.0.0/16 MATCH (MUST MATCH SUBNET LENGTH EXACTLY)

2. ip prefix-list MatchListGreater permit 10.0.0.0/8 ge 24
10.0.0.0/8 NOT A MATCH
10.9.9.0/24 MATCH (matches the first 8 bits, matches the subnet length)
10.0.0.0/22 NOT A MATCH
10.0.0.0/28 MATCH
10.0.0.0/24 MATCH

3. ip prefix-list MatchListBetween permit 172.18.0.0/16 ge 20 le 24
172.18.0.0/16 NOT A MATCH
172.18.0.0/30 NOT A MATCH
172.18.1.0/24 MATCH
172.18.1.0/23 MATCH
172.18.0.0/20 MATCH



Remember -
1. If there is no ge or le, the / notation MUST MATCH the subnet mask. (basically must match your route exactly)

2. If there is a ge or le, the / notation only tells you what bits to match in the address, the le and or ge tells you what to look at for the mask.


Need to read the explanation again? Click Here

Prefix List in BGP

Ok, so yesterday we took a quick look at prefix lists. Lets try a real world example in BGP. Say your ISP is pushing you hundreds of routes but all you want to receive is a default route.

#Router bgp 65001
#neighbor 1.1.1.1 remote-as 65002
#neighbor 1.1.1.1 route-map RouteFilter in

#route-map RouteFilter permit 10
#match ip address prefix-list defaultOnly

#ip prefix-list defaultOnly seq 10 permit 0.0.0.0/0

So what have I done here.
First we neighbored with AS 65002 and applied a routefilter in (filter routes inbound from our neighbor)
Then we create a route filter that requires matching the prefix list defaultOnly.

Last we create a prefix-list that requires the route to match 0.0.0.0/0 exactly (eg. only default routes)

If we had two+ ISPs, we could add

match as-path ##
set weight 120

then make another filter entree like we did above and set the weight to 110 for any other ISP's default routes. Then we have successfully filtered out all incoming routes except default routes, and weighted our prefered path by setting that AS to a higher weight.

Prefix List explanation

A quick touch on prefix lists.

They are for matching, similar to an access list or whatnot, but can match exact subnet mask lengths.

First you just have an IP with slash notation, and you are matching that EXACT prefix. For instance:

#ip prefix-list ListName permit 10.1.0.0/16

would match the first sixteen bits. This will not match 10.1.0.0/18. It must match the subnet length EXACTLY.



But say we are looking to match a bit more than that.

#ip prefix-list ListName permit 10.1.0.0/16 ge 24 le 24

So we need to match the prefix 10.1.0.0 exactly, but we only want to match /24 masks (remember, this is for matching routes, not hosts) So any /24 route that starts with 10.1. will be matched.



So you want a real life example. Say all my loopback addresses start with 10.99.x.x and I want to match them with a filter. Well I know all my loopbacks are a /32 mask, so I can put

#ip prefix-list LoopBackMatch permit 10.99.0.0/16 ge 32 le 32

I matched the 10.99 prefix, then look through those and only match /32 bit masks.

Last example

ge meaning greater than or equal to, le meaning less than or equal to, we can match a range of masks.

Say all my client routes are 10.x.x.x with /22 masks, and all my switch management, wireless APs, security, and other networks are /24 and /25 masks, and my router links are /30.

#ip prefix-list ClientMatchList permit 10.0.0.0/8 ge 22 le 22
#ip prefix-list ManageNetworksList permit 10.0.0.0/8 ge 24 le 25
#ip prefix-list RouterLinksList permit 10.0.0.0/8 ge 30 le 30

Here I matched the /22 in the first line for client networks.

Then I matched greater or equal to /24 and less than or equal to /25 to match the other networks

Lastly I matched /30 subnets for the router links.

As always, let me know if I got something wrong, I am learning!

Try a few examples!

Simple BGP prepending

So, Having a baby seems to suck up a lot of time... Anyway,

Getting back to my CCNP studies, lets look at some simple BGP path selection: prepending.

First lets glance at BGP route selection process.
1. Highest weight (local/cisco proprietary)
2. Highest Local Preference (propagated in IBGP, stripped from EBGP)
3. Originated by Local Router
4. Prefer shortest AS path
5. Lowest Origin Code
6. Prefer lowest MED
7. EBGP over IBGP
8. Closest IGP neighbor
9. Oldest EBGP
10. Lowest BGP neighbor ID
11. Lowest Neighbor IP address


So, down at step four we are looking at how to manipulate traffic coming into our AS.

Patch selection is by AS hops, so if we have two paths into our AS we are going to make it appear to use extra AS hops through one of the paths.

We can use a trusty route map to prepend these extra AS'.

We'll use BGP AS 65000 as us, 65010 (10.1.1.1) as the desired path, and 65020 (10.2.2.2) as the less desirable path.

#router bgp 65000
#neighbor 10.2.2.2 route-map PrependASMapSample out
#
#route-map PrependASMapSample permit 10
#set as-path prepend 65000 65000 65000

Now, lets first notice, you need to prepend your own AS number, don't use someone else's. I have used the neighbor command on the LESS DESIRABLE AS and attached a route-map that adds three extra AS hops. Now when this adjacent AS 65020 wants to send you traffic, you appear as 4 hops instead of just 1. If the path through 65010 is only three hops away, you just directed traffic through the more desirable ISP.

Cisco 5508 WLC 5 min timeout bug

Ok, don't you love it when you've been struggling to troubleshoot something that just doesn't make any sense, then you start grasping at a straw and it starts coming together. So, we have 4 devices. Three existing 4404 cisco wireless lan controllers. I come along with a new and pretty 5508 to add to the bunch. Configure it so it has all the same vlans/ssids/settings/mobility groups/etc. as the others, bring up some access points on it, everything looks great.

So, i go log into the old controller, take a building worth of APs and add the new 5508 to the top of their "High Availability" list, let them swing over on their own. Walk over to the building, log in for a minute, everything looks great, project successful right?

Hour later I start hearing reports about people in that building on the 5508 getting kicked off every 5 minutes. I hurriedly swing all the APs back to the old 4404s and problem goes away.

Ok, not sure why the testing didn't bring this up but lets bring up a test AP at my desk. I stream video on my laptop beside me for 4 hours before deciding there isn't a timeout issue. I swing a single AP over to that problem building and walk over to test with my laptop, make sure there actually is a problem. Sure enough, every 5 minutes I have issues. Still says I'm connected on laptop and controller, but cannot ping gateway, cannot get anywhere. Reconnect/click repair on my wireless icon and I'm good to go (for another 5 minutes). It doesn't even ask me to authenticate again so I know the web authentication isn't getting timed out, BUT, I go ahead and change the idle timeout to several hours (since it is 300 seconds, I tried to avoid seeing 300 anywhere), and changed the user timeout to 8 hours. I peer through looking for any other 300 second timer that might be giving me issues. Go ahead and test, still nothing wrong at my desk with the test APs but still timing out in the problem building...

verify there are no ACLs that might be blocking or different for the problem building versus my test lab building.

Finally I start grasping at something, the APs that I am testing with are booting straight to the 5508. The APs swung over using high availability do not reboot but simply authenticate to the new controller.

The next time I swung the APs over in the production building I chose to reset AP after changing the primary high availability. To my delight i am now typing this on a non-timing out connection. I also verified there are identical software versions on all controllers, so there shouldn't be problems moving between them... I should probably let TAC know about this little bug.


*Before any tells me not to test on a production network, #1, I did test in the lab first and didn't find anything #2, it's spring break so there are only a handful of students on campus anyway, far from the thousands of wireless clients I would have on a typical school day*


PROBLEM CAME BACK TODAY- think I found the real problem now (and this time it makes sense). Two of my controllers were using the same AP multicast address!!! #facepalm APs aren't going to like getting updates from two different WLCs at the same time, periodic updates must come at a 5 minute interval. I think this will actually be the solution, will update if for some reason it is not.

ASA prompts

SO USEFUL!!! If you manage redundant ASA's, read @aconaway 's post on changing your prompt to include the active/standby and primary/secondary state of your firewall to the prompt. Click Here

You might be a network guy if:

You might be an Network Guy If

you know more ip addresses than phone numbers

You regularly mock TV shows for using technology that isn't part of the feature set available on the devices they have

You correct people who mix up Megabytes and Megabits

You waited eagerly for wireless N to be approved officially.

You can explain everything in your life using 7 layers

You tell people not to use TKIP because of it's security flaw

You think people should be able to do without DNS for a day, just use IP addresses...

You follow your wife around shopping retail stores and spend your time skimming the ceilings for their APs and mapping out a heat map of the store in your head

you know what TCP/IP stands for, not to mention DNS, HTTP, SNMP, BGP, OSPF, WPA, and DHCP - Sometimes you wonder if you know more acronyms than words

You've known what IPv6 was for years

cmd, telnet, and ssh are useful everyday tools, not just black boxes

Linus Torvalds comes up in everyday conversation

You know jokes about DHCP and LSAs

You cringe when you have to use a Gui to configure a switch or router

Your Amazon wish list consists of routers and ASA firewalls

Dealing with Tier 1 tech support makes you pull your hair out.

You have read the NSA's security best practices

The routing protocol in your house changes daily depending on what you have been reading

You know what a nibble is

You know what 1000 Terabytes is called

You can intelligently discuss how Egypt shut off their Internet to the country