IP Host Functionality on the ML-MR-10 Card

This chapter describes the IP host functionality on the ML-MR-10 card.

This chapter contains the following major sections:

•Overview

•IP Application Deployment Scenarios

Overview

Because the ML-MR-10 card does not support IP forwarding or routing protocols, it uses IP Host Functionality to send and receive IP packets.

The IP host functionality enables the ML-MR-10 card to:

•Receive IP packets that are sent to its main interface or subinterfaces.

•Generate IP packets and send them on its main interface and sub-interfaces.

When sending IP packets, the ML-MR-10 card may not know the IP destination address due to the lack of IP routing protocols. In order to overcome this situation, configure a next hop node (IP node) either with a specific route or with a default route on the ML-MR-10 card.

Static Routing for IP Forwarding

Although the ML-MR-10 card does not support the IP Forwarding feature, software-based IP forwarding is possible by configuring IP static routes on the card.

Support for IP Applications

IP Host functionality supports the following IP applications:

•Simple Network Management Protocol (SNMP) queries

•Telnet

•IP ping functionality

•Remote Authentication Dial-In User Service (RADIUS) in standalone and relay modes

Subinterface Support

An IP address can be configured on the main interface or on the subinterface. Dot1q encapsulation (VLAN) must be configured before assigning an IP address to a subinterface.

IP Application Deployment Scenarios

Although the following illustrations show the RADIUS application, the illustrations are applicable for any IP application.

Scenario 1: ML-MR-10 card as a RADIUS Client and RADIUS Server is Directly Connected

Figure 27-1 IP Application Deployment Scenario 1

In the scenario depicted in Figure 27-1, the ML-MR-10 card acts as a RADIUS client. Because the RADIUS server is directly connected to the RADIUS client, IP static route configuration is not required.

The management user log in via the data plane or CTC/TCC. The RADIUS client sends an authentication request to the RADIUS server and for this requires the following:

•RADIUS server configuration (for example, 10.0.0.2)

•IP address configuration on the interface (for example, 10.0.0.1 255.255.255.0)

Scenario 2: ML-MR-10 card as a RADIUS Client and RADIUS Server is Not Directly Connected

Figure 27-2 IP Application Deployment Scenario 2

In the scenario depicted in Figure 27-2, the ML-MR-10 card acts as a RADIUS client. The RADIUS server is not directly connected to the RADIUS client. Because a next hop (IP) node is connected to the RADIUS client, the static IP route to reach the RADIUS server is configured on the ML-MR-10 card.

Scenario 3: ML-MR-10 card as a RADIUS Client and RADIUS Server is on the Other Side of the Ring

Figure 27-3 IP Application Deployment Scenario 3

In the scenario depicted in Figure 27-3, the ML-MR-10 card acts as a RADIUS client. Because the RADIUS server is not directly connected to the RADIUS client, the static IP route to the RADIUS server needs to be configured on the ML-MR-10 card A with the next hop as ML-MR-10 card B.

Software IP Forwarding is done at ML-MR-10 card B, that is, the RADIUS packets generated by or destined for the ML-MR-10 card A are IP forwarded in the ML-MR-10 card B.