Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

PPP 가입자 액세스 네트워크 개요

PPP 가입자 인터페이스에 대한 동적 프로필 개요

가입자 관리 PPP 지원을 통해 PPP 가입자 인터페이스에 대한 동적 프로필을 생성하고 첨부할 수 있습니다. PPP 가입자가 로그인하면 라우터는 지정된 동적 프로필을 인스턴스화한 다음 프로필에 정의된 속성을 인터페이스에 적용합니다.

동적 프로필은 정적 및 동적 PPP 인터페이스 모두에 사용됩니다. 정적 PPP 인터페이스의 경우, CLI를 사용하여 PPP 옵션을 지정하는 동적 프로파일을 연결할 수 있습니다. 동적 PPP 인터페이스의 경우, 동적 프로필은 PPP 옵션을 포함한 인터페이스를 생성합니다.

참고:

동적으로 생성된 인터페이스는 PPPoE 인터페이스에서만 지원됩니다.

기존 PPP 지원과 달리 가입자 관리는 양방향 PPP 인증을 허용하지 않으며, 인증은 라우터에 의해서만 수행되고 원격 피어에 의해서만 수행되지 않습니다. 라우터의 AAA 프로세스는 가입자 관리를 위한 인증 및 주소 할당을 관리합니다. 동적 프로필에 대한 PPP 옵션을 구성할 때 CHAP(Challenge Handshake Authentication Protocol) 또는 PAP(Password Authentication Protocol) 인증을 구성할 수 있으며 라우터가 CHAP 및 PAP 프로토콜을 협상하는 순서를 제어할 수 있습니다. 또한 CHAP 인증의 경우 CHAP 챌린지 메시지의 기본 길이를 수정할 수 있습니다. 다른 PPP 옵션은 기존 PPP 인터페이스 구성에 일반적으로 사용되거나 필수이며, 가입자 관리 동적 프로파일에서 지원되지 않습니다.

라우터가 가입자 시작 PPP Fast Keepalive 요청을 처리하는 방법 이해하기

MPCs/MICs(Modular Port Concentrators/Modular Interface Cards)를 사용하는 MX 시리즈 라우터에서 MPC/MIC의 패킷 전달 엔진은 PPP 가입자(클라이언트)가 시작하여 라우터로 전송하는 LCP(Link Control Protocol) 에코 요청 패킷을 처리하고 응답합니다. LCP 에코 요청 패킷 및 LCP 에코 응답 패킷은 링크가 제대로 작동하는지 확인하는 데 도움이 되는 PPP 킵얼라이브 메커니즘의 일부입니다.

이전에는 LCP 에코 요청 패킷 및 LCP 에코 응답 패킷이 라우팅 엔진에 의해 MX 시리즈 라우터에서 처리되었습니다. LCP 에코 요청 패킷이 라우팅 엔진 대신 패킷 전달 엔진에 의해 처리되는 메커니즘을 PPP 패스트 킵얼라이브라고 합니다.

PPP Fast Keepalives의 이점

  • PPP Fast keepalive는 처리를 위해 LCP 패킷을 라우팅 엔진으로 보낼 필요 없이 패킷 전달 엔진이 PPP 가입자로부터 LCP 에코 요청 패킷을 수신하고 LCP 에코 응답 패킷으로 응답할 수 있도록 하여 킵얼라이브 교환에 필요한 시간을 줄여줍니다.

  • PPP Fast keepalives는 라우터에서 증가된 대역폭을 제공하여 라우팅 엔진이 LCP 에코 요청 및 에코 응답 패킷을 처리할 필요가 없도록 함으로써 향상된 성능으로 더 많은 수의 가입자를 지원합니다.

  • PPP Fast Keepalive는 협상된 매직 넘버를 사용하여 라우터 또는 네트워크 문제에 대한 잠재적인 트래픽 루프백을 식별합니다. PPP 원격 피어가 협상된 번호가 아닌 임의의 번호를 사용하는 경우와 같이 원치 않는 PPP 세션 종료를 방지하기 위해 필요한 경우 검증을 비활성화할 수도 있습니다.

PPP Fast Keepalive 처리 작동 방식

패킷 전달 엔진에서 PPP Fast keepalive 요청을 처리하기 위해 MPCs/MIC가 있는 MX 시리즈 라우터에서 특별한 구성이 필요하지 않습니다. 이 기능은 기본적으로 활성화되어 있으며 비활성화할 수 없습니다.

다음 시퀀스는 MX 시리즈 라우터가 MPC/MIC의 패킷 전달 엔진에서 LCP 에코 요청 패킷 및 LCP 에코 응답 패킷을 처리하는 방법을 설명합니다.

  1. 라우팅 엔진은 PPP 논리적 인터페이스에서 keepalive 요청의 전송이 활성화되면 패킷 전달 엔진에 알립니다. 알림에는 서버와 원격 클라이언트 모두의 매직 넘버가 포함됩니다.

  2. 패킷 전달 엔진은 PPP 가입자(클라이언트)가 시작한 LCP 에코 요청 패킷을 수신합니다.

  3. 패킷 전달 엔진은 LCP 에코 요청 패킷에서 피어 매직 넘버를 검증하고 라우터가 협상한 매직 넘버가 포함된 해당 LCP 에코 응답 패킷을 전송합니다.

  4. 패킷 전달 엔진이 링크에서 루프 상태를 감지하면 추가 처리를 위해 LCP 에코 요청 패킷을 라우팅 엔진으로 보냅니다.

    라우팅 엔진은 루프 조건이 해결될 때까지 LCP 에코 요청 패킷을 계속 처리합니다.

라우터의 패킷 전달 엔진에서 keepalive 요청 전송은 현재 활성화되어 있지 않습니다.

PPP Fast Keepalive에 대한 통계 표시

MPCs/MICs가 있는 MX 시리즈 라우터가 PPP 링크에 PPP fast keepalive를 사용하는 경우, Keepalive statistics 운영 명령의 출력에 show interfaces pp0.logical statistics 있는 필드에는 수신 또는 전송된 keepalive 패킷 수 또는 라우터가 마지막 keepalive 패킷을 수신 또는 전송한 이후의 시간에 대한 통계가 포함되지 않습니다.

포워딩 클래스 구성 변경의 영향

라우팅 엔진에서 생성된 아웃바운드 트래픽에 대한 기본 대기열 할당(포워딩 클래스)을 변경하려면 계층 수준에서 문을 [edit class-of-service host-outbound-traffic] 포함할 forwarding-class class-name 수 있습니다.

MPCs/MICs가 있는 MX 시리즈 라우터와 PPP 클라이언트 간에 전송되는 PPP 빠른(인라인) keepalive LCP 에코 요청 및 LCP 에코 응답 패킷의 경우, 포워딩 클래스 구성 변경은 구성 변경 후 생성된 새로운 PPP-over-Ethernet(PPPoE), PPP-over-ATM(PPP-over-ATM) 및 L2TP 네트워크 서버(LNS) 가입자 세션 모두에 즉시 적용되며, 기존 PPPoE, PPPoA의 경우 및 구성 변경 전에 설정된 LNS 가입자 세션.

매직 넘버 불일치 무시

패킷 전달 엔진은 수신된 LCP 에코 요청 패킷에서 피어 매직 넘버를 검증할 때 매직 넘버가 예상치 못한 것인지 여부를 확인합니다. 수신된 번호는 LCP 협상 중에 합의된 원격 피어의 번호와 일치해야 합니다. 원격 피어 번호는 로컬 피어 번호와 달라야 합니다. 동일할 경우 루프백 조건(트래픽이 로컬 피어로 루프백됨) 또는 일부 다른 네트워크 문제가 존재할 것으로 예상됩니다.

검증 검사에서 불일치가 존재한다고 판단하면, 즉 수신된 원격 피어 번호가 협상된 번호와 다르다는 것을 의미하며, 패킷 전달 엔진은 실패한 에코 응답 패킷을 라우팅 엔진으로 보냅니다. 유효한 매직 넘버를 가진 에코 응답이 특정 간격 내에 수신되지 않으면 PPP는 이를 keepalive 실패로 간주하고 PPP 세션을 중단합니다.

일부 고객 장비는 로컬 매직 넘버를 협상하지 않고 대신 keepalive 패킷에서 라우터로 보내는 매직 넘버로 임의의 값을 삽입할 수 있습니다. 이 숫자는 불일치로 식별되며 세션은 결국 삭제됩니다. Junos OS 릴리스 18.1R1부터는 매직넘버 검증 검사를 수행하지 않도록 라우터를 구성하여 이러한 결과를 방지할 수 있습니다. 불일치가 식별되지 않기 때문에 라우터는 원격 피어와 PPP keepalive 패킷을 계속 교환합니다. 이 동작을 구성하려면 L2TP 그룹 프로필, 라우터에서 종료된 동적 PPP 가입자 연결의 동적 프로필 또는 LNS의 동적 터널링된 PPP 가입자의 동적 프로필에 명령문을 포함합니다 ignore-magic-number-mismatch .

CPE 디바이스에 대한 RADIUS 소스 연결 상태 업데이트

Junos OS 릴리스 20.2R1부터 RADIUS 소싱 메시지를 사용하여 BNG가 홈 게이트웨이와 같은 CPE 디바이스로 투명하게 전달하는 정보를 전달할 수 있습니다. 예를 들어, 이 정보는 업스트림 대역폭 또는 CPE 디바이스에 필요한 다른 연결 속도 매개변수일 수 있습니다. 이 기능은 트래픽 관리를 가입자에 최대한 가깝게 동적으로 적용하려는 경우에 유용합니다.

일반적으로 RADIUS 표준 속성 Reply-Message(18)를 사용하여 PPP 인증 중에 이 정보를 CPE 디바이스에 전달할 수 있습니다. 그러나 이미 해당 속성을 다른 용도로 사용하고 있는 경우 주니퍼 네트웍스 Connection-Status-Message VSA(26-4874–218)를 사용할 수도 있습니다. 이 VSA는 Reply-Message 특성(18)에 대한 논리적 확장이며 형식과 의미 체계가 동일합니다.

PPP는 LCP에 대한 주니퍼 네트웍스 벤더별 확장을 사용하여 Connection-Status-Message VSA의 내용을 피어 홈 게이트웨이로 보냅니다. PPP는 LCP Connection-Update-Request 메시지의 Connection-Status-Message 옵션에 이 정보를 포함합니다.

RADIUS는 다음과 같은 방법으로 Connection-Status-Message VSA를 인증에 전송할 수 있습니다.

  • PPP 세션의 협상 및 권한 부여 중 RADIUS Access-Accept 메시지에서

  • 활성 PPP 세션에 대한 RADIUS CoA 요청 시

비즈니스 또는 가정용 가입자를 위한 지정된 세션에 대해 이 두 가지 방법을 모두 사용할 수 있습니다. Access-Accept 메시지는 초기 연결 매개 변수를 제공합니다. CoA 기능을 사용하면 세션 수명 동안 필요에 따라 연결 속도 매개 변수를 업데이트할 수 있습니다. Connection-Status-Message VSA에 전달되는 정보는 일반적으로 동적 서비스 프로필 또는 해당 ANCP Port Up 메시지와 같은 로컬 구성에 의해 적용되는 트래픽 속도입니다.

