Telkom vs WebAfrica -- a thorny problem !

b@nD

Banned
Joined
Mar 22, 2012
Messages
754
Reaction score
1
Hopefully one of the bright ISP "insiders" can help me with an ongoing apparently unsolvable problem.
Apologies to the "guilty" parties for the "embarrassment" but they have now had a week to try and sort it out.

Last week as part of their upgrade / maintenance program Telkom did some work on the PMBG DSLAM & ESR. Right after this the problems started.

I have had a Telkom ADSL line for four or more years now with a Telkom Internet account. I have also had the WA MyBB special for nearly two years.

All of these accounts worked perfectly even with an upgrade to the new Telkom One Meg line speed.

I use a Cisco router which enables me to run multiple ISP accounts on one ADSL line ( sharing the bandwidth of course ) As mentioned everything was working fine with this setup.

The Problem:

Although the Telkom account is working OK the WA account is not

Packet loss , unable to ping , tracert not working , no browsing -- in short Internetlessness
Sometimes I cannot even get to their first hop router.

WA claim that this is a Telkom problem. Telkom -- well Telkom support being what it is , there is not much hope here ( they claim the fault has been resolved -- but cannot tell me what fault.) As my line is with Telkom the other ISP's throw their hands up and say -- not MY problem !

So I am posting some data here in the hope that some switched on dude can work out where the problem is ( WA engineers are none the wiser as to the EXACT cause )

I do not have knowledge as to how Telkom configure their DSLAM'S or ESR and it would seem that getting this tech knowledge is a state secret.

Basically when the router using PPP connects it is given an IP address from a pool that is allocated to that ESR ( after all the other negotiation )

The user has NO control over which IP is given( Dynamic IP addressing IPCP ) or the IP of the Edge Router that is going to handle the rest of the routing.

Here is the detail -- hopefully someone can explain what is happening and what is not working.

Traceroutes ;

These results are from my WA account
They should be quite instructive.

Code:
C:\>ping www.webafrica.co.za

Pinging www.webafrica.co.za [196.220.58.66] with 32 bytes of data:

Reply from 196.220.58.66: bytes=32 time=41ms TTL=122
Reply from 196.220.58.66: bytes=32 time=38ms TTL=122
Request timed out.
Request timed out.

Ping statistics for 196.220.58.66:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 38ms, Maximum = 41ms, Average = 39ms

C:\>tracert www.webafrica.co.za

Tracing route to www.webafrica.co.za [196.220.58.66]
over a maximum of 30 hops:

  1     4 ms     2 ms     3 ms  192.168.30.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5  ^C
C:\>ping saix.net

Pinging saix.net [196.25.1.200] with 32 bytes of data:

Reply from 196.25.1.200: bytes=32 time=61ms TTL=245
Reply from 196.25.1.200: bytes=32 time=76ms TTL=245
Reply from 196.25.1.200: bytes=32 time=49ms TTL=245
Reply from 196.25.1.200: bytes=32 time=77ms TTL=245

Ping statistics for 196.25.1.200:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 49ms, Maximum = 77ms, Average = 65ms

C:\>tracert saix.net

Tracing route to saix.net [196.25.1.200]
over a maximum of 30 hops:

  1     4 ms     3 ms     2 ms  192.168.30.1
  2    14 ms    12 ms    12 ms  npmb-ip-bb-1.ipnet.wa.co.za [41.185.170.1]
  3    38 ms    41 ms    38 ms  wnls-ipc1-vl-108.wa.co.za [196.220.59.238]
  4    40 ms    39 ms    40 ms  wnls-cr2-vl-801.wa.co.za [41.185.0.66]
  5    38 ms    37 ms    37 ms  wnls-cr1-vl-10.wa.co.za [41.185.0.42]
  6    39 ms    38 ms    38 ms  wbs-ip-hsll-1-vl101.telkom-ipnet.co.za [196.220.59.226]
  7    85 ms    36 ms    38 ms  wblv-ip-essr-1-atm-2-0-0-1.telkom-ipnet.co.za [196.43.11.22]
  8    41 ms    66 ms    41 ms  wblv-ip-www-1.saix.net [196.25.1.200]

Trace complete.

C:\>

Here are the results from my Telkom Internet account

Code:
C:\>ping www.webafrica.co.za

Pinging www.webafrica.co.za [196.220.58.66] with 32 bytes of data:

Reply from 196.220.58.66: bytes=32 time=34ms TTL=122
Reply from 196.220.58.66: bytes=32 time=73ms TTL=122
Reply from 196.220.58.66: bytes=32 time=34ms TTL=122
Reply from 196.220.58.66: bytes=32 time=33ms TTL=122

Ping statistics for 196.220.58.66:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 33ms, Maximum = 73ms, Average = 43ms

C:\>tracert www.webafrica.co.za

Tracing route to www.webafrica.co.za [196.220.58.66]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.20.1
  2    11 ms     9 ms    10 ms  dsl-146-0-01.telkomadsl.co.za [41.146.0.1]
  3    34 ms    34 ms    34 ms  196.43.51.26
  4    97 ms    34 ms    34 ms  wnls-cr1-vl-102.wa.co.za [196.220.59.229]
  5    33 ms    34 ms    34 ms  wnls-hr2-gi-8-13.wa.co.za [41.185.1.34]
  6    34 ms    34 ms    33 ms  196.220.58.66

Trace complete.

C:\>ping saix.net

Pinging saix.net [196.25.1.200] with 32 bytes of data:

