On 10/04/2018 11:30 PM, Vieri Di Paola via Shorewall-users wrote: > I finally got it working, but I still have a few doubts (see below). > > On Thursday, October 4, 2018, 12:25:05 PM GMT+2, Vieri Di Paola via > Shorewall-users <shorewall-users@lists.sourceforge.net> wrote: >> >> If I were to move to my 3-ppp setup, I guess I would need to specify the ppp >> option "defaultroute" for each ppp interface, right? > > Setting up the "defaultroute" option on all three ppp interfaces did the > trick. > >> Also, when starting or restarting shorewall for the first time, I get this >> message: >> WARNING: Interface enp7s0 is not usable -- Provider ISP1 (1) not Started >> (same thing for the other 2 providers) >> This also happened when I used the pppoe links instead of ethernet. >> However, all 3 providers are up and running, ie., I can successfully ping to >> a remote host through their interfaces. >> I need to manually run "shorewall enable INTERFACE" and restart shorewall. >> No issues from this point onwards. >> So why is Shorewall complaining about the interfaces? How does it decide if >> it's "usable"? > > This can still happen, but it's not always reproducible. > > However, there's one more awkward situation I've noticed today. > In my fully working 3-pppoe gateway setup, I decided to physically shut down > one of my 3 provider modems and boot it back up again to see what happened > (say, ppp3). I was unable to access Internet via ppp3 even after a long while > (to allow it to sync). > My ppp options are as follows: > > noauth > defaultroute > persist > holdoff 0 > maxfail 0 > noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp > > > I still haven't found the time to fully check what went wrong, but here's > what I did to bring the link back up: > > First, I manually restarted the ppp3 interface and waited for full sync. I > checked the logs and confirmed that it was all up and running (authenticated, > etc.). > > However, I still didn't have connectivity through this pppoe link. > > I then issued "shorewall reenable ppp3", and SW reported that it had first > "stopped" the ppp3 provider and then "started" it (which means that shorewall > didn't automatically disable it while the modem was rebooting).
Shorewall will NEVER automatically disable an interface when it goes down; that is the job of a link monitor like FooLSM. > > I still had no connectivity through this pppoe link. > > Finally, a shorewall restart (full stop and start) actually DID solve the > issue. I magically got my ppp3 link working again. > So, of course, I'm worried that if there's a power outage or if someone > reboots the modems then the gateway might get cut off from the Internet if > shorewall doesn't restart. I can't comment without seeing the difference between the ruleset after 'reenable' and the ruleset after 'restart'. > >> I have the following: >> # sysctl net.core.default_qdisc >> net.core.default_qdisc = fq_codel >> # sysctl net.ipv4.tcp_congestion_control >> net.ipv4.tcp_congestion_control = cdg >> # ip addr show | grep qdisc >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group >> default qlen >> 10002: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast >> state UP group default qlen >> 10003: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc tbf state UP >> group default qlen >> 10004: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc tbf state UP >> group default qlen >> 10005: enp8s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc tbf state UP >> group default qlen >> 10006: enp10s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast >> state UP group default qlen 1000 >> Why do I see pfifo_fast and tbf instead of fq_codel? > > OK, I think I got this one. > I had TC_ENABLED=Simple. Disabling it activates fq_codel on all "outer > interfaces", but not on the "inner" eth interfaces. > > # ip addr show | grep qdisc > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1000 > 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP group default qlen 1000 > 3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP > group default qlen 1000 > 4: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP > group default qlen 1000 > 5: enp8s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP > group default qlen 1000 > 6: enp10s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP group default qlen 1000 > 7: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel > state UNKNOWN group default qlen 3 > 8: ppp2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel > state UNKNOWN group default qlen 3 > 10: ppp3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel > state UNKNOWN group default qlen 3 > > I still don't know why some interfaces are set to use pfifo_fast, or if it's > recommended or not for a gateway/router. > Which has nothing to do with Shorewall... -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