참고:

동적 클라이언트 프로파일에 lcp-connection-update PPP 옵션을 포함하지 않으면, PPP는 인증의 알림을 처리하지만 아무런 조치도 취하지 않습니다. 라우터의 LCP가 열림 상태가 아닌 경우 PPP는 VSA에 대해 아무 작업도 수행하지 않습니다.

다음 단계에서는 RADIUS가 Access-Accept 메시지에서 VSA를 전송할 때 발생하는 상황에 대해 설명합니다.

  1. 인증 프로세스는 RADIUS 서버로부터 Access-Accept 메시지로 Connection-Status-Message VSA를 수신합니다.

  2. 인증 프로세스는 Connection-Status-Message VSA를 PPP(jpppd)로 보냅니다.

  3. PPP NCP 협상은 원격 게이트웨이 PPP 클라이언트와 라우터의 PPP 간에 이루어집니다.

  4. 협상에 성공하면 가족 활성화 요청이 이루어집니다. PPP 세션은 패밀리가 활성화될 때 세션 업 상태로 들어갑니다.

  5. 동적 클라이언트 프로파일에 PPP 옵션이 포함되어 lcp-connection-update 있고 라우터의 LCP가 열림 상태인 경우, PPP는 LCP Connection-Update-Request 메시지를 게이트웨이로 보냅니다. 이 메시지에는 Connection-Status-Message 옵션의 VSA 정보가 포함됩니다.

    • 게이트웨이가 LCP Connection-Update-Request를 지원하는 경우 LCP Connection-Update-Ack 메시지를 라우터에 반환합니다. 홈 게이트웨이 LCP는 요청을 수신할 때 열림 상태여야 하며, 그렇지 않으면 요청을 삭제합니다.

    • 게이트웨이가 LCP Connection-Update-Request를 지원하지 않는 경우 LCP Code-Reject 메시지를 라우터에 반환합니다.

    참고:

    게이트웨이가 응답하지 않으면 라우터는 업데이트 요청을 다시 시도합니다. 시도 사이에 3초 간격으로 최대 10회의 재시도의 PPP 기본값을 사용합니다.

    참고:

    동적 클라이언트 프로파일에 lcp-connection-update PPP 옵션을 포함하지 않으면, PPP는 인증의 알림을 처리하지만 아무런 조치도 취하지 않습니다. 옵션이 있지만 라우터의 LCP가 열림 상태가 아닌 경우 PPP는 VSA와 관련하여 아무 조치도 취하지 않습니다.

다음 단계에서는 RADIUS가 CoA 요청에서 VSA를 보낼 때 어떤 일이 발생하는지 설명합니다. 여기서는 NCP 협상이 이미 성공했고 세션이 활성 상태라고 가정합니다.

  1. 인증된 프로세스는 RADIUS 서버로부터 CoA 요청으로 Connection-Status-Message VSA를 수신합니다.

  2. 인증 프로세스는 Connection-Status-Message VSA를 PPP(jpppd)로 보냅니다.

  3. 동적 클라이언트 프로파일에 PPP 옵션이 포함되어 lcp-connection-update 있고 라우터의 LCP가 열림 상태인 경우, PPP는 LCP Connection-Update-Request 메시지를 게이트웨이로 보냅니다. 이 메시지에는 Connection-Status-Message 옵션의 VSA 정보가 포함됩니다.

    • 게이트웨이가 LCP Connection-Update-Request를 지원하는 경우 LCP Connection-Update-Ack 메시지를 라우터에 반환합니다. 홈 게이트웨이 LCP는 요청을 수신할 때 열림 상태여야 하며, 그렇지 않으면 요청을 삭제합니다.

    • 게이트웨이가 LCP Connection-Update-Request를 지원하지 않는 경우 LCP Code-Reject 메시지를 라우터에 반환합니다.

    참고:

    게이트웨이가 응답하지 않으면 라우터는 업데이트 요청을 다시 시도합니다. 시도 사이에 3초 간격으로 최대 10회의 재시도의 PPP 기본값을 사용합니다.

홈 게이트웨이가 Connection-Update-Request 메시지를 수신하지 못하면 라우터는 메시지 전송을 다시 시도합니다. 또한 라우터는 게이트웨이에서 Connection-Update-Ack 또는 LCP Code-Reject를 다시 수신하지 못하거나 Ack 메시지에 문제가 있는 경우 요청을 다시 시도합니다. 기본 재시도 간격은 3초입니다. 라우터는 종료되기 전에 메시지를 기본값인 최대 10회까지 다시 시도합니다. 라우터가 적절한 Connection-Update-Ack 메시지를 수신하지 않고 모든 재시도 시도를 소진하면 PPP Code-Reject 메시지를 수신한 것처럼 메시지를 기록합니다.

참고:

RADIUS는 Access-Accept 메시지 또는 CoA 요청에 Connection-Status-Message VSA의 여러 인스턴스를 포함할 수 있습니다. 이 경우 authd는 첫 번째 인스턴스만 사용하고 다른 인스턴스는 무시합니다.

Access-Accept 또는 CoA 요청에는 Connection-Status-Message VSA 외에 다른 속성이 포함될 수 있지만 VSA와 다른 속성 간에는 상호 종속성이 없습니다. 메시지에 Activate-Service(26–65) 또는 Deactivate-Service(26–66) VSA가 포함된 경우에도 마찬가지입니다. 종속성이 없다는 것은 인증이 다른 속성을 성공적으로 적용하지 못하더라도 연결 정보를 PPP로 전송하고, PPP는 VSA 콘텐츠를 홈 게이트웨이로 전송한다는 것을 의미합니다.