Reply from 196.25.1.200: bytes=32 time=38ms TTL=248
Reply from 196.25.1.200: bytes=32 time=37ms TTL=248
Reply from 196.25.1.200: bytes=32 time=37ms TTL=248
Reply from 196.25.1.200: bytes=32 time=36ms TTL=248

Ping statistics for 196.25.1.200:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 36ms, Maximum = 38ms, Average = 37ms

C:\>tracert saix.net

Tracing route to saix.net [196.25.1.200]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.20.1
  2    10 ms    10 ms     9 ms  dsl-146-0-01.telkomadsl.co.za [41.146.0.1]
  3    35 ms    36 ms    35 ms  wblv-ip-essr-1-atm-2-0-0-2.telkom-ipnet.co.za [196.43.11.30]
  4    37 ms    37 ms    37 ms  wblv-ip-www-1.saix.net [196.25.1.200]

Trace complete.

C:\>

As you can see the WA next hop router is 41.185.170.1

This appears to be where the problem is -- is there some misconfiguration in the TELKOM DSLAM / ESR ?
Is there some misconfiguration in 41.185.170.1 ( WA router / device )

When Telkom made the current changes the IP for the Telkom next hop router was changed from [41.240.40.1] to what you currently see now [41.146.0.1]

What this means is anybodies guess as Telkom are not telling

Trying to find a certified network engineer is like looking for the Holy Grail !

So sorry to throw this problem open to the public -- but when the organizations / companies that you place your trust in are unable --or -- unwilling to do what they are supposed to do one has ( in desperation ) to try something else.

Maybe there is someone out there that understand this stuff at the level of a properly certified engineer that can tell me where to look and what to do.
 
Technically, while 41.185.170.1 is a WA ip, it is located on the Telkom ESR (BRAS) and not on WA's network. This is part of how the IPC MPLS VPN setup works. So the first ip on WA's equipment is 196.220.59.238.

So as you can see, it actually looks like the problem is on the Telkom ESR (BRAS) config, unless it is on your Cisco router. Have you tried to plug in a general ADSL modem and connect to the WA account, or even setting it up in Bridge mode and test from a Windows machine.

Lastly, have you tried another account which is IPC based, like M-Web, IS-based (Afrihost/Axxess ect), Cybersmart, ATC ect ect.
 
If Telkom works and WA doesn't, try a third ISP.
 
Why is WA traceroutes going to 192.168.30.1 and telkom ones to 192.168.20.1? Are you using a multiple gateway configuration?
 
what I find strange is the first hop on trace route,
Why is it 3-4 ms on WA but <1ms on telkom ?, are you using different pc's ?
 
Last edited:
Responsibility

Technically, while 41.185.170.1 is a WA ip, it is located on the Telkom ESR (BRAS) and not on WA's network. This is part of how the IPC MPLS VPN setup works. So the first ip on WA's equipment is 196.220.59.238.

So as you can see, it actually looks like the problem is on the Telkom ESR (BRAS) config, unless it is on your Cisco router. Have you tried to plug in a general ADSL modem and connect to the WA account, or even setting it up in Bridge mode and test from a Windows machine.

Lastly, have you tried another account which is IPC based, like M-Web, IS-based (Afrihost/Axxess ect), Cybersmart, ATC ect ect.

Thanks for all your replies

I connect one subnet (LAN) to one ISP and the other subnet to another ISP

Also use different machines as well as a WiFi network.

I have not made any changes to the line , the router , or the config -- to what was working 100% previously. ( apart from changing the Telkom next hop IP )

OK -- so who gets to take responsibility for 41.185.170.1 and who gets to configure it ? WA / Telkom / Both ?

WHO does one complain to when it is NOT working ? Strange setup for a "Tier One" ISP ????

I am in the process of trying another IS based ISP via a test account. ( although I really do not think that this will make a difference )

If anyone has a test account which does not involve jumping through hoops and over barrels please give me a shout (PM )

I know IS have a "test" router which one can use to test from within the network -- does Telkom have anything similar ?

general ADSL modem WHAT is that :)
 
Thanks for all your replies

I connect one subnet (LAN) to one ISP and the other subnet to another ISP

Also use different machines as well as a WiFi network.

I have not made any changes to the line , the router , or the config -- to what was working 100% previously. ( apart from changing the Telkom next hop IP )

OK -- so who gets to take responsibility for 41.185.170.1 and who gets to configure it ? WA / Telkom / Both ?

WHO does one complain to when it is NOT working ? Strange setup for a "Tier One" ISP ????

I am in the process of trying another IS based ISP via a test account. ( although I really do not think that this will make a difference )

If anyone has a test account which does not involve jumping through hoops and over barrels please give me a shout (PM )

I know IS have a "test" router which one can use to test from within the network -- does Telkom have anything similar ?

general ADSL modem WHAT is that :)
You should probably create a support ticket with WA explaining its a advanced problem that should go directly to their network engineers and who then need to escalate it to SAIX IPC wholesale.
 
Although the Telkom account is working OK the WA account is not

But, you authenticate, and get an IP, right?

Packet loss , unable to ping , tracert not working , no browsing -- in short Internetlessness
Sometimes I cannot even get to their first hop router.

WA claim that this is a Telkom problem.

It may be, but if you authenticate, and get an IP, then it is not a Telkom consumer problem, it is a Telkom wholesale problem, WA is their customer, and needs to resolve the issue.

Telkom -- well Telkom support being what it is , there is not much hope here

