Hey all, I am setting up a new Firewall with Shorewall Version 4.5.20 iptables v1.4.18 Kernel 3.10.10 perl v5.16.3 v6.19, protocol version: 6 quagga 0.99.22.3 providers file is ISP1 1 0x100 - vlan10 10.0.11.1 track,loose - ISP2 2 0x200 - vlan11 10.0.12.1 track,loose - in shorewall.conf USE_DEFAULT_RT=Yes MULTICAST=Yes On the same host zebra is running and I''ve just inserted some default static routes like ip route 3.3.3.3/32 10.0.12.1 After shorewall is started *and* zebra is restarted zebra cannot inject static routes into the kernel anymore .. vtysh -c "show ip route" shows S 3.3.3.3/32 [1/0] via 10.0.12.1 inactive and linux ip route command does not show the route at all .. I have another Firewall with shorewall 4.4.27.3 running bgp and zebra with no such problems Please Advise Regards Harry ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
Does vlan11 go down down when you stop zebra? If it does try adding "optional" to the interface: vlan11 eth? detect optional On Thu, Sep 12, 2013 at 8:11 AM, HL <freemail.grharry@gmail.com> wrote:> Hey all, > > I am setting up a new Firewall with > > Shorewall Version 4.5.20 > iptables v1.4.18 > Kernel 3.10.10 > perl v5.16.3 > v6.19, protocol version: 6 > quagga 0.99.22.3 > > providers file is > ISP1 1 0x100 - vlan10 10.0.11.1 track,loose - > ISP2 2 0x200 - vlan11 10.0.12.1 track,loose - > > in shorewall.conf > > USE_DEFAULT_RT=Yes > MULTICAST=Yes > > On the same host zebra is running and I''ve just inserted some default > static routes like > > ip route 3.3.3.3/32 10.0.12.1 > > After shorewall is started *and* zebra is restarted > zebra cannot inject static routes into the kernel anymore .. > vtysh -c "show ip route" shows > > S 3.3.3.3/32 [1/0] via 10.0.12.1 inactive > > and linux ip route command does not show the route at all .. > > I have another Firewall with shorewall 4.4.27.3 > running bgp and zebra > with no such problems > > Please Advise > Regards > Harry > > > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
On 9/13/2013 6:01 AM, HL wrote:> After endless tries the only way that I have managed to feed zebra > routes into kernel is .. > #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY > OPTIONS COPY > ISP1 1 0x100 main vlan10 > 10.0.11.1 track,loose - > ISP2 2 0x200 main vlan11 > 10.0.12.1 track,loose - > > and > in shorewall.conf > USE_DEFAULT_RT=No > > In particular when the duplicate column is empty thus ''-'' causes a lot > of problems > > Final Question is ... Is SHOREWALL compatible with networking suites > like quagga - ZEBRA ... > Or it completely ignores the other partners in the system and bosses - > messes around things ??I consider Shorewall''s multi-ISP facility to be an alternative to using routing protocols. Given that my ISPs don''t support such protocols, I personally have no way to test the interaction between zebra/quagga and Shorewall. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
On 13/09/2013 04:35 μμ, Tom Eastep wrote:> On 9/13/2013 6:01 AM, HL wrote: >> After endless tries the only way that I have managed to feed zebra >> routes into kernel is .. >> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY >> OPTIONS COPY >> ISP1 1 0x100 main vlan10 >> 10.0.11.1 track,loose - >> ISP2 2 0x200 main vlan11 >> 10.0.12.1 track,loose - >> >> and >> in shorewall.conf >> USE_DEFAULT_RT=No >> >> In particular when the duplicate column is empty thus '-' causes a lot >> of problems >> >> Final Question is ... Is SHOREWALL compatible with networking suites >> like quagga - ZEBRA ... >> Or it completely ignores the other partners in the system and bosses - >> messes around things ?? > I consider Shorewall's multi-ISP facility to be an alternative to using > routing protocols. Given that my ISPs don't support such protocols, I > personally have no way to test the interaction between zebra/quagga and > Shorewall. > > -TomHi Tom and thanks However, Your inspiring "http://www.shorewall.net/MultiISP.html" pages indicate I quote: "For most routing applications, Quagga is a *better* solution although it requires that your ISPs offer routing protocol support." Well, I also don't really have ISP protocol Support rather than 2 modems with zera-ripd and the like in front of linux *shorewall* box connected to the ISPs. I really don't understand, don't have a clue, or hint, why zebra is blocked to add or remove routes. For instance in your case you only need to install zebra with *no* other daemon to test it. In my case zebra GETS Blocked. Why? Regards. Harry. ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
On 13/09/2013 04:35 μμ, Tom Eastep wrote:> On 9/13/2013 6:01 AM, HL wrote: >> After endless tries the only way that I have managed to feed zebra >> routes into kernel is .. >> #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY >> OPTIONS COPY >> ISP1 1 0x100 main vlan10 >> 10.0.11.1 track,loose - >> ISP2 2 0x200 main vlan11 >> 10.0.12.1 track,loose - >> >> and >> in shorewall.conf >> USE_DEFAULT_RT=No >> >> In particular when the duplicate column is empty thus '-' causes a lot >> of problems >> >> Final Question is ... Is SHOREWALL compatible with networking suites >> like quagga - ZEBRA ... >> Or it completely ignores the other partners in the system and bosses - >> messes around things ?? > I consider Shorewall's multi-ISP facility to be an alternative to using > routing protocols. Given that my ISPs don't support such protocols, I > personally have no way to test the interaction between zebra/quagga and > Shorewall. > > -TomPlease also consider that I was faced with the following scenario in the past 3 ISP's 1 required me to run BGP with a private AS number so that he could see me alive and activate his routes. The remaining ISP's didn't offer BGP protocols. I had to run bgp daemon with out zebra in order to see traffic comming in from the bgp provider. Mean while the site had a vpn with a remote building that I've install ripd and found it very convenient with no need to monitor ( ping ) lines to alternate routes. Thank's again Regards, Harry. ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
On 9/13/2013 7:08 AM, HL wrote:> For instance in your case you only need to install zebra with *no* other > daemon to test it. > > In my case > zebra GETS Blocked. Why?I''ll try it over the weekend. After I''ve installed and started zebra, what must I do to try to reproduce your problem? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
On 13/09/2013 05:52 μμ, Tom Eastep wrote:> On 9/13/2013 7:08 AM, HL wrote: > >> For instance in your case you only need to install zebra with *no* other >> daemon to test it. >> >> In my case >> zebra GETS Blocked. Why? > I'll try it over the weekend. After I've installed and started zebra, > what must I do to try to reproduce your problem? > > -Tom >just place a '-' under column COPY of your providers file and under "OPTIONS" track,loose Restart Shorewall Then from vtysh or zebra shell conf t ip route 8.8.8.8/32 "ip address of a specific provider" exit vtysh or zebra ip route will not show the route to 8.8.8.8 vtysh -c "show ip route" will list the enty 8.8.8.8 as inactive Further digging regarding quagga zebra + iproute2 and rt_tables I've found this. http://lists.quagga.net/pipermail/quagga-users/2008-February/009359.html Thanx^10 for this .... Regards Harry. ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
On 09/13/2013 10:17 AM, HL wrote:> On 13/09/2013 07:25 μμ, Tom Eastep wrote: >> On 09/13/2013 09:21 AM, HL wrote: >>> On 13/09/2013 05:52 μμ, Tom Eastep wrote: >>>> On 9/13/2013 7:08 AM, HL wrote: >>>> >>>>> For instance in your case you only need to install zebra with *no* >>>>> other >>>>> daemon to test it. >>>>> >>>>> In my case >>>>> zebra GETS Blocked. Why? >>>> I''ll try it over the weekend. After I''ve installed and started zebra, >>>> what must I do to try to reproduce your problem? >>>> >>>> -Tom >>>> >>> just place a ''-'' under column COPY of your providers file >>> and under "OPTIONS" track,loose >>> >>> Restart Shorewall >>> >>> Then >>> from vtysh >>> or zebra shell >>> conf t >>> ip route 8.8.8.8/32 "ip address of a specific provider" >>> >>> exit vtysh or zebra >>> >>> ip route >>> will not show the route to 8.8.8.8 >>> >>> vtysh -c "show ip route" >>> will list the enty 8.8.8.8 as inactive >>> >>> Further digging regarding quagga zebra + iproute2 and rt_tables I''ve >>> found this. >>> http://lists.quagga.net/pipermail/quagga-users/2008-February/009359.html >> Let''s back up a bit. I''ve just installed quagga on my Debian gateway. >> >> If I run vtysh, I get: >> >> root@gateway:/etc/pam.d# vtysh >> Exiting: failed to connect to any daemons. >> root@gateway:/etc/pam.d# >> >> -Tom > your have to start zebra first ... ;-) > > with minimal conf in /etc/quagga/zebra.conf > Commets start with ! > > ------------------------------------------------------------------ > hostname Router > password zebra > enable password zebra > ! > ! Interface''s description. > ! > !interface lo > ! description test of desc. > ! > !interface sit0 > ! multicast > > ! > ! Static default route sample. > ! > !ip route 0.0.0.0/0 203.181.89.241 > !I can''t even get this to work when Shorewall is cleared. See attached log: -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
On 09/14/2013 07:18 AM, Tom Eastep wrote:> > I can''t even get this to work when Shorewall is cleared. See attached log: >Okay -- I did another experiment on a Virtual Machine running Foobar 6 (a derivative of RHEL 6). It has two uplinks - one wired (eth0) and one wireless (eth1). /etc/shorewall/shorewall.conf: ... USE_DEFAULT_RT=Yes ... TRACK_PROVIDERS=Yes ... TC_BITS=14 PROVIDER_BITS=8 PROVIDER_OFFSET=0 MASK_BITS=16 ZONE_BITS=0 /etc/shorewall/providers: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY LAN 1 - - eth0 detect balance WLAN 2 - - eth1 detect fallback [root@foobar64 quagga]# service zebra start Starting zebra: [ OK ] [root@foobar64 quagga]# vtysh Hello, this is Quagga (version 0.99.15). Copyright 1996-2005 Kunihiro Ishiguro, et al. foobar64.shorewall.net# exit [root@foobar64 quagga]# vtysh -c "ip show route" % Unknown command. [root@foobar64 quagga]# vtysh -c "ip route show" % Unknown command. [root@foobar64 quagga]# vtysh -c "show ip route" Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 10.0.0.0/24 is directly connected, eth1 C>* 127.0.0.0/8 is directly connected, lo C>* 172.20.1.0/24 is directly connected, eth0 [root@foobar64 quagga]# vtysh Hello, this is Quagga (version 0.99.15). Copyright 1996-2005 Kunihiro Ishiguro, et al. foobar64.shorewall.net# conf t foobar64.shorewall.net(config)# ip route 8.8.8.8/32 172.20.1.254 foobar64.shorewall.net(config)# quit % Unknown command. foobar64.shorewall.net(config)# vtysh -c "show ip route" % Unknown command. foobar64.shorewall.net(config)# exit foobar64.shorewall.net# exit [root@foobar64 quagga]# vtysh -c "show ip route" Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route S>* 8.8.8.8/32 [1/0] via 172.20.1.254, eth0 C>* 10.0.0.0/24 is directly connected, eth1 C>* 127.0.0.0/8 is directly connected, lo C>* 172.20.1.0/24 is directly connected, eth0 [root@foobar64 quagga]# This is how I would have expected it to work. USE_DEFAULT_RT=Yes has the advantage that the ''main'' table is traversed first. So all of the routes added by Zebra will be seen prior to jumping to the provider-specific tables; those tables contain only default routes. -- [root@foobar64 quagga]# shorewall show routing Shorewall 4.5.20 Routing at foobar64.shorewall.net - Sat Sep 14 08:11:14 PDT 2013 Routing Rules 0: from all lookup local 999: from all lookup main 10000: from all fwmark 0x1/0xff lookup LAN 10001: from all fwmark 0x2/0xff lookup WLAN 20000: from 172.20.1.152 lookup LAN 20000: from 10.0.0.5 lookup WLAN 32765: from all lookup balance 32767: from all lookup default Table balance: default via 172.20.1.254 dev eth0 Table default: 10.0.0.1 dev eth1 scope link default via 10.0.0.1 dev eth1 src 10.0.0.5 metric 2 Table LAN: 172.20.1.254 dev eth0 scope link src 172.20.1.152 default via 172.20.1.254 dev eth0 src 172.20.1.152 Table local: local 172.20.1.152 dev eth0 proto kernel scope host src 172.20.1.152 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 10.0.0.5 dev eth1 proto kernel scope host src 10.0.0.5 broadcast 172.20.1.255 dev eth0 proto kernel scope link src 172.20.1.152 broadcast 172.20.1.0 dev eth0 proto kernel scope link src 172.20.1.152 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 broadcast 10.0.0.255 dev eth1 proto kernel scope link src 10.0.0.5 broadcast 10.0.0.0 dev eth1 proto kernel scope link src 10.0.0.5 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 Table main: 8.8.8.8 via 172.20.1.254 dev eth0 proto zebra 172.20.1.254 dev eth0 scope link src 172.20.1.152 10.0.0.1 dev eth1 scope link src 10.0.0.5 172.20.1.0/24 dev eth0 proto kernel scope link src 172.20.1.152 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.5 metric 1 Table WLAN: 10.0.0.1 dev eth1 scope link src 10.0.0.5 default via 10.0.0.1 dev eth1 src 10.0.0.5 [root@foobar64 quagga]# shorewall version -a shorewall-core: 4.5.20 shorewall: 4.5.20 shorewall6: 4.5.20 [root@foobar64 quagga]# FWIW, my failed experiments were on my main gateway that runs Debian 7. I''ve attached the Shorewall configuration directory. Regards, -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
On 09/14/2013 08:17 AM, Tom Eastep wrote:> > FWIW, my failed experiments were on my main gateway that runs Debian 7. >And the Shorewall configuration that works on Foobar 6 fails on Debian 7. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
On Sat, Sep 14, 2013 at 9:01 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 09/14/2013 08:17 AM, Tom Eastep wrote: > > FWIW, my failed experiments were on my main gateway that runs Debian 7. > And the Shorewall configuration that works on Foobar 6 fails on Debian 7. > -TomFYI, Works fine on CentOS 5 too. [CAVEAT: 10.1.5.1 is my FW address, not the next-hop. That does create an inactive route...] (config)# ip route 1.2.3.4/32 10.1.5.1 # show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route S>* 1.2.3.4/32 [1/0] via 10.1.5.1, eth1.5 [root@centralservices ~]# ip route 65.209.210.217 dev eth1.8 scope link src 65.209.210.218 24.52.191.241 dev eth1.9 scope link src 24.52.191.244 1.2.3.4 via 10.1.5.1 dev eth1.5 proto zebra equalize --lee ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
On 9/14/2013 9:51 AM, HL wrote:> On 14/09/2013 05:18 μμ, Tom Eastep wrote: >> On 09/13/2013 10:17 AM, HL wrote: >>> On 13/09/2013 07:25 μμ, Tom Eastep wrote: >>>> On 09/13/2013 09:21 AM, HL wrote: >>>>> On 13/09/2013 05:52 μμ, Tom Eastep wrote: >>>>>> On 9/13/2013 7:08 AM, HL wrote: >>>>>> >>>>>>> For instance in your case you only need to install zebra with *no* >>>>>>> other >>>>>>> daemon to test it. >>>>>>> >>>>>>> In my case >>>>>>> zebra GETS Blocked. Why? >>>>>> I''ll try it over the weekend. After I''ve installed and started zebra, >>>>>> what must I do to try to reproduce your problem? >>>>>> >>>>>> -Tom >>>>>> >>>>> just place a ''-'' under column COPY of your providers file >>>>> and under "OPTIONS" track,loose >>>>> >>>>> Restart Shorewall >>>>> >>>>> Then >>>>> from vtysh >>>>> or zebra shell >>>>> conf t >>>>> ip route 8.8.8.8/32 "ip address of a specific provider" >>>>> >>>>> exit vtysh or zebra >>>>> >>>>> ip route >>>>> will not show the route to 8.8.8.8 >>>>> >>>>> vtysh -c "show ip route" >>>>> will list the enty 8.8.8.8 as inactive >>>>> >>>>> Further digging regarding quagga zebra + iproute2 and rt_tables I''ve >>>>> found this. >>>>> http://lists.quagga.net/pipermail/quagga-users/2008-February/009359.html >>>>> >>>> Let''s back up a bit. I''ve just installed quagga on my Debian gateway. >>>> >>>> If I run vtysh, I get: >>>> >>>> root@gateway:/etc/pam.d# vtysh >>>> Exiting: failed to connect to any daemons. >>>> root@gateway:/etc/pam.d# >>>> >>>> -Tom >>> your have to start zebra first ... ;-) >>> >>> with minimal conf in /etc/quagga/zebra.conf >>> Commets start with ! >>> >>> ------------------------------------------------------------------ >>> hostname Router >>> password zebra >>> enable password zebra >>> ! >>> ! Interface''s description. >>> ! >>> !interface lo >>> ! description test of desc. >>> ! >>> !interface sit0 >>> ! multicast >>> >>> ! >>> ! Static default route sample. >>> ! >>> !ip route 0.0.0.0/0 203.181.89.241 >>> ! >> I can''t even get this to work when Shorewall is cleared. See attached >> log: >> >> -Tom >> >> > Sorry for the late answer gmail insists on moving shorewall mail into > Important folder or SPAM folder. > > Anyway. > > Correct, same here ! > is something left behind after shorewall is stopped and cleared ??? > > As I mentioned in my mail 2 U this morning > I suspect that the Packet mark stuff --TC_BITS, Provider bits and the > like-- have something to do with the zebra getting blocked-Which distribution are you running? -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
On 9/14/2013 10:26 AM, HL wrote:> I Removed the .... DEFAULT GATEWAY and placed a ''-'' > After all zebra should do that, right! > > And I thing ... Bingo ! > ip r > default via 10.0.173.254 dev eth0 proto zebra > 4.5.4.5 via 192.168.21.254 dev vlan122 proto zebra > 10.0.173.0/24 dev eth0 proto kernel scope link src 10.0.173.193 > 45.45.45.45 via 192.168.21.254 dev vlan122 proto zebra > 99.99.99.99 via 192.168.21.254 dev vlan122 proto zebra > 192.168.21.0/24 dev vlan122 proto kernel scope link src 192.168.21.1 > alpdev-2_5_4:/etc/shorewall# vtysh > > Hello, this is Quagga (version 0.99.22.4). > Copyright 1996-2005 Kunihiro Ishiguro, et al. > > alpdev-2_5_4# conf t > alpdev-2_5_4(config)# ip route 5.5.5.5/32 192.168.21.254 > alpdev-2_5_4(config)# ^Z > alpdev-2_5_4# show ip route > Codes: K - kernel route, C - connected, S - static, R - RIP, > O - OSPF, I - IS-IS, B - BGP, A - Babel, > > - selected route, * - FIB route > > S>* 0.0.0.0/0 [1/0] via 10.0.173.254, eth0 > S>* 4.5.4.5/32 [1/0] via 192.168.21.254, vlan122 > S>* 5.5.5.5/32 [1/0] via 192.168.21.254, vlan122 > C>* 10.0.173.0/24 is directly connected, eth0 > S>* 45.45.45.45/32 [122/0] via 192.168.21.254, vlan122 > S>* 99.99.99.99/32 [1/0] via 192.168.21.254, vlan122 > C>* 127.0.0.0/8 is directly connected, lo > C>* 192.168.21.0/24 is directly connected, vlan122 > > alpdev-2_5_4:/etc/shorewall# ip r > default via 10.0.173.254 dev eth0 proto zebra > 4.5.4.5 via 192.168.21.254 dev vlan122 proto zebra > 5.5.5.5 via 192.168.21.254 dev vlan122 proto zebra > 10.0.173.0/24 dev eth0 proto kernel scope link src 10.0.173.193 > 45.45.45.45 via 192.168.21.254 dev vlan122 proto zebra > 99.99.99.99 via 192.168.21.254 dev vlan122 proto zebra > 192.168.21.0/24 dev vlan122 proto kernel scope link src 192.168.21.1 > > #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS > COPY > isp1 1 0x100 - eth0 - track,loose > isp2 2 0x200 - vlan122 - track,loose > > shorewall show routing > Shorewall 4.5.20 Routing at alpdev-2_5_4 - Sat Sep 14 17:25:26 UTC 2013 > > > Routing Rules > > 0: from all lookup local > 999: from all lookup main > 10000: from all fwmark 0x100/0xff00 lookup isp1 > 10001: from all fwmark 0x200/0xff00 lookup isp2 > 32765: from all lookup 250 > 32766: from all lookup main > 32767: from all lookup default > > Table 250: > > > Table default: > > > Table isp1: > > default dev eth0 scope link >But there is no point in even using Shorewall''s Multi-ISP this way since the above route is completely useless on an Ethernet interface. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
On 14/09/2013 08:57 μμ, Tom Eastep wrote:> But there is no point in even using Shorewall's Multi-ISP this way since > the above route is completely useless on an Ethernet interface.Hi, Tom As promised before shorewall start #ip r default proto zebra nexthop via 10.0.11.1 dev eth1 weight 1 nexthop via 10.0.12.1 dev eth2 weight 1 8.8.4.4 via 10.0.12.1 dev eth2 proto zebra 8.8.8.8 via 10.0.11.1 dev eth1 proto zebra 10.0.11.0/24 dev eth1 proto kernel scope link src 10.0.11.2 10.0.12.0/24 dev eth2 proto kernel scope link src 10.0.12.2 10.52.0.0/24 dev eth0 proto kernel scope link src 10.52.0.77 --------------------------------------------------------------------------------------- after shorewall start default proto zebra nexthop via 10.0.11.1 dev eth1 weight 1 nexthop via 10.0.12.1 dev eth2 weight 1 8.8.4.4 via 10.0.12.1 dev eth2 proto zebra 8.8.8.8 via 10.0.11.1 dev eth1 proto zebra 10.0.11.0/24 dev eth1 proto kernel scope link src 10.0.11.2 10.0.11.1 dev eth1 scope link src 10.0.11.2 <============= THESE cause the problem .. 10.0.12.0/24 dev eth2 proto kernel scope link src 10.0.12.2 10.0.12.1 dev eth2 scope link src 10.0.12.2 <============= **** Problem 10.52.0.0/24 dev eth0 proto kernel scope link src 10.52.0.77 Entered a and got an inactive route S>* 8.8.8.8/32 [1/0] via 10.0.11.1, eth1 S 9.9.9.9/32 [1/0] via 10.0.11.1 inactive C>* 10.0.11.0/24 is directly connected, eth1 No mater what the providers file configuration was. So I guess the question is, Isn't the route entry "10.0.11.1 dev eth1 scope link src 10.0.11.2 redundant and covered all-ready by "10.0.11.0/24 dev eth1 proto kernel scope link src 10.0.11.2" ???? If I remove these routes from the tables all seem to work with no problem at all and very smoothly! Thanks in advance and Regards Harry. ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
On 9/18/2013 9:04 AM, HL wrote:> On 14/09/2013 08:57 μμ, Tom Eastep wrote: >> But there is no point in even using Shorewall''s Multi-ISP this way since >> the above route is completely useless on an Ethernet interface. > Hi, Tom > > As promised > before shorewall start > > #ip r > default proto zebra > nexthop via 10.0.11.1 dev eth1 weight 1 > nexthop via 10.0.12.1 dev eth2 weight 1 > 8.8.4.4 via 10.0.12.1 dev eth2 proto zebra > 8.8.8.8 via 10.0.11.1 dev eth1 proto zebra > 10.0.11.0/24 dev eth1 proto kernel scope link src 10.0.11.2 > 10.0.12.0/24 dev eth2 proto kernel scope link src 10.0.12.2 > 10.52.0.0/24 dev eth0 proto kernel scope link src 10.52.0.77 > --------------------------------------------------------------------------------------- > > after > shorewall start > default proto zebra > nexthop via 10.0.11.1 dev eth1 weight 1 > nexthop via 10.0.12.1 dev eth2 weight 1 > 8.8.4.4 via 10.0.12.1 dev eth2 proto zebra > 8.8.8.8 via 10.0.11.1 dev eth1 proto zebra > 10.0.11.0/24 dev eth1 proto kernel scope link src 10.0.11.2 > 10.0.11.1 dev eth1 scope link src 10.0.11.2 <============= THESE > cause the problem .. > 10.0.12.0/24 dev eth2 proto kernel scope link src 10.0.12.2 > 10.0.12.1 dev eth2 scope link src 10.0.12.2 <============= **** Problem > 10.52.0.0/24 dev eth0 proto kernel scope link src 10.52.0.77 > > Entered a > and got an inactive route > S>* 8.8.8.8/32 [1/0] via 10.0.11.1, eth1 > S 9.9.9.9/32 [1/0] via 10.0.11.1 inactive > C>* 10.0.11.0/24 is directly connected, eth1 > > No mater what the providers file configuration was. > > So I guess the question is, > Isn''t the route entry "10.0.11.1 dev eth1 scope link src 10.0.11.2 > redundant > and covered all-ready by "10.0.11.0/24 dev eth1 proto kernel scope > link src 10.0.11.2" ???? > > If I remove these routes from the tables all seem to work with no > problem at all and very smoothly!Those routes are there because the firewall won''t start on some distributions without them. Apply the attached patch and add the ''nohostroute'' option to your providers. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk