SD-WAN business policy Internet IP match mechanism
Article ID: 376227
Updated On:
Products
Issue/Introduction
This article introduces how VCE matches destination Internet IP configured in a business policy. Sometimes customer may raise case about unexpected business policy match especially destination Internet IP match.
Environment
All supported VMware by Broadcom SD-WAN edge versions
Cause
SD-WAN edge identifies Internet IP by route lookup. For example, if flow is created with destination IP 8.8.8.8, SD-WAN edge firstly lookup the destination route for 8.8.8.8. If the most preferred route type is "cloud", SD-WAN edge identifies 8.8.8.8 as Internet IP and flow can match the business policy with destination is "Internet".
However, if most preferred route is "edge2edge" type, even if 8.8.8.8 is a well-known public IP address, SD-WAN edge does not identify it as "Internet" IP, the flow does not hit business policy with Internet destination.
For partner gateway deployment, there is a possibility that customer configure specific route for particular IP on partner gateway:
In this scenario, when lookup destination route for 8.8.8.8, the most preferred route is the specific route advertised by SD-WAN partner gateway:
Although the flag of this route is "PgR", the type is still "Cloud", SD-WAN edge treats 8.8.8.8 as "Internet" IP.
FID SECURE SEGID FDSN MAX_RECV_FDSN FDSN_READ LAST_LATE_FDSN SRC_IP DEST_IP SRC_PORT DEST_PORT PROTO DSCP PRIORITY APPLICATION APP_CLASS TRAFFIC-TYPE ROUTE ROUTE-POL LINK-POL BIZ-POL NH-ID LINK-ID FLAGS1 VERSION SRC ADDR SR DR FLOW AGE MS IDLE TIME MS CBH-FLOW DROPS LAST_DROPPED_REASON LAST_DROPPED_PATH BIZ_POL_FIXUP
23464 0 0 7 0 0 0 10.0.1.25 8.8.8.8 3902 2048 1 0 normal APP_ICMP(70) APP_CLASS_NETWORK_SERVICE(13) transactional Cloud via Gateway gateway fixed Internet_match_policy d664f7aa- N/A 0x200000 1 local 0x5587664ac500 0x7f6374721bd0 0x7f6374725890 6363 214 0 0
In rare scenario, customer may find that even a private IP hits Internet destination business policy and raise case to technical support:
edge:b1-edge1:~# debug.py --flow_d all 10.96.145.34 0
FID SECURE SEGID FDSN MAX_RECV_FDSN FDSN_READ LAST_LATE_FDSN SRC_IP DEST_IP SRC_PORT DEST_PORT PROTO DSCP PRIORITY APPLICATION APP_CLASS TRAFFIC-TYPE ROUTE ROUTE-POL LINK-POL BIZ-POL NH-ID LINK-ID FLAGS1 VERSION SRC ADDR SR DR FLOW AGE MS IDLE TIME MS CBH-FLOW DROPS LAST_DROPPED_REASON LAST_DROPPED_PATH BIZ_POL_FIXUP
23561 1 0 1 1 1 0 10.0.1.25 10.96.145.34 3905 2048 1 48 normal APP_ICMP(70) APP_CLASS_NETWORK_SERVICE(13) transactional Cloud via Gateway gateway fixed Internet_match_policy d664f7aa- N/A 0x200000 1 local 0x5587664b1c80 0x7f6374721bd0 0x7f637472d570 12488 12486 0 0 - - 0
As always, SD-WAN edge first lookup the routes for 10.96.145.34:
SD-WAN partner gateway learns 10.96.0.0/16 from its PE via BGP and advertise to connected SD-WAN edge, please note the type of this route is still "cloud" hence SD-WAN edge handles 10.96.145.34 as "Internet" IP. Thus flow matches Internet policy as expected. This is very likely to occur in partner gateway deployment, while in cloud gateway deployment, the flow is dropped due to RFC1918.
http://www.flgnetworking.com/RFC_1918.html
Resolution
To troubleshoot the issue, TAC engineer should always check the most preferred route (route on the top) and verify if the route type is "Cloud".
Additional Information
Feedback
