When the L2TP clients in the same network segment dial in to R2621 (LNS), part of them could communicate with internal server, and part not.

Publication Date:  2012-07-27 Views:  114 Downloads:  0
Issue Description
  1. Network diagram: internal server―spans network segments-- CISCO26 router(e0)--(e0)R2611LNS(e1)--MA5200 (LAC)-- PC

2. Description: CISCO router e0: 10.170.52.1/25; R2611e0: 10.170.52.126/25; Virtual-Template1: 10.170.52.126/25 borrows the address of e0 (Note: This should be noted particularly); the address segment assigned to dial-in users is: 10.170.52.128/25. Additionally, both the external access network and the internal server run OSPF.

 

Alarm Information
 1. For clients who dial in to R2621 (LNS) and get IP addresses from address pool, they cannot ping through to the server connected to R2621, and neither does the internal server.

Release: VRP1.74--0110

 

Handling Process
 1. Force a static route to private network segment at LNS: ip route-static 10.170.52.128 255.255.255.128 Virtual-Template 1 preference 60 (Note: we cannot specify the next hop as the address, because it goes against the rule that gateway address must be identical to the network number of the network segment address)

2. Summary



The point to solve the problem is to look up route table. Generally, we regard Virtual-Template1 as an interface of the router, so it could create direct route, but we need to make sure if the direct route takes effect. In the case, the so called direct route does not take effect. As a result, it is required to specify a static route. Additionally, the case involves address borrow, which is the special point in the problem. Otherwise, if address borrow is not involved, or the address of Virtual-Template1 and that of internal network interface are not in the same network segment, the problem will not occur.

 

Root Cause

1. Make sure if the user has dialed in to LNS



 1) dis aaa user



 mlkss@mlgan      0      PPP    10.170.52.129         00:00:00 



 mlxf@mlgan      1      PPP    10.170.52.130         00:00:00 



From the information above, we could find that two users have accessed the LNS, with the IP addresses allocated like above.



2. Perform a ping test to verify if the accessed users can access the internal server normally; for R2611, the routes are direct, so you could ping for a test directly.



They could ping through to 10.170.52.130 and 10.170.52.129. There seems to be no problem, but after two minutes:



  [MLGongAn_2600]ping  10.170.52.130



     Reply from 10.170.52.130: TTL expired in transit



They could ping through to 10.170.52.129. The problem is found: the IP addresses of 10.170.52.129 and 130 are in the same network segment (with mask as 25, network number: 10.170.52.128). What causes one through and the other blocked?



3. Check the host routes of both IP addresses:



MLGongAn_2600]dis ip rout: 10.170.52.130



Routing Tables:



  Destination/Mask  Proto   Pref     Metric     Nexthop    Interface



     10.168.0.0/14   O_ASE  150        20      10.170.52.1 Ethernet1          



       10.0.0.0/8    O_ASE  150        20      10.170.52.1 Ethernet1          



        0.0.0.0/0   Static   60         0   218.62.176.253 Ethernet0    



MLGongAn_2600]dis ip rout 10.170.52.129



Routing Tables:



  Destination/Mask  Proto   Pref     Metric     Nexthop    Interface



  10.170.52.129/32  Direct    0         0    10.170.52.126 Virtual-Template1  



     10.168.0.0/14   O_ASE  150        20      10.170.52.1 Ethernet1          



       10.0.0.0/8    O_ASE  150        20      10.170.52.1 Ethernet1          



        0.0.0.0/0   Static   60         0   218.62.176.253 Ethernet0   



According to the information above: the route to address of 10.170.52.130 has no specific route, but that to the address 10.170.52.129 has, so we could configure the IP address with a static route to solve the problem: ip route-static 10.170.52.130 255.255.255.128 Virtual-Template 1 preference 60 (Note: we cannot specify the next hop as the address, because it goes against the rule that gateway address must be identical to the network number of the network segment address). However, after careful analysis, it would be troublesome to configure each user with a static route to solve the problem if it occurs when the other else IP addresses dial in, so we could configure a segment of routes to eradicate the problem:



 ip route-static 10.170.52.128 255.255.255.128 Virtual-Template 1 preference 60



 



END