Currently the BGP peer-group remote-as validation appears to be a bit broken, but probably an upstream bug in FRR:
```
vyos(config)# router bgp 123
vyos(config-router)# neighbor 1.1.1.1 peer-group foo
vyos(config-router)# neighbor 2.2.2.2 peer-group foo
vyos(config-router)# neighbor 1.1.1.1 remote-as auto
vyos(config-router)# neighbor 2.2.2.2 remote-as internal
% Peer-group members must be all internal or all external.
vyos(config-router)# neighbor 2.2.2.2 remote-as auto
% Peer-group members must be all internal or all external.
vyos(config-router)# neighbor 2.2.2.2 remote-as external
vyos(config-router)#
```
seems like when `remote-as auto` was added to FRR, the validation wasn't adjusted (code looks like it), otherwise I wouldn't see a good reason why you can configure `remote-as external`, but **not** `remote-as internal` or `remote-as auto` when the other peer-group member is `remote-as auto`
VyOS reflects this logic to prevent failed FRR commits, hence we need to be aware of this.
I've also posted this in the FRR slack, asking for some guidance what is the intended behaviour.
I'm not even exactly sure why this restriction exists in FRR.
I think we will have to wait for the FRR folks to state when the intended behaviour is, and possibly adjust the config validation.