Policy Routing to the Servers

Articles » Scalable Policy Routing » Policy Routing to the Servers

Whenever you want to implement policy routing in a network, you have to consider both traffic flow directions independently. For example, changes you make to force the traffic from remote sites to use a particular link toward a specific server usually do not influence the traffic flowing in the other direction, potentially resulting in asymmetrical traffic.

In this section, we’ll focus on the traffic flow from remote sites toward the servers; the next section will deal with return traffic.

To influence the traffic flow toward the servers, remote site routers have to prefer IP prefixes for the legacy servers received from the CoreFR router over those received from the CoreInet router. You could use a variety of BGP mechanisms, but the only one that requires no configuration changes on remote sites (and this is crucial to achieve scalability) is the Multi-Exit Discriminator (MED) attribute, which can be set on the central site routers and accepted by the remote sites.

The following MED values are used in the sample network:

• MED=200 is set on all IP prefixes advertised from the CoreInet router to the remote sites.
• MED=300 is set on IP prefixes advertised from the CoreFR router to the remote sites to ensure the backup path is only used when the primary link fails (lower MED values are preferred)

• MED=100 is set on IP prefixes of the legacy servers when they are advertised from the CoreFR router, making them more preferred over the slower link.

You can use the show ip bgp prefix command on the remote site router to see the impact of the MED settings:

Site-A#show ip bgp 10.0.21.0
BGP routing table entry for 10.0.21.0/24, version 22
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  65000
    10.0.11.1 from 10.0.11.1 (10.0.1.2)
      metric 200, localpref 100, valid, external, best
  65000
    10.0.8.1 from 10.0.8.1 (10.0.1.3)
      metric 300, localpref 100, valid, external

Site-A#show ip bgp 10.0.20.0
BGP routing table entry for 10.0.20.0/24, version 13
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  65000
    10.0.11.1 from 10.0.11.1 (10.0.1.2)
      metric 200, localpref 100, valid, external
      Community: 65000:100
  65000
    10.0.8.1 from 10.0.8.1 (10.0.1.3)
      metric 100, localpref 100, valid, external, best
      Community: 65000:100

You could set the MED with an access-list or a prefix-list on the CoreFR router, but a more scalable approach would use BGP communities:

• The originating router (the Legacy router in our network) would set a BGP community (65000:100 is used in the sample network) to indicate that the IP prefix belongs to the legacy servers
• The CoreFR router would use the community to set the MED values.