BGP(Border Gateway Protocol) 라우팅의 기본 셋팅 및 peer 정보 확인 방법, 세부 정책 적용의 예시

오랜만에 BGP 셋팅하고 오니 기억이 새록새록;;;

네트웍 관리자로서 이러면 안되는데;;; ^^;;ㅋ

그래서!

오늘은 BGP 기본 셋팅 방법과,
peer 또는 neighber, adjacency 정보를 확인하는 방법을 알려드리도록 하겠습니다.

BGP는 Dynaminc Routing Protocol 중 하나로 Border Gateway 역할을 하고 있으며,

이 BGP 라우팅 프로토콜은 보통은 SP나 ISP간, 그리고 국제망 또는 대기업 등에서 소유하고 있는 BGP AS Number 로 연동을 하고 있습니다.

우선 BGP의 기본 셋팅을 한번 확인해 보도록 하겠습니다.

router bgp 11111
 no synchronization
 bgp log-neighbor-changes
 neighbor x.x.x.x remote-as 22222
 neighbor x.x.x.x description <<< ~~~~~ >>>
 neighbor x.x.x.x ebgp-multihop 10
 neighbor x.x.x.x update-source Loopback0
 neighbor x.x.x.x timers 10 30
 neighbor x.x.x.x soft-reconfiguration inbound
 neighbor x.x.x.x route-map ----- in
 neighbor x.x.x.x maximum-prefix 100
 neighbor x.x.x.x filter-list 106 in
 neighbor y.y.y.y remote-as 33333
 neighbor y.y.y.y description <<< ~~~~~ >>>
 neighbor y.y.y.y soft-reconfiguration inbound
 neighbor y.y.y.y route-map ----- in
 neighbor y.y.y.y filter-list 104 in
 neighbor z.z.z.z remote-as 11111
 neighbor z.z.z.z description << ~~~~~ >>
 neighbor z.z.z.z update-source Loopback0
 neighbor z.z.z.z next-hop-self
 neighbor z.z.z.z soft-reconfiguration inbound
 neighbor z.z.z.z filter-list 10 out
 no auto-summary
!

BGP가 셋팅된 라우터의 샘플 configuration 이며, 이 라우터가 소속한 그룹은 11111 의 AS-NUMBER 를 갖고 있습니다.

총 3개의 BGP peer를 맺고 있는데요,

z.z.z.z 의 neighbor 는 iBGP로, 동일한 AS에 속해 있는 라우터입니다.

x.x.x.x 와 y.y.y.y 2개의 neighbor 는 eBGP로 서로 다른 AS에 속해 있습니다.

위 그림을 참고하시면 되며, 우선 하나씩 설명해 드리도록 하겠습니다.

 no synchronization
 no auto-summary

이 2가지의 명령으로 auto-summary와 synchronization을 사용하지 않습니다.

BGP를 사용하고 있는 거의 모든 라우터들에 이 2개의 명령은 반드시 들어가 있습니다.

x.x.x.x 에 해당하는 BGP 셋팅으로, 기본적으로 x.x.x.x 에 대한 ping 응답이 있어야만 BGP peer 가 맺어지게 됩니다.

remote-as 명령으로 상대편 AS-NUMBER를 지정해 주며,

z.z.z.z 의 peer는 동일한 AS-NUMBER 를 셋팅해 줌으로 동일한 AS 내의 iBGP 임을 선언하게 됩니다.

neighbor x.x.x.x remote-as 22222
 neighbor x.x.x.x description <<< ~~~~~ >>>
 neighbor x.x.x.x ebgp-multihop 10
 neighbor x.x.x.x update-source Loopback0
 neighbor x.x.x.x timers 10 30
 neighbor x.x.x.x soft-reconfiguration inbound
 neighbor x.x.x.x route-map ----- in
 neighbor x.x.x.x maximum-prefix 100
 neighbor x.x.x.x filter-list 106 in

x.x.x.x 의 AS-NUMBER 22222 의 라우터와 BGP를 맺고 있는 모습이며, ebgp-multihop 으로 구성되어 있습니다.

나 자신의 Loopback ip로 업데이트 소스를 지정하며,

ebgp-multihop 특성상 다른 경로로의 우회를 차단하기 위해 timers 명령으로 hello 타임과 dead 타임을 지정해 줍니다.

soft-reconfiguration 명령으로 상대편 라우터에서 어떠한 BGP 테이블 정보의 변경이 있을 때 soft 하게 유동적으로 나의 라우팅 정보도 자동적으로 업데이트를 하게 됩니다.

maximum-prefix 명령으로 최대 수용 가능한 Prefix 개수를 제한하여 이상한 라우팅 정보가 업데이트 되는 것을 방지합니다. (이 경우는 100개를 지정함으로써 x.x.x.x 의 peer에서 100개 이상의 라우팅 정보를 넘겨주더라도 100개만 수용하게 됩니다)

route-map 명령으로 inbound 정책을 지정하고 있으며, route-map 으로 만들어진 정책은 아래부분에서 설명해 드리도록 하겠습니다.

