BGP Community Local AS

ReneMolenaar · December 29, 2016, 5:46pm

This topic is to discuss the following lesson:

mario_ramales · September 20, 2015, 10:10pm

Quick question Rene on this topic. The lab works fine as I followed along with my own topology. But I am just wondering why R2 should send the community only to R3? For example, you mentioned: “R2 sets the community so make sure that it advertises it to R3”… why should it not send the community to R4 as well. I know R4 is in another AS, but R4 would have filtered it out as well, wouldn’t it?

ReneMolenaar · September 24, 2015, 7:25pm

Hi Mario,

On R2 I configured the route-map inbound (facing R1) so that R2 sets the local AS community. Because of this, R2 will no longer advertise prefixes to R4 since it’s another sub-AS. R3 will still receive it since it’s in the same sub-AS as R2.

To make sure R5 (and R4) learn anything through R3, we need to advertise the local AS community to R3.

Rene

marty.stoyanoff · February 4, 2016, 8:23am

Excellent topic! Thank you Rene!

farooqateeq1 · June 14, 2016, 7:03am

Hi Rene,

In your comment you mentioned “To make sure R5 (and R4) learn anything through R3, we need to advertise the local AS community to R3” . How can R3 advertise to R4 and R5 when they in different Sub AS.

Thanks in advance.

ReneMolenaar · June 15, 2016, 8:25pm

Hi Mohammed,

You can advertise prefixes from one sub-AS to another sub-AS, that’s no problem.

Take a look at the BGP Confederations lesson, that might be helpful.

Rene

champ.lsp · July 11, 2016, 11:51am

Hi,

I am confused about BGP selecting path.Here topology

R5 is in sub-AS 45.And advertise prefix 9.9.9.9/32.

R5#sh ip bgp             
BGP table version is 14, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, &gt; best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*&gt; 9.9.9.9/32       0.0.0.0                  0         32768 i
*&gt; 192.168.12.0     2.2.2.2                  0    100      0 (23) i
* i                 2.2.2.2                  0    100      0 (23) i

R4 is in sub-AS 45 same R5 and it learn prefix 9.9.9.9/32 from R5.

R4#sh ip bg              
BGP table version is 15, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, &gt; best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*&gt;i9.9.9.9/32       5.5.5.5                  0    100      0 i
* i192.168.12.0     2.2.2.2                  0    100      0 (23) i
*&gt;                  2.2.2.2                  0    100      0 (23) i
R4#sh ip bgp 9.9.9.9/32
BGP routing table entry for 9.9.9.9/32, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
        2
  Local
    5.5.5.5 (metric 11) from 5.5.5.5 (5.5.5.5)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best

R2 is in sub-AS 23 and it learn prefix 9.9.9.9/32 from R4.

R2#sh ip bgp
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, &gt; best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*&gt; 9.9.9.9/32       5.5.5.5                  0    100      0 (45) i
*&gt; 192.168.12.0     0.0.0.0                  0         32768 i
R2#
R2#sh ip bgp 9.9.9.9/32
BGP routing table entry for 9.9.9.9/32, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
        1    3
  (45)
    5.5.5.5 (metric 21) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, confed-external, best

R3 is in sub-AS 23 and it learn prefix 9.9.9.9/32 from both R2 and R5.

R3#sh ip bgp 
BGP table version is 3, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, &gt; best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  9.9.9.9/32       5.5.5.5                  0    100      0 (45) i
*&gt;i                 5.5.5.5                  0    100      0 (45) i
*&gt;i192.168.12.0     2.2.2.2                  0    100      0 i
R3#
R3#
R3#sh ip bgp 9.9.9.9/32
BGP routing table entry for 9.9.9.9/32, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
        2
  (45)
    5.5.5.5 (metric 11) from 5.5.5.5 (5.5.5.5)
      Origin IGP, metric 0, localpref 100, valid, confed-external
  (45)
    5.5.5.5 (metric 11) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best

The question is, Why R3 select confed-internal(2.2.2.2) instead confed-external(5.5.5.5)?

