728x90
R1
----------------------------------------------------------------------------------------------------------------
routing-options {
    static {
        route 0.0.0.0/0 next-hop [ 192.168.1.3 192.168.4.2 ];  // 192.168.1.3 ->R2  192.168.4.2.->R3
    }
    forwarding-table {
        export loadbalance;
    }
}
policy-options {
    policy-statement loadbalance {
        then {
            load-balance per-packet; 
        }
    }
}
----------------------------------------------------------------------------------------------------------------

commit 완료 후  R2, R3 에서 tcpdump 명령어로 sequence number 확인

tcpdump 명령어---------------
root@R3> start shell
root@R3% tcpdump -l -i em2
------------------------------
R2_ tcpdump
11:42:01.239017  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 122, length 64
11:42:03.238959  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 124, length 64
11:42:04.239231  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 125, length 64
11:42:07.239038  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 128, length 64
11:42:10.238711  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 131, length 64
11:42:11.239002  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 132, length 64
11:42:13.238967  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 134, length 64
11:42:14.238755  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 135, length 64
11:42:17.238425  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 138, length 64
11:42:20.238648  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 141, length 64
11:42:21.238450  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 142, length 64

R3_ tcpdump
11:42:09.992713  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 123, length 64
11:42:12.995975  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 126, length 64
11:42:13.996726  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 127, length 64
11:42:15.998653  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 129, length 64
11:42:16.999949  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 130, length 64
11:42:20.002647  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 133, length 64
11:42:23.005435  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 136, length 64
11:42:24.006640  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 137, length 64
11:42:26.008672  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 139, length 64
11:42:27.009432  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 140, length 64
11:42:30.012188  In IP truncated-ip - 24 bytes missing! 1.1.1.1 > 1.1.1.3: ICMP echo request, id 13080, seq 143, length 64

728x90
aggregated route는 단일 route announcement 에 여러 ip 경로를 보내는 것을 말한다. 간단히 말해서 경로를 요약해서 광고하는 것 이다.
 


Chardonnay는 Shiraz와 연결되어있고 BGP를 이용해서 라우팅 정보를 광고해야 한다. 이를 해결하기 위해 multiple
methods를 사용할 수 있지만 우리는 Shiraz에게 요약된 경로를 보내고 싶다. 이 요약된 경로는 Merlot, Cabernet, Riesling과 연결된 모든 고객들의 경로를 포함하고 있을 것이다. 가장 정확한 요약정보는 192.168.0.0./17 이고 이런 설정이 active 되면 요약된 경로들은 BGP로 재분배 및 광고가  될 것이다.
 
Contributing Routes

라우팅테이블에 aggregate route를 만드는 핵심포인트는 하나 이상의 contributing route 가 있느냐 없느냐 이다.
contributing route는 요약된 경로보다 더 구체적이면서 라우팅 테이블에 active되어 있는 경로를 말한다.  위의 그림에서 192.168.16.0/24, 192.168.32.0/24, 192.168.48.0/24 는 aggregate route ( 192.168.0.0/17)의 contributing route 이다.

user@Chardonnay> show route protocol aggregate detail
inet.0: 23 destinations, 25 routes (23 active, 0 holddown, 0 hidden)
192.168.0.0/17 (1 entry, 1 announced)
*Aggregate Preference: 130
Next hop type: Reject
State: <Active Int Ext>
Age: 23
Task: Aggregate
Announcement bits (2): 0-KRT 5-Resolve inet.0
AS path: I (LocalAgg)
Flags: Depth: 0 Active
AS path list:
AS path: I Refcount: 3
Contributing Routes (3):
192.168.16.0/24 proto Static
192.168.32.0/24 proto Static
192.168.48.0/24 proto Static 

 show route 명령어에 detail 이나  extensive 옵션을 사용하면 모든  aggregated route들을 확인 할 수 있다.

Next-Hop Options

 라우팅테이블에 있는 모든 경로들은 반드시 next-hop 이 유효해야 한다. aggregated route도 예외는 아니다.  static route와는 달리 오로지 2가지 옵션만 사용이 가능하다.

 reject 
   null값으로 설정되어 있고, reject가 선언된 구문에 매치되면 패킷을 드랍하고  ICMP는 "목적지가 도달불가능" 이라고
   메시지를 되돌려보냅니다. 디폴트로 설정되어 있다.
 discard
   null값으로 설정되어 있고, discard가 선언된 구문에 매치되면 패킷을 드랍시킨다.