Technically, if your ADSL line syncs, then when using a different ISP, Telkom has no further responsibility. One of the (many) reasons Telkom call centres are so busy is because of customers of other ISPs phoning about ISP problems ...

As my line is with Telkom the other ISP's throw their hands up and say -- not MY problem !

Unacceptable IMHO. If you authenticate against the ISP, the line is working sufficiently for them to at least investigate the problem.

I do not have knowledge as to how Telkom configure their DSLAM'S or ESR and it would seem that getting this tech knowledge is a state secret.

I don't see why anyone but wholesale ISPs need to know ...

Basically when the router using PPP connects it is given an IP address from a pool that is allocated to that ESR ( after all the other negotiation )

The user has NO control over which IP is given( Dynamic IP addressing IPCP ) or the IP of the Edge Router that is going to handle the rest of the routing.

Both IPC and non-IPC accounts require that the user is placed into the correct IP pool for the ESR. Allowing the customer to specify their own IP would break everything ....

As you can see the WA next hop router is 41.185.170.1

AFAIK, this should be their end of the IPC link. Hmm, actually, maybe the IP in WA's VRF on the ESR.

This appears to be where the problem is -- is there some misconfiguration in the TELKOM DSLAM / ESR ?

Possibly, but this is WA's problem, not yours. It is possible that you are being placed in the wrong VRF. It is possible that this could be a misconfiguration on the ESR. WA can have Telkom Wholesale verify the config on this ESR (they should already have all the necessary information, all the details are in the RADIUS Access-Request packet they get).

Is there some misconfiguration in 41.185.170.1 ( WA router / device )

IMHO, this is more likely.

Trying to find a certified network engineer is like looking for the Holy Grail !

Most of them are busy doing work for wholesale customers, who are supposed to do 1st and 2nd level support, then kind you aren't getting from WA.

I really can't help any further, WA needs to investigate and escalate to Telkom Wholesale if they believe the problem is on the Telkom side. They have a contract with Telkom for this service ...
 
Last edited:
The "Skinny"

Hi Ranger -- thanks for the insights

Here is a PPP debug dump -- perhaps you or the famous ROMAN can make head or tail of it

PPP debug from Telkom account -- which comes up really quick and has no problems.
As stated previously this is the exact same ADSL line and exact same router Cisco 877 with the same config that was working previously.
Murphy is always busy so who knows maybe there is a hidden bug in the config ?

