See how BGP and route redistribution can link remote sites

To maintain privacy between two corporate divisions after a merger, one admin was tasked with keeping the two sites from seeing each other's routes. Find out how she solved the problem of filtering routes between two sites linked over a VPN.

In today’s merger-happy corporate environment, linking distant corporate entities that have suddenly become partners is a necessity, and VPN is often the method of choice. Administrators face many challenges in establishing these VPN links—challenges that are often complicated not by technical issues but by human ones.

Take the case of one company that sought to link multiple sites to a home office via VPN tunnels. Two of the sites did not want their routing tables to be open to one another. This presented a bit of a challenge to the company, which had VPN links from the home office over OSPF going out to multiple sites. Suddenly, two locations in the mix were throwing a curve by saying they wanted their networks kept private from each other.

Suzie, one of the company’s systems administrators, was tasked with solving the puzzle of how to achieve this without creating other problems in the process. Her solution made the existing setup a bit more complex but accomplished just what was intended. The key was using BGP and configuring routers so that the routing tables were filtered between the two sites.

Accommodating privacy requests
Suzie's company uses VPN to link the home office in the United States to several locations across Europe. When links to two new sites became necessary as a result of company acquisitions, officials at the two locations said that they did not want their routing tables forwarded to the other. The sites are located in different countries, thousands of miles apart.

In the existing setup, OSPF governs VPN traffic. But because OSPF does not allow for filtering routes on outbound traffic, the request to not forward routing table information necessitated a move to BGP for communication between the two sites.

Using BGP, Suzie said, “You can filter incoming data so that it won’t show up in routing tables, but it will still pass all the routes to the next location.”

Matters were further complicated because the administrator at one site didn’t want anybody poking around in his routers, so he wouldn’t grant access to anyone outside of his IT department.

The solution to the problem was to create separate BGP sessions on the routers at each of the sites, adding parameters in the routers at each to filter routes from the other location. The diagram in Figure A shows how the sites were linked.

Figure A
Site VPN links

As you can see, the protocol used from the corporate headquarters out to all sites is OSPF. But at the two sites that want their routes filtered, BGP governs outbound traffic from the routers, while private OSPF sessions are used internally. This ensures that routes are advertised correctly within the networks at each site but filtered on outbound traffic so that VPN-3 and VPN-4 cannot view each other’s tables.

It may seem like an odd setup, but it’s the solution that satisfied officials at both locations.

Suzie said the issue was purely a political one. Each site was concerned about protecting its privacy from the other, so she was obliged to accommodate the request.

“We could’ve turned to static routes,” she said, “but that would’ve been a [network] management nightmare.”

Suzie said the biggest danger in what she was doing was that if she didn’t do it correctly, she could end up with routing loops. The first issue she encountered with BGP was its defaulting to auto summarize. This caused problems until she discovered that the auto summarize option was causing recursive routing. After she disabled this property, she was able to make the BGP solution work.

“It took me a while to figure that one out,” she said. “Basically, what happens is, if BGP sees recursive routing, it shuts itself down. Once I figured out that it was auto summarizing and turned that off, it worked fine.”

Suzie used access list parameters to configure the router filters, as shown below. Note that IP addresses were changed from the originals and coincide with the diagram in Figure A.
access-list 55 deny
access-list 55 permit any
access-list 56 deny
access-list 56 deny
access-list 56 deny   200.333.21.5
access-list 56 deny   200.333.10.5
access-list 56 permit any
access-list 57 deny
access-list 57 deny
access-list 57 deny   200.333.10.0
access-list 57 deny   200.333.21.0

The IP aliases may make it difficult to tell, but if you match the IPs to those shown in Figure A, you’ll see that BGP is essentially blocking VPN-3 and VPN-4 IPs.

Suzie also had to include commands for redistributing the routes. She said this is common when company acquisitions take place because different organizations often use different protocols.

Suzie used Cisco IOS commands similar to the following to redistribute the routes:
router ospf 1
 no log-adjacency-changes
 redistribute bgp 01 metric-type 1 subnets
 passive-interface FastEthernet0/1
 passive-interface Tunnel1
 passive-interface Tunnel23
 network x.x.x.0 area 0
 network xx.xx.0.0 area 0
router bgp 01
 no synchronization
 bgp log-neighbor-changes
 neighbor remote-as 02
 neighbor next-hop-self
 neighbor distribute-list 56 out
 neighbor remote-as 03
 neighbor next-hop-self
 neighbor distribute-list 57 out
 no auto-summary
 redistribute ospf 1 match internal external 1 external 2

In the redistribution into OSPF, however, these IPs are not blocked to VPN-1 and VPN-2. Thus, VPN-3 and VPN-4 cannot see each other’s route tables, but VPN-1 and VPN-2 can.

After setting the parameters necessary to block specific routes and then redistribute them, Suzie had to test everything to ensure that routes were being filtered and redistributed as intended.

She Telnetted into the routers at VPN-3 and VPN-4 and used the command show IP route to view the routes displayed at each. As intended, neither showed the other’s routes. Suzie then Telnetted one router hop out from VPN-3 and VPN-4 to ensure that they were seeing only OSPF and directly connected interfaces as well as VPN-1 and VPN-2 routes. Again, the routes were advertised as expected. She then Telnetted into routers at VPN-1 and VPN-2 and verified that all routes were visible at these sites.

Suzie’s solution, though perhaps unorthodox, resulted in her being able to accommodate the two locations that wanted their routes kept private from one another without disrupting VPN links among the other sites in the network.

Final word
Company mergers can result in complicated technology requests for the administrators who are called upon to integrate what are often disparate networks. In this case, a privacy issue forced one admin to take steps that would otherwise have been unnecessary, but the end result was that sites located thousands of miles apart were successfully linked via VPN without being able to see each other's routes, as requested for political and competitive reasons.

Editor's Picks