Aggregate Route Attributes

static route에서 보았던 많은 어트리뷰트들이 aggregate route에서 볼 수 있다. 이는 JUNOS의 특성이다. 어트리뷰트 옵션을 알아보자
routing-options {
   aggregate {
       defaults {
         aggregate-options;
       }
       route destination-prefix {
          policy policy-name;
          aggregate-options;
       }
   }
}

active 
    next-hop이 사용불가능할 경우 라우팅 테이블에서 해당경로를 제거합니다. 디폴트로 설정되어 있습니다.
as-path
    static route에 수동으로 AS path를 설정하는 옵션이고 BGP로 재분배할때 유용합니다. 
brief
   모든 BGP contributing경로의 AS path 중에 가장 긴 common sequence를 가진 경로만 aggregate로 전송한다.
community
   BGP community값을 경로에 할당한다. 또한 경로 재분배할때 유용하다.
full
   모든 BGP contributing 경로의 AS path의 AS값이 aggregate 에 포함된다  기본적으로 설정되어 있다.
metric
   preference값이 동일할때 라우팅엔진이 어떤 경로를 선택할지 결정하기 위해 metric 값을 할당하는 옵션 
 

Configuration Examples

[edit routing-options]
user@Chardonnay# set aggregate route 192.168/17

이렇게 설정 하면 요로케 보인다..

[edit routing-options]
user@Chardonnay# show
   aggregate {
      route 192.168.0.0/17;
   }

지금의 설정에서는  attribute가 설정되어 있지 않다. 기본적으로 aggregate route 가  inet.0 라우팅 테이블에 등록이 될려면 적어도 하나의 contributing route가 필요하다.

contributing route를 입력하자.