마찬가지로 authd는 PPP가 Connection-Status-Message VSA의 내용을 원격 게이트웨이에 성공적으로 전달하는지 여부에 관계없이 다른 모든 속성을 적용하고 CoA 응답을 반환합니다. 이는 CoA에 Connection-Status-Message VSA만 포함된 경우에도 마찬가지입니다. 모든 게이트웨이가 이 기능에 사용된 LCP 확장을 수락하는 것은 아니므로 이 기능이 필요합니다.

메시지 및 옵션 형식

그림 1 은 Connection-Update-Request 및 Connection-Update-Ack 메시지의 형식을 보여줍니다. 형식은 동일하지만 표 1은 두 메시지에 대해 일부 필드 값이 다르다는 것을 보여줍니다.

그림 1: Connection-Update-Request 및 Connection-Update-Ack 메시지 형식 Connection-Update-Request and Connection-Update-Ack Message Format
표 1: Connection-Update-Request 및 Connection-Update-Ack 메시지의 필드 값

필드

연결-업데이트-요청

연결-업데이트-ack

코드

공급업체별 경우 0

공급업체별 경우 0

식별자

공급업체별 패킷 식별자

Connection-Update-Request 메시지와 동일한 식별자입니다. 이 값이 일치하지 않으면 라우터는 오류를 기록하고 패킷을 삭제합니다. 이렇게 하면 게이트웨이가 요청 메시지를 받지 못한 것처럼 요청 메시지를 다시 시도할 수 있습니다.

길이

패킷의 바이트 수: 12에 Connection-Status-Message 옵션의 길이를 더한 값

Connection-Update-Ack 패킷의 바이트 수: 12

매직 넘버

로컬 PPP 매직 넘버에 대한 협상 값

로컬 PPP 매직 넘버에 대한 협상 값

OUI(조직 고유 식별자)

주니퍼 네트웍스의 경우 00-21-59

주니퍼 네트웍스의 경우 00-21-59

종류

세션 업데이트의 경우 1

Session-ACK의 경우 2입니다. 다른 값의 경우 라우터는 오류를 기록하고 패킷을 삭제합니다. 이렇게 하면 게이트웨이가 요청 메시지를 받지 못한 것처럼 요청 메시지를 다시 시도할 수 있습니다.

TLV 형식의 Connection-Status-Message 옵션

지원되는 값이 없습니다.

PPP 매직 넘버가 어떻게 사용되는지 구성할 수 있습니다.

  • PPP 옵션을 구성 ignore-magic-number-mismatch 하면 매직 넘버가 검증되지 않습니다. PPP는 요청의 매직 넘버와 Ack 메시지 간의 불일치를 무시합니다. 다른 검증 오류가 없는 경우, PPP는 Connection-Update-Ack 메시지를 수락합니다.

  • PPP 옵션을 구성 ignore-magic-number-mismatch 하지 않으면 매직 넘버가 검증을 거칩니다. Ack 메시지의 매직 넘버가 LCP 협상 중에 설정된 게이트웨이의 매직 넘버와 일치하지 않으면 라우터는 오류를 기록하고 Connection-Update-Ack 메시지를 잘못된 응답으로 삭제합니다. 이렇게 하면 게이트웨이가 요청 메시지를 받지 못한 것처럼 요청 메시지를 다시 시도할 수 있습니다.

매직 넘버에 대한 자세한 정보는 PPP Keepalive 교환 중 PPP 매직 넘버 검증 방지 를 참조하십시오.

그림 2 는 Connection-Status-Message 옵션의 형식을 보여줍니다. 표 2 에는 필드 값이 나열되어 있습니다.

그림 2: Connection-Status-Message 옵션 형식 Connection-Status-Message Option Format
표 2: connection-status-message 옵션의 필드 값

필드

형식

1

길이

옵션의 바이트 수; 2에 메시지 길이를 더합니다. 메시지 길이는 1바이트에서 247바이트 사이일 수 있습니다.

상태 메시지

Connection-Status-Message VSA의 내용

PPP에 대한 동적 프로필 구성

동적 프로필은 클라이언트 액세스(예: 인터페이스 또는 프로토콜) 또는 서비스(예: IGMP)에 대한 속성을 포함하는 구성을 생성, 업데이트 또는 제거할 수 있는 템플릿 역할을 합니다. 동적 프로필을 사용하면 클라이언트(그리고 클라이언트 그룹)의 모든 공통 속성을 통합하고 동시에 속성을 적용할 수 있습니다.

동적 프로파일이 생성된 후 프로필은 라우터의 프로파일 라이브러리에 상주합니다. 그런 다음 명령문을 사용하여 dynamic-profile 인터페이스에 프로필을 연결할 수 있습니다. 동적 프로필을 PPP 인터페이스에 할당하려면 계층 수준에서 명령문을 [edit interfaces interface-name unit logical-unit-number ppp-options] 포함할 dynamic-profile 수 있습니다.

구성을 모니터링하려면 명령을 실행합니다 show interfaces interface-name .

동적 프로필에 대한 정보는 Junos 가입자 액세스 구성 가이드동적 프로필 개요를 참조하십시오.

동적 프로필 생성에 대한 정보는 Junos 가입자 액세스 구성 가이드기본 동적 프로필 구성을 참조하십시오.

