OSPF routing with ISP

[gensonator]

I am new to this technology so please be kind.  I need assistance in making OSPF work between out Head Office (HO) and the Branch Offices where the ISP is not involved in OSPF routing.

We are using OSPF protocol on our entire network and our ISP 1 is involved in OSPF routing between the HO and the branch.  We are now trying to establish another link to the branches with a second ISP but they do not support OSPF like the first ISP and only use static routing.  They redistribute our routes via BGP.  The HO can talk to the branch using static routes but of course I would like to use dynamic routing instead.

How could I make OSPF work in the new backup link?  The  Engineer for the IS said that I need to use tunneling but I don't know how to configure it.  Is there any other way to make it work aside from tunneling?

Please see attached diagram. 

[rickymao16]

hi Gensonator,

I think tunneling is a choice.

I am quite curious why the old ISP offers OSPF routing. I work in a local ISP, and we always do like this:

router bgp 100

network 10.90.0.0 netmask 255.255.255.0

........

Is it a so small ISP that it offers OSPF?  I am also wondering whether it is easier for your router to calculate metric if the ISP offers OSPF routing.

By the way, the way that our company offers to the customers looks quite like the new ISP does.

Ricky

[Giuseppe Larosa · Accepted solution]

Hello Gensonator,

you need to use a GRE p2p tunnel in order to run OSPF over it.

On new ISP facing routers you just need one static route to reach the remote end router

MAIN office new  ISP CE

ip route 10.90.0.8 255.255.252 10.90.0.5

interface tunnel  12

description GRE tunnel over new ISP

tunnel source 10..90.0.6

tunnel destination 10.90.0.10

ip address 10.91.0.1 255.255.255.252

!

router ospf 10

network 10.91.0.0 0.0.0.3 area 0

Note: do not configure network area commands in OSPF for the PE-CE IP subnets of new ISP to avoid instabilities

The same has to be done in a mirrored way on the branch office CE router facing the new ISP.

The tunnel creates a logical common subnet (10.91.0.0/30 in my example) that allows to run OSPF over it.

Both OSPF messages and user traffic are encapsulated in GRE packets with source and destination according to the commands tunnel source and tunnel destination and new ISP will see only packets like IP SA 10.90.0.6 IP DA 10.90.0.10 and does not need to inspect the inner payload

Edit:

You can tune OSPF cost with ip ospf cost under interface tunnel configuration

Another important note is that the aggregated traffic that can travel on the GRE tunnel is limited to 8 Mbps by default.

This parameter can be changed in advanced security packages

Hope to help

Giuseppe

[gensonator]

Thanks for the reply Guiseppe and Ricky.  I managed to create a tunnel but OSPF does still not work between the Head office and the Branch.  The HQ router does not see the Branch router as an ospf neighbor and vice versa - with or without ospf password.

They tunnel interfaces are both up/up and the CEs can ping each other. Am I missing something here?

Below is the sanitized configuration of the Head Office CE (Catalyst 6500) and the Branch CE (Cisco 1921).

Head Office#

interface Vlan8

ip address 10.92.0.6 255.255.255.252

ip ospf message-digest-key 1 md5 password

!

interface GigabitEthernet1/4/47

description --- Link to NEW ISP ---

switchport

switchport access vlan 8

switchport mode access

!

interface Tunnel7

description --Tunnel to NSD---

ip address 10.92.1.57 255.255.255.252

tunnel source 10.92.0.6

tunnel destination 10.92.0.58

router ospf 1

log-adjacency-changes

nsf

area 0 authentication message-digest

redistribute static subnets route-map STATIC-TO-OSPF

passive-interface default

no passive-interface Vlan6

no passive-interface Vlan7

no passive-interface Vlan8

no passive-interface Vlan11

no passive-interface Vlan951

network 10.92.1.0 0.0.0.255 area 0

network 172.9.0.0 0.0.255.255 area 0

BRANCH1#