Telkom
Code:
Mar 23 19:00:47.844 SAST: %DIALER-6-BIND: Interface Vi2 bound to profile Di2
Mar 23 19:00:47.844 SAST: Vi2 PPP: Phase is DOWN, Setup
Mar 23 19:00:47.844 SAST: Vi2 PPP: Using dialer call direction
Mar 23 19:00:47.844 SAST: Vi2 PPP: Treating connection as a callout
Mar 23 19:00:47.844 SAST: Vi2 PPP: Session handle[250001AC] Session id[0]
Mar 23 19:00:47.844 SAST: Vi2 PPP: Phase is ESTABLISHING, Active Open
Mar 23 19:00:47.844 SAST: Vi2 PPP: Authorization required
Mar 23 19:00:47.844 SAST: Vi2 PPP: No remote authentication for call-out
Mar 23 19:00:47.844 SAST: Vi2 LCP: O CONFREQ [Closed] id 1 len 14
Mar 23 19:00:47.844 SAST: Vi2 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:00:47.844 SAST: Vi2 LCP:    MagicNumber 0x155128AA (0x0506155128AA)
Mar 23 19:00:47.856 SAST: Vi2 LCP: I CONFACK [REQsent] id 1 len 14
Mar 23 19:00:47.856 SAST: Vi2 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:00:47.856 SAST: Vi2 LCP:    MagicNumber 0x155128AA (0x0506155128AA)
Mar 23 19:00:49.836 SAST: Vi2 LCP: Timeout: State ACKrcvd
Mar 23 19:00:49.836 SAST: Vi2 LCP: O CONFREQ [ACKrcvd] id 2 len 14
Mar 23 19:00:49.836 SAST: Vi2 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:00:49.836 SAST: Vi2 LCP:    MagicNumber 0x155128AA (0x0506155128AA)
Mar 23 19:00:49.844 SAST: Vi2 LCP: I CONFREQ [REQsent] id 2 len 18
Mar 23 19:00:49.844 SAST: Vi2 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:00:49.844 SAST: Vi2 LCP:    AuthProto PAP (0x0304C023)
Mar 23 19:00:49.844 SAST: Vi2 LCP:    MagicNumber 0x9744EED5 (0x05069744EED5)
Mar 23 19:00:49.844 SAST: Vi2 LCP: O CONFACK [REQsent] id 2 len 18
Mar 23 19:00:49.844 SAST: Vi2 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:00:49.844 SAST: Vi2 LCP:    AuthProto PAP (0x0304C023)
Mar 23 19:00:49.844 SAST: Vi2 LCP:    MagicNumber 0x9744EED5 (0x05069744EED5)
Mar 23 19:00:49.848 SAST: Vi2 LCP: I CONFACK [ACKsent] id 2 len 14
Mar 23 19:00:49.848 SAST: Vi2 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:00:49.848 SAST: Vi2 LCP:    MagicNumber 0x155128AA (0x0506155128AA)
Mar 23 19:00:49.848 SAST: Vi2 LCP: State is Open
Mar 23 19:00:49.848 SAST: Vi2 PPP: No authorization without authentication
Mar 23 19:00:49.848 SAST: Vi2 PPP: Phase is AUTHENTICATING, by the peer
Mar 23 19:00:49.848 SAST: Vi2 PAP: Using hostname from interface PAP
Mar 23 19:00:49.848 SAST: Vi2 PAP: Using password from interface PAP
Mar 23 19:00:49.848 SAST: Vi2 PAP: O AUTH-REQ id 1 len 49 from "User-Name"
Mar 23 19:00:59.849 SAST: Vi2 AUTH: Timeout 1
Mar 23 19:00:59.849 SAST: Vi2 PAP: Using hostname from interface PAP
Mar 23 19:00:59.849 SAST: Vi2 PAP: Using password from interface PAP
Mar 23 19:00:59.849 SAST: Vi2 PAP: O AUTH-REQ id 2 len 49 from "User-Name"
Mar 23 19:01:01.449 SAST: Vi2 PAP: I AUTH-ACK id 2 len 5
Mar 23 19:01:01.449 SAST: Vi2 PPP: Phase is FORWARDING, Attempting Forward
Mar 23 19:01:01.449 SAST: Vi2 PPP: Queue IPCP code[1] id[1]
Mar 23 19:01:01.449 SAST: Vi2 PPP: Phase is ESTABLISHING, Finish LCP
Mar 23 19:01:01.449 SAST: Vi2 MCB: Initialize
Mar 23 19:01:01.453 SAST: Vi2 PPP: Phase is UP
Mar 23 19:01:01.453 SAST: Vi2 IPCP: O CONFREQ [Closed] id 1 len 10
Mar 23 19:01:01.453 SAST: Vi2 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 23 19:01:01.453 SAST: Vi2 CCP: O CONFREQ [Closed] id 1 len 9
Mar 23 19:01:01.453 SAST: Vi2 CCP:    Stacker history 1 check mode SEQUENCED (0x1105000103)
Mar 23 19:01:01.453 SAST: Vi2 PPP: Process pending ncp packets
Mar 23 19:01:01.453 SAST: Vi2 IPCP: Redirect packet to Vi2
Mar 23 19:01:01.453 SAST: Vi2 IPCP: I CONFREQ [REQsent] id 1 len 10
Mar 23 19:01:01.453 SAST: Vi2 IPCP:    Address 41.146.0.1 (0x030629920001)
Mar 23 19:01:01.453 SAST: Vi2 IPCP: O CONFACK [REQsent] id 1 len 10
Mar 23 19:01:01.453 SAST: Vi2 IPCP:    Address 41.146.0.1 (0x030629920001)
Mar 23 19:01:01.461 SAST: Vi2 LCP: I PROTREJ [Open] id 3 len 15 protocol CCP (0x80FD010100091105000103)
Mar 23 19:01:01.461 SAST: Vi2 CCP: State is Closed
Mar 23 19:01:01.465 SAST: Vi2 CCP: State is Listen
Mar 23 19:01:01.465 SAST: Vi2 IPCP: I CONFNAK [ACKsent] id 1 len 10
Mar 23 19:01:01.465 SAST: Vi2 IPCP:    Address *VALID IPCP Address*)
Mar 23 19:01:01.465 SAST: Vi2 IPCP: O CONFREQ [ACKsent] id 2 len 10
Mar 23 19:01:01.465 SAST: Vi2 IPCP:    Address *VALID IPCP Address*)
Mar 23 19:01:01.473 SAST: Vi2 IPCP: I CONFACK [ACKsent] id 2 len 10
Mar 23 19:01:01.473 SAST: Vi2 IPCP:    Address *VALID IPCP Address*)
Mar 23 19:01:01.473 SAST: Vi2 IPCP: State is Open
Mar 23 19:01:01.473 SAST: Di2 IPCP: Install negotiated IP interface address 41.X.X.X
Mar 23 19:01:01.477 SAST: Di2 IPCP: Install route to 41.146.0.1
Mar 23 19:01:01.477 SAST: Vi2 IPCP: Add link info for cef entry 41.146.0.1
Mar 23 19:01:02.448 SAST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up

OK -- here are the WA attempts at PPP negotiation -- stops at a significant point which should tell the experts where the problem is ?

WebAfrica
Code:
Mar 23 19:08:24.159 SAST: %DIALER-6-BIND: Interface Vi1 bound to profile Di1
Mar 23 19:08:24.159 SAST: Vi1 PPP: Phase is DOWN, Setup
Mar 23 19:08:24.159 SAST: Vi1 PPP: Using dialer call direction
Mar 23 19:08:24.159 SAST: Vi1 PPP: Treating connection as a callout
Mar 23 19:08:24.159 SAST: Vi1 PPP: Session handle[EA0001AF] Session id[0]
Mar 23 19:08:24.159 SAST: Vi1 PPP: Phase is ESTABLISHING, Active Open
Mar 23 19:08:24.163 SAST: Vi1 PPP: Authorization required
Mar 23 19:08:24.163 SAST: Vi1 PPP: No remote authentication for call-out
Mar 23 19:08:24.163 SAST: Vi1 LCP: O CONFREQ [Closed] id 1 len 14
Mar 23 19:08:24.163 SAST: Vi1 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:08:24.163 SAST: Vi1 LCP:    MagicNumber 0x15582025 (0x050615582025)
Mar 23 19:08:24.163 SAST: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Mar 23 19:08:24.519 SAST: Vi1 LCP: I CONFACK [REQsent] id 1 len 14
Mar 23 19:08:24.519 SAST: Vi1 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:08:24.519 SAST: Vi1 LCP:    MagicNumber 0x15582025 (0x050615582025)
Mar 23 19:08:25.159 SAST: Vi1 PPP: Sending Acct Event[Down] id[90]
Mar 23 19:08:25.159 SAST: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1
Mar 23 19:08:25.159 SAST: Vi1 PPP: Block vaccess from being freed [0x10]
Mar 23 19:08:25.163 SAST: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
Mar 23 19:08:25.163 SAST: Vi1 LCP: State is Closed
Mar 23 19:08:25.163 SAST: Vi1 PPP: Phase is DOWN
Mar 23 19:08:25.163 SAST: Vi1 PPP: Unlocked by [0x10] Still Locked by [0x2]
Mar 23 19:08:25.163 SAST: Vi1 PPP: Unlocked by [0x2] Still Locked by [0x0]
Mar 23 19:08:25.163 SAST: Vi1 PPP: Free previously blocked vaccess


