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