BGP – advertise-peer-as
1. The default
In the Juniper documentation we have the following statement: by default, Junos OS does not advertise the routes learned from one EBGP peer back to any EBGP peers that are in the same AS as the originating peer.
Let’s explore this feature and put it to the test. The text book scenario for this feature is the following:
As we can see, R6 and R8 have the same AS number, so there is an as-path loop. In Junos, R7 will see the as-path loop, and in order to optimize BGP advertisements, it will not even exchange the prefixes between R6 and R8. R7 will accepts the prefixes form R6 and R8, but it will not advertise those prefixes back to the AS65535:
- R7 will not advertise 192.168.66.0/24 to R8
- R7 will not advertise 192.168.88.0/24 to R6
### Basic BGP config:
root@R7# show protocols bgp | display set
set protocols bgp group AS65535 peer-as 65535
set protocols bgp group AS65535 neighbor 17.8.14.1
set protocols bgp group AS65535 neighbor 17.8.17.2
### R7 will accept the prefixes from R6 and R8:
root@R7# run show route protocol bgp
inet.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.66.0/24 *[BGP/170] 01:59:17, localpref 100
AS path: 65535 I, validation-state: unverified
> to 17.8.14.1 via ge-0/0/2.0
172.16.88.0/24 *[BGP/170] 00:00:22, localpref 100
AS path: 65535 I, validation-state: unverified
> to 17.8.17.2 via ge-0/0/3.0
### But R7 will not advertise the prefixes back to R6 and R7.
[edit]
root@R7# run show route advertising-protocol bgp 17.8.14.1
[edit]
root@R7# run show route advertising-protocol bgp 17.8.17.2 This may seem strange to you if you come from Cisco. If we are to make a comparison, R7 with Cisco IOS will advertise the prefixes back to R6 and R8, and it will be on R6 and R8 to notice the loop and reject the prefixes.
2. Add the advertise-peer-as knob
We will change the setup a little bit.
The documentation is talking about EBGP to EBGP advertisements, but in our new setup we have iBGP to EBGP. will that work?
### The configuration represents the new setup:
root@R7# show protocols bgp | display set
set protocols bgp group AS65535 peer-as 65535
set protocols bgp group AS65535 neighbor 17.8.14.1
set protocols bgp group iBGP type internal
set protocols bgp group iBGP neighbor 17.8.17.2
### the prefixes are accepted by R7:
root@R7# run show route protocol bgp
inet.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.66.0/24 *[BGP/170] 02:35:11, localpref 100
AS path: 65535 I, validation-state: unverified
> to 17.8.14.1 via ge-0/0/2.0
172.16.99.0/24 *[BGP/170] 00:01:08, localpref 100
AS path: 65535 I, validation-state: unverified
> to 17.8.17.2 via ge-0/0/3.0
### R7 will still not advertise prefixes to R6 because of the loop:
root@R7# run show route advertising-protocol bgp 17.8.14.1
[edit]
root@R7# As we can see, R7 will notice the as-path loop, and will optimize advertisements by not sending the prefix to R6.
Maybe not the most realistic setup, but for learning purposes we want to see the advertise-peer-as knob at work, so let’s configure that:
### Let's add the advertise-peer-as:
root@R7# set protocols bgp group AS65535 advertise-peer-as
[edit]
root@R7# show | compare
[edit protocols bgp group AS65535]
+ advertise-peer-as;
[edit]
root@R7# commit
commit complete
### Now we are advertising the prefix to R6:
root@R7# run show route advertising-protocol bgp 17.8.14.1
inet.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.99.0/24 Self 65535 I
### But the prefix is not visible on R6 because of the as-path loop:
root@R6# run show route receive-protocol bgp 17.8.14.2 hidden extensive
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
### By default these prefixes are discarded, so let's change that:
root@R6# show | compare
[edit protocols bgp group AS54100]
+ keep all;
[edit]
root@R6# commit
commit complete
### Now we can see the prefix on R6, but hidden because of the as-path loop:
root@R6# run show route receive-protocol bgp 17.8.14.2 hidden extensive
inet.0: 21 destinations, 21 routes (20 active, 0 holddown, 1 hidden)
172.16.99.0/24 (1 entry, 0 announced)
Nexthop: 17.8.14.2
AS path: 64100 65535 I (Looped: 65535)
Hidden reason: AS path loop
R7 is now advertising the prefix to R6, but R6 will discard the prefix because of the as-path loop. But we can make R6 to allow and use the prefix by configuring the loops knob. This is similar to the Cisco allow-as in.
### Let's allow one loop in the as path:
[edit]
root@R6# set protocols bgp group AS54100 family inet unicast loops 1
[edit]
root@R6# show | compare
[edit protocols bgp group AS54100]
+ family inet {
+ unicast {
+ loops 1;
+ }
+ }
[edit]
root@R6# commit
commit complete
### Now the prefix is usable:
root@R6# run show route protocol bgp
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.99.0/24 *[BGP/170] 00:00:18, localpref 100
AS path: 64100 65535 I, validation-state: unverified
> to 17.8.14.2 via ge-0/0/3.0For completeness, let’s acknowledge that in order to make this working end to end, of course we must configure the advertise-peer-as and loops combo on the R8 and R9 routers. To keep the post short, I will not show the R8 and R9 configuration here because it is identical.
3. Not applicable scenarios
At this point you may be tempted to say that “Junos doesn’t advertise the routes if the neighboring AS number is already in the AS path of the respective route”. When learning about this default behavior I was guilty of this myself. But this is not true. We have scenarios where Junos will advertise the prefix to a neighbor even if the is an as-path loop:
We can see that R2 will advertise to R1 the prefixes from R4 and R5 even without the advertise-peer-as knob, even if the loop is there.
### The 'advertise-peer-as' is not configured:
root@R2> show configuration protocols bgp | display set
set protocols bgp group AS65535 peer-as 65535
set protocols bgp group AS65535 neighbor 17.8.0.1
set protocols bgp group AS65002 peer-as 65002
set protocols bgp group AS65002 neighbor 17.8.8.2
### The neighboring AS number is already in the AS path of the respective route, but not the 1st AS.
### But the prefix is still advertised to R1:
root@R2> show route advertising-protocol bgp 17.8.0.1
inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 192.168.40.0/26 Self 65002 65535 I
* 192.168.50.0/26 Self 65002 65535 64003 IWe can conclude that Junos will check for an as-path loop, but it will compare only the 1st AS from as-path.
In our example, it will compare AS65002 with the destination AS65535. No loop here, ignore the rest and advertise the prefix to peer.
Personal note: when I consider that some prefixes can have long AS paths, and considering the sheer number of Internet prefixes that are managed by BGP, then it makes sense not to go crazy and compare each AS from the as-path. Comparing only the 1st AS is probably a good balance and will save a lot of computing resources on the router.
4. Closing remarks
But why even allow the loop in the network? If the previous scenarios are maybe not that common, in MPLS L3VPN it is norm to use the same AS number for all VPN sites of a given Customer. If we want end to end connectivity, then we must allow as-path loops in the network, by either using the advertise-peer-as and loops combo, or the as-override feature.
A few final remarks:
- Notice this post was more about the EBGP advertisement default behavior, and less about advertise-peer-as.
- The default behavior: When advertising to an eBGP peer, Junos will check each prefix for as-paths loops, but will check only the 1st AS from the prefix as-path. If there is an as-path loop for 1st prefix, don’t advertise that prefix.
- advertise-peer-as will change the default behavior by advertising the prefix to the peer. It will be on the peer to discard the prefix with the as-path loop.
- advertise-peer-as is often used in conjunction with loops.
- often times as-override is a better solution.
Note: enabling the AS loops feature may result in routing loops. Use this feature only for specific applications that require this type of behavior, and in situations with strict network control.
External Resources: