이는 명백해 보이지만, 제공자가
당신을 위해 해야 하도록 되어 있는 두 가지 일이 있다: (1)인터넷(internet)에서
당신의 네트웍(network)으로 데이터를 가져오는 것과 (2)당신의
네트웍에서 인터넷으로 데이터를 가져가는 것이다.
#1에 대해서: 제공자가 데이터를 가져오기
제공자들은 서로 경로를 교환한다. 경로는
IP 주소 공간의 부분에 대한 설명과 그 IP 주소 공간 에 대한 “데이터를
받아들이겠다는 약속”이다.
어떻게 네트웍의 어떤 지역의 사람이 당신에게
데이터를 보낼까? 그들은 그들의 제공자에게 패킷(packet)을 보낸다.
당신이 그들과 다른 제공자를 사용하고 있다면, 그들의 제공자는
당신의 제공자에게 패킷을 보낸다. 이 과정은 그 두 제공자 사이에서
이루어진 “경로 공지(announcement)”에 기초 한다.
그래서 나가는(outgoing) 경로 공지는 데이터를
당신의 네트웍으로 인도한다.
제공자가 당신의 경로를 내부 경로 테이블과
외부 경로 공지 테이블에 넣거나, 당신이 경로를 제공자에게 공지하고
그 후 그 경로들이 내부와 외부 경로 공지 테이블에 들어간다. 물론,
만약 제공자로부터 당신의 IP 주소 공간을 얻을 수 있다면, 당신의
하위 경로를 인터넷에 공지하지 않아도 된다.
#2에 대해서: 인터넷에 데이터 보내기
내부 네트웍이 아닌 외부 네트웍으로 보내야
하는 패킷을 하나 만들었다. 어디로 보내야 하는가? 제공자 중의
하나로 보내야 한다. 어떻게 그 결정을 하는가? 당신의 “경계 라우터(border
router)”에는 한 경로가 있다.
기본(default) 경로: 만약 기본 경로가 있다면
(또는 0.0.0.0 경로로 쓰여진다), 제공자와 관계가 없는 모든 데이터를
보낸다. 기능성 멀티-호밍을 할 때도, 여전히 이렇게 하려 할 지도
모른다.
제공자에게서 경로 가져오기: 만약 하나의
제공자가 있다면, 모든 인터넷 주소(95/12/15에 약 32,000개)를
가져올 수 있다. 이 글은 16mb Cisco 2500 계열 라우터에 맞춰져
있다. 만약 단지 하나의 제공자만 있다면 어떻게 하겠는가? 그것은
그 제공자를 기본 제공자로 설정한 것과 같은 효과를 준다.
간단한 설명 1: 만약 단일(single)-호밍의
경우?
일반적인 설정:
제공자는 네트웍에 대한
모든 경로를 정적으로(statically) 추가한다. 이는 만약 당신에게
즉시 다시 번호를 매길지를 확신할 수 없는 “C등급의 유산”을
가진 고객이 있다면, 제공자에게 당신에 대한 경로를 추가해 달라고
요청해야 한다는 것을 의미한다.
제공자에 기본 경로를 설정한다.
int e0 ip add [local_ip_adx] [local_ip_mask]
int s0 ip add [local_t1_adx] 255.255.255.252
ip route 0.0.0.0
s0
노트: 대개 마스크는 255.255.255.252이다.
이는 IP 주소 공간을 보존하기(conserve) 위한 것이다.
약간 더 바람직한 설정:
당신의 경로를
제공자에게 공지하기 위해서 BGP를 이용한다. 이 방법으로 당신은
NOC나 당신 대신 해주는 “경로 부서”에 연락하지 않고도 경로를
추가할 수 있다. 만약 계속적으로(또는 언제나, 때때로) 요청하면,
당신의 경로 공지에 필터 목록을 놓거나 또는 정적 경로로 바꿔
줄 것을 기대할 수도 있다. (노트: 우리는 BGP 고객들이 우리에게
공지할 수 있는 경로에 대한 목록을 만들었다. 이는 그들이 우리에게
잘못된 경로를 주는 것을 방지하기 위해...)
제공자에 기본 경로를 설정한다.
int e0
ip add [local_ip_adx] [local_ip_mask]
int s0
ip add [local_t1_adx] 255.255.255.252
router
bgp [your-asn]
network [net1]
network [net2] mask 255.255.254.0
network [net3] mask 255.255.252.0
neighbor [remote_t1_adx]
remote-as [provider-as]
ip route 0.0.0.0 s0
ip route
[net1] dest1
ip route [net2] 255.255.254.0 dest2
ip
route [net3] 255.255.252.0 dest3
노트: 이 방법은 엉뚱한 경로가 끼여들 수
없는 것을 보장한다. 그러나 그것은 단 하나의 제공자를 가지고
있을 경우에만 일 것이다.
BGP 노트:
만약 제공자가 하나만 있다해도, 큰 걱정을
할 것은 없다. 만약 제공자가 여러 개 있다면, 잘못된 경로(또는
모든 네트웍에 대한 경로)를 공지하지 않도록 주의를 해야만 한다.
제공자들을 대개 외부의 경로로 보이는 경로 상의 고객 경로를 신뢰하도록
설정이 되어 있다. 그래서 만약 MCI 경로를 UUNET으로 공지하면,
UUNET은 MCI에서 MCI로 보내는 지역 데이터 모두를 MCI T1로 보낼
것이다!!! 만약 이중(dual)-호밍을 사용하지 않는다면 걱정할 필요는
없다.
간단한 설명 2: 만약 이중(dual)-호밍의
경우?
들어오는 데이터 (나가는 경로 공지)
일반적인 설정:
경로를 공지하기 위해
제공자 둘 다에게 BGP를 이용하여 알린다.
무슨 동작을 하는가:
제공자에게 BGP를 이용해야만 하는 이유는 전혀 없다. 제공자들은
정적으로 당신의 경로를 추가할 수 있지만, 기본 가정은 다음과
같은 이유로 당신이 BGP를 이용하기를 원할 것이다:
(1)더
지능적인 경로 설정에 대한 결정을 하기 위해 제공자로부터의 완전한
경로를 가져올 수 있기를 원하거나/원하고
(2)대인 관계없이
경로를 추가할 수 있기를 원 한다.
나가는 데이터 (들어오는
경로 공지와/또는 기본 경로)
방법1: 기본 경로만: 같은 가중치
제공자에 대한 많은 인터페이스(interface)를
사용하거나 당신의 “직렬 단말”(serial end)에서 같은 지역 IP를
사용할 경우. 이 때, 두 제공자는 당신의 단말에 있는 같은 라우터(router)상에
있다는 것을 가정한다. 같은 가중치로 두 라우터에 기본값을 설정하기만
하면 된다. 두 직렬 회선에 ‘ip route-cache’를 설정한다.
이는 당신이 하나 또는 두 제공자에 대해
BGP를 이용하면서도 가능하지만, 만약 BGP를 이용하고 있다면 아마도
“고객 경로”(customer route)를 가져오기를 원할 것이다. (방법3을
보아라.)
물론, 나가는 경로 공지에 대해서 BGP를 이용하기를
원한다면, 모든 들어오는(incoming) 경로를 걸러 내면 이 방법으로
1MB Cisco 2501에서 조차도 멀티-호밍을 할 수 있다는 것을 알 수
있을 것이다.
▲ top
방법2: 기본 경로만: 하나는 백업
각 제공자에 대해서 하나씩, 두 개의 기본
경로를 가지고 있다. 그러나 하나는 더 낮은 가중치를 가지고 있어서
주 제공자에 대한 연결이 끊어졌을 경우에만 동작을 한다. (노트:
Cisco에서는 경로(기본 경로도 포함하여)는 연결된 인터페이스가
문제가 있는 경우에 사라진다.)
이는 한 제공자가 성능이 좋지 않고 보조
접속이 큰 대역폭(bandwidth)을 필요로 하지 않을 때, 효과가 있을
것이다.
방법3: 각 제공자로부터 “고객 경로” 가져오기
두 제공자에 대해 BGP를 이용한다. 제공자
X로부터 그리고 제공자 Y로부터 모든 제공자 X의 고객 경로를 가져온다.
그 후, 같은 가중치로 두 제공자에 기본 경로를 설정하거나, 하나에는
기본 경로를 다른 하나에는 백업 기본 경로를 설정하면 된다. 이는
16MB 2501에서 확실히 동작할 것이다.
방법4: 각 제공자로부터 “완전 경로” 가져오기
두 제공자에 대해 BGP를 이용한다. 각 제공자에서
모든 것에 대한 경로를 모두 가져온다. 이는 16MB 2501에 맞을 것
같지만, 아마도 동작하지 않을 것이다. Morningstar/gated나 PC/gated로서
32MB 4000이나 4500이 좋을 것이다. 이 설정을 이용하여, 기본 경로
없이 운영할 수 있다 - 기본 경로가 없이, 네트웍의 모든 접속 사이트(site)에
대한 완전한 경로를 가지고 있기 때문에. 그러나 만약 하나 또는
두 제공자가 꼬이게 되어 완전한 경로를 제공할 수 없다면, 기본
경로가 없기 때문에 접속을 할 수 없을 것이기 때문에, 이런 방법으로
할 필요는 없다. 완전 경로를 가져오면서 기본 경로를 설정하는
것은 아무런 문제가 없다.
방법5: 창조적인 경로-균형 방법 balancing
이는 방법3과 방법4의 중간 정도의 방법이다.
두 제공자에 대해 BGP를 이용한다. 각 제공자에게 “고객 경로”를
가져온다. 그 후, 인터넷을 키 운송(key transit) 제공자의 AS로
나눈다:
·MCI (AS3561)
·Sprint (AS1239)
·ANS
(AS690)
·UUNET (AS701)
·PSI (AS174)
·Net99
(AS3830)
·AGIS (AS4200)
이 숫자들은 당신의 것과 다를 지도 모른다!
맞는 지는 당신의 경로 테이블을 확인해 보아야만 한다. (ftp.uu.net,
ftp.psi.com, ftp.sprintlink.net 등에 대한 AS-경로를 본다.)
그 후, 단지 제공자A에서 MCI 경로의 것을,
제공자B에서 Sprint 경로의 데이터를 받기를 결정한다. 또는 당신이
원하는 바대로. 어떤 제공자로 부터 어떤 경로의 데이터를 받을
지에 대한 균형을 잡는 것은 평균 이용률의 균형을 유지하는 것이다.
두 제공자에 기본 경로를 같은 가중치로 또는 하나는 주, 하나는
보조로 추가하라.
terry@spcvxb.spc.edu Terry Kennedy,
Operations Mgr. at St. Peter’s College, US
In article <1995Dec18.164944.1@hujicc>,
yehavi@vms.huji.ac.il (Yehavi Bourvine (58-4279)) writes:
· 하나의 ISP는 곧 NAP에 직접 연결된 두
ISP에 대한 이중-호밍이 될 것이다.
· 질문은 어떤 라우터를
이용해야 하는 것인가 이다: 32MB의 4500또는 64MB의 7010. 내 주요
관심사는 경로 테이블(완전 BGP 테이블)과 그에 사용될 메모리 양이다.
· 테이블의 앞으로의 크기를 예상할 때, 4500은 충분한 여유
메모리를 가지고 있는 것인가? 또는 안전하게 64MB의 7010을 선택해야
하는가? 7000과 7500은 당연히 가격 문제도 있다.
이 질문에
대해서는 의도와는 좀 다른 답이 있다. 난 CIX 라우터로부터 받아
낸 숫자들을 포스팅했었고, 사람들은 내게 “CIX 라우터는 많은
경로를 걸러 내서 완전 경로를 이용하는데 문제가 있을 것이다.”라고
말했다.
하지만, 난 어쨌든지 그것을 해냈다. 난 주
메모리 32MB와 입출력 메모리 16MB의 4500을 사용하고 있다. 그것은
Sprint와 Alternet에 이중 연결을 하고 있고 완전 경로를 유지하고
있다. 다음은 sh ip bgp sum과 sh mem의 결과이다.
router>sh ip bgp sum
BGP table version
is 2436598, main routing table version 2436598
32175 network
entries (61909/64360 paths) using 5679608 bytes of memory
3550 BGP path attribute entries using 413828 bytes of memory
0 BGP route-map cache entries using 0 bytes fo memory
5246
BGP filter-list cache entries using 83936 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ
OutQ Up/Down State
xxx.xxx.xxx.xxx 4 701 432288 20337 2436532
0 0 2d13
xxx.xxx.xxx.xxx 4 1239 411988 20314 2436532 0 0
1w6d
xxx.xxx.xxx.xxx 4 xxxx 19984 19978 2436532 0 0 3d04
xxx.xxx.xxx.xxx 4 xxxx 20222 19979 2436532 0 0 4d23
xxx.xxx.xxx.xxx
4 xxxx 19512 19881 2436532 0 0 2d17
router>sh mem
Head FreeList
Total(b) Used(b) Free(b) Largest(b)
Processor60508B40 604ACA78
28275904 15935728 12370176 11647024
I/O400 00000 604AD78C
16777216 1842080 14935136 14877616
Terry Kennedy Operations Manager, Academic
Computing
terry@spcvxa.spc.edu St. Peter's College, Jersey
City, NJ USA
+1 201 915 9381 (voice) +1 201 435-3662 (FAX)