PPP 인터페이스에 동적 프로필을 할당하는 방법에 대한 자세한 내용은 Junos 가입자 액세스 구성 가이드정적 PPP 가입자 인터페이스에 동적 프로필 연결을 참조하십시오.

동적 프로필을 사용하여 PPP 가입자를 인증하는 방법에 대한 정보는 PPP 가입자를 위한 동적 인증 구성을 참조하십시오.

참고:

PPP 가입자의 동적 프로필은 이 릴리스의 PPPoE 인터페이스에서만 지원됩니다.

PPP Keepalive 교환 중 PPP 매직 넘버의 검증 방지

PPP 매직 넘버는 LCP 협상 중에 피어 간에 협상됩니다. 피어는 서로 다른 매직 넘버를 가져야 합니다. 숫자가 동일하면 로컬 피어에서 보낸 트래픽에 루프백이 있을 수 있음을 나타냅니다. 이 경우 로컬 피어는 원격 피어에 새 번호를 보냅니다. 원격 피어에서 반환된 매직 넘버가 로컬 피어에서 보낸 최신 번호와 다르면 숫자가 일치합니다. 그렇지 않으면 매직 넘버 교환은 유효한(다른) 번호가 수신되거나 프로세스 시간이 초과될 때까지 계속되며, 이 경우 세션이 삭제됩니다.

숫자가 합의된 후 피어는 PPP keepalive(Echo-Request/Echo-Reply) 패킷을 교환할 때 각각의 매직 넘버를 포함합니다. 패킷 전달 엔진은 각 교환에 대해 수신된 매직 넘버를 검증합니다. 원격 피어에서 수신한 PPP 매직 넘버가 LCP 협상 중에 합의된 값과 일치하지 않을 때 불일치가 발생합니다. 검증 검사에서 불일치가 있다고 판단하면 패킷 전달 엔진은 실패한 에코 요청 패킷을 라우팅 엔진으로 보냅니다. 유효한 매직 넘버를 가진 에코 응답이 특정 간격 내에 수신되지 않으면 PPP는 이를 keepalive 실패로 간주하고 PPP 세션을 중단합니다.

경우에 따라 이 동작은 바람직하지 않습니다. 일부 고객 장비는 로컬 매직 넘버를 협상하지 않습니다. 대신 keepalive 패킷에서 라우터로 보내는 매직 넘버로 임의의 값을 삽입합니다. 기본적으로 이 숫자는 불일치로 식별되며 세션은 결국 삭제됩니다. 이 결과는 패킷 전달 엔진이 매직 넘버 유효성 검사를 수행하지 못하도록 하여 방지할 수 있습니다. 불일치가 식별되지 않기 때문에 라우터는 원격 피어와 PPP keepalive 패킷을 계속 교환합니다.

동적 PPP 프로필, L2TP LNS 동적 프로필 또는 L2TP 그룹 프로필에 적용된 PPP 옵션 중 하나로 문을 포함하여 ignore-magic-number-mismatch 매직 넘버 유효성 검사를 비활성화합니다. 원격 피어 매직 넘버가 예상 협상 번호인 경우 이 명령문을 구성해도 LCP 매직 넘버 협상 또는 keepalive 교환에 영향을 주지 않습니다.

참고:

매직 넘버 검증이 수행되지 않기 때문에 패킷 전달 엔진은 원격 피어가 로컬 피어의 매직 넘버를 전송하는지 여부를 감지하지 못하며, 이는 루프백 또는 기타 네트워크 문제를 나타냅니다. LCP 협상이 성공적으로 완료되어 당시에 루프백이 없었기 때문에 이는 가능성이 낮은 상황으로 간주됩니다.

패킷 전달 엔진이 매직 넘버의 불일치를 감지하지 못하도록 동적 프로필을 구성하려면 다음을 수행합니다.

PPP 옵션을 구성합니다.

  • 라우터에서 종료된 동적 PPP 가입자 연결의 경우:

  • LNS 인라인 서비스 인터페이스에서 동적 터널링된 PPP 가입자의 경우:

명령을 사용하여 매직 넘버가 show ppp interface interface-name extensive 무시되는지 여부를 확인할 수 있습니다.

CPE 디바이스에 대한 RADIUS 소스 연결 상태 업데이트를 구성하는 방법

RADIUS 소스 메시지를 사용하여 BNG가 홈 게이트웨이와 같은 CPE 디바이스로 투명하게 전달하는 정보를 전달할 수 있습니다. 예를 들어, 이 정보는 업스트림 대역폭 또는 CPE 디바이스에 필요한 다른 연결 속도 매개변수일 수 있습니다.

이 기능을 활성화하면 PPP는 RADIUS Access-Accept 메시지 또는 CoA 메시지에서 인증으로 수신된 Connection-Status-Message VSA(26–218)에서 작동할 수 있습니다. 그런 다음 PPP는 LCP Connection-Update-Request 메시지의 VSA 내용을 원격 피어로 전달합니다. 이 작업을 수행하려면 다음 조건이 충족되어야 합니다.

  • 적어도 첫 번째 주소 패밀리가 성공적으로 협상되었고 세션이 활성 상태입니다.

  • 라우터 LCP가 열림 상태입니다.

그렇지 않으면 PPP는 VSA에서 아무런 조치도 취하지 않습니다. 옵션을 활성화 lcp-connection-update 하지 않으면 PPP는 인증의 알림을 처리하지만 아무런 조치도 취하지 않습니다.

