I'm going to try to thin this down to relevant info...
/ip address> pri
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
1 ;;; Radius
172.16.1.9/29 172.16.1.8 ether1
7 ;;; West Sector Bcc
172.16.1.85/30 172.16.1.84 ether10
10 2.2.2.1/32 2.2.2.1 lobridge
When did Oklahoma move to France?
inetnum: 2.0.0.0 - 2.15.255.255
netname: FR-TELECOM-20100712
descr: Orange S.A.
country: FR
14 63.97.254.2/24 63.97.254.0 ether1
16 172.16.6.10/24 172.16.6.0 ether3
] /ip route> pri
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 63.97.254.1 1
9 ADo 2.2.2.18/32 172.16.1.86 110
10 ADo 2.2.2.19/32 172.16.1.86 110
...
38 ADC 63.97.254.0/24 63.97.254.2 ether1 0
39 Do 63.97.254.0/24 172.16.1.10 110
172.16.1.11
...
60 ADo 63.97.254.211/32 172.16.1.86 110
62 ADo 63.97.254.250/32 172.16.1.86 110
...
89 ADo 172.16.1.86/32 172.16.1.86 110
90 ADo 172.16.1.89/32 172.16.1.86 110
91 ADo 172.16.1.90/32 172.16.1.86 110
/ip firewall filter> pri
Flags: X - disabled, I - invalid, D - dynamic
6 ;;; Drop Pings
chain=input action=log protocol=icmp src-address-list=!Allow List
log-prefix="Ping"
7 chain=input action=drop protocol=icmp src-address-list=!Allow List
WHY???!!! It only breaks troubleshooting. Of course, so does having routed hops without public IP spaces on the links. Burn a /30 on each backhaul which is visible to the customer/ someone troubleshooting connectivity to the customer. Life is too short for non-functional network addressing.
00:43:11 Mon Dec 30 $ traceroute 63.97.254.211
traceroute to 63.97.254.211 (63.97.254.211), 64 hops max, 52 byte packets
...
6 cr2.dlstx.ip.att.net (12.122.157.97) 36.516 ms 30.348 ms 31.854 ms
7 12.122.212.13 (12.122.212.13) 31.402 ms 25.718 ms 35.289 ms
8 192.205.37.126 (192.205.37.126) 32.492 ms 33.848 ms 25.758 ms
9 0.xe-5-1-6.xt4.dfw9.alter.net (152.63.96.29) 31.578 ms
0.xe-5-1-4.xt3.dfw9.alter.net (152.63.96.25) 26.968 ms
0.xe-5-1-6.xt4.dfw9.alter.net (152.63.96.29) 26.537 ms
10 pos6-0.gw10.dfw9.alter.net (152.63.101.129) 20.194 ms 19.785 ms 20.001 ms
11 airespring-gw.customer.alter.net (152.179.74.122) 35.586 ms 34.375 ms 34.716 ms
12 host2.iamigo.com (63.97.254.2) 45.100 ms 44.517 ms 52.703 ms
13 * * *
14 * *^C
01:00:07 Mon Dec 30 $ traceroute 63.97.254.250
traceroute to 63.97.254.250 (63.97.254.250), 64 hops max, 52 byte packets
...
6 cr2.dlstx.ip.att.net (12.122.157.97) 34.685 ms 37.973 ms 31.170 ms
7 12.122.212.13 (12.122.212.13) 38.345 ms 68.697 ms 63.759 ms
8 192.205.37.126 (192.205.37.126) 28.944 ms 25.497 ms 26.671 ms
9 0.xe-5-1-4.xt3.dfw9.alter.net (152.63.96.25) 47.669 ms
0.xe-5-1-6.xt4.dfw9.alter.net (152.63.96.29) 96.193 ms 34.422 ms
10 pos7-0.gw10.dfw9.alter.net (152.63.101.133) 31.476 ms 31.334 ms
pos6-0.gw10.dfw9.alter.net (152.63.101.129) 19.742 ms
11 airespring-gw.customer.alter.net (152.179.74.122) 33.993 ms 35.802 ms 34.912 ms
12 host2.iamigo.com (63.97.254.2) 44.630 ms 45.125 ms 47.713 ms
13 * * *
14 * * *
/ip firewall nat> pri
Flags: X - disabled, I - invalid, D - dynamic
Nothing to do with our host IP ranges, looks okay.
/ip firewall address-list> pri
Flags: X - disabled, D - dynamic
# LIST ADDRESS
0 ;;; Dude Server - Alva
Allow List 63.97.254.54
1 X management 64.250.193.0/24
2 ;;; Dude Server - Woodward
Allow List 216.207.94.25
3 management 172.16.6.0/26
4 ;;; Bank Network
Allow List 64.250.193.94
So, "Allow List" is your only address list on any of the routers?
I don't see 63.97.254.0/24 in the "Allow List" how do you get traceroute responses?
We need the relevant information, like what I left above, for the other three routers which are involved. Anything that references an IP in the traceroutes.
In the below traceroutes, does 63.97.254.211 and 250 live on these MikroTiks from which you are running the trace?
Tracert from customer unit to 8.8.8.8
admin@SU: [hwchurch]] /tool> trace <--- No Internet
address: 8.8.8.8
# ADDRESS RT1 RT2 RT3 STATUS
1 172.16.1.90 7ms 8ms 11ms
2 172.16.1.89 3ms 11ms 12ms
3 172.16.1.85 4ms 7ms 3ms
4 0.0.0.0 0ms 0ms 0ms
5 0.0.0.0 0ms 0ms 0ms
[admin@Saulsbury Industries (Chesapeak)] > tool <--- Working Customer On Same AP using same backhaul
[admin@Saulsbury Industries (Chesapeak)] /tool> trace
address: 8.8.8.8
# ADDRESS RT1 RT2
1 172.16.1.90 1ms 2ms
2 172.16.1.89 3ms 3ms
3 172.16.1.85 4ms 3ms
4 63.97.254.1 6ms 11ms
5 152.179.74.121 20ms 16ms
6 152.63.101.134 20ms 18ms
7 152.63.84.14 39ms 39ms
8 152.179.241.10 39ms 45ms
9 72.14.239.100 39ms 40ms
10 66.249.94.24 41ms 40ms
11 209.85.243.254 41ms 41ms
12 0.0.0.0 0ms 0ms
13 8.8.8.8 41ms 41ms
tracert to customer unit with no Internet
C:\Users\Administrator>tracert 63.97.254.211
Tracing route to host211.iamigo.com [63.97.254.211]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.16.6.1
2 <1 ms <1 ms <1 ms 172.16.1.110
3 <1 ms <1 ms <1 ms 172.16.1.109
4 1 ms 1 ms 1 ms 172.16.1.105
5 17 ms 20 ms 20 ms 172.16.1.101
6 2 ms 21 ms 19 ms 172.16.1.1
7 9 ms 18 ms 18 ms 172.16.1.9
8 3 ms 13 ms 5 ms 172.16.1.86
9 6 ms 20 ms 17 ms 172.16.1.90
10 5 ms 19 ms 21 ms host211.iamigo.com [63.97.254.211]
Trace complete.
tracert to customer unit with Internet
C:\Users\Administrator>tracert 63.97.254.211 > traceche.txt
C:\Users\Administrator>tracert 63.97.254.250
Tracing route to host250.iamigo.com [63.97.254.250]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.16.6.1
2 <1 ms <1 ms <1 ms 172.16.1.110
3 <1 ms <1 ms <1 ms 172.16.1.109
4 4 ms 1 ms 2 ms 172.16.1.105
5 2 ms 19 ms 20 ms 172.16.1.101
6 3 ms 19 ms 20 ms 172.16.1.1
7 13 ms 3 ms 19 ms 172.16.1.9
8 6 ms 20 ms 3 ms 172.16.1.86
9 7 ms 17 ms 10 ms 172.16.1.90
10 10 ms 15 ms 61 ms host250.iamigo.com [63.97.254.250]
Trace complete
We're going to have to see the RADIUS attributes for each customer.
63.97.254.211 static IP
Working Customer
|
|
|
AP / Bridged Backhaul
172.16.1.90 wlan1 <------> 172.16.1.88 wlan <-----> 172.16.1.85 ether10 <---> 63.97.254.1
| 172.16.1.84 ether1 RB1100 in question Internet
|
|
63.97.254.250 static IP
Non-Internet Customer
Customers without a static IP address are given an address from a private IP pool
You need to follow the packet through each hop looking at the firewall/nat rules and comparing them to the source address of the customer's packet. There is something, most likely in your other routers, which is doing something with packets from your customer to {not your IP space}. The problem customer may be in a dynamic address list which is used in a firewall or nat rule. The RADIUS attributes may be hosed for the problem customer and creating dynamic firewall rules for them which block their traffic to the Internet. You showed us 5% of the relevant data.
I'm very busy at work. It may be another month before I get back into the forums to look at follow-up. If you do your part of the homework, someone else may have the patience to review the relevant info sooner.