To the BGP Gurus,
I may be "flogging a dead horse" here but here goes........:
High Level Summary:
Are there any gloabl BGP neighbours cmds (i.e. NOT under VPNV4 or IPV4 address-family functionality) to perform a "AS-override" function?
PE1 (AS100) PE2(AS100)
\ VPN1 / VPN2
Basically the CE is dual-homed via different VPNs back the same AS100 cloud (please do not ask why this is being done this way, as I have only "extracted the bare minimal essence" to simplify the problem description and the issue- the real setup is quite complex....)
So the CE will learn the 10.100.10.0 subnet from PE2, likewise the CE will learn the 192.168.10.0 subnet from PE1. So far so good. Now when the CE advertises the 10.100.10.0 to PE1, of course PE1 will see it's own AS in the AS path info and delete/ ignore it. (BGP loop prevention). A similar scenario is undertaken on PE2 for the CE advertise 192.168.10.0 subnet.
[Yes, PE1 is required to have visibility of the 10.100.10.0 subnet and vice versa]
So two thoughts on this:
1) A couple of standard "nerd-knobs" to address this would be the bgp neighbor "as-override" or the "allowas-in" functions. However as this is a very one off / non-standard customer specific scenario, one would be relundant to apply changes on the PE side and if the cmds are global, may affects ALL BGP neighbors, not this specific one. There is also high-impedance to deviate away from a standard PE configuration...
What I would like to do is to remove the "AS100" from or manipulate the as-path information from the CE advertised routes to the PEs.
2) It seems that the only CE global BGP metric available to influence the best path selection is the autonomous system path length, which basically "prepends" an arbitray AS path string and not to modify one [i.e. I would like to remove the AS100 from the advertised CE routes and of course put the appriopriate filters in to prevent any potential loops etc]
I have investigated the use of route-maps to modify the advertise routes from the CE. Although one can used regualar expresssions to match on the as-path aspects, there seems to be no corresponding "set" cmd to modify it (probably because of the obvious implications! :-))
A temporary work-a-round using the "aggregate-address.......summary only" cmd does permit the PEs to accept the subnets, but with there origins stemming from the CE.
Is there any other way / method to manipulate / permit the AS-Path information that the CE is advertising to the PEs?
All kind thoughts welcome!
i think you already have the answers to your questions
the ways that can be used in your case and in my mind now
use aggregation toward each SP ( but this may lead to blackholing !!)
or you may create a VRF and add all the interfaces in the router to this VRF in this case you will be able to use the as-overwrite under the vrf bgp config
Yes, my post is more of a "sanity check" incase I'm missing something [which I normally do! :-( ]
Further reseaching this, there's an interesting option on the end of the "aggregate-address.." cmd >> "advertise-map". Seems that this may permit manipulation of the advertise AS path information
Has anyone used the "advertise-map" functionality under the BGP "aggregrate-address x.x.x.x 255.255.0.0 as-set summary-only advertise-map
as-set advertise-map with BGP summary can be used to control to which AS you can send the summary and also from which AS the aggregate route will take the attribute
if R2 sumarize the network from R1 and R3 to 10.1.0.0/16 then both of R1 and R3 will receive the route with source AS of AS 2 because once the route aggregated it considered atomic aggregate and it will lose the route attributes such as AS-path
if you want this summary route to be sent only to AS 3
the advertise-map as-set will help you here
ip as-path access-list 1 permit ^1$
route-map map1 permit 10
match as-path 1
router bgp 2
aggregate-address 10.1.0.0 255.255.0.0 as-set advertise-map map1
now if you do show ip bgp in R3 you will see the summary but with AS path as 1 and 2
while this summary route will not be show in R1 BGP routing table as the AS 1 now is included in this route and once R1 see its own AS will ignore it
your case is a bit differnt because you need your CE router to a transit router/AS
if helpful Rate
I have the exact same problem, 2 customers A and B want to speak together via our network, but the 2 customers have their VPN with the same provider.
(All routing is BGP so when the provider sees routes comming from VPN A into VPN B he rejects the routes because in the AS-PATH the provider sees its own ASes.)
How did you finally managed to "rewrite" the advertised as-path ?
Thanks a lot