'주노스' 태그의 글 목록

- Topology

[R3]-ge-0/0/2--------------ge-0/0/2-[R1]

- OSFP 네이버 ExStart 상태
root@R3# run show ospf neighbor
R3# run show ospf neighbor
Address Interface State ID Pri Dead
10.10.13.1 ge-0/0/2.0 ExStart 1.1.1.1 128 37

ExStart : database sync 중인 상태. FULL 상태가 아님.

- 트러블슈팅을 위한 traceoption 설정 ( cisco debug command 와 동일하다고 보면됨)

root@R1# set protocols ospf traceoptions file ospf.log
root@R1# set protocols ospf traceoptions flag error detail
root@R1# commit

- OSFP 로그 확인

root@R1# run show log ospf.log
Nov 18 07:06:06.275796 OSPF packet ignored: MTU mismatch from 10.10.13.3 on intf ge-0/0/2.0 area 0.0.0.0
Nov 18 07:06:10.310038 OSPF packet ignored: MTU mismatch from 10.10.13.3 on intf ge-0/0/2.0 area 0.0.0.0
Nov 18 07:06:14.389599 OSPF packet ignored: MTU mismatch from 10.10.13.3 on intf ge-0/0/2.0 area 0.0.0.0
Nov 18 07:06:19.429346 OSPF packet ignored: MTU mismatch from 10.10.13.3 on intf ge-0/0/2.0 area 0.0.0.0

> MTU mismatch 확인

-라우터 설정 확인

root@R3# show protocols ospf | display set
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p

root@R3# show interfaces ge-0/0/2 | display set
set interfaces ge-0/0/2 mtu 9000
set interfaces ge-0/0/2 unit 0 family inet address 10.10.13.3/24

root@R1# show protocols ospf | display set
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf traceoptions file ospf.log
set protocols ospf traceoptions flag error detail

root@R1# show interfaces ge-0/0/2 | display set
set interfaces ge-0/0/2 unit 0 family inet address 10.10.13.1/24

R1 ge-0/0/2 MTU : 1500 ( default )
R3 ge-0/0/2 MTU : 9000

- R3 ge-0/0/2 MTU 수정 ( 9000 -> 1500 )

root@R3# delete interfaces ge-0/0/2 mtu

- 수정 후 OSPF neighbor 확인

@R3# run show ospf neighbor
Address Interface State ID Pri Dead
10.10.13.1 ge-0/0/2.0 Full 1.1.1.1 128 37

- Topology

[R3]-ge-0/0/2--------------ge-0/0/2-[R1]

- OSFP 네이버가 맺어지지 않는 상태
root@R3# run show ospf neighbor
--- 네이버 없음 --

- 트러블슈팅을 위한 traceoption 설정 ( cisco debug command 와 동일하다고 보면됨)

root@R1# set protocols ospf traceoptions file ospf.log
root@R1# set protocols ospf traceoptions flag error detail
root@R1# commit

- OSFP 로그 확인

root@R1# run show log ospf.log
Nov 18 06:30:41 trace_on: Tracing to "/var/log/ospf.log" started
Nov 18 06:30:42 OSPF packet ignored: area mismatch (0.0.0.1) from 10.10.13.3 on intf ge-0/0/2.0 area 0.0.0.0
Nov 18 06:30:42 OSPF rcvd Hello 10.10.13.3 -> 224.0.0.5 (ge-0/0/2.0 IFL 335 area 0.0.0.0)
Nov 18 06:30:42 Version 2, length 44, ID 3.3.3.3, area 0.0.0.1
Nov 18 06:30:42 checksum 0xe618, authtype 0
Nov 18 06:30:42 mask 255.255.255.0, hello_ivl 10, opts 0x12, prio 128
Nov 18 06:30:42 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
-> area mismatch 확인

-라우터 설정 확인

root@R3# show protocols ospf | display set
set protocols ospf area 0.0.0.1 interface lo0.0 passive
set protocols ospf area 0.0.0.1 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.1 interface ge-0/0/6.0 interface-type p2p
set protocols ospf area 0.0.0.1 interface ge-0/0/2.0 interface-type p2p

root@R1# show protocols ospf | display set
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set protocols ospf traceoptions file ospf.log
set protocols ospf traceoptions flag error detail

R1 OSPF area : 0.0.0.0 = 0
R3 OSPF area : 0.0.0.1 = 1

- R3 OSPF area 수정 (0.0.0.1 -> 0.0.0.0 )

root@R3# rename protocols ospf area 1 to area 0

- 수정 후 OSPF neighbor 확인

root@R3# run show ospf neighbor
Address Interface State ID Pri Dead
10.10.13.1 ge-0/0/2.0 Full 1.1.1.1 128 39

BGP FlowSpec은 BGP peer간에 신속하게 filtering and policing 기능을 전파시켜 DDOS 공격을 방지하는 역할을 한다.

기존의 RTBH는 ddos공격을 대상의 주소의 next-hop 을 null/discard 로 전파하여 공격을 방지 하였다. 하지만 이럴 경우 공격 공격대상이 unreachable 상태에 빠지게 된다.

FlowSpec는 기존의 RTBH와는 다르게 null/discard 동작만이 아니라 source , destination, L4 parameter, packet parameter( length, fragmentation , etc, ) 등등 더 다양한 옵션을 사용 하여 ddos 공격에 대응 할 수 있다.

Juniper FlowSpec 동작

아래 그림과 같이 BGP peer를 통해 전달받은 flow를 validation 과정을 거쳐 match 되는 flow를 Local-RIB에 저장하고 firewall filter로 변환하여 각각에 PFE에 내려주면 모든 인터페이스에 해당 filter를 적용시킨다.

LAB TEST

망 구성도

[ R1 ] --------------------- [ R2 ]

1.1.1.1 192.168.0.0/24 2.2.2.2

R1

set logical-systems TEST_1 interfaces xe-1/2/0 unit 0 family inet address 10.10.10.1/24

set logical-systems TEST_1 interfaces lo0 unit 1 family inet address 1.1.1.1/32

set logical-systems TEST_1 protocols bgp group TEST type internal

set logical-systems TEST_1 protocols bgp group TEST local-address 1.1.1.1

set logical-systems TEST_1 protocols bgp group TEST family inet unicast

set logical-systems TEST_1 protocols bgp group TEST family inet flow no-validate TEST_default

set logical-systems TEST_1 protocols bgp group TEST neighbor 2.2.2.2

set logical-systems TEST_1 policy-options policy-statement TEST_default term 10 then accept

set logical-systems TEST_1 policy-options policy-statement TEST_default term 5 then reject

set logical-systems TEST_1 routing-options static route 2.2.2.2/32 next-hop 10.10.10.2

set logical-systems TEST_1 routing-options autonomous-system 1234

R2

set interfaces xe-1/3/0 unit 0 family inet address 10.10.10.2/24

set interfaces lo0 unit 2 family inet address 2.2.2.2/32

set routing-options static route 1.1.1.1/32 next-hop 10.10.10.1

set routing-options autonomous-system 1234

set routing-options flow route TEST match protocol icmp

set routing-options flow route TEST then discard

set protocols bgp group TEST type internal

set protocols bgp group TEST local-address 2.2.2.2

set protocols bgp group TEST family inet unicast

set protocols bgp group TEST family inet flow no-validate TEST

set protocols bgp group TEST cluster 2.2.2.2

set protocols bgp group TEST neighbor 1.1.1.1

set policy-options policy-statement TEST then accept

-> R2 에서 icmp discard 하는 flow (TEST) 를 생성하여 R1 에게 전달함.

BGP를 통해 flow를 전달받은 R1은 수신한 flow 를 보고 firewall filter 를 생성하여 모든 인터페이스에 적용시킨다.

R1에서 R2로 ping을 시도하면 수신받은 flow 기반으로 생성한 firewall filter에 의하여 icmp packet이 Drop 된다.

R1 firewall filter ( R1에서 R2로 ping 시도 후 )

icraft@Mx960# run show firewall

Filter: __default_bpdu_filter__

Filter: __flowspec_default_inet__

Counters:

Name Bytes Packets

*,*,proto=1 588 7

[edit]

icraft@Mx960#

수신받은 flow는 show route 명령어를 통해 확인가능 하다. 해당 flow는 inetflow.0 table에 저장된다.

R1 routing table

inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

*,*,proto=1/term:1

*[Flow/5] 01:04:20

Fictitious

[edit]

icraft@Mx960#

수신받을 flow 도 필터링이 가능하다. 아래와 같은 flow 를 생성 하고 라우팅 테이블을 확인해보면

R2

set routing-options flow route TEST match destination 100.100.0.0/16

set routing-options flow route TEST then accept

icraft@Mx960:TEST_1# show protocols bgp

group TEST {

type internal;

local-address 1.1.1.1;

family inet {

unicast;

flow {

no-validate TEST;

}

neighbor 2.2.2.2;

}

R1

inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

100.100/16,*/term:N/A

*[BGP/170] 00:02:49, localpref 100, from 2.2.2.2

AS path: I, validation-state: unverified

Fictitious

[edit]

icraft@Mx960:TEST_1# #

위와같이 R2로 부터 수신한 flow 가 table 에 등록되어 있는 것을 확인 가능하다.

이때 R1에 아래와 같은 정책을 적용한다.

R1

policy-statement TEST_reject {

term 10 {

from local-preference 100;

then reject;

}

term 20 {

then accept;

}

icraft@Mx960:TEST_1# show protocols bgp

group TEST {

type internal;

local-address 1.1.1.1;

family inet {

unicast;

flow {

no-validate TEST_reject;

}

neighbor 2.2.2.2;

}

R1에서 보내준 flow는 bgp로 수신받은 flow 이기 때문에 preference 가 100이므로 해당 flow 가 reject 가 된다.

이 때 라우팅 테이블을 확인 해 보면

R1

icraft@Mx960:TEST_1# run show route hidden

inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

inetflow.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

+ = Active Route, - = Last Active, * = Both

100.100/16,*/term:N/A

[BGP ] 00:09:27, localpref 100, from 2.2.2.2

AS path: I, validation-state: unverified

Fictitious

[edit]

icraft@Mx960:TEST_1#

해당 루트가 hidden으로 빠진걸 볼 수 있다. validation에서 match 되지 않는 flow 는 hidden 으로 빠지는걸 확인 가능하다.

저작자표시

Nonstop Active Routing

NSR은 인터페이스와 커널정보를 보존하기 위해 GRES와 동일한 구조를 사용한다. 그러나 GRES와는 다르게 NSR은 백업 라우팅 엔진에서 rpd( routing protocol daemon)을 실행하면서 라우팅 정보를 동기화 하고 있다. 이로인해 helper 라우터로 부터 라우팅 정보를 복원할 필요가 없습다. peer 라우터가 GR (gresful restart) 를 미지원 할 경우 사용하면 유용하고, GR (graceful restart)의 대안으로 사용하기도 한다.

- NSR를 사용하기 위해서는 반드시 GRES가 enable상태이여야 한다.

1. 마스터 라우팅엔진 부팅

2. 마스터 라우팅엔진에 chassisd, rpd 가 실행된다.

3. 패킷포워딩엔진이 시작하고 마스터 라우팅엔진과 연결된다.

4. 모든 시스템 정보가 업데이트 된다.

5. 백업 라우팅엔진이 시작되고 chassisd, rpd 가 실행된다.

6. 시스템이 GRES, NSR 이 enable 되어 있는지 확인한다.

7. ksyncd ( kernel synchronization daemon) 이

8. ksyncd가 마스터와 백업라우팅엔진을 서로 동기화 시킨다.

9. 지원되는 프로토콜의 상태정보는 마스터와 백업 rpd 사이에서 다이렉트로 업데이트 된다.

1. 마스터와 백업간의 keeplives 가 실패하면 시스템은 백업라우팅 엔진으로 switch over 한다.

2. 패킷 포워딩엔진이 백업라우팅엔진과 연결되며, 백업라우팅엔진은 마스터가 된다. rpd 가 이미 실행중이기

때문에 restart 가 필요없다. ( GRES 만 enable 상태일 경우에는 rpd 가 실행중이지 않으며 restart 가 된다.)

3. switch over 중에 배운 상태정보는 시스템에 업데이트 된다. 포워딩과 라우팅은 switch over 동안에 계속되며 이로인해

최소한의 패킷로스가 발생한다.

4. 마치 아무일 없었던 것처럼 peer 라우터와 계속적으로 정보를 교환한다. adjacencies 와 session 정보는 손실되지 않고

(백업 , 마스터 rpd 가 동기화 하고 있었기 때문에 ) rpd 가 restat 되지 않는다.

GRES만 enable 된 경우 백업 라우팅엔진에 rpd 가 running 중이 아니므로 restart 가 필요하고, 인접 peer 라우터에게 라우팅 정보를 업데이트 받아야만 한다.

출처 : http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/swconfig-high-availability/nsr-overview.html

차노 블로그

주노스

OSPF Troubleshooting - MTU mismatch

OSPF Troubleshooting - Area mismatch

Juniper BGP flowspec

Non-Stop Routing (NSR)

Nonstop Active Routing

+ Recent posts

티스토리툴바