CPE 디바이스를 사용하는 가입자와 연관된 동적 클라이언트 프로필에서 이 기능을 구성합니다. 실제로 클라이언트 프로필의 다른 여러 기능에 이 기능을 추가하고 있습니다. 이 예에서는 이 기능에 대한 특정 구성만 보여 줍니다. 또한 이 기능을 사용하려면 RADIUS 서버에서 VSA 26-218을 구성해야 합니다. 이는 이 설명서의 범위를 벗어납니다.

PPP 가입자 인터페이스에 대한 동적 프로필에서 연결 상태 업데이트를 구성하려면:

  1. 클라이언트 프로필에서 PPP 옵션을 편집합니다.
  2. 연결 상태 업데이트를 사용하도록 설정합니다.

PPP 논리적 인터페이스에 대한 명령을 사용하여 show ppp interface extensive LCP 연결 업데이트의 성공 여부를 확인할 수 있습니다. 명령으로 관련 통계를 모니터링할 수 있습니다 show system subscriber-management statistics ppp .

동적 프로필을 정적 PPP 가입자 인터페이스에 연결

동적 프로필을 정적 PPP 가입자 인터페이스에 연결할 수 있습니다. PPP 가입자가 로그인하면 지정된 동적 프로필이 인스턴스화되고 프로필에 정의된 서비스가 인터페이스에 적용됩니다.

동적 프로필을 정적 PPP 가입자 인터페이스에 연결하려면 다음을 수행합니다.

  1. PPP 옵션을 구성할 것을 지정합니다.
  2. 인터페이스와 연결할 동적 프로필을 지정합니다.

정적 PPP 가입자 구성을 동적 프로파일로 마이그레이션 개요

이 주제에서는 동적 프로필을 사용하여 특정 정적 종료 IPv4 PPP 가입자 구성을 동적 구성으로 마이그레이션하기 위한 몇 가지 고려 사항에 대해 설명합니다. 레거시 Junos OS 릴리스(Junos OS 릴리스 15.1R4 이전)를 사용하여 라우터에서 정적 가입자를 관리하는 서비스 프로바이더는 향상된 가입자 관리(Junos OS 릴리스 15.1R4 이상 릴리스)를 실행하는 라우터에서 동적 프로필로 관리되도록 정적 가입자를 마이그레이션하기 위한 요구 사항이 있습니다. Junos OS 릴리스 18.2R1부터 이러한 정적 서비스 프로바이더 구성을 동적 프로필로 쉽게 전환할 수 있도록 몇 가지 개선 사항이 추가되었습니다.

로컬 인증

정적 구성을 사용하는 일부 공급자는 CHAP 또는 PAP가 아닌 인증 프로토콜을 지원하지 않는 CPE 장치를 사용할 수 있습니다. 프로바이더는 정적 PPPoE 논리적 인터페이스에서 가입자를 인증하고 권한을 부여하기 위한 기본적인 방법으로 PPPoE 서비스 이름 테이블을 사용할 수 있습니다. 가입자 ACI 또는 ARI가 테이블 항목과 일치하지 않으면 PPP PADI 및 PADR 패킷이 일반적으로 삭제됩니다. 레거시 Junos OS 릴리스는 인증 방법에 대해 인증 없이 구성된 가입자를 지원하지 않습니다.

CPE가 PAP 및 CHAP와 같은 인증 프로토콜을 지원하지 않는 가입자의 경우 사용자 이름과 비밀번호를 로컬로 구성할 수 있습니다. 라우터는 인증을 위해 RADIUS 서버에 연결할 때 이러한 값을 사용합니다.

  • 로컬 인증을 위한 사용자 이름을 구성하려면 동적 논리적 인터페이스에 대한 PPP 옵션에 명령문을 포함합니다 username-include . MAC 주소, 상담원 서킷 ID, 상담원 원격 ID 및 도메인 이름 속성 중 하나 이상을 기반으로 이름을 정의할 수 있습니다. 기본적으로 마침표(.)는 이름 요소 사이의 구분 기호이지만 대신 다른 문자를 정의할 수 있습니다.

  • 로컬 인증을 위한 비밀번호를 구성하려면 동적 논리적 인터페이스에 대한 PPP 옵션에 명령문을 포함합니다 password .

동일한 동적 프로필을 사용하여 인증 프로토콜을 지원하지 않는 CPE와 지원하는 CPE를 모두 지원할 수 있습니다.

CPE 소스 주소 할당

일부 정적 구성의 경우, 라우터에서 RADIUS 또는 로컬 주소 풀을 사용하여 가입자 주소가 할당되지 않습니다. 대신 CPE에는 가입자에 대해 구성된 고정 주소가 있습니다. IPCP 협상 중에 CPE는 라우터에 해당 주소를 가입자에게 할당하도록 요청합니다.

Junos OS 릴리스 18.2R1부터 RADIUS 서버 구성의 Framed-Route-Address 속성 [8]에 와일드카드 주소 255.255.255.255를 할당할 수 있습니다. RADIUS가 해당 값을 가진 속성을 반환하면 jpppd는 다른 주소를 할당하는 대신 IPCP configure-request 메시지에서 클라이언트가 제공하는 가입자 IP 주소 할당을 자동으로 수락합니다.

Tag2 경로 속성

일부 구성에서는 정적 PPP 가입자 인터페이스가 서로 다른 VRF로 구성됩니다. 각 VRF 구성에는 다음 홉 주소로 정적 PPP 가입자 인터페이스를 가리키는 정적 경로가 있습니다. 이러한 경로에는 tag2 속성이 구성되어 있을 수 있습니다. MP-BGP는 경로를 보급할 때 적절한 로컬 기본 설정과 커뮤니티를 적용해야 합니다.

Junos OS 릴리스 18.2R1부터 가입자를 인증할 때 Framed-Route 속성 [22]에 tag2 속성을 포함하도록 RADIUS 서버를 구성할 수 있습니다.