interface Tunnel1

ip address 10.92.1.58 255.255.255.252

tunnel source 10.92.0.58

tunnel destination 10.92.0.6

!

interface GigabitEthernet0/1

ip address 10.92.0.58 255.255.255.252

ip ospf message-digest-key 1 md5 password

duplex auto

speed auto

!

router ospf 1

router-id 192.168.30.7

area 0 authentication message-digest

area 1 authentication message-digest

network 10.92.1.0 0.0.0.255 area 0

network 172.20.56.0 0.0.7.255 area 1

!

ip route 10.92.0.4 255.255.255.252 10.92.0.57

The Head Office Router links is the WAN aggregation router to multiple branches. 

Does this mean I have to create a tunnel for the link to each branch. 

Can I create multiple tunnel from one source interface of the HO?

Should make the mask to a bigger subnet, say /24?

Do I still have to configure BGP routing?

[rickymao16]

Hi gensonator

I am not sure, but maybe it is because the new ISP filters the multicast traffic. at the boundaries. I saw the configuration of our company. They configure it under the BGP progress, like :

router bgp 100

neighbor x.x.x.x route-map ABC in

And then they write a route-map to deny the multicast traffic.

I would be very like to hear some voice of our expert if this is the actual reason : )

[Giuseppe Larosa · Accepted solution]

Hello Gensonator,

on Head office router you need to add

router ospf 1

no passive-interface tunnel1

because you have configured passive-interface default

You should configure one GRE p2p tunnel for each remote branch, each GRE tunnel uses a different IP subnet, you cannot use a single IP subnet.

You can reuse the same IP source on the HQ router side (CAUTION this is not possible for multilayer switches like C7600 or C6500, but it is possible with software based ISR routers, I'm assuming that your router in HQ is a SW based router).

On HQ side each GRE tunnel will use a different tunnel number, it is common practice to use the same number at the other end but these numbers don't need to match.

A different destination IP address for each branch is needed

on HQ router

router ospf 1

no passive-interface tunnel X

for each defined tunnel and the IP subnet used on the tunnel has to be covered by a network ... area 0 command

Hope to help

Giuseppe

[gensonator]

Hi Guiseppe,

Thanks for the very helpful information.  Two thumbs up!!!  So far OSPF between the Head Office and a branch is working after following your advise.

The PE router in the Head Office directly connects to the C6500, so assume I would have a problem creating multiple tunnels on a single IP source.  Would you suggest installing another router in between?  What router model would you recommend if I am aggregating 7 branches with 4Mbps links and 2 x 20Mbps link.   The WAN aggregation link is 50Mbps.

You also said that the GRE tunnel is limited to 8Mbps but can be changed if I upgrade the IOS to Advance Security package. Does this mean that I would not be able to utilise the full 20Mbps link of one of the branches if I am using using IOS s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(33)SXI5?

[Giuseppe Larosa]

Hello Gensonator,

nice that OSPF is now running over the GRE tunnel.

About your questions:

given the low number of remote sites you can overcome the C6500 limitation by using loopback interfaces, one for each site, to provide a different source address for each GRE tunnel

The IP addresses of the loopback interfaces have to be taken from the address space of HQ so that PE router of new ISP can route them.

You can use /32 IP addresses on the loopbacks so you need to get a /28 space from your addresses.

About the BW limitation of GRE Tunnels to 8 Mbps it applies for sure on ISR software based routers.

GRE implementation on C6500 with Sup720 is different and it might be not affected by this limitation,

The command I was referring to is

tunnel bandwidth transmit|receive  

to be given under interface tunnel X.

Further investigation is needed to understand if it applies to a C6500 or not.

Hope to help

Giuseppe

[JamesEwing]

You also may not want to use Area 0 for a tunnel interface.  If the tunnel goes down, your entire Area 0 backbone will go down.  I recommend using a different Area for tunnels if you really feel you must run OSPF over a tunnel.