Best Practice: Isolating Enterprise Zones in Second-Tier Networks

Business-to-business (B2B) networks often require strict isolation of each partner’s data at the same time as they require data to flow in two directions between the hub and each partner. Border Router: Isolating Enterprise Zones illustrates a situation in which the main network in zone A must exchange data freely with partner P and partner Q—but data from either partner must not flow to the other partner. The border policy configures this separation as required.

(Incidentally, notice that Border Router: Isolating Enterprise Zones features zone stability, co-locating routers P1 and Q1 near border router BR; see Best Practice: Zone Stability in Second-Tier Networks.)

Figure 87: Border Router: Isolating Enterprise Zones

Adding fault tolerance to the topology of Border Router: Isolating Enterprise Zones would seem straightforward, but actually adds an unexpected complication. Border Router: Isolating Enterprise Zones and Fault Tolerance depicts the resulting topology. Notice that we address two aspects of fault tolerance (as we did in Border Router: Fault Tolerance):

•

Redundant border routers (BR1 and BR2) guard against failure of either member of this pair. BR1 and BR2 each connect the hub to both partner zones (zone P and zone Q).

•

Redundant routing across WAN communications guards against WAN link failure. The familiar X pattern is repeated within each partner zone.

Yet this topology introduces a prohibited behavior—messages can flow between the two partners. BR1 routes messages from partner P to hub A; BR2 forwards the messages from hub A to partner Q. To block this unintended data flow, administrators must properly configure border policy on BR1 and BR2; it is crucial to restrict the flow to those messages which have not yet crossed a border (see First Border). Configure this restriction separately for each subject that these border routers forward.

Figure 88: Border Router: Isolating Enterprise Zones and Fault Tolerance