또한 Framed-Route 속성에서 tag2 값을 파생하도록 동적 프로필을 구성해야 합니다. 이를 위해 액세스 경로가 동적으로 인스턴스화될 때 사용할 $junos-framed-route-tag2 사전 정의된 변수를 지정합니다. 또는 동적 프로필을 구성하여 특정 액세스 경로 접두사에 대한 특정 tag2 값을 제공할 수 있습니다.

사전 정의된 변수에 대한 자세한 내용은 Junos OS 사전 정의된 변수를 참조하십시오.

혜택

  • 로컬 인증은 CPE가 PAP 및 CHAP와 같은 인증 프로토콜을 지원하지 않을 때 가입자에 대해 로컬에 저장된 암호 및 사용자 이름으로 인증을 활성화합니다.

  • CPE 소스 주소 할당을 통해 라우터는 로컬 또는 외부 소스 주소 풀에서 주소를 할당하는 대신 CPE가 요청한 정적으로 구성된 가입자 IP 주소를 수락할 수 있습니다.

  • tag2 속성을 사용하면 경로를 보다 자세히 지정할 수 있습니다.

정적 종료 IPv4 PPP 가입자를 위한 동적 프로파일의 로컬 인증 구성

정적 구성을 사용하는 일부 공급자는 CHAP 또는 PAP가 아닌 인증 프로토콜을 지원하지 않는 CPE 장치를 사용할 수 있습니다. 프로바이더는 정적 PPPoE 논리적 인터페이스에서 가입자를 인증하고 권한을 부여하기 위한 기본적인 방법으로 PPPoE 서비스 이름 테이블을 사용할 수 있습니다. 가입자 ACI 또는 ARI가 테이블 항목과 일치하지 않으면 PPP PADI 및 PADR 패킷이 일반적으로 삭제됩니다.

Junos OS 릴리스 18.2R1부터 PAP 및 CHAP와 같은 인증 프로토콜을 지원하지 않는 클라이언트에 대해 로컬로 사용자 이름과 암호를 구성할 수 있습니다. 라우터는 인증을 위해 RADIUS 서버에 연결할 때 이러한 값을 사용합니다. 이는 정적 가입자가 향상된 가입자 관리를 실행하는 라우터에서 동적 프로필을 사용하도록 마이그레이션하는 데 도움이 됩니다.

로컬 인증 구성하기:

  1. 사용 가능한 옵션 중 하나 이상을 사용하여 사용자 이름을 구성합니다.
    1. (선택 사항) ACI(Agent Circuit Identifier)가 사용자 이름에 포함되도록 지정합니다. ACI는 PPPoE 태그에서 파생됩니다.

    2. (선택 사항) 에이전트 원격 ID(ARI)가 사용자 이름에 포함되도록 지정합니다. ARI는 PPPoE 태그에서 파생됩니다.

    3. (선택 사항) 클라이언트 PDU의 MAC 주소가 사용자 이름에 포함되도록 지정합니다. MAC 주소는 PPPoE 패킷에서 파생됩니다.

    4. (선택 사항) 사용자 이름을 끝낼 클라이언트 도메인 이름을 지정합니다. 라우터는 @ 문자를 이 옵션의 구분 기호로 추가합니다.

    5. (선택 사항) 사용자 이름을 구성하는 구성 요소를 구분하는 구분 기호를 지정합니다. 기본 구분 기호는 마침표(.)입니다. 라우터는 항상 @ 문자를 도메인 이름 앞의 구분 기호로 사용합니다.

  2. 가입자의 비밀번호를 구성합니다.

사용자 이름은 모든 옵션을 포함하고 기본 구분 기호를 사용할 때 다음 형식을 취합니다.

예를 들어 ACI가 aci1002, ARI가 ari349, MAC 주소가 00:00:5e:00:53:ff인 다음 샘플 구성을 고려하십시오.

이 구성으로 인해 다음과 같은 고유한 로컬 사용자 이름에 대한 로컬 비밀번호는 $ABC 123$ABC123이 됩니다.

0000.5e00.53ff-aci1002-ari349@example.com

정적 종료 IPv4 PPP 가입자를 위한 동적 프로파일의 Tag2 속성 구성

일부 구성에서 PPP 가입자는 tag2 속성이 있는 정적 경로를 사용합니다. 예를 들어, MP-BGP는 경로를 보급할 때 tag2를 사용하여 적절한 로컬 기본 설정과 커뮤니티를 적용할 수 있도록 합니다. 향상된 가입자 관리를 실행하는 라우터에서 동적 프로필을 사용하도록 이러한 가입자를 마이그레이션할 때 경로에 대한 특정 값을 구성하거나 RADIUS 서버에서 값을 파생하여 tag2 속성을 구성할 수 있습니다. 이 지원은 Junos OS 릴리스 18.2R1에서 처음 사용할 수 있습니다.

  • 경로에 대한 특정 tag2 값을 구성하려면 다음을 수행합니다.

    • 값을 지정합니다.

  • RADIUS 서버에서 tag2 값을 파생하려면:

    1. 가입자를 인증할 때 Framed-Route 속성 [22]에 tag2 속성을 포함하도록 RADIUS 서버를 구성합니다. 구성 정보는 RADIUS 서버 설명서를 참조하십시오. 구성은 다음 예제와 같을 수 있습니다.

    2. $junos-framed-route-tag2 사전 정의된 변수를 사용하여 Framed-Route 속성에서 tag2 값을 동적으로 도출하도록 동적 프로필을 구성합니다.

      $junos-framed-route-ip-address-prefix 사전 정의된 변수는 Framed-Route 속성에서도 액세스 경로에 대한 IPv4 주소 접두사를 파생합니다.