Mar 23 19:08:47.401 SAST: %DIALER-6-BIND: Interface Vi2 bound to profile Di1
Mar 23 19:08:47.401 SAST: Vi2 PPP: Phase is DOWN, Setup
Mar 23 19:08:47.405 SAST: Vi2 PPP: Using dialer call direction
Mar 23 19:08:47.405 SAST: Vi2 PPP: Treating connection as a callout
Mar 23 19:08:47.405 SAST: Vi2 PPP: Session handle[4E0001B2] Session id[0]
Mar 23 19:08:47.405 SAST: Vi2 PPP: Phase is ESTABLISHING, Active Open
Mar 23 19:08:47.405 SAST: Vi2 PPP: Authorization required
Mar 23 19:08:47.405 SAST: Vi2 PPP: No remote authentication for call-out
Mar 23 19:08:47.405 SAST: Vi2 LCP: O CONFREQ [Closed] id 1 len 14
Mar 23 19:08:47.405 SAST: Vi2 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:08:47.405 SAST: Vi2 LCP:    MagicNumber 0x15587AFD (0x050615587AFD)
Mar 23 19:08:47.405 SAST: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
Mar 23 19:08:47.413 SAST: Vi2 LCP: I CONFACK [REQsent] id 1 len 14
Mar 23 19:08:47.413 SAST: Vi2 LCP:    MRU 1492 (0x010405D4)
Mar 23 19:08:47.413 SAST: Vi2 LCP:    MagicNumber 0x15587AFD (0x050615587AFD)
Mar 23 19:08:48.153 SAST: Vi2 PPP: Sending Acct Event[Down] id[91]
Mar 23 19:08:48.153 SAST: %DIALER-6-UNBIND: Interface Vi2 unbound from profile Di1
Mar 23 19:08:48.153 SAST: Vi2 PPP: Block vaccess from being freed [0x10]
Mar 23 19:08:48.157 SAST: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
Mar 23 19:08:48.157 SAST: Vi2 LCP: State is Closed
Mar 23 19:08:48.157 SAST: Vi2 PPP: Phase is DOWN
Mar 23 19:08:48.157 SAST: Vi2 PPP: Unlocked by [0x10] Still Locked by [0x2]
Mar 23 19:08:48.157 SAST: Vi2 PPP: Unlocked by [0x2] Still Locked by [0x0]
Mar 23 19:08:48.157 SAST: Vi2 PPP: Free previously blocked vaccess

This appears to be the crunch

Mar 23 19:09:11.158 SAST: Vi1 PPP: Sending Acct Event[Down] id[92]

I increased the PPP timeouts but that has not helped.

Maybe someone can explain what it is saying ?
Even better perhaps someone can tell what to do to FIX it ?
Still better -- Hhhmmm -- Let's see first where the problem is ?
 
Even better perhaps someone can tell what to do to FIX it ?
Still better -- Hhhmmm -- Let's see first where the problem is ?

You have been given those answers. WebAfrica needs to fix this, by esculating to Telkom Wholesale. Nothing you do will fix this.
 
Yipee

You have been given those answers.
WebAfrica needs to fix this, by esculating to Telkom Wholesale.
Nothing you do will fix this.

Weelll I do not know who did what ( I did a bit of tweaking here -- which might just be co-incidental ) , but it appears to be working again.

Here is what the working PPP debug looks like

