2. switch(boot)# 프롬프트에서 부팅 프로세스를 중지하도록 구성 loader> cmdline recoverymode=1
3. NXOS 이미지로 슈퍼바이저 모듈을 부팅 loader> boot <image>
※ 이미지가 부트플래시에 없으면 부팅 시퀀스 중에 로더 프롬프트로 돌아간다. (FTP 또는 USB를 통해 부팅 필요)
4. 스위치의 파일 시스템 파티셔닝을 기본 설정으로 복원. (NXOS 파티셔닝으로 재설정되고 이미지는 삭제됨) switch(boot)# init system
5. NXOS 이미지 파일 업로드를 완료한다. switch(boot)# load-nxos
6. NXOS 이미지를 부트플래시에 다시 복사하고, 다음에 다시 로드 시 NXOS 이미지를 부팅하도록 한다. switch# copy usb1:nxos-image-name bootflash: switch# configure terminal switch(config)# boot nxos bootflash:nxos-image-name switch(config)# copy running-config startup-config switch(config)# end
KT-CGNAT_FG-4401F (global) # set admin-login-max
admin-login-max Enter an integer value from <1> to <100> (default = <100>).
KT-CGNAT_FG-4401F (global) # execute disconnect-admin-session
<integer> Index of admin to be disconnected
Currently connected admins:
INDEX USERNAME TYPE VDOM PROFILE FROM TIME
0 admin ssh root super_admin 192.168.128.139 Sun Jun 8 15:02:41 2025
1 admin https root super_admin 192.168.128.139 Sun Jun 8 15:37:31 2025
2 admin ssh root super_admin 192.168.128.139 Sun Jun 8 15:56:55 2025
KT-CGNAT_FG-4401F (global) # get sys admin list
username local device vdom profile remote started
admin ssh mgmt1:10.215.129.68:22 root super_admin 192.168.128.139:5816 2025-06-08 15:02:41
admin https mgmt1:10.215.129.68:443 root super_admin 192.168.128.139:5919 2025-06-08 15:37:31
admin ssh mgmt1:10.215.129.68:22 root super_admin 192.168.128.139:5954 2025-06-08 15:56:55
2. 여러 장비 동시 모니터링 방법
3. 트랜시버 상태 확인
4. 롤백 명령어 확인
: 없음.
다른 방법(CLI) - 수동 백업
execute backup config flash TEST
내부 플래시 메모리에 저장된 백업 컨피그 파일의 목록(실제 파일명 대신 revision ID로 표시됨) 확인
execute revision list config
설정 복원
execute restore config flash <filename>
백업 파일 삭제
execute revision delete config 4
* 리비전 기능을 통해 롤백 가능하나 권장하지 않음.
1. 재부팅시 삭제
2. FLASH 용량 문제
3. 관리 문제
5. 트래픽 세션 수 확인
KT-CGNAT_FG-4401F (policy) # edit 1
KT-CGNAT_FG-4401F (1) # set cgn-session-quota
cgn-session-quota Enter an integer value from <0> to <16777215> (default = <16777215>).
6. 계정 암호화 종류 확인
sha256 알고리즘이 적용됨.
KT-CGNAT_FG-4401F (global) # sh full-configuration | grep admin-http
config system global
set admin-ssh-v1 disable
set admin-https-ssl-ciphersuites TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256
set admin-https-ssl-versions tlsv1-2 tlsv1-3
set strong-crypto enable
set ssh-enc-algo chacha20-poly1305@openssh.com aes256-ctr aes256-gcm@openssh.com
config system admin
edit "test_admin"
set accprofile "super_admin"
set vdom "root"
set password-expire 2025-06-07 15:49:24
set password ENC SH2n2lZc4Zprwo6Tccq/6en6+Yqu2enfETMIqiY8enDvOmqhi57AmWW3aNlHg0=
SHA256
set password ENC SH2RHqyB8gaEKC10dzpgU6lZg7YSpnb21wWLFOtqzMlpyKJZyyq3ISFYPyIL/s=
PBKDF2
set password ENC PB2a2X8D3DIt0gXbBXVdknLZb48BKrGTD50z//UrbpWAD5kpFdwqBKie0h8STxL6Db//wQ2ZWN/5FW3+DkX3+0nBE1RNbeTKSVi18WcFmSPDQM=
7. http, telnet 포트 비활성화 확인
HTTPS 리다이렉트 활성화
http://로 접속할 경우 자동으로 https://로 리디렉션 됨.
HTTPS 리다이렉트 비활성화
Telnet 활성화
Telnet 비활성화 (global)# set admin-telnet disable
8. SNMP Trap 활성화 기능 타국사 확인
9. SYSLOG 트래픽 로깅 메뉴 의미 확인 * 타국사 설정
vd root
config log setting set local-in-allow enable set local-out disable
config log setting
set local-in-allow enable ← Log allowed traffic [정책에 의해 허용된 세션만 로그로 기록]
set local-in-deny-unicast enable ← Log denied unicast traffic [유니캐스트 트래픽이 차단된 경우 로그 생성]
set local-in-deny-broadcast enable ← Log denied broadcast traffic [브로드캐스트 트래픽이 차단된 경우 로그 생성]
set local-out enable ← Log local out traffic [장비 자체에서 발생한 트래픽을 로그로 기록]
* CLI에서는 vd root에서만 변경가능하며, 글로벌도 같이 적용됨. 다른 vdom은 적용안 됨
● Port Fast * PC↔SW 연결되자마자 포워딩 과정을 거치지 않고, 항상 포워딩 상태를 유지할 수 있도록 한다. * SW↔SW 간에 연결되어 있으면 서로 BPDU를 주고 받아서 스패닝 트리를 동작시켜야 한다. 그런데 포트 패스트 적용 시 스패닝 트리를 계산하지 않고 항상 포워딩 상태를 유지하게 된다. 상대방이 던져주는 BPDU 무시하나 양쪽 다 무시하게 되면 룹이 발생할 수 있기 때문에 상대방 쪽에서 BLOCK을 할 수 있게 하기 위해서 BPDU를 주기적으로 전달한다. 즉, 해당 기술은 STP 기능을 디세이블 시키는 게 아니라 인에이블은 돼있지만 항상 포워딩 상태를 유지할거기 때문에 별도로 스패닝 트리를 계산할 필요가 없고(포워딩 또는 블록을 결정 하기 위함) BPDU를 2초마다 보내지만 받는거는 무시한다.
* INTERFACE에 설정 - 해당 인터페이스만 포트 패스트 설정 : 조건에 상관 없이 항상 포트 패스트가 인에이블 상태
* GLOBAL 설정 - 어떤 조건에 매치가 되면 그 조건에 매치되는 인터페이스를 포트 패스트 적용하라. 방법1. 모든 Access port에 PortFast 설정, PC나 서버는 엑세스로 연결되고 스위치하고는 트렁크 포트로 연결될거라는 가정에서 설정한다.
방법2. Access port인테 스위치와 연결된 경우 - Access port 중 Switch와 연결된 포트는 제외하고 PortFast 설정 스위치와 연결됐는지 아닌지 아는 방법은 BPDU 정보를 받는지 아닌지 확인하면 된다.
방법3. Trunk Port에 PortFast 설정 스위치랑 연결된 쪽에 적용하는 게 아닌 서버들 중에서 트렁크를 지원하고 설정된 서버와 연결된 경우 사용.
● Uplink Fast 블록 포트를 통해서 BPDU를 수집하고 있었으니, 스패닝 트리를 미리 계산 해놓고 30초라는 시간을 줄이고자 함.
● Backbone Fast 루트 포트가 죽었는데도 불구하고, 루트까지 가는 경로가 없는데 계속 루트에 대한 정보를 갖고 있을 필요가 없으니 루트 포트가 없어지고 나면 루트로 가는 경로가 사라진거니 루트에 대한 정보를 바로 삭제 시켜서 맥시멈 에이징 타임(20초)을 없애고자 만들었다.
● BPDU Guard - 알지 못하는 스위치 또는 허브가 연결되지 못하게 하는 기술 * 동작원리 - 관리자가 알지 못하는 스위치가 연결되는 것을 막기 위한 기술. - 스위치가 연결되고 BPDU를 받으면 유입된 인터페이스를 ERR-DISABLE 상태로 만든다.
* 적용방법 방법1. 인터페이스 설정(글로벌 설정도 동작 원리는 같다) - 조건에 상관 없이 해당 인터페이스에 무조건 BPDU 가드 적용 - 글로벌 설정과의 차이점은 인터페이스에는 무조건 BPDU 가드가 적용되는거고, 글로벌에 걸게 되면 포트패스트가 적용된 인터페이스에만 BPDU 가드가 적용 된다. spanning-tree bpduguard ebanle
(default) no spanning-tree bpduguard
방법2. 글로벌 설정(포트 패스트와 연동) - 포트 패스트가 적용된 인터페이스에만 적용된다.
spanning-tree port type edge bpduguard default
no spanning-tree bpduguard (default)
● BPDU Filter - 스위치가 연결되서 룹 구조가 발생하지 않게 하는 기술 * 동작원리 포트패스트는 BPDU를 받는 건 무시하고 보내는건 허용하면서 항상 포워딩 상태를 유지하지만 스패닝 트티가 디세이블된 상태는 아니었다.(STP 계산만 하지 않음) 그런데 필터는 BPDU를 받지도 보내지도 않는다. 아예 STP 자체를 해당 인터페이스에서 디세이블 하는 기술. 리소스는 아낄 수 있지만 자칫 잘못된 설정으로 룹 구조가 되어 루핑이 발생할 수 있다는 위험성이 있다.
* 적용 방법 1. 인터페이스 설정 무조건 BPDU FILTER 적용(PC, 스위치 어떤게 연결이 되든), 항상 스패닝 트리가 디세이블 됨. 그리고 스위치가 아닌 단말이 연결되어 있다는 게 보장되었을 때 적용되어야 한다. 만약 스위치가 연결이 되서 룹 구조가 된다면 절대로 인터페이스에 설정하면 안된다. 이럴 경우 한 쪽을 블록 시켜야 하는데 해당 설정은 스패닝 트리를 디세이블 시키는데 어떻게 블록을 시킬 것이냐라는 문제가 생긴다. 필터는 STP를 디세이블 하기 때문에 BPDU를 인식하지 못하기 때문에 항상 포워딩 상태이고 룹이 발생하는 상황이 생길 수 있다. 그래서 포트 패스트를 이용하게 된다.
무슨 말이냐면 글로벌에 BPDU 필터를 적용하면 조건이 포트 패스트가 적용된 인터페이스에 BPDU 필터를 적용해라는 식으로 동작하게 된다. 그러면 일단 STP는 인에이블 되어있고, 필터가 적용되어 있으니 BPDU를 보내지도 받지도 않게 된다. 이 상태에서 BPDU가 들어오게 되면 STP는 필터가 적용되어 있는데 BPDU가 들어오네 라는 것을 감지하게 되고, 포트 패스트를 강제로 디세이블 시키도록 만들었다.
2. 글로벌 설정(포트 패스트와 연동) - 특정 조건에 해당이 되는 경우 BPDU FILTER을 일괄적으로 적용. - 포트 패스트가 설정된 포트에 BPDU 필터 적용 - BPDU를 받는 경우 포트 패스트 디세이블(1) 그리고 포트 패스트가 디세이블 되었기 때문에 BPDU 필터도 디세이블(2) STP가 동작하게 된다(3) 그래서 하나의 인터페이스가 블록이 된다(4)
================== USER_SW-1 =======================
spanning-tree port type edge bpduguard default
spanning-tree loopguard default
spanning-tree vlan 1,30 priority 4096
interface Ethernet1/4
switchport access vlan 30
spanning-tree port type edge
================== USER_SW-2 =======================
spanning-tree port type edge bpduguard default
spanning-tree loopguard default
spanning-tree vlan 1,30 priority 8192
interface Ethernet1/3
switchport access vlan 30
spanning-tree port type edge
Leaf-3# show spanning-tree vlan 30
VLAN0030
Spanning tree enabled protocol rstp
Root ID Priority 30
Address 00b3.cd3e.1b08
This bridge is the root
Bridge ID Priority 30 (priority 0 sys-id-ext 30)
Address 00b3.cd3e.1b08
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po30 Desg FWD 3 128.4125 P2p
Eth1/3 Desg FWD 4 128.3 P2p
Eth1/4 Desg FWD 4 128.4 P2p
USER_SW-1# show spanning-tree vlan 30
VLAN0030
Spanning tree enabled protocol rstp
Root ID Priority 30
Address 00b3.cd3e.1b08
Cost 4
Port 1 (Ethernet1/1)
Bridge ID Priority 4126 (priority 4096 sys-id-ext 30)
Address 0049.02de.1b08
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/1 Root FWD 4 128.1 P2p
Eth1/2 Desg FWD 4 128.2 P2p
Eth1/4 Desg FWD 4 128.4 Edge P2p
USER_SW-2# show spanning-tree vlan 30
VLAN0030
Spanning tree enabled protocol rstp
Root ID Priority 30
Address 00b3.cd3e.1b08
Cost 4
Port 1 (Ethernet1/1)
Bridge ID Priority 8222 (priority 8192 sys-id-ext 30)
Address 0070.92c0.1b08
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/1 Root FWD 4 128.1 P2p
Eth1/2 Altn BLK 4 128.2 P2p
Eth1/3 Desg FWD 4 128.3 Edge P2p
● Root Guard - 기존의 STP 구조를 망가뜨리는 상황을 막기 위함. * 동작원리 스위치가 연결되는 것까지 허용, 그런데 새로 연결된 스위치가 BPDU 정보를 보냈는데 그 BPDU에 루트에 대한 정보가 기존에 내가 알고 있던 정보보다 더 좋은 정보여서 해당 인터페이스가 루트 포트가 되는 것을 막는 기술이다. 만일 받은 BPDU 정보 내에 현재 내가 알고 있는 루트 정보보다 더 좋은 우선순위가 높은 루트 정보가 들어온다 라고 하면 해당 인터페이스를 블록 시킨다. 즉, 새로운 스위치에 연결된 인터페이스에 루트 포트가 되는 상황이 발생하게 되면 블록 포트로 만든다.
● Loop Guard - 스위치가 연결된다는 조건에서 사용 그래서 포트 패스트와 연동되지 않는다.
- 스위치와 연결된 인터페이스에 적용하는 기술이다. 그렇기 때문에 포트 패스트와 관련이 없다.
- - 어떤 정상적이지 않은 상태에서 이상함을 감지하고 BPDU가 들어와야 하는데 안들어오면 BLOCK 상태를 풀지 않음으로써 룹을 방지하는 기술이다. - 특정 장비에 BPDU Filter가 적용 되었거나 또는 STP 프로세스에 문제나 케이블 불량 등으로 BPDU가 제대로 전달되지 못하는 경우에 룹을 차단하는 기술. - 루프 가드는 BPDU를 받는 인터페이스에서만 동작하기 때문에 D.P 포트에서는 설정할 필요가 없지만 다른 역할의 포트로 변경될 수 있으니 설정하는 게 좋다. - 정상 경우: 루트 또는 블록 포트인데 BPDU가 들어오지 않으면 비정상적인 경우이다.
1. 인터페이스 설정
BPDU를 받아야 되는 루트 포트와 블록 포트에서 동작하도록 만들어 졌다.
2. 글로벌 설정
port-type P2P인 경우(full duplex) 이면서 스위치와 연결된 인터페이스에만 적용 된다.
● 스위치 전원을 켜고 케이블을 연결하고 바로 STP가 바로 포워딩 상태로 동작하는 게 아니다. BLOCK(20s) > Listening(15s) > Learning(15s) > Forwarding
- 특정 네이버에게만 디폴트 루트를 보내고, 라우팅 테이블에 0.0.0.0 네트워크가 저장되어 있지 않아도 된다.
vPC와 HSRP 같이 사용하는 이유
BUM 트래픽
ip access-list INTERNAL-ZONE
statistics per-entry
10 permit ip 172.21.10.15/32 172.21.20.15/32
20 permit ip 172.21.20.15/32 172.21.10.15/32
30 deny ip 172.21.10.0/24 172.21.20.0/24
40 deny ip 172.21.20.0/24 172.21.10.0/24
50 permit ip 172.21.10.0/24 172.21.30.0/24
60 permit ip 172.21.20.0/24 172.21.30.0/24
70 permit ip 172.21.30.0/24 172.21.10.0/24
80 permit ip 172.21.30.0/24 172.21.20.0/24
interface Vlan10
ip access-group INTERNAL-ZONE in
ip access-group INTERNAL-ZONE out
interface Vlan20
ip access-group INTERNAL-ZONE in
ip access-group INTERNAL-ZONE out
interface Vlan30
ip access-group INTERNAL-ZONE in
ip access-group INTERNAL-ZONE out
spanning-tree port type edge bpduguard default
interface Ethernet1/6
switchport access vlan 20
spanning-tree port type edge
SW-2# sh spanning-tree interface eth1/6 detail
Port 6 (Ethernet1/6) of VLAN0020 is designated forwarding
Port path cost 4, Port priority 128, Port Identifier 128.6
Designated root has priority 20, address 5005.0000.1b08
Designated bridge has priority 4116, address 5000.0007.0007
Designated port id is 128.6, designated path cost 4
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
The port type is edge
Link type is point-to-point by default
Bpdu guard is enabled by default
BPDU: sent 249, received 0
spanning-tree loopguard default
interface Ethernet1/6
switchport access vlan 30
spanning-tree port type edge
spanning-tree bpduguard enable
SW-2(config)# sh spanning-tree interface eth1/6 detail
The port type is edge
Link type is point-to-point by default
Bpdu guard is enabled
Loop guard is enabled by default
BPDU Filter
Filter 적용 전
Port 6 (Ethernet1/6) of VLAN0030 is designated forwarding
The port type is edge
Link type is point-to-point by default
Bpdu filter is enabled by default
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/6 Desg FWD 4 128.6 Edge P2p
Filter 적용 후
Port 6 (Ethernet1/6) of VLAN0030 is designated forwarding
Link type is point-to-point by default, Peer is STP
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/6 Desg FWD 4 128.6 P2p Peer(STP)
R1#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 i
넥스트홉(0.0.0.0), 웨이트(32768) 확인시 network 명령어를 사용하여 BGP로 광고함을 의미.
R2#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 192.1.12.1 0 0 1 i
R3#sh ip bgp
% BGP not active
R4#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.0/24 192.1.12.1 0 100 0 1 i
R4가 R2로부터 수신한 네트워크에 대해 '>' 기호가 없으므로 라우팅 테이블에 저장되지 않는다.
R5#sh ip bgp
R4의 문제로 인해 1.1.1.0/24 네트워크를 광고 받지 못한다.
BGP는 기본적으로 넥스트 홉 IP 주소를 변경하지 않고, 이 때문에 문제가 발생할 수 있다.
R4가 넥스트 홉(192.1.12.1)에 통신이 되는지 확인해보자.
※ BGP 테이블에 항목이 보이지 않는 경우.
1. 라우팅 테이블에 없는 정보이거나 인터페이스 문제.
2. network 명령어 사용 시 잘못된 서브넷 마스크 입력.
R4#sh ip route 192.1.12.1
% Network not in table
넥스트 홉에 대한 경로가 라우팅 테이블에 없기 때문에 1.1.1.0/24 네트워크가 저장되지 않는다. 다음 방법을 사용.
Next Hop이 R2의 루프백 인터페이스로 변경. (192.1.12.1 → 2.2.2.2)
R4#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.0/24 2.2.2.2 0 100 0 1 i
R4#sh ip rou ospf
O 2.2.2.2 [110/3] via 192.1.34.3, 00:29:47, GigabitEthernet0/2
R4에서 라우팅 테이블에 설치됐으므로 R5에 접두사 광고.
R5#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 192.1.45.4 0 2 1 i
R5#sh ip rou bgp
1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 192.1.45.4, 00:07:02
R5#ping 1.1.1.1 sou 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5
.....
Success rate is 0 percent (0/5)
라우팅 테이블에 엔트리가 있지만 핑이 가질 않는다.
원인은 R3에서 목적지(1.1.1.1) 패킷을 수신했지만 어디로 보내야 할지 몰라 버려지게 되고, 트랜짓 AS의 모든 라우터에서 iBGP가 필요한 이유이다.
R3#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.0/24 2.2.2.2 0 100 0 1 i
ping 확인
R2#ping 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms
R3#ping 1.1.1.1
.....
Success rate is 0 percent (0/5)
R4#ping 1.1.1.1
.....
Success rate is 0 percent (0/5)
R5#ping 1.1.1.1 sou 5.5.5.5
.....
Success rate is 0 percent (0/5)
R3에서 여전히 ping 안 됨, R3의 테이블 확인시 목적지까지 경로에 대해 문제 없으며, R1의 테이블 확인 필요.
R1#sh ip route
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.0/24 is directly connected, Loopback0
L 1.1.1.1/32 is directly connected, Loopback0
192.1.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.1.12.0/24 is directly connected, GigabitEthernet0/0
L 192.1.12.1/32 is directly connected, GigabitEthernet0/0
R1은 R3으로부터 다음의 IP 패킷을 수신하고, R3으로의 경로가 없으며, 5.5.5.5로 응답하려고 할 때 어디로 보내야 할지 모른다.
src ip : 5.5.5.5
dst ip : 1.1.1.1
R3가 R1에 도달하는 것은 중요하지 않고, R5가 R1에 도달 하길 원한다.
R5에서 5.5.5.5/32를 BGP에 포함시키고 R1에서 BGP 및 라우팅 테이블 확인.
R1#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 i
*> 5.5.5.5/32 192.1.12.2 0 2 3 i
R1#sh ip route
B 5.5.5.5 [20/0] via 192.1.12.2, 00:43:21
ping 확인
R5#ping 1.1.1.1 sou 5.5.5.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/7 ms
R4#ping 1.1.1.1
.....
Success rate is 0 percent (0/5)
R3#ping 1.1.1.1
.....
Success rate is 0 percent (0/5)
R1#ping 5.5.5.5 sou 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms
라우팅 테이블 확인
R1#sh ip route
B 5.5.5.5 [20/0] via 192.1.12.2, 00:43:21
R2#sh ip route
B 1.1.1.0 [20/0] via 192.1.12.1, 06:47:59
O 3.3.3.3 [110/2] via 192.1.23.3, 05:36:30, GigabitEthernet0/1
O 4.4.4.4 [110/3] via 192.1.23.3, 05:29:04, GigabitEthernet0/1
B 5.5.5.5 [200/0] via 4.4.4.4, 00:43:22
O 192.1.34.0/24 [110/2] via 192.1.23.3, 06:47:46, GigabitEthernet0/1
R3#sh ip route
B 1.1.1.0 [200/0] via 2.2.2.2, 05:09:17
O 2.2.2.2 [110/2] via 192.1.23.2, 06:47:43, GigabitEthernet0/1
C 3.3.3.3 is directly connected, Loopback0
O 4.4.4.4 [110/2] via 192.1.34.4, 05:29:08, GigabitEthernet0/2
B 5.5.5.5 [200/0] via 4.4.4.4, 00:43:21
R4#sh ip route
B 1.1.1.0 [200/0] via 2.2.2.2, 05:28:49
O 2.2.2.2 [110/3] via 192.1.34.3, 05:29:09, GigabitEthernet0/2
O 3.3.3.3 [110/2] via 192.1.34.3, 05:29:09, GigabitEthernet0/2
C 4.4.4.4 is directly connected, Loopback0
B 5.5.5.5 [20/0] via 192.1.45.5, 00:43:21
O 192.1.23.0/24 [110/2] via 192.1.34.3, 05:29:09, GigabitEthernet0/2
R5#sh ip route
B 1.1.1.0 [20/0] via 192.1.45.4, 05:29:00
위의 넥스트 홉 문제에 대한 해결 방법 중 next-hop-self가 아닌 라우팅 프로토콜(IGP 또는 BGP)을 사용하는 경우.
BGP는 IGP에서 접두사를 검증할 수 없는 경우, iBGP 네이버로부터 학습한 내용을 eBGP 네이버에게 알리지 않는다.
동기화는 AS 내에 모든 라우터가 iBGP를 활성화할 필요가 없었던 시절에 적용되어 온 규칙이며, 현재는 사용되지 않는다.
iBGP 피어링은 반드시 직접 연결되어 있지 않은 라우터 간에도 피어링을 맺을 수 있다. iBGP 피어링은 iBGP 라우터가 AS 내에서 실행되는 IGP를 통해 서로 연결될 수만 있으면 된다.
이 시나리오는 R1과 R5 간에 통신이 아닌 BGP가 BGP 동기화를 통해 접두사를 공유하는 방식에 초점을 맞췄다. BGP 접두사가 테이블에 어떻게 표시되는지 확인하는데에 국한되었으며, R5에서 R1로 ping은 필수가 아니다. 그리고 전송 AS의 모든 라우터에서 iBGP를 실행하지 않는 시나리오에 대한 솔루션을 말한다.
iBGP 세션 설정을 위해 IGP(OSPF) 구성. (R1은 접두사를 광고하고 R2, R3에서 이를 학습한다.)
R2와 R4는 iBGP 피어링을 맺고, OSPF를 통해 서로 통신. (R4는 R2로부터 iBGP를 통해 1.1.1.0/24 학습)
OSPF 구성
R2
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.1.23.0 0.0.0.255 area 0
R3
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.1.23.0 0.0.0.255 area 0
network 192.1.34.0 0.0.0.255 area 0
R4
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.1.34.0 0.0.0.255 area 0
1.1.1.0/24의 BGP 테이블 확인. R4, R5 모두 이 네트워크에 대해 알고있다.
R4#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.0/24 2.2.2.2 0 100 0 1 i
R5#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 192.1.45.4 0 2 1 i
현재 문제는 R4 또는 R5가 도달할 수 없는 경로를 학습했다는 거다. R3에서 BGP를 실행하지 않았기 1.1.1.0/24 네트워크를 모르고, AS3에서 AS1로 IP 패킷이 전달되지 못하고 R4가 R3에게 패킷을 전달하면 R3는 해당 패킷을 드랍한다. (R3 블랙홀)
R3#sh ip rou 1.1.1.0
% Network not in table
R4#sh ip rou 1.1.1.0
% Network not in table
이 문제를 해결하기 위해 동기화 규칙이 만들어졌다.
BGP 동기화 활성화
경계 라우터(R2, R4)에서 활성화 한다. 동기화를 활성화하면 1.1.1.0/24 네트워크를 더 이상 R5에 광고하지 않고, IGP에서 해당 경로를 알고 있으면 R3가 패킷을 전달할 수 있다는 것을 알고 나서 R5에 경로를 광고한다.
동기화가 활성화되면 사용 중인 IGP에서 해당 경로를 알아내기 전까지 해당 경로가 라우팅 테이블에 설치되지 않는다.
동기화 규칙의 역할은 라우터가 먼저 경로가 IGP에 의해 알려진 경로인지 확인하도록 하는 것이다. OSPF의 경우 LSDB에서 해당 경로에 대한 기록이 있는지 확인한다.
R1, R2
router bgp 2
synchronization
R4#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.0/24 2.2.2.2 0 100 0 1 i
R4#
R4#sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 3
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 3
1
2.2.2.2 (metric 3) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
rx pathid: 0, tx pathid: 0
R4의 BGP 테이블에서 네트워크가 학습되지만 사용할 수 없는 경로이다. no best path와 not synchronized를 확인할 수 있다.
R5#sh ip bgp 1.1.1.1
% Network not in table
이 문제를 해결하기 위해 동기화를 비활성화하고, 풀 메시 구성하여 AS 내의 모든 라우터가 iBGP 피어링을 맺거나 IGP에 접두사를 재분배하여 해결할 수 있다.
R2
route-map AS1 permit 10
match ip address 1
!
access-list 1 permit 1.1.1.0 0.0.0.255
!
router ospf 1
redistribute bgp 2 subnets route-map AS1
R4는 해당 네트워크에 대한 IGP 경로가 라우팅 테이블에 저장되어 있지 않으면, BGP 경로 저장을 거부한다.
이렇게 하면 해당 경로가 IGP 도메인 내에서 인식되므로 iBGP를 실행하지 않는 모든 라우터가 해당 경로를
라우팅할 수 있다.
R2에서 1.1.1.0/24 네트워크를 OSPF로 재분배하여 R4의 OSPF에 해당 네트워크를 포함. 이렇게 하면 동기화 규칙이 충족되고 1.1.1.0/24로 향하는 BGP 경로가 라우팅 테이블에 등록된다.
R3#sh ip rou 1.1.1.0
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 1
Tag 1, type extern 2, forward metric 1
Last update from 192.1.23.2 on GigabitEthernet0/1, 00:00:05 ago
Routing Descriptor Blocks:
* 192.1.23.2, from 2.2.2.2, 00:00:05 ago, via GigabitEthernet0/1
Route metric is 1, traffic share count is 1
Route tag 1
R4#sh ip rou 1.1.1.0
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 1
Tag 1, type extern 2, forward metric 2
Last update from 192.1.34.3 on GigabitEthernet0/2, 00:00:05 ago
Routing Descriptor Blocks:
* 192.1.34.3, from 2.2.2.2, 00:00:05 ago, via GigabitEthernet0/2
Route metric is 1, traffic share count is 1
Route tag 1
Network Next Hop Metric LocPrf Weight Path
r>i 1.1.1.0/24 2.2.2.2 0 100 0 1 i
'r' : 해당 경로가 라우팅 테이블에 등록되지 않았음을 의미한다. 하지만 OSPF를 통해
라우팅 테이블에 저장된다. 이상태는 해당 경로가 eBGP를 통해 R5에게 전달되지 않는다는
것을 의미하지는 않는다. 따라서 R4에는 OSPF를 통해 학습된 1.1.1.0/24 경로가 있으므로
라우팅이 가능하다.
R5#sh ip rou 1.1.1.0
Routing entry for 1.1.1.0/24
Known via "bgp 3", distance 20, metric 0
Tag 2, type external
Last update from 192.1.45.4 00:00:05 ago
Routing Descriptor Blocks:
* 192.1.45.4, from 192.1.45.4, 00:00:05 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 2
MPLS label: none
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 192.1.45.4 0 2 1 i
Q. R4에서 OSPF에서 BGP로 재분배를 하지 않고, BGP로 다시 재분배하지 않는가? R5가 접두사를 학습하는 방법은?
A. BGP를 통한 광고의 전제 조건은 해당 네트워크가 로컬 라우팅 테이블에 있어야 한다는 것이다. '1.1.1.0/24'는 BGP 테이블에는 있지만 R4의 라우팅 테이블에는 없었다.
해결책은 해당 네트워크를 라우터 자체 내에서 BGP에서 OSPF로 재분배하는 것이다. 그 결과 네트워크가 라우팅 테이블에 저장되고 BGP를 사용하여 R5로 광고된다. (BGP가 해당 네트워크 정보의 소스이기 때문에 BGP로 다시 재분배할 필요가 없다)