filter-list 의 명령으로 해당 AS-NUMBER 인 22222 의 tag만 인정해 주어, 22222 에서 이상한 AS-NUMBER 정보가 넘어오지 못하도록 설정합니다. (filter-list 106 에서 그 정책을 지정해 놓았습니다)

 neighbor y.y.y.y remote-as 33333
 neighbor y.y.y.y description <<< ~~~~~ >>>
 neighbor y.y.y.y soft-reconfiguration inbound
 neighbor y.y.y.y route-map ----- in
 neighbor y.y.y.y filter-list 104 in

neighbor 33333 에 대한 config 입니다.

x.x.x.x 의 peer보다 다소 간단하게 셋팅되어 있으며, 이 경우는 ebgp-multihop이 아닌 direct-peer 구성으로 서로 1개의 홉으로 맞물려진 라우터간에 사용하게 됩니다.

soft-reconfiguration inbound 명령과 route-map 정책 및 filter-list를 이용하여 AS-NUMBER 33333 에 대한 정책을 지정하고 걸러주게 됩니다.

 neighbor z.z.z.z remote-as 11111
 neighbor z.z.z.z description << ~~~~~ >>
 neighbor z.z.z.z update-source Loopback0
 neighbor z.z.z.z next-hop-self
 neighbor z.z.z.z soft-reconfiguration inbound
 neighbor z.z.z.z filter-list 10 out

z.z.z.z 에 대한 peer는 동일한 AS-NUMBER 로 셋팅하여 iBGP 정보로 갱신하게 됩니다.

다른 셋팅은 모두 동일하며 next-hop-self 명령으로 next-hop 을 자신의 ip로 설정하여 줍니다.

보통 iBGP 에서 나의 정보를 전달할 next-hop을 설정할 때 사용하며, route-reflector 명령은 iBGP 에서 RRC로 만들어 Split Horizon 을 해결할 때 사용합니다.

이렇게 기본 셋팅 방법을 알아 보았습니다.

이제 BGP peer 정보를 확인하고 peer로부터 수신되는 BGP 라우팅 Prefix 를 확인하는 방법에 대해 알아보도록 하겠습니다.

BGP peer 의 정보를 요약하여 보여주는 명령입니다.

ROUTER#show ip bgp summ
BGP router identifier ?.?.?.?, local AS number 11111
BGP table version is 6787379, main routing table version 6787379
25297 network entries using 2858561 bytes of memory
50602 path entries using 2631304 bytes of memory
1476/1457 BGP path/bestpath attribute entries using 194832 bytes of memory
21 BGP rrinfo entries using 504 bytes of memory
1190 BGP AS-PATH entries using 29796 bytes of memory
31 BGP community entries using 744 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
1455 BGP filter-list cache entries using 17460 bytes of memory
BGP using 5733201 total bytes of memory
118 received paths for inbound soft reconfiguration
BGP activity 229491/204194 prefixes, 1419904/1369302 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
x.x.x.x     4 22222 6585830 7273559  6787379    0    0 14w6d          37
y.y.y.y     4 33333 5715355 7234032  6787379    0    0 14w6d          59
z.z.z.z     4 11111 2079065 1099806  6787379    0    0 1y44w       25183
ROUTER#

x.x.x.x 의 neighbor (AS22222) 로 부터 수신되는 Prefix 개수는 37개 이이며,
y.y.y.y 의 neighbor (AS33333) 로 부터 수신되는 Prefix 개수는 59개 이이며,
z.z.z.z 의 neighbor (AS11111) 로 부터 수신되는 Prefix 개수는 25183개가 됩니다.

모두 현재 가장 많이 사용되고 있는 BGP v4 로 연동되고 있습니다.

x.x.x.x 와 y.y.y.y 의 경우에는 보통의 데이터센터, MSO, 대기업 또는 관공서 등 AS-NUMBER 를 소유하고 있는 곳이 되며,
x.x.x.x 의 경우에는 iBGP로, Prefix 개수가 많은 이유는 국내 BGP Prefix 의 정보를 모두 갖고 있기 때문입니다.

보통은 SP 또는 ISP 에서 각 지사간, 또는 각 센터별로 iBGP 연동 시 사용하게 됩니다.

ROUTER#show ip bgp neighbors x.x.x.x received-routes
BGP table version is 6787466, local router ID is ?.?.?.?
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
*  123.456.789.0/24   x.x.x.x              0             0 22222 i
*  123.456.789.0/24   x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
r  123.456.789.0/24  x.x.x.x              2             0 22222 22222 22222 22222 22222 22222 ?
r  123.456.789.0/24  x.x.x.x              2             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.789.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 ?
*  123.456.81.0/24   x.x.x.x              0             0 22222 i
*  123.456.82.0/24   x.x.x.x              0             0 22222 i
*  123.456.83.0/24   x.x.x.x              0             0 22222 i
*  123.456.84.0/24   x.x.x.x              0             0 22222 i
*  123.456.85.0/24   x.x.x.x              0             0 22222 i
*  123.456.86.0/24   x.x.x.x              0             0 22222 i
*  123.456.87.0/24   x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 i
*  123.456.88.0/24   x.x.x.x              0             0 22222 i
*  123.456.89.0/24   x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 i
*  123.456.90.0/24   x.x.x.x              0             0 22222 i
*  123.456.91.0/24   x.x.x.x              0             0 22222 i
r  123.456.94.0/24   x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 i
*  123.456.95.0/24   x.x.x.x              0             0 22222 i
*  123.456.189.0/24 x.x.x.x              0             0 22222 i
*  123.456.113.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 i
*  123.456.114.0/24  x.x.x.x              0             0 22222 i
*  123.456.115.0/24  x.x.x.x              0             0 22222 i
*  123.456.116.0/24  x.x.x.x              0             0 22222 i
*  123.456.117.0/24  x.x.x.x              0             0 22222 22222 22222 22222 22222 22222 i
*  123.456.118.0/24  x.x.x.x              0             0 22222 i

 Total number of prefixes 37