Working WA PPP negotiation
Code:
Mar 23 21:18:11.021 SAST: %DIALER-6-BIND: Interface Vi1 bound to profile Di1
Mar 23 21:18:11.021 SAST: Vi1 PPP: Phase is DOWN, Setup
Mar 23 21:18:11.021 SAST: Vi1 PPP: Using dialer call direction
Mar 23 21:18:11.021 SAST: Vi1 PPP: Treating connection as a callout
Mar 23 21:18:11.021 SAST: Vi1 PPP: Session handle[A50001D2] Session id[0]
Mar 23 21:18:11.021 SAST: Vi1 PPP: Phase is ESTABLISHING, Active Open
Mar 23 21:18:11.021 SAST: Vi1 PPP: Authorization required
Mar 23 21:18:11.021 SAST: Vi1 PPP: No remote authentication for call-out
Mar 23 21:18:11.025 SAST: Vi1 LCP: O CONFREQ [Closed] id 1 len 14
Mar 23 21:18:11.025 SAST: Vi1 LCP:    MRU 1492 (0x010405D4)
Mar 23 21:18:11.025 SAST: Vi1 LCP:    MagicNumber 0x15CEFFB0 (0x050615CEFFB0)
Mar 23 21:18:11.025 SAST: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Mar 23 21:18:11.033 SAST: Vi1 LCP: I CONFACK [REQsent] id 1 len 14
Mar 23 21:18:11.033 SAST: Vi1 LCP:    MRU 1492 (0x010405D4)
Mar 23 21:18:11.033 SAST: Vi1 LCP:    MagicNumber 0x15CEFFB0 (0x050615CEFFB0)
Mar 23 21:18:13.032 SAST: Vi1 LCP: I CONFREQ [ACKrcvd] id 2 len 18
Mar 23 21:18:13.032 SAST: Vi1 LCP:    MRU 1492 (0x010405D4)
Mar 23 21:18:13.032 SAST: Vi1 LCP:    AuthProto PAP (0x0304C023)
Mar 23 21:18:13.032 SAST: Vi1 LCP:    MagicNumber 0x97C4E3C7 (0x050697C4E3C7)
Mar 23 21:18:13.032 SAST: Vi1 LCP: O CONFACK [ACKrcvd] id 2 len 18
Mar 23 21:18:13.032 SAST: Vi1 LCP:    MRU 1492 (0x010405D4)
Mar 23 21:18:13.032 SAST: Vi1 LCP:    AuthProto PAP (0x0304C023)
Mar 23 21:18:13.032 SAST: Vi1 LCP:    MagicNumber 0x97C4E3C7 (0x050697C4E3C7)
Mar 23 21:18:13.032 SAST: Vi1 LCP: State is Open
Mar 23 21:18:13.032 SAST: Vi1 PPP: No authorization without authentication
Mar 23 21:18:13.032 SAST: Vi1 PPP: Phase is AUTHENTICATING, by the peer
Mar 23 21:18:13.032 SAST: Vi1 PAP: Using hostname from interface PAP
Mar 23 21:18:13.032 SAST: Vi1 PAP: Using password from interface PAP
Mar 23 21:18:13.032 SAST: Vi1 PAP: O AUTH-REQ id 1 len 27 from "User-Name"
Mar 23 21:18:13.232 SAST: Vi1 PAP: I AUTH-ACK id 1 len 5
Mar 23 21:18:13.232 SAST: Vi1 PPP: Phase is FORWARDING, Attempting Forward
Mar 23 21:18:13.232 SAST: Vi1 PPP: Phase is ESTABLISHING, Finish LCP
Mar 23 21:18:13.232 SAST: Vi1 MCB: Initialize
Mar 23 21:18:13.236 SAST: Vi1 PPP: Phase is UP
Mar 23 21:18:13.236 SAST: Vi1 IPCP: O CONFREQ [Closed] id 1 len 22
Mar 23 21:18:13.236 SAST: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 23 21:18:13.236 SAST: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 23 21:18:13.236 SAST: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 23 21:18:13.236 SAST: Vi1 CCP: O CONFREQ [Closed] id 1 len 9
Mar 23 21:18:13.236 SAST: Vi1 CCP:    Stacker history 1 check mode SEQUENCED (0x1105000103)
Mar 23 21:18:13.236 SAST: Vi1 PPP: Process pending ncp packets
Mar 23 21:18:13.236 SAST: Vi1 IPCP: I CONFREQ [REQsent] id 1 len 10
Mar 23 21:18:13.236 SAST: Vi1 IPCP:    Address 41.185.170.1 (0x030629B9AA01)
Mar 23 21:18:13.240 SAST: Vi1 IPCP: Accept the peer address 41.185.170.1
Mar 23 21:18:13.240 SAST: Vi1 IPCP: O CONFACK [REQsent] id 1 len 10
Mar 23 21:18:13.240 SAST: Vi1 IPCP:    Address 41.185.170.1 (0x030629B9AA01)
Mar 23 21:18:13.244 SAST: Vi1 IPCP: I CONFNAK [ACKsent] id 1 len 22
Mar 23 21:18:13.244 SAST: Vi1 IPCP:    Address 41.X.X.X (0x030629B9AEA3)
Mar 23 21:18:13.244 SAST: Vi1 IPCP:    PrimaryDNS 196.220.59.188 (0x8106C4DC3BBC)
Mar 23 21:18:13.244 SAST: Vi1 IPCP:    SecondaryDNS 196.220.59.189 (0x8306C4DC3BBD)
Mar 23 21:18:13.244 SAST: Vi1 IPCP: O CONFREQ [ACKsent] id 2 len 22
Mar 23 21:18:13.244 SAST: Vi1 IPCP:    Address 41.X.X.X (0x030629B9AEA3)
Mar 23 21:18:13.248 SAST: Vi1 IPCP:    PrimaryDNS 196.220.59.188 (0x8106C4DC3BBC)
Mar 23 21:18:13.248 SAST: Vi1 IPCP:    SecondaryDNS 196.220.59.189 (0x8306C4DC3BBD)
Mar 23 21:18:13.248 SAST: Vi1 LCP: I PROTREJ [Open] id 3 len 15 protocol CCP (0x80FD010100091105000103)
Mar 23 21:18:13.248 SAST: Vi1 CCP: State is Closed
Mar 23 21:18:13.248 SAST: Vi1 CCP: State is Listen
Mar 23 21:18:13.256 SAST: Vi1 IPCP: I CONFACK [ACKsent] id 2 len 22
Mar 23 21:18:13.256 SAST: Vi1 IPCP:    Address 41.X.X.X (0x030629B9AEA3)
Mar 23 21:18:13.256 SAST: Vi1 IPCP:    PrimaryDNS 196.220.59.188 (0x8106C4DC3BBC)
Mar 23 21:18:13.256 SAST: Vi1 IPCP:    SecondaryDNS 196.220.59.189 (0x8306C4DC3BBD)
Mar 23 21:18:13.260 SAST: Vi1 IPCP: State is Open
Mar 23 21:18:13.260 SAST: Di1 IPCP: Install negotiated IP interface address 41.X.X.X
Mar 23 21:18:13.260 SAST: Di1 IPCP: Install route to 41.185.170.1
Mar 23 21:18:13.264 SAST: Vi1 IPCP: Add link info for cef entry 41.185.170.1
Mar 23 21:18:14.232 SAST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

