BGP 피어 세션 만들기하나의 AS 안에는 여러개의 BGP 라우터가 존재할 수 있다. 외부 AS 에 직접 연결된 BGP 를 EBGP 라고 부르고, AS 내부에서 BGP 라우터간 BGP 연결을 IBGP 라고 부른다.
EBGP 인지, IBGP 인지는 OPEN 메시지내 AS 번호를 이용해 구분하게 된다.
EBGP 는 반드시 물리적으로 직접 연결이 되어 있어야 한다. BGP가 아닌 라우터를 중간에 둘 경우에는 루프나 블랙홀이 생길 수 있으므로 복잡한 설정이 필요하다.
IBGP 는 중간에 여러개의 내부 라우터가 존재하는 간접 연결도 가능하다.
라우터에는 여러개의 인터페이스가 있으며 각기 주소가 설정되어 있다.
아무것나 사용해도 되나 가능하면 안정된 하드웨어를 사용하는게 좋다. 불안한 하드웨어를 사용하면 접속이 끊어졌다 다시 붙었다하는 현상이 생길 수 있다. 시스코 라우터는 가상 인터페이스를 둬서 물리적인 인터페이스의 고장 여부에 상관없이 작동된다
라우터는
EBGP 를 통해 받은 루트 정보는 다른 라우터로 전달하지만IBGP 로 받은 루트 정보는 전달하지 않는다. R(a), R(b), R(c) 3개의 라우터가 있을때
R(a) - R(b) - R(c) 선형으로 연결하면
R(a)에 EBGP로 들어온 루트 정보는 IBGP 로 통해 R(b) 에 전달되지만
R(b)는 IBGP로 들어온 루트 정보를 다시 보내지 않으므로
R(c)는 R(a) 의 외부로 연결된 루트를 알지 못하게 된다
즉,
AS내 BGP 들은 서로 모두 접속되어있는
풀메쉬(Full-mesh) 구조로 연결이 되어있어야 한다
BGP 간 동기화 문제같은 AS 내 외부로 연결된 R(a) 와 R(d)가 있고 그 사이를 R(b) 와 R(c)가 연결되어 있다.
R(a) 에서 R(d) 로 가는 패킷이 있을 경우
R(a) 는 R(b) 로 보내고
R(b) 는 R(c) 로 보내고
R(c) 는 R(d) 로 보내야 한다
하지만 R(b) 와 R(c) 는
내부 라우터라 패킷을 어디에 보낼지 모르므로
R(b) -> R(c) 를 디폴트로 처리하고
R(c) -> R(d) 를 디폴트 처리해야한다
이렇게 패킷 전송은 가능한지만 R(d) 에서 R(a)로 응답을 보내야 할 경우
R(c) 는 디폴트 설정이라 무조건 R(d) 로 보내므로 루프 현상이 발생하게 된다
이런 현상을 막기 위해 R(b) 와 R(c) 가 디폴트 처리할때는
되돌아 가는 루트를 확보해줘야 한다.
루트 확보를 자동으로 하기 위해 BGP 데몬의 루트 정보를 RIP 에 인젝팅 하는 방법도 있지만
BGP 라우팅 테이블은 규모가 매우 커서 내부 라우터의 부하가 너무 커지기 때문에
좋은 방법은 아니다.
라우팅 업데이트의 소스 문제소스란 누가 제일 처음 업데이트 메시지를 주었는가이다.
소스를 파악하는 것은 라우팅의 정확도(accuracy)와 안정성(stability)를 위해 중요하다.
BGP 는 소스가 누군지 알고 있지만
IGP 는 소스를 모른다
BGP 를 통해 AS내로 들어온 루트가 있다
루트를 IGP 를 통해 전달할 경우 소스 정보는 사라진다.
IGP 를 통해 전달된 루트가 다시 AS 밖으로 나갈때는 다시 소스가 필요한데,
소스가 없다면 자동으로 현재 AS 로 설정된다.
BGP에 잘못된 소스 정보를 사용하는걸 막기 위해서는
소스가 남아 있는 IBGP 를 통해서 루트 정보를 전달해야한다.
시스코 라우터는 BGP 로 받은 걸 다시 AS 외부로 내보내지 않는 식으로 문제를 해결하고 있다.
결론
IGP 를 통해 받은 루트 정보를 BGP 로 올리면 많은 문제가 생기므로
BGP 는 가능하면 스태틱하게 설정한다.
굳이 자동화 할경우에는 Network 커맨드를 사용하게 된다.
Network 는 특정 네트워크 주소가 자기 AS 임을 알려주는 명령이다.
자동화된 BGP 테이블내 엔트리에는 BGP Origin Type 이 설정되는데
근원을 모르는 것은 INCOMPLETE
BGP 를 통해 들어와 소스를 알 수 있는건 EGP
Network 명령으로 설정된건 IGP 로 표시된다
(
0)
(
0)
http://imp17.com/tc/myevan/trackback/163
python 을 좋아하는 게임 프로그래머