Thank you in advance.

ReneMolenaar · July 18, 2016, 3:15pm

Hi Ler Sak,

BGP doesn’t differentiate between confed-internal or confed-external. When the two paths are the same, it’s up to the router ID to decide which one will be selected.

Here’s an example from the topology I used in this lesson:

R4#show ip bgp 55.55.55.55/32
BGP routing table entry for 55.55.55.55/32, version 5
Paths: (2 available, best #1, table default)
Flag: 0x800
  Not advertised to any peer
  Refresh Epoch 1
  (35)
    5.5.5.5 (metric 2) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  (35)
    5.5.5.5 (metric 2) from 5.5.5.5 (55.55.55.55)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0

Above you can see the path from 2.2.2.2 has been selected. Let’s change the router ID on R2:

R2(config)#router bgp 24
R2(config-router)#bgp router-id 222.222.222.222

Now it prefers R5:

R4#show ip bgp 55.55.55.55/32
BGP routing table entry for 55.55.55.55/32, version 13
Paths: (2 available, best #2, table default)
Flag: 0x800
  Advertised to update-groups: (Pending Update Generation)
     2          4         
  Refresh Epoch 1
  (35)
    5.5.5.5 (metric 2) from 2.2.2.2 (222.222.222.222)
      Origin IGP, metric 0, localpref 100, valid, confed-internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  (35)
    5.5.5.5 (metric 2) from 5.5.5.5 (55.55.55.55)
      Origin IGP, metric 0, localpref 100, valid, confed-external, best
      rx pathid: 0, tx pathid: 0x0

Hope this helps!

Rene

champ.lsp · July 18, 2016, 8:26pm

Hi Rene,

Thank you so much.

staut_stefanita · April 5, 2019, 10:39am

Hello,

Just a few remarks/questions for this lesson.

I believe R2 should advertise the 192.168.12.0/24 network (network 192.168.12.0 mask 255.255.255.0), otherwise the other routers will not know about 192.168.12.1 as next-hop for 1.1.1.1 (I checked the confederations lesson).
Also on R3 the neighbor command for R6 should be .2 instead of .6.

One question is how will R5 select the path towards 1.1.1.1? In your previous post I saw that Router ID is selected, but shouldn’t be attribute 7 (eBGP path over iBGP path)?. I believe that confed-external behaves like eBGP and attribute 7 has higher precedence over Router ID.

Thank you,
Stefanita

ReneMolenaar · April 11, 2019, 8:59am

Hello Stefanita,

I just made some changes to this lesson:

I fixed this in the topology picture.

If you want connectivity between the different routers, you’ll have to advertise some more networks yes. R3, R4, R5, and R6 don’t know about 192.168.12.0/24 but R1 also doesn’t know about any of the subnets in between R2, R3, R4, R5, and R6. For this example, it doesn’t matter since the only thing I wanted to demonstrate is how the local-as community works.

I double checked this. According to this document:

It states:

Paths that contain AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the confederation. Therefore, these paths are treated as internal paths. There is no distinction between Confederation External and Confederation Internal.

So, there is no difference between “external” and “internal” here, which is why R5 uses the lowest BGP Router ID to choose the path. Here’s what R5 has now:

R5#show ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 4
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  (23) 1
    192.168.12.1 (metric 3) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, confed-external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  (23) 1
    192.168.12.1 (metric 3) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, confed-internal
      rx pathid: 0, tx pathid: 0

It chooses 3.3.3.3 as the best path. Let’s change the router ID:

R3(config)#router bgp 23
R3(config-router)#bgp router-id 33.33.33.33

Here’s R5 again:

R5#show ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 5
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     3         
  Refresh Epoch 1
  (23) 1
    192.168.12.1 (metric 3) from 3.3.3.3 (33.33.33.33)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  (23) 1
    192.168.12.1 (metric 3) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      rx pathid: 0, tx pathid: 0x0

You can see R5 doesn’t care whether it’s confed-internal or confed-external, it picks the path with lowest router ID.

I hope this has been helpful!

Rene

william.ninobla50 · May 13, 2019, 5:52am

Hello Rene,

Can the local-as community be configured only by the router receiving the traffic, just like the MED and AS-Path prepending attributes?

Thanks

William

lagapidis · May 13, 2019, 1:22pm

Hello William

Notice that the command to set the local AS is in the form of a route map. The following is an example of such a command, as taken from the lesson:

R2(config-router)#neighbor 192.168.12.1 route-map LOCAL_AS in

The keyword “in” makes the local AS be enforced on all AS’es received from neighboring BGP routers. So in this case, it is enforced on AS’es being learned.

If we used the keyword “out” then it would be enforced on all AS’es being sent to neighboring BGP routers.

So depending on the keyword being used, the implementation of the local-AS can be modified.

I hope this has been helpful!

Laz

fqtsys · August 17, 2019, 4:57am

Hi,
In R2 configuration. it has the following code:

 neighbor 4.4.4.4 remote-as 45
 neighbor 4.4.4.4 ebgp-multihop 2
 neighbor 4.4.4.4 update-source Loopback0

In R3 configuration it has the following code:

 neighbor 5.5.5.5 remote-as 45
 neighbor 5.5.5.5 ebgp-multihop 2
 neighbor 5.5.5.5 update-source Loopback0

My question is, why do we need “ebgp-multihop 2” here? R2 and R4 are directly connected, R3 and R5 are directly connected.

Thanks.

lagapidis · August 18, 2019, 4:57am

Hello Jianxun

The reason why multihop is being used is because it is the loopback addresses that are the update source. This means that the loopbacks are actually two hops away from each other, even though the routers are directly connected. If the interface IP addresses were used as the update source, then no multihop command would be necessary.

You can find out more info about this at the following lesson:

In the link above, take a look at the second scenario which is similar to the situation in this lesson.

I hope this has been helpful!

Laz

ribeiro.luis · April 26, 2020, 5:02pm

Hi Rene,

Was there any particular reason to apply the route-map inbound on R2 instead of outbound on R1, like in the other lessons?

Thanks.

lagapidis · April 27, 2020, 10:30am

Hello Luis

Both configurations will actually work, the result is the same. However, in the real world, there are additional factors involved in deciding how to implement it. For example, AS 2345 may belong to you, but AS 1 may belong to another entity such as the ISP. This means that you will be unable to implement the set community local-AS command on R1, but on your R2.

Rene has used a variety of options (configuring outbound on R1 or configuring inbound on R2) to show that it can be done in various ways.

I hope this has been helpful!

Laz

jain.mukul2011 · May 3, 2020, 5:25pm

Hi Rene,

Can you please explain, Why have you introduced (192.168.12.0/24) network between R1 and R2 in OSPF neighborship configured on R2 router.When R1 and R2 is forming a EBGP neighborship with physical interface.

router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.23.0 0.0.0.255 area 0
 network 192.168.24.0 0.0.0.255 area 0
!

Regards
Mukul Jain

lagapidis · May 5, 2020, 5:44am

Hello Mukul

In the configurations in the lesson, the network 192.168.12.0 0.0.0.255 area 0 command is only found in R2 and not in R1. This means that an OSPF neighbor adjacency between R1 and R2 is not created. However, OSPF is aware of the 192.168.12.0 network and advertises it, and this is necessary for routers in AS 2345 to be able to find that network. Notice that in the BGP tables of the routers in AS 2345, they have an entry for network 1.1.1.1/32 with a next hop address of 192.168.12.1. This address cannot be routed to (and the topology would fail) unless it is included in the OSPF advertisements.

I hope this has been helpful!

Laz

anvesh199 · May 7, 2020, 6:43am

Hi Rene

A quick question, In case R1 wants to advertise the route to AS6 and through R3 would it be possible? May be add a community tag on R1 while advertising the route to R2 and then in R3-R6 peering match it with the community and advertise with no-export?

Regards
Sai