Implement targeted routing using Policy Routing

This article describes in detail how to implement targeted routing for Policy Routing, and provides detailed configuration procedures and command line operations from the policy routing function to the interface application. The following article will introduce you in detail.

The topology is as follows:

Because of the design requirements, different address segments on the aggregation layer must be routed to different endpoints on the core layer to achieve load balancing. The topology is not complete here. In fact, there is an authentication gateway on each of the two network segments between NE40 and 3550.

The policy routing function on cisco3550 is used here.

First, create two ACLs to define the source address:

Access-list 100 permit ip 10.200.0.0 0.3.255.255 any

Access-list 104 permit ip 10.204.0.0 0.3.255.255 any

Note: we only need to define the source address for the two ACLs. It is only the IP address connected to V5.0.

Then define the policy route:

Route-map lygcatv permit 10

Matches ip address 100

Set ip next-hop 172.20.0.1

!

Route-map lygcatv permit 20

Matches ip address 104

Set ip next-hop 172.20.0.9

Note: The names of the two policies are the same. The values 10 and 20 are the index numbers or priority numbers. In actual applications, the values 10 and 20 are not matched. 100 and 104 correspond to the two ACLs above, and finally define the next hop address, that is, the address connected to NE40 and 3550.

Finally, it is applied to the interface:

Interface FastEthernet0/12

No switchport

Ip address 172.20.0.17 255.255.255.255.248

Ip policy route-map lygcatv

Note: The policy can only be applied to the portal. Otherwise, it will fail, but it will only result from a painful failure. Later, I checked the information. In this way, no static or dynamic routing is required on 3550, and the correct routing must be set on 7650.