Pavlin,
I'm running my experiments using virtual machines using KVM(QEMU) software
which run Debian x86_64 GNU/Linux with kernel 2.6.22-3-amd64.
Your statement about which is the behavior that I had observed of XORP is
right. I can't recall any other important detail about my experiments that I
haven't metioned before. Except, for running my experiments what I did was
to configured the interfaces in system's shell and then boot XORP RTRMGR.
I've to mention that I didn't configured any FEA parameter at all.
Here is the output that you asked me for on previous e-mail:
[EMAIL PROTECTED]> show interfaces
eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
physical index 5
ether 52:54:0:12:35:52
eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
physical index 6
ether 52:54:0:12:35:52
[EMAIL PROTECTED]> exit
Route-Server:~# ifconfig eth1.12 down
Route-Server:~# ip addr
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe12:3552/64 scope link
valid_lft forever preferred_lft forever
4: [EMAIL PROTECTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff
inet 10.100.100.1/24 brd 10.100.100.255 scope global eth1.3
inet6 fe80::5054:ff:fe12:3552/64 scope link
valid_lft forever preferred_lft forever
5: [EMAIL PROTECTED]: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue
link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1.12
6: [EMAIL PROTECTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.2/24 brd 192.168.2.255 scope global eth1.13
inet6 fe80::5054:ff:fe12:3552/64 scope link
valid_lft forever preferred_lft forever
Route-Server:~# /usr/local/xorp-1.5/rtrmgr/./xorpsh
Welcome to XORP on Route-Server
[EMAIL PROTECTED]> show interfaces
eth1.12: Flags:<> mtu 1500 speed 100 Mbps
physical index 5
ether 52:54:0:12:35:52
eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
physical index 6
ether 52:54:0:12:35:52
[EMAIL PROTECTED]> exit
Route-Server:~# ifconfig eth1.12 up
Route-Server:~# ip addr
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe12:3552/64 scope link
valid_lft forever preferred_lft forever
4: [EMAIL PROTECTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff
inet 10.100.100.1/24 brd 10.100.100.255 scope global eth1.3
inet6 fe80::5054:ff:fe12:3552/64 scope link
valid_lft forever preferred_lft forever
5: [EMAIL PROTECTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1.12
inet6 fe80::5054:ff:fe12:3552/64 scope link
valid_lft forever preferred_lft forever
6: [EMAIL PROTECTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.2/24 brd 192.168.2.255 scope global eth1.13
inet6 fe80::5054:ff:fe12:3552/64 scope link
valid_lft forever preferred_lft forever
Route-Server:~# /usr/local/xorp-1.5/rtrmgr/./xorpsh
Welcome to XORP on Route-Server
[EMAIL PROTECTED]> show interfaces
eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
physical index 5
ether 52:54:0:12:35:52
eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
physical index 6
ether 52:54:0:12:35:52
As you can see, the IP address is in kernel.
Please let me know if I can provide any additional information that you
think might be important.
Francisco
-----Original Message-----
From: Pavlin Radoslavov [mailto:[EMAIL PROTECTED]
Sent: 21 August 2008 05:51
To: Francisco Rodriguez
Cc: 'Pavlin Radoslavov'; [email protected]; [EMAIL PROTECTED]
Subject: Re: [Xorp-hackers] OSPF bug(s) in XORP-1.5
Francisco,
In the example below it appears to me the issue is that setting
"disable" to true for "default-system-config" interface is no-op.
FYI, I tried it with VLAN and regular interface, and I observed same
behariov.
In my original email I wrote:
* If you use the "default-system-config" statement, all the
configuration information and changes should come from the
underlying system. However, if you "disable" an
interface/vif/address by using xorpsh, the "disable" state will have
effect only inside XORP; i.e., it will not be propagated to the
kernel.
After I checked with the source code implementation, it appears that
the second sentence above (about the "disable" flag) is incorrect.
Currently, if "default-system-config" is set for an interface, all
the state will come from the UNIX kernel, and the "disable" XORP
flag is ignored.
In other words, I believe what you see below is correct (it is
consistent with the above correction).
Please let me know if I missed something from your experiment and
description.
I am still puzzled by the disappearance of the IP address (from your
previous email), but as I described in my previous email I couldn't
reproduce it.
Thanks,
Pavlin
Francisco Rodriguez <[EMAIL PROTECTED]> wrote:
> Pavlin,
>
> I have noticed that the behavior that I described in the previous e-mail
is
> only presented when disabling a VLAN interface (eth1.12), and not a main
> interface (i.e. eth1).
>
> Here is the output of such failure:
> [EMAIL PROTECTED]> show interfaces
> eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100
Mbps
> inet6 fe80::5054:ff:fe12:3552 prefixlen 64
> inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
> physical index 5
> ether 52:54:0:12:35:52
> eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100
Mbps
> inet6 fe80::5054:ff:fe12:3552 prefixlen 64
> inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
> physical index 6
> ether 52:54:0:12:35:52
> [EMAIL PROTECTED]> show ospf4 neighbor
> Address Interface State ID Pri
Dead
> 192.168.1.3 eth1.12/eth1.12 Full 192.168.1.3 128
39
> 192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128
> [EMAIL PROTECTED]> show interfaces
> eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100
Mbps
> inet6 fe80::5054:ff:fe12:3552 prefixlen 64
> inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
> physical index 5
> ether 52:54:0:12:35:52
> eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100
Mbps
> inet6 fe80::5054:ff:fe12:3552 prefixlen 64
> inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
> physical index 6
> ether 52:54:0:12:35:52
>
> [EMAIL PROTECTED] create interfaces interface eth1.12 disable true
> [EMAIL PROTECTED] commit
> [EMAIL PROTECTED] exit
> [EMAIL PROTECTED]> show interfaces
> eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100
Mbps
> inet6 fe80::5054:ff:fe12:3552 prefixlen 64
> inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
> physical index 5
> ether 52:54:0:12:35:52
> eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100
Mbps
> inet6 fe80::5054:ff:fe12:3552 prefixlen 64
> inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
> physical index 6
> ether 52:54:0:12:35:52
> [EMAIL PROTECTED]> show ospf4 neighbor
> Address Interface State ID Pri
Dead
> 192.168.1.3 eth1.12/eth1.12 Full 192.168.1.3 128
39
> 192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128
35
> [EMAIL PROTECTED]> configure
> [EMAIL PROTECTED] show interfaces
> interface "eth1.12" {
> description: "Network 192.168.1.0/24 for DVR01 Route Server"
> disable: true
> default-system-config
> }
> interface "eth1.13" {
> description: "Network 192.168.2.0/24 for DVR01 Route Server"
> default-system-config
> }
>
> Now if I try to enable-disable the interface again I have the same
results:
> [EMAIL PROTECTED] create interfaces interface eth1.12 disable false
> [EMAIL PROTECTED] commit
> [EMAIL PROTECTED] exit
> [EMAIL PROTECTED] create interfaces interface eth1.12 disable true
> [EMAIL PROTECTED] commit
> [EMAIL PROTECTED] show interfaces
> interface "eth1.12" {
> description: "Network 192.168.1.0/24 for DVR01 Route Server"
> disable: true
> default-system-config
> }
> interface "eth1.13" {
> description: "Network 192.168.2.0/24 for DVR01 Route Server"
> default-system-config
> }
>
> [edit]
> [EMAIL PROTECTED] exit
> [EMAIL PROTECTED]> show interfaces
> eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100
Mbps
> inet6 fe80::5054:ff:fe12:3552 prefixlen 64
> inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
> physical index 5
> ether 52:54:0:12:35:52
> eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100
Mbps
> inet6 fe80::5054:ff:fe12:3552 prefixlen 64
> inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
> physical index 6
> ether 52:54:0:12:35:52
> [EMAIL PROTECTED]> show ospf4 neighbor
> Address Interface State ID Pri
Dead
> 192.168.1.3 eth1.12/eth1.12 Full 192.168.1.3 128
35
> 192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128
31
>
> As described in previous e-mail, it seems to be a FEA problem.
>
> Cheers,
> Francisco
>
>
> -----Original Message-----
> From: Pavlin Radoslavov [mailto:[EMAIL PROTECTED]
> Sent: 08 August 2008 18:33
> To: Francisco Rodriguez
> Cc: [EMAIL PROTECTED]; [email protected]
> Subject: Re: [Xorp-hackers] OSPF bug(s) in XORP-1.5
>
>
> Francisco,
>
> At the high level, the interface configuration should work as
> follows:
>
> * If you use the "default-system-config" statement, all the
> configuration information and changes should come from the
> underlying system. However, if you "disable" an
> interface/vif/address by using xorpsh, the "disable" state will have
> effect only inside XORP; i.e., it will not be propagated to the
> kernel.
> This behavior is intentional by design.
> In this setup if you use "ifconfig" to change interface status,
> this change should be proparaged to the FEA and the rest of the
> XORP processes.
>
> * If you explicitly configure an interface/vif/address through XORP,
> then the the configuration information/changes should come through
> XORP. In that case you should *not* use "ifconfig" to change the
> interface.
> Making changes from both xorpsh and ifconfig can lead to
> possible configuration inconsistency.
>
> See additional comments inline.
>
> Francisco Rodriguez <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi,
> >
> > I have done further tests and realized which was the real problem.
> >
> > OSPF appears to update correctly, although XORP in general might be
> affected
> > by the different ways in which you can simulate a network failure.
> > For example, I was trying to simulate a failure by just entering the
> command
> > "ifconfig <int1> down" which effectively will cause XORP to detect a
> > failure. But, if I enter the command "ifconfig <int1> up", then XORP
will
> > detect the interface was coming up, but in this case the routing
protocol
> > process (OSPF) have an inconvenient with that, and will not update its
RIB
> > neither its neighbors as a consequence. It's important to mention that I
> > enter these commands in the system's shell, situation that XORP didn't
> liked
> > at all. Its better to log into XORP's shell (./xorpsh) and make the
> changes
>
> Could you confirm that in this experiment you explicitly configure
> the interface in xorpsh and did not use the default-system-config
> statement.
> If you did not use the default-system-config, and you used
> "ifconfig" to manipulate the interface, then all bets are off (see
> above).
> However, if the FEA detected the interface coming up, the rest of
> the XORP processes (incl. OSPF) should also detect that.
> Could you confirm that "show interfaces" indeed shows that the
> interface/vif/address are all UP.
> This will tell us whether the problem is in the FEA or OSPF.
>
> > there. Also, I noticed that there are different levels at which we
should
> be
> > able to disable a physical port (interface, vif, address). I noticed
that
> > the only way I was able to completely disable the whole interface was by
> > entering the command:
> > "create interfaces interface <int1> vif <int1> address <ip_address>
> disable
> > true".
>
> I presume that in this experiment you did not use the
> "default-system-config" statement.
> In that case if you disable an interface, then all vifs and
> addresses below it will be disabled. Same applies for disabling a
> vif.
> Could you run again the "show interfaces" command to help us
> identify where the problem is.
>
> > Also I noticed that this command will only have effect when interface's
> > configuration didn't take system's default configuration settings
> > ("default-system-config"). Furthermore, when using
"default-system-config"
> > command and entering an interface disable command in XORP's shell, at
> > interface/vif level, it won't disable the interface/vif at all, but
> prevent
> > the use of such interface/vif by XORP processes. For this case, entering
> an
> > "ifconfig <int> down" command will definitely disable the interface.
>
> This is the intended behavior. See the explanation in the beginning
> of this email.
>
> Pavlin
>
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
