My telco is moving to feeding me over fiber, breaking out with a media converter to one Ethernet interface. At present, I am retaining the static feed over copper on eth0, and taking the two new feeds via vlans on eth1. I have configured the static IP feed on eth1:790 as vlan 790, and that seems to be fine, and eth1:780 as the PPPOE feed, and brought up PPPOE to give me an IP, that is configured as interface ppp0. The ppp0 feed works fine. I have trouble understanding how to refer to eth1:790 in the configuration files. Should I just call it eth1 or can I refer to it as eth1:790? Chris Mason -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--On February 18, 2008 5:56:21 PM -0400 "Chris Mason (Lists)" <lists@masonc.com> wrote:> My telco is moving to feeding me over fiber, breaking out with a media > converter to one Ethernet interface. At present, I am retaining the > static feed over copper on eth0, and taking the two new feeds via vlans > on eth1. I have configured the static IP feed on eth1:790 as vlan 790, > and that seems to be fine, and eth1:780 as the PPPOE feed, and brought > up PPPOE to give me an IP, that is configured as interface ppp0. > The ppp0 feed works fine. I have trouble understanding how to refer to > eth1:790 in the configuration files. Should I just call it eth1 or can I > refer to it as eth1:790?That looks like an alias, not a vlan. Vlan interfaces are provided by the 8021q driver for 802.1q encapsulated vlan''s and begin with vlan (unless you rename them), they''re also full devices in their own right. But this requires 802.1q capable switches and that you''re actually getting traffic handed off with 802.1q encapsulation. Since it''s working at all, this probably isn''t the case. In any event, what you need to do depends on context. eth1, refers to the ip address on that device, or to all aliases on that device, depending on context. (In the interface context, it means all, in the address context it would mean the IP that is on eth1). In the case of defining an interface for which traffic will traverse, you can''t identify an alias there, as it''s not an interface. I think in most cases inside of shorewall you''ll be referring to the interface, as it''s asking about an interface, not an alias. Aliases aren''t really devices in and of themselves. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Chris Mason (Lists) wrote:> My telco is moving to feeding me over fiber, breaking out with a media > converter to one Ethernet interface. At present, I am retaining the > static feed over copper on eth0, and taking the two new feeds via vlans > on eth1. I have configured the static IP feed on eth1:790 as vlan 790, > and that seems to be fine, and eth1:780 as the PPPOE feed, and brought > up PPPOE to give me an IP, that is configured as interface ppp0. > The ppp0 feed works fine. I have trouble understanding how to refer to > eth1:790 in the configuration files. Should I just call it eth1 or can I > refer to it as eth1:790?Neither. VLAN interfaces are typically given names like eth1.780 and eth1.790. Neither Shorewall nor iptables nor ip can deal with names that look like ifconfig aliases as yours do. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
The traffic come to me with 802.1q encapsulation, two vlans on one interface. 780 is the pppoe adsl feed, 790 is the static IP. I was able to bring the 790 feed up first, and it works as an interface if I ping it and ping the gateway for that network, but I never got it to work in Shorewall. With the 790 and 780 up, eth1 has more than one IP so I don''t know how to refer to eth1:790 in shorewall. I could insert a vlan capable switch upstream and separate the networks to different interfaces, but that would be too easy, and us linux types don''t do it the easy way. Chris Mason -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Chris Mason (Lists) wrote:> The traffic come to me with 802.1q encapsulation, two vlans on one > interface. 780 is the pppoe adsl feed, 790 is the static IP. I was able > to bring the 790 feed up first, and it works as an interface if I ping > it and ping the gateway for that network, but I never got it to work in > Shorewall. > > With the 790 and 780 up, eth1 has more than one IP so I don''t know how > to refer to eth1:790 in shorewall. > > I could insert a vlan capable switch upstream and separate the networks > to different interfaces, but that would be too easy, and us linux types > don''t do it the easy way.All of the Linux VLAN howtos I''ve read result in a different interface for each VLAN (even though they all share a single physical interface). Here''s sample output from ''ip addr ls'': 4: vlan179@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue link/ether 00:1a:64:8b:fd:00 brd ff:ff:ff:ff:ff:ff inet 200.13.169.2/29 brd 200.13.169.7 scope global vlan179 inet6 fe80::21a:64ff:fe8b:fd00/64 scope link valid_lft forever preferred_lft forever 5: vlan152@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue link/ether 00:1a:64:8b:fd:00 brd ff:ff:ff:ff:ff:ff inet 10.215.0.5/24 brd 10.215.0.255 scope global vlan152 inet6 fe80::21a:64ff:fe8b:fd00/64 scope link valid_lft forever preferred_lft forever Those two vlans would be referred to in Shorewall as vlan179 and vlan152 respectively. Another common naming convention would be eth0.179 and eth0.152. So I have not seen another case of what you are apparently doing. But if it ends up with multiple IP addresses on a single interface using the archaic ''aliased interface'' naming convention then you need to read http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> > > Those two vlans would be referred to in Shorewall as vlan179 and vlan152 > respectively. Another common naming convention would be eth0.179 and > eth0.152. > > So I have not seen another case of what you are apparently doing.Small typo in my last email. My vlans follow the naming convention you detail above. Given that, how do I refer to them in Shorewall? 12: eth1.790: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue link/ether 00:03:47:95:9d:66 brd ff:ff:ff:ff:ff:ff inet 207.42.133.74/30 brd 207.42.133.75 scope global eth1.790 inet6 fe80::203:47ff:fe95:9d66/64 scope link valid_lft forever preferred_lft forever 14: eth1.780: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue link/ether 00:03:47:95:9d:66 brd ff:ff:ff:ff:ff:ff inet6 fe80::203:47ff:fe95:9d66/64 scope link valid_lft forever preferred_lft forever 15: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3 link/ppp inet 209.59.77.67 peer 69.57.237.1/32 scope global ppp0 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Feb 19, 2008 at 06:10:13AM -0400, Chris Mason (Lists) wrote:> My vlans follow the naming convention you > detail above. Given that, how do I refer to them in Shorewall?With those names... ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Feb 19, 2008 at 06:10:13AM -0400, Chris Mason wrote:>> My vlans follow the naming convention you >> detail above. Given that, how do I refer to them in Shorewall? >>Just with the name "vlan780" , "vlan790" like "eth0", "eth1". In linux (and other Unix OS) a vlan device is handled like a "real" network device. Only in a few cases you see the connection to the physical interface behind (like in the output of "ip addr show"). vlan technique must not confused with ip aliases. Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Chris Mason (Lists) wrote:> Tom Eastep wrote: >> >> Those two vlans would be referred to in Shorewall as vlan179 and vlan152 >> respectively. Another common naming convention would be eth0.179 and >> eth0.152. >> >> So I have not seen another case of what you are apparently doing. > Small typo in my last email. My vlans follow the naming convention you > detail above. Given that, how do I refer to them in Shorewall? > > 12: eth1.790: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue > link/ether 00:03:47:95:9d:66 brd ff:ff:ff:ff:ff:ff > inet 207.42.133.74/30 brd 207.42.133.75 scope global eth1.790 > inet6 fe80::203:47ff:fe95:9d66/64 scope link > valid_lft forever preferred_lft forever > 14: eth1.780: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue > link/ether 00:03:47:95:9d:66 brd ff:ff:ff:ff:ff:ff > inet6 fe80::203:47ff:fe95:9d66/64 scope link > valid_lft forever preferred_lft forever > 15: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3 > link/ppp > inet 209.59.77.67 peer 69.57.237.1/32 scope global ppp0 >In that configuration, you would define eth1.790 and ppp0 to Shorewall (using those names). As always, unbridged interfaces without an IPv4 address, like eth1.780, are not defined to Shorewall. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> > In that configuration, you would define eth1.790 and ppp0 to Shorewall > (using those names). As always, unbridged interfaces without an IPv4 > address, like eth1.780, are not defined to Shorewall.And it works perfectly. Thanks to everyone for your help. The ISP''s tech wanted to find a Cisco switch to separate the Vlans to two interfaces. I told him it was trivial to implement 802.1q vlans, ppoe using linux and shorewall. Other than getting confused between aliases and vlan naming, it was pretty simple. I am still working on the tcrules stuff, some of the services are not routing properly, but that''s normal messing around. Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/