[화웨이] 네트워크 과제 2 - Static route 과제

개요

1편에서 기본적인 설명과 명령어를 적었으니 이제 과제를 진행해 보자.

 

과제의 내용은 다음과 같다

 

1 - 2 - 3 - 4

 ＼ ／         |

    5          6

 

기본 연결은 1-2-3-4-6

5번은 백업으로 1-5-3으로 연결되어 있음

6번은 default routing을 4번으로 넘겨줌

1. static 만 사용해서 전체 장비끼리 핑이 되어야 함(루프백 포함)
2. 평상시에는 늘 1-2-3 끼리 통신하고 5번은 사용하지 않음
3. 1-2 라인 단절 시 3-5-1로 통신하도록 BFD 백업 설정

• 탭 사용하지 않고 전체 명령어를 반드시 직접 입력할 것

 

과제 설명

말 그대로 다른 라우팅 프로토콜을 사용하지 않고 static 만을 사용해서 전체 장비를 연결하는 과제이다.

 

거기에 백업과 디폴트 라우팅이 추가되었는데, 6번의 디폴트 라우팅은 6번과 연결된 장비가 4번뿐이니 상단 장비로 데이터를 넘겨준다고 생각하면 되고, 백업은 BFD를 이용하기로 한다.

 

탭을 사용하지 말라는 뜻은 화웨이 OS에 적응해 나가는 과제에서 명령어를 익히라는 의미로 주어진 것으로, 과제에서는 탭 만을 명시했지만 화살표 위아래 키를 이용하여 히스토리를 가져오는 것도 가급적 사용하지 않았다.

 

 

토폴로지 구성

 

토폴로지를 그린 다음 각 장비에 호스트네임과 아이피를 입력해 준다. 이전 편에서 언급한 설정들이므로 설정하는 부분은 생략

 

 

스태틱 라우팅 설정

 

2번 장비로 보면, 특정 루프백과 인터페이스를 가려면 어떻게 설정해야 하는지를 지정해준다. 이건 말그대로 어딜 가려면 어떤 장비를 거쳐야하는지, 그 장비에는 어떤 설정이 들어가있어야하는지를 설정해야하는 부분이므로 하나씩 설정하면서 ping을 테스트하다 보면 자연스럽게 전부 구성할 수 있게 된다.

 

 

6번 장비에서는 4번 장비가 반드시 상단이며, 따로 하단에 추가로 다른 장비나 단말기가 있는 게 아니기 때문에 default routing 만 설정해 주면 된다. 

 

백업(BFD) 설정

BFD는 Bidirectional Forwarding Detection(양방향 전달 감지)라는 의미로 두 장비 간에 Echo(Hello-like) 패킷을 주고받으면서 일정 시간 안에 응답이 없으면 연결이 끊어진 것으로 간주하는 프로토콜이다. 따라서 설정을 할 때 양쪽 장비에 정확하게 설정해 줘야 동작한다. 특히 static route 에도 BFD 관련 설정을 넣어줘야 한다.

 

 

bfd <1, 로컬 세션 이름> bind peer-ip <20.1.1.1, 감시할 아이피> source-ip <20.1.1.2, 패킷의 출발지 ip>

discriminator local <12, 내가 사용할 판별자 id>

discriminator remote <11, 상대측 판별자 id>

commit 

 

출처 : https://support.huawei.com/enterprise/en/doc/EDOC1100112356/b77662d3/example-for-configuring-multi-hop-bfd

 

bfd의 세션 이름은 이 장비에서 여러 개의 bfd를 설정할 때 구별하기 위한 id이다. 따라서 해당 이름은 다른 장비에 전달하지 않기 때문에 위의 공식 예제처럼 각 장비별로 다른 이름을 사용해도 상관없다.

 

각 장비에서 bfd 패킷을 식별하기 위한 값은 discriminator (판별자. GAN에서 generator와 사용하는 그 discriminator와 스펠링이 같다)이다. 따라서 local과 remote 값을 서로 정확하게 매칭해야 동작한다.

 

