Re: [Vyatta-users] DMZ Question
A similar question was asked on the forum recently: http://www.vyatta.org/forum/viewtopic.php?t=110 -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Azrin Aris Sent: Wednesday, March 26, 2008 6:06 PM To: [EMAIL PROTECTED] Subject: [Vyatta-users] DMZ Question Hi, I'm using VC2 and I want to create a web server behind my Vyatta router. I tried to follow the Quick evaluation document on how to do the DMZ configuration but my problem is the WAN IP is dynamic. So how do I configure Vyatta if I have a dynamic WAN IP. Thanks in advance Azrin ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Request for link redundancy suggestions
Daniel, If you're able to use the glendale alpha (i.e. VC4.0.0) it does have support for adding an IP address on the bridge interface and it also supports ECMP which might be an option for your dual links. I wrote a quick howto for ECMP on the new forum at: http://www.vyatta.org/forum/viewtopic.php?t=20 stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Daniel Stickney Sent: Wednesday, March 05, 2008 11:42 AM To: [EMAIL PROTECTED] Subject: [Vyatta-users] Request for link redundancy suggestions Hi Everyone, I have exhausted my ideas and am now looking for suggestions on how to achieve my goal of having redundant links from two clustered Vyatta boxes. I'll lay out the technical details and goal first. We have two edge layer 3 switches which are stacked (with stacking modules and cable, so they are a single logical switch with a single administration interface. For those not familiar with stacking, they act like separate 48 port blades in a switch chassis) and two Vyatta boxes with clustering configured. The cluster resources are one public VIP, and one private VIP. I am excluding the rest of the network architecture to focus in on the links between the two Vyatta boxes and the edge (logical) switch. Our network design requirements document stated we wanted to have no single point of failure in our network backbone. To meet this goal, we have 2 ISP drops with 2 cables per drop (spanning-tree used to select designated cable on each drop) to our edge switch stack; one cable from each drop is connected to each switch (think connected to each blade) so if an edge switch in the stack dies (or if a blade in the chassis dies) traffic can still run through the surviving edge switch (blade). As mentioned, we also have two Vyatta boxes clustered. The only part of this that I can't figure out how to make redundant is the gigabit network cable between each Vyatta box and the edge switch stack (named link1-1, link1-2, and link2-1, link2- 2 below). I am hoping to hear some suggestions on how this might be achieved within our architecture. So far I have considered port-channeling and spanning-tree, but neither of these appear to be a solution in this case. Here is an ASCII drawing of this description: ISP-drop1-1|-| ISP-drop1-2|edge-sw-1|link2-1 | |link2-2 | |-| | | -link1-1--| |ISP-drop2-1 | | |-link1-2-|edge-sw-2|ISP-drop2-2 | | || |-| | | || | | || -- | || | || | | || | | |--| |--| | vyatta-1 | | vyatta-2 | |--| |--| I realize the link1 and link2 can be done with one cable from each Vyatta box to the edge switch stack, but we are trying to eliminate each cable as a single point of failure by providing a backup cable from each Vyatta box to the edge. We have no interest in applying a 'duct-tape and bubble gum' hacked together solution on our network backbone, so I am hoping there is a standardized method to achieve our goal. I am concerned that I am misunderstanding something or missing an option which has left me at my dead end. Here is how I have gotten to this logical dead end. Vyatta (VC3) does not support Linux bonded NICs (devices named bondX) in the command shell or web interface, so port-channeling is not an option. Vyatta (VC3) does support bridge groups, but not officially assigning them IPs within Xorpsh or the web interface (yes I know the Linux shell method, but we are avoiding any unofficial hacks). With 2 bridged interfaces, running spanning-tree with the switch ports to have only one active cable would meet our goal, but we need the clustering to move a VIP resource back and forth between the bridge group interfaces on the two Vyatta boxes, and as far as I can tell from reading the manuals and forums and guides, this is not supported. Am I understanding things correctly? I am ok with the answer being there is no way to do what you want at this time, I just don't want to miss an officially supported method if it exists. If we just have to use a single cable from each Vyatta box to the edge stack, it is not optimal but it is acceptable. Thanks very much for suggestions. -Daniel -- Daniel Stickney - Linux Systems Administrator Email: [EMAIL PROTECTED] ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com
Re: [Vyatta-users] Glendale Alpha 1 ERROR!!!
I'm pretty sure the vyatta cli in alpha 2 has telnet mapped, but even in alpha 1 you can still get to telnet via linux (by using full path) even if the vyatta cli hasn't been mapped for it. Try: /bin/busybox telnet 192.1.1.1 stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Johnson Sent: Thursday, February 28, 2008 8:22 AM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] Glendale Alpha 1 ERROR!!! In the course of my normal, hack first, read documentation later, mode of operation, I managed to hang the netopia DSL router. Having done this before I know that the outside access is still good, just the inside network interface is scrod. So I reconfigured vyatta (A1) to route traffic to the Netopia via the outside link set protocols static route 192.1.1.1/32 next-hope 12.1.1.1 Where 192.1.1.1 is the inside IP of the DSL router (fully routable class C address) and 12.1.1.1 is the next hop out the cable modem. Everything seems to work fine. Traceroute works correctly. I'm happy. Then I try the required magic telnet 192.1.1.1. Command not found. What do you mean command not found!!! What operating system does not include telnet? Either the name changed or a tool is missing. Please make sure that telnet is included in future releases. (The hack I had to put into place required me to set up a NAT rule so that I could telnet from one of the inside machines) Best, -Chris (tongue in cheek) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale Alpha 1 ERROR!!!
Hi Chris, You're right it is a bug, but one that has been opened/fixed: https://bugzilla.vyatta.com/show_bug.cgi?id=2478 :-) BTW, I think the ssh client still hasn't been mapped to the cli, but probably is in the default admin path. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Johnson Sent: Thursday, February 28, 2008 9:13 AM To: [EMAIL PROTECTED] Subject: Re: [Vyatta-users] Glendale Alpha 1 ERROR!!! You are absolutely correct. Therefore the bug is: telnet is not properly mapped. *GRIN* Thanks for your help Stig. Best, -Chris On Thu, Feb 28, 2008 at 11:30 AM, Stig Thormodsrud [EMAIL PROTECTED] wrote: I'm pretty sure the vyatta cli in alpha 2 has telnet mapped, but even in alpha 1 you can still get to telnet via linux (by using full path) even if the vyatta cli hasn't been mapped for it. Try: /bin/busybox telnet 192.1.1.1 stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Johnson Sent: Thursday, February 28, 2008 8:22 AM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] Glendale Alpha 1 ERROR!!! In the course of my normal, hack first, read documentation later, mode of operation, I managed to hang the netopia DSL router. Having done this before I know that the outside access is still good, just the inside network interface is scrod. So I reconfigured vyatta (A1) to route traffic to the Netopia via the outside link set protocols static route 192.1.1.1/32 next-hope 12.1.1.1 Where 192.1.1.1 is the inside IP of the DSL router (fully routable class C address) and 12.1.1.1 is the next hop out the cable modem. Everything seems to work fine. Traceroute works correctly. I'm happy. Then I try the required magic telnet 192.1.1.1. Command not found. What do you mean command not found!!! What operating system does not include telnet? Either the name changed or a tool is missing. Please make sure that telnet is included in future releases. (The hack I had to put into place required me to set up a NAT rule so that I could telnet from one of the inside machines) Best, -Chris (tongue in cheek) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Problems with Glendale Alpha 2
What error did you get with install-system? We have seen some issues with vmware's scsi hard drive not being recognized, so if that's the issue then you might try editing the virtual machine to use an IDE hard drive instead. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paco Alcantara Sent: Wednesday, February 27, 2008 4:15 PM To: [EMAIL PROTECTED] Subject: [Vyatta-users] Problems with Glendale Alpha 2 Some problems when trying Alpha 2 1.- Error when trying install-system to install Alpha2 in a hard disk (I am using VMWare environment). 2.- I am looking for PPPoE commands are I cannot find them. Any help?? Regards. Paco. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] newbie query - issue in site-to-site VPN
Have you tried adding a proposal 1 with aes256 under esp-group ESP-1E for
site 2 so that the proposals match up?
stig
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Biswajit
Banerjee
Sent: Wednesday, February 27, 2008 7:08 PM
To: vyatta-users
Subject: [Vyatta-users] newbie query - issue in site-to-site VPN
Hi All ,
i am newbie to vyatta iPSEC VPN has setup an site - to -site VPN as per
config document of vyatta between 2 vyatta routers . Not able to establish
the VPN and /var/log/messages says
site 1
Feb 28 02:39:44 localhost pluto[3973]: peer-Y.Y.Y.Y-tunnel-1 #691:
initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP to replace #690 {using
isakmp#687}
Feb 28 02:39:44 localhost pluto[3973]: peer-Y.Y.Y.Y-tunnel-1 #687:
ignoring informational payload, type NO_PROPOSAL_CHOSEN
Feb 28 02:39:44 localhost pluto[3973]: peer-Y.Y.Y.Y-tunnel-1 #687:
received and ignored informational message
Feb 28 02:39:54 localhost pluto[3973]: peer-Y.Y.Y.Y-tunnel-1 #687:
ignoring informational payload, type INVALID_MESSAGE_ID
Feb 28 02:39:54 localhost pluto[3973]: peer-Y.Y.Y.Y-tunnel-1 #687:
received and ignored informational message
Feb 28 02:40:14 localhost pluto[3973]: peer-Y.Y.Y.Y-tunnel-1 #687:
ignoring informational payload, type INVALID_MESSAGE_ID
Feb 28 02:40:14 localhost pluto[3973]: peer-Y.Y.Y.Y-tunnel-1 #687:
received and ignored informational message
Site 2
IPsec Transform [ESP_AES (256), AUTH_ALGORITHM_HMAC_SHA1] refused due to
strict flag
Feb 28 02:31:33 localhost pluto[3983]: peer-X.X.X.X-tunnel-1 #751: no
acceptable Proposal in IPsec SA
Feb 28 02:31:33 localhost pluto[3983]: peer-X.X.X.X-tunnel-1 #751:
sending encrypted notification NO_PROPOSAL_CHOSEN to 202.91.74.130:500
Feb 28 02:31:40 localhost pluto[3983]: peer-X.X.X.X-tunnel-1 #746: Quick
Mode I1 message is unacceptable because it uses a previously used Message
ID 0x211f93c1 (perhaps this is a duplicated packet)
Feb 28 02:31:40 localhost pluto[3983]: peer-X.X.X.X-tunnel-1 #746:
sending encrypted notification INVALID_MESSAGE_ID to Y.Y.Y.Y:500
Site 1 config
vpn {
ipsec {
ipsec-interfaces {
interface eth0
}
ike-group IKE-1W {
proposal 1 {
encryption: aes256
}
proposal 2 {
}
lifetime: 3600
}
esp-group ESP-1W {
proposal 1 {
encryption: aes256
}
proposal 2 {
encryption: 3des
hash: md5
}
lifetime: 1800
}
site-to-site {
peer X.X.X.X {
authentication {
mode: rsa
pre-shared-secret: test_key_1
rsa-key-name: CO-key
}
ike-group: IKE-1W
local-ip: Y.Y.Y.Y
tunnel 1 {
local-subnet: 192.168.1.0/24
remote-subnet: 192.168.0.0/24
esp-group: ESP-1W
}
}
}
}
rsa-keys {
rsa-key-name CO-key {
rsa-key:
0sAQOBguI8jQvYGCKf3KFP3sQHTTwP3AVokIXnoEyaNOEgqxPtITCEV4SJYkBk7//ZnBovZJJ
8s0/qDGOPkjK4rAjTNEXCoGZBoHR3W6Sus40RU+33Cc/qwBzl5xHgU2iDdlESMWV8PVa1keVqU
19KELpc3zLS0GdFaJKoJIeDSyyWoicAp9AQ8GG2OaaYDI+GvLKpf5V1DK6Rqfz5dLab+UIXcqL
sqQ2a+VrL9Bbul/p8Z5vc7RgqS8GRjwzoPqUr+5HDw2HUxTXAhUek3HBu96lJ+H1LO63d28OV+
B2cc0kWMuiEke1MGJtcWbyYtr6vKCQbGjOJjZqB+sq8ma9Zg8kAOIrPLIpQsXe/TjS4Cp0xbMg
X
}
}
}
Site 2 config is
vpn {
ipsec {
ipsec-interfaces {
interface eth0
}
ike-group IKE-1E {
proposal 1 {
encryption: aes256
}
}
esp-group ESP-1E {
proposal 2 {
encryption: 3des
hash: md5
}
lifetime: 1800
}
site-to-site {
peer 202.91.74.130 {
authentication {
mode: rsa
pre-shared-secret: test_key_1
rsa-key-name: NLD-key
}
ike-group: IKE-1E
local-ip: 202.91.67.162
tunnel 1 {
local-subnet: 192.168.0.0/24
remote-subnet: 192.168.1.0/24
esp-group: ESP-1E
}
}
}
}
rsa-keys {
rsa-key-name NLD-key {
rsa-key:
0sAQOOVx2lEQNsCqFU9M4bhovvC28mf7e1sYNaBC1FAaG5qyO2PnGic+anlVJYvjvHBj3wBYV
+L6pMRsTv28Qn9wFGCXUR/aSM4+RdnHSTBy8sgWKpw9vCVMJ/J60x6/B7uc6a0e8+2jJ8PnfFD
Re: [Vyatta-users] vrrp issues on VC3
I'm not sure if the version you're using has the disable-vmac option, but
if not try searching the archives for how to disable it.
stig
Ken,
You might have seen the vrrp priority of 150 for eth2 on R2 which was
just a test and replaced with 20 since a few days, but the problem still
exists.
Anyone else? ;-)
Cheers
Tobias
Ken Rozinsky schrieb:
Hello,
I'm in no way an expert but it looks to me like the priority on both
your eth2 interfaces are set at 150.
setting the second to 20 might fix it for you.
Regards,
Ken
Tobias Orlamuende wrote:
Yes, all interfaces are GBit, but connected to a 100 MBit/s switch.
Interfaces are Intel 82571EB and 82573E/82573L
/var/log/messages prints only errors like these ones:
Feb 25 13:34:24 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: printk: 7 messages suppressed.
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.54 from
78.138.64.71, on dev eth0
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.54 from
78.138.64.71, on dev eth2
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.74 from
78.138.64.71, on dev eth0
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.74 from
78.138.64.71, on dev eth2
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Cheers
Tobias
Dave Strydom schrieb:
are all the interfaces 1000Mbit interfaces?
and
if you login to the routers as root, what do you have in
/var/log/messages ?
- Dave
On Mon, Feb 25, 2008 at 12:54 PM, Tobias Orlamuende
[EMAIL PROTECTED] wrote:
Hi all,
I set up 2 routers with VC3 and want them to do vrrp. Setup of
vrrp
was
done exactly as described in the documentation.
Unfortunately vrrp doesn't seem to work properly. On both routers
vrrp
seems to act as a master. When connecting to one of the physical
addresses of one of the routers, I get packetloss of about 50%.
The
other router is fine as well as their virtual IP.
My setup looks as follows:
Upstream via a small transfer-net 83.220.149.16/29 (eth0)
The following networks are received through this transfer-net:
194.8.86.0/24 (eth2)
78.138.64.0/25 (eth1)
Default-route points to our upstream-provider's router
(83.220.149.17)
Router1:
[EMAIL PROTECTED] show interfaces
loopback lo {
}
ethernet eth0 {
description: upstream
hw-id: 00:15:17:39:b6:8a
address 83.220.149.19 {
prefix-length: 29
broadcast: 83.220.149.23
}
vrrp {
vrrp-group: 3
virtual-address: 83.220.149.18
authentication: 123456
priority: 150
}
}
ethernet eth1 {
description: old-PA
hw-id: 00:15:17:39:b6:8b
address 78.138.64.71 {
prefix-length: 25
broadcast: 78.138.64.127
}
vrrp {
vrrp-group: 4
virtual-address: 78.138.64.1
priority: 150
}
}
ethernet eth2 {
description: old-local
hw-id: 00:30:48:91:96:06
address 194.8.86.1 {
prefix-length: 24
broadcast: 194.8.86.255
}
vrrp {
vrrp-group: 2
virtual-address: 194.8.86.254
priority: 150
}
}
ethernet eth3 {
hw-id: 00:30:48:91:96:07
}
[edit]
[EMAIL PROTECTED] show vrrp
Physical interface: eth0, Address: 83.220.149.19
Interface state: up, Group: 3, State: master
Priority: 150, Advertisement interval: 1s, Authentication type:
simple
Preempt: yes, VIP count: 1, VIP: 83.220.149.18
Advertisement timer: 3310s, Master router: 83.220.149.19
Virtual MAC: 00:00:5E:00:01:03
Physical interface: eth1, Address: 78.138.64.71
Interface state: up, Group: 4, State: master
Priority: 150, Advertisement interval: 1s, Authentication type:
none
Preempt: yes, VIP count: 1, VIP: 78.138.64.1
Advertisement timer: 3310s, Master router: 78.138.64.71
Virtual MAC: 00:00:5E:00:01:04
Physical interface: eth2, Address: 194.8.86.1
Interface state: up, Group: 2, State: master
Priority: 150, Advertisement interval: 1s, Authentication type:
none
Preempt: yes, VIP count: 1, VIP: 194.8.86.254
Advertisement timer: 3310s, Master router: 194.8.86.1
Virtual MAC: 00:00:5E:00:01:02
Router2:
[EMAIL PROTECTED] show interfaces
loopback lo {
}
Re: [Vyatta-users] vrrp issues on VC3
This thread mentions the file to edit to disable vmac.
http://www.mail-archive.com/vyatta-users@mailman.vyatta.com/msg00957.html
stig
-Original Message-
From: [EMAIL PROTECTED] [mailto:vyatta-users-
[EMAIL PROTECTED] On Behalf Of Tobias Orlamuende
Sent: Monday, February 25, 2008 9:44 AM
To: [EMAIL PROTECTED]
Subject: Re: [Vyatta-users] vrrp issues on VC3
Thanks for the answer. I|d love to trz but in VC3 there is no
possibility. Seems we have to buy a subscription...
Could somebody from Vyatta please confirm this (vrrp) issue?
Cheers
Tobias
Justin Fletcher schrieb:
Some systems have issues with the virtual MAC addresses - try the
option to disable it.
Best,
Justin
On Mon, Feb 25, 2008 at 8:35 AM, Tobias Orlamuende
[EMAIL PROTECTED] wrote:
Ken,
You might have seen the vrrp priority of 150 for eth2 on R2 which
was
just a test and replaced with 20 since a few days, but the problem
still
exists.
Anyone else? ;-)
Cheers
Tobias
Ken Rozinsky schrieb:
Hello,
I'm in no way an expert but it looks to me like the priority on
both
your eth2 interfaces are set at 150.
setting the second to 20 might fix it for you.
Regards,
Ken
Tobias Orlamuende wrote:
Yes, all interfaces are GBit, but connected to a 100 MBit/s
switch.
Interfaces are Intel 82571EB and 82573E/82573L
/var/log/messages prints only errors like these ones:
Feb 25 13:34:24 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: printk: 7 messages suppressed.
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.54
from
78.138.64.71, on dev eth0
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.54
from
78.138.64.71, on dev eth2
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.74
from
78.138.64.71, on dev eth0
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.74
from
78.138.64.71, on dev eth2
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Cheers
Tobias
Dave Strydom schrieb:
are all the interfaces 1000Mbit interfaces?
and
if you login to the routers as root, what do you have in
/var/log/messages ?
- Dave
On Mon, Feb 25, 2008 at 12:54 PM, Tobias Orlamuende
[EMAIL PROTECTED] wrote:
Hi all,
I set up 2 routers with VC3 and want them to do vrrp. Setup of
vrrp was
done exactly as described in the documentation.
Unfortunately vrrp doesn't seem to work properly. On both
routers vrrp
seems to act as a master. When connecting to one of the
physical
addresses of one of the routers, I get packetloss of about
50%.
The
other router is fine as well as their virtual IP.
My setup looks as follows:
Upstream via a small transfer-net 83.220.149.16/29 (eth0)
The following networks are received through this transfer-net:
194.8.86.0/24 (eth2)
78.138.64.0/25 (eth1)
Default-route points to our upstream-provider's router
(83.220.149.17)
Router1:
[EMAIL PROTECTED] show interfaces
loopback lo {
}
ethernet eth0 {
description: upstream
hw-id: 00:15:17:39:b6:8a
address 83.220.149.19 {
prefix-length: 29
broadcast: 83.220.149.23
}
vrrp {
vrrp-group: 3
virtual-address: 83.220.149.18
authentication: 123456
priority: 150
}
}
ethernet eth1 {
description: old-PA
hw-id: 00:15:17:39:b6:8b
address 78.138.64.71 {
prefix-length: 25
broadcast: 78.138.64.127
}
vrrp {
vrrp-group: 4
virtual-address: 78.138.64.1
priority: 150
}
}
ethernet eth2 {
description: old-local
hw-id: 00:30:48:91:96:06
address 194.8.86.1 {
prefix-length: 24
broadcast: 194.8.86.255
}
vrrp {
vrrp-group: 2
virtual-address: 194.8.86.254
priority: 150
}
}
ethernet eth3 {
hw-id: 00:30:48:91:96:07
}
[edit]
[EMAIL PROTECTED] show vrrp
Physical interface: eth0, Address: 83.220.149.19
Interface state: up, Group: 3, State: master
Priority: 150, Advertisement
Re: [Vyatta-users] vrrp issues on VC3
Tobias,
The thread mentioned below will tell you how to hack the functionality
into VC3. If you prefer not to hack you might consider trying out the
Glendale alpha since it doesn't use the vmac in it's vrrp implementation.
It also supports multiple VIPs/group and multiple groups/interface and
user feedback so far has been that the switchover times are faster.
For Glendale see:
http://mailman.vyatta.com/pipermail/vyatta-users/2008-January/002966.html
stig
This thread mentions the file to edit to disable vmac.
http://www.mail-archive.com/vyatta-users@mailman.vyatta.com/msg00957.html
stig
-Original Message-
From: [EMAIL PROTECTED] [mailto:vyatta-users-
[EMAIL PROTECTED] On Behalf Of Tobias Orlamuende
Sent: Monday, February 25, 2008 9:44 AM
To: [EMAIL PROTECTED]
Subject: Re: [Vyatta-users] vrrp issues on VC3
Thanks for the answer. I|d love to trz but in VC3 there is no
possibility. Seems we have to buy a subscription...
Could somebody from Vyatta please confirm this (vrrp) issue?
Cheers
Tobias
Justin Fletcher schrieb:
Some systems have issues with the virtual MAC addresses - try the
option to disable it.
Best,
Justin
On Mon, Feb 25, 2008 at 8:35 AM, Tobias Orlamuende
[EMAIL PROTECTED] wrote:
Ken,
You might have seen the vrrp priority of 150 for eth2 on R2 which
was
just a test and replaced with 20 since a few days, but the problem
still
exists.
Anyone else? ;-)
Cheers
Tobias
Ken Rozinsky schrieb:
Hello,
I'm in no way an expert but it looks to me like the priority on
both
your eth2 interfaces are set at 150.
setting the second to 20 might fix it for you.
Regards,
Ken
Tobias Orlamuende wrote:
Yes, all interfaces are GBit, but connected to a 100 MBit/s
switch.
Interfaces are Intel 82571EB and 82573E/82573L
/var/log/messages prints only errors like these ones:
Feb 25 13:34:24 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: printk: 7 messages
suppressed.
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.54
from
78.138.64.71, on dev eth0
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.54
from
78.138.64.71, on dev eth2
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.74
from
78.138.64.71, on dev eth0
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Feb 25 13:35:25 localhost kernel: martian source 78.138.64.74
from
78.138.64.71, on dev eth2
Feb 25 13:35:25 localhost kernel: ll header:
ff:ff:ff:ff:ff:ff:00:00:5e:00:01:04:08:06
Cheers
Tobias
Dave Strydom schrieb:
are all the interfaces 1000Mbit interfaces?
and
if you login to the routers as root, what do you have in
/var/log/messages ?
- Dave
On Mon, Feb 25, 2008 at 12:54 PM, Tobias Orlamuende
[EMAIL PROTECTED] wrote:
Hi all,
I set up 2 routers with VC3 and want them to do vrrp. Setup
of
vrrp was
done exactly as described in the documentation.
Unfortunately vrrp doesn't seem to work properly. On both
routers vrrp
seems to act as a master. When connecting to one of the
physical
addresses of one of the routers, I get packetloss of about
50%.
The
other router is fine as well as their virtual IP.
My setup looks as follows:
Upstream via a small transfer-net 83.220.149.16/29 (eth0)
The following networks are received through this
transfer-net:
194.8.86.0/24 (eth2)
78.138.64.0/25 (eth1)
Default-route points to our upstream-provider's router
(83.220.149.17)
Router1:
[EMAIL PROTECTED] show interfaces
loopback lo {
}
ethernet eth0 {
description: upstream
hw-id: 00:15:17:39:b6:8a
address 83.220.149.19 {
prefix-length: 29
broadcast: 83.220.149.23
}
vrrp {
vrrp-group: 3
virtual-address: 83.220.149.18
authentication: 123456
priority: 150
}
}
ethernet eth1 {
description: old-PA
hw-id: 00:15:17:39:b6:8b
address 78.138.64.71 {
prefix-length: 25
broadcast: 78.138.64.127
}
vrrp {
vrrp-group: 4
virtual-address: 78.138.64.1
priority: 150
}
}
ethernet eth2 {
Re: [Vyatta-users] Glendale First Impressions
- show ospf4 database self-originate is one of the best commands to troubleshoot ospf with, can we please work towards adding it? Nick, I just now get around to seeing if quagga supports a similar command and I found: vDUT:~# show ip ospf database self-originate OSPF Router with ID (1.1.1.1) Router Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Link count 1.1.1.1 1.1.1.1 46 0x8003 0x569e 1 AS External Link States Link ID ADV Router Age Seq# CkSum Route 1.1.1.1 1.1.1.1 66 0x8001 0x5f57 E2 1.1.1.1/32 [0x0] 10.0.0.01.1.1.1 66 0x8001 0x0ba5 E2 10.0.0.0/24 [0x0] 15.0.0.01.1.1.1 66 0x8001 0xc9e1 E2 15.0.0.0/24 [0x0] 50.0.0.01.1.1.1 66 0x8001 0xfb8d E2 50.0.0.0/23 [0x0] Hopefully that is the same functionality you were looking for. stig ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale First Impressions
Hi Nick, Thanks for the feedback. Comments inline. Hi Guys, Lots of big changes in Glendale and I'm enjoying them. I did my usual drop test, dropping the Glendale test router into production. I even spiced up my config a bit, adding authentication where possible. So far so good guys. The new version looks exciting, and I can't wait to see the new features that are coming out in the next builds. I have noticed a couple things though. Some of this is probably me still wrapping my mind around this new CLI. It took me a while to find out how to set the OSPF RID, and get redistribution working, so I wouldn't put it past me just not grasping this new CLI yet. So here's my list: - top doesn't take you to the top of the command line hierarchy, it runs the shell top program. For example if you edit interfaces ethernet eth3, make changes and then type top it runs the top program. That's http://bugzilla.vyatta.com/show_bug.cgi?id=2616 and is fixed. -Right now it appears you can't edit service dhcp-server. The command line hierarchy was one of the best features of this CLI, it should be added to everything. I know it's a new command line and I hope this is something you guys are working on. I think that's been fixed, but I'll let someone else confirm. - I think I saw this about the previous release, however it appears to be the same in Glendale. Even if an interface description is set in the command line SNMP returns the following values for interface description: Found item [ifDescr='eth0'] index: 2 [from value]. Interface descriptions are a big deal in the service provider arena; it should be very easy to indentify interfaces by description. Descriptions should show up in the output of show interface system. I'll look into the snmp issue, but at lease we now do show the description in the various show interface commands (although it didn't make the cut for alpha1). We now also default to a brief style output if the command could show multiple interfaces. For example: [EMAIL PROTECTED]:~$ show interfaces InterfaceIP Address State Link Description br0 - up up bridge eth0 and eth1 eth0 172.16.117.15/24 up up Link to Internet eth0 6.9.9.9/32 up up Link to Internet eth0.100 - up up Switch to vlan 100 eth0.200 - up up Switch to vlan 200 eth1 15.0.0.15/24 up up eth2 2.2.2.3/24 admin down down Testing eth2 172.16.139.15/24 admin down down Testing eth3 - up up lo 127.0.0.1/8up up tun0 10.0.0.1/24up up GRE tunnel over IPSEC [EMAIL PROTECTED]:~$ show interfaces ethernet eth0 eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:1a:08:62 brd ff:ff:ff:ff:ff:ff inet 172.16.117.15/24 brd 172.16.117.255 scope global eth0 inet 6.9.9.9/32 scope global eth0 inet6 fe80::20c:29ff:fe1a:862/64 scope link valid_lft forever preferred_lft forever Last clear: Thu Feb 14 11:45:22 PST 2008 Description: Link to Internet RX: bytespackets errorsdroppedoverrun mcast 775 11 0 0 0 0 TX: bytespackets errorsdroppedcarrier collisions 1972 19 0 0 0 0 Any thoughts on that as a default? In the detailed output you can see the description and you might notice the Last clear which means we've added a clear counters command. - You don't seem to be able to use run to execute some commands from inside config mode. Just like do in Cisco IOS, run in this CLI is an essential tool that simplifies troubleshooting new configs We do support run in config mode: [EMAIL PROTECTED] run show version Version :glendale (alpha 1) Built by:[EMAIL PROTECTED] Built on:Thu Feb 14 06:03:10 UTC 2008 Build ID:08021406038278164 Boot via:livecd Uptime :11:48:18 up 13:23, 1 user, load average: 0.00, 0.00, 0.00 Not sure why ping doesn't work with that (I'll file a bug), but you can use the linux ping from config mode: [EMAIL PROTECTED] ping 172.16.117.1 PING 172.16.117.1 (172.16.117.1) 56(84) bytes of data. 64 bytes from 172.16.117.1: icmp_seq=1 ttl=64 time=0.666 ms - There doesn't seem to be a way to run OSPF of VIFs. Please tell me I'm crazy and this is not the case. That's my fault as I forgot to also add it under the vif. I fixed it yesterday, so it'll be in the next release. [EMAIL PROTECTED] set interfaces ethernet eth3 vif 5 address description firewall bridge-group disable vrrp [edit] [EMAIL PROTECTED] set interfaces ethernet eth3 vif 5 - I don't mind the new CLI, however I REALLY miss the ? and the space auto completion. If there is
Re: [Vyatta-users] Glendale source
In Glendale the vyatta shell is integrated with the regular bash shell, so when you login just type configure and start adding the configuration. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of piyush sharma Sent: Sunday, February 10, 2008 8:43 PM To: vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] Glendale source Hi, How can I go to the shell prompt for Vyatta? Thanks, Piyush ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] backup route question
Hi Dave, I think it was Ken Felix that mentioned using different metrics to get similar functionalty to xorp's qualified-next-hop feature. I'll verify that when I get in the office tomorrow. stig Hi Stig, What i was looking for was next-hop qualified-next-hop. next-hop being the 10.10.1.2 and qualified-next-hop being 10.10.2.2 This actually works really well. - Dave ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Vyatta box hacked?
Hi Jostein,
Are you using telnet or ssh to access the box? Using telnet in not secure
from a public network as the username/password is in clear text.
stig
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jostein
Martinsen-Jones
Sent: Monday, February 04, 2008 2:43 AM
To: Dave Strydom
Cc: vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] Vyatta box hacked?
Jupp, I think i have an intruder, the ip 202.172.171.217 isn't known to me
at all.
I am the only one knowing the root password, and I have not logged in
those times that last are showing.
root pts/0202.172.171.217 Mon Feb 4 05:21 - 07:38 (02:16)
root pts/0202.172.171.217 Sat Feb 2 14:54 - 16:05 (01:11)
root pts/0202.172.171.217 Fri Feb 1 23:51 - 23:57 (00:05)
root pts/0202.172.171.217 Fri Feb 1 13:49 - 17:18 (03:29)
How did this happen?
I changed all the passwords on install to 8 character long, using numbers
and letters.
This is from my old config, are plaintext-password supposed to be blank?
# show system login
user root {
authentication {
encrypted-password: $1$nZxxsgXC/
plaintext-password:
}
}
user vyatta {
authentication {
encrypted-password: $1$yyyt0/
plaintext-password:
}
}
2008/2/4, Dave Strydom [EMAIL PROTECTED]:
Login to your router as root and run:
# last | more
and see if there are any logins to your machine which you do not
recognize.
On Feb 4, 2008 12:05 PM, Jostein Martinsen-Jones [EMAIL PROTECTED]
wrote:
I got mail from another linux user today. He complained about login
attempts
to his boxes, from my vyatta router!
Am I haxored or what? This is from his log and the ip 12.34.56.78 are
my
router.
Feb 2 18:11:39 88.191.40.120 sshd[30444]: (pam_unix) authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=12.34.56.78
user=root
Feb 2 18:11:40 88.191.40.120 sshd[30444]: Failed password for invalid
user
root from 12.34.56.78 port 42492 ssh2
Feb 2 18:11:46 88.191.40.120 sshd[30450]: User root from 12.34.56.78
not
allowed because not listed in AllowUsers
Feb 2 18:11:46 88.191.40.120 sshd[30450]: (pam_unix) authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=12.34.56.78
user=root
Feb 2 18:11:48 88.191.40.120 sshd[30450]: Failed password for invalid
user
root from 12.34.56.78 port 42926 ssh2
Feb 2 18:11:54 88.191.40.120 sshd[30456]: User root from 12.34.56.78
not
allowed because not listed in AllowUsers
Feb 2 18:11:54 88.191.40.120 sshd[30456]: (pam_unix) authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=12.34.56.78
user=root
Feb 2 18:11:56 88.191.40.120 sshd[30456]: Failed password for invalid
user
root from 12.34.56.78 port 43408 ssh2
Feb 2 18:11:56 88.191.40.120 sshd[30494]: refused connect from
12.34.56.78
(12.34.56.78)
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] IPSec Termination
Ken, You are right that changing the auto=start line will change this behavior. Initially our goal was to have a fairly simple configuration to bring-up a tunnel, but over time we'll need to add more options to the vpn cli. The last time this came up I opened an enhancement request to make this configurable (https://bugzilla.vyatta.com/show_bug.cgi?id=2506). Maybe I should increase the priority of that bug? Note: changes to /etc/ipsec.conf will be lost on a reboot. If you want to change the behavior such that it will survive a reboot you can edit /opt/vyatta/libexec/xorp/vpn-config.pl (search for auto=start). stig Couldn't you get the same thing with the VPN dead peer-detect set to HOLD? Under strongswan for example, their's a setting that would allow you to auto=start or auto=ignore, if you could add this, you should be okay. Here's how my vyatta ipsec.conf looks; conn peer-1.1.1.1-tunnel-1 left=1.1.1.1. right=2.2.2.2 leftsubnet=192.168.254.0/24 rightsubnet=192.168.255.0/24 ike=3des-md5-modp1024 ikelifetime=28800s aggrmode=no dpddelay=30s dpdtimeout=60s dpdaction=restart esp=3des-md5 keylife=3000s rekeymargin=540s type=tunnel pfs=no compress=yes authby=secret auto=start If the last line was set to auto=ignore, than I would think ipsec would be started and the host would wait for the far-end ( right ) to initiated the session. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] glendale problems my 1st view
Frankly I miss the ? and space auto-completion too, but am slowly getting use to the tabtab. Given that the new cli is integrated with bash and ? has special meaning to bash, then it probably limits our usage of ? for help. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aubrey Wells Sent: Tuesday, January 29, 2008 7:48 AM To: Ken Felix (C) Cc: vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] glendale problems my 1st view #3 - I agree, please bring back my beloved ?! Its an automatic reflex to hit ? whenever I'm in a router. I end up hitting it 3 or 4 times before I realize that its echoing the char to the screen rather than activating help. That and the new CLI being mildly confusing (i'm adjusting to it) are my only two complaints so far. -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Jan 28, 2008, at 10:03 PM, Ken Felix (C) wrote: 1. Still todate, OSPF md authenication is not enable or even configurable 2. System uptime is now show via show version show system uptime 3. system help now requires a tab vrs the previous question mark on the CLI, I thought this was confusing at first 4. system configuration like for protocols ospf is slightly different vrs vc3 5. any help on the CLI regardless of level show bash options vrs th vyatta engine options. (confusing to say the least ) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] glendale problems my 1st view
Frankly I miss the ? and space auto-completion too, but am slowly getting use to the tabtab. Given that the new cli is integrated with bash and ? has special meaning to bash, then it probably limits our usage of ? for help. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aubrey Wells Sent: Tuesday, January 29, 2008 7:48 AM To: Ken Felix (C) Cc: vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] glendale problems my 1st view #3 - I agree, please bring back my beloved ?! Its an automatic reflex to hit ? whenever I'm in a router. I end up hitting it 3 or 4 times before I realize that its echoing the char to the screen rather than activating help. That and the new CLI being mildly confusing (i'm adjusting to it) are my only two complaints so far. Has anyone explored using ~/.inputrc to rebind the ? character to something for auto-completion? It might be possible, to do $if Bash ?: C-IC-I $endif Good call Stephen. I just tried: $if Bash ?: \C-i $endif And now I get the following: [EMAIL PROTECTED] set 1st ? cluster firewallinterfaces policy protocols service system vpn [edit] [EMAIL PROTECTED] set 2nd ? Possible completions: cluster Configure clustering firewall Configure firewall interfacesNetwork interface configuration policyConfigure routing policy protocols Routing protocol configuration service Service configuration systemSystem configuration vpn Configure VPN Maybe we won't have to give up the ?. stig ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] glendale problems my 1st view
I'd vote for #1 also (but my thinking may be warped by over a decade of IOS development using the ? key ;-). The other thing to consider is the principle of least astonishment for the over 100,000 downloads of vyatta before glendale. stig I vote for #1. Maybe its just because I've been doing this for quite a while, but I would think that most people who would be annoyed about not being able to put a ? in a description or something know how to use the ctrl-v escape like with a cisco. maybe it can be a config option? set system online-help key-rebindings true -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Jan 29, 2008, at 5:27 PM, An-Cheng Huang wrote: Note also that if the '?' key is bound to auto-completion, the user can still input the '?' character using the readline escape sequence (i.e., in this case Ctrl-v ?). So basically it came down to a choice between these: (1) Keep '?' key as help. To input a '?' character, prefix it with Ctrl-v. (2) Use some other key sequence for help. A '?' character can be entered directly. At that time, (2) was deemed more acceptable than (1), so we currently have (2). An-Cheng An-Cheng Huang wrote: That was the first thing I tried when we started implementing the help system. The problem is when the user actually wants to input a '?' character, how do we rebind the '?' key back to the actual character? I also tried to rebind the key after seeing a quote (assuming '?' characters can only appear in quotes), etc., etc. In the end, this is a limitation in the readline library (which is used by bash for command line input). We _could_ change readline, I suppose, somewhere down the road. An-Cheng ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] glendale problems my 1st view
Hi Ken, Let me 1st address point #4. There is a new routing engine that has better performance, better scalability and a lot more features. Because of this the commands for the routing protocols are different. Our initial approach was to try to map the old cli exactly, but in many cases that prevented us from being able to take advantage of the new features (for example we can now support multiple bgp instances, but couldn't do that with the old cli). Another example of a cli change is vrrp which was required if we wanted to support multiple vrrp groups per interface. As for ospf md authentication, the new command for ospf authentication is under the interface (similar to how cisco does it). Try: [EMAIL PROTECTED] set interfaces ethernet eth1 ip ospf authentication md5 key-id 1 md5-key testing123 must add the md5-key for key-id 1 [edit] [EMAIL PROTECTED] commit The warning message must add the md5-key for key-id 1 is a cosmetic bug that can be ignored (bug 2211). Using wireshark I captured an OSPF hello packet and verified that Auth Type is Cryptographic Let me know if that works for you. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Felix (C) Sent: Monday, January 28, 2008 7:03 PM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] glendale problems my 1st view 1. Still todate, OSPF md authenication is not enable or even configurable 2. System uptime is now show via show version show system uptime 3. system help now requires a tab vrs the previous question mark on the CLI, I thought this was confusing at first 4. system configuration like for protocols ospf is slightly different vrs vc3 5. any help on the CLI regardless of level show bash options vrs th vyatta engine options. (confusing to say the least ) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale bug with VRRP virtual-address
Hi Dave, Actually you should be able to ignore the message and shouldn't have to enter it a 2nd time. This is bug 2211 (http://bugzilla.vyatta.com/show_bug.cgi?id=2211) which doesn't really hurt anything, but is annoying. Basically we have validation checks that are meant to be invoked on commit, but currently are also invoked on sets. These check would fail on commit, but don't fail on sets. stig Hi, When setting up the vrrp virtual-address, you need to type it in twice. Example: == [EMAIL PROTECTED] set interfaces ethernet eth1 vrrp vrrp-group 40 virtual-address 10.10.10.10 Must define the virtual-address for vrrp-group 40 [edit] [EMAIL PROTECTED] set interfaces ethernet eth1 vrrp vrrp-group 40 virtual-address 10.10.10.10 [edit] == Dave ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] DHCP pool questions
* Well that and the WAN dhclient that's in progress.
Dhcp client has already been committed to the development branch which
means itll be available in the next release (glendale) assuming the
testing goes well.
stig
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of silvertip257
Sent: Sunday, January 13, 2008 6:55 PM
To: Marat Nepomnyashy; vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] DHCP pool questions
Why cannot I take addresses out of the beginning of the block like I'd
rather it do? How can I (without rewriting/modifying source code)? That
would really stink to have to statically assign everything to make it the
way (that it makes sense). It's great and all that it actually does
assign an address and ' works ', but why not start at the beginning?
From what Marat wrote, I understand that you've seen that behavior before
- confirmed. Now, can it be changed?
I won't try to start any wars here, but that would unfortunately be one
reason I would not want to use Vyatta. Well that and the WAN dhclient
that's in progress.
I could have sworn (oh and I did commit it) that I added a config for a
second dhcp pool (separate) for eth2, but voila it's gone when I check
dhcpd.conf...
Thanks,
Mike
On Jan 13, 2008 8:37 PM, Marat Nepomnyashy [EMAIL PROTECTED] wrote:
Hi Mike,
As far as I know, it is normal for the ISC DHCP server that the Vyatta
router is using to lease out addresses starting from the last address of
the DHCP lease block, I've seen this before. Not quite sure myself why
ISC does it this way, maybe there is an assumption that the IPs at the end
of the block are less likely to be already taken...
When you write I have discovered that various parts have been separated
from the main config, what do you mean?
The DHCP server configuration file is '/opt/vyatta/etc/dhcpd.conf', not
'/opt/vyatta/etc/dhcp.conf'. The configuration for eth2 should not show
up there if you did not configure any DHCP leases for any of the subnets
to which your the interface is connected.
If you have additional questions, please send us snippets of your router
configuration under hierarchies 'interfaces ethernet' and 'service
dhcp-server'. Please also send the contents of
'/opt/vyatta/etc/dhcpd.conf'.
Thanks,
Marat
- Original Message -
From: silvertip257 mailto:[EMAIL PROTECTED]
To: vyatta-users@mailman.vyatta.com
Sent: Saturday, January 12, 2008 4:36 PM
Subject: [Vyatta-users] DHCP pool questions
I've set up a complete vyatta system a few times, even with two versions
(2.2 and 3.0).
I'm currently working with 3.0 and I'm getting the same behavior as the
last time.
I setup a DHCP server on eth1, but when it hands out addresses, it always
gives out the last address in the block (in this case 192.168.0.60
consistently).
When finding the configuration, I have discovered that various parts have
been separated from the main config - I don't know if it was that way in
previous versions, but thought I'd mention it.
Also, my DHCP server for eth2 does not show up in
/opt/vyatta/etc/dhcp.conf ;; that's another issue that I'll have to solve
after this one.
My config for the DHCP server:
shared-network Subnet1 {
subnet 192.168.0.32 netmask 255.255.255.224 {
not authoritative;
default-lease-time 86400;
max-lease-time 86400;
range 192.168.0.34 192.168.0.60;
}
Thanks,
Mike
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^
_
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^
--
// SilverTip257 //
==
~
· ·
/V\
// \\
/( )\
^`~´^
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] VRRP and disable-vmac true
Hi Dave, When a new master takes over the vip address it sends out a gratuitous arp so that the hosts can learn the new mac. stig Hi, I been reading a few posts regarding Bug 2350 https://bugzilla.vyatta.com/show_bug.cgi?id=2350 Doesn't the disable-vmac true option create an issue with the arp cache on the devices that are routing to the vrrp vip address? Dave ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] GLBP
Can canyone comment more on load balaning vrrp? Active/active style configuration? Perhaps even noting bgp? I was not aware with vrrp one could have two routers handling packets :/ This may have changed, but I believe Vyatta only supports one VRRP address per interface. Consider what I'm describing here a feature request, although perhaps someone else can comment on how to make this work with the current functionality. :) Hi Dave, I have already added the support of both multiple vrrp groups per interface and multiple vips per vrrp group in the current development branch. So assuming the testing of these features goes well, then you should see it in the glendale release. I'm hoping to also add support for vrrp sync groups if time permits. stig If Vyatta supported multiple VRRP addresses (and the equipment behind it supports ECMP), you could do active/active by configuring two default gateway addresses and using the VRRP priority/preempt parameters to give one address an affinity for one router and one for the other. For instance: Router A, x.x.x.3, VRRP addresses x.x.x.1 priority 100 and x.x.x.2 priority 50 Router B, x.x.x.4, VRRP addresses x.x.x.1 priority 50 and x.x.x.2 priority 100 Device C, x.x.x.5, default gateway configured as x.x.x.1 and x.x.x.2 with equal metrics In normal operation, half the packets will be processed by either router (depending on how device C implements equal cost multipath). If one router fails, both the .1 and .2 addresses end up on the surviving box. N.B. this breaks stateful packet inspection. I believe the original reason for the one-addres-per-interface restriction was due to the virtual MAC address. Now that we have the disable-vmac option, perhaps this limitation could be removed? - -- Dave Pifke, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBR4aPSTuW2fOIQC3pAQFKmgP/U6kbweEz+HR0Tbrq5aeoXOZu2JXpav4y fVjBzG8wR7mL/2b1whiVjUq/hj55uiMcXPWQ4+dxWvbRoJgZZx1o1kpjfASW3z+J aCJ4fbcv0O2fmWqxVGuEc8gPohW3BrBuWOipj1y7vFofmfV7dkEtyOdLLFbaLE9I Jt7AFqzoFCM= =ASQ2 -END PGP SIGNATURE- ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Commit Error
Check /var/log/messages (or show log) for further error messages.
stig
-Original Message-
From: [EMAIL PROTECTED] [mailto:vyatta-users-
[EMAIL PROTECTED] On Behalf Of Clint Chapman
Sent: Friday, January 04, 2008 6:38 PM
To: [EMAIL PROTECTED]
Subject: [Vyatta-users] Commit Error
[EMAIL PROTECTED] show protocols
bgp {
bgp-id: removeIP
local-as: my as number
peer 72.*.*.* { (ISP side of the /30)
local-ip: 72.37.132.238 (My side of the /30)
as: 25973
next-hop: 72.37.132.238 (My side of the /30)
disable-readvertisements: true
}
}
static {
route 0.0.0.0/0 {
next-hop: 72.*.*.*
}
}
[edit]
[EMAIL PROTECTED] commit
[edit]
Commit Failed
102 Command failed
[EMAIL PROTECTED]
Why am I getting that error, I don't think I have anything to complex
in there.
Thanks!
CLint
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Possible Memory Leak
Shouldn't the command 'show system memory' be mapped to run through 'free -m' then? I would consider this as a feature enhancement. Seems like a reasonable request. It's very easy to change yourself if you don't want to wait for a future release. Here's how (assuming vc3): 1) login as root 2) go to the template directory vDUT:~# cd /opt/vyatta/share/xorp/templates 3) find the free command vDUT:# grep free *.cmds rl_misc.cmds: %command: free -ot %help: Show system memory usage; 4) See that it's in the file rl_misc.cmds. Change it from -ot to -m with sed vDUT:# cp rl_misc.cmds rl_misc.cmds.bak vDUT:# sed -i 's/free -ot/free -m/' rl_misc.cmds 5) try it: vDUT:# xorpsh Welcome to Vyatta on vDUT [EMAIL PROTECTED] show system memory total used free sharedbuffers cached Mem: 250190 59 0 23 96 -/+ buffers/cache: 70179 Swap:0 0 0 stig I am also in a state of confusion as to why this list insists on sending the reply address as the sender of the last message..I have to manually copy and paste the '[EMAIL PROTECTED]' email address into the To.. box everytime I reply to a message. Thanks, Shane McKinley Habersham EMC -Original Message- From: David Nalley [mailto:[EMAIL PROTECTED] Sent: Monday, December 17, 2007 1:08 PM To: Nick Davey; [EMAIL PROTECTED] Subject: Re: [Vyatta-users] Possible Memory Leak To people who aren't used to dealing with Unix-like systems this is a common complaint. What show system memory is really doing is running free. BTW Vyattans - to avoid this in the future, please consider this a enhancement request to alias 'show system memory' to 'free -m' In olden days, RAM was expensive, but it's also very fast; far faster than disk, so Linux would buffer and cache items to RAM that it 'thought' it would use, and keep it near full all of the time, because it was mere nanoseconds to dump and fill with something else. The thought was that you paid oodles for this expenseive RAM, might as well use it to speed the system up even if you don't have a lot of use for it as RAM, maybe we can use it as a tertiary level CPU cache, or a nice disk buffer. To really see what is 'freeable' it should look at free ram as the free column plus buffers and cache. If you use free -m from the comand line you will see something akin to: vyatta:~# free -m total used free sharedbuffers cached Mem: 1011995 16 0467 427 -/+ buffers/cache:100911 Swap:0 0 0 Which shows that the system is really consuming only 100 Megs of RAM but has almost 900 cached. Nick Davey wrote: Hi All, I've noticed some pretty intense memory usage out of my Vyatta router: [EMAIL PROTECTED] show system memory total used free sharedbuffers cached Mem:255268 250956 4312 0 142652 32900 Swap:0 0 0 Total: 255268 250956 4312 I know the spacing is a bit off, but free memory is only 4312 bytes. Examining the process memory usage under the shell shows that the xorp daemons are using the lions share of the memory: core:~# ps aux | more USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 1948 636 ?Ss Oct31 0:03 init [2] root 2 0.0 0.0 0 0 ?SOct31 0:00 [migration/0] root 3 0.0 0.0 0 0 ?SN Oct31 0:00 [ksoftirqd/0] root 4 0.0 0.0 0 0 ?SOct31 0:00 [watchdog/0] root 5 0.0 0.0 0 0 ?S Oct31 0:00 [events/0] root 6 0.0 0.0 0 0 ?S Oct31 0:00 [khelper] root 7 0.0 0.0 0 0 ?S Oct31 0:00 [kthread] root31 0.0 0.0 0 0 ?S Oct31 0:00 [kblockd/0] root52 0.0 0.0 0 0 ?S Oct31 0:00 [kseriod] root86 0.0 0.0 0 0 ?SOct31 0:00 [pdflush] root87 0.0 0.0 0 0 ?SOct31 0:00 [pdflush] root88 0.0 0.0 0 0 ?S Oct31 0:00 [kswapd0] root89 0.0 0.0 0 0 ?S Oct31 0:00 [aio/0] root 1494 0.0 0.0 0 0 ?S Oct31 0:00 [khubd] root 1580 0.0 0.0 0 0 ?S Oct31 0:00 [ata/0] root 1581 0.0 0.0 0 0 ?S Oct31 0:00 [ata_aux] root 1843 0.0 0.0 0 0 ?S Oct31 0:09 [kjournald] root 2006 0.0 0.2 2176 612 ?Ss Oct31 0:00 udevd --daemon root 2835 0.0 0.0 0 0 ?S Oct31 0:00 [kpsmoused] root
Re: [Vyatta-users] VRRP Confusion
I wonder if this might be solved with the disable-vmac setting? stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Daniel Stickney Sent: Wednesday, December 12, 2007 2:47 PM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] VRRP Confusion Hello everyone, I used google to search the mail list archive, but didn't get any results for my issue. This is my second day working on the problem and my colleagues don't have any suggestions. This post is a little long, but I hope thorough enough to give all relevant information. Here is my setup: vyatta01 - eth0:192.168.2.50, eth1:192.168.10.3 vyatta02 - eth0:192.168.2.51, eth1:192.168.10.2 laptop01 - eth0:192.168.10.11 Laptop01 is connected to a switch, which also has cables from eth1 on both vyatta01 and vyatta02 connected. Eth0 on both vyatta01 and vyatta02 are connected into the main 192.168.2.0/24 network which has internet connectivity. With a base configuration of a default route to 192.168.2.21 on both vyatta01 and vyatta02, and the above IPs assigned to their respective network cards, I can ping 192.168.10.2 and 192.168.10.3 from laptop01; and I can ping 192.168.10.2 from vyatta01, and I can ping 192.168.10.3 from vyatta02. Basically, everything can ping everything. I then proceed to setup VRRP between vyatta01 and vyatta02 with the following config: --Vyatta02-- set interfaces ethernet eth1 vrrp vrrp-group 10 set interfaces ethernet eth1 vrrp virtual-address 192.168.10.1 set interfaces ethernet eth1 vrrp preempt true set interfaces ethernet eth1 vrrp priority 150 commit --Vyatta01-- set interfaces ethernet eth1 vrrp vrrp-group 10 set interfaces ethernet eth1 vrrp virtual-address 192.168.10.1 set interfaces ethernet eth1 vrrp preempt true set interfaces ethernet eth1 vrrp priority 20 commit So vyatta02 is the master, VIP is 192.168.10.1. Immediately, and as expected, I see in the output of show vrrp that vyatta02 considers itself the master, and vyatta01 sees itself as the backup. In a tcpdump from laptop01 I can see the VRRPv2 advertisements from vyatta02 every second. At this time from laptop01 I am unable to ping 192.168.10.1 or 192.168.10.2, but I can ping 192.168.10.3. The arp table on laptop01 shows the following: # arp -n Address HWtype HWaddress Flags MaskIface 192.168.10.3 ether 00:1A:A0:2A:04:0A C eth0 192.168.10.1 ether 00:00:5E:00:01:0A C eth0 192.168.10.2 ether 00:00:5E:00:01:0A C eth0 From vyatta01, I am also unable to ping 192.168.10.1 and 192.168.10.2. What is causing me great confusion is if on vyatta02 I login as root and execute a tcpdump -i eth1, instantly my pings from laptop01 and vyatta01 to both 192.168.10.1 and 192.168.10.2 start getting responses. As soon as I ctrl-c the tcpdump on vyatta02, the ping responses stop again. If I reconfigure the VRRP priority of vyatta02 to be lower than vyatta01, they change over to vyatta01 being the master, and vyatta02 as the backup. At this time from laptop01 I am able to ping 192.168.10.1, 192.168.10.2 and 192.168.10.3. In a tcpdump on laptop01 I see the VRRP advertisements coming from 192.168.10.3 as expected. The arp table on laptop01 now looks like this: # arp -n Address HWtype HWaddress Flags MaskIface 192.168.10.3 ether 00:00:5E:00:01:0A C eth0 192.168.10.1 ether 00:00:5E:00:01:0A C eth0 192.168.10.2 ether 00:14:6C:70:50:6B C eth0 All systems can ping eachothers 192.168.10.x IPs at this time. In summary, I don't understand why when vyatta02 is master in the VRRP group both its IP 192.168.10.2 and the VIP 192.168.10.1 it is holding become unresponsive to pings. Then when a tcpdump -i eth1 is run on vyatta02 both of the previously unresponsive IPs start responding to pings, then when the tcpdump is killed, the ping responses stop again. In a tcpdump from laptop01 while pinging 192.168.10.1 while vyatta02 is master and a tcpdump is not running, I can see the arp request and reply, then icmp echo requests being sent, but no responses. 15:24:38.645141 arp who-has 192.168.10.1 tell 192.168.10.11 15:24:38.645304 arp reply 192.168.10.1 is-at 00:00:5e:00:01:0a 15:24:38.645327 IP 192.168.10.11 192.168.10.1: ICMP echo request, id 43386, seq 1, length 64 15:24:39.644156 IP 192.168.10.11 192.168.10.1: ICMP echo request, id 43386, seq 2, length 64 15:24:40.644125 IP 192.168.10.11 192.168.10.1: ICMP echo request, id 43386, seq 3, length 64 15:24:41.644104 IP 192.168.10.11 192.168.10.1: ICMP echo request, id 43386, seq 4, length 64 15:24:42.644064 IP 192.168.10.11 192.168.10.1: ICMP echo request, id 43386, seq 5, length 64
Re: [Vyatta-users] VRRP Confusion
Hi Daniel, I don't think the disable-vmac option was in vc3, but you can look at the change here: http://suva/git/?p=xorp.git;a=commit;h=0b3e4418e0ae961d902cc40209035f1b5ea a7adf Basically you can edit vrrpd.init and add a -n parameter to vrrpd to enable non-rfc compliance mode (i.e. no vmac). stig Thank you both Stig and Allan for your input. How might I disable the vmac setting? I found a file called /opt/vyatta/sbin/vrrpd.init, but no mention of the string vmac in all of /opt. An interesting point is that the failure to respond to pings except when tcpdump is running only occurs on vyatta02. When vyatta01 is master, it responds to pings on 192.168.10.1(VIP) and 192.168.10.3(eth1). When vyatta02 is master, neither the VIP it holds nor 192.168.10.2(eth1) respond to pings. I tried two other tests without success. I swapped out the switch they are all plugged into for the 192.168.10.0 network, and I also swapped the 10.2 IP to vyatta01 and the 10.3 IP to vyatta02, but that also made no difference. I have placed them back to their configuration as documented in my original email. Thanks for your time, -Daniel Allan Leinwand wrote: A thought here that may help cut through some of the confusion. I think that when you run tcpdump on the interface it places that interface into promiscuous mode. When in this mode, it can respond to pings to both the real IP address on the Ethernet and the virtual IP address (all packets are being received by the interface so when it sees one for it's own IP addresses, it responds). However, when the interface is running VRRP and in non-promiscuous mode I am unsure if the real IP and the virtual IP both respond to pings. Final caveat: I have not tried any of this recently, so with my advice YMMV. Thanks, allan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stig Thormodsrud Sent: Thursday, December 13, 2007 12:23 PM To: 'Daniel Stickney'; vyatta-users@mailman.vyatta.com; 'Daniel Stickney'; vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] VRRP Confusion I wonder if this might be solved with the disable-vmac setting? stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Daniel Stickney Sent: Wednesday, December 12, 2007 2:47 PM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] VRRP Confusion Hello everyone, I used google to search the mail list archive, but didn't get any results for my issue. This is my second day working on the problem and my colleagues don't have any suggestions. This post is a little long, but I hope thorough enough to give all relevant information. Here is my setup: vyatta01 - eth0:192.168.2.50, eth1:192.168.10.3 vyatta02 - eth0:192.168.2.51, eth1:192.168.10.2 laptop01 - eth0:192.168.10.11 Laptop01 is connected to a switch, which also has cables from eth1 on both vyatta01 and vyatta02 connected. Eth0 on both vyatta01 and vyatta02 are connected into the main 192.168.2.0/24 network which has internet connectivity. With a base configuration of a default route to 192.168.2.21 on both vyatta01 and vyatta02, and the above IPs assigned to their respective network cards, I can ping 192.168.10.2 and 192.168.10.3 from laptop01; and I can ping 192.168.10.2 from vyatta01, and I can ping 192.168.10.3 from vyatta02. Basically, everything can ping everything. I then proceed to setup VRRP between vyatta01 and vyatta02 with the following config: --Vyatta02-- set interfaces ethernet eth1 vrrp vrrp-group 10 set interfaces ethernet eth1 vrrp virtual-address 192.168.10.1 set interfaces ethernet eth1 vrrp preempt true set interfaces ethernet eth1 vrrp priority 150 commit --Vyatta01-- set interfaces ethernet eth1 vrrp vrrp-group 10 set interfaces ethernet eth1 vrrp virtual-address 192.168.10.1 set interfaces ethernet eth1 vrrp preempt true set interfaces ethernet eth1 vrrp priority 20 commit So vyatta02 is the master, VIP is 192.168.10.1. Immediately, and as expected, I see in the output of show vrrp that vyatta02 considers itself the master, and vyatta01 sees itself as the backup. In a tcpdump from laptop01 I can see the VRRPv2 advertisements from vyatta02 every second. At this time from laptop01 I am unable to ping 192.168.10.1 or 192.168.10.2, but I can ping 192.168.10.3. The arp table on laptop01 shows the following: # arp -n Address HWtype HWaddress Flags MaskIface 192.168.10.3 ether 00:1A:A0:2A:04:0A C eth0 192.168.10.1 ether 00:00:5E:00:01:0A C eth0 192.168.10.2 ether 00:00:5E:00:01:0A C eth0 From vyatta01, I am also unable to ping 192.168.10.1 and 192.168.10.2. What is causing me great confusion
Re: [Vyatta-users] Vyatta null route
Unfortunately there is a known bug with discard. See http://bugzilla.vyatta.com/show_bug.cgi?id=1933 stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Peter Wohlers Sent: Wednesday, December 12, 2007 9:22 AM To: Shane McKinley Cc: [EMAIL PROTECTED] Subject: Re: [Vyatta-users] Vyatta null route Try the 'discard' operator so set protocols static route x.x.x.x/x discard or maybe it's set protocols static route x.x.x.x/x next-hop discard --Peter Shane McKinley wrote: I am trying to figure out how to insert a null route into my Vyatta OFR. I tried: set protocols static route x.x.x.x/x next-hop 0.0.0.0 But then it does not show when executing: show route Any ideas? Thanks, Shane McKinley Habersham EMC ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Serial Port
Did you do a apt-get update after adding the debian repository?
stig
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Todd Worden
Sent: Thursday, December 06, 2007 7:04 PM
To: vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] Serial Port
Hi thx!
I added that package, but got an error on apt-get install minicom.
complains that minicom is not available, but is referred to by another
package. This may mean that the package is missing, has been obsolete, or
is only available from another source E: Package minicom has no
installation candidate
Would a different repository help?
Thanks!
Todd
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aubrey Wells
Sent: Thursday, December 06, 2007 9:26 PM
To: Todd Worden
Cc: vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] Serial Port
I just add the debian repository to my config and then apt-get install
minicom and use it.
package {
repository community {
component: main
url: http://archive.vyatta.com/vyatta;
}
repository stable {
component: main
url: http://mirrors.kernel.org/debian/;
}
}
--
Aubrey Wells
Senior Engineer
Shelton | Johns Technology Group
404.478.2790
Support: [EMAIL PROTECTED]
www.sheltonjohns.com
On Dec 6, 2007, at 8:32 PM, Todd Worden wrote:
Is there a serial port console application that comes with Vyatta like TIP
so that I can connect my null modem cable to the router and then to my
Netgear switch to configure the switch from my router appliance?
Todd Worden
Software Developer
Growing Technologies
P: 434-296-1500
E: [EMAIL PROTECTED]
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
__ NOD32 2708 (20071207) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] documentation suggestion
Hi Jeff, Another relevant bug is https://bugzilla.vyatta.com/show_bug.cgi?id=2368 As for ipt_rlsnmpstats, that's used to get the stats you see with show snmp, but shouldn't affect the rest of the system. However there are other minor changes to our kernel. stig FWIW, to verify if the r8169 driver problem was fixed, I built a 2.6.23.9 stock kernel and booted the router using it. When I built it, I used the original config as a starting point: # cd /usr/src/linux # cp /boot/config.gz . # gunzip config.gz # make menuconfig (and then load .config, check everything, and save) It boots up fine, but when it goes to start the router-mgr I get: Module ipt_rlsnmpstats not found. Is this a custom vyatta module maybe that isn't in the stock kernel? Should I just give up and buy some different NICs or is using a newer kernel potentially an option once this module issue is solved? Thanks, Jeff P.S. I apologize if I should have posted this to vyatta-hackers instead. - Jeff Stockett [EMAIL PROTECTED] wrote: My vyatta test setup includes two identically equipped older athlon xp systems where eth0=onboard nforce, eth[1-3]=r8169 based cards. Everything is working fine on both systems, but this weekend I spent about an hour trying to get VRRP to work for fail-over. It works fine on eth0 (onboard nforce) but I couldn't get it to work on eth1-3. In exploring the issue, it appears that not all drivers support the ability to set the MAC address (which it appears VRRP needs). I found the following post: http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.22- git1.log It appears to indicate the r8169 driver didn't get the ability to set its MAC address until sometime in kernel 2.6.22 which obviously does me no good at the moment. This isn't a big deal financially, as the only reason I bought the cards was that Fry's had them on sale for $4.99 each and they had a low profile bracket which fit the cases I was using. However, it might be useful to put a blurb in the VRRP section of the documentation stating that the card's driver must support setting the MAC address for VRRP to work (and maybe even list which drivers support and don't support it although I can see how this list might be difficult to compile). FWIW, I also notice in: https://bugzilla.vyatta.com/show_bug.cgi?id=2370 that the latest greatest build has support for a disable-vmac option - but when I tried it in VC3 I just got syntax errors. I'm assuming this would fix the problem also as the card then wouldn't have to set its MAC address but just use it as is? How hard is it to upgrade to a nightly build (we're still a few months away from production so I wouldn't be too concerned with stability)? Any suggestions other than use a different card? Thanks, Jeff ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Remote access VPN Howto
Hi Biswajit, There is some documentation at: http://www.vyatta.com/documentation/VC3/Vyatta_ConfigGuide_VC3_v02.pdf. Also one of our community members has put together a great tutorial at: http://www.openmaniak.com/vyatta_case_ipsec.php. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Biswajit Banerjee Sent: Sunday, November 25, 2007 11:23 PM To: [EMAIL PROTECTED] Subject: [Vyatta-users] Remote access VPN Howto Hi , There are documentation reference to site-to-site VPN . Can some throw light on remote access vpn configuration on vyatta so that any win / linux client can access vyatta and network via VPN. Any how tos are available ? TIA Regards Biswajit ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] IPsec SA idle timer
To exemplify, the other end of the tunnel is represented by an ISA 2006. After about 5-6 minutes, time within the tunnel was idle(no traffic exchange between the two sides), ISA will drop the IPsec SA informing its tunnel partener about this. The IKE SA is not dropped. If the other end of the tunnel was, say another ISA, and no traffic was needed to pass through the tunnel, then no IKE QM negotiations will follow, so no IPsec SA. Once traffic destined to the remote site reaches ISA, IKE QM are started and IPsec SAs are established. I suppose the logic behind this is not to waste resources. However, Vyatta, after receiving the ISAKMP Informational packet from ISA to delete the SA, it does so and immediately starts the IKE QM negotiations to establish a new IPsec SA even when is not traffic ready to be sent through the tunnel. I think the reason for the immediate re-establishment is the auto=start value in /etc/ipsec.conf. If you want to experiment you could try logging in as root and edit /etc/ipsec.conf and change auto=start to auto=add. Then go back into xorpsh and do a clear vpn ipsec-process to reread the conf file. If that works then I can send you a patch to the perl script that generates that conf file. stig So we end up consuming resources instead of saving them. ISA lets me modify its idle timer through a reg hack, but it's a global modification(not per site). As said before this is not really an issue or a problem. I do not have something against maintaining the IPsec SA up throughout its lifetime. By the way, ISA does not support DPD. Thanks, Adrian ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Cannot remove/change default route
* I need some help here. I have hard time to change the default route.
I tried delete and commit, set (new value)
* and commitnothing sucessfull. Check below. Does anyone can point
out my mistake?
Hmm, that's odd. I just booted up a vc3 and tried the same thing:
[EMAIL PROTECTED] show protocols static
route 0.0.0.0/0 {
next-hop: 172.16.117.1
}
[edit]
[EMAIL PROTECTED] delete protocols static route 0.0.0.0/0
Deleting:
0.0.0.0/0 {
next-hop: 172.16.117.1
}
OK
[edit]
[EMAIL PROTECTED] commit
[edit]
OK
[EMAIL PROTECTED] show protocols static
[edit]
Can you check /var/log/messages to see if it logged any errors? You could
also try delete protocols static. Do you happen to also have a default
gateway setup with set system gateway ip addr?
stig
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Philippe
Marcais
Sent: Wednesday, November 21, 2007 5:46 PM
To: [EMAIL PROTECTED]
Subject: [Vyatta-users] Cannot remove/change default route
I need some help here. I have hard time to change the default route. I
tried delete and commit, set (new value) and commitnothing sucessfull.
Check below. Does anyone can point out my mistake?
[EMAIL PROTECTED] show version
Baseline Version: vc3
Booted From: livecd
[EMAIL PROTECTED] configure
Entering configuration mode.
There are no other users in configuration mode.
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] # show protocols
static {
route 0.0.0.0/0 {
next-hop: 10.60.40.2
}
}
[edit]
[EMAIL PROTECTED]
[EMAIL PROTECTED] delete protocols static route 0.0.0.0/0
Deleting:
0.0.0.0/0 {
next-hop: 10.60.40.2
}
OK
[edit]
[EMAIL PROTECTED] show protocols
static {
- route 0.0.0.0/0 {
- next-hop: 10.60.40.2
- }
}
[edit]
[EMAIL PROTECTED]
[EMAIL PROTECTED] commit
[edit]
Commit Failed
[EMAIL PROTECTED] t delete unicast route for 0.0.0.0/0: no such
[EMAIL PROTECTED]
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] a few questions/problems
1. Is VIF support NIC specific? I have a test box, with one built-in 100Mb/s forcedeth (NForce2) interface, and a couple of cheap Realtek 8169 PCI 1000Mb/s interfaces. All work fine without VIFs, but when I try to add a VIF to the r8169 cards, the commit fails (and all subsequent commits of any type until a reboot). Adding VIFs to the onboard Nforce NIC works fine. Is there a list somewhere of what cards work with VIFs or is this perhaps something else? Could you try the vif command from the linux shell instead to see if it gives you a error message on that nic. For example, try creating eth1.101 with: vDUT-stig:~# vconfig add eth1 101 Added VLAN with VID == 101 to IF -:eth1:- vDUT-stig:~# ifconfig eth1.101 eth1.101 Link encap:Ethernet HWaddr 00:0C:29:EF:FC:25 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) 2. Also, are there any plans for a web service interface as an alternative to the CLI. The scenario would be wanting to control the router(s) externally from another custom management app. For instance, I'd like to be able to connect to the router via a secure channel from my app, and create a new VIF and a few NAT and FW rules for it, etc. I can see how this might be hacked by reverse engineering the inputs to xgcgi in your existing web interface and feeding it with curl or something similar over https, but a standard web services interface would be much nicer. Does libxorp already have something like this? There is a web interface that can be enabled with set service webgui. 3. After I get the VIFs working properly, I'm going to test the VRRP stuff. One question that doesn't seem to be covered in the VRRP documentation that I've been wondering about - do the configs auto update between master and slave(s) or is the user responsible for manually editing the configs on all machines in the group to keep things in sync? The standard vrrp feature as described by rfc2338 does not have any config sync'ing. stig Thanks, Jeff ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] IPsec configuration
Think of it as an access-list where a packet's source/destination
addresses are compared to see if it should be encapsulated into the
tunnel. Those subnet commands do accept 0.0.0.0 such that anything
matches.
stig
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Philippe
Marcais
Sent: Wednesday, November 21, 2007 5:58 PM
To: [EMAIL PROTECTED]
Subject: [Vyatta-users] IPsec configuration
What is the purpose of the following configuration line;
tunnel 1 {
local-subnet: 192.168.0.0/24
remote-subnet: 10.40.1.0/24
Why does the tunnel has to be link to a local subnet? In fact, I may have
multiple local subnet from multiple interface or sub-interface using this
IPsec tunnel.
Same question regarding for the remote subnet. I do have multiple remote
subnets that I'd like to reach out on the remote side.
Thanks,
Philippe
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] vyatta on VMWare on Ubuntu AMD64
I have run into this in the past when I've copied a virtual machine from one physical machine to another. When I did a search on vmware's forum for this error message they said it generally was due to a file permission problem. In my case a quick chmod fixed the issue, so you might want to look at the file permissions in your virtual machine directory. stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Bernhard D Rohrer Sent: Monday, November 12, 2007 6:36 AM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] vyatta on VMWare on Ubuntu AMD64 Hiya I have downloaded and tried to boot the VMWare image and have also tried to boot a Vm from ISO myself. in both cases I am getting Unable to change virtual machine power state: The process exited with an error: End of error message. help? cheers Bernhard -- Graylion's Fetish Fashion Store Goth and Kinky Boots, Clothing and Jewellery http://www.graylion.net ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Login
Sounds like it might be chocking on the wireless adapter in the laptops. Are there other error messages in /var/log/messages? stig _ From: Eduardo Pardo [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2007 7:18 AM To: Stig Thormodsrud Subject: Re: [Vyatta-users] Login Starting Vyatta router: migrate rl-system firewall rtrmgr /bcm43xx: Error: Microcode bcm43xx_microcode5.fw not avaible or load failed. bcm43xx: core up for active 802.11 core failed (-2) On Nov 12, 2007 10:16 AM, Eduardo Pardo [EMAIL PROTECTED] wrote: Hi, Yes, I got this error message at the end of booting part while starting rtrmgr : Starting Vyatta router: migrate rl-system firewall trmgr /bcm43xx: Error: Microcode bcm43xx_microcode5.fw not avaible or load failed. bcm43xx: core up for active 802.11 core failed (-2) any idea ? On Nov 11, 2007 10:56 PM, Stig Thormodsrud mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: * If the router manager wasn't able to start or if it crashed, then you won't be able to log in as root Opps, I meant you won't be able to login as vyatta if router manager doesn't start. You can also check for the router manager with: vDUT-stig-2:/# ps aux | grep rtrmgr root 4549 0.3 5.5 28468 14244 ?Ss Nov05 30:08 /opt/vyatta/sbin/xorp_rtrmgr -b /media/floppy/config/config.boot root 9658 0.0 0.2 2856 700 pts/0R+ 20:56 0:00 grep rtrmgr stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stig Thormodsrud Sent: Sunday, November 11, 2007 7:54 PM To: 'Eduardo Pardo'; vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] Login If the router manager wasn't able to start or if it crashed, then you won't be able to log in as root. Login as root and look for errors in /var/log/messages that might give a clue to the problem. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduardo Pardo Sent: Sunday, November 11, 2007 7:40 PM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] Login Hi, I've just burned vyatta image into a cd in order to run vyatta live cd in my laptop, an HP pavilion dv2410 running Windows Vista, but I could not log in, because the username vyatta and the password vyatta, was wrong, although I could log into linux promt with username root and vyatta as the password. I tried to run the vyatta live cd in another laptop, a COMPAQ, running Windows XP, and in another desktop,running both Windows XP and Ubuntu, I had the same problem in the laptop BUT NOT in the desktop, I could log in into vyatta and work properly in it. How come ? Could somebody help me ? I really need to run vyatta in my laptop. Thanks. -- Eduardo Pardo C. -- Eduardo Pardo C. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] OpenVPN and OSPF
Hi Troppy, Under quagga i just successfully added the network 10.7.0.2/30 (the tunnel network) in OSPF but under Vyatta you need to use an interface (set protocol ospf4 area 0.0.0.0 interface ...) and of course i have no tun or tap interface available at the VYatta level, so i tried to use the ethernet interface and put 10.7.0.1/30 as a secondary interface. In the current release it is difficult to get xorp to deal with any interfaces that are created outside of its control, so I think it will be difficult to get xorp to play nicely with your tunnel interface. There is work well under way to change that, but until that release is available do you know if OpenVPN allows you to configure it with NetKey. For OpenSwan we use NetKey instead of KLIPS and with NetKey it uses an existing interface instead of creating a tunnel interface. The best thing would be that it wouldn't be mandatory to add an interface in the Vyatta OSPF statement. :-) That's also fixed in that future release that I mentioned. :-) stig Hello, Here is the routes i see on the Vyatta interface. the OpenVPN virtual interface tun0 is correctly seen. [EMAIL PROTECTED] show route Routes: 6/6, Paths: 6/6 0.0.0.0/0 [static(1)] to 50.0.1.1 via eth0 10.7.0.0/30 [connected(0)] to 10.7.0.1 via tun0 10.7.0.1/32 [connected(0)] to 10.7.0.1 via tun0 10.255.255.1/32 [connected(0)] to 10.255.255.1 via lo 50.0.1.0/24 [connected(0)] to 50.0.1.51 via eth0 127.0.0.0/8 [connected(0)] to 127.0.0.1 via lo The problem is i cannot use the tun0 interface in the OSPf statement Regards TRoopy -- Original Message -- From: Troopy . [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Mon, 12 Nov 2007 12:09:16 +0100 Hello, I have installed OpenVPN on Vyatta successfully to test OSPF status with a Linux/Quagga router. I would like to use it with Vyatta in a (magic) triangle scenario. The thing is, OpenVPN creates a Virtual interface called tap or tun. Under quagga i just successfully added the network 10.7.0.2/30 (the tunnel network) in OSPF but under Vyatta you need to use an interface (set protocol ospf4 area 0.0.0.0 interface ...) and of course i have no tun or tap interface available at the VYatta level, so i tried to use the ethernet interface and put 10.7.0.1/30 as a secondary interface. The result is the following, the Quagga sees correcty the Vyatta router as OSPF neighbour but not the contrary. I think this is because i had to declare the network tunnel (10.7.0.0/30) under the eth0 interface. The best thing would be that it wouldn't be mandatory to add an interface in the Vyatta OSPF statement. :-) Can you help me? Has anyone connected two Vyatta together with OSPF and OpenVPN? Thanks Troopy __ Désirez vous une adresse éléctronique @suisse.com? Visitez la Suisse virtuelle sur http://www.suisse.com __ Désirez vous une adresse éléctronique @suisse.com? Visitez la Suisse virtuelle sur http://www.suisse.com ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Login
If the router manager wasn't able to start or if it crashed, then you won't be able to log in as root. Login as root and look for errors in /var/log/messages that might give a clue to the problem. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduardo Pardo Sent: Sunday, November 11, 2007 7:40 PM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] Login Hi, I've just burned vyatta image into a cd in order to run vyatta live cd in my laptop, an HP pavilion dv2410 running Windows Vista, but I could not log in, because the username vyatta and the password vyatta, was wrong, although I could log into linux promt with username root and vyatta as the password. I tried to run the vyatta live cd in another laptop, a COMPAQ, running Windows XP, and in another desktop,running both Windows XP and Ubuntu, I had the same problem in the laptop BUT NOT in the desktop, I could log in into vyatta and work properly in it. How come ? Could somebody help me ? I really need to run vyatta in my laptop. Thanks. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] invalid pre-shared secret key
Hi all, just installed yvatta and wanted to establish an ipsec vpn connection. When entering the pre-shared-secret I receive the following message: snip [EMAIL PROTECTED] set vpn ipsec site-to-site peer xxx.xxx.xxx.xxx authentication pre-shared-secret 11([EMAIL PROTECTED] [edit] [EMAIL PROTECTED] commit [edit] Commit Failed invalid pre-shared secret key 11([EMAIL PROTECTED] /snip I tried to escape the chars but without succes. So, any idea why those special chars (for higher security of course) don't work? Have you tried using quotes around it? [EMAIL PROTECTED] set vpn ipsec site-to-site peer 10.0.0.1 authentication pre-shared-secret 11([EMAIL PROTECTED] [edit] stig Cheers Mathias ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Static routing and E1 serial
I have two PCs linked by an E1 link wit Sangoma A101 cards PC1 eth0 10.0.0.0/24 wan0 local 192.168.0.1 remote 192.168.0.2 prefix-length 24 PC2 eth0 10.9.1.0/24 wan0 local 192.168.0.2 remote 192.168.0.1 prefix-length 24 show route does not show the wan ports and I cannot ping them locally Do the connected routes show up in show route system forward? Can you ping the remote end of the wan link (often you can't ping the local end of a non-broadcast media). stig Looking at PC1 /var/log/wan0.1.log I see Peer is not authorized to use remote address 192.168.0.2 and equivalent also on PC2 The wan link is in PPP mode with authentication type set to none ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Implementing IPsec across two points with staticrouting
It would be helpful to see the configs, but my quess would be that the packet coming from C does not match the local-subnet and/or remote-subnet configuration on B, so it's not getting put in the tunnel. If C has a different subnet you may need to add another tunnel or if this is all internal you might try the any subnet 0.0.0.0. stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Sent: Monday, October 15, 2007 2:19 PM To: [EMAIL PROTECTED] Subject: [Vyatta-users] Implementing IPsec across two points with staticrouting Greetings folks, I'm a new vyatta user and we've been trying to do some testing internally to determine whether or not Vyatta may be a candidate to replace some of our routers out in the field. Recently we were pleased by the ease of setting up IPsec tunnels, but we ran into one little snag in our testing environment. We currently had three routers configured, we'll call them A, B, and C. All three of these Vyatta installations have PC's behind them. Routers A B were connected with IPsec tunnels, and each private network could speak the other. Router C was directly connected to router B. All three were configured to talk to each other via static routes. When C wanted to speak to A's network, she could ping both the external and internal vyatta interfaces, but couldn't seem to reach the LAN PC's connected behind A. Traceroutes for the failed pings indicated that the packets seemed to die at Router B, never even getting forwarded over towards Router A-- but again, only when trying to get to the LAN PC's. Is this a bad setup that we botched in some way, or perhaps something else like the lack of GRE or routing with IPsec in general? Let me know if anyone needs further information or some pasted configurations. -Thomas _ Check http://us.rd.yahoo.com/evt=51201/*http:/autos.yahoo.com/new_cars.html;_yl c=X3oDMTE5NWVzZGVyBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDYXV0b3MtbmV3Y2Fy %0d%0a out the hottest 2008 models today at Yahoo! Autos. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] IPSec - RSA
Hi Troopy, I haven't actually tried this on a cisco, but I did bit a googling and found this site with an online base64 to hex converter that might help: http://www.net-force.nl/tools/hex_conv/ stig -Original Message- From: Troopy . [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 12:42 AM To: [EMAIL PROTECTED]; vyatta-users@mailman.vyatta.com; Stig Thormodsrud Subject: RE: [Vyatta-users] IPSec - RSA Hello, Thank for your answer. The thing is when i try to copy the public key generated by Vyatta on Cisco, i have an error message on cisco at the firrst non-hexadecimal characters. This is because Cisco accepts only hexadecimal characters in the public key field. crypto key pubkey-chain rsa addressed-key 100.0.0.1 key string Then, Cisco says Enter a public key as a hexadecimal characters the problem is that Vyatta generates its public in ASCII Is it possible to generate the Vyatta public key in hexa? thanks -- Original Message -- From: Stig Thormodsrud [EMAIL PROTECTED] Date: Mon, 1 Oct 2007 08:47:41 -0700 (PDT) Hi Troopy, Im not sure about the cisco error, but on the vyatta side the rsa config would like something like: set vpn ipsec site-to-site peer x.x.x.x authentication mode rsa set vpn ipsec site-to-site peer x.x.x.x authentication rsa-key-sig tunnel-name set vpn rsa-keys rsa-key-name tunnel-name rsa-key 0sAQNwHJia0mD+fNH1uR4vWFlX44UaZEGgVfzWh+IGJlfN3Uw4eFBIL0/vtrRY0U/hkbmbDEN j kTKwY6XtOYK9OPpzOfc5b6fNkY4/7sx9az8Fx19eR4CuGqoNnQveOGVmuNnBDdtYmEKDA4595 R kuZ6wBRV6SoTrHmTe+TRpsitH4UCBWrgaou1RnEWj1zsZsezZhbr5VRDX+ydDgdO9hrtRsREg H h+kYecPVvIRQqms0PZrLuOKyDVI5/zGt1T224VTtaRqsu8UlIYehvlq+k5XrQGhzE9Dxz8kOo n jWnwDMiFly88ZF1f4yDnaZH2JeATER+1aPGSMkJ9DUTnFBAtPvJAVec9+ItGAdjYvhkcpkOah C 6ZK1CSUnnhwAMrDSt5Pz/3oLKjzDMCVIeSuDVCSZz7nnAEBl/JM2+riPqJNaY/ORE1R5xhYnN Y lEZTRMytmbDGA+sSsUliEcMR55c549GoCzOQFfhk9Tqfs/R4RL6Ih9WGejtJ8PrpI81VkTTb3 v QwnKPLUdrd2LmlgnfkCf+ubxz+Mc4Jl4myZ8SVR4iJUNR7jsQLHmwNJwB8GmLfmSUCLPnKDQT 0 VFt3z7Xte14EWteCYKfN0HUBNWM0ofgrhJxSKuOa5MtA3Y9HZZpYIAHxeJbJa0AYXxQy2y6q9 F abBrhURETcuXnlmsQ7SKJw== stig Hello, I have 2 questions concerning vyatta rsa mode: 1. RSA#8722;Encrypted Authentication I am trying to establish a IPSec Tunnel in RSA#8722;Encrypted Authentication mode betwwen Cisco and Vyatta. when i try to copy the Vyatta rsa public key on cisco, there is an error message because Cisco seems to use only hexadecmial caracteres 2. RSA#8722;SIG Authentication/CA Is there a vyatta RSA#8722;SIG Authentication/CA mode? something like the following Cisco config: crypto isakmmp policy 1 authentification rsa-sig Thanks Troopy __ Désirez vous une adresse éléctronique @suisse.com? Visitez la Suisse virtuelle sur http://www.suisse.com ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users __ Désirez vous une adresse éléctronique @suisse.com? Visitez la Suisse virtuelle sur http://www.suisse.com ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] IPSec - RSA
Hi Troopy, Im not sure about the cisco error, but on the vyatta side the rsa config would like something like: set vpn ipsec site-to-site peer x.x.x.x authentication mode rsa set vpn ipsec site-to-site peer x.x.x.x authentication rsa-key-sig tunnel-name set vpn rsa-keys rsa-key-name tunnel-name rsa-key 0sAQNwHJia0mD+fNH1uR4vWFlX44UaZEGgVfzWh+IGJlfN3Uw4eFBIL0/vtrRY0U/hkbmbDENj kTKwY6XtOYK9OPpzOfc5b6fNkY4/7sx9az8Fx19eR4CuGqoNnQveOGVmuNnBDdtYmEKDA4595R kuZ6wBRV6SoTrHmTe+TRpsitH4UCBWrgaou1RnEWj1zsZsezZhbr5VRDX+ydDgdO9hrtRsREgH h+kYecPVvIRQqms0PZrLuOKyDVI5/zGt1T224VTtaRqsu8UlIYehvlq+k5XrQGhzE9Dxz8kOon jWnwDMiFly88ZF1f4yDnaZH2JeATER+1aPGSMkJ9DUTnFBAtPvJAVec9+ItGAdjYvhkcpkOahC 6ZK1CSUnnhwAMrDSt5Pz/3oLKjzDMCVIeSuDVCSZz7nnAEBl/JM2+riPqJNaY/ORE1R5xhYnNY lEZTRMytmbDGA+sSsUliEcMR55c549GoCzOQFfhk9Tqfs/R4RL6Ih9WGejtJ8PrpI81VkTTb3v QwnKPLUdrd2LmlgnfkCf+ubxz+Mc4Jl4myZ8SVR4iJUNR7jsQLHmwNJwB8GmLfmSUCLPnKDQT0 VFt3z7Xte14EWteCYKfN0HUBNWM0ofgrhJxSKuOa5MtA3Y9HZZpYIAHxeJbJa0AYXxQy2y6q9F abBrhURETcuXnlmsQ7SKJw== stig Hello, I have 2 questions concerning vyatta rsa mode: 1. RSA#8722;Encrypted Authentication I am trying to establish a IPSec Tunnel in RSA#8722;Encrypted Authentication mode betwwen Cisco and Vyatta. when i try to copy the Vyatta rsa public key on cisco, there is an error message because Cisco seems to use only hexadecmial caracteres 2. RSA#8722;SIG Authentication/CA Is there a vyatta RSA#8722;SIG Authentication/CA mode? something like the following Cisco config: crypto isakmmp policy 1 authentification rsa-sig Thanks Troopy __ Désirez vous une adresse éléctronique @suisse.com? Visitez la Suisse virtuelle sur http://www.suisse.com ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] VRRP Problems
Hi Dominique,
I don't see anything wrong with your config, so it's puzzling that the
other processes aren't getting started. You might be running into bug
2325 (https://bugzilla.vyatta.com/show_bug.cgi?id=2325) , but then you
probably would have additional error messages in your log. I might be
interesting to try to manually start the process from the linux shell to
see if it gives any error messages. Try (/opt/vyatta/sbin/vrrpd -i
eth6.102 -v 102 -p 150 -d 1 10.2.102.1)
stig
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dominique
Jeannerod
Sent: Thursday, September 27, 2007 6:02 AM
To: vyatta-users@mailman.vyatta.com
Subject: [Vyatta-users] VRRP Problems
Hello,
i'm trying to configure a Vyatta OFR on a Xen virtual machine, configured
with 10 ethernet interfaces, some of them tagged.
When I configure VRRP on one of them (only one), everything is ok :
- I see the vrrp process,
- I can ping the VRRP IP
- show vrrp output shows the VVRP interface, and ip addr on linux
shows also the right IP addresses.
This works ok for standard eth interfaces and also for tagged ones.
Here is the conf of some of them :
ethernet eth1 {
hw-id: 00:16:3E:2A:22:13
address 10.1.1.252 {
prefix-length: 24
}
vrrp {
virtual-address: 10.1.1.251
priority: 150
}
ethernet eth5 {
hw-id: 00:16:3E:4A:FD:4B
vif 101 {
address 10.2.101.2 {
prefix-length: 24
}
vrrp {
vrrp-group: 101
virtual-address: 10.2.101.1
priority: 150
}
}
But when I'm trying to configure several ones (eth1, eth5, eth6, eth7)
with VRRP, VRRP starts only on 2 of them, even after reboot, and it looks
like the vrrp process is not started. One example :
Vyatta Conf
[EMAIL PROTECTED] show configuration
protocols {
static {
route 0.0.0.0/0 {
next-hop: xxx.xxx.xxx.xxx
}
}
}
policy {
}
interfaces {
loopback lo {
}
ethernet eth0 {
hw-id: 00:16:3E:5C:AE:13
address 193.33.79.10 {
prefix-length: 24
}
}
ethernet eth1 {
hw-id: 00:16:3E:2A:22:13
address 10.1.1.252 {
prefix-length: 24
}
vrrp {
virtual-address: 10.1.1.251
priority: 150
}
}
ethernet eth2 {
hw-id: 00:16:3E:10:7A:CD
}
ethernet eth3 {
hw-id: 00:16:3E:0E:F6:9B
}
ethernet eth4 {
hw-id: 00:16:3E:4F:69:1E
}
ethernet eth5 {
hw-id: 00:16:3E:4A:FD:4B
vif 101 {
address 10.2.101.2 {
prefix-length: 24
}
vrrp {
vrrp-group: 101
virtual-address: 10.2.101.1
priority: 150
}
}
}
ethernet eth6 {
hw-id: 00:16:3E:65:DE:08
vif 102 {
address 10.2.102.2 {
prefix-length: 24
}
vrrp {
vrrp-group: 102
virtual-address: 10.2.102.1
priority: 150
}
}
}
ethernet eth7 {
hw-id: 00:16:3E:71:4C:10
vif 103 {
address 10.2.103.2 {
prefix-length: 24
}
vrrp {
vrrp-group: 103
virtual-address: 10.2.103.1
priority: 150
}
}
}
firewall {
}
service {
http {
}
ssh {
}
}
system {
host-name: sv-inf-tst-fw-01
domain-name: hostics.fr
name-server 10.1.1.202
name-server 10.1.1.201
ntp-server 10.1.1.202
ntp-server 10.1.1.201
login {
user root {
authentication {
encrypted-password: $1$$Ht7gBYnxI1xCdO/JOnodh.
}
}
user vyatta {
authentication {
encrypted-password: $1$$Ht7gBYnxI1xCdO/JOnodh.
}
}
}
package {
repository community {
component: main
url: http://archive.vyatta.com/vyatta;
}
}
}
rtrmgr {
config-directory: /opt/vyatta/etc/config
}
ps -ef | grep vrrp output :
root 2585 1 0 12:03 ?00:00:00 /opt/vyatta/sbin/vrrpd -i
eth1 -v 1 -p 150 -d 1 10.1.1.251
root 2590 1 0 12:03 ?00:00:00
Re: [Vyatta-users] Using xorpsh non-interactively
One more thing: Watch out for empty lines at the end of the files Oh yeah, seemed to be a CR/LF vs CR thing. https://bugzilla.vyatta.com/show_bug.cgi?id=1880 stig _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Sent: Tuesday, September 18, 2007 11:29 AM To: vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] Using xorpsh non-interactively One more thing: Watch out for empty lines at the end of the files. You can get all sorts of problems then. Should be in the mail or bugzilla archives, can't remember which Jon On 9/18/07, Stig Thormodsrud mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I need to set a few 'configure' paramters non-interactively as soon as the router boots up. For instance, to set the host-name I run: xorphsh -c configure set system host-name myrouter1 xorphsh -c configure commit That doesn't seem to work. Can someone please tell me the correct incantation for xorpsh in non-interactive mode ? I think you can feed it a file with your commands such as: cat /tmp/foo configure set system host-name jimbob commit ^d Then: xorpsh /tmp/foo Or from a shell script: #!/bin/sh xorpsh ! configure set system host-name joebob commit ! Hope that works for you. stig Thanks Ramaswamy __ __ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Allowing FTP Connections
Dave probably meant tshark instead of wireshark.
stig
-Original Message-
From: [EMAIL PROTECTED] [mailto:vyatta-users-
[EMAIL PROTECTED] On Behalf Of Dave Roberts
Sent: Tuesday, August 28, 2007 9:34 AM
To: 'Daren Tay'; 'Wink'; vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] Allowing FTP Connections
No, on the router. Login in as root and fireup Wireshark.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Daren Tay
Sent: Tuesday, August 28, 2007 4:32 AM
To: Wink; vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] Allowing FTP Connections
woah... on the desktop that i am trying to connect from?
-Original Message-
From: Wink [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 28 August 2007 19:14
To: Daren Tay; vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] Allowing FTP Connections
Packet captures? Perhaps the forwarding function is working.
I'd run wireshark and see if the FTP packets are being
forwarded out of the router...
- Original Message -
From: Daren Tay [EMAIL PROTECTED]
To: vyatta-users@mailman.vyatta.com
Sent: Tuesday, August 28, 2007 6:09 AM
Subject: [Vyatta-users] Allowing FTP Connections
Hi guys,
I realise after setting all the static routes, and what
not, I can SSH
but I can't FTP. weird...
basically the public ip is at my router which directs to my private
server
(192.168.40.x) via routing.
The 2 key NAT rules are:
rule 1 {
type: source
translation-type: masquerade
outbound-interface: eth0
protocols: all
source {
network: 192.168.40.0/24
}
destination {
network: 0.0.0.0/0
}
}
rule 12 {
type: destination
translation-type: static
inbound-interface: eth0
protocols: all
source {
network: 0.0.0.0/0
}
destination {
address: public ip
}
inside-address {
address: 192.168.40.73
}
}
Can SSH, HTTP etc, but I can't do FTP weirdly do I need
to do more
NAT?
Thanks!
Daren
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.484 / Virus Database: 269.12.10/976 - Release Date:
8/27/2007 6:20 PM
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
