"Split" routing issue

[Jeff Bull]

Have an interesting issue. After migrating to a secondary internet pipe last night, by changing our core switch default route, all traffic sourced internally flows out the attached firewall to the internet without issue. Unfortunately, our MS Exchange OWA server is receiving traffic from our primary internet pipe, yet sending the return traffic out the new one.

As a result, mail from outside to in works generally, but not OWA. Since we use OWA for all mobile devices to sync with our mail environment, they have all stopped working.

What options do I have, outside of changing the public DNS entry for OWA by moving it to the new internet feed?

Attached is a topology diagram that should give a better picture of the scenario.

Thanks in advance!

Jeff B

[Richard Burts]

Jeff

From your description and from the drawing it is pretty clear what is happening. Traffic arrives via the ATT connection and is forwarded to the mail server/OWA server. It sends response to its default gateway which is the core switch. The core switch has a static default route pointing to 10.33.200.5 and that is how traffic from the OWA server gets to the Internet.

What is not clear is why you do not have this issue with more than OWA, since it seems fairly clear that you have created an asymmetric routing path where most traffic would arrive on the ATT connection and return via the new Internet connection. And it is not clear why the core switch has a static default route pointing to the new Internet connection. It is also not clear how you wish to treat both Internet connections. Are they both to be active and share load, or is one to be primary and the other to be failover. Once we have a better understanding of your intentions and your design we may be able to give you better advice.

In the mean time based on the little bit that we currently know I would suggest that one alternative for you to consider would be to configure Policy Based Routing on the core switch. This would allow you to identify OWA response traffic and to send it back out the ATT connection.

HTH

Rick

[Jeff Bull]

Rick,

  Thanks for the response! Here's some additional background. We have 2 internet feeds, as you can see.... one from AT&T, and one from TelePacific. I'm wanting to use the secondary feed (TelePacific) for user generated internet requests, in order to prevent big downloads or misuse of the bandwidth from affecting our critical business services.

As of today, ALL primary internet based traffic for our business (online banking, vendor connections, vpn's, etc), and user generated requests, go through our AT&T feed. The previous person responsible for my team opted to manage all of this with roughly 40-50 static routes on our core switches. As luck would have it, most of the critical services are specifically called out by a static route. This allowed me to think that (big assumption here) I should be able to change the default route and use our secondary internet feed just for User generated Internet requests, thus mitigating bandwidth and other issues from affecting our business systems.

Obviously, that is an assumption, and one in which I've already been bitten. Without a complete redesign of our core switching/routing environment (which is not in the cards right now), I have to work with what I have.

I like the idea of using a PBR to get just this traffic flow back the way it came. Unfortunately, I don't have much experience deploying these. What would that configuration need to look like?

Jeff B

[Richard Burts]

Jeff

The additional information is helpful. For the situation that you describe PBR would seem to be a good alternative. The configuration might look something like this:

- first configure an access list that will identify the traffic coming from OWA. perhaps something like

access-list 151 permit ip host 10.33.2.119 any

- then configure a route map that will match the access list identifying OWA traffic and will set the next hop as being toward ATT. perhaps something like

route-map OWA permit 10

match ip address 151

set ip next-hop 10.33.200.3

- then apply the route map under the interface on which the traffic arrives. perhaps something like

interface fast1/1

ip policy route-map OWA

If you want more details about PBR this link may help

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpbr_ps1835_TSD_Products_Configuration_Guide_Chapter.html

HTH

Rick