IP Directed Broadcasts

This is a quick one. Enabling IP Directed broadcasts to allow a server to communicate on specific ports to a subnet. This was done out of necessity and more or less not something you want to do....

• Here is what was constructed for a backup service:

First you need to create an ACL that permits the ports from the server(s) that the the hosts will be backing up to:

access-list 109 remark ** Allow backup servers to send directed broadcasts limited to a single port
!
access-list 109 permit udp host 172.16.192.111 any eq [port #]
access-list 109 permit udp host 172.16.192.112 any eq [port #]
access-list 109 permit udp host 172.16.192.113 any eq [port #]

• Next you need to make a statement on the interface (in this case it's a cat 6500 and it's the primary interface in an HSRP setup) to allows the communication through to the subnet:

interface Vlan100
description Some LAN Segment
ip address 172.16.105.11 255.255.250.0
ip helper-address [DHCP Server #1]
ip helper-address [DHCP Server #1]
no ip redirects
ip directed-broadcast 109 <----- this references the ACL 109
ip pim sparse-mode
ip cgmp
no ip mroute-cache
standby 1 ip 172.16.105.1
standby 1 priority 150
standby 1 preempt
!

• Thats all you need to do to poke a hole in a subnet and allow directed broadcasts.

MAN Link Failover

This is a quick example of the setup for failing from a 100MB connection (something like OPT-E-MAN) to a 10MB connection (not really a service but it's a slower speed link and for the purposes of this example it's easy).

This is not rocket science and EIGRP is going to do all the work but I wanted to document this more for the fact that I had never done integrated routing and bridging on a router before (bridge irb).




The setup is simple. We have a router at each end of this with a LAN segment. The Eureka side has 172.16.200.3/32 and the Sacramento side has 172.16.200.4/32. From the Eureka router we have two paths to Sacramento, one through a high speed link in blue and a slower speed link in red. The interface with the 172.16.8.1/24 address will be preferred over the 172.16.1.10 as you can see in this show eigrp topology:

sacramento#show ip eigrp topology
!
IP-EIGRP Topology Table for AS(100)/ID(172.16.200.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 172.16.200.4/32, 1 successors, FD is 128256
via Connected, Loopback1
P 172.16.200.3/32, 1 successors, FD is 156160
via 172.16.8.1 (156160/128256), FastEthernet0/1
via 172.16.1.10 (409600/128256), FastEthernet0/0

• The real heart of this configuration and the reason I am writing this is the configuration on the provider routers. The FastEthernet0/0 and FastEthernet0/1 interfaces need a "bridge-group 1" statement on each in order to group them and allow L2 traffic to pass from one provider switch to the other. The other key part of this is the "bridge 1 protocol ieee" statement and the "bridge irb" statement. Here is what it looks like from the Redding router:

redding#
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
bridge-group 1
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
bridge-group 1
!
bridge 1 protocol ieee
!
bridge irb

• Now the test. Here is the route statement on the Sacramento router for the 172.16.200.3 network:

sacramento#show ip route 172.16.200.3
!
Routing entry for 172.16.200.3/32
Known via "eigrp 100", distance 90, metric 156160, type internal
Redistributing via eigrp 100
Last update from 172.16.8.1 on FastEthernet0/1, 00:02:01 ago
Routing Descriptor Blocks:
* 172.16.8.1, from 172.16.8.1, 00:02:01 ago, via FastEthernet0/1
Route metric is 156160, traffic share count is 1
Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1


• Now we pull the link on redding FA0/1 to the AB switch and we see the Sacramento router go through a neighbor state change:

sacramento#
04:38:10: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.16.8.1 (FastEthernet0/1) is down: holding time expired..

• Lets ask the Sacramento router what the route to the 172.16.200.3 network is:

sacramento#show ip route 172.16.200.3
!
Routing entry for 172.16.200.3/32
Known via "eigrp 100", distance 90, metric 409600, type internal
Redistributing via eigrp 100
Last update from 172.16.1.10 on FastEthernet0/0, 00:00:05 ago
Routing Descriptor Blocks:
* 172.16.1.10, from 172.16.1.10, 00:00:05 ago, via FastEthernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1


• Next we restore the link on redding FA0/1 to the AB switch and we have another state change:

sacramento#
04:39:23: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.16.8.1 (FastEthernet0/1) is up: new adjacency

• And another check of the route shows it's back on the higher speed path:

sacramento#show ip route 172.16.200.3
!
Routing entry for 172.16.200.3/32
Known via "eigrp 100", distance 90, metric 156160, type internal
Redistributing via eigrp 100
Last update from 172.16.8.1 on FastEthernet0/1, 00:00:05 ago
Routing Descriptor Blocks:
* 172.16.8.1, from 172.16.8.1, 00:00:05 ago, via FastEthernet0/1
Route metric is 156160, traffic share count is 1
Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

• A look at the eigrp neighbors shows that the link has been up for a short time but it is preferred over the other:

sacramento#show ip eigrp neighbors
!
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
0 172.16.8.1 Fa0/1 13 00:02:15 3 200 0 18
1 172.16.1.10 Fa0/0 13 00:09:20 2 200 0 19

Router Core Dumps

I wanted to write something about a very seldom used series of commands used to save the last gasp of a router to a server via something like tftp, of in this case ftp.

• The Core dump:
How do you save a router core dump to a server?
First off you have to know that saving a core dump via the exception command - something like this...
!
router# exception dump [hostname or IP]

will pass the file via tftp to the server you defined. The issue with this is that it will only dump the first 16 MB of the core file. This is a tftp limitation so lets just move onto configuring it to use ftp.

• FTP configuration
First you have to setup the service and you would think the command would be something like "service ftp" but no...

router#ip ftp username [somename]
!
router#ip ftp password [somepassword123]

• The exception command is the next step and here are the options you get:

router#exception ?
core-file --- Set name of core dump file
crashinfo --- Crashinfo collection
data-corruption --- Data error exception handling
delay-dump --- Pause dump (in the case of dump via peer)
dump --- Set name of host to dump to
flash --- Set the device and erase permission
memory --- Memory leak debugging
protocol --- Set protocol for sending core file
region-size --- Size of region for exception-time memory pool
spurious-interrupt --- Crash after a given number of spurious interrupts

We will elect to set the protocol:
!
router#exception protocol ftp
!


• Now the real heart of al this, the dump command with the the server ip
!
router #exception dump [x.x.x.x]

Thats all their is to it. Have fun testing this one out.

Frame-Relay

Just for the record, I never liked Frame-Relay. It's old and tired and every connection should be a metro ethernet connection in my opinion.... well something better than this. But the reason I am writing this and documenting the setup of a very basic Frame-Relay connection is because it's something that is still asked about and test questions want you to be able to configure it.

Ok Here goes - We have three routers (rack1r1, rack1r2 and rack1r6) each connecting to a Frame Switch (fsw) on a different serial interface. The frame router is essentially any old router with a few serial connections and a global command "frame-relay switching" set.



• Step 1
On the fsw we setup the serial interface to rack1r1 like so:
!
frame_switch#
interface Serial1/0
description connection to r1
no ip address
encapsulation frame-relay <--- This is important
keepalive 20
no fair-queue
serial restart-delay 0
clockrate 64000 <--- Need this too
frame-relay lmi-type ansi <--- another important item
frame-relay intf-type dce <--- this as well
frame-relay route 102 interface Serial1/1 201 <--- This maps traffic into fsw with DLCI 102 to rack1r2 DLCI 201
frame-relay route 103 interface Serial3/2 301 <--- This maps traffic into fsw with DLCI 103 to rack1r6 DLCI 301
!

• Step 2 and 3, you setup the interfaces that connect to rack1r2 and rack1r6. In this case it's Serial1/1 and Serial3/2:
!
frame_switch#
interface Serial1/1
description connection to r2
no ip address
encapsulation frame-relay <--- same
keepalive 20
no fair-queue
serial restart-delay 0
clockrate 64000 <--- same
frame-relay lmi-type ansi <--- same
frame-relay intf-type dce <--- same
frame-relay route 201 interface Serial1/0 102 <--- ok DLCI 201 over to 102 - thats the reverse of rack1r1
frame-relay route 202 interface Serial3/2 302 <--- This is DLCI 202 over to rack1r6 which we configure below

Here is the link to rack1r6:
!
frame_switch#
interface Serial3/2
description connection to r6
no ip address
encapsulation frame-relay <---yup
keepalive 20
no fair-queue
serial restart-delay 0
clockrate 64000 <--- yea
frame-relay lmi-type ansi <--- I know...
frame-relay intf-type dce <--- I know!
frame-relay route 301 interface Serial1/0 103 <--- Reverse again 301 to 103 which is rack1r1
frame-relay route 302 interface Serial1/1 202 <--- Back to rack1r2 on 202

• OK so we have all that in place. We are ready now to configure the interfaces on the routers themselves to make all this happen:



- Starting with rack1r1:
!
rack1r1#
interface Serial0/0
description connection to frameswitch s1/0
ip address 192.168.1.1 255.255.255.248
ip pim dense-mode
encapsulation frame-relay <--- need this here also
keepalive 15
no fair-queue
frame-relay map ip 192.168.1.1 102 broadcast <--- This is in place so you can ping yourself
frame-relay map ip 192.168.1.2 102 broadcast <--- map for traffic destined for rack1r2's ip
frame-relay map ip 192.168.1.3 103 broadcast <--- map for traffic destined for rack1r6's ip
frame-relay lmi-type ansi <--- the options you have here are cisco, ansi and q933a

• OK same thing on the other two routers:
!
rack1r2#
interface Serial0/0
description connection to frameswitch s1/1
ip address 192.168.1.2 255.255.255.248
ip pim dense-mode
encapsulation frame-relay <--- same thing
keepalive 15
no fair-queue
frame-relay map ip 192.168.1.1 201 broadcast
frame-relay map ip 192.168.1.2 201 broadcast <--- This is in place so you can ping yourself
frame-relay map ip 192.168.1.3 202 broadcast
frame-relay lmi-type ansi <--- same
!
rack1r6#
interface Serial0/0
description connection to frameswitch s3/2
ip address 192.168.1.3 255.255.255.248
encapsulation frame-relay <--- same
keepalive 15
no fair-queue
frame-relay map ip 192.168.1.1 301 broadcast
frame-relay map ip 192.168.1.2 302 broadcast
frame-relay map ip 192.168.1.3 301 broadcast <--- This is in place so you can ping yourself

• Ok now that thats all done you should have a working model with the ability from any router to ping the other two and yourself.

Here is what the fsw should look like when you do a "show frame-relay route"

Input Intf Input Dlci Output Intf Output Dlci Status
Serial1/0 102 Serial1/1 201 active
Serial1/0 103 Serial3/2 301 active
Serial1/1 201 Serial1/0 102 active
Serial1/1 202 Serial3/2 302 active
Serial3/2 301 Serial1/0 103 active
Serial3/2 302 Serial1/1 202 active

ASA Packet Capture

This post is intended to show how to capture packets on an ASA. This is especially helpful when you are trying to determine why something is not being allowed through the FW, you can permit all traffic from a host using an ACL and then capture the traffic and find out what is going on.

• First you need to create the ACL. In this case the host 192.168.168.31 is the target and we are allowing ip to anything.
!
(config)# access-list test permit ip host 192.168.168.31 any

• Next we will define the capture for this host. We make the statement "inside" at the end because this hosts sits on the trusted inside interface.
!
(config)# capture test1 access-list test interface inside

• Now all you do is ask to see what has been captured
!
# show capture test1

• Here is a typical dump:

21 packets captured

1: 11:21:43.783315 802.1Q vlan#1 P0 192.168.168.31 > 192.168.168.221: icmp: echo reply
2: 11:22:13.784322 802.1Q vlan#1 P0 192.168.168.31 > 192.168.168.221: icmp: echo reply
3: 11:22:23.056652 802.1Q vlan#1 P0 192.168.168.31.24894 > 216.239.38.10.53: udp 60
4: 11:22:23.097559 802.1Q vlan#1 P0 192.168.168.31.50934 > 74.125.53.9.53: udp 49
5: 11:22:23.165076 802.1Q vlan#1 P0 192.168.168.31.53 > 192.168.168.221.59255: udp 281
6: 11:22:27.040464 802.1Q vlan#1 P0 192.168.168.31.43688 > 74.125.53.9.53: udp 60
7: 11:22:27.110605 802.1Q vlan#1 P0 192.168.168.31.53 > 192.168.168.221.58190: udp 498
....


• Make sure you clean up your capture when you are done so as not to add to the load of the FW unnecessarily. Here's how to stop things:
!
(config)# no capture test1

And here's how to delete the ACL:

!
(config)# no access-list test permit ip host 192.168.168.31 any

!
# show access-list test
ERROR: access-list does not exist

Have fun with this one.

ASA Regular Expression - Whitelist/Blacklist

The intent of this post is to show how you can permit specific web sites from your inside hosts and block all others. In order to do this URL (or IRI) filtering on the ASA you need to create few things.

• First off you need to decide what you want to allow by calling them out in a regex statement:
!
regex urlreg1 "cisco.com"
regex urlreg2 "yahoo.com"

• Next we will group these statements under a class-map and call it whitelist:
!
class-map type regex match-any whitelist
match regex urlreg1
match regex urlreg2

• The class-map "goodclass" just assembles the URL's that are listed in the "whitelist" and says match this.
!
class-map type inspect http match-all goodclass
match request header host regex class whitelist

• Now we need to create a class-map that blocks everything not in the allowed list. This is done by creating the "badclass" and stating "match not" for the whitelist.
!
class-map type inspect http match-all badclass
match not request header host regex class whitelist

• Here we are taking the "badclass" and "goodclass" and putting them into a policy-map that has actions. In this case the action for the "badclass" is to drop it
!
policy-map type inspect http regex-policy
parameters
class goodclass
class badclass
drop-connection

• The policy-map "global_policy" might already exist on the ASA (not sure since I have hacked mine to hell) but in any case it calls out the "class inspection_default" that has to exist on the box for the statement under the "global_policy" to take. If you are missing it here it is:

# class-map inspection_default
# match default-inspection-traffic

!
policy-map global_policy
class inspection_default
inspect http regex-policy

• This next statement applies the "global_policy" to the inside interface. Once applied this will allow users on the trusted LAN to access two sites - cisco.com and yahoo.com and thats it.
!
service-policy global_policy interface inside

Have fun with this one. Maybe call out some social networking sites in the regex statement and change the actions in the policy-map "regex-policy" to log the hits and see how often your users are accessing those sites.

Here is a graphical Illustration of what we just made: