차노 블로그

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

<script src="https://ads-partners.coupang.com/g.js"></script> <script> new PartnersCoupang.G({ id:370207 }); </script>

5.1.1 Changing the Settings for the Console Port

Of the three connections previously described, the console port is unique in that it is always used for the initial steps needed in configuration because it is by default the only interface that can be used to access the CLI on a Juniper Networks router. All other interfaces lack a functional configuration at initial startup. The console port is an RS232 male 9-pin connection on the craft interface of every Juniper Networks M-Series router. Refer to Figures 5-1 through 5-6 to identify the location of the console port connection on the craft interfaces of the routers.

By default the console port is considered to be secure in that it is permissible to log into the router as the root user through this connection. Those familiar with UNIX will recall that the root user has special permissions. In the Juniper Networks world, the root user is capable of accessing the UNIX kernel, as well as the core of JUNOS. Under normal conditions, root access should be permitted through the console. However, should a network engineer find it necessary, the console port can be blocked from allowing root access. The following example shows how to disable the root login on the console port:

[edit system ports console] 
lab@Chicago# set insecure

The default speed for the console connection is 9,600 baud. The following example shows the command completions for setting the connection speeds. By using the question mark, the valid completions for any command string can be accessed from any point within the JUNOS CLI.

[edit system ports console] 
lab@Chicago# set speed ?
Possible completions:
  115200               Standard terminal at 115200 baud
  19200                Standard terminal at 19200 baud
  38400                Standard terminal at 38400 baud
  4800                 Standard terminal at 4800 baud
  57600                Standard terminal at 57600 baud
  9600                 Standard terminal at 9600 baud

If the baud rate on the console port is changed, any user logged in through that port will immediately be disconnected once the change is committed. The configuration sample below shows how to set the link speed for the console port to 19.2Kbps. It also shows user lab being logged off once the change is committed:

[edit system ports console] 
lab@Chicago# set speed 19200

[edit system ports console]
lab@Chicago# show
speed 19200;

[edit system ports console]
lab@Chicago# commit

Problem

When you activate a configuration, you want to include a short message that describes the changes you made.

Solution

Include a comment when you activate the configuration:

        aviva@router1# commit comment "turned on telnet"

Discussion

It's good practice to include a short description of the changes you made to each version of a configuration file so you can keep a history of configuration changes. You do this by using the comment option with the commit command.

To track down what changed in the configuration and when, you can review the comments:

        aviva@router1> show system commit

        0   2005-03-31 20:26:16 UTC by aviva via cli

            turned on telnet

        1   2005-03-31 11:12:28 UTC by aviva via cli

            set host gildor facility-override local4