2

Here's the setup:

Two companies (A & B) share office space and a LAN. A 2nd ISP is brought in and company A wants its own Internet connection (ISP A) and company B wants its own Internet connection (ISP B).

VLANs are deployed internally to separate the two companies' networks (company A: VLAN 1, company B: VLAN 2, shared VOIP: VLAN 3).

With separate VLANs it's simple enough to use separate DHCP servers (or separate scopes on the same server) to assign the default gateway to each company's gateway for their Internet connection. Static routes can be created on each gateway to point traffic destined for the other company's VLAN or the voice VLAN so that all nodes are reachable as expected.

However, I think this is a form of asymmetrical routing, right? (The path from node A1 to node B1 is not the same as the path back from node B1 to node A1).

Can I set up policy-based routing to correct this? In that case, can I assign the same default gateway to every device on all VLANs and create a routing policy on a L3 switch to look at the source address and forward traffic to the appropriate next hop? In that case, I want the routing logic to go like this:

  1. If the destination address is known, forward the traffic (traffic destined for a different VLAN).
  2. If the destination address is unknown, forward the traffic to ISP A's gateway if the source address is on VLAN A; or forward the traffic to ISP B's gateway if the source address is VLAN B.

Am I thinking about this problem in the correct way? Is there another way to solve this problem that I am overlooking?

UPDATE