commit 은 말 그대로 commit이다. 현재 bfd 설정을 완료할 때에 commit을 입력해야 세션이 활성화된다.

 

양쪽 장비의 discriminator와 peer-ip를 정확하게 매칭했다면 dis bfd session all 명령으로 State 가 Up으로 나오는 걸 확인할 수 있다.

 

 

ip route-static 1.1.1.1 255.255.255.255 20.1.1.1 track bfd-session 1
ip route-static 1.1.1.1 255.255.255.255 20.1.1.6 preference 200

기존에 static 설정을 해둔 상태라면 Info: Succeeded in modifying route.라고 나오면서 설정이 업데이트된다.

 

static 설정에서 track bfd-session 명령어로 아까 만든 bfd session 이름과 매핑한다. 그리고 대체 경로를 preference 200으로 설정해 주면 bfd-session 1의 session state 가 Up 이 아닐 때에는 기존 경로가 죽고 대체 경로가 활성화된다.

 

 

테스트

 

우선 기본 static 설정에서 전체 핑이 잘 되는지를 확인한다. 1번 장비에서 2~6번 장비까지 전체 핑이 문제없이 진행되는지 확인한 뒤, tracert 명령어를 사용하여 3번 장비로 나가는 경로가 늘 일정하게 2번 장비 거쳐서 3번으로 가는지도 확인한다. (스크린샷은 없지만 다른 장비도 확인한다)

 

 

그다음 1-2 장비 간 인터페이스를 제거한 다음 bfd session 이 down으로 전환됐는지 확인한다.

 

 

전체 장비가 핑이 잘 나가는지 확인하고 tracert로 우회해서 잘 넘어가는지 확인한다.

 

 

그다음 장비를 다시 연결해준다음 bfd session 확인해 주고 정상적으로 연결돼서 bfd session 이 끊기기 전처럼 동작하는지 확인하면 테스트 완료.

 

 

버그 내역

 1-2 단절 후 1 -> 3은 핑이 잘 나가는데 3 -> 1 은 핑이 안 나가는 현상이 있었음

 -> 1번 장비 설정에 해당 라우팅 추가
 - 기존에 얘기했듯이 ping 명령어는 -a 옵션 없이 사용하면, 라우팅 테이블에 따라 자동으로 선택된 인터페이스의 IP 주소를 출발지 IP로 사용한다. 그런데 3번 장비에서 보낸 ping이 1번 장비에 도달했으나, 1번 장비에서 응답을 되돌릴 경로(즉, 3번과 연결된 5번 인터페이스에 대한 경로)가 설정되어 있지 않았기 때문에 응답 패킷이 전송되지 못한 것으로 보인다.

 
 1-2 단절 후 재 연결 시 3->2->1 경로가 되살아나지 않는 증상

 -> 3번 장비에서 static routing의 1-2 인터페이스 백업 설정 제거
 - 3번 장비에서 1번 장비로 가는 경로를 BFD로 감시하면서, 해당 경로에 static route의 backup 설정을 동시에 적용한 경우, BFD가 복구되어도 우선순위 낮은 백업 경로가 여전히 유지되어 원래 경로로 복구되지 않는 문제가 발생했다. BFD 세션이 정상으로 복구되더라도, static route가 다시 primary route로 되돌아오지 않는 증상이 있었는데, 이는 track과 연동된 route 설정이 양쪽에 모두 제대로 적용되지 않거나, BFD session이 실제로 up 되었어도 track 상태 반영에 지연이 있었던 것으로 보인다.

 1-2 물리 단절 시 3번 장비 라우팅 테이블이 변경이 되지 않는 증상
 -> 3번 장비 스태틱 설정에 track 설정 추가

 - 3번 장비에서 BFD 세션은 정상적으로 설정되었으나, 해당 세션을 참조하는 static route에 track bfd-session 설정이 누락되어 있어, 링크 단절 시 라우팅 테이블이 자동으로 변경되지 않았다.