RFC 4271 NEXT_HOP Attribute 정의

The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the destinations listed in the UPDATE message.

  NEXT_HOP Attribute는 ORIGIN, AS_PATH Attribute와 마찬가지로 ‘Well-known mandatory attribute’이다. NEXT_HOP Attribute는 RFC 문서를 기준으로 기본 동작원리를 설명하고, 추후에 ‘Transit AS’를 설명 때 추가적인 부분을 자세히 설명하도록 하겠다.

  NEXT_HOP Attribute에는 당연히 해당 Network으로 Packet을 보내기 위해 어디로 보내야 하는지 정보가 들어있다.  그런데, IGP처럼 BGP는 NEXT_HOP이 Router를 거칠 때마다 변경되지 않는다. 그래서,  BGP는 NEXT_HOP Attribute의 값이 언제 어떻게 변경되는지 알아야 하는데 그 부분을 학습해 보도록 하자.

  먼저, NEXT_HOP Attribute는 IBGP로 Update하는 경우와 EBGP로 Update하는 경우의 규칙이 다르기 때문에 IBGP와 EBGP를 나누어서 설명하도록 하겠다. 먼저 IBGP 규칙을 확인해 보면 다음과 같다.

1. IBGP Neighbor에게 Update를 할 때, 자신이 광고한 Network이 아니면 NEXT_HOP Attribute를 변경하지 않는다.

  자신이 광고하지 않은 Network이란 다음의 경우를 말한다.

  • EBGP로 Update 받아서 IBGP로 Update 하는 Network
  • Route Reflector가 IBGP로 Update 받아서 다른 IBGP로 Update 하는 Network (Route Reflector는 추후에 설명하도록 하겠다.)

  위와 같은 경우에 BGP는 NEXT_HOP Attribute를 변경하지 않는다. 다음의 예를 통해 확인해 보자.

  ‘1.1.1.1/32’ Network를 R2와 R4에서 보면 모두 Next-hop이 ‘10.10.10.1’로 되어 있는 것을 확인할 수 있다. R2는 ‘1.1.1.1/32’ Network는 자신이 광고하지 않은 Network이기 때문에 그대로 전달한 것이다.

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

2. IBGP Neighbor에게 Update를 할 때, 자신이 광고한 Network은 IGP의 Next-hop 정보를 NEXT_HOP Attribute에 복사하여 전달한다.

  위 그림에서 ‘3.3.3.3/32’ Network를 R2에서 확인해 보자.

R2#show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Advertised by bgp 2
  Last update from 30.30.30.2 on GigabitEthernet3, 00:04:08 ago
  Routing Descriptor Blocks:
  * 30.30.30.2, from 3.3.3.3, 00:04:08 ago, via GigabitEthernet3
      Route metric is 2, traffic share count is 1

OSPF 1을 통해 ‘3.3.3.3/32’ Network 정보를 받았고 Next-hop이 ‘30.30.30.2’로 되어 있는 것을 확인할 수 있다. 이제 이 정보를 BGP로 광고후 R2에서 BGP의 Next-hop 정보를 확인해 보자.

R2(config)# router bgp 2
R2(config-router)# network 3.3.3.3 mask 255.255.255.255

R2#show ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 4
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  Refresh Epoch 1
  Local
    30.30.30.2 from 0.0.0.0 (2.2.2.2)
      Origin IGP, metric 2, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0

  OSPF의 Next-hop 정보인 ‘30.30.30.2’가 BGP database에도 Next-hop으로 저장되어 있는 것을 확인할 수 있다. 이 정보를 NEXT_HOP Attribute에 복사하여 R4에게 Update 한다,

R4#show ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 13
Paths: (1 available, best #1, table default, RIB-failure(17))
  Not advertised to any peer
  Refresh Epoch 1
  Local
    30.30.30.2 (metric 2) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 2, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

3. IBGP Neighbor에게 Update를 할 때, 자신이 최초로 광고하는 Network에 대해서는 자신의 IP address를 NEXT_HOP Attribute에 저장하여 전달한다.

  자신이 최초로 광고하는 Network 정보는 다음과 같다.

  • Direct Connect 정보를 BGP로 광고하는 경우
  • BGP Database에서 Aggregate-address 명령어를 사용하여 Summary Network을 생성한 경우

  먼저 R2와 Direct Connect 되어 있는 ‘2.2.2.2/32’ Network를 BGP로 광고하고, ‘1.1.1.1/32’ Network을 ‘1.1.0.0/16’ Netwrok으로 Summary 한 후 R2에서 Next-hop 정보를 확인해 보자.

R2(config)# router bgp 2
R2(config-router)# network 2.2.2.2 mask 255.255.255.255
R2(config-router)# aggregate-address 1.1.0.0 255.255.0.0

R2#show ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.2/32, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0

R2#show ip bgp 1.1.0.0
BGP routing table entry for 1.1.0.0/16, version 5
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  Refresh Epoch 1
  Local, (aggregated by 2 2.2.2.2)
    0.0.0.0 from 0.0.0.0 (2.2.2.2)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
      rx pathid: 0, tx pathid: 0x0

  R2에서 Next-hop 정보를 보면 Direct Connect Network과 Summary Network은 Next-hop 정보가 없기 때문에 ‘0.0.0.0’으로 설정되어 있는 것을 확인할 수 있다.

  이런 경우 해당 Network을 Update 할 때, Next-hop ‘0.0.0.0’을 그대로 전달 할 수 없다. 그래서, Next-hop이 없는 경우는 자신의 IP address를 NEXT_HOP Attribute에 설정하여 전달한다. R4에서 결과를 확인해 보자.

R4#show ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.2/32, version 12
Paths: (1 available, best #1, table default, RIB-failure(17))
  Not advertised to any peer
  Refresh Epoch 1
  Local
    2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
R4#show ip bgp 1.1.0.0
BGP routing table entry for 1.1.0.0/16, version 14
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local, (aggregated by 2 2.2.2.2)
    2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
      rx pathid: 0, tx pathid: 0x0

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.