Hello Stefan,
looking at your network diagram I understand that:
Central site routers CS R1 and CS R2 run a different BGP AS number AS X
All devices on the right part of the network diagram run BGP AS number Y.
>> Each VPN have redundant Route-Reflectors "RR1" and "RR2". And several location routers "Location1" to "Location n".
This is clear to me as represented in network diagram
>> Route-Reflectors have as clients the location routers within the VPN as well as the central routers
I dot not follow you on this, we have just noted that CS R1 and CS R2 are in BGP AS X, all other routers are in AS Y.
I would re-write the sentence in the following manner:
The Route reflector routers are acting as RRS in in iBGP in AS Y for Location 1 to Location N PE routers.
In addition the 4 RRS have eBGP sessions with CS R1 and CS R2.
I think this is more accurate from a technical point of view.
The next point that we need to clarify is the nature of the eBGP sessions between
CS R1 and RR1A, RR2A, CS R1 and RR1B, RR2B
CS R2 and RR1A, RR2A, CS R2 and RR1B, RR2B
Here I have given the names RR1A, RR2A to RRS in VPN A (top right portion of network diagram ) and RR1B, RR2B to RRS in VPN B ( bottom right portion of network diagram).
You write of two VPNs VPN A and VPN B.
Are the central site routers aware of existance of two VPNs VPN A and VPN B ?
If so both CS R1 and CS R2 are PE nodes and are acting as ASBR nodes in two inter-AS VPNs.
Here you have two options to create the control plane for Inter AS VPN:
A) option A interAS VPN requires to use per VRF eBGP sessions
something like
router bgp X
address-family ipv4 vrf VPNA
neighbor RR1A remote-as Y
neighbor RR1A send-community
neighbor RR1A activate
neighbor RR2A remote-as Y
neighbor RR2A send-community
neighbor RR2A activate
address-family ipv4 vrf VPNB
neighbor RR1B remote-as Y
neighbor RR1B send-community
neighbor RR1B activate
neighbor RR2B remote-as Y
neighbor RR2B send-community
neighbor RR2B activate
However, in this case you couldn't have put all the eBGP neighbors in the same peer-group as they are in different BGP AF.
2) option B
You have configured your CS site routers as full PE nodes and use option B for interAS VPN you enable your eBGP neighbors in AF VPNv4
Configuration example:
router bgp X
neighbor RR1A remote-as Y
neighbor RR2A remote-as Y
neighbor RR1B remote-as Y
neighbor RR2B remote-as Y
address-family vpnv4
neighbor RR1A activate
neighbor RR1A send-community extended
neighbor RR2A activate
neighbor RR2A send-community extended
neighbor RR1B activate
neighbor RR1B send-community extended
neighbor RR2B activate
neighbor RR2B send-community extended
In this second case you could have used a peer-group. however, I am not sure you can apply a route-map to set the MP BGP SoO extcommunity attribute in VPNv4 AF.
I would go for option A: split the peer-group in two groups use per VRF eBGP sessions and apply inbound route-maps to set the appropriate site of origin desired value.
Let us know what you have configured up to now.
Coming to your specific questions:
>> 1.) Are different SoO values for eBGP Peers, which are members of the same peer-group allowed?
As long as they share the same outbound filtering this should be possible. However, application of a route-map to set SoO may be limited to in VRF eBGP sessions and not available in MP EBGP AF vpnv4.
>> 2.) In case of yes, is there a difference if this BGP config it made in the global instance or under address-family ipv4 vrf?
Yes, there is difference I don't think you can apply a route-map setting a MP BGP attribute like SoO in a standard eBGP session defined in global or under address-family ipv4 unicast.
The use of eBGP sessions in VRFs is instead a correct point of application for setting SoO.
Hope to help
Giuseppe