routing-options {
    static {
        route 192.168.16.0/24 next-hop 1.1.1.1;
        route 192.168.32.0/24 next-hop 1.1.1.1;
        route 192.168.48.0/24 next-hop 1.1.1.1;

확인해보자

user@Chardonnay> show route protocol aggregate detail
inet.0: 11 destinations, 26 routes (11 active, 0 holddown, 0 hidden)
192.168.0.0/17 (1 entry, 1 announced)
*Aggregate Preference: 130
Next hop type: Reject
State: <Active Int Ext>
Age: 3
Task: Aggregate
Announcement bits (2): 0-KRT 5-Resolve inet.0
AS path: I (LocalAgg)
Flags: Depth: 0 Active
AS path list:
AS path: I Refcount: 3
Contributing Routes (3):
192.168.16.0/24 proto Static
192.168.32.0/24 proto Static
192.168.48.0/24 proto Static

[edit]
root@R1# run show route
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.0/17     *[Aggregate/130] 00:37:48
                               Reject

3개의  static route가 하나의 aggregate로 묶였다.

aggregate에서 default next-hop이  reject 이다.


728x90

JUNOS에서 static route 란 next hop을 사용자가 지정해준 경로를 말합니다. static route가 라우팅 테이블에 등록되기
위해서는 반드시  next hop  이 유효해야 합니다. (next hop이 다운 이라면 테이블에 등록이 안되겠죠~)  이는 즉, 라우터는
next hop을 사용하여 패킷을 포워딩 한다는 말 입니다.
static route는 토폴로지 변경이나 새로운 라우팅 정보에 영향을 받지 않고 테이블에서 삭제할 때 까지 라우팅 테이블에 존재합니다. 간단하게 예를들어 봅시다.


위 그림에서 Chardonnay는 192.168.16.0/24, 192.168.48.0/24, 192.168.32.0/24 네트워크와 연결되길 원합니다. 이 세가지 경로들은 각각 Merot, Cabernet, Riesling뒤에 위치하고 있고, Chardonnay 라우터에 각각의 경로에다 static route 설정을 했습니다..  
Chardonnay에 연결된 Riesling의 인터페이스가 next-hop 이 될 것이고 두 라우터 간의 링크가 Chardonnay 와의 연결 가능한 유일한 링크이기 때문에 이 설정은 잘 동작할 것이다. 만약 이 링크가 죽는다면 대체 링크는 없고 Chardonnay는 연결이 끊어질 것이다. 이 간단한 예제의 문제는 확장성(scalability)이 없다는 것이다. 만약 네트워크가  커진다면 Chardonnay는 네트워크가 커질 때 마다 관리자는 일일이 static route를 설정해줘야 한다.

단일링크 연결일 경우에는 static route가 좋은 방법중에 하나일 것이다. 밑의 그림을 보자 Shiraz는 AS65001의 경계라우터이고 5개의 고객사 라우터에 단일링크로 연결되어 있다. 각각의 라우터들은 AS65001을 통하여 인터넷 연결을 하고싶어 한다. 이럴 경우에는 static route가 좋은 방법이다. Shiraz는 5개의 static route 가 설정되어 있다. 5개의 static route들은 다이나믹 라우팅 프로토롤을 통해서 AS65001에 있는 다른 라우터들에게 광고가 된다.


각각의 고객 라우터들은 자신들이 연결하고 싶어하는 네트워크에 static route 설정을 하였다. 이런 연결 방법은 이전 예제와 같은 제약사항이 있다. 연결가능한 네트워크가 늘어날 때 마다 static route를 설정해 주어야 하기 때문이다. 한가지 해결 방법은 default route (0.0.0.0/0)를 설정하는 것이다. 이렇게 되면 각 고객들의 라우터에 있는 모든 네트워크는 인터넷에 연결이 가능하게 된다.  
그럼 지금부터 왜 static route가 필요한지, 어떻게 config를 해야하는지 자세히 알아봅시다~

Next-Hop Option

static route 를 사용할때 netxt-hop은 무조건 유효하거나 사용가능한 next-hop으로 설정해줘야 합니다. JUNOS는 6개의 next-hop 옵션을 제공합니다.
 
Directly connected IP address 
   물리적으로 연결된 서브넷의 IP Address은 static route의 next-hop으로 자주 사용됩니다. remote router와 연결된
   인터페이스는 패킷을 포워딩 할 때 사용합니다.
Remote IP address
   네트워크 안에 있는 다른 IP들 또한 next-hop으로 사용가능 합니다. 로컬 라우터는 inet.0 routing table에서 설정되어 있는
   Address로 가는 물리적 next-hop 을 찾기위해 recursive lookup을 수행합니다. IP를 선얼할때 resolve명령어를 사용하여
   이런 기능을 활성화 시킬 수 있습니다.
reject
   reject값은 null 로 설정되고 라우터가 라우팅 테이블을 lookup 할때  reject옵션이 쓰인 static route에 매칭이 된다면 
   매칭된 패킷은 드랍됩니다.
discard
   discard값은 null 로 설정되고 라우터가 라우팅 테이블을 lookup 할때 discard 옵션이 쓰인 static route에 매칭되면 
   매칭된 패킷은 드랍됩니다.
 qualified next hop 
   단일의 static route 에 next-hop으로 여러 IP Address를 할당 할 수 있다. qualified next hop을 설정하면 하나의 네트워크
    에 preference값만 다른 여러 경로가 라우팅 테이블에 보여진다.

          예)   192.168.1.0/24     *[Direct/0] 00:21:10
                                              > via em2.0
                                           [Static/100] 00:05:03
                                              > to 192.168.4.2 via em3.0
                                           [Static/110] 00:05:03
                                             > to 192.168.4.2 via em3.0
  Label switched path (LSP)
    MPLS가 설정된 네트워크에서는 static route는 LSP의 next-hop 값으로 설정할 수 있다. 이 next-hop 에 매칭되는 모든
    경로들은 IP address 가 아니라 Lable value 에 의해서 포워딩 된다. 자세한 내용은  MPLS 부분에서 확인하자.

Static Route Attributes

  next-hop값은 static route에 단 하나만 할당가능한 어트리뷰트 입니다. JUNOS에서는 static route에 다양한 파라미터 값을
  설정할 수 있습니다.  몇몇의 기능들은  static route 에 유용한 기능들이고 그 중에 preference 값은 floating static route 에
  사용됩니다. 다른 어트리뷰트들은 다이나믹 라우팅 프로토콜에 유용합니다. 예를들어 BGP는 static route에 할당된
  community 값을 사용합니다.
  이제 기본적인 static route 설정을 확인해 봅시다.

routing-options {
   static {
      defaults {
      static-options;
      }
   route destination-prefix{
         next-hop next-hop;
         qualified-next-hop address{
            metric metric;
            preference preference;
         }
         lsp-next-hop lsp-name{
            metric metric;
            preference preference;
            }
         static-options;
      }
   }
}


static route 어트리뷰트 들은 route부분은 실제 prefix부분이 설정되는 곳 입니다. next-hop 과 다른 모든 설정들이 각각의 route 부분에 들어갑니다.  default부분은 각각의 static routes들이 모두 동일한 설정값을 가질때 사용합니다. default 부분은 오로지 floating static route만 사용할 때 사용합니다. 각각의 경로에  preference 값을 설정하는 대신에 default 부분에 한번만 설정하면 각각의 경로는 default 부분에 선언된 어트리뷰트 값을 상속받아 사용합니다.

static route에 사용가능한 옵션값을 알아봅시다.

   active 
      next-hop이 사용불가능할 경우 라우팅 테이블에서 해당경로를 제거합니다. 디폴트로 설정되어 있습니다.
   as-path
      static route에 수동으로 AS path를 설정하는 옵션이고 BGP로 재분배할때 유용합니다. 
   community 
      BGP community값을 설정할 때 사용한다. 이것 또한 재분배할 때 유용하다.
   install
      패킷포워딩 엔진에 있는 포워딩 테이블에 사용가능한  static route 를 넣는다. 디폴트로 설정되어 있다.
   metric
      metric옵션을 사용하면 라우팅엔진이 static route에 설정된 메트릭 값을 참고하여 동일한 경로(같은 preference) 중에
      어떤 경로를 사용할지 결정한다. 
   no-install
      install옵션의 반대로 동작함.
   no-readvertise
      이 옵션은 외부에서 들어온  static route 경로가 라우팅 테이블에 올라가는 것과 라우팅 정책을 사용하여 다른 라우팅
      프로토콜로 재분배 되는 것을 막는다. 
   no-retain
      라우팅 프로세스가 shut down 되면 static route 가 포워딩 테이블에서 지워진다. 디폴트로 설정되어 있다. 
   passive
      active옵션의 반대로 동작
   readvertise
      no-readvertise옵션의 반대로 동작. 디폴트로 설정되어있다.
   retain
      no-retain 과 정반대로 동작함.

Configuration Examples

 


 192.168.16.0/24 네트워크에 연결하기 위해서 Chardonnay에 아래와 같은 설정이 필요하다.

[edit routing-options]
user@Chardonnay# show
     static {
         route 192.168.16.0/24 next-hop 1.1.1.1;
         }

 설정된 next-hop (1.1.1.1)이 바로 연결되어있는 인터페이스이기 때문에 static route는 active 상태가 되고  inet.0
 라우팅 테이블에서 볼 수 있다. 다음과 같은 명령어로 확인할 수 있다.

   user@Chardonnay> show route protocol static
   inet.0: 10 destinations, 15 routes (10 active, 0 holddown, 0 hidden)
   + = Active Route, - = Last Active, * = Both
   192.168.16.0/24 *[Static/5] 00:02:28
   > to 1.1.1.1 via fe-0/0/0.0

 나머지 네트워크도 동일한 방법으로 설정하면
inet.0: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.16.0/24 *[Static/5] 00:03:58
> to 1.1.1.1 via fe-0/0/0.0
192.168.32.0/24 *[Static/5] 00:01:14
> to 1.1.1.1 via fe-0/0/0.0
192.168.48.0/24 *[Static/5] 00:01:14
> to 1.1.1.1 via fe-0/0/0.0
요로케 될 것이다.


728x90
  
JUNOS software Configuration
 



     [edit protocols]
     user@Cabernet# show
     rip {
         group neighbor-routers {
                 neighbor fe-0/0/0.0
                 neighbor fe-0/0/1.0;
                 }
          }
     각각의 라우터마다 요런 config를 설정 해주고  show rip neighbor  명령어로 네이버들을 확인 할 수가 있다.

     user@Cabernet> show rip neighbor 

                              Source    Destination  Send   Receive     In
     Neighbor   State  Address    Address    Mode    Mode      Met
     ---------- ---    ---------  ---------- ------  ---------  ---
     fe-0/0/0.0  Up     172.16.1.2  224.0.0.9    mcast    both        1
     fe-0/0/1.0  Up     172.16.2.1  224.0.0.9    mcast    both        1
 
     user@Cabernet> show route protocol rip
     inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
     + = Active Route, - = Last Active, * = Both
     
     show route  protocol rip  명령어로 확인한 결과 어떠한  RIP 정보를 확인 할 수가 없다.
     이런 현상이 나타나는 이유는 JUNOS의 default advertisement 설정이 어떤 라우터에게도 광고를 하지 않도록 되어
     있기 때문이다. 그래서 꼭 routing policy설정이 필요하다.

Applying Export Policy
  
  기본적으로 RIP은 자신의 라우팅 테이블 정보를 자신의 네이버들에 전송하지 않는다. 라우팅 정보를 전송하기 위해서
  export policy가 필요하다. 라우팅 정책이 하나도 match 가 되지 않으면 default policy 정책이 적용되고  어떠한
  라우터에게도 export하지 않는다. 

  그룹레벨에 export 정책을 설정해보자

[edit policy-options]
user@Cabernet# show
policy-statement connected-routes {
  term advertise-routes {
     from protocol direct;
     then accept;
     }
}
policy-statement transit-rip-routes {
  term advertise-routes {
    from protocol rip;
    then accept;
    }
}
[edit protocols]
user@Cabernet# show
rip {
    group neighbor-routers {
      export [connected-routes transit-rip-routes];
      neighbor fe-0/0/0.0;
      neighbor fe-0/0/1.0;

이렇게 설정하면 Cabernet으로부터 오는 RIP라우터 정보를 Riesling 이 받을 수 있다.
user@Riesling> show route protocol rip
inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.2.0/24 *[RIP/100] 00:07:25, metric 2
> to 172.16.1.2 via fe-0/0/0.0
192.168.8.1/32 *[RIP/100] 00:07:25, metric 2
> to 172.16.1.2 via fe-0/0/0.0
192.168.24.1/32 *[RIP/100] 00:00:25, metric 3
> to 172.16.1.2 via fe-0/0/0.0


Applying Import Policy
 
  JUNOS는 인접해있는 네이버들로부터 받아오는 라우팅 정보를 필터링 할 수 있습니다. 임포트 정책을 사용하는
  경우는 원치않는 라우팅 정보를 차단하거나 받아오는 라우팅 정보의 Metric값 등을 수정할 때 사용합니다.  이렇게 
  들어오는 라우팅 정보를 가공하기 위해서는 반드시 rouing policy 를 선언해야 하며 선언된 라우팅 정책을  RIP
   configuration에 적용시켜야 됩니다. 만약 하나 이상의 라우팅 정책이 선언되면 첫번째 부터 마지막 정책 순서로 
   수행하고 처음으로 일치하는 라우팅 정책이 적용이 됩니다.  일치하는 라우팅 정책이 하나도 없다면 모든 RIP
   라우팅 정보를 받아들이게 됩니다.

[edit policy-options]
user@Cabernet# show
policy-statement filter-Riesling {
  term filter-routes {
     from {
       protocol rip;
       route-filter 192.168.0.0/16 orlonger;
       }
       then reject;
    }
 }

[edit protocols]
user@Cabernet# show
rip {
  group neighbor-routers {
    export [connected-routes transit-rip-routes];
    neighbor fe-0/0/0.0 {
        import filter-Riesling;
        }
    neighbor fe-0/0/1.0;
    }
}

이 설정에서 Cabernet은 Riesling 을 부터 오는 192.168.0.0/16 서브넷 정보를  reject 하고 neighbor절에
선언되어 있습니다.

Modifying the Incoming Metric

   라우팅 테이블의 메트릭값은 광고된 메트릭값 과 로컬 메트릭값을 더한 값 입니다. JUNOS의 로컬 메트릭값은
   기본으로 1로 설정되어 있고 metric-in 명령어를 사용하여 변경이 가능합니다.
  
  Cabernet으로 부터 받는 라우팅 정보의 메트릭 값을 5로  변경해 봅시다.

 [edit protocols]
user@Riesling# show
rip {
  group neighbor-routers {
    export [connected-routes];
    neighbor fe-0/0/0.0 {
      metric-in 5;
      }
   }
}
neighbor구문에 metric-in  명령어를  사용하여 metric 값을 5로 변경했습니다. 확인을 해봅시다~

user@Riesling> show route protocol rip
inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.2.0/24 *[RIP/100] 00:08:25, metric 6
> to 172.16.1.2 via fe-0/0/0.0
192.168.8.1/32 *[RIP/100] 00:08:25, metric 6
> to 172.16.1.2 via fe-0/0/0.0
192.168.24.1/32 *[RIP/100] 00:01:02, metric 7
> to 172.16.1.2 via fe-0/0/0.0

172.16.2.0 네트워크를 확인해 봅시다 기존에는 광고된 메트릭값 1 +  로컬 메트릭값 1 = 2 가 되었지만
로컬 메트릭값을 5 로 변경하였으므로 5+1 이 되어 6임을 확인 할 수 있습니다.

Modifying the Outgoing Metric
  
  metric-out 명령어를 사용하여 해당 라우터에서 나가는 모든 라우팅 정보 ( loop back 이나 직접연결된 서브넷 등)
  의 메트릭 값을 변결 할 수 있습니다. 

[edit protocols]
user@Shiraz# show
rip {
   group neighbor-routers {
      metric-out 3;
      export [connected-routes transit-rip-routes];
      neighbor fe-0/0/1.0;
      }
}
Shiraz에서 나가는 라우팅 정보의 메트릭 값을 3으로 변경.

user@Riesling> show route protocol rip
inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.2.0/24 *[RIP/100] 00:19:33, metric 6
> to 172.16.1.2 via fe-0/0/0.0
192.168.8.1/32 *[RIP/100] 00:19:33, metric 6
> to 172.16.1.2 via fe-0/0/0.0
192.168.24.1/32 *[RIP/100] 00:06:04, metric 9
> to 172.16.1.2 via fe-0/0/0.0

Configuration Authentication

   JUNOS 에서 authentication 은 default 설정이 disable 되어 있습니다. 인증설정은 글로벌하게 또는 피어 - 피어 
   로 설정이 가능합니다. 인증 설정을 하게 되면 인증 설정된 RIP라우터들끼리만 response message를 주고 
   받습니다.
   인증 설정을 위해서는 authentication-type 과   authentication-key 설정이 필요합니다. type는 인증방식을
   의미하고, key 는 password를 의미합니다.  인증 방식에는 두가지가 있고 다음과 같습니다.

     Simple authentication
        단순한 패스워드를 사용한 방식입니다. 패킷에 포함되어 전송되어지고 수신받은 라우터는 패스워드 값을
        확인해서  이 패킷을 인증 합니다. 이 방법은 암호화 방식이 적용이 안되어 있기 때문에 패킷 분석툴을
        이용하면 패스워드값을 알 수 있습니다.
    MD5 authentication
        해쉬알고리즘으로 패스워드를 암호화 하는 방식입니다. 암호화 되어 있기 때문에 패킷분석툴을 이용해도 
        패스워드 확인이 불가능합니다.  패스워드가 틀리면 해당 패킷을 폐기합니다.

[edit protocols]
user@Cabernet# show
rip {
   authentication-type md5;
   authentication-key " $9$09-4OhrW87Vs4xN"; # SECRET-DATA
   group neighbor-routers {
      export [connected-routes transit-rip-routes];
      neighbor fe-0/0/0.0;
      neighbor fe-0/0/1.0;
      }
}
글로벌하게 MD5 암호화 방식을 사용한 config 예제입니다.
key값은 암호화 되어진 채로 보여집니다.

Controlling Route Preference
 
   JUNOS에서 라우팅 테이블의 default preference값은 100으로 설정되어 있습니다. 라우팅 테이블에서 preference값을
   사용하는 이유는 여러 라우팅 프로토콜이 사용될 때 최적의 경로를 찾기 위해 사용됩니다. 로컬라우터는 가장 낮은
   preference값을 찾아서 forwarding table 에 등록합니다. preference값의 범위는 0 ~ 4294967295 입니다.
  
   preference값을 수정하기 위해서는  그룹 레벨에서 preference명령어를 사용합니다.  아래 예제는 Shiraz의 preference
   값을 90을 변경하는 예제 입니다.

[edit protocols]
user@Shiraz# show
rip {
    group neighbor-routers {
        preference 90;
        export [connected-routes transit-rip-routes];
        neighbor fe-0/0/1.0;
        }
}
user@Shiraz> show route protocol rip
inet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/24 *[RIP/90] 00:21:48, metric 2
> to 172.16.2.1 via fe-0/0/1.0
192.168.8.1/32 *[RIP/90] 00:21:48, metric 2
> to 172.16.2.1 via fe-0/0/1.0
192.168.16.1/32 *[RIP/90] 00:21:48, metric 3
> to 172.16.2.1 via fe-0/0/1.0

show route protocol rip  명령어를 사용하여 preference값이 90으로 변경된 것을 확일 할 수 있습니다.


Configuring Update Messages
    
    기본적으로,   모든 RIP라우터들은 자신들의 모든 네이버들에게 RIPv2 message를 멀티케스트를 이용해서 보낸다. 또한
    RIPv1, RIPv2 message 를 다 받을 수 있다. 
    receive명령을 사용하여 inbound default  설정을 변경 할 수 있고 send명령을 사용하여 outbound default 설정을 변경 할
    수 있다. 이 두 명령어들은 모두 global 혹은 neighbor 레벨에서 사용 가능하다.
   
     receive 옵션값
        both - RIPv1, RIPv2 패킷을 모두 받는다.
        none - RIPv1, RIPv2 패킷 모두 받지 않는다.
        version-1 - RIPv1 패킷만 받는다.
        version-2 -  RIPv2 패킷만 받는다.
    send 옵션값
       broadcast - RIPv2 패킷을 브로드케스트로 보낸다 (RIPv1 호환가능)
       multicast - RIPv2 패킷을 멀티케스트로 보낸다. 
       version-1 - RIPv1 패킷을 브로드케스트로 보낸다.
       none - RIP update를 보내지 않는다.

  
  그림에서 Merlot은 오로지  RIPv1 패킷만 사용이 가능하다. 그래서 Shiraz에게 receive, send 명령어를 사용하여 
  Melot과 통신하게 만들어보자 


[edit protocols]
user@Shiraz# show
rip {
   group neighbor-routers {
      export [connected-routes transit-rip-routes];
      neighbor fe-0/0/1.0;
      neighbor fe-0/0/2.0 {
         send version-1;
         receive version-1;
         }
     }
}

이제 Shiraz은 Melot과 RIPv1을 사용하여, Cabernet 과 RIPv2를 사용하여 통신이 가능하게 되었다. Shiraz는 자신의
네이버들에게 적절한 RIP update를 사용하여 통신을 하게된다.

Configuring the Number of Route Entries in an Update Message

   RIP update message 에는 기본적으로 25개의 라우팅 엔트리가 포함될 수 있다. 라우팅 엔트리 갯수는 각각의 update 
   message  마다 255개 까지 설정이 가능하다.
   message-size명령을 사용해서 Riesling라우터에게 update message 마다 100 개 의 라우팅 엔트리를 보낼 수 있게
   설정해보자.
 
   [edit protocols]
user@Riesling# show
rip {
   message-size 100;
   group neighbor-routers {
      export [connected-routes];
      neighbor fe-0/0/0.0 {
         metric-in 5;
         }
     }
  }
Accepting Packets Whose Reserved Fields Are Nonzero

  RIPv1과 RIPv2는 아주 흡사하다. 다른점이 있다면 RIPv1은 많은 필드들이 예약되어있다.  반면에 RIPv2는 RIPv1에서
  예약되어 있던 공간에 subnetmask, next-hop 등의 값들이 들어있다. RIPv1에서는 예약된 공간에 모두 0으로 채워놓고
  0이 아닌 값들이 들어오면 모두 폐기시켜버린다. RIPv2 라우터 또한 0으로 채워져야 할 필드에 다른 값들이 들어오면 
  해당 필드의 값을 폐기시킨다. JUNOS에서는 이러한 처리과정을 변경 할 수 있다. 왜나면 이러한 처리과정은 RFC1058,
  RFC2453에 어긋나기 때문이다. no-check-zero명령어를 사용하여 RFC에 규약에 어긋나지 않도록 설정이 가능하다.


user@Shiraz# show
rip {
   no-check-zero;
   group neighbor-routers {
      export [connected-routes transit-rip-routes];
      neighbor fe-0/0/1.0;
      neighbor so-1/0/0.0;
      }
}
  Shiraz가 인터페이스 so-1/0/0.0로 다른 네트워크와 연결되어 있다고 가정해보자 Shiraz는 표준을 지키지 않는다.
  (JUNOS default 설정때문에)  그래서  가능한 모든  RIP패킷을 수신하기 위해 ( RFC에 나와있는 표준)  no-check-zero
  명령어를 사용한다.


- 참고 : Juniper JNCIA studyguide 

+ Recent posts

티스토리툴바