Confucius say .... Man who never give up always finish race
 
A tale of two ISP's ( & a cyberdenizen )

For anyone that is interested ( in other peoples problems ) here is the end of the story

1.)
Telkom changed / upgraded their equipment on 15 /16 March 2012 -- without spelling out what the changes might be. I never got an advisory from TelkomSA.net , the retail branch of Telkom SAIX

2.)
This led to changes on the network ( changes to router IP addresses -- and probably other stuff )

Telkoms router IP for PMBG changed from 41.240.40.1 to 41.146.0.1

WA router IP for PMBG changed from 41.185.68.1 to 41.185.170.1

On a normal simple paste and glue ADSL "modem" this would make no difference as the router takes care of these changes itself.
When one has something a bit more complex that needs next hop routeS configured it makes BIG difference

3.)
Apart from the IP changes the WA PPP negotiation was failing -- WHY ? I am not sure as the Telkom and WA Dialer configs on the router were in all respects the same !

4.)
When the WA PPP passed and the link was up , strange pings / tracert's etc were a result of NOT changing the routers config to the new IP ( I never noticed this and WA tech support never mentioned it ? Perhaps they did not think that it was significant ? Perhaps they never knew it had changed ? )

5.)
Things are once again back to normal ( thank goodness ) let us see how long the daytime full speed downloads last ?


So who resolved the problem ?
Have heard nothing from Telkom / Wholesale / SAIX ?
Maybe they changed something on the DSLAM / ESR ? -- will we EVER know ? No reply to any tickets !

Have heard nothing from WA -- never suggested anything past the normal ping , tracert . speedtest -- except to say things looked fine on their side.

So who to blame ?
Telkom for never informing anyone EXACTLY what changes were being made ?
WA for not picking up on this and following up with Telkom wholesale as suggested here ? ( or did they ? )
Kiepie for not paying attention and picking up on the changes fast enough ?

All's well that ends well -- give THIS man a BELL's:D
 
Its a good idea to never statically configure next hops, because they can change without you knowing. So the best way to configure your router is to be based on interface level instead of static ips, that way you should never have a problem at least.

This seems to be because you configured stuff statically, which could have been avoided by doing it dynamically.

Just my opinion of-coarse.
 
Coarse

Its a good idea to never statically configure next hops, because they can change without you knowing. So the best way to configure your router is to be based on interface level instead of static ips, that way you should never have a problem at least.

This seems to be because you configured stuff statically, which could have been avoided by doing it dynamically.

Just my opinion of-coarse.

NOTHING wrong with your opinion -- thanks for the suggestions.

As I understand it ............. ( which could be completely wrong )

One can use PBR and route-maps -- in which case you need to stipulate a next hop address to tie a VLAN to a Dialer

Configuring Policy-Based Routing

http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html


Route-Maps for IP Routing Protocol Redistribution Configuration

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008047915d.shtml

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ftnatrt.html

or

You can user ppp ipcp route-default

Default Route on a PPP Virtual Access Interface

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtdfltrt.html


Sounds like you are recommending the IPCP Route-Default method -- which as I understand it would be dynamic ?

( in which case it appears that you also do not need ip route statements ? )
 
Maybe try to fake it with PBR like so.

I don't know what Cisco call a ppp interface, so I am going to just call it ppp0 and ppp1 in this example.

Code:
ip route 192.168.10.1 255.255.255.255 ppp0
ip route 192.168.11.1 255.255.255.255 ppp1

route-map pbr-to-adsl1 permit 10
 set ip next-hop recursive 192.168.10.1

route-map pbr-to-adsl2 permit 10
 set ip next-hop recursive 192.168.11.1

So what I have done is, I've set two simple static routes, one for each ADSL account. The PBR then make use of those static routes, the good thing is, those next-hops will be overwritten by the next router (BRAS) anyways so that is why I am making use of ips which you hopefully don't make use of. So while I have made use of static routes, it is actually still dynamic, because the point of the static routes is, to point to an interface instead of an actual next hop. One of my favorite way to send packets out a interface if you don't know what the actual next-hop is.

The problem with the IPCP default route is, that will only add a default route, and all your internal clients will then route out the same account. Unfortunately I think the only way to do this on Cisco is in fact PBR. I just have 0 experience with ADSL on Cisco, or even dial-up accounts for that matter.
 
PAT

Maybe try to fake it with PBR like so.
I don't know what Cisco call a ppp interface, so I am going to just call it ppp0 and ppp1 in this example.
Code:
ip route 192.168.10.1 255.255.255.255 ppp0
ip route 192.168.11.1 255.255.255.255 ppp1

route-map pbr-to-adsl1 permit 10
 set ip next-hop recursive 192.168.10.1

