02-22-2019 11:25 AM - edited 03-02-2019 11:37 PM
This article now available on CCO: https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/214147-vedge-does-not-advertise-its-own-as-when.html
This document describes why vEdge router does not advertise it's own Autonomous System (AS) number when advertising Border Gateway Protocol (BGP) routes into Overlay Management Protocol (OMP).
Cisco recommends that you have knowledge of these topics:
The information in this document was created with help of the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Here is a simple topology diagram that describe the setup:
192.168.41.0/24---|R1---vedge1–-Overlay–-vedge2---R2|---192.168.51.0/24
And the problem can be depicted as below:
For prefix A on R2 - you expect to see AS-PATH: 65002, 64500, 65001, 65156 but only saw 65002 64500 65156
For prefix B on R1 - you expect to see AS-PATH: 65001, 64500, 65002, 65157 but only saw 65001 64500 65157
1) Take a look at the prefix B (192.168.51.0/24) on vedge2.
vedge2# show bgp routes 192.168.51.0/24 detail bgp routes-table vpn 40 192.168.51.0/24 best-path 1 info 0 nexthop 192.168.50.115 metric 0 weight 0 origin igp as-path 65157 ri-peer 192.168.50.115 ri-routerid 2.2.2.1 path-status valid,best,external tag 0
As you notice, AS-path here consists of singe AS of our peer router R2 and this is an expected behavior. You see this prefix on vedge2 as it was advertised to us.
You can observe similar behavior as on ordinary Internetworking Operating Systems (IOS) routers as well.
2) Advertising BGP routes via OMP.
omp overlay-as 64500 advertise bgp !
Advertise bgp configuration is just like a well-known Cisco IOS redistribute command. OMP is similar to BGP, but in reality it’s another protocol developed specifically for SDWAN solution. So you preserve BGP prefix attributes that you had in BGP table (refer to step 1).
3) Looking at prefix B (192.168.51.0/24) on vedge1 after passing through overlay.
vedge1# show omp routes 192.168.51.0/24 detail --------------------------------------------------- omp route entries for vpn 40 route 192.168.51.0/24 --------------------------------------------------- RECEIVED FROM: peer 192.168.30.103 path-id 12 label 1003 status C,I,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 192.168.30.105 type installed tloc 192.168.30.105, mpls, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 50 preference not set tag not set origin-proto eBGP origin-metric 0 as-path "65157" unknown-attr-len not set
As you notice, attributes of this prefix were preserved similar to how it would be done for any other dynamic routing protocol. AS-path of BGP is just another one attribute of foreign routing protocol that has no meaning for OMP. Note that only one AS is seen in the path. It is an expected behavior because vedge2 didn’t do any advertisement to another BGP neighbor. It did redistribution to OMP from BGP, so it must not prepend its own AS to this prefix.
4) Performing redistribution of OMP into BGP AS 65001, but now on vedge1.
omp no shutdown overlay-as 64500 advertise bgp ! … ! vpn 40 router bgp 65001 propagate-aspath address-family ipv4-unicast redistribute omp ! neighbor 192.168.40.114 no shutdown remote-as 65156 ! ! !
Here is the place where overlay-as actually steps in and plays it's role, but unlike on ordinary Cisco IOS you won't see changes to prefix as it's advertised to R1 because on vEdge there is no command similar to Cisco IOS "show ipv4 uncicast bgp neighbors 192.168.40.114 advertised-routes" that can help us to see newly constructed AS-path.
5) So you are only left with possibility to check AS-path on receiving router (in this case R1).
R1#show bgp vpnv4 unicast vrf vEdge1_18.3 neighbors 192.168.40.104 routes BGP table version is 11, local router ID is 192.168.41.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:183 (default for vrf vEdge1_18.3) *> 192.168.51.0 192.168.40.104 1000 0 65001 64500 65157 ?
OMP shares some similarities with BGP, but this fact should not make any confusion when two protocols interact with each other. AS-path is one of the topics that commonly causes such misunderstanding.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: