Forwarding Protocols • Re: Peculiar PCC setup/issue and more

First, let's sort out some things.

• just to avoid confusing other folks reading your post - the phone cable is not connected to a "bridge" but to a modem in bridge mode.
• the reason why the PPPoE client cannot be attached directly to the Ethernet interface and a VLAN is required is that other services (namely, IPTV and telephony) may be optionally provided on the same physical path and VLANs are used to logically partition the physical media. Big companies have to use "one size fits all" solutions wherever possible so even if you only subscribe to internet, the protocol hierarchy on the physical media stays the same.
• PPPoE, like all the other protocols based on PPP, does not use DHCP to assign an address to the client; instead, PPP uses its own procedures for that. So you cannot use any methods of obtaining the gateway address that rely on operation of a DHCP client.

Next, the routing.

• /ip/address/print shows you three items - address, network, and interface:
  Code:

  [me@myTik] > ip address printFlags: X - disabled, I - invalid, D - dynamic #   ADDRESS            NETWORK         INTERFACE 0   192.168.88.1/24    192.168.88.0    bridge 1 D 10.213.126.51/32   10.10.10.1      pppoe-o2

  In case of PPP, the network one is what you should set as a gateway of a route to let the routing look the out-interface up by an address. According to your configuration, it seems you have used your own address assigned by O2 as the gateway of the routes, which is not correct. What you haven't done right either is the configuration of the dst-address of those routes: 0.0.0.0/32 means literally only a single exact address 0.0.0.0, as the /32 specifies that each of the "first 32" bits of the address (which actually means all of them) must have a value of 0. To make those routes work, you have to change that to 0.0.0.0/0, meaning "the whole IPv4 address range", as each of the 32 bits of the address except the "0th one" (so actually all of them) can have either value.
• it's very likely that you cannot ping the network address associated to the PPPoE address (10.10.10.1 in the example above) manually, so set check-gateway on the routes using that gateway to none. Most likely no equipment actually listens at that address, because the sole purpose of that address is to serve as a kind of alias for the interface name, as mentioned above. If you want to check the transparency of the "oh too" uplink all the way to the internet because you suspect the PPPoE part could be up but the data would not get through (which can indeed happen), you have to use the "recursive routing" approach as described multiple times here on the forum, the primary resource being viewtopic.php?t=157048 .

DNS server addresses are yet another issue - those listed in your configuration seem to be "internal" ones of the respective ISPs, which typically means that although their addresses are "public" in the sense of address type, they do not respond to requests coming from outside the network of the respective ISP. So if you send a request via a "wrong" uplink by chance, you'll never get a response. To deal with this, you have two options, either manually set the DNS addresses to some publicly accessible ones (like Google, Cloudflare, Quad9 to name the most well-known ones), or add dedicated /32 routes towards the addresses provided by the ISPs via their respective uplinks, but such a solution is a bit fragile as the ISPs may decide to change those addresses next year or next minute. If you decide to use the publicly accessible ones and at the same time to use the recursive next hop search to check the fitness of the uplink, make sure that you do not use the same address for DNS and as a canary address for the next hop search.

Statistics: Posted by sindy — Wed May 22, 2024 10:28 am

---