How to add static secondary route to the same subnet which has BGP route

[Essam Ahmad]

Dears,

I hope you're all doing well...

I have BGP protocol that has a route to subnet: 192.168.100.0 with AD=200

I need to add a secondary static route as following:

ip route 192.168.100.0 255.255.255.0 172.16.55.50  

Which should be used only in PBR (Policy Based Routing) rule in file copying using port: 445

The problem is that if I added this static route in the configuration it replaces the BGP route in routing table, I can force adding the static route in the routing table by setting the administrative distance to a value lower than 200 (current BGP Admin Distance) but it will removes the BGP route, and I want to keep both but uses the static route only for PBR rule.

Routing table:

IT-Building(config)#do show ip route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets

B        2.2.2.2 [200/0] via 192.168.181.237, 02:10:07

      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks

C        172.16.55.0/24 is directly connected, FastEthernet1/0

L        172.16.55.60/32 is directly connected, FastEthernet1/0

      172.55.0.0/16 is variably subnetted, 3 subnets, 2 masks

C        172.55.20.0/24 is directly connected, FastEthernet1/1

L        172.55.20.254/32 is directly connected, FastEthernet1/1

B     192.168.100.0/24 [200/0] via 192.168.181.237, 00:02:46

        192.168.181.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.181.236/30 is directly connected, GigabitEthernet0/0

L        192.168.181.238/32 is directly connected, GigabitEthernet0/0

Could you help me in this task?

[Peter Paluch · Accepted solution]

Essam,

You can not do it by manipulating the routing table directly because the routing table is concerned only with destinations while you want to perform routing based on additional criteria, not just the destination. This is accomplished purely using PBR, as you correctly mentioned, and route-maps.

In a simplified example, something like this should do the trick:

ip access-list extended PBR
 permit tcp any 192.168.100.0 0.0.0.255 eq 445
!
route-map PBR permit 10
 match ip address PBR
 set ip next-hop 172.16.55.50
!
interface ...
 ip policy route-map PBR

Note that the routing table is not modified in any way. This is the way PBR works - you override the routing table in the route-map, and keep the routing table intact.

Would this help a little?

Best regards,

Peter

[Essam Ahmad]

Thank you Peter in advance,

It's working now, but I want to share with you my notes and other problems that I encountered:

1- I had a wrong assumption that I must have a valid  route in the routing table to be used in the PBR, but you have corrected  this to me.

2- I used GNS3 for simulating my network  setup, in order to test PBR I make a rule to test icmp from a specific host by adding this testing ACL entry:

permit icmp host 172.55.20.20 192.168.100.0 0.0.0.255

And the complete setup for PBR is:

ip address 172.55.20.254 255.255.255.0

ip policy route-map DATA_TRAN_MAP

duplex full

speed 100

route-map DATA_TRAN_MAP permit 10

match ip address FTP_ACL

set ip next-hop 172.16.55.50

set ip next-hop verify-availability

ip access-list extended FTP_ACL

permit tcp host 172.55.20.20 192.168.100.0 0.0.0.255 eq 445

permit tcp host 172.55.20.20 192.168.100.0 0.0.0.255 eq ftp

permit tcp host 172.55.20.20 192.168.100.0 0.0.0.255 eq ftp-data

permit icmp host 172.55.20.20 192.168.100.0 0.0.0.255

What caused confusion to me is that by default when  you use trace command in VPCS (Virtual PCs) it will use port 17 by  default which will not trigger the testing ACL entry and hence the  desired PBR action will not work. The solution to this is to specify  icmp in the trace command in the VPCS. Check the difference hereunder:

I hope everyone will take advantage from this issue.

Thanks & Best Regards,

[Peter Paluch]

Hello Essam,

You are welcome!

1- I had a wrong assumption that I must have a valid  route in the  routing table to be used in the PBR, but you have corrected  this to me.

Quite right. What you need to have, though, is a route towards the next hop specified in the route-map. Usually, it is required that the next hop is on a directly connected network. Newer IOSes allow using a recursive next hop.

What caused confusion to me is that by default when  you use trace  command in VPCS (Virtual PCs) it will use port 17 by  default which will  not trigger the testing ACL entry and hence the  desired PBR action  will not work.

Hmm... Port 17? I do not understand this one. Are you perhaps talking about IP protocol 17, i.e. UDP? In that case, however, I do not see any UDP entries in your ACL.

Best regards,

Peter

[Essam Ahmad]

Dear Peter,

Kindly find my reply on this portion here below:

Hmm... Port 17? I do not understand this one. Are you perhaps talking about IP protocol 17, i.e. UDP? In that case, however, I do not see any UDP entries in your ACL.

Yes, for VPCS its default is using IP protocol UDP port number (17) for the trace not using the icmp protocol.

Please check this snapshot from trace command help in VPCS:

       

And for that reason I had to write the following trace command in VPCS console:

VPCS[8]> trace 192.168.100.1 -P 1

To force the trace command to use default icmp port and hence this ACL entry:

permit icmp host 172.55.20.20 192.168.100.0 0.0.0.255

Will do its function as expected.

Is this clear enough?

Best Regards,

[Peter Paluch · Accepted solution]

Hello Essam,

Alright, I see your point. Still, please be aware that the -P switch as used by your trace command specifies an IP protocol number and not a port number. Do not confuse these two terms and concepts.

IP protocol number is a single 1B field in IP header that identifies the type of the payload in this IP packet - whether the IP packet carries a TCP segment, UDP segment, ICMP message, OSPF packet, VRRP packet, PIM message, etc.

A port number is used only by selected transport layer protocols such as TCP and UDP (not by IP, as IP is not a transport layer protocol), and it is a 2x2B field in segment header that uniquely identifies the process that either sent this segment or is supposed to receive it - that's why there are source and destination ports.

Best regards,

Peter

[Essam Ahmad]

Thanks Peter for your kind support.