- GNS와 GNS(다른 PC) 연동
- rip 네트워크를 추가 해준다.
다른 pc와 연결된 것을 확인할 수 있다.
GNS와 VMware 연동
OSPF 특징
빅데이터 인공지능 openstack ssl 해킹
1. Link-state 프로토콜
2. 현재 사용되는 버전은 2
3. 프로토콜 번호 89번을 사용
4. Classless 라우팅 프로토콜을 지원 (VLSM,CIDR 등, 지원)
5. 수렴시간이 빠르고, Multicast를 이용
6. AD값 - 110
<장점>
- area 단위로 구성되어 있어 특정 에이리어에서 정보가 다른 에이리어로 전송되지 않아 안정되게 운영할 수 있다.
- stub 이라는 축약 기능이 있다
- 대부분 라우터에서 사용이 가능하다
<단점>
- 설정이 다른 라우팅 프로토콜보다 까다롭다.
- 라우팅 정보 계산&유지를 위해 CPU,DRAM 자원을 꽤 많이 사용한다.
OSPF 네트워크 분류
- 브로드캐스트 네트워크
- 포인트 투 포인트 네트워크
- 포인트 투 멀티 포인트 네트워크
- 논브로드캐스트 네트워크
라우팅 네트워크 종류
1. broadcast multi-access Network
2. NBMA Network ( Non-broadcast multi access )
3. Point-to-Point
- OSPF 패킷
- OSPF가 설정된 인접한 라우터간 네이버 관계를 형성하고 네이버 관계를 유지하는데 사용.
OSPF 패킷은 라우터ID, area ID, 인증 암호, 서브넷 마스크, hello 주기, dead 주기, stub area flag, 라우터 Priority, DR, BDR,네이버 리스트의 정보를 담고 있다.
1. DBD (DDP)
- OSPF의 네트워크 정보를 LSA(Link state advertisement)라고 부르는데 OSPF는 자신이 만든 LSA와 네이버에게서
받은 LSA를 link state 데이터 베이스에 저장한다.
DBD는 OSPF 라우터의 link state 데이터 베이스에 있는 LSA들의 요약된 정보를 알려주는 패킷이다.
즉, 네이버간 LSA를 교환하기 전에 자신의 link state 데이터베이스에 있는 요약된 LSA목록을 상대방에게 알려주기
위해서 사용한다.
2. LSR (Link State Request)
- 네이버에게 전송받은 DBD에 자신의 link state 데이터베이스에 정보가 없는 네트워크가 있다면 그 네트워크에 대한 상세정보(LSA)를 요청할 때 사용되는 패킷이다.
3. LSU (Link State Update)
- 네이버에게 LSA를 요청받는 LSR을 받거나 자신이 알고 있는 네트워크의 상태가 변했을 경우 해당 라우팅 정보를
전송할 때 사용하는 패킷입니다. 즉, LSA를 실어나를 때 사용하는 패킷이다.
4. LS ACK (Link State Acknowledgment)
- OSPF 패킷을 정상적을 수신했음을 알려줄 때 사용합니다
DBD, LSR, LSU 패킷을 수신하면 LS ACK 패킷을 사용하여 수신받았음을 알려준다.
- 패킷 종류
- Hello packet - 라우터간 이웃 관계를 형성하고 이웃 관계를 유지하는 데 사용
- DBD - 네트워크 정보를 LSA라고 부르는데 자신이 만든 LSA와 이웃에게 받은 LSA를
데이터 베이스에 저장한다.
- LSR - 이웃에게 전송받은 DBD에 자신의 데이터베이스에 정보가 없는 네트워크가 있다면 그 네트워크에
대한 상세정보(LSA)를 요청할 때 사용되는 패킷
- LSU - LSA를 실어나를 때 사용하는 패킷
- LS ACK - OSPF 패킷을 정상적을 수신했음을 알려줄 때 사용
- OSPF를 설정하는 방법
1.(config) #rotuer #rotuer ospf process-ID == 라우터간 서로 달라도 괜찮다.
2.config-router) #router-id #router-id x.x.x.x (식별자 역할)
3.(config-router) #network #network y.y.y.y 0.0.0.0 area 0(area 0는 백본 에어리어)
->OSPF 네이버 확인 => show ip ospf neighbor
- OSPF 동작방식
- 이더넷, NBMA 등의 멀티 엑세스 네트워크에 접속된 모든 라우터가 서로 1:1로 LSA를 교환하면 동일 네트워크에서
중복된 LAS와 ACK가 많이 발생하게 된다.
-> 때문에 LSA 중계 역할을 하는 DR(Designated Router)을 선출하고, DR에 이상이 생길경우를 대비해서
BDR(Backup DR)을 선출용한다.
즉, OSPF가 설정된 모든 라우터는 대표 중계 라우터인 DR에게만 LSA를 보내고 DR이 나머지 라우터에게 이를 중계하면
훨씬 효과적이다. (LSA와 ACK 패킷이 줄어든다.)
-> DR, BDR은 브로드캐스트 및 논브로드캐스트 네트워크에서만 사용되며, 포인트 투 포인트 네트워크에서
사용하지 않는다.
- DR 선출방법
1. 인터페이스 OSPF priority가 가장 높은 라우터가 DR이 된다. (다음으로 높은 라우터가 BDR이 된다.)
-> OSPF priority가 0이면 DR이나 BDR이 될 수 없다.
2. OSPF priority가 모두 동일하면 라우터 ID가 높은 것이 DR, BDR이 된다.
3. DR, BDR이 선출된 후에 더 높은 우선 순위의 라우터가 추가되어도 DR, BDR이 변하지 않는다.
(라우터를 재부팅하거나 clear ip ospf process 명령어를 사용해야 다시 선출한다.)
4. DR이 다운되면 BDR이 DR이 되고 BDR을 새로 선출, BDR이 다운되면 BDR을 새로 선출한다.
DR이 아닌 라우터를 DROTHER라고 부른다. (확인은 show ip ospf neighbor 혹은 show ip ospf interface로 할 수 있다.)
- OSPF adjacent 네이버
- OSPF 라우팅 정보(LSA)를 서로 주고 받는 네이버를 adjacent 네이버라고 한다.
- DR과 다른 라우터들
- BDR과 다른 라우터들
- 포인트 투 포인트 네트워크로 연결된 두 라우터
- 포인트 투 멀티 포인트 네트워크로 연결된 라우터들
- virtual-link로 연결된 두 라우터
-> 확인은 다른 라우터와 연결된 인터페이스에서 'show ip ospf serial 0/0'
- OSPF 네이버 상태 변화
- 일반적으로 down 상태에서 시작해서 네이버와 라우팅 정보 교환을 끝낸 full상태로 변한다.
1) 다운(down)상태 : OSPF가 설정되고 hello 패킷을 전송했지만 아직 상대방 라우터에게 hello 패킷을 받지 못한 상태, full 상태 후에도 dead 주기 동안 OSPF hello 패킷을 받지 못하면 다시 다운 상태가 된다.
2) attempt 상태 : 논브로드캐스트 네트워크에서만 적용되는 상태. OSPF 설정에서 neighbor 명령어를 사용하여 지정한
네이버에게서 헬로 패킷을 수신하지 못한 상태를 의미.
3) init 상태 : 네이버에게 hello 패킷을 받았으나 상대 라우터가 아직 내가 전송한 hello 패킷을 아직 수신하지 못한 경우 (상대방이 보낸 hello 패킷 안의 네이버 리스트에 내 라우터 ID가 없는 경우)
4) two-way 상태 : 네이버와 쌍방향 통신이 이루어진 상태. 멀티액세스 네트워크라면 이 단계에서 DR과 BDR을 선출한다.
DROTHER간은 라우팅 정보를 교환하지 않으므로 즉, 어드제이션시를 맺지 않으므로 네이버 상태가 투 웨이 상태로 남는다.
5) exstart 상태 : 어드제이션트 네이버가 되는 첫 단계. 마스터와 슬레이브 라우터를 선출 (라우터 ID가 높은것이 마스터)
6) exchange 상태 : 각 라우터에서 자신의 link state 데이터베이스에 저장된 LSA 헤더만을 DBD라고 부르는 패킷에
담아 상대방에게 전송한다.
DBD 패킷을 수신한 라우터는 자신의 link state 데이터베이스의 내용과 비교해 보고 자신에게 없거나
자신의 정보가 더 오래된 것이면 상대방에게 상세한 정보를 요청하기 위해
link state requestlist에 기록. DBD를 수신받고 그 안에 자신에게 없는 정보가 없으면 바로 full 상태가
된다.
7) loading 상태 : 상대로부터 DBD수신이 끝나고 자신에게 없는 정보를 LSR로 요청한다. 요청받은 라우터는 해당 정보를 LSU로 전송해준다.
8) full 상태 : 어드제이션트 라우터들간에 정보 교환이 모두 끝나서 어드제이션트 네이버간 link state 데이터베이스 내용이 모두 일치된 상태이다.
-> 네트워크 종류에 따라서 몇 단계를 건너뛰기도 한다. (debug ip opsf adj)을 실행하고 ospf를 설정하면 네이버간의 상태변화를 확인할 수 있다.
- OSPF 메트릭
- OSPF 메트릭은 cost라고 부른다.
- 10^8/bandwidth(bps) = cost
- 코스트 계산시 소수점이하는 전부 버린다. 하지만 1 미만이면 1로 계산한다.
- 인터페이스에서 명령어로 코스트를 변경할 수도 있다. (ip ospf cost ?)
- OSPF area
- OSPF는 복수개의 area로 나눠서 설정
- 규모가 작을때는 하나의 area만 사용해도 된다
- area가 하나일 경우에는 area 번호로 아무거나 사용해도 된다.
하지만 area가 두 개 이상일 경우 하나는 반드시 0으로 써야 한다.
- area 0은 백본 에어리어라 불리며 기본적으로 다른 area 들은 area 0과 물리적으로 직접 연결돼야 한다.
- area로 나눠서 구성하면 안정된 대규모 네트워크를 운영할 수 있다.
-> OSPF 라우팅 정보를 LSA라면 여러 종류가 있다. type 1과 2는 동일한 area 내부로만 전달
즉, area가 다르면 이 두가지 LSA는 다른 area로 전달되지 않는다. 결과적으로 토폴로지의 변화가 심한 불안정한 네트워크라도 그 영향을 자신의 area 내부에 국한시킬 수 있다.
OSPF는 RIP이나 EIGRP처럼 임의 라우터에서 축약하는 것이 아니라 area별로 축약을 설정한다. 따라서 특정 area에
소속된 네트워크를 축약함으로 특정 area 네트워크 정보를 전송하는 LSA type 3의 전송을 최소화할 수 있다.
즉, 특정 area에서 발생하는 토폴로지 변화가 다른 area에 미치는 영향을 최소화한다.
OSPF 외부 네트워크 또는 다른 에어리어의 라우팅 정보가 모두 차단되어 라우팅 테이블을 획기적으로 줄이는
stub area 기능이 있다.
- OSPF 라우터의 종류
1. 백본 라우터 : 백본 에어리어(area 0)에 소속된 라우터
2. 내부 라우터 : 하나의 에어리어에만 소속된 라우터
3. ABR : 두개 이상의 에어리어에 소속된 에어리어 경계 라우터를 의미
4. ASBR : OSPF 네트워크와 다른 라우팅 프로토콜이 설정된 네트워크를 연결하는 라우터를 의미
- OSPF 경로
- LSA와 link state database
- OSPF가 사용하는 라우팅 정보를 LSA라고 한다.(Link state advertisement)
- 모두 type 1부터 type 11까지 11 종류의 LSA를 이요하여 라우팅 정보를 전송
- OSPF는 수신한 LSA를 모두 link state database에 저장한 후 최적 경로를 선출해서 라우팅 테이블에 올린다.
-> 많이 사용되는 OSPF LSA type
-> link state database에 저장된 LSA를 확인하려면 'show ip opsf datebase'명령어를 사용한다.
-> link state database는 에어리어별로 관리되며 동일한 area의 내부 라우터들은 link state database 내용이
모두 동일하다.
1) type 1 : OSPF가 동작하는 모든 라우터가 생성하고 동일 area 내의 모든 라우터에게 전달된다.
링크 데이터의 정보와 각 인터페이스의 cost를 다른 라우터에게 알려주는 역할
2) type 2 : DR이 만들며 동일 area내의 모든 라우터에게 전달, DR과 연결된 라우터들의 라우터 ID를 표시한다.
3) type 3 : ABR이 만들며 다른 area에 소속된 네트워크를 현재의 area에 소속된 라우터들에게 알리기 위해 사용
4) type 4 : 다른 area에 소속된 ASBR 라우터 ID와 그 ASBR까지의 cost를 현재 area에 소속된 라우터들에게 알리기 위해
5) type 5 : ASBR이 만들며 OSPF 도메인 외부 네트워크를 OSPF 도메인 내부의 라우터들에게 알리기 위해 사용된다.
- OSPF 네트워크 summary(축약)
- RIP과 EIGRP의 경우에는 라우팅 경로를 전달하는 라우터의 인터페이스에서 축약을 설정했었다.
- 하지만 OSPF는 RIP과 EIGRP와는 달리 축약을 할 수 있는 위치가 고정되어 있다.
- 자신이 속한 area의 네트워크들을 축약하여 다른 area로 전송시키려면 그 area 사이에 있는 ABR에서 축약을 하고
외부에서 재분배된 네트워크를 축약하려면 ASBR에서 축약해야 한다.
- 축약시 얻을 수 있는 장점은 좀더 안정된 네트워크를 유지할 수 있다는 것이다.
축약에 포함된 상세 네트워크의 변화가 (up, down)전체 네트워크에 미치는 영향을 최소화 시킬 수 있다.
또 축약에 의해 LSA(라우팅 정보)의 수량과 라우팅 테이블의 크기가 줄어들고 bandwidth 및 라우터의 메모리와
CPU가 절약된다. -> 라우팅 테이블 검색 속도가 빨라지고 통신 속도도 좋아진다.
- 축약에는 ABR에서의 축약과 ASBR에서의 축약이 있다.
1) ABR에서 축약
<설정>
R3(config)#router ospf 1 // 축약할 네트워크가 있는 라우터가 아니라
R3(config-router)#area 2 range x.x.x.x y.y.y.y 축약한 정보를 넘기는 area의 ABR에서 설정한다.
--- ------- -------
1 2 3
-> 1 : 축약하는 정보가 있는 area ID
2 : 네트워크를 축약한 IP
3 : 축약한 네트워크의 서브넷 마스크
- 축약을 설정한 라우터에도 null 0로 축약 네트워크가 광고되어 진다. => EIGRP와 마찬가지로 루핑을 방지하기 위해서
- R1에서 확인하면 축약된 정보로 광고되어 진다.
2) ASBR에서 축약
- 외부에서 재분배된 네트워크르르 축약하려면 ASBR에서 축약을 해야한다.
<설정>
R2(config)#router ospf 1
R2(config)#summary-address x.x.x.x y.y.y.y
------- -------
1 2
-> 1 : 네트워크를 축약한 IP
2 : 축약한 네트워크의 서브넷 마스크
- ABR에서 축약과 마찬가지로 축약을 설정한 라우터에도 루핑방지를 위해 null 0로 축약 네트워크가 광고되어 진다.
- R1에서 확인하면 축약된 정보로 광고되어 진다.
- OSPF 네트워크 인증
- OSPF는 RIP, EIGRP와는 달리 인접한 네이버간의 네이버 인증외에도 특정 area전체를 인증할 수도 있다.
- 인증을 하지 않는 것은 type 0, 평문 인증은 type 1, MD5 인증은 type2 인증이라고 한다.
(MD5로 인증하는 것이 보안성이 더 좋다.)
1) AREA 인증
- OSPF area 인증이란 동일한 area에 소속된 모든 라우터가 OSPF 인증을 하게 하는 것
- 동일한 area에 속한 모든 라우터의 인증 방식은 동일해야 하고 인증키는 네이버간에만 일치하면 된다.
<설정>
- MD5 인증 -
R1(config)#router ospf 1
R1(config-router)#area 1 authentication message-digest
R1(config)#interface serial 0/0
R1(config-if)#ip ospf message-digest-key <key 값> md5 <word>
//md5로 인증, 인증키와 word는 네이버간 일치하면 된다.
- 평문 인증 -
R1(config)#router ospf 1
R1(config-router)#area 1 authentication
R1(config)#interface serial 0/0
R1(config-if)#ip ospf authentication-key <word>
=> 설정하고 'debug ip ospf adj'로 디버깅하면 인증 내용들이 디버깅돼서 보인다.
2) 네이버 인증
- 네이버 인증은 네이버와 연결된 인터페이스에서 인증방식과 키를 설정하면 된다.
<설정>
- 평문 인증 -
R1(config)#interface serial 0/1
R1(config-if)#ip ospf authentication
R1(config-if)#ip ospf authentication-key <word>
R3(config)#interface serial 0/0
R3(config-if)#ip ospf authentication
R3(config-if)#ip ospf authentication-key <word>
- MD5 인증 -
R1(config)#interface serial 0/1
R1(config-if)#ip ospf authentication message-digest
R1(config-if)#ip ospf message-digest-key <key 값> md5 <word>
R3(config)#interface serial 0/0
R3(config-if)#ip ospf authentication message-digest
R3(config-if)#ip ospf message-digest-key <key 값> md5 <word>
-> 설정하고 'debug ip ospf adj'로 디버깅하면 인증 내용들이 디버깅돼서 보인다.
- ACL( Access List )
- 네트워크에 접근여부를 허용할지 말지를 결정하는 리스트 (필터링이라고 보면 된다.)
- 보안을 위해서 많이 사용된다.
- 라우터에서 세팅 된다고 네트워크 계층까지가 아니라 어플리케이션 계층의 부분까지 관리하기 때문에 네트워크
계층까지라고 단정할 수 없다.
(하지만 물리계층에서 어플리케이션 계층까지 완벽히 막을 수 없기 때문에 더 많은 보안기능이 있는 firewall같은
전문 보안 장비를 사용한다.)
- 액세스 리스트는 크게 두 종류로 numbered과 named로 구분할 수 있으며, 각각에는 standard와 extended가 있다.
1) standard Access list -> source address 만 참조해서 필터링 여부를 결정한다.
2) extended Access list -> source address외에도 destination address, 프로토콜, 포트 번호 등 좀더 자세한 정보를
참조해서 필터링 여부를 결정한다.
- 각 ACL 별 사용하는 ACL numner
- ACL 규칙
- ACL은 윗줄부터 순서대로 수행된다. 때문에 ACL은 좁은 범위 설정이 먼저 되어야 한다.
만약 다음 처럼 넓은 범위를 먼저 설정하게 되면 모든 Packet이 허용되게 된다. (필터링 효과가 없다.)
R1(config)# access-list 1 permit any
R1(config)# access-list 1 deny 125.101.1.0 0.0.0.255
- ACL의 동작방식
1) inbound 설정
- 패킷이 라우터 내부로 들어올때 필터링 여부를 결정
- 라우터 인터페이스로 패킷이 들어올 경우 수신 인터페이스에 ACL이 설정되어 있는지 확인하고 설정이 되어있지
않으면 그냥 통과시킨다.
- 만약 ACL이 설정돼 있다면 들어온 패킷의 정보와 ACL에 설정 내용을 비교해서 통과 여부를 결정한다.
(조건과 일치하고 permit이면 통과, deny면 통과 X)
2) outbound 설정
- 패킷이 라우터 외부로 나갈때 필터링 여부를 결정한다
- 라우터 인터페이스에서 패킷이 나갈 경우 인터페이스에 ACL이 설정되어 있는지 확인하고 설정이 되어있지 않으면
그냥 보낸다.
- 만약 ACL이 설정돼 있다면 나가는 패킷의 정보와 ACL에 설정 내용을 비교해서 통과 여부를 결정한다.
(조건과 일치하고 permit이면 통과, deny면 통과 X)
============================
- standard ACL
- standard ACL의 경우는 출발지 주소(source address)를 보고 permit, deny 여부를 결정한다.
- 패킷의 source address와 ACL에 정의된 source address가 일치하면 ACL의 내용을 수행한다. (permit or deny)
- permit이면 패킷을 정해진 경로로 전송하고 deny면 패킷의 흐름을 막은 다음 'host unreachable'이라는
ICMP 메시지를 뿌려준다.
- standard ACL의 사용 list-number는 1-99까지 사용한다.
- ACL 인터페이스 적용 하는법
-> R1(config)#interface serial 0/0
R1(config-if)#ip access-group <list-number> <in | out>
----------- --------
1 2
1 : 앞에서 정의한 ACL을 불러와서 필터링 내용을 인터페이스에 적용한다.
2 : inbound와 outbound 설정.
in은 라우터의 인터페이스로 패킷이 들어오는 경우
out은 패킷이 라우터의 인터페이스에서 나가는 경우
* standard ACL은 항상 destination 라우터 쪽에 설정되어야 한다. 중간 라우터에 설정하면 다른 라우터들까지 ACL의
영향을 받아서 정상적으로 패킷 전송이 이루어지지 않을 수 있다.
- ACL 인터페이스 적용 예제
예문1> 210.100.8.2/32 IP주소를 출발지로 가진 패킷을 R1에 들어오지 못하게 차단하시오.
(serial 0/0 포트가 외부 아이피가 들어오도록 연결되어 있다.)
R1(config)#access-list 10 deny 210.100.8.2 0.0.0.0
R1(config)#access-list 10 permit any
R1(config)#interface serial 0/0
R1(config-if)#ip access-group 10 in
예문2> 190.150.82.21/32 IP주소를 출발지로 가진 패킷만 R2에 들어오도록 설정하시오.
(serial 0/1 포트가 외부 아이피가 들어오도록 연결되어 있다.)
R2(config)#access-list 5 permit 190.150.82.21 0.0.0.0
R2(config)#interface serial 0/1
R2(config-if)#ip access-group 5 in
예문3> 51.100.92.8/32 IP 주소가 출발지인 패킷을 R3을 통해 외부로 나가지 못하게 설정하시오
R3(config)#access-list 20 deny 51.100.92.8 0.0.0.0
R3(config)#access-list 20 permit any
R3(config)#interface serial 0/0
R3(config-if)#ip access-group 20 out
- Extended ACL
- standard ACL은 source address만 조건으로 보고 필터링을 수행한다.
하지만 extended ACL은 출발지와 목적지 주소(destination address) 모두를 제어한다.
- 또한 standard ACL은 TCP/IP에 대해 제어만을 하지만 extended ACL은 ip, tcp, udp, icmp 등의 상세 프로토콜을
선택해서 설정할 수 있다.
- extended ACL의 사용 list-number는 100-199까지 사용한다.
Extended 인터페이스 적용 하는법
Extended 인터페이스 적용 예제
예문1> R1에 들어오는 트래픽 중 목적지가 210.150.6.0/24 네트워크에 있는 트래픽들을 모두 차단하시오
R1(config)#access-list 101 deny ip any 210.150.6.0 0.0.0.255
R1(config)#access-list 101 permit ip any any
R1(config)#interface serial 0/0
R1(config-if)#ip access-group 101 in
예문2> R2에 들어오는 트래픽 중 출발지가 200.101.52.0/24 네트워크만이 129.29.31.0/24 네트워크에 있는 FTP와 telnet서버에
접속할 수 있도록 하여라
R2(config)#access-list 110 permit tcp 200.101.52.0 0.0.0.255 129.29.31.0 0.0.0.255 eq 20
R2(config)#access-list 110 permit tcp 200.101.52.0 0.0.0.255 129.29.31.0 0.0.0.255 eq 21
R2(config)#access-list 110 permit tcp 200.101.52.0 0.0.0.255 129.29.31.0 0.0.0.255 eq 23
R2(config)#interface serial 0/1
R2(config-if)#ip access-group 110 in
예문3> R3의 197.2.13.1/32 에서 나가는 트래픽 중 HTTP와 TFTP만을 차단하고 모두 허용하여라
R3(config)#access-list 150 deny tcp host 197.2.13.1 any eq 80
R3(config)#access-list 150 deny udp host 197.2.13.1 any eq 69
R3(config)#access-list 150 permit ip any any
R3(config)#interface serial 0/1
R3(config-if)#ip access-group 150 out
예문4> R4로 들어오는 트래픽 중 목적지가 HTTP서버(201.11.102.10) FTP서버(190.20.81.1)인 트래픽만 들어올 수 있도록 설정하시오
R4(config)#access-list 120 permit tcp any host 201.11.102.10 eq 80
R4(config)#access-list 120 permit tcp any host 190.20.81.1 eq 20
R4(config)#access-list 120 permit tcp any host 190.20.81.1 eq 21
R4(config)#interface serial 0/1
R4(config-if)#ip access-group 120 in
* Well Known Port (지정포트)
1) TCP : FTP(20, 21), Telnet(23), SMTP(25), HTTP(80), HTTPs(443)
2) UDP : DNS(53), TFTP(69), DHCP(67, 68)
공감(♥) 과 댓글은 필자에게 큰 힘이 됩니다. 잠시 1초만 내주시면 안될까요? ~~ 로그인 없이도 가능합니당 |
'클라우드 아키텍처 설계 기초지식 > 02 네트워크 인프라구축' 카테고리의 다른 글
| 네트워크 인프라구축(3) - EIGRP (0) | 2018.10.21 |
|---|---|
| 네트워크 인프라 구축 관리 (2) -RIP세팅 및 개념,축약,스테틱(static) (0) | 2018.10.21 |
| 네트워크 인프라 구축 관리 (1) -정적 네트워크 설정 (0) | 2018.10.21 |
댓글