route-map pbr-to-adsl2 permit 10
 set ip next-hop recursive 192.168.11.1
So what I have done is, I've set two simple static routes, one for each ADSL account. The PBR then make use of those static routes, the good thing is, those next-hops will be overwritten by the next router (BRAS) anyways so that is why I am making use of ips which you hopefully don't make use of. So while I have made use of static routes, it is actually still dynamic, because the point of the static routes is, to point to an interface instead of an actual next hop. One of my favorite way to send packets out a interface if you don't know what the actual next-hop is.

The problem with the IPCP default route is, that will only add a default route, and all your internal clients will then route out the same account. Unfortunately I think the only way to do this on Cisco is in fact PBR. I just have 0 experience with ADSL on Cisco, or even dial-up accounts for that matter.

Looking at your example I am just wondering where and when NAT / PAT is going to take place ?


With Cisco ADSL is classed like ISDN as a DIAL technology -- you therefore have Dialer interfaces for ADSL ( but not the old DDR [Dial on Demand Routing] way )

So your ppp0 would be Dialer0 and so on

ip route 0.0.0.0 0.0.0.0 Dialer [n] is the command where the Dialer is the outside interface

0.0.0.0 0 0.0.0.0 because you do not have a fixed public IP and you do not know the next hop of the ISP router which is what normally happens in DIAL technologies interfacing to the Internet.

you cannot ( should not ) route a private IP address across the internet

One could probably in the route-map use an interface instead of a fixed IP ?

set ip next-hop recursive Dialer0


So although you can use PPP [Point to Point Protocol] on a dedicated circuit instead of HLDC [High Level Data Link Control] it is also used for "dial" once the link is established. IPCP [IP Control Protocol] is a sub protocol of PPP

192.168.X.X <subnet mask>

are private IP's not routable on the Internet

I assume NAT / PAT occurs before you have a routable public IP ? or -- the route to the next hop router is established first and then a routable public IP is allocated by the ESR ( ESSR ) -- to which your NAT/PAT must then translate your internal networks.

More things to try out -- more things to break ( and as a "home" not business or wholesale customer one has to work out the other side of things by guesswork --or -- by alchemy ? )
 
The NAT/PAT will still happen the same as it would in the past before the PBR, PBR is just a different way for the router to decide how to switch the packet.

192.168.x.x is technically routable on the internet, like any other IP, it can route, the problem is, because of RFC1918 it can be used on other devices as well, so you don't know what will happen with it. Now technically speaking you not really routing it to that IP, you just using it to decide which interface to send it out on.

So if you know Dialer 1 will always be ISP A, and Dialer 2 will always be ISP B, you might as well just use the way I explained. It is only to force the packet to the correct interface, you not actually routing to the IPs in my example, even though you are using them to force it to a specific device.

The BRAS will then receive the packet on the specific interface you sent it out, look at the destination (which will be lets say 8.8.8.8) and send it via the MPLS-VPN to the correct IPC-ISP.
 
The NAT/PAT will still happen the same as it would in the past before the PBR, PBR is just a different way for the router to decide how to switch the packet.

The BRAS will then receive the packet on the specific interface you sent it out, look at the destination (which will be lets say 8.8.8.8) and send it via the MPLS-VPN to the correct IPC-ISP.

Thanks
I found a nice working example where you do not need to use hard coded router IP/s

See if you consider this to be a "dynamic" configuration ?

I tested it and it works ( you can use an extended ACL -- can be named ) but you still need an IP route statement for a gateway of last resort.


http://pierky.wordpress.com/2009/07...n-connections-using-policy-based-routing-pbr/


LAN1 traffic through the Bronze link, LAN2 traffic through the Gold link. We want LAN-to-LAN reachability too.

We define an access list which matches all traffic towards subnets out of our network:

access-list 199 deny ip any 192.168.0.0 0.0.255.255
access-list 199 permit ip any any

If we don’t exlude 192.168.0.0/16 our route-maps policies will also be applied to LAN-to-LAN traffic.

Then we make route-maps and apply them to LAN interfaces:

route-map LAN1 permit 10
match ip address 199
set interface Serial2/0

route-map LAN2 permit 10
match ip address 199
set interface Serial2/1

interface FastEthernet0/0
description LAN1
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip policy route-map LAN1

interface FastEthernet1/0
description LAN2
ip address 192.168.2.1 255.255.255.0
ip nat inside
ip policy route-map LAN2

Now, routing is Ok; traffic coming from LAN1 with destinations different from LAN2 subnet will be routed out S2/0. Same for LAN2 traffic, out S2/1.

Now, we have to build policy-based NAT: traffic out the S2/0 interface has to be translated using S2/0 IP address; same for traffic coming out from S2/1, translated with S2/1 address.

route-map NAT_LAN1 permit 10
match interface Serial2/0

route-map NAT_LAN2 permit 10
match interface Serial2/1

ip nat inside source route-map NAT_LAN1 interface Serial2/0 overload
ip nat inside source route-map NAT_LAN2 interface Serial2/1 overload

Tests

Pings from the LAN (in the GNS3-Lab PCs are routers) to “internet” (4.4.4.4) are routed accordingly to what expected:

GW#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 2.2.2.2:6 192.168.1.10:6 4.4.4.4:6 4.4.4.4:6
icmp 3.3.3.2:6 192.168.2.10:6 4.4.4.4:6 4.4.4.4:6

If you want to try this in GNS3 please download the lab from the previous post; just few changes are required!
 
Top
Sign up to the MyBroadband newsletter
X