ROUTER#

명령어에 포함된 neighbor 로 부터 수신되는 recevied-route 정보를 보는 명령입니다.

routes 명령과 동일한 기능을 수행하지만 계산되지 않는 정보를 보여주고 있습니다.
(advertise-route 명령은 neighbor 에게 광고하는 BGP Prefix 의 수를 표시하여 줍니다)

위의 summary 의 명령으로 확인한 37개의 BGP Prefix 정보를 세부적으로 보여주고 있으며, AS 22222 에서 던져주는 정책의 세부사항을 볼 수가 있습니다.

뒤에 22222 i 가 되지 않고, 22222 22222 22222 22222 22222 i 가 붙는 이유는 AS 22222 내부적인 정책으로 AS-PATH Prepend 를 적용하였기 때문이며, 이러할 때 유입되는 BGP의 경로 우선순위는 낮아지게 됩니다.

BGP path 의 최적 알고리즘 선정에 대해서는 이 링크를 참고하시기 바랍니다.

-----

이제 위에서 설명드리지 못한 route-map 셋팅과 filter-list 에 대해 설명해 드리도록 하겠습니다.

위의 x.x.x.x 에 대한 경우를 예로 들어보도록 하겠습니다.

neighbor x.x.x.x remote-as 22222
 neighbor x.x.x.x description <<< ~~~~~ >>>
 neighbor x.x.x.x ebgp-multihop 10
 neighbor x.x.x.x update-source Loopback0
 neighbor x.x.x.x timers 10 30
 neighbor x.x.x.x soft-reconfiguration inbound
 neighbor x.x.x.x route-map ----- in
 neighbor x.x.x.x maximum-prefix 100
 neighbor x.x.x.x filter-list 106 in
!
route-map ----- permit 10
 match as-path 106
 set local-preference 300
!
ip as-path access-list 106 permit ^(22222_)+$

ip as-path access-list 를 이용하여 AS-NUMBER 22222 에 해당하는 PATH 경로만을 수용하기 위해 as-path ACLs 106번을 만든 후 inbound 방향으로 filter-list 를 적용하였습니다.

route-map 을 하나 만들어 AS-NUMBER가 22222 인 as-path access-list 106에 해당될 때, BGP 경로 알고리즘의 2순위인 Local-preference 값을 고정시키키기 위해 inbound 방향으로 route-map을 적용하였습니다.

Local-preference 를 지정하는 이유는 수많은 iBGP 경로 중 다른 경로가 있을 만한 이유는 없겠지만, 다른 경로가 있다고 하더라도 나의 경로가 1순위가 되도록 지정하는 것입니다.

보통은 300 정도의 값을 지정하게 되지만 내부 정책에 따라 이 수치는 틀려질 수 있습니다.

이러한 filter-list 와 route-map 등을 사용할 때에는 in/out 방향을 명확하게 한 후 적용을 해야 합니다.

예를 하나 들어 보겠습니다.

보통의 MSO 에서는 내부 정책 및 계약 조전에 따라 트래픽 양을 조절하게 됩니다.

이 때에도 역시 route-map을 이용하여 조절하게 되며, 위에 말씀드렸던 22222 22222 22222 ~~~ i 등의 정책으로 그 양을 인위적으로 조절할 수가 있습니다.

정책을 선언한 후 outbound 방향으로 정책을 적용하였을 때 inbound 트래픽양에 관여하게 됩니다.

BGP 관리자들이 가장 헷갈려하는 부분으로, 반대 개념으로 생각하고 정책을 적용하게 되면 무리가 없을 듯 합니다.

이것 또한 BGP path 의 최적 알고리즘 선정에 준하게 됩니다.


-----

보통은 SP나 ISP에서 각 회사의 정책에 맞추어 필터링 또는 옵션을 추가하는데요,

이 때 사용되는 BGP 정규식 (Regular Expression)은 이 링크에서 참고하시기 바랍니다.

이러한 정규식과 ACLs, 그리고 class-map, route-map 등을 이용하여 정책을 추가/수정하게 됩니다.

-----

BGP 의 AD값은 External BGP가 '20', Internal BGP가 '200' 으로 각각 지정되어 있습니다.

라우팅 프로토콜의 AD값은 이 링크를 참고하시기 바랍니다.

-----

들러주셔서 감사합니다 (__)