PPP 가입자를 위한 동적 인증 구성

PPP 클라이언트가 네트워크에 동적으로 액세스할 수 있도록 하는 PPP 인증을 포함하는 동적 프로필을 구성할 수 있습니다. CHAP 또는 PAP 인증을 지정할 수 있습니다. 선택적으로 라우터가 CHAP 및 PAP 프로토콜을 협상하는 순서를 제어할 수도 있습니다.

동적 인터페이스의 경우, 라우터는 단방향 인증만 지원하며, 라우터는 항상 인증자 역할을 합니다. 동적 프로파일에서 PPP 인증을 구성할 때 CHAP 인증은 challenge-length CHAP 챌린지 메시지의 최소 길이와 최대 길이를 구성할 수 있는 옵션을 지원합니다. CHAP 인증과 PAP 인증 모두 문을 비롯한 passive 다른 구성 옵션을 지원하지 않습니다.

참고:

PPP 가입자의 동적 프로필은 PPPoE 인터페이스에서만 지원됩니다.

PPP 가입자 인터페이스에 대한 동적 프로파일에서 인증을 구성하려면:

  1. 동적 프로필의 이름을 지정합니다.
  2. 동적 프로필에 대한 인터페이스와 유닛을 구성합니다. 인터페이스 유형 및 유닛에 대한 사전 정의된 변수에 사용합니다 pp0 .
  3. PPP 옵션을 구성합니다.
  4. 동적 프로필에 사용되는 인증 프로토콜을 지정합니다. CHAP 또는 PAP를 구성할 수 있습니다. 두 인증 프로토콜에 대한 추가 옵션은 없습니다.
  5. (선택 사항) CHAP 챌린지 메시지의 최소 길이와 최대 길이를 구성합니다.

    CHAP 챌린지 길이 수정을 참조하십시오.

  6. (선택 사항) 라우터가 CHAP 및 PAP 인증 프로토콜을 협상하는 순서를 구성합니다.
  7. (선택 사항) IPCP 협상 중에 CPE가 동적 PPPoE 가입자에 대한 DNS 주소를 협상하도록 라우터를 구성합니다.

CHAP 챌린지 길이 수정

라우터가 PPP 클라이언트에 보내는 CHAP(Challenge Handshake Authentication Protocol) 챌린지 메시지의 기본 최소 길이와 최대 길이를 수정할 수 있습니다. 특정 PPP 가입자 세션에 고유한 정보를 포함하는 CHAP 챌린지 메시지는 라우터에 액세스하기 위한 클라이언트의 ID를 확인하기 위해 라우터와 클라이언트 간의 인증 메커니즘의 일부로 사용됩니다.

기본적으로 CHAP 챌린지의 최소 길이는 16바이트이고 최대 길이는 32바이트입니다. 이 기본값을 재정의하여 CHAP 챌린지 최소 길이와 최대 길이를 8바이트에서 63바이트 사이의 범위로 구성할 수 있습니다.

모범 사례:

CHAP 챌린지의 최소 길이와 최대 길이를 모두 16바이트 이상으로 구성하는 것이 좋습니다.

시작하기 전에:

CHAP 챌린지 메시지의 최소 및 최대 길이를 구성하려면,

  1. PPP 옵션을 구성할 것을 지정합니다.
    • 동적 PPP 가입자 인터페이스의 경우:

    • PPP 캡슐화가 있는 정적 인터페이스의 경우:

  2. CHAP 옵션을 구성하도록 지정합니다.
    • 동적 PPP 가입자 인터페이스의 경우:

    • PPP 캡슐화가 있는 정적 인터페이스의 경우:

  3. CHAP 챌린지의 최소 길이와 최대 길이를 지정합니다.
    • 동적 PPP 가입자 인터페이스의 경우:

    • PPP 캡슐화가 있는 정적 인터페이스의 경우:

    예를 들어 pppoe-client-profile이라는 동적 프로필의 다음 challenge-length 문은 CHAP 챌린지의 최소 길이를 20바이트로 설정하고 최대 길이를 40바이트로 설정합니다.

예: 최소 PPPoE 동적 프로파일

이 예는 정적 PPPoE 인터페이스에 사용되는 동적 프로필에 대한 최소 구성을 보여줍니다. 구성에는 스탠자가 포함되어야 interfaces pp0 합니다.

가입자 관리를 위한 PPP 구성 확인 및 관리

목적

가입자 관리를 위한 PPP 구성에 대한 정보를 보거나 삭제합니다.

작업

  • PPP 인터페이스에 대한 정보를 표시하려면:

  • PPP 통계 정보를 표시하려면:

  • PPP 세션 요약 정보를 표시하려면:

  • PPP 주소 풀 정보를 표시하려면:

릴리스 기록 테이블
릴리스
설명
20.2R1
Junos OS 릴리스 20.2R1부터 RADIUS 소싱 메시지를 사용하여 BNG가 홈 게이트웨이와 같은 CPE 디바이스로 투명하게 전달하는 정보를 전달할 수 있습니다.
18.2R1
Junos OS 릴리스 18.2R1부터 이러한 정적 서비스 프로바이더 구성을 동적 프로필로 쉽게 전환할 수 있도록 몇 가지 개선 사항이 추가되었습니다.
18.1R1
Junos OS 릴리스 18.1R1부터는 매직넘버 검증 검사를 수행하지 않도록 라우터를 구성하여 이러한 결과를 방지할 수 있습니다.