A Close Look at the Redistribution of OSPF Routes into BGP in the ProCurve

As an example, consider the following network diagram:

OSPF Area 0 includes switches SW1, SW3 and SW4. In SW3, a static route to network 10.8.0.0/16 is configured, and this static route is configured to be redistributed into OSPF. Also in SW3, subnet 192.168.13.0/24 (or VLAN 13) is connected and also configured to be redistributed into OSPF.

We will focus on SW1, where both OSPF and BGP are configured, and where OSPF routes are exported into BGP.

First, the routing table in SW1 will look like this:

Notice that SW1 learned 3 routes from OSPF:

- 10.12.30.0/24 (VLAN 30) generated from with OSPF, hence listed here as "IntrArea" and considered an internal route.
- 10.8.0.0/16 and 192.168.13.0/24 (VLAN 13) distributed into OSPF from "static" and "connected", hence listed here as "External2" and considered external routes.

Now let's look at the distribution of these OSPF routes into BGP in SW1. Below is how SW1 is configured under BGP router (Scenario 1):

router bgp 1200
    enable
    redistribute ospf
    neighbor 192.168.20.2 remote-as 1300
    exit

With the above configuration, the BGP routing table in SW1 will look like:

As seen in the screenshot above, only the OSPF route 10.12.30.0/24 appeared in the BGP routing table. The reason is that the command "redistribute ospf" under BGP only exports OSPF internal routes into BGP. All external routes are excluded from the redistribution.

Now consider another BGP configuration in SW1 (Senario 2):

router bgp 1200
    enable
    network 10.8.0.0 255.255.0.0
    redistribute ospf
    neighbor 192.168.20.2 remote-as 1300
    exit

In this configuration, under BGP we have the command "network 10.8.0.0 255.255.0.0". The resulting BGP routing table will looks like:

In the screenshot above, in addition to the OSPF internal route of 10.12.30.0/24 (VLAN 30) which is exported into BGP by the command redistribute ospf, the route to subnet 10.8.0.0/16 also appears in the BGP table because in this scenario we have the command network 10.8.0.0 255.255.0.0 under BGP. In contrast, a route to subnet 192.168.13.0/24 (VLAN 13) is not present in the BGP routing table because this subnet is not configured with the network command under BGP.

The bottom line is that in the ProCurve, OSPF external routes cannot be exported into BGP using the redistribute command. They have to be specified using the network command under BGP to be present in the BGP routing table. This is different from Cisco IOS, which allows the export of OSPF external routes into BGP by the command redistribute ospf 1 match external.

Configuring and Monitoring Policy-based Routing (PBR) in the ProCurve

(This feature is available only on the 3800 Series, and the 5400/8200 Series with v2 or higher modules)

PBR allows path manipulation based on packet attributes. The following steps are required to configure PBR:

- Traffic is selected into one or more classes by using the “match” and “ignore” commands.
- A PBR policy is created, which specifies the actions to be performed on a traffic class.
- The policy is then applied to inbound traffic on a VLAN interface. PBR cannot be applied to a physical port.

Creating a class:

HP-5406zl(config)# class ipv4 Windward
HP-5406zl(config-class)# match tcp 192.168.4.0/24 eq 9801 host 192.168.1.3
HP-5406zl(config-class)# exit

In the example above, a class named "Windward" was created for all TCP traffic with the IP source address belonging to subnet 192.168.4.0/24, TCP port 9801, and destination address 192.168.1.3. For verification, use the command “show class config”. The “match” command accepts a wide range of protocols (tcp, udp, ip, igmp, esp, ospf, pim, and so on). Under each protocol we can specify source/destination IP addresses, TCP/UDP ports, DSCP, VLAN, etc. Use the question mark (?) in the CLI to view the available options.

Creating a PBR policy:

HP-5406zl(config)# policy pbr Alpharetta
HP-5406zl(policy-pbr)# class ipv4 Windward
HP-5406zl(policy-pbr-class)# action ip next-hop 20.0.0.1
HP-5406zl(policy-pbr-class)# exit

In the example above, a PBR policy named "Alpharetta" was created for the traffic class Windward as defined in the previous part. All packets matching the class Windward will have IP address 20.0.0.1 as the next hop. PBR actions also include “interface null”, which will drop the applicable packets. Each class may include up to 8 actions; the first action will be executed first, and the next action will apply if the first action cannot be executed (for example, the specified interface in the first action is down). Using this feature, multiple backup routes can be configured for a class of traffic.

Applying the PBR policy to a VLAN interface:

HP-5406zl(config)# vlan 10
HP-5406zl(vlan-10)# service-policy Alpharetta in

Notice that PBR policies only apply to VLAN interfaces, and only in the inbound direction.

Monitoring PBR:

The show statistics policy command displays hit counts for each policy action.

To enable debug logging for PBR, enter the debug ip pbr command.