I tried Kyle's solution below and had some issues. Here's the relevant bits of my config (I'm testing this with a 2821 BTW):

interface GigabitEthernet0/0
 ip address 10.0.1.1 255.255.255.0
 no ip proxy-arp
 duplex auto
 speed auto
 no mop enabled
!
interface GigabitEthernet0/0.100
 description VoIP VLAN stub
 encapsulation dot1Q 100
 ip address 10.0.100.1 255.255.255.0
 no ip proxy-arp
!
interface GigabitEthernet0/0.110
 description RT VLAN stub
 encapsulation dot1Q 110
 ip address 10.0.110.1 255.255.255.0
 no ip proxy-arp
 ip policy route-map RT-out
!
interface GigabitEthernet0/0.120
 description TCI VLAN stub
 encapsulation dot1Q 120
 ip address 10.0.120.1 255.255.255.0
 no ip proxy-arp
 ip policy route-map TCI-out
!
interface GigabitEthernet0/1
 ip address 192.168.1.20 255.255.255.0
 no ip proxy-arp
 duplex auto
 speed auto
!
ip route 192.168.0.0 255.255.0.0 192.168.1.2
!
ip access-list extended match-RT-out
 permit ip 10.0.110.0 0.0.0.255 any
ip access-list extended match-TCI-out
 permit ip 10.0.120.0 0.0.0.255 any
!
route-map TCI-out permit 11
 match ip address match-TCI-out
 set ip next-hop 192.168.12.2
!
route-map RT-out permit 10
 match ip address match-RT-out
 set ip next-hop 192.168.11.2
!

And the output of show ip route:

     10.0.0.0/24 is subnetted, 4 subnets
C       10.0.1.0 is directly connected, GigabitEthernet0/0
C       10.0.110.0 is directly connected, GigabitEthernet0/0.110
C       10.0.100.0 is directly connected, GigabitEthernet0/0.100
C       10.0.120.0 is directly connected, GigabitEthernet0/0.120
C    192.168.1.0/24 is directly connected, GigabitEthernet0/1
S    192.168.0.0/16 [1/0] via 192.168.1.2

And here's the problem: It doesn't seem like my route-maps are working (well, I think they are matching, but they don't seem to be modifying the next-hop result). Output of debug ip policy for one ping to an external IP address:

*May  5 21:26:11.631: IP: s=10.0.120.100 (GigabitEthernet0/0.120), d=209.85.225.100, len 52, FIB policy match
*May  5 21:26:11.631: CEF-IP-POLICY: fib for address 192.168.12.2 is with flag 0
*May  5 21:26:11.631: IP: s=10.0.120.100 (GigabitEthernet0/0.120), d=209.85.225.100, len 52, FIB policy rejected - normal forwarding
*May  5 21:26:11.631: IP: s=10.0.120.100 (GigabitEthernet0/0.120), d=209.85.225.100, len 52, policy match
*May  5 21:26:11.631: IP: route map TCI-out, item 11, permit
*May  5 21:26:11.631: IP: s=10.0.120.100 (GigabitEthernet0/0.120), d=209.85.225.100, len 52, policy rejected -- normal forwarding

So you can see in that output that it looks like it matches...followed by an immediate FIB policy rejected - normal forwarding. I get back a ICMP Destination Host Unreachable from my router (10.0.120.1) in this case (when I've tried to ping 209.85.225.100).

This is getting long, but hopefully it explains where I'm having trouble.

3
  • 1
    Re Update: Hmm... maybe there still needs to be a matching route? What happenes if you add a default route? May 5, 2010 at 23:16
  • 1
    Actually, it would make sense to me that the next hop needs to be in the route table as a gateway. So for example, with via 192.168.1.2 I bet that would be an acceptable next hop. I am not entirely sure, but that is my best guess. May 5, 2010 at 23:33
  • Kyle- after some additional experimentation, it would appear that you are correct. The next hop must be in the routing table as a gateway to another network. There was a slightly confusing (to me) option in the documentation for set ip next-hop recursive 192.168.12.2 that I thought would allow the next-hop to in reality be 2 or more hops away, but that wasn't working for my test clients. It worked on the router itself using ip local policy route-map TCI-out but didn't work for any nodes "behind" the router. Anyways, thanks for your help! Oh and debug ip policy was massively helpful. May 6, 2010 at 15:11

1 Answer 1

3

Since they are different networks, you can just set up Source Based Routing using Policy based routing to route out different interfaces based on the source IP address of the outgoing packet.

For Cisco IOS is is basically the following (I think, untested) (F0/0 is the internal interface, 12.12.12.12, and 13.13.13.13 are your two IP gateways, you have two LANs 192.168.0.0/16 and 10.0.0.0/8):

interface FastEthernet0/0
     ip policy route-map foo-out

route-map foo-out permit 10
 match ip address match-foo-out
 set ip next-hop 12.12.12.12

route-map foo-out permit 11
 match ip address match-foo2-out
 set ip next-hop 13.13.13.13

ip access-list extended match-foo-out
 deny   ip 10.0.0.0 0.255.255.255 any
 permit ip 192.168.0.0 0.0.255.255 any


ip access-list extended match-foo2-out
 deny   ip 192.168.0.0 0.0.255.255 any
 permit ip 10.0.0.0 0.255.255.255 any

If these are just Frame-Relay then set interface instead of next hope would be okay as well.

For your inter-company communication, you wouldn't really have to do anything but change those acls so they deny source and dest where it is the same company, ie: deny ip 192.168.0.0 0.0.255.255 10.0.0.0 0.255.255.255. Also if these are two lan interfaces maybe a different route map for each interface makes more sense or is required, this is just meant to be an example to push you in the right direction, hopefully :-)

4
  • Will this send traffic from 192.168.0.0/16 destined to 10.0.0.0/8 to the next-hop 12.12.12.12 or will that traffic be forwarded based on the routing table's knowledge of 10.0.0.0/8 being a directly connected network? May 4, 2010 at 16:21
  • My above example, without the deny ip 192.168.0.0 0.0.255.255 10.0.0.0 0.255.255.255 I added in the last paragraph, Traffic from 192.168/16 will be sent to 12.12.12.12 regardless of the routing table and regardless of its destination. If you had the previously mentioned rule, then traffic from 192.168/16 to anything but 10.0.0.0/8 goes to 12.12.12.12, then what didn't have the route map applied (ie dest 10/8) follows the routing table as normal. I think, I have only done sourced based routing a couple of times, if Cisco, test with dynamips or lab equipment. May 4, 2010 at 16:27
  • Oh, and this was with a router, I don't know if L3 Switches do this or not. May 4, 2010 at 16:35
  • Tried this with a 2821 in the lab and ran into some issues. See updates in question body. May 5, 2010 at 21:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .