BGP Community Local AS

(Rene Molenaar) #1

This topic is to discuss the following lesson:

(Mario R) #2

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?

(Rene Molenaar) #3

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 S) #4

Excellent topic! Thank you Rene!

(Mohammed F) #5

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.

(Rene Molenaar) #6

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

(LER-SAK P) #7

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, > 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       0.0.0.0                  0         32768 i
*> 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, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>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
*>                  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, > 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
*> 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, > 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
*>i                 5.5.5.5                  0    100      0 (45) i
*>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.

(Rene Molenaar) #8

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

(LER-SAK P) #9

Hi Rene,

Thank you so much.

(Staut S) #11

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

(Rene Molenaar) #12

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

1 Like
(William N) #13

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

(Lazaros Agapides) #14

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