Posts tagged RIP

An Interesting Problem with Multiple DCs on a Stick

We talked about running multiple data centers on a stick back in August, which is where you have multiple logical pairs of client and server VLANs on a single CSM for different tiers or functions.  The big point of the article was that you had to do some fancy forwarding to get a server-initiated connection from one server VLAN to appear out the appropriate client VLAN.  Well, we ran into an interesting issue with the given solution.

Let’s set up a scenario.  Check the diagram for an overview.  We have many pairs of client and server VLANs each with a firewall interface as the gateway into the DCOAS.  Let’s just focus on just one, though — client VLAN 101 and server VLAN 102.  In VLAN 101 is ServerA (not pictured) with an IP of 1.1.101.45; in VLAN 102 is our web farm that needs to connect to ServerA to drop off some data.  We add a static route on ServerA pointing traffic for 1.1.102.0/24 back through the CSM.

When you try to connect from the web farm, though, it just times out.  Why is that?

Remember that weird forwarding vserver that we had to use to get traffic to come out of the right client VLAN?  Well, that’s stabbing you in the eye right now.  When the web server initiates a connection, it sends traffic to the server VLAN IP of the CSM.  The forwarding vserver grabs the new connection and load balances it to its only RIP, which is the IP of the firewall.  What happens when any good firewall accepts traffic destined on an interface destined for a host out of the same interface?  It drops the packet, and, eventually, the server times out.

What’s the fix, then?  There are a few that come to mind.  The first may be to just move ServerA to another network segment.  Another may be to change the process around a bit by having ServerA pull the data instead of it being pushed since client-initiated connections will work like a champ.

A really outrageous one would be to set up another forwarding vserver that has only ServerA as it’s serverfarm.  You would then add a static route in the web servers pointing to ServerA through that VIP, which would foward it over.

On the CSM, you’d do something like this.

serverfarm SERVERA-SF
 no nat server
 no nat client
 real 1.1.101.45  <--- ServerA
  inservice

vserver SERVERA-VS
 virtual 1.1.102.5 any
 vlan 102
 serverfarm SERVERA-SF
 inservice

On the server, you would add a static route to ServerA through 1.1.102.5. If you’re using some brand of Linux, you’d do this.

route add 1.1.101.45 gw 1.1.102.5

Don’t forget the static route on ServerA.

Send any Peeps questions my way.

ACLs and HSRP, BGP, OSPF, VRRP, GLBP…

Here’s a handy list of ACL entries to allow your devices to speak routing protocols, availability protocols, and some other stuff. We’ll assume you have ACL 101 applied to your Ethernet inbound; your Ethernet has an IP of 192.168.0.1.

  • BGP : Runs on TCP/179 between the neighbors

access-list 101 permit tcp any host 192.168.0.1 eq 179

  • EIGRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.10

access-list 101 permit eigrp any host 224.0.0.10

  • OSPF : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.5; also talks to 224.0.0.6 for DR/BDR routers

access-list 101 permit ospf any host 224.0.0.5
access-list 101 permit ospf any host 224.0.0.6

  • HSRP : Runs on UDP/1985 from the source interface IP to the multicast address of 224.0.0.2. I’ve seen in the past that it runs on UDP/1985, but I didn’t find any evidence of that in a quick Google for it. Can someone verify?

access-list 101 permit udp any host 224.0.0.2 eq 1985

  • HSRP version 2 : Runs on UDP/1985 from the source interface IP to the multicast address of 224.0.0.102.

access-list 101 permit udp any host 224.0.0.2 eq 1985

  • RIP : Runs on UDP/520 from the source interface IP to the multicast address of 224.0.0.9

access-list 101 permit udp any host 224.0.0.9 eq 520

  • VRRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.18

access-list 101 permit 112 any host 224.0.0.18

  • VRRP-E : This is a Foundary thing according to readers, and runs on UDP/8888 from the source interface IP to the multicast address of 224.0.0.2

access-list 101 permit 112 any host 224.0.0.2 eq 8888

  • GLBP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.102

access-list 101 permit udp any host 224.0.0.102

  • DHCPD (or bootps) : Runs on UDP/67 from 0.0.0.0 (since the client doesn’t have an address yet) to 255.255.255.255 (the broadcast).

access-list 101 permit udp any host 255.255.255.255 eq 67
If anyone else has one to add